The Digital Security Poverty Line

Like many information security practitioners, this week marks the return to the office and reflection after attending the annual RSA Conference in San Francisco. Every year there are interesting speakers, some better than others, crazy parties, and a vendor show the size of a small city. And every year I admit I get a little contemplative at the end of the week and try to reflect a little more on our industry.

This year there was a phrase that I heard that got me thinking, the phrase described the challenges of the “Digital Security Poverty Line.” So it got me thinking, is this a real thing? Is this hype or when we look at organizations today are there really haves and have nots in the world of information assurance?

I think one of the first discussion points has to be a monetary one. Do larger organizations have larger budgets when it comes to information assurance? I think the knee-jerk reaction most of us would have to this is yes. But a better question might be – do larger organizations have a larger percentage of their budget allocated to information assurance? According to a study performed by BAE Systems Applied Intelligence and the Gartner Group there is a wide range of spending that organizations allocate to information assurance. According to their October 2013 study ( the majority of organizations allocate between 3-10% of their IT budgets towards information assurance efforts. 


But this still begs the question – does that mean if your organization allocates lower than 3% of its IT budget on information assurance, does that mean your organization is in poverty?

For this statement to be true, there would have to be a set of organizations under-allocating resources – which likely is true. But also the industry would have to be lacking in low cost quality tools that could be used to secure information systems. So is that true?

This is where I think the phrase starts to break down. Yes, in my opinion, there are and there always have been low cost tools available to small, midsized, or “poverty stricken” information assurance departments that could be used to secure information assets. While certainly it would be nice if everyone could afford a tool like Tenable’s Security Center, Tenable has always been gracious enough to provide tools like stand-alone Nessus if your organization did not have the funds for the larger solution. And of course this does not even take into account the abundance of free or open source (FOSS) tools that companies could employ – OpenVAS anyone?

I can certainly understand the vendors point about the appearance of a poverty line. And more importantly I think it’s quite generous for companies such as Qualys and Tripwire (nCircle) to release tools for small businesses to help them alleviate the stress. For those of you would did not notice, both of these vendors released free tools at the RSA Conference to help SMBs to secure their information systems based on the recommendations from the Critical Security Controls project.

So free or low cost tools are available to organizations. So if there is a poverty line, then it would have to be related to the personnel resources that an organization allocates to the issue. In the long term automation will help to remove this as a consideration, but as organizations initiate their assurance programs, it will take people to kick things off and create a strategy for organizations. Certainly that’s hard to argue against.

So, is the idea of a digital poverty line real? That’s hard to say. It could be the emergence of a new trendy marketing word. Or on the other hand if one does exist today I would argue that is has to do with the allocation of personnel and not the allocation of capital budgets. So what’s the moral of the story? If a digital security poverty line exists, it is because of their personnel. So if I was an organization today reading about data breaches and theft of intellectual property I would make sure I’m investing in the people that keep my data secure. Am I giving them the training and mentoring necessary to make good decisions for the organization or am I simply throwing my capital after more products. Maybe it’s time we all followed after groups like the State of Colorado and spend fewer resources on software licenses and fancy appliances and more on investing in the people that watch over our organization’s data every day.

Critical Security Controls Maturity Model

One of the projects that we have been thoroughly engaged on at has been to work with the Council on Cybersecurity on the Critical Security Controls project. If you haven’t had a chance to see the project, I would strongly recommend that you take a look. The full text can be most easily found at the SANS Institute at the following link:

One question I get asked a lot is regarding maturity models and the Critical Security Controls. Is there a maturity model that I can use to measure myself against to see how I compare to other organizations implementing the controls? At this point the official answer from the Council is “No, there is no official model.” However that being said, there’s also quite a bit of discussion around what might constitute a solid maturity model.

To answer this question I think the first thing we need to understand is that the controls are not just a list of good things to do. They also compose a mentality and philosophy for securing information systems. Therefore to understand a potential maturity model, we have to understand the guiding principles that the controls teach. The core philosophies of the controls are:

Offense informs defense: Use knowledge of actual attacks that have compromised systems to provide the foundation to build effective, practical defenses. Include only those controls that can be shown to stop known real-world attacks.

“Prioritization: Invest first in controls that will provide the greatest risk reduction and protection against the most dangerous threat actors, and that can be feasibly implemented in your computing environment.

“Metrics: Establish common metrics to provide a shared language for executives, IT specialists, auditors, and security officials to measure the effectiveness of security measures within an organization so that required adjustments can be identified and implemented quickly.

“Continuous monitoring: Carry out continuous monitoring to test and validate the effectiveness of current security measures.

“Automation: Automate defenses so that organizations can achieve reliable, scalable, and continuous measurements of their adherence to the controls and related metrics.”

That being said, it seems like a good maturity model would need to be composed of more than just “What percentage of the controls have you implemented.” So in anticipation of the various summits held on the controls this year in London and Washington, DC, we created the following maturity model for organizations looking to measure themselves:

Level #0:              Project Initiation

Level #1:              Some Controls Implemented & Audited

Level #2:              All Controls Implemented & Audited

Level #3:              All Controls Automated

Level #4:              All Controls Reporting to Management

Level #5:              Continuous Monitoring & Remediation

This is meant to be a high level statement, not a deep dive or project plan. But I think it could be the start of an interesting discussion. Companies need to do more than simply check boxes that they’ve implemented the right controls. Those controls need to be integrated into business processes, automated, and placed in the hands of knowledgeable business owners. Hopefully this model encourages us to start considering each of these aspects as we judge our maturity.

Steps to Creating a New Metrics Program

Metrics definitely seem to be a buzz word in information security circles these days. It seems that I can hardly give a presentation or meet with clients without the topic coming up at some point in our discussion. But to be fair, I think these discussions are healthy and I’m glad to see so many people beginning to ask the question, “how can I measure my efforts in securing my organization’s data?”

My fear though, is that there are a number of organizations who see other organizations implementing metrics and they believe that they can skip the core foundational program steps and jump right to interesting dashboards and metrics. It’s like watching someone who never exercises observing a marathon runner and saying, “I think I’d like to run a sub-four hour marathon too this year.” Without establishing a base and putting in the effort to practice, achieving great results can be difficult to impossible.

So this begs the question, in terms of information security, how would you build a base, and what steps could you take to lay the foundation for a solid, mature information security program. After working with our clients for the past 10-15 years, this would be our advice:

  1. Obtain a security management charter from senior management
  2. Create an organization wide IS Steering Committee
  3. Document your organization’s overall security goals
  4. Create & approve appropriate security policies, procedures, & standards
  5. Educate your organization on those documents

Then what? If we finish those steps, then can we start a metrics program? Absolutely! Once you have a proper foundation and you know what your organization is trying to achieve, then I think it’s a perfect time to kick off a program to develop metrics in your organization. But take it one step at a time. Don’t try to bite off too much too quickly. Take it slow, achieve results, and then progressively add to the sensors and data you collect.

  1. Here are the steps we would take to start your initial metrics program:
  2. Identify what information security sensors you have already successfully deployed
  3. Determine what meaningful metrics can be gleaned from these sensors
  4. Deploy a tool that can centrally aggregate, normalize, and report on the data collected by the sensors
  5. Create basic reports based on the metrics from strep #2
  6. Work with business owners to remediate risk

Our best advice though is this: achieve value from a small number of metrics first, and then grow your program. If you can’t achieve value from a small number of measurements, you certainly won’t achieve value with a greater volume. Eat that elephant one bite at a time.