 Welcome to today's session of theCUBE's presentation of the AWS startup showcase, the next big thing in AI, security and life sciences. And in this segment, we feature Sunrise security. Of course, for the security track, I'm your host, Dave Vellante. And today we're joined by Sandy Byrd, who's the co-founder and chief technology officer of Sunrise and Avi Boru, who's the director of cloud engineering at World Fuel Services. And in this discussion, we're going to talk about 22 to two data centers, how World Fuel Services and Sunrise security actually made it happen securely. Folks, welcome to theCUBE, come on in. Thank you. So we hear consistent themes from chief information security officers that many, if not most enterprises, they struggle today with cloud security. There's confusion with various tools and the pressing lack of available talent to attack this problem. So Sandy, I want to start with you. We always love to ask co-founders, why did you start your company? Take us back to that decision. Yeah, I think looking at Sunrise security was interesting in that it was a time to start over. It was a time to build native in the cloud as opposed to having a data center and be able to use a vendor and infrastructures, be able to use the latest and greatest technology and really change the way people secured their workload. What was interesting when we started the company, I believe that the world was in a more mature space probably in cloud than they were at the time when we were starting it and that we were really focused around if we could understand all of the rights and entitlements to data, we could understand data movement, we'd had a hope in protecting the data. In arriving in cloud, we realized that the maturity of the company's building in cloud were not quite there yet. They were really struggling with the identity models in the cloud, how to actually secure workloads, serverless functions that are ephemeral, these types of things, and even just sometimes basic governance problems. And the technology we had built was great at understanding all of the ways that data could be accessed. We were able to expand that into all the resources of the cloud. And it's an exciting space to be in. And it's also, I truly believe, we'll be able to actually make cloud environments more secure than what we were doing in enterprise. Because again, for the first time ever, you have full inventory, you have the ability to make controls that apply to the entire infrastructure. It's really an exciting time. I mean, I've said many times, I feel like cloud, like security is a do-over. And the fact that you're coming at it as a data problem and bringing in the cloud, that intersection I think is actually quite exciting. So Avi, let's bring you into the conversation. You know, obviously we've seen cloud exploding, it's continuing to be a staple of digital business transformations and acceleration, especially around identity. And so what's your point of view on cloud security? What's different? And how does your company approach it? Sure, thank you for having me, Dave. And just to give you a bit of world-field services. World-field services, it's a public company and it's based out of Miami. And we are ranked 91 in the Fortune 500 list. So we have spread all across the globe. And as part of our transformation to destress our business, we took over a big challenge to migrate all our global infrastructure from 22 data centers to AWS. That was a massive challenge for us. And we are down right now to 20 data centers. We only have two more to go. And we did this in the last two years. And that was really good for us. But as we've been doing this migration, there was also strong need for us to build a strong security foundation. Because going into the cloud, as much as capabilities it gives us to innovate, it also gives us a lot of challenges to deal with from security standpoint. And as part of building a security foundation, we had to tackle some key challenges. One was, how do we build our cloud security operating model? And how do we upskill off people, the talent that you've been pointing it out? And how do we make security a way of working in this new world? And more than choosing a solution, we needed a really strong security partner who can help us guide in this journey, help us build the foundations and take us further and make sure it was in this. And that's where it was really interesting for us to partner with Sunray, who helped us along the way. They love foundation and now helping us make sure our security platform. What were the technology underpinnings that enticed you to work with Sunray? Sunray has a lot of unique capabilities, but I'll take out on two key points, right? One, Sunray has its cloud security posture management, which is different from other platforms that are out there, because they give you capability for a lot of out-of-the-box frameworks and controls, but in addition to that, every organization has a need to build your own specific framework, specific controls. They give you that capability, which is massive for enterprises. And the second key thing is, if you look at AWS, it has more than 200 services and every service has its unique capability, but one key component they use across all the services is identity and access management, IAM. And Sunray has a unique perspective of using IAM to track risks and identify the interactions between user and machine identities, which was really exciting and new for us. And we felt that's a really good foundation and stepping point to use Sunray. Sandy, we definitely saw the need for better identity explode in conjunction with the cloud migrations during the pandemic. It was sort of building and building and then it was accelerated. Maybe talk a little bit about how you approach this, specifically talk about your identity analytics and the graph solution that you guys talk about. Yeah, I've been a fan of graph solutions for many years. One of the great benefits in this particular space with identity is that the cloud models for identity are fairly complex and quite different between AWS, Azure, and GCP. However, the way that entitlements work, some identity is granted an entitlement and that entitlement gives them access to do something. Sometimes that something is to assume another identity and then do something on that identity's behalf. And when you're actually trying to secure these clouds, this jumping of identities, which happens a lot in the AWS model or inheritance, which happens a lot in the Azure model where you're given access at one level of the tree and you automatically gain access to things below that if you have that entitlement. Those models inside of graph allow us to understand exactly how any given identity, when we talk about identity, we always think of people, but it's not, of course, as you said, sometimes it's a machine, sometimes it's a cloud service. It could be many different things. How does every single one of those identities get access to that given resource? And it's not always as clear as, okay, well, here are the direct identities that can access this resource. It may only be able to be accessed with a single key, but who has access to the key and what has access to the key and what's the policy on that key? And if that's set too widely, can other maybe nefarious actors get access to that key? And by using the graph, we can tie that whole model together to understand the entire list of what gets access. I think that's actually what surprises a lot of the identity governance and data governance teams that are not in cloud. When enterprise, it was very intentional. You configured the database to use the identity provider and the rules that you wanted it to use and that's all that ever got access to that database. In cloud, there are a lot of configuration knobs and things and depending on how you turn them, you could open up a lot of identities to get access to whatever that resource is, often it's data, but it could be a network, it could be many things. So the graph allows us to tie all that together. The second part of it is it really allows us to see, we call them effective permissions, what the effective permission of that identity is. The clouds have done this phenomenal thing in using identities as a control mechanism, just like an firewall, like an identity firewall, where they can take permissions away from things based on sets of conditions. So one of the great ways, let's say you didn't want to have any data store deployed without encryption, you could write a policy at the top of your cloud that says anytime a data store's deployed, if encryption's not there, deny that function. And so what happens is you can create this very protective environment using identity controls. But the problem is when you actually go to evaluate your cloud for risk, you may find a scenario where an identity has access as an example to do something like create an internet gateway or create a public endpoint, but there's this policy somewhere else that's taking that away. And you don't want thousands of alerts because of that. You want to actually understand the model and say, look, if we understand that this policy is mitigating your risk, then don't show the alert in the first place. And it really helps by putting it in a graph because we can actually see all of these interconnections, we can see how they're interrelated and determine the exact effective permissions of any identity and what risk that may have. So Avi, I mean, Sandy's really getting to the heart of operationalizing your security in the cloud. And look, the compelling aspect of the cloud, one of them anyway, is scale. But people tell us to really take advantage of the cloud. They have to evolve that operating model, maybe completely change the operating model to really take advantage of scale. So my question is, how do you operationalize your security practices? What should people think about in terms of the time it takes to build in automations and bots for things like continuous compliance? What can you share in terms of best practice? So traditional ways of operating, if you look at it, is you identify a security risk and a ticket is created and team starts mitigating them. But with so many cloud services and with so many solutions that teams start building in the cloud, it becomes too much of an overhead for teams to mitigate all these security risks that keep coming into the backlog. So as we partner with Sunray in building a foundation, the way we try to approach it is differently. We said, why don't we build this using automated remediations? If we know what are the security risks that we should not be creating in our environment and be non-compliant, how can we mitigate them? And with Sunray and AWS API capabilities, it's not that hard for us to build automated remediation bots because identifying risk has already been taken care of by Sunray. The only aspect we need to take care of is how do we mitigate that? So that's the path we chose in building our cloud security operating model is modeling more on automated remediations. But as part of building that, there is always a cases where everything cannot be remediated automatically. And for these kinds of scenarios, we built a workflow where it still gets funneled through teams so they can prioritize in their backlog. But other key thing that we did as part of operationalizing is teams need to use Sunray as their way of working. Teams need to know what and why they should be using Sunray. So we've connected a lot of training and onboarding and working sessions for teams. So they understand how to use Sunray, how to consume the data coming out of Sunray so they can proactively start acting on how to stay compliant. But yeah, it's been an amazing experience building a foundation though. So I wonder if we can come back to talking about comparisons with the traditional prevailing security models. I mean, we're entering this API economy, as I said before cloud is a staple of digital business. But people have been doing on-prem security for decades. Data loss prevention is an entire sub-industry so what's different about doing it in the cloud? How should we think about that in terms of whether what responsibilities we have, the technology, what's your perspective on that? There's at least five questions in there, Dave. So we'll- Pick your favorite. Pick your favorite. To feed off of what Avi was talking about, he said many times teams need to solve these issues. Teams need to see the issues they're creating and it's interesting as we move to cloud, we decentralize some of these security functions. And that's actually an important part of the summary solution and how you build a cloud security operating model. There's a set of findings we'll call them, maybe they're security findings, maybe they're informational findings that are a fairly low risk and should be dealt with by the individual teams themselves. But that same team maybe isn't the person that can sign off on the risk if it's high enough. And if it's not, then it needs to be escalated to the next level up to have that risk signed off on. A lot of times in large enterprise for workloads, that was done using unfortunately, tickets and systems and humans actually filling out some form of a checklist saying, yes, I met this, no, I didn't. And we can automate huge numbers of those tests, including distributing them to the teams for the teams to solve themselves. And if they do their job right, there's not even the need for the central security body necessarily to know about the issues because they got solved. But when they don't get solved, that's when rather escalation to bots and automation or escalating to a centralized team starts to make sense. You kind of said a lot about DLP there as you were doing in cloud and just data security in general. And I do think cloud has given us this interesting opportunity that's really upset data security in the old way on its head. We used to do data security by putting agents on systems or sometimes it was a proxy in front of it, but either way, that doesn't work well in cloud when you're consuming platform as a service. Amazon's not going to let you put an agent on their database that they're provisioning for you. And if you put your own proxy in front of it, you probably just messed up the elastic scalability that was built into the whole thing to begin with. So we needed a different way to look at this. However, we also took away a couple of things. In cloud, the application teams themselves generally use fit for purpose data stores. They use the data store that's the best for the workload they're doing. Our own workload has many data stores under the covers. It's not one data store. And so because of that, this kind of, the old world of there being a data security team or in a database optimization team that optimized the database workloads actually gets distributed as well all back to those teams. And so we've gained kind of this fit for purpose, smaller sets of data stores that are being used all over. And on top of that, the cloud vendors in many cases have done great things to enable monitoring. Part of the reason we were putting agents on database servers is because the Oracle admin said, I can't turn logging on. I don't have a big enough system to do it. It's going to crash the system. Well, in cloud, parts of that go away. You can scale the systems up. You can enable logging. So now you can get that rich data that you wanted when you were in enterprise. And so Sunner's really kind of taken that model and said, look, we can give you the visibility around data movement. We can give you the visibility around all of the entitlements to that data. We can understand, is your data at risk? And then we can profile all of that for anomalies and say, it's kind of odd that the workload that normally connects into this automated fashion is now using its access key from a different location. That doesn't make any sense. Why is that happening? And so you get kind of strong anomaly detection as well as the governance. So data security in cloud, if we kind of fast forward a few years, will look very different than it does today. I still believe some of the teams are not quite there yet in cloud. They're still struggling with some of these identity problems we talked about. They still struggle some of them with CSPM problems. And so we have to solve those first, obviously, before we get to the true data security. But it's interesting that cloud has enabled us with such rich tooling and APIs to actually do it better than what we've done on enterprise. A lot of really powerful concepts in there. Thank you, Sandy. I mean, this notion of decentralizing security functions reminds me when Warner Vogels describes this hyper decentralized distributed system that Amazon is building. And it's clearly a theme, you know, maybe it's bromide, that people talk about shifting left, designing security in. And it's important, you're not just bolting it on as an afterthought. And so maybe this next question sort of really relates to the theme of this event, which is all about scale. And so here's the question, Sandy. Thinking about your contribution to the future of cloud, obviously you start a company, you want to grow that company, you want to serve customers and grow your revenues, et cetera. But what's your defining contribution to the future of cloud scale? Look, we want to enable companies to scale faster. We want them to be able to put more workloads in cloud using, you know, the right set of security controls to keep those workloads safe. I know we can actually do this in a way where, you know, we talk about defense in depth for years, right? And usually in enterprise, that meant many levels of networks before you got access. Now we need to do defense in depth in terms of, you know, actually variety of controls. We can't throw the network control away. It's still us to be there. We need an identity control and it will be the primary control for what we do in cloud. We need a data lock, you know, rather that's through an encryption key policy or whatever it is. So we have multiple different layers of defense in depth. We can use in cloud today. And so it'll be a much more secure environment than it was in the future. But we have to, again, so my contribution is hopefully I can help everybody get to that level because right now we still see way too many breaches with very simple configuration problems that ended up exposing data unintentionally. And that's worrisome. You know, that's funny. A lot of people maybe can't relate to that defense in depth. I mean, obviously security people again, but we as individuals who now rely so much on our mobile phones and things like SMS. And then you start to build in non-SMS, you know, base two factor authentication and you start to build your own personal layers. It's sort of a microcosm of the complexity that you have to think about in the enterprise but in having tools to automate is critical and expertise obviously. So let's wrap, Avi, give us your final thoughts in key takeaways on building a world-class cloud security. I guess the key takeaways would be is you need to choose the right partner. It's not just a solution. And another key takeaway is automate your way because with security in the cloud is different than traditionally how you do it. And the only fastest way to move is automate yourself away out of it and rely on talent, rely on a lot of young talent that's coming in and all the tools like Sunray, AWS are making it easier to operate in the cloud. So bring up the young talent and upskill the talent and leverage all these tools to be more secure on the cloud. Yeah, use automation to solve the big problem of that talent gap. This is not enough of it out there and the adversaries they're well-equipped and quite capable. Okay, Sandy, please give us your last word. Look, again, I think cloud is going to get us to a point where we are more secure than we were in enterprise. We have all of the right tools and controls to do it. We can decentralize the security and make it better. Again, I think if anything just encourage people to really look at a cloud security governance model, right? You can't do this ad hoc trying to whack a mole of small issues as they come up. You build it in as an operating model, you automate it end to end and you deal with the exceptions. Yeah, I mean, you're very optimistic and I think is for good reason. I remember listening to Steven Schmidt a couple of years ago at reinforce basically saying, look, we feel pretty optimistic about solving this problem. Whereas I have to say every year I look back in the enterprise on prem and it's getting worse. And so keep up the good work, Gents. Really appreciate the time on theCUBE today. Thank you. Thank you. And thank you for watching theCUBE's presentation of the AWS startup showcase, the next big thing in AI, security and life sciences. I'm Dave Vellante.