Root Causes 74: Device and Network Access

Episode Transcript

Lightly edited for flow and brevity.

• 

  Tim Callan

  How you doing today, Jay?

• 

  Jason Soroko

  Fantastic. Thanks for having me. And we also have our excellent and repeated guests. David Colon. Welcome back, Dave.

• 

  David Colon

  Hey, Tim. Hey, Jay. How's it going?

• 

  Tim Callan

  So, Dave, of course, is a Senior Dev Ops engineer here at Sectigo and brings a unique perspective to this podcast that we really love. And I want to harken back to one of the things that you said in one of our earlier conversations, Dave. It was kind of a, you were moving past it cause you're making another point, but just sort of said, you know, if I'm a remote employee or if I'm an employee who travels to different locations, one of the things that’s really lame - I don't think that's the word you used - but one of the things I don't really love is walking in and having to figure out what are the passwords to get onto Wi-Fi here at this location that I'm in now. And you were making the point that there is a better way and that better way involves certificates.

• 

  David Colon

  Yeah, so, there's a standard called 802.1x which defines how to authenticate hosts over a network. It can use a combination of machine-based client certificates and a directory to check the user's information in order to determine what networks the user belongs in.

• 

  Tim Callan

  So, and that second point is important. So, that allows us to have different what do I want to say, categories of privilege, right? So, not everybody is just - - it's not like when you walk in and you say what's the username password and there's one thing and, you know, maybe it's on a piece of paper that's taped to the wall, and everybody is identical. In this case, your point is that we can actually say these are different categories of visitors and based, or users I guess I should say, and based on those users, we can have different privileges and different treatment of them.

• 

  David Colon

  Correct. So, it's not enough to say, hey, my name is David and this is my password. You actually also need a client certificate because what if I wrote my username and password on a post-it and put it on my desk. Anyone visiting the office could pretend to be me. But with a client certificate, especially on company-issued equipment, that's kind of like a second factor of authentication.

• 

  Tim Callan

  And so, I think it's maybe obvious the way we would do it, but, you know, we certainly could do things like you restrict access based on your needs. So, if you're in the development department, you're allowed to have access to certain tools that allow you to do things like, you know, modify source code and if you're not, you don't right. And if you're not in the HR Department, you can't go into the tools that allow you to deal with confidential employee information but if you are, you do, right. Is that the kind of idea on how you would divide those permissions up?

• 

  David Colon

  Exactly. That's definitely the idea and this is done on the network level. So, a developer trying to access the HR website would get denied by a firewall because they're put in the appropriate group.

• 

  Tim Callan

  Right. And then this also gives us flexibility, right? So, employees role changes, employee gets promoted and all of the sudden they need to have more privileges or employee transfers to a different department and now their privileges need to change, you can do that on the backend, on the identity end very easily without even having to let's say, change the certs that are existing on the equipment.

• 

  David Colon

  Exactly. And then there's also another added benefit to change. What if the user moved across the office floor? So, they didn't necessarily change roles, but they just move location? So, that same client-based certificate authentication with a username and password can be applied on a physical ethernet port, not just Wi-Fi. Therefore, that developer can move all along everywhere in the office and still get the same access everywhere.

• 

  Tim Callan

  Okay. So, you're saying, when you're sitting at your desk, I'm expecting you to access this particular port, but if you're in a conference room, I'm expecting new access to a different port and maybe we're even changing permissions at that level?

• 

  David Colon

  The ports on the switch are actually configured the same. These ports can be ran to the user’s desk, Wi-Fi access points or the conference room, as you said. The magic is what happens when someone plugs their computer to that port. The switch will initiate the authentication to something like our radius server and based on the user's information that is fetched back from the radius server, that user will be put in their respective network that they belong to. As a result, if a machine does not pass authentication, you can then place them in a network that either goes nowhere, or it has very limited access to maybe just the internet, which is an actual good solution for guests at a conference room. Taking the conference room scenario as an example, you may have visitors in a conference room and you may also have employees. A common scenario would be an employee plugs into a port in the conference room and they want to be given the same sort of access that they have at their desk. The reason this is important is usually what they access to on their desk is something that they might want to show that guest user. The flip side is also true. If a guest is in your conference room, you don't want that port to be configured just like your regular corporate user. You want to be able to know to a certain degree that that machine that's connected to that port that belongs to that guest user, should not be on the same network as your regular corporate users are on.

• 

  Jason Soroko

  That's great, Dave. So, this is something that I have seen in some larger organizations. People who, you know, CIOs, etc., who are employing mobile device management, MDM tools, uh, for, you know, to control the whole, bring your own device question. So that's one way of provisioning out those kinds of certificates. Um, what, what ways have you been seeing lately?

• 

  David Colon

  That's actually a good question. I don't think we've actually revisited the idea because we haven't really fully implemented it everywhere. Is there something you're looking for?

• 

  Jason Soroko

  Yeah. So, one thing that I have seen, Dave, is the mobile operating systems themselves - iOS being one, obviously, and Android being the other, especially specific implementations, such as Samsung's, um, both of those operating systems now actually have some MDM-like capabilities within the operating system itself. That's something that's CIOs, CSOs need to actually look at, start looking at, because of the fact that for those who don't want to employ full blown MDM, it is something that they can start taking advantage.

• 

  David Colon

  Got it. So, I'm slightly - - I'm aware of like Samsung Knox and what works, but my understanding of it was a couple of years ago, so I'm actually kind of happy that they made it easier for smaller orgs I guess, to participate in.

• 

  Jason Soroko

  Yeah, absolutely. And additionally, you know, even things such as pushing profiles for, you know, setting up your email addresses, all that stuff that would come to you from an MDM is now quite baked in, nicely, into these mobile operating systems. It's very new. You know, the fact that it seems to, you know, it's not ringing a bell for you is not terribly surprising. It's something that was just put out in very recent releases, but I think that's why we want to talk about it now on this podcast, especially when we're talking about client certificates for devices, especially mobile devices and getting those things provisioned out. But in terms of other protocols, provisioning protocols, I know in the world that I live in an IoT, we often see EST, but those typically is not pushing out certificates to mobile devices, but we definitely are seeing, other protocols that have been around a long time, such as SCEP being used as well.

• 

  David Colon

  S/MIME is very useful for email communication because S/MIME helps the recipient verify who the sender is, as well as validate the integrity of a message. This is such a huge win for security because phishing is a common social engineering attack that has proven to be quite effective. For example, admins on subreddits and forums have usually performed phishing exercises in their respective organizations and usually say anywhere from a 10 to 20% success rate. Success rate here, isn't a good thing. It actually means that the user and the organization fell for the phishing attack. If everyone on the internet were to use an S/MIME certificate, it would actually make it a lot harder for bad actors to spoof the sender or from line in an email as well as altering the contents of the email message. Client certificates can also be used to digitally sign a document. This is very similar to email. It helps the integrity of a document as well as showing that the person acknowledges the document at the moment they signed it. And finally, code signing is similar to digitally signing a PDF or Word document, except it's actually used on code, specifically like installers or binaries that someone might execute. This is useful for distributing code and making sure that when your code is distributed, that no one has altered the binary executable when the recipient actually uses it.

• 

  Jason Soroko

  Yeah. That's exactly right. So, so Tim, what we're talking about now is not just provisioning device certificates into mobile devices, but the need to provision certificates into all kinds of things, such as, you know, perhaps even routers or other kinds of networking equipment that you might be using. There's a lot of technologies that are out there and things are advancing fairly, fairly quickly. And the days of it just being some sort of heavy-handed MDM, still definitely useful, especially for larger organizations but, thankfully more lightweight mechanisms are being available to people. But there's an interesting topic. So, Dave, in terms of the advantages of provisioning out certificates, are there other certificate types or other certificate use cases such as, I mean S/MIME comes to mind, right, for encrypted email and email signing. What about for document signing? Have you seen the need for, you know, people wanting to do various kinds of say code signing from your devices? Perhaps you're in a development shop where you're actually running a mobile operating system development? Are here are other use cases where provisioning out certificates for those kinds of purposes that are not just for network authentication?

• 

  David Colon

  Yeah. So, you definitely have S/MIME for emails. You would like to know that if the email's being spoofed or not and I think that is huge. Another aspect would be document signing to make sure that the user signs a document as is and no one modified it in flight or in transit to the intended user or audience. Another useful benefit, too, and this kind of goes back on the network though, is you can invite visitors to your office and if you had a malicious user that just wanted to plug in their personal device to that ethernet port, if their machine doesn't have a client certificate, they would most likely be put on what's known as a dead end VLAN where they get no access to anything or very little access, if anything.

• 

  Jason Soroko

  Oh, that's pretty interesting. I could even see the possibility for honeypots there if you were suspecting something bad was going to be happening. So, Dave, getting back to the idea of machine certificates, do you see the role for radius servers still in this kind of environment?

• 

  David Colon

  Yeah, the radius server is actually used as an authentication server and based on how it's configured, it can actually pass the necessary information to the switch or a Wi-Fi access point in which the switch and that Wi-Fi access point can then take that information and based on some certain mapping put the user in the correct network.

• 

  Jason Soroko

  Any other thoughts, Dave, in terms of pushing out certificates to devices and why you might want to do it? Advantages of it? What you're doing to help manage it. Any final thoughts?

• 

  David Colon

  Yeah. Client certificates are definitely an easy way to help protect yourself on the network level to also help users on the application level to identify who they are and that the message that they sent is exactly as intended and it wasn't modified.

• 

  Jason Soroko

  So, my final thought on this, Dave, is that this is probably one area of security where a lot of times security can be heavy-handed. It can actually reduce the, the usability. It can reduce the speed at which people get authenticated into things. I think this is one example where it's the opposite of that. In fact, it improves the user experience. Would you agree?

• 

  David Colon

  Oh, definitely.

• 

  Jason Soroko

  All right. Well with that, Tim, I think Dave said his peace and I think that in terms of things to think about, if you haven't already, client certificates for mobile devices and other use case is a great idea.

• 

  Tim Callan

  It seems like an easy win, right? Seems like all upside, no real downside and a really best practice that you should have a real good reason not to be doing.

• 

  Jason Soroko

  Yeah, I agree.

• 

  Tim Callan

  So, as always, thank you very much, Dave. I always enjoy our talks and Jason, thank you.

• 

  Jason Soroko

  Thank you, Tim.

• 

  Tim Callan

  And, thank you audience. This has been Root Causes.