MAKE IT EASY ON THE DEVS

January 4th, 2019

Development teams are often at odds with the security teams, specifically pentesting teams. Below, we’re going to talk about why this happens and what you can do to help improve development participation in your organization.

CONFLICTING OBJECTIVES

At a macro view, the objectives of development and security align. Organizations need software and security to operate. At the micro level, each team has very different objectives that don’t align.

Development teams are measured on delivering functional code on time and on budget, yet development teams regularly struggle to meet release deadlines. There are various reasons as to why, some avoidable and some not. Common reasons include scope creep, scope underestimation, unforeseen roadblocks, and bad planning.

The application security team is at least partially measured on how many vulnerabilities they find. If they don’t find vulnerabilities, that means the development team did a good job, but the security team has a hard time justifying the value they provide. Security teams scrutinize applications deeply because their reputation depends on what they can find. More often than not, they succeed in doing their jobs. The vulnerabilities they find have to be fixed.

The application security testing (AST) process only increases the deadline pressure development teams are under. Fixing vulnerabilities takes time and delays code push. The outcome is a double whammy. The development team’s ability to deliver on time is put in jeopardy. The developers themselves feel as though their reputation has been tarnished if their code is found to have flaws.

It’s no wonder why development teams often chafe, drag their feet, or otherwise try to hinder the AST process. They submit to testing because it’s required, but they are generally not willing participants.

EVALUATING POSSIBLE SOLUTIONS

Rational arguments for security are well understood by development. Providing training and explanation to the developers does nothing to align the conflicting objectives and outcome of AST. Reasoning and rationale can only increase willingness so much.

Some organizations try to bake security into the SDLC. Time is allocated between the release date and the production target for security testing. As development projects slip, security is the first thing to be pushed out so the deadline can be met. Development teams would rather get all the features in and risk an unknown number of security flaws hoping none exist. This leads back to the conflicting objectives.

As discussed in our prior article, the shift left movement is a worthy pursuit. Automation built in during the SDLC to help catch problems early can reduce the findings during a pentest. There is a diminishing return though. More scanners will not eliminate all of the vulnerabilities found during a pentest. This does not solve the conflicting objectives.

GETTING BUY IN

The best security solutions are also the most convenient. Security is often viewed as a necessary evil by those burdened by the requirements. Convenience reducing the effort needed is the best way to improve buy-in and willingness.

This is where another part of Application Security Testing Orchestration (ASTO) comes in.

STEP 1

Scheduling testing should be as simple as possible. Ideally it should be possible to allow self-service for development teams to view, filter, and schedule testing slots based on security resource availability. This reduces the human effort needed to coordinate and schedule.

Dates often slip. Rescheduling pentesting last minute can cause a great deal of disruption to the security team. Having a backlog of tests scheduled already can be used to help buffer in this case. For the backlog to work, scoping information for scheduled tests must be ready well ahead of time.

STEP 2

Make the process of scoping security testing as seamless and convenient as possible. Your ASTO tool should track the application scope information ongoing. Annual tests should allow for development stakeholders to carry over prior information. Stakeholders should review and revise it prior to testing, but it’s much easier to revise than to write the entire form again.

Passing a word document back and forth with comments and track changes gets messy and is hard to manage. Scoping questionnaires should be collaborative web interfaces where security and development can participate. After development has submitted revised scoping information, security teams should review it quickly and verify it from a queue. If any errors or discrepancies are found, communication should be easy to follow and track. Comments and markup on the scoping form are an ideal way to enable the communication flow. The web form can be mapped into a database in a standardized way and used in automated processes, something a word document cannot do.

STEP 3

Vulnerabilities will be found during testing. Providing full context of how to fix the vulnerabilities with high quality remediation instructions can save the developers time. Avoid making the developers work to figure out how to fix the problem. This requires a remediation instructions library that’s vetted with good content. Sure, pentesters can write instructions as well, but the consistency and quality will come from a standard library.

STEP 4

Developers work in their own tools. Giving them a laundry list CSV of vulnerabilities or a static report is not going to make it easy for them. Don’t make them load the list into their tool or force them to track on a spreadsheet. This risks losing track of vulnerabilities and increasing their workload.

Integrate directly with the development SCRUM tool. Push vulnerabilities into their existing workflow with the included remediation instructions. This saves them time and effort and makes it easier to track when the issues have been fixed. Having a bidirectional sync with the SCRUM tool also makes it much easier to track remediation.

STEP 5

Retesting and verification that vulnerabilities have been fixed should be expedient and as automated as possible. Waiting to retest for weeks or months after a developer has fixed the problem will only increase the frustration the developers feel. Some scanners can automatically verify a vulnerability has been fixed, which can be triggered based on an ASTO process. Adding retest tasks to a queue for the security team and having an SLA on the task will also ensure that the security team is following up on the fix in a timely fashion.

CONCLUSION

While it may not be possible to entirely remove the conflict between security and development, it’s certainly possible to ease the inconvenience. Development teams understand the need for security. The experience is generally the problem. Improve the user experience for your developers, just like you would for any customer, and you will have a much easier time getting buy in for the AST process.

Close
612.465.8880 sales@netspi.com