This is part three on looking at governance and compliance. Compliance is often, and sometimes justly, derided, but is there a way for its devilish cost and complexity to yield something of value for the enterprise>
In the first post, we looked at Charlie Munger's comments on governance. Specifically, how a seamless web of deserved trust beats the compliance check box Olympics.
Compliance is a drag, but on the other hand the regs are not there for no reason. In the second post in this series we looked at Chesterton's Fence and how compliance regs are a result of legitimate consumer concerns.
Whether they are too heavy handed or too prescriptive or not prescriptive enough or on target or relevant, well those are all valid questions. The reality is they are there and we need to deal with them on some level. The best approach that I have seen for security architects is to try to use compliance to your advantage and that's what we'll explore here.
The opportunity set for improving enterprise security is quite vast. Enterprise secuirty architects all have their favored tools and processes that they would like to roll out and deploy improved security capabilities. Whether its improving provisioning, SIEM, AppSec, Directories, data security, mobile, and so on - its not a short list.
So the list of wants on the sec arch side is long, but what's the blocking factor to fielding these capabilities? Mainly, its cost and timelines. And here is the opportunity of compliance. Compliance regimes come with built in authority, you have a hammer, some authority to get things done. The question is what?
Most of the time, you slide your index finger from left to right across the page of approved controls, and wait til the box says its checked. But there's a better way. As our guides on this journey, to reconcile these problems, we'll use the insight of Adam Shostack (because Threat Models) and Ron Swanson.
Ron Swanson was asked if he was bringing his personal woodshop up to the city government code, and he replied simply, "No, I'm bringing my workshop up to the Swanson code. And if the Swanson code happens to overlap with the city government code..."
Point being, there should be a larger goal in mind, pride in craftsmanship. What does this look like in software security? We need better stuff. Duh. We cannot have a zombie like following of compliance regs be the be all end all of our security practice. We need to find a way to better capabilities. One of the best ways I know is through building Threat Models finding ways thing fail and identifying mechanisms that cope with the threat. So let's dub this for security architects the Shostack Code.
I contributed a paper to Information Security Technical Report special issue edited by the insightful Andre Marien on matchmaking between compliance and security entitled "From auditor-centric to architecture-centric: SDLC for PCI DSS." The paper examined ways to improve security architecture by harnessing the executive attention that compliance activities like PCI DSS bring to security and focus that attention toward improving security architecture over the long term. Threat modeling fills a gap between the system’s functional requirements and the auditor’s checklist, and is used to catalyze this change of focus.
Let's take a concrete example. The output of a threat model like STRIDE is a set of threats and countermeasures. I add in the concept of the attack surface to locate where the most cost effective place to defend is.
| Section | Service | Threat | Data | Method | Channel |
| 8.1 | Authentication | Spoofing | SAML | SAML SP | Mutual authN TLS/SSL |
So if we start with a Threat Model that looks at mitigating Spoofing through authentication, with a variety of different protocols like SAML and mutually authenticated TLS/SSL, this is our expression of seurity architecture goals. Then when looking to deal with PCI or other regs, use those regs to amplify what security architecture goals you have to find the right place to invest scarce security resources. Better yet, you have a air chance of having compliance teams behind you to help give you the hammer to actually implement. Want evidence? Look no further than log management. I mean HP bought Arcsight for more than a billion. That's more than 95 times earnings. You don't pay 95 times earnings unless you see growth. Buy in from compliance to your initiatives means better prospect of buy in and deployment.
The order of execution matters. There are knock on effects here. Use them to your advantage. Develop your threat model first, then review the compliance regs. Hopefully you will find that the compliance regs will frequently overlap with the Shostack Code that your threat model defines.
In closing:
You can borrow from the Devil
You can borrow from a friend
But the Devil give you twenty
When your friend got only ten
-Robert Hunter
Comments