This is the third part in our ‘What the Sec is DevSecOps?’ series. 

You don’t need the wisdom of hindsight to appreciate how important security is and how disruptive breaches can be. But wouldn’t it be great to not have to revisit/rework a feature simply because security was overlooked?

As mentioned in a previous post, traditionally the instinct of a developer is to get coding as quickly as possible without security as a priority. In a DevSecOps world, the job is to both ensure that security is not slowing down the process, and also that it is integral to the product of each sprint.

Developers are awesome at coding to requirements, taking great pride in the efficiency and optimised nature of their code, even being measured by who is best at doing so in the shortest possible time. Unfortunately, if they are building to an inherently insecure design, or indeed don’t have any security requirements to measure against, then it doesn’t really matter how good your developers are, you’re leaving your application open to risk.

Before fingers hit keyboards, we need to ensure that we have the right security design principles in place so that we don’t assume that our developers just innately consider security in what they do.

What is Secure by design?

Secure by design is about first thinking not only of the feature, performance and great looking UI that you need to improve in your MVP on it next sprint, but how and who would benefit from misusing it, and what needs protecting. Above all, avoiding assumptions that the application will be used in a certain way. Balancing that all important consumer usability with a healthy dose of caution.

From our experience here are 6 considerations to get you started about thinking about securing your design.

6 considerations for secure by design

1. ‘Think Evil’

Underpinning our journey to DevSecOps is that fundamental mind shift to think not only of what’s expected, but what is unexpected. This is at the core of secure by design as it sets the rest of the sprint up for security success.

Some evil thoughts you should focus on include:

• What is of value? The data that this software is custodian of or the actions it performs. Think of the variety of adversarial types that would appreciate its value, any regulation you are to be governed by as this will help frame the extent of the risk and the extent of the control required.
• Where an attack would begin. No, not just the “know thy enemy” of which cybercrime syndicates, nation states or anarchists could be after us; but where is our software? How could someone gain access to lead them to what’s valuable? – i.e. the attack surface. Who should be able to access the system? How and for how long? How is data shared or transmitted?
• Any sequence of actions that lead to the pot of gold. Regardless of intent, think through ways that the features or workflow in this sprint’s backlog, added to what has been implemented already, could be misused, side stepped or made to work in a different way than you intended.
• The need for the feature. Is this new feature applicable to every user, does it need to be on by default and what would secure by default look like – so that users have to gain privilege to remove or bypass security measures.
• Consider the risk/reward calculation and the end result if you were in the attackers’ shoes and were successful. How hard would it be to make the attack? How hard would it be to cover your tracks, if you did?

2. Use frameworks to guide design-thinking

This all may seem a little like a practice of theory (especially if you haven’t experienced a breach before), or indeed may appear overwhelming when you have the business pushing hard to get the new feature to market.

However, done well and with some structure to the process, formalising these thoughts against existing secure design principles (such as OWASP) via a framework that suits your team will help you not only appreciate the requirements and prioritise them; it guides your team to be objective and realistic in what you can and can’t protect against.

Threat modelling is a proven technique to guide your secure by design thinking with frameworks and activities that include:

• Identification and scoring through STRIDE/DREAD
• Trike
• PnG and VAST (good for agile)
• OCTAVE (if you’re really up for it but perhaps not for DevSecOps)
• Attack trees (CI4AM)
• Abuse case modelling
• Trust boundary mapping
• Adversary profiling

Any approach you take would benefit from quantified evaluation. Each of these will take some practice, but as your pipeline efficiency and quality improves so will your ability to anticipate threat and counter risk with robust and resilient design.

3. Own it. Make it usable

It always used to be that a coding standard was a document left in a drawer and not revisited after a cursory glance on your first day of a new job. The key reasons being it wasn’t consumable, it wasn’t prioritised, agreed upon or owned by everyone, and it likely (as it is hard to do) didn’t fit each application teams’ “unique” circumstances or the pace they wished to move at.

Don’t let a secure design activity go the same way. A cursory attempt at thinking who may be bad out there won’t give you the benefits of this key activity in your pipeline. Whichever framework you choose or customise to fit, whichever means of eliciting and documenting security requirements you take, it must be relevant, accepted and championed by all. Like all other aspects of your pipeline, it should be tested and continuously improved to get the most out of it.

To achieve that outcome, your standard must be something that suits the dynamic of your team(s), your environment and velocity, the types of software you’re delivering, maybe even your industry (when it comes to specific threat vectors) and not be so rigid in structure that it can’t improve as you do.

4. Don’t reinvent the wheel, build a library

The temptation to design and build something yourself which has been done by others many times before should be resisted. Security through obscurity should not be relied upon, and thinking you can decrease risk through complicating and adding your own “sophisticated” architectures simply adds to the likelihood of errors.

If you’re coming up against a similar threat for a new feature that you’ve encountered previously in an earlier sprint, or have a number of disparate teams creating software with similar threats; then multiply the benefits of secure design by forming and referring to a library of approved secure blueprints. Rather than having each project team implement its own security features (e.g. authentication, role management, key management, logging, cryptography, protocols), developing a library of reusable code modules for the DevSecOps groups to use will add that efficiency, consistency, testability later down the pipeline and give confidence that you won’t have to track down the kinds of subtle errors that often creep into security features.

Using an established, trusted methodology, security features from the platforms you are developing on, or an open-source solution as part of your design means the wider community has your back. Even if vulnerabilities are found with the components you’re using, then there will be many more hands working on the fix, getting you to a patch faster.

5. Make sign-off work

This one could be a little controversial in the DevSecOps endeavour for automation; however, this is one of the elements that automated assessment and validation tools find hard to achieve. With Secure by Design being focused on the logic of a system and human decisions made on the prioritised likelihood and impact of exploitation, this particular activity is more human driven than almost all other phases that we will cover in the series. To be confident that you’ve considered what you need to before progressing and to ensure your coders set off on the right path, a manual sign off or risk acceptance is preferable.

Don’t be alarmed though; there are of course ways to automate the capture of that acceptance, the traceability of tests back to security requirements and to keep the review and sign-off process time bound so it doesn’t unnecessarily affect the efficiency of the pipeline.

6. Love Fail Fast

Through DevOps we learnt to fail fast and improve faster. This is definitely an area where experience counts. and relies on the appreciation and understanding of application security that your teams may have only recently been introduced to. Don’t shy away from getting started with secure design and security architecture reviews because of lack of experience; let the secure by design process improve and develop as you have done with your software creation process. Extending the principle of owning it and making it usable, your secure design principles, each teams’ secure design and your reusable security code modules needs to be a living and breathing artefact that is revisited, improved on each sprint and not a manual that you dust off to check every few months or years.

Final thoughts – When ‘D’oh!’ just doesn’t cut it

When major breaches that could have been avoided through careful planning occur, ‘D’oh!’ moments unfortunately just don’t cut it. Considering both sides early and often may be a change that doesn’t come easily; our human nature can lead to accepting a high risk for a higher reward, rationalising risks to be lower than they actually are, or looking for the instant gratification that “we’re now safe”. On the flipside, for some, it can lead to over-analysing, paralysing progress and velocity with little gain.

You can’t let everything grind to a halt by trying to think of every possible angle of attack against a system that you haven’t yet developed; however you can ensure that everything you add, as you add it, has security considered, has traceable requirements where possible, and reuses proven security architecture building blocks to avoid logic based flaws that even perfect code can’t prevent.

And you don’t have to go at it alone. Where it makes sense to bring expertise in, even if it’s just to get you started. Ensure that whatever the experts do, the knowledge is transferred, relevant and usable by your teams and most importantly, streamlined to keep pace.

These are the key considerations that we’ve put forward. Do you have any pearls of wisdom or stories that you would like to share? Follow us on LinkedIn and comment on the post.

You might be interested in:

Download: Secure by Design 6 key considerations

Download: DevSecOps Security Controls Infographic