How Security Can Bridge the Chasm with Development

There's always been a troublesome rift between enterprise security teams and software developers. While the friction is understandable, it's also a shame, because the chasm between these teams makes it all the more challenging to build quality applications that are both great to use and safe.

Why is the strife between security teams and software developers so acute? Essentially, it's because both teams have, to a large degree, opposing goals. For security, it's about ensuring that apps are not easily exploitable and reasonably secure versus, on the development side, creating new applications and features for existing ones. There's no way to avoid the conflict between these two objectives, which reflect two very different and deep areas of expertise.

Another contributing factor is that today's enterprise technology has shifted from a focus on IT and infrastructure to being driven by software. And, frankly, security hasn't kept up with its out-of-date operations and infrastructure worldview, which has exacerbated the challenge.

The reality is that both software development and security are hard. The mindsets - breaker verses builder — are completely different. And we as security professionals need to take different approaches than we have in the past. Let's take a deeper look at these challenges, and then how security teams can help close the gap.

Be transparent. Connect with members of the development team and take time to understand their own processes and objectives. Walk in with an open mind and simply ask for their help. Engineers love solving problems. Be open to letting them help with the solutions to software security issues. This allows you to work with — and not against — development teams and enlist them as part of a solution, not condemn them as part of the problem.

Keep it simple. Developers are our customers, and our job is to help provide a service that makes their jobs easier. Apply this idea to everything. From helping to automate interactions between teams to what policies are really required to how results are delivered.

No more OWASP Top 10. Forget tackling the entire OWASP Top 10 — at least not all at once. Consider focusing on your own OWASP Top 2. Concentrate upon diligently eliminating certain classes of vulnerabilities in your organization over time. This eliminates creating a horribly long, seemingly insurmountable, list of items that are typically delivered to software engineering. A shorter, focused list enables the development team to easily slip into small sprints and fix errors. It's about quality, not quantity.

Deliver results development teams need. If your organization uses automated scanning tools to identify software flaws, then it is the security team's job to ensure that results delivered to the team are free of false positives and are high quality. This applies to anything from static to dynamic scanning or bug bounty programs. Filter and eliminate as much noise as possible.

Hire engineers. Talent is always a tough thing to find, but when it comes to hiring experienced security employees, it is even harder. It's almost impossible. So, instead look for talent in quality engineers, DevOps, and software development. It is 1,000% easier to teach security to this technical talent pool than to take a tools and operations security professional and teach them engineering. Security is a hot market, and I see a lot of interest from professionals in these groups to try to figure out how to move into cybersecurity.

Align goals. Keep in mind that most engineers want to write secure code and that they find security problems fascinating to solve. The challenge here isn't personal; it's often organizational and a lack of proper goal alignment. Too often there isn't enough time and energy allowed to be invested in solving security problems. This is driven by the organization and company goals and not the fault of developers. So, the single most effective thing a CISO can do to close this chasm is to create and pitch a higher initiative for the entire company to rally behind. Such a pitch can be as simple as a vision that Quality Software = Performance, Functionality, and Security.

Building secure software is much needed in the world today and will continue to be so tomorrow. We have traditionally focused our priorities on technologies that patch, watch, or block because this is easier. This reasoning needs to evolve and get in line with current (and future) security needs — and that means building secure software and automation. Security needs to be more engineering focused, come to a better understanding of secure development, and make it a priority.

Related Content:

Join Dark Reading LIVE for an intensive Security Pro Summit at Interop IT X and learn from the industry’s most knowledgeable IT security experts. Check out the agenda here.Register with Promo Code DR200 and save $200.