Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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
Comments
Threaded  |  Newest First  |  Oldest First
Aviation Faces Increasing Cybersecurity Scrutiny
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/22/2019
Microsoft Tops Phishers' Favorite Brands as Facebook Spikes
Kelly Sheridan, Staff Editor, Dark Reading,  8/22/2019
MoviePass Leaves Credit Card Numbers, Personal Data Exposed Online
Kelly Sheridan, Staff Editor, Dark Reading,  8/21/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2016-6154
PUBLISHED: 2019-08-23
The authentication applet in Watchguard Fireware 11.11 Operating System has reflected XSS (this can also cause an open redirect).
CVE-2019-5594
PUBLISHED: 2019-08-23
An Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting") in Fortinet FortiNAC 8.3.0 to 8.3.6 and 8.5.0 admin webUI may allow an unauthenticated attacker to perform a reflected XSS attack via the search field in the webUI.
CVE-2019-6695
PUBLISHED: 2019-08-23
Lack of root file system integrity checking in Fortinet FortiManager VM application images of all versions below 6.2.1 may allow an attacker to implant third-party programs by recreating the image through specific methods.
CVE-2019-12400
PUBLISHED: 2019-08-23
In version 2.0.3 Apache Santuario XML Security for Java, a caching mechanism was introduced to speed up creating new XML documents using a static pool of DocumentBuilders. However, if some untrusted code can register a malicious implementation with the thread context class loader first, then this im...
CVE-2019-15092
PUBLISHED: 2019-08-23
The webtoffee "WordPress Users & WooCommerce Customers Import Export" plugin 1.3.0 for WordPress allows CSV injection in the user_url, display_name, first_name, and last_name columns in an exported CSV file created by the WF_CustomerImpExpCsv_Exporter class.