Hello. Good morning. Good afternoon. Depending on your time zone for sure. I would kindly ask you to introduce yourself with a few words. Maybe we start with J Jacob.
Yeah. Hi everyone. I'm Jacob. I do product marketing at Bitglass secure access service edge offering, and really excited to be here with you today to talk about zero trust.
Thank you, Scott.
I'm Scott Rose. I work at the, as a computer scientist at the national Institute of standards and technology,
And last but not least Rebecca
Rebecca Nielson and I'm director of technology integration for PPH enterprises here in the Washington DC area.
Okay, thank you very much for that introduction. Maybe we start with a really basic question, but I'm pretty sure not everybody's aware of it. And from my point of view, it's a perfect question for Scott. What is your trust and why is it important and relevant today?
Well, yeah, I guess, you know, as we, as we learn through the day to sum it up, zero trust is basically a set of principles. It's kind of all the good things that we've been doing all throughout the years of, of ideas of, you know, least privilege, you know, trying to restrict lateral movement, less reliance on perimeter, multifactor authentication, all those kind of good, healthy risk based cybersecurity principles kind of rolled into kind of an overall architecture and used to authenticate and authorize users devices before they access any kind of resource on the network. And that's, you know, kind of at a, at a nutshell, you wanna kind of never grant implicit trust just based on either network location or, you know, previous authentication, but you wanna do that in a continuous basis throughout, throughout a workflow.
Perfect. Thank you very much. And Jacob, what are the basic components of such your trust environment? What do you see there?
Yeah, I think, I think Scott really, really nailed it with the idea that, you know, you want to have implicitly zero trust. And so, you know, I think that some of this is going to require things like really robust authentication, knowing who your users are, because you're going to need to know who is who you're going to enforce contextual and identity based security policies, but also some other things such as, you know, DLP, for example, the ability to protect data and provide varied levels of access to files and, and resources and applications in order to make sure that sensitive information doesn't leak and you really are sticking to those principles of zero trust.
Okay, perfect. Rebecca, anything to add from your end?
So I do think I, I really like those definitions, cause they're much more positive about what a lot of times people try to define zero trust by what it isn't rather than what it is. I do think that one of the authentication is really important, both from the perspective of the end user, but also authenticating the device that that user is using. So not only do you need to trust who is accessing your resource, but you need to trust the path that that data is traversing, because if somebody can access the device other than the user, you think you're talking to, you may have just handed your resource off to somebody you didn't intend to.
Okay, perfect. And how does identity and trustworthiness fit into an overall zero trust system? Rebecca?
So I, I sometimes say that you, you can't do zero trust without identity management, but you can do identity management without zero trust, but it's really a core, almost a foundational element of zero trust because if you can't have a good level of assurance about who both the resource side and the end user side are, then how do you be able to know whether you can create a trust in order to share that resource or not? So it really, if, if you don't have good identity and access management, you need to start there and then build other zero trust things on top of that.
Okay. Scott, what do you think is having standard identity and access management or IGA solution to foundation for zero trust? Or is it something different or something which integrates into each other?
No, I, I agree. It's, it's one of the pillars you can say have zero trust, you know, it's, you know, user identity, device identity, you know, and, and data access policies. These are kind of the foundations. You know, if you don't have, if you don't know who is all on your network, what user accounts, what, you know, system accounts are actually operating on the network, doing, you know, performing actions, you really don't have a Azures architecture or even really trust in that your business processes are, are acting as they should. If you don't know, who's actually doing those things. If you don't have full knowledge as to what, what user identities are or what have, what access to what resources
Perfect. Usability is a big topic. Earlier this day, we had a, a longer discussion about how much impact our security of things. We try to implement have to, to the customer, to the user who is using the system every day. Especially if you talk about multifactor authentication, all this stuff, and users are forced to ask for, for a second factor or something like that. Jacob, what do you think is here the best approach? Is it good always to ask actively the user to do something? Or is it more in the direction in behind doing passwordless stuff doing or using metrics in behind?
Yeah, I think that it, some of, of it's going to depend, but in general I would say passwords are, are not enough, right? I mean, that's kind of obvious at a base level here because we have people who write their credentials on a post-it note and stick it on their computer and do those kinds of things, or, you know, fall pre to phishing schemes and whatnot. And so passwords alone are not enough, I would say. And so you really do want that, that multifactor authentication where, you know, you're using Google authenticator or SMS tokens or hardware tokens, just something else to further reinforce, you know, that you, your authorization, your authentication process. And in particular, just to, to add one, one note here, I think being able to enforce step up authentication in with MFA is, is really important. So not just okay, someone's signing in, let's have them, you know, undergo MFA, but also, oh, this person is doing something kind of suspicious. Maybe they aren't who they say they are. Let's, let's enforce step up MFA in real time and, and challenge them for additional authentication. So I do think multifactor authentication and especially where you can use it in a, a real time kind of fashion is, is really powerful.
Scott, what do you think is step up the right thing is multifactor the right thing, or do we need something more,
Definitely a multifactor or, or some of the new password lists, technologies and ideas that are kind of out there cuz you know, if you follow the, you know, the strict letter of the law of zero trust, you can start introducing what's what some call security fatigue, where you keep pestering the users for either during a password, a pin inserting a smart card or something like that. And pretty soon users get tired of doing that and they try to find workarounds and then you've get the whole shadow it growth, which is kind of the opposite of what you want. So you have to kind of draw that line between how often are you actually prompting the user to do some sort of input versus some other factor. Some could be even something as simple as, you know, biometrics, we've seen some ideas floated of, you know, camera on the user, you know, is there actual the same person there?
Are you doing a facial recognition? The idea that, is it still the person at the console doing it or is somebody else there trying to do something in which case, you know, that that will fail some sort of check and that action will be stopped and the connection will broken or something. So yeah, there's, there's the things going on right now with multifactor. And then there's the things that kind of people are seeing in order to do this kind of full zero trust kind of more of in a continuous authentication. Could we, could we leverage something like that, biometrics behavioral analysis and that sort of, those, those kind of, sort of things,
Rebecca, in your presentation, in your previous presentation, you also talked about strong authentication and multifactor authentication. Can you repeat a little bit, your thoughts about that question?
Yeah, so I, I think, you know, users are remarkably creative at getting out of things they don't want to do. And so making it too hard to do what you want them to do will usually find a, they'll find a security hole in your system. So I think one of the things to think about is really, as you are managing your data that maybe low risk resources and accessing those low risk resources can have a lower bar. And then as the user wants to then maybe access a higher risk resource to do that step up authentication to say, Hey, okay, you stopped being just a general user. Now I do need to do like a little bit of work and authenticate yourself. I do think trying to do some of the frictionless multifactor where it's provided by the user's device can, can make a difference.
But I also, I, I also think thinking about the concept of fail close versus fail open and for a given transaction, which is more important, you know, is it better to prevent the legitimate user from performing an action because they can't authenticate in order to prevent the attacker or is it better to allow the risky transaction to occur and then maybe figure out how to stop the attacker later if it turned out to be an attacker. So a lot of it really is about doing that risk assessment and figuring out what the balance means and that's different for every organization, which is why it's hard to just say here is the right answer.
And that's honestly a good statement. There is no right answer, but there's a good approach and a good process. Jacob, Rebecca already started to talk about risk level and risk scoring and things like that. How can we decide and define how risky a user is, or at least the combination of accessing some data or some application? What is here a good approach?
Yeah. I think that Rebecca probably touched on this a little bit just now, but just to echo what she said somewhat here, I don't think it's necessarily going to look the exact same way for every organization, but there are a few things that you can keep in mind as you're trying to figure out how you should go about this and in your company. So, you know, what is their, their, their level in the organization? What kind of data should they be privy to? What should they be able to access as you go up the ranks presumably, or perhaps by department, you know, there are gonna be different resources and, and data types that they should be able to access. And so when people go out of their, their normal kind of state of affairs, so to speak, that's something that should be seen as a, a risk, but even on top of that, people can do risky things in line with accessing data that they normally access.
And what I mean by that is, for example, you have a, a salesperson who, you know, is accessing a CRM app or something like that. And they should access that CRM app. That's part of their job. But if they suddenly download, you know, massive quantities of data and they don't usually do that, then that's something that's going to represent a risk. And so you do want some, some real time awareness. And typically this is gonna rely upon things like machine learning, where you're doing, you know, user and entity behavior analytics. And you're saying, okay, here's the normal baseline of this person's behavior. They're doing something pretty unusual. They're departing from that normal baseline. So again, that can be resources, they access how many resources they access, maybe something like time of day, geographic location, device type, all kinds of different factors that, that you should consider, but not necessarily one size fits all. So plenty things to think about.
So at the end you have to collect various attributes of the user. So device location, time of the day, if he's in vacation or not, or things like that and define policy. So this is the core, the heart of defining a, your trust strategy. And this is what Scott also shared in his presentation about the newness standard. Scott, if you start with defining policies, is it a thing you do once or is it, how do you start and how do you maintain it at the end?
No, it's actually, it would be more of a continuous process. Actually. We relied on in our, in, in our, in the special publication, 800 dash, 2 0 7, we relied on previous missed work. It's called the risk management framework and it kind of describes a series of steps and kind of, it's a continuous process of identifying and evaluating and then testing and then going into operation. And then all then a feedback loop back to the beginning. Every time something changes, anytime you set up a set of policies for a workflow or business process, whatever you wanna refer to it as anytime there's a change there and new devices added and new users added a new technology, upgrade, whatever a new site, you know, that, that kind of restarts the process again, where you identify it, how does it work in what policy changes need to be made? How do I test that? And then how do I go into new operations? So it's kind of a, kind of a continuous improvement loop that we describe in the document. Based upon, like I said, there's previous missed work called the risk management framework that that's also available that people can use as kind of a, a guide to start this kind of process in policy generation.
Very interesting. Rebecca, you, as a person who is very experienced in designing and defining processes, what do you think about that statement and in general about designing and defining processes or policies here?
I think that's exactly the point. You can't just go from where you're at to saying you have a full zero trust environment, you know, in six months or even a year, it is a continuous process and it's something you almost never finish because technologies change, threats, change what your organization does for a living may actually change. And in fact, I think that's one of the most important things is to really pay attention to what's changing and how systems you've implemented either are adapting or are not adapting to address that. So when you're looking at processes, they need to be reviewed on a regular basis. If you don't have a process in place, that's maybe where you start is to say, how do we look at what we're doing? I think a lot of the attacks that we've seen recently that sort of led to the popularity of the zero trust as a concept were defenses that were designed for a workforce that sat in a building on a physical network and didn't account for your suppliers coming in and accessing your systems directly didn't account for your users doing work on travel from their personal devices.
So really paying attention to how is the environment changing and how do processes need to change to address that is very important.
Definitely, definitely. We are almost at the end of our panel discussion. This always goes so fast. One final question. What future developments do you expect in that space in this very agile space checkup?
Yeah, I think once again, Rebecca kind of set the stage for me a little bit here. I think that, you know, the last year in particular has really highlighted some things that have been happening for the last few years. So we've been moving to, you know, cloud remote work, B Y O D all of these kinds of things for some time, but when, when COVID hit, you know, everything just accelerated very quickly. And so I think organizations have been forced to grapple with the fact that the, the legacy style of security isn't the best fit for the world we live in anymore. And so in order to stay safe and have secure operations, you really need to make sure that you have flexible security in place that can adapt as things evolve, because if you're constantly playing catch up, you know, you're, you're never gonna get there. And so you really do want, I don't want use a buzz term like future proof. So I'll just say flexible solutions that can meet evolving sets of, of use cases.
Perfect. Yes. And there is the set statement. I'm not sure if you know it, the best driver for digitalization is the pandemic crisis, and that's honestly a set statement. So Scott, what about, what are your thoughts about future development towards your trust? What will change?
I, I kind of agree with that, like remaining flexible and the idea of, of flexible security policies. I kind of see it as also telemetry is coming into you into its a new field. It's kind of useful. You're gonna be in order to do zero trust in order to actually have this kind of flexibility. You're gonna need to get all that data. And not only soon, you're gonna be drowning in data. You're gonna have to find some way of getting meaningful, actionable intelligence out of that. And that's probably looking at some of the gene learning models or even AI or something like that to kind of quickly digest all that incoming data from applications and users and all the actions and all the cloud based instances that are out there as part of a organizational infrastructure. And so can I, you know, quickly react to kind of new threats and new risks.
Perfect Rebecca.
So one thing I think is a really interesting area is we're seeing a lot more security capabilities from mobile devices, you know, better protections of things like cryptographic keys, but also better ways of compartmentalizing data so that I can view data on a device that maybe is less secure, but the data is being held inside a secure vault within the device, and it's not stored on the device it's stored in the cloud. And so I think some of those capabilities really will provide a better way to share data so that your users have it when they need it. But it's not sitting in vulnerable locations, it's protected in a cloud environment and it stays there. And I think those can really help with a better user experience while still improving the overall security.
Definitely. Okay. So we are really at the end of our panel discussion. I want to say thank you very much to Jacob. Thank you very much to Scott and thank you very much to Rebecca for your insights about zero trust and how to approach it. Thank you very much.
Thank you.
Thank you.
Thank you.
