Cloud Interoperability Security Strategy | Ft. Splunk, Okta, Netskope, HashiCorp & AWS Marketplace

In our latest Podcast episode, Anne invites Baz Donoghue, Technical Cloud Environment Consultant at Somerford, to theorise creating your cloud strategy with your security strategy. They detail the vision, value and visibility such strategy can offer as well as where to get started.

✓ Not sure how to contact us?
https://www.somerfordassociates.com/contact-us/

✓ Learn more about the technologies featured in this video on our website:
https://www.somerfordassociates.com/technology/

✓ Keep notified of news & announcements on Linkedin:
https://www.linkedin.com/company/somerford-associates-limited/

✓ View our complimentary events:  
https://www.somerfordassociates.com/events/

✓ Follow us on Twitter for instant updates: 
https://twitter.com/Somerford_Ltd

♫ Background Music (Planeteer Reaction) Written by Bryan Teoh

#SplunkCloud #CASB #Netskope #SWG #Terraform #HashiCorp #Okta #AWS #HashiCorp

Transcript

Cloud Interoperability Security Strategy | Ft. Splunk, Okta, Netskope, HashiCorp & AWS Marketplace

[00:00:00] Anne Mundy: Okay, welcome everyone. Thank you very much for joining Somerford Associates' podcast,

we are going to be talking about why do you want to create your cloud strategy with your security strategy? So integrating the two of those together. And so for that, I've got Baz Donoghue, welcome Baz.

Baz Donoghue: Thank you. Thank you. 

Anne Mundy: So we'll go into why we want to do it. How when's your debts should there's not always a should, but how we suggest you could do this with our three vs vision value visibility, we'll go through that later. And then most importantly, practical examples of how to do this and how it works.

So anything else we want to throw into the conversation? Both. 

Baz Donoghue: There might be some stuff that crops up as we talk. I think that might come to mind, but yeah, I'll get on and you can touch the phone. 

Anne Mundy: Cool. Do you want to just give a quick [00:01:00] update of who you are and why you're talking about cloud strategy for the listeners in case they haven't met you before?

Baz Donoghue: Yeah, sure. So I'm biased on you. I'm a solutions consultant at Somerford Associates, and I've also been building out our cloud security strategy as well, which essentially encompasses. Understanding, not just our kind of specific tools that are within our, our kind of our offering catalog, but the general types of tooling around cloud security and conventional kind of static infrastructure, just tooling as well.

And how best to integrate those both with a view to kind of. Trying to realize, really realize that realize as much value as possible from kind of cumulatively building these capabilities. But as well as seeing where customers already have, you know, maybe one, two or more of these capabilities and they maybe aren't integrated in such a way where they're not getting as much value or which visibility is they could do.

So it's, it's kind of taking a, a wide view lens, look at those types of capability. And why 

Anne Mundy: do you [00:02:00] want to do it then? Why does someone need to do this? 

Baz Donoghue: So that's an interesting question. So with regard to cloud security, I don't think it's any secret that it's you know, certainly. If your organization is starting to make those steps towards being to, to leveraging cloud capability, whether or not that's from an infrastructure perspective through ask whether or not your lab led leveraging software as a service and all the various different acronyms and capabilities that are in between.

You need to have some sort of security strategy for doing so Many customers as we've kind of spoken to or many organizations, as we spoken about, maybe on previous podcasts have kind of taken what we call that running Jenkins cloud. Or this has had a more measured approach into cloud and others have kind of started off in cloud and the cloud only.

And depending on where you are in, in that level of maturity, you're still gonna need to have to have a view of what, what your security requirements are. And depending on where you are. In that journey will depend [00:03:00] exactly on, on what you kind of look at. So it was built out around some customers, initially the ones taking these, running these running jumps into clouds to maintain operations, then retrospectively having a look back and saying, okay, well we've built all this stuff in our cloud.

And then we built all this capability. W you know, w we've operationalized it really well, but. Now we can take a backwards look and almost retrospective. Look how security, because you know, we've seen it. We've seen a news, we've seen articles we've seen across industry that you know, cloud-based threat actors have increased massively through various different for various different reasons that we've kind of talked about before, but we'll no doubt.

Talk about again. So yeah, so the 

Anne Mundy: threats increased, everyone's got some sort of big nebulous. Messy situation with cloud, whether that's partly on prem. Okay. So yeah, we definitely need to think about security along it. How are people doing it then when we're talking to these clients? How, how are most people securing that cloud?

[00:04:00] Baz Donoghue: Yeah. Good question. So I think there's various different camps. Of thought and there's various different camps of capabilities as well, I suppose when it comes to being enabled to deploy those security controls for cloud there's, there's quite a lot, but I'll probably make me maintain about three of the minutes.

So, so one is customers who are maybe hybrid in their approach to cloud. So they've started statically and they're moving towards leveraging more and more cloud capability. So typically that. Really starts with our iOS solutions and maybe some elements of SAS. So office three 65, for example, and then branching out into elements of Azure, AWS and kind of GCP from a Google perspective and kind of leveraging those platforms and what they tend to do is.

Tried to maintain security controls around those cloud technologies based on how we do on their static infrastructure. So whether or not that's through routine of traffic back through their VPN and maybe to an on-premise security stack So that's one methodology that we've [00:05:00] seen or trying to translate those kinds of security controls that they have on their static infrastructure, across to native security controls within their cloud infrastructure.

So from know, from an Azure and then from an office three 65 perspective, if they're familiar with windows and they're familiar with. The kind of policies and services that they can apply their security controls around or brand. And they can somewhat translate those across into some elements of their cloud.

So there'll be some customers who have that approach. There are other customers who. Have an approach of using quite heavily leaning into the tools provided by those constellations. Particularly if they're very heavily into leveraging cloud resource or elastic resource. So AWS, GCP, and Azure. So they'll, they tend to leverage the tool that's available within.

Those particular cloud platforms. So when we talk about AWS, it's things like guard duty and their cloud trail and the security hub, et cetera. And again, various different security services for everyone with a GCP. And then Microsoft again has a whole raft of other offerings. So [00:06:00] they tend to leverage those and use those in conjunction with either their static infrastructure, security tools.

So feeding back, if they've got some on-prem log analysis platform potentially, and maybe doing some updating of this kind of security use cases And kind of trying to, trying to maintain the level of security control that way. And then we have other customers who typically who are kind of cloud and cloud only like cloud, they take the cloud-first approach.

And they tend to leverage tools like security tools that are available in the cloud that are outside of those security platforms. Then. Traditionally what work has been solutions, but now I don't really like to go on CASB. I mean, CASB is a capability, but a lot of the solutions that, that say that they're a CASB solution, they actually do a lot more so of a lot more that they're their cloud security platform and capability in their own.

Right. And CASB is a part of the service and microservices essentially that they offer around that 

Anne Mundy: and the advantages of doing this third way. So we've got hybrid, but treat it like it's on-prem. The second one is. [00:07:00] Use the tools, native cloud security facility. And then there's the cloud. First one, we use a whole separate.

Vendor for your security post has the advantage of not being tied to just AWS or tied to just ECP because you can have it on top 

Baz Donoghue: of all of it. Okay. Yeah. Yeah. And, and, and it kind of offers I mean, I don't think it'd be any secret to say kind of offers you the best position from a security standpoint, but.

That's because you're leveraging various different tools from a security perspective. Obviously the, the, the offshoot of that is you need these additional products and you need to work into configuring and understanding how you're going to leverage these additional products. So, so whilst, yeah, it's fantastic, you know, I did one of the more ideal solutions isn't without its drawbacks from either a deployment or a procurement perspective 

Anne Mundy: as well.

Do you have an impression of where you think people should get to where the vision of most of the CSOs is where they want to [00:08:00] be? 

Baz Donoghue: That's a great question, actually. I think what I would like to see is. CSOs have been organized. I think CSOs you've been organizations kind of already know where they need to be.

If I'm honest, when it comes to that, that kind of vision, that cloud security vision, I think they already have that vision, right. For the most part. Pretty much nearly every organization, CSO that we've spoken to has that vision. They, they appreciate the risk within cloud. They appreciate the need to secure it.

And they appreciate the kind of discreet, particular nuances and use cases dependent on how their organization does business with the cloud. So I think they already appreciate that. I think the challenge is being able to take that really kind of top level overarching vision. Being able to translate it tactically down to the next level.

So not, we're not, not kind of nuts and bolts building up the kind of actual technical capability, being able to make that link between the strategic view and the tactical view and ensuring that the requirements. You know, th th the requirements within the [00:09:00] vision on that, at that level, by being able to articulate the specific kind of security use cases that are required, and ultimately what the goal is, you know, what's what, what is you know, clarifying that vision, you know, we're going to talk about the three V's, but CAC.

So this is exactly what we mean as opposed to kind of having these broad sweeping station, you know, statements of, you know, we want to invest in cloud security. Yeah. Yeah. What does that mean? What's more important to you? Where do you, where should you focus first and where can you kind of leverage what you're already doing and how, where do you kind of need to build up maybe a new kind of policy or a new strategy to address something that's emerging in, in, in, in trends that we've seen that security.

Anne Mundy: Do you have an example of where you've helped someone take that high-level vision and actually translate it to what we actually need to do tactically in the security environment? 

Baz Donoghue: Yeah, so, so we host a customer of ours, a longstanding customer of ours. Who we work closely with both from a professional services perspective, but also helping provide kind of additional context from a security [00:10:00] perspective.

So again, the security team already had a vision. They already understood what it is, what it was that they wanted to achieve. And, and what we were doing was kind of helping them from a helping them gently from a people to process perspective, but essentially trying to get them to leverage their tooling to provide them with as much maximum value that we can.

And we, and we, and we managed to help them to, to, to build up to that, to that point. And then based upon that, we were having conversations around about what the strategy is moving forward from a cloud perspective. And you know, now that now that the kind of more on-premise securities that more on premise security controls have been put in place and the security practices were there, you know, what the next stage was.

And we kind of had a look at that cloud capability and actually from this customer's perspective, they already had these capabilities. So they already have the, they already had the tooling in place. It was just somewhat siloed. And I've kind of been, it had been utilized to address a couple of use cases, but not that that you could do so much more.

So we were having [00:11:00] con we had conversations around about. You know, how, what, how are you currently utilizing this tool? Is it, you know, from what you're utilizing it for, is it, is it the best tool for you or is it that often you have something that maybe doesn't have quite the same capability, but does those specific elements that you want?

And actually the desire was there to utilize the whole kit that was provided by this capability. It was just a matter of how we, how we integrate that with the way you. That the organization was currently carrying out a security, but say you had to look at the capability, we'll have a look at how they were utilizing it.

And then we had to look at marrying that with the, with the current practices that the soccer carrying now from a strategy perspective and came across some some nice paradigms that we could pull across both ways, really. So helping expand the Sox view of, of cloud security threats and pulling them in a way that the SOC.

Would like to do their business. And then also being able to take the Sox expertise and pass it back through to the team in charge of managing that platform to help them develop their policies and processes on that platform to [00:12:00] better secure it. So that was quite a good win from that perspective. But yeah, so, but the challenge, I suppose, there is kind of something we're going into is, is again, it can be really difficult for some organizations to articulate what their security.

Vision what their security strategy is from a cloud perspective is and one of the elements that I know that we've been working on is kind of trying to demystify trying to demystify this process. There's lots and lots of security tooling. There's lots of, lots of acronyms. I think there's an, there's a new buzz word, you know, at least one new Rosemary, if not, you know, a few per day from a cloud security perspective.

And being able to understand what were these capabilities mean? Are they relevant to us as an organization? Is this something that we should be focusing on? Is this something that we already do? A lot of these questions are things that are being asked at that level, and it's difficult to articulate it based on the information that's given, but on these products alone.

So that's kind of where we've really tried to build out the kind of, so what element by saying, okay, well, let's give you some practical examples of use cases that [00:13:00] leverage the common cloud security threats and the technologies that are used to provide security controls around them and see if that's a fit for your organization.

Is that something that you're concerned about? And if it is, then we can. Nicely articulate. Okay, well, this is the kind of product you want. It needs to integrate with these products. And this is the overall capability solution that you're going to get. And trying to demystify it that way. 

Anne Mundy: Yeah, that's, that's really valuable because I'm not full-time in technical work like this as you are.

So, so keeping abreast of all those buzzwords and things and trying to cut through that, the new ones and how they apply in Our clients' worlds. This is, this is a real challenge. That's thrown a practical example here. We've gone through so vision and we've sort of hinted on like how to get the best value from the tools that you've got already.

But let's throw in a 

Baz Donoghue: practical example. Sure. One that I've seen more recently it's becoming more and more relevant is, is around EDR. So and what's interesting about EDR almost actually [00:14:00] quite interesting about cloud security solutions or traditional CASPI solutions is a concern from my perspective from, from clients, customers about how to deploy, manage those technologies and an enormous, excuse me, one more state reluctance to do so.

So the reason being is. If you look at a tool like an India, or you look at certain security capabilities like log analysis or network analysis that can come from an operations perspective is typically deemed to be much more passive, you know, production from deploying those capabilities to the end user.

Because you're deploying them at that kind of the network layer. Maybe you've got various different senses that you're deploying and typically the end user working away on there, you add all that end point that they typically they're. They're not, they won't be affected by that kind of configuration.

Whereas as soon as you start to talk about deploying agents to end points or capabilities to end points, then. You know, security personnel immediately starts gap effigy because it [00:15:00] maybe took them a significant amount of time to get to a point where they've got this gold state disc image that they've deployed to their endpoints, maybe already managing several other kinds of end solutions such as that virus or various different update capabilities.

So adding additional agents onto the inboxes is often a concern. But what we have seen is, is Kind of raising the requirement for it based on kind of threats that discovered at the cloud. So for example, if we were going to utilize Netskope. And we're going to leverage Netscape, which is cloud security capability with, with various different security capabilities within that.

So from a CASBY solution through to you know, cloud threat detection and DLP elements as well. One nice integration that we've seen from the Netscape expenses is as if we were to deploy that scope. Ideally we would deploy with it with an agent on the endpoint and that agent would then steer.

We use as traffic through to our, to our tenant. And then all of our traffic could be expected. Inspected. There are also elements where our Netskope tenant is also going to inspect our [00:16:00] cloud cloud storage capabilities, whether or not I asked. So if that's public cloud or if it's SAS. So, for example, we want to be able to scan out one drives.

We want to be able to scan up Google drives. You want to scan out boxes, you know, et cetera for, for malicious content, that's been uploaded there and they could potentially be then downloaded by our user base. But we also want to be able to check for those natively in the resources of the solutions as well.

So S3 buckets, so block storage, because again, they're, they're places where malicious content could be stored now. Next kit will protect us from those if we configure it correctly. So it will, it will it can retrospectively scan those areas and it can actively make sure that malware doesn't get delivered to those areas as well.

But what it can't really do is, is help us in providing if, if for whatever reason, some Alec did get downloaded onto an endpoint. It's quite difficult for us to be able to tell what happens thereafter. So we, we, with Netskope, we can easily tell it went to a particular point. It was downloaded by a particular user and [00:17:00] have all the information surrounding that.

Once it's on an end point, it's really difficult for some Stan, what it did. So therefore, depending on how the, that you help the organization is configured. Lateral movement becomes really easy for the attacker because we can't see it. Right. However, if the customer does have. An EDR solution and you can sync the two up.

So what you can say is, is there any kind of threats that Netskope came across, any kind of artifacts, some malicious artifacts that we detected, we can take the hashes of those files and we can pass that through as threatens into intelligence, dynamically through to the EDR solution. So the next step is essentially saying, Hey, found a load of stuff that's been delivered to our, you know, I have an absolutely massive cloud environment, which is a huge.

Footprint that that can be pretty much attack for more or less anywhere. And with all this really juicy information with regards to malicious files, Here's a heads up. Here's some files keep an eye for these on the end point. So then the end points can be completely up to date with not just generic file hashes that we're seeing, but actual file hashes that [00:18:00] you've seen in your cloud environment.

So,

yeah, I mean, we'll look for all kinds and they'll try and give you a broader coverage as possible, but if there's a new threat that's been specifically delivered to your cloud services. And we detect those on the cloud. We want to be able to pass that information to the endpoint, to protect them as well.

So then you protect it both at the interface from the customer and the ineffective in the cloud. So that's from, from the user and then the cloud. So. Yeah, you, you, you covered on both ends of the spectrum there. That's a 

Anne Mundy: really good interoperable kind of example there where you pass information between the different tools.

Yeah, 

Baz Donoghue: absolutely. And you can expand that out further, right? So that's, so from my perspective, relatively straightforward, right? Passing through some threat intelligence. Well, you could do the reverse as well. So you could, if, if, if if an EDR solution detects a threat on an endpoint, Again, you could be able to pass that, that information back into the next code, and then let's will be able to, [00:19:00] based on the outcome you could apply then some security controls based around that.

So if there's something that you didn't detect then again, you, they can mutually benefit from being able to update nation. Okay. Cool. Thank you. That's a good 

Anne Mundy: practical example. Let's delve more into that. Getting the best part of your mash of tool with the interoperability, because I'm so fully full there, visibility to people listening.

We have a suite of solutions and they do a various type of functions. And we're not saying you need all of them, and we're not saying you need necessarily, even one of them. We're just saying that you need ones that do these generic titles and they need to talk and interoperate. Together. So what are the generic capabilities that we're looking for out of these solutions?

Baz Donoghue: Okay. So some common capabilities that we see into into operate. Okay. So so first, first one would probably be identity access management, as you mentioned. So I do think it's, I think many people have heard of Opta. So again on [00:20:00] organizations and products and again, so from an ion perspective, I think that's kind of must certainly if you're delving into cloud security, because if you don't have an IAM solution, Then it becomes much more difficult for you to then to implement and start to leverage much more mature security capabilities later on.

So for example, if we look at any CASPI, regardless of whether or not it's Netscape or another one of the, one of the core tenants of re of, of being able to understand who is accessing what is being able to leverage because without them, we can't apply security controls based on identity. So if you don't have, I am, then you can't do that, right?

You can't, you can't, you can't understand. Which identities are accessing any cloud capability, whether or not they are cloud services, whether or not they're your sanctioned data pages or not. And then you cannot, you can't then retrospectively or in line of plus security controls based on that. So I think the move and I, and I think most organizations are here, but the move away from.

Usernames and you know, static tokens to or having a list of [00:21:00] accounts and moving more towards an identity and having, having a common identity is you know, already being taken up by most organizations in one form or another. And I think it will, will underpin a lot of the, of the security capabilities moving forward.

What kind of evolution of I am that we've seen as well, which is really interesting at the moment it's kind of cloud Pam, right? So the elastic Pam, so we'll be calling it so privileged access monuments. So again, there's lots of capabilities. In fact, we have multiple capabilities that can provide the Pam solution, but there can be certain challenges when it comes to being able to provide a comm solution that is truly elastic.

So what we mean here is that. If within an IAS solution or within our public cloud, we we've configured one of or several of our resources to be elastic so that if we need, for example, we have a web service and if I web service becomes inundated and we can no longer handle the traffic that currently assigned the resources are assigned to that particular service.

And we can automatically [00:22:00] expand out the resources available to us. So we spin up more resources on the end, we have more web servers. We have to help the web servers. We have more load balances. We spend on more load balances and in order to help those, we have more database back ends and everything kind of grows elastically to help us deal with that surge of, of of requirement.

And then it traces itself back down. And this can happen in, you know, in seconds or even, you know, it can happen across minutes or hours or it can happen across seconds and being able to help with that kind of explosive burst of additional security footprint that we need to manage. Sometimes there's a Pam solution to find that too good to keep up with.

So elastic pump, the mini is something that's really interesting. And I know sort of thing that's been said and worked to from an optic perspective with the advanced server access, which enables you to be a predominantly focused on the dev d environment so that developers can access in a secure way.

Any. Any of these resources that being spun up in public cloud, either as a completely new projects or, or as devices that have been expanded [00:23:00] out elastically, but using the same identity in a manner that is useful to them. So they're not having to necessarily log on through some sort of third party or proprietary.

Desktop management solution that can SSH strands or box, or they can RDP straight onto a box. It's just what developers want to do. They don't have to 

Anne Mundy: use that as well. Like if there was an incident, I just did an expanded 

Baz Donoghue: box. It's a good question, potentially. It depends. It depends on, on, on the roles, responsibilities and capabilities of the SOC.

So some organizations keep their standard. They there's a, there's an argument of conflict of interest. Yeah. So we don't really want SOC analysts logging into our boxes to provide us with information and give it and help triage a security incident, but we don't necessarily want them to go and do the triage that allocate selves, but other organizations actually, they're adapting to having these kinds of super socks almost where all of the members of the SOC are.

The analysts in their own. Right. But they also [00:24:00] work across all the various different other capabilities as well. And in that case, maybe they will do so they might not do it necessarily if they're in that sock hot seat, but they may well access that in order to  it kind of depends on, on how organizations configure their runbooks.

Yeah. 

Anne Mundy: So we hinted a Sage. So I suppose there's a lot of secrets as well into the, across the whole infrastructure and he needed 

Baz Donoghue: to. Yeah, yeah, absolutely. So so this, so from a secret management perspective there's a couple of different challenges. So yeah, one absolutely is around accessing resources in our public cloud.

Which is hopefully going to be managed by some sort of identity solution, but isn't necessarily a way. But then if we take that and couple that with multicloud environments, so they don't necessarily all play very nicely together. So you might have to have individual identities for each multicloud environment, depending on how you're configured.

And then when we look at sassy even further, again, You may, you may need [00:25:00] multiple, not just for users accessing SAS solutions, but for all of your integrations through API or otherwise, or, or internal communications between services, typically you're gonna need some sort of secret whether or not it's a certificate, it's a token be that, you know, be that rest or, or, or any other and managing these tokens can then become incredibly difficult.

So this is where we sit in secret management. Become more and more prevalent, certainly in the cloud space. Not, not purely because they're a secure vault for us to be able to secure our secrets. So actually we are our users and our developers don't need to interact with those secrets that our solution will do that for them by proxy.

But yeah, so not just from that perspective, but from the perspective that There's other capabilities built in so things that are we kind of haven't put it on there, but I think we talked about it last time, which is like encryption as a service as well. So you know, developers working in the cloud, developing what they need to develop and they don't, you know, they don't necessarily want to have to develop the specific.

Mechanisms for encrypting [00:26:00] the data. That's either at rest of the imports or communicate between the various different endpoints or moving parts within their capability. So and maybe wanting to choose a service and typically these, these secret management solutions, they, they Harbor that as well.

Anne Mundy: And for that we think 

Baz Donoghue: HashiCorp folks, Scott volt. Yes. Yeah, absolutely. Specifically as cobalt for that comes to mind. And, and not just that, but it interacts with All the other various different kind of supporting capabilities associated with a dynamic cloud environment. So you take Terraform.

So that's your infrastructure infrastructure's code again, integrates very nicely with vault so that when we're configuring our infrastructure as code anything that needs to be done securely, any secrets that we need to leverage as part of that deployment can all be leveraged nice and security via vault.

So again, it's, it's never presented in the code. It's never presented. Outside that interaction between those two different capabilities. Same again, if we're going to get expanded even further. So if you've, if you're looking at our service to service communication, and then again, HashiCorp console, we'll manage that as a secure service [00:27:00] mesh.

And again, leveraging vault as part of that, to, to help add in that, that kind of additional security by an able to encrypt the communication between those services. So yeah, all of these kinds of different capabilities that we see, you know, this meshes infrastructure as code or secret management, regardless of whether or not it's HashiCorp and another, that we need the capability for them to all integrate or interact with us nicely because human interaction is ultimately going to fall off from a cloud perspective.

It's interesting discussions around whether or not it needs to, or whether or not it will, but

That would be 

Anne Mundy: a whole nother podcast, so, okay. We got, I am Copan CASBY secrets management. Christian is service and then service meshes infrastructures code. Cool. Okay. Let's time for another practical example, throw in another practical 

Baz Donoghue: example. I mean, when we kind of talked around it with, with elastic Pam, right.

So let's have a discussion around how we would do that. So for example This is kind of born from an [00:28:00] idea. Certainly when we look at a we were looking at doctors, advanced server access, sometimes it can be difficult to articulate the requirement of it, of a, an elastic Pam solution like that.

If you're just looking at. The technical documentation and member, some of the marketing elements could be kind of difficult to understand why that's any different from Pam and why you would actually need it and what it gives you above, above and beyond other Pam solutions why it's relevant. So in order to do that, we kind of need to have conversations about, well, what exactly, what is it that we were meaning to secure?

When we talk about dev development environments? And I won't go into too much detail now. I think we've done a webinar on it. And I think we'll be talking about it much more in the future, but essentially it's being able to understand, which is kind of part of the vision that kind of vision V is understanding well, what is it we're actually protecting?

So if we're talking about dev ops, you know, sec dev ops dev sec ops, and all the variations in between The different iterations from my perspective they have, they have different connotations [00:29:00] associated with them. So, you know, if you're looking at dev sec ops or sec dev ops, really my perspective that's do developing a product and that product aims to be secure.

So if you're developing a software, you're developing something that is going to be delivered to a customer, either potentially all sorts of service, then it's ensuring that that service is created and delivered in a secure way. And the DevSecOps, the sec dev ops, our argument is we'll do we do after we've developed it.

And we do it, do it as part of our development. And that's a whole argument. And there pros and cons for, for, for both sides. But actually what we see with a lot of our customers who do, who don't do that a lot of our customers is just helping maintain operational it for their organization solely for use within their organization, some and some providing services.

On an edge to customers who, you know, they don't develop code to do develop programs, but they do th that do provide services externally to customers. But actually they have development environments as well. And we want to secure that. So it's more about securing the development environment because [00:30:00] certainly in cloud development environments even not in cloud development environments are goldmine for threat actors because.

Typically most people who work within our privileged access have privileged access. Typically through all ways of working, having done them myself in the past for my sins, you kind of have to leverage kind of all sorts. You typically leverage things like kind of backdoors to help you get in. So whether or not certainly when we were to statically, you might try and surticious the hide access on a box somewhere in case you don't get access to it anymore, you might be storing credentials locally encrypted or otherwise you may inadvertently be storing credentials in, in code.

And again, if you're in the Oldcastle mode scenario, it didn't see much of a problem because you're secure behind your name. Right. But in cloud, we know there is no boundary anymore. So we should, we shouldn't be doing that and leveraging that. So privileged typically in developing environments, then, like I said, there's this a huge wave of information that can be used against your organization and because they're developing, they might not necessarily have all of the security policies process [00:31:00] applied at that stage.

So. This is where I've kind of advanced server access comes in. If we were thinking about building a whole environment from scratch and split cloud, actually leverage this without, as a service. So Wensman cloud have a new customer and they need to spin up an entirely new highlight new tenant for that customer from a cloud perspective.

And what they do is, is they'll, they'll leverage Terraform, so infrastructures to build out that environment for them typically on AWS, but I think there are other platforms available. But they're typically build them out on AWS. Or what they'll do is they'll leverage up to ASA at the same time to start to build out a list of, of users that can access these newly spun up instances and assign various different tokens.

And then there's a PR there's an ASA project that will then be assigned and linked across to those users. So that as soon as. The Terraform instance system spinning up what it needs to spin up. You can log onto it straight away with your identity. So you're not having to use admin and then the default and not having to use [00:32:00] anything else.

You can look straight into that box as developers or as a supporting elements of the organization. Stratify. 

Anne Mundy: Yeah, that makes sense. Okay. So should we go back into the other kind of capabilities that we need to have? So we've mentioned CASB, secure access, service, edge 

Baz Donoghue: sassy in there. So yeah, so essentially what you know, if you were to say.

So CASB technology has been around for a while. And as I said, a lot of, a lot of capabilities that have this CASB capability, I think it's a bit unfair to just call them a CASB. They can do CASB, but they do say it's more. And access security broker it's brokering access between your cloud applications can do a whole lot more across all the platforms, certainly from a Netscape perspective.

So Netscape doesn't do that. So not only, not only is Netscape kind of a CASBY solution as we've [00:33:00] mentioned, but it has all these other capabilities. So we've got various forms of threat identification, in fact detection as well as data loss prevention. Which allows us to provide these very granular controls around access to data and ensuring that it is only accessed by those who should access it.

If they meet certain criteria, so they have to be on the right end point, there has to be the right group that has to be coming from the right place. And they carrying out the right activities for them to be able to maybe access elements. And again, that can be ephemeral and change dependent on.

Where they're logging in from which device are logging in from even time of day. So you can be extremely granular with that. So, so it carries out all of these capabilities as well. So there's a swayed more capability that they carry out and sassy is kind of the next evolutionary step, which of which most of these capabilities are already have a foot in that, you know, have a foot across that line where we're, we're carrying out various elements of, of networks security as well.

So we're not just looking at the cloud. You know, assess area or, or, or kind of next [00:34:00] gen web kind of secure web gateway elements. We're also looking at that network level is hearing that network level at the cloud as well. And, and the kind of support in network services and connectivity to them as well.

So that's kind of where that whole secure edge comes from. Yeah. 

Anne Mundy: So I think we've talked about capabilities, which were based on users and it also based on the infrastructure or the applications talking services, talking to one another and then getting into them. So brokering access to them or securing the edge of them.

And then, and then there's a whole suite of capabilities around I presume visibility 

Baz Donoghue: across all of them. Yeah. Yeah, absolutely. So so again, so Splunk Data from anywhere platform. Let's do it. It'd be called like log analysis platform, but really day for any web platform. So as human readable, you can, you can pull it in.

And then you can, whatever you want to do that day, you can pretty much do it as long as you want to stand what it is you want to do. That's the biggest challenge. So, yes, as, as we see more and more information, there's, there's, there's almost a kind of somewhat of a shift we're seeing with [00:35:00] regard to kind of logging us as platforms or day from anywhere platforms to be able to leverage that visibility.

So, whereas we were seeing and it's still extremely relevant in static organized it's static infrastructure as what makes the dynamic. It's pulling as much information as is relevant against our use cases into a platform like splint and then building out our alerting and detecting use cases based on that.

If we're looking at, from security perspective, if we're looking at it ops, maybe we're looking at measuring specific mattress metrics or or key indicators trying to understand you know, how we're doing hour an hour or day on day based on those. But when it comes to cloud security, Sometimes it can be a little bit overwhelming to take the wealth of information that's provided by certainly ISDN solutions and many SAS solutions, ingest them into a platform like splint and then be able to apply logic across the top for a couple of different reasons.

One is, is that there's literally hundreds of thousands of SAS applications and they might all report critically differently than have a completely different [00:36:00] set of fields. They might, they might have completely different set of endpoints available. So the level of data, the verbosity of that data and cardinality of the data, it's going to be completely different.

And sometimes interpreting that customer can be difficult, which is where our w where we come in from a professional services perspective, but it can still be it could be, it's still a lot of information to process. And then if we look at the iOS platforms like. AWS, for example, again, if you turn everything on from CloudTrail, you turn every single VPC flow log on and you ingest and explode, then.

Yeah, you're going to have a huge amount of information that you can search through, but sometimes it can be really difficult to pull out the value of the information in that, you know, so what, what it would be better to do. And for some people as well, with regards to information, they can only pull so much information in.

So what we want to do is make sure that they can pull as much information as they can, but the information that's most valuable to them. So the trends that we're seeing is, is. The various different cloud security solutions in that unit scopes and your, your Okta from an IBM perspective [00:37:00] and all the various different HashiCorp elements that are based in the cloud,  doing what they do, and then sending the information about what they've done into Splunk.

So this one becomes your single pane of glass for kind of the security element and the operational element. So, so rather than trying to reinvent the wheel, we let the tools do what they're best at doing. Yeah, it was all of that into one place. And then we can apply our own logic to get value out of it over the top of it.

Anne Mundy: Yeah. Yeah. And then connect the dots as well between them. 

Baz Donoghue: Yeah, absolutely. So it can act as that. Certainly when we're talking about that kind of next step, like orchestration. So if we're talking about orchestration and automation, then again, the individual products can, can operate in an isolated manner if they need to, but we can pull it all into like a nerve center and they in a sentence.

Do what it needs to do based on the, the information from all the other elements. That makes sense. 

Anne Mundy: So, and then we get to the sort of, we didn't really speak about Varonis as a good visibility tool, but there we I've named dropped it there. [00:38:00] I think he comes up in at your next practical example probably, but then we've got processes on top.

So Hashi Corp does a lot of the kind of processes for improving the cloud operations and then even process in terms of how to buy. All of these things on a place there's, there's so many different parts to the, to this cloud security equation. 

Baz Donoghue: The process is part around purchasing is actually interesting, right?

Because. You know, some people would not really see it as, as much of a topic, but again, when we've had to look at our strategy actually is, and it falls in line with end user satisfaction as well. So we've talked about, you know, keeping the end user happy and making their experience as easy as user-friendly as possible whilst trying to keep them as secure as possible.

Because if you start to put blockers, you start to put bumps in the road in front of users. They'll just science that they're gonna find a way to get around what. Your security controls in order for them to need to do what they need to do so they [00:39:00] can do their job. The same is for purchasing. So there's a fantastic solution that ticks all your boxes, but it's not only possible for you to get, get it.

If you can't procure that and procure it, you need a solution. So you're going to go somewhere else to do it. And the problem is, is if that's under the vendor or another capability from a different vendor than fair enough. You might not be getting exactly what it is that you want and they think they might not.

Interleave quite so well with your capability, but there is the other risk of just going, okay, well, we don't know where to processes. Is it clear how we purchase it? We're just going to go down that kind of you know, open source route and start to build stuff ourselves, or you know, if we're not, if we can't have access to an AMI or if there's not an AMI that's been built for that helps you really leverage a capability bus.

Spitting out post immediately. And then, then customers will essentially go start to spin up those easy two instances themselves, start to develop all the code. And then that's when figuration starts to slip. And, you [00:40:00] know, misconfiguration is probably the biggest cause of cloud based threats being delivered from IAM solutions or effecting our solutions easily.

Yeah. 

Anne Mundy: Whereas in, in the sort of ideal situation, if you have the vendors on AWS marketplace and you purchase it through there, it's all sort of more of a click of a button situation before you. And so there's less resistance 

Baz Donoghue: to getting it. Yeah. And it's tested, it's supported it's, you know, it's, it's all been you know, prebuilt and checked.

So it's, it's so much easier to, to leverage it and then like that than it is to kind of try to build something custom. If you have to build something custom. No. That's cool. You can do that too, but if there's something that's available for you right there, then it's going to make sense. 

Anne Mundy: Yeah. Okay. Last practical example then, should we, have you got one of on visibility?

Baz Donoghue: I got a use case on visibility. Yes. So in case we can leverage that kind of visibility element that we talked about About about configuration. So I just mentioned that. And so [00:41:00] one of the use case scenarios that we see very, very often is one that you've probably seen a lot in the media is ransomware.

Okay. So a bit of a hot topic, but essentially ransomware occurs regardless of where the data is, but if somebody can access your data and they can run a process against sedan, Then basically they're going to encrypt it so that you can't use it anymore. That's what it is. Right. So that they'll encrypt it in a way where it, you can't then encrypt it.

And there's a couple of different Security controls and mitigations you can put in place. So why did you get back up all of your data all the time or a decent increment so that if, for example, some day is exposed and does get encrypted and taken hostage, you don't have to worry about paying the ransom to give it back.

That's the only one that's only, only solves one part of the problem, right? That's that's about getting access to back to your day. So you get back to being operational. It doesn't solve. The breach in data that then so if [00:42:00] you've, if you're, if you're yeah, if your governance and your kind of data sanitization is particularly great, then it's not going to help you solve that problem, but technically it will help you not have to pay around because you have, your day are available to you. Which is, can be extremely valuable if you're, if, if you require that day operationally.

Yeah. It doesn't that doesn't help him reputationally. So that's one element. The other element is being able to make sure that only people can access, you know, there's, there's no security holes in where your data is stored so nobody can access your data. So if it's on prem again, we're talking about old static infrastructure, typically it's cost and the moat.

Usually you'd have various different layers of security that I wouldn't have to do these houses

Anne Mundy: at the time, but it sounds so much 

Baz Donoghue: easier to secure. Yeah. We're in the high trust zone. It's all good in the HSA. So yeah, cloud there's no trust. So you have to be really vigilant about applying the right security policies to any [00:43:00] data that's exposed publicly. And what this can mean is data that shouldn't be exposed publicly.

Make sure that it isn't well, then it can't be exposed publicly, or if it is exposed publicly, you're aware of it immediately. You can revert the changes or data that is provided exposed publicly. That's the right type of data and expose that we don't have data that shouldn't be exposed probably inadvertently end up in, in those areas.

And again, the use case here is to leverage Again, CASPI solution in the first instance to, for, for both of these and, and for a couple of different use cases are first and foremost is to have a data loss prevention policy so we can identify data. And again, this is where we can use CASB solution, or we can use something like Varonis is going to be able to identify the data for you can categorize that data, and you can understand exactly where across.

Your organization and across your whole estate, where data is and how it's categorized which kind of also falls into the visibility kind of vein because you can't defend against things that [00:44:00] you don't know where your stuff is. Right. So you need to understand where everything is and to what level. It is currently being exposed and how sensitive it is.

And when you have that, then you can start to apply the right security controls to pull it back into where it needs to be, and then wrap around those controls to make sure we're saying the access by those who need to access it. So that's one element. So we can have these, these data loss prevention policies that stop people accessing something.

If they shouldn't. Well, you need to couple that typically with iron, cause we need to be able to identify who these people are to be able to apply those granular security controls, where you're ultimately get to a position where if somebody can access something they should be able to, unless they, if they shouldn't be able to access it, then they can't.

In the cloud, so we need to be able to do it in the cloud. Also we need to be at the point where we, we do retrospective scanning of information to make sure that if for whatever reason, they, it doesn't inadvertently end up somewhere. It shouldn't that it's removed. And that we then we've then reviewed the policy and apply the security controls to understand how it got there and make sure it doesn't get them again.

Which is [00:45:00] something that's going to happen in a huge cloud environments. The other side of that coin is that actually it might be that an organization has these policies. They have this security policies and they believe they've deployed them, but they have no real way of auditing and testing that they've done it.

That that is easy for them to monitor. And that's where things like the public cloud, a compliance, audit, and compliance elements of the CASBY solution, the cloud security solution, not Netscape comes in because Netskope can then. Carry out all this on your, or on your cloud estate. So it can tell you it can inventory everything.

So take it how many easy two instances, and there are three buckets. There are how many blob storage elements there are. How many. Azure instances, there are et cetera. It can tell you exactly where they are within which accounts they reside. And it can tell you the types of security policy that are applied against those, and then provide you with an audit and she'd say, okay, well, all of these S3 buckets are compliant.

We've got the vice security controls. These ones, actually, they don't because. This one could be accessed by anyone. This one has [00:46:00] a certain cost control policy applied to it. That means anybody from this particular range of IP addresses can access it. And again, it can, you can check your, your the posture of your cloud your, your public cloud infrastructure to make sure that the policies that you have set have been applied and that there aren't any kind of gaps where somebody is going to come in and go find an S3 bucket full of interesting.

There I'm going to, I'm going to encrypt this and then. Oh, it's a ransom. So misconfiguration of those items solutions is, is easily at the moment. One of the major problems because of the pace at which it's deployed. And, and often because it's depending on the technologies that you used to deploy it, you know, These are 

Anne Mundy: both prevention.

And then the actual, if even though you've got a DLP policy and you're auditing regularly, you might still have an instant. And then it's the responding to the incident as well. You need all of the, that sort of setup as well. Are there any automated responses or. 

[00:47:00] Baz Donoghue: Yes. Yeah, absolutely. So so yeah, so, so we would rely upon on that information from an audit perspective, to understand when there have been breaches and there are a couple of different solutions, which kind of hearkens back to our original conversation about depending on how people do things, right?

So you're the type of organization that likes to do things natively with tools. Then also you can kind of do that. So if we take of the rest, for example, you could build a Lambda in AWS that if you've detected that two S3 buckets is open to the public and shouldn't be, then the London will run and it will, it can remove the public access from that bucket, which is really good.

If you've got a yes, the difficulty being is is that if you're multi-cloud. Yeah. And you know, that doesn't necessarily work. So you might have to have multiple iterations of that kind of capability. And as well, if you want to do a little bit more than that, then integration becomes difficult because it, so AWS has fantastic orchestrating its own capabilities, but it doesn't necessarily have you know, there's [00:48:00] some scope, but not, no, not total scope for it to go to walk straight with other tools.

So that's kind of where then another solution such as Phantom, for example, Which would be a security orchestration and automated response tool can do that orchestration for you. So we'll talk about soar. Really for me. And isn't a name, but it's about doing two things. The first one is about orchestration.

And what we really mean by orchestration is being able to do all of the cool stuff that our tools can do, but from one place. Yeah. So having that one level of integration, so rather than having to rely upon integrate Tulay with toolbox and then integrating to be with tool C and then it's been all these tiny little inspections.

We want one platform to do that. That orchestration for us is the conductor in our so 

Anne Mundy: much more maintainable. The nightmare I 

Baz Donoghue: can see you can do so much more with it because you can, depending on how you configured it, you can orchestrate tools that don't natively [00:49:00] integrate because it's all done through the orchestration platform.

And then once you've got that orchestration, the next step is then automation, because now that you can orchestrate things, then now FTP automated. So if we go back to the scenario of an S3 bucket, what you can do is if an estimate book has been made public, rather than just have it automatically closed, because that's your, your, your, your, your green or red light policy for public history, bookcase.

You can receive that information and say, there's necessarily been made public. You can understand who made it public. Where was that configuration made from? You know, w w was there a particular IP address within a range that we understand to be ours? Was it in, through our console? Was it in through a CLI?

How was it done? All that information up. And then once you've got all of these kind of informational artifacts, you can then process them individually. So, okay. Well, do we know that IP address hasn't got high risk associated with it? Has it got bad reputation? Is this user, what else have they been doing?

You know, where does it come from? Was there anything else that's associated with that particular account we carried out and you can pull up all [00:50:00] of this information and apply it to a playbook of steps that are worked through logically, and then depending on each of the independent outcomes. You can then have some sort of automated response to either close the S3 bucket and automatically notify the individual who made it public, that they shouldn't doing that or leave it open.

So this seems a bit alien, but you might want to leave it open because there are some estimates, as you know, dependent on your organization, there might be semester buckets that you want them to be public, but you might want to have some more granular security control, apply it against them. And others might want the bucket to be public because they want people to carry out malware against it.

Cause they're gathering intelligence, for example. So we don't leave those organizations out as well. So you might want to do it in a way that, you know, it might not always be some new ones. Yeah, yeah, yeah. You want to be able to have that granularity and you can do that through, through a kind of that granularity is given more easily to assort.

Anne Mundy: Well, we've covered so much content.

[00:51:00] What are the next steps for clients? If any of this is ringing true, or anyone's grappling with this sort of cloud security, how to skew my cloud question or how to make things work together better. Interoperably how, how we w what, 

Baz Donoghue: what are they going to do? Yes. Good question. So, I mean so we're building out content like this.

I'm sure the desire as well. So it's always worth going out and trying to try to listen to there's different conversations, various different talks webinars. And just trying to get an understanding for what's about can be a bit of a risk cause sometimes webinars might be skewed, more sales in.

They're not going to give you the information that you want, but there's lots of information out there. From, from our perspective, you can always come and have a conversation with us. And actually it's something that we're we're building on now is, is developing a specific kind of cloud capability assessment.

So rather than it being maybe, maybe like some of our other assessments, which are more [00:52:00] based around technology from a, from a cloud capability assessment where we're looking at is. How, how are you leveraging the cloud as an organization? What tools and capabilities do you already have from a cloud capability perspective and.

You know, let's have a discussion about your vision. So where do you want to be? What is it that you want to protect from a cloud perspective and trying to understand what, what your, your, your threats are, what we call the big crocodiles, nearest the canoe from a security cloud perspective, right?

Because there's going to be lots. I don't think there's any organization that can say we're 100% cloud secure far from it for the most part. You can't do everything at once. So let's understand where those crocodiles are, the nearest one. So you can develop some sort of strategy to whack them in the puddle.

Anne Mundy: It's actually helping prioritize and looking at what people have already, what we should do next.

Yeah. So basically just get in touch. I'll I'll put in Into the podcast information how to get in touch with us marketing at [00:53:00] some of it, www.somerfordassociates.com is usually a, a good start from there. But thank you, Baz for describing through some of those practical examples of what you need to do and different capabilities that we have, and that people have to deal with this securing your cloud question.

Baz Donoghue: You're very welcome