Perimeter
10/25/2012
12:06 PM
Mike Rothman
Mike Rothman
Commentary
Connect Directly
RSS
E-Mail
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
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0485
Published: 2014-09-02
S3QL 1.18.1 and earlier uses the pickle Python module unsafely, which allows remote attackers to execute arbitrary code via a crafted serialized object in (1) common.py or (2) local.py in backends/.

CVE-2014-3861
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to inject arbitrary web script or HTML via a crafted reference element within a nonXMLBody element.

CVE-2014-3862
Published: 2014-09-02
CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to discover potentially sensitive URLs via a crafted reference element that triggers creation of an IMG element with an arbitrary URL in its SRC attribute, leading to information disclosure in a Referer log.

CVE-2014-5076
Published: 2014-09-02
The La Banque Postale application before 3.2.6 for Android does not prevent the launching of an activity by a component of another application, which allows attackers to obtain sensitive cached banking information via crafted intents, as demonstrated by the drozer framework.

CVE-2014-5136
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in Innovative Interfaces Sierra Library Services Platform 1.2_3 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.