Security Blog

Security Blog

This blog will follow the lives of the TRaC Defence team focussing on areas of interest, technology, industry news and problems encountered.

Can Security Truly Be Agile?

Sunday, November 12, 2017

Security and Agility; they go hand in hand, right?

To be able to have a security approach that meets your needs but doesn't stop the business in its tracks needs to be Agile. But can and should security try to be delivered in an Agile way? Agile, as I am sure you are aware, is the latest buzz in project management. Agile as defined is (as per google dictionary) 'relating to or denoting a method of project management, used especially for software development, that is characterised by the division of tasks into short phases of work and frequent reassessment and adaptation of plans'. So taking this approach can it truly be applied to security? Short phases with clear defined outputs sound great and I can understand why clients would like well defined and clear outputs that can be delivered in 2 possibly 3 weeks at a push, but is this realistic?

So lets look at this.

The Agile methodology works around small projects called sprints. Sprints are small tasks with a clearly defined and set deliverable (although this doesn't guarantee the output expected). So I want my websites to allow my client to choose a product and pay for that product electronically and in a secure way? This is a good, clear deliverable with a set demonstrable outcome. Great. Agile could work. I want a new security solution for my business... mmm this is when Agile starts to no longer be Agile. You can split this task into separate components such as requirements capture, design, POC etc... But this isn't truly Agile. As going into a sprint, the requirements need to be well defined and the client needs a clear deliverable that demonstrably works and can be done in bite size chunks no more that 2 weeks preferably. A design doesn't do that, it shows a potential option or approach, however it's not a true Agile deliverable as it's only part of a deliverable. Of course security can very much be part of an Agile process as part of an overall requirement, e.g. I want my clients to be able to buy my products through my website and it must be secure.

So what should be in place to run an Agile security project?

To be Agile the requirements have to be very clear and well defined from the start.
The client has to be very clear on what they want. As at the end of a given sprint the client / product owner must be able to say yes or no. For example, you asked for a red box. I have produced a red box. Is this what you expected?... Yes or No? Yes. Great. Now onto the next requirement; it needs holes, and so on.
Agile does seem to follow the path of fail fast which is great - limited exposure and limited cost. However, failure of programmes tend to be due to unclear requirements, scope creep, and lack of client engagement and knowledge about what they want, which goes against the Agile ethos. Of course, misinterpretation by the provider is also a factor, but Agile doesn't protect you against this. For example, you asked for a red box. I have produced a red box. Is this what you expected?... No, I didn't want corners... ok be back in two weeks. Ok, slight exageration but you get the point. So you could have multiple failed attempts.
This means that for a sprint you have to be able to carry out a full development lifecycle for the deliverable for that sprint, from design to implementation to test. So why is it people read a word like Agile, think 'that sounds great' and fail to understand what the approach is and how it works and more importantly what it is designed to do. I have heard that Agile replaces the 'V' or Waterfall model, which in a sense it does with lots of short sharp implementations of the V or Waterfall approach for software development.

However, I do see parts of Agile that can work for Security. I am always fond of a good story; it's the story that sets the start of the Agile process. If somebody can articulate what they are trying to achieve in the form of a story which focusses on a business benefit or a set outcome as a service delivery or consultancy company, this makes life a lot easier and allows for risk reduction and accurate timing to take place. But this doesn't mean I can follow a true Agile process to deliver the outcomes / requirements of that story.

As people, are we too quick to jump on a keyword because it sounds good rather than it is the right thing to try and apply. As mentioned above doing a requirements capture sprint and then elongating the process to say 8 weeks is not Agile and shouldn't be described as such.

What are your thoughts? Have I missed the point? Or, should I embrace peoples' enthusiasm to take a process and change it beyond recognition to make it sound like they are doing something special and that this is going to miraculously drive better outcomes than previous projects?

Let the conversation begin...

www.TRacDefence.com

wrote
Friday, March 23, 2018, 11:27
Thanks much for your post, it influence us to have an ever rising number of circles all through our life, So type for you, I likewise faith you will make more and more exceptional post and allows more and more converse, much gratitude, dear.
wrote
Saturday, October 6, 2018, 12:23
Well Thanks For Posting Such An Outstanding Idea. I Like This Blog & I Like The Topic And Thinking Of Making It Right.<br />
wrote
Monday, January 4, 2021, 08:52
It is a very informative article.
Search