A technology that’s been around for quite some time is IPSec, it helps to ensure security of communications between two network devices. With IPSec in place two devices need to establish a peer-to-peer trust before communication can take place, it’s kind of like having a secret handshake.
If your enabling an environment where people will be able to bring their own device you probably have some requirement to prevent them accessing some services, such as the HR system, so that they don’t walk off with the CEOs pay slip. IPSec is perfect in this situation to preform something called Server and Domain Isolation. Essentially this means that only specific devices can access the super-secret servers but every device can have broad network access.
Accesses to services and resources is somewhere that an 80/20 rule applies. Most people need access to most of the network for most of their work, some people will need access to the other 20%. Using SDI and IPSec you can require people to access secure information from devices you consider to be more trustworthy. Perhaps they can’t access the HR System from their Windows Phone but they can from their Windows Laptop, that’s BitLocker encrypted etc.
IPSec is implemented in Server 2008R2 and Windows 7 using Group Policy controls for Windows Firewall with Advanced Security. Essentially you place your super-secure resources into a group or OU that REQUIRES access and place clients that you are happy to have access to those resources into a group or OU that set things up so that clients will reply correctly if asked to do the secret handshake. If the client doesn’t know the secret handshake that’s the end of the conversation. Whilst you’re at it you can raise the general security level on your network by telling all clients to REQUEST access. That way the first thing the client will say is “do you know the secret handshake” if the answer is no they can still talk to each other.
For Windows everything is controlled through Group Policy, so not only is it easy to administer it’s easy to get very granular, for example you could say that only clients that match a specific WMI query get the IPSec policy's applied.
If you’re wondering why you wouldn’t just do this with some app level access control or some file level access control then consider this: you don’t know what’s running in the background maliciously on any device that someone casually brings in.
RESOURCES for IPSec and SDI have been gathered together in one place already on this IPSec Page of TechNet but I thoroughly recommend the following:
If you’re thinking about how you can make your environment more suitable for a world where people want to bring their own devices into the office then you could do well to attend an IT Camp where we talk about just that. Of course those events are now full, so I won’t bother to link them but now you can build the lab at home.
We’ve just released the Test Lab Guide that is part of the basis for the stuff we show at a camp, download, evaluate and have fun.
In my last two posts I talked about People + Devices and Data + Apps – essentially 4 of the things you need to manage and probably already are in your environment. A fourth element is the network but I won’t be going into that in particular because it’s purely a means to an end, a way for People to connect the apps on their devices to the data that they need to be productive. What “client infrastructure managers” now need to do though is to combine those essential elements into the users journey and how to manage that journey not just the individual items.
Consider the scenario (one you’ll see at IT Camps): Ben is working on a document on his laptop, he needs to share it with Alice who needs to approve the content. Ben then has to go to the coffee shop but he doesn’t want to carry the weight of his laptop for a quick coffee so he just takes his slate. Whilst he’s out he realises he needs to amend the document, so he connects back to the place he shared it with Alice and makes the changes – whilst she’s actually reviewing it. Then he starts a new document, but he has to run so he just powers off. When he gets back to his laptop in the office the document is “magically” there. When he’s done for the day he packs away his laptop and locks it in his desk drawer but just before he gets out the door Don asks him to share the new document with him, so he jumps onto Don’s PC and does just that – even though he only saved the document on his desktop over on his laptop, which is locked in his desk drawer.
Some of what just happened might sound like magic. It’s not, it’s all possible with existing tools and the right deployments of User State Virtualisation, SharePoint, DirectAccess and some other established tech. All IT did was provide the means to make it happen – put some glue in place that allowed for a mixed device style.
Really it’s always been the job of IT to make technology work in the most approachable, appropriate way.
The next paragraph is the same as the story above but with the bit’s of tech marked out so you can see where we used them.
Ben is working on a document [Word 2010] on his laptop, he needs to share it [SharePoint 2010]with Alice who needs to approve the content. Ben then has to go to the coffee shop but he doesn’t want to carry the weight of his laptop for a quick coffee so he just takes his slate [Windows 7]. Whilst he’s out he realises he needs to amend the document [Word 2010], so he opens the place he shared it [DirectAccess + SharePoint 2010]with Alice and makes the changes – whilst she’s actually reviewing it from the browser [Office Web Apps]. Then he starts a new document, but he has to run so he just powers off. When he gets back to his laptop in the office the document is “magically” there [User State Virtualization]. When he’s done for the day he packs away his laptop and locks it in his desk drawer but just before he gets out the door Don asks him to share the new document with him[User State Virtualization], so he jumps onto Don’s PC [Remote Desktop Services] and does just that – even though he only saved the document on his desktop back his laptop[and on the server], which is locked in his desk drawer.
So it’s all about the journey or rather planning for the journeys that your users might make and whilst you can’t plan them all, you’ll find plenty of commonality.
My last post was about how, in order to embrace consumerisation, you need to start thinking in terms of managing the access that people and devices have, or more accurately the access that People on Devices have. This post is an extension of that previous post in that we’re going to start thinking about the two other of the four ingredients in our consumerisation cocktail that represent the things that people want to access.
Other than admins no person should ever have to think about accessing a server, they shouldn’t need to be thinking – “golly gosh I need to access the latest sales data so I need to go to \\sales\2012\march\week3\some-random-share\sales.xls”. In fact no person ever really wants to have to remember that, they just want to access the sales information. More over they really don’t need to be thinking, “what credentials were they, umm, lets try this, no, how about this, no err, how about…”. People just want access to information.
OK, it’s not that simple, they do need a way to access that information but we can see a marked shift here too in resent times. Today people think in terms of Apps, services have become apps – just pick up the mobile device nearest you and the proof is instantly visible. There are also really only two types of Apps too: Viewing and Doing. The former category, Viewing, are in fact ways to consume information and the latter so they fall into our information category, Doing, are generally ways to create information. It’s hard to cite a single example of anything other than these two.(You could argue that there’s a 3rd type, Games, but that’s about it).
What we need to do when we consider how to allow a more consumerised environment - whilst also protecting our corporate assets - to control who has access to Do what with Information. Nothing new, it’s a problem we’ve had for many years and we have a wealth of well known solutions, but do they stack up in this brave new world?
Today what many organisations are doing is using the same old solutions, that were perfectly good in the past, applied to todays problems and they’re being effective some of the time – but not all. The old way to manage information was to manage who had access to it where it rested, on the server, but the trouble with that approach is that the information is no longer at rest, it’s constantly moving and through many applications, devices and people. How do we cope?
To give you an example, what happens when your CFO emails the financial accounts to his home PC because it’s more convenient. The chances are that the information is only protected at rest, so when it’s attached to an email that protection (the file system ACL) is removed, it then goes over a HTTPS (good) connection to the email provider (who could then read it at will) then it lands on his mobile device…or rather it wood if he’d sent it to the correct email address, instead it lands on JoeBloggs@contoso.com ‘s device not Joe.Bloggs@contos.com ‘s email inbox.
The best idea is to manage the information assuming it’s mobile, assuming that it will leave the confides of the firewall, essentially assuming the worst case will happen.
In a modern environment where employees can use their own devices and you might not have access to control those devices your best approach is to manage the information in a way that never leaves the information. To embed security into the information.
We’ve had a technology built into Microsoft Office documents, built into Microsoft Exchange and built into Windows for quite some time to manage this issue but now is the time to turn it on. Rights Management is built on the requirement that the App that is opening the information (the document, the email) will check to see what the person opening the document can do. The App does this by requesting that information from Active Directory Directory Services, normally this only happens if the device is allowed to request that information. As such you have a mechanism to ensure that the right person can access the information from a device or App that’s secure enough to store the information.
You might well notice that again, the two variables of management you have remain People and Devices.
A second thought might well be that you need some kind of rich client software (Microsoft Outlook 2010, Microsoft Word 2010) in order to ascertain the rights that the user has over the information. Apps of course don’t have to be delivered on a device, they can be delivered as a Web App and AD-RMS works with Office Web Apps. Web Apps of course play an important part in the mix. With Web Apps you have a way to reduce the potential for data walkabouts because with a web app your data doesn’t need to leave your firewall – even though it’s displayed through a web portal outside your firewall.
Apps probably cost money and as such you will probably want to protect access to apps not primarily to prevent access to information but to prevent you from overspending. Controlling access to apps is a fairly simple process but it’s something we’ve done a great job of automating in System Center Config Manager 2012 – which is a future post all of it’s own. The key thing to remember though is that SCCM 2012 implements and user self service request mechanism and administrator approval mechanism for application installs, in addition to admin driven installations. Essentially you get a corporate Store for Apps – and people are comfortable with that these days, just look at your mobile device.
Control access to information at rest and in motion based on People and Devices and try to control access to apps to manage cost not information – after all what would you do if the user brought their own app?
In the past I’ve written a number of articles on how to start thinking about the consumerisation of IT – if you aren’t familiar with the term hopefully this link will help. Now I think it’s time to move beyond thinking about how you’ll build a consumerisation strategy and how your support will change and start looking at the tech that you’ll need to support a flexible environment. In this post we’ll take a look at the two major variables, People and Devices, and look at the types of tech to help support more variability in them.
There are two variable user-centric components that you use to control access in your organisation, the identity of your people and the identity of your devices. If you’re like most IT shops you’ve had your eye on these for a long time and have probably locked things down around these two things. First and foremost your people have become user accounts and this is where your access controls are probably currently more focused. Secondly you have control of devices because they’re corporate issued assets, you named them, you have admin access, you say what software is installed and what isn’t, you have to fix them when they break. We’ll spend most of our time in this post discussing devices.
Devices
The first thing to note is term I’m using - I’m not saying desktop, I’m specifically being more inclusive than that. Devices includes desktops, laptops, mobile phones, smart phones, embedded devices (you might have Electronic Point of Sale (EPOS or tills to everyone not in retail). It really doesn’t matter what the device is, people have so many today (device multiplicity) that you need to think about how to best support them all.
Traditionally we controlled devices in a binary, red and green way – you either have a corporate one or not, allow or deny. Today though people will try to bring in what they want and they love those devices so much that they will fight to make them work on the network, and when they do they break some kind of corporate policy. If we think about the Windows environment that we all have devices have identity – an account in active directory and it’s that identity that allows us to control secure and support them.
What we need to aim for then is a world in which we have as much knowledge about the devices on our network as we can, given the devices constraints. For example you can’t domain join an Android device. The upshot is that you can’t control secure and support it using the traditional methods of Group Policy etc. but the only reason you can’t is because there isn’t an account there. Most people know that the majority of mobile devices connect to our corporate network using Exchange Active Sync so that they can receive their email. There for the management connector for mobile devices – the thing that knows what that device is – is the email system.
Of course devices don’t receive email….people do. So what we really know here is some information about the device based on the person, not just the device. Given that a device does things without the person using it knowing necessarily (I’m thinking looking for resources but malware could also be a problem) don’t we need to think in pure device terms? Yes
What we need then is a lower level identifier than just the individuals identity, perhaps we consider the devices identity as it presents itself to the network.
At the network level we can see the devices MAC address first, then it’s IP Address (which we give it probably) then once meaningful communication is established we can ask for certificates, identity attributes, capability profiles and the like. Of course we need to enable the right components. It sounds obvious but the best way to support devices you have no control over is to ask them what capabilities they have and respond to that.
People
Managing people is far easier than managing devices because what we need to do here is long established. Essentially we manage what an individual is allowed to see, and do from both an information (data) and resource perspective. Normally we manage both based on Access Control Lists or permissions and on Privilege. Dave has READ access, Donna has WRITE access, Helen is DENIED access. Simple.
We are able to do this because people have a user account on the system they need access to and the really sensible shops have already introduced and enforce a single identity or at least Single Sign On. If you don’t this is your starting point.
People on Devices
The tricky considerations come into play when we use both variables together, P + D = x , and this is where the challenge for us comes in as IT Professionals. We need to build an environment that responds to this.
If Dave has access to the company accounts on his work PC (which is a fully managed, encrypted, asset) and he has the same level of access from his very beautiful mobile phone, what happens if his devices are stolen? First thing you do to respond is change is disable his user account and change his password. Second you know his work PC is encrypted so you classify that a low risk of loss. Then you turn to his mobile – it might be encrypted, it might not, perhaps just the mail box, not the app storage, did he sync the files to a public cloud location, can it be remote wiped, yes, is it switched on, is the SIM card still in the device? Questions pop up thick and fast. All I’m getting at is that you need to take into account not only the person, but the device that the person is using.
P + D = x
What a person can do on device A might need to be different to what they can do on device B, C and D so we need an infrastructure that can help manage that.
Some tech…
To secure & manage people on devices you might like to look at using:
For most this should be a familiar and not so scary list of technology. Deployed in a flexible way you won’t loose control but you’ll allow people in your organisation to do what they want – which sounds like too good to be true marketing fluff…but it’s not.