Why Controlling Time Matters

January 29, 2019 Editor

Your browser doesn't support HTML5 audio

Why Controlling Time Matters An Interview with Arun Sood

An Interview with Arun Sood, CEO of SCIT Labs

Cyber Security Dispatch: Season 3, Episode 2

Show Notes:

Welcome back to the Cyber Security Dispatch. This is the first in the new series of interviews focused on innovative technology in cyber security where we talk about new solutions to protect our data and systems. Today on the show we welcome Arun Sood, CEO of Self Cleansing Intrusion Tolerance (SCIT) Labs. He is the co-inventor of all six SCIT technology patents that are based on the research undertaken at his research center. In this episode, we are setting the clock on why controlling time matters. Arun is an expert on moving target defense and building resilience systems. He offers a refreshing perspective on how controlling time can give security teams a key advantage in stopping attacks and limiting the impact of those attacks. It is a really fascinating perspective and one that can help you see things differently. For all this and much more be sure to tune in!

Key Points From This Episode:

Understanding moving target defense.
The resilience requirement: continuity of operations.
Providing higher levels of security through diversity and redundancy.
How redundancy can be used to achieve a dual goal.
Understanding the concept of diversity.
How complexities affect cost: the additional expense.
Why you can’t change the implementation in a redundancy based approach.
Dwell time: a measure of how the server is performing.
Steps of a cyber-kill chain.
Understanding the SCIT system.
Thinking of data in three different ways.
Recovery systems in the cyber security space.
How to think about measuring success: what does it mean?
Two principle things to start with as a small user.
Choosing your throttle time.
And much more!
Links Mentioned in Today’s Episode:
Arun Sood — http://scitlabs.com/about-us/team
Arun on LinkedIn — https://www.linkedin.com/in/arunsood/
SCIT Labs — http://scitlabs.com/
George Mason University — https://www2.gmu.edu/
Drupal — https://www.drupal.org/
WordPress — https://wordpress.com/

Introduction:

TRANSCRIPT

[0:01:05.5] AS: I am Arun Sood and I am a professor at George Mason University but currently, research at George Mason has led to six packets and at one stage, we decided to start a university startup, we are a group affiliated to George Mason has equity shares in the company so there is a close relationship between the two things. I’m the founder of this and currently in the CEO but I see we have a chief architect, we have lots of people who are helping with us and how this is going to evolve is only time will tell.

[0:01:46.7] AA: Yeah, I think, you know, one of the things that was so interesting about what you got up to is you’re sort of focusing, you’re focused on moving target defense so that’s a concept we’ve talked a lot about on this show but for those who kind of aren't familiar with moving target defense, you just want to kind of talk about what it is and how you kind of how you kind of got involved in it.

[0:02:07.3] AS: Right. There are many ways to look at this but I’m going to try something slightly different based on my experience recently at a conference in Tampa. Think of the following issue. Server security is something which everybody needs for their systems but it is becoming more and more clear that people also need resilience. Server security means the bad guys, when they come in you make sure they don’t stay in so you may have to shut the system down but that is not good enough for people who have to have continuity of operations.

The resilience requirement is that you have to have continuity of operations. Now, if the two systems if you design your systems to be static, now you have a problem. If the system is static and you shut it down, it loses all the continuity of operations. We need a potentially need a dynamic solution and the moving target defense as we see it, as we have used it, as a mechanism, which it creates balance between these two things.

[0:03:16.9] AA: Yeah, I think if I understand you correctly, there’s that this sort of opposition between two things, right? If you imagine, what a lot of systems are measured on is all the time, right? We are continuously to make it simple like deploying popper, right? We need to have the five nine’s right? 99.999% of the time where the system is on and then the classic way of thinking about cyber security is to actually shut things off because there’s problem there.

How do you sort of square that circle? Is that, am I understanding it correctly?

[0:03:48.7] AS: That’s exactly right and I think we got to make sure that we understand a resilience system is not only, has to operate continuously but it Is expected to perform even in the presence of an attack. Many of our systems are, which are operational, they may have bad guys sitting in them but they keep operating. Because of the read me generation and so on and because of the importance of the system, their continuity of operation is critical, you’re actually right.

This provides a challenge, the challenge is, if you have a static system, that system is not changing and you, somebody comes and sits on it, if you shut it down, you’re in trouble, you don’t get continued service.

[0:04:32.3] AA: Yeah, I’ve seen some interesting kind of models, different graphics where you’re, when you’re thinking about system design. You know, thinking about essentially redundant pathways, you know, multiple methodologies for delivering a service or allowing whatever is information travel and then essentially as you look at that design, understanding essentially assessing it based on how much of the system could be compromised and you can still essentially still deliver service or accomplish the mission, the task, et cetera.

You know, I’m not a systems engineer, that’s not my background but that seems like not a concept that the majority of systems or at least many systems are built with at the offset.

[0:05:20.0] AS: You're right. Many systems I see, they don’t have security as one of their requirements, it’s sort of bolted in at the end of the process, which is, makes it a challenging situation. But the idea is quite straight forward, less designer systems in such a fashion that you realize it is going to be compromised, because it is going to be compromised, we have to do something to handle the compromise and yet maintain continuity of service.

There are in my view, there are two basic ways by which people provide higher levels of security and one is through diversity and the second one is through this whole idea of redundancy. The redundancy idea enables you to actually maybe can help you achieve both things that you’re able to switch things around so it’s not static. If you make the system none static, there’s a higher probability that you can achieve security as well as redundancy.

[0:06:31.2] AA: Yeah, I think. Walk us through on a simple, how individuals are doing that? If you think about either together, diversity and redundancy or one and then the next. How, when a person kind of understands that those are beneficial qualities. How can you add those two a, to a system?

[0:06:52.9] AS: Right. I’m going to talk a little bit how redundancy can be used in the case of diversity, we have a particular challenge and I’ll come to that in a second. Let’s talk about redundancy. The idea basically is if you want to get high availability, what do you do, you use redundancy, you want high availability, you have to serve the customer in sort of just relying on one box you may have two boxes or three boxes or let’s say you’ll have multiple servers or even if they are on the cloud, you can have multiple servers and those servers, if one of them goes down, the other one takes over the load and you are not having continuity of service all the time.

That’s one paradigm. If you do redundancy now and from the view point of security, you have this redundancy, you can do continuous checking and say okay, is one of these boxes busted? If it is busted, they’re basically, you can take it offline and you can have continuative service. Fair enough?

[0:08:05.5] AA: Yeah.

[0:08:06.5] AS: Okay, now, let’s go to the other one to the whole idea of diversity. Diversity, you can apply at lots of levels, all the way from the application to the operating system, down to the hardware and that is in my experience, talking to CSO’s if you try to do diversity at a high level, they look at this as a very expensive proposition, there have been people who have tried to do this to elegant mechanisms but this has been a constraint so far.

There are ways by which for example, is a large kind of approaches, which can provide diversity at a lower level and it is not as effective as if you were to do a diversity to higher level but it may be good enough for many situations. Is that a reasonable explanation?

[0:09:06.6] AA: Yeah. I think you’re hitting upon the challenge that I think a lot of people encounter when they start thinking about adding diversity and redundancy, they’re concerned about perhaps certainly the additional cost, probably in dollars but also in kind of in investment in knowledge and expertise that their people need to have, they’re worried about, I barely –

I think if behind closed doors, when you talk with a lot of sort of senior leaders in the security space, they’re like, “We’re barely kind of treading water trying to keep up with what we’ve got, adding additional complexity, you know, only scares me. I feel like I definitely be drowning that.” How do you kind of think through that, that additional expense or complexity?

[0:09:58.1] AS: Yeah, I think that’s a very good question. The question is that you can have different types of complexity. As you increased some complexity then the cost is higher and some of the kind of complexities the cost may not be so high.

As I gave you this example, if you’re in your shop, you decide to use four different operating systems then you have to train everybody on those four operating systems, this can become a very costly operation.

[0:10:28.4] AA: Yeah.

[0:10:28.9] AS: On the other hand, If you were to look at diversity, you have to then balance the question of what level of security are you seeking? The way we have tried to post this thing more recently is to talk about this whole idea of dwell time. You're asked a question, how much dwell time can you tolerate? If you can allow for higher dwell time, the cost that is the level of redundancy you require goes down and the cost will go down.

If you want very good systems and hence you want, you have a – your risk profile is very high, in that case, you may want to have a lower exposure and that will increase the cost. The after I translate some of these ideas into cost of implementation so that a user can make adjustment. “Okay, I think I probably have four hours before the bad guys can do much damage. Let us change things every two hours.” You see the logic of what I’m trying to get at this. Use that logic to decide on how you’re going to do this but there is one thing that is very important in my view point.

If you do a redundancy based approach, you have to make sure that you do not change the implementation, you do not go on changing the things like the application, things like the operating systems. You don’t go on changing these things for each implementation because that increases the cost.

That’s what we have focused on is trying to see if you have – if you are using something, do you want to be able to use that same platform over and over again?

[0:12:19.9] AA: Yeah, let’s take in a little bit on SO, for those listeners who kind of don’t think about or as familiar with the idea of dwell time, that’s basically just the time that an individual is connected or inside a system. Now, that can be just so we’re quite pointed is dwell time measured for every user or we measuring it for only users that were perhaps concerned are negative or a threat.

[0:12:49.4] AS: Okay, the dwell time is really a measure of how the server is performing., what we are doing is reducing the dwell time on the server. Maybe, let me sort of conceptualize this from a higher level. f

[0:13:05.9] AA: Yeah, I think they’d be helpful.

[0:13:08.3] AS: Okay, if you think about this, a cyber-kill chain has basically got three steps of it. You can divide them further and more detail but the three steps are easy to understand and easy to explain. The three steps, the fourth step is somebody has to get it. This is usually done through a phishing attack. They get into somebody goes to their desktop and they click on something and the phishing attacks starts. That’s the first thing, get it.

The second step is, once you get in, you have to do a lateral move to get to where the data is. If you got into some user’s laptop, that’s okay but it’s not – that’s not, we have the damage is going to be done, the damage has got to be done inside the, on the place where the data is, which is usually a server.

After you get in, you go through what is called a stay in step. The stay in step means that you will do migrate to where lateral moves and so on and migrate to where you want to do damage. The last step is the whole step of act. In act, for example, if you’re entrusted in stealing data, you want to do data exfiltration so the action is data exfiltration.

There’s some rules about data exfiltration. If you try to do the exfiltration of the highest speed, you’ll get detected very quickly. When you do this data exfiltration, you have to do this at a fairly low speed so that means it takes more time but you have the time because you are resting there and you're sitting in there. And you can take days, weeks and months to do your complete exfiltration. Get in, stay in and act.

If we can manage to reduce the amount of time, somebody stays in and the time for act, we are going to make sure that the losses are significantly minimized. That is what we call the dwell tech, that’s the amount of time you are giving the attacker to stay in the system.

[0:15:23.2] AA: Yeah, I think kind of like rough industry statistics are like the average dwell time that people realize after they’ve had an incident is kind of somewhere in the neighborhood of six months, right? Someone is in there has been at work for quite a long time, right? This isn’t like, I was in for two or three hours, right?

The ability to kind of reduce dwell time to a few hours, a few minutes, it look like your goal was to take it as low as like 90 seconds. Am I understanding that correctly?

[0:15:58.2] AS: One of implementations we have got it down to 90 seconds but you're absolutely correct I think in many cases, something like a dual time of two hours maybe adequate. The point is that the lower the dwell time, there’s a cost impact on the whole thing. We basically recommend a dwell time, which is consistent with your need.

We had something called tellos, which is some testing for DOD insulations, we have them attack our system, which is an ecommerce system and which – they have complete access, we took a three couple time, put it on a system and basically told them, “Look, this is the name of the file, this is its location, there is no firewall, there’s no IDS, no IPPPS, no DLP, none of this is there, go get it. “

When they try to get that file, the discovered that they could get in the system in less than five minutes but extraction of the file was a problem because we were doing rotations every 90 seconds and they can just complete the process in that time. They called up and said, “Look, this rotation is making it more difficult for us,” by the way, this is on their website and n our website described here, this project is describing.

[0:17:18.5] AA: Yeah, I was reading this assessment, it’s really interesting. I will make sure that we link to it in the notice for this podcast so listeners can grab that right on our website.

[0:17:27.5] AS: The point was, if I may just complete the story, they asked us to do an – allowed them to do an automated test. They did the automated test and they came with the same problem because it is way difficult and the second part of this issue is to, want to look as evolving. If somebody attacks us once, it may be difficult to find them but if somebody is forced to attack us twice, three times, four times, five times, it becomes easier and easier to find them.

It is basically if they come in once and do the damage, you may have given another notice there. But if we are forcing them to do this thing multiple times, then our parameter defense systems will know that something is going on. In that sense, that’s an example of how getting stay and act, works with the parameter defense systems, which are really preventing the get in stage itself.

[0:18:27.2] AA: Yeah, we were talking about this before we sort of recording the episode. You know, looking for a single solution is kind of, you’re not going to find a single solution that sort of solves all your problems but when you start to layer different potential approaches on each other, that becomes really interesting, there’s very positive inter play.

Yeah, I can imagine if you are an administrator at an organization and you see, right, the top person connecting is probably like one of your busiest employees but then there’s this other item that keeps connecting, right? What is that? Essentially, by reducing 12 time you were making someone attack constantly, they’re going to quickly bubble up to the top of being a very active account or process. Is that how I’m understanding?

[0:19:19.4] AS: yes, you’re right. We basically use a redundancy operation, a redundancy based system and our system is called SCIT. We use SCIT and we have recently added a component, which examines the system regularly so that we can actually say, “Hey, we don’t know how it happened but you have something, which have changed in your system.”

That has been our approach. Try to find out what has changed, try to establish rules on, which the data should be infiltrated at a particular rate and all this kind of stuff so the thing is, when we are in this process, we are trying to add components, which solves specific problems to give a whole overall solution to the system.

[0:20:15.1] AA: Yeah, is this what you – we were trying to throttling, you're sort of throttling connections, is that potential? Yeah, I think that those are very complimentary. Essentially, you re connecting it now, it limits someone from exfiltration more than a certain amount in a certain period of time. For those kind of more technical listeners, walk us through a little bit of how the system works. If you’ve got a server and you install SCIT on top of it, how does it actually do what it’s doing?

[0:20:43.0] AS: It’s relatively straightforward. All our implementations are based on the whole concept of virtualization and that is broadly accepted now so we are done of virtualization or VMware kind of stuff as well as we have done it on the cloud. So rationalization has become a bread and butter if you like that’s what most of our installations are based on. So what we are basically saying is that we are going to spend more VM’s than you need and what is going to happen is that at regular intervals we are going to take some of the VM’s off, examine them and see if they have a comprise, send out an alarm and go so on.

So that’s how our system works and we try to keep the number of standby VM’s to a minimum and how is that minimum defined? If I am going to have for one hour then maybe I need to have a standby VM only for five minutes. So we try to reduce the amount of resources required to complete our process.

[0:21:54.7] AA: Got you, so essentially you may, if I am running a server but to use your example for an hour, I then maybe in the last five minutes you are going to spin up and additional VM and then there will be some sort of an handoff between the two virtual machines at the end of that hour to assure continuous…

[0:22:15.9] AS: That’s right.

[0:22:16.9] AA: Right, okay and then how do you handle and that is all happening at the application layer, what layer is that happening? I mean I know data, how do you think about where the data lives and as you think about spinning up a system and destroying the old one, how do you think about data living longer?

[0:22:41.4] AS: So effectively, you can think of data and do it three different ways. There is a distinct, which ever called persistent data and persistent data is stored somewhere. We strongly recommend that you have a backup mechanism and our approach actually will enable you to have a backup mechanism and ultimate test that what the backup is actually works. So there is this persistent data and then there are also things where after all in today’s world SSD’s are very common.

So you can get very faster performance but if you want even faster performance, then you have a shared memory approach. So any one of these works with our system.

[0:23:26.9] AA: Got you, so essentially data is kept in this. You have a backup system in place but then also essentially as I understood, the files are not necessarily refreshing. It is more of the application operating system. The file structures get separately.

[0:23:45.4] AS: Correct, we are basically focused on making sure that there is our systems are operating in a pristine state and where we don’t have the bad guys resident in our system from more than the authorized dual time.

[0:24:03.4] AA: Got you and you know, when you create these environments are you – is it essentially where can you deploy something like this? Does it have to be application by application when you’re doing an implementation? Is there additional sort of custom engineering that happens there or what needs to happen to actually deploy?

[0:24:23.9] AS: So to just give you an example, we have started down this road off of building system that are very specialized to the requirements of the Navy, they asked us for some things we built and showed them how this worked. Then we basically said, “Hey what we’ve done right now is we have looked at things like Drupal and WordPress and there are a lot of users there so we have actually built sample systems using Drupal and WordPress as a demonstration of what we are able to do with these kind of systems, which are very widely used,” and hopefully we are going to work with some people to adopt them in their systems.

[0:25:02.5] AA: Got you, what happens if you are like in the middle of a number of users are in a middle of a session and the VM’s need to flip, right? Let’s say we’re streaming video or we are in a middle of a conference call or we’re a trader where there’s this continuous flow of data back and forth. How do you handle that? =

[0:25:26.0] AS: So we just have to make sure that there is no loss of data, that’s all and our system is built to make sure of that.

[0:25:32.2] AA: Got you, so there is some sort of buffering that happens.

[0:25:34.9] AS: Yeah, we do a bunch of stuff to make sure. It is a challenge but we have demonstrated that it works.

[0:25:41.9] AA: Yeah, let’s switch gears a little bit from the technology to sort of the environment overall. I mean I think I have been surprised by sort of the resistance or the lack of awareness about resiliency as a framework or a paradigm to think through. What if you encounter it in the space also what do you think sort of potentially stopping things from moving more quickly in that direction?

[0:26:08.6] AS: Well I would say that until about two years ago or something, tables of general feeling, “Hey guys, we know how to do detection. You’ve got at all these fancy ways of doing detection. Detection is going to work why do all this stuff,” you know? I think people are now beginning to feel that it is not working. I mean it works some of the time but not all the time and when it doesn’t work then we have a problem.

So there was that kind of reluctance but there is a problem that people do have built in infrastructure. So somebody is having 10 layers of or 20 layers of detection working. Now they basically say, “Hey listen, these are things. Why am I going to do a new level of complexity or a different layer of complexity?” so there is that reluctance. It is for us to come forward with solutions and demonstrations and proof of concepts and be able to do and we are trying to do all this stuff.

To basically convince people that we can actually provide this in a cost effective fashion. I submit to you that if you have several layers of defense, many of these layers may be actually contradictory to each other. If you use our approach, you may be able to drop some of these layers and hence, all our cost will actually go down. So there is this kind of – it is an ongoing effort.

[0:27:32.2] AA: Yeah and I think you know, I certainly feel from a lot of individuals they do feel that complexity is just their drowning, right? But I think you are right where if you accept that you do have that water shed moment where you realize, “You know what? We can’t keep doing what we are doing” that is the definition of insanity, right? We have been trying this for a while and it’s not working. Well, let us try something else.

And then when you start to unpack what the potential for that moving target or refreshing systems allow you to do, you realize that it is actually the idea of just starting a fresh every day makes things a lot simpler, right? Every day or every hour or whatever that dwell time target that you are shooting for, right?

[0:28:20.6] AS: Right and so many times in their presentation, I ask a simple question. “How often do you restart your servers?” because one sure way of getting rid out of malware without having to do detection is to restart the server. So I ask the question, “How often do you do this?” and invariably the answer is very infrequently.

[0:28:42.6] AA: Yeah, never would be mine.

[0:28:44.7] AS: Yeah and the reason for that is there is a cost of back store and there is a legacy issue attached to it. If you look at this 10, 15 years ago, you brought up a server, you never knew what state the server is going to come up in. So starting, restarting a server is a big deal but it is not unusual though. So those kind of things have to be able to grow out of it. So now basically, we start the server with fairly high level of reliability.

So those are the kind of things, which have stood in the way but you’re not do decline with this, developing and there is going to be more people doing this kind of stuff and they are actually five or six companies now, which are based on moving target defense and you seemed to have talked to some of them also so.

[0:29:26.7] AA: Yeah, definitely. Yeah and I think in the world of cyber security and we’re often used the terms around disease a lot. We talk about viruses and malware and infections and compromise and all of these sorts of things that helps of systems and I think we are advancing in the business, in the industry and I think the more we move towards the complexity of systems and the approaches that you see effectively in medicine and in nature itself, right?

I mean I think the idea of – I mean certainly a hospital, a cornerstone of their approach to battling disease is disposable stuff. I mean gloves and needles and surgical instruments, they realize that to keep things clean the easiest thing to do is not to try and figure out where all the diseases or viruses are but just to throw a lot of stuff away, which perhaps environmental issues with waste and whatnot but certainly has been very effective.

And the more that they do that, the better they do from an infection perspective and it actually becomes quite a bit simpler, right? If you don’t have to think about scrubbing everything to the Nth degree. You should just use it once and toss it, right?

[0:30:50.0] AS: I agree, this is a very good example. Many times, it is not worthwhile to do a complete diagnosis. I mean the way I look at it is suppose you are driving a boat. You are in a boat and you spring a leak, what do you think you want to do? Try to find out and do an in depth analysis of the leak or try to plug the damn thing?

[0:31:09.8] AA: Yeah.

[0:31:10.5] AS: So that you are trying to recover from it, recover from it and so only after you have had a chance to get back to shore will you do a deep analysis. That’s what we are recommending.

[0:31:21.6] AA: Right and I think to six frame on that analogy right? I think this is a little bit like working in the tech space, right? It’s like you’re out on a lake in some sort of canoe. If you don’t, you don’t know when your canoe is going to spring a leak but as long as you know that you got a lot of friends in other canoes that you can jump into, you’re probably going to be okay, right?

[0:31:43.8] AS: That’s right.

[0:31:45.1] AA: And so yeah, the most important thing is to either have a lot of friends or own a canoe factory, right?

[0:31:52.3] AS: That’s right but this is an example of we use these ideas. It is not that we go into with this ideas but we have to translate them to this cyber security space is what we need to do.

[0:32:03.8] AA: Yeah, definitely. You know to sort of build on the advancement of this sector overall and I think one of the things that I am stunned by is the lack of really clear measurements for success of any of the approaches that have been up there. I mean I think if you think about detection, when you think about blocking attacks, you actually ask a lot of practitioners like, “What are you measuring when you get a huge amount of diversity of answers?”

And in many cases, the answer is nothing really very precisely or accurately or things that are meaningful. I think one of the interesting things of how you approach is that you are focused on dwell time is something that is quite measurable. Talk me through how you think about measuring success and whatnot.

[0:32:59.2] AS: Yeah, that’s a very good question. The point basically is many of the detection approaches, the point is you have to take a lot of things on freight and by the way, this is okay. We do this on a regular basis but the point is, if you are going to use AI techniques there is a problematic character to them and that problematic character many times you are not able to quantify them adequately. I have been driven by the notion that we should be able to say quite explicitly what we are doing not making it fuzzy.

And that is the reason we have talked about all of these idea. We are being very explicit. “Okay, your dwell time is going to be so much. Your throttling time, the time it’s going to take, the throttle will take based on such and such way." So all these are deterministic ideas but they have pretty low value and if we can combine them with ideas, which are more problemistic, I think we’ll have a good joint effort in this case.

[0:34:01.6] AA: Yeah and I think being so explicit about what are we trying to improve here and what are we giving you here. You know, whenever someone says that they’re meeting 10 I mean gosh, seven, eight, nine things right? Let alone like you when you start thinking about we’re aligning to 23 different things. It is sort of like more than I can count on maybe one hand and maybe not even using all the fingers there that seems reasonable, right? If you have so many things that you are trying to focus on typically you are not doing – you are not really moving the needle on most of them, potentially all of them.

[0:34:41.4] AS: Yeah but it is acting, that is a valid part but have on the justice, yes. The complexity is even more of a problem. So if you are the US Government, you can go around having 20 layers of defense. Okay, then what about this guy who runs a company, which has got $10 million of revenue a year? He can have these levels of defenses right?

[0:35:04.3] AA: Right.

[0:35:04.9] AS: So what are we going to do? Are we going to protect these guys or what? So I am suggesting is and that is why many of these have migrated into the cloud. So that is why the rationalization and what SCIT does should be helpful. So we have actually tried to do some of these, we are talking to a few people who have several who’s customers are small and they have Drupal websites or they have WordPress websites. And so we think that that maybe some place, which we want to explore. We can be doing much more for the bigger customers but we also want to support the guys who are smaller and are growing. Does that make sense?

[0:35:45.5] AA: Yeah and so just to be really clear, if someone is undertaking this approach, what would you point to as saying, “Okay here is where you were now. Essentially your dwell time is potentially unlimited” or whatever you’re going back to kind of your – should you ask how often are you restarting these servers, right? Your restart with this force in a reconnection from everyone, right? You are saying, “Okay I am going to move your dwell time to whatever the refresh cycle is that you have chosen.”

A day, a few hours, whatever that target is potentially as low as 90 seconds and then also you can throttle the flow of data to whatever you think is reasonable for those business. Those are the main measures that you would say these are the things that we are targeting to a brew or are there others outside of this?

[0:36:39.8] AS: I think especially for small customers, small users I think those are the two principle things, which we would still recommend that you start with. So as we learn about these things more, we will act to these set of things but that’s where we think we should start.

[0:36:56.8] AA: And let’s talk about what it takes to undertake this approach. So your technology is just at the software layer, right? Does it necessarily require any additional hardware?

[0:37:07.5] AS: Correct.

[0:37:08.4] AA: And we have talked a little bit, you had mentioned the level of use of the different servers like how much utilization they were seeking.

[0:37:15.6] AS: You’re right, so if you want to talk about end premise systems and let’s say you are using VMware, which is utilized and stuffed and let’s say that you’re utilization of the server is less than 60% then you will not require any more hardware to implement what we do but if your utilization is more than 80%, then you may need additional hardware. But most places, which we have talked to they don’t have – they are closer to 50, 60% rather than to 80% that’s actual.

[0:37:54.6] AA: Got you and then from a throttle perspective, you are just choosing that throttle based on what typical usage is, right? Or whatever the –

[0:38:03.2] AS: Yes.

[0:38:03.7] AA: Got you.

[0:38:04.4] AS: So you’ll effectively – you are user, the guy who designed the system knows that you will be getting to a separate website, that is going to tell you how much of data is going to be downloaded on any query from there, you can tell how much of bandwidth you need and then you can choose your throttle time in consultation with the customer.

[0:38:25.2] AA: Got you and then you think that there are certainly they’re like the normal patterns that you see in organizations okay, right? Most of the time where we’re just doing 10 megabits per second or whatever it is but maybe let’s say you are holding a big event and so suddenly you’ve posted a lot of materials on your website that people are downloading. How do you think about assist and then now people need to download this much larger files so that traffic is really spiking?

[0:38:56.9] AS: Yes. I think what you are basically saying is that you may need multiple parts into the system, one part for the conventional user but then there could be some people who are doing their additional work and because they are doing additional work, they may need to lure download bigger files and you need to get them another part and on that part, your throttle times will be different.

[0:39:20.9] AA: Yeah, exactly or just the experience is not normally distributed, right? If you think of a retailer where all of the activity happens in the holiday Christmas season, right? So bandwidth is just exploding, usage is exploding in a certain few or like Amazon day, I forgot what it is, Prime day right? You think through that. How do you think through that, is this designed in the system in that way? Can you just as simple to toggle of the volumes on a certain day or are there other options? =

[0:39:54.4] AS: Well, I think this one idea of a throttle has to accommodate what the user requirements are. So you may have a bunch of users, you may be able to do something by which you tell them the throttle to the user. A user comes in, “You know that this was going to go to this website, this website, this website.” So the throttle would be different then somebody has to go to another website. So you can do all of that. Our implementation currently is a single throttle time but these are the kind of things which we need to extend our system to.

[0:40:35.1] AA: Yeah, well Arun, I want to be thoughtful about time because you have been great in terms of walking through a lot of different questions about how your technology works and the application of it really enjoyed you doing that. If people want to learn more about what you’ve been up to and other resources about resiliency and moving target defense, anything that you’d recommend we can put links to stuff on the show notes.

[0:41:00.4] AS: So you can go to scitlabs.com is our website and this is scitlabs.com is a website, which you can go to. We have links to several whitepapers. We have analyzed for example the worst breaches in the last decade and tried to show how our approach would have worked in those cases. There is a lot of stuff there and of course, you could always get hold of me and I can answer more questions.

[0:41:29.7] AA: Cool. Well, Arun thank you so much. I really enjoyed this. Yeah we’ll check back in and see how things are going over the coming months and years too. Thank you so much.

[0:41:38.5] AS: Very good, thanks very much. I surely enjoyed this. This is fun.

[END]