Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Getting to DevSecOps: 5 best practices for integrating security into your DevOps

Greg Bledsoe Lead Technical Advisor , Unbounded Enterprise

As the cost of the insecurity of our applications and environments grows more and more obvious by the day, we're all getting nervous about one big question: Are we doing everything we should be to mitigate the risk? The answer for most of us is a resounding "no," and the fix is both simpler and more difficult than we would like to admit, for one very basic reason: Security cannot be bolted on as effectively as it can be baked in. But DevOps is the perfect place to begin fixing the problem.

You've already done a lot of hard work to integrate operations into your development process and vice versa, so this is the perfect place to weave security awareness and practice into your process from beginning to end.  

Here are five best practices to get started along the path to DevSecOps:

1. DevSecOps culture starts at the top

There must be organizational commitment all the way to the top to dedicate time, money, and other resources to cultivating security awareness in every action your team takes. That's not a difficult a case to make; just keep bringing out the headlines about high-profile security and data breaches and the associated costs in liability and brand damage. Everyone must be aware of the potentially catastrophic damage security breaches can inflict on the entire business. The pressure to get projects out on time can produce shortcuts even for organizations that normally do things right—and this is when security awareness at the highest level will pay off, giving you that extra day to think through security implications or allowing you to pause deployments for penetration testing. If short-term thinking dominates the cost/benefit, risk/reward analysis every single time, you are going to have a hard time not turning your products into Swiss cheese. The first and most important best practice is to get your executives on board.

2. Security awareness in development begins on Day One

The tenure of every developer and operations hire should start with security training that covers the basics of secure coding and the most common exploit vectors. Your presentation of this information as an organizational priority inculcates security mindfulness. Get your most senior developers trained and task them with producing training courses on secure coding practices and the most common security mistakes. Not only does this give them ownership of security for the juniors, but it also forces them to think through these issues, which is critically important, because those senior developers are your most important allies when you're in the grime and grit of daily commits, reviews, and deploys. Training should be revisited multiple times per year, increasing in complexity as your teams' sophistication on the subject grows. 

3. Keep your security processes clear and minimal, but forceful

The level and kinds of authentication that are adequate shouldn't be left to guesswork and on-the-spot decision making under the gun of a deadline. Work out with your teams exactly what minimal levels of encryption keys, ciphers, and password complexity are acceptable for your use cases, but don't go overboard with verbosity or trying to hit every possible corner case. Your people should know when they've hit a possible exception for which additional discussion is required—if you can't trust them to understand that, that calls your hiring process into question. You should have a WISP (written information security plan), a DIRP (data incident response plan), and any other procedural documents that are called for in your industry or regulatory regime, but the goal should be to keep them as simple and concise as possible—simple enough to keep all of it in your head all the time. When they're more than a couple of pages apiece on average, they become worse than useless—they become obstacles, for a reason that the next best practice explains. 

4. Keep it simple, stupid

Complexity is the enemy not only of security, but of reliability, predictability, and operational efficiency as well. Have one solution per problem. You don't need to be supporting, patching, and tuning five brands of databases when one will do. Cultivating deep expertise in the small list of tools and environments your teams specialize in brings economies of scale and efficiencies that are lost when you have to be a jack of all trades supporting multiple platforms, all to do the same things.  

5. You don't know anything until you test it

You may believe you can fly and have that delusion persist until the moment you jump off the roof.  And you might think the same about your code and not learn differently until you release it into the wild: Do penetration testing and code review! I personally prefer to do a rolling code review as a part of the deploy process as well as a periodic deeper dive, and to have inside staff do rolling pen testing, supplemented by occasionally paying outside firms to give us a go. To really motivate your staff, pay them a bonus per legitimate issue they find. Doing all of the above may seem over the top for your organization, but to achieve true DevSecOps, you have to be doing at least some subset.

When every business is a technology business

Because it has become clear that all business is now cyber-business and that no business is too small to be a target, not doing everything you can to bake security into your process could be viewed as negligence. Data breaches will have IT staff answering to executives, executives answering to the board, the board answering to shareholders, and the entire business answering to the consumer and the customer, both in court and in the market. We should be proactive about voicing the importance of security—and advocating for DevSecOps—before that happens so that we don't wind up after the fact answering for why we didn't.  

Hopefully, you find this list a helpful starting point. There are far more than five things to do along the way to getting from DevOps to DevSecOps so this cannot possibly be exhaustive. Please sound off and let me know what things you would have included that are more important than the five I settled on here.

Image credit: Flickr

Keep learning

Read more articles about: App Dev & TestingTesting