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
Newest First  |  Oldest First  |  Threaded View
7 Tips for Infosec Pros Considering A Lateral Career Move
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2020
For Mismanaged SOCs, The Price Is Not Right
Kelly Sheridan, Staff Editor, Dark Reading,  1/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
IT 2020: A Look Ahead
Are you ready for the critical changes that will occur in 2020? We've compiled editor insights from the best of our network (Dark Reading, Data Center Knowledge, InformationWeek, ITPro Today and Network Computing) to deliver to you a look at the trends, technologies, and threats that are emerging in the coming year. Download it today!
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-8003
PUBLISHED: 2020-01-27
A double-free vulnerability in vrend_renderer.c in virglrenderer through 0.8.1 allows attackers to cause a denial of service by triggering texture allocation failure, because vrend_renderer_resource_allocated_texture is not an appropriate place for a free.
CVE-2019-20427
PUBLISHED: 2020-01-27
In the Lustre file system before 2.12.3, the ptlrpc module has a buffer overflow and panic, and possibly remote code execution, due to the lack of validation for specific fields of packets sent by a client. Interaction between req_capsule_get_size and tgt_brw_write leads to a tgt_shortio2pages integ...
CVE-2019-20428
PUBLISHED: 2020-01-27
In the Lustre file system before 2.12.3, the ptlrpc module has an out-of-bounds read and panic due to the lack of validation for specific fields of packets sent by a client. The ldl_request_cancel function mishandles a large lock_count parameter.
CVE-2019-20429
PUBLISHED: 2020-01-27
In the Lustre file system before 2.12.3, the ptlrpc module has an out-of-bounds read and panic (via a modified lm_bufcount field) due to the lack of validation for specific fields of packets sent by a client. This is caused by interaction between sptlrpc_svc_unwrap_request and lustre_msg_hdr_size_v2...
CVE-2019-20430
PUBLISHED: 2020-01-27
In the Lustre file system before 2.12.3, the mdt module has an LBUG panic (via a large MDT Body eadatasize field) due to the lack of validation for specific fields of packets sent by a client.