Rob Cuddy, Colin Bell, and Dragan Pleskonjic

Rob Cuddy

Rob Cuddy: 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 going to 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. I'm Rob Cuddy, an application security evangelist for HCL.

Colin Bell

Colin Bell: Hey, I'm Colin Bell. I'm the AppScan CTO at HCL.

Dragan Pleskonjic

Dragan Pleskonjic: My name is Dragan Pleskonjic, and I'm senior director, application security at IGT.

Colin Bell

Colin Bell: So to start this, I thought what we would do is maybe focus from a continuous security perspective, and then maybe we can have a conversation around what this means to everyone. So myself and Rob have presented our model on continuous security for a while now, and just what you're looking at here is really what that manifests itself as. So 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 setting things up. Everything is sort of bolt on, and it really, to a certain degree, is the DevOps piece. But we want continuous security to be a lot more than just that. So we also recognize that as organizations build on that, they move into a phase which we call intensify, which is really where you're starting to educate people. You're starting to roll things out to security champions. You are starting to build on top of that and build out controls and whatever else. And then the final phase for us is around assurance, and assurance is making sure we're doing the right thing in the right way. And really, the focus of this discussion, I think, is going to be on the assurance side of things.

Rob Cuddy

Rob Cuddy: Right. The governance, the audit, and how things flow back and forward. 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 fit back in to help us drive security throughout. So really like how this just kind of feeds through onto itself and continues to build improvement. So we know, Colin, when you and I talk about this a bit, we talk a lot about the importance of governance and what that looks like. So when we hear that, what do you think it looks like for security governance fit into a software development model? What does a good security governance model look like?

Colin Bell

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

Dragan Pleskonjic

Dragan Pleskonjic: I believe that's an essential thing in big organizations, but probably in all organizations. Governance means that you are 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 organizations have adopted agile processes. And agile process means bi-weekly sprints, and it's very fast, and it seems that security and agile process to be in conflict in some degree. And big question here is how to make security to be part of agile process. Mm-hmm. And I see it from real life that software development teams are pressed very hard by business, and business is 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. And in that rush, security-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 governance is, from another side and perspective, often a much slower discipline, and needs and wants stability. So philosophical view will be that they are opposing each other, and you need to find a trade-off between these two. And there is so-called software security assurance program, which I was introducing with my teams, which tries to put all things or these three things on the same level. And one thing that is very often neglected in some organizations, I have seen those, is they don't have asset inventory. When I say asset inventory in terms of software security, I mean lists of applications, modules, components, whatever, product solutions. And that list need to have not just names of applications and components and modules, but also who own what. Yeah. Who personally own it or which function. You need to know where source code is stored, where are build systems, which programming languages, which clients you have deployed that solution to, and what you charge for those specific clients. Right. And 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 see what the business impact is. You need to consolidate all of that information which falls within different tools, SAST, DAST, IAST, or GRC tools. So you need to feed this data within these tools so you can have some kind of central dashboard, which is very important usually for top management of companies because what they are interested in is one overall risk position of the company. So you need all of these details continually followed, continually audited, so you can know at every point what is going well and maybe what is not going so well, and fix it. And you need to fix that very quickly. You don't want vulnerable applications, products to go to production because it can really, as we talked, single security lapse can take you completely out of the business, and you don't want that to happen.

Rob Cuddy

Rob Cuddy: Right. Which I think leads right into the other key piece of this, which is the metrics that you're using to be able to notice those things. So as you're looking to continually improve and provide that assurance as you're going through 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, "This is something we now need to go address"?

Dragan Pleskonjic

Dragan Pleskonjic: So you can go different details and depth of metrics. From the, I think, top perspective, it's actually to define high-value targets, or HVTs, and to look into those and to pay closer attention to this. Some organization can have statistics like number of applications, number of modules, components, number of lines of code- Yeah ... per language, per different breakdowns. But in my opinion, the most important is number of findings and the breakdown of these findings per severity, critical, high, medium, low. And also, what are real vulnerabilities that you need to focus on? Because there are false positives in virtually most of tools today. So you don't want to spend time on something that is not exploitable or maybe is not a real issue or can be covered by other security mechanisms, but you want to focus on those. And apart from breakdown by severity, you probably will want to track times to remediate and how much your teams spend on remediation tasks, because it directly impacts the delivery times. And also, one very important area are types of vulnerabilities. So if you go just very short list of Top 10, you will see which ones you find more often. Mm-hmm. And maybe you will 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 the future in regard to that. For example, injection attacks or cross-site scripting or whatever. So that's, in my opinion, part of very important metrics that you need to track. Over time, situations and metrics change, so probably most organizations will be interested to know progress and to see their continual improvement, which is mandated by most of standards, but also it's very important to see where things are going good and how you fixed the challenges that you had. So that's something what- Yeah ... is interesting about trends.

Colin Bell

Colin Bell: Totally agree with you on the metrics side of things. There are a couple others which I see have emerged with other organizations. I think one of the key ones which often interests me is age of the vulnerability. It's often seen with lots of organizations where they find something, and it's maybe a low priority, and it remains a low priority, and it remains a low priority, and it remains a low priority, but it never actually gets fixed. Right. So, there's this concept that's sort of emerging that is, as something ages, 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, if we look at when we blow out our whole sort of model in continuous security, the key things for us are governance as a starting point to write the rules, and then security audit. And a security audit can be, for a lot of people, is penetration testing and things like that. But my proposition is that the challenge of security audit is to actually make sure that we're doing the things that we say we're doing in governance. So security audit is the controlling mechanism, which I guess your team is doing to a certain degree, Dragan. You're ensuring that you measure against the governance, I'm assuming, yeah?

Dragan Pleskonjic

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

Colin Bell

Colin Bell: And that's something that I've seen some more mature organizations start to adopt. And in relation to the model that we have in front of you here, there's a couple of other things, and one of the key ones that I think is really important is measuring how often an application gets tested in the lifecycle. If you're just doing a pen test of an application, is that enough? If you actually follow a full lifecycle, if you start with a threat 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 IAST during the testing phase and the penetration testing, you're hitting four or five different points in the lifecycle where you're testing that application. And therefore, if you know that you're doing that for a given application, you're 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 the SIEM. And this I think is something that, again, I think some organizations are starting to adopt. So, 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 it's only through having a big picture and having a very strong auditing team that you probably get to that level.

Rob Cuddy

Rob Cuddy: Yeah, and I think with the SIEM too, 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 as part of the development side? I think what's interesting here too, 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 a static scan here and another dynamic scan over here, and maybe you're doing some interactive testing somewhere. 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, drive better governance and verify providing that assurance of what we're trying to do as we move through. It's interesting too, right, when we talk about moving that through a process and governing well. I heard somebody say one time that if you're just doing approval, you're not really doing governance. And so I'm curious what you think about just where that line is between just having kind of a quality gate and an approval somewhere versus really having good governance.

Dragan Pleskonjic

Dragan Pleskonjic: I would again mention software security assurance program, which actually needs to be correlated with the software development lifecycle, 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 SAST or DAST. It starts actually every time when you plan to bring new product or even to bring new features to existing product or some change or fixing some issue which is present in current product. So starting with the security architecture requirements and architecture. Then with the detail design, threat modeling, because if you're doing SAST, you sometimes need to understand business logic and context and domain you work in. If that's financial software, for example, you need to understand that realm. And then after threat modeling, you go further with the static and dynamic testing, IAST, as well as RASP, and penetration testing or vulnerability assessment, et cetera. And also, you then monitor real environment with SIEM tools or whatever way you use. And very important things here is security orchestration, how you can orchestrate all of these things that you work on or test or monitor, so you can get very good information. What is going well, what maybe has some risk or threat or even incident, so you can return back and fix that early in maybe architecture or design or coding or whatever.

Rob Cuddy

Rob Cuddy: Yeah, I love the comment on architecture, because I think that infrastructure piece and the design piece around it, it tends to be a little bit of an afterthought, right? We tend to look at the code itself, the behavior itself, and pulling those things in. So, and then mentioning thinking about the architecture right up front, not thinking the earlier days of DevOps, right? We used to have this notion of environments being very different and what was going on in the developer desktop wouldn't mirror with production, and so they started doing the whole infrastructure as code. Security needs to be a part of that same discussion, thinking through how are we going to secure those assets and align what a developer's building in their environment with what's ultimately going to come out into production. So, I know that's something that's 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?

Dragan Pleskonjic

Dragan Pleskonjic: And work with development teams closely and tell them that you are helping and advising them and learning from them. Because if you're going in with policy, then it will not end up very well. So actually, work with software architects, solution architects, software development teams, program and product manager, whatever, as you'll see, stakeholders or participants of that process. You need to have your allies on that side. Usually in practice, in my life, I try to get some role called secure development champions. They're people that are part of those teams and that they help us to contact the right teams, and they have passion for our security, and we can talk to them, they can talk to us. And that's, I think, a tremendous advantage that you can have with teams because real life and real people can have all kinds of habits that sometimes you need to work on and to make that practically possible. So that's one set of things that needs to be done.

Colin Bell

Colin Bell: Building out security champions is not an easy thing. And 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 security champions? What are the right sort of people that should be part of that program?

Dragan Pleskonjic

Dragan Pleskonjic: In practical life, you're going to software development teams or product or project management, and you recognize which people kind of have some skills and a passion toward security. You need to recognize who of them is interested in it. If you're trying to name someone which is not passionate about security- It doesn't work ... the program will not go too far. So find someone who you feel that you understand with and who has passion toward that. And then work with that person or persons, and then tell them that person will work with you and maybe most organizations have some kind of management by objectives or annual goals or bonus programs or other ways of building excellence or recognition. So put those persons on that program, give them some reward for what they are doing. That's, I think, one of the important things.

Colin Bell

Colin Bell: Do you see a need to sort of bring them together? 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?

Dragan Pleskonjic

Dragan Pleskonjic: Yes, actually, we had practice of monthly meeting with the security champions from different teams, so they know each other, so they can share information. That's probably very important, I'd say, isn't it? Oh, absolutely. And this COVID situation is not good for us because social distancing and everything keeps us not traveling, not seeing in person, maybe have some events which will make that relations much better, people to know each other- Right ... other in person. But we have these, like calls and conference calls and cameras so we can work through that.

Rob Cuddy

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

Colin Bell

Colin Bell: Well, it's very short, and obviously we could talk about this for a lot longer. So if you want to continue that conversation, we'd be more than happy.

Dragan Pleskonjic

Dragan Pleskonjic: Sure. I wanted to say, we're doing some personal research with a group of scientists and industry professionals how to automate some processes like triage of findings and using machine learning and AI to remedy security vulnerabilities in source code. So maybe one topic in the future.

Rob Cuddy

Rob Cuddy: GoloD.ai, AI is artificial intelligence, G-O-L-O-D.

Dragan Pleskonjic

Dragan Pleskonjic: Exactly. You will find some things there.

Rob Cuddy

Rob Cuddy: All right. Excellent. With that, yep. With that, just enjoy the rest of the conference, and we'll see you there.