Security Incident Response

By Rich Loeber,

As the security officer for your IBM i shop, you've done all you can to lock down your systems and implement your organization's security policy. Once you're all set up and configured, you think you're looking good, but there may be a piece of the puzzle that is still missing. One thing we know for certain with computers is that no system is perfect. So, there is still the possibility that something will break down in the security design for your shop. This tip will take a look at what you should do when something goes wrong.

Security incident response consists of several steps and processes that you should document for your organization. There are all sorts of event types that you may be faced with and each one can have a number of responses or actions that you will need to consider.

A security incident is something that has, at its root cause, the action of a person or group of people. Incidents can have varying degrees of severity and the first step in a response is to decide how serious the incident is for your organization. Generally, incidents can fall into three categories:

• Ordinary or Normal - these do not affect your organization's operations nor do they require notification of management. They can be contained and dealt with easily within the security group or help desk function in IT.
• Elevated or Serious - these can affect operations and will require an implementation in order to deal with them. Management will have to be notified and may have to be involved in the resolution.
• Emergency - these can affect people's health and well being, breach normal business controls on your operations, affect your financial performance or may even place your organization in violation of public law. Management must be informed and others may also have to be drawn along with vendors, customers and public officials as needed.

Each type of incident will need a tailored response. Ordinary incidents can be logged and dealt with during the normal course of business. The logs should be reviewed periodically, but these should not end up taking a lot of time.

On the other hand, serious incidents and emergency incidents need to have a response plan in place.

The first thing you want to do is identify the specifics of the incident and determine if it is still on-going or if it was a one time event. If it is on-going, your response should first attempt to identify the source and then stop the incident from continuing. An example of this might be that you discover that someone has breached your system via the FTP server function. If they are still logged on to your system and taking actions, you should first get as much identifying information as you can as to who is the behind the action, then cut them off by shutting down the FTP server function on your IBM i. This may affect other users on your system, but the integrity of your system is at risk and you need to take action to protect your organization's assets.

Once the event has been identified and suspended, you then need to analyze the event to determine how the incident was accomplished and what security safeguards can be put in place to prevent it from happening again. If at all possible, the affected system should not be placed back into normal use until steps have been taken to prevent a repeat of the incident.

As soon as the severity of the incident has been determined, you will also have to notify management and even your organizations principals. If the incident includes law violations, such as data theft of identity information, then public officials will also have to be notified. During this process, it may also be important for you to contact and work with your organization's public relations staff to make sure that the facts that are made public are correct and not overstated.

Each step along the way must be documented and permanent records kept for future reference. This will demonstrate how the event was handled and it will provide a clear path towards showing how a repeat of the event will be prevented.

These days, it is not enough just to have a security policy in place, you need to be prepared for what might be needed when the security policy breaks down.

If you have any questions about this topic, you can reach me at rich at kisco.com. I'll give it my best shot. All email messages will be answered.