Agile is Fragile

If I asked you what is the antonym of fragile, I bet you would say something like resilient unless you have read Nassim Taleb

[i]

. But what is fragility and what does it have to do with cybersecurity?

The definition of fragile is that it is easily broken.  You will find many articles on the Internet talking about the benefits and virtues of Agile.  But should you look, you will find many articles saying Agile is broken.  To many, Agile looks like a cult: lots of promotional literature, lots of disciples, hoards of money-grubbing snake-oil-selling evangelists, and no evidence that it works at all.  To paraphrase many, it is a lot like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, everyone claims they are doing it, and those that are don’t do it wellAs with most things in life, the truth lies somewhere in between.  Let’s look at some of the myths about Agile and how they impact on security.

Many people think Agile means more talk and less documentation.  People inexperienced with Agile choose this methodology thinking they could deliver the project more quickly and easily by avoiding documentation.  But Agile is not an excuse for skipping documentation; especially important security artifacts. Documentation is just as important in Agile projects, though it is often more focused and condensed. It is true you don’t document for documentation’s sake.  Yet, documentation needs to be appropriate to the particular project you are working on and the maturity level of the team.  It gets treated like any other deliverable for an Agile project.  It gets estimated, sized, and prioritized like any other user story

[ii]

.  So when you get a project saying they don’t need to document controls, they are flat out wrong.

Because we did away with the waterfall development methodology

[iii]

, many people believe we have done away with project management and planning.  Au contraire.  While it is true that Agile stresses “responding to change over following a plan,” this doesn’t mean you don’t plan.  Agile is not anti-planning.  There’s a whole passel of planning going on.  You have your daily stand-ups, you have your bi-weekly Iteration/Sprint Meetings and you have your quarterly (or thereabouts) release planning for the next deliverable.  Some teams may have success in delivering in-the-moment, valuable solutions to customer problems, but these solutions have to work in a larger environment.  This is where planning comes in.  And speaking of planning, there are many Agile project management methodologies; for example, DSDM Atern, PRINCE2 Agile, PMI-ACP and APMG Agile Project Management, where roles, process and artifacts are described.  You need to get security inserted into your methodology

[iv]

.  Yes it is true Agile favours collaboration over management, but you cannot take authority away from a project manager or whatever you choose to call that person.  Project managers are good at prioritization, which is a necessary part of Agile.

Some Agile practitioners don’t approach security until the 11th hour—perhaps because in some organizations security is still seen as a blocker and not as a facilitator.  However, Agile encourages small, close-knit teams—DevOps-like.  In Agile, you adopt and adapt processes to the team that work for the team.  So when security has not been called to the table early enough or is not part of the team, then they are clearly at a disadvantage and have nothing to work with.  So make sure you are part of the scrum.

Perhaps the real problem with Agile is that smaller organizations with no discipline or structure whatsoever adopt it.  And, IT managers champion Agile who possess little knowledge of structured processes and practices but simply want to gain the favour of business management by promising lower costs through elimination of what they believe are vexatious planning activities, costly testing, and inane standards.  But the evidence shows this does not scale well in medium to large organizations.  Don’t let your organization devolve into chaos because of the anarchy Agile brings to some organizations.  At the end of the day, we need Agile thinking not Agile development methodologies.  Oh, and don’t throw away COBIT 5 for Information Security and Implementing NIST Cybersecurity Framework using COBIT 5 just yet.

By Peter T. Davis, CISA, CISM, CGEIT, COBIT Foundation, COBIT Implementation, COBIT Assessor, COBIT INCS, CISSP, CPA, CMA, CMC, ITIL FC, ISO 9001 FC, ISO 20000 FC/LI/LA, ISO 27001 LI/LA, ISO 27005/31000 RM, ISO 28000 FC, ISTQB CTFL, Lean IT FC, Open FAIR FC, PMI-RMP, PMP, PRINCE2 FC, SSGB, RESILIA FC




[i]

Refer to Taleb, Nassim Nicholas.  2012.  Anti-Fragile: Things That Gain from Disorder.  New York: Random House.

[ii]

User stories capture the “who,” “what” and “why” of a development requirement.  You could read more at https://en.wikipedia.org/wiki/User_story.

[iii]

In reality most organizations used the spiral model that pointed you to incremental, waterfall, or evolutionary prototyping based on risk.  See https://en.wikipedia.org/wiki/Spiral_model.

[iv]

Actually another problem with Agile is the meaning of Agile.  There are lots of Agile methodologies such as Dynamic Systems Development Method (DSDM), Scrum, Extreme Programming (XP), Feature Driven Development (FDD), Kanban, DevOps and Crystal Family.  Some are ready for prime time like DSDM Atern and some are not.

Category: Cybersecurity

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.