 Welcome to another edition of RCE. We actually have a special show today. But before, you can find all of our old shows online at rce-cast.com. You can also follow me at Twitter, at Brock Pailin, all one word. You'll also see me. You can send questions to me to have on future shows and things like that on there. Also, again, I have Jeff Squires and Jeff, you have something coming up recently, don't you? Yeah, but first I gotta make funny if we're not having your normal microphone. That's why you sound a little funny today. You're using your built-in laptop microphone. Shame, shame on you, sir. No, but I'll just bust out my professional amateur card and get away with it. That's true. Just two guys doing a podcast, ma'am. That's all there is to it. Just questions. Well, yeah, so today, today's a little different. We're not doing normal HPC kinds of things, but really on the services that enable HPC kinds of things. It's stuff that probably many of our listeners use for connecting to their corporate networks or their home organization networks or things like that. Some people love this stuff. Some people hate this stuff, but I don't think anybody can say that it's not important. And I've seen when security is implemented poorly, it's really a pain, but when it's implemented well, it's pretty seamless and you barely notice it. And so I think today we're gonna hear about some ways to implement things well so that it becomes painless and actually secure. Yeah, before we get into that though, I'm gonna be out to the TerraGrid 11 conference. I'll actually be out there early on Saturday. So if anybody's listening, wants to meet up while you're in Salt Lake, you can just send me a tweet at Brockville and I'll get a hold of you. Cool. So let's jump in to today. Today we're talking to two guys from Duo Security and this kind of touches on the administrative side of HPC, as I said. Services getting in, securely logging in, authenticating and things like that. And why don't we just go ahead and let you guys introduce yourselves. We have Doug Song and John Oberhide. John, could you guys say hello? Hi guys, thank you for having us on the show. Hi guys, it's a great honor. So I'm the CEO of Duo Security and my prior history was I've done a bunch of other companies in the security space, everything from enterprise security to large scale carrier grade security for pretty much all the world's ISPs, about 80% of all the ISPs worldwide using our systems from Arbor Networks. My name is John Oberhide, I'm the CTO of Duo Security. My background is in security research and I've done my master's PhD at the University of Michigan, focusing on a lot of topics such as cloud security and mobile security that we've really brought forward into our product at Duo Security. One thing John also doesn't like to spell out but I will for him is that he's also one of the proudest experts on Linux kernel exploitation. So he writes a lot of finds and writes a lot of exploits in Linux kernels but also now mobile devices which have happened to be running Linux. Something that might be relevant to you guys with HPC clusters, probably mostly based on Linux systems and having lots of local users that might be untrusted. Yeah, so that's something unique about a lot of HPC clusters. We're not like a single service that's facing. We actually have to allow local user logins and access and resource managers that run stuff as users on remote systems on their behalf. So what can you really do about supporting long running batch jobs when you have security updates coming out all the time? Yeah, that's a big issue and it's funny. The first thing whenever we debug an incidents or something like this is look at the uptime system because guaranteed if it's been up for, I don't know, more than a couple weeks, there's probably been a vulnerability that's been published that would have led to a remote, well, not necessarily remote, but a root exploit if an attacker got access to the system. And I think John points out from some of his research that there really hasn't ever been a time that at least the Linux kernel has been vulnerable to some exploit or other. And so it is tough. It is tough to manage. And one of the things that we sort of look to do with security in depth is to make sure that even if one system gets compromised, that an organization as a whole doesn't sort of suffer. And there are ways to actually kind of contain things. And certainly some of the batch queue systems and so forth that some of these clusters have implemented over time sort of been oriented around that, all right, partitioning access to data and as well as compute resources in manner that can isolate those kind of faults. But it's a tough problem. And it's become a tough problem, particularly because the attacks are no longer just against those systems, but against the users, right, and admins of the systems because it's easier. Almost everybody has either some kind of filtering firewall or again, the router switch configuration that kind of protects those systems from, or firewall that went from remote access. But when attackers can simply mail an email to somebody with a corrupted PDF that pops in a wrote shell or something on our user's box or installs a remote access Trojan, there's very little you can do to clean up after a user has been compromised pretty severely. And so a lot of the focus and a lot of the current rationale behind our current company duo and a lot of what we're doing in terms of our research is in figuring out security solutions that can deal with end users being compromised. So you mentioned their exploited user account or like they get a user's password or something like that or some form of social engineering where they figure out a user's password. How common is it actually to see a completely drive-by like if they have your IP address and they can actually just get into your system? Is that very common anymore? So there's definitely a lot of brute force attempts that target servers that have exposed SSH port listening with common usernames and passwords. So if you have any sort of server whether it's a part of HPC cluster or just a standard Unix server, you're nonstop being hammered by numerous brute force attempts from all over the internet trying to guess usernames and passwords. And if they succeed, that's when they'll replace your SSHD binaries to collect usernames and passwords and sort of spread the infection from there to gather more credentials. The other thing that we see though is we also see increasingly target attacks where instead of simply drive-by sort of scans for machines to brute force. For instance, in the Apache.org attack of last year where the attackers actually got as far as the Apache build servers compromising the admins and all the local accounts originally through an XSS, right? Through a web vulnerability on their Jira instance, right? They just so happened to have an open bug tracking system that an attacker posted an exploit onto that compromise that user's accounts. And of course, with passwords being shared between different accounts, they're able to follow that user into the Apache infrastructure. And so that's one of the big challenge that we see that even if systems are secure themselves the end users are often the ones being targeted. Okay, so still most of the time we're talking about users actually gain access into doing some sort of root escalation. So you guys actually have a product and let's do a security which I recently started using and I've liked it so far. What is it and how does it prevent these like brute force attacking or compromise passwords? Duo is an implementation of two factor authentication where the two factors involved or something you know which is typically using a password. And our second factor which is something you have which in our case is a phone either a mobile phone, a landline or actually a hardware token that we also support. But this idea has been around for forever. I think the original, you know DoD orange book back from the rainbow book days kind of outlined different models of authentication that would be used for different, you know levels of security for government use. And the idea behind providing again a secondary factor of authentication is simply that, you know passwords are easily lost, shared, stolen and they're hard to audit, you know sometimes it's very difficult to tell if your password has been stolen. And if you know, if you're using things like a stage keys for instance, right those can also be stolen there's also just secret numbers that happen to be in a file on disk. But again with end users being targeted those can be stolen as well. And so the idea behind Duo is, you know to try to make two factor authentication as easy to deploy as possible as easy to use as possible and there's a little administrative burden as possible, right because you know who has time to go and manage a bunch of, you know hardware inventory in the form of these tiny little hardware tokens that you have to carry around. And you know, our background being I used to do actually security for the university managing actually a bunch of UNIX machines. You know, I know the constraints I think of having any kind of security budget in those environments. And so we've actually made this solution free for up to 10 users and with a lot of larger sites even having less than 10 admins you know, it's an honor and privilege for us to be able to give it away to actually some very, very large sites with quite a lot of compute resources to protect in a way that they can actually afford. So that's really the goal of the company. So I wonder if you could explain this to me. So you said that, you know, very large sites but it's free up to 10 users but you cited 10 administrators. So are you talking 10 administrators or 10 login users or what exactly does that mean? Yeah, 10 users of the system who would be using their phones different than login to manage a bunch of you know, different systems. You may not, for instance, have two factor required for your user submitting jobs. You know, although we'd argue that you probably should but certainly for admin access, right? For root accounts and so forth. We're trying to make it as easy as possible for folks to be able to roll out. That's actually pretty cool. So you're talking about a different granularity here that some users could have two factor and some users not. Did I understand that correctly? Right, yeah. And a lot of our customers are deploying us for administrative or privilege access to a Unix servers. It's sort of a different model than the traditional enterprise case where you have a lot of users, all your employees accessing a handful of systems when in some HPC environments you have maybe a handful of admins that are accessing hundreds or thousands of actual systems underneath. Right, so to give you an example, right? You know, we have a customer who's using the system for free down in Indiana. The Indiana high performance computing group down there who for their various, you know, Linux and I believe AX clusters, you know, have us deployed as part of their requirement for their Terragid grant. And again, this has allowed them to again, maintain compliance with these sort of university regulations and so forth and those grant terms. Anyways, it's just very easy for them to manage because they just don't have that many people, you know, logging into the systems for administrative access. So you mentioned, you know, using this for administrative users, but that may be managing thousands of systems. If I need to distribute this a new configuration for my resource manager to my thousand compute nodes, so I actually have to, you know, authenticate a thousand times, how would you set this up to have two factor but somehow still make it easy for the administrator to push things to all of the systems at once using SCP or some other tool? Yeah, that's a great question. So one of the things that we have coming out of PyG specifically for that use case that we've seen from this environment is a way to batch those transactions so that we can actually have, for instance, all of them approved at once, right? But visible, for instance, within your smartphone. So one of the ways that we do authenticate people out of band using their smartphone is with a mobile application called Duo Mobile that's available for free for pretty much every major smartphone platform. And we can actually literally push the details of the commands being executed in the transaction to the phone to actually approve or deny with one touch. And in other scenarios where we're also doing things, for instance, like in financial services where we might only do that if there's some element of the request that is actually anomalous, all right? So it's sort of adaptive authentication based on where the user is doing it from or whether, you know, in their case, if it's like a new pay or something, we can do that. But for large scale compute environments, we're looking at different models to do fraud detection and so forth to make this kind of thing really scalable in that way. So how is this implemented? Is am I, I'm guessing that this is kind of a Linux PAM kind of service so that it can inject itself during the login or pseudo kinds of levels of authentication or where do you insert this? Yeah, for our UNIX integrations we have sort of two models. The one is that you mentioned with a PAM module that can work with any sort of PAM-adailable application whether it's pseudo or SU or OpenSSH with password auth. The second that we use, which is very common for UNIX integrations is a wrapper called login duo which wraps your traditional login shell and is executed in OpenSSH Ds force command so we can post authentication, we can actually wrap your shell and make sure you go through a secondary stage of authentication which allows us to integrate with a pubkey auth for OpenSSH which using a PAM module is not feasible in that scenario. Are there other ways as well? Like what say I'm building a specialized application that's not necessarily a root level application but I have some privileged actions in there. Is there an API that I can use to call your stuff and say, hey, get me a two factor before I perform this privileged operation? Yep, absolutely. So we have both UNIX CAPIs that are available as actually part of that Duo UNIX package, a lib duo that you can link against and simply call to authenticate just about anything. And then we also have web SDKs that are all OpenSource so all this integration code is all OpenSource and hosted at our GitHub at github.com slash duo security. And we support PHP, Java, dot net, Ruby, Python. Yeah, we are OpenSource guys and that's our background so we feel that not only giving back to the OpenSource community is a good thing but also the fact that you're deploying these PAM modules and login duo and web SDKs on sensitive servers so you really do need the source to be able to audit for security purposes and we supply that fully open in our GitHub to the world. Yeah, well, I mean, we're just kind of elaborate and I mean, I actually was one of the authors of OpenSource. If you look at the SH man page, you'll find me there. And the design of our UNIX integration which includes again that login program was really to allow for you to be able to deploy us without restarting any SSH servers anywhere. And so that's the interesting thing I think about our login duo integration that is sort of unique is that you can deploy it as a user. You don't need root level access to deploy it if you tie it to, for instance, your SSH authorized keys and you can also deploy in a way that doesn't require again any changes to any system configuration or any restart of SHD. So for large production environments that again, you can't take down or whatever, you can't bounce, it's an easy way to introduce it without really messing anything up. So one thing I want to point in here is that so I set up login duo and all my personal systems and stuff. I had like six different machines, couple of VMs. They were all Linux based and one Mac based machine. It was really easy. I didn't have to set up an actual server because you guys are actually providing a service. Everything's set up on your end. All I have to do is the client side stuff. So compared, I'd always been freaking out about two factor and I got scared a little bit and came across this installed it and it was ridiculously easy to set up. I was really happy with the way it was done. Yeah, that's something we really targeted is the ease of deployment for our two factor auth. We don't want you to have to deploy a extra server on premise or on your network, especially if you're a small user with 10 machines or something like that. So being able to just drop something, a very lightweight module into each server you're trying to protect and have it all backed by our secure cloud hosted service. That's a real win from the integration cost of adding two factor auth. Actually, a funny thing is sometimes I forget that I even have it there and I like scp a file up there and all of a sudden my phone rings and I'm like, who the heck's calling me? And I pick it up and it's like, this is deal with security. Someone's trying to log in, approve this press star. It was like, oh, oh yeah. Yeah, I want that to happen. That is one of the downsides. That's fascinating right there. So this is not like the traditional RSA token, although I know you said you guys offer tokens as well, but that's actually pretty darn convenient because I have to admit I was assuming we were talking about typing in a code somewhere, but you're talking about you just performed some action, you get a phone call and you hit star and then it goes through. Did I understand that right? Yep, yep, that's one of the factors. So we support phone calls, we support, you know, pass code sent via SMS. We also support, you know, hardware token and software generated, you know, one time passwords that our mobile application produces, but then we also support this smartphone push, which is, you know, I think really unique to our system that, you know, if you have a smartphone, you can receive a notification and simply hit approve or deny to approve it. Oh, that is tremendously cool. Yeah, actually I had something come up recently where I needed to provide temporary access to a system to some remote providers. I actually generated some of those SMS tokens and in your settings, you let me say how long those tokens were good for. So I said, you only have 24 hours before these tokens go bad. It was actually kind of a neat way to like give them something that would work and it all worked, it was pretty nice. Yeah, we've tried to stay sort of an authenticator agnostic, you know, supporting whatever authenticators, you know, work best and are most flexible for the users. So, you know, we understand that users have a wide range of requirements, whether they have a smartphone, whether they have a dumb phone, whether that phone is online or offline when they happen to be logged in or even if the user has no phone, whatsoever, and needs a traditional hard token. I must say though that the neatest part is the fact that you let me type in a message per server that when the phone calls me, it does like text to speech on that. So like I have the dumbest things said to me when certain servers call me, it's pretty funny. Hey, let me ask a completely out of the box kind of question here. So I'm not a security expert. I sort of understand the issues around these things, but it strikes me that there's at least some kind of similarity here between authorization of a particular individual, right? You're looking to say, yes, this is Joe and therefore he is allowed to do this particular operation, right? Does OpenID come into this at all or is there ever a meshing between, you know, the two factor authentication that you're talking about and a particular, say, OpenID on a random service? Yeah, it's not. That make any sense at all. Yeah, sure. No, it is confusing space for sure. I mean, authentication means a lot of things, a lot of people, and particularly, you know, in HBC, you know, things like federated identity are certainly hot topics with a number of researchers and different organizations that do need sometimes to access each other's environments. You know, we talk a lot with the internet too folks about what they're doing within common and have seen actually some of the challenges of how organizations represent their users to each other's systems, right? That's slightly different problem than the one that we deal with. And we think it's certainly important, you know, to have a way to sort of fluidly authenticate yourself. It's like having passports, right? To be able to cross international borders. You kind of do want to have a system online that allows you to authenticate as, you know, as a representative of your organization to another organization. But what we really do in terms of two factors is, it's more like an identity verification in a way that's out of band. And so because we're not ever, you know, providing primary authentication, we're not ever making an assertion about who you are and what organization you belong to. We simply tell you that, yeah, this is the same guy that logging in that with this, that has this device, has this phone that you saw last time. It's more a way to kind of, again, tie a piece of physical hardware to an account where otherwise, you know, you don't know where this person's coming from. You know, you don't know, you know, just because they have the password, maybe it's them, maybe it's not. And so- The key word you threw in there that made it make sense for me is you're not doing the primary authentication. So that, I think that makes it clear. There was a very polite way of saying, no, you're wrong, Jeff. That's actually from a, not only a philosophical standpoint of, you know, we don't want to get involved in that hairy, hairy space of password management and single sign on federated identity, but also from a security standpoint where we only want to be that secondary verification step. We don't want to ever be in that, that path of your primary authentication. That's not our job. That should be handled independently for security purposes. And it's also, it's kind of like belt and suspenders, right? It's the reason why we believe that our service is completely appropriate to offer as a cloud hosted service, you know, again, that you guys would use remotely because all we ever track are an opaque identifier tied to a device identifier. We have no user, we have no full names. We have no addresses. We have no email addresses. We store no personally identifying information at all, which again, really reduces the scope of risk when you think about, you know, tying some portion of your login to an external service. And so, you know, we're really the service that you use to reach out and touch that person that you're seeing a login from, and that's about it. So because of this, though, the machine you're connecting to needs to have network access. Obviously, if you're protecting only SSH or something like that, if it didn't have working network access, it wouldn't work, but what does happen? Say if I'm at a local console and I want to run sudo and I've got the pan module in place and I've taken the machine off network because I want to make sure that it's not being touched or something like that because I'm concerned about it. What do I do when I can't see the network? Yeah, so we have a bunch of different models for that. So we have one particular configuration that allows you to define the failure mode if the network is down and it can either fail safe, which is say that you basically do it was disabled and allows the operation or can fail secure, which is say that it simply prevents the operation. And by default, it's fail safe. So if we can't be reached to do the second verification, then we can be simply disabled out of the path. But we're also working on various policy configuration as well where you can actually define that on a more fine-grained basis. We have a number of customers who only want to use us when they see logins from an unknown IP address or one that they don't trust. That's something that, again, is pretty easy for us to add so that it limits the burden to the user when they have to see us. So going back a little bit in the conversation here, you said you guys are all open source. Woohoo, we love open source. And all your stuff is on GitHub and things like that. Do you have much of a developer community surrounding you or is your code mostly out there just for transparency and third-party verification, other eyeballs on the code and things like that? Or do you actually get submissions from other people or have regular developers outside of your organization? I think it's a little both. We have had a number of external developer contributions, especially to Duo Unix, which is our integration with Pam and Login Duo. Our original goal is to make it very transparent, but as we see new customers come in and customers have different requirements, we do see more of a community developing for people who want to add to our service and augment the functionality in ways that we might not have thought of ourselves, but they might have particular requirements or particular functionality that they'd like to add. So we have been getting a number of contributions that are non-trivial from the external community. What we also see is we actually do see a community of folks actually open-sourcing specific integrations that our service can be applied toward. And so for instance, we've had two students submit WordPress, Drupal, Code Igniter. At some point, probably we have, there's another third-party that's working on a Media Wiki integration. And all these are just simple to drop-in modules for those different applications to add, again, two-factor auth through those logins. Because pretty much anywhere there's a log-in protect, you can add us, but if someone has already done the work to do it, then it's just easy to just drop in and be up and running with it. Yeah, and in particular with our web integrations, where we have a number of sort of native integrations that are SDK for each particular language, anywhere from cold fusion to classic ASP to Node.js, Python, PHP, .NET, across the board. But as you know, there's a thousand and one different web frameworks out there. So we've had a lot of contributions coming from these custom web frameworks where people take our existing PHP SDK and then they integrate it into the Drupal framework and then we release that to the community. So actually, let me interject here. I, in my personal non-professional life here, I do a bit of work with Drupal kinds of things. How far along is that module? Is that stable, usable by the general population? Yeah, it's supposed to, you know, probably posted to the Drupal blog some time ago and there's a bunch of folks using it. Oh, I need to go investigate that when we're done here. So, I had a question for you guys. So what are the main kind of concerns that you guys have? Because we've seen actually a number of breaches at various sites across campuses, but also from some different research groups that have been pretty staggering, you know, with attackers that are pretty, really, pretty clueless. I mean, in some cases, no internals of AFS and Kerberos and, you know, I mean, the degree of sophistication of some attackers these days, particularly trying to get access to large compute resources to, you know, mine bitcoins or run again, large password cracking, best jobs, right? This is sort of a perennial favorite. And we see this stuff all the time. And I always curious, you know, what you guys see as the main concerns that, you know, that the community has? Well, Jeff, I'll start with this one, considering I'm an admin of a site with public users. So, my point of view has almost been being around us, you know, even for that long, is that it's not a matter of if, it's more of a matter of when. And when that happens, it's still a major, major task of going through and cleaning stuff up. So, of course, we want to prevent it from happening as many times as possible, or, you know, just other things. You know, we have 1,000 hosts and you've gotta quickly somehow verify that you've got a new load to put on all of them that's secure, but you don't know what data they've touched and you've got a 140 terabyte scratch file system. How do you trust any of that data anymore? Because who knows what's been placed where? It's a real pain. So, you know, preventing it if possible and then minimizing it when it happens. Yeah. So I'll chime in from the user side because I'm just a poor schlep engineer, developer type over here at Cisco, right? So I'm not involved in any of the IT administration or anything. We're fortunate over here at Cisco that we have actually pretty darn good IT support. I mean, when they implement a new service and roll it out to all 60 plus thousand employees that it generally tends to work pretty well. Our VPN, for example, I do have a two factor out there. I have a little RSA token, which hopefully that's secure, but nobody really knows right now. But, you know, when I connect, it works. It just works. I pull it out. I type in one number and it goes through and I look at that in comparison to some of my peers who are in academia or other research organizations or even other non-IT based, you know, industry organizations. And it takes 10 minutes to log in on their VPN. I mean, that's insane. The real frustration that I can see from the user side is that it's gotta just work and be just easy. Kind of like what I was saying at the beginning of the podcast here that you want it to be as transparent as possible. Yeah, you gotta, you know, in the user's mind, it's gotta be, yes, I gotta do this extra step for security. There's a good reason that I'm doing this, but then it should just work from there and not be a, oh, God, I gotta sign on to my VPN and then type in six more passwords and da, da, da, da. You know, so if it works and it works well, I think, you know, one minor speed bump before getting to your email or whatever task it is you're trying to do is much more palatable to the end user. I've seen users with good security implementations who are like, oh yeah, I just, I pull out my RSA token and I go and, you know, that's it. And others who, you know, like I said, that's a no-joke citation of 10 minutes to log on to a VPN and that's just painful. It really discourages you from wanting to get on the VPN. So that's my big thing. It's gotta work and it's gotta work well. We see that all the time, you know, security is always a balance of protection versus usability and so it's a very delicate trade-off. If you try to roll out security mechanisms that are just so abhorrent that your user population rejects them or it's so unusable that it drives your costs up prohibitively high, it's just not gonna work. So you need something that adds that extra security but does it, like as you said, in a transparent way to the user where it doesn't cause a extra speed bump for them. So, you know, adding the speed bump or the gates for attackers but not adding the gates for your legitimate users. So let me ask you guys a question. You're a cloud-based service here. So let me ask you some of the typical cloud risk factors here. I mean, how many data centers do you guys have? How many, you know, different feeds and pops do you have on the internet? What happens when you go down? You know, I'm a CTO asking you for implementation for my company. Yeah. So one of the things that we've, you know, having built a business prior at our networks where we literally saved the internet from DDoS is back in 2000 when we started the company, that company, there were 14-year-old kids literally in Canada that were taking out eBay, Amazon, E-Trade, CNN, Yahoo just for, I guess, for the lulls, right, as people say today. And now that's mostly gone away now because of the plumbing, the traffic monitoring and management systems that we basically deployed across pretty much every major backbone provider. We've had a lot of experience with things like DDoS and a large-scale network attack for a better part of a decade. And with the cloud, it's been interesting. We've actually been multi-cloud for some time. And the idea behind that is really that, and also that in terms of our points of presence, I mean, we maintain shadow deployments across multiple regions with a lot of infrastructure that we can actually repurpose and reprovision in an automated fashion, right, swapping out. If you take a look, if anyone takes a look at the details of our deployment, getting kind of reverse engineer how we're doing things, you'll see that, for instance, all the customer records for where our API hosts, our endpoints are and so forth are all behind customer-specific DNS records and so forth that allow us to, again, move things around appropriately. And that really is the magic, I think, of modern cloud computing today, which is that it is elastic. We can spin things up, spin things down, move them around as needed in a way that to date has allowed us to preserve over four and a half nines uptime is all, we pay for other people to measure us, but that's sort of where we are right now with our site reliability. And also do that for other reasons that are not necessarily security and availability-related, but have to do with issues of jurisdiction and so forth. I mean, there are lots of organizations who they want to know that their cloud providers are in their data as in a jurisdiction that is apical to them. And so we do have ability to go and deploy because of our multi-pronged kind of deployment approach into private cloud-osings scenarios on multi-tenant public clouds, but also for very large customers deploy on-site, on-premise. And so that's the, I know it's a little bit hand wavy, but the honest answer there is that we're able to do just about anything the customer wants us to do in terms of deployment, but what we find is that most folks actually are just fine with us being using our default multi-tenant cloud service because of the flexibility it gives us and them to scale up, scale down, and also defend them against attack. So one thing I noticed, you've got these WordPress plugins and you've got the PAM module and you've got the Duo Unix, which actually has a neat way to integrate with protecting SSH keys, which I thought was pretty neat. But I noticed you didn't have a Windows client. Can you enlighten us about that? Yeah, the honest truth is we're a little bit Unix-biggest. I'm just being honest with you. We do have Windows integrations. We just don't like to do them. And we are coming out with, again, native integrations for things like RDP, internal services. We already have, again, things like form authentication for things you can put behind the SQL to UAG, TMG, and so forth. I'm sorry, you've got to understand, Brock and I are Unix-biggits too. We don't know what this alphabet soup is that you're throwing around. It is a pretty soupy alphabet. But if you look back at the Windows authentication history with Gina and OWA and TMG and... Well, yeah, but it's really the ICIPolicy server. It became the UAG, became the TMG to the Threat Management Gateway. And the whole ecosystem of what Microsoft networking architecture looks like for security and so forth is a realm in which we have to play. And so we do, we have those things. And we are working, again, to kind of go low level to bake into things even like desktop login that some people have asked for. But out of the gate, we prefer to, you know, but what we see also is that, by and large, most of the big computing environments that we see that are not desktop, right, but they're all servers are Unix, you know, we do still see, you know, you know, a handful of Windows servers being deployed for things like exchange and email and all the rest of that whole corporate stack, IT stack. But when it comes to, you know, high performance computing and other things, you know, large scale compute environments, I mean, I don't know what you guys see out there either if you've seen a lot of that. And we did have other, for instance, you know, friends, previous customers at Arbor and so forth, companies like TerraMark that have run some of the world's largest VMware vCloud instances, but those have also supported a lot of Unix instances, right? You know, so I, you know, I'm not gonna slide too much on Microsoft and Windows stuff, but the honest truth is it's, particularly for your podcast listeners, I think it's hopefully they'll appreciate that, you know, we're big, big, big Unix guys, whether it's Linux, John was on a lot of Linux kernel stuff. I did a bunch of NFS before stuff for Linux and BSD. It was also open BSD developer. And I think we all cut our teeth on things like Sonos back in the day. And yeah, I've been, I've watched with fascination is, you know, pretty much all the commercial Unices have died out over the past decade and replaced by Linux. But yeah, we're doing what we can to kind of keep the dream alive. I'm sure that, you know, Unix is still the most secure and, you know, you know, I mean, it's certainly the most flexible environment for computing today. So I want to touch on something else. The university uses a lot of Kerberos type systems where you get a ticket that lives somewhere that then gives you authentication access or you also mentioned TerraGrid. TerraGrid uses a lot of grid security infrastructure, GSI, where it is another ticket based system. It seems like if you had a compromised system, you could then just take somebody's ticket and then do something. Does Duo do anything for that? Or is that something that is just, that's a hole in that kind of system? No, absolutely. That's exactly I think the point of us being able to do authenticate transactions versus users in a given application because tickets again are effectively shared secrets, right? That if they're stolen, right, they can be reused sometimes, sometimes not. But certainly the end user passwords that are used to acquire those tickets can be compromised. And so, for certain sites, for instance, you can imagine that there might be some kind of batch king system and stuff that upon job submission would be able to validate that the user who submitted that actually was them. And we could, you could use all the rest of the native. I don't know what's hot these days in this world whether it's Globus or whatever it on this, all that gobbledygook. But on the back end of that application, we can actually again be added to authenticate individual transactions if they look like they're weird or if they're high risk, right? So you can imagine that we might be deployed only for certain accounts or only for certain kinds of for jobs and only for certain infrastructure that's really mission critical. And we're fine with it. That's really our goal is to make sure that where two factor can be useful and is needed that it can be deployed appropriately. And we don't necessarily want to make those decisions for the customer. I mean, the customer knows best, the customer is always right. They know their threat profile, they know their applications and they know where the sensitive transactions lie. Right. But it's interesting. I did a bunch of work on, I did all the original integration of AFS and Kerberos into SSH, all the ticket passing stuff and so forth. And I'm a big believer. I'm a big believer in trusted third party, need them shorter based key exchange protocols. But at the same time, they don't solve any problem and the threat is really migrated towards something that's so much more mundane, right? You can have all that awesome infrastructure and still someone somewhere opens the wrong email. So where are you guys going in the future? Do you have any features that you can talk about publicly that are coming down the pike? You mentioned one earlier already, but given that at least some of this stuff is developed in the open or maybe you develop internally and then push to the open. What are some things that your users and customers can expect in the future? Well, you know, one of the things that we're doing because, you know, there is a lot of hype around, you know, mobile security and what's happening there and then which kind of begs the question, you know, can you really trust your phone as an authenticator, right? For access. And, you know, John here has done, you know, quite a lot in that area. Most of the major breaks in Android over the last year, including the pretty, you know, catastrophic break of the Google Android marketplace that took Google quite some time to fix up. We're part of some of the research that we've done in this area where, you know, the computers that are now in our pockets, you know, these smartphones, you know, they're better networked and in some cases, more powerful than our actual computers were just five years ago. And so, again, there is some appreciable threat there that, you know, we also need to help solve and some of the things we have coming down the pike are targeting exactly that to make sure that, you know, your mobile device is secure and is clean and free of any threats so that you can actually use it in a secondary way for authentication. But beyond that, you know, a lot has to do with our specific integrations. We've built what we believe is the best platform in the industry for doing this kind of thing. And we just hope to find it applied to more and more environments. Because, again, there are plenty of places where you log in to act as something sensitive or, you know, mission critical. That if, again, if we had a chance to protect, it would really improve site security. So what's some of the, like, websites and places to get information about Duo? Well, our own website, www.duosecurity.com, is where you can actually sign up for our service. Again, for free, for up to 10 users and without even a credit card, it's, you know, you just sign up and you can be up and running and using it in literally five minutes. We also have a blog where we talk about security users of the day. And actually, one of the posts that we wanted to do at some point is we'll be looking at some of the security issues in this environment, in, you know, research computing and high performance computing, because there had been some fairly high profile breaks over the last, you know, a few years that, again, kind of went by quietly. But if you look at them, I mean, are fairly serious. Because one of the interesting things about, you know, this domain is you've got lots of users from lots of different places sometimes with sometimes, you know, really interesting, you know, access to a lot of interesting systems and data. And if you're able to compromise them, one of the reasons people go and do things like install, you know, backdoor to SSH demons that mail passwords out, right? Once they've compromised, you know, the login server for one of these clusters is because those users go lots of places and sometimes, you know, use the same passwords or credentials, again, to get elsewhere. And if you kind of map out, you know, you map out the incidents that have happened and in other communities, right? Where there's so-called ISACs or these incident sharing, sort of communities that, you know, compare notes on who's been breached and how and why and from where, you'll find that there's just these huge attack trees that follow from one side being attacked to many other sites being attacked and again, oftentimes going back to the users. And that's actually a topic that we do intend to cover because it's one of those things that is very, very tangible and that sometimes you can find out details about whereas, you know, a bank being breached, everyone ends up being very hush-hush about. So we'll start to, you know, cover some more of those kinds of things and you'll also find other folks, you know, tweeting and blogging about us. If you look for DuoSec on Twitter, you can follow us there and you'll also probably find lots of folks, you know, tweeting and blogging about their experiences with us. And as Doug mentioned, it's really easy to get started once you sign up on our site and I think our record time that we've clocked so far is from sign up to a working DuoUnix integration and production was six minutes. So, you know, if anyone out there thinks they're a better Unix guy, we invite you to break that record. Excellent. Okay, guys, well, thanks a lot. We're gonna wrap this up and I'll have to show up soon and thanks again for your time. Yeah, thanks for your time, guys. All right, thank you guys so much. We appreciate it.