Incident Response | Chakraborty Software

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