[BreachExchange] How to Solve the Developer vs. Cybersecurity Team Battle

Audrey McNeil audrey at riskbasedsecurity.com
Tue Jul 10 19:01:53 EDT 2018


https://threatpost.com/how-to-solve-the-developer-vs-
cybersecurity-team-battle/133759/

There is an ongoing tension between developers and security teams in many
organizations.

On one hand, developers face mounting pressure to build rich,
feature-driven applications on nearly impossible timelines to remain
competitive. On the other hand, security teams face rising pressures of
their own that come from an increasingly dangerous cybersecurity threats
and growing demands from consumers that organizations properly safeguard
their data.

Without proper planning, these two demands can come into conflict as each
team focuses on meeting its own goals. Development teams see security teams
as bottlenecks, slowing down each new release. Meanwhile security teams
resent the extra (and unplanned) work responding to vulnerabilities created
by developers who cut corners on secure coding in order to meet deadlines.

However, with a little groundwork, organizations can set these teams up to
work together and to help each other. The earlier a vulnerability is found
in the development process, the easier, faster, and less expensive it is to
fix; therefore, organizations need to find ways to move the focus on
security earlier in the development process. That means that they should
work with developers to make sure security is not an afterthought.

The first step is to help the organization recognize the part security
needs to play in the development process. This will allow product and
business leaders to establish that security is an important part of
applications they develop and must be considered by everyone involved in
the process. These leaders must emphasize that security is a subset of
quality, just like resilience, scalability, maintainability, uptime, and so
on. It’s just that for most developers, security is simply uncharted
territory. It just has not been part of their jobs or training before now.

One of the easiest and most effective ways to communicate that security is
a priority for an organization is to begin offering training on how to
write secure code. By educating developers on basic techniques, they can
take a little more personal ownership. No developer wants to write insecure
code. They just need to understand how and why security issues arise and
have access to helpful tools and resources to produce software that meets
secure coding standards.

The next step — the one with biggest and most scalable impact — is to bring
the security and development teams into closer contact with each other.
This may already be happening as organizations adopt DevOps or DevSecOps
methodologies. Each team needs to not only work closely together, but also
have a much deeper understanding of the others’ pains, processes and
priorities.

One of the most effective ways to do this is to designate a Security
Champion on the development team.

A Security Champion is a member of the developer team who understands
application security best practices and helps advise their colleagues. They
are trained by the security team to help developers find and fix
vulnerabilities as early as possible in the development process, ultimately
reducing the burden on the security team. This will not only help
developers write more secure code, it will reduce the amount of unplanned
work from vulnerabilities discovered late in the process. The ongoing
interactions between the teams will also build trust and promote goodwill.

It is understandable why security and development teams are so often at
odds given the apparent incompatibility of their roles. But, with a little
careful thought and open communication, organizations can bring them
together so that they better understand what the other needs. That way,
instead of fighting, they can help each other to build better software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180710/429259c1/attachment.html>


More information about the BreachExchange mailing list