Incident or Event Management: Keep it simple but real! By Brad C. Johnson

There is probably no single topic area that is more documented and discussed than that of Incident or Event Management. In addition, there are as many tools in this space – public domain, open source, and 3rd party programs –as almost any other area for your IT environment. Yet oddly, this is one of the areas almost every organization has problems with.

In an article in the June addition of ISSA I addressed a number of important basic security areas including this one (here is a copy of that article: http://www.systemexperts.com/assets/pdf/ISSA0710-Johnson-SecurityBasics.pdf). Let’s revisit some of the key issues in this area of incident management.

All too often, people wait until after they have had an incident to figure out a plan for reacting to one. The normal outcome is that they are woefully unprepared for the first incident, gather the wrong information, do not know who to contact or who is responsible for managing the situation, and taint the evidence because of the lack of well-documented procedures. While it’s good to be prepared for any incident, it’s usually pretty easy to at least agree on the top 10 events that you know your company should be prepared to handle.

Interestingly, in most cases, the basic instructions of what each person should do will fit on one page. For managing the event you need to clearly state the chain of command for making decisions, define a policy for how your organization will respond, learn, and improve your procedures for future incidents, and make sure you have spoken with appropriate authorities to understand what evidence needs to be collected.

The first step is to develop a (small) list of real-case scenarios that you need to be prepared to handle, for example:

• A virus somehow enters the internal network and is infecting systems
• The corporate website has been defaced
• An unauthorized mobile device has connected to the corporate internal wireless infrastructure

For each of these events, you would want to document the exact steps that each person involved would perform and identify specific people (and their backups) that would execute the work. Once you have defined these things you want to try them out to work out the kinks. Trust me, there will be problems.

Our experience has shown that you will find that there are important steps that have not been documented, that not all of the appropriate people have been identified that need to be involved, and that you have invalid assumptions built into your understanding of what it will take to be fully recovered. It normally takes a number of iterations through the process to fine tune the game plan for a quick recovery.

Let’s get going on this! Document your top 5 incidents, describe who should handle the incident and what they should do, and then try running through those scenarios to work out the fine-grain details so you are prepared to deal with them.