Why should they?
They didn't when Gerry Mander presented his Four Arguments for the Elimination of Television, and he was in a position to know.
In case you're not aware, ISECOM (Institute for Security and Open Methodologies) has OSSTMM3 - The Open Source Security Testing Methodology Manual - http://www.isecom.org/osstmm/
There's an interesting segue to this at
Skip over his ranting about the definition of "hackers"
This is the meat:
Wewrote the OSSTMM 3 to address these things. We knew that penetration
testing the way it continued to be marginalized would eventually hurt
security. Yes, the OSSTMM isn't practical for some because it doesn't
match the commercial industry security of today. But that's because the
security model today is crazy! And you don't test crazy with tests
designed to prove crazy. So any penetration testing standard, baseline,
framework, or methodology that focuses on finding and exploiting
vulnerabilities is only perpetuating the one-trick pony problem.
Furthermore it's also perpetuating security through patchity, a process
that's so labor intensive to assure homeostasis that nobody could
maintain it indefinitely which is the exact definition of a loser in the
cat and mouse game. So you can be sure it also doesn't scale at all with
complexity or size.
I've been outspoken against Pen Testing for many years, to my clients, at conferences and in my Blog. I'm sure I've upset many people but I do believe that the model plays up to the Hollywood idea of a Uberhacker,
produces a whack-a-mole attitude and is a an example of avoidance behaviour, avoiding proper testing and risk management such as incident response good facilities management.
I've seen to many "pen testers' and demos of pen testing that are just plain ... STUPID. Unprofessional, unreasonable and pandering to the ignorance of managers.
In the long run the "drama-response" of the classical pen-test approach is unproductive. It teaches management the wrong thing - to respond to drama rather than to set up a good system of governance based on policy, professional staffing, adequate funding and operations based on accepted good principles such as change management.
And worse, it
- shows how little faith your management have in the professional capabilities of their own staff, who are the people who should know the system best, and of the auditors who are trained not only in assessing the system but assessing the business impact of the risks associated with a vulnerability
- has no guarantees about what collateral damage the outsider had to do to gain root
- says nothing about things that are of more importance than any vulnerability, such as your Incident Response procedures
- indicates that your management doesn't understand or make use of a proper development-test-deployment life-cycle
Yes, classical hacker-driven pen testing is more dramatic, in the same way that Hollywood movies are more dramatic. And about as realistic!
"Crazy" is a good description of that approach.
It seems that to make better cybersecurity-related decisions a senior FBI official recommends considering a simple algebraic equation:
rather than solely focusing on threat vectors and actors.
To be honest, I sometimes wonder why people obsess about threat vectors in the first place. There seems to be a beleive that the more threats you face, the higher your risk, regardless of your controls and regardless of the classification of the threats.
Look at it this way: what do you have control over?
Why do you think that people like auditors refer to the protective and detective mechanisms as "controls"?
Yes, if you're a 600,000 lb gorilla like Microsoft you can take down one - insignificant - botnet, but the rest of us don't have control over the threat vectors and threat actors.
What do we have control over?
Vulnerabilities, to some extent. We can patch; we can choose to run alternative software; we can mask off access by the threats to the vulnerabilities. We can do things to reduce the the "vulnerability surface" such as partitioning our networks, restricting access, not exposing more than is absolutely necessary to the Internet (why oh why is your SqlServer visible to the net, why isn't it behind the web server, which in turn is behind a firewall).
Asset to a large extent. Document them. Identify who should be using them and implement IAM.
And very import: we have control over RESPONSE.
Did the FBI equation mention response? I suppose you could say that 'awareness' is a part of a response package. Personally I think that response is a very, very important part of this equation, and its the one you have MOST control over.
And response is - or should be - totally independent of the threats
since it focuses on preserving and recovering the assets.
I think they have it very, very confused and this isn't the most productive, most effective way of going about it. But then the FBI's view of policing is to go after the criminals, and if you consider the criminals to be the threat then that makes sense.
But lest face it, most corporations and are not in the business of policing. neither are home users.
Which is why I focus on the issue of "what you have control over".
Related articles by Zemanta
- School Spy Program Used on Students Contains Hacker-Friendly Security Hole (wired.com)
- The Top 10 Reports For Managing Vulnerabilities (lockergnome.com)
- FBI searching for 'Flavor Flav Bandit' (seattlepi.com)
- Why Security Vendors are loosing (tech.bl0x.info)
- Editorial: Flawed F.B.I. Background Checks (nytimes.com)
- FBI details surge in death threats against lawmakers (americablog.com)
I saw this assertion go by and it stood out:
The bigger cost would be the cost of not patching. Such items as downtime will affect more staff/users than patching will.
The issue so far has been black and white.
There is a black and white difference between devices that face the internet and those that are not accessible to or from the 'Net.
But what about the "grey"? No all patches have the same criticality even for 'Net-facing devices.
And there's more to security - even of the Internet-facing devices - than patching software.