A Cyber Incident Response Plan for Your Web Applications

Barely a day goes by without reports of a data breach or costly outage in yet another organization, and hundreds of similar incidents go unreported. With so many businesses dependent on web technologies, chances are that sooner or later your organization will face a cyber security incident involving your websites, web applications or critical web services running in the cloud. Having a cyber security incident response plan (IR plan) is crucial for maintaining business continuity and recording all information required to manage any incident and its aftermath, and web security is no exception. In fact, your web-facing or cloud-based systems and processes are more exposed to threats than any other area of the organization, so response planning for web incidents is crucial to ensure information security. In this article, we will look at how you can plan your web security incident responses, what threats you need to consider, and why having an effective and tested response plan is a necessity, not a luxury.

Your Web Cyber Security Incident Response Team (CSIRT)

Before you start planning, you need to determine who will be involved in incident evaluation and response processes: you need a web cyber security incident response team (CSIRT). To choose the right people, look at your web application structure and back-end, and see who has the skills and authority to analyze incidents and perform recovery. Depending on the size and complexity of your website or application, your team could be anything from a couple of system administrators to a cross-function mix of individuals and groups across the organization. Remember that security operations affecting the entire organization, such as taking critical systems offline or running recovery, might require authorization from higher up, so your team may need to include executive as well as technical staff. In your plan, document the roles and responsibilities of key individuals and groups. Ensure that everyone in your security team knows their role and is trained accordingly.

Communication is crucial in any emergency, and especially in a cyberattack that may affect your organization’s infrastructure. Your plan should specify multiple channels of communication among team members and anticipate technical issues that may arise in likely attack situations. You should also ensure that all crucial roles will always be filled in any emergency – a detailed response procedure will be useless if the only person with the required skills or authority is on holiday, or left the company last year.

One approach to assigning human resources to security teams is to establish a dedicated Security Operations Center (SOC) – basically a separate IT security team responsible only for cyber security. Depending on your resources and requirements, you can create an SOC in-house or outsource it to an external provider. SOC outsourcing can be especially attractive for small and medium businesses that are heavily reliant on cloud solutions but lack the resources or expertise to develop and maintain their own detection and investigation team for computer security. SOCs use specialized staff and advanced security tools, including security information and event management systems (SIEM), firewalls, intrusion detection, breach detection and so on.

Cybersecurity Risk Analysis

Analyze your web systems and processes to identify areas critical for business operations due to high exposure, data value or other factors. Focus on places where your websites or applications interact with business-critical processes and systems, and perform a risk analysis for every likely incident scenario. Identify possible cyber threats and define suitable incident types and severities. You should also plan how and when to act on available threat intelligence, and link your plan into existing threat detection and intrusion detection tools and processes.

For identified risks, decide what web security events should be considered security incidents, and how priorities should be assigned. For example, should persistent unsuccessful login attempts be treated as actionable incidents? What level of server response latency will require investigating? Should phishing attempts be handled as part of web security or general network security? To define specific priorities, you can use this guide provided by the United States Department of Homeland Security. Remember that your plan should cover not just high-severity threats, but also lower priority events – even if a security breach is technically low or medium priority, it could still have serious consequences, including data loss, information exposure or malware infection.

Identify other systems that could be affected by a web security incident. Depending on your application and systems architecture, a compromised web application might be interfacing with core business systems and databases, so security risks can extend far beyond web systems. Remember that adding a new web service or extending an existing one is now very easy for developers, so dependencies on cloud-based services can turn up in unexpected places. To prepare for recovery, identify existing backup policies and processes and define required recovery point and time objectives (RPO/RTO) for your web infrastructure, including servers, storage, and operating systems.

Cyber Incident Response Process

Once you know your team and the risks you might have to face, prepare response and disaster recovery procedures for identified incident types and severities. For each procedure, specify the required security tools along with communication and authorization requirements. Remember to include procedures for logging incident information and recording the response process, so you know what happened when and who took which actions. Incident logs are crucial not just for your own post-mortem examinations, but also for any investigations by regulators or law enforcement.

Situation awareness is a key aspect of any emergency response, so your plan should specify rules and methods for monitoring the threat situation in real time. Who decides when an event becomes an incident? How is that information communicated within the IR team? Who is responsible for status updates and how often should they occur? All these questions need to be answered to ensure a clear picture of any emergency situation.

Depending on the scale and reach of your web operations, it may be a good idea to prepare suitable messaging templates for specific incident types and severities. These may range from simple error messages to public statements for serious outages or breaches. For large organizations, remember that external communication during incident recovery may affect not just your reputation and value, but also regulatory interest in your incident – especially for potential leaks of confidential information. Make sure your messaging is approved by PR and legal, and that your IR plan clearly specifies who is authorized to publish what information.

For a more formal and detailed discussion of recommended cyber incident response practices, see the NIST Guide for Cybersecurity Event Recovery.

Incident Response Plan Testing and Reviews

When your plan is ready and approved, you will need to test it to ensure that all procedures and communication channels are realistic and work as expected. Tabletop exercises are an easy and cost-effective way of simulating incidents, honing response procedures, and training your team. Make sure you document each tabletop session to provide a record of identified problem areas and potential improvements.

To ensure your processes keep pace with new threats and changes to systems and organizational structures, you will need to conduct periodic reviews – typically once a year, but quarterly reviews might be required in fast-changing or high-profile environments. In your reviews, check the accuracy of recorded systems information and procedures, and don’t forget to periodically update contact information to ensure an effective flow of information.

The Benefits of Effective Response Planning

An effective and tested web cyber incident response plan is an invaluable asset for your organization. It ensures you are prepared to quickly and effectively react to likely incidents and reduces business impact when things do go wrong, so you can minimize costly downtime and contain issues before they get out of hand. In the process of defining your plan, you will also gain a clear understanding of your organization’s web systems and overall security posture. From a legal point of view, having a documented plan is vital to ensure compliance, demonstrate your diligence, and provide a clear paper trail of all events, affected systems, potentially exposed data, and your team’s responses.

On the flip side, not having an effective plan for web incidents leaves your organization vulnerable to downtime, data loss, and potentially even legal liability. While the direct business impact of web service downtime seems relatively easy to understand and quantify, dependencies on web technologies are often tightly woven into the application infrastructure, so actual consequences may be more serious than initially expected. What’s more, increasingly stringent data protection laws (notably the European GDPR) can make detailed response planning and logging a necessity. Without a good response plan and precise incident recording, any data breach resulting from a compromised web application or unsecured cloud container may have serious consequences going far beyond financial costs – from loss of reputation to legal liability and regulatory fines.