How to Use ‘Best Practices’ in Security Incident Management

eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

/images/stories/70×50/bug_knowledgecenter_70x70_%282%29.jpgWhile a security breach is often a surprise, the genesis of how it came about seldom is. Surprise or not, quite often the security breach introduces situations full of complexities that are difficult to synthesize in a timely manner. While all of this is transpiring, so-called “solutions teams” are being built, brought together and introduced to the milieu.

The goal of the team is to understand and solve either specific incidents or numerous ones affecting the same departments within an organization. As a direct result, incident management, logging and SIEM (security information event management) have come to the forefront of IT security due to several factors, including:

• regular outbreaks of malicious worms, viruses and other related incidents;
• requirements for new regulatory controls affecting corporate, personal, federal and other security;
• deployment of monitoring, detecting, reacting, and security management and logging technologies; and finally,
• the logical outcome of the success of the current SIEM solutions (highly qualified incident identification) and log management tools as a driver for incident management.

Once an incident is identified, it must be managed as any project would be: with a beginning and an agreed-upon ending point. The key for IT security managers thinking about or planning for incident management is to understand the objective of incident handling as an independent “project.” There are numerous organizational questions which must be addressed and answered prior to incident response and planning. These include:

??Ç Is the primary objective to communicate/report?

??Ç Is the primary objective to log and learn from existing information in both real time and in time delay?

??Ç Is the primary objective to remediate?

??Ç Is the primary objective to prosecute?

??Ç Is the primary objective any combination of the above?

Understanding the financial, technological, regulatory and operational impacts on a given business or mission if a system or group of systems, is compromised is absolutely fundamental to proper planning. Both affected and unaffected assets must be analyzed, so when an incident targeting a given asset occurs, the security team knows where the asset is located, who to contact, how much time they have to respond, what steps they are supposed to take and how to proceed in a given time period, when appropriate. It is also essential that organizations plan for future attacks and breaches based on the analysis of logged information from prior incidents. This enables more realistic planning, training and preventative measures to be taken.

Understanding security practices on a departmental level, as well as an organizational one, takes bandwidth. Realizing how to protect an organization, both internally and externally, based on logged information decreases the amount of bandwidth necessary to create preventative scenarios for a given security practice.

Security organizations do not own, or necessarily have access to, the assets that may be involved in a potential incident. As a direct result, security teams must draft the appropriate technical and operational personnel, as well as test and execute mini-disaster recovery and security management plans designed to mitigate the risks of loss to a given organization. Not understanding the impact of even the smallest incident on an organization can take a major toll on the organizational structure-from a security, technological and operational perspective.

With all incidents, there is a risk of loss. An incident does not have to be catastrophic to have a significant impact on an organization. There are several areas where the logging, management and monitoring of critical information assets is essential. These include: 1) avoiding risk through the implementation and supervision of proper IT controls (either automated or manual); 2) transference of risk through proper disaster recovery insurance; and finally, 3) acceptance of risk and not ignoring threats or weak security programs, especially in organizations that are just beginning to create or update their security management practices. Without a managed, ongoing practice, the majority of organizations tend to accept their risk and do what they can from a security perspective, but not manage their risk to the level some organizations are able to do.

In the final analysis, although technology can help mitigate risk for an organization, it is what an organization does via its security, log management and SIEM efforts (and how the data processed through them is integrated into an organization’s IT controls, with the human resources for effective incident management programs) that is the most telling. In reality, in many organizations, these efforts have been achieved in IT network and IT systems management programs.

/images/stories/heads/richards_jeff70x70.jpgJeff Richards is vice president of Security Sales at CrossTec. Jeff is responsible for day-to-day operations and development of the security segment of CrossTec, including domestic sales and foreign channels. Jeff has been in the technology space for over 10 years, serving as domestic channel manager and vice president of Channels for CrossTec, as well as general manager for CrossTec affiliate BrightTools, a distributor of security software. He can be reached at jr@crosstechsoftware.com.