Let the Security Facts Speak for Themselves

The other day I challenged someone who made an untrue claim in front of a group of people. It wasn't the first time the claim had been made, though no one had spoken up. I had just walked past Emile Zola St. – named after the renowned 19th century French journalist – in my neighborhood, so the importance of truth and facts was at the forefront in my mind.

If given the chance, the truth can stand up to an intense interrogation. Facts will not crumble under an inquiry. What security lesson can we learn from this? When a security program is built on a sound strategy, solid data, and real facts, it can withstand questioning.

I’d like to share five ways in which sticking to the facts is good for an organization’s security posture:

Risks: A security team needs to be aware of its organization’s exposure to different risks, particularly those that have the potential to cause financial loss. These risks must be clearly articulated to business stakeholders and leadership. When doing so, it’s best to stick to the facts. While it may be tempting to embellish, play up certain risks, or provide worst-case scenarios, doing so without a firm understanding of those risks or objective data supporting any claims is a dangerous game. All it takes is one misstatement, disproved claim, and/or unsupported assertion to cause the business and leadership to lose confidence in the security team. The last thing you want to hear are statements like, “Oh, security is claiming that?” or “Question everything they tell you.”

Goals: A good security team is driven by strategic goals that are broken down into operational and tactical objectives. If the security team has done a good job understanding, enumerating, and prioritizing risks, its goals will help the organization objectively work toward addressing and mitigating them. If all of that work is based on real data and hard facts, the security team will be able to address any concerns, adjust course as required based on any reasonable objections, and gain stakeholder buy-in.

Policies: The purpose of security policies should be to act in tandem with other controls to mitigate risk. In some instances, security policies may be difficult for a business to understand and see value in. In other cases, they may require the business to change the way it works in order to comply. As a result, it is important that policies are based on logic and demonstrate a measurable reduction in risk or improvement in security posture.

Processes: Ideally, processes are designed to ensure that policy is adhered to, that roles and responsibilities are clearly identified, and that workflow proceeds in an efficient and effective manner. Processes should be well-designed, well-defined, and justified by objective data and sound logic. When they are, it’s easier to make the case and enforce that they should be followed, even if it isn’t quite clear to different stakeholders why the processes are necessary. When processes aren’t built on a strong foundation of truth, it is all too easy for people to find ways around them and justify doing so.

Metrics: Metrics are near and dear to my heart. They are also a topic that, in general, is not well understood or well-executed in the security profession. In addition to all of the other benefits described above, having a factual understanding of risks, goals, policies, and processes provides a security team with reliable, measurable data. This data, of course, is the cornerstone of high-quality, meaningful, impactful security metrics. Building and reporting metrics on anything other than solid data make those metrics unreliable. That, in turn, makes it both difficult for a security team to measure the value it is providing and for leadership and other stakeholders to see that value and trust in it.

It is too easy to stray from the truth. Although it requires a bit more effort, basing your security program around hard data and objective facts pays huge dividends in the long run. Just ask any security professional who has witnessed someone getting called out on a fabricated or falsified claim. It isn't pretty, and it does tremendous harm to the security team and its efforts to protect the enterprise.