As the security officer for your IBM System i shop, you've done all you can to lock down your systems and implement your organization's security policy. Once everything is set up and configured, however, there may still be a piece of the puzzle missing. One thing we know about computers is that no system is perfect. There is always a chance that something will break down in your shop's security design. This tip will take a look at what to do when something goes wrong.
A security incident response system consists of several steps and processes that your organization should document. There are many event types that you may be come across, and each one will have a number of responses to consider.
Any security incidents will, at their root, be the actions of a person or group of people. These 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 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 within the security group or help-desk function in your IT department.
- Elevated or serious: These can affect operations, and they will require an implementation in order to be dealt with. Management will have to be notified and perhaps even involved in the resolution.
- Emergency: These can affect people's health and well-being, breach your normal business controls, affect your financial performance or even place your organization in violation of public law. Management must be informed, as well as possibly vendors, customers and public officials.
Each type of incident needs a tailored response. Ordinary incidents, for example, can be logged and handled during the normal course of business. But serious and emergency incidents ...
To continue reading for free, register below or login
To read more you must become a member of Search400.com
need to have a response plan in place.
The first thing to do is identify the specifics of the incident and determine if it is ongoing or a one-time event. If it is ongoing, your response should be to first identify the source and then stop the incident from continuing. This could be something like discovering a breach of your system via the FTP server function. If the person performing the breach is still logged on to your system, you should first get as much identifying information as possible and then cut them off by shutting down the FTP server function on your System 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 need to analyze it and determine how it was accomplished and what security safeguards can 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 incident's severity has been determined, you will have to notify management and your organization's principals. If the incident includes law violations, such as theft of identity information, public officials will also have to be notified. During this process, it might also be wise to contact your organization's public relations staff to make sure that the facts made public are correct and not overstated.
Each step along the way must be documented, with permanent records kept for future reference. This will show how the event was dealt with, along with providing a blueprint to prevent a repeat incident.
It's not enough to have a security policy in place; you need to prepare 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@kisco.com.
