Every company operates with some level of uncertainty and ambiguity. What separates the winners from the losers is how the company responds. For example, I once worked at a company where their (DBA) described them this way:
Think of company x as a ship floating on a large sea. The ship has no rudder and tends to get thrown around by the waves. Be assured, though, that wherever the ship lands, it is exactly where it needs to be.
As someone who believes in the value of planning, the vision of this helpless ship being tossed about is alarming. On the other hand, the company continues to thrive today—so perhaps the way it handled risk was acceptable.
Is Security Strategy, by Necessity, Random?
When I think about the state of many security programs, particularly from a systems engineering perspective, it's hard not to see a typical enterprise security strategy as eerily similar to the ship my DBA colleague described so many years ago.
What's particularly troubling to somebody like me, an admitted newbie to this topic, is that there seems to be broad consensus that security is, and is forever ordained to be, reactive in nature. (See my Information Week blog for more on this topic.)
Companies seem to spend their security dollars to prevent platform breaches ("I buy product X to protect my mobile devices, product Y for data center, and product Z for my networks") rather than it being part of a more holistic strategy. While this approach may have been acceptable (or perhaps excusable) when everything resided under one relatively friendly roof, it's not sustainable as you move your infrastructure, software, and data to locations outside your immediate control.
So what can you do?
Security by Design
Throughout 2012, I worked with Intel’s CISO, spent some time talking with a senior director at McAfee, and listened to some wisdom provided by the Ponemon Institute, LLC. The goal was to try to craft a security approach that changes the fundamental way an enterprise views and implements security.
As it turned out, the answer is deceptively simple and even somewhat intuitive. You just have to view and manage security like you do any other business investment. The challenge is to get your CEO, CFO, and CIO to view security using the same fundamental criteria.
So what is Security by Design?
As you might expect from someone with a systems engineering and enterprise architecture background, I believe Security by Design understands that security is first and foremost, a business issue. This is necessary to align the goals of your CEO and CFO (who control the budget).
The Security by Design framework is explained using three categories:
1. Current state of enterprise security
2. Security by design
3. Defense in depth
I can't detail the entire security framework in this blog. But I can provide the important elements you can use to start building your own strategy.
First, divide enterprise security into four topics:
1. Organizational
2. Controls
3. Approach to risk
4. Funding and cost efficiency
Make a brutally honest assessment of where corporate power lies, where security decisions are made (think many decision pockets), conflicting enterprise security goals, and hidden security expenditures.
Figure 1 shows the building blocks of security by design.
Figure 1. Security by Design Elements
The elements of this framework make a very nice picture. But in reality, few (if any) companies actually have all of them in place. If you're going to have any control over your security strategy, it's important to recognize that you need to formally document (and regularly reference) at least some of these elements. If you don't, you're like that ship without a rudder.
You also need to base your framework on four security investment rules which were based on a foundation provided by Intel’s CISO:
· Rule 1: Security solutions have no intrinsic value unless you can demonstrate savings or cost avoidance.
· Rule 2: You need more information than “Who did what to what (or whom), with what result?”
· Rule 3: Intelligent security investment requires a cohesive, defensive strategy to answer four simple questions:
1. Whose actions affected the asset?
2. What actions affected the asset?
3. Which assets were affected?
4. How was the asset affected?
· Rule 4: There can be only one individual/office responsible for end-to-end security investment; authority cannot be separated from responsibility.
(Learn more about an earlier version of these rules in a blog I wrote for Information Week.)
Organizational Impacts and Common Language
As you might expect, once you begin to approach security from a system strategy perspective, there must be a paradigm shift in your IT and business units as well as with individuals. These shifts include:
· Accountability
· Policy
· Control discipline
· Awareness
Finally, as your organization moves toward a defense in depth strategy, you must establish some common terms to describe security threats. While this might sound simplistic, it's important to remember that everyone in your organization must understand the threat in universally understood terms. The entire enterprise must speak about threats using the same vocabulary.
Figure 2 shows industry-standard terminology for common categories of threats.
Figure 2. Threat Categories
Finally, the defense in depth component of your security by design strategy requires setting goals at each defensive level (following the Intel security investment model we discussed in an earlier blog).
To learn more about Intel's security by design framework, contact your Intel field sales representative or reach me via Twitter.
Download Now
Download Now
Download Now
Download Now
Download Now
Download Now
