Skip to main content

Is "X" a security risk?

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.
Chris Hayes said…
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 ( for better understanding the elements that make up risk but for also trying to quantify risk.

Popular posts from this blog

Offset, Depth, Distance, and Within

Without going off the deep-end here and discussing every single Snort rule keyword, I just wanted to touch on a few modifiers that people sometimes misunderstand.  They aren't difficult, and hopefully after this explanation and a few examples, I can clear some of the air around these five modifiers.

The five modifiers that I am talking about are
OffsetDepthDistanceWithinnocaseThese five modifiers are not keywords of themselves, but rather they apply as modifiers to another keyword.  That keyword is "content". The content keyword is one of the easiest pieces of the Snort rules language as all it does is look for a particular string.  So for instance if I wanted to look for the word "joel" within a packet.  A simple:
content:"joel";Would allow me to do that.  The interesting part comes into play when you want to specify where inside of a particular packet you want the string "joel" to be looked for.  If you are running just a plain content ma…

Writing Snort Rules Correctly

Let me start off by saying I'm not bashing the writer of this article, and I'm trying not to be super critical.  I don't want to discourage this person from writing articles about Snort rules.  It's great when people in the Snort community step up and explain some simple things out there.  There are mistakes, it comes with the territory.  If you choose to be one of the people that tries to write Snort rules, you also choose to be someone who wants to learn how to do it better.  That's why I write this blog post, not to bash the writer, but to teach.

I noticed this post today over at the "Tao of Signature Writing" blog, and to be honest I glanced over most of it figuring it was a rehash of things I've already read or things that have already been written from countless people about "Here's how you write Snort rules!".  I scrolled down quickly skimming, not reading at all really, and noticed this part:
Now, let us look at the second questio…

Safari 5.1.4 now available

Safari 5.1.4 now available, fixes issues and improves performance | TUAW - The Unofficial Apple Weblog:

Improve JavaScript performanceImprove responsiveness when typing into the search field after changing network configurations or with an intermittent network connectionAddress an issue that could cause webpages to flash white when switching between Safari windowsAddress issues that prevented printing U.S. Postal Service shipping labels and embedded PDFsPreserve links in PDFs saved from webpagesFix an issue that could make Flash content appear incomplete after using gesture zoomingFix an issue that could cause the screen to dim while watching HTML5 videoImprove stability, compatibility and startup time when using extensionsAllow cookies set during regular browsing to be available after using Private BrowsingFix an issue that could cause some data to be left behind after pressing the "Remove All Website Data" button