Standards are the best way to prevent staff breaking the
law, writes Daniel G Dresner of theNational Computing
Centre. If this comes as a surprise to
you, then that's simply because standards are so often implemented
only in part.
Some reports of the
recent woes at Société Générale suggest that
standards
were in place but not acted on.
Standards can tell you what checks or measures to take, and are
typically brimming with specifics that can be designed into policy
setting tools, for example. But technology is just one lever in the
mortise lock of security. It also helps to identify where people's
weaknesses lie.
Now, you can't just bounce up to prospective or current staff
and ask, "Are you now or have you ever been a risk?" Everyone with
access to information that can make a difference, whether they have
the authority to manipulate that data or not, is a vulnerability.
As soon as we are given our log-on we are tarred with risk.
But it's not just end-users who represent a security risk to the
business. Whenever businesses set up new operations, they also
generate new risks and temptations.
Fraud has always been a risk for betting shops, for example, and
online gambling is just a new manifestation of that risk. We
need to start from the premise that it's a matter of when, not if,
and then consider the risks carefully, and not turn into control
freaks.
When you've got a handle on your potential risks, it's time to
look at what you can accept, what you can deal with, and what you
can just monitor. Monitoring is useful only if you've got the
decision support structure and the time to deal with the alarms
that are raised. And that decision support structure has to have a
supporting architecture for authority or you may risk collusion
between a supervisor and those supervised, not necessarily in the
crime, but in the concealment of poor supervision.
Quis custodiet ipsos custodes?
Codes of practice
This is why one of the 135 controls in
BS ISO/IEC 27002:2005 (a code of practice for information
security management) is segregation of duties.
While we are talking numbers, have you discovered
BS 7858:2006 (a code of practice for security screening
individuals in security)? If we have responsibility for valuable
assets, we all need to be considered as secure environments. These
environments need to travel with our assets but that's another
discussion. This particular standard recognises that not all human
vulnerabilities are full-time staff, and that staff move round
organisations like pieces on a chessboard. Problems arise if they
are allowed to collect authorities like others collect stamps.
Let IT do the security
Judo is about using your opponent's weight or speed against
them. So if we are committed to facilitating a business with
information and communications technology, let's apply the same
technology to provide the safeguards.
We may be limited by how much ICT is just a model of the
business (attenuating the detail) but we can use it as a regulator
to shape operations to remain within an acceptable risk
profile.
Make
heuristics analysis part of the system to detect worrisome
behaviours and ensure what may be seen as a non-functional
requirement remains up to date with the knowledge of the risks.
Technology can provide the data and must be interfaced with those
with the authority to make decisions within the framework of
acceptability where machines cannot. We could use systems
management tools to generate alerts when persistent or frequent
attempts are made to circumvent current privileges.
Other tell-tale alert-generating behaviour could be attempts to
access certain information from an unusual location, handling an
unusual quantity of information (particularly if attached to an
e-mail, say) or perhaps - in the realms of
biometrics - an usual typing pattern for the profile of who
should be logged.
Now we are not in the realm of insider trading or security of
risk management here, we are staring squarely at software quality.
Systems will need testing for acceptability and this testing will
need to keep up to date with change by testing the regression
effects of those changes as developers react to the constant stream
of user demands. The validation and authorisation of those changes
is critical as is making sure that programmers haven't slipped in
their own little backdoor. Of course, your vetting process should
ensure that you can trust your staff, but people change.
Opportunity makes a thief and a previously trusted employee with
financial woes can turn into one.
Remember the value of people, if you become a slave to the
decisions of the system, prepare to be disappointed. Watch out for
all those smaller, tell-tale disappointments that will suggest
improvement (plan-do-check-act) and turn the inevitability of
forensics into the predictability of foresight.
Read more expert advice from the Computer Weekly Security Think
Tank >>