Access Control in 2016 - Deep Dive

Thanks. How about that? So I got a couple questions, so we'll start in about a minute, but anything we could do better? Eric can do... No, see, we wanted to give you the East Coast feel. So that's why we have high humidity, high heat. Okay? Yeah, you want snow. In California, we visit the snow. We don't live in the snow. You know what I mean? Yeah, so anything we're doing wrong? Yeah, yeah, I already know. The lighting here, sorry about that. Larger venue. Larger venue. Excellent question, sir. So let me give you a proposition, okay? I teach at City College part-time, and we could get City College San Francisco, their Chinatown campus, which is probably about a 10, 15-minute walk from Moscone Center.

The trade-off is we have lots of rooms, we have a large auditorium. The bad side is you cannot consume nor can we serve alcohol on premises.

Wait, wait, wait, wait, wait a minute. This is California. That doesn't mean you can't come in inebriated. It just means you can't consume on premises. So the thought would be to get some vendors to sponsor an open bar that's off campus. And that way at 9 o'clock when you come in for the first session, you can consume as much alcohol as you would like and then enjoy yourself at the sessions. And you're the first group that I've asked that have booed me on that one. That's excellent. I didn't say that before. Oh, OK. Now that I've given you the full story. Yeah. So would CCSF be acceptable? With an open bar. With an open off-site bar. We can't do it.

Across the street there's a Hyatt or Hilton or one of those hotels. Okay, so we could do some compromises, right? Okay, and we will have escorts. Oh, we could live stream to the bar. See, I'm creative. All right. So let me introduce today's session presenter here. Ehrlich, right? Dr. Ehrlich. And what are you an expert at right now? He just shared this with me. Changing diapers. Right? So I know you're dealing with a lot of shit, right? And isn't that what we deal with every day is security is shit. Well, that one didn't go over too well. Yeah, I'm going to turn this over to you, Ehrlich. Take care. Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman,

Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich Kahneman, Thank you. Ehrlich K It's going to be a deep dive, scratch the surface presentation. There'll be some technical stuff, like I show you some stuff, but there'll be also just the overarching concepts. This is based on an early version that I was presenting at TorCon, and it's evolved a lot since then. So yeah, I guess about myself, it's the diaper story. That's what

I do. And other than that, I've been in the industry for a while, and I think All you need to take away from this slide is that I've been kind of focused on access control for 20 years. And I work for object security, which you can read on the website. So anyway, access control. So the roots really We're talking software access control go back quite far. So there's one paper that people usually cite if you're on the academic end. And we don't have to go through it, but it's from 71, and it doesn't actually use the word access control. But it kind of has this idea in it that you can see at the bottom here, where there's a reference monitor that blocks something. Let me

see if I can handle the technology here. They called the enforcement point essentially reference monitor back in 71. So this is kind of, well, and then The picture appeared in a publication in 83, so this didn't move very fast back in the days, right? I started myself in 98 looking at access control and been banging my head against the wall since then. So that's what that is. And the reason why I'm going through this high level stuff is because access control means a lot of things to a lot of people. And very often what people do is then limited by that kind of particular bucket of understanding they have what it might mean. When you

look at Wikipedia, It's pretty broad. It says selective restriction of access to a place or other resource. So I want to say that because I want to kind of preempt this thinking that many security people have that it's about user account access, for example. It's a lot more than that. A lot more. And it may not have anything to do with user account access. There's also many buzzwords. In the next three slides or so, I'm going to throw a load of buzzwords at you to show you. It's not about the buzzwords. It's about the fact that I'm going to show you how confused the market is, how confused the community is around access control. So authorization is another one, which is specifying access rights to resources.

Yeah, I don't really know how that, strictly speaking, in the definition is different from access control. Now, the identity management crowd made it kind of like seem something else, a different process in the lifecycle. But it's kind of related. There are things like entitlement management that popped up a while back and then disappeared because that vendor got bought by a large vendor and went belly up from what I hear internally. Could have been any company bought by a large vendor, I guess. But anyway, so there's a lot of buzzwords, right? So when you try to understand the challenges, actually, you realize, well, and that's, I think, the crux of it. There's access control implementation. So we're not just talking high level blah blah here in a policy document. The

technical implementation is often inadequate, it's often not well understood. People don't really know what they're getting. It's very often not auditable. That's actually a critical problem that you have, that people implement something and there's no trail. So, you look at, for example, other hospitals that I've seen where they may have some access control or not, but the fact is when they have access control, they don't log anything. And then when something happens for HIPAA reasons, they don't really know. They don't have any way to demonstrate what happened or didn't happen. It's often confusing, inconsistent. It's dotted around the enterprises in different ways depending on what tools there are. Often either, and this is where it gets interesting, it's either too complex to be manageable, so if I really want

to do my access control right, it's a beast, or it's too simplistic to be useful. So you go to DoD and they have multi-level security and everyone understands that. You give somebody a clearance and some system a classification. And depending on the hierarchy of security levels that you've assigned, access is granted if the resource isn't higher than the caller. That's what multi-level security is. That's kind of easy. The only problem is it almost never really matches with your policy. That's not really what you wanted. So there's a huge disconnect. And then we have ever-changing policies and IT landscape. So this is kind of a big mess. that I guess we're in. So what I kind of always like to focus on, I think, is that there's

a difference between the what we want part and the what we get part, I guess, in access control. So what you have at the top is stuff at the really far and high end top is stuff where some guidance from some regulation or government or whatever says. Access should, say for user account access, it would say, access should only be granted to authorized users. Sure. No malware should ever enter the organization. Sure. Good. Great. So that doesn't really have any tangible kind of access control meaning. You can bubble this down. There's more. But a lot of that stuff, when you look at the English language that the lawyers cooked up and what that really means, it's actually

very rich, it's often very rich concepts like HIPAA privacy rules saying some access is only granted for the minimum necessary to do the task. That's least privilege, which nobody really implements well when you actually take what I just said at face value and try to implement that. Instead, the vendor landscape has kind of figured we're calling privileged account management now least privilege. which is a very small slice. So we do have major problems with the what we want part in the sense that people don't step back from their pre-established notions and read the thing for what it is or write the policy for what they really want so that it captures that. That's one problem. But

you do have this problem with the government guidance that there's no implementation. guidance of any sort. So it's easy to write a bunch of stuff if you're NIST. And then the question is, what are you going to do if you have an enterprise with 50,000 users and a whole mess of IT? I think this change of mindset is critical. That's, in fact, why I chose to try to present here. And now I'm here. Because I feel there needs to be a mindset change in the industry as a whole. And I hope you can become spokespeople, too, afterwards for that. to step away from some of the established notions that we've done over the last 20, 30 years in access control. They're not bad. They're

just tainting our thinking of what we can actually do. And by the way, they're also often not clear those requirements either. So anyway, the what we want part is the one half. And then there's a huge disconnect. And then we got the what we get part. The what we get part is the technical implementation. Let's face it. If you write a document and you paper shuffle at the top, And I don't think this is the crowd that does that. But there is a crowd that does a lot of that. And the Mosconi. They're over at the Mosconi, right? So

what you can call, and I didn't say the Mosconi part just for the camera, right? That was this guy. So you can say there's like this, if compliance, I guess, isn't implemented well, there's this whole spinning wheel. at the top that never hits the technology, and in the end something gets signed off that was written on paper and spreadsheets were shuffled and this and that. And when the rubber hits the road, it's totally disconnected from any of this. So that's the problem. At the bottom, you've got the problem that the tools are really fragmented when it comes to access policy. People have often put access control right into the applications. You just code it in. People use relatively basic mechanisms, and there are many.

basic firewalls, you look at basic network segmentation and things like that, these are very basic access control mechanisms. And they're good ones. The only problem is if that's, say, if I only have that one hammer, OK, so I'm the guy, the networking guy, say, and I look at my entire security only from the network layer, I'm missing out like 90% of the rest of the stuff. I need that too. But that's the problem on the what we get part. We got this hodgepodge of stuff and it's fragmented, it's all different. central understanding of the policy, and there's basically a disconnect. I call this the semantic gap. There's no trademark, but you can still quote me. You can tweet it now if you want. And this

is between the policy requirements and the implementation. That's a real, real, real big problem today. And when you look at auditing, it's not coming back. So the fact is that stuff gets signed off at the top then. Some CISO signs something that has nothing to do Really. It's a human process. So some technical guy gets some document, reads something, figures it's mostly BS. I don't know. That doesn't apply to my stuff. Figures out what they may have meant and what makes sense and implements, say, some permissions in some Java or something, right? Or database or whatever it is, right? So this is a real problem. Now, when you look at Why that is, I hinted

at it, one aspect is that the access control models that are used are often very basic. What's actually happening is when you look and you don't really have to read it, and you can't read it anyway, when you look at Wikipedia, this is just a cut and paste, there are many models already there, like the mandatory access control, discretionary, role-based, rule-based, identity-based, and organization-based, whatever. And I don't even subscribe to all of these names. But the fact is, they already have kind of a hodgepodge of stuff of different approaches on their website. And when you actually dig a little deeper and look at what these more high-level requirements say and what the access control model would be that would implement that, you

get a real big hodgepodge. So this is what I kind of put together, all nice acronyms, because they love acronyms. And I hope I don't get sued for using that image. But who is it? So anyway, what we do a bit later is go through some of those in detail. But I think now I'm just going to tell you the names and quickly what it is and explain to you why that acronym soup in a way matters, but why it's also designed almost to confuse the customer, I guess. So you have mandatory versus discretionary access control, where mandatory is, if you will, enforced policy by the system. Discretionary is more where the data owner figures out

when they create some content, for example, who should get it so I can pass documents on based on those permissions. Identity-based is what everyone knows. Somebody has a user login and they get in kind of role-based is also very known. Attribute-based access control is a relatively big deal, a very complex deal today that people talk about and can't really implement so well because it is a very rich model where you say, OK, why don't we just make rules based on attributes? And attributes could be anything. So it could be, for example, identities or roles. But it could be any other attribute that I can fetch to, like a task related to a person, geolocation, or anything else. Now, that gives me a lot more meat, if you will,

And there are tools out there to do that. It gives me a lot more meat to actually implement a policy that I want. And proximity-based access control. We have authorization-based like OAuth where I'm dealing with the whole problem more like by passing tokens around. So saying rather than who are you and what your permissions are, I'm saying there's this car key and I'm giving you, I don't care who you are, but you show the car key to my car and it lets you in. That's kind of what that idea is. It's a different model again of It makes delegation much easier. We got it on the network layer. We got the whole VLAN story, application layer security, virtual. Every layer has its own way

of doing it. History-based access control. And in case you're passing out and getting to the second column, there is risk-adjusted or risk-adaptive access control, which I haven't looked at in detail. There's something some DOD contractors did where the access control is essentially dependent on a calculation of risk associated with that access. Health-based access control is something we've done some work on recently and some university somewhere where it's not health of you, it's health of your system, if you will. So you would say, well, this system can only access that system if it doesn't spew malware, for example. Stuff like that. That's kind of a pretty obvious blocking policy. And what you see is these are all different aspects that in combination can

actually enforce a very rich policy. You have capability-based access control that's actually built in Linux and built in SE L4 and things like that, where you pass tokens around, unique references to, say, memory pages around. And then only whoever has the correct handle can see my memory page. Graph-based access control is something that we would say, OK, everyone can only access, say on Facebook, everyone can only access their friends and their friends' friends. That's based on a graph, right? Business process, I call it BPMBAC. Sorry, that's my name. I don't know. You could call that, I don't know, stateful workflow policies, I think, or something, where you essentially say something's only allowed in a certain

step of a particular workflow. So say before and after and things like that. Plays often a very important role because there's some steps. I don't think it's realistic to capture an entire workflow of an organization and then have access control. But you can make certain statements. Something else has to happen before something else is allowed, for example. Further down, you've got more the management parts of this. Model-driven security is one of them. And identity and access management is the big bucket and single sign-on. So anyway, now you're probably like, what the F is going on with all this stuff? It's really complex. On the other hand, it doesn't have to be so much. I think

when you want to categorize them, And actually before I categorize them, I want to, for the people that don't look so much at locking down networks but are more on the vulnerability end or the security researcher end of the spectrum, I should maybe explain how this relates. So this is sort of, if you will, about preventing a compromise from spreading across, say, your internal network. Because if something gets compromised, say you get your hacker node, some are one system, the access control systems on whatever you're trying to essentially then take over will enforce a better policy than if you don't have a policy or you only have role based. So say you hack a root account on a Linux box. You can do a load of stuff

everywhere, probably. Fact is, if these other systems all enforce a policy, you can only do whatever that account could have done and not other stuff. You don't get extra privileges. So that's the idea here. It's what I call the springboarding gets easier to control. Springboarding being that kind of moving over from one system to the next. It's also, when you look at it, it's the actual enterprise policy. The finding malware is, if you will, the hygiene part of it. This is on top of it saying, well, OK, so this user should only do this in this particular instance. And if this happens, and this device should only talk to that device if something else happened and things like that. So coming back to this now here, what's the, I

guess, one main distinguishing factor between those various approaches? So one is that they have one approach has the rigor. And you see that on the DoD end of models. So there's a lot of Essentially, if you will, the policy logic is baked into the model. Like a multi-level security, it's only one policy. The policy is, well, if your level isn't lower than what you're accessing, I'm simplifying. But if your security level isn't lower than what you're accessing, then you get it. So you have to be at least, if you want to say, you have to be top secret if you want to see something top secret or classified. If you are just classified, you can't

get top secret. That's about what it is, right? Role-based access control is very rigorous, too. You see much of what came out of government is designed with the idea that there is a rigorous corporate structure, if you will. And the funny thing is that not even DoD has that. But for sure, nobody else has it. So role-based access control fails in many cases because many organizations don't really have roles that stay enough static. So then you have something that we wrote about 15 years ago, or longer, I guess 20 years ago, called role explosion, where you bake somebody on vacation into another role. So it's Joe can access the MRI scanner, but Jeff can access the MRI scanner if Joe is on vacation role. And then if

Joe and Jeff are on vacation, then XYZ can access it, and this person can't roll. So you put random stuff into the rolls, and you have more rolls than users in the end. That's actually a reality and a problem. Or you have both. If stuff comes together and the stars don't align, then you have rigor and chaos at the same time. Or you can't manage it, or you can't implement it. So one way or another, you're screwed, I guess, unless you really know all these differentiating factors. There's also the things have heated up recently around this. It's been one of those things where you would go, 2005, I would go to customers and would say something not as, I guess, if you will,

refined, but more crude back in the days. But I would come in and tell them they need better access control, and they'd be like, I don't think so. Nowadays, IT environments have changed, and the policy landscapes have changed, and that has had impact on, I guess, if you will, the fact that access control is is even more insufficient today. So IoT and big data and stuff are classic cases. And the business environments have changed. Everything's interconnected. Everything's moving around. Multi-stakeholder environments, you know that. So policy-wise, we also have a lot more. We have HIPAA. We have whatever. We got CISOs. Most organizations now actually have CISOs. But 10 years ago, CISO was like the almost retired guy that was waiting for retirement, kind of.

So we have a bunch of examples where policy requirements highly impact the implementation. Like in health care, for example, nothing would happen without the regulations. So approaches you need to know. Let's kind of, if you will, deep dive into a few of those. I put attribute-based access control first because it's one that's been much talked about and not much implemented because of its, I guess, complexity. Some of it rightly, some of it wrongly. It's really, if you will, almost like a rule engine, a general purpose rule engine. So you say essentially if you, OK, so that's my way of looking at it, is to say you pick up an attribute, you calculate something, you compare it with something. So say if the user identity equals Joe,

then allow or something. And you can combine those rule elements. But you could also say, well, if the requestor's geolocation is within, and the resource's geolocation are within one mile, then allow. So you only allow it if they're, say, within one mile or within the same building or something. There's a standard by OASIS that they've written for, I don't know, 10 years called Ixacomal. That stands for Extensible Access Control Markup Language. And we're deep diving in some of that now. And there's essentially an architecture which I think is pretty much not really very readable. What it essentially is, there's a policy decision point, which is sort of like the thinking part. It has those rules, and there's a policy enforcement point that calls

the decision point and says, hey, you know what? I got these attributes that I found. Is access allowed or not, basically? And the rest is kind of padding in this model. So when you look at it, and you can see some of it here. It's like some pretty bloated XML. I can scroll you through it if you like. I have, I guess, some of them here and some IDE somewhere. Let's just see. I'll open this quickly. We actually, let me see, is this where it's supposed to be? Xtext. Let's take this one, for example, because it's probably more readable. Yeah. So what actually happens is these are really bloated. It's complex, but it's not crazy. But

this is actually stating something in the standard XML notation that many major identity management tools support. But when you round trip engineer an actual enforcement, They really only, if you will, often enforce, they have a glorified, sometimes only a glorified text editor. Sometimes they actually have a runtime, but it's sort of half-hearted, the support so far. And that's because of customer pushback. Because what that is, what you get blamed, if you come in and say, we're going to do Xacamo, you're being told that you are the complexity. When it actually turns out they are the complexity, they already have the complexity, except you now have a tool that you built where they have to enter the complexity, and that's what really kills the deal very often for the

exacrimal crowd. You're blamed for the problem because you're the messenger, I guess. So what we do in Eclipse, I've just had it open, is we take the padding off and import that in a more readable form. It's still a lot of bloat, so I colored a few of those things. Just to give you an example here, and I see if I can see. So for example, you could say, well, if the primary care physician string and the

If the calling physician is a primary care physician, so that's the string equal. And we have an action is calculated. So these are all rule elements, right? And then you can say, well, if the physician here we got is a, yeah, actually this is easy. If the role is equal to physician, for example, so you can combine this. And if somebody's accessing the medical record and if the the ID of the patient is

the primary physician ID in the record is accessing doctor, then it's allowed. So the doctor can only basically access stuff of their patients. You can capture that all very flexibly, just as one example here. So I took that from the XACOMO specification. That's why this is so much bloat, just to make a point here. Or here we have one that essentially says, well, take the date of birth at 16 years, compare it to the current date, and if that's higher, then we will not grant access, or we will grant access. So he would not allow if somebody's under 16, for example. So these are things that can be calculated with this policy language. And there's a lot of tooling out there. This is on the policy end, though.

When you're looking at the enforcement end, things are a different story again. It depends what you have. If you have some app servers that talk, there's a lot of enforcement infrastructure. If you have a hodgepodge, it's going to be hard. So this is never quite as simple when you're going full round trip from top to bottom. But there's a lot of implementation. So you can deploy such a tool. And the trick that we found works better is to start small. with one particular policy set and one particular environment and then grow. And think of master data management in a sense that your policy is in one place. You externalize that and have that and whenever

something needs to be enforced somewhere that is based on what you already have, you will not duplicate it somewhere but you will base it on what you already have. It's the same what we did for identity management for the last 20 years. to avoid the mess. Proximity-based access control is a special case, I guess, that can be implemented in this ABAC. I got an info from one of our customer engagements, one here, where it's essentially what's interesting about that rule, I read it out quickly, and I should be an eye on the time. All analysts, so this is intelligence analysts, can access all information about any suspect that has to investigate and also about all

other suspects that are within free hop social proximity of that suspect. So that's a nice rule. if you have a big data store that mines graphs of social networks of criminals, for example, which some agencies have, police forces, for example, what's the beauty of this? And this shows you what I guess this is the bring home, take home message with this moving up into the more human understandable policies. I'm not saying anything about any specific analyst here or any specific suspect or any specific task. All I'm saying is if these things are aligned and within three hops, If I fetch all these values and the value is within three, then I'll allow access. So what that means is I can have 1,000 analysts and 10,000

criminals in my database and whatever I have, and I'll only have one rule. So that requires tooling to take that and make that happen at the enforcement end. But the difference between auditing this and auditing a hodgepodge is huge. So that's, I guess, if you will, the logic of implementing better policies. You're trying to generalize without being so generic that it's kind of useless. So this is, for example, from our tool. It's sort of the same thing that you've seen in the Eclipse. It's actually very easy to capture these kind of policies. You just feed two attributes in, and I guess it's really blurry here. You feed the requested geolocation, for example, in here, and the resource geolocation. And then you say, is it

within three hops? Now, you have to have these attributes. They need to come from somewhere. So for example, the device, if it's reliable, or you might have tri-ungulation of the devices by the network, if you don't trust them, that would be a good way. So there's ways of getting those attributes. And that's an integration job when you want to do access control well. Now, again, people would then step back and say, I don't want to deal with that mess. or we just spent 20 years with that mess in identity management, and if I had said the same thing about identity 20 years ago, or you just got to externalize everything, put everything in one place, and then have something, a standard to connect everything, people would have said,

oh, go home, right? Now we do have SAML and a bunch of other stuff and OpenID, and it actually kind of works. So I wouldn't give up on this, and I think It's critical to do something like this, because if we don't actually enforce a real policy somewhere in today's environments, we're never going to get better than the attackers. I covered those guys. I guess this is a picture of the risk adaptable. They have a security risk determination function that essentially feeds in a bunch of values and calculates the risk of an access. That's interesting. HealthBase is essentially saying, Like I mentioned, you may be able with today's malware endpoint solutions to know the likelihood of a box being infected

or being compromised in some form, right? And you may want to block, say, other nodes pushing content into that potentially compromised box, but you may want to do that only for certain types of content. So say, for example, the box should still work for relatively unimportant stuff. got the crown jewels you wouldn't send anymore. You would just raise an alarm. So that's kind of the idea here. It has issues, implementation issues, race condition issues that need to be resolved, right? Because if these attributes values don't propagate around quickly enough between the different nodes, you will not be able to stop stuff in time. But that's a nice way of, if you will, marrying the malware

detection end of things with the preventive security enforcement part.

Business process-based, I have just an example here where you could, for example, say there's a bunch of steps in a workflow, like say a call center workflow tool or something. This was the example that we used. And you have one step that says charge the credit card of whatever calls me up and wants to order something, you could say something like, well, this has to actually go through these steps beforehand. And you have to have evidence of that before you can charge the credit card. And the credit card charging node will only accept the connection if the BPMS for the web apps, for example, is in the right state for that particular session, things like that. Now, that's, by the way, a hard one sometimes because

you have to get that workflow information from somewhere. So again, I guess the crux is The richer your policy gets, the more data sources you need to tap on in order to enforce it. And the quality of that data needs to be pretty good too. So if you have crappy data going in, then it doesn't matter how good the policy is. If it doesn't know your geolocation very well, it's only 80% accurate, and maybe it's got the wrong continent once in a while, then you might not want to do it. So that's the question. So we built that back then in a BPMS tool. It's an open source tool called Intaglio because we needed to get that state from somewhere. And that was kind of nice.

It would bake security policies into their applications without you having to configure anything. So if you change workflows afterwards, after you set everything up, it would automatically update the policies, right? Because you would say, OK, only if the workflow is correct will allow that particular node to be accessed. If you move things around, it's still true. but I don't have to manage the policy. There's this agility of policy, if you will, that you can support that way by moving up into more generic concepts. Graph-based, I think I mentioned already. So I think where we're homing in on is that the management of this is actually a major problem. So implementation is a major problem too, but when you look at the management of it, who's

going to write those policies? Who's going to integrate those data feeds? And who's going to check that they are correct? And who's going to figure out that the data feed actually matches with what whoever writes the policy thinks they are, and so on. So think of potentially like a scenario that has like 40 nodes here, for example. And it doesn't matter what it does. There's actually no text on my slide, so you're not missing anything. I know the projector skips a lot, but that's what it actually looks like. And you just want to sort of, if you will, in this trivial example, whitelist some flows between some devices and blacklist and block some other ones, just as an example. So the problem scenario can

then be looked at as just nodes. And nodes might have MAC addresses, IP addresses, and ports. So you can detect that and feed that in as one feed. That's just one attribute, if you will. And all the flows too. So that's not rocket science. You guys can do that too from TCP dump and stuff. Now feeding that into something that then ends up helping you configure For example, operating system firewalls or network equipment or application security and stuff like that. That's sort of, if you will, the manageability round trip here. So you have to have a tool that essentially can feed in all the stuff that we talked about and take your generic policy and essentially export something that gets configured somewhere.

You might have runtime agents that you can install. That's the nice, that's the cozy business case. If it's a homogeneous environment and I can install endpoints, I can do a lot. But I don't know about your customers and my customers. There's a lot of stuff where you can't touch the endpoint or it's some weird device or some weird whatever vendor maintained and stuff. So this is never really that easy. And this trivial example is only one of many aspects here. You have a lot of policy everywhere. in your organization, right? It's really unmanageable. And you look at this as a picture. It looks almost like this on a slide. It's a picture. This is not a circuit board. This is

a picture, supposedly, of a bank's high-level view of their IT landscape. That's from Computer Weekly. There's actually a web link. You'll ask me later. So that's just about the functional system model on a high level, right? And then I have some health provider customers, when you go to the compliance people into their office, there's a wall of paper that is essentially all the regulations that they have to deal with. And you're trying to marry those two, the landscape that they don't even know. So banks are maybe better than others at actually documenting their IT landscape. But you look at the scale of trying to do stuff. Turns out, well, it's always hard. But it's not so hard if you were to only say everything in one

place. So somehow we need to have some kind of master data management and some configuration management so we don't say the policy 50,000 times and 50,000 ways everywhere. In this trivial 14-node example, when you actually write it out, it's only four pages if you don't duplicate. Because why would you duplicate? You already said it. This is about whitelisting IP flows, very trivial example, but just as an example. Now, moving up the ladder again to actually something human understandable, well, if the rule is really only allow IP information flows we have detected and approved, say, in some learning mode, then we only have one rule left. And the analyst rule I already mentioned, now that doesn't apply to the specific scenario that I just had two slides ago because I

didn't show you the other feeds that go in. But if you just assume now there's other feeds, that would also be one rule no matter how many analysts there are. So that's, I guess, a goal. What that requires is to step back as a security professional and actively try to not think in the terms of an existing product. Because when you look at an existing product today in access control, it's either snake oil or it has a certain model baked in. And very few tools are flexible enough to let you really think in the way that the policy, that give you the creative, I guess, if you will, space to come up with the policy the way it actually should be. So you're like an identity and access management

guy, and you've done this for 20 years, for example, you would automatically take Whatever it is that happens, and not think about geo-proximity or analysts and suspects and geo-social proximity. You would think in assigning privileges to roles and the roles to identities and the entities to accounts. Because that's what you've done for 20 years. And it's very hard. And I'm maybe simplifying this, but it's very hard to step out of that and actually say, OK, so if we don't have any constraints, what would it actually be? And then move from that. down into this tooling. The tooling is there, so this isn't an academic exercise anymore. I showed you 20 of those models or so earlier. There's more than that. So then the question is to pick the

approaches that actually make sense to implement whatever you come up with, and then figure out what are the various products and vendors that can do some of that. So this is the semantic gap, again, that I talk between the human and the technical. I have something I think that this is you can believe this the one rule into hundreds of rules but when you also look at and I move forward I come back to this slide the high-level policy if you export a simple example that I have in this isn't supposed to be readable it's only supposed to show you it's 20 224 lines of natural language of just very high-level kind of sparse stuff that says this policy has the following rules and in the

rules we wanna do this and if this is and that whatever. So you specify four or five rules or 10 rules. In this particular example, 224 lines. Now, after you run the entire round trip and say feed in your IT landscape, generate whitelists based on the IPs, and maybe you have tags for the systems that say it processes PII, like personal information, and your policy says I will only whitelist PII or blacklist PII and not the others or whatever you want to say, you can generate a lot of rules. So it turns out What we do in this trivial example, I can run this, but I probably don't have time now. So if anyone wants to see the thing running in Eclipse later, I can show you. The output's

actually 4,446 lines of the same algorithm to generate the human language. That's what you would now push out. And that's only one output, a non-redundant output. If I now say, OK, now I want to configure, say, operating system firewalls on Linux and Windows, I take some subsets of those. rules and push them to the particular nodes and generate configurations for those. Somebody usually has to do that if they want to do OS layer firewall stuff. And then somebody has to say, oh, now we bought an enterprise firewall. Somebody's going to take the same logic of what's here, take whatever applies to the firewall, and configure it there again. In the end, you just have this mess everywhere, and you've got probably much more

than 4,446 lines of things that you need to understand and audit. So that's kind of the idea here. The business realities now, where does this actually fit in? So often it doesn't matter if you have a good idea or not, unfortunately, in enterprise software, it's the question, where does it slot into the established buckets? So what we found is it's really identity and access management is the enterprise function where this fits in. Unfortunately, it's by those guys themselves. It's not often seen that way yet. And that's partly because the big vendors in that space, they will move when the customer moves. And I don't blame them. I would do the same thing if I was established in the market, like an IBM or something. I would move, and the

customer moves. But the fact is, there's no real other good place. The Xacomol crowd that I mentioned earlier, the Oasis guys, they tried to be part of the application security crowd back 10 years ago and said, this is really application security. And then the guys at the Moscone changed the narrative, and application security is something else now. And they're like, whatever. The only place where this fits in an enterprise is in IAM as the A of IAM, which is anyway underdeveloped. And the identity part, when it came out of PKI back in the days, public key infrastructure and all this stuff, it took the same kind of roadmap that I see access control going through right now, a maturity roadmap that's going to take many years where an

in-house effort, multi-year effort is required to clean the house, essentially. So it's just part two of identity and access management roadmaps, really. And I took Wikipedia again because I like their super high level kind of how they explain stuff. I mean, it's really a discipline. I think that's what you really figure out. There's no way you're going to ship a product. For what I described, you don't ship a product to the customer. You can ship a tool. We ship tools. Other people ship tools. And it's the totality of the tools that need to be deployed at the customer. There's no way. This will ever, I think, not in the next 10 years be something you just have some SaaS that will take care of

it automatically, unless the standards landscape is going to evolve massively. Identity and access management itself is kind of a pretty crazy acronym soup, unfortunately. So authentication, authorization is part of it, audit, forensic, workflow, automation. These things are all part of a big program where somebody goes in and tries to kind of a little house clean, figure out what our workflows say tickets, somebody would issue a ticket from PeopleSoft, or some kind of HR issues a ticket, says somebody just joined the organization, they need the following accounts. And then some sad guy has to go and do stuff, and then somebody gets provisioned, and hopefully somebody documents it, you know, and that's typically what happens today. So when you automate that in an IAM

initiative, you have tools that would work through these different steps automatically, or at least will check that every step has been done. Because it's not the provisioning that's the problem. Somebody's going to complain if they don't get access. It's the deprovisioning that's the problem, or changing. I have customers that at least they're supposedly supposed to inform someone if somebody's deprovisioned. So somebody's sacked or something, then somehow it's supposed to bubble through that these accounts are going to get closed, and somebody's supposed to write an email back. when your role changes sufficiently that it affects your access rights and your job position, they don't have a process for that. And that's our medical provider. So I think they're pretty good overall. So

it's just where we are today, I guess. I think the acronym soup, I leave that out, by the way, because that's going to kill everyone if you have more acronyms. But there's a lot that they have and a lot of standards. And it's like you pick your standards like it is with all this web stuff. You pick your standards and then your standards compliance. But the idea is simpler administration and auditing and compliance, basically. That's really what you're trying to do. So it fits right in there doing access control better. It's just, unfortunately, the most difficult part, I believe. Maybe I'm already tainted by the hammer and nail problem myself, but when I see the

problems that identity people have today, they're nearly the level of complexity that they're still facing on the access control end. I think the auditing end is still going to... bite everyone in the end big time. But access control right now is hard. The tools all have support for it if you buy an identity management solution. But when you actually try to do something that is more than, and I'm definitely not picking on any of those vendors. I think these are pretty established solutions. But say if you buy, I don't know, from a database vendor, you buy a major identity solution, most likely it's going to work really good with their portfolio of database. If you have some home cook cooked random stuff on some random platform, or you're like

a DoD and you run IE6 and Windows XP and some home cooked I don't know what, things aren't going to enforce out of the box. So this is majorly still difficult, I think. I think if you want to take a buzzword home, master data management for Policy is probably one that plays a role here, similar to the way we have master data management for identities today. And we have it for roles, mostly. I mean, when you look at where it goes, there's still, you do have subsets where it's not the case. But I see things as they get retired or as things get integrated to be moved more into central repositories because it saves you time. Right. I mean, there's some guy, when you think about it, there's

some guy that does something somewhere. Every single time somebody changes something, some access changes. Some identity, somebody goes, somebody, whatever, changes a role, moves department. There's actually somebody dealing with a trouble ticket. That's not... Really, I mean, we forget that, but that's where we are at. So yeah, this is an interesting, and this is in fact the last topic that I'm going to cover. So now we have this soup of complexity that I've covered. What do you pick for what use case, kind of, right? And I show you a few examples what we found. I'm not claiming that I know this stuff. This is just what we found for the specific example projects that are good combinations of mechanisms to enforce

access. There might be other good ones, or maybe somebody, if anyone has any suggestions, would be great. But what we found in industrial Internet of Things, so we have a project in Europe around intelligent transport systems. We found that attribute-based access control with proximity-based attributes are clearly a winner, because you would have policies such as, oh, well, if you're an NGO, like a non-governmental organization, being a first responder, you should only see live CCTV off the site in the smart cities environment, for example, that you are assigned to actually do something. But that will not be like the NSA being able to see every camera or something. For that, you need geolocation. Or somebody can see only within one mile of where they are so

that they could reroute traffic or something, things like that. We found a highly distributed enforcement architecture good in this case. That's, in fact, our bread and butter. Didn't work for all scenarios that I'm going to show. But in this one, you really want an enforcement point on each node. It really helps. And the model-driven security part, this is this whole round-trip engineering part where you keep the policies, I guess, generic. It really worked well there because This is kind of complex on the policy end, but the policy end isn't the most complex part. The real problem here is the scale. It's the scale and this dynamic change in a large transport system. So this works pretty well as a combination of mechanisms, I guess. Here's the sort of scenario.

It's really unreadable. What that basically shows is just there's a, it's not what it, and forget the slides, or it's not very visible. What traditionally happened in ITS intelligent transports is there was a network provider almost. This was all coming out of one hand, and they would just own the whole turf. Turns out that's not really viable anymore. A lot of vendors, a lot of stakeholders interacting, making it a multi-stakeholder environment when it comes to policy. And this is a question of who's responsible for which context and whatever happens. So if somebody makes a decision and blocks somebody out based on content they received from somewhere which they didn't have any control over, but where the rubber hits the road, somebody's going to get sued based on something upstream

that happened, you have problems. So this is, I think, where this industry is going. Smart Cities is going to go that way. Smart Grid, not so much, I think. But ITS, for sure, just because the vendor landscape is a lot more dynamic. So forget that. That's a couple of screenshots. We don't really need to cover that, what we did there. Actually, what's interesting is, so yeah, we do actually, you know what? Maybe I'll cover it quickly. So the authoring part, I kind of mentioned, we let people there author policies. in these generic terms and generate the rules. We talked about that, generate export configurations in there. There's a standard they have, Etsy, machine to machine. Etsy is like a telecommunications standards body or whatever. So we configure

security for them with the tool. We generate the English language output and compliance documentation, basically. So that works pretty well. So then we have a medical facility where we do stuff. And it turns out it's less of a big technology problem. It's more of a trying to figure out what's going on problem. There's a very small IT department. very chaotic, very expensive landscape of stuff. MRI scanners, you don't throw those out ever kind of thing. So we found start small and then evolve with access control. A lot of the SCADA stuff was critical, turned out, because that hangs on the same networks. And it's anything from HVAC to bedside monitors, infusion pumps, and any of that. So we found

there the only way to bring it in is part of IAM to actually look at stuff. The big... It's rubber.

It's not me. I showers, okay? Maybe the other guy didn't shower. Sorry, let me just tell you, it seems like they're doing a roof down the block.

Like $7 a way. So when the earthquake fire comes down this way, we'll let you know in two blocks. And I should give you time, OK? JOSEPH BALESIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERIERI

And when you're trying to do reduction and filtering and stuff like this based on complex data, you have to figure something out about the semantics of that. So access control becomes very granular, and the complexity goes up with the data granularity and unstructuredness. So what we found there is critical things are history-based access control, especially about it's sort of what the academics wrote about database security back in the day. It's like, well, if I can aggregate enough what they call products in the intelligence community, like enough results, sets of results, and I might get something that I was never supposed to get because I'm screwing that history-based access control. So that's a real challenge where you have to keep track without getting

super slow. So it's a real problem. How do you keep state? A lot of research has been done, but it's still a challenge. So we found the attribute-based access control again useful with semantic data labeling. So that essentially, that part, unfortunately, the partner that does that hasn't finished it yet, but we have two more years in the project, so they will. And then we base access control more on those data labels that they tag. So we're not the tagging guys. But tagging data, I think, is critical for very fine-grained access control to data. So that's easy if it's very structured. In this case, we found centralized access control better, because this actually all goes through a database, like a cluster of databases, like a

hub-in-spoke thing almost, right? Because it's very hard to do complex analytics on a totally distributed nature, because everything depends on everything else. There's a graph database that essentially, or something that essentially manages a graph where edges get added based on what the analytics finds out, right? So obviously, you might not know that two people are related in some way of something that is relevant, right? But after you run a bunch of stuff, it may actually learn that that's the case. And it just grows and grows. And there's no, we, I'm not dealing with this part, but it's very hard, I think, to do that distributed. But for security, that means it's a good choke point, is that hub, you know? Yeah, and we found the

model-driven security useful again. Now, in this case, it's not so much about the agility. It's more about just the fact that these data labels may change. So you've got agility on some other inputs in this process, right? You can't just say, OK, here's the five attributes that you're going to use to talk about your data. And nothing ever, right? So nothing will ever change. So that's it. So I think conclusion is that access control is complex and has to be really understood, right? I think stepping back and rethinking is important. And it should be seen as an initiative. So if somebody sells you just a product in access control, I mean, there are tool vendors.

We are tool vendors and many others, too. But you're not going to buy a product for access control and be done, right? And today's advanced approaches, they aren't just BS. I mean, there's a lot that you need in order to capture the richness of what the simple sounding English language sentence in some policy says, because it has a lot of, potentially, a lot of meaning in it, even like least privilege. It means a lot. It means a lot of complexity when you want to do it right. So that's actually really one of the important parts here. They help you enforce, essentially, the policies that you need. And at the same time, some of those tools make it more manageable. Because you can talk about

something that you more understand that is less rules than if you were to do everything with, like, 1,000 simple rules somewhere. Sometimes richer rules are much easier to manage than many simple rules. And that concludes that. I don't know if you have time for questions. Probably not. I'm around for another couple of hours. Hope that was interesting. Any questions, you can email me too. That's it. Thank you.