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

3/25/2013
01:21 PM
Gunnar Peterson
Gunnar Peterson
Commentary
50%
50%

Putting Out Fires With Gasoline

Spending for security and identity products is going up, but here is a sobering thought that should give you pause--our solutions may be part of the problem

How many legs does a three-legged dog have if you call a tail a leg? It still has three legs, just because you call a tail a leg does not make it a leg.

Complexity is security's biggest enemy. This adage is as old as information security itself. But stop and think about a typical enterprise: sure, they have databases, customer apps, Web apps, messaging systems, app servers, and a boatload of custom code, and all those systems create a lot of work for security teams that have to harden them for production use. However, those systems are not the most complex in the enterprise. Ask yourself - is there anything more complex in your enterprise than Kerberos or PKI or any number of security and identity protocols?

Complexity is security's biggest enemy, and yet the security mechanisms themselves are the most complex parts of the enterprise. This simple, sobering thought explains so much of security's struggle. We identify problems in some complex app, but the controls introduce yet more complexity (and a whole series of unintended consequences brought on by the interaction of two or more complex systems). Infosec is good at locating fires, problem is we're pouring gas on the fire when add yet more complexity.

The security industry has identified numerous problems in applications and servers, but the security controls brought in to remediate these issues, well, where did they come from? They did not emerge from a mountaintop in Switzerland where all the keys to perfect programming are known. Frequently they were written by the same companies and even teams who wrote the other products we're trying to protect. Often they run inside the same server code.

Even when the security products are written by a different vendor there is no particular evidence that they raise the bar in overall security. In fact they may lower it.

Veracode's State of Software Security report showed that security products have the most insecure code of all product types! Worse than learning systems, worse than customer support, worse than operations. This is a message that deserves to be told again and again. Just because you call your product a security product does not mean its adding security, it may be subtracting security.

It's even worse than that because when an isolated app fails, you have an isolated failure in which you can hopefully contain the fallout. But when a security or identity system fails, the damage is potentially widespread. Contagion, if you will. Your access management system that does authentication across 27 apps: what happens if it fails? Suddenly 27 apps have inherited a big problem.

The typical security engagement goes something like this:

    1. App team reviews project with security team
    2. Security team does risk and vulnerability assessment
    3. Security team recommends controls to address findings
    4. App Team implements controls
That is fine as far as it goes, but needs two important steps
    0. Dogfooding - Security team vet, extensively test, risk and vulnerability assessment on all controls in security architecture
    1. App team reviews project with security team
    2. Security team does risk and vulnerability assessment
    3. Security team recommends controls to address findings
    4. App Team implements controls
    5. Security team tests the composite of its own recommendations once integrated with the app
To me, step 0 dogfooding is very important for the security team to build credibility, it should hold its own products to a higher standard than it holds its own app devs too. Simply put, the risk is higher. Unfortunately, the situation today is security products are deployed with less not more security.

As for step 5, there is no replacement for a synthetic test to identify weaknesses in the ways the different parts are integrated. This is essential. App development teams take it for granted that they have unit test code for all functionality. Security teams often throw stones at methodologies like Agile, but say this for Agile - they got the importance of testing. Do most companies have similar rigor for automated test suites on the identity and access management systems that provide access control across all users? In a word, no.

Your next Security Development Lifecycle target should not be your company's next big application project, it should be your security and identity products themselves. For those products - how much did you trust versus how much did you verify? Security, heal thyself.

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

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
ANON1248837340478
50%
50%
ANON1248837340478,
User Rank: Apprentice
3/25/2013 | 8:21:32 PM
re: Putting Out Fires With Gasoline
Security vendors are often no help, especially with their web-based product consoles. If I had a dollar for every admin console with a XSS or SQLi vulnerability, that did not allow the use of SSL, or only allowed it with a self-signed certificate, I'd easily have another $25 or so. That's $25 too much. And that's just scratching the surface.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/2/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9498
PUBLISHED: 2020-07-02
Apache Guacamole 1.1.0 and older may mishandle pointers involved inprocessing data received via RDP static virtual channels. If a userconnects to a malicious or compromised RDP server, a series ofspecially-crafted PDUs could result in memory corruption, possiblyallowing arbitrary code to be executed...
CVE-2020-3282
PUBLISHED: 2020-07-02
A vulnerability in the web-based management interface of Cisco Unified Communications Manager, Cisco Unified Communications Manager Session Management Edition, Cisco Unified Communications Manager IM & Presence Service, and Cisco Unity Connection could allow an unauthenticated, remote attack...
CVE-2020-5909
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, when users run the command displayed in NGINX Controller user interface (UI) to fetch the agent installer, the server TLS certificate is not verified.
CVE-2020-5910
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the Neural Autonomic Transport System (NATS) messaging services in use by the NGINX Controller do not require any form of authentication, so any successful connection would be authorized.
CVE-2020-5911
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the NGINX Controller installer starts the download of Kubernetes packages from an HTTP URL On Debian/Ubuntu system.