Tech in 20 Minutes Ep. 3: Jim Anthony, AppGate

In this episode, Max Clark talks with Jim Anthony, AppGate’s VP of Cybersecurity, about AppGate’s approach to secure access. Jim breaks down Zero Trust Network Security and explores the security problems that can be addressed by their Software-Defined Perimeter.
Episode Transcript:
INTRO: [00:00] Welcome to the Tech in 20 Minutes podcast, where you’ll meet new tech vendors and learn how they can help your business. At Clarksys we believe that tech should make your life better, searching Google is a waste of time, and the right vendor is often one you haven’t heard of before.
Max: [00:18] I’m Max Clark and I’m with Jim Anthony, VP of cybersecurity for Appgate. Jim, thanks for joining.
Jim: [00:24] Thanks for having me, Max.
Max: [00:27] So, what does Appgate do?
Jim: [00:28] Well, Appgate is a company – is a cybersecurity software company. We were spun off from Cyxtera on January 1st of this year, and we’ve got products that play in various spaces, including something around zero-trust and software defined perimeter called Appgate SDP.
Max: [00:48] So let’s talk about the SDP and zero-trust. What is zero-trust for somebody who doesn’t have any exposure to it?
Jim: [00:56] Zero-trust is a concept, more than anything. It isn’t a product or a thing that you can go buy, it’s really a concept that’s being defined by Forrester and Gartner. The idea behind it is that – they have their own definitions by the way – they’re a little bit nuanced, a little bit different between the two companies, and really, it’s open to a little bit of interpretation as well. The idea behind zero-trust is that nothing on your network: no user, no device, not even the network itself, should be inherently trusted because of what it is. You should build trust with those things every time you see them pop up on the network. That means that because a user is on a corporate-issued device, you shouldn’t automatically trust the user. You should decide in real-time whether that user is trustworthy, and the device is trustworthy. Just because the device is on your corporate LAN, that doesn’t mean it should automatically be trusted. You should build that trust as that devices comes up. And so, that’s really the fundamental thing about it. Then if you think a little deeper, these things – whether they’re humans or devices or PCs or laptops, or whatever – they change over time as well. So, you can trust it in once instant, but then something might happen, and you might want to make an adjustment to that trust level in real-time. So, zero-trust incorporates some of those concepts as well.
Max: [02:15] So, when you say not trusting any devices, you’re talking about a device inside of an office location, a device travelling, a device in somebody’s home, a device on a cell phone connection or cellular network somewhere in the world. So, this isn’t… You bring your laptop and then plug into your desk and now you get access to a server, this is you have to do something else regardless of where that laptop actually sits?
Jim: [02:39] That’s right – I mean, there’s certainly technologies out there that are a little more traditional I nth way that they do things, that would have you believe that you need to control every single thing that gets plugged into your network. And that’s one way to solve some security problems that companies have around corporate assets, corporate networks, applications, and things like that. The problem with that simple model is that you can’t control everything that’s on the network. You can only control what it knows about and then try to bucketize or isolate the other things. Then what happens when those things that you do know about… What happens when they leave the network, but they still need access to the network? And so, how do I get those devices effectively back on the network, and build that trust all over again? It’s just the wrong way to do it, it’s a very complicated way to do it and very specifically I’m talking about a NAC. The NAC in general will have you believe I have to control everything on the network. When something that’s controllable goes off the network, I have to bring it back on the network and then apply that control again. What software defined perimeter is all about is: control the things you care about and ignore everything else. Don’t grant those other things any access to anything, isolate them, send them to a black hole, don’t even let them see the other things on the LAN. That’s what’s our software defined perimeter helps you accomplish. I’m kind of the king of analogies around here, with some of the things that we do, and so this whole concept comes up to this approach, right? We all drive on the roads, on the highways, we use tolls roads, right? So, the NAC would have you believe that you need to control everything on the road, like a toll road. You’ve got to control the entry points, you’ve got to control the exit points, you’ve got to control the road itself – it’s a very expensive proposition to use this road, to build this road, and to maintain this road. But that’s what the NAC is trying to sell into the road. On the Appgate side, on the other hand, it’s more like the interstate system that we have and that we know and love, the free interstate system. Built by Eisenhower in the fifties, right? Anybody can use this interstate system, but when something important goes down that interstate system, we want to manage that something that’s important. Whether it’s a first responder with sirens on, we want to give that first responder a lane to use. If it’s a dignitary that needs an escort, we provide the escort for the dignitary. That’s really the different between a NAC and a software defined perimeter solution. The NAC would say “control everything, make no exceptions,” and then the software defined perimeter would be like “control what you have to control, what you need to control, and ignore everything else. If you want to let it use the infrastructure, let it use the infrastructure, but if you don’t, then don’t let it use the infrastructure.” That’s kind of the way we look at it.
Max: [05:47] So Appgate works by installing a client on the end user’s device, and then a gateway that the device can authenticate with and pass traffic through. And then you establish trust based on policy or a set of rules. At a high level, what’s some basic example of roles or conditions that you’re checking or can be checked with the SDP?
Jim: [05:59] That’s a really good question, and very specifically in Appgate we call these policies. The policies can be built un a number of different things, both included in the product by default and things that you can create as an owner or a user of the product. Generically speaking, we call these claims. Claims, you can think of them as variables. Every single time a user connects to a corporate network, there’s a couple of different things that are true about that connection. First of all, there’s a user and an identity. That identity is managed by some identity management system, say Active Directory, Azure AD or Ping Identity or Duo or Octa, whatever. But that identity management system also contains attributes about the user. Here’s where our first set of claims come from. So, you can take any attribute from that identity management system about the user, and score it in a user claim in Appgate, and use that to build a policy. You can also combine it with claims from the user’s device and the network that that device is connected to. Obviously, we call these device claims and network claims. Things like, what is the laptop’s default gateway IP address? Is the laptop’s hard drive encrypted, yes or no? True or false? Are certain processes running on the laptop? Where are the geocoordinates of the IP address that’s being used as the default gateway? Things like that are captured by the Appgate client when the user is attempting to log in, and again sent to the controller, stored in variables that we call claims, and all of these claims are available to be used to define policy. So now, I can literally make a policy that goes something like: if they user is a member of the finance group, as defined by Active Directory, and the MAC address that’s stored in Active Directory for their corporate-issued laptop is the same as the MAC address of the device they’re on, and the corporate-issued certificate is on the device, and the device is connected to a network whose default gateway is inside the boundaries of the United States, and it’s Monday through Friday and it’s regular working hours and its antivirus running, et cetera. You can use any of these variables. Then, I might want to grant that user access to the apps that take him to do his job. So, because I said finance as the group, maybe I’ll give you access to the finance server, a couple of finance file shares, an application running in Amazon that’s a finance-oriented reporting tool… Those are the things that you get access to to do your job. Then, Appgate will actually serve those entitlements down to the end user, and his Appgate client will established secure, encrypted tunnels to the data servers where all those applications live. This is a multi-tunnelling concept that we have built into the product. We hold a patent on it that really begins to really change the dynamic of how you think about users accessing applications in a multi-data center environment.
Max: [09:05] So, twenty years ago-ish, the precursor to 802.1x hit the market, which is… My network device is aware of you know, this computer is allowed access, and this model has matured a little bit. Then Google released a paper which ended up becoming zero-trust for a lot of people, or the foundations for it, and Google has extended into beyond corp. We look at corporate networks – this is a pretty big shift – to go from existing infrastructure network design into a zero-trust model. I mean, if a company doesn’t evolve into zero-trust, what’s the negative. Why is zero-trust important to them and why should people be taking this seriously?
Jim: [09:47] That’s a good question, and probably a very opinionated or oriented answer would be what comes out of me here. I don’t think there’s a right answer to that question. I think if you’re not thinking about zero-trust, and adopting newer technologies, newer ways of protecting your assets, your corporate applications, then you’re going to be left with using traditional IP-based technologies. We all know IP addresses have had a shift over the last few years, from IPv4 to heavier and more frequented option of IPv6. The point here is that IP addresses are typically pretty static. However, when users move around with their devices, even their mobile devices, they’ll pop onto different cell towers, different partnered networks – if you will – if they’re really travelling across the country. The next thing you know, they’ve got different IP address all the time. So, the source IPs very dramatically – as the users become more and more mobile, more and more independent of working in the office – and that’s the fundamental issue with IP-based access controls in the first place. The IP-based access controls are really about: do I trust the source of this traffic? And the source is defined by the IP Address of where it’s coming from. Well, that IP address is become less and less predictable from an end user perspective. Yes, you can probably predict the IP address of their work from home location, but you’d need to ask them to get it for you and document it for you and send it in. You can certainly use that as an attribute to validate that they’re actually at home. But that side of the equation becomes more and more scary as users become more and more independent of working in the office. The other side of the equation: how do I define the destination? That’s becoming more and more fluid as well. Of course, we have DNS that we can use to resolve IP addresses in real-time, so that’s one way that you can start thinking about… How do I tie a name – a static name – to a different set of IP addresses, a revolving or changing set of IP addresses? That certainly works in one regard, but now cloud – AWS, Azure, GCP, even VMWare and OpenStack, give us the capability of programmatically building and destroying applications on demand. So, we can auto scale stuff, we can execute scripts that will build new applications and build them temporarily, and then destroy them later. Here’s the problem that we’re starting to run into: this building and destroying starts to use and reuse IP addresses in different ways, in the same network. So, today I might press a button and build a new finance server and it’s got a 10.1.1.5 IP address… Tonight, I might destroy that finance server, you know – back up the data, whatever, destroy the finance server so I’m not paying for the resources overnight. Then tomorrow, build a new one. Well, that finance server might end up with a new IP address, which is entirely possible. DNS would help us solve that problem, but I might also turn around and build a new QA platform, and that 10.1.1.5 IP address is now part of my QA environment. Well, how do I make a rule that allows my finance people to reach that finance server, no matter what the IP address is, and vice versa? When QA is allowed access to 10.1.1.5 and all of a sudden, the next day is 1.1.5 is associated with my finance server, now my QA people have access to it because the rule is built around IP addresses. That’s a disaster, right? It’s a complete complicated disaster that you’ve got to figure out how to solve. With Appgate, we’ve added another capability that allows you to define applications based on meta-data. It’s a very unique capability. So now I can go and tag those instances as a finance instance, and it doesn’t matter what the IP address is, whether it’s 1.1.5 or something else. When that thing is tagged a certain way, I can associate that tag with the IP address and grant access to the end user based on that tag value. So, we can do that in AWS and Azure and GCP, we can do it on VMWare and we’re working on ways to do it with OpenStack, Cooper Netty, HyperV and other platforms as well. We’ve got a majority of the platforms covered where that dynamic application concept exists today.
Max: [14:04] This can take a lot of load off an IT department in terms of managing and supporting resource creation and access controls and just… inventory management. I mean, what does this look like for people after deploying?
Jim: [14:20] That’s an interesting question, too. When you hear me describe what Appgate does, if your head is oriented around the traditional way of thinking about solving these problems, I tend to make your head explode, right? People on the other end of the speaker, they tend to say, “wait a minute, this is way too complex, I’ll never be able to get my head around it, I’ll never be able to understand how to make this work completely.” But the answer is… It’s actually so much easier, because we can control the endpoint with a client and we can control the entry point to the network with gateways, we’re actually controlling all of the outbound traffic from the end user’s side, and all of the inbound traffic to the data center’s side, and vice-versa. It becomes an easy way of thinking about using these attributes that I was describing earlier, to help define those policies. I don’t have to go in and manually program individual switches, or individual appliances or even individual user devices. I can do it all centrally, I can do it all through the use of this tagging, through the use of the metadata, I can do it through the use of these attributes that are coming from the identity management system, the end user’s device and the network that it’s connected to. It makes it so much easier. We’ve actually got real case studies out there where we’ve got certain entities in North America – in fact – that are handling tens of thousands of connected users, and they’ve literally got one or two admins that are dealing with issues or making modifications to the platform. They do it all from a central command console, they’re managing these Appgate appliances that are deployed in five different data centers, and they’re doing it with a very small crew, and a very small amount of time, every day. So, it’s a pretty easy thing to do once you start to really understand the power of the multi-tunnelling, and the use of these attributes that I’m talking about.
Max: [16:20] So now in a post-COVID world, companies are scrambling to have a remote workforce, work from home or really just a distributed workforce in general. That seems to play right into what you’re telling me Appgate does and its strength. Can we talk a little more about what your customers have experienced now, post-COVID and what this has been like, using Appgate if it was already there, or if they’re onboarding now post-COVID?
Jim: [16:43] Yeah, I could answer that in two different directions. So, obviously with COVID-19 there’s a major shift in work from home attitudes, across the world, and across every industry. If you’re a knowledge worker that needs to work on a computer for a good part of the day, and you’re not dealing with packages or individual things that you’ve got to move around, if you’re a knowledge worker on a computer, the idea now is that you’re probably working from home. Most of our existing customers, they’ve handled this transition very smoothly. With Appgate, all of our stuff is all software, it’s all based on appliances, virtual appliances that are deployed to protect assets, software that’s deployed on the end user’s device. It’s self-service, and they’ve handled it easily. In some cases, they’ve called us for upgrades, right? They originally specced the system out for a hundred users, or for two hundred users, and they’ve called us and said “hey, we need to double that or triple that, or quadruple that.” Easy enough for us, we just issue a new license, they apply to that to their system, no downtime involved. That gives them the ability to add more capacity, whether there are more end users connecting into the system, or more gateways to handle the load. It’s very easy to expand to handle either side of that equation. Then you’ve got another answer to the question. How about non-Appgate questions, how are they handling this shift? Well, from my perspective, from our perspective, we have seen a dramatic uptick in interest in Appgate. A lot of prospects that aren’t customers have been using traditional VPN technologies. One of the first things they figured out is that VPN, having a single tunnel going into a concentrator, the concentrator is typically overwhelmed immediately. That’s the first thing that falls over, and now they’re scrambling around saying they need to upgrade their concentrator, they need to buy a bigger one. That’s typically a hardware appliance, right? And they also need to buy HA licenses because they can’t handle it going down now, that means their whole business is effectively offline, so they need to buy a second one. They’ve got to buy HA licenses to go with it and activate that – that’s a little more complicated. And then they start looking around after they get that problem solved and they say, well now they’ve got the ability to have the concentrator handle the users, the pipe from the internet that’s feeding the concentrator isn’t fat enough, so I’ve got to upgrade that, right? Everything is coming through that single pipe. And then they get that solved and they look around and they’re like, well now everybody is VPN’ing into corporate and all these users used to be working in different places, different branch offices, and now they’re all using the same pipe to get out to the internet, or to get out to some other data center that I have, and that pipe isn’t big enough. So, it’s a cascading domino effect of things that are just running out of steam. Appgate obviously solves this with this multi-tunnelling concept. There isn’t a single-entry point into the network with Appgate. You actually – as a user – if you’re granted access to an app that lives in a data center, you will have an encrypted tunnel to that data center. If you’re a company that has ten data centers with apps deployed in all ten of them, then as a user granted access to ten apps and ten data centers, then I’ll have ten tunnels running to all those locations. So, I have no single-entry point, no single point of failure, my traffic is split across all those internet connections, or all those direct connections. So, I distribute the load across all the infrastructure. In fact, Appgate removes the end user traffic off that data center to data center connectively link, leaving it for that critical server to server communication that’s necessary to make stuff work.
Max: [20:31] You mentioned license keys for users and gateways. Can you run me through how Appgate SDP actually prices? What are the components and how do we scale this to match into an environment?
Jim: [20:43] That’s a good question – two simple answers. There’s two components to the pricing model. The first component – and the prominent component – is users. So, as you have people that are trying to authenticate and get into the environment, they consume user licenses. As a human, I might have a laptop, I might have an iPhone, and an iPad – so three, four, five devices. My company might allow me to use any of those devices to connect to the network and do my work. That’s still one user license, from an Appgate perspective. So, it’s an easy way to think about… I’ve got a five hundred employee company, and four hundred of those are now work from home employees. I need four hundred user licenses for my Appgate deployment. The second component – and it’s a minor component – is what we call a site license. You can think of a site as a data center, a traditional data center, you can think of it as a region in the cloud, like an AWS Northern Virginia region. You can think of it as… A more detailed description of what a site really is, is a collection of subnets in a location, controlled by a single-entry point from the outside world. So, think about a traditional place where you might have a data center with a bunch of different subnets that are all fed from a DMZ, and that DMZ’s protected by a single firewall and router combination. Well, that would be a site in our licensing model. So, as a company – most companies will have three or four, maybe five sites. Not a problem, we can add those three, four or five sites to the license. There are a few exceptions to this, where some companies in adopting cloud, they’ve come back in and said, “we want to make our cloud adoption really tight, really secure, so we’re going to have a completely different account for every single application that we deploy in the cloud.” And so now, if you have a hundred applications and you have a hundred different accounts… Well, those accounts, if they’re in different regions or whatever, you’ve potentially got a hundred different sites. The great thing about Appgate is that we don’t actually delineate between accounts within the AWS or Azure, GCP world. So, you can actually have a site span multiple accounts. There’s another workaround as well… AWS about two years ago came out with a concept called a ‘transit VPC’. So, with a transit VPC, you can establish trusted connectivity from a transit VPC to multiple other VPCs that might be in the same region, or maybe in different regions. If you’re using an architecture like that, then that still becomes one site. That transit VPC becomes the entry point from the internet, and then you’re using AWS networking to get to the other locations that you’ve got apps deployed. So, that’s still only one site in our world. So, there’s a lot of different nuances there and like I said, it’s a minor component, the major component being end user identities.
Max: [24:44] Alright, last question for you Jim, actually two question. Give me an idea of the pricing per user, and if somebody wants to kick the tyres and test this before they deploy, do you have an eval or a demo program as part of your pre-sales engagement?
Jim: [23:56] Absolutely. It is about $140 per user, per year. Obviously, there’s discounts associated through partnerships, there’s discounts associated with quantities of users, there’s discounts associated with years of commitment. The site licenses are around $3000 per site, and then obviously there’s other options with Appgate too. We can sell you physical appliances, those have a price. We can sell you implementation services, that has a price. We usually include a starter pack that gives you about a weeks’ worth of services to help you get started, those kind of things. So, those are some of the price points. The answer to your second question – things that people can use to get started. Lots of things that are out there, right? So, first of all – in all three major cloud platforms: AWS, Azure and GCP, we have the Appgate appliances in the marketplace. A special version of that appliance is a free fourteen-day trial. So, if you’re already a cloud customer using this infrastructure as a service concept on one of those three providers, pop out to the marketplace, search for Appgate, find the one that’s labelled fourteen-day free trial, download it and off you go. There’s instructions there how to build it, how to deploy it, how to make it do what you need it to do, do some testing. All the clients are available on our download page, so you can just search for Appgate downloads. You’ll find the various clients for Linux and MacOS and Windows. We even had iOS, Chromebook, and Android clients as well. You can find all those three on our download page. Another way that you can experience Appgate is through something that we call the test drive. So, we’ve actually taken time to build a global Appgate deployment, there’s components that run in North America as well as in Europe for this test drive environment. You can go to a URL, it’s called testdrive.appgate-sdp.com, that’s testdrive.appgate-sdp.com, register for an account, it’ll send you an email, you follow a link and go back in to complete the registration process, and you’ll have full access to a deployed Appgate environment, as both a user and an administrator. So, you can experience the user-side of the equation, how it works, what’s the user going to do, how do they interact. Then on the admin side, now that I’ve logged in as a user, what does that look like to the admin? What was that user granted access to, what are some of the attributes associated to the user? And of course, it’s all video oriented, so you can watch videos that explain step by step exactly what do to and how to get it done.
Max: [26:43] Awesome Jim, this was fantastic, thank you very much for your time.
Jim: [26:46] Max, thanks for having me, I had a great time.
OUTRO: [26:51] Thanks for joining the Tech in 20 Minutes podcast. At Clarksys we believe tech should make your life better, searching Google is a waste of time, and the right vendor is often one you haven’t heard of before. We can help you buy the right tech for your business. Visit us at Clarksys.com to schedule and intro call.