What Is It You Would Say That You Do Here?

Don't take it personally: It's a fair question. Economic times are tough, companies run lean and mean, and there should be a value proposition to support any company expense.

Even in the face of some harsh budget cuts, for the most part spending on security keeps going up. But is this wise? Would it be better to cut the infosec budget? Say, to zero?

In terms of how many infosec departments operate, the answer is probably yes.

The reason why is about value to the enterprise. Unfortunately, many security departments do not provide much security at all and instead operate as giant policy-exception machines slowing down development and operations -- adding little security at all.

The oft-repeated relationship between many security teams and development groups is filled with tension. The development team is trying to ship features A, B, and C. The security team says no way. A stand-off ensues.

Then you get the three Es of infosec: The dev team escalates to its executive and plays the age-old game of "my development VP beats your security VP." Then the security team issues the exception to go ahead. What value was created here? The dev team was merely slowed down; that's not the famous CIA of Infosec: It's the three Es, and they equal negative value.

Security is supposed to be confidentiality, integrity, and availability, but the escalation to an executive for exceptions is not security -- it's a CYA exercise. Worse yet, it's a CYA exercise that impinges on other people's ability to deliver.

Nice work if you can get it. (Well, as long as you don't care about building anything.)

Why Does This Happen?
Like many problems, it begins with policy. Most information security policies are north of 100 pages, and never read even by their "authors." Worse yet, for most security policies there is no possible way to achieve the goals; there are no mechanisms, processes, and tools to realize the goals in the policy. Whether the policy defines judicious goals or not is irrelevant if you cannot deliver on the goals in the first place.

The current infosec holy war is against BYOD. But to frame the issue as users versus security is to miss the point.

As its relates to policy, the first and most important step is for infosec to hold itself accountable -- meaning writing an effective, pragmatic, and short policy -- before holding everyone else accountable to its policy. A simple rule of thumb: If you cannot deliver on the goals in the policy today with readily available tools, process, and personnel, then remove the policy statement. You are wasting people's time and the company's money.

Security people love to pull from math and physics. If we want to continue to exist, then we need to learn more from biology. Charles Darwin had an average IQ and became a world changing scientist not through any particular genius. He held himself to a rigorous standard, wearing an intellectual hairshirt, and he was always most suspicious of his own ideas.

This is the opposite of how most security teams operate.

What Is Better?
The policy should be fixed to start not because it's the end game, but because it sucks up resources and wastes time. Policies are mainly a hodgepodge of "best practices" and whatever the auditors over the past few decades said to write.

A better way is to start by finding diamonds in your own backyard. It's shocking, but right now somewhere in your company many things are working and even being done properly from a security perspective. So step 1, delete your old policy; step 2, find the things that are working right now in the real world; and step 3, codify these as the starting point for your policy and build on it from there. Hold to the simple rule that every policy item must be backed by an existing development and/or operational skill set, process, and/or tool set. It's not about auditor least-privilege theory -- it's about what's proved to work at your company.

Once the policy view is cleaned up, the infosec team can begin the hard but important work of building in security. To ensure the infosec teams increase the level of CIA in your company instead of just generating policy exceptions means engaging in the full life cycle -- architecture, design, development, deployment, and operations. Like most important issues, this is a simple concept but not easy to execute.

Identity and access management (IAM) projects and architecture are rarely cost-effective in the context of a single project. Heck, even the shining star of IAM, SSO, is only useful with more than one app -- otherwise, it's not Single Sign On, it's just login! One of the great values of infosec is that it has excellent visibility across multiple projects. Patterns can emerge, both good and bad. This visibility is an underutilized asset in infosec today; it's the diamond in infosec's own backyard if we choose to think and act more as builders and not only auditors.

The OWASP Top Ten has largely not changed over the past decade. We are still living with the problems of 2001 and before. Why? Six of the OWASP Top Ten are directly related to IAM weaknesses. Infosec teams are today in a position to identify solution patterns to address these weaknesses across projects, but doing so requires getting out of policy exception mode and into architecture, development, and deploy mode.

Otherwise, why have a security department at all?

Gunnar Peterson is a Managing Principal at Arctec Group