Transcript
After this session we'll have a decent sized break, about 30 minutes, at least 30 minutes, where you can take a break from sessions and chat with each other and go and visit some of the booths or whatever you want to do. We will now welcome Craig Donovan to the stage for the zero touch zero hassle session. Hey there, how's it going everyone? I'm Craig Donovan. I'm a senior enterprise customer success engineer here at Jamf and really what my job is in the company is to help you guys get the most out of the product overall. So yeah, today we're going to be looking at the session zero touch zero hassle, rethinking secure access for Apple device fleets. A little bit of a mouthful but really what we're looking at overall is kind of what's changing regarding access and identity. We're going to take a look at managed device attestation and then we're going to look at zero trust, zero trust network access and using Jamf's network relay. So yeah, we have quite a bit to cover. We'll try keep it in the half-hour, we'll try and get some time for Q&A at the end if we can. I don't know, we have to kind of set up in here so let's see how it goes. So yeah, before we start, I just pre-recorded the demo in the interest of time. What I have here in front view is a Mac that's enrolled in Jamf Pro. It has no network payloads on it at all so it's just sitting at home on my home network and what I'm essentially going to do is try and connect into some business applications that are hosted either in the cloud or on-prem. So if we go ahead and have a look here, what we should see first of all is me trying to log into Microsoft services, have the two-factor authentication but once I complete that and what you'll see is I get kicked out from being able to sign in basically because traffic isn't coming from a secure location or from a secure IP address. The next thing once that's done is I'm going to try and connect to an application that I have hosted on premises so basically behind an IPSec tunnel that's not on the device and what you'll see is when we go, hey that time's up, can't get in and then last but not least if anyone has terminal open and wants to do a who is, if you go ahead and have a look here you'll see I'm just connecting on a public IP address there so there's nothing within the network stack at all. By the end of this demo hopefully without really having to interact with anything in this Safari window, what should happen is we'll push a payload out via Jamf and networking will appear. There'll be no end-user interaction, all those services that we tried to connect to there should just automatically work without really having to do anything but before we get there we kind of need to talk about like what's changing in access and identity so we're all probably like pretty familiar with this. If we look at the left we can see, hey we have our device fleet and on the right hand side we have applications that we want to connect to or we want our users to connect to in order to be able to do their jobs. Problem with this is there's also bad actors out there that also want to connect to our resources and you know use it for whatever, to compromise a business, to hack something, to get information or ransomware or anything like that. So the traditional model for securing against this was really we have our services, we put a network perimeter around it and we spin up a VPN or a firewall rules that effectively says hey allow trusted devices in and allow and well to block devices from anyone that's not allowed and this worked quite well for quite a long time but the landscape is changing a little bit and it has changed really. So first of all what we're looking at here originally was an on-prem environment. As we know most companies now are moving into SAS so there's now applications that your users need to connect to outside of this secure perimeter. Additionally, well if I hit next, there we go. Additionally attacks can happen within that perimeter and once a device has entered your network or a bad actor has got in there you know they have lateral transversal and are able to go ahead and really access everything on that plane and then third of all it's quite easy either through phishing or credential theft or something like that for bad actors to spoof a good device in order to be able to access these services. So that's how it is now. What we're looking at doing is really moving towards a more zero trust access security model and I'm sure we've heard it before either from Jamf things you've been at or from other vendors or wherever else but there's kind of like a few core principles to it and really it is access evaluation is granular and tied to an individual resource instead of the entire network. Pretty straightforward so rather than saying we're going to secure a network and place our apps inside it, we're going to apply security posture to each app individually that our users are connecting to. Next in a zero trust model access to resources is granted on a need to know basis so meaning that users and devices are only given access to the resources they need to do their job. So for example your HR people within your business probably doesn't need access to your AWS environment, your devs probably don't need access to Salesforce and so on. It's really about locking down the services to the type of users that are looking to connect and then third it's really about continually monitoring these connections and enforcing access controls. So the moment a device falls out of trust within the organization the moment you guys as the admins define hey this device is potentially dodgy to no longer allow the connection into whatever the services are. So they're kind of like the three core principles of it overall. So I mentioned trust there but the next question is really how do we define trust particularly in an IT environment? Well really we use contextual information to make that access decisions. So we're looking for information such as user identity so who the user is, the device identity what's going on with the device itself, is the device managed, what's the security posture of this device and then we can even take in other things like where the device is and what time the user is connecting at. So you know we're all familiar with what trust is as a concept and that's hey from looking at this thing from ascertaining some information is this trustworthy or not and if it is trustworthy we say all right great and if it's not trustworthy we deny access. So really what we're trying to do is keep the bad guys out by building trust before allowing access and then once we've allowed access to be sure that we're always reassessing the trust posture beyond the initial decision. Like again if we're talking in personal terms I'm sure there is someone some people that you deem trustworthy before that are no longer trustworthy to you now. So the same thing must applies here there's more than just that initial trust to say if you're allowed to connect or not. And yeah so zero trust starts with identity and when we talk about identity there's kind of two cores to identity. One you're probably more familiar with than the other and that is user identity which typically nowadays we're all using an IDP. So in order to establish a user identity a user has to sign in with their credentials that are matched against your IDP. If the user can pass whatever checks that occur on that whether it's a password, whether it's passwordless, whether it's two-factor or whatever challenges you have in place there. Assuming user can pass those tests or can pass those challenges you say all right we trust them. And that works great it's really important but we do live in a world now of credential theft and phishing and impersonation attacks and because of that we kind of have to understand that well maybe we should start looking at device trust in addition to user trust to build a fuller picture of what's going on here. So we're not just saying is this user able to connect but we're also saying is this user and the device they're on able to connect. So really when we talk about device trust we're looking for a unique and verifiable representation of a device used to establish trust and authenticate it. So yeah we're looking to prove that the device is what it says it is in order to say whether we should allow connection or whether we should trust this device or not. And that's kind of been a bit of a challenge on Apple devices for years. So when we think about well how would we identify a device is what it is well we'd probably look for things like serial number or UDID or something like that and they're great they're something that's unique to the device but they are also spoofable and by nature of them being spoofable they're not particularly secure in terms of using it to build some trust. So if you guys remember the Intel days of Mac OS well if you wanted to spin up a VM you could just steal a serial number off a device and use that to go from there. So how do we solve this problem of well avoiding the spoofing and avoiding the devices claiming to be something they're not. Well Apple have a solution for this and that is managed device attestation. It's an Apple platform security feature that provides hardware-based cryptographic evidence otherwise known as an attestation of a device's identity and several core properties. Kind of think of attestation as a certificate or think of attestation as a cryptographic proof of identity and device posture. So when you receive an attestation back for the device this is effectively some information from Apple saying hey exactly this is what this device is or this is how we believe it should be and we are the manufacturers of this device. So managed device attestation offers two different ways of using it and we're going to kind of talk about them today and then we're going to talk about how we use them for secure access. So on the basic level there's something that's called a device information attestation and it is kind of what it sounds like and it is to query Apple's attestation services to get some information about the device. So effectively what happens here is our MDM pushes a device inventory command out to the device. The device connects to Apple's attestation services using the secure enclave and the device basically creates a key that it uses to connect to the Apple attestation services and then the Apple attestation services responds. The device passes that information back on to the MDM and then you can effectively check the information Apple says about the device versus what the device claims to be itself. So what information are we really looking at in here? Well we're looking at attested properties. So again this is information coming directly from Apple about immutable and mutable fields. So something immutable which means it's unable to be changed would be stuff like the device's UDID, its serial number, its software device ID but it'll also give an extra context such as what's the OS version of the device, what's the SEP OS version, what's the secure boot status and the kernel extension approval. Are we okay? Yeah okay. Cool so that's how we can get some information out of the attestation but then how do we use it? And really what that comes down to something that's called ACME device attestation. So similar kind of workflow, similar thing but with an extra step in it which is an ACME payload attestation. So if we take a look at this now and oh yeah sorry all right testing all right we'll give that one a go. So yeah ACME or automatic certificate management enrollment protocol is something that works similar to SCEP if you've used it in the past where it is about getting a certificate on the device that other services can use that in order to connect to infrastructure or to set up TLS and really where ACME comes in is it ties in to the device attestation. So the first step and I think it happened there and while I was getting mic'd up again and is the MDM pushes an ACME payload to the device. From there the device generates a hardbound key again using the secure enclave and then the device attempts to connect to the ACME server looking for a certificate. The ACME server basically challenges the device and says all right you're trying to connect well prove you are the device and that you say you are. Therefore the device then goes to Apple's attestation server and pulls in the attestation something similar to what we've seen earlier and then that information gets passed on to the ACME server. Assuming that that information is good, assuming that the device is verified as what it says it is, an ACME certificate is placed on the device and like I said an ACME certificate would be something similar to SCEP where you can then use this certificate in order to connect into your enterprise resources. So we can use that alongside you know our MDM or Wi-Fi or Kerberos or VPN or anything like that but the only way that this certificate can arrive on the device is that it passes this attestation check in order to be able to get it. So why does this matter? Well the good thing about it is once the device has this we're able to then say well all right the device is genuine Apple hardware, it is a specific device so it is the device it claims to be, that the device hasn't been tampered with because if it was tampered with it wouldn't receive a attestation and using that we can then go ahead and well establish trust with the MDM and within the organization. So this is a certificate on the device that effectively is used to attest for device trust. So now that we know how we can establish device trust using managed device attestation we're going to take a look at our zero trust network access for Apple fleet. So that is made up of a combination of attestation, something called network relay which you may have heard of before if not we're going to talk about it right after this and then we're also going to use Jamf's ZTNA engine which lives in the Jamf security cloud. So network relay you may have heard of it you may have not well and network relay or relay in this case is a special type of proxy that is optimized for performance using the latest networking transport and security protocols and it's natively built into the Apple operating systems. So at a high level think of it as a new way to connect Apple devices to work applications a modern VPN but smarter lighter and built right into the OS. It's a system level feature it's built off mask a tunneling framework which itself is built on top of HTTP 3 and quick and it's the same technology currently powering iCloud private relay which you probably are already aware of and probably using if you're in this room right now but instead of masking your personal browsing it's designed to securely route enterprise traffic so from your Apple devices into your enterprise resources. So yeah we're going to go ahead now and talk about kind of how this works and how we set it up from there. So in order to do this we need to have devices and we need to have applications to connect to. Using the Jamf security cloud if you're familiar with it if if not I'll show it in a little moment but in there it allows you to effectively define what your business applications are, what devices are allowed to connect to them, what's the minimum security posture of the devices allowed to connect into this and then what route the traffic will take to those applications. So this will work across SaaS apps or something that lives in on-prem. So for SaaS apps for example when you're defining them they may be accessible over the public internet but on-prem apps you might need a VPN so how we work in this regard is to set up an IPSec connection between the Jamf security cloud and your on-prem resources from there. Things then work as a split tunnel to effectively say that when traffic goes from the device into the security cloud and where the traffic goes. So in order to get this working you define what everything is in the security cloud and then your MDM comes into play in our case Jamf Pro and that then pushes a network relay an ACME payload to the device. So again you push this out as a configuration profile the way you're familiar you know with pushing configs out. Once that reaches the device the device goes through that attestation flow that we talked about earlier. We won't go through it again but in this case we're going to imagine hey this is a genuine device that's enrolled within our MDM it can be new fresh out the box or it can be you know you used before but all we know is that from attesting this against Apple that hey this device is good and secure therefore we get the ACME payload on the device. Now anytime a user goes to connect to one of the applications we we've decided on well a mass tunnel or a relay as we call it using HTTP tree is established between the device and the Jamf Security Cloud using a tested mutual TLS using that ACME certificate that we put on the device. So again in the event that a device wasn't able to pass the attestation check well that tunnel would never be spun up in the first place and this potentially dodgy or risky device would never have the correct network routes in place to be able to connect to our business applications. In this case hey everything looks quite good therefore we're going to go ahead and allow the connection we're going to spin up that that tunnel and yeah the connection goes into the Jamf Security Cloud where we then provide basically further security risk posture checks assuming that hey they work out access to those applications is granted and your users are able to connect to those services. In the moment that a device was to fall out of management state or become a high risk the traffic will to these applications will be killed off in the Jamf Security Cloud itself and never actually make it to those business applications so a potentially infected device is kept isolated from your network resources. So yeah kind of some key features around this then is it's zero touch and pre-stage ready microtunnels so because there's no end-user interaction required on this you can actually push this out as a configuration in your pre-stage enrollment so that means from the moment your users first connect to a network and enroll within the MDM you're able to define traffic routes to your business critical resources and you're also able to say that hey if a device is being tampered with in transit or if a device is somehow spoofing what it is it will effectively never be able to connect in to your network research network resources or your business applications even on like its first boot or its first connection from there so if you're an IT organization who say ships devices out from Apple or from your vendor to your end users working in a remote environment you can be sure that hey without ever touching a device the moment a user tries to connect online they're going to be able or they're going to be they're going to be required to pass this attestation check and in order to really be able to connect from there again we're talking about strong device identity assertion we are using the managed device attestation and yeah because it's built off and Apple's relay it's using mask and HTTP 3 it's ultra fast and compatible so it's using the same protocols as yeah HTTP 3 I think it's UDP for UDP port 443 and what that means is you shouldn't really need to do any network tinkering here or open any ports on your network in order to be able to get this to run it if you're already supporting HTTP 3 which you probably are and you're unaware of it this this is just going to work out the box where this is particularly handy is oh not only on your own network in terms of it but if you're on any more restrictive networks or if your devices are on there including kind of like some great firewall scenarios it should work again and because of the because it's just using kind of highly already used ports from there and because it's not actually using the VPN payload for this it can coexist with other VPNs so you don't have to rip out all of your existing VPN infrastructure you can use this for just saying specific routes from your device into specific resources so for example in a world of platform SSO perhaps you want to say all traffic going from my device to my IDP from the moment of pre-stage get secured and wrapped up in a network relay payload and then once the device goes through pre-stage it's you know working with your end-user every everything is going fine well then you can flip over to your traditional VPN or you can continue to use the two things together right there and yeah what this really allows us to do then is streamline the onboarding process where as part of it we're able to define what's happening on the network side of things it also means because we're focused on device identity and leaving the user identity side to the IDP this will work seamlessly on shared devices so if devices are flipping between users it's not a case of each one of those has to sign out of the VPN and sign back in or anything like that and in addition to it well because there's no interaction required it'll also work on headless devices so if you have devices that are never plugged into a monitor maybe a point-of-sales device or something like that well yeah you can just plug it in assuming the moment it goes online it connects to your network and pulls the configuration from Jamf yeah you have secure and connectivity there straight out the box other than that yeah it's seamless ubiquitous remote access so this works across applications it works across web browsers it's baked into the OS so there's no packages or anything like that you have to push out once you push the configuration profile which we'll look at in a moment and the device passes that attestation check it should just work so yeah back to the demo there now and this is the same device this was the same session I just cut it up a little bit and in order to set this up this is the Jamf Security Cloud we're looking at I already have my applications defined in here they're defined in something that we call access policies really what an access policy is I'll click on one in a second is some host names and some risk posture and a route so what are we trying to connect to what's the risk posture around it and then where does the traffic go from there once we've defined our access policies we define we create what's called an activation profile in Jamf and select manage device attestation this is really just to create a configuration profile that says hey what do we do and what Jamf Security Cloud services are we putting on this device we give it a name and we can choose what groups within the security cloud we want this assigned to and then once that's created we'll be given a configuration profile that we can push out so we choose whether we want Mac OS or iOS and when we open it up we'll see our profile is in here if we scroll down and again it's a biggish profile but what we should see in here is some match domains and basically anything that matches those domains on the device gets sent through our network relay and then via our Jamf Security Cloud to whatever those services are so there we go we can have a look at them there now and once we've decided that hey this is everything we want we can just choose our groups within Jamf Pro and hit deploy again I'm pushing this out to all managed clients and yeah it's been successful so yeah this device here is enrolled in that instance and yeah if we have a look within VPN as well yeah we can see VPN and relay is on the device it's already turned on there's those match domains that we were looking at before so again any traffic on the devices that match these gets passed through relay which means these other browsers here that we have should just or these other things should work so yeah you can see my IP address flipped over there we should see now when we look in our settings just to prove that it worked and the attestation check was passed if we look under device management well here in our network relay payload that was pushed to device we can see hey yeah look there's an ACME certificate living there and yeah it's assert the attestation check was passed so yeah now when I go and look at my on-prem app for example look at that it's already loaded in the background and now when I try and go and connect into my Microsoft 365 services again this time as part of the conditional access check it's going to say all right traffic is indeed coming from a Jamf IP address therefore allow the user to connect so I'm saying hopefully this will work but it is pre-recorded so it's it's definitely going to work but and there we go so from the end user standpoint the user that was using this device they went from something that was entirely isolated from their corporate network through kind of a couple of clicks of a button within the Jamf security cloud to now being able to connect into their workplace resources and go from there so yeah and it's pretty cool stuff and and yeah I think that's all we have we're kind of buying on the 30 minutes and so yeah thank you for having a look at that and I think we do have some setup in here now so we don't have time for an out loud Q&A but I'll be basically standing over there if anyone has any questions or if they've had a look at this or yeah if you want to diagnose it before and yeah you can always catch me just on the floor for a beer later this evening so yeah thank you very much everyone Thank You Craig well done we actually have longer than the build break now so this is our afternoon break we've actually got about one hour left so we'll see you in a bit
