The fatal flaw in IT Risk management
Is interviewing is a much better method that self-certifications and a checklist, if time and resources allow.
Two points:
In the ISO-27001 forum, my friend and colleague Gary Hinson has repeatedly pointed out, and I fully support him in this, that downloading check-lists from the 'Net and adopting question lists from there is using a solution to someone else's
problem. If that.
Each business has both generic problems (governments, sunspots, meteor strikes, floods & other apocalyptic threats and Acts of God) and ones specific to it way of working and configuration. Acts of God are best covered by prayer and insurance.
Gary recommends "open ended questions" during the interview rather than ones that require a yes/no answer. That's good, but I see problems with that. I prefer to ask "Tell me about your job" rather than "Tell me how your job ... can be made more efficient".
My second point is that risk management will *ALWAYS* fail if the risk analysis is inadequate. How much of the RA should be done by interviewing people like the sysadmins I don't know, but I have my doubts. I look to the Challenger Disaster. I started in the aviation business and we refines FMEA - failure Mode Effect Analysis. Some people think of this in terms of "impact", but really its more than that, its also causal analysis. As Les Bell, a friend who is also a pilot and interested in aviation matters has pointed out to me, "Root Cause Analysis" no longer is adequate, failure comes about because of a number of circumstances, and it may not even be a single failure - the 'tree' fans both ways!
Yes, FMEA can't be dome blindly, but failure modes that pertain to the business - which is what really counts -- and the fan-in/out trees can be worked out even without the technical details. Rating the "risk": is what requires the drill-down.
Which gets back to Donn Parker's point in a number of his books, though he never states it this way. The FMEA tree can be heavily pruned using diligence as he says: standards, compliance, contracts, audits, good practices, available products. The only thing he leaves out are Policy and Training. Policy gives direction and is essential to any purpose, the choice of standards and products, and identifying what training is needed.
All in all, the article at https://blog.anitian.com/flawed-it-risk-management/ takes a lot of words to say a few simple concepts.
How to build an asset inventory for 27001
How do you know WHAT assets are to be included in the ISO-27K Asset Inventory?
This question and variants of the "What are assets [for ISO27K]?" comes up often and has seen much discussion on the various InfoSec forums I subscribe to.
Perhaps some ITIL influence is need. Or perhaps not since that might be too reductionist.
The important thing to note here is that the POV of the accountants/book-keepers is not the same as the ISO27K one. To them, an asset is something that was purchased and either depreciates in value, according to the rules of the tax authority you operate under, or appreciates in value (perhaps) according to the market, such as land and buildings.
Here in Canada, computer hardware and software depreciates PDQ under this scheme, so that the essential software on which you company depends is deemed worthless by the accountants. Their view is that depreciable assets should be replaced when they reach the end of their accounting-life. Your departmental budget may say different.
Many of the ISO27K Assets are things the accountants don't see: data, processes, relationships, know-how, documentation.
Help on ISO-27000 SoA
This kind of question keeps coming up, many people are unclear about the Statement of Applicability on ISO-27000.
The SoA should outline the measures to be taken in order to reduce risks such as those mentioned in Annex A of the standard. These are based on 'Controls'.
But if you are using closed-source products such as those from Microsoft, are you giving up control? Things like validation checks and integrity controls are are 'internal'.
Well, its a bit of a word-play.
- SoA contains exclusions on controls that are not applicable because the organization doesn't deal with these problems (ie ecommerce)
- SoA contains exclusions on controls that pose a threat (and risks arise) but cannot be helped (ie A.12.2 Correct processing in applications) and no measures can be taken to reduce these risks.
With this, a record must be present in risk assessments, stating that the risk (even if it is above minimum accepted risk level) is accepted
The key to the SOA is SCOPE.
“Cybercrime” is still Crime and “Cyberfraud” is still Fraud
This says it all:
At the end of the day, cybercriminal activity is not all that different
from more traditional forms of organized crime. Obviously, the way the
crime is perpetrated is new, but the ways in which cybercriminals
operate is not all that different from anything that has gone on before.
Heck, once upon a time there was no telegraph, no "Royal Mail" (or whatever the equivalent in your state/nation). But when those came along they offered new opportunities for fraud. Most places have laws in place again fraud perpetrated by mail or telegraph and telegraph
includes the telephone.
And this is where I get to wonder at how our politicians work, the knee-jerk "something must be done NOW" attitude.
Here in Canada we have a criminal code. It covers fraud. We don't need new laws to deal with cybercrime because the ways our laws are written they are general and not reductionist. They specify the crime, not the technology used.
I get the impression that in the USA (and possibly other places) its the other way round. That's why they need lots of new laws to address every fine-grained detail as the technology advances. Personally I don't think this is a good way of working since it piles laws upon laws.
In science we was that in astronomy before Newton. The classical "Ptolemaic" system piled epicycles upon epicycles as corrections because the underlying model based on a geocentric approach and the idea of 'perfect spheres' was fundamentally flawed. Piling human laws upon human laws to deal with special cases of what is really a general
situation is no less flawed in approach.
Fraud is fraud is fraud. It doesn't matter if its perpetrated by a hustler in person as in the scenes in "Paper Moon", by mail, over the phone or using the Internet. Fraud is fraud is fraud.
We don't need new laws; we just need a better understanding of how criminals use technology. We perhaps we security droids don't, perhaps the public, the police, the legislators and the managers of the firms and organizations impacted by such criminals need that understanding.
But that's not what detailed, reductionist legislation is going to achieve, is it?
Related articles
- Guarding your business against cybercrime (premierlinedirect.co.uk)
- Interpol Promises New Center to Fight the E-Mob (spectrum.ieee.org)
- Russian Cybercrime pays! (toinformistoinfluence.com)
- Cybercrime 'cannot be stopped entirely' (premierlinedirect.co.uk)
- Former National Cyber Czar Creates Cybercrime TV (prweb.com)
- There's no business like Cybercrime business! (blog.bt.com)
- Impact of cybercrime underestimated as most crimes go unreported|Network security (c24.co.uk)
- European Commission wants a cybercrime centre (h-online.com)
- Everything you thought you knew about cybercrims is WRONG (go.theregister.com)
- FBI finds scammers impersonating the FBI now one of worst online threats (theneteconomy.wordpress.com)
- Educate Customers on Mass Marketing Fraud (ibaeducationblog.com)
- Cybercriminals offer bogus fraud insurance services (zdnet.com)
Which Risk Framework to Use: FAIR, FRAP, OCTAVE, SABSA …
What framework would you use to provide for quantitative or qualitative risk analysis at both the micro and macro level? I'm asking about a true risk assessment framework not merely a checklist.
Yes, this is a bit of a META-Question. But then its Sunday, a day for contemplation.
When does something like these stop being a check-list and become a framework?
COBIT is very clearly a framework, but not for risk analysis and even the section on risk analysis fits in to a business model rather than a technology model.
ISO-27K is arguably more technology (or at least InfoSec) focused that COBIT, but again risk analysis is only part of what its about. ISO-27K calls itself a standard[1] but in reality its a framework.
The message that these two frameworks send about risk analysis is
Context is Everything
(You expected me to say that, didn't you?)
I'm not sure any RA method works at layer 8 or above. We all know that managers can read our reports and recommendations and ignore them. Or perhaps not read them, since being aware of the risk makes them liable.
Ah. Good point.
On LinkedIn there was a thread asking why banks seem to ignore risk analysis .. presumably because their doing so has brought us to the international financial crisis we're in (though I don't think its that simple).
The trouble is that RA is a bit of a 'hypothetical' exercise.
Risk Analysis Makes No Sense … does it?
- Image via Wikipedia
Take a look at this article.
http://www.zdnet.com/blog/security/security-engineering-broken-promises/6503
You're back? What did you think of it?
OK, now look again, scroll down the section titled "Risk Management". It picks up on a number of themes I've discussed and has this interesting observation:
Prioritization of security efforts is a prudent step, naturally. The problem is that when risk management is done strictly by the numbers, it does deceptively little to actually understand, contain, and manage real-world problems. Instead, it introduces a dangerous fallacy: that structured inadequacy is almost as good as adequacy, and that underfunded security efforts plus risk management are about as good as properly funded security work.
Guess what? No dice:
The author goes on to illustrate a number of ways that the approach we as the InfoSec community have preached and practised makes no sense.
Stolen laptop leads to drug bust
I must admit, this isn't quite what I expected when I read the headline. I was expecting the contents of the laptop that had somehow come into the hands of the police or DEA to contain evidence that lead to the bust. As it was, the recovery was a result of "phone home" software and the
bust was an incidental.
Security software built into a stolen laptop computer led police to a
Hoisington residence on Tuesday. Authorities not only found the
computer, but they also uncovered what appears to be a methamphetamine
lab.
So what is the procedure around the 'phone home' software? Does it
contact the police directly? Does the owner notify the 'phone home'
software vendor and they in turn notify the police when they have a trace?
Detective Denton Doze at the Great Bend Police Department said the
$9,000 computer, along with hand tools and power tools, was stolen
during a burglary reported last Friday at the My Town project, 1419 Main
Street.
That must have been quite some laptop!
As of Wednesday evening, the missing tools had not been accounted for.
Well, obviously. They don't have 'phone home' software that runs when they are used.