 Do you have to do, oh, okay. Hello everyone, hi. So it's the best time of the day to relax and see something interesting. So before I get started, I wanted to request one thing, is my United Flight change times and I pretty much have to shrink this presentation just by 10 minutes. So I do encourage questions as we are going through the various points in the topic and if we have more time at the end of the presentation, the whole point is let's find collaborators, let's get some good feedback and I'd be happy to answer questions now or follow up with you later. So what are we talking about today? So the previous presentation if you were there was very good from the perspective of defining virtual versus physical infrastructure and today we're basically looking into the platform as a part of an identity management system. So that's the key point is when we want to have better transparency and visibility into a platform to be able to make access control decisions, there needs to be an easy to use mechanism to do it. So the question is how do you figure out what are the platform attributes given the virtual infrastructure today and how do you link it with user attributes to make user access control decisions? So here are some of my proposals. Actually, I bet the pointer works, right? Okay, so what we have here is my proposal is let's work, find the collaboration points to design a comprehensive federated identity management system which includes platform attributes and also look at interacting with the keystone authentication mechanisms. I was just talking here where there's a multi-factor initiative that we've started looking into and if there is a way to hook in the platform attributes then that would be very interesting. So to the basics, what do we have typically? Typically people talk about user attributes. Username password, 99% of the case. Then the more interesting ones become like biometrics which are very hardware dependent so there's a huge problem of interoperability but then there are PKI certs which have been talked about, people's demographic information, their preferences, even things like usage history. There are things like reputation of where have you been? It's becoming very good part of your social media. But then there's a huge other set of attributes which are associated with you and that's related to the devices, one or more set of devices that you use. So it could be the location of your device, it could be the sensors on your device or what are the different types of sensors that you have associated in your device. And the first thing that probably came to your mind when you read about this was the TPM, the various registers in the TPM. How do you leverage the information stored there to make some evaluation of trust on that system? There are other things related to certificates which are related to the device itself so you can have keys burnt on the system or certificates issued to a certain hardware which may imply something about that system and the service that you're going to offer. And then of course the whole software stack and everything below it, the firmware, the bios, what are the capabilities of the platform that you may want to leverage. You may also have systems, the previous speaker which talked about isolation which was really good to understand what are the capabilities of the platform that can guarantee some level of isolation of your workload so that there is non-interference, there is no security, nobody's attacking. So there are some really big implications about these various types of device attributes. Any questions? Who else is catching a flight with me? So the whole point is we've always considered a user attributes and device attributes separately but let's really, this is something that's not novel. Many people have been talking about it but we need to find a really good mechanism to get to this point right here. The user and device attributes interplaying with each other and have a nice anchor to the device itself so that there is a way to enforce that this particular device attribute and user attributes are linked together and depending on the type of service you can figure out what is a set of information that you really need. So a trustworthy mechanism to be able to retrieve this information and a usable method that is by using our identity management system to be able to use it in our access control systems. That will have huge implications on the security, the privacy and the usability of the system and here is a list of, one could go into each one of them and we could spend a lot of time but I think the audience here is very advanced so you can probably translate a lot of those points into things that you're working on. So there's a huge amount of work which has been done in attribute-based access control. I think there are folks here who have led initiatives. I think the whole point is that in an attribute-based access control which has mostly covered the top area, let's see how it integrates with the device attributes to better enhance the security, preserve, privacy without compromising the usability of the system. Any questions? Okay. So one thing which I want to point out over here is that oftentimes we say that I only care about this application and the user attributes but it is very important to know at the end of the day the behavior of the system hosting this application and this user because there's a route of trust which is established during the system boot up or when this application is running on the system where you have to really depend on something that can provide you a certain level of guarantee on how the device is behaving. So I have an example here which will help understand the progression. So you can divide services into these four types based services which are free, which really don't care about user ID or the device and that's most of the time when you're surfing the web but then there might be application which require a high assurance on user identification. So you do multi-factor authentication using user, strong user name, password and they're yet another type of service where the user doesn't matter but you really do care about what device it is. Blu-ray is a very easy example but just see the difference where there is relevance of user information or there's relevance of device information but as we go to high assurance services where something like a healthcare application where you do care about the user information for sure because you need to get to the right record if it's your pharmaceutical service which is being offered online you need to make sure that it is this right users electronic medical record but also you need to make sure that the device is secure because at the end of the day you want to make sure that the device is not being attacked by malware so there's a certain amount of isolated environment provided by this healthcare application and also that the residual data that is generated because of this whole e-pharma in this particular case interaction is also protected. So we want to make sure that if such an application denoted here in green is interacting with the cloud service if it's in a hostile environment there is some sort of guarantee that the platform beneath is providing the support needed to secure this application. Any questions? So what do we have here? I have just two more slides so this is going to be, I'm hoping to get more feedback because I think the point is very clear is that we started off with basic authentication mechanisms within OpenStack they are a lot of good plans about integrating. I'm sorry. So I attended your talk about the various Keystone initiatives and there's some great work happening there and the point is that as we progress there are certain design requirements when we start including different types of attributes very much looking into the attribute-based access control to make it less hard to incorporate a bunch of attributes as you progress. So every time you add a new sensor or you add a new type of attribute then we shouldn't have to go back and redo a bunch of those your components. But there's a crawl walk run so there are two key pieces. One is this is a very typical at least identity provider service provider but it's a typical identity management system considered paying Shibulit, a bunch of others and I think there are initiatives which are looking into integrating with them. The piece that I was very interested in is how can you locally add certain platform attributes as you're building the local authentication system and then how it would integrate with the identity management system that exists today. One key component is there's a device verification services which is important to have a logical distinction because oftentimes people don't know what to do with that data. Device attributes are not very easily understood. So what if I have a Zen versus KVM versus something else? Is there some mapping of more secure, less secure? And these are things that I think the policies and translation of the information that you get from the device to actual information would be another key initiative. Which one? The part where you write. So there's some initial work like the whole TCG type initiative where you're looking at what is your trusted computing base but I think there is a lot more to it where I was starting to understand when we look at loopholes in a certain hypervisor versus a certain platform that is vulnerability management piece that is need to be developed. There's another piece which talks about capabilities. Certain platforms have certain capabilities where you can have higher assurance that my random number generator has a certain strength or my degree of isolation is enforced by the hardware or not. So from crypto, non-crypto, there are a lot of various things that have been discussed earlier which can impact the decision on how trustworthy a certain application is. So there are things in the industry but there's a huge amount of work that needs to be done. Okay, we can come, okay. Yes, that's an excellent point. So the question was, do you presume that the attributes are static or I mean, what about the dynamic ones which change over time? So there's some really good work within the attribute-based access control community where they talk about static and the attributes which change over time. So things like data birth or user attributes which don't, unless there's a correction, they don't change. But then most of the time, the attributes, there's a whole management system which needs to be updated, revoked, corrected, the quality of the data being collected and the whole privacy aspect to it. That is number one. There's the revocation. There's a lot of work that has been done at least in research which talks about how do you revoke an attribute which is collected. So definitely these attributes which are being considered a dynamic. There's the system state in the beginning which may change once the system has already booted. The consumption, the policies, making sure, what it means, why is something more trustworthy than the other is definitely a separate major piece of work that is ongoing but it really requires a lot of good collaboration and defining to do, agree. 100%. And the dynamic part is definitely there too. How much trust? Right, so we need to separate out the providing of those attributes versus the evaluation of those attributes and what it means to my system. You can take a bunch of the metadata that you may be adding with the various attributes. You can use them as a data point to build your own formula for confidence or which tier does your set of attributes fall into. So there is some work in policies which have been done to be able to collect a certain level of attributes, a language which says that okay, if you have these attributes issued by the whole provenance of where this attribute came from and then translated it into a certain category. So there has to be some simplifying mechanism for it to scale, so that is one of the things that we can talk about in just one minute but there's a whole policy and scale aspect which is a huge amount of focus that needs to be done to be able to really use this information. So as you said, we can provide the information but to be able to leverage it to the maximum you need to have this verification mechanisms and also translation to trust levels. What is trusted and not? And such a platform-based attributes can also give you different types of applications. I have been very involved in the standard space where there's requirements coming from understanding where is the server located, what are the various hardware features that a certain client may have. So there may be some requirements from the standard side. Also, there might be some compensating controls. There might be certain requirements for anti-malware for instance but if you have a compensating control where you say, hey, but this is isolated and I can say something about this environment, then there might be some new policies that may help you achieve the goal without having to have only one way of implementing things. So there's a standard compliance space, excellent piece that you can do from the audit end. It's really very interesting of how you can use this metadata and plug it into, for example, the CSA audit and understand how you can evaluate the compliance of a certain infrastructure based on this information. The other pieces which are like sensor-based, I have one of the reasons that people may think about biometric authentication, not being so useful remotely is because you really don't know where this, how trustworthy is the sensor that is capturing this information. So biometric authentication, there's some trust that can be established on the device. Then you have, there's this end-to-end trust where you not only trust the user because the user has certain capabilities on the platform but I can be sure that there are folks from everywhere over here. You can talk about which geo do you want your workload to be or the kind of policies that may be associated with a certain physical location. So there might be some physical aspects of your policies that can be enforced by this mutual trust mechanism. And finally, with this metadata or these platform attributes associated with the user attributes, there are some very nice things that can happen from the fraud detection purposes. Somebody's logging on to my account from none of my devices from India or somewhere else at the same time as me. It just gives you a little bit less poofable mechanism of providing some security services. I see a smile there. So call to action. Essentially, what we discussed, what I want to get away from this presentation is understanding your interest. I think we have had some great questions about what would be the next first steps, understanding static versus dynamic attributes, looking at how can these attributes be used as part of the multi-factor authentication effort that is going on. The next step would be to do the back end, the verification services, integrating it into the identity management systems that exist today. And finally, which is really the hectic part of it is the policies and how it would scale. I think that's the toughest. While there are some really nice researchy solutions out there, really understanding what works, what scales, what is a usable method that we can develop, which can be used by this, OpenStack is in such a good position to make an impact from that manner where you're kind of building things right from scratch, like and there's an opportunity here to learn from what we've learned in the identity management space, from the trusted computing space and really building something good with all the various applications that we just talked about. So any takers for blueprint collaboration, any kind of interest from the policy, GRC type work would really welcome that. So open to any further questions? See how we are on time. Okay, here's your question. Yeah. I know I wanted to go to David's talk too a lot. So I think one of the things that we want to do is at least connect. If you can email me please. I have the longest email that I think anybody has in the conference. So I think we can make a collab, we can at least connect and define the interest and we go from there, from design phase and then we have folks who are interested in the implementation too. It's a lot of work we're doing on the identity management space. Yeah. I think that's the best part, right? You can get a lot of information. I really didn't stress on the trustworthy aspect as much is because some of the mechanisms and I really didn't get into the details here, but the way you get the platform information is in a manner which is cryptographically enforced. So the information cannot be forged very easily. So if you are storing this information that you're getting from the platform about the entire stack, about various credentials that led to the fraud detection, then you can probably dig into that database with high assurance and know that the information is correct based on the keys and yeah. Yeah, there's a huge amount of, there's a nice initiative from McAfee for instance, you know with the Global Trust GTI. What is it? I for it. Initiative or infrastructure, one of those two. So essentially there is work where this huge amount of logs which are generated, how do you like principal component analysis, right? Where you take the most significant information and they're able to, the point is you can do roll up and roll down. So essentially you can take bits and pieces of information. If you suspect something is going wrong unless you have already deleted the log, there is a way to go down the right thread, right? Where you can track down and say, okay I really need to get to this log. Otherwise there are mechanisms which have been developed over so, which have been taking the summary data so to say at various levels to come to a point where the root of the tree says okay, I have high confidence that something is wrong here. So we can look into some mechanisms which are out there. Oh yeah. Right, right. The de-identification of the data, how to make sure that for example, if you're doing trials, a huge amount of trials on user health, there's something I looked at. So a person who was born to, when they grow is just, oh you know, when you were born they injected you with something and then 20 years later there is certain disease which is found. So can you track down? How far do you go without compromising privacy? So there is certain amount of work. All the answers are not here but I think that's one very interesting area of how do you aggregate logs? How do you make sense of it? The whole big data issue. And there's another piece of it which says can we incorporate device data into this mix? Can we somehow have an easy mechanism of retrieving device data to have greater assurance of user information or if device was sufficient? As we talked about the various use cases, we can use them just the way we use user attributes. That's excellent point. I think it may or may not depending on what the thing is. So for example, if you think about some premium content, actually can you? So yeah, if you can please repeat or I can help. To the point about device and the device attribute being important, it does when you want to say I want to look at my photographs from my iPhone or my laptop but it kind of disappears when you're doing like really server loads of work of data crunching and things like that. So when you do, I think that would be a good thing to check like as part of data mining things where it doesn't matter exactly. I'll give an example. It doesn't matter what exact device you had sometimes but the fact it was the same device, you know, or for example, all Zen hypervisors, you know, leading to certain behavior or something like that. So you may not want to uniquely identify something but you may want to group certain device attributes to learn something about the system as well. So case by case. I think that would be something really good to understand which use cases exist. And I think that's a great idea is to take understand which use cases, where is device attributes relevant, where it is not based on the usage model. Okay, so if you have any further questions, please let me know. I'm sorry for the rush rush. It's United Airlines fault, none of them. Yeah. Yeah. Yeah. Yeah.