Corporate security

Why Urgency & Budget Beats Security – 2015 Remix

It’s out! The all new Trustwave Security Pressures Report.

Last year 80% IT pros felt pressure to deliver insecure IT solutions. What’s changed?


Ohhh this one never gets old! This post was first published over a year ago when Trustwave reported last…. GREAT NEWS! That’s now down to…wait for it….77%!

There’s lots of other ‘interesting’ findings in the Trustwave Report (PDF). Here’s a great summary from Norsecorp. Having absorbed that it would be customary to tweak a re-released blog post to fit the new info. Absolutely no need. This is (sadly) just as relevant now as it was then.


It’s a is a long-standing cultural issue and dramatic false economy.  Jane Frankland highlighted it in a paper 10 years ago (one she is likely to update and re-release). At that time she quoted the 2001 IEEE estimate that bug-fixing after release costs up to 100 times more than fixing in-flight.

That figure needs to be viewed in proper context (WhiteHat Security’s Jeremiah Grossman notes bugs are not the same as vulnerabilities and challenges accuracy here), but it’s quoted so far and wide because it contains a huge dose of common sense we all identify with.

So why is this an almost universal problem?

egg-under-pressureIn my opinion, this issue has been so persistent and so pervasive, because associated risks are rarely (if ever) handed over to owners of post implementation services.

I don’t mean the IT bodies, I mean executive business owners, the ones in the financial, regulatory or operational firing line if the service fails, or unfixed problems lead to a security breach.

Most of this is relevant whether you are engaging suppliers and designing solutions for internal use, or putting together something to sell…except that question of risk ownership.  In the vendor world, the risk is largely handed off to the customer. I’ve picked that discussion up in a separate post:  “Are IT Vendors Being Paid To Fail?

Bugs, vulnerabilities and non-compliant controls are created or discovered at a specific point in time. Often out of sight of anyone in authority who cares. The PM, who naturally has his eye on the bonus prize, will also have constant pressure to deliver on time.

Can we pin all of this on PMs? No. It is about the relationship between security and the board.  How well change and procurement security risk is communicated and the openness of the board to listen. If those conversations are not working, bad behaviours, with no evidence of quick consequences, won’t stop.

What can you do about it?

Here’s my take on one way forward, while being mindful the business has to make money and risk assessments have to be realistically weighed against potential benefits: Critically, ensure your security assurance processes enable you to engage early (pre-initiation if possible) . The typical challenge is “We don’t have enough detail in the design yet”. Not a problem.

An early triage questionnaire for scope need only be a handful of very high level questions. The questions can be built in as a mandatory self-service project initiation activity (if you design it cleverly). If the procurement or project team don’t know if work will involve these kinds of things, then they should:

  • Confidential data
  • Credit cards
  • In scope SOx systems
  • New/existing Ecommerce Sites
  • Data handling offshore
  • Messing with high availability systems/processes
  • New suppliers
  • Significant changes to contracts with existing suppliers

Getting in early – key practical steps & aims;

  1. Getting formal buy-in from all interested parties before you start (risk, legal, IT management, business unit CIOs etc).  If work skyrockets or staff numbers get cut, having sign off for an agreed assessment scope opens the door to conversations about flexing resource and deliverables.
  2. Discarding things from scope that pose little or no risk as early as possible.
  3. Saving time spent on detailed triage, by only targeting entities linked to more inherent risk.
  4. Delivering relevant security requirements to projects and procurement teams, before plans take shape and budgets are spent e.g. for pen testing, SOx compliance, PCI DSS requirements, referral for supplier security due diligence.
  5. Pitching the overall assessment scope to balance available resource with inherent risk appetite.
  6. Enabling arm’s length oversight of moderately risky projects, by confirming control requirements and creating clear triggers for re-engagement. Triggers linked to a repeat of the high level triage, done at key project stages, to pick up new or increasing risks.

If stakeholders don’t feel comfortable with entities being put out of scope, assess on request. Make it clear what else has to be de-prioritised or de-scoped.  If stakeholders don’t want to flex existing scope or resource, cross-charge extra resource to the project sponsor requesting the work. When risks emerge, as they will, there needs to be a governance structure ready to deal with them.

With systemic issues like persistent late engagement by security (or lack of engagement with security by projects) changing things is likely to be an uphill struggle.  Things have probably become reactive and political.  However, there is a duly diligent way to claw things back despite ROI for security spend being extremely hard to prove:

Build consideration of outstanding risks into key project gating meetings and  procurement process steps. Then (as a final backstop), into go/no go decisions. Use the ultimate service owner/supplier relationship manager and the project team to predict operational fallout and risk SMEs to input the regulatory and reputational risk perspective. Take the output to the exec sponsor to get sign off.

However, that doesn’t guarantee things will get fixed. You sometimes have to revert to the very un-illustrious path of rock solid “I told you so”, by ensuring it goes on a risk register with regular review with that same sponsor.  Make sure potential impacts are kept up to date and made clear in plain English. At some point there will be a related incident which will focus some minds and may generate the sponsorship needed for a culture change.

Is all the effort worth it?

One natural effect is significantly improved security awareness. It isn’t pure osmosis. While rolling this out you must have visible executive sponsorship, a good communications plan and excellent awareness sessions for all senior and operational stakeholders. Early in the second cycle, calls begin to come in;

“I think you need to be involved with this project”

“Can you help with due diligence for this supplier?”

In other words, the security holy grail. Informed, proactive engagement while there is still time to make a difference.

At about the same stage, statistics from assessments accumulate to the point where trends and persistent hot spots can be identified. Some senior staff will be impatient (expectations have to be carefully managed), but the impact, when meaningful MI is delivered, can be game changing; visible dropping of shoulders, constructive questions about on-going operation, less fear and uncertainty, more collaboration and debate.

Assessment, remediation and risk management activity carries on in the background. Evidencing a month on month improvement in baseline security. This isn’t a pipe dream. I’ve seen it happen. Is there a better way…maybe, but while assurance teams are under the cosh, projects are ever more squeezed for time and money (not to mention the growing use of Agile methodologies) and folk are accumulating ever more suppliers, it’s a solid and cost-effective approach.

But it’s all a question of culture

If security doesn’t hold the right place in the minds of decision makers. If security folk are persistently seen as the grit in the business machine. If it’s a low margin, crowded, and poorly differentiated market where privacy and security are not natural additions to the value proposition…

…well I’ll let you draw your own conclusions. Conclusions that are only likely to be challenged by an event that focuses minds. Too late for customers, but perhaps the next breach induced security-go-round will land something that takes root.

Related articles:


The usual caveats apply. This is entirely my opinion and does not reflect any past or present employer or necessarily represent their opinions.

5 replies »

  1. I loved this post Sarah and am thrilled for the mention. I will definitely update my paper and you’ll be the first to know when that happens. I thoroughly agree with you about the Board. They need to be better informed and take more of an interest. And, the only this will happen is by communicating risk & cyber security not in technical terms, but in a language they understand i.e. business. Change begins in language.

    Like

    • Glad you liked it, planning more on this subject soon, but working on a vendor security governance piece first. If you had a specific aspect you wanted more on let me know (enquiries@infospectives.co.uk).

      17th October 2014
      As you can see from the update above, we now offer consultancy in this area. If you are still interested in knowing more we’d be happy to discuss any specific challenges you have.

      Like

Want to add to the discussion?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s