Why isn't disaster recovery and business continuity included in the dozen security processes?

Disaster recovery and business continuity (DR/BC) is generally included in the theoretical information security agenda. It is a core domain in the CISSP body of knowledge. For many organizations, though, DR/BC is actually handled outside of the information security department. Typically, the information security team is focused on controlling risk due to malicious adversaries: worms, hackers, etc., and the skill set of a typical information security team reflects this focus.

IT business continuity teams have a different set of skills. They are first and foremost focused on getting the necessary IT infrastructure up and running as quickly as possible after a disaster. Information security has a role to play here, without a doubt, but it is often not a role in the driver's seat. Because of this, I don't include it in the twelve security processes.

Plus, have thirteen security processes seems to be just asking for trouble.

When building your organization's security program, it is helpful to have a starting framework, something that gives you a solid initial structure yet is malleable enough to fit the particulars of your situation. I've found that thinking about security as a collection of processes provides just such a framework.

To keep us all on the same page, I'll offer up my definition of a process. This isn't the most exciting stuff, but, oh well. A process is a set of measurable, controlled activities aimed at achieving a specific goal. Measured means that the activity produces metrics that can be used to help determine if the process goal is being met. Controlled means that the activity's steps are clearly defined, roles and responsibilities have been assigned, and that outputs are reviewed as necessary.

Risk is an important concept, but too often, bringing risk into a security discussion leads to more analysis and talk and not to productive action. I prefer productive action.

If your discussion is more abstract and includes terms such as confidentiality, integrity, availability, and non-repudiation, then maybe including the reduction of risk as a motivation is appropriate. But if you're in a meeting with the business and trying to determine concrete direction and actions, then I'd recommend that you translate risk into controlling business disruptions related to unauthorized access. Then you have something definite to talk about and measure.

I wrote about information security as cost control mechanism in an earlier post. This post looks at using information security as a way to add value to the business.

Adding Value

Your customers and business partners want assurance that you are keeping the information and services that they've entrusted into your care safe from unauthorized access. In an environment of identity theft and stolen data, this assurance is valuable. All other things being equal, the business providing the better assurance is more likely to get the customer.

To capture this value, the information security team is going to have to go after polish. The base activities will likely be the same--the team is still out to prevent and detect unauthorized access--but now those activities will have to be refined and honed to a point where they are presentable.

The type of polish depends on the business. For some, white papers describing security features and vetting procedures will be appropriate. For others, tours of security operation centers and meetings that include information security folks will work better. An especially effective approach is to demonstrate thought leadership in security relevant to your business. Microsoft is doing an excellent job in this area. The goal is to polish your security processes until they shine, and then present them to your customers so that they can admire that shine.

Of course, you should not make promises you can not keep or claim security processes that you don't actually follow. The FTC is watching for these sorts of misleading statements and has successfully pursued legal action in several cases.

The decision to pursue a value-add approach needs to be carefully considered. Every dollar you spend on polishing your security beyond the point where it is acceptably functional is a dollar that could've been spent on something else. Will a dollar's worth of polish capture an additional dollar in sales or prevent a dollar from going to a competitor?

Each business will need to determine how sensitive their customers and partners are to security gradations. My suspicion is that initially a little goes a long way, but you soon reach a point where additional effort at security polish does not lead to appreciable increases in feelings of assurance.

Extracting value from an information security program is still fairly new and unproven, but more and more customers and partners are looking for assurance. I've seen plenty of contracts where security requirements have been explicitly baked into the agreement. Many regulations require that organizations ensure that their vendors provide appropriate security. The writing seems to be on the wall--we'll see if it fades or becomes bolder.

Previously I'd said that a good, practical definition of information security is to prevent and detect unauthorized access. That definition is fine, but it doesn't address why a business would be interested in pursuing an information security program. In my view, there are two primary reasons: a good information security program can help control costs and add value.

Control costs

Unauthorized access leads to disruptions and disruptions cost money. The unauthorized access might directly disrupt business, worm and virus infections that crash workstations are good examples, or the results from the unauthorized access might be disruptive, such as when trade secrets or product development plans are stolen. As a result, the business wants information security to keep such disruptions to an appropriately low level.

Of course, the business would be perfectly happy if information security eradicated all unauthorized access. Unfortunately, not only is this an impossible task, the closer you get to such a goal, the more difficult it is to do business. Disruptions due to security processes can quickly become greater than the disruptions from the unauthorized access. So the business instead tasks information security with keeping disruptions at an acceptable level.

When operating to control costs, an information security team manages processes aimed at increasing the difficulty of gaining unauthorized access (prevention) and decreasing the damage potential of unauthorized access (detection). I feel that detection naturally includes response--if you detect something, you investigate and respond--but I've talked to others who feel that response should be an explicit part of the information security mandate. If your organization falls into that category, it's easy enough to alter the definition: prevent, detect, and respond to unauthorized access.

An effective information security program must be founded on frank discussions between the business and information security on the disruption unauthorized access would cause and the disruption security controls and processes would introduce. Those discussions should focus on identifying relevant disruptions and figuring out how they can be measured. Once you can measure disruption, you can work on defining acceptable levels of disruption. And from there you're well on your way to an information security program that the business backs because it produces a measurable control of costs.

A later post will explore how an information security program can add value.

The holy trinity of information security is CIA. The principles of confidentiality, integrity, and availability are de rigueur for most descriptions of the info sec field. Every student learns to recite the trinity in their sleep, often with the addition of authentication and non-repudiation. These concepts are valuable and useful, but they are a bit abstract and academic. Whenever they are trotted out in a meeting, eyes begin to glaze.

I've found that unauthorized access essentially means the same thing, is more intelligible to most of us, and is more in line with what most people seem to expect from information security. Let's face it, to most people availability covers much more than business continuity planning (think redundancy, load balancing, scalability, bandwidth management, fault tolerance, etc.), and it is a rare infosec department that is called in to help with database design to maximize throughput.

For a useful, practical definition of information security, I like prevent and detect unauthorized access. It covers the key areas and is fairly intuitive to non-info sec specialists. It also has, I think, surprisingly deep implications.

I use access in the "read, write, execute" sense. This covers confidentiality, integrity, and things like compromised machines and escalated privileges that don't always have direct confidentiality and integrity ramifications. The concept of authorization cuts directly to the issue of permissions and approvals which lie at the heart of information security. What are your users allowed to do?

Information security should work closely with the business to specify what is and what is not authorized. Unfortunately, this key business benefit (technically called a security model) is often underemphasized in favor of flashier infrastructure and technology. I don't blame information security departments for this failure--at least not entirely.

Specifying and maintaining a security model is hard work. It can easily uncover weaknesses and segregation of duty issues in business processes. It requires that a lot of hand waving and ambiguity be clarified, and the fear is that the flexibility needed to get business done will evaporate into rigid policies.

These are fair concerns. It is information security's responsibility to provide the expertise that will produce security models that don't block the business. At the same time, the business needs to recognize that effective security requires knowing what is and what is not allowed. Some flexibility will need to be sacrificed.

The prevention and detection of unauthorized access is ultimately what most businesses want their information security teams to deliver. To accomplish this, the business needs to be a full partner in defining what is authorized and what is unauthorized. The information security team can then work with IT to keep as much flexibility as possible while carrying out their mandate.

Dedication

My grandfather had a wonderful shop in his basement. To me, it was a place of mystery and fascination, and I would spend hours wandering through it, looking at all the tools and projects in various states of completion. Not being much of a wood worker, I've never had the need for such a shop (not to mention that I lack a basement), but recently it occurs to me that my gear, computers, and software are my shop. This site is for my late grandfather and everyone else who takes personal pride in carefully executed work.