Why Should You Care About Incident Response?
Cybercrime continues to increase and criminals are becoming more and more inventive in the ways they steal information or otherwise harm your systems. Even the best security solutions have vulnerabilities that can be exploited and rely on the people operating them to be equally secure, which usually isn’t the case for end-users.
What this means is that the odds are against you if you’re relying on the idea that a security incident won’t happen to you. Rather than waiting until it does, you can use an incident response plan to ensure you are ready to respond quickly and effectively when an incident does occur.
What Is an Incident Response Plan?
An Incident Response Plan (IRP) is a set of instructions used to plan for, detect, respond to and recover from security incidents, such as cybercrime, data loss or service outages. It is used to mitigate risk, reduce damages inflicted and evaluate responses to improve procedures when an incident occurs.
How to Build an Incident Response Plan
Building a good IRP takes time and you are likely to miss some key components if you rush through it. To avoid that, be methodical and keep the following guidelines in mind to ensure that nothing is missed when you develop your plan.
Identify Critical Components and Vulnerabilities
The basis of any good plan is solid research━before you can plan how to best protect your assets, you need to know what they are, how they are currently protected, and what you need to protect against.
Start by taking an inventory of what data and resources you have and begin prioritizing your findings in order of value or risk. When doing this, you should consider how the loss or compromise of each item might affect your operations and productivity. Don’t forget to take into account whether or not data is subject to regulations━even if the data is not vital to your operations, punishments for lack of compliance can seriously affect your operations and your bottom line. Make sure to involve representatives from all of your teams during this process as data or systems that seem low-priority to you could be vital to someone’s productivity.
Once you have a firm grasp on what you need to protect, it becomes meaningful to evaluate how those assets are currently protected and how they might be vulnerable. Examine any current security policies or solutions you have and verify whether they are being implemented efficiently. If they aren’t, you will need to reapply them until they are and if they are, you should verify that your protocols for use are actually being followed.
This process should help uncover where potential gaps in your security lie and what threats you should need to focus on protecting against. Determining this will involve some research and include tests of your current system. You should at least do some threat modeling but can go as far as hiring a “white hat” hacker to thoroughly test your systems.
Address Identified Vulnerabilities
You most likely found at least a few weak spots in your security when evaluating your assets and current procedures, which is exactly what you want. Finding those vulnerabilities now allows you to take preventative action to secure them. If the issues you uncovered are fixable, through patches, changes in the tools being used, or changes in policy, implement them as soon as possible.
If, however, the vulnerabilities you found are ones inherent in the system, or ones created due to an operational need, such as having customer-facing endpoints, you can focus on monitoring and isolating them as much as possible from the rest of your system.
A tiered architecture can help you isolate your most valuable data by requiring multiple levels of authentication before access can be gained. Monitoring solutions that include features like User Entity Behavior Analytics (UEBA) can help quickly identify suspicious behavior and immediately alert the appropriate parties or restrict access to the identified source.
During this step, you should build redundancies into your system when possible to eliminate single points of failure and to ensure that if data or systems are lost, they can be recovered as quickly and painlessly as possible. Consistent backups are a key component here and using cloud-based services can help ensure that even if some aspects of your system become inaccessible, your teams and customers can retain functional access.
Create Incident Response Protocols
Once you know your needs and weaknesses and have taken preventative steps, you need to address any remaining vulnerabilities. You should identify the most likely scenarios to occur and build step by step instructions for handling them, from detection to post-incident analysis. If there aren’t specific scenarios to point to, flowcharts and other decision-making tools can guide how your response team should act.
Playbooks should be used to document the protocols you create and each should address the following:
- Preparation━what steps have already been taken, including what tools and policies are in place
- Detection━what systems are in place for detection, what parameters are being used to identify an incident and who will be alerted
- Analysis━who is responsible for analyzing incidents, what tools are available for analysis and how to use them, and at what point analysis is sufficient to determine action
- Isolation and Eradication━how threats are to be contained and neutralized, and the priority level of security vs productivity
- Recovery━how to assess the damage, the priority for returning functionality and recovering data, and what necessary notification or compliance steps need to be taken
- Post-incident handling━how to measure efficiency and effectiveness of response and how to use the experience to improve future responses
Your instructions should layout which actions to take and who needs to take them. No one who is responding should have to waste time tracking down which tools are being used, the process for revoking user access, or which data backups are needed. All of these can be explicitly defined ahead of time and some of them might even be automated so that responders need only initiate a prebuilt process.
Develop a Response Team
The best plans are useless if you have no one to implement them. When building your response team you will need to identify specific members of your staff and explicitly assign them roles and responsibilities. Including fallback members can help ensure that you are prepared even if an incident happens when someone is sick or otherwise unavailable. On your team, you should consider including an incident response manager, security analysts, threat researchers, a documentation leader, your IT director, and other members appropriate to the situation such as lawyers or communications experts.
Once your team is in place, make sure that everyone understands your plan, why it’s important, and knows their specific part. Running incident response drills can help cement this knowledge, expose any flaws in the plan, and get both your team members and your wider employee base more comfortable with plan execution.
Developing a comprehensive incident response plan is not easy, nor is it done overnight. Despite this, it is vital to successful incident management and prevention and your ROI is sure to be significant if the process is approached methodically. The guidelines covered here can help you ensure that any plan you develop is as effective as possible and can give you the peace of mind that your assets are maximally secure.
The post How to Develop Your Incident Response Plan appeared first on Web Development & Technology Resources.