How much security is enough?

Security professionals have an interesting job. They manage existing security controls while eternally looking for gaps in their organization’s defenses. Recognized gaps often result in analysts running to the favored security vendor for another application, appliance, or service. But is this the best approach financially or “defensively”?  Probably not.

The challenge

Many organizations approach security like players of Whack-a-Mole.  (See Figure A, 360digest.com.)  Placing basic security controls in place, they wait for the next emerging threat and whack it with a virtual mallet.  This process continues without end and without any real protection strategy. The one-off approach may protect the organization, but related costs are probably much higher than necessary. In addition, integrating new business solutions simply expands the number of holes from which moles might stick out their little furry heads.

Figure A

Management of disparate security controls, implemented in answer to new threats or regulatory requirements, requires a large number of soft dollars. These often redundant and “un-unified” components may actually create holes in the organization’s defenses, making it harder to protect information assets and to deploy new business solutions.

This is the way the security profession began its tenure. However, business managers are tiring of what they see as nickel-and-diming the IT budget. So it is past time when we need to manage security objectives via a security architecture. The architecture must support other enterprise business frameworks intended to achieve business objectives. By building all solutions within these architectures, we are assured of a “secure enough” environment, flexible enough to safely accommodate new or existing business systems.

The solution

Figure B depicts a set of enterprise architectures designed to achieve expected business results.  First come the outcomes based on a clearly stated business strategy.  The outcomes are then translated into an information architecture that actually defines the business.  Network and system architectures are designed to support processes that create, massage, and deliver information relevant to management and operational teams.  Security’s role is to continuously enable safe and available operation of components built within these architectures.

Figure B

The enabling goals of security do not play well with the Whack-a-Mole approach.  What is needed is a well-defined, documented, and manageable security architecture.  Using it, IT teams build systems and network segments with security built-in.  Required is what Novell’s Jay Roxe calls a unified framework.

According to Roxe,

The first step is to get away from the ad-hoc, piecemeal approach to regulatory compliance and risk management. That’s achieved best by initially taking inventory all of the organization’s risk management processes and controls, and then making sure they are clearly defined and documented. As there may be hundreds to thousands of controls and policies in place, depending on the size of the organization, this could take some time and effort. But, it’s well worth it (ZDNet, 2010).

This step results in a list of all controls currently in place, their function, and a view of existing gaps and redundancies. We performed this task at ManorCare several years ago. We used a spreadsheet like the one shown in Figure C.

Figure C

The Layer/Required Control column represented the expectations surrounding the new security strategy we’d written.  The strategy was based on a combination of COBIT, HIPAA, and ISO/IEC 27002 considerations, encompassing all data and system protection objectives. The purpose of the strategy was to define and document an architecture that:

• Met regulatory requirements
• Protected employee data
• Protected confidential business information
• Ensured availability of critical processes in accordance with management expectations
• Enabled the safe delivery of data anytime, anywhere
• Allowed us to pass both internal and external audits

Subsequent columns showed how each existing security solution met or did not meet each control requirement.  The process took about 60 days, but the results were immediate.

Using the matrix, we eliminated several controls due to redundancy or by enabling unused functionality on other controls. We continued to use the matrix to identify our risk every time a new threat was identified.  In most cases, we found we could simply modify configurations on existing software or hardware to adapt to the new challenges. (For more information about how we used the matrix, see, Use a security controls matrix to justify controls and reduce costs.)

So the combination of a strategy and a managed controls matrix reduced costs, communicated how systems and network components fit into the enabling process, and allowed flexible responses to emerging threats.  We stopped reacting and began to proactively build a prevent, detect, contain, and respond framework to meet every contingency.

The final word

We recognized earlier than many security organizations that our ability to run up a red flag and automatically get budget dollars was waning. I won’t say that our approach was perfect, but it provided a foundation upon we improved over time. The end result was the ability to react to business need while methodically and proactively addressing external and internal security challenges at a reasonable cost.