Automatically transcribed, so names and technical terms may be misspelled. The audio is the record.

The Colorado Equals Security podcast is your local source for regional security news, local events, and interviews with key individuals in the region. Now, here are your hosts, Robb Reck and Alex Wood. Welcome to Colorado Equals Security. This is episode 42 for the week of November 20th. Alex, it's Thanksgiving week.

It is indeed, Robb. We, we made it. We made it. Uh, gonna get to, uh, relax a little this week, uh, eat some turkey, I guess cook some turkey first and then eat some turkey. You staying here in town?

We are staying here in town. We've got some family coming into town, um, as we are recording this. In fact, my parents are on, are on an airplane, should be arriving here shortly. How about you? Uh, yeah, we're gonna hang out with some family and, and obviously just do the normal Thanksgiving holiday.

We're gonna take a few days off. From work. So that's not too bad. Should be a pretty good time. And obviously you and I, we're going to do a little bit different podcast next week.

So there will be a podcast folks can tune in and listen to, but it won't be the normal format. Exactly. We're going to just talk a little bit about what we're thankful for and also give— I don't want to call it a rerun, a repeat, a little extra bonus interview. Yeah. One of our favorites from the archive.

Exactly. All right, let's go ahead and dive into the news this week. First, as a reminder, do sign up for our mailing list if you want to get the show notes delivered into your inbox every week. Nice reminder that the show has been published. Yeah, and even better than that, we've got an announcement.

So we have set up a Colorado Equals Security Slack channel. So if folks are interested in more real-time collaboration and discussion, then go check out that Slack channel. The link will be in the show notes. Yeah, so the intention is it's a place for security professionals in the area to get together, to get to know one another, talk about jobs that are out there, events that are coming up, really a place for you to connect with, with others in the community. It'll be moderated, so it will not turn into a big vendor home, or those folks will be asked to leave.

So do expect it to be a good place to connect with, with other folks who you know in the community. Exactly. The link for that's in the show notes. It's also going to be on our website, so go ahead and join up there, and hopefully we'll see you in Slack. So first on the news list for this week, Hyperloop is coming to Denver.

So a company called Arrivo is supposed to be putting in a Hyperloop track here.

Robb, I was telling you earlier, this seems a little science fictiony and also almost feels like someone's trying to pull the wool over our eyes. There's some things in here that are just a little bit funny. The gentleman who is the founder of Arrivo, his name is Brogan Bambrogan. Uh, which I'm sure he's a wonderful person, but you know, it could be a made-up name. Is that what we're thinking?

So first of all, this is not the same Hyperloop that we talked about a few months ago when we were looking at, uh, at Elon Musk's Hyperloop company. This is a different proposal. You know, that one had been to go all the way from the north in Colorado down south to like Pueblo. Um, this is really proposing to go along the 36th Um, that, that turnpike there. And instead of going, you know, 500 miles an hour, this takes you at about, um, 200 miles an hour.

And, and instead of being an underground, uh, tube, this is really something that's basically a tray that your car— you drive your car onto this tray, the tray slides in, and, and it takes your car at about 200 miles an hour down the road to, you know, to take that whole 45-minute drive down to like a 6-minute drive or something like that. Right. Which would be awesome. Yeah. It looks like they're gonna have a test track also out by E-470, and that's supposed to break ground in early 2018.

So it's a neat idea. If it works, fantastic. I am glad to see that we're trying to come after some innovative ways to solve the congestion and the infrastructure problems we have here. Once they figure that out, I will be looking forward for the Hyperloop that goes you know, from downtown up to the ski areas on I-70. That's what, that's what we need the most.

That's— I think there's a massive amount of money that the state is passing up on, tax revenue and of course money for all those, those mountain resorts because we don't have easy access up there. Yeah, there are a lot of people like me who would like to go a few times a year, but I don't go at all because it is so painful to drive through the traffic on the way up there. Anyway, next couple stories. We have 2 different stories here about Amazon. The first one is that the state has now released our proposal that we submitted to Amazon for getting HQ2.

It sounds really interesting, right? Well, sort of. They've released it. It's like the FBI releasing some old file with, you know, 3/4 of it is blacked out, right? They redacted the good stuff.

Right. They redacted the 8 locations where we might go, and they redacted the details on the financial incentives. Yeah. My understanding though is that the financial incentives were not a big part of the package. We weren't like some other places offering billions and billions of dollars of incentives, more focusing on quality of life, other things like that.

And then the second part, Wall Street Journal put out an article this week saying that Denver is not in the top 5 for potential choices for the Amazon headquarters, but drum roll, are number 6. So, okay, we're not in the top 5, but we're the, the next best. Yeah. So, I mean, they basically went through and, and did a, a ranking of all of the cities that they were aware of who submitted, um, and, and then rated them based on, you know, the 6 criteria Amazon had put together. It was like income, number of, um, number of, uh, tech graduates coming from there, size of the workforce in general, cost of living, Um, like culture fit.

So we didn't fit great on a couple, but we did fit great on, you know, culture fit. And I can't remember a couple of them we were really good fit on. Yeah, so we'll see. The soap opera continues. Yeah, it'll be— I think it's like mid next year that they're supposed to let us know.

I did also notice that, um, we delivered our proposal in a custom-made wooden box. Yeah, so you know, that, that's got to go for something. Handcrafted. Yeah, handcrafted. It's got to be good stuff.

Uh, you know, it— there's This is the best free advertisement for Amazon ever. It's pretty amazing. Yes. We'll keep talking about it because it's interesting, right? Yep.

So next, SendGrid. We had talked previously that they were going to IPO. That IPO happened this week, and they had a nice 16% jump in their stock. Yeah, so they initially had put their estimate of opening price between $13.50 and $15.50. That was their guidance, and then they ended up pricing at at $16.

So they actually came above their range, and the first day of trading they ended up closing at $18. So a 16% jump even beyond that. So obviously a successful initial IPO, and it'll be interesting to see how, how it goes for them in the long term. For those who don't know a lot about IPOs, um, you know, I've got to learn quite a bit about it. And they, they basically gave up, call it about 10% of their company to the public markets for, you know, for this price per share.

And it's expected that over the next, you know, 6 to 24 months, they'll probably have a secondary and then a third offering of stock where they offer more and more of their stock. The point is they don't want to flood the, flood the markets with it because they don't— they want to keep the price high. At the same time, they want to be able to get money out for earlier investors and of course employees who were, who were given stock as a part of their compensation. So it's kind of a slow trickle of shares over time so that they can keep the price from, from, you know, taking a nosedive. Right, exactly.

So anyway, congrats to DC. Dave Campbell, the CISO over there, a friend of ours, uh, really obviously a big success and a lot of security work leading up to going public as well. Um, so once again, DC, good job. Um, the next one is an article we saw from Digital Colorado really saying that Colorado cyber— cybersecurity workers are in high demand. Couple of really interesting numbers in this article.

The first thing is they say that there's about, what was it, 9,500-ish open security jobs, which is incredible, across Colorado. That's significantly larger than I would've guessed. We do 10 or so per week, so we're getting a very small percentage of those. Keep in mind that this was over 12 months, so 9,500 jobs from September to September. Okay, still fair enough.

Great number. Yeah, so almost 10,000 jobs, but then they estimate that there's 18,300 cybersecurity workers Colorado right now. So 2 big things about that. One, 18,000, I think it's above— Alex and I have talked about this a lot, how many cybersecurity folks in Denver do we think there are, in Colorado we think there are. I think we were thinking somewhere between 10,000 and 15,000.

18,000 is bigger than I would have guessed. And number 2, half of those have been posted in the last year, it sounds like, right? Right. Either they're unfilled, so we're going to add another bunch to that 18,000, or half of the jobs have turned over. Either way, It's just a— those are massive numbers when you put them together.

I just think it talks about the strength of the community here and also the shortage of skills. Because if you, you know, even if only half of those 9,000 jobs were turnover, still, that, that's, you know, like a quarter of the total jobs that turned over in a year. Pretty incredible. That's amazing. So next, CU students.

CU Boulder, that is. They were— had essentially a competition across all majors around cybersecurity. So the headline says that they flexed their cybersecurity muscles, but it sounds like they did some education as well as sort of some hackathons, capture the flag kind of stuff around cybersecurity. So really cool across all departments. They all came together and, well, as anyone who was interested came together and did a security hackathon competition where the winners got $500 and really got that exposure.

I love the idea of us getting exposure to business majors and history majors and those— Music majors. Who might not have otherwise really thought about security, right, in their day-to-day lives. So really cool stuff. Yeah, definitely good stuff. As we go a little further in education, the Colorado Technology Association has partnered up with the Colorado Succeeds in Silicon STEM Academy to offer scholarships for Colorado high school students.

So this is actually not just something we want to report on, but we want to kind of give you guys an action item and go get people to apply for this. Right now there are 100 open scholarships to participate in this. It's basically a coding and, you know, a STEM acceleration class program, right? So this is for high school students. So if you have a high school student in your household or know someone who does, encourage them to apply for this.

So basically, it sounds like starting in January, they're going to be offering these classes and the, the scholarship is to, to get into those classes. Yeah. And they have a couple of goals for the program. One is that of the 100 people, that 50 of them will be females. And the other is that out of the 100, 50 of them will be from outside the Boulder-Denver corridor.

They're looking for people from other parts of the state, right? Yeah. So these are— the classes are actually offered online. So anybody in Colorado should be able to take them. It doesn't necessarily have to be within a certain proximity.

So if you know a female high school student in Grand Junction, she's got a really good chance of getting in this if she applies. So send the notes out there. Next, Joe Bonnell, who we've had on the podcast before, CEO of Alchemy Security, was included in some testimony to Congress this week. Yeah. So Joe got plugged in with some staffers from D.C. earlier this year who were looking for feedback from the industry on how can we do a better job supporting security from a national level.

So he, as he's been a part of this, really he's been giving advice on how we can improve. And this testimony, which is linked in the show notes, really has a good quote from him. Do you want to summarize, Alex? Yeah. So basically he was advocating for, for education through lunch and learns or, you know, short features like the Schoolhouse Rocks things that we had when we were kids dating ourselves.

Yeah. School— just imagine the Schoolhouse Rock for security. Is it a sad Russian trying to break in and we're I don't know what it is. Anyway, it's a good visual. That would be awesome.

But in any case, I mean, it's a great point. You know, small investments in education can definitely go a long way. And hopefully they take that advice. Yeah. Next story is Denver Business Journal did a profile on our friend Brian Beyer.

Brian is the founder and CEO or co-founder and CEO of Red Canary, local security company. It's a nice profile talking about, you know, the the small company nature of Red Canary, that they are not trying to grow as quickly as possible at the expense of profitability and, you know, burning through cash. Um, he's, uh, it's a good profile and you get to know a little bit about him as a leader in the community. I think it shows very well for him. Yeah, good job.

Uh, next, InteliSecure was ranked number 6 on the Denver Business Journal Fast 50. Uh, so this is, um, about, about growth.

Congrats to them for making that list. Congrats to InteliSecure. Next, we have a couple of different articles from Optiv. They made 2 acquisitions in the last week. Number one was a Canadian company called Connexus, who was basically a VAR in Canada.

I think rather than adding capabilities, they're probably just adding some revenue and adding some customers here. Then the second acquisition was from a company called Decision Lab, which is an AI and security analytics company. I'm not sure what they're looking to offer, but there is a quote from that, that new head of emerging services who we talked about last week, really talking about how this is going to move them into a new area. It seems a little odd to me, but I'm sure that they have some vision and I'm sure it will come to fruition. Next, there were a couple articles this week about Route 9B, one of them announcing the fact that Route 9B Holdings, which was the, the parent company to Route 9B, essentially the operational company.

It was going to be discontinuing operations. So this is no surprise to us, right? We knew Route 9B was— the holdings company was in trouble. They were bankrupt, and they ended up selling off their only asset to Tracker Capital a month or so ago. So this is no surprise.

Yep.

The, the next article was by Brian Krebs. Apparently Krebs and some other folks had covered Route 9B several years ago as they had come into the market, made some splashy claims that people were a little skeptical about. So he was also picking up on this fact that Route 9B Holdings was closing. Yeah. So the title of his headline is Route 9B, We Hardly Knew Ya.

And basically the way I read this is 2 things. Number one, it seems like he thinks that Route 9B is going to not operate anymore, which I don't think is true. I think that they, you know, that the same leadership is going to be there and the same name is going to be there under Tracker. And then the other thing I got out of this is he seems to think that they're kind of hucksters or fraudulent, right? That they're making claims that's not backed up by actual services in reality.

And I don't know that I can say one way or the other. You know, we have seen plenty of news about Route 9B. We have reached out to them several times to see if they'd be interested in coming on the show, and we haven't heard anything. I don't know anybody personally that has been a customer of theirs. Yeah.

Um, but I would sure imagine that there are customers out there and they could probably tell you whether they're decent service providers or not. Yeah, I think the, the very first show we did, one of the first news articles we had was them being number 1 on the cybersecurity— was it 500 or whatever list? Uh, and, and Brian Krebs goes into that list in a little bit of detail that, you know, it's a pay-for-play. And, and apparently what they're really rating you on according to that article is is how good is your marketing and sales, right? That's— that is the rating.

Like, apparently that's what it actually is. I, I don't know. It's hard to— it's hard to get to the bottom of that. Yeah. So, um, a little bit of, uh, of confusion here and, and potentially, uh, some bad news for Route 9B.

Some of it we already knew about. All right. Last article this week, uh, is actually a blog from CableLabs, and this is a fun one. It's how to build your own LTE network. So before we go any further, I wanna say, hey, this is probably illegal.

Maybe you shouldn't do this. Potentially, depending on how you do it, there are potentially some hurdles you would have to overcome here with the authorities. I would rather say don't do this unless you're positive that you're not breaking the law because I don't want anyone to say that Colorado Equal Security told them to go build an LTE network. Yeah, basically the article is talking about how you can build your own software-defined radio, set that up to be the LTE receiver, Is it all about like what frequency you use to get legality? I'm not a lawyer and I don't want to give legal advice, but I think some of it is about frequency and some of it is about power.

But yes, again, be very careful. But if you are someone that likes to play around and want to be able to say that you have your own telephone network, you could do that. Very cool. Well, thanks for sending this over, Mike Glenn. We appreciate it.

Reminder that we, we'd love it if you would go out and do a review on the iTunes or Google Play Store. We have, you know, a number of reviews on iTunes. I don't think we have so many on Google Play. So if you're listening on Google Play, that'd be a great place for you to do it. Is that because Android is so much less secure and none of the security people go out there and use that?

I'm confident that's not the reason. All right. So moving over to trivia. Last week's trivia— not question. Last week's trivia command was Colorado's Equal Security had 2 lawyers as guests.

Name them. The correct answer for this was Dave Navetta and David Wilson. And the answer was properly given to us by Noah Kaplan. And Noah is also a lawyer. So it's a good thing he knew this.

Congratulations, Noah. We haven't had Noah on the show as an interview because his name isn't Dave. Yeah, we only interview cybersecurity lawyers named Dave. Yeah. And so, Noah, make a change and we'll be sure to get you on the show.

Exactly. So this week's trivia question, going back to a Colorado trivia question, that question is, whose mission is it to support and promote statewide emergency preparedness, disaster response, and mutual aid assistance for public and private water and wastewater utilities? So basically, who is it that's there to make sure that water and wastewater are prepared for any kind of disaster? Right, exactly. Yeah, that's an interesting one, and I had never heard of this group.

And thanks a lot to our sponsor Andre Gaeta for coming up with these really fun questions that get to teach me about the area. So really cool. Send a note to info@colorado-security.com or send, you know, or come to me and talk to me on Slack about it, and we can talk about it there. So let's move over to events. Of course, we do have our event calendar on the website, so make sure to check that out for the latest information.

We only have one event to talk about this week, and we've talked about it several times. This is the, uh, from Optiv, their Insight focus group on application security. And that's, that should be good. I think that it's going to happen, so sign up immediately, uh, if you're, if you're going to be able to make it. It's the week after Thanksgiving.

Uh, we're looking forward to it. We do have a bunch of stuff in December, but that's too far off, so we don't want to talk about it exactly. However, we do, we did just put on the, the website a couple of big events for next year. So on March 8th of next year will be the annual OWASP conference called SnowFROC. That's a full-day event.

I assume it's back at the Cable Center, although I haven't seen that confirmed yet. We'll get that for sure when we know. And then May 8th through 10th is the Rocky Mountain Information Security Conference. And it's about that time of year where we're going to start talking about it again. Exactly.

So we do have some Rocky Mountain Information Security Conference news. Our call for papers is open. So if you are interested in speaking, go ahead and submit. If you go to rmisc.org, you will find all the information there. Additionally, we are looking for sponsors.

So if you're someone interested in sponsoring the conference, again, check out the website. You can find all the sponsorship details there. And finally, we're actually doing registration differently a little bit this year. In the past, we have waited for all of the sessions and everything else to be ready before opening registration. This year registration is actually open now, so if you are someone that needs more lead time, if you potentially have extra budget at the end of 2017 that you want to use for education, you can go and register now.

So once again, you can find that at rmisc.org. Very good. And we also do have some keynotes that are confirmed, but we're gonna wait and announce that here over the next few weeks. We're gonna give it to you a little bit at a time to make it exciting. Very good.

Look forward to that. So let's jump over to jobs. Uh, first, uh, LenderLive, they are looking for a Chief Information Security Officer. Yeah, it's a— that's a mortgage company here in Denver, and we've known a couple of the folks over there over the last few years. Uh, Dish is hiring an IT Security Manager.

This would report to John Everson, our friend who's been on the show. I think it'd be a great opportunity to work in security and have a lot of responsibility at a Fortune 200 company. I think he said this is a group that manages 10 to 15 kind of people. So you have some, some direct reports there. Comcast is looking for Manager 1 of Security Incident Response.

CA Technologies is hiring a Senior Cybersecurity Engineer. Wells Fargo is looking for a Systems Architect 5 for Payment System Security. Now, seriously, 5. This, this is— that's a big number. That is a big number.

I wonder how big those numbers get. I, I can't imagine it's much more than 5. You got to be pretty senior to be a 5. Yeah, that's pretty good. So if you weren't a 4 previously, don't bother applying.

That's right. It's just, just a joke. Uh, Guidepoint Security is looking for a VSOC cyber threat hunter. I assume this is a virtual security operations center, so I would assume that means you can work from your, from your home in your robe and I would assume that as well. Yeah.

PricewaterhouseCoopers, or I think it's actually just PwC now, right? Kind of like KFC. Yeah, I think so. PwC is hiring a cyber risk experienced associate. Yes.

So if you're just a regular associate, not an experienced associate, please do not apply. Pearson is looking for an information security intern. This is for the, the CISO business operations group. And then Level 3 is also hiring an intern. I guess it's probably now really, uh, CenturyLink, right?

Yeah, it sounded like this one was coming from the CenturyLink side. So CenturyLink, uh, an intern in the Inroads Cybersecurity Program. Uh, and then finally, Optiv is looking for an Executive Vice President of Security Services and Solutions. So if you've had security solutions experience and, um, want to be high up at Optiv, that would be the job for you. All right, so that's it for the news this week.

We're gonna throw it over to the feature interview. That was you this week talking to David Kruger from Absio, right? Yes. So definitely an interesting interview. David doesn't come originally from a cybersecurity background, so it's interesting to hear about how he and his brother started the company, them sort of taking a look at the problem of data security and trying to kind of get back to the roots of what is— what causes it, and then figuring out problem or solutions to how to solve those problems.

Sounds good. Well, everyone have a great Thanksgiving. Listen to the interview here and hopefully we'll see you on the Slack channel soon. Awesome. Thanks, Robb.

See ya. This is Lucia Turpin, CISO at Polycom. This is Colorado Equal Security for Colorado security professionals by Colorado security professionals.

This is Alex Wood with Colorado Equal Security. And I am here with David Kruger, co-founder of Absio. David, how are you doing today? I'm doing fine. Wonderful.

I wonder if when we start here, if you could just give me a little background on yourself, how maybe you got into this industry, and then maybe a little bit about Absio and what you guys do. Okay, well, I'm actually not an IT guy. Historically. I'm a safety engineer. Okay.

And I got involved with my twin brother who was the founder of Absio, helping him out with his first software company back in the late '90s. He needed somebody with construction management expertise because we were doing a software company that hosted construction plans online for commercial contractors. He didn't know anything about the construction industry, and I'd been managing construction projects inside of chemical plants and places like that for a long, long time. So I helped him stand that company up and get it started. So I've learned a lot about the IT world and specifically about the security world in the last few years, but I'm not a guy who's been in the business long-term.

Yeah, it's funny how the different ways that people get to where we are in our industry. You know, I would still say security is a pretty young discipline, so you don't necessarily have a lot of people that, you know, went to school to be in security. So you do get people that come from it from all different ways, which is fun. Oh yeah, well, security and safety are a lot more analogous than most people think because you're still fundamentally trying to keep bad things from happening. Yeah, I worked for an oil and gas company for a few years running their security program, and we had this giant push around safety.

Safety was the biggest thing, and I didn't always have the exact same amount of traction in the security program. And then one day it dawned on me, well, we're the same things. I should get in bed with the safety people and then ride their coattails, this will be great.

So tell me a little bit about the company, about Absio, what you guys do and what kind of services you deliver. Well, we're a cybersecurity company is a general way to say it, but very specifically we developed a new kind of encryption technology. And really that— our understanding of that encryption technology does relate back to sort of the safety engineering aspect. And we had— when we first started the company, we had a general idea about what we wanted to do. We did a couple years' worth of stealth engineering.

This was after selling another software company, just to see if what we thought was going to be possible. And then we started working with the military. So that's Just in real general terms, that's the broad sweep of history. But military contracts ended due to sequestration, and then we made the pivot here to the commercial market. We took what we had developed essentially for the intelligence community, and we've made it now a series of commercially available technologies.

So was it the construction management software company that you sold to get into this one, or was there another one in between? No, there was another one in between. We sold the construction management software company. We started up another company that made specialized— if you think of a low-code platform for SharePoint. This is all the way back in 2003 to the 2008 timeframe where we just made it very simple for SharePoint people that were not developers to put together pretty complex SharePoint applications just with a series of drag-and-drop web parts.

We sold that to Quest Software, which was eventually sold to Dell. And then we took essentially the money from that. We wanted to get into the cybersecurity realm because we had some very specific ideas how to solve the problems of data breach, of data loss. And again, that's goes back to a couple years worth of stealth engineering and then beginning to work with US Army intelligence specifically, but with the intelligence community as a whole. So how did that work?

So did you guys, as you're doing this SharePoint company, did you think, you know what, I have this other great idea, maybe we should do this someday? Or did you run across the problem? How is it that you got that idea to do I mean, it's a different company, but essentially a pivot to do something else. Well, so this is where the confluence of safety and cybersecurity kind of come together. When you're a safety guy, you always start everything you can with a root cause analysis.

And the reason you do that is because the farther upstream you can solve a problem, typically the solution is less expensive. Expensive and it's more effective. I would agree with that. Right. So what we looked at was, you know, why are all these stories in the news about, you know, what we've come to call data loss, data breach, where basically data got exfiltrated from an organization and ended up in the hands of somebody that it wasn't supposed to.

And there were all kinds of prescriptive things to do. You know, you could mitigate it this way. You could, you know, all the different things that people do now after they have a breach, give people free credit reporting and all that. So we actually did a root cause analysis on that, and the thing that we came up with as the root cause is the way applications make files. They make files that are by default unsecure and uncontrollable.

And so we started this exercise. We had the time and we had the money of saying, okay, how can we we solve the problem at that level? And that's what led to Absio, working on ways to solve that root— what we think is the root cause of this sort of vulnerability. So I'm really interested in that root cause analysis process. So you guys, did you do this on multiple ideas or was this sort of a course of business for you guys thinking about, hey, I've got a cool idea, you know, let's think about what the root would be so maybe we can try and solve it.

It really kind of started with trying to do the root cause analysis first because it was just saying, look, there's all these breaches. Let's sit down and have a series of conversations and we can just again sort of do a semi-formal— this is really over a set of phone calls because I lived in Dallas and Dan lived here in Denver. This is really a set of phone calls about, let's think about why this is such a problem. And those phone calls took place over a period of a couple of months. So it wasn't a concentrated thing, it was just this sort of continuous nibbling at the problem until one day the light turned on.

The problem is the format that files are made in, because unbelievably the storage media has changed from tape to, you know, whatever. But the way that we make files, the way applications make files, really hasn't changed since the first digital files were laid down in the '50s. You lay down a bunch of ones and zeros that have the content, and you lay down some metadata so that that content can be recognized and reused, re-edited or read again and that type of thing. And it was in that structure, the format of the file where the vulnerability was built in. I don't know if that makes sense or not.

Yeah, that makes sense for sure. It's just always interesting to me how people come to ideas. Sometimes it's someone stumbles over something, sometimes it's this deliberate looking at a particular problem. I always like to try and look at those ways that people come to an idea and how they're going to solve it. So now you've got the root cause, you know what the problem is you want to solve, so then you guys went off and thought of ways to try and solve it?

Well, yeah, we went through a bunch of permutations. Actually, coming up with the fundamental concept was fairly simple. We said, okay, if that's the root cause, then how do you address the root cause?

Again, I say files, but this is files, byte streams, anything. Right? If it's— it can be read by anybody who possesses the software in it. So just merely having possession of this sort of naked unprotected file is a problem. There's a real simple solution for that.

You have to encrypt it. But you need to encrypt it from the moment that it's created, right? The other vulnerability was that you had to share information with other people. They were going to be maybe inside your network, but more often than not, they were going to be outside your network. So you had to figure out a way to be able to sort of extend your control in what you could do with that file, even if it was on somebody else's device or network.

So we arrived at that, that's what we had to do, pretty quickly. It took the next 2 years of stealth engineering to figure out how to actually do that. We had to go off and hire staff, engineering people and so forth, and spent really the better part of 2 years not writing that much code but just figuring out how could you do that. How could you encrypt things when they were made? How could you maintain visibility and control of that object throughout its lifespan?

So our largest probably expenditure besides, you know, paying for engineering staff that first couple years was, was buying more boxes of dry erase markers, you know, just, just trying to figure out if that was even possible and what the work— the, the architecture of that ecosystem would be. And so at this point, is this still for, essentially for a future idea? Or was this work being funded by the government organizations that you guys were working with at the time? No, initially this work was funded— we had some family and friends investors that came along with us from our prior software ventures, and we had money of our own from the sale of the SharePoint web part company, which was called Workplace Architects. So mostly it was some family and some friends and some funding that came out of that directly.

Alright, so then you spent those 2 years figuring out how to solve the problem, and then what happened? Well, we, through, you know, one of those happenstance things, at the time we also had another— I had a software company that was working in the aviation industry. And we met a guy at an air show who ran the technology incubator at Purdue. We started talking as a couple of pilots hanging out at an air show, then, you know, the normal thing, what do you do and what do you do? And I explained what we did and he explained that he ran the technology incubator.

And he said, there's some people that we work with in the Pentagon. I need to get you 2 guys together. And that's what happened. We went up to the Pentagon, we met with some stars and bars and laid out what we thought this technology would do. Would do.

And then we got into working with US military intelligence, particularly Army intelligence. So, and then I would imagine after that, this is the point where you start actually building the product, trying to solve some of these problems that you figured out. We were in Iraq and Afghanistan at the time. And they had— what they needed was a secure tactical battlefield communication system, sort of the nature of asymmetric warfare, which we even encountered in Iraq and Afghanistan in a way that this country had never encountered before, required you to have real-time intelligence in the warfighter's hands. Things like a bad guy, good guy database where you could actually look at a picture and see, is the guy on my tablet or phone the guy that is a friendly, right?

Or is it a guy that I need to do something otherwise with— because no uniforms, right? And difficult operating environments. The fundamental problem was is that you had to put that information updatable in real time in a warfighter's hands, and you need to be able to do it on something that was portable like a phone or a laptop, which meant that you had to have a server out in the field to communicate communication server out in the field, but that server and those end devices presented several different threat vectors, right? You could actually steal, capture the server, or you could blow it up and you'd lose all the— hit a mortar round, hit it, and you'd get all the data loss on it.

Your end device— sorry about that— the end device could be captured, and then the bad guys database, good guy database, they would all know who each other was. That device could be lost, that device could be captured and sent off, or the server could be sent off to a nation-state for a hack. So what we ended up with was a set of requirements. We need a tactical battlefield communication system, which is a fancy way of saying email, right? But really, really secure email that If the server's captured, if the server's captured, been captured by a nation-state, you still have to keep the data that's on it secure.

I mean, physically carried off. If it's blown up and you've just got end devices, those end devices need to be able to have all the data on them that the server does, whatever's appropriate for that particular warfighter. You're in a contested environment, so you can't guarantee a connection. So we had to figure out how to do— and this is sort of the fundamental of the capability. We had to figure out how to entirely automate key management and push it— and push that and encryption to the edge and then do it in a disconnected environment, which is an entirely different paradigm than the encryption that you're used to where you're calling a central server and it's serving up your keys or you're sending data up for encryption and it's sending you back an encrypted file or sending it up for decrypt and sending it back.

We had to figure out how to do what we call software-defined serverless encryption. The other thing that was an aspect was that we had coalition partners that we couldn't adequately vet because it wasn't politically copacetic to do so. So that created a requirement to be able to have visibility and control of that data when it was in somebody else's hands that was not a member of the US military, right? And we had to be able to not only have control and visibility of it, we needed to be able to delete it at a remove. We had to be able to remove access no matter where that object was stored or whose device or whose network it was stored in.

We had to be able to revoke access on demand or modify their privileges to be able to further share that data. So that was the challenge before us. So that sounds like, I don't want to say the Holy Grail, but some pretty amazing technology that I think a lot of people would be interested in. So I'm curious if you can go into more depth on how that actually works. I obviously have some familiarity with encryption, but I am more familiar obviously with the more traditional models that you mentioned with having some sort of keys, but then it's authenticating somewhere, things like that?

There's a few components to this. Let's start with just the encryption piece and then we'll go to the control piece. We had to devise an automated PKI structure and a set of, well, essentially software development kits that were platform-specific that would generate the public and private keys at the device level, on the device, and attach to whatever application was creating the data, right? And then you were able to take any file, byte, or stream and encrypt it with its own unique key. Now that kind of brings up the classic problem of having the keys and the content together.

So we got multiple patents off of this work. We were able to retain all of our IP. One of them was an obfuscating file store. So when we encrypt an object on a device in an application as it's made, right, or we take existing content and we encrypt it, each object has its own unique key. That key is stored in an encrypted database.

The content and the encrypted database with the keys in it is all stored in an obfuscating file store. It's just a bunch of randomly named, randomly located objects that all have 6-character alphanumeric names. The thinking was that— and since each one is individually encrypted to AES-256 at this time, right— that we just simply created a math problem. You can't tell what it is that the object is. There's no file types, there's no anything like that.

So you just— OK, here's a whole bunch of randomly named, randomly located objects, right? Some of those objects have some value. How do I find them? You've got to brute force decrypt things one at a time. Now, one of the members of our board is the past CTO of the CIA, who was CTO of the CIA at the time we were doing this work for military intelligence.

So we have a fairly good understanding of who actually is able to decrypt AES-256 files, and it's a relatively small universe of sort of nation-state-level actors that could do it. So they could conceivably brute-force decrypt that. But if you've got to brute-force decrypt thousands and thousands or hundreds of thousands of files or tens of thousands of files on a device, where do you start when you can't tell what the content is? That whole randomization paradigm and obfuscation paradigm just presents this enormous computational resources challenge to anybody who would happen to capture either the server that was running around behind— being towed behind an MRAP or a Humvee, portable 3G network that they would put up in theater. You capture that, okay great, you've got hundreds of thousands of individually encrypted, nonsensically named, randomly located files.

Have fun. Have lots and lots of fun. Well, you know, that's sort of one of the principles that I think a lot of people try to employ when they're doing security is you're never going to make anything perfect. Where you can't— where you can guarantee that something will be secure, but the idea would be that you want to slow down an attacker as much as possible so that you can detect, that you can remediate, that you can do other things like that. So with an infinite amount of time, it sounds like yes, they could brute force all these things.

We make 2 guarantees. We'll guarantee you that this system is not perfect, that you can get to the data. The other guarantee is that it's going to be very, very expensive to do so.

Essentially, that's the best that you can hope for. The funny thing is, by the nature of the way we do things, the more data that you have protected this way, the tougher the problem gets. Because you get more and more files. You'd much rather have millions of files individually encrypted and nonsensically named in a random structure than thousands. Right.

Right. Yeah. So that's the encryption side. Then you said you had the control side as well. The control side, we had a couple of different problems, right?

We needed to be able to have metadata that would allow an application that used the technology to maintain control of that data even when it was on somebody else's devices. So we did this This was originally an email system that we did for the military. If you think about that context, you send somebody an email that's outside of your network and it's got attachments on it, you want to be able to control whether they can forward that to somebody else or whether they could cut and paste from the email body or from an attachment. Could they print it? You want to be able to control its lifespan.

For instance, take the Pulte is in the mortgage document business. You need to have information for somebody to be able to perfect a mortgage. You don't need to have that information in the other party's hands forever. So can you set it so that you can say, okay, we're going to put metadata in there that says after so many days, months, years, whatever, this data is essentially, with the help of the application, going to delete itself. So all of those things are possible, and those controls are behind authentication, right?

You decrypt the object and those controls were better. The other problem that we had from a data management standpoint in the battlefield is pretty much the same problem that we have in data governance and data management to begin with, is that you need to be able to have people manage large chunks of that data but not have access to the content. So we had a second metadata metadata layer where we can associate, because each encrypted object has a GUID, it has its own unique ID. We can manage that and say, okay, here's metadata about this object. This is mortgage information, or this is healthcare information, or it doesn't matter what the metadata is.

It's a way to be able to manage that object's, you know, where it's stored, who has access to it, and so forth. Without decrypting the content. So that capability of being able to pull in metadata from any source and either put it behind, encrypted with the file, bound to the file, and only available after decryption, extending control, or being able to decrypt it and— or not decrypt it, but to manage it and maintain proper separation of duties. We had to build into the system in order to be able to meet the IC's, the intelligence community's requirement for this tactical battlefield email system. Yeah, I have seen some people talking recently about— well, so you guys, it sounds like, are solving at least 2 encryption problems.

One is being encryption at rest. So if you have files there, then they're going to be protected. You're going to solve encryption in transit because these things are still encrypted as they're being transited. Not the transport layer itself, but the files as they're moving around. Well, we actually are moving, you know, in our particular product set, right, everything, any communication outside of an application of an encrypted object is done via TLS that we manage so that we know certs are up to date, it's the proper version, and so forth.

It's randomly named obfuscated files flowing through an encrypted pipe. Again, so if you break the pipe, you're still back at that thing. Then there's other safety measures that are more sort of conventional, one-time use session keys, that type of thing, with the encryption that we do for an object during transport where we send a key blob that's got the content and the the keys, it's further encrypted. It's an ephemeral object that those keys are thrown away anytime it's transported. You get a new set of keys, you know, all of that sort of blocking tactics you have to do to meet the IC's requirement for— yet again, assume that the object is going to be captured.

Assume that the device is going to be captured. Assume that it's going to get into the hands of a that we can't trust everybody who we give access to the data to. We have to take care of all those problems, and we did. That's awesome. And then, so really the third area that one could protect against would be encryption in use, and it sounds like you guys are solving a little bit of that problem if you only care about the metadata.

So I could know things about this file but keep the file encrypted, where I have seen some people talking lately about encryption methods where you can act on a file even though you don't decrypt it and things like that, which is interesting to me, but it seems very science fiction-y. Well, there are limits to what we can do. For instance, I mean, in our sort of world, the way that our tools work, we'd never decrypt a file in motion or in transit once it's created. We only decrypt it in memory. But that's an exploitable area, right?

So we don't do anything about memory scrapers, right? That's a separate problem from what we have. But if you look, I mean, there are known memory scraper exploits that have been successful, right? But if you look at the breaches that make the news, what's the— Equifax just here recently. Mostly what was breached was unencrypted, and this is always the case, is unencrypted, unstructured data.

People, I mean, you can, you have had some historical breaches that come from somebody getting improper access to a big database, big relational database, but that's actually, I mean, people don't steal databases, right? Most of the time what they do is they're stealing datasets, which are unstructured data, because they've gotten access to the to that access to that database. Well, if you're encrypting the unstructured data and applying the controls to it, you really don't care, right? Because they still can't— you still are able to do things like you can open it up, or you can get the dataset, but you can't open it up unless it's on a device that the application recognizes and that's authenticated to the object. It says these objects are available on this range of devices.

Devices only. All of those things are possible once you solve the fundamental problem of the format the files are created in. I don't know if that makes sense. It makes complete sense. Alright, so now you've developed this Battlefield product.

It sounds like it worked well. Well, it was tested and ready for deployment. And then all of a sudden lost funding. Sequestration hit. The former administration sort of took the posture that, you know, there's better use of those funds because we're not going to need that secure attack because everybody's coming out, right?

This time people are coming out of Iraq and Afghanistan. So this was money that was specifically slotted for those— was tied to those engagements. So when those engagements effectively ended, so did the funding. And this was just one subset of a very large military tactical communications and data storage upgrade. And that all literally is a multi-billion dollar project.

We were just one tiny piece of it. It all went away overnight. So then all of a sudden you guys are sitting here with some cool stuff and nothing to do with it. Well, we had to make a pivot to the commercial market.

That had its good aspects and its bad aspects. Sort of the good thing about that was that like any sort of experimental development shop, we had a wee bit of code boat. The original specification from the military was to build this only in Java. We knew to go to the commercial world. We had to build for all common platforms, which we needed to do.

We needed to do multiple languages.

We needed to extend our ability to synchronize data and keys across multiple platforms, which was a huge challenge and sort of a product distinction for us because there are a lot of people that can do encryption. There are people that do file-level encryption and things like that, but actually synchronizing keys and content across multiple platforms. Typical scenario, I've got something that I need to be able to keep secure, but I've got it on my laptop, I've got it on my phone, I've got it on my tablet, you know, and it's a Windows notebook and an Android phone and an iPad, right? You've got to be able to synchronize keys. So the majority of the work was just in taking that technology and packaging into SDKs and then making it all work across platform.

And the way we did that is we actually built another email system, the complete system. And email is sort of an ideal candidate for doing this sort of testing of the underlying technology. It scales. You have to— if you're going to do an email system, you have to work— it has to work across all platforms. It has to sync across all platforms.

Platforms.

You need to be able to— I mean, that's the basis of it. You need to be able to integrate with other systems, right? You need to have a way to be able to decrypt content legitimately, things for things like data loss prevention systems, things like other archiving systems, threat mitigation systems that need to— so that we chose email because we'd done one already, just in one language. Language, and it's a great testing platform, so we built that entire system out and have people using it now. That's awesome.

You mentioned being able to decrypt for things like data loss prevention and other things like that. You guys have built in the capability that essentially a third-party platform, I would imagine, can use the same SDKs or APIs or whatever it might be, essentially to get access to the encrypted data so that they can see what's going out without essentially decrypting it inline and doing other things like that. So to say a DLP system, it's a system user that has access to the— it can decrypt the content, examine it. So again, because we push the key management encryption decrypt out to the edge, right? You can encrypt or decrypt any authenticated user, be that a person or another system, can decrypt and encrypt where they need to be.

That way, right, the data wherever it's handled is always encrypted, only decrypted in memory for analysis in this particular instance, but not decrypted in transit or in memory. In transit or in storage. And then I'd imagine with this, the control piece that you have built in, if the DLP system decrypts it and says, ooh, this is something I don't want to go out, then it can interface with the control system and say, okay, don't let anybody see this. Yeah, exactly. You don't even have to worry about the transport.

It can get there, but then if now you no longer have permission to see it, it doesn't really matter if you've gotten it or not. Because it's an encrypted blob that they can't do anything with. That's correct. We had this saying, we don't care if people get the data, we care about if they get the information. They can exfiltrate AppShield-protected files all day long.

Have a nice day. I hope you've got lots and lots of spare computing capacity.

Where are you guys today then? You said you built this system. Sort of proof of concept that now people are using email system, right? But you also have the— well, that was the SDK piece. The email system was a means to an end that the SDKs, right, the multiple platform SDKs are really the endgame, because our goal has been to make this technology generally available, right?

And the first commercial SDKs, which was a JavaScript SDK, went into GitHub. Remember the name of it. It went into GitHub in June. C# just went into NuGet, right? So those, those are now tools that are generally available.

We have other languages coming down the pipe here over the next few months. We'll— we've got, you know, JavaScript, Node.js, C#, C# Portable that'll work with Xamarin, Swift for iOS and Android. We have a Python version that we just published, I guess, about in the last 2 weeks or so. So again, any kind of common environment you can think about, we will either have or we will have shortly an SDK for that. And there's also what we call a broker application.

That's the file and key synchronization mechanism that's available as a Python In Python, it's available as a Docker instance. That's not a necessary component, but that's where anywhere you're doing encryption and you need to be able to share that data or sync that data and keys across platforms or across multiple objects. That's also available. Obviously, you have to have that if you're going to be doing any sharing of content. It sounds really cool.

Many times I talk to people that are trying to solve a sort of, I'll say, standard problem in a known way, but maybe in a different way than other people are trying to solve it. This is really— I think it's really interesting that it's a completely different way of trying to solve the problem.

Sort of legacy type of centralized key management-based encryption certainly has a place in the market, but where it tends to fall down is on the endpoints. We now live in this world where we have these huge masses of data that are not only stored, but they're being created on phones and tablets and laptops, and those things need to be able to run in a disconnected environment just from a practicality standpoint. Standpoint, and you can't do that with centralized key management alone. Doesn't mean that we don't necessarily supplant that, but it means if you're going to extend it in the edge, which is what regulations like the New York Department of Finance, ITAR, GDPR in Europe are now all requiring— those things don't give you prescriptions to use a certain framework. They just basically say if you've got data that falls into a specific set of categories, it needs to be encrypted, stop.

But that means it needs to be encrypted everywhere, and so you need something that is a complement to the existing encryption technologies that allows you to be able to do things at the device and the application level, and that's what we do. Yeah, so I'm going to pivot a little bit myself here. Okay. So as you know, we are Colorado Equals Security. Yes.

I wanted to see if I could get your opinions on how it is being a startup in Colorado. Have you guys found the environment here beneficial to you guys? Yeah, I mean, there's, you know, we've obtained local capital resources, which is always nice. It's a, for want of a better term, it's a friendly community for our cybersecurity cybersecurity startup. People here get it.

We've been very— Apptio as a company and us personally, we've been very involved with the National Cybersecurity Center down in the Springs and so forth. So it is, it's a good thing to be in a culture that kind of understands not only what we do, but why we need to do it, right? And that's a great thing about having this particular kind of technology technology in a, in a Denver-based company, Highlands Ranch-based company. That's great. Yeah, that's awesome.

Yeah, I live just up the street. So I'm glad that you guys are close by and doing well. So we're getting towards the end of our time here. I just wanted to see if there was anything else that you wanted to talk about while we're here that we hadn't talked about already.

I can't really think of anything. We've kind of covered the waterfront here. Awesome. Well, if there's nothing else, David, it's been great talking to you. Best of luck to Absio.

It sounds like really cool technology. Thank you. And this has been Colorado Equals Security. Thanks. We'll talk to you next time.

Learn more about the Colorado security scene at colorado-security.com. Where you can see information about local security groups, a calendar of upcoming security events, and learn more about Colorado Equals Security. Reach out to Alex and Robb by emailing info@colorado-security.com.

Until next time, remember, Colorado equals security.