In praise of OSSTMM
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
https://www.infosecisland.com/blogview/14651-How-to-Pen-Test-Crazy.html
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
OSSTMM Logo
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.
8 Dirty Secrets of the IT Security Industry – CSO.com
Image via Wikipedia
Do make note of points 1,3, and 6.
I particularly appreciated the subtext of the wording of #1.
Vendors don't need to be ahead of the threat, just the buyer.
We all know the story of the two campers and the bear, but this is an interesting variation. We've just discussed Mr Carr screaming about how he wasn't told by his security staff that there were more threats.
Yes but ... Its not the security staff that set the budget or make the buying decisions. Look: it says "buyer", not "customer".
How often have you had your security advice over-ridden for anyone of a number of reasons? Its not you doing the BUYING is it.
And why do you think that the saleswomen wear suits and talk in that stupid language using terms like "solution" (oh-ho, watch out, here comes Les...) and "bottom line" and other stuff that has nothing to do with InfoSec.
'Cos it isn't YOU doing the buying.
At best they throw you a bone since you might be an 'influencer' - more salesman-speak. (But 'influencer' is too close to 'influenza' which is why they don't get too close to you...)
Mean while, you're talking to your manager about all these nasty things like threats and the possibility of embarrassment in the press and lawsuits, while that nicely dressed saleslady is talking sweetly about nice things such as profit and success and such like.
Image via Wikipedia
Lets face it, the game is semantically rigged against us.
"Given a choice between dancing pigs and security, users will pick dancing pigs every time."
"Oh look http://pics4.city-data.com/cpicc/cfiles34082.jpg hey, that's neat, I didn't know they could do that...."
Related articles
- InfoSec In The Supply Chain (blogs.forrester.com)
Security Posture Assessment resources
No, I don't think this is a good start.
Its ignores such fundamentals as policy, change management, awareness, management reporting, risk assessment and risk tolerance ...
And much like that.
Couldn’t happen to a nicer buncha guys …
An independent security consultant describes how vulnerabilities in
unpatched releases of the Zeus crimeware kit are being exploited by
hackers in order to steal resources from their fellow criminals. The
security researcher has come across an interesting posting made by a
botnet runner, who asks for help to secure his infrastructure after
being compromised several times by other hackers.
http://news.softpedia.com/news/Cyber-criminals-Target-Their-Own-Kind-105728.shtml
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=c878b56c-41ae-4b9d-9461-2618b4037ecb)
Separation of Duties: InfoSec, IT and Audit
A colleague who had the opportunity to restructure the role of his InfoSec department asked for advice about defining the roles and duties and how to make his department more effective.
Being very conservative in some ways I recommended a traditional Separation of Duties. It begins with what might be described, for lack of a better term as "the separation of InfoSec and IT".
In the limiting case:
- IT "makes it so"
- Audit makes sure that they did.
in other words InfoSec addresses the areas you've expressed concerns about responsibility for by setting policy, standards and requirements (?compliance?). IT is responsible for the implementation, the hardware, the software, its installation and maintenance.
It can be an easy sell if you approach it properly.
| You: | See that firewall? |
| IT: | Yea, what about it? |
| You: | Its on the network, right? |
| IT: | Yea, where the f*** do you think it should be? You bu**ers are always interfering. |
| You: | And you guys take care of the network and stuff on the network? |
| IT: | When you bu**ers don't interfere. |
| You: | Well we're not going to. Its yours. We won't touch it. We won't go off and buy stuff and put it on your network. |
| IT: | Are you serious? |
| You: | Yes. |
| IT: | Can I have that in writing? |
| You: | Yes. I'll copy you on the roles & responsibilities and separation of duties documents. As well as the policies, compliance and audit requirements. |
Smile when you say that, but don't make it a predatory smile.
Yes, that makes it sound easy, but reality never is, is it?
That's why people buy books that offer the same kind of advice.
If you really want to work it through, try the books by The Harvard Negotiation Project:
* Getting to Yes: Negotiating Agreement Without Giving In
* Difficult Conversations: How to Discuss what Matters Most
* Getting Past No: Negotiating Your Way from Confrontation to Cooperation
* Getting Ready to Negotiate
Consultants, that is people with no formal authority in the hierarchy, may also appreciate
(Another time I'll discuss the stupid idea that some people in the recruiting profession have that because 'consultants' don't occupy a line-management role that they have no management skills or experience.)
The technical staff in the IT department may be perturbed in a number of ways. They might feel that their 'freedoms' are being removed and they are being 'policed'. Make it clear to them that YOU are not policing them. AUDIT is policing them. That is the correct corporate role for audit.
InfoSec is writing the specs - the policy, the requirements, and they are doing it in cooperation with not only IT but also with other stakeholders in the business and to make sure that the IT department is serving the needs of the business and not just collecting expensive "Toys For Boys".
This is no different from a software or hardware development situation, or, for that mater, the original set-up and procurement that went onto IT.
Someone did a needs analysis (even if it was only guesswork and estimations on a paper napkin), wrote up a requirement and handed it over to the people with a Picard-like order to "made it so".
I appreciate that this 'formal' approach is being depreciated by 'agile' methodologies where the techies work without any of the formal management structure, without specifications or formal requirement, writing and running their own tests, all in the name of "Web 2.0".
However the original idea as to set up a formal system of division of responsibility and duties and to deal with strengths and specializations.
Many people think that by fitting in with the power of a formal system they are giving up 'freedom'. They don't see the power of having all that organization (and buying power) behind them, of having defined roles that offload from them the detailed housekeeping that slows them down. They only think in terms of the Marxist cant about oppressive 'production lines' that dumb down the worker into an automation.
This is short-sighted and they know it if they'd stop and think about it.
Lets look at an example out of IT: The compiler - a tool that takes a high level requirement and specification and converts it to the fiddly assembly code - is one they accept. But some of us are old enough to remember the arguments against compilers, that they couldn't produce the same quality code as good assembly programmer.
Perhaps: that may have been true back 30 years but its not now. Now compilers are 'expert systems' in code generation for very complex CPUs and instruction streams and branches. Programmers recognise this and accept it, often without thinking very deeply about it - they just code in the HLL and the compiler "makes it so" that it runs on the machine. But even 30 years ago compilers could produce assembly code to match a 'good' assembly programmer - but at 10 to 100 times the speed and when used by a middling programmer who understood the subject matter of the application better than he did the hardware of the computer did a very good job of delivering the application program.
This is a classic example of abstracting and encapsulating specialized knowledge and division of labour.
I have no doubt that today's programmers would be upset if you took away their compilers.
What I am suggesting in this separation of duties between InfoSec, IT and Audit is no different from a doctor writing a prescription and the patient taking it to an apothecary to be filled. The apothecary isn't doing the diagnosis or needs analysis, but he still plays an essential role.
The "You" in InfoSec, have to understand business needs, regulations, compliance issues. The "Them" in IT have to understand the details of the technology they are working with. Each have their roles to play.
Its when people start interfering with these responsibilities, these 'separation of duties', that things get upset.
Related articles
"Paid to be paranoid"(infosecblog.antonaylward.com)
