What is the Problem?

00:00

just a sec out Fundamentals lesson 1.2 We're just gonna kind of talk about what's the problem here. So just need to define it as a more about Like I said then. Just automated tools just kind of look at it from a whole perspective,

00:16

so that objectives would describe the need for a cultural change. That's really what it's gonna take is to

00:21

to

00:22

to just again not just tools, not just processes, but the whole organization getting along with it, agree. And we need to integrate security into our dev up cycle.

00:33

And so we'll look at some of the security challenges and also discussed the need for automated tools because I keep saying we don't need automated tools or it's not the only solution, but we definitely need them

00:43

one.

00:44

So the first is cultural change, he said. This is a saw. This image and I was pretty funny is from PHS Lock like got it from his Twitter account,

00:52

um, so that the developers have their own culture culture. They have their own demands,

00:57

so it requires a change in executive by and so if you're gonna be able to cut across the development side the production side the, uh,

01:07

operations. You're going to need somebody an executive at the top that can instruct all of these leaders of across the organization say, here's the policy. This is what we're doing. This is why we're going to need it to do it.

01:18

So from the perspective of the developers, they have tight coding schedule, especially when they're moving to agile in our new every two weeks doing drops,

01:26

they have, ah, have a tight schedule and try to come in there and say we're gonna do cigarette. We need to the security reviews. These tests are gonna take multiple weeks. Just not gonna work out. So we have to be realistic.

01:38

Um, yeah, like so they they have limited testing schedule available.

01:42

Um, there's also probably limited contractual enforcement.

01:47

They may just say, you know, bugs think something like that. So we're gonna need some teeth to the to the contracts to say why you need Teoh integrate security and write more secure code.

01:59

And part of the issue to is the testing that that's done on these systems are not designed for security and really not designed to fail there. They're designed for specific business checks on the order of the four,

02:12

the service or the whatever component of the application to make sure it meets a requirement. So security has to write their own testing,

02:21

and the operational culture has their own demand there.

02:24

Their job is keep it running. We don't have time for you to say we don't have time for me to get a lot of push backs, especially when you want to start putting in security control that can possibly affect the up time.

02:38

And so security has their own challenges.

02:40

The special there's were if removing toe agile development, I mentioned, it's difficult to

02:47

thoroughly review with, from a security perspective, an application on a tight schedule, an agile development, especially if they don't leave a lot of time for the testing.

02:59

And as he moved to continuous integration, continuous delivery the C I. C D, which will see a lot

03:04

now is justice continuous

03:07

production of small bits of code, especially his micro services. Anything like that.

03:13

And there's a complete automated pipeline. Ah, developer commits code. It instantly goes to this pipeline and can get pushed out with almost no human interaction. So we have to. You have to really be able to select your security controls correctly and that can that can fit into that tight schedule.

03:29

We're really gonna need some automation, they mentioned can't slow down the process and have to integrate into the existing pipeline. We can't suggest some tools that don't fit and just say, Well, just redo everything because this is what we need for security. It's not gonna work.

03:43

And from the security perspective, if you're auditing it, you need to have some coding experience. Some knowledge, what the amount of experience you need. It's really dependent on how in depth the application is or how in depth the tools you're using because you needed to be able to take these tools,

04:00

summarize them to actual risk that are presented to the executives or even the developers will be able to speak the same language is them

04:08

and to produce,

04:09

Thies said. Consumable reports You can't just run it and hand over and say, Here you go Here's just 1000 page report. Please fix it. It's just not gonna work out.

04:19

So one of these questions just for you just to kind of get you to think before we start

04:24

going into far are big Just taking. What I'm saying is, why is def sec up so difficult?

04:33

So it kind of mentioned this already. Do the auditors understand Cody?

04:38

Do they understand the operation sided? Can they produce?

04:42

I said risks or these vulnerabilities that really makes sense or the mitigation of them. Are they actually gonna work in a production system? Where are they? Do they are they other? Worse than

04:51

the actual vulnerability that this mitigation you're requesting

04:56

and for the developers even understand security. They probably have some security knowledge a little bit, but it's probably not gonna be as robust as we're expecting And the metrics in the requirements you put in place.

05:08

So they're going to really need to understand. They're gonna need to have some tools to help them really need. They're gonna need to understand the process. And they're gonna need again from the executive down through the organization to say we are doing this no longer. We're just going to say

05:23

we're gonna live with this done. We'll just push it off for another day.

05:29

So I mentioned we need really need automated tools because it's

05:31

they're great for large volumes of code special. When you're doing applications with hundreds of thousands millions of lines of code, you just You can't do it by manually going through the code,

05:43

um,

05:44

so you can manually review and might be good into the spot. Check in certain places it, or if you start seeing code, that's that's coming up with a lot of vulnerabilities. It's very intensive, but you may identify additional findings because the automated tools look for patterns. But they may not be able to go and as depth is

06:02

as a human obviously would be able to.

06:05

The problem is there so many languages. There's java dot net python ph b No, even on the

06:13

on the you I side, there's JavaScript, html five cascading style sheets. With all these languages that you have to understand, you have to know and be able to look at it from really a security perspective. So it's It's really difficult for one person or even a couple people that to know these tools, really, why we need these automated tool to have this understanding built into them.

06:33

The problem is with a lot of these automate tools, they may have some issues that should go hitting an A p I or in these very dynamic sites where there's not a lot of content coming back. Or maybe they're tuned specifically for Web page,

06:46

they may not do as well is just just straight on. If you get Jason XML back, things like that, they can look at the patterns of the way it's transferred and data that send in and out. But they may not work as well,

07:00

so let's just do a quick quiz here.

07:03

What is the most secure language? Is it Java? Is it PHP or is it dot net

07:12

Does the course was a trick question. Insecure code could be written in any language. So it's really dependent on

07:18

who created the code and where it's deployed and any third library that that are brought in. We'll see this as we go along through the

07:27

the course.

07:30

In this model, we learned about