Due to the increasing frequency of information security breaches, CISOs are being asked to evaluate the risk of a security breach in their environments and put appropriate measures in place to protect against them. As a result, in a recent Forrester Research survey, security and risk management professionals rated "protecting customer data" and "protecting sensitive corporate data" as their top priority for the next 12 months.
Here are some lessons learned that corporations should keep in mind when devising a plan against information security breaches.
Carefully plan a layered defense approach
An attacker has many potential avenues from which to attack, and this is perhaps the biggest breach-protection issue; if security personnel miss just one such avenue, that may be enough to cause a security breach. Taking a layered approach to security breach planning eliminates some of this risk by ensuring other layers of defense can compensate when a corporation can't provide absolute security through one means.
Many security professionals understand this concept, but unfortunately apply it through technology only. For example, they would say, "I have multiple inbound gateways for email and spam, and have antivirus and antispam technologies on my desktops." What they often forget is that there is another dimension to this layered approach, i.e. the people and the process layer. Organisations need to train employees to watch out for social engineering
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
Establish and test processes
It's astounding to see how many companies don't have a have a plan or a process to respond to information security breaches. Many have an incident response plan, but such plans are often focused on operations and getting systems up and running, as apposed to minimizing the risk to information assets. Then again, the incident response plan is rarely a living breathing document; it is typically on a shelf gathering dust.
CISOs should ensure that security breach planning is a core part of the incident management plan. It is also essential that this plan is tested regularly. Have the response team practice responding to various scenarios and work under stimulated stress conditions. Having mock tests trains the organizaitons to work effectively as a team under stressful conditions. These tests can also highlight areas of deficiency and will help keep the plan current, accurate and in line with reality.
Build external relationships
Security breaches often require involvement on the part of external entities such as the local police, regulatory authorities and forensic specialists. It's important to build these relationships up front. If an enterprise has to spend time searching for the right law-enforcement contacts immediately following a breach, not only does it lose invaluable time, but it is also rushed when evaluating and selecting a partner that fits its needs.
Publicly acknowledge a breach as soon as the facts are verified
Many companies have been penalized by regulators for not communicating about breaches in a timely fashion. Many others that were quick to come out in public were embarrassed when later investigations found the size and scope of those breaches to be much bigger than initially reported. Customers and regulators tend to be more forgiving of companies that report breaches quickly. Still, Organisations should ensure that they have verified all the facts before going to public.
Understand legal and jurisdictional requirements up front
It's essential for an organisation to involve legal experts up front and understand the requirement constraints before initiating a response. For example, the data breach laws in the U.S. dictating how an enterprise should acknowledge, report and respond to a security breach vary from state to state. In other parts of the world, organisations may not need to acknowledge a breach publicly, but may still have evidence-collection and forensics requirements to consider.
Empower the team to make decisions
Due to the sensitivity of these issues, the security breach-response teams typically consist of senior-level people within the organisation. Although it's important to keep them abreast of the situation, they are typically not the ones who deal with operations at the ground level. Therefore, the breach team should have a healthy mix of decision makers and technologists.
Valuable time is often also lost in responding to a breach because the right person at the right level isn't available to authorize an action. Organisations should empower the breach team members to make critical decisions, such as bringing down a critical server or blocking corporate access to the Internet, without fear of retribution if the situation requires them to do so.
Not just lessons learned but root cause analysis
Breach investigations should go beyond Band-Aid remedies and look for the real cause of the failure in controls. Typically after the breach, management is more willing to spend money to get things right, and therefore the investigation should identify the root causes and recommend a phased approach to address those root causes. Once the mitigation plan is developed, it is essential to document, track and ensure that the changes are implemented in a timely fashion.
Measure security policy compliance
Most organisations can honestly say they have a pretty good set of security policies. Where companies fail is in implementing these policies. This becomes an important factor in data breaches. When a corporation has a data breach, the first question any external assessor, regulator or court official will ask is whether the proper policies were being followed. If it is learned they weren't, that enterprise will be considered negligent in its responsibilities. It's essential for corporations to measure their policy compliance consistently. Implementing policies requires processes, procedures and standards that need to be established within the company, including ones for security breaches.
About the author:
Khalid Kark is a principal analyst at Forrester Research. His research focuses on information risk management strategy, governance, best practices, measurement, and reporting. He can be reached at firstname.lastname@example.org.
This was first published in May 2008