This post is in response to a buddy of mine's, Martin McKeay over at the "Network Security Blog". He has a post entitled "Is Twitter a risk?". Well, of course Twitter is a risk. Of course Email is a risk, of course "X" is a risk! Everything is a risk, but you have to get to a point where you have to do the balancing act between what is allowed and what isn't allowed. If you won't want to allow Twitter in the work place, then there are many ways to ban things like that (websense, proxies, etc). I don't want to pick on Twitter, because I am on Twitter. But any "Service" is going to pose a risk.
Heck, SSH at my house poses a greater risk than anything I can post on Twitter. You know how much data one person who knew what to do could offload from your corporation to their house via SSH? The possibilities are endless.
At some point you prevent your employees from doing bad things, at some point you prevent your employees from doing things to your networks, and other people's networks. But at some point you have to invest a certain amount of trust in users. And I know people are going to disagree with me and say "never trust your users!". Which, is mostly a good philosophy, but it's a delicate balancing act. Where do you draw the line?
Subscribe in a reader
Going from private sector, to DoD, and now back from the Third Reich I can say user education rests solely on those who want their network/resources in better shape than they currently are. It's pretty easy to say a lot of the mantras and perscribed diatribes that accompany most IT/Security positions, however, it's much more fulfilling and ultimately better business practices to develop policy, educate, and enforce. Sure, you wont hit everyone, nor should you expect to. You will provide your network and your user base more functionality at the cost of peace of mind. Yeah, I can dig on that.
I left the same comment below on the blog posting you referenced.
The technology itself is not a risk. The loss forms that can result via use of the technology is where risk (exposure to loss) comes into play. For example, in the context of unauthorized / malicious data leakage, a company would need to:
1. Determine which internal employees / contractors could be threat agents (or part of threat community).
2. Understand & evaluate its existing security controls.
3. Estimate how often these threat agents attempt to disclose data
4. Estimate how often the threat agents are successful (are able to overcome the security controls).
5. Estimate the amount of damage – in terms of dollars – the company has incurred.
Within the information security profession, we tend to use the term risk – whether unintentionally or intentionally - as a placeholder for components that actually make-up risk – all to often to reflect the vulnerability aspect of a given technology or practice without fully understanding the risk.
I highly recommend the FAIR methodology (http://www.riskmanagementinsight.com/) for better understanding the elements that make up risk but for also trying to quantify risk.
Post a Comment