Developers and Security can work together
I recently gave a talk on securing DevOps. I thought this makes for an interesting blog topic. The intent of this talk was to start the dialogue between development and security teams. I also wanted to provide an overview of what DevOps is. Lastly, I wanted to provide some take away information that could be used immediately.
Traditionally, security is seen by development as an impediment. Security is seen as enforcers, or blockers. How many times has a developer been ready to go to production, only to be shut down at the 11th hour due to a security concern? On the flip side, development is seen as this mysterious group who produces new products (security risks) from thin air. These groups often have competing interests. Development is looking to move their code into production. Security is looking to protect production. We should strive to change this.
DevOps came along as a philosophy to help the development and operations teams work closer together. The ultimate goal being to reduce work and reduce overhead. We saw tools such as Chef, Puppet, and Jenkins come into our lives. Ultimately, the goal was to get code to production faster. There’s one problem with this. Without security, DevOps merely introduces vulnerabilities into production faster. For security to work, just like software testing, it must be a part of the development and deployment process.
From the development side, think about what would happen if you waited until development was complete before doing any testing? Essentially, that is where we are today with security. The goal should be to shift security left in the Software Development Life Cycle. Security should be at the table during the design phase. Security should not have to tell a developer that they can not move to production due to a security concern. This conversation should happen early in the SDLC. The goal in securing DevOps is to enable the delivery of secure software at the speed of DevOps.
How do we get there?
SecDevOps will not be a one size fits all approach. There will be multiple tools, including manual testing involved. It is not a strategy driven by perfection or compliance. There is no magic bullet.
As a developer, the goal is to form a partnership with your Security teams. This creates an avenue for open discussion. Ultimately, enhancing the feedback loop (right information, right time). Through this partnership you will gain a better understanding of how vulnerabilities impact your applications.
How do we get there? Simply put: People, Process, and Technology. Security is everyone’s responsibility. It goes beyond the developers. It goes beyond the security team. Even the users of your applications need to be aware. Developers need to understand the tools available. NIST provides an outstanding resource list of Source Code Security Analyzers. Developers also must understand the vulnerabilities described in the OWASP Top 10. Security must be engaged early and often during the SDLC. The result will be a better mutual understanding. In the end, the success of the business is everyone’s goal.
Starting today, developers can take small steps to make their code more secure. Become familiar with the OWASP Top 10. Become familiar with the defensive coding strategies to protect against these vulnerabilities. Think like an attacker. For every user story, consider creating an abuser story. How could a user misuse this feature? When creating your unit tests, consider creating security unit tests as well. Consider using a tool such as the Microsoft Threat Modeling Tool during the design phase. Don’t try to boil the ocean. Target the low hanging fruit and your code will be more secure starting today.