Agile Mindset - Secure Delivery
Practicing great security, while deploying at the speed of
Agility!
Robert Woods - Aarons, Inc.
Big brother is watching…and he’s not happy.
Once again, the kiddos have created a mess and big brother was
left to not only clean it up, but take it on the chin for time to market. Looks
like he had to play the role of “bad guy” and take the fun out of Agile
delivery by throwing that whole ‘was it developed securely’ question out there
and halting production deployment, skewing project deliverables and sending it
back to development.
Who hired these guys anyway?
I recently attended the Agile2013 conference in Nashville,
TN and it was brought to light by more than a few attendees what felt like a
glaring absence of security awareness and discussion in the Agile community.
Subsequently, I hosted a volunteer 15 minute lightning session on Agile Secure
Delivery and sure enough, companies such as McAfee, John Deer and others showed
as eager participants. I brought that idea back to Aarons (who happens to have
one of the best Information Assurance teams in the Southeast) and they
confirmed that, based on their experience, Security consistently gets a bad rep
in software development circles; especially so by teams who claim to be “Agile”.
Corporations want to be quick to market, generate feedback, and increase
velocity; sometimes at the unfortunate expense of best security practice.
So is the life of an InfoSec or Information Assurance team who
has the gall to live in our Agile
world.
Here’s a question…Can we call ourselves Agile if we fail to
adapt to the requirements of one of our key stakeholders? Because that’s what
Security is; A Key Stakeholder!
Now, what that means for the team, specifically the Product Owner, is the need to get Information
Assurance involved from the very beginning of the product evolutionary process
to provide that evaluation. They can then take the results found and work with
their IA team on creating real user stories based on security requirements and
regular code checkpoints. For example:
“As user A, I need to
answer a series of personal questions, so
that the system can verify my identity.” (Basic Security Feature
Requirement)
Or
“As user B, I need penetration
tests run against the code so that any
potential weaknesses are identified” (Regularly scheduled and planned security
verification)
The team , in turn, can estimate and plan for those stories
which means they will need to collaborate in greater detail with the story
stakeholder; Information Assurance! They recognize upfront this will be a part
of their overall velocity. The exposure to best practice secure development
generated from these conversations creates a culture of visibility into overall
greater security awareness in developers, testers and business owners. In
creating checkpoints, the team literally has multiple opportunities,
pre-scheduled, where the IA team will help do what amounts to a secure code
hardening.
I recently heard Gene Kim, Co-author of “The Phoenix Project” (great read if you
get the chance), speak on continuous deployment and information security impact.
He spoke of companies taking this concept to the next level by literally checking
every line of code via automation as the developer hits SAVE. While this level
of checks and balances may not be immediately feasible for many development
shops, this does give you an idea of the direction some companies have headed
to ensure not only quality security but also faster time to market by reducing
the perceived security bottleneck.
For Agile teams not capable of that type of constant check, the
point is, as opposed to waiting for the
end of a project to see if we have it right, we will check security iteratively
and often (sound familiar?)
The greater the exposure the team has to security best
practice, the less time it actually takes to evaluate these environments.
Eventually, the team gets in into a cadence of checks and balances which, in
the end, expedites time to market with high levels of security as key product features.
Below is an example of a scaled framework we use for implementing
security touch points baked into a product lifecycle:
As
you can see, it’s a relatively non-evasive process that simply adds our
Information Assurance team as an additional stakeholder with requirements no
different than features needed from our users. The blue security shields are
simply touch points baked into portfolio planning, backlog creation, Sprint 0
analysis, sprint planning, retrospective and release planning (this type of
involvement might be typical for high levels of involvement based on initial
evaluation of product). The key point to
remember is that this is a framework.
Each product is different and this secure framework is Agile and therefore
adaptive to the needs of each individual solution.
Speaking of which, shouldn’t great security automatically be
considered core product features?
This Agile Security Awareness mindset can, and should, apply
to any aspect of solution development we undertake as Agile teams. If we aren’t
baking security into our backlog, we aren’t accurately capturing the needs of
our user.
As an Agile team, that’s heresy!
Conversely, wouldn’t you rather have a team who plans for
the user’s needs, concerns themselves with corporate data security, while
working with and aligning themselves with all
required stakeholders in order to deliver quickly to market…securely?
And Big Brother…well I'm sure we can find plenty of other things to
blame him for.
Robert Woods
Agile Trainer/Coach/Speaker
Aarons, Inc.
No comments:
Post a Comment