Risk
1/13/2014
11:06 AM
Calum MacLeod
Calum MacLeod
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
100%
0%

Why IT Security RFPs Are Like Junk Food

Buying the latest security technology won't save you if your company isn't carrying out basic health checks.

As Woody Allen once said, "I'm not afraid of death; I just don't want to be there when it happens." Sometimes I think the approach of the average board of directors is the same when it comes to investing in information security; they’re worried about being breached and just hope it doesn’t happen while they're in the job. But naturally the question is whether investment is the only course of action.

Like my health, I can either cut down on bad cholesterol or I can spend money on medication that will supposedly do it for me, and allow me to continue my bad habits. But the sad reality is that medication alone is not going to keep me alive and healthy.

The same applies to IT security. Buying the latest technology is not going to save you if you are not carrying out basic health checks in your organization. As an example, in my role at Lieberman Software, when I talk with customers who are concerned about APTs or malware, their response seems to be to buy whatever is touted as the latest and greatest solution.

It's like an obese person drinking only diet beverages while still consuming too much food. Regardless of what technology they buy, the failure to carry out basic internal security checks means they are just as vulnerable. And like the obese person, they know what they need to do but it’s just too hard.

How many IT departments control the passwords being used by administrators and yet fail to do the same for services, scheduled tasks, and other applications that use credentials? Organizations fret about their private keys being stolen and used in malware but then don’t enforce any security policy around the protection of keys. Organizations allow hundreds, and in some cases thousands, of employees to have privileged access to their PCs because it is easier than enforcing a policy that demands permission to install software. Yet how many organizations regularly check the registries of their workstations to see if anything has been added or modified?

The placebo effect
Today, more often than not, security related projects usually start off with a failed audit – the equivalent of a sharp pain in the chest. This is usually a result of bad habits that have developed over the years. You would think that the patient (management) would rush to the hospital to make sure everything is fine. Yes it is inconvenient, but surely you don’t want to take risks?

The reality is different. What management generally does is

  • Call in the consultants who frequently have no practical experience; 
  • Consult industry reports which frequently are not much more than regurgitated marketing material from a variety of vendors.

The result is frequently an RFP that consists of little more than a list of irrelevant questions. This is then sent to a group of vendors who promise to cure all diseases for the lowest possible cost. It's little more than a placebo. Actually I've come to realize more and more that most technology seems to be little more than a placebo -- in other words you will feel better for taking the stuff that you buy, but it probably won't do you much good. You might as well start browsing health websites when you have a heart attack, put together a questionnaire and send it off to several hospitals, and see what they offer as a solution.

Too many organizations have learned through bitter experience that implementing a privileged identity management solution is too important a process to delegate to a rubber-stamp RFP or a battle of vendor checkboxes. If handled correctly your implementation can help you close critical security loopholes; help make staff members accountable for actions that impact IT service and data security; and lower the cost of regulatory compliance.

You'd never choose a doctor based solely on cost, nor would you trust a physician who writes a prescription before taking the time to diagnose your condition, check your medical history, and perhaps run some tests. Maybe the time has come to treat your IT security like your personal health. After all, when you’re in the operating theater it is comforting to know that you're neither the guinea pig for a first-time surgeon, nor the patient keeping them from their next round of golf!

Calum MacLeod has more than 30 years of experience in secure networking technologies and is currently responsible for European business development at privileged identity and security management provider Lieberman Software.

The complexity of enterprise IT systems and processes is growing, as are threats against organizations’ assets. Unfortunately, security budgets are not. Security pros must therefore play a high-stakes game of figuring out which problems to tackle and in what order. In this Dark Reading report, Using Risk Assessment To Prioritize Security Tasks And Processes, we explain how risk assessment techniques can inform the process of prioritizing security tasks and processes, and recommend steps security pros can take to apply data based on their own enterprise's risk profile. (Free registration required.)

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
1/13/2014 | 5:15:30 PM
Where's the beef in your vendor security RFPs?
Are you getting the most out of your security vendors from the request for proposal process? Let's chat about your greatest successes -- and worst failures. 

 

 
Stratustician
50%
50%
Stratustician,
User Rank: Moderator
1/20/2014 | 2:05:54 PM
*sigh*
I personally like to think of RFP to stand for "Request for Punishment" since honestly, especially when it comes to security, it's really a crapshoot.  For one, as pointed out, half the time the request is a laundry list of things they'd love to see, but really unless you have the right people writing these things, half of them are really not going to solve the problem that they are really trying to solve.  It's a "tell me what you have to fix this problem, but we're not going to tell you what the problem is".  Often they are looking for solutions that they've heard are the latest and greatest and will solve all their woes, but even if the right product is positioned (Huzzah!), cost is often such a critical component that it doesn't matter anyway.  Not to mention that half these RFPs are written in conjunction with a vendor who can conviently bid on it.  It's such as strange process, that really, needs to be overhauled.
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
1/22/2014 | 9:35:48 AM
Re: *sigh*
@stratustician What are some of the most egregious items that you've seen in RFPs and if it was up to you, how would you overhaul the process to make it  credible?
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.