Quick: Your job as a security manager is to secure the:
- D. Users
Actually, it's a trick question. The answer is none of the above. Your job is to secure the business.
No problem, you say. I've got firewalls, DMZs, IDSes, authentication servers. Wrong answer. Securing the business isn't about point technologies or security architecture. It's not even about policy. It's about presenting security-relevant data in a business context. It's about cost-justifying decisions based on risk models, not unpredictable threats and arbitrary vulnerabilities. It's about framing the security message in a way that motivates the stakeholders who drive business strategy and sign security PO's.
In short, it's about security business intelligence (BI).
BI is the latest management catchphrase for next-generation data warehousing. Where data warehousing focuses on data integration, BI is concerned with data governance -- the practice of using integrated data to make strategic business decisions about expenditures, workflow and product quality.
To see how BI works in the enterprise, look no further than the CIO, to whom 70 percent of security managers report. For the CIO, BI is primarily about aligning all technology initiatives with business strategy. In fulfilling this role, the CIO's chief weapon is the ability to quantify decisions based on facts, not intuition.
Unfortunately, most security teams have a long way to go before they can productively contribute to corporate BI. The good news is that security has plenty of information: reams of firewall logs, IDS events and policy exceptions. The bad news is that none of it is organized or presented in a way that lends itself to business intelligence. Making matters worse, in the past most security decisions have been based on intuition: back-of-the-envelope estimates of what it will cost to protect the organization from a future risk based on a past incident.
Achieving security BI begins with the procedures you've heard a thousands times: assigning a value to information assets; obtaining timely information about relevant vulnerabilities; assessing threats given the target environment and the potential for exploit code; and responding appropriately should an attack occur.
One way to build security BI is to create a "criticality scorecard" prioritizing risks you need to address. The scorecard is where all your risk management work comes together. Each risk is rated according to threat severity and vulnerability relevance with respect to asset value, existing security defenses and applicable standards or regulations. You can build this type of scorecard through a relational database, or you can buy automation software from any number of security vendors (some vendors call it a "dashboard"). Either way, it takes a lot of elbow grease to produce the desired results.
By ranking each identified risk in relation to all the others -- let's say on a scale of 1 to 10 -- you can develop a workflow in which the IT team is addressing the most serious risks (those ranked 9 or 10) while ignoring or delaying the others (those ranked 1 or 2). The criticality scorecard should track the time and resources it takes to address high-priority risks.
The primary goal of the scorecard is to produce an executive report that illustrates how security is focused on the organization's most critical risks; how deficiencies in the time-to-patch for critical vulnerabilities can result in security breaches; and how the consequences of failing to devote adequate time and money to mission-critical risks leads to unnecessary exposure and reactionary spending. This is just the type of business intelligence your CIO needs to make fact-based security decisions.
About the author:
Andrew Briney, CISSP, is editorial director of the TechTarget Security Media Group, which includes Information Security, SearchSecurity.com and the Information Security Decisions conference.