Over the last decade, the responsibility for securing Business Applications has unnaturally shifted towards the Security organization. The idea is that a central group with a holistic approach and a SIEM can defend better. This shift of gravity towards centralized Security requires more resources in the Network and Security space, but as is so often the case, the additional responsibility does not come with additional resources. Security teams remain on tight budgets like everyone else. This impacts how effective they can be when spread so thinly. Results range from internal approval delays for everyday requests to projects on hold. A central security program must triage and rank priorities based on much more than just risk. We created our own bottleneck.
How does centralization of security map to the goals of the business? Frequently it does not. Application owners are the true business owners, and have their own strategic roadmap for delivering the services which contribute to the company’s productivity. The availability and reliability of these applications is their primary objective. They are the ones that must make the case for budget and staff. They handle technology refresh and acquisition, work with the Server and Storage groups, but for some reason Security is special. Perhaps some kind of hacker voodoo factor.
As opposed to behaving as if securing applications were an arcane voodoo for the elite, Security needs to be something that we run as a commodity with very real statistically viable metrics which show trends, progress, and regress. To do this, the center of gravity needs to shift slightly outwards so that the Business Application owners take on more responsibility for securing what is ultimately theirs. Security must intelligently emancipate them and in the process enable them. I am not suggesting by any means that we simply let the patients run the asylum.
What I am suggesting is taking the first steps towards implementing Security as a service. The Business Application owners and their staff are specialists who know their applications inside and out. What they need is support in an area that is outside of their direct field of expertise. Helping them define their own security-oriented SLA to which they should adhere, and assign themselves yearly targets actually helps them meet their own objectives. In other words, the application owners set the bar for themselves, and then they work with the Security team to achieve it.
This approach turns the tables and should foster a more symbiotic relationship. Traditionally, Security has been viewed as the group to say “no” which has formed a sort of opposition paradigm. In a best case scenario, perhaps a dependent situation in the face of door rattling teams of hackers. What I am suggesting puts the decision making power back where it ought to be, but in a framework of assisted self-control based on achieving the yearly goals.
Those of you experienced in organizational change management, virtual teams, and running something as a service could probably get going right away, but for the rest of the readers I will give some suggestions for how to get a program like this going in my next post. Stay tuned for Part 2.
Receive notifications of new posts by email.