Shadow IT

Have you heard of Shadow IT? Do you worry about it?

Many organisations have a defined IT policy and processes surrounding it. They may outsource provision to a Third Party, or they may have their own IT department, even if that’s just Billy sitting in the corner, who is totally self taught.

The organisation may have a standard build for all their equipment, and may use only one brand of equipment, which should make managing security risks quite well defined and limited.

However, there may be individuals or whole teams that don’t use the company standard. There might be an MD who really wants to do everything on a tablet device, but the company has a strict “no tablet” policy. There might be a team that installs its own network connection “just in case the company one fails”. And then there’s George in Marketing who prefers to use his Mac to the standard Windows machines.

The MD goes ahead and connects her tablet to the corporate network. The team with their own network connection leave it live and accessible 24×7: there’s no firewall and no way of blocking traffic coming in or going out. George brings in his own Mac and plugs it in to the network. None of these involve the IT or security teams, consequently the risk is unknown and therefore not managed.

These are all examples of Shadow IT – the unknown equipment attached to the corporate network which has little or no security controls in place. Many organisations have a problem with the proliferation of Shadow IT devices.

I think that we’re rapidly approaching – or may already have passed – the moment when we have to stop thinking of it as Shadow IT, and makes sure that our controls can take the plethora of unofficial devices and configurations.

For example, it may be prudent to create a kind of “internal guest network”, for non-standard / uncontrolled devices. This could be easy to connect to but provides an additional layer of control. Using some kind of Mobile Device Management (MDM) solution allows you to provide some services to personal mobile devices, while also giving the ability to remotely wipe the data on them if necessary.

I think we need to be having that conversation in the organisations we work in or encounter. Rather than calling it “rogue” or Shadow IT, call it uncontrolled then work out how to control it.

G is for…


The General Data Protection Regulation (GDPR) is an EU regulation which sets out the minimum requirements for Data Protection in the EU. It is a bit more stringent than the Data Protection Act, which is the current legislation in the UK. The UK has been heavily involved in its development, and it will come into force on 28th May 2018.

As an EU Regulation it immediately becomes law in every member country the day it comes out, and every member state will have to comply from that date.

For further advice and guidance, go to the ICO website and check out these 12 Steps to GDPR which you should be following right now.


It’s all well and good having lots of security controls in place, lots of shiny hardware and the latest software, but how do you know that what you have is effective and is being used by everyone?

That’s what Governance is for. It’s about the oversight of all security related activities to make sure that they are fit for purpose and delivering benefit. It’s normally done through regular reporting, reviews of metrics (ie data which demonstrates how effective controls are) and key performance indicators.

What does this mean in practice? Let me give you an example. Let’s assume that an organisation is security policy states that all relevant critical patches from software vendors must be applied within 1 month of their release. A metric that might be used is to identify the number of machines which don’t have critical patches applied within 2 months, and for those machines to be inspected to find out why.

Grey Hat hacker

In an earlier post we talked about Black Hat hackers, who are effectively the bad guys, and we’ll talk about White Hats later this year (you’ve guessed it, they’re the good guys). Grey Hats fall somewhere in between. They see themselves as doing good, trying to help organisations, but technically they’re breaking the law.

It works something like this. A white hacker has written permission in advance before trying to test a system for vulnerabilities. A grey hat doesn’t have that permission, but tests systems for them anyway. When they find a vulnerability, they either notify the organisation or the company that makes the software they’ve found the vulnerability in, often in the hope they’ll get some kind of reward. It has been known for them to be arrested because they’ve not had that ore-authorisation to carry out their tests.