In a world getting less predictable every week, good business leaders proactively prepare for cyber incidents with plans that anticipate and minimize disruptions. But as you start looking ahead, it’s easy to get confused about the differences between incident response plans, disaster recovery plans and business continuity plans. In this post, we’ll explain how the plans all weave together into a holistic strategy to protect your business.
The IR plan is the overarching document that gives your team clear guidance on exactly what to do during incidents, data breaches, and other pressure-packed situations when it’s easy to get overwhelmed. If you realize you may be facing a cybersecurity incident, the IR plan will help direct your actions. Every good cybersecurity program puts a high priority on writing and regularly reviewing an IR plan. In many cases, you may be required to have one by industry regulators, your cyber insurance company, key customers who want assurance that you can handle incidents, etc.
Your IR plan will describe your specific:
Note that many organizations combine the DR and BC plans into a single document that outlines the processes involved for declaring a disaster, the formulation of the Response Team Members, the processes necessary for a secure recovery, and finally the steps necessary to maintain the continuity of business operations. We’ll explain the differences in the documents here, but rather than fixating on rigid definitions, just make sure you have thorough plans in place.
The DR plan usually centers specifically on data and technology operations with processes for recovering information systems at an alternate facility in response to a major hardware or software failure or destruction of facilities. The DR plan explains, for example, how you can restore lost data, whether that means restoring a single system or an entire data center.
The DR plan will include details such as recovery time objectives (RTOs) and recovery point objectives (RPOs). These define, respectively, how long you can function without a service and how current the data must be when you restore it. For example, RPOs may tell you that restoring copies of training materials from 48 hours ago isn’t a problem. But if your business runs on current stock market trading data, the RPO will show that you need data to be current within a few minutes.
The BC plan describes how you’ll maintain operations during and after a significant disruption or an incident. The BC plan should include a triage process for restoring the most essential operations first, such as filling customer orders, making payroll, supporting business partners, etc.
Your BC plan will explain how you can maintain operations in situations such as:
The BC plan rests on the foundations of an overall information technology risk assessment and a business impact analysis (BIA). The BIA specifically identifies potential operational implications of various scenarios. What happens to your business if, for example, you lose access to a certain database or cloud-based software? How long could you withstand such an outage without major damage to your business? In a BIA, you’ll seek to put an actual financial cost on various interruptions so that you can make informed investments in prevention and mitigation strategies described in your BC plan.
For all three of the plans described in this post, be sure to include these key elements:
For help assessing your specific business risks and making a plan to mitigate them, contact Pratum today.
Recent high-profile ransomware attacks have motivated many organizations to dust off their incident response plans—or create one for the first time. If you’ve ever endured a breach, you know the value of a well-designed incident response plan. By guiding decisions in the critical first hours of an incident, the incident response plan can keep a minor situation from turning into an operational shutdown, as well as help your team track down the breach’s root cause, file cyber insurance claims, manage messages to customers and more.
A solid plan helps ensure that your crisis won’t ripple out to all of your clients and partners. A well-planned response prevents data loss, financial loss, impaired reputation and long-term damage to your business. Use the following guidelines to make sure you create an incident response plan that includes all the essentials.
Start by determining what others require of you. In many industry sectors, incident response (IR) plans are mandated by state law, federal guidelines (such as HIPAA) or your biggest customers’ vendor contracts. For example, more than a dozen states require any company in the insurance industry to maintain a written IR plan, among other best practices. And your cyber insurance underwriter will almost certainly offer you a better rate if you have policies such as an IR plan in place.
One go-to standard for IR plans is NIST publication 800-61, known as the “Computer Incident Handling Guide.” This 79-page document provides details on tasks such as structuring an IR team, handling incidents as they occur and coordinating across departments and organizations. NIST’s approach boils down to this four-part Incident Response Life Cycle:
You should also review the SANS Institute’s more concise guide, known as the Incident Handlers Handbook. SANS recommends that every plan provide a specific process for these six areas:
Begin by asking these critical questions about your business:
Before implementing an IR plan, let your staff know so they can understand why you’re writing the plan and what their role will be during an incident. Include pertinent staff members in creation of the plan so that they’re invested in executing the plan when an incident comes up.
These are the key elements to include in your IR plan:
– An incident coordinator tasked with managing meetings, keeping notes and documenting actions.
– People with strong tech skills, IR experience and an understanding of the business.
– Multiple people with strong communications skills they can use to share information clearly and efficiently in the right directions.
– Representation from key related areas such as legal, HR, and the physical facilities team.
– An executive sponsor who can champion the team’s concerns up the ladder and provide visibility to the overall business.
– A system for rotating IR team members on a planned basis to avoid burnout and promote fresh perspectives.
It’s easy for IR plans to get very long and complex, especially as you continue to revise it over the years. But you should focus on streamlining your plan to the essentials that people can realistically follow in the excitement and confusion of a real incident.
Just as critical as your organization’s internal team is the lineup of external service providers you’ll call on in an emergency. It’s essential to identify and build relationships with your providers in advance for two reasons. First, service providers that get to know your organization in normal times will be prepared to spring into action with an informed point of view at a moment’s notice. Second, securing the providers ahead of time will help you use your preferred vendors rather than being stuck with an unknown company from your cyber insurance carrier’s preferred provider list. Once you’ve picked a vendor, ask your cyber insurance company to add them to the preferred list to ensure that you get to work with your selected partners.
Your external vendor team should include:
Your IR plan isn’t a set-it-and-forget-it proposition. You won’t know if it works unless you test it. And you won’t know if it continues to work unless you incorporate a specific, regular schedule for review. At minimum, review it once a year. If your business is highly dynamic, it may require more frequent review. Common changes that prompt plan updates include:
After you experience an actual incident and contain the problem, the IR plan should include steps for reviewing the incident. Ask what went right and what went wrong. Establish a timeline of events to help answer these questions and show you the bigger picture.
After the review, adjust your plan as needed. If a step in the process didn’t go as planned, figure out why and make changes.
If you need help creating an IR plan tailored for your specific situation, contact Pratum today.
Penetration testing provides a real-world test of your security posture by sending an ethical hacker to break in using the same techniques as actual bad guys. While most people picture penetration testing as someone cracking lines of code, the process entails far more than that. Here's an overview of penetration testing explained from initial scoping to final validation.
In this phase, clients and testers agree on the ground rules, such as whether the test of a web app extends to the infrastructure behind it. The team also decides whether to alert the client’s IT team about the penetration test or to let them practice stopping what they think is an actual attack.
Like real hackers, good penetration testers use the web, social media and other public sources to identify individuals and parts of the organization to target. They also uncover technical details through port scanning, network sniffing and more.
Automated tools scan your system for known vulnerabilities such as open ports and unpatched software that the human pen tester can use in their attack.
It’s easier to hack a person than a server. So pen testers often try to fool someone into giving up their system credentials through phishing, pretexting phone calls, etc.
Armed with research, ethical hackers attack the system using known vulnerabilities; predictable or leaked passwords; spoofed login sites or devices; and more. Once they gain a foothold, penetration testers pivot through the environment to see how much data they can access.
The pen tester begins listing risks they discover and categorizing them according to a common standard such as the OWASP Top 10 for web apps. Risk categories include broken access control, cryptographic failure, insecure design and more.
Now the penetration tester formats their work into an understandable, actionable report for the client team. A good reporting process includes an executive summary, an in-depth technical report and an action plan listing recommended remediations.
Armed with the detailed report, the client’s team can begin remediating moderate and high risks.
After the IT team remediates risks highlighted in the external portion of the penetration test, the pen tester returns to confirm that each risk has been eliminated. This confirmation is included as part of all external engagements.
Get our blog articles delivered
to your inbox: