Dragan Pendic - Application Security - Achieving Security at Speed and Scale

I'm dragon Peni. I can see some familiar faces, people disappearing. There's some familiar faces from yesterday. So just continuing, maybe kind of some of the messages from yesterday, zero trust. And what does it mean in the context of an enterprise and moving into the kind of more specific scenarios of application security? I'm dragon Pendi I'm principal direct Accenture technology in the UK and Ireland been in the industry for about 25 years. So as an technologist security, professional privacy and architecture sort of altogether. So I hope you're gonna find this useful.

So I'm gonna provide you with a more mundane version of what I think is, is the, the modern application security in the context of DevSecOps, and then sort of deliberately squeezing that sec between Devon ops. What are the areas of application security? I think just really kinda laying out this for you. And I think something let's say picked up earlier in terms of what are we considering and then really exploding this into more detail. I'm gonna concentrate. The secure application development are some of the areas we need to think about.

And what expertly was provided in the previous session is API security. Why APIs and microservices are important because they surface data. And I think this is ultimately kind of the way why we think of securing them and why they're kind means of securing the regular systems and applications wouldn't necessarily work in the context of APIs and something that is a very short lived, very fast, very kind of ephemeral, you know, short lived. So I'm gonna concentrate secure application development in a particular kind of look into the cultural organizational and technology aspects of it.

And hopefully you can take out some important things. You can, you can apply in your own organizations. I had this slide yesterday, but I wanna really kind of emphasize something that is very important in the context of the DevOps.

In general, if you think you're a DevOps organization, probably you dunno your organization that well, and I think really comes into various, you know, sort of aspects and forms, and really is very important to understand before these things actually gonna put a challenge, the it in general, but at the same time, the talents you're going to bring within the organization, as well as your technology landscape. This is the sort of the view from the product-centric element versus the actual customer-centric view.

And the customer-centric view assumes that you really build a sets of products around the customer rather than the other way around, which is basically just creating a product that everyone can consume in exactly the same way. So the DevOps really cannot take this forward and explode possibly million times more granular than this and the change is immense. So if you think about the responsibility of security in this context, this means that responsibility of a security within an enterprise or your business is not just to protect the enterprise it's to protect the customers as well.

So that really is a important, you know, kind of to consider because you're not necessarily in the sort of the old world to say, okay, customers on their own. Now the legislation is pushing us towards that sort of goal. And I think most ultimately it's gonna be, you want to be loyalty and the brand reputation that is really something we need to consider as professionals as well.

So just really kind of then contrast between the traditional and the agile worlds and what DevOps or basically kind of developers will be living day in day out is, is sort of very different and opposing what is the traditional security is about. So if do we have any security professionals in the room that, you know, security function sort of leading or being part of?

Okay, so that's good. So probably kind of looking at the left hand side, you, you, you're sort of looking at the ways of saying, okay, change is bad. Why is bad? Because you not really kind of, you don't wanna change things. You don't wanna really kinda mess around with things that actually put in place. You've been working hard to put those controls in place. On the other hand, the other side of the spectrum is everything is fluid. Everything is in flux.

And when you look at that really kind of gives you an anxiety of what is going to be that next change is the change big enough for you to intervene? Are you, you know, are your resources big enough? Do you have enough people to attend all of those projects, moving around changing things and really kind of giving you a proper scare? So these are the things to consider. And I think very importantly, kind of, you need to look into the, from the architecture perspective, the product and tooling perspective, whether you have the right things in place to keep up with those changes.

So, because the change is easy because change is automated because, you know, testing is automated, everything really kind of leading towards the automation and you're less automated than these guys really kind of, you need to sort of step back and think, okay, what do we need to do to incentivize perhaps these guys to champion security and work with me rather than me chasing them.

So very important sort of thing to remember that agile in a sense that I don't know if you, if you agree with me, but I've seen a lot of, lot of customers sort of thinking, oh, we're are running projects using agile, you're actually running projects. You're actually running and delivering products. And that's really this very important distinct distinction between the running a project and running and sort of delivering a product, which is what DevOps is about what development is about.

So I've, I've stolen this image from a, a report because it's a nice representation in terms of what is the ratio and the challenge today between the development, operations and security. And because you stand there kind of on your own, trying to figure out how to fix this and maybe kind of you think, okay, I don't have this ratio in my organization, but still completely, you're completely outnumbered in terms of what is happening. Maybe you don't have in house, but your agencies and your external suppliers will be having people working on your behalf. And that really is, is the same situation.

So how do you really kind of keep up with this and how do you push from the bottom over to top to the development team to make sure that these guys stay, you know, you know, basically kind of on top of everything in the standards and policies you need to kind of push forward, why secure DevOps or they said, or however you want to call it is you have a different mission sort of in each individual phase in between you have some sort of walls of conflict and then necessarily walls of conflict, not necessarily means the conflict itself, but there is no integration.

There is no collaboration of any kind. And you have a sort of broken messaging happening across in between these teams or you don't have communication whatsoever having it to sort of fix this is not the answer. And when you look at the customer side, basically kind of, you need to create flexibility for these customers. You need to deliver new products swiftly you need to, you need to sort of respond to market trends.

You, you sort of, maybe in the business, there's been sitting statements or exactly the same for the last decade or so now you need to create new products. You need to excite your customers. You need to sell new services, which will put pressure on everything underneath.

So the, the development side is basically kind where you're creating effective change. So the change management is, is important. Moving slightly to the rights. You basically have the, the, the operations team, which we're creating sort of stability as in running with things in a predictive, predictive way. So there is no sort of surprise in terms of, you know, outages, wrong things being deployed, or, you know, having incidents all over the place.

You know, maybe, I don't know if you, if you know some banking in the UK, but some of the kinda split between Lloyds and TSB led to some of the banks, having their systems out for, for weeks. And the co resigned, everything went really kind of, you know, ugly. And it was really kind of all over the news, basically sort of operations and everything was developed. It wasn't up to scratch and security.

Basically, you need to protect your surprise. You need to protect your customers. So these are the kind of linkages in between. What is it, developments where DevOps will be sitting and where devek ops will be sitting as well. So this is a bit of kind of a messy slide, but I thought sort of to bring this in the context of what goes, what happens at the beginning and what you drive towards the production and in, in red is basically some of the vulnerabilities or threats, sorry, the, which will be linked to particular phase of this, of this kind of end to end process.

So if you look at the goals in perspective and look at the vulnerabilities, there's sort of distinctive areas, but what we need to do is focus on these goals. Basically don't lose the conf you know, expose confidential data and non-production systems, which is very, very easy to do because these guys are making things so easy for us, you know, exposing data, moving data around creating snapshots, using AWS, probably many of you have seen in practice. It's very easy to lose data. It's very easy to leak the actual sensitive data. The non-production systems are expose to your competitors as well.

So these are the kind of in blue, you can see some of the important stages where some security activities will be taking place. You know, what the, what is the kind of sec static application security testing, where the pen test will be sitting altogether in this process and when these things will be taking place. Okay. So speaking of making things easy, how many of, how many of you have seen this, this, this window, this is AWS. So this is EBS as basically kind of elastic block store.

And then what it does is kind of conveniently, you can actually kind of get this, you know, make it private or public and is insane. At least from our customer perspective is, is how many of these things get exposed to wrong people because you just simply kind of, it's so easy to do, and you completely lose the track of what is internal, what is external, what is production, what is not production that is, is very, very easy to make a human error, which really kind of puts things into perspective saying if there is a human error, how do we really kind of tackle this? Okay.

So the automation aspect in the context of select say was saying, and everything that happens underneath is, is really kind of maybe kind of the old good, old security, but in the new context or virtualizing, virtualizing the, the security and making it more kind of distinctive from the predecessors, the stuff we already do with the traditional security. So if you say the cloud and what cloud provides to your business, you need to sort of understand how to automate these services and products to work towards a same goal.

So you don't slow down the development team or operations will be running predictive set of services without any problems, but at the same time, you're delivering the same sort of perspective and confidence to the business that you can actually provide information on the breach. You can harden the system underneath and really kind of look after the agility of the entire process as it should.

So just look at the, kind of, some of the elements in there, sort of reflecting to the previous slide, the static, the dynamic tests you have far management as sort of the regular thing, the, the actual form factors will change. You know, some of these things will not necessarily be within your enterprise. It'll be cloud to cloud sort of communication. It'll be within the cloud service, provide environments all basically kind of delivered via the APIs.

So two slides on implementing this all together is really starting with developing, you know, sort of a, some sort of a roadmap within your organization defining what are the goals you need to achieve? You know, do I have the right people? Do I have the right processes in place? Is my it up to scratch? Maybe that was six years ago. I met up with one of the guys, the guy who moved to BBC in London, moved to the ITV. I don't know if, you know, sort of British broadcasting companies. My ITVS is one of the broadcasters in the UK.

He moved on to sort of be the head of API sort of development, sort of revamping everything that ITV was doing at the time. And he faced a significant problem in terms of the talent and skill. He founded ITV at the time, he had to sort of let go, 70% of the actual technical staff, which means, you know, this is what you're facing up, you know, in terms of changes, you're gonna be putting in place. Do you have the right talents?

Do you have the right people and technologies and products to take the company forward and make sure that the company will still be relevant in their years to come build a platform? So the reference platform will be explained in the next slide, but basically kind of making sure that you have something to measure this against.

You need to sort of show the perspective of terms of if I'm building this and implementing, I need to make sure they have the right KPIs, the right metrics to provide to the business, to say shortening the actual time required to develop new products and services, making sure that we kind of minimize the time between testing the security for the particular products in time, because we are not gonna wait, you know, kind of six months and run another audit on something that has been changed maybe a hundred times or more things like that.

So moving onto the right is sort of integrate the pilot and basically kind of run and scale this really kind of over time. So what does it mean in terms of more kind of granular kind of look into the kind of the, you know, what do we mean by foundational, you know, kind of enables there. So the Automational aspect, security frameworks, and trusted libraries, all of these things that will really kind of make a difference, do they exist in any shape or form within your organizations? You need to sort of come up with that.

The program management is strategy and governance sits across everything you do, and you will see the linkage between product development and operations, obviously, because there is a hard link between those two elements because they need to exist and sort of inform each other. If something happens, basically you need to respond in a certain way. So the focus is different for each of those.

If you look at the kind of foundation enables its enabling assets that will allow, you know, for DevSecOps at scale and speed, the product development element is, is focused on integrating security requirements in DSDC. How do we do this?

You know, do we have all the products and services talking to each other sort of end to end process? Are they sitting sort of isolated in, in a verticals?

You know, not really kind of speaking to the rest of the organization, that's very important because you don't necessarily go and talk to these services because, you know, just happens to knock on the door. They have to be formed almost in real time and obviously operations, the good old identity and access management comes into play, the access control and everything has been talked kind of previously in terms of API security management, you know, red teaming, you know, creating scenarios for you to say, what if something bad happens? How do I know I can recover from this?

You know, what people can come up with to basically disrupt the, the actual, you know, products, steal information, you know, abuse my customers and, and sort of create, create some sort of negative effect on my brand. Speaking of integration, again, looking from some of the perspectives, what tools will exist.

I'm, I'm hoping you're gonna have some of these tools in your, in your organization and, and I'm hope it's not just email. So you're gonna be doing various sort of integrations across the verticals and across the distinctive phases in, in the process. But these things are very important to make sure that, that whatever you deliver at the, at the end has a predictive outcome.

And it really requires for things like have you, by the way, has anybody been tinkering or deploying runtime application, cell protection, kind of, you know, controls or products of any kind, anything like that for container purposes, container security.

So basically kind of some of these things are very important and, and I'm going to reflect some of the container security after this, but this is really kind of shifting from idea of development, where you're gonna be talking about vulnerability and guidance, security, test results, and pushing this to the threats and, and, and sort of attack intelligence. If you receive an alert, you better be sure there is something happening that is not to force positive. There is not something that is not even relevant to you. This is very busy again, but this is in detail.

If you kind of look into the, what is the effort required to come up with end-to-end solution tool set technology, landscape products, you would require to run this either through your partners and suppliers or yourselves. This is an, this is an example what you need to do. So if you look at the, kind of the aspects of static and dynamic, if you look at the ongoing operations, your system labels in there, by all means, I've, I've tried to sort of reflect some of the vendors in this space.

So up there, you can see Quist, you can see, or metric Palo Alto cloud passage, Spion that this is the logo. I think they've changed the logo for information discovery and classification and profiling. That really is important after all the data itself has to be validated. It has to be known in order to build something. And I think that's very important to sort of understand.

So shifting down there, what is happening, the deploy and test phase, you have various aspects where tools will come in and what security team will be doing is basically kind of making the sense of, if something goes wrong, what went wrong, who was the, the actor who was, who, what was compromised, who was accessing the data, what data was compromised, all of that should be visible and monitored frequently, container security, I think Alexei was, was discussing.

And I thought to sort of reflect some of the kind of new risks because of the speed of change because of the convenience, because of the, you know, desire to quickly change and build new things, there is a kind of risk of, of you kind of losing and losing the sight of these important changes happening and perhaps human error or automated error that is really kind of leading towards something more catastrophic for organization, but basically kind of looking into the aspects, what are the new risks?

I'm not sure if we understand completely what are the, what is a threat landscape for containers today, but basically exposing and surfacing data through various aspects because of the, I don't know, serverless products like Lambda AWS is sort of short, lived less than a second with these things.

Again, it's very difficult to track what is happening with these services, because if we don't then basically kind of, we, we kind of, we are really late to confirm what's happened, access controls, relevance, container hardening, other aspect, integration and compatibility, I think is, has already kind of, sort of discussed in the previous slide and run time in defense. That's sort of run time application self-protection what's in the code itself. We really kind of bring things to life.

So it lives with the code itself and brings these threats, or basically attempts to compromise out in the open. I hope you're gonna find this useful because I'm not sure if, if, if you've been dealing with specifically finding the right vendor for container security, but this is the kind of look into the space. So what evaluation criteria of some sort could be for you to, if you decide to say, okay, we invested heavily into containers, containers actually effectively now, you know, kinda way of life within our organization.

I wanna really want to know, do we have the traditional tools that will tackle this problem, or do we need to go off and discuss evaluation of, of some external products? And this is basically kind of comparing them, perhaps, maybe it's slightly because these things do change quickly. These things could probably kind of move on and some maturity levels probably could have increased over time and new capabilities gained, but this is something that you could, you could see what is important. So obviously kind of logging, is it open source? Is that relevant?

That is open source possibly, you know, for organization, depending on the organization you've been running, it could be important very, and yeah, hopefully this is, this is useful. So how does it fit, you know, felt this is, this is a sort of very high level view on what is the aspects of culture process in technology, how that feed into the agile developments, where the change is immense, everything flu and how security should be adjusting in the sense that we somehow need to keep up with these changes.

Somehow, this is, this is the sort of the stack of things that we've known. You know, if we say, for example, you opening up a firewall rule on ports, 80 or 4 43, and then there is an inspection taking place, but here's the thing. Can this firewall get into the payload, the actual messaging level of what's happening in the traffic? So it can give us understanding of what API security sh looks like, you know, is this something that this these technologies can do?

If not, then basically we need to ask ourselves, you know, what, what are the kind of those threats that we need to address? Do we have the right tools and technologies embracing new technologies?

I, I feel this there's the loads of new, new vendors out there, which are very relevant into, in the space of application security in particular DevSecOps, but being able to cover end-to-end process and integrate and automate the tools is, is, is very important. So basically big guns in certain areas will not save you. I think it's integration and compatibility is very important. I think there's, this is, this is everything I sort of nicked this from, from actually kind of my guys who, who are delivering some piece of work to ITV and ITV produced this show how to be a millionaire.

So I thought this is gonna be the kind of a appropriate slide to finish off this presentation. Any questions?

Well, Thanks a lot. First Of all,