All posts tagged compliance

This week the US senate was exposed to a security report that spoke about a BGP Hijacking event that occurred in April 2010. It is all over the wires that there are claims that China “stole 15% of the Internet” – for 18 minutes – with China unsurprisingly denying these allegations.

While the politicians prattle on about whether or not China is stealing Internet traffic or if this was a geniunly innocent error, I am more interested in the fact that scaremongers talk about how “Experts fear sensitive data, such as the contents of email messages, could have been seen and viruses implanted”.

BGP hijacking is an old problem (the earliest referenced at WikiPedia was in 1997) and has been in use, albeit on a smaller scale, by spammers and malware writers for a long time already. This 2006 paper by Anirudh Ramachandran and Nick Feamster, discusses in detail how spammers use BGP hijacking to create short lived networks that have IP addresses not yet seen by any of the RBL services.

So why is such an old and well known problem still causing so much consternation?

I believe that it is because this is the first time most companies have really understood the potential ramifications of not securing their transmissions. Everybody knows that sending data across public infrastructure is dangerous, and what we’re seeing here is one huge, indiscriminate risk that could expose your organizations intellectual property quite by chance!  It highlights that you don’t actually need to be the target of such an event in order to expose sensitive information; just in the wrong place at the wrong time.

Because of risks like this, encryption standards like TLS (Transport Layer Security) have become much more widely adopted over the past few years and various institutions have imposed encryption requirements on parties with whom they may share sensitive information.  Any encrypted transmissions captured during a BGP hijacking would be useless without a costly and time-consuming cryptographic effort to decrypt it…

All of which makes it doubly important that we make use of the technologies that are available to us. Use your DLP (Data Leak Prevention) system to ensure that nothing leaves your control that shouldn’t, and use encryption standards like TLS to ensure maximum coverage for any data that does have to traverse the public Internet.  And NEVER submit private information to unsecured websites.

Add your comment (0)

Enterprise Consultant
Mimecast

Article Tags

, ,

Some of you have the luxury of a regulation that ‘dictates’ what you should retain and for how long; unfortunately many are not so lucky. The great unregulated masses are looking for answers, answers that are still defined as, alarmingly, grey areas. Let’s face it; when you are retaining data you’re worried, and when you’re not retaining it you’re worried that perhaps you should be.

Retention- A dam holding back water

The struggle

Retention whether driven by regulation, policy, mandate or ego has been a struggle and if you’re trapped under the deluge of data (especially email) you have my sympathy, I’ve been there too. Probably the most tricky situation to deal with, is when you’re working with an unclear retention policy.

Often I find IT managers and CIOs adhering to email retention guidelines handed down to them by a lawyer rather than a technologist; and all too often the policy is trying, and failing, to balance risk against reward and, perhaps legal protection. Added to this complex advice on retention the CIO has to build a solution that fits and remains in budget, budget of course that is never based on an oft overlooked metric – VOLUME!

I would suggest that predicting how much email your users will send in the next ten minutes is hard, predicting that volume for the next ten years is almost impossible.

Good luck planning your hardware budget for that. Perhaps attempting to save cost on hardware is one of the reasons why retention policies can be so diverse, even within the same organization?

I think the uncertainty surrounding email retention will remain, I say this because I often find different retention policies in organizations regulated by the same authority – like I said; alarming, and open to legal interpretation.

It is estimated that this year mankind will create 1200 Exabyte’s (billion GB)  of information, and that’s up from 150 Exabyte’s five years ago; with that growth we’re all going to need a lot more disk to cope with our insatiable appetite to hold onto the past.

Disk may be cheap, but do you really want the hassle?

Retention policy or not, your users are going to keep on generating data. A clear, plain English, succinct and unambiguous policy makes life easier but you’re still going to retain the data.

Retention is here to stay, so everyday is a the start of a new five/seven/ten/many years (delete as necessary) for your data, whether driven by a policy or not. We should be thinking about this as a forever-project rather than a five/seven/ten/many year retention project.

Add your comment (0)

CISSP, CCSK
Mimecast, North America.