Web Application Security

The Necessity of Compliance Alone Is Insufficient for Justifying Security Investment

It is often much easier to justify investing security resources that are legally or contractually mandated than basing such investments on the overall value to the company of an adequately funded information risk management group. Given this disparity of  funding “must do” tasks while overlooking “should do” tasks, security teams can take the initiative and do the “non-essential” actions that strengthen their organizations’ security as they meet compliance requirements. This approach  also provides a security group the information it needs to justify requests for risk management resources.

The compliance standards currently applicable to application security include PCI-DSS, HIPAA, FFIEC, GLBA, ISO 27001/27002, and Sarbanes Oxley. A organization’s failure to comply to their standards can lead to fines, legal action, and sometimes even business shutdown. When executive management is faced with these possibilities, a typical conversation with the company’s security staff usually results in the conclusion that,  “The company must spend $A on X compliance mandate because non-compliance with regulation X carries an estimated cost of $B.”

As obvious as it may seem that compliance requirements should convince management to allocate funds for security, the necessity for compliance is often insufficient to get management to actually make the needed investments.

Government and/or industry-mandated regulations can frequently differ in how they impact an organization,  and typically can be applied differently to each organization. Some organizations may be able to change specific aspects of how they do business, and thus meet mandated requirements by changing the parameters of compliance. Other organizations,  after estimating that the punishment for non-compliance will cost less than the costs necessary to comply, may decide to simply ignore the notification to comply.

At WhiteHat we think a more realistic way to look at compliance issues is that in some instances you MIGHT get hacked, but for ignoring certain regulations you WILL get audited. In either case it is essential to understand the “historical record” of how a particular compliance standard has been applied within an industry; and to then be able to estimate the capital and operational expenditures required for your organization to comply. This way, when management asks you to justify your request for funding based on how NOT DOING SO would impact business, you’ll have the information immediately at hand, which will make the decision-making process far easier.


Tags: security
  • http://twitter.com/itinsecurity Anders Reed-Mohn

    Somehow, I’m left with the feeling that this is all a bit backwards.

    Personally, I am trying to move away from (primarily) compliance driven security measures, and my impression is that so do most other security professionals I meet these days.

    You make the case for “strengthening security as you meet compliance requirements”, however it’s quite clear that even the most standards compliant organizations are far from immune to serious breaches.

    Compliance is meaningless if it’s just a layer of make-up, and common controls to verify compliance are often not able to go beyond scratching the surface via measuring some KPI or similar. Instead, if you treat compliance (like security) as an emergent property, a state your org. goes into when you’ve done your job properly, then you might actually have security and compliance for real.

    In other words, if you’ve done the ground work well, compliance will follow.

    If you’re just playing along with the “men in ties” at the C-level, exploiting their fear of non-compliance to get some security measures in place, all you will end up with is that layer of make-up, and the first rainfall is going to expose you.

    At least, that’s my approach to it 🙂

    • http://www.whitehatsec.com/ Jeremiah Grossman

      @Anders: Thanks for the comment. You’ll be hard pressed to get me to defend compliance standards. 🙂 I’ve also seen what it eventually lead to. The nature of the post was intended for those without any other options, compliance-driven dollars or none at all, some guidance on how to better do their homework. Personally, I like data. Compliance frameworks should include the necessity of sharing incident data where the numbers can be compiled and aggregated. That way we might be able to prove what new controls are necessary and perhaps which ones really are not.

      • http://datadevastation.com joshua marpet

        Well said, Jer. This will at least get the ball rolling for brand new security pegs. And kudos on explaining why you wrote the post the way you did.

        As always, Jer, you’re an honest guy. 🙂

        Don’t change.


  • http://twitter.com/itinsecurity Anders Reed-Mohn

    ” Compliance frameworks should include the necessity of sharing incident data where the numbers can be compiled and aggregated.”

    Amen to that!

  • AviD

    Very true, and this brings to mind my own eponymous rule…

    AviD’s Law of Regulatory Compliance states: “Compliance reduces the risk of the penalties of non-compliance”.

    See http://security.stackexchange.com/q/622/33#631 for the origin…

  • Pingback: Battling Goliath: An Analysis of the National Privacy Principles (Part II: Principles Five to Nine) | Tech Law Forum @ NALSAR()