The Road to Creating More Secure Code and Interlocking two Traditionally Distinct Practices
As DevOps continues to expand across verticals, including the financial and government sectors, security has become paramount in the minds of CIOs and CTOs. As such, more organizations have begun to integrate security early in the development process. While security alwayshas been a theoretical part of DevOps, the number of breaches making headlines recently and costing many IT professionals their jobs has taught us that now it is more important than ever for companies to build security into each and every methodology and practice. “Build it in from the start” is a fitting mantra for any developer today―and even more so for his or her boss.
Creating more secure code for products and platforms starts from day one in the planning stages, and some industries are doing it better than others. You must include security―not just in the end product and late development stages, but also throughout the life cycle. Organizations can do this by employing a defined methodology and unified tools that support that methodology, so developers make security not only a consideration for their end product, but something fundamentally baked into their build.
To achieve this harmony between Development and InfoSec, developers and Operations staff must be included in decisions about tools, standards and methodologies that the organization will follow. They need to understand what requirements are coming down the road so they can recognize the need to address those requirements in advance, rather than than being caught off-guard by problems or issues after the fact.
Build a DevOps Toolset with Dev, InfoSec Buy-inIt’s important to recognize that the door swings both ways; InfoSec folks can’t simply give developers a laundry list. Developers must be able to communicate their needs when it comes to security, and also must take an active role in the security of their product.
Part of the importance of this two-way street is recognizing the benefit of having developers involved in security decisions from the beginning. When Dev stakeholders are given the opportunity to participate in the purchase decisions of security tools at the outset of a project, they gain insight not only into the importance of incorporating that tool into their build as well as an understanding of what the capabilities of that tool are. After all, the most expensive part of application security is having to start from scratch because of poor initial planning.
When it comes to tools and security, good security is not necessarily what you buy but what you build. A good place to invest is at the DevOps tool level, where developers can build a process and methodology that allows them to create secure code throughout the process. This is a crucial step that limits point-in-time testing after the product is built―which can lead to expensive re-engineering.
Teach Teams: A Bug Fix is not a Security RiskOne way to keep costs down and priorities straight when addressing security challenges is to keep security issues and bugs separate from each other. Bugs are bugs and we all want them fixed, but a flaw in a piece of software is not necessarily always a security risk and does not necessitate an immediate fix (despite what the stakeholders for that feature might tell you). Finding flaws certainly should be immediate, but the process of fixing those flaws should involve prioritization.
This does mean, however, that evaluating flaws in a very timely manner is important, and one of the first questions you ask yourself when addressing potential flaws or bugs in your software product should be, “Does this pose a security risk?” If the answer is yes, you can quickly pinpoint the source of that risk and address it. The good news is that by doing this, you can greatly reduce the potential of your product having security risks you either a) didn’t know about or b) didn’t think were actually security issues. The challenge is that this is a constant and ongoing process. Be sure though, the benefits are well worth the time you’ll invest.
Recognize Fixing Flaws is a High PriorityIt also can be difficult to balance the practice of fixing security flaws versus adding new features, particularly when developers are getting pressure from above to continue adding features and improving the end product.
Again, you need to look at risk. By weighing the benefit of features against the risk of flaws, you will be able to make smart decisions for prioritization. For just about every software product out there, security flaws should be addressed before new features.
It’s also worthwhile to consider the fact that bringing new features into a flawed environment is probably not a great idea. Not only does it mean you still have a fundamentally “broken” product, but that new feature may 1) not work as you expect or 2) increase the security risk further. If the second scenario is the case, now you not only have to fix the initial security flaw, but you also may have to reel that release back in―something you probably would rather avoid.
It’s also important to remember that good tracking, knowledge preservation and collaboration let you pinpoint issues, understand dependencies and determine the trade-offs faster.
Security is not an Option―It’s a MustIf you are looking for inspiration on how to better incorporate DevOps security best practices into your development process, look no further than government, financial and pharmaceutical industries. These industries face heavier regulations than just about anyone when it comes to security requirements, so they are continuously delivering secure software. Not only do they have to include security in their development process, they also must test that security and have defined educational requirements for their developers. In this end, all of this leads to some of the best and most sophisticated security practices in all of DevOps. If you want to gain good insight into how you can improve your security and see some of the latest advances in software development security trends, these are the industries you should pay attention to.
The surest way to provide a poor user experience and to compromise an organization’s success is to allow a security breach that could have been prevented with better foresight. That is why security best practices for DevOps (or rugged DevOps) are so important. By following the recommendations above and employing some of these tactics into your DevOps process, you can decrease risk for you and your company, and ultimately have more confidence in the success of your product.
About the Author / Ward Osborne
Ward Osborne serves as Information Security Officer at CollabNet and has more than 20 years of experience in Information Technology and Security Management. For the past 15 years he has focused on security integration and cloud security and has worked with dozens of companies of all sizes creating a culture of security and using security as an accelerator in business processes. Connect with him on LinkedIn and Twitter .