Leveraging the use of Cloud Design, Paved Roads, and Vulnerability management for a scaled cloud security programme
If you missed the presentation at the CSA AGM 2021 from our CEO @francesco you can find the summary here.
you can rewatch the full presentation here:
Setting the Scene
So you might see in a little bit of phoenix or presentation, we know obsessed by Phoenix, but I really like the Phoenix. Cloud is not a new thing. And I think we might have experienced that by now. And was in 2006, the bones of AWS on the back of the data centre, the usage and the consumer words. And then we see the evolution of the cloud, going with VMware, then as your then IBM Cloud. And then we start seeing the evolution and cod adoption of new services, new SAS proposition, new models, a new abstraction layer. And as I say, these are abstraction layers. So this is innovation, but also obstruction of something that is fundamentally becoming more and more complex. I’ve seen people that don’t have any, I mean, the new level of engineering in the level of cloud, they don’t have a concept of network, or they have very the concept of the network because this has become a commodity. And we’re good in the bed that calm because we can focus more on software we can solve, we can focus more on cloud on the new modern way to things. But again, we are not that far off from datacenter land, we might be, you know, 15 years from data centre land, but it’s still there. It just abstracted and the good part is that some things have changed. Some things have improved, there is security by default, but some other things haven’t.
Why Vulnerability Management/Cloud Security
Major recent data breaches
Microsoft disclosed in January 2020 an incident that occurred in an internal support analytics database. A change on Dec. 5, 2019, to the database’s network security group, introduced misconfigured security rules. As a result, 250 million records of support cases were compromised, including email and IP addresses as well as support case details.
Estée Lauder remediated the exposure on the same day that it was discovered and assured its customers that no consumer data was compromised. Despite minimal damage, there are at least three important lessons that can be learned from this breach: There is no evidence that the database was ever exploited, and Whisper took it down immediately after being contacted by The Washington Post. It is truly hard to fathom how an exposed database from a secret-sharing app could have gone undetected by the company for so many years.
there’s a consequence of not doing security by default or security in general. And we have seen, you know, more recent breaches, you know, Microsoft with some data leakage here and there with the scores of database access. There has been some other disclosure here and there of Microsoft in as your thing. As a loser has reported an incident that has been gone through MGM has been the one that is maybe more popular Warner media and so many more. So every year, we cannot get cast on by these data breaches. But ultimately, we should protect our cloud because we all get affected by and the number don’t lie, you know, there is a lot of element about called, I mean, data breaches, that due to miss-configuration, or to obligation security, you have these two aspects as well, I’m very passionate about these two elements. Even though in the last year, we’ve seen the rise of ransomware. And, you know, crypto locking and crypto-jacking of devices, there has been a little bit more on the race. So it’s it’s not a link to the data breach, but disruption in general.
We can’t solve the problem with bodies
And if we throw bodies at the problem, if we develop an application, if we develop cloud environments, traditionally, just one security person get associated with the application and on average, I’ve seen one security person being associated with 10 teams maximum because that’s the best they can do. So there is definitely a scale problem. And, you know, DevOps have shown that there is clearly a scale problem. And if you don’t know me, or if you don’t like me, please see because I love me and I love giving a smile because sometimes security can be a terrifying word and can be challenging to be in these words. So yeah, Rambo is good info days of yeah, we can do this and verify look. So clearly, there is a problem. And clearly, we can solve this without any level of automation any level of you know, scrutiny and scanning and analysis in a way or another. So how do we do this? Well, we need some tools, but we also need some proactive control. So not everything can be solved by tools, because as I love to say, we’re going to end up getting used by the tool. So don’t use a tool, use the tool as a tool don’t get used by the tool, otherwise, you become a tool. And that’s one of my favourite sayings, to use to, for their purpose for us to for doing things at scale, but in a conscious way. So if you don’t have a plan, and you just throw a tool at a problem, you’re gonna end up with a problem and a tool and a bunch of other problems from the tool.
AppSec Framework
So I like to introduce the concept of paving the way or paving the road to security. And this is one of the frameworks that we use a lot in AppSec Phoenix to measure things but also to see and show how to build things, right. So we start from the left, which is a security by design. And that’s where the definition of pattern guardrails comes and embedding those patterns or working with the various team and deciding what are the things that need to be so funny to be done. And then moving forward is how do we take these patterns? And how do we enforce them? So how do we create a CloudFormation TerraForm action script or element of the sword?
And how do we enforce that in production or in pipeline description? So for example, you can create a pattern that describes how to use it in the right way with the right condition in the right controls, s3 buckets. And then teams that just want to use an s3 bucket without asking exception, they can take and leverage it. And the second step is you can take on s3 patterns, and you can start adapting them for use cases. So you start deploying the use cases or solution patterns where you say, you know, I want to use this s3 For this specific data categorization.
And maybe I need to put additional restrictions, additional processes and procedures. All of these can be embedded in code, not everything because some of this stuff is processed procedures. But a lot of these can be embedded in code and informed so you can produce a CloudFormation script that fundamentally takes these concepts and asked you a couple of questions of what is the name of the team what is the name of the group? Enforce everything else and on day one You don’t need tons of manual lines of codes. But you just need to tweak a couple of options of view option. Because nobody, not all the team needs to do custom things at scale a lot. A lot of things in the organization are repeatable. And we should strive for repeatable things.
Because we have repeatable things, we can define patterns, we can define a standard, we can define standard things, and then deploy it consistently. And in their way, we get ahead of the curve. So moving from reactive, and continuously monitoring the organization in firefighting, we go ahead of the curve, where we can define what’s right. We can focus on important things we can focus on a balanced way of, you know, working on important things in working on firefighting instead, and let the tool fundamentally do the firefighting because once you define what good looks like, what right looks like, you can start defining rules to say, if you are in a specific environment, or if you have, for example, specific tags on your bucket, or if you don’t have buckets, find me all the buckets that don’t have a tag, and then start questioning the owner of the team, you know, why are those bucket not having a tank, and you should start getting this role-based vulnerability or conflict or misconfiguration issue or misalignment from
Where you can look next: how do you select open source
But also there is a lot of good tooling from OWASP, an open-source project, a prowler, that offer the ability to do this at scale in a cost-effective way. And that’s also work in upstate Phoenix we deployed, we have a stack of tooling and scanning two that are open source. And that’s why we have the OWASP. Alliance to offer effectively those tooling and access to AppSec, Phoenix to everybody. They want to do this into monitoring, focus on vulnerability management, and let the tool actually do an orchestrate a lot of that stuff and monitoring give objective, but then focus in their way we free up the security in to actually talk with the development team and focus on the project and what matters most that is fundamentally looking at what they need to solve what problem they need to solve, and how can we be proactive? How can we create policy procedures? How can we create libraries, for example, on standardized ways to authenticate work the director of a standardized way to deploy certain things, or create a pipeline that repeats the same things to do things at scale in an automatic way, and solve hard problems. And so the interesting from an operation is just the same as, as we said before, is repeating what we’ve done with vulnerability, management’s control enforcement, and monitoring that it is not divergent from the norm. Because the environment changes, people change, new people join the team, they don’t know how to configure things.
Tooling how you can mature
How can we help?
Phoenix Security Platform is there to come to the rescue, we help organizations get ahead of the curve and aggregate vulnerabilities and free up security professionals up
Have a look at the full platform https://phoenix.security/platform/
if you would like a demo of the appsec platform https://phoenix.security/request-a-demo/
