Three Techniques For Squeezing Security Enhancements Into Products
It’s often difficult to get security enhancements into products as they’re being built, it is challenging to prioritise hardening and security improvements against the never ending train of feature demands.
I think part of this stems from friction between developers and security practitioners. I think that the root of this friction likely comes from a misalignment of objectives between the security and development functions within an organisation. This has created a really painful situation for a lot of development and security teams alike. Sometimes this manifests in teams that “don’t have time” to work on security.
My approach to solving this problem has changed over the years. I used to think it was enough to articulate the risk to the organisation and communicate this “up the chain”. Over time I realised that while I saw the world only in terms of security assurance, the program managers, developers and product owners all had priorities that in their mind were the most important. It’s rare for an offering manager to be measured on something as intangible as security, it’s far easier (and more common) to measure them on features delivered.
The central theme to all three of my tips below is understanding what peoples’ objectives are, how to communicate effectively with them and how to provide systems that make it easier for them to deliver secure versions of those objectives.
Security as a feature
Most of the time, something we build to make our offerings more secure would also be a desirable feature for our customers.
Where possible find a way to make a security improvement into a feature that shows direct benefit to the customer or ecosystem that you are working on. Customer facing enhancements very often get higher priority on the project managers roadmap, as they are what the project manager is judged by.
Security architects need to work closely with the program management groups in their organisations. They need to be part of the planning process and attend the meetings etc. When priorities are hard to quantify, security architects should look to the security outputs described later in this post — namely, can regulatory compliance be leveraged to push a security feature further up the stack ?
Secure the path of least resistance
Developers are busy, this means that often when faced with something mundane they will find the easiest way to tick it off the list and move on. This can lead to big security issues down the line.
Let’s take certificate management as a prescient example: I’ve never worked somewhere where either self signed certificates or expired certificates didn’t cause some sort of painful outage or security incident at some point. To address that at HP we built a system called Anchor and introduced client tooling that made it easy to get a certificate that was recognised and valid for the environment you are working in.
We built tools that made it easier to obtain a valid certificate than using google to find out how to cut a self signed one using OpenSSL.
There are so many areas of low hanging fruit where we can secure the path of least resistance, there’s still a lot to be done around secrets management at the infrastructure layer, tools like HashiCorp Vault are helping but we still need to build wrappers or automation to make using these tools easier than say, storing keys in Github… Find that low hanging fruit, solve it with automation and tooling.
Leverage “compliance”
I’m not a fan of the disconnect that many companies have between their “compliance team” and their “security team”. I understand that in some situations there are good reasons to keep these teams decoupled but that does not mean that they should not be cohesive in their objectives or collaborate to create better outcomes for the business. Security teams should be building the technologies and processes that make life easier for developers, align with compliance controls and generate robust audit streams for the compliance team to review, evaluate and document.
Your organisation probably needs various regulatory compliance certifications for its products/services. They’re useful for demonstrating to customers that you can do the security basics and they’re also a good litmus for comparing similar offerings.
You’re going to need this to meet compliance requirements X,Y,Z and Z requires a 6 month evidence window — instead of doing that manually let's figure out how to roll it into a feature that adds value now and gets you compliance for free in six months…
Good security should have outcomes beyond “we didn’t get hacked”. Pay attention to your compliance roadmap when considering features you can build into your roadmap or automation that can ease security pain for developers. What artefacts should this feature emit, what evidence does my automation need to generate, what other things can we do that will make compliance easier for everyone in the long run?
I’ve found that the spectre of regulatory compliance can be a fantastic way to engage with project managers. Compliance certifications are concrete deliverables that are often driven by sales requirements. A savvy security architect will find ways to meet these compliance requirements; by deploying technical security controls that benefit the wider product.
We probably all know that Compliance != Security, what I’m suggesting is that you can leverage Compliance to ratchet up security while making everyone (Developers, Security, Project Managers, Sales, Customers) a bit happier about the product.
