Standards are the best way to prevent staff breaking the law, writes Daniel G Dresner of the National Computing Centre. If this comes as a surprise to you, then that's simply because standards are so often implemented only in part.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.