Cryptography

Introduction

Welcome to Right Size Security, the podcast where we discuss all manner of infosec, from enterprise security to practical security every business can use, all the way to end user security. Your hosts for Right Size are me Simon Gibson, longtime chief information security officer (CISO). And me Steve Ginsberg, former head of operations and CIO. This is a two part-er about how a CIO can prioritize building a security program either from greenfield or by taking over an existing program. We're going to look at what some of the pitfalls are, what to watch out for and how to make the most progress in a short amount of time. In the next episode, we'll look at the problem from the CISO's perspective. How does the CISO work with the CIO as well as other parts of the company when they're not at the same reporting structure?

Transcript

Simon Gibson: So welcome to the first episode ever of Right Size Security. Before we get into the topics at hand: building out security programs from the CIO's perspective, let's talk about some current events. Steve, you had brought one up. You want to start with it?

Steve Ginsberg: Sure. So I just thought it was interesting to see in the news: there was a lot of interest already with the Mars rover going silent up on Mars. And interesting to see that it's actually come back to life. And then looking over some of the details, I saw part of that is by design. So the NASA program evidently had built in already the ability... so my understanding is that it failed to reboot which I think any systems administrator can have some sympathy for. And then but by design, they had an out of band way to get back in and actually link a backup. And I thought it was just interesting how mission critical operations can really be followed and planned for ahead of time.

Simon Gibson: Yeah. That's amazing. I can't tell you the number of times I've had a data center 10 miles away and not had the out of band, the machines and had to drive places. So it's pretty impressive that they can get to like a console to get the thing out of a net 5 or wherever it was.

Steve Ginsberg: Yeah and I think it really goes to where you want to think these things up front. And I think as we look at security programs, “What could possibly go wrong?” is a great question.

Simon Gibson: Yeah, I think we'll get into it, but one of the key things that I think people don't maybe spend enough time on with security is resiliency. I think we talk a lot about security in terms of cryptography, verification. We talk a lot about availability and integrity. But being able to operate in a degraded state, being able to come out of a degraded state, how to fail correctly, those are all topics for information security. The other kind of topic that we thought of was cops pulling over self-driving cars. I thought that was really an interesting one too.

Steve Ginsberg: Yeah it seems like an interesting potential development, right? Obviously around self-driving cars where we're seeing the bounds of a lot of things and of course we've already seen people hack features of cars, and you know having the ability to pull over your car might be something you don't want hackers to be able to get access to.

Simon Gibson: That was one of the topics that we had discussed a few years ago at an old job I had. It was the notion of ransomware hitting your smart car. So when you're speeding down the freeway at 80 miles an hour, suddenly you get a text that says ‘if you want control of your brakes in five minutes,you better wire some money or we're gonna do something to you.’

Steve Ginsberg: Yeah, that wasn't the case I had thought of but it did remind me of the movie Speed.

Simon Gibson: Very much so. I mean with connected cars, all these sorts of things [could happen]. You know I mean there's this good and bad side to it, right? Steve and I have been friends for quite a while and one of the topics that [came up and] we decided to discuss was: what's it like to build a security program as the CIO? We're going to cover the sorts of things that you need to know if you are the CIO and you've been asked to build a security program... things like: where do you start? What do you leverage? What do you keep? What you outsource? How does your program fit in with the rest of the company? And finally how do you report on and track that? That's coming up. Stay tuned for Right Size Security.

---

All right. So let's kick this off. In your case Steve, I think your leadership and exact staff team at some point looked at you, at your company and said, “We need some security here.” Tell us about what that was like for you.

Steve Ginsberg: Yeah so actually for us, it was a more ‘bottom up.’ So having designed a security program and then spoken to peers about this, organizations come to this a lot of different ways. So depending on what the situation is in the company, you know first of all, as we said in the opening, you might be inheriting a greenfield opportunity or you might be coming into an existing program.

Simon Gibson: So your exec team didn't come to you? You had the guys and the engineers come to you and say “We need to do something about this”?

Steve Ginsberg: We really moved it. Yes. So there were individual events that ultimately contributed to our security program. And I feel good that in the situations I've been involved, I've often worked with really great technical leads on the systems and then on the network side. And also security and form developers, and so in the companies I've been a part of, we've always designed a bit of security as we go. And so the audience would be familiar obviously with good Unix security if they're Unix Linux people, or good Windows security if they're good Windows folks, or Mac or whatever platform that you're on. So that type of thing that was... in all the companies I worked with, there was at least a healthy amount of that to start.

And then I think in looking at a more formal program, certainly in the case of Pandora as a public company, moving towards that or even as a company that had strong internet presence that was well-known, it became very clear to me as an IT leader that I would want to have a program with great security. And part of that is absolutely protecting the brand and keeping the business moving in the right direction. And part of that quite honestly, is also a personal piece of not wanting to have that interruption of having a security issue that now my team has to get involved in.

Simon Gibson: So as it was sort of ‘ground up’ did you have one particular champion? Was it a confluence, did you end up kind of taking the mantle from your champion and becoming a security champion? There are always situations in enterprises where there's some need that somebody recognizes and they choose to go solve it, and obviously that makes and breaks careers. I mean I've seen people do very, very successful big things and really send their career a long way as a result.

Steve Ginsberg: Yes. So I would say that I became one of the champions for security in the company, but there were certainly important contributors who took areas on and and made them really work. And in time as my department/ organization was built, we basically built to sub organizations that were essentially for us the security and compliance portion and then the security operations part.

And so they led important parts of the effort working in confluence with the technical operations leaders, also the development leaders and also folks in other parts of the company. One of the things as you build a larger security program is you realize you need to be in coordination with the finance department, with legal, with the communications department. And then even reaching out to all departments, ultimately of course HR and marketing as well.

Simon Gibson: So after this all came to be and you realized this is what we're gonna do and you I assume you at some point went to your leadership and said, “We're going to embark on this.” What was the first step and what did you need to get done?

Steve Ginsberg: So I think in my case quite honestly, having managed security and been involved somewhat with Internet security over time, well I guess I will say in truth Internet security was really the first thing that we started to look at. And you mentioned resiliency, so availability to the service was a major part that we looked at, so obviously understanding firewalls at the perimeter, including on the web facing data centers and then also understanding DDoS availability. So... what kind of things could bring down our site? So and that’s pretty common for web scale companies.

There's definitely multiple DDoS options, which bring up the topic that we discussed also about whether you rely on vendors or not. So with something that was as large as Pandora, our fault tolerance enabled us to actually sort of self-insure to some degree. Which is that we had wide pipes, we made sure our utilization would be low enough for example that we could sustain some amount of attack in that regard. But then also over time, we certainly brought in products and also used outside services to manage that DDoS.

Simon Gibson: So it was effectively a sort of: what assets do you have and where are they?

Steve Ginsberg: Absolutely.

Simon Gibson: And then there was probably some sort of a ranking, a stack of what's important: the firewalls have to be able to take a certain amount of throughput, or if you're going to do state full inspection or not and how much throughput can you take.

Steve Ginsberg: Yeah absolutely, and I think in our case we're both looking... as being a web scale company there is making sure the product is available the consumer facing portion. And then at the same time in the enterprise, we have the business systems. What systems are critical? What access could be around them? What data is most critical?

Simon Gibson: Give me a sense of scale in terms of... Obviously I think most people are familiar with Pandora and the service, the website and the different... I think it was a little bit of a surprise to me to understand how many different ways Pandora can be distributed: whether it's on a mobile, whether it's on a computer, if it's in a car. So that's sort of the obvious side.

But in the internal systems, the management, I mean there's clearly a lot of music management. There's uptime management, there's there's a ton of systems. Scale size: How many systems did you guys have to support?

Steve Ginsberg: Sure, so it was in the scale of thousands or moving towards tens of thousands.

Simon Gibson: And what services roughly?

Steve Ginsberg: So the the product originally was somewhat monolithic. And then of course over time the development team moved more towards micro service. So now you start to move.... And even from the corporate side, back on the other side SaaS services is a good example... something that totally emerged during the time that I was there and we moved from perhaps having one or two to even hundreds of SaaS.

Simon Gibson: So as the CIO who is now responsible for the security, the reputational security, the compliance, the whole kit and caboodle of security, did you have any special methods to sort of decide what was important and what wasn't? Did you have any formal ways of managing that?

Steve Ginsberg: Sure. So we started with informal conversation. So the good thing about starting in an organization that was at the time, on the scale of maybe a thousand employees (or we probably got started before before that), but moving during that window is, the folks in an operations team, in an I.T. organization, we have a pretty good idea of what's in the business. S

So a number of things could be listed just from our own assessment. And it was basically a combination of what was known what was easily discoverable: so certainly network probes, software that would test what is available on the network. And then we moved out at the same time towards a more formal risk assessment program working with leaders across the company to talk about: ‘well what are the important assets?’

Simon Gibson: What do you need to do here, if it breaks, does your business stop working? I did a similar one and the odd thing I thought for sure it was going to be the customer relations, you know Salesforce was going to bethe one thing across the whole business that if it broke, we're going to all stop. It turns out it was the phones. The phones were the most important thing to... We interviewed 8-10 lines of business, and without fail every single one of them said (for the most part all of them said) that if we don't have phones, we really can't work, so...

Steve Ginsberg: So then work stops, but the Salesforce can get back. In another hour, they'll be fine.

Simon Gibson: If we can't help a customer who's having an outage on the phone, we're in big trouble for our organization or we can't get suppliers, we can't... It was an unusual thing when you start to peel apart these risks assessments.

Steve Ginsberg: It makes the good general point which we're mentioning, but just stresses like ‘speak to the business, don't assume you know the answer is…’

Simon Gibson: Absolutely. What about, without getting too much into compliance and regs, I know those are important, but let's sort of talk about those in complement with talent and retention. How do you sort of assess talent against the sort of compliance and business needs you have and how do you retain and manage that talent?

Steve Ginsberg: Sure. So as I mentioned, I tended to view things of... I have very talented operators and some of them were able to move into this security space. However we recognize we did not have all the talent. So compliance is a great example. That was where we absolutely had to bring in talent to grow that effort. And that's also one that turns out to be balanced. So when you look at compliance,first of all leaders need to understand what compliance they need to comply with. What are the regulations? And so what expertise is needed? So of course in the case of Sachs companies are going to engage outside consultants of the kind of like a big accounting firms at some level, but on our side, we also did a bunch of that stuff internally.

Simon Gibson: You still have to be able to manage the expectations of one of your auditors and somebody needs to deliver the proof of the control so you know you can hire all the firms you want. You still have somebody generating a report that works for you, satisfying the requests of the audit.

Steve Ginsberg: Absolutely. And I think with compliance too, there's the important distinction that some of the audience will know, but compliance is not security. Just because you are compliant, that does not at all mean that you're secure.

However compliance can be used to move security forward. So it's a good time, for example, to separate systems from each other, to segment the network or to tokenize a financial transaction or things like that. Well basically lessening what you need to protect in the future or at least using it to secure those things, those business functions you're going to keep.

Simon Gibson: So that's perfect timing. So after you've sort of done the assessment, you've looked at your capabilities, you've looked at the expectations of the business, how do you decide what to keep and what to get rid of? I don't mean get rid of, but I mean outsource to another department in the company or full on outsource to a vendor?

Steve Ginsberg: Sure. So for me, I always viewed those decisions as ongoing. IT organizations do a lot of vendor management, right? And so that's going to be basically coming first from, as you said, what capabilities do you have for talent internally? What can you do really well, and should you do those things really well or should that talent be doing something more valuable to the business? Is this a valuable use of the talent you either have or can hire and retain? And then what are the vendor options and what's kind of relative cost?

The typical return on investment that you might look at for any kind of outside vendor I think in the security space still applies. So will you get a better return by investing with an outside partner than doing that effort internally? And also are there real capabilities that you just can't achieve in a certain time scale? If you can do a great job on security, but you can't get there in three years and your assets are going to be unprotected, that's clearly a case where you would want an outside service if they can do far better on that.

Simon Gibson: How about in terms of what did you do about situational awareness? Because I know in my experience, there's this notion of: what are you logging and how comprehensive is that? But then there's always this sort of: ‘you don't know what you don't know because you're not logging it’ sort of thing. There's that problem. How did you deal with that?

Steve Ginsberg: Sure.When we went into the security program it was literally as they ask in business, ‘’What keeps you up at night?’ And it literally was something that was keeping me up at night. And the reason was since a formal security program hadn't been started kind of dual fold, which is one, we haven't gotten to everything, as you said, “we don't know our... you'll never know your unknowns” by definition, but we don't even know yet how close we are. We don't even have a sense of that.

And also because we haven't really engaged, I worried from a reputational stance that if there was an attack, we didn't even have a great story for the board or for outside parties about like ‘hey we've done all these things.’ Over time of course so we engage and we built up situational awareness was absolutely something that we built up.

And one of the things that I guess I would point out here too, in terms of the talent assessment is security professionals. There's a very wide range of how people engage with security, with the programs, with the work; and that can be from very... I would characterize on the range of: there might be people who are policy experts, but don't know really to do anything effectively when they log into a system. So they're gonna move Excel and PowerPoint and read documents and that can be super valuable, but it's not... those people aren't going to make you secure through their own direct contributor efforts. So they will increase your security by making you compliant, make sure your policies make sense, doing the communication with your organization. So very valuable, but different skills.

And then in terms of operators, there is a wide range of sophistication too, of those folks who will just operate tools that exist and there can be a great range of security that you can get that by using good security tools that have consoles say, if you get to a single pane of glass, you can have people monitor that security and follow workbook cookbooks to do things. But then I was fortunate enough to work overtime at multiple organizations with folks who were strong enough to program security, and I think that's a significant part: to be able to break through open source tools, to be able to write Python and similar, to really bring together logging systems that are very sophisticated and can provide deep monitoring. So I think that's a big piece.

Simon Gibson: I definitely as the CISO in different sort of types of CISO roles, somewhere where I had sort of a large team that was busy writing code and actually responding to incidents and doing pen tests and product security versus when I've been a CISO running sort of a small city operation center or had fewer resources, the world I always found myself living in was this sort of world of the boss saying “You know you you're not looking hard enough. Are you sure you're looking at everything? Do you know you're logging everything? Or you go to the boss and say, “hey look we had a small breach, this is what happened.” “How did you let that happen?” So I find as the CISO, you often are the person who has the single throat to ring. And so to be able to think from the CIO's perspective is super useful at least in my experience.

Another thing is the flow of the company. Obviously if you're in charge of the technology as the CIO, it's not only security, and security can absolutely stop a business process. I mean I had a story where we decided to disable USB devices. So we went around the whole company with 12,000 people in 200 something countries and said “Okay, who needs USB devices? because we're going to turn them off.” And 100 people came back and said “yeah our group uses them” and we went ‘OK.’ We left them on in the group policy. We flipped a switch and suddenly there were just people with pitchforks at our door going “What have you done to our computers?” We said, “well we asked you” and they said “No, you said “Do you need USB drives? These are jump drives. You turned off our jump drives.” And we went, “uggh,” you know like we broke their whole process.

So as the CIO it's very much the same thing. You implement an upgrade, you implement some end of life thing happens, you bring in a new SaaS product program. How have you thought about like working with the rest of the company? Not just assess where the business processes are, but working with like procurement and HR, and how do you think about inter operating with the company?

Steve Ginsberg: Right. I think it involves this kind of multi-level approach. So there are some efforts that we could easily identify this change, [and] only the affected group will be limited. So in some cases even it was only folks in my own organization. We need to change how systems administrators do X or Y in order to improve security. So those are pretty easy to manage generally, although there can be times where even that's going to be a tight... Scheduling can be an issue, communication can be an issue. That was a great example of where you did communication, we just didn't know what you were talking about.

And actually we spent a lot of time with audience certainly when you get on these kind of rollouts that go to the whole whole company, communications style becomes really key. And then you find out also in the modern age, people maybe don't even read email after a certain amount of time. And that was something culturally I've always had a thing [about], because for me, I was always on email..

Simon Gibson: Not me. I think by the 13,723rd corporate communication email, I just broke a rule and deleted them. I figured if this is important enough, someone's going to come to my desk and say “hey you need to pay attention to this.”

Steve Ginsberg: And you certainly have you find out that communication, and this is true for issues outside of security as well. But in this hearing space you have people [who] want to be informed, in terms of they don't want to be surprised. Right? They don't want anything to happen to their work that they don't feel like they were... and it's not just informed actually. They want to be, in that case, consulted about what the best ways to do things are and so they really want to be [involved]

Simon Gibson: If it's a business process that changes their workflow. You gotta have their ‘buy in.’

Steve Ginsberg: Absolutely. But on the other side, most folks in a busy modern environment actually don't want to attend a meeting to do those things. They don't really want to be on an email about that or a call. So it's really a very delicate balance. And of course getting that right is important, and so you have to spend the time to figure out who can...

One of the things that can be effective if I can maybe offer a solution, is to find out: are there important folks (and we did a bunch of this), within an organization where you can get the ‘buy off’ of someone in the organization and then they can communicate at their ‘stand up,’ that kind of thing, so you don't feel like you necessarily have to go to all meetings for everything. And then on the other hand, we did certainly find that sometimes sending people to stand ups or similar was super important...

Simon Gibson: Did you try to implement a BISO program like a business security expert? That sort of head of security in a business unit, so you identify 15 or 20 business units. You pick somebody in that unit who has some sense of the importance of the business and the workflow and you deputize that person in that unit to be in charge of security for them, and they report back up to you, or the dotted line back to you?

Steve Ginsberg: Right, so we didn't do that aside from the application security effort again was kind of relying on strong contributors for a while, and then we discussed over time: when would be right a right time to grow that effort? Right. And so that was basically software development grew their own small security organization to work with others there, educate, and then also a lot of meetings back and forth to make sure that communication was continuing and happening and we were tuning. Quite frankly it takes some tuning to get that because development security their views... in a product organization, the priority is to get product released.

And so one of the great learnings there which is well-known in this security community, but might not be well-known everywhere, is get upstream. Make it so that you have tools that when developers check in code, they just get a quick score right there, so that they can just fix it then, and you're not having to fight with production deadlines.

Simon Gibson: And is that work you wound up doing or was that sort of taken on by the head of engineering that then sort of consulted you afterwards? Or did you sort of go to the head of engineering and say “hey you know I'd really be nice if you put some sort of code sanitization or code scrubbing in front of this?”

Steve Ginsberg: Right. Yeah. So I think that was our recommendation coming from... we looked at obviously O-op standards and NIST standards and things like that. So I think my team kind of grew that. They may have already in our case... maybe development already had an idea that that would be coming, but I do think that my security leaders certainly at times educated the development teams and I think the development teams... it works both ways, right? There's gonna be pieces, for example when we went to go mobile security where we wanted to secure people's phones. That was a very active conversation with end users throughout the company, but certainly developers who had strong opinions about what could sit on their phones.

Simon Gibson: That's a whole can of worms let's open it. Why not? One of the problems I've certainly faced (and I've been in many companies where this is the case), if you're going to go to a programmer who's capable of running a very secure laptop or at least well secured, patched, updated, understands what's on their system, understands processes that are running things that are injected into memory, really knows their system well and is good at keeping their computer running nicely, can your IT team and are you able to support them in such a way that is as good or better than themselves? And if you can't, how do you then have that conversation with the programmer that says you need to use the corporate image?

Steve Ginsberg: That's certainly an interesting issue and I've talked to folks at different companies who've had to kind of address that. You know I don't feel like there's one perfect answer. There would be a perfect answer if there was a perfect suite of security products. If you could get products from a vendor that could be installed in a way that could be agreed that did a better job than the best individual, then you can easily say “hey look this keeps you productive and it provides the best security.” So your job is to develop, not to do security. This is perfect now.

Simon Gibson: Right right.

Steve Ginsberg: But free of that, and it's a conversation.

Simon Gibson: As any vendor or anybody who's thinking of a startup listening to this right now is probably going, ‘that's what we ought to be building right now.’ But no, I think the reality is for me personally: I had a lesson once where we did an assessment. We were hiring a third party Instant Response Team. I was at a company [where] we were building out our program, [and] we were probably six months to a year away. What you said earlier about if something happened, I needed a good story, right? I needed to show not only my board, but my executive staff and our shareholders, we were actually taking this seriously and doing stuff. So we retained an instant response company and we went through an assessment with them.

One of the things that shook out of it was the need to be able to access an employee’s laptop for potentially intellectual property, insider threat. Are they doing something that they should not be doing on your network, and if you allow the programmer to have their own laptop with their own password as the security team you don't necessarily have the option to forensically image that laptop, where if it's a corporate image, you actually have that. You say “This is our corporate image, [so] you have to give it to us to forensically image.”

And so I've never used that argument with a programmer, but I wonder if that is not something that a programmer might go “well I would let you have access to it or I can give you the root password and you can check my laptop once a month or randomly and prove that you can always get onto my machine.” Yeah so I think that's really what we're trying to do. I don't think we're necessarily trying to take control away from programmers or control away from people. I think we just want to know, as an enterprise, that whatever is on our network is something that we can then go back and audit and make sure is up to at least the standards we have.

Steve Ginsberg: Yes. I think enterprises have these trade offs in different places with employees and we all want a place where our privacy and our individuality is protected and is held true. And I think those are important things to do as well as you can. And I think that it's become common also in enterprises to say “well it is a corporate laptop, your work when you do here that it has to be ours because there could be legal discovery, there could be reasons we could be liable for what happens there.”

And so I think a big part of that is getting the communication up front that the policy is very clear when you join a company, or if that's something you have to add after the fact, that it's added very clearly changes to policy: ‘these machines will be corporate mail.’ And I think what there are issues like this in security that have gotten a bit easier over time, which is more people are used to this now than I'd say when I was managing the same issue 10-15 years ago, people were more surprised that a company wanted to say “This is my machine” or “We might monitor network connect communications,” things like that. It may be different in the finance space.

Simon Gibson: Well in the finance space, my experience has been certainly that it's quite locked down. I will say though that just me personally, as somebody who is pretty keenly aware of what's happening on my machine at most times (and I've looked at some of the software and some of the backup things that sort of software IT wanted to install on my machine) and I wouldn't want any of that stuff on the machine. It presents more of a risk, you know.

But I think there's a statistic that IBM has and it's something like per thousand lines of code, there's something between four and eight errors. So the more code you put on a machine, the more likelihood there are errors. So if there's stuff on my machine that I don't need or want, like you're just introducing new threat models and threat profiles onto my...

Steve Ginsberg: Sure, and I always think of the Kaspersky thing at that point Kaspersky, who makes security software, they themselves were hacked. So you know an IT organization was trying to do the right thing or many of them were, install that software and then you're making the machine actually less secure. Never mind that it's not more secure. It's actually less secure.

Simon Gibson: [I was] at Bloomberg when we did large assessments and we're looking at deploying software to 40000 machines, a vulnerability in a piece of software we did an assessment on is a deal breaker. Like if we deploy software to 40000 machines and somebody figures out one problem with it, they can now own 40000 machines so it's a big scale problem.

So one of the last [things] as we're kind of wrapping and getting onwards to the end: tracking and reporting is one of the ones that I always really struggle with. I managed to develop a system wherein we would record every incident we find big or small. We rank it, we use sort of a CVSS like ranking. We track the time that was reported. We track the time it was started, repaired and the time it was remediated, and we'd sort of over time say whether it's a virus on a machine or we know somebody doesn't have the rights community string on an SNMP router configured properly, it’s public or we don't have the right segmentation on the net everything right all the way through. And we kind of rank, we score them and then we can over time track basically how much we're spending and how well we're doing in terms of fixing them. And that was about the best way I'd found to report on it, but I know there must be better ways.

Steve Ginsberg: Sure. So yeah, I think absolutely the first level which that was a big piece of is ticketing any security effort, work that's getting done, and then separately having some form of project tracking. Of course there's so many different systems you can do that in, but have proper project tracking for major efforts.

For me I would say we did struggle with it also and then it mostly filtered into just our overall IT reporting. So what projects are we working on? Are we doing a budgeting project? So I felt like those flows could be unified mostly, but separately we did more in detail meetings with heads of product so that they knew what [things] are we doing that are affecting their team. And so part of that is what we were talking about before: about giving good ‘upcoming’... ‘these are the things that we're working on that are going to land on your teams that you want to know about.’ And then a lot of that then also was ongoing.

So for example, like a mobile rollout or something like that... anything you know, production firewall changes, anything that's going to affect the development and the product teams. Also not only some formal data, so those meetings would include graphs and slides and things, but also the conversation that says “well you know this is what we think you think is most important and also ‘ears open.’ What do you think is important [enough] that we're going to give you a chance to tell us what is important that we might be missing.

Simon Gibson: That was a good conversation, Steve. I enjoyed that.

Steve Ginsberg: Yeah I enjoyed that as well. I thought maybe for our audience, we should just look back and say “Have we really given good advice on how to create a security program overall for the CIO? Obviously this going to be different for different size enterprises. But I guess if I look back at what we were thinking about, I would say prioritizing is the most important thing you can do.

You know it took us a while to discover that common security in depth. Yeah there's not one move, even when you get all the way down to a machine and you're buying software, you might not make the move that actually makes you more secure. Right? So how do you create a system that has many places where you're making it more secure, and do it without overwhelming the talent you have and the budget that you have to do that effectively?

Simon Gibson: Right. It's that it is definitely that prioritization and it's that assessment that starts from it. Do the assessment, do the prioritization and figure out what you have, what's your talent capable of. Obviously there's some budget constraints and you want to understand your budget for the next couple of years. Who can you hire? What can you spend and what are the most important things in your business?

I personally when I think about a security program, I think about what is going to put us out of business? If the human resources database gets compromised and everybody's salary gets out, that's pretty embarrassing. I never want that to happen. Probably not going to put us out of business, like it's not a good thing but it's probably not my most important thing. You know if we ship a piece of software that somehow causes a nation state to then attack the Pentagon because it was our software that we released, that's probably gonna put us out of business, not to mention to being terrible. So that's kind of how I think about in terms of prioritization.

Steve Ginsberg: Yeah absolutely got to look at the reputation of the company and real potential legal issues for the company or compliance issues that are going to interrupt business.

Simon Gibson: Well that's right too, that's the auditing part. So are we in compliance? If an event happens, are we reporting it properly? Are there the controls in place so that if a machine that deals with finance has some sort of a problem are we reporting that correctly back to our auditors? And that kind of thing. What about outsourcing? We talked a little bit too about what do you keep and what do you not do?

Steve Ginsberg: Sure. So I think vendor management is a very important topic obviously for businesses across the board and in the security space. I had a lot of trouble trusting outside parties. Initially we want to build up. I can put my hand on the shoulder of these folks who I know well if we have an incident and that kind of thing.

On the other hand, over time I felt for example with cloud, it's likely that Salesforce is monetizing their security effort for an internal product or for their product more than I can for my file servers. So as much as I know: well my team does a good job managing file servers, I know that at this point, a large cloud company, they're going to have a deep team and that kind of thing.

And so there are places where you absolutely can make a good leverage choice but you also have to consider [that] well one day that choice may also still fail. What am I going to do there? Is my data backed up somewhere? Can I keep moving in another system?

Simon Gibson: Right. I know for me in supply chain specifically, there were certain things that I know wouldn't work like employee database for example. Don't want to have it get out, but if it's in the cloud sending it to something like Workday, probably not the end of the world and I also know that because it's sensitive data and they take it very seriously, it's their whole business, and Fortune 100 companies are using them. Those companies are also doing security assessments and pen test.

So if they have 10 of the best red teams in the world go hit Workday. I am now benefiting as a result of those pen tests. So I am getting a heightened level of security and I'm actually getting something off my network. So now I've got one less thing that I actually have to be concerned about. Now it really truly is in your universe.

Steve Ginsberg: One other thing that you touched on that I just wanted to bring up is maybe also looking at security being about herd mentality, which is you might not be able to get to the 100% place on your security efforts. You know if you have a very well financed program and you really do everything right, maybe you can. But it's so much better to get to 80% or 90% than not much. And so I think that leaders shouldn't be paralyzed by ‘oh my, we can never get all the way there’ you know, don't let the perfect be the enemy of the good...

Simon Gibson: The other argument that I always had to come up against was the programmer who said “Well you know it's always been broken like this” or “so what's the point of fixing it?” I mean it's like well clearly there's some esoteric really hard attack that could possibly break into the system. But the reality is we can still do these other things.

It is a defense in depth mentality and again it's really: keep the cost of the attack greater than the value of the target. I really do think that's absolutely true. You know if this attack is so expensive that you're going to burn tons of hours and tons of zero days and tons of money and it's gonna be really, really, really hardcore, it's got to be something really worthwhile at the other side, so you have to adjust your program in equilibrium.

Steve Ginsberg: We used to also like to say that you don't always have to be faster than the bear.

Simon Gibson: You just have to be faster than the other guy. That's right. So then the other part was: how does it fit in with the rest of the company? I think we kind of hit that really. It's at least for me as far as the security person working with the networking team and the engineering teams, it's a lot of horse trading. I think in this case as the CIO, you have a little bit more control around when things get done, although you probably still have to horse trade with other businesses about when you get stuff done, right?

Steve Ginsberg: Yeah. That's the way I look at it. And yeah in a perfect world, you could make the enterprise perfectly secure and it's seamless to everyone; no one is ever interrupted in any way. But like a lot of things in modern business, sometimes establishing ‘No, there will be certain windows where things have to happen,’ like any operational upgrade. You may have to establish some of that.

Simon Gibson: And then finally track report your progress. Keep tabs, keep as much data as you can and figure out a way to summarize it that makes sense for your business. I don't know how valuable it is to say “we had 150,000 hits to our ePO console and we cleaned them all up and there was just adware that we solved.” But you're keeping track and you're saying: we have this much and this is what we're seeing. And over time you can start to track it. So write everything down and then trend it. And what is important will start to come out.

Steve Ginsberg: Yeah absolutely.

Simon Gibson: All right. So that’s it., This was the very first edition of Right Size Security. I'm your host Simon Gibson.

Steve Ginsberg: I'm Steve Ginsberg.

Comments are closed.