Computer Security Incident Response - Part 3

Tuesday, November 16, 2010

John McGloughlin

E2c407e8f2b2f7e67cf000863bd588da

This is the third of a three part series (Part 1) (Part 2) of articles defining a computer security incident response capability (CSIRC) framework and an implementation schema for computer security incident response teams (CSIRT).

Computer Security Event & Incident Response Capability (CSIRT) - Part 3

The CSIRT is responsible for day-to-day tactical operations in protecting the assets of the corporation from electronic borne threats and attacks.

This team is also referred to as the Security Operations Center (SOC) team. If you don't have a SOC team in place, you should. If you do, congratulations!

Documentation & Training

The efficiency and effectiveness of the SOC depends on disciplined conduct, continuous communication, uniformed approach, low defect rates and positive attitudes. This team uses a stream of documentation and training as the basis of its continuous effort to protect the assets of the corporation.

This commitment to documentation and training also provides the company with a concrete best practices implementation view for audit and legal concerns.

The SOC uses a protected, web based, light-weight documentation repository to record all of its procedures (instructions) used in its intelligence gathering (surveillance), event handling, containment (combat), remediation (eradication), and recovery and reporting functions.

It also documents the usage and maintenance of its tools (weaponry) used throughout the course of its day-to-day functions. New team members go through a basic training program that enables them to perform efficiently and function at a high level in short order. Existing team members are trained and checked out on new procedures and weaponry as they are introduced into the environment.

Coordination

The SOC does not own the majority of the assets that are yielding intelligence so it depends heavily on the cooperation of other teams within the organization.  Furthermore, it may not own a particular asset that could be used as a weapon in a combat situation.

Therefore it is necessary for the SOC to coordinate its efforts with these asset owners. This requires not only the mechanism for how to do that (channels) but requires confidence building with these owners on behalf of the SOC.

If their confidence factor is high that their time, energy, and cooperation will be used to not only protect their assets but contribute to the overall health of the corporate computer security posture, they will most likely want to contribute. The SOC doesn’t waste other team’s time. The SOC is accurate and concise and provides messages in brevity that are designed to achieve the goal of the SOC.

In addition to the effort of developing high quality relationships with other asset owners the SOC establishes communication corridors and channels that result in those owners moving with alacrity when requested to do so. The SOC uses a formal template for providing the “who, what, where, and how” to other asset owners when action is required on their part. The primary vehicle for delivering this information is via email.

Staffing

The SOC is a virtual body of individuals and computers that operates 24x7x365.

Human Interfaces

The SOC provides interfaces for humans to report events or respond to notifications via a web interface, an email interface, and a phone number.

Functional Model

soc functional diagram

Intelligence Gathering

The primary motive for conducting intelligence gathering is to assist the SOC in gaining an advantage over its attacker by having more information about its assets than an attacker has. Gathering intelligence from an asset or a collection of assets permits the SOC to perform asset value and liability evaluations and be able to use that information to its advantage against the attacker.

The secondary motive for conducting intelligence gathering is to assist the SOC in creating greater asset value for itself and greater asset liability for the attacker. The goal in creating greater liability for the attacker is to prevent the attacker from achieving its motive and possibly prosecuting the attacker.

The tertiary motive for conducting intelligence gathering is to perform active surveillance and analysis in order to detect real-time threats or attacks. The SOC uses this detection information as a catalyst for resource deployment used to contain the threat or attack. This motive also supports many compliance and regulatory logging and threat detection requirements.

Finally, community knowledge that intelligence gathering is constantly taking place creates an environment of deterrence against insiders who seek to cause harm to the assets of the company or its customers.

Intelligence Sources

The SOC identifies intelligence sources at two vectors: internal and external, and the entities are either human or electronic. The SOC uses these vectors as a way to model confidence in the value of the source over time (configuration error = low confidence) and possibly guide its event handling strategy (NPI breach reported by a customer = severe TLA). This approach also aids the SOC in being able to distinguish noise from worth.

Internal sources are assets that are owned by the organization (devices that log). External sources are assets that are owned by partners or third party sources (CVE/BID) and well known professional security news groups (Dark Reading).

Intelligence is considered human when an individual contacts the SOC to convey an experience that they consider detrimental to the assets of the corporation or to their own personal information. Intelligence is considered electronic when the feed is automated and information was ascertained electronically (wire / wireless).

Asset Logging

All assets in the organization provide some form of logging capability either directly or holistically. Management is committed to having asset owner’s forward asset intelligence to the SOC via automated channels developed and maintained by the SOC. The SOC is responsible for working with asset owners to determine if the asset is capable of logging, its logging mechanisms, perceived and real impact to production performance, network impact, and value of asset intelligence.

There are situations where an asset simply can’t forward intelligence. This may be the result of a performance impact assessment or capability. This is formally known as an asset logging exception. In these situations the SOC is responsible for evaluating the holistic environment of the asset to determine the best intelligence sources that could provide information regarding the particular exception.

Asset Enumeration and Valuation

The SOC performs statistical analysis and reporting on assets as part of its diligence in determining the availability of assets and their contribution to the overall intelligence gathering strategy. Assets are enumerated by name, owner, address, vector type, category, event count, vulnerability, and confidence factor and business value.

The combination of this information allows the SOC to place a value on the intelligence the asset provides (confidence factor) as well as the value the asset has to the business (importance factor) if it were to experience an exploit. This valuation combination is used when performing a threat assessment to determine the level of severity to assign to the threat or attack.

Collection, Non-Repudiation, Archiving

The SOC maintains a proprietary immutable collection point for the initial storage of asset logs. The primary goal of the collection points is to permit the SOC to maintain the logs in a non-repudiated state. This model also decouples the logs from correlation managers and other log management system, provides fine grained search capability for expert forensics purposes, allows proprietary control of the hashing and archiving strategy, and provides an a valid digital chain of custody environment.

Log streams are then copied in memory and forwarded onto additional destinations or consumers that have interest in these logs. Destinations can take the form of correlation engines, other log management tools, individual requests, etc.

SOC logging diagram

Surveillance (ATI) / Analysis & Correlation / Threat Level Assessment

Asset Enumeration and Valuation

Surveillance / Attack Type Indicators (ATI)
The SOC is constantly performing surveillance on both systems and human intelligence. The SOC uses a taxonomy of uniform meta descriptors known as Attack Type Indicators (ATI) to describe the results of correlated intelligence streams. ATI take the format of TopLevelATI/SubLevelATI – Optional Characteristic. A few examples of ATI:

Reconnaissance/Port Scan Malware/FooBar.j Trojan
Unauthorized Activity/SSH Tunnel
Unauthorized Activity/P2P Usage
Unauthorized Activity/Music Download - The James Gang
Data Loss Prevention/NPI Leakage
Suspicious Activity/After Hours Access - XYZ Facility
Phishing And Hoaxes/Common Phish - Help Me Get Out Of Nigeria

ATI are included in all notifications delivered by the SOC. They are used by combat assets and containment personnel to determine the most effective and efficient method for handling the attack. They are also used in reporting and audit functions in order to provide a picture of the attack landscape. This type of view provides decision makers at all levels with data for determining resource deployment and resource requirements.

Analysis & Correlation

Analysis is the activity of determining the intelligence in the environment that constitutes an ATI match. Once an intelligence signature is known it can be associated with an ATI and automation can be applied to matching that pattern. This activity of matching is also known as correlation.

The SOC can take multiple streams of intelligence from multiple assets and correlate that into a single ATI that represents an actionable security event. It uses confidence factors from asset intelligence as part of its correlation to improve the quality of the analysis. Much of the analysis and correlation performed within the SOC is fully automated placing the efficiency and quality of analysis at a very high level.

Threat Level Assessment

Each ATI are assigned a threat level assessment that represents the degree of likelihood that a threat will manifest itself into a successful attack and its impact to the business. Asset confidence factor and business importance are used as the basis for calculating this assessment. This information is maintained as part of the intelligence gathering process by performing asset enumeration and valuation.

Most assessments are automated (quantitative) but some involve manual (qualitative) assessment by SOC analysts or an external source. SOC analysts follow work instructions when performing manual assessments to guarantee a minimum level of defect rate as a result of the analysis. Specifically analysts are trained to focus on attack surface enablers, access to the target, and the capabilities of the attacker.

The SOC views assessments as communication entities and uses them as guides for escalation paths and to aid decision makers along those paths. Subsequence activities within the event lifecycle of an attack can trust that the SOC analysis and correlation has a high level of quality behind this assessment.

Event Handling

Event handling is the process the SOC uses to memorialize the lifecycle of an event or incident. Before the event or incident reaches event handling it has gone through some form of analysis and correlation, it has been assigned an ATI and has been assigned a threat level. This model permits the event handling process to focus its efforts on escalating and notifying the appropriate resources that are required to contain and remediate the event.

Routing / Notification

The SOC does not own many of the assets it is attempting to protect. When the SOC detects that an asset is experiencing a threat, under attack, or has experienced an exploit the SOC must know not only the resources required to contain and remediate the event but also who or what to notify for the deployment of those resources.

During intelligence gathering the SOC will establish the asset owner (technical and business) and use these as its notification contacts. The SOC determines the type of resources and combat techniques that should be deployed based on the ATI. This information is included in the content of the notification. The notification is delivered by email.

Escalation

The SOC maintains a feedback channel for each notification it sends into the community (or assigns to itself). The SOC has established escalation policies based on the combination of the ATI and the threat level. Depending on the feedback it receives or doesn’t receive for the notification it will execute those policies.

Fatigue Management

Feedback channels will often produce human emotions in the world of security professionals. Many times during a containment situation these emotions are the result of fatigue from lack of rest. The other type of fatigue that can occur is when the group being notified of evens is overwhelmed or has just decided not to cooperate because of other factors. The SOC monitors these feedback channels closely for this type of fatigue and if encountered will take measures to deal with the situation.

Combat / Containment

The SOC is responsible for ordering best practice combat and containment activities for threats, attacks, and exploits. As a result of its intelligence gathering, the assignment of ATI and the threat level assessment the SOC has the best vantage point for describing the proper action to take for a particular event.

The majority of the time the SOC will use the resources of its asset owners to carry out activity required to contain the event. The SOC also has the authority to contain events through the use of perimeter enforcement (IDS / Firewall). The SOC would conduct perimeter enforcement activity based on escalation policies.

Eradication / Remediation

The sphere of influence of the SOC starts to diminish in this phase of the event life cycle. However, the SOC has experts that are able to participate in eradicating a threat or an attack from the environment. This includes recommending activities for auto threat containment or attack prevention in the future. The SOC uses its feedback channels to record activity that asset owners have taken within this phase.

Recovery

Recovery is the term used to describe the state an asset reaches when it has been fully restored to its operational expectation post attack. The SOC is responsible gathering the factual data through its feedback channels that supports this state has been achieved. This information is primarily used by company management and auditors to ensure that the asset is fully functional and able to support the business.

Reporting

The SOC produces reports as a result of its intelligence gathering and event handling activities to communicate security related information with a clear purpose to a specific audience. Reports provide strategic and tactical level teams within the organization with the necessary intelligence to shape proactive and reactive decision making. These reporting functions are also used to satisfy compliance and regulatory requirements.

Policies & Compliance

Policies and compliance artifacts represent legislation that the SOC is responsible for enforcing. All activities conducted by the SOC can be linked to a company policy that may or may not point to an industry compliance or regulatory requirement. The SOC includes a reference to these policies in its event notifications to the community.

This creates an environment of continuous awareness for company policies regarding computing security. This approach also fosters the principle of egalitarianism where each individual within the community is subject to the same computer security policies with no individual or group having special privileges unless that individual or group has been authorized by management for those privileges as part of their job function.

Cross-posted from GuardSight

Possibly Related Articles:
11762
Policy
Risk Management Security Strategies Incident Response Governance
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.