Zero to ‘Secure’ in 60 Seconds: 3 Tips for Using Agile Security to Create a Security Posture


You’re hired…. Now ‘do’ security!

That’s a common challenge to information security professionals hired into an organization that previously had not staffed security positions.  Daily breach headlines, and evolving threats, can make the pursuit of a security program the equivalent of a game of ‘Whack-a-Mole’.  After spending a few years in the security consulting arena myself, I’ve recently taken a position where that is the task ahead… to get my organization as secure as possible, as quickly as possible.  Easy, right?

Well, no, it won’t be easy, but with some discipline, we can get there.  In order to make this happen, the security team I’m fortunate to lead is taking on an Agile methodology, as we look to paint a masterpiece out of blank canvas.  Our end goal is a complete security program, which takes ‘development’ just like a software application.  So, we developed a vision of where we want to be, and cataloged the steps to get there, and are tackling each with an Agile flair.  We’re running weekly sprints, and tracking our tasks on our own Kanban board for openness in our progress.  In an attempt to boil down to key steps that will make, or break, our success, here are three that have produced the most value, so far…..

  • Know Your Enemy – Given that security can touch everything in a computing environment, the ‘enemy’ is loose ends. When building a security program, it is quite easy to start 100 tasks and see 0 of them to completion… leaving 100 vulnerabilities in the environment.  A more effective strategy to combat those loose ends is to define the success of those 100 tasks before engaging.  This is not groundbreaking, as it is developing a ‘mini-statement of work’ for each objective; however it is critical as these 100 success markers become the ‘Agile Security Backlog’.
  • Backlog, Backlog, Backlog – This cannot be stated enough, that management support of the security backlog is paramount. It may take a few sessions, but gather CIO support of the priority of those 100 items in the backlog is a great success enabler.  And remember those daily breach headlines from earlier?   The security world is changing, almost by the Tweet, so be prepared to periodically review the backlog with the management team that supports it, for complete long term effectiveness.
  • Pick the Right Size Mountains to Climb – Diversify the current tasks being worked on. Again, this is groundbreaking information, but mixing in quick wins is great for team morale of the immediate team, and also relationship building to external teams.  If you do not have any quick wins at the top of your backlog, then breakdown the larger tasks into smaller subtasks.  Instead of ‘Reviewing Vulnerabilities in Servers’ as a tasks, review Domain Controllers first, and then Database Servers next, and so on.

Building a Security Program is a daunting task, and not for the faint of heart.  Putting these three weapons in your arsenal for world domination, can help fast track success.


Jon Tidwell is part of the GovLoop Featured Blogger program, where we feature blog posts by government voices from all across the country (and world!). To see more Featured Blogger posts, click here.

Leave a Comment


Leave a Reply

Cliff Berg

Mr. Tidwell wrote, “I’ve recently taken a position where that is the task ahead… to get my organization as secure as possible, as quickly as possible.”

He clearly is taking the work seriously, but the quote illustrates the problem: it reminds me of a scenario from The Wire, where leaders suddenly find it expedient to focus on an area and command their subordinates to make it happen in short order, when in reality it takes years to address this kind of issue.

The core problem is that software developers within organizations do not understand application level security. We often read in the news about a breach, and the news media blames the infrastructure, such as “a server had not had two factor authentication implemented”. But there will always be some loophole that a hacker can find – infrastructure is just too complicated today, and too distributed, to expect it to all be locked down. So it really falls to the app developer, to design the app and the databases such that if someone gets through the infrastructure (because someone will), then (1) the breach is discovered soon through active intrusion detection monitoring of apps, and (2) the amount of data that the intruder can get in that time is small. Achieving #1 requires that app developers work with Security to profile an app properly, and achieving #2 requires that developers and DBA understand concepts like compartmentalization of data, privileged context, and least privilege.

Getting developers to know these things requires that managers make these things a priority for their developers to learn – something that has not happened.