Right Size Security – Episode 2: Building a Security Program for the CSO

Intro

Welcome to Right Size Security, the podcast where we'll discuss all manner of infosec from enterprise security, practical security every business can use all the way down to end users security. Your hosts for Right Side Security are Simon Gibson longtime CISO and - Steve Ginsburg leader and technical operations and former CIO. In our last episode we discussed how a CIO might go about building a security program using the perspective of the CSO or CISO, in this second of the two parter we're going to discuss the challenges a CISO or CSO faces getting a program built around the obstacles faced working with the CIO and the other business units.

Transcript

Simon Gibson: So current events, we realized that you know we tape these podcasts and sometimes they don't air what is current. So we had this first section called current events. But what we kind of discussed were even though these events are current and are happening now they seem to have a very familiar feeling. They seem to happen all the time. It's one breach or another. It's one sort of cyber mistake or another or one set of controls that failed somewhere. There's sort of different names but kind of all the same thing.

Steve Ginsberg: Yeah. It made me wonder as I think about it whether we're kind of in a time that has some duality which is some things are the more they change the more they stay the same. And I guess what I mean by that is we sort of have these five or spy. And so there's always going to be folks trying that trying to one up the the other ones. But also it makes me think that in some ways security is still in kind of a nascent phase that we're still learning.

Simon Gibson: I mean I think that's true in some ways but in others it isn't, there are certain things there's like fundamental primitives that should not happen. And the thing that stands out for me is the Facebook you know using clear text passwords to be stored. And to me that is such a fundamental violation of all that is as anything to do with Logins or passwords. It's you know at a former job, sometimes people would post hashes or shadow files in a public ticket and we would like to admonish them not to do that they didn't quite understand what's hash but. Well yes it is but if you have enough sort of compute power you might be able to work out what's in that hash, cracking the hash and kind of I think maybe if you're using clear text passwords you fundamentally don't understand how long it works.

Steve Ginsberg: It makes me concerned that tech companies and even companies where tech isn't the focus but that are involved in the digital sphere sometimes they're just moving too fast and it is as you say a fundamental piece is being missed because they just haven't addressed it with a security program at all.

Simon Gibson: Or the programmers just don't have the experience to know. But a login for example never sends a password when you type a password into a login form whether it's a Unix terminal or a browser. Your password is hashed and then the hash is compared with the hash on the other side. And if they match you get logged in. So I mean just the fundamental tenets of log in are violated by using pure text passwords to Facebook which like I'm just really shocked at for a technology company.

Steve Ginsberg: Yeah, and of course you know Facebook and others have been in the news for you know a range of issues of really not taking user privacy seriously or seriously enough. And maybe this is good to get...

Simon Gibson: Some endemic sort of problem, and yours the 800 million users.

Steve Ginsberg: Yeah. So you know there was another one recently and just kind of the raw scale of these you know really becomes a real question. We've talked about Equifax in the past and people are certainly shocked that someone had you know a company that had that kind of data wouldn't have a better security program around it. Of course we know it's very hard to make it so that something is absolutely not exploitable. And so there are challenges involved in some of these as well. But certainly we would encourage everyone to take security seriously but also to scale the more credentials you have the more you should be considering that they might have a value that someone might come after.

Simon Gibson: Yeah that's true. You know we want to talk today about what it's like to build out a security program from the perspective of the CSO or CISO and in some cases the CISO or CSO is going to have resources that they manage they might manage an IRT or security operations center, they might manage the firewalls or they might not. They might manage Active Directory or they might not. In most cases at least in my experience CISOs often have budget but don't always have direct authority or management. They don't designate or delegate the responsibilities of actually pulling the wrenches on the firewalls.

Steve Ginsberg: Sure so for our audience we're kind of turning the table a little bit this time so last time we were talking about for more from the CIO perspective which is certainly something where I had built up the program from that perspective. Simon has obviously built it from the CISO perspective; since you're making the distinction between CISO and CSO, maybe you want to talk a little bit to the audience about just how you view that also.

Simon Gibson: Yeah I think it's different for organization. I think you know when I think about the CSO role, it's usually more than specifically technical controls or more than governance risk and compliance or more than facilities physical security. I'm sorry for the CSO role. The CSO role would sort of encompass all of that. Where the CISO may or may not have facilities security, badges and locks and those kinds of things and you know access to certain rooms and whatnot that may not fall under the CISO that may sort of fall to facilities unless there's a CSO in that case, all security probably roles up of the CSO.

Steve Ginsberg: Right. So it's kind of the general would be maybe CISO is more likely to be digital only or mostly digitally scoped. Right yeah.

Simon Gibson: Yeah. Or you know again depending on the organization the CISO may have a component of security, chief information security officer in this company focusing more heavily on compliance, this heavily this company focusing more heavily on audit, this company focusing more heavily on technology, whereas the CSO might have the CISO and some legal stuff and some privacy stuff and some physical security stuff. And so I think that's just the sort of defined scope of role I think is a way to think.

Steve Ginsberg: Yeah sure. That's helpful. When we look at a program, when you think about the program maybe either if it's Greenfield or starting within an organization from kind of the highest level of the territory where would you start?

Simon Gibson: For CISO specifically listening in people who are working at you know again I think you learn this quickly in the space if you are a practitioner you learn very quickly that to be successful you really want to be thought of as an enabler. When I have this story I like to tell about you know brakes on a car. If you didn't have any brakes you wouldn't go more than three miles an hour because your car would stop. You wouldn't want to wreck it, so you just keep your car under five and try to coast to a stop and maybe grind your wheels in the sidewalk slow down. But you would not go quickly and security gives you the ability to go quickly. And I think as a CISO or CSO any part of a security organization telling the business units no you can't do it because it poses a security risk, is not the way you want to be thought of. Now there are gonna be times where there truly are risks and you want to stop a certain thing, where you want to make sure a process is secure, but if your office is thought about as being the office that says no, people will go around you and it will actually create more problems for you than trying to be an enabler. So I think it's so important for people to think about security as an enabler.

Steve Ginsberg: Yeah I think that's a great point. I certainly know that the approach and interaction with the business is gonna be super important for all organisations. And then so how do you kind of start a program, start building it up, and have that culture built into it?

Simon Gibson: Yep. You know I think the first thing it's sort of like the first hundred day problem for anybody in a new job. I think for the CISO and the CSO I'm going to sort of speak to the technical CISO because that's my expertise I'm understanding compliance frameworks and audits that I've worked on. But again my sort of background has more to do with building out technical controls and testing technical controls that other people build. And making sure they work and not always making them happy. You know I think the first thing to start is figure out where things are fragile and where things are robust. Look throughout the company and figure out you know lines of business, an assessment throughout all lines of business come up with them you know most 15 most pressing questions you think you can ask to the line of business and go ask all the lines of business what's the one thing if it vanishes, if it stops working or if it becomes degraded is going to stop your line of business from working? There's this term CIA which is not the Culinary Institute of America. It's confidentiality, integrity and availability. And it really just means can you get to something because it's up, someone hasn't dedoxed it or taken it down. Can you reliably trust the information it's giving you and can you get to this resource without anybody else seeing the data between you and it? And it's a nice paradigm I think kind of where that paradigm fails though is with resilience, it doesn't talk about kind of operating in a degraded state or how long you can be integrated state and what are some of the things you can do to bounce back from it. But I think if you take that paradigm and you think about integrity and availability really that's just good engineering, I mean you would do like web scale and building out stuff to scale the top ninety fifth percentile and run that's like availability and integrity right.

Steve Ginsberg: Yeah. We spent a lot of time thinking about fail over and as we touched upon in the last episode a little bit, well what goes wrong when your plan goes wrong or what happens when you're backup system and it fails. We had for a while we started to say three is the new two as we were going after was that where we used to rely on two systems to keep us going all the time kind of either live live or front and backward you know backup primary backup. Then suddenly you need a third option as well.

Simon Gibson: Yeah for sure the interviewing lines of it is I had a really good experience in doing that. The one thing that almost more businesses had in common than anything so one company many lines of businesses, operations, delivery, human resources, sales, hiring, engineering, manufacturing line, all the different lines of business. The one thing that they had in common that if it fails was surprising to me it was the telephones that if they lost are our PBX they couldn't take customer support calls a bunch of ordering stuff failed. I mean it was the one thing for sales things broke, treasury functions, to pay people broke, all kinds of weird things that you would think probably wouldn't matter if the phones went down. Turned out that it was the one thing across eight or nine different lines of business that if it failed it hurt all of them.

Steve Ginsberg: Yeah. This was a great thing to bring up because one of the things I've learned as you build out a program as you were saying you need to ask the lines of business because not everyone is like you. So for example in our department the desk phones meant nothing. Everyone had cell phones, no one ever answered their phone didn't use it for anything, it was all email. All you know like that or something like that.

Simon Gibson: Yeah definitely, I mean the next thing is you know what you've got to understand and relies on one understanding how it's supported who who takes care of the thing, if it's a telecode do you have it as a PBX, do you have a contract with somebody? Is it a Nortel switch of some sort and somebody comes in and services, you have a local person what does your failover look like when that thing breaks and you understand how it works whatever you know it could be access to a particular room if the badge readers go down, what's the process for getting you know sort of just depends on the company and then I think the next question is like how much telemetry does that thing give off. Can it be monitored? Is someone monitoring it and is that part of your security program? When someone try to hurt you by taking it down and you start to prioritize and understand how you manage and build out your program kind of based on the type of you know what support and how much telemetry it gives you.

Steve Ginsberg: Yeah. No. That totally makes sense one of the things from the last episode we talked, you asked about was there executive sponsorship to try to get us going in the security program. And as I mentioned a bunch of it in our case was kind of top up but there was one question that actually had started it which was the then CTO asked me if we were hacked, would we even know? And so a lot of the program in our case was brought with that question which I think was actually a great central question to motivate us to modify our behavior to look into each one of these sections would we even know for a situation?

Simon Gibson: Absolutely. And apart from the sort of the things what are the current policies? I mean again a lot of security is about creating a set of policies and controls you know both active controls that you know will actively block you from getting somewhere to detective controls like is this thing being followed? And then is your policy being reflected digitally? That's kind of the main the next main question is can you say like what we built it to do this but is it actually doing this? You want to understand kind of you know not only what the compliance and right procedure should be but also sort of what's the cadence of activity around it, and are you actually doing it as it was designed?

Steve Ginsberg: Yeah. And with policy there's also that's a whole world of in of itself right. There's all the subtlety of it's something a guideline or a rule.

Simon Gibson: Yes to the best practice or we can all forget about that with the quarters closing we got to and who cares about all that? All those policies were great but we got to close this quarter. I think the other thing is you know who's responsible for what? You know very often I think in the CISO role especially if the CISO doesn't have a big staff they are sort of the one throat to ring for the executives. And so they're responsible to saying whether or not we're secure. But they may not be able to implement the security and therefore there's a lot of managing by influence as the CISO and so the other part that I think this gets lost is, well it's a security thing the CISO guy knows it. But if it's a business process somewhere very deep down in some part of the business that makes a whole lot of money. But they have this really obscure process and that's just how we've done it for the last 10 years. The CISO can't possibly know what that business process is. And so really understanding who's responsible for that line of business, who owns that process, who owns it when it breaks, who knows is the best, is it documented, is it supported, those are the kinds of things that the CISO needs to figure out. The CISO won't know everything about how the business is run or should they? But understanding who owns what the lines of business is super important.

Steve Ginsberg: Yeah and of course that stuff's going to change over time too so even if you know one day a month later you're not going to know all those things again. Some things will change.

Simon Gibson: Yeah. Anybody who's put together a you know like a run book for crisis preparedness you know three months after you built it out every year you got to go back and change all the names because the boxes are still there. But somebody who's moved on from that jobs to your point of contact and a phone number. It's difficult often to keep those those current fresh.

Steve Ginsberg: You mentioned crisis management there, curious what are your thoughts about kind of communication style or how to structure good communications during crises as you said the board is likely to come to you or CEO exec staff is likely to come to the CISO and say OK tell us what's happening.

Simon Gibson: I think part of that's a good question and that what would I recommend for the CISO is a threat model is go model your threats. What is it? What are you worried about the most? What are your top seven priorities and don't you know I personally pick things that are going to put us out of business. I know if our payroll database leaks and it shows how much the CEO made how much so-and-so spent on his expense report or she spent on her expense report it's not going to be great for the business but may not put us out of business. So yes it's important but is it the most important thing? And I think maybe it is for some companies and certainly for Sony it was a big deal when all the emails got out sort of people's salaries and how people were treated. That was a very big deal for Sony. But I think for a lot of companies it might be you know software you ship, if you ship an app to somebodies phone, you have millions and millions of customers or tens or hundreds of millions and there's a Trojan or a backdoor in your app that causes people to lose money or materially be damaged that will put you out of business. And so those are the kinds of things the CISO needs to think about. And so threat model your stuff, and then I think you kind of will get to an answer in terms of how that works.

Steve Ginsberg: Yeah absolutely. And then when there is such a crisis then how about communication kind of during incidents and both that kind of, so there's at least two major realms right there's internal communication what do you tell other parts of the company while things are happening and then what do you tell the outside world which obviously some of that's governed by law.

Simon Gibson: Sure. Yeah, different states. And I think it's very important to be prepared. I have always again within sort of the first like right after the first hundred days there's generally a create the crisis plan and it's just a right glass that lives in the head of communications desk or the head of compliance or the head of the whoever needs to own that thing so that when there's a crisis that there's a PR firm onboard that there's a communication plan that the right people can be notified that the playbook, you know this happened insert this here, we have taken the appropriate steps and so on and so forth and again prepare that stuff in advance.

Steve Ginsberg: Right. So then you don't have to create it in the midst of a crisis.

Simon Gibson: If you can't, you know if you don't have the resources internally go find a third party go find a third party that will support you, get to know them. Do the T's and C's of the contract before the crisis hits. That way when you bring on the paratroopers to help get you out of whatever trouble you're in, they already know you, you know them the contract is signed and often in my experience when I've done this kind of work, I've been able to use these third parties as consultants to do reviews, to do the threat model to rank our programs to give us advice and so you know even if you don't use the money on a crisis you can still get some pretty good work product by retaining these companies in advance.

Steve Ginsberg: Right. Yeah. That point of having the idea of the maturity of the security program is really a great thing as well, like as you're saying understanding within the kind of individual parts of the program and then the kind of the program overall to kind of be able to compare to peers and that kind of thing. What do you think about kind of what's a good overall structure for the department? You know you have an organization you'd be building and then you're gonna fit into the great organization in some ways. You mentioned a bit about that being influenced a lot of cases but how do you think about that?

Simon Gibson: It's a tough one it's different for every company in some cases the CSO CISO kind of functions report under the CFO and in some cases that's right. In some cases they report under the CIO in some cases that's right. In some cases it's direct you know up into the CEO. It just it depends on the organization. I think there are some inherent risks for an organization, a technology organisation to manage their security. If you're trying to ship a product and it's got bugs and you know it's, you make money for shipping product not for shipping secure product at the end of the day people don't write checks for good software they write checks for software. Right. I mean that's you're gonna ship the product and I think security can sometimes take a backseat. So having some autonomy I think is a good thing. At the same time that autonomy means getting stuff done can be harder because you're not necessarily part of that organization. And again that goes back to the kind of horse trading. So I think it matters. You know by organization.

Steve Ginsberg: Yeah. And we talked about previously, you're mentioning some of the ways in which you can move up line and kind of streamline to kind of get security built into product.

Simon Gibson: Definitely, having a penetration test done, having a real red team exercise done against either a core component of your code or the corporate network at large or some component of the DMC will often yield a lot of valuable information. And so you can sort of drive some behavior around what you want to get done that way. Again you have to be very careful with that because if you are constantly breaking into things and showing what's broken, eventually you're going to want to just be able to fix things. And if you sort of get too many red tests done and they're, you know it's like calling someone's baby ugly, eventually you're going to not hear from them anymore. You have to be careful about how you use it. But that's one way to drive behavior. Another way to build security upfront you know people tend to be motivated and this is just an unfortunate fact that human nature is that people are motivated by pain like when something is hurting or not right people will do things to correct it. Again security should be thought of as an enabler. So the more things security can do to show that they're enabling process and business I think the more willing engineering teams and other teams are to bring them in.

Steve Ginsberg: Yeah no we we often looked at it about trying to avoid that pain upfront. But you're right, motivating people in that way sometimes doesn't work because as you said product deadlines those type of things they have movements that they have to make. We did have some success moving up into the code repository like tools that would scan code automatically and that kind of thing. But as you say the balance of that kind of communication back and forth with errors have been found please fix them and prioritize them. That's a tough one from there. How do you think the security program fits into the overall flow of the company?

Simon Gibson: You know it has a lot to do with the, I think there's three kind of areas I like to think about when I look at you know how a company should structure their program you know really it has a lot to do with the compliance regulations and environment that you're in. Like if you're regulated and you're part of the EU you're going to have a certain set of rules. If you're in medical you're going to a certain set of rules if you're managing credit cards or money or you have a certain set of rules so your compliance environment. The next is your capabilities. You know how much institutional knowledge is there? How much legacy stuff is there and how much you really how much you pay in your IT team? I mean I know it sounds kind of cold but really, do you have a type really strong engineers that are building and running your IT organization? Or have you sort of you know your IT organization had a lot of churn and you know there's not a lot it's very sort of you know very level one help desk response and people age out of those roles. Is there good support? And then the last component you know it's technical capabilities, regulation and then customer expectation. Who are your customers and what's their expectation of security? And that's kind of you take those three into consideration and then that's kind of how you think about where you pipeline security.

Steve Ginsberg: So maybe to drill down a little when you talk about technical proficiency of the IT staff what would you extrapolate from that? So if you have more junior entry people or maybe less proficient people for whatever reason versed you have very strong technical people. How is that different for the CISO? Obviously that you have to consider the capabilities of the CISO department but then, but I think you are also maybe he's talking about the IT organization in general or that category.

Simon Gibson: I think it's absolutely in general as to your point about putting up some kind of code getting tool into the repo to check for you know potentially just obvious errors in code. You need engineering resources to be able to do that and to be able to run that and that you have to have either not just people that are capable of putting that in the pipeline, people that are capable of maintaining it. So there's like there's a staffing component around it as well. Do you have a role for somebody to do that and is it staffed? From an IT perspective, you know if there's a lot of churn in the IT department, often IT staff has quite a lot of capability. I mean they generally have some level of admin if not domain admin depending on kind of where you are, most places I've seen tend to have a few trusted people that have domain admin and whether or not they use that as their personal log in for everything or they have a separate dash account for administrative things. You know those are all the kinds of little details that highly proficient engineering staffs versus an IT department that you know there's a lot of churn against a lot of Level 1 people who come through it. That's going to make a big difference for the program, it's where is it being resourced? And I think that's what you have to look for.

Steve Ginsberg: And that's really a common vector for a Red Team test and or real hackers to get into a Windows environment for example.

Simon Gibson: On the Domain Controller with a link or the domain admin.

Steve Ginsberg: And then that's a good point that you brought up that relates to what do you try to own as a CISO versus what you do you try to have other departments to do? So you mentioned in engineering or in other departments how do you kind of draw those lines if you have the choice or how do you broker where would you take a stand if you weren't getting the first choice of just it falling down?

Simon Gibson: Great great question. It's going to depend on the CISO I know I kind of think where the most important controls that can hurt you the most are probably the things that the CISO should own and then everything else the sort of business. I think it's difficult for a CISO organization if you don't have a couple of programmers to be able to deliver support to a programming organization. If you want to get things done or build tools or connect tools together so that they work you kind of need programmers. So there's probably some in my opinion some level of software engineering that a CISO should own I also sort of believe that the demarcation between Internet and internal whether or not there is actually any internal is a separate conversation but really the kind of the core firewall controls probably something that CISO should own or at least have a part of the change control process where somebody wants a firewall rule. It's a new line of business needs to connect X with Y, it should go through an organization to review that rule and make sure that that control makes sense and it fits into the policy. So the CISO should probably own at least if not the actual change, the mechanisms, the logins. But certainly some part of the review process and I think incident response is fine to put in the CISO's office. Again though you start running into the shared admin responsibility where if two separate groups have admin it's really difficult to manage things. And so again that collaboration between the CISO's group who may own and serve response so a machine has been compromised an alert has been thrown off. We know something bad is happening, well now that has to get remediated. We need a memory image and we need you know this machine to be forensically examined and somebody needs a new machine. The business needs to keep going you know if that's IT or the CISO but there has to be a good working relationship.

Steve Ginsberg: Yeah. That when you're starting talk about incident response here it just reminded me how these things do really branch off in a lot of discussion. A lot of directions and discussion about scoping really becomes important like incident response some of the same things that are in crisis communication will eventually be things that have nothing to do with digital security at all. Right. So you know a company may have a crisis you know as you mentioned PR kind of crisis, those type of things that those may have nothing to do with information security at all and yet a lot of those same procedures would be shared in time that kind of communication. You know you just mentioned the outages of various kinds and so sometimes when you have an outage you don't know whether it's a security outage or just an equipment failure or coding failure change failure until you get into it and then at a certain point it will branch off and either become something for the CISO or not. How about network teams do you have any specific, you alluded to that, but any kind of specific thoughts for and again this I'm sure will be different in different organizations based on who is there but so firewall is one of the main things there and you said to be in change network skeys to be in ACLs and things like that and that's maybe one step a little closer to networking but still affects security maybe is probably somewhat similar but do you feel any different about that or anything else kind of down that path?

Simon Gibson: Yeah I mean a network team can just run a circuit from here to there and suddenly what wasn't a party or threat model is now in your threat model whether you know it or not. You know again that's another sort of problem is the you know the communications and whether it's you know collegial and informal or very formal through a change control process. I feel like the CISO is a very key part of establishing those kinds of controls so network teams that we're going to bring up DR sites and data set. OK so that means we're going to turn on some TWM and do something and get connectivity to some other area. Well that should definitely be on the CISO's radar.

Steve Ginsberg: Yeah I think all that stuff's magnified a bit now in the cloud world too. Now I think enterprises you know the default assumption might be hey if it's in Amazon they've got security it's probably fine but you're really just connecting d-lands into the cloud.

Simon Gibson: Now your corporate network is touching Amazon which is touching the Internet. Is there any security around that? Absolutely, cloud is a whole, I'm glad you brought that up because that is another is a huge bailiwick especially I mean all the way from that example of a VPN to a cloud, it's now the Internet. You just basically open a hole in your firewall to the Internet to micro services that run and turn up and down. And those services then need some credentials to go get information from a database maybe in your data center or on prem or from another cloud service provider. How do they get from one or two or five or 10 hops and share Federated credentials around to be able to pull it especially if they're coming up and down quickly being able to understand you know login password equals this data. Now thousands of services that come up and down need that stuff.

Steve Ginsberg: Yeah. And I think that they're coming up and down quickly is one of the New Horizons that we've been getting closer and closer to that over time. But this idea that infrastructure really is ephemeral now. That in a containerized world system.

Simon Gibson: You can't count on an IP in a subnet to define a workload. Right. Anyway I think for a long time we kind of said well that's the such and such segment you know. OK fine. These are the rules for the such and such let's say. And now very much so, not only is the IP sort of irrelevant but the workload may migrate it may move around from machine to machine. We actually at RSA saw some very interesting companies that we're working on precisely that and some standards open source organizations that kind of were focused around identity and then we wrote a paper in a security part under my practice at GigaOm. And it talks about identity being the next security perimeter, and I think that's true I didn't coin that but I really firmly believe that security and identity are, they're just they're linked to where instead of being provisioned at a firewall for your idea that you kind of get in and you get out and get taxed on all your things really you get provisioned as a user, and then based on your provisioning you can access the thing. So it's sort of the ground up.

Steve Ginsberg: Right everything is role based, to what role you have in the company or what multiple roles you have in the organization.

Simon Gibson: Even more granular in like a teaching hospital for example you may have someone who's a student by day and a nurse or doctor by night and so during the day they have a certain role and certain set of access and then at night when they come to either shift their role now changes, the same person different different use cases.

Steve Ginsberg: Yeah that's reminding me that just how roles too within a company somebody changes jobs multiple times while they work at a company that their security provisioning needs to move with them.

Simon Gibson: Yeah I think the other thing apart know when we're finishing is we're kind of getting towards the end about building this program one of the most important things is to be able to track and measure and you need to not only be able to track and measure this with the rest of the company, you need to be able to track and report on it to your boss, to their peers. You may have to report on it at a board meeting and you need to obviously be able to reward your people or you know understand who's doing what, and if you need more people or you've bought a tool that now decreases workload you sort of have to measure all this stuff, what I've done in the past is build tools and you can do it in a spreadsheet all the way to build a database, do it yourself, but track all your risks. Once that threat model is done, record every single thing that happens, whether it's a stupid piece of malware or a machine that gets caught by any virus console and scrub to a systemic problem and network segmentation to you know if you've done an audit and you found that a policy says it should be one way and it hasn't happened and you found something different track that is a risk. There are different kinds of risks and they don't have the same severity but track everything and then once you track everything you can start to normalize the severity and then you start to report on progress. This is a good way to know if you want to make more investments to make the company more secure or to gain back your own time or both. Then you'll have a good basis for that. I think every executive wants to know if I spend X how much more secure will I be? And if you're not tracking that, you don't have historical you know you don't have this historical trend. Well we know we've spent x million over the past year, how more secure are we now as opposed to then?

Steve Ginsberg: Right it's pretty intangible really of how secure are we. But at least if you can show things trending in the right direction.

Simon Gibson: Meantime you repair a number of things found. You know sometimes the number of things found, the more is better. Right now you're looking harder so it doesn't mean that while we've, you know last month we only had a thousand things and this month we had ten thousand, so well we started to look at a lot harder this month, so that's a good thing.

Steve Ginsberg: That's right. It can actually your trend can go in the wrong what seems like the wrong direction. How do you manage change? So you've built a great security program, it's humming along, but the company that you're in is going to change right?

Simon Gibson: Always going to change. Yeah it's always going to change, and this was you know I lived this for years which was you know August September get business plans going. You know, October November meet and finalize business plans, early December business plans were approved. Everything goes, the GL is funded on Jan 4th or whatever and then January 15th, everything's changed, there's nothing. All the business plans are gone the number one priority thing you had in December is now number seven because there's five more, six more priorities in front of it. Be flexible. I think there is, in security there tends to be a lot of you know this particular problem will end the world or this will be a terrible thing if we let this happen and I think you know the security practitioners need to stay flexible and you know things will change, M+A will happen, new partnerships will happen with new companies. Being flexible is key, leadership will change, the product may change, you may get new products that you ship, you may ship a different version, some new enhancement will happen in the cloud as a great example your company that was once very much we're never going to put anything in the cloud may now start to put loads of workloads in there. Really the key is just is flexibility have a program and a framework and then be flexible within it.

Steve Ginsberg: You mentioned partnerships there maybe we'll probably deal with that in more detail in a future episode but maybe now since you brought up what's kind of your your top list for you've got a product company of some kind or some important part of the digital flow of the company now there's a new partner that wants to participate from the security Org out, what are your kind of either top questions or top procedures to decide whether you're ready to go join networks, you know they want to join to the network somewhere that belongs to another company?

Simon Gibson: Right. I think that gets into a whole like just a business review what are we trying to accomplish as a business and how critical is this partnership not just to our business but to the critical path of us shipping a product? And if they're directly in the critical path like if they break we can't ship our product, then obviously you need to give them more attention and you spend time with them. And if you need an auditor you need to talk to their security people and look at their ISO or whatever and meet them and see if they do change control? Do they have a written program in place that you can see, do they have evidence of control and some kind of accountability and then you know the answer maybe no. And then so what do you do right? And then so again leap, like the least amount of trust possible. What do we actually need to get the business done? And it's all about being flexible.

Steve Ginsberg: Yeah I think this is an area where a lot of our peers spend a bunch of time trying to figure out what limited access would solve it first? But to your point even you know even limited access you really want to know who's on the other side of that that limited access and then kind of grow things only appropriately. It sounds like we've described kind of the main thing that security leaders should be looking when they're building programs and working with the business to both get that established, get some important wins and then move into place where it's sustainably grown.

Simon Gibson: Yeah I think that the CISOs at the CSOs listening, you know again everyone is sort of, there's always a slightly there's no one right way, I get asked this question a lot. So you know tell us the secret thing that the CISO knows that they want to do it. And the answer is you know especially you get asked this a lot from sales organizations. What is the thing that the CISO you know that I need to tell the CISO that they're the most worried about it. And the answer is know the CISO you're talking to. What are his or her concerns? Are they at CISO that has you know lots of compliance and regulation and they're constantly in the soup with auditors and their job is really just running around answering the mail and trying to get things to the point where the policy makes sense? Are they you know a technical CISO, are they trying to build out technical controls? Are they in charge of the firewalls? Are they not in charge of the firewalls? You know who the CISO is,t hat's the most important thing you can do when working with a CISO. So I think that's it right.

Steve Ginsberg: That sounds really great. Thanks Simon.

Simon Gibson: It's great conversation, thanks Steve.