Improve Your Security Program by Blending Principles of Kaizen and Your Security Risk Analysis

Tim Rohrbaugh

CISO at Jetblue Airways

Learning Objectives

Security program improvement should be tied to security risk which changes frequently. This session will cover the reasons security risk is fluid and the benefits to approaching security program improvement through small incrementation changes (I.e. Kaizen). This proposed approach turns compliance driven change and traditional approach of program maturity on its side.


Key Takeaways:



  • Learn how to apply Kaizen principles to security tasking

  • Learn how to apply Kaizen principles to security tasking

  • How to use the Agile development style in Security


"By reducing the volume of data or the things that somebody can get access to, then the security team has fewer enclaves or systems that it has to monitor, and criminals have less data that they could actually acquire and sell. "

Tim Rohrbaugh

CISO at Jetblue Airways

Transcript

Hello, welcome to this presentation. The title of presentation is improve your security program by blending principles of Kaizen and security risk analysis. If you’ve ever struggled with, how do I grow the program? How much emphasis should I put on compliance requirements? Where do where does feedback come from with respect to each of the efforts that we take, as a as a security engineer or analyst on the team? Sometimes you struggle with how do I equate what I’m doing to an actual threat? Some of these questions I’ll answer in this. And then also and also give you an alternate approach to actually building the security program from something that’s customized to you, and allows the team to actually feel like they’re more of the solution and understand how their contributions actually affect the overall program. My name is Tim Rohrbaugh. I’m the chief information security officer of JetBlue Airways. I’d like to start off presentation, giving you a little bit of background on some of the vernacular that I use. And then also, kind of a, an area, which I’d like to emphasize, which is the purpose of any information security professional is shared across all industries, all sectors, all domains, everything that we do from an investment perspective with respect to time, or or capital can be broken down into one of two results. Either we’re trying to reduce the probability that a security event will occur, or we’re trying to reduce the consequence when one does occur. Sometimes an actual retake covers both. When you think about the first one, though, reducing the probability of a security event, you can sort all of the actions in there things like creating roadblocks, roadblocks for criminals to actually get a foothold in your environment, to get access to data. We’re probably by and large, the only the only employees of a company typically, which are paid to make somebody else’s life miserable. It’s not the employees inside the company that we’re trying to do this do this to, it’s actually criminals or people who want to misuse company’s resources, or consumers data or credit card details, things like that. On the second one, reducing the consequence, when security event occurs, probably the best way to think about that is that it’s that if someone breaks in, and there’s nothing there, then there’s nothing to be sold, there’s less of a risk consequence, if data that’s taken is not consumer data, if it’s of less lesser value. So the ideas, and the concept to apply here is things like data minimization, or putting maximum time periods on retention. By reducing the volume of data or the things that somebody can get access to, then the security team has fewer enclaves or systems that it has to monitor, and criminals have less data that they could actually acquire, and sell. So what things typically drive a security program, for most, the first one is just intuitive. In fact, that’s what we do a lot of our budget to get, but it’s maybe not the best approach. But there are two forms of compliance, and we talked about it one is, is capital C compliance. And when we when we talk about that form of compliance, we’re talking about federal or state legislation, then there’s small c compliance. And that is related to contractual obligations or private security requirements, such as like PCI. The problem with both of those approaches as a primary driver for how do you improve your security program is that they prioritizations of each of the requirements and the control points is considered equal. There’s no difference between them. And it doesn’t take into account the context of your environment. And I’ll explain contexts in a little more detail in a little bit. Then there’s another approach that people use and that is to use a framework. The frameworks can be thought of, as, you know, ISO 27,001, and two control set, or it could be


could be one of the government NIST ones, or any other framework. It’s a it’s a formula for building a security program, but it still needs to be placed into the context of the risk of that business. Since again, it doesn’t take into account the differences between each of the industries, it’s unable to actually prioritize which controls have more value at achieving either a risk reduction right with the probability that a security event will occur, or the consequence when when does when does occur. There’s a third option and sometimes blended in, sometimes this becomes the main focus, but it’s actual incidents. So companies as you know, when they experience a breach, or they experience a security event, when they go through and do a retrospective of that event or post mortem, then it’s determined that they should have had patching in place where they should have had some type of logging, whatever those should have had end up being, obviously part of business cases, and they become more likely funded as part of activity to grow the security program. The problem is, is that if you use this as a main driver, then you have to have these experiences to have investment in the right area. But that only takes into account what criminality did in the past, not necessarily what they’ll do in the future. Another variation on that approach is to use what other companies experience. And that’s a, that’s a fine approach, because then you’ll you’ll figure out what techniques criminals are using at that given point in time and, and make those most likely to occur in your future. The problem with that is, is that most companies don’t share the details of their breach. And so for one company to learn from another company, it’s rare, it can be done in certain situations. And that falls into the last one of the categories and last tactic for growing. And that is to predict what security loss events, you will experience based off of the things that you personally and your team members have experienced your company’s experience, and threat Intel. And this is where you have information sharing groups, which actually have non disclosure agreements. And they share the details. Some of these are financial services FSA sack, or aviation, I sac or health iseq. There’s other ones that are not necessarily in the iseq range. And then we have consultancies that actually produce papers, which list all of their investigations over the prior year. Those are, those are helpful, but it’s very difficult to get down to the details of those. And to really equate those with what type of criminal activity is being done by individuals who are inside of your company, and others like you, what are the employees or we call them crew members inside of JetBlue? What are the employee? What mistakes are they making, based on their focus based on the patterns of behavior, which have been going on for a very long time, once you define which of these that you want, which of these past drivers that you want to actually develop your program based off of where you blend it, you still need to equate each action to a specific to a specific point. This point is best described as who, how and what another way to think about that is you can think of this as t cubed. So that’s a threat actor, a threat scenario. And a target is the combination of those three, threat air threat actors, there’s a finite number of threat actors, we all know what they are. Not all of them have the same probability of being your threat actor against your company that’s most likely to cause a loss. But we’re talking about things like disgruntled employee, criminal organized crime group focused on cards, it could be an individual, it could be a hacktivist. There’s all various ones but but you get the point, there are certain there’s only a finite number of threat actors. On the other side of the equation is targets. There are also a finite number of targets. But those are not shared across the industry. We each have each company has a specific set of targets, you have to know those and identify those as your applications or places of data enclaves or certain types of data, data attributes that somebody may be able to monetize or acquire from your environment. And so then that becomes a directed target. What’s variable in this equation is the threat scenarios, the how, and these are the ones that you have to be very careful about because these threat scenarios change as criminalities pattern changes. So that’s, that’s why we have to actually identify all three so threat actor, maybe organized crime, they’re doing


a carding against your site, to find credentials that are used and other sites that were breached. And see if those customers have X, same account and passwords at your site. And then we have target, what are they actually after? It may be things like card details and maybe personal details and maybe transactions so that they can they can have better spear phishing campaigns, and the higher conversion rates, whatever it is, every action that you take, you should be able to articulate who the threat actor is what the threat scenario isn’t what the target is that you’re intending to either remediate or to make the threat actor’s job more difficult. It’s a good good time to talk about actual perceived improvement. Most of us who go through a career and we experience, you know, the trials and tribulations of actually growing a practice, or improving building a product or improving the program. And we get to the end, during that process, we realize how tedious It is, in the end, we see the improvement. And we forget all of those middle steps. And so when you go back, and you think about perception of improvement, a lot of people will think about it as a linear curve. Now, it could be linear, it could be exponential. But either way, it seems very smooth. In reality, though, what is it, it meanders all over the place? And, and sometimes if you if you look at how your your team is working more, or the efforts that you’re putting in, sometimes you either don’t see what you expect from the results, or you underestimated how much labor was going to be associated with it, or you just you just had some incorrect assumptions in your hypothesis about the actions that you would take, and why you would take them and what the benefit would be were completely wrong. that none of that’s bad, except for when you do it in a project lifestyle cycle or, or more traditional waterfall, because what happens is, is that you run this as a project over a very long period of time. And your feedback loop doesn’t allow you to just stop and restart very easily. And also, you know, you have sometimes you have a long time from start to end before you actually measure the results of what you’re doing. And it can be very complicated. The other thing that project or waterfall methodology causes is large number of very tedious, very complicated requirements. And what happens is, people just get stressed over it or they feel, you know, like, it’s just so complicated that they get, you know, apathy sets in, or they procrastinate. All of those things, you can trick the brain you know that you can you can hack the brain by actually altering the methodology and going to more of what was today is called agile, but we’re going to, we’re going to talk about it slightly differently. We’re going to use kind of what the basis of one of the methods and the process is, is, is based off of it’s called Kaizen. Kaizen, I think I read that it wasn’t actually a Japanese philosophy, it came out of America, World War Two, I don’t know if that’s true or not, but from the standpoint of the word Kaizen, it is absolutely Japanese. And it talks about continuous improvement. I like this, this, this quote off the site, but but the key point is, is that it’s a strategy for all employees at all levels of the company, to work together or on the team work together. And to be active in the process of actually creating a better program. Not only does it give a sense of empowerment to each of the employees, but it actually gives them the ability to provide feedback very


quickly. One of the things that you’ll find in all levels of the organization, no matter how much experience you have, you may not if you don’t have a lot of experience, you may not come up with a solution. But what you’ll find is, is that you will find problems just as fast and sometimes faster than people who have been there for a very long time. The ability to actually find problems with the solutions that were that we’re advocating early allows us to adjust as a team. And so having everybody select small segments of work, and then provide feedback quickly and complete, it allows the team to adjust and for you to test your assumptions. And and also to obviously prove out that you’re moving in a in a more linear approach to growth and improvement. There was a quote that, that has an analogy that helps me to think about this and describe this and it came from Ray Dalio, his principles where he talked about everyone on the team owning the machine. everyone on the team does own a piece of the machine. And it’s all it’s our job to make the machine run better, more efficient. Very simply in the security program, or security pro world. It’s really about addressing risk. And it’s really about addressing risk consequence. Present has a lifecycle horror methodology that’s worth bringing forward and that is, it has an acronym it’s called be PD ca. So plan, do check act. One of the important points of any security program is doing a risk analysis. When we do a risk analysis and we identify what the threat actor threat scenario and target is that we want to address because it’s most likely, then we hypothesize sighs how we can improve how we can, how we can lower the probability that that will occur or that they will be successful. And we do that by creating, in this case, a small, bite size amount of work. And that bite size amount of work ends up being based off of a hypothesis. So that’s the planning part, the doing is actually doing that bite size amount of work. Some people call it snackable amount of work. And then and then after doing that, then what we do is we actually verified did it move the needle? Did it make? Did it actually make a change that we could measure? If we can at that time, it’s okay. There may be some dependencies. But regardless, you should be thinking about after each evolution of work, I’m going to use agile words. I’ll try not to use them right now. But after every snackable bit of work, you’re going to actually think about how could I measure whether this has a positive effect or not? And then act is the part of the phase where it circles back around. This is where you actually you actually assess what’s happened and then decide either, should I refine the story, the next story, should I choose a different story, should I go down a completely different path, because this wasn’t this was a guess. And that was incorrect. So I’m going to just set it aside and start on the next one. Because this work cycle is so quick. And and the work efforts are so small, you typically won’t get too far off track. So what I’m advocating for is combining a few aspects or a few few ingredients. One is a risk analysis. This means whatever you do to actually start your security program maturity, whatever point it may be from ground up, or whether you’re coming in after the program has been in place 10 years, you still must do a risk analysis, you must do at a period of time, not just at the beginning of the year and the beginning of the cycle, you have to you have to have the frequency come much more much more often. Because what happens is criminality is changing. So is the practices inside the business. Anybody who’s gone through COVID, notice that a lot of the assumptions that were made in January had to be altered with respect to where, for instance, employees were coming from and accessing systems. So that changed the way that you had the view where you were logging data, the efficiency of actually your, your patching systems, all of that. So doing a risk analysis frequently, or when there’s a material change in the business throughout the year is important that needs to be fed into these other aspects. And that is making sure that you create the security drivers that you would actually combine into this mix. And then you want to add in Kaizen approach. And this Kaizen approach is going to be thought of as incremental improvement in small manageable steps. And these steps are, you’re going to describe them as aspects of agile development process. And we’ll get into what some of those terms are in just a second. So if you do these four things, what I’m suggesting is that you’ll have a process


for incremental improvement, which is both empowering to the customer to the employees, but also allowing for faster recovery from this steps. In addition, adjusting as quickly as your adversary criminalities tactics are constantly changing. And so is their ability to actually monetize one type of data versus another. So they’re going to be changing quickly. And then also it keeps your investment aligned with measurements of inspected improvement, so that you just don’t have a program that’s running for years and really never know whether it’s effective or not. So what does this new process sound like? It sounds a lot like an agile development process. One of the best things to do is to actually have daily stand ups, daily stand ups, you can read about these things in in Scrum guides and other types of Agile process, which describes similar types of efforts and terminology. But daily stand ups are when you actually get the entire team together. And you literally have each person’s given just a small time slice and a chance to either talk about what they achieved in the last day, what they’re working on today, or any roadblocks. And if you have, if you have each person stand up and say that then everybody on the team gets to hear where somebody is that possibly help out or make suggestions. And it also gives the person who’s managing it the ability to listen for the roadblocks in the end to formulate an attack to actually remove those from the team and from the individuals effort. Then there’s also a story creation story is and I was struggling with a way to describe those that that bite size or snackable chunk of work. They’re called stories. And inside a story sometimes you have tasks but think of the story as something that has a finite amount of work and you create even Points associated with the level of effort. A point could be any amount of time that you want it to be. It can be, it can be half a day, it can be a full day, whatever it is, you define a one story point first.


So let’s say you do it at four hours. The important part is not how much how much time is associated with the story point, it’s that when you get to a tune of two point story, it has to be double. So if the story point is four hours, two points, is eight hours. So you’ll define a story as costing you 1234 points, when you get up to the larger point values. At that point, that should be an indication to you that you’re going to possibly underestimate, or, or not as bad overestimate how much work is associated with it. It may, they may pull one person away so long to work on that, that they’re not going to get a chance to give you feedback, but maybe once a week. And that that’s not enough, when you might be running your work cycles in a very short period of time. There’s another word for the warm work cycle. And I’ll tell you in a second. So these stories are something that you want to put a value of labor on, you want to create them in small, incremental efforts of improvement. And then those fall under these stories are actually sorted under security domains or in Agile terminology. They’re called epics. So one of these might be vulnerability management, it might be network security, it might be policies and compliance, whatever it may be, you organize it for your environment, as it makes sense. And it could be related to different teams, you could possibly even run a team just for an epic if you have very large teams. But other than that, at least create these epics sort your stories of improvement, put them in the backlog, and then run grooming sessions. grooming sessions are when you actually take the items, the stories, you make sure that they’re estimated about the right amount of work. And then you then you sort those, and you bring those up from a priority standpoint, into the next cycle of work that you’re going to do. Now, these grooming Sessions is, is usually run just before the beginning and towards the end of each cycle. The cycles if you’re going to stay with agile terminology, are called sprints. These Sprint’s are going to be some anywhere from let’s say recommend two weeks to a month. But I like to run them in two weeks cycles that two weeks then allows you to say, at the beginning of the cycle, we’re going to estimate that we’re going to do a certain number of points. Based on the labor that we have, you might only have half of each person’s time. The other half, they might be doing business as usual type activities. But if they contribute that half of their time, then they should be able to pick up stories if they’re estimated well, that equate to that amount of time. And you’ll get better over as as this process goes on. So from the standpoint of these grooming sessions, you’re actually pulling the stories in now in Agile, and especially for development, you’d be very rigid about what you’d pull into the sprint, what, what effort to pull in there, the one thing that I did find that I would probably advocate is that you’d be much more flexible when you’re talking about security program, and building a security program under under this process. And the reason is, is because you might actually place a story in there during the two, two weeks. And either you run into an issue where you didn’t get the result of the prior previous story or something’s happening with respect to a security incident. And you may want to adjust and bring in something different from an improvement standpoint into that two week spread. I think that’s fine. You just need to make sure that you know what your total point value is that the team is capable of doing. And then pull something out and then put it in. And then beyond the sprints. As you get to the end of that and you close it out. The goal is obviously to complete everything, then that’s in the sprint, don’t worry about if you could have put a few extra things in there to use that time to maybe maybe spend more on getting ready for and actually thinking about and documenting read the retrospective. So the retrospective is a is a session that you run. And that session posts the sprint goes back. It’s time for betas take a breath before the next grooming session and say, you know, what did we do well, and then what could we have done better? And what we could have done better get specific. Do we find that we underestimated the point value of each of the stories? Did we did we Go down and try to improve one of the epics that maybe didn’t actually show that much improvement, or we were unable to measure or maybe had some dependencies on something else that we didn’t know.


So it’s a way to kind of adjust your thinking and to make the next sprint even better. If you do this and you go through this process, you may go backwards a little bit, you’re definitely going to go forward. But you will find that the sprint activity will get better and better and better over time, and people will feel more comfortable with it. So I hope this session helps you think about maybe an alternate way to grow your security program. And that if you may be biased, more heavily towards compliance, or towards what your third party contracts or your your partnership contracts require you to do, that you stopped and take a look at some of the risk drivers. And there’s risk drivers put into context. Again, really make those you know, get put a lot of fidelity to those by describing them as a threat, actor threat scenario and target. Make sure you you’ve learned from every one of your incidents, stay connected with your, your information, sharing groups, if you don’t have them, join them even things like infragard. Network out there, bring those details back in and then adjust what’s happening out in the environment, to your security program makes sure that your security program takes into account, you know what’s most probable, and then think about actually changing your project mindset into one that’s more Kaizen, where it’s small, incremental changes, that will actually improve the program. And what I think you’ll find is you’ll find that people will be more engaged. And you’ll you’ll, if you do miss step, it will you won’t be that far off path. So thank you very much for your time.


Get full Q/N Access

Sign up to Q/N with a few details to watch this presentation.

  • Hidden
  • Hidden