royal guard standing watch in London
PHOTO: Shane Rounce

Anyone building solutions in the information space is aware of the concept of agile. Most also have learned about DevOps, the integration of the development and operations teams for an application. What is less well known is DevSecOps, the integration of the security team into the DevOps team.

Security, and other “non-functional” requirements, have long suffered in the development of new applications. Everyone focuses on what information the new applications will make available and leave security until the end. Security often becomes an added, and distinct, layer on top of the applications. This is a mistake. Security needs to be part of the MVP (minimum viable product) and a core part of every application and service you build.

Related Article: How Much Information Security Is Enough?

Baking in Security Is Easier From Day One

I recently spoke with someone who was having problems getting her application into production. She was adding audit for all activity at every service level. The team had decided to pass a token around that would contain all the information needed to validate authorization and provide key auditing information. While not ideal, it seemed workable.

There was one problem: The token kept getting lost.

The team was reexamining every service to ensure the token was captured and passed on to the next service. They kept coming across instances that were not capturing or passing-on the token. They thought of alternate approaches, but they were no less intrusive at this late stage in the project.

The problem wasn’t the requirement or the solution. The issue was the auditing requirement wasn’t explored until the end of their MVP's development. If the auditing requirement had been identified from the beginning, the token approach could have been readily incorporated as new components were created. They possibly might have even found an easier approach.

A similar situation also happens with user roles. A recent project only had one defined role. In my experience, additional roles will inevitably be added to a system later in its life. We decided to implement user roles to manage authorization for people. We knew it would be easier, and more secure, to create role-based access on day one. Sure enough, the client added the requirement for more roles. Because security wasn’t an afterthought, we were able to meet the new requirements though a configuration change.

Related Article: 4 InfoSec Trends for 2019

Security Needs to Get Involved

I’ve been on numerous projects where we were in the final testing stage, aka the last 5%, when security came in with their “standard” security scans. We then spent weeks determining which findings were valid and remedying concerns. The process ate time and delayed the release. Meanwhile, our customers sat, anxiously waiting, while we met the security team’s requirements. We couldn’t give the customer a hard date because the finish line was always shifting.

Security experts need to be involved from the beginning. They need to be part of the team so they can help everyone understand the risks involved and the steps other parts of the organization are taking to protect against those risks. This makes it possible to address all of the necessary security concerns as part of the core design. Additionally, it helps security experts understand the benefits the application is creating, allowing the team to strike a better balance between organizational and security needs.

An added benefit is it will also get developers thinking about security in everything they do. No longer will they react to security requirements at the end of the project, now they'll start asking the right questions on the first day. This is especially critical when new applications use new technical architectures that the security team’s scans don’t understand.

Related Article: Is There an ROI for Investing in Information Security?

An Insurance Policy for the Future

As application development evolves at an ever-increasing rate, so too grow the benefits. But the risks also grow if security isn’t part of the process. You need to focus on security from the beginning or you risk either security breaches or long delays as you finish the last 5% of the application. Even if — and this is a big “if” — security is merely 5% of the application, it is 5% that touches everything.

The last thing you need is news about a breach of privacy or having outsiders gain unfettered access to your application. These days, it could even lead to a fine for a GDPR violation. Use DevSecOps to include security from day one so the only news about your system is how it is improving productivity and bringing in new customers.