Notes from Agile Finland and Finnish Information Security Association's event on secure software development and agile methods. The event was organised by Agile Finland and the Finnish Information Security Association in Helsinki, Finland on 6th April, 2010. We started with a couple of presentations to set the stage and then followed with group work and discussion, which has been summarised below.

Starting comments

• Agile security: The Devil's Advocate (Camillo Särs / F-Secure) (PDF)
• Software security for large agile projects (Antti Vähä-Sipilä / Nokia) (PDF)

Discussion notes

Is there an implied security promise in Agile methods?

• Yes, perhaps – but it depends
• When an Agile method requires stringent automated testing that happens often, that is probably a good thing for security
• Agile methods that aim to minimise quality debt also help security as far as security can be seen as being analogous (or a subset of) quality (or if you start talking about security debt) (See: http://en.wikipedia.org/wiki/Technical_debt)
• Lean processes make it faster to be reactive when faced with vulnerabilities (lean processes can react faster to external issues)
• Simple processes may be easier to follow than complex ones – therefore there may be more time to spend time on actual issues and less on process
• Add security into Definition of Done for Scrum teams – then it will become a criteria that will be automatically assessed after every Scrum sprint
  • If security is thought in every sprint, in the end this results in more hours spent on security than in normal processes where there could be just a single security analysis in the beginning
• Security is not only about identifying the risks we need to cover, but also responding to problems once they are found. Agile methods are by nature more responsive to changes, so they are more adequate to environments where speed of response is required as a way to tackle security issues.
• Agile methods like Scrum are also a work-management method, as such they allow the company to “inject” certain security related activities into the scrum. For example one can define that the software must undergo security testing at the end of every sprint (automated testing for example). This at least ensures that security related regression does not happen.
• Agile methods focus on quality. As such there is an indirect benefit regarding security. More quality has an impact on some security properties of the system.

Security requirements and risk controls

• Differences in security requirements & other requirements
  • Security requirements are often negative (normally requirements are positive) – see below for discussion of misuse cases
  • There are also non-technical security controls
    • NDAs, insurance, etc.
    • These might not be seen in functional requirements at all but their existence may still affect the way in which risks are portrayed
• Who should set the security requirements?
  • The customer?
    • The customer is the “original” source of money – the “ultimate business owner”
    • Knows where the SW is being used, so at least in theory should have information for risk / money tradeoff
    • For an enlightened customer, security requirements might not be that different from other requirements
    • But, for example, consumers do not make very good experts of their security risks (how else could be explained that following a data breach, a company can actually get a rise in customers…)
    • Also, isn’t it a well-known problem that many customers don’t know what they want but actually have to be told what solves their problem (or what their problem even is)? So why would they be able to articulate security requirements?
  • The Product Owner?
    • The Product Owner, in the Scrum ideology, is an agent / proxy for the customer, so especially in the case of a non-professional customer (consumer) may potentially be the closest you get to the “ultimate business owner”
    • But would need to be a Superman, Product Owners are already now burdened with all sorts of responsibilities of things that should be taken into account (for a good discussion on Product Owner’s responsibilities, see, for example, Roman Pichler: Agile Product Management with Scrum: Creating Products That Customers Love, at http://www.romanpichler.com/)
    • With proper support, a “layman” Product Owner can however perform pretty well even though not a Superman (see section on support)
    • Customer may still want to have to say the last word, at least in prioritisation, if the customer has a plausible expertise in the issue
    • So it really depends on the type and expertise of your customer whether you can or want to engage the customer in security requirements setting (most b2b probably yes, b2c probably less – some sort of crowdsourcing of opinions and market research of course can help)

Misuse cases / abuse cases / “attacker stories”

• Background: http://en.wikipedia.org/wiki/Misuse_case (never mind the picture, that's just RUP overkill, it's the concept that counts…)
• Misuse cases or abuse cases can be on any level (from business case level to technical level), so an alternative naming could be an “attacker story” – instead of “As a user, I can …”, say “An attacker must not…”
  • This brings the real-world attacker capabilities into the story, so it also often gives a way to think about the risks related to the real-world operational environment
  • However, this may restrict thinking more into an intentional attack (and take focus away from unintentional things such as data leaks)
• Several people in the audience had used or planned to use misuse cases with promising results
• Misuse / abuse cases can also be used as a tool to find security requirements
  • As a way to make people think more like an attacker in threat / risk analysis
  • As an intermediate communication tool, where product management can communicate needs to developers without having to have a solution proposal (“I want this not to happen but I don’t know how”)
• Misuse / abuse cases are more cross-cutting than requirements usually
  • Specific positive functional requirements tend to be narrow in scope (targeting specific functionality) – misuse cases are often wider, covering all possible ways to attack a system
  • Saying whether a misuse case is “done” may be hard, and a single misuse case might be a larger requirement that a single sprint can deliver
  • Misuse cases would therefore need to be decomposed into narrower functional (positive?) requirements so that them being “done” can be measured
  • Misuse cases can be sometimes transformed into test cases (esp. in well defined narrower situations?), but that does not mean that misuse case based tests would be all security testing that would be needed

Testing for security

• Normally testing is against a specification, security testing is against unspecified things
  • Does not fit unit / integration testing that well (so only relying on CI / TDD tests might not be enough, although you could plausibly put fuzzing there)
  • Exploratory testing, including pentesting, is needed to find the unspecified, and that is very hard (if impossible currently) to automate

Support required for secure Agile activities

• Not free, needs some sort of investment
  • Management will quickly ask what you’re using all the money for
  • You may need metrics very soon (but this isn’t Agile specific…)
• Needs at least time
• Constant awareness raising needed
• Implementation language / environment specific support is also needed
• Get training that actually fits what the people are doing, not a one-size fits all one
• You need guides, HOWTOs, etc.
• Security experts made available
  • Needs security competences made available to the team
    • Autonomy of Scrum team may necessitate a specific security person in the Scrum team
    • Test engineers and QA should be security conscious
    • Gary McGraw / BSIMM refers to these people (security minded people in teams) as the “satellite”
    • Microsoft has “office hours” where you can meet security experts – a kind of a software security helpdesk
    • Microsoft (?): It is easier to make a good developer into a security person, than a security person into a decent developer, so it may be useful to tap into your developer base to find security champions
  • Each team might not need a fully fledged security person but at least someone who knows when something would have to be done
    • Relative expertise: one guy who is perhaps not a security expert, but at least more expert than the rest of the team
    • Pooled security teams are also an option, but may face scalability challenges when many teams do things simultaneously (like Scrum often does, if sprints are synchronised between teams)
  • Should every team be required to have demonstrated capability in the “seven security competences” (McGraw?)
    • Not perhaps in the same person, but distributed between different people
    • If a Scrum team is missing these competences, would need to be addressed or separately approved
    • A company should decide which security-related knowledge areas need to be covered by the team itself (things the teams needs knowledge on every day) and what should be part of a more security-focused group or person.
• Support to Product Owners (see section on security requirements for discussion of Product Owner role)
  • Possibly would come in a form of “creativity games”, tools that help an intelligent but security-wise “layman” product owner to establish security risks and control needs
  • Creativity tools should be used in workshops, especially beginning teams do not get good results working alone
  • Microsoft: “Elevation of Privilege” card game (http://www.microsoft.com/Security/sdl/eop.aspx) – although this is probably for technical threat analysis, not necessarily for product owners
  • Should not use Excel sheets, checklists etc.
• Lists of things which should trigger a contact to a “real” security person
  • Example: Implement crypto
  • Example: Plan to use obfuscation
  • Probably a lot more depending on your specific systems

What to ask a prospective Agile SW vendor

• Try something that is hard to answer yes/no or without knowing what you're meaning
  • “What are your acceptance criteria for security”
  • “How can you prove me that your product is secure”
  • “Can you demonstrate your current list of security risks”
• The main point is actually not to assess the security – what means more is how the company responds
  • If they say they do “everything” and are “secure” they probably aren’t
  • If they say they don’t know what security is, they certainly don’t
  • But if they start to explain what they do wrt. security, you can actually determine whether they’re any good – if they start to explain risk analysis, etc.
• There are of course companies who could have read the How to Bluff Your Way Around Security, and could respond even though they understand and do nothing

Managing security when there is a transition to Agile

• If an organisation makes many transitions at once, like web to SOA, waterfall to Agile – this has a lot of potential for things going wrong
• Manage expectations
  • A permission to fail – do not use on a business critical thing for the first time, if you’re doing an agile transformation
  • If you are doing transition to Agile, start Agile with the best teams and pilot new things there first
• If an organisation does not understand security, transition to Agile won’t magically heal it
• Agile should be understood correctly:
  • Should really give the teams the alternative to say “we are not done” and to say how much they really can implement in a  sprint
  • Should not be just force-feeding teams in timeboxes
  • Should not have incentives to claim to be “done” if they are not really “done” on a high quality level

Compliance / audit based security and Agile methods

• Imposed compliance may actually be a liability transfer – to show that you’re done stuff correctly, not to increase security
  • So you don’t necessarily need to make your process look like it “implements” ISO 2700x, but you can have ISO 2700x as a deliverable alongside the system?
  • Some compliance specs are easier than others
• It really should (and is?) possible to argue compliance based on stuff that comes out of Agile processes
  • Not necessarily a formatted PDF stored on a document server
  • Some creativity may be needed in what artifacts can be used as compliance documentation
  • Perhaps there still is a need to create documentation for compliance purposes
• Compliance does not lead to security, so if you have a secure system, you might just tolerate the overhead to create the documentation that supports your claims. If you aren’t secure, well then you’re screwed anyway