00:00:00

<silence>

00:00:12

So, hey everyone, thanks for joining us today. We're really excited to be part of this year's DevOps Enterprise Summit, and today we're gonna be talking to you about what it looks like to make it easier for people to do things right. So focusing in on measuring, governing and auditing security. Uh, I'm Rob Cudi, an application security evangelist for HCL.

00:00:32

Hey, uh, I'm Colin Bell. I'm, uh, AppScan, CTO at, at HCL. My

00:00:37

Name is, and I'm senior director of Application Security at idt.

00:00:43

So, to start this, I, I thought what we would do is maybe focus from a continuous security perspective, and then maybe we can have a, a conversation around what this means to everyone. So we, myself and Rob have presented, um, our model on continuous security for a while now. And, and just what you're looking at here is really what that manifests itself as. So we, we break it into three phases, and I know there are other models which do similar things, but to us there's a construction phase, which is really about, you know, setting things up. Everything is sort of bolt on, and it really, to a certain degree is, is the DevOps piece. Um, but we want continuous security to be a lot more than just just that. So we also recognize that as organizations sort of build on that, they move into a phase, which we call intensify, which is really where you're starting to educate people. Um, you are starting to roll things out to security champions. You're starting to build on top of that and build out controls and, and whatever else. And then the final phase for us is, is around assurance. And assurance is making sure we're doing the right thing in the right way. And, and really the, the focus of this discussion, I think is gonna be on the assurance side of things. Um, right. You know, the governance, the audit, and, and how things flow back and forward. Right?

00:02:07

Right, right. And the nice thing about it is that this fits exactly into the key paradigm with DevOps, where you want feedback that you can use to make better decisions. So this is about getting those other pieces around beyond just adding testing to a pipeline or figuring out ways to do scanning better or getting developers to run tests and those kinds of things. But it's really about using security throughout the pipeline and having pieces that, that fit back in to help us drive security throughout. So really like how this just kind of feeds through, uh, on, onto itself, um, and continues to build improvement. So we know, Colin, like when you and I talk about this a bit, we talk a lot about the importance of governance and what that looks like. Um, so when we hear that, what do you think it looks like for security, um, for having governance fit into a software development model? You know, what does a good security governance model look like?

00:03:06

I mean, I think in essence it's a, you know, governance comes from a lot of things. You know, it's important to decide who's in charge of the security program in the first place. You know, so if you've got, um, you know, a centralized point that controls the security, um, you know, that, that's an important element to, I think, to getting governance going. And you have to ensure that they have teeth as well. So there's no point having a, you know, a level of governance where, you know, the DevOps manager can decide, I'm not gonna really do that, you know, because it doesn't suit me. Um, and then I think the final thing is, I think there's also, you need to have a willingness to bring in experts and, and thought leaders and, and try and learn and develop that program. So governance can be a whole lot of things, but, but ultimately setting out the rules that, that we want to have from our applications. I in Dragon In, in your world, like how is, how is governances generally done in a large organization like yours? Are you, do you see that as a, a central opportunity or is it something that is a little bit more distributed?

00:04:15

I believe that's in, in a session thing, uh, and, uh, in big organization, but probably in all organizations, governance means that you're on top of things and that you can manage it continuously. So things change constantly and sometimes they change very quickly. And at present time, when we talk about software development, most of organization adopted agile process, uh, and agile process means, uh, biweekly sprint, <inaudible>, and it's very fast. And it seems that security and agile process could be in conflict in some degree. And big question here is how to make security to be part of agile process. Mm-Hmm. <affirmative> and I see from real life that software development teams are pressed very hard by business, uh, and businesses in rush to deliver on time and in quality. And the market requires new features and functions of software, which will be extra cool, so to speak, and which market will adopt and they can get advantage over their competition.

00:05:39

And in that rush, security related, related things can be neglected if there is no strict governance. So strict governance means you are still in that fast process in control and, uh, is from another side and perspective, often much slower the discipline and, uh, uh, needs and wants stability. So philosophical view will be that they are opposing each other, and you need to find, kind of trade off between these two. And there is, so-called software security assurance program, which I was introducing with my teams, which tries to kind of, uh, put all things or these three things on same. And one thing that is very often neglected in some organization I have seen those, is they don't have asset inventory. When I say asset inventory in terms of software security, I mean list of applications, modules, components, whatever, products, solutions, and that list need to have not just names of applications and co and modules, but also who own what, who personally, or which function.

00:07:06

You need to know where source course stored, where systems, which programming languages, which clients you have deployed that solution to, and what you changed for that specific clients. Right? And all overall, you need to have very clear picture about risk posture, about your risk position. That means you need to have very good risk assessment and management process. You need to, uh, see what is business impact. You need to, uh, consolidate all of that information, which flow between different tools, dust, uh, I and all, uh, secure GRC tools. So you need to feed this data between these tools so you can have some kind of central dashboard, which is very important for, usually for top management of companies because they, what they are interested in is one overall risk position of company. So you need all of these details, uh, continually followed, continually audited, so you can know at every point what is going well and maybe what is not going so well to fix that. And you need to fix that very quickly. You don't want, uh, vulnerable applications, products to go to, to production because it can really, as we talked, single security labs can take you completely outta the business and you don't want that to happen.

00:08:43

Right. Which I think leads right into the, uh, the other key piece of this, which is the metrics that you're using to kind of be able to notice those things. So as you're looking to continually improve and provide that assurance as you're going through, uh, the different stages in the pipeline, I'm curious, what are some of the key things that you're looking for that let you know that things are going well versus, you know, this this is something we now need to go address.

00:09:12

So go, you can go different, uh, details and depth of metrics from the, I think top perspective, it's actually to define high value targets, uh, or hvt. And to look into those and to pay closer attention to this, some organization can, uh, have statistics like number of applications, number, number of modules, components, number of lines of code, yeah. Uh, per language, per different breakdowns. But in my opinion, uh, the most important is, uh, number of findings and breakdown of these findings per severity, critical, high, medium, low. And also, uh, what are real vulnerabilities that you need to focus on? Because, you know, uh, there are false positives in virtually most of tools today. So you don't spend time on something that won't be used or maybe is not real issue or can be covered by other security mechanism, but you wanna focus on those. And apart of, uh, breakdown by severity, you probably will want to track times to remediate and how much your teams spend on remediation, uh, tasks, uh, because it directly impacts the delivery times. And also one very important area, uh, types of vulnerabilities. So if you go just very, uh, short list of, of top 10, you'll see which ones you find more often Mm-Hmm. And maybe you'll want to give some special attention to those and maybe to work with the teams to give them additional education about that, to help them to be better in future in regard to that, for example, injection.

00:11:23

So that's, in my opinion, uh, part of a very important metrics that you need to track during the time situa situation and metrics change. So probably most of organization will be interested in to know progress, to see, uh, uh, the continual improvement, uh, is, which is mandated by most of standards, but also it's very important to see where things are going good, and how do you kind of fix the challenges that you had. So that's something what yeah. Is interesting about trends.

00:12:04

Totally agree with you on the, on the, on the metrics side of things. I mean, there are a couple of, a couple others which I, I see have, have emerged with other organizations. I think one, one of the key ones, which often interests me is age of the vulnerability. It's often seen with, um, see with lots of organizations where they, you know, they find something and they don't, it's maybe a low priority and then, and they, it, it remains a low priority, it remains a low priority, and it remains a low priority, but never actually gets fixed. Right? Um, so, you know, there's this concept that's sort of emerging that is as something ages, it's, it moves from maybe being a low priority to a medium to being a high risk because it's been there for so long. In essence, you know, if we look at, you know, when we blow out our, our whole sort of model and continuous security, you know, the, the key things for us are governance as, as a starting point to write the rules and then security audit. Now, security audit can be for a lot of people is, is pen testing and things like that. But, and I, uh, I'm proposition that the, the challenge of security audit is to actually make sure that we're doing the things that we say we're doing in, in governance. Um, so, so security audit I is, is the controlling mechanism, which I guess your team is, is doing to a certainty dragging your, in, ensuring that you measure against the governance? I, I, I'm assuming. Yeah.

00:13:31

Yes, exactly. So, uh, usually we call the process software security or program software security assurance or SSA, and actually that's complete program, which has lot of things inside some, I would say governance things and some, uh, application security practicing things. So you need to set up processes, procedures, guidance, and, uh, then audit can go against it. So you can compare what you said and how you followed it.

00:14:07

And that's something that I've, I've seen, you know, some more mature organizations start to adopt. And, you know, in, in relation to the model that that, that we have in front of you here, you know, the, there's a couple of other things. One of, one of the key ones that, that I think is really important is, is measuring how often an application gets tested in the lifecycle. You know, if you're just doing a pen test of an application, is that enough? You know, if, if you actually follow a full lifecycle, if you start with a fret model and you start with doing some developer testing, perhaps in the IDE and move through to doing some automation of static analysis and dynamic analysis, and perhaps even doing some ias during the testing phase and the pen testing, you are hitting four or five different points in the lifecycle where you are testing that application.

00:14:58

And therefore, if you, if you know that you are doing that for a given application, you are giving yourself the best chance to find the vulnerabilities that are potentially out there. And the other angle on this as well is to also leverage the information that sits out in this, in the sim. Um, and, and this I think is, is something that, again, I think some organizations are starting to adopt. So, you know, if, if, if I'm seeing an application that's being attacked on a regular basis, so maybe my most attacked URIs become an important factor in how I address that within the applications themselves, or how many attacks are we getting against known vulnerabilities that are happening out there? And, and it's only through having a big picture and having a, a very strong auditing team that, that you, you probably get to that, that level.

00:15:52

Yeah. And I think with the sim too, you know, is that information filtering itself back into your threat modeling so that your threat model continues to evolve as you move through the lifecycle, you learn a little bit more about where you're vulnerable. And then are we accounting for that, you know, as part of the, the development side. I think what's interesting here too, that, that you kind of implied when we were talking about the testing, but testing throughout the lifecycle, but being able to kind of correlate that information together and use it more holistically so it's not just, uh, a static scan here and another, a dynamic scan over here, and maybe you're doing some interactive testing somewhere. Um, but really being able to bring those things together and provide a better picture of risk that can then influence what you're doing for some of these other areas, you know, drive better governance and, and verify providing that assurance of, of what we're trying to do, um, as we move through. You know, it's interesting too, right, when we, when we talk about moving that through a process and governing, well, um, I heard somebody say one time that, right, if you, if you're just doing approval, you're not really doing governance. And so I'm curious what you think about, you know, just where, where that line is between just having kind of a, a quality gate and an approval somewhere versus really having good governance.

00:17:17

Uh, I would again mention Social Security security assurance program, which actually needs to be correlated with the software development life site, which is technical process. And that means that there are number of points where you get touch points between these two processes and programs. So software security assurance starts not just with SaaS or dust, it starts actually, uh, every time when you, uh, plan to bring new product or even to bring, uh, new features to existing product or some, uh, change or, or, or fixing some issue, which is, uh, present in current product. So starting with, uh, security, uh, architecture requirements and architecture, then with the detailed design threat modeling, because if you're doing, you can sometime need to understand business logic and context and domain you work in. If that's financial software for, for example, you need to understand that rail. And then after threat modeling, you go farther, uh, with the static and dynamic, uh, testing highest as well as ra pain penetration testing or vulnerability assessment, et cetera. Mm-Hmm. And also you then monitor a real environment with simple or whatever way you use. And very important things here is, uh, security orchestration, how you can orchestrate all of these, uh, things that you work on or monitor, test or monitor so you can get very good, uh, uh, information. What is going well, what is maybe have some risk or threat or even incident so you can return back and fix that early in, in maybe architecture or design or coding or whatever.

00:19:20

Yeah. I love the, the comment on architecture. 'cause I think that infrastructure piece and the design piece around it is, is tends to be a little bit of an afterthought, right? We, we tend to look, you know, at the code itself, the behavior itself, um, and pulling those things in. So, and you know, mentioning thinking about the architecture right up front, you know, not, um, think in the earlier days of DevOps, right? We used to have this, this notion of environments being very different and, you know, what was going on in the developer desktop wouldn't mirror with production. And so they started doing the whole infrastructure as code. Um, security needs to be a part of that same discussion, you know, thinking through how are we gonna secure those assets and, and align what a developer's building in their environment with what's ultimately gonna come out into production. So I know that's something that's, um, been really important as part of the discussion that we've had. So how do we get some of these things working a little bit better together to provide that kind of assurance that we're looking for

00:20:24

And market development teams, uh, closely and tell them that you are helping and advising them and learning from them. Uh, because if you're gonna kind of, uh, policy, then, then it'll not end up very well. So actually, uh, work with software architect solution architects, uh, software development teams, programing, product manager, whatever the, uh, s uh, stakeholders or participants of that process, you need to have your kind of, uh, on that side. Uh, usually in practice, uh, in my life, I try to get some, uh, role called Secure Development Champions, the people that are part of those teams and that, uh, they help us to contact, uh, right teams and, uh, they have passion of our security and we can talk to them, they can talk to us. And that's, I think, tremendous, uh, advantage that you can have with teams because, uh, real life and real people can have all that kind of, uh, the habits that sometime you need to, to work on and to make that practically possible. So there's one set of things that needs to be done.

00:21:54

Building out security champions is not an easy thing. Um, you know, and I, I know that some organizations struggle to work out how to do that, but do you have any sort of tips on how best to go about building out like security champions? What, what are the right sort of people that should be part of that program?

00:22:13

Uh, in practical life? You're going to sort of development teams on product, product management, and you'll recognize which people kind have, uh, some skills and, uh, passion or security. You need to recognize who of them is interested in. If you're trying to name someone which is not passionate about security,

00:22:39

It doesn't

00:22:40

To far. So find someone who you feel that you understand, win and have passion over that, and then work with that person or persons and then tell them that, uh, uh, that person will work with you. And maybe most of organizations have some kind of, uh, management by objectives or annual goals or bonus programs or other base of building excellence or, or recognition. So put that pass on, so on, on that program, give them some, uh, reward for what they're doing. That's, that's I think one of important things.

00:23:22

Do you see a need to sort of bring them together? Um, so you have security champions on different teams. Would you bring them together as a center of excellence and sort of let them share each other's experiences? Is that an important part of this?

00:23:36

Yes, actually we had practice of, uh, any of monthly meeting with the security champions from different teams so they know each other so they can, uh, have information. That's

00:23:47

Probably very important, I'd say. Oh, absolutely.

00:23:50

And, uh, this, this common situation is not good for us because, uh, social distancing and everything, uh, keeps us not traveling, not seeing in person, maybe have some events which will make, uh, that relations much, uh, better people to know each other, uh, right. Other in person. So, but we have this like calls and, uh, confidence calls and cameras, so we can work hard through that.

00:24:20

With that, guys, thank you so much just for the conversation today. We hope you've enjoyed us, uh, talking about, you know, doing governance and auditing and measuring better. So make it easier for people to do the right things. Uh, we are certainly available to, we reached out to you to answer questions or any other thoughts if you wanna continue the conversation. But, uh, thanks for having us today, Colin and Dragon, any closing thoughts?

00:24:43

But it's very short and obviously we, we could talk about this for a lot longer, so if you wanna continue that conversation, we'd be more than happy. You know,

00:24:52

Uh, I wanted to say doing some personal research with group of scientists in industry professionals, how to automate some processes like, uh, triage of, uh, findings and, uh, using machine learning and AI to remedy, uh, security vulnerabilities in source code. So maybe one topic in future, uh, ai, AI is artificial intelligence. You'll find some things there

00:25:22

That just enjoy the rest of the conference and we'll see you there.