DevSecOps is a more than just getting security testing integrated into a pipeline and using the results to influence flow. Real success with DevSecOps comes when you are able to identify and measure critical aspects of your risks as well as your security controls and functions. It means that you have governance that enables and encourages the right behaviors – not just inhibits bad ones and you have an audit function that can measure this success. It also means you are able to incorporate and include security related information from all parts of the SDLC – including threat, design, testing and at runtime. Many places have achieved higher degrees of automation and education within their DevSecOps initiatives, however this needs to be an improving and continuous cycle. Taking it to the next level involves intensify these efforts with accurate threat analysis, secure design, measuring, governance and audit. Join us as we share insights on how organizations are moving beyond DevSecOps and more towards real Continuous Security.
Senior Director of Application Security, IGT
CTO AppScan, HCL Software
Application Security Evangelist, HCL Software
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 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, uh, I'm Rob Cuddy and application security evangelists for HCL.
Hey, yeah, I'm Colin bell. I'm a AppScan CTO and it takes shell to stop 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 we, myself enrollment presented, um, our model on continuous security for a while now. And it just, what you're looking at here is really what that manifests itself as 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, then everything is sort of bolt on and it's really to a certain degree is it's the dev ops 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 theme, move into a phase, we call intensify, which is really where you're starting to educate people. Um, you're starting to roll things out to security champions. You're starting to build on top of that and build up 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, and really the focus of this discussion I think, is going to be on the assurance side of things. Um, you know, the governance, the audit and how things flow back and forth. Right,
Right, right. And the nice thing about it is that this fits exactly into the key paradigm with dev ops, 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 on, onto itself, um, and continues to build improvement. So we know Collin, 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 is a good security governance model?
I mean, I think in essence, it's, 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. 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, you know, a level of governance where, you know, the dev ops manager can decide that I'm not going to really do that, you know, cause 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 thought leaders and try and learn and develop that program. So governance can be a whole lot of things, but, but ultimately it's setting out the rules that we want to have from our applications, like in your world. Like how is, how has governments 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?
I believe that's the session thing and a 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 returns very quickly. And at the present time, when we talk about software development, most of organization adopted a jar process. Uh, and I drove process means biweekly sprints and it's very fast and it seems that security and the driving process be in conflict in some degree. And the question here is how to make security, to be part of the giant. And, uh, uh, I see it from real life that software development teams are pressed very hard by business and business is in the rush to deliver on time and in probably the quality and the market requires new features and functions of software, which will be extra cool, so to speak and which markets will adopt and they can get advantage over their competition.
And in that rash, security related unrelated things can be neglected if there is no fifth gardens. So through governance means you are still in that fast process in control. And the Godness is from another site in perspective, often mass for that discipline and, uh, uh, needs and wants stability. So philosophical view will be that they are opposing each other and you need to find them kind of trade off between these two and the so-called softer security. I should've up. We try most introducing with my themes, which tries to kind of, uh, put all things or these ratings on same. And one thing that is very often neglected in some organizations have seen those is they don't have asset inventory. When I say, ask if inventory in terms of software security, I mean, at least so far applications, modules, components, whatever products, socials, and that at least need to have not just main obligations and competence and modules, but also who own what, who , or which function you need to know, very soft core store where I build systems, which programming languages, which clients you have deployed that solution to and what you transfer that specific clients, right?
And at all, 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 is business impact. You need to, uh, cross all of that information, which fall between different tools, SAS, the dusk ism, or secure GRC tools. So you need to feed this data it's in the store. 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 forward, continually audited. So you can know at every point what is going well and maybe what is not going so well. And you need to fix that very quickly. You don't want the vulnerable applications products to go to the production because it can really, as we talked, single security logs can take you completely out of the business and you don't want that.
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 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 is something we now need to go address.
You can go different details and depth of metrics from the, I think top perspective, it's sexually predefined, high-value targets or HTTPS, and talking to those and to pay closer attention to this. Some organization can have statistics, like number of applications, the number of modules, components, number of lines of court better, which better different to break down. But in my opinion, uh, the most important piece, uh, number of findings and break down of these findings, spare severity, critical high, medium, low, and also, uh, what a real vulnerability is that you need to focus on because you know, the positives team with totally most of tools today. So you don't want to spend time on something that won't be used, or maybe it's not really issue or can be common and biotic other security reasons, but you want to focus on goals and a part of a breakdown by severity.
You probably will want to PreK tanks put energy and how much your teams spent one of the remediation, uh, tasks, because it directly impacts the delivery times. And also renovating bottom barrier are types of vulnerabilities. So if you go dressed very short lists of, of top 10, you will see which ones you will find more often. 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 future. In regard to that, for example, injection episode 15 one. So that's, in my opinion, uh, Octo for very important metrics that you need to track during the time situations, the situation and metrics change. So probably most of organizations will be interested in to know progress to see, uh, uh, continue continual improvement, which is my invasion by most of the standards from that. Also, it's very important to see where things are going good and how you kind of faced challenges that you had. So that's something think about trends,
Totally agree with you on the, on the, on the metrics side of things. I mean, there are a couple of a couple of others, which I, I see have, have a merged 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, let's 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 remains a low priority and it remains a lower priority and it remains low priority, but it 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, and 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, uh, 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 pen testing and things like that.
But, and I 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 governance. Um, so-so security audit is, is the controlling mechanism, which I guess your team is, is doing to certainly be dragging your ensuring that you've measured against the government's. Like I, um, I'm assuming, you know,
Yes, it's not console. Uh, usually we call the process software security or product photo security assurance, as I say, initially, that's complete program, which has lot of things inside some, uh, I would say governance scenes and some, uh, application security practice team, the beings. So you need to set up processes, procedures, guidance, and the audit can go against it. So you can compare what you set and how you follow it.
And that's something that I've seen, you know, some of the 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, that 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 life cycle. You know, if you're just doing a pen test of an application, is that enough? You know, if you actually follow a full life cycle, if you start with a fret model and you start with doing some developer testing, perhaps in the ID and move through to doing some automation of static analysis and dynamic analysis, and perhaps even doing some IIS during the testing phase and the pen testing, you were hitting four or five different points in the life cycle where you're testing that application.
And therefore, if you, 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 this, in the SIM. Um, and, and this, I think 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, maybe my most attacked your eyes become an important factor in how I address that within the applications themselves. Well, how many attacks are we getting against no one vulnerabilities that are happening out there. And it's only through having a big picture and having a very strong, older the team that, that you probably get to that level.
Yeah. And I think with the SIM too, you know, is that information filtering itself back in to your threat modeling so that your threat model continues to evolve as you move through the life cycle, 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 to that, that you kind of implied when we were talking about the testing, but testing throughout the life cycle, 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. 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 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 quality gate and an approval somewhere versus really having good governance.
Uh, I would go again, you mentioned that sulfur security assurance program, which actually needs to be correlated with the software development place site, which is very difficult process. And that means that a number of points where you get touch points between these two processes and programs. So for security assurance, that's not just with software, it starts sexually, uh, every time when you, uh, plan to bring the new product or even to bring new features to existing product or some, uh, trends or, or, or fixing some issue she's present in current product. So starting with the security, uh, architectural requirements and architecture, then with the detailed design threat modeling, because if you're getting sauce, you can sometime need to understand business logic and complex. In domain, you work in just financial software. For example, you need to understand that. And then after threat modeling, you go farther, uh, with static and dynamic testing, ISA as well as Raspin penetration testing or vulnerability assessment, et cetera. And also you then monitor a real environment. It's simple. So whatever the value use and very important things here is a security orchestration, how you can orchestrate all of these things that you work on or more tests or monitor. So you can get very good information, what is going well? What is maybe you should have somebody score even incident for, you can turn back and features that early in, in maybe architectural design or coding or whatever.
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, um, and pulling those things in. So, and then, you know, mentioning thinking about the architecture right up front, you know, not, um, thinking the earlier days of dev ops, 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 going to secure those assets and, and align what a developer is building in their environment with. What's ultimately going to come out into production. So now 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
And Bartha development teams, uh, causally and tell them that you are helping and advising them and learning from them, because if you bring to kind of policy, then, then it's been locked that up very about. So actually, uh, work with the software architects, solution, architects, uh, software development teams, program, product managers, the, uh, his VOC, uh, stakeholders or participants of that process. You need to have your kind of a license on the side. Uh, usually in practice in my life, I tried to get some, a role called secure development champions, the people that are part of those teams, they help us to contact the right themes and they have passion for 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, uh, real life and real people can kind of all that kind of the habits that sometime you need to, to work on and to make that practically possible. So this one sets of things that needs to be done,
I don't think our 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 are the right sort of people that should be part of that program,
Uh, in practical life, you going to the development teams on product product management, and you will recognize the beach. People have, uh, some skills and the passion you'll need to recognize who of them is. Interestingly, if you're trying to make someone which is not passionate about security. So find someone who you feel that you are the servant, and if you have passion for that, and then work with that best on the vessels, and then tell them that, uh, that person feeling more video, and maybe most of organizations have some kind of a management by objectives or annual goals, or look both Providence or bother based software building excellence, or I could Nisha, so put to death best song song on that program, give them some reward what they are doing this, I think Klein of important things.
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?
Yes, actually we had practice of, uh, uh, monthly meetings with the security champions from different teams. So they know each other, so they can share information. This COVID situation is not good for us because social resourcing and everything keeps trust and not failing, not seeing best on maybe cause some even skewed should be, make relations much better. People do know each other. So, but we have these like Colson conference calls. And so we kind of work through that.
Would that guys, thank you so much just for the conversation today. We hope you've enjoyed us 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 be reached out to you to answer questions or any other thoughts if you want to continue to conversation. But, uh, thanks for having us today, Colin and dragon, any closing thoughts,
But it's very short and obviously we could talk about this for a lot longer. So if you want to Dean that conversation would be more than happy. You know?
Uh, I wanted to say, I think some personal research group of scientists and industry professionals called golden meet some processes like findings and using machine learning and AI to remediate security vulnerabilities. And so Scott, so maybe one topic in future AI, AI is after O D you will find some things in there.
Yep. That's just enjoy the rest of the conference and we'll see you there.