Perimeter
10/25/2012
12:06 PM
Mike Rothman
Mike Rothman
Commentary
50%
50%

Making Security Trade-Offs

Security is all about the trade-offs. You need a consistent method to evaluate risks and assess the pros/cons of each decision

I recently saw a research report from another analyst firm that espoused the benefits of application whitelisting (AWL). You know, the technology that defines a list of applications that are allowed to run on an endpoint and blocks anything else. It's basically default deny for endpoint devices. In concept, AWL is a great idea. Most malware probably isn't authorized to run (compromised Windows or Adobe updates excepted), so locking down the device can prevent many malware infections.

But there is a downside to AWL. It breaks lots of stuff. Sometimes workers need to run something not authorized. They may even have a business need to do so. Giving a user a grace period makes the technology usable, but clearly impacts the security model.

So AWL involves making a trade-off. Obviously, you can favorably impact your security posture by locking down the endpoints. But you also run the risk of alienating users and impacting their productivity. Is it worth it? That's actually a pretty complicated question without an easy answer. Even better, it can only be answered by you (and your organization). And I'm not picking on AWL here -- every security control requires some kind of trade-off.

Let's look at next-generation firewalls (NGFW) with the shiny, new capability to enforce application-oriented policies. Is it a risk to have employees use Dropbox? Yup. Can you stop it using an NGFW? Yup. Will the powers that be support that decision? Maybe. Dropbox and other cloud storage offerings provide tremendous value in facilitating collaboration, and that may be worth the risk of having data in a shared environment where Dropbox employees can access it (under subpoena, of course).

It's not malicious. Your employees just want to do their jobs. And you want to do yours, which can be at odds every so often. An employee may want to access his Facebook wall, but you may believe it's an unnecessary risk. How do you say no without being the person who always says no? You need a way to assess the risk, weigh the trade-offs, and make these tough decisions. More importantly, you need to use the method consistently to eliminate any perception of bias or unfair practices.

I'd start the process by requiring some kind of formal request from the employee. You know, make them jump through a hoop to see if he really wants it. The request should provide information on the application in question, as well as the business justification for installing it. Once you get that, then you can start your side of the analysis. Check out your favorite search engine and see if there are known security issues with the app or device. Check it out and see what it does. Maybe monitor outbound network traffic to see what the application really does and where it sends data. If you are going to say no, you need to have your ducks in a row.

Next you'll want to define an escalation process, so when you want to say no and the employee doesn't like that answer, there is someone to make the decision. Does this escalation need to be a formal process? Probably not. You don't need to contract with a retired judge to arbitrate the value of Facebook Chat. But you want to make sure the employee doesn't just go over your head without some structure to how that escalation happens and who gets to make the decision.

Once you've defined your process, you'll need to communicate it to the masses. If you are going to have the ability to say no, then you better make sure everyone understands how they can get you to yes. Whether it's part of awareness training or maybe as part of your periodic security newsletter, your employees need to understand the process to get new capabilities approved or devices onto the network.

I also recommend you get ahead of the process a bit by making decisions on applications or capabilities you know are going to come up. You know, things like BYOD, Facebook, Twitter, or the aforementioned Dropbox. Do you allow it? If so, when and why? What's the process to gain approval? Can you provide an alternative that provides better security? Those are the kinds of questions you need to be able to answer.

One more thing to mention. There is a real risk to having a consistent, fair process, and that's the reality that not all of the decisions will go your way. You will end up with stuff on your network that you don't want. But that's not a bad thing. Remember, security is a game of perception and influence. Protecting information tends to get in the way of business. So by making employees justify what they want to do and giving you an opportunity to go on record with concerns, you may end up surviving the inevitable train wrecks. And that's a trade-off you can probably live with.

Mike Rothman is president of Securosis and author of The Pragmatic CSO. Mike's bold perspectives and irreverent style are invaluable as companies determine effective strategies to grapple with the dynamic security threatscape. Mike specializes in the sexy aspects of security, like protecting networks and endpoints, security management, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Bryan Yurcan
50%
50%
Bryan Yurcan,
User Rank: Apprentice
11/19/2012 | 4:38:31 PM
re: Making Security Trade-Offs
Interesting viewpoint, well-written
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
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-1421
Published: 2014-11-25
mountall 1.54, as used in Ubuntu 14.10, does not properly handle the umask when using the mount utility, which allows local users to bypass intended access restrictions via unspecified vectors.

CVE-2014-3605
Published: 2014-11-25
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2014-6407. Reason: This candidate is a reservation duplicate of CVE-2014-6407. Notes: All CVE users should reference CVE-2014-6407 instead of this candidate. All references and descriptions in this candidate have been removed to pre...

CVE-2014-6093
Published: 2014-11-25
Cross-site scripting (XSS) vulnerability in IBM WebSphere Portal 7.0.x before 7.0.0.2 CF29, 8.0.x through 8.0.0.1 CF14, and 8.5.x before 8.5.0 CF02 allows remote authenticated users to inject arbitrary web script or HTML via a crafted URL.

CVE-2014-6196
Published: 2014-11-25
Cross-site scripting (XSS) vulnerability in IBM Web Experience Factory (WEF) 6.1.5 through 8.5.0.1, as used in WebSphere Dashboard Framework (WDF) and Lotus Widget Factory (LWF), allows remote attackers to inject arbitrary web script or HTML by leveraging a Dojo builder error in an unspecified WebSp...

CVE-2014-7247
Published: 2014-11-25
Unspecified vulnerability in JustSystems Ichitaro 2008 through 2011; Ichitaro Government 6, 7, 2008, 2009, and 2010; Ichitaro Pro; Ichitaro Pro 2; Ichitaro 2011 Sou; Ichitaro 2012 Shou; Ichitaro 2013 Gen; and Ichitaro 2014 Tetsu allows remote attackers to execute arbitrary code via a crafted file.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?