Before the Breach Part 2 - 6 Best Practices

Anthony Di BelloEarlier this week, we talked about the implortance of incident response. In this post, I'm going to touch on the 6 best practices presented in our webinar, and why I think these are important considerations for you to take.

Best Practice #1: Preparation. Whether you are running a sports team, a military, or incident response effort, success requires that the team be prepared. A plan of action needs to be in place. The organization needs intelligence on new threats and risks it faces. Also, anyone involved in the incident response process needs a clear understanding of what their expectations are and what they need to do to when an incident is underway.

Another part of preparation is understanding the abilities and limitations of your organization. Do you have the resources necessary to respond to outbreaks manually, or would network-enabled response help your team save time and effort? Other important aspects of preparation include having clear and up-to-date knowledge of your environment, as well as understanding where sensitive and regulated data are stored. Finally, as is true with any successful team, you need to test your incident response processes with fire drills and ongoing practice.

Best Practice #2: Identify the risk. Make sure you can identify incidents as quickly as is reasonably possible. Tune your intrusion detection systems properly and integrate security and infrastructure event logs with your SIEM (if you have one). This way, you can quickly identity the critical events that need immediate attention. And note that while SIEMs can help eliminate a lot of noise from your intrusion detection systems, as well as events from throughout your infrastructure, high risk incidents will need to be carefully vetted and handled by incident response proceedures.

Best Practice #3: Triage. Speaking of alerts, as you have them rolling in from various security platforms, you need to have a system in place that enables you to understand what threats need immediate attention and which can wait for analysis later. In one interesting example during our best practice webinar, Darrell Arms, solutions engineer, Accuvant Inc., recalls an instance when a client was on the verge of publicly disclosing what, initially appeared to be a significant breach on the company’s data. Fortunately, after a thorough forensic investigation, it came to be realized that there wasn’t any breach at all. That experience goes to show how important the power and visibility provided by capabilities driven by forensic principles can be.

Best Practice #4: Contain. To be able to contain a threat, you need to be able to collect, preserve, and understand the evidence associated with the incident. That includes any malware uncovered. And this evidence can’t be collected in a haphazard way; it needs to be handled as evidence, because it potentially will be. Malware and live system information must be collected and preserved in real-time, in order to provide accurate and timely details for a full scope assessment. This is crucial to understand potential targets of the attacker, as well as how deep the attacker may have infiltrated, or how far malware had propagated. Live system details as well as the Malware binary can be leveraged to seek out other infections throughout the network quickly. While the largest enterprises may have the expertise in-house to reverse engineer malware, it is a time consuming and expensive process when there is more readily available data that can be used to immediately perform an accurate scope assessment. Either way, have a plan in place to utilize when needed.

Best Practice #5: Recover & Audit. Before the incident can be considered closed, all offending malware and exploits have to be removed from affected systems, and any offending vulnerabilities that made the attack possible need to be closed. Systems need to be cleansed, or possibly even rebuilt. It’s important, for this stage, to have the ability to search throughout the network for other potentially infected or compromised systems. During this phase of your incident response plan, you’ll need to conduct a sensitive data audit of any affected systems that may have contained personally identifiable information, intellectual properly, data that are governed by regulatory controls, or anything that could possibly trigger a mandated breach notification.

Best Practice #6: Report & Lessons Learned. Hopefully, the breach didn’t involve regulated data. However, if it did, you’ll need to consult all relevant data breach notification regulations, and develop a plan with internal stakeholders such as IT, communications, business leaders, and legal on how you’ll move forward.

It’s important to remember that any business can be breached. In fact, most will be. And, if a company has been in business long enough, it’ll be breached more than once. That’s why it’s so important to learn from these incidents. Document, in detail, what went wrong, and suggest controls that could work better in the future. Also, document what went right and why.

Perhaps this negative incident can also be an opportunity to obtain the budget for things that have been neglected, but shouldn’t have been. Perhaps your organization needs more people dedicated to IT security and response. Maybe what’s needed is not more people but employees with perhaps different skills sets than are currently on staff. Maybe it is certain types of technology that you’re missing that would help to block such attacks more effectively, and more rapidly expose those that do manage to slither through. Take the opportunity to learn from what went wrong, so you can be stronger in the future.

No comments :

Post a Comment