Dec 182014

The embarrassing hack of Sony’s corporate information, followed by the company’s decision not to release The Interview because of vague online threats, has already resulted in a lot of hand-wringing about how secure corporate information is, and whether companies have done all they can to secure it to the utmost. Owners, shareholders, customers, and partners will want to relieve that anxiety, so 2015 may be the year of a lot of impromptu security projects. Given the scale of the urgency and unknowns, coupled with the potential for a lot of unintended business consequences, 2015 may be the year that many IT departments consider a more Agile approach to security.

The worst response to the Sony hack would be a long, complicated cycle of first auditing the real state of the organization’s security, followed by a lot of simultaneous, high-priority projects. Not only will this strategy take a long time to develop the big up-front requirements (because that’s what the result of a security audit are), but the new projects that spin off from that audit might very easily suck all the spare resources out of many IT departments. The tone will be a lot like Jack Bauer’s constraint refrain in the TV series 24: “There’s no time!” Unfortunately, the 24 in this case might refer to the number of new projects, or the number of months before the security panic subsides. Meanwhile, many of the new security measures may erect barriers to productivity, while reducing the resources available to other projects that might have increased productivity further. (Not to mention all the other corporate objectives that IT can’t help fulfill, while it’s too busy dealing with security.)

Agile, as a disciplined, field-tested set of practices and principles, seems like just the way to handle the urgent security priorities without falling into this trap.

  1. Security challenges take time to understand. There will never be an immediate answer to a question like, “How much risk is there that someone might use our partner portal to get access to our internal systems?” Agile is best when dealing with unknowns, breaking them down into manageable chunks, then delivering the “minimum viable experiment” quickly to validate what you think you know.

  2. Security solutions take experimentation to develop. Software development projects allow for a very wide range of possible solutions to a single problem. If that problem involves security, you want to be able to discover any flaws quickly, then make adjustments. Agile creates a structure and cadence of work that allows for ongoing experimentation and adjustment: for example, put the proposed fix to a cross-site scripting vulnerability into a sandbox environment, or in limited release, and see what happens. Use the short sprint cycle to develop and deliver improvements to that code.

  3. Security challenges evolve. Since the security landscape is always changing, any investment in enhanced security should improve the IT department’s ability to identify and address security threats more quickly. The modularity of Agile (lots of little building blocks of effort, not one giant monolith) make it easier to adapt to changing security requirements.

  4. Security requires prioritization. No one can escape the mathematics of limited time, limited resources. Therefore, not every security project can share the same level priority. Agile compels tough prioritization decisions, then makes it easy to re-prioritize as needed, without losing the clarity of the prioritized backlog.

  5. There is not an inevitable trade-off between security and other goals. If you say, “Security trumps everything else,” then you may get nothing else. Agile practices can help prevent an unnecessary sacrifice of other corporate priorities to security. For example, when developing the backlog, you not only want to write user stories about the security professional (“As the security supremo, I want to build a hard shell around the corporate network…”), but about the people whom new security capabilities will affect (“As a salesperson, I need to access the corporate network while on the road…”). Seeing these stories side-by-side leads to deeper thinking about how to satisfy more than just the security imperative.

  6. Security requires collaboration among different stakeholders. These different corporate objectives do not exist in the abstract. Real people, like the CFO, an HR person, a middle manager, and the VP of marketing embody these objectives. Whether you’re trying to deal with their needs within a security project, or you’re balancing the security project against other work that IT is planning to do, you need the participation from people outside of IT. Agile gives a better framework for collaboration with these other stakeholders, providing frequent, regular feedback moments.

  7. Security requires “security-mindedness” earlier in projects. The earlier you grapple with security requirements, the more likely to are to make the necessary architectural and functional decisions needed to address them. Unfortunately, many projects deal with the security at the very end. You can implore people to take security more seriously up front, but you’ve already seen how successful that approach is. Agile gives a more modular project structure in which it is far easier to plug into the process the participation of security experts, balancing factors like the timing of key architectural decisions and the availability of the security pros.

  8. Security requires a disciplined approach. Happily, we’ve almost reached the point where the entirely false stereotype of the Agile “cowboy developer” has faded away. However, there are still people concerned whether Agile can work in extremely sensitive contexts, such as heavy regulation and high security. Since there are plenty of good success stories in these settings — banks, medical device manufacturers, energy companies, and military branches, to name but a few — anyone concerned with Agile’s applicability to security projects can simply reach out to the larger Agile community for examples and advice.

Those are some of the reasons why, if you want to respond quickly and effectively to post-Sony security concerns, without disrupting the rest of the business, Agile methods might provide a better path than the one you’re contemplating right now. Just be aware that, if you have limited or no experience in your organization with Agile, there will be time needed to learn the practices and principles. A little up-front investment might be worth it, if you want to escape the burdens of long, complex, and ultimately unpredictable security mega-efforts.




Tom Grant

Tom Grant is the former Practice Director of Cutter Consortium's Agile Product Management & Software Engineering Excellence practice. His expertise lies in software development and delivery, with a particular focus on Agile, Lean, application lifecycle management (ALM), product management, serious games, collaboration, innovation, and requirements.


 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>