Incident Response And Configuration Management NIST SP 800 100

Attacks on the information security system and the networks have continuously raising and organizations today are actively taking the numerous measures to prevent such attacks. However, it is not possible to prevent all kinds of the incidents from occurring. The organization needs to analyze the risk to their system and take proper measures to reduce its influence to the acceptable level. They also need to possess a well-defined incident response capability to detect the incidents rapidly, reduce destruction and loss, determine weakness and restore IT operations rapidly. This article is about to discuss the outline of the incident response phases and the configuration management with the reference to the NIST SP 100-800.

Incident Response Lifecycle

The following figure illustrates the major phases included in the incident response:

incident handling lifecycle

Preparation

Incident preparation involves creating an incident response competency to make the organization prevent its system, network, and application from the incident by ensuring adequate security and respond to any incidents if happens. The incident response team needs to involve in a certain set of actions to prevent as well as handle the incidents. The overview of those actions is described below:

Preparing For Incident Response

Making the accurate planning as well as implementation decisions are the main key to construct an effective incident response program. The followings are the tasks needed to concentrate during the preparation phase of the incident response:

  • Create organization specific definition for the “incident” to make the incident scope clear

  • Make an incident response policy

  • Develop incident response & reporting procedures

  • Make guidelines for connecting with external parties

  • Define essential services of the incident response team

  • Choose a team structure & staffing model

  • Staff & train the response team

Preparing To Collect Incident Data

Being prepared for collecting subjective and objective data for each incident is an important action in the preparation phase. These data are useful in the process of meeting the requirements, measuring the success of the team, and making funding decisions. When it comes to collecting the data, an organization needs to focus on gathering the data which are actionable, instead of considering the entire available data.

Preventing Incidents

When compared to reacting a problem after they happen, preventing them from occurring can be the most effective and less costly effort. In case organization’s security controls are insufficient, then there is a chance for the high volumes of incidents and it also overwhelms the resources and competency for a response that would result in incomplete or delayed recovery. The organization needs to complement the incident response competency with the sufficient resources in order to perform their incident handling effectively. The main aim of this process is to reduce the incident frequency in order to allow the incident handling team to focus on the serious incidents. The followings are some of the example practices, which will support to prevent the incident from happening:

  • Comprising a patch management program that will support the system administrators in determining, obtaining, testing & deploying patches, which remove identified vulnerabilities

  • Configuring perimeter of the network to deny the entire activity, which is not permitted

  • Deploying software to detect & stop malicious code

Detection and Analysis

Detection and Analysis phase involves determining whether an incident has happened or not. If so, it determines the extent, type, and magnitude of the incident. The organization can detect incident by using several different ways with varying extents of fidelity and detail. For example:

  • Manual Method: User report

  • Automated Detection: host-based and network-based intrusion detection, log analysis and anti-virus software

Generally, initial analysis is conducted by the automated detection system to select the events for the manual review. Whatever techniques used to detect the incident, the effectiveness of this action depends on the quality of the data, which is taken as the input for the detection. Once the process of incident identification is completed, the team need to take action as soon as possible to analyze as well as validate the identified incidents. They also require to analyse each and every step they have taken. The process of analyses intends to determine the scope, attack methods & targeted vulnerabilities of the incident. The result of the analysis should offer enough details for the team to perform subsequent activities. Furthermore, the organization should also create an escalation process to follow when the incident response team members fail to respond to any incident within the given time.

Containment, Eradication, And Recovery

It is essential to prevent the spreading of the incident since it overwhelms the resources and increases damage. Incident containment early in the incident handling process is an ideal way to solve this issue. Decision making, such as disabling certain system functions, shutting down a system and disconnecting the system from the network are the important part of the containment. After the containment of an incident, the next necessary step to eliminate the incident component is eradication. For example: deleting malicious code and disabling the breached user accounts.

In some case, eradication is considered as unnecessary and performed along with recovery action. Recovery actions involve restoring the system to its normal operating state. Recovery may include actions like:

  • Installing patches

  • Restoring systems from backups

  • Tightening network perimeter security

  • Changing passwords

Post-Incident Activity

After an incident has been handled successfully, the enterprise should conduct a lesson-learned meeting that offers a platform to review the effectiveness of the incident response actions and determine mandatory enhancements to available security practices and controls. The information gathered from the lessons -learned meetings and data accumulated during the incident handling process should be employed to determine systemic security deficiencies and weakness in the procedures and policies.

Configuration Management (CM)

Changes to the software, hardware, or firmware components of the information system can possess a significant influence on the security system. Configuration Management is essential to handle the influence of difference or changes in the configuration of the information system/network. It supports in streamlining the processes of change management and protect changes, which could detrimentally impact the security position of the system before they occur. As per the process of CM, the changes in the system should be tested before the implementation in order to observe the influences of the changes, thereby reducing the risk of the opposing result.

The following tables list the seven configuration management controls, which are mandatory to implement:

configuration magagement

Configuration Management In The System Development Life Cycle

Due to the ever-increasing impact of the security issues, now it becomes essential to address the CM in the SDLC process. In the Software Development Lifecycle process, the planning of the CM takes place in phase 2 and phase 3. CM process implementation falls on phase 4. the phase 4, operation/maintenance, includes the CM change control & auditing steps. In case, there was a notable change addressed the configuration management process, then it is essential to recertify and reaccredit the system.

Configuration Management Roles And Responsibilities

For implementing an effective CM, several roles need to be included. An enterprise must guarantee that they are aware of the proposed changes & assess that a detailed review & approval strategy is in place. In addition, they should also address separation of duties to ensure that the changes are applied only after being tested & approved.

As we have discussed the roles and responsibilities in the blog, An Introduction To Information Security Roles and Responsibilities, the examples of responsibilities for the configuration management are as follows:

Chief Information Officer (CIO)

  • Setting forth policies regarding CM

  • Implementing CM at the uppermost level of the enterprise

System Owner

  • For developing the functional needs & analyzing that the needs are implemented appropriately

Information Systems Security Officer (ISSO)

  • Addressing security issues associated with the CM program

  • Offering expertise & decision support to the CCRB (Configuration Control Review Board)

CCRB

  • Analysing CM metric details on the funding & other CM-associated problems

  • Discussing & resolving change requests, which require extra resources or funding to implement

CM Manager

Responsible for the day-to-day activities:

For example:

  • Documenting & implementing the configuration management plan

  • Creating system baselines & evaluating controls

System Users

  • For reporting any vulnerabilities or new needs, which are determined in the recent software versions

Developers

  • Coordinating & working with the configuration management manager to determine, resolve & implement controls

Configuration Management Process

The configuration management process determines the steps needed to guarantee that entire changes are adequately requested, assessed & authorized. This process also offers a step-by-step detailed procedure for determining, processing, tracking & documenting changes.

The following figure illustrates the examples of the CM process:

Configuration Management Process

Identify Change

Identifying the need for the change is the beginning step of the CM process. A change may comprise the updating the records or fields of the database to enhance the OS with the recent security patches. After the identification of the changes, it is important to submit the change request to the proper decision-making body.

Evaluate Change Request

Once the change request is initiated, the effects of the change of the system should be analyzed. Guidelines for the impact analyze includes:

  • Whether the change is feasible and enhance the system’s performance or security

  • Whether the security of the system will be influenced by the change

  • Whether the change affects the security components

Implementation Decision

Once the changes are evaluated, any one of the following activities should need to take:

  • Approve – authorize implementation and document the authorization signature

  • Deny – denial of request irrespective of the information and circumstances

  • Defer – postpone a decision until further notice

Implement Approved Change Request

Once the decision on the change implementation has been made, it is the time to move it from the test environment to the production.

Continuous Monitoring

Continuous monitoring of the CM process ensures that the configuration management is operating as desired and the applied changes don’t adversely influence either the security or performance of the system. Agencies can use configuration verification tests and system audits for the continuous monitoring system.

Hope the above details provide foundational information on the incident response and configuration management activities.


    All Comments (0)

    No one has commented yet.



Leave a comment