Risk Assessment | Chakraborty Software

Risk Management -- Useless?

Jul 202009

I just read a post on Marcus Ranum’s Tenable Network Security blog, titled “Anatomy of a Security Disaster“. One of his main points appears to be that corporate risk management, by attempting to boil down risks to something easily quantifiable (“trying to balance an unjustified estimate of cost of failure against a wild-ass guess multiplied by a fudge factor”), contributes to bad things happening. According to Ranum, it does this by giving uninformed managers a potential issue that they should not be allowed to sign off on without fully understanding the underlying problem, and without someone in, say, a development process being forced, through increased accountability, to be responsible for making sure things are done right straight off the bat.

There is a very strong thread in the article that risk management, while maybe not directly at fault for either acute or systemic failures, is at least partially to blame for it:

“Unfortunately for us all, the Wall St crash of Dec 2008 serves as a complete debunking of the value of risk management. All the big firms that lost billions or went out of business had risk management departments and practices and felt they were taking acceptable risks. Perhaps the risk management departments were wrong, or perhaps management was living with a reality gap.”

This, bluntly, is nonsense.

First, it is not the fault of a risk management department if management fails to accept a demonstrated risk. Risk analysis will, by its very nature, always be an approximate art (no, not a science, you need to hire people with a lot of experience, and maybe a bit of gut instinct, pay them a bunch of money, and be prepared to trust their analysis.) Otherwise, why would anyone ever address a potential security flaw?

Risk analysis is nothing more than the prioritization of potential problems with a system, process, tool, what have you. It is at the core of any bug fix, response to security failures, in short, any security event. And security events do happen, like it or not. It’s not a perfect world, nobody will ever have all the information, and it is a tired cliché that “hindsight is 20/20″, it’s still true.

Second, a proper risk management process does not just entail handing an incompetent manager a set of gift-wrapped risks on a silver platter and saying, “here you go, enjoy.” That’s called covering your ass. Correctly done risk assessment and management consists of accompanying, for example, a development process from a to z and being the additional pair of eyes to spot non-obvious flaws.

Ranum’s ideas about how to help prevent or reduce the probability of something going pear-shaped are all valid. However, he doesn’t seem to understand that these all constitute part of a correctly designed risk management process.

SOMAP -- Open Source Risk Management

Best Practices, Risk Assessment No Responses »

Nov 252006

I recently stumbled onto the Security Officers Management & Analysis Project and thought I’d share. It’s an attempt to create a community-supported risk analysis processes and best practices repository, and a pretty cool idea at that.

The handbook is currently in version 1.0, downloadable from the site, although some of the other resources (risk analysis guide, repository) are in development. The SOBF (Security Officer’s Best Friend) — a risk reporting and analysis tool is also in beta, but looks to be nearly usable. I am going to have a closer look at this to see how it can work together with more technology-specific risk analysis tools like Symantec’s, or with methods such as CERT’s OCTAVE. As it stands, it might be an interesting start for companies who’re out to build their own custom tools and methodologies anyway.

I hope this doesn’t go the way that the OpenCA/OpenPKI project did a while ago (published a handbook that was a great start, but stagnated for a long time, although there seems to have been some work going on recently.) Check it out.

Edit: Adrian Wiesmann from SOMAP just wrote me a nice note to tell me that they’re working on the second version of SOBF, and are looking for a project manager in Switzerland as of present (25.11.2006.) “To make it less possible that the project stops again right after starting, we are actively looking for a project manager which would coordinate the contributors, manage timelines and subprojects.” So if you’re interested, drop them a line via their website.

Updated Vulnerability Assessment Framework

Network Security, Pen Testing, Risk Assessment No Responses »

Nov 252006

Just a quick note that Kevin at http://www.vulnerabilityassessment.co.uk has a new version of his excellent framework diagram –

http://www.vulnerabilityassessment.co.uk/Framework.png

Good stuff, check it out. I’m a big fan of the pen testing processes he puts up, very methodical. Also check out his ace default password list:

http://www.vulnerabilityassessment.co.uk/passwords.htm — wish I’d had that at Buenos Aires airport, as their wireless routers didn’t seem to be particularly well configured (and of course I’d forgotten to re-build nessus on the Powerbook, joy.)

Incident Response & Risk

Best Practices, Incident Response, Management, Risk Assessment No Responses »

Nov 082006

I created a basic computer security incident response presentation a while ago. It outlines the benefits and concerns involved in the creation of teams and mechanisms tasked with action after computer-related security issues.

Note that a CSIRT doesn’t replace the regular R&D and operations groups, but is a supplementary body, coordinating both preparation for and response to things like information breaches and attacks.

By its very nature, a CSIRT has to have a strong mandate and a lot of authority in an organization; this requires management support, and a lot of it, in addition to a really close and positive relationship with all other teams involved in these activities. Examples of these are the network security organization, various helpdesks, human resources, email administrators and others who may be attached as auxiliaries to a CSIRT.

In order to get this sort of mandate, you will have to coherently demonstrate an overall risks-rewards scenario. So:

What are the threats to my organization and what will I lose if I do nothing about them?
What does my organization stand to gain (productivity enhancements, etc.) by dealing with these in an organized manner?

In my experience, the most positive elements of a CSIRT is that it allows coordinated vulnerability management and a coherent, organization-wide process for things like patching systems and updating security software, in addition to being a locus for discussion and cooperation by various technical groups (the Windows server administrators, UNIX, email, network, security, etc.) This sort of collaboration tends to extend beyond the direct focus of the CSIRT’s day-to-day activities.

A few examples of the logic I use:

Simply put, if you don’t do anything, and something goes wrong, the results can vary from your looking stupid to someone going to jail. There’s a fine line between FUD and realistically outlining possible consequences, and IMHO Sarbanes-Oxley has been a bit overused by enthusiastic security people, but I would clearly outline things like data protection laws or past Bad Things happening when organizations suffered attacks (i.e. British Airways losing several thousand workstations to Blaster.)

I think this is a pretty good outline of what it is I’d propose as a CSIRT’s roles and competence. In your case, you might want to play up the final business value a bit more, maybe put numbers on the risk reduction.

If you contact me and ask nicely, I’ll be glad to share the whole thing.

Basic Incident Response

Incident Response, Risk Assessment No Responses »

Nov 042006

I once helped put together and run a computer security incident response team. The team was unique in drawing a specialist or two from each of the major technical and risk management groups (Windows server support, mail infrastructure, firewall & network security, network, etc.) as well as from the existing financial fraud and internal affairs investigation organization.

Much of our time was spend developing the individual policies and procedures outlining the IRT’s responsibilities, defining authority and basically selling ourselves to both management and the line teams–an investment that paid off pretty well; by involving everyone closely in what we were doing, we received a lot more cooperation than we could have expected had we just been imposed on the company as a fait accompli. In the end we ended up handling several high profile cases pretty successfully. I’ll be writing more on this topic in the future, but the following is a partial outline of what I see as an IRT’s basic responsibilities:
- threat investigation, categorization and warning/announcement

- vulnerability management (a monthly vulnerability board meeting to discuss these)

- investigation of external attacks, bank-related fraud, phishing, etc.

- internal forensics (e.g. information leaks, sabotage, harassment)

We started out essentially from scratch and within the space of about 6 months had a fully functioning organization. Lesson learned: always handle budget and authority first. Lesson #2: PR is as important as substance. Frequently, PR (i.e. keeping people informed clearly and concisely of threats, vulnerabilities and your activities) IS substance, there’s no reason why you can’t combine the two.

Another thing we figured out is that every CSIRT is a tailor-made affair; even in a large corporation, some massaging and diplomacy is required to exert authority in subsidiary companies — again, involving their staff and management and keeping them informed goes a long way towards fostering acceptance.

A few of the links that got us started:

- CERT and it’s “creating a CSIRT” page:

http://www.cert.org/

http://www.cert.org/csirts/Creating-A-CSIRT.html

- The CMU CSIRT handbook:

http://www.sei.cmu.edu/publications/documents/03.reports/03hb002.html

- RFC 2350, Expectations for Computer Security Incident Response:

http://www.ietf.org/rfc/rfc2350.txt