In addition to deploying effective security solutions and practices, they need the ability to quickly identify and address attacks, hence ensure minimal damage, disruption, and costs. Every IT system is a potential target of a cyber-attack, and most people agree that it is not a matter of if, but when it will happen. However, the impact varies according to how quickly and effectively you address the issue, hence the need for incident response preparedness. A cybersecurity incident response (IR) refers to a series of processes an organization takes to address an attack on its IT systems. This requires a combination of the right hardware and software tools as well as practices such as proper planning, procedures, training, and support by everyone in the organization.

Best practices before, during and after security incidents

When a cyber-attack occurs, multiple activities may take place simultaneously, and this can be hectic when there is no coordination or proper incident handling procedures. However, preparing in advance and establishing a clear and easy to understand incident response plan and policies allow the security teams to work in harmony. This enables them to focus on the critical tasks that limit the potential damage to their IT systems, data, and reputation in addition to avoiding unnecessary business interruptions.

Preparing an incident response plan

An incident response plan documents the steps to follow in the event of an attack or any other security issue. Although actual steps may vary according to the environment, a typical process, based on SANS (SysAdmin, Audit, Network, and Security) framework, will include preparation, identification, containment, elimination, recovery, notification of the incident, and a post-incident review. The preparation includes developing a plan with relevant information and the actual procedures that the computer incident response team (CIRT) will follow to address the incident. These include:

Specific teams and individuals who are responsible for each step of the incident response process. Defines what constitutes an incident, including what warrants what type of response. Critical data and systems that require more protection and safeguarding. A way to preserve the affected states of affected systems for forensic purposes. Procedures to determine when and who to notify about a security issue. When an incident occurs, it may be necessary to inform the affected users, customers, staff law enforcers, etc. but this will differ from one industry and case to another.

An incident response plan must be easy to understand and implement as well as align with other plans and organization policies. However, the strategy and approach may differ across different industries, teams, threats, and potential damages. Regular testing and updates ensure that the plan is valid and effective.

Incident response steps when a cyber-attack occurs

Once there is a security incident, the teams should act fast and efficiently to contain it and prevent it from spreading to clean systems. The following are the best practices when addressing security issues. However, these may differ according to the environment and structure of an organization.

Assemble or engage the computer incident response team

Ensure that the multi-discipline in-house or outsourced CIRT team has the right people with both the right skills and experience. Out of these, select a team leader who will be the focal person to give direction and ensure the response goes according to plan and timelines. The leader will also work hand in hand with the management and especially when there are important decisions to make as regards the operations.

Identify the incident and establish the type and source of the attack

Upon any signs of a threat, the IR team should act fast to verify if it is indeed a security issue, whether internal or external while ensuring that they contain it as fast as possible. Typical ways of determining when there is an issue include but not limited to;

Alerts from security monitoring tools, malfunctions within the systems, unusual behaviors, unexpected or unusual file modifications, copying or downloads, etc Reporting by users, network or system admins, security personnel, or external third-party partners or customers. Audit logs with signs of unusual user or systems behavior, such as multiple failed login attempts, large file downloads, high memory usage, and other anomalies.

Assess and analyze the impact of the attack

The damage an attack causes vary depending on its type, effectiveness of the security solution, and the speed at which the team responds. Most often, it is not possible to see the extent of the damage until after completely resolving the issue. The analysis should find out the type of attack, its impact, and the services it could have affected. It is also good practice to look for any traces that the attacker could have left and gather the information that will help in determining the timeline of activities. This involves analyzing all the components of the affected systems, capturing relevant for forensics, and determining what could have happened at each stage. Depending on the extent of the attack and the findings, it may be necessary to escalate the incidence to the relevant team.

Containment, threat elimination, and recovery

The containment phase includes blocking the attack from spreading as well as restoring the systems to the initial operation status. Ideally, the CIRT team should identify the threat and root cause, remove all the threats by blocking or disconnecting compromised systems, cleaning the malware or virus, blocking malicious users, and restoring services. They should also establish and address the vulnerabilities that attackers exploited to prevent future occurrences of the same. A typical containment involves short term and long term measures as well as a backup of current status. Before restoring a clean backup or cleaning the systems, it is important to keep a copy of the status of the affected systems. This is necessary to preserve the current state, which can be useful when it comes to forensics. Once backed up, the next step is the restoration of disrupted services. Teams can achieve this in two phases:

Check the systems and network component to verify that all are working properly Re-check all the components that were infected or compromised and then cleaned or restored to ensure that they are now secure, clean, and operational.

Notifying and reporting

The incidence response team does the analysis, responding, and reporting. They need to explore the root cause of the incident, document their findings of the impact, how they resolved the issue, recovery strategy while passing the relevant information to the management, other teams, users, and third-party providers. If the breach touches on sensitive data that require notifying legal enforcement authorities, the team should initiate this and follow the laid down procedures in their IT policy. Usually, an attack results in theft, misuse, corruption, or other unauthorized activity on sensitive data such as confidential, personal, private, and business information. For this reason, it is essential to inform those affected so that they can take precautions and protect their critical data such as financial, personal, and other confidential information. For example, if an attacker manages to access user accounts, the security teams should notify them and ask them to change their passwords.

Conduct a post-incident review

Resolving an incident also offers lessons learned, and teams can analyze their security solution and address the weak links to prevent a similar incident in the future. Some of the improvements include deploying better security and monitoring solutions for both internal and external threats, enlightening the staff and users on security threats such as phishing, spam, malware, and others that they should avoid. Other protective measures are running the latest and effective security tools, patching the servers, addressing all vulnerabilities on client and server computers, etc.

Nepal’s NIC Asia Bank incident response case study

Inadequate detection capability or response can lead to excessive damage and losses. One example is the case of Nepal’s NIC Asia Bank, which lost and recovered some money after a business process compromise in 2017. Attackers compromised the SWIFT and fraudulently transferred funds from the bank to various accounts in the UK, Japan, Singapore, and the USA. Luckily, the authorities detected the illegal transactions but only managed to recover a fraction of the stolen money. Could there have been a better alerting system, the security teams would have detected the incident at an earlier stage, maybe before the attackers succeeded in the business process compromise. Because this was a complex security issue involved other countries, the bank had to inform the law enforcement and investigative authorities. Also, the scope was beyond the bank’s internal incident response team and hence the presence of external teams from KPMG, the central bank, and others. A forensic investigation by external teams from their central bank established that the incident may have been from insider malpractice that exposed critical systems. According to a report, the then six operators had used the dedicated SWIFT system computer for other unrelated tasks. This may have exposed the SWIFT system, hence allowing attackers to compromise it. After the incident, the bank transferred the six employees to other less sensitive departments. Lessons learned: The bank should have deployed an effective monitoring and alerting system in addition to creating proper security awareness among the employees and enforcing strict policies.

Conclusion

A well-planned incident response, good team, and relevant security tools and practices give your organization the ability to act fast and address a wide range of security issues. This reduces the damage, service disruptions, data theft, loss of reputation, and potential liabilities.

An Introduction of Cyber Security Incident Response Management and Best Practices - 49An Introduction of Cyber Security Incident Response Management and Best Practices - 68An Introduction of Cyber Security Incident Response Management and Best Practices - 84