Craft Safer Software Using Secure by Design Principles

In my experience, the concept of 'Secure by Design' has repeatedly proven itself as not just a best practice, but a necessity. You want your applications to be built on a solid, secure, foundation. Security should be part of your company's DNA, not something you add on top of it.

Every week we're seeing more and more companies in the news due to cyber security incidents. Having a secure by design mindset doesn't guarantee you'll be safe from these threats, but it definitely reduces the chances of your attackers finding success.

Understanding the 'Secure by Design' Philosophy

The Importance of a Solid Start

'Secure by Design' is simply integrating security measures throughout the software development life cycle. This means that security is considered before the first line of code is even written, as well as every stage of development through the time it ships. Security shouldn't be a band-aid applied in the aftermath of development, but a guiding principle right from the start. An added benefit of this approach is that it makes security easier. You don't need to chase a moving target - build your security into your application from the start!

Strategies for Implementing 'Secure by Design'

Tip 1: Establish Security Champions

What is it?

Security champions act as liaisons between security teams and developers. They do not have to be security experts, but are people who are passionate about advocating for security best practices within their teams. Often times security champions are given additional resources / training to expand their knowledge and help spread it throughout the organization. We can also think of security champions as security evangelists.

Why it Works

Having a security champion program can significantly raise security awareness. The most important thing someone with a security-first mindset can do is ask questions. They may not have all the answers, but you'll never get an answer unless the question is asked. I've seen wildly successful security champion programs in companies with as few as 20 developers, and as many as thousands. To get a program started, you simply need to ask people if they're interested. From there, it's just a matter of supporting them and providing them with the resources they need.

Tip 2: Utilize Abuser Stories

What is it?

Abuser stories are a lot like the scrum user stories that you may be accustomed to, except that they are from the perspective of an attacker. Abuser stories help developers anticipate and mitigate potential threats by thinking like the attackers. This proactive approach can expose vulnerabilities before they become 0-days.

Why it Works

Incorporating abuser stories in sprint planning sessions often uncovers unexpected security considerations. This can change the way developers approach their problem-solving and feature development. This is also a helpful aide in driving a defensive programming initiative! An example might be as follows:

User Story

"As a user, I want to pay for my purchase with my credit card"

Abuser Story

"As an attacker, I want to intercept users' credit card information"

Well how does the abuser do that? Are they listening on the wire? Do we have HTTPS enabled? Are we logging the credit card information anywhere? Is it encrypted in transit and at rest?

You can see how this would spark the imagination of a talented developer, and get them thinking about security before any code is written. In addition, your product owners and product managers will start considering security as a priority when they are planning features and sprints.

Tip 3: Integrate Security into the SDLC

What is It?

The Software Development Lifecycle (SDLC) describes how a company develops software, and the discrete steps/stages that are part of that process. Security should be considered at each step of this process, from requirements gathering to design, implementation, testing, and deployment.

Why it Works

Security is a team sport. It is not only the job of security engineers, but everyone within an organization. When you identify areas where security controls or training may be appropriate, it exposes you to more members of the team and provides an opportunity to empower your colleagues to help fight the good fight. Pro tip: Don't leave out your customer support/success, sales and marketing teams either!

Tip 4: Implement CI/CD Security Gates

What is It?

Integrating security gates within continuous integration / deployment (CI/CD) pipelines helps ensure that each deployment meets essential security benchmarks, preventing unsecured code from making it into production. Bonus points if your teams are writing regression tests for patched vulnerabilities!

Why it Works?

If you've ever spent time as a developer, you probably know that sinking feeling when you break the build. Developers tend to do whatever it takes to get the green checkbox, and if that means making security improvements, they're usually pretty willing! There are a ton of tools available to help you automate this, both free/open-source as well as commercial.

Tip 5: Consider Privacy from the Start

What is It?

Integrating privacy and security simultaneously ensures compliance with laws and helps build trust with your customers. You want to establish a solid reputation for respecting user data. Everyone throughout the organization should be considering privacy.

Why it Works

Consider this: A person on the product team starts defining requirements for a new feature. That new feature makes it to developers, who then write code, test, and have it ready for deployment. Now comes the security team, and they say "Hey, we can't do that - it violates our users' privacy!"

That'd be a bad day for everyone involved, and a costly one at that. If privacy is considered at every part of the SDLC, this issue could have been uncovered before any serious work was put into the feature, and saved the company a lot of money.

Additional Tips for 'Secure by Design'

Automated Security Testing

Automate security testing to consistently check for vulnerabilities without slowing down the development process. Tools like static application security testing (SAST), source code analysis (SCA) and secret detection can all be integrated into your CI/CD pipeline for continuous feedback.

Regular Security Audits

Conducting periodic security audits helps maintain a clear, updated understanding of the security posture of applications, identifying weaknesses before they can be exploited. A bonus of having these security audits is exercising your remediation strategy - you can be confident that vulnerabilities are remediated within a reasonable amount of time.

Developer Security Training

Regular training sessions on the latest security threats and best practices empower developers to write secure code and recognize potential security issues from the start. In my experience, hands-on, practical sessions are beneficial for most developers. They've all heard of SQL injection by now, but do they know how to exploit a boolean based blind sqli? Maybe host a "capture the flag" (CTF) event with prizes for the top team/people! Not everyone is going to be as enthusiastic about this as others, but the people who participate will likely gain new security knowledge and thus, make your security posture even stronger.

Threat Modeling

Incorporating threat modeling sessions can help teams proactively understand and mitigate potential security threats specific to their projects. Empower teams to do quick threat modeling sessions on their own. There are some wonderful free and open-source tools available, such as OWASP Threat Dragon

Code Review and Pair Programming

This one may seem obvious, but don't allow anyone to push straight to production. Code reviews / pull requests are an essential part of a security program. While not every code review requires a security specialist, sometimes just having a second set of eyes is enough to catch a mistake that may have lead to a serious security issue.

Challenges in Adopting a 'Secure by Design' Mindset

Cultural Shifts Are Hard

Sometimes, people aren't interested in security. Other times, they can't stand all the perceived overhead. It's important for a security organization to have an "enabler" mindset, and use the same tools they are providing to others. This allows you to commiserate and share helpful tips. Being proactive in building relationships, and sometimes going the extra mile to explain the "why" can go a long way. Some strategies to consider:

• Make remediation a team effort: sit with them and see a patch through to the end.
• Be receptive to feedback: if a tool or process is adding friction, the team may have insight into how to make it better. You should listen.
• Be vulnerable: Talk about your mistakes, show you're a human too. People can feel attacked when they're told that they made a mistake. Own your mistakes, share them, and foster a culture where it's ok to make mistakes.
• Buy donuts: ....ok, not really security related, but if it's an option, bribery can sometimes work.

Conclusion

Embracing 'Secure by Design' is about more than following a set of guidelines; it's about making security a fundamental aspect of your organizational culture. There is no prescriptive list of all the things you must do to have a secure-by-design workflow. It's a gradual, continual, cultural shift that protects your projects and improves your overall credibility as an organization. If you take nothing else away from this article, please remember: security is not as a checkbox to be ticked but a cornerstone of software craftsmanship.

If you're looking for even more ways to adopt a secure by design culture, you should check out AppSec Assistant: the Jira Cloud plugin that fosters security by design by providing AI-based security recommendations on your Jira tickets with the click of a button!