Agile Software Development Doesn’t Create Secure Software

We recently came across a fun book. A book that basically tells us why most Agile software development projects do not include security in their processes and that most software built in an Agile-fashion are not secure.

Wake up call anyone?

Below is some of the abstract from the book:

“In this article, the authors contrast the results of a series of interviews with agile software development organizations with a case study of a distributed agile development effort, focusing on how information security is taken care of in an agile context. The interviews indicate that small and medium-sized agile software development organizations do not use any particular methodology to achieve security goals, even when their software is web-facing and potential targets of attack. This case study confirms that even in cases where security is an articulated requirement, and where security design is fed as input to the implementation team, there is no guarantee that the end result meets the security objectives.”

The authors contend that security must be built as an intrinsic software property and emphasize the need for security awareness throughout the whole software development lifecycle. This paper suggests two extensions to agile methodologies that may contribute to ensuring focus on security during the complete lifecycle.

Worth a read for $30? Yep. I bought a copy. I’ll update this post as I finish it and let y’all know.

[HT: IGI-Global]

21 Replies to “Agile Software Development Doesn’t Create Secure Software”

  1. Nice wake-up call..

    Most development (Agile or otherwise) isn’t naturally secure. Users, product owners, developers, etc. usually don’t think of security. You need to invite someone to represent that interest to the table as subject matter expert and ensure their stories/requirements are considered also.

    An unfortunate item in most Govt shops is often the security person simply points to a document, but provides no trade-off guidance or context and the document rarely, no make that extremely rarely, provides enough details for someone to develop a secure application.

    Some organizations will better integrate security thinking. One segment that comes to mind is the financial sector. They usually think about encryption, authentication, least privilege, etc. by nature.

    Keep the posts coming!

    1. One quick addition, in Govt, security is often baked in, but quite often at the end. The security person has to make a final check in the block and they put up the stop sign. Rework is done to the app make it secure; unfortunately after most of it was developed and quite often after even passing testing successfully. The security person wasn’t at the table initially, so has to put up the red flag at the end. This is even when they were invited; often they just want to be at the end.

    2. Exactly, I think for many tech companies, we need to keep security in mind, maybe as non-functional requirements even. For most, as we progress in technology, we need to be acutely aware of this issue.

  2. Having been involved with the early bi-annual DHS-sponsored gatherings (which continue today) to promote software assurance, I agree with Paul Boos that it is not merely an Agile problem. Joe Jarzombek, the DHS head of their software assurance program, continues, after years, to point out how, even in safety-critical applications, security is lacking. Indeed, one of his favorite points is that if one cannot make a case for the securitry of a system, how can one claim it is safe? Yet there are safety standards that organizations meet without having to demonstrate the security of their systems.

    One issue in an Agile deveopment environment that I see regarding security concerns is that those who oversee security considerations are part of a silo that frequently chooses not to engage projects until they are nearly done. They often say (as do performance groups) that V&V for security (or performance) cncerns makes no sense on partial systems, leaving it up to development groups to meet the standards.

    So even if we treat security concerns as requirements for a system, the “customers” of those requirements often prefer not to engage in an Agile manner. I believe this is because they do not see themselves as gatekeepers for security, not assurers of it.

    1. Mike Cottmeyer and I discussed some challenges dealing with security at Agile Coach Camp 2008. At the time, I had aggressive security organization that asked for things that didn’t prove security; they still wanted to be gatekeeper silo as Scott so aptly put it, but at each phase gate (and they expected us to be operating as a waterfall). An example of a non-value added artifact they wanted was screenshots of the user admin interface to our applications. This of course doesn’t prove anything about security, simply how to administer users. Mike suggested we measure these extra activities so we could understand the cost.

      More importantly though would be to measure the cost of rework (in both dollars and time – lead time impacts, etc.) as a result of security acting as a gatekeeper. You might be able to get the organization to evolve to a more collaborative environment with some evidence.

      One last thing, often our security gatekeepers look at their job as though it is black and white, not shades of gray. While we may want a secure application, in the end this is usually a non-value add from a functionality standpoint for most stakeholders/users. It shouldn’t be ignored, but it should be worked in the priorities along with the rest of the items.

      1. Sometimes you need a specific person or voice representing the security side of things. When I did a Agile transformation with the Airforce we had an EITDR architect and Security Officer who represented the security needs of the system. Unfortunately, every change made to the portal needed to be vetted through them…

    2. Agreed. Many of the security issues are brought up at the tail end of a project, and not baked in. it’s almost an environment shift that’s needed to get people with the program!

  3. I think there are a couple of elements here. The first being to improve a team’s ability to support secure coding. As you would expect, having a clear understanding of what is expected and what vulnerabilities must be accounted for is of critical importance. Often this is just seen as coding practices but secure systems start at design. Architectural patterns can be used to reduce the impact of vulnerabilities. In services development it is possible to provide standardized templates that are designed to protect against certain vulnerabilities in the contract interfaces.

    Continuous integration tooling, such as static code analysis, may be helpful in identifying coding practices that more easily expose a system to security vulnerabilities.

    In all instances secure coding is just a part of the day to day job. As Paul mentioned there is the situation where security serves as a gatekeeper. Detecting issues and throwing them back to development teams. Security needs to be part of the “team”, providing guidance, training, side by side helping developers to practice secure coding. Serving only as a gatekeeper creates a situation where security locally optimizes at the expense of meeting the overall goal which is delivering secure systems.

    1. I like how you said: “Coding practices.” For those platforms that need to be secure, security needs to be part of the coding practices of the team!

      1. Here are some additional comments on that topic.

        * Security seems like a quality attribute to me. Everything you’ve heard about quality could apply here: “security built-in”, continuous & automated security testing, static code analysis, intrusion detection, pair programming, penetration testing, etc.
        I.e. focusing on quality (agile pretends to do so) also means focusing on security if it matters.
        – Yes, specific skills, techniques and special attention are necessary to build secure applications. (Same also applies to other non-functional requirements as scalability for example).
        – And all that has its cost.

        * Definition of Done should be clear enough about security.

        * Possible inherent insecurity of employed 3-rd party tools and frameworks should not be overlooked. (Vulnerabilities of such “crappy” tools and backends could compromise the security of the whole system).

      1. Maybe those folks presenting the code should have unit tests and security tests.

        BTW, I don’t fully subscribe to security being entirely an “-ility” issue. Quality code isn’t necessarily secure as security often is a set of features (e.g. lock the user out after 3 unsuccessful attempts for one hour). This is something that can be coded for…

        Some of it is an -ility issue, example: I have a field in a form and this field just gets inserted into a SQL string executed against the database; this will expose me to SQL injection attacks.

        The feature-oriented ones need to be prioritized just like any of the others. The Product Owner/Growth Facilitator (to use OpenAgile terminology) should have the final say, but with input from a Security SME who is a part of the team.

        My viewpoint summarized:

        – ensure Security is invited to the table
        – provide proper change management so that security folks understand they are a part of the team throughout the development (strong encouragement)
        – adequately capture Security as functional and non-functional requirements and have tests appropriate for them
        – ensure the PO/GF properly prioritizes the security items so they aren’t forgotten

  4. I’ve just written a post on Non-Functional Requirements here
    I would generally through security in as a candidate for. People may disagree, but what’s important is that we treat security as a feature, and don’t assume we get it for free with Waterfall and we don’t get it at all with Agile. If you want a super secure system fine, but it’s going to take longer to deliver, and more interations before you reach your minimum feature set.

Leave a Reply