On a fairly regular basis, I get messages and emails asking my opinion on how to include security into the Agile framework. I’m not a real big believer in the Agile approach for the simple reason that I’ve found, through multiple experiences, that people that talk Agile are more often than not talking about doing things quickly and not well. So it begs the question – is there a way to deliver security projects faster?
Now, I want to be clear about where I stand on a few things. First, I fully believe that if you don’t get the requirements correct right at the beginning of a project, the missing elements or the improper requirements will propagate through your project and result in a project that doesn’t meet what the stakeholders need.
I’ve also had a great deal more experience with a Waterfall approach to delivering projects than with the Agile methodology. I’ve found that having checks and balances in a project is important to ensure that a project is being delivered properly. It goes with the old saying that “if it’s important, you should be able to measure it”. Using gates as checkpoints in a project are, for me, a necessity to ensure that a project is moving in the right direction.
But I also believe that the waterfall approach tends to layer on bureaucracy. At the end of the day, if you spend more time documenting and doing bureaucratic things than actually delivering a project, the focus shifts away from the main goal of the project. A project is about results, not secondary activities such as status reports and sitting in meetings.
When I created my Reference ENTERPRISE Architecture, I came to realize that there are primary services and secondary services. Primary services are those that focus on the core activity of a business and Secondary services are services that support the Primary service. IT organizations tend to forget that they are there to focus on supporting whatever the core activity of the company and not focus on Secondary services or even itself. So, looking at a Project, the core activity is to DELIVER. The primary supporting services for that project would be the people that actually do things that deliver for the Project like implementing servers, getting network connectivity, and creating applications. Secondary services are those things that support the supporting services, such as reporting, organizational administration, and (sorry) project management oversight.
For security people out there, the same goes for what you do. Remember, a project is there to DELIVER. A security organization is there to support the project. So they need to streamline things to the point where it takes no time to get things done. If a company wants a project, it’s important to ensure that the risks are communicated BEFORE the decision is to go forward. Then you use a standardized process to deliver security as quickly and as efficiently as possible.
Security is interesting because you can have a Security project as the core activity where you may be implementing a security technology, you can have security activities as a primary supporting service such as creating roles and accounts and provisioning, and you can have security activities as a secondary supporting services such as doing vulnerability scans of implemented infrastructure. It’s important to not confuse those activities and remember that it’s the stakeholders that say what is a primary support service and what a secondary service is.
So, how to deliver security projects faster? Do two things; first, reduce the bureaucracy so you can focus on what the core activity is and, second, recognize what activities are truly supporting core activities and what is just a secondary service.
Hope that helps …