Big Brother is watching…and he’s not happy. Once again, the kids made a mess, and Big Brother was left to not only clean it up but also take it on the chin. By asking serious questions about security, Big Brother halted production deployment, skewed the deliverables, and sent the whole project back to development. (Who hired these guys, anyway?)
While attending the Agile2013 conference in Nashville, the absence of discussion surrounding security awareness in the Agile community became abundantly apparent. Of the nearly 200 sessions that focused on developing great products and providing business value to customers, not one session focused on security (listen...that’s the sound of thousands of security engineers shaking their heads).
By request, I hosted a fifteen-minute “lightning session” on Agile security, and, sure enough, companies like McAfee, John Deere, and others were eager participants. I brought my ideas about Agile security back to Aarons, Inc., one of the largest retail rent-to-own companies in the North America—which happens to have one of the best information assurance (IA) teams in the southeast—and they confirmed for me that while security gets a bad rap in support and software development circles, it’s particularly derided by teams that profess to be “agile.” Corporations want to be quick to market and adaptable to constant change. They want to generate feedback, reduce support calls, and increase velocity.
Unfortunately, this is often achieved at the expense of sound security.
The Agile Effect
An ongoing (and concerning) trend observed in “Agile” teams is the failure to engage the proper individuals or teams in product development from the beginning. Information security (InfoSec), for example, is often brought in towards the end of development, or after the support organization starts receiving calls. They’re asked to run penetration tests and the like, at which point they find themselves having to explain why the product “doesn’t quite meet industry security standards,” putting the business in the unenviable position of weighing security risk and supportability against time to market. Inevitably, security comes to be perceived as a “production bottleneck,” and Agile teams as lacking any sense of structure, standards, or morals.
The situation is much the same for support teams. Take Bob, for example. (Names have been changed to protect the innocent.) Bob is a member of an overutilized yet underappreciated DevOps team. His job is to not only support the product developers as they take products to market but also support the products themselves. Before deploying Product A, Bob diligently reviews the code for anything that might cause him to receive a late-night or weekend call. He runs the code by InfoSec, to make sure it’s been validated against best practices. Much to his (lack of) surprise, InfoSec denies ever having seen it. Bob turns his discovery over to change management, who in turn runs it by executive management, who then greenlights the deployment.
Bob stocks up on Red Bull and Hot Pockets for the long nights ahead.
Here’s the question: Can we call ourselves Agile if we fail to adapt to the requirements of our key stakeholders? Because that’s what both support and InfoSec are: key stakeholders!
Show Me the Business Case!
In working with the Aaron’s IA team on developing its S-SDLC (Secure-Software Development Life Cycle), we evaluated the Agile framework at the portfolio level. By identifying the InfoSec team as a stakeholder, we were able to bake security steps and checks into the product backlog itself, basing the degree of InfoSec involvement on a product’s level of information risk, as determined by the IA team. In some cases, the InfoSec team is minimally involved; in others, it’s deeply involved (e.g., daily).
What does that mean for the team? For the product owner and team facilitator in particular, it means getting IA involved from the very beginning of the product development process. Based on IA’s evaluation, the team can create user stories (small slices of functionality) that include security requirements and regular code checkpoints. In Agile, this involves identifying the who, what, and why. For example:
- User A [who] needs to answer a series of personal identification questions [what] so that the system can verify his/her identity [why].
- User B [who] needs to run penetration test against the code [what] to identify any potential weaknesses [why].
User stories in hand, the mature Agile team can estimate and plan more accurately (i.e., we can accomplish X in a given period of time), and collaborate more effectively with IA and InfoSec. By building in check points, the team will have multiple opportunities to engage the IA team in what amounts to a secure code hardening; engaging the IA team will, in turn, create opportunities for supporting that security going forward and drafting any lean documentation required to do so. (Yes, even though we’re Agile, we do document the items our stakeholders consider to be of high value. Security and support documentation fall into this bucket! Can you say “ISO compliance”?) The cumulative effect of the exposure this brings to best practice–driven secure development is the creation of a culture of security awareness among developers, testers, downstream support engineers, business owners, and others.
I recently heard Gene Kim, coauthor of The Phoenix Project, speak on continuous deployment and information security. According to Kim, some companies literally check every line of code automatically when the developer hits the “Save” button. While this level of checks and balances may not be feasible for some shops, it should give you a sense of the levels to which organizations have risen to ensure not only quality security but also faster time to market (by mitigating the effect of security bottlenecks). That’s right! If we bake these needs into our frameworks, lifecycles, and processes, we can go to market faster and more securely with fewer production-related problems.
For Agile teams that aren’t capable of constant verification, this doesn’t mean they can’t verify security iteratively and often (sound familiar, Agilists?). The greater exposure the team has to security best practices, the less time it will actually take to make these assessments. Eventually, the team will settle into a rhythm of checks and counterchecks, which, in the end, will have the same effect as constant verification: expedited time to market and high levels of security.
The following is a high-level example of the scaled framework Aaron’s uses for incorporating security touchpoints into the product lifecycle.
For Agile professionals, this framework looks similar to the SAFe method of Agile scaling. As you can see, it’s a relatively nonevasive process that simply adds the IA team as a stakeholder. The blue security shields are preplanned touchpoints in the portfolio planning, backlog creation, sprint analysis, sprint planning, retrospective, and release planning stages.
The key point to remember is that this is an Agile framework. Every product is different, and the organization’s needs will vary in response to those differences. The worst thing an organization can do is look at another’s Agile adoption and think, “That’s exactly how we’re going to do it.” Avoid this at all costs! Your organization has different people, products, projects, and requirements. Don’t expect the same results to come from copying the same practices, and don’t allow the process to define you. Instead, take the framework and mold it to your needs.
Mind Over Process
This security awareness mindset can—and should—apply to any aspect of product development. If we aren’t baking security into our backlog, we can’t accurately capture the needs of our users. For Agile teams, that’s sacrilege!
Wouldn’t you rather have a culture that anticipates the user’s needs and plans accordingly, all while working with stakeholders to deliver products to market quickly and securely?
Make no mistake: We’re talking about a culture shift at the organizational level. This brings us back to Bob...
Imagine a new project has been initiated. Bob is brought in at the beginning, along with the development team, security, and other impacted areas of the business. Over the course of a select few meetings, Bob shares his own ideas on what would make his life easier and what end users would value, and identifies opportunities for secure code review. Together, Bob and the IA team work with the product owner to create a backlog the core development team can actually consume and plan for in advance. Throughout the development lifecycle, the team regularly touches base with Bob and security to make sure it’s not making any faulty assumptions .
By the time release rolls around, Bob feels great (well, better) about deploying and supporting the new product. He checks with security, even though he knows they’ve been involved from the beginning, and they give him a big thumbs-up. Bob deploys the product and leaves for a long-overdue date night with his wife.
We live in a fast-moving world that requires constant communication and collaboration to make sure we’re not only keeping up, but keeping right. In other words, just because we want to move fast, that doesn’t mean we want to move quickly in the wrong direction. When Agile is done right, you can have your cake and eat it, too.
As for Big Brother…well, I’m sure we can find plenty of other things to blame him for.
Robert Woods has eighteen years of experience in systems engineering, software development, continuous improvement, leadership, project management, and portfolio development. He’s currently an Agile coach and trainer, mentoring both corporations and individuals in scaled enterprise Agile adoptions, and his sessions cover a wide range of topics, from team dynamics and leadership to product ownership and Agile development, portfolio management, and corporate culture. As an industry expert in improvement through collaboration, Robert coaches teams at all levels, from development to executive, in aligning the business and IT. Follow him on Twitter @mindoverprocess.
Robert will be presenting a session on this topic at FUSION 14 (session #409). Add it to your schedule today!