 Live from Las Vegas, it's theCUBE! Covering AWS re-invent 2019. Brought to you by Amazon Web Services and Intel, along with its ecosystem partners. So good to have you with us here on theCUBE to continue our coverage here. We're live at AWS re-invent 2019. We've been here since Tuesday, wrapping up a little bit later on this afternoon. It's a pleasure to welcome Jeff Frick in for the first time. Why haven't seen you in a while? Thanks for coming out. John Wall's here and with Neha Rukta, who is the principal applied scientist for the Automated Reasoning Group at AWS. Neha, good to see you as well. Thanks for joining us here. Thank you for having me. All right, so let's kind of put this in perspective for people at home. You got the AI world and the ML world all happening and automated reasoning applying in all those contexts. So kind of give us an idea about what that mesh looks like. What is it all about? Then we'll jump into what you're up to at AWS. Right. Automated reasoning is a subfield of AI. So the way you can think about is AI is a discipline of computer science that allows you to have rules to teach a computer system or an algorithm rules about how to think intelligently. So a lot of the tasks that traditionally humans did, we transferred to a computer doing it. And ML and automated reasonings are subfields of AI. I would call them sister fields, but on the opposite ends of the spectrum. So in machine learning, you would have the computer system learn the rules by observing data, lots of data. And it's very good for certain things like voice recognition. There is no definitive set of rules that says how can I recognize a voice? While automated reasoning on the other hand doesn't look at data, but for the things that we know that exist, there exists a definitive set of rules, we encode them. And the system and the algorithms can reason about it. And access control is a great example of that. There is no unknowns. We know what the shape of access control looks like, what its definitions are. And we encode those rules in a computer system and algorithm. That allows us to ask many questions and be able to have different applications and security, compliance, availability. Sorry, we're talking about asking questions in the context of security and access. Who's asking who, what questions? Is it the system asking the person trying to get in? Is it the person trying to get in making sure they're getting into the right system? Who's actually asking those types of questions or what are those questions? So some questions are very general. For example, in most cases you do not want, you want to make sure that your S3 bucket is not public. Only if you're hosting web assets or web pages are potentially the only cases where you would want a bucket with wall read access. So this is a question that's a global security best practice. So we would say we would ask the question in AWS. Is this the case that the bucket is public? But as an organization, you may have specific questions about who in my organization can access something. And that can vary based on organization, based on the security best practices that you have, based on the governance rules. So some questions I would say are best practices while others can be specific to organizations and enterprises and companies. But that's really important because when we do hear about breaches and we hear about breaches all the time, it seems like usually if Amazon is involved, it was some misconfiguration, some switch got left in the wrong position. So this is the type of application that you guys can now search for in advance to make sure that whether it's industry best practices or are you sure you want to leave this knob open, you guys can get ahead of the curve on that. Absolutely. And at AWS we want the customers to have options and have flexibility to do those things. But at the same time, we want to provide them different means where they can check, double check, triple check, that their configurations are as they intended. And we've partnered with S3, so you see the public not public badge in the S3 console. Last year we also partnered with them on the block public access where it allows account administrators to turn on that nobody can ever access their bucket. And so we've been providing a lot of features to our customers to allow for them to detect and prevent misconfiguration of their resources. Yeah, how much more complicated is it now or complex because you have so much more resource. You've got a lot of data. Companies want it to be accessible to a lot of different people or people within the company want access to it. But just in terms of fundamentals, what does that do to your game? I mean, in terms of what you're trying to provide, the controls you're trying to provide when there's a lot more of it and a lot more people want to get at it basically. And this is where I, is one of the powerful things of automated reasoning where, as I said, it's a sister field, but in a way the opposite end of machine learning, it doesn't need data or logs or who has accessed things in the past. But it just looks at your configurations, your policies, and because of the rules we've encoded, it can very quickly tell you who outside your account has access. And we launched a feature this Monday called I am access analyzer that with one click you can enable it in your account. It will scan all the resource policies in your account and tell you, hey, Bob here from marketing can read this bucket. Is that intentional? And that's not something we can say because that's a business use case. They put that on the customer, right? They'll let them make that determination for themselves. They provide that visibility. And the goal is for the customer to say, yeah, that's intended, he needs access. So I'm going to archive this. I'm going to say this is intended. While if it's not, they can go to the respective service console and fix the access. And essentially it empowers the customers to make decisions about what access is intentional versus not. And does it just like fire off notifications if there's something that seems kind of out of band within your system that says this doesn't seem right or how's that actually executed? Because I don't think most people understand how complex access control can be between different roles, different projects, different resources. It gets to be a pretty nasty hairy mess. So I mean we have many ways that customers can get notified. We've provided integrations in the S3 console. They don't need to go somewhere else. If people are in the S3 console, they can have this information right there. There's a little tab in the S3 console that says access analyzer for S3. Security Hub is where a lot of the security compliance people look for a holistic view of their security and compliance posture. Look at findings from other security services as well as partner solutions. And we also provide integrations with cloud watch events so people can just subscribe. Hey, this bucket suddenly allowed John access. I don't know, John. Careful of that, yeah. So, shut that thing down. But what about just in terms of ease of use? I mean that's always, I think it's, as more capabilities come to the market and you give me more choice as a customer, sometimes I'm going to say, oh, you know, wait a minute. This seems like it's going to be over my head or a lot more complex or a lot more intricate than I thought. Can you keep it simple? I mean I don't mean access for dummies, but can you keep it relatively, that ease of use in a pretty comfortable level for me? Absolutely, and that's our goal. So, traditionally, when you talk about automated reasoning, there's been this, oh, it's high touch or you need to be an expert user to do it. And what's with this offering here, all that, like it's all one click and you don't have to be a security expert or even know how access control works or be like a mathematician or a logician, it's just simple declarative statements. It'll say John, from account one to three, can read your resource. And that's it, it's that simple. So, it's essentially for customers of all verticals. You don't need to be a large customer with a huge team to be able to use it. Anybody, anybody can just turn it on and use it. And that's been one of the things that we've pushed really hard on is to have that ease of use. So, I'm curious philosophically, is this a different type of AI that can be applied when you have use cases that just don't have the big data set? Because that's what we hear all the time about traditional AI, is to identify the Chihuahua dog from the blueberry muffin, you need a lot of pictures. But this is something where you don't need a lot of data, so you see lots of different applications beyond this initial launch to apply this type of reasoning. Absolutely, so, and there's a lot of systems, a lot of configurations, a lot of even code, architectures. There's many, many systems that, where we can apply these technologies for us to have. And that, I think you hit a very key point. We don't need the data. We are in a way data agnostics because the rules that we derive are the rules that we've made up. I mean, we know the rules because that's how AWS is constructed. So we leverage that to create these automated reasoning technologies. And we're starting with access control, but there's a lot of other places that we want to start using this and applying it. So how is this making our operations more secure then? I mean, ultimately, because if you're giving me a chance to better identify who's coming in, who's coming out, obviously there's some protection there. But, I mean, look at that for us, or at least try to paint that picture for us a little bit. And why does this give us better protections, better securities in terms of protecting from invasion? So in the cloud, like security is our number one priority, is we call it job zero at AWS. And as you talked about, where it's flexible, it's growing, your business is growing, you want to know what's happening. And you want to be empowered to make the right choices and right decisions. And this provides you that visibility. You don't have to dig through the different configurations to see what's happening. Like for your compliance auditor comes on board saying, are you sure that this meets these privileged practices? And now you don't have to go digging, you can just say, oh, here's a report generated from this tool that has analyzed all the possible accesses. So it allows you to scale better. As a business, you can focus more on your business value core propositions rather than having to say, oh, how do I check the different configurations to meet my security requirements? And it's not passing judgment. It's not saying this is good or bad because what may be good or bad for a business can be different. Just depends on their perspective. Exactly, and so I think that's the key part here. There, I mean, there are some cases which we would call security best practices, but there's a whole tail of use cases that are very, very specific to your business. And I think by empowering you to make that choice and decision of what is intentional, what is not, and do it in a way that's easy one click, you don't have to think hard about it. I think changes the game for security. Well, I would say my only piece of advice is don't give John access to anything. And with that, with access analyzer, you can check that John runs. Jeff, you now have control. Shut him down. Thanks for joining us, we appreciate the time and walking us through. Good luck with the product launch too. Sure, things are rolling well for you. Neha, thanks for being with us. Yeah, thank you. Back with more, we continue our coverage here. We are live in Las Vegas at AWS re-invent 2019.