Preventing and Responding to Security Incidents

Preventing and Responding to Incidents image

Preventing and Responding to Security Incidents

One of the primary goals of any security program is to prevent security incidents. However, despite the best efforts of information technology (IT) and security professionals, Cyber incidents do occur. When they happen, an organisation must be able to respond to limit or contain the incident.

An security incident/security crime incident is any event that has a negative effect on the confidentiality, integrity, or availability of a companies IT assets, and they are commonly defined within computer security policies, or incident response plans, such as the following:

  • Any attempted network intrusion.
  • Any attempted denial-of-service attack.
  • Any detection of malicious software.
  • Any unauthorised access of data.
  • Any violation of security policies.

Effective incident response management is handled in several steps or phases below. It's important to know that incident response is an ongoing activity and the results of the lessons learned stage are used to improve detection methods or help prevent a repeated security incident.

Incident Response Step 1 - Detection

Information Technology environments include multiple methods of detecting potential security incidents. The following identifies many of the common methods used to detect potential incidents, and it includes notes on how these methods report the incidents:

  • Intrusion detection and prevention systems send alerts to administrators when an item of interest occurs.
  • Anti-malware software will often display a pop-up window to indicate when it detects malware.
  • Many automated tools regularly scan audit logs looking for predefined security events, such as the use of special privileges. When they detect specific events, they typically send an alert to administrators.

Incident Response Step 2 - Response

After detecting and verifying a security incident, the next step is response, which varies depending upon the severity of the security incident. Many companies have a designated incident response team, who are activated during a major security incident but not for minor incidents.

A formal incident response plan documents who would activate the team and under what conditions. Team members are trained on incident response and the companies incident response plan.

Usually, team members assist with investigating the incident, assessing the damage, collecting evidence, reporting the incident, and recovery procedures. They also are involved in the remediation and lesson learned stages, and help with root cause analysis.

The quicker a company can respond to an incident, the better chance they have at limiting the damage.

Incident Response Step 3 - Mitigation

Mitigation steps attempt to contain an incident. One of the primary goals of an effective incident response is to limit the effect or scope of an incident. For example, if an infected computer is sending data out of its network card, then the card can be disabled or the network cable disconnected.

Sometimes containing the incident involves isolating the affected network from other networks, so that security personnel can address the incident without concerns about the security issue spreading to other networks and systems.

In some cases, responders take steps to mitigate the incident, without letting the attacker know that the attack has been detected, allowing the security personnel to monitor the attackers activities to determine the scope of the attack.

Incident Response Step 4 - Reporting

Reporting refers to reporting an incident within the company and to other companies and individuals outside of the company. Although there's no need to report a minor malware infection to the CEO, upper-level management does need to know about serious security breaches.

Companies often have a legal requirement to report some incidents to outside regulatory organisations, but many incidents are not reported because they aren't recognised as incidents due to inadequate training or through concerns that the company would lose both reputation and share value.

Incident Response Step 5 - Recovery

After investigators collect all the appropriate evidence from a system, the next step is to recover the system, or return it to a fully functioning state.

This can be very simple for minor incidents and may only require a reboot. However, a major incident may require completely rebuilding a system.

Rebuilding the system includes restoring all data from the most recent backup. When a compromised system is rebuilt from scratch, it's important to ensure it is configured properly and is at least as secure as it was before the incident.

Incident Response Step 6 - Remediation

In the remediation stage, security personnel look at the security incident and attempt to identify what allowed it to occur, and then implement methods to prevent it from happening again.

This includes performing root cause analysis, which examines the incident to determine what allowed the incident to happen. For example, if attackers successfully accessed a database through a website, personnel would examine all the elements of the system to determine what allowed the attackers to succeed. If the root cause analysis identifies a vulnerability that can be mitigated, this stage will recommend a change.

I could be that the web server didn't have up-to-date patches, allowing the attackers to gain remote control of the server. Remediation steps might include implementing a patch management program. Perhaps the website application wasn't using adequate input data validation techniques, allowing a successful SQL injection attack.

Remediation would involve updating the application to include input validation, or maybe the database is located on the web server instead of in a backend database server, therefore remediation might include moving the database to a server behind an additional firewall.

Incident Response Step 7 - Lessons Learned

During the lessons learned stage, personnel examine the incident and the response to see if there are any lessons to be learned. The incident response team will be involved in this stage, but other employees who have knowledge about the security incident will also be involved.

While examining the response to the incident, security personnel look for any areas where they can improve their response. For example, if it took a long time for the response team to contain the incident, the examination tries to determine why. It might be that they don't have adequate training and didn't have the correct knowledge and expertise to respond effectively. They may not have recognised that it was a security incident when they received the first notification, allowing an attack to continue longer than necessary.

First responders may not have recognised the need to protect the evidence and inadvertently corrupted it during the response.

The output of this stage can be fed back to the initial detection stage of incident management, e.g. administrators may find that attacks are getting through undetected and increase their detection capabilities and recommend changes to their IDS intrusion detection systems.

It is very common for the incident response team to create a report when they complete a lessons learned review. Based on the findings, the team may recommend changes to procedures, the addition of security controls, or even changes to security policies. Management will decide what recommendations to implement and be responsible for the remaining risk for any they reject.

Please Note

The preventing and responding to incidents information shown above is mostly generic in nature and based on best-practice, therefore to get a better understanding on what we can do for your business, all we ask is that you contact us to discuss your preventing and responding to cyber incidents needs, to protect your IT systems and data.
Click here to contact us