In this podcast recorded at RSA Conference 2017, Todd Bramblett, President of Nehemiah Security, talks about why cyber risk has become such a hot topic, the importance of IT operations and cybersecurity working together, as well as the AtomicEye RQ platform.
Here’s a transcript of the podcast for your convenience.
We’re going to spend some time today talking about cyber risk. Can you give us a brief introduction to yourself and your perspective on cyber risk?
Sure. My partner and I, Paul Farrell, started the company in 2015. We have both got business backgrounds primarily – I was a CFO, started in accounting many, many years back – and typically approach things with an ROI sense of things, return on investment. And we’re trying to bring that business-oriented, business-driven security mentality to this marketplace. Where cybersecurity is very technical, we want to have the technical married up with the business risk and consider both pieces.
We hear a lot about cyber risk today. Can you give us an idea of why you think cyber risk has become such a hot topic?
Cyber risk is such a hot topic, I think, because the world has gotten very complicated in cybersecurity. We have point solutions, we have network point solutions, we have endpoint solutions, we have endpoint protection, detection, remediation, the list is endless. But at the end of the day, the question is, ‘Was it effective? What’s my resulting risk?’ Because a ton focus on the inputs, the efforts, but is it actually working? And that’s where we’re fuzzy. We don’t know what’s working and what’s not working. Sometimes patches on Microsoft Tuesday might close some holes and open others. So we don’t know what the end state of the company’s risk posture looks like.
We’re saying, ‘Rather than focusing on the endpoints alone, let’s focus on the end result.’ What’s the end result is what’s the impact up to the business of the particular risk posture they’re at. So we believe that risk is such a hot topic, but it should be, but we’re trying to measure this risk – is always the trick. Say on a scale of one to ten, are we at an eight, a seven, a six, a five? I don’t know. Well, we spend millions of dollars. Where do we stand? Nobody has an answer to the question, ‘What’s our current state?’ And they certainly don’t know, ‘What should our future state look like?’ There’s no way to measure this today, and that is a big topic because of that.
I hear you talk about investment, I hear you talk about technology, I hear you talk about results. Who, from within an organization, do you find needs to be involved in this conversation to help make it work?
I think this is the trick. We actually identified, as you know, the top ten problems that the cybersecurity industry is facing, one of which is there’s an inherent conflict and a mandate between, say, IT operations, which is ‘help the business accelerate’ and cybersecurity, which is ‘secure the business’. So, help grow the business versus secure the business. These two have been opposed to one another, but that shouldn’t be the case. They’ve got to work together.
Extend this idea of IT operations and security being opposed to one another; they should work together. You can extend this into the C-suite. So you have the CXOs, CFO, COO et cetera, all the way up to the board. We need these three to all have the same goal in mind. They’re going to have different views of what’s important to them, but if they’re not working in concert, they might be working at odds with one another, and create tremendous confusion and poor investment strategies on how to secure the business.
So you just talked about the need to bring the business leaders, and the security leaders, and the IT leaders together on this challenge. Are you seeing any best practices emerge that help them do this within an organization?
I’m not sure how many best practices are emerging per se, but we certainly are trying to promote our own, one of which would be a common system where while the screens, the dashboards, the metrics that they’re looking at might be different, they’re all coming back to us as common core. So the system might be interested in network parameters, and endpoint, and all the different point solutions, where the business leaders on the far end of that are thinking budgets, security; because there’s many ways to solve the cybersecurity problems – they have to get insurance. Buying another application might not be their only answer. They think, ‘Well, I’ve got ten million dollars to spend. I’m going to put two into insurance, I’m going to put four into endpoint, I’m going to put two more into my already very substantial network, and I’m going to put two…’ You know, they have to decide where they’re putting their money.
If they don’t have a common language, a common platform where they’re working together, it becomes very difficult; and the CISO can’t explain to the CFO or the board why they need what they need, and the board can’t understand what in the world they’re even talking about, because CISOs talk a language that CXOs really don’t get very well. Having common business terms where it does actually often come back to financial, ‘What’s the result?’ ‘I’m going to put x amount in. For what back?’ This seems like a wise move to create a common platform for common language.
I know that Nehemiah Security is an active player in the cyber risk market, and I see you that you are featuring AtomicEye RQ for risk quantifier at this year’s RSAC show. Can you introduce us briefly to AtomicEye RQ?
We’re really excited about it. This platform was built over eight years with an intention, really, of attack. It’s from the ground up, always been an attack platform. It’s been used in arenas that I really can’t talk about, but we’re commercializing it, so it’s no longer classified, at least the components that we’re commercializing.
This platform is exciting because it allows us to focus on the end result of all the money and effort that goes into securing a company. For instance, they have GRC, and they’ve got policy, and they’ve got systems et cetera. They’ve got many things that they’re doing for the inputs, but what is really difficult for them to figure out is, ‘Is my security better today than it was last year?’ It’s very, very difficult to answer that questions. There’s plenty of systems focused on inputs, we want to focus on the end state. After all their efforts and all their investments, what is the end state?
So with RQ, we do four things. We, first of all, clone the system. So we literally read and clone the current state of the system. Whatever inputs have been put in, whatever dollars have been invested at some point, as of the moment we test it, there’s an end state, so we clone it. Then, we configure a test that has hundreds of thousands – it could have millions, but today it has hundreds of thousands – of attacks that can be set against this end state system. Then, we compromise the system, we attack it in this virtual world that we’ve created. So, we cloned it, we configured it, test, attack. Then, we do the attack and thereby compromise the system. When we’ve completed this entourage of attacks, the last piece is we correlate the information. We say, ‘Well, here’s what we’ve found. We have a 97% chance of getting in this vector, we have 100% chance of getting in these seven, we have 84% chance of getting in here et cetera, et cetera.’ Until there’s a long list of avenues for compromise. At that point, the company then can decide, ‘Oh, now we need to go back to the drawing board to try to begin to address these issues.’ But this is a concrete test of the end state, the current state of their systems that is not theoretical in any way – one. And two, it measures and it can measure, for instance, every evening, every time a change is made to the network. Did it get better or worse? It’s very hard to answer that question. We can answer it. It either got better or worse, depending on what we find when we do that next attack.
So it’s incredibly concrete results that the company is going to act upon. And they know now better where to spend their dollars when they’re getting ready to try to close these gaps.
At its core, what is unique and powerful about AtomicEye RQ?
We bought the company with this product, because we thought that there were many things that were unique about it. Let me start back one second. In the world of analyzing the end state of a particular company’s network and endpoints, what’s typically done as some form of the service’s consulting gig where we come in and we look at their governance, risk, and compliance; we look at their adherence to policy, we look at the number of stakes they’ve applied if it’s a government facility, we look at many of the inputs, but again, what’s not looked at is the end state result.
This application takes an actual system, a network with all its endpoints, and looks at the end state. Not like a human would with a services organization where I might take hackers and I might say, ‘Let’s try a pen test here on a particular date. And I will have my best three people attack the system, do a services-oriented pen test.’ At that point, as they begin to do the attack, they cannot possibly use or employ every combination or permutation of doors. So they get through door one, they go for door two. They get through door two, they escalate the privileges to door three. And eventually, they get through the tenth door, let’s say, and they’re in the system, and they’ve got all the privileges they want. That is one path through the system that they were able to find. What RQ does, it takes every conceivable path. So that’s a big difference. We effectively have an unlimited number, an infinite number of pen testers, if you will, in the sense that the system is giving the pen testing, it’s not human – one. Two, it’s been used in the filed for eight years. While it’s new for commercialization, it’s not new at all in regards to its technology and its intellectual property. This is well used with tremendous background over those eight years.
Third, because pen testers will do something as a point in time, they’ll do it today, and then in whatever, in a month or a quarter, they’ll come back as regulatory requirements might demand, they come back and they do it again. But there’s been 10, 20, 100, 1000 changes to the network and the systems in that time. Did the door open and close within the 90-day window or did it get left open in 90 days? Pen testing, fundamentally, is – being a service’s orientation – is only able to be done on a punctuated one time, now, do it a little bit later, do it a little bit later. RQ is continuous. As soon as we see a change on the network of any kind from any source, we kick it off again. So, applied Microsoft Tuesday patches. As soon as that happens, we kick it off again. Someone modifies a particular whatever, DLL gets modified, register keys get modified, we kick it off again. So, every single change can be reviewed as to the result that it’s having on the network. That’s something humans could never do unless someone would want to spend hundreds of millions of dollars on a thousand people sitting there doing this. It’s not practical. We do this with automation.