Perimeter
1/8/2013
12:44 PM
Gunnar Peterson
Gunnar Peterson
Commentary
50%
50%

What Is It You Would Say That You Do Here?

Here is a dangerous question to start the new year: Does your company actually need a security department? If you are doing CYA instead of CIA, the answer is probably no

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.

    Security: "You really should not do that."
    Dev: "We are doing it anyway."
    ... things go bad ...
    Security "I told you so."

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.

    "You see, BYOD is actually a user-led rebellion against poor IT practices, inflexibility, and infosec autocracy -- @selil

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 Gunnar Peterson (@oneraindrop) works on AppSec - Cloud, Mobile and Identity. He maintains a blog at http://1raindrop.typepad.com. View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-8891
Published: 2015-03-06
Unspecified vulnerability in the Java Virtual Machine (JVM) in IBM SDK, Java Technology Edition 5.0 before SR16-FP9, 6 before SR16-FP3, 6R1 before SR8-FP3, 7 before SR8-FP10, and 7R1 before SR2-FP10 allows remote attackers to escape the Java sandbox and execute arbitrary code via unspecified vectors...

CVE-2014-8892
Published: 2015-03-06
Unspecified vulnerability in the Java Virtual Machine (JVM) in IBM SDK, Java Technology Edition 5.0 before SR16-FP9, 6 before SR16-FP3, 6R1 before SR8-FP3, 7 before SR8-FP10, and 7R1 before SR2-FP10 allows remote attackers to bypass intended access permissions and obtain sensitive information via un...

CVE-2015-1170
Published: 2015-03-06
The NVIDIA Display Driver R304 before 309.08, R340 before 341.44, R343 before 345.20, and R346 before 347.52 does not properly validate local client impersonation levels when performing a "kernel administrator check," which allows local users to gain administrator privileges via unspecified API call...

CVE-2015-1637
Published: 2015-03-06
Schannel (aka Secure Channel) in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 does not properly restrict TLS state transitions, which makes it easier for r...

CVE-2014-2130
Published: 2015-03-05
Cisco Secure Access Control Server (ACS) provides an unintentional administration web interface based on Apache Tomcat, which allows remote authenticated users to modify application files and configuration files, and consequently execute arbitrary code, by leveraging administrative privileges, aka B...

Dark Reading Radio
Archived Dark Reading Radio
How can security professionals better engage with their peers, both in person and online? In this Dark Reading Radio show, we will talk to leaders at some of the security industry’s professional organizations about how security pros can get more involved – with their colleagues in the same industry, with their peers in other industries, and with the IT security community as a whole.