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

Published: 2015-03-31The build_index_from_tree function in index.py in Dulwich before 0.9.9 allows remote attackers to execute arbitrary code via a commit with a directory path starting with .git/, which is not properly handled when checking out a working tree.