Embracing Cybersecurity By Design – Shanni Prutchi, Bishop Fox

This is Textron TV. Hey guys. Thanks the throw we're here with Janine Pucci who's a consultant with Bishop Fox and they do all kinds of interesting things around security design.

And the question is is what exactly are the issues of people around into these days because as we all know luck is the residue of good design as they say, so maybe you might want to start out with a plan Shani welcome the show Thank you very much for having me on. So what exactly are the issues that people are running into with design because so much of what we do is reactive. I'm not sure we have a great plan going in.

Maybe just walk us through. What are you seeing that people do that make you shake your head? Yeah, so we've seen over the past few years that we have this shift left ideology that's starting to enter the information security the cyber security space even though it's been around within the application design Community for maybe two decades now.

um and what we're really finding is that by only worrying about security concerns. Later after the product's been designed while you know, everything's going through implementation. You really find structural issues.

So for example, you may find one case of cross-site scripting or SQL injections that is actually indicative of SQL injection throughout the entire application and such that if you mitigate that one case, you're not preventing it from popping up again, if like they you expand your site all your new endpoints that talk to the same database may have the same instance because you haven't addressed it if the root of the problem and this is become such a concern that a wasp actually added it to their 2021 top 10 vulnerabilities. They created an entire new category of insecure design because we really see that when security anti patterns are in place of that is the contrast what we would consider secure design patterns such as the fence and depth which you know, we all know about these are patterns that get that get touted when we talk about the basics of security when we have these anti-patterns that are in place these really become A structural issue that can end up as you know, all the common vulnerabilities were used to seeing like authentication issues and stuff like that. And we you know, if I keep looking at that list that you described there, I would shake my head.

It's the same ones you're in a year and we seem to be repeating the same vulnerabilities over and over again. So what is the fundamental problem? Is it just the way we didn't teach the developers the fundamentals of security or is there something else going on in the environment?

I think really the basis of it is that we're only bringing Security in after the design phase. Some organizations are getting a lot better. And once the basic design phase is complete.

They'll pass off the design to the security team to do a review but even then That's starting to late because at that point you are the security team is still infringing upon the developers idea and there's already going to be pushed back really our argument is that from the beginning the security team should be involved with the developers and saying here are the problem Point. Here's where data is flowing into different components and not data may or may not be trusted. So let's say if I have a user sending data from the internet and now it's hitting the application.

That data from the internet should be untrusted. I don't know what's in it and when it's coming into my application that's entering a trusted area where I'm running things in a you know, an escalated permissions because it's running within the application context. Knowing that I should be able to say.

Okay. Here's the data that's coming in. What's the data?

I'm expecting and where further in the application will this impact is this going to a database? If so, I need to worry about SQL injection. If not, you know, that's not a huge concern but you might need to not only identify where are you entering these trust zones, but also what is the later context and based on that later context you can then decide whether the appropriate control.

Now, I don't think it's necessarily a flaw in the part of the developers right? Because even if you have secure design, the implementation can be insecure and if you're implementation isn't secured, you can still find a host of security vulnerabilities that you can get through and as long as the developers have secure coding guidelines, I don't think that's necessarily an issue on their part. It's really when the security team can get involved.

So how far will we ship left? Because can the developers do they have the expertise required or do we need to kind of maybe lean left? And we need to put more guardrails in the systems that prevent them from making mistakes in the first place and that's kind of the processor.

Is it kind of like this overarching thing that spans all the way from the developer to the cicd environment and we just have to figure this whole thing out on and basis. I don't think it's necessarily about putting guardrails in place. I think what it means is having a security champion who during the design process fits in with the developers.

It doesn't need to be security taking over the development process, right? Because that's not what security does. They're not the developers.

They're not the designers. Really what we're hoping for is that there starts to be a security Champion a delegate of the security team who sits in during the initial design and has that conversation with the developers and over time the developers can start developing those skills themselves. So really the skills we're talking about our threat modeling is identifying where you have those trust boundaries and saying, okay.

Well what can go wrong when things cross the trust boundary and how can we prevent it? Really that is the most basic aspect that we're looking at because by doing that you can Also address and prevent using those anti-patterns. Do you think it as we go along that we will see the emergence of something that looks like a security engineer.

We have site reliability engineers and I'm wondering if we might see somebody who is this specialist who works with developers to ensure Security in the same way that sres ensure reliability. I certainly hope so to be quite honest because we see you know, like you said the vulnerabilities in the top 10 keep on repeating they keep on coming up and even if they're not exactly the same right? You can't say the crust type scripting and SQL injection is the same but at the end of the day they come back to the same anti-pattern and they come back to this anti-pattern of allowing data to become a code and that anti pattern is inherent in the design of the application.

And so I really hope that there does start to be either, you know, unofficial position or even an unofficial alliance between the security and design teams within an organization to start that from the very beginning because we do see like Security architecture professionals within huge organizations, right? They have dedicated security Engineers who review the design of application I would just argue that that may happen a little bit too late in the process because at that point the design already exists and if you're going back with any with any proposed changes there may already be pushed back. It's like well this is counter to how we wanted it to work or this would require complete overhaul of functionality.

Do you think as we kind of move down these whole conversation and that the cultural divide is just too big between security and developers to bridge because it's been going on forever developers think of security is something to avoid and Enron and the security people think of developers as the root cause of all their problems and how do we kind of get all these people together in a way that you know, they don't wind up killing each other. To be quite honest, I think that most of developers these days understand the role of security. I think that society as a whole in the past even five years has had a huge shift in how they be security, you know, even if you're not in the community you hear about all of the breaches, you know, I get family members who are not in the Tech Community asking me questions about it and society as a whole has a lot greater understanding of cybersecurity and I'd argue that as an extension of that developers are aware of it and developers these days, I think I have to have that view and I think they also feel it right because when there's an issue the developers are the ones who have to fix it.

They're the ones who get told. Okay, like this is this is the problem and this is what caused the vulnerability you need to go fix it now, so I think it's also in their best interest. to start doing secure design because it means that when there's an issue to mitigate.

you know, they can be like oh They're you know, maybe we if there is an issue to mitigate. They can fix it the most space or they're able to avoid having to make all of those changes because it is a less sorry because there's a less chance of there being a repeating vulnerability. In the land of application development.

We have this notion of design thinking it's kind of a way of getting people the bill applications that are a little easier to use because they have some empathy for the developer or the actual end user. Is that kind of what we're looking at here is this kind of a design thinking approach to security where we're going to sit down and say look there are some fundamentals here that you need to master and you need to just make sure you're walking through these things, but it's not rocket science. Absolutely.

I think that there are some really basic considerations that need to be made and I really think that that's going to be sorry. I think that's really going to become part of the development process that these are the things that we need to keep in mind. Similar to a checklist but less rigid because these are very general idea.

And I will say that just like, you know you have in design thinking that you want to make things easy on the user. We have a similar Concept in patterns and anti-patterns that we do not want to present any barrier in the security of an application. That is so difficult.

The user would find a way around it. and I think that's also something that developers need to keep keep in the back of their minds that if You take the security, you know way past where it needs to be in an application users are either going to not use. Your your service or they'll find a way around the security in your application.

So whether it's you know having MSA or you know, requiring some very extreme password. Rules they're going to find a way around it and that's going to diminish the security of your application. The security works really hard to build in.

Hmm. What is your best advice to somebody who sits up higher level in the food chain of an IT organization and has this development team on the one side and the security team on the other that kind of bring it all together and reach some level of cohesion in these groups because I think a lot of them look at it and they're a little frustrated because everybody speaks their own language and nobody knows exactly what the other one is talking about. So, how do I have this moment to get around the Tower of Babel?

I think it really looks like integrating someone from the security team Within. within the development team is have that person from security team or that select group of people. If you have a whole bunch of applications being developed.

You don't want to just stress one person out with having to handle everything so really it depends on the scale of the operation but really have that person become the dedicated developer security. Communication and they for the immerse themselves in the world of the developers. When we do a threat modeling engagement.

I spent time reviewing the architecture documentation. I meet with the application developers and ask them all of the questions I may have. And for me I'm coming in with no knowledge of what it looks like on the back end.

I know very little and in a few hours I come up to Pace to understand, you know, where I'm at. If you're within an organization, you can do that so much more easily and with a lot greater flexibility because you can just sit in on those developer meetings. You can ask basic questions.

You have a lot more access to formal or even informal documentation that exists and you can also start becoming part of that decision process. So I think it's really about taking a single person or a small group of a few people and really integrating them into the development team instead of you know forcing to development team to get along with security. All right.

Well, hopefully from your lips to whatever his ears you believe in that will hopefully come the past Johnny. Thanks for being on the show and sharing your knowledge and incense. All right back to you in the studio.