Can you be agile and secure? That's the dilemma agile software developers face as they build flexible, responsive applications.

But it is possible, according to Dan Cornell, principal at the Denim Group. Some compromises just need to be made.

Organisations are being pulled in two directions, Cornell told attendees at the 2006 AppSec Seattle conference. On one side you have the agile forces where developers are more responsive to business concerns, the frequency of stable releases is increased, and the time it takes to deploy new features is decreased.

Download this free guide

From forensic cyber to encryption: InfoSec17

Security technologist Bruce Schneier’s insights and warnings around the regulation of IoT security and forensic cyber psychologist Mary Aiken’s comments around the tensions between encryption and state security were the top highlights of the keynote presentations at Infosecurity Europe 2017 in London.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

On the other side you have the security forces that call for a more aggressive regulatory environment, an increased need for security and traditional top-down, document-centric approaches.

We didn't invent new security things to be done, but made [existing techniques] fit into the agile development life cycle.Dan Cornellprincipal, Denim Group

"Unfortunately it puts the two forces opposite each other," Cornell said. "There are going to be trade-offs that need to be made."

The challenge is to take the good things out of the security development lifecycle, such as threat modelling and application testing, and add them to the agile method, he said.

Injecting securityStart with the project setup, Cornell said. When considering education and training for developers, testers and users, include security. Then following your user stories, use case development and architecture decisions, agree on threat modelling standards for the project -- Stride priorities or Dread ratings.

When you move into the release planning phase, as you do your user stories and use cases include concerns, Cornell said. Consider inputs for threat modelling, security testing scenarios and determine the qualitative "risk budget."

"Developers and customers need to agree at the outset what is expected," Cornell added. "Keep the customer involved in making risk trade-offs."

As you finalise architecture and development guidelines, include security in your common coding standards. During this phase you should also conduct initial threat modelling and create a designer's security checklist, he said.

In addition to the traditional project roles of product manager, program manager, architect, developer and tester, Cornell said it's important to designate someone as the security adviser. That person will keep track of what was determined through threat modelling.

Planning, executing and closing an iterationSecurity also comes into play during the iteration planning phase, which is usually one to four weeks. At the iteration planning meeting where user stories are broken down into development tasks and developers estimate their own tasks, you need to also document the attack surface or story level.

Cornell said you should also model the threats alongside the user story documentation. This is important in documentation-light processes. "Your code will tell you what decision was made, and threat models will tell you why decisions were made," he said. "It's crucial for 'refactoring' in the face of changing security priorities."

As you execute an iteration, you have daily stand-up meetings but you should also have continuous integration, making use of code scanning tools and security testing tools.

You should also adhere to common coding standards and security guidelines, Cornell said. "You should always be enforcing security standards, as they're crucial for communal code ownership," he said.

When closing an iteration, run automated customer acceptance tests but make sure to include negative testing for identified threats. You should also conduct a security code review, as something may have happened informally during pair programming, Cornell said.

During the final phase of stabilising a release, you want to make one last push for security and test for defects and vulnerabilities. Prioritise vulnerabilities with client input based on agreed-upon Stride and Dread standards. You also want to include traditional penetration testing.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy