Risk of Security Programs

Twenty years since Information Security emerged out of IT's shadow, how are most security programs built?

Not strategically.

Many, if not most, tech-dependent companies that you know of, and that you've worked for, including perhaps your current company, haven't carefully considered Why they have a security program. They just know that they have one. They staff and execute the program in the same manner that they consider and manage risk: without a vision.

Ready. Fire. Aim.

Typically, there has been no effort to agree on the Why. So the program proceeds, in a tactically sound but aimless manner, reflexively responding to the threat du jour. Without the rudder of carefully considering true risks to the business, the security program can't navigate its workload. Instead, it tries to address every risk, doing lots of things poorly, including deploying security point solutions partially, ineffectually. (Note: Indiscernible ROI for discernible security program cost results in negative internal PR that undermines the program's best intentions.)

...

Wait, hold on, you say. In the current hyper-awareness regarding data privacy, data security, software vulnerability, infrastructure vulnerability, threat actors, threat management, security awareness -- with the gory details of egregious and avoidable breaches at top of mind -- many if not most companies are still giving security and compliance the short shrift?

Sorry to disappoint. Yes.

It's why these real security incidents seem so ordinary, so banal.

• an embarrassing exploit of a known vulnerability leads to a web site compromise that exposes customers' personally identifiable information, which surfaces on a paste site
• a faulty configuration on an application database exposes highly sensitive customer data, resulting in a class action lawsuit
• an unpatched WordPress site in the production environment provides a front door into the hosted application environment, which is replicated elsewhere, resulting in take-down notices, reputation damage, lost market share
• a lack of server patching rigor, a weak privileged admin account password, or poor management of encryption keys results in an extended service outage while ransomware terms are resisted, then complied with

Equally disappointing, what often passes for a compliance program is merely the ability to check the box on an immediate, pressing business request:

• responding to external interrogations regarding logical access and data security in the present with stats about service availability in the past
• performing due diligence on an acquisition target based on anecdotal information
• providing assurances about the existence of security policies and processes, without providing validation of their effectiveness
• updating the publication date on the disaster recovery plan

The compliance work proceeds piecemeal, without a roadmap for reducing overall risk through development of reliable, reasonable controls that are automated, and monitored, and based on agreed-upon best practices.

Many if not most security programs are an ongoing cautionary tale: Perpetually avoiding the need to carefully quantify, qualify, and categorize their risk, they proceed blindly, incapable of aligning their visionless security and compliance program with the company's current and future strategic goals and objectives. Perpetually on the defensive, doomed to rationalizing their existence, unable to position their program positively.

No wonder so many skilled security and compliance program architects, engineers, analysts, admins, and project managers end up feeling like they've worn out their welcome and move on after two years (full disclosure: that assertion based on my informal poll at a range of technology conferences, BSides to RSA to CIS to Blackhat, and networking events in-between,)

...

We can't expect to build successful security and compliance programs like it's 20 years ago, circa Y2K, behind a curtain of smug technical expertise, without transparency or accountability. Approaching year 2020, a successful security and compliance program has to be a horizontal, syndicated endeavor -- something that enlists broad support, continuously informs in non-technical language, and works across the organization to execute on behalf of the business, not just on behalf of the security program.

Here is an unavoidable fact we can be absolutely certain about. Until and unless the hard strategic work of assessing and prioritize security risks is undertaken, reasonable expectations cannot be established. Your security and compliance program shall not thrive when:

• The program has an incomplete picture of the comprehensive risk landscape
• The program can't confidently communicate to leadership what can be done reasonably, over time
• The program hasn't earned and doesn't deserve the budget, resources, and support needed to accomplish its half-baked risk management efforts

Risk doesn't self-assess. It has to be researched, identified, and portrayed in realistic terms of impact, cost, likelihood. Otherwise, the human tendency to accept vaguely perceived risks will prevail, and the organization will gravitate to the comfort of Security in Numbers (i.e., any negative security event will probably happen to somebody else, not me).

...

Now the positive ending to this discomforting diatribe.

Successful security and compliance programs are their own relentless risk management advocates. They accept that product marketing is focused on competitive features and positioning, sales is obsessed with meeting end-of-quarter sales goals, finance is thinking about quarterly reporting, IT is all about sustainable operations, and product development is committed to continuous integration and release cycles.

So they become the champions of the security of the product, the confidentiality-availability-integrity of the data, the resilience of the network, the effectiveness of the controls. They communicate these qualities as assets, as competitive advantages, as revenue-generating differentiators. They leverage their overall compliance posture to help close deals. They streamline and harden the development life cycle so that development staff is focused on features in the next release, not bug fixes in the previous.

Another characteristic of a security and compliance program that has its house in order: staff isn't looking to jump ship to a program with an articulated, demonstrated strategic vision.