Contents
1. Security Incidents
Security Incident Terminology
Security Event: these occur anytime that an observable action takes place on a system that has security implications. This may be a user accessing a web page, a file being written to disk by a process, a connection being established through a firewall, or any other security related event. Thousands of security events take place every hour on active networks
Adverse Security Events: These are events that could have negative consequences. A user attempting to access a file without permission is an example of an adverse event, as is the receipt of a phishing email message.
Security Incidents: Any adverse event that violates security policies. For example, if the user that tried to access a file was able to view confidential information and send it to a third party without permission, that would be a security incident. Similarly, if the recipient of a phishing message clicked a link in the message and provided their password to an attacker, that would also be a security incident.
Categorising Security Incidents
Organisations may benefit by having documented incident types and using these incident category definitions in their reporting. One common method for categorising incidents is by their attack vector, the way that they occurred.
- External Media
- Attrition
- Web
- Improper usage
- Equipment loss or theft
- Other
2. Preparing for Incident Response
Incident Response Program
No matter how well we prepare, security incidents can and do occur. Security professionals are responsible for preparing their organisations for this eventuality by building a security incident response program. The National Institute for Standards and Technology, or NIST is the authoritative source for information on security incident response. As you develop your incident response plan, you may wish to refer to their Computer Security Incident Handling Guide, which is NIST Special Publication 800-61.: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
Incident Response Program Components
- Incident Response Policy
The policy and related documents should include the critical details of your organisation’s approach to incident response. The incident response policy is, by its nature, very general and shouldn’t change all that often. Items to include:
– the foundational authority. There may be unpopular actions that need to take place during an incident (such as disconnecting equipment during an incident) and the team must have authority to carry out these actions where necessary
– define incidents that fall under the policy
– include an incident prioritisation scheme based upon incidents and their severity - Incident Response Procedures
Incident response procedures, on the other hand, are where you’ll find the details of your incident response practices and tactical guidance to incident responders. Procedures should be written very clearly, and provide actionable advice to troops on the ground. Items to include:
– Notification procedures
– Escalation procedures
– Reporting procedures
– System isolation procedures
– Forensic analysis procedures
– Evidence handling procedures - Communication Guidelines
The next important element of an incident response program is formalising the way that you communicate with units outside the core incident response team. You’ll need to provide peer guidance on when and how to involve groups such as senior executives, legal counsel, public relations, regulatory agencies, and law enforcement. In most cases, you aren’t under a legal obligation to report security incidents to law enforcement and the decision to do so is complex. Once you file a report with law enforcement, it’s likely that the details of the incident will become public, which may be undesirable. - Build an Incident Response Team
One of the most important tasks you’ll undertake in your incident response program is building and staffing your incident response team. The team may need to be available 24/7. You may need primary and backup members to cover holidays etc…
Some groups that should be represented on the team are:
– management
– information security staff
– subject matter experts (database administrators, developers, system engineers, virtualisation experts)
– legal counsel
– public affairs
– human resources
– physical security staffYou won’t necessarily need to activate all team members for any given incident, but each of these groups should have representatives trained and ready to participate before an incident starts.Testing incident response plans ensure readiness for real incidents
3. Incident Identification and Containment
A lot of this was covered in section: https://www.spktechfit.com/?p=249
Incidents can be reported in a number of different ways:
- alerted by internal networking monitoring equipment
- External sources such as customers or staff noticing issues
- External threat intelligence products reporting issues
First Responders
The team member who first notices an incident and others who may be on duty has special first responder responsibilities. Just as in a medical emergency, the first person on the scene has the ability to have a tremendous impact on the successful response to an incident by acting quickly and decisively to protect the organisation.
First responders should act quickly to contain the damage from a security incident. If they suspect that a system or group of systems may be compromised, the first responder should immediately isolate that system from the rest of the network to contain the damage. Depending upon the technical circumstances, the first responders may quarantine the system by removing it from the network keeping it running to preserve evidence, but cutting off the potentially comprised system’s ability to communicate with attackers or infect other systems on the corporate network effectively quarantining it.
EXAM TIP: the highest priority of a first responder is containing damage through isolation
4. Escalation and Notification
When security professionals detect a potential incident, they should immediately swing into first responder mode, acting to isolate effected systems and contain the damage caused by the incident. As soon as they’ve handled the immediate emergency, they should move into the Incident Escalation and Notification Process.
Escalation and Notification Objectives
- Evaluate incident severity based upon impact
- Escalate response to an appropriate level
- Notify managers and other stakeholders
Triaging Incidents
After containing an incident, responders should begin a triaging process that identifies the potential impact of the incident. The process for rating incident severity should be found in the organisation’s incident response procedures. EG:
- Low impact:
– minimal or no impact to systems or information
– normally handled by first responders
– Normally does not require an after hours response - Moderate impact:
– have significant impact on systems or information
– Triggers full or partial response from Incident Response Team
– Prompt notification of management - High impact:
– May cause critical damage to information or systems
– Justifies an immediate full response from the Incident Response Team and the entire team should be mobilised
– Immediate notification to senior management
5. Incident Mitigation
As the full incident response team assembles, they move from the isolation and quarantine strategy used by first responders into a full incident mitigation mode. The goal of this mitigation phase, is controlling the damage and loss caused to the organisation by performing a full range of incident containment activities.
Containment Strategy Evaluation
1. Consider the potential for damage and theft of resources during the incident
2. Preserve evidence
3. Evaluate service availability requirements, and the impact of different containment strategies, on that service availability
4. Responders must understand the time and resources required to implement any proposed containment strategy.
5. Responders should understand the expected effectiveness of the strategy. Will an approach fully contain the incident, or is it likely only a partial fix?
6. Responders must understand the length of time that the solution will remain in place
The goal is to select the containment strategy, that balances the business needs of the organisation, with the security objectives of incident response.
Once an organisation begins implementing containment actions, responders must keep in mind, that the attacker will likely detect those actions, and know that investigators are hot on their trail. This may cause the attacker to speed up activities, destroy evidence, or perform other actions that are detrimental to the incident response, or the organisation’s business.
At the end of the containment process, the organisation should be in a semi-stable state. Responders should be confident that the incident is over, and there is not immediate danger to the organisation. Business operations should be functioning, at least on a limited basis, although they may be using temporary work arounds. Everything is generally okay, and the organisation is ready to move on to the next phase of the process, eradication and recovery.
6. Eradication and Recovery
The goal of this phase is to remove any effects of the incident and return the organisation to normal operating status with all technology systems in place and protected against future attacks.
Technical Recovery Efforts
This phase includes finalising the technical response to the incident. The details of this technical response will vary depending upon the type of the incident. Some of the actions you may need to take during the incident recovery effort include:
- Rebuild compromised systems
- Removing malware from infected hosts
- Disable breached accounts
- Restore corrupted or deleted data
Remediate Vulnerabilities
In most cases a incident occurred because an attacker exploited one or more vulnerabilities. During the incident reconstitution effort administrators must identify and remediate those vulnerabilities. This may include:
- Applying security patches
- Updating firewall rules
- Implementing Intrusion Prevention Systems (IPS)
- Strengthening access controls
It’s not unusual to have a recovery effort that takes weeks or months in the wake of a serious security incident.
Responders should use a phased approach that implements controls that deliver the greatest amount of security in the shortest amount of time following an incident and then work through long term changes over time.
7. Lessons Learned and Reporting
The Lessons Learned process is designed to provide everyone involved in the incident response effort an opportunity to reflect on their individual role in the incident and the team’s response overall.It’s an opportunity to improve the processes and technologies used in incident response to better respond to future security crises. The most common way to conduct Lessons Learned is to gather everyone in the same room or connect them via teleconference or video-conference and ask a trained facilitator to lead a Lessons Learned session. Ideally, this facilitator should have played no role in the incident response, leaving him or her with no preconceived notions about the response.
The facilitator should be a neutral party who simply helps guide the conversation. Time is of the essence with a Lessons Learned session because, as time passes, details quickly become fuzzy and memories are lost.
Questions to ask in the Lessons Learned sessions include:
- Exactly what happened and at what times?
- How well did staff and management perform in dealing with the incident?
- Were documented procedures followed? Were those procedures adequate?
- Were any steps or actions taken that might have inhibited the recovery?
- What would the management and staff do differently the next time a similar incident occurs?
- How could information sharing with other organisations have been improved?
- What corrective actions can prevent similar incidents in the future?
- What precursors or indicators should be watched for in the future, to detect similar incidents?
- What additional tools or resources are needed to detect, analyse, and mitigate future incidents?
