It's not a big secret. Organizations need to be much more proactive about security. Firewalls and antivirus are not a plan anymore, they are doors and windows that can and will be circumvented. Expecting that attackers will simply stay off of your network is foolish. No one knows the moment they've been hacked. They find out much later, after their networks have been compromised over long periods of time. People like to say, "it is not a matter of if, but when you will be attacked." This is why it isn't about keeping threats out of your network so much as how quickly you can respond to attacks when they happen. What are some do's? We can gain more insight by looking at some don'ts:

DON'T -NOT- UNDERSTAND YOUR NETWORK

An incident response plan without adequate understanding of your network is an exercise in frustration and can make you appear incompetent to clients. How can you possibly determine when activities are suspicious or not if you don't know where to look? When something happens, how will you isolate and mitigate an attack without the knowledge of how to effectively do so without just "shutting everything down"?

Incident response typically consists of identifying the source and shutting it down but that’s not enough. With a complete understanding of your network and associated resources, you can determine if other systems were infected before it was shut down. When an attack occurs, the ability to discover lateral movement to stop the spread of an infection is critical, otherwise it leads to deeper data breaches.

Obtaining thorough knowledge and documentation of your network, both internal and external, is challenging. Cloud architectures and mobile technologies add complexities to the task. There are tools and methodologies to help.

Data collected from these need to be collected, analyzed and stored over the long term to provide value for audit trails and for actionable intelligence. Done according to best practices, though, using the right tools, can help make finding needles in haystacks more efficient, less frustrating and help you sleep better at night. Building documentation about the network using this information is well worth the investment of time and resources. It will help you to swiftly detect and respond to attacks. Don’t rely on others to inform you that your network has been compromised.

DON'T HAVE THE WRONG EXPERTISE ON THE TEAM

Most security experts are not necessarily experts at incident response. Organizations need staff or consultants skilled at responding to incidents. An incident response team that includes someone intimately familiar with your network environment will produce more relevant, accurate information faster and enable you to respond to an incident when needed.

For an incident response plan to be effective, it also needs to include everyone. Other departments will be potentially impacted and should play a role in helping to plan for incidents before they happen. Bringing these departments up to speed on how to best respond in the event of an incident is important. No one wants to wait until a breach occurs. No one enjoys scrambling to figure out what to do when time is of the essence.

DON'T BE QUIET ABOUT IT

Budgets are always tight. The budget for something like this is there, just typically not allocated ahead of time. Establishing a formal budget for incident response requires we prove its value to the organization. Need help translating the technical stuff into formal business relevance when the time comes? Get in touch.

Management teams need to be kept in the loop when it comes staying educated about the current threat landscape, pitfalls and best practices. We are all smarter when we share our areas of expertise and, in doing so, make the Web safer to do business. Not to mention, if your management team has no idea what is going on, and you don’t take the time to inform them, then there’s little hope they will support these mission-critical efforts. That puts everyone's livelihood at risk.

DON'T PANIC - HAVE A PLAN

You also need a comprehensive plan. Not having one results in everyone running around making hasty, uninformed decisions in the midst of a crisis and that is never good for business or anything else. A documented playbook that very clearly delineates roles and approved procedures for handling an incident is the goal. The playbook will ask and answer questions like: Is the team authorized and enabled to take services offline during an attack? Are such actions permitted when necessary? What legal, regulatory and contractual obligations need to be observed when a breach is discovered? It is critical to have these answers in writing and approved by the collective before an incident happens.

BEND PROCESSES TO FIT YOUR CULTURE, NOT THE OTHER WAY AROUND

Playbooks are not one-size-fits-all. Context is key to building them. Take into account specific types of critical assets, processes and roles, where they're located, your overall risk tolerance and how much leeway your response team will have to make major decisions that will involve changes to your technology infrastructure. Ideally, these playbooks or plans should strike a balance between having policies in place to ensure that the right decisions can be made in a crisis, without too many layers of complexity of approval that hinders their efficacy.

DON'T FOCUS ON THE WRONG THINGS

Focus on protecting what is most valuable. No one can protect everything all the time, so it is critical to understand where your organization’s owned risk really lies. Knowing which assets have the biggest impact if taken down by an attacker is key. Give thought to the types of scenarios that would put those assets at the most risk.

DON'T IMPROPERLY CONFIGURE DEVICES FOR YOUR NETWORK

The maximum value of network devices are never leveraged by using them with their default configurations as they come out-of-the-box. Too many organizations do this and it is an avoidable mistake. Today’s complex network infrastructures require that devices are tuned according to the size and need of the infrastructure they are attached to, their purpose and more. These devices will need to be tuned and reconfigured as things continue to change or as you become more fluent in using the tools within and also more familiar with your needs, requirements and expectations.

Neglecting to properly configure a device can lead to a myriad of problems, which actually makes responding to incidents harder instead of easier. Some products, when not properly tuned, end up not being used at all. Companies that have been breached often find out later that one of their tools had not been implemented correctly and could have detected the attack before it was too late. No one wants to end up in that position. When you purchase a new tool, take time to learn how it works best for you and your environment.

DON'T IGNORE HARD TRUTHS - LEARN FROM YOUR MISTAKES

When an incident happens, incident investigations reveal a lot of information. Somehow, more than 50 percent of companies who experience a breach do not implement other suggestions made by investigative teams. 54 percent do not collect threat indicators from their own incidents for use in fighting future attacks. Organizations need to learn that information uncovered during an incident investigation is valuable, more than a third-party threat feed in determining the types of attacks they may anticipate and how to be better equipped and prepared for them.

It is important to keep in mind that even experienced and talented attackers often reuse attack methods, exploits and infrastructure. Like the organization they target, if their tool set seems to be working, why change it? Learning as much as possible when an incident occurs enables organizations to gather insight for the future.

Would you like to learn more? Please - get in touch!