Perimeter
1/8/2013
12:44 PM
Gunnar Peterson
Gunnar Peterson
Commentary
Connect Directly
RSS
E-Mail
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
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
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-2021
Published: 2014-10-24
Cross-site scripting (XSS) vulnerability in admincp/apilog.php in vBulletin 4.4.2 and earlier, and 5.0.x through 5.0.5 allows remote authenticated users to inject arbitrary web script or HTML via a crafted XMLRPC API request, as demonstrated using the client name.

CVE-2014-3604
Published: 2014-10-24
Certificates.java in Not Yet Commons SSL before 0.3.15 does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.

CVE-2014-6230
Published: 2014-10-24
WP-Ban plugin before 1.6.4 for WordPress, when running in certain configurations, allows remote attackers to bypass the IP blacklist via a crafted X-Forwarded-For header.

CVE-2014-6251
Published: 2014-10-24
Stack-based buffer overflow in CPUMiner before 2.4.1 allows remote attackers to have an unspecified impact by sending a mining.subscribe response with a large nonce2 length, then triggering the overflow with a mining.notify request.

CVE-2014-7180
Published: 2014-10-24
Electric Cloud ElectricCommander before 4.2.6 and 5.x before 5.0.3 uses world-writable permissions for (1) eccert.pl and (2) ecconfigure.pl, which allows local users to execute arbitrary Perl code by modifying these files.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.