Agile != security

I am going to fail. Agile and security just do not mix, especially secure at source. Agile is all about rapid development, everyone in a room with brown paper plastered across the wall, product backlogs building up while developers code feverishly on today's priorities. Security works well in a structured environment. We influence through control points and project gates. Oh, you are writing requirements? Let me provide you some from security. Design stage? A threat model and design review. Build we will mostly ignore but test is our Coup de grĂ¢ce. The pen test is the height of security skill where your lovely creations will be decimated! But how do I apply this magnificence to agile when I am called a CHICKEN and thrown out of the room?

I have been reading some of the Microsoft material on a Secure Development Life-cycle (SDL) in agile. There was also a good post on the Security Architecture Linked-in group on my last post on this security people coding in agile environments. Apparently secure at source in an agile world is just what we struggle to do in waterfall projects, with all our control and gates, but just done every sprint. How hard could it be?

Therefore, this is really a post of two halves. I probably should have told you that from the start so you would not think there is gold in these hills. However, I am reading Little Bets so here is to failing fast and often. Aside: why do I buy books that tell you the whole argument in the title? The Long Tail, Blink, Little Bets etc... Right so this is what I am going to try:

Per sprint: 

  • Get to the daily scrums and fortnightly sprint planning sessions so I can put forward my valuable chicken advice and requirements. This will probably only work if I am in the same room, which could be a challenge since I am in a different continent but I will work on my boss on that.
  • Threat model. Try to get the developers and product guys to think of mis-use cases and attack trees per sprint. This could be challenging, as they will probably say NO (although Lulzsec, Sony and RSA are helping my cause here and I know a few physiological tricks now to exploit). Nevertheless, a sprint may also be too small a unit for threat modelling. This may work best per release.
  • Security unit test cases. Writing security unit tests along with the developers’ functional unit test. These should be from the threat model and will also be automated and added to the regression suite where possible
  • Static analysis. We have an automated code-scanning tool, which the developers should be running every time they check-in code. Tickets are then raised for defects. Let's see how quickly these get fixed and what priority they receive. I will also be pushing for manual peer review by both developers and me. One of the biggest problems I can for see is although there is a lot of new code being written, there is many existing assets to be re-used. The web stuff from the start-up is being manually pen tested but doubt anyone has reviewed the code and we will not have time to do that.
  • Dynamic analysis. We also have the Q/A group that use an automated application vulnerability scanner. I will be looking at that, working with them to tune and raising tickets for defects.

 Per release:  
  • Manual penetration test. Sorry I promised at B-sides to call this a security controls review, as we are too soft and squishy for outcome based testing. Even if we were not the CEO is probably not going to like the spear phishing email nor our partners when we try to hack through them. Still we have an internal team for this testing and it will do what it always does give us some comfort we are running faster than the guy running from the bear.

For the program:
  • Try getting the developers some secure coding training. They have already started so I like my chances of finding some time between 1-4am. Maybe bribing them with beer will work. We have secure coding standards, which I will also make them aware of, but unfortunately, they do not cover all languages in use. Enough general OWASP stuff to be of use though.
  • Security incident response plan. I am a big fan of having the fire engine well tuned. A full rehearsal hardly ever happens in a project but once again, at the start I am optimistic.
  • Security architecture. We have specialists within the architecture team drawing boxes and lines. This all looks good, reusable loosely coupled authentication services, role based authorisation, logging, and encryption in the right places, DDOS protection. Policies and standards are providing the broad requirements.
  • Infrastructure and network security. The ops guys will do their normal job of reviewing builds, installing configuration compliance, vulnerability scanning and setting up the correct firewall rules. YAWN.... Well until IP V6 stuff-ups makes all this important again. Manual controls review will test this all as well for what it's worth.
  • Security governance and risk reporting. All the existing 10 levels of security and risk committees will be used. The big test as always will be whether we can convince them to delay launch to fix the 10 medium-low risk security bugs. Think about that for a bit before you comment.
  • Metrics. Therefore, we can actually measure the ongoing state of security and whether the secure at source approach has been effective.

Security at source in agile development my approach:

  • Get in the room, be a pig if possible
  • Write threat models and security test cases per sprint or release
  • Source code review on check in. Dynamic and manual testing
  • Developer secure coding training and coding standards
  • Security architecture at least conceptual
  • Infrastructure and network security. #bettersafethansony
  • Incident response plan that is rehearsed
  • Security governance and risk reporting and escalation
  • Measure everything. Especially after you release

Only time will tell if this is all effective. I can see some massive challenges ahead and I really wonder if anyone is doing security well in agile, especially in large organisations. Do we all just have the waterfall SDL hammer and everything looks like nail? Of course if you are doing this well, I would love to hear what you have found works practically. Especially if you have proven it works more than once. If you have been able to measure this impact even better. Please leave a comment or contact me at , I'll be happy to share my thoughts in more detail also. Watch out for my post in a few months for lessons learned on this. A few Lulz to be had.

Related posts:
Like this post? Get updates via RSS or follow me on Twitter:

Photo credit: antiguan_life Flikr 

No comments:

Post a Comment


Written by