Risky Business - When standards drive innovation

David Cottingham

Risky Business Podcast

When standards drive innovation

Airlock Digital on how to make sure
security standards work


In this Risky Business News interview, Tom Uren talks to Daniel Schell, CTO and David Cottingham CEO of Airlock Digital. They discuss the security standard that drove innovation and the genesis of Airlock Digital and also how to make sure that standards don’t become box-checking exercises.


Risky Business Episode
When standards drive innovation



Hello, everyone.

This is Tom Uren and I'm here with another risky business news sponsor interview.

And today I have with me David Cottingham, who's the CEO and co-founder of Airlock.

Is it airlock or airlock digital?

Airlock digital?

Because there's lots of other airlocks, I suppose.

And also I have Daniel Shell who is the CTO and co-founder.

Good day, Daniel.

Good day David.

Hey, Tom.

Hey, Tom.

So I was thinking about the history of allow listing.

And I remember when I worked at a SD, they came out with what was called the top four and that had a number of mitigations for network defenders.

And I, I seem to remember they said that at the time that if you implemented these, it would cut out 87% of sophisticated intrusions, some like pretty significant number.

And one of them was a allow listing.

And my understanding is that that was the impetus that drove the creation of Airlock digital.

Is that right?

Yeah, that's correct.

So I was working in a federal government department called Industry Science and Research and essentially we had some security requirements that we needed to meet and that was at the same time that the top four came out, we needed to stop malware more effectively.

And it was my job in the security team there to actually go and implement these requirements.

And through that began a very rapid and focused journey of, of learning what worked and what didn't.

And I tried to implement what was called whitelisting at the time now called allow listing and found it to be extremely challenging.

I bricked a lot of things throughout that time, frustrated a lot of users, I accidentally once patched the entire departments server fleet, much to the dismay of, of administrators, but we got the patching done.

But e essentially through, through a lot of that learning and that practical hands on, we did get a allow listing done and it was through a whole bunch of hacky tools.

Essentially what I went on to do then is I wrote a training course for this, a company called the Sands Institute which taught security practitioners how to implement these controls.

It was a three day course and two out of three days was on allow listing.

Specifically, people came away from the course saying all these Hackey tools that you've put together is too hard, too difficult, it will never work.

And I sort of agreed to be honest, but I guess through all of that thinking and work, I met Daniel at a trade show and basically realized that if, if we're gonna do this.

We need to take all these hacky tools and turn it into something and that sort of really started the company and Daniel and I and some other developers worked for about five years just to start building the, what is the base of the product today?

So a SD a government body said these standards should apply across federal government.

And so there's a market there in the Australian federal government market.

I'm wondering how that's translated overseas.

So,, one thing that was really interesting, we, we developed it with the federal government in mind because of these standards.

But it wasn't until quite a few years in, until we got one of the federal government agencies as a customer and, and, and today, many more of them and our first customers were, Australian companies that supplied federal government because the federal government said, hey, if you're going to supply us with services, then you need to do the top four, the standard that was here.

And so companies were trying to figure out how to do that.

And that's where we found a lot of success early on.

And then also through contacts, we got a,, us,, sales rep reasonably early on in the piece that was based over in the US.

And we started picking up a number of different organizations around there that we're just looking at doing this because it is a good security control to do even without a standard that was driving the adoption of a allow listing over in the States.

I think security practitioners know that that type of posture, you know, choosing what you trust and, and blocking everything else is just a foundation, good security control.

And noone argues that it's ineffective or, or doesn't provide benefit.

And we started picking up a lot of, a lot of companies that were just trying to get that extra level of risk reduction within their environments, particularly a lot of industrial control system, manufacturing type environments and that's really continued to expand.



I, I always thought that you were a Windows Shop.

Is that right?

No, we have Windows Mac and also Linux as well.



And we support a lot of legacy operating systems as well.

We support Windows XP all the way still today to modern Os S and that's just because there's so much out there.

Yeah, I'd say our, our most successful criteria for landing in the US was that we supported Windows XP.

And so that's the industrial control system, pharmaceuticals and defense, defense manufacturing over sees a lot of that and at that time as well.

I guess we also were quite lucky to establish a relationship with Crowdstrike as well.

For crowdstrike was you know, at that time being in the EDR market competing with Carbon Black, which didn't allow this thing or had that sort of capability.

And we solved a bit of a problem for people who are looking for, you know, crowds strike EDR.

But then they say, hey, but we know this, allow listening.

Oh, we've had good experience with this.

How do we keep doing that?

So we had sort of a partnership with them that if they ran into sort of opportunities with an allow this requirement, then they would bring us to the table as well in a way ad saying that you should do a LA listing was very much a stretch goal in that everyone thought it was a good idea, but just no one was doing it because it was too hard.

Is that, that's the vibe I'm getting.

So, yeah, that, that's correct.

You know, we, we wouldn't exist if it wasn't for that standard.

That really pushed us to do it.


Now, now the question I have is that as far as I know in terms of government organizations or cybersecurity authorities, a SD is still the only one that says that at least for federal government.

So it's not, I, I think it recommends it for everyone, but as far as I know for federal government, it's required none of the other ones I'm aware of like CIA or the U K's N CS C has gone that far.

Is that right?

There are a few I wouldn't say as far and with clear decisive guidance.

Now, I think that there's another standard that's out of Canada, which is called the top , it, security actions.

And number  on that list is implement application allow lists.

Also the top four we got on there.

That's it.

There, there's been actually a lot of discussion about whether it's a ranked list in terms of affecting these things or not.

But,,, yeah, so there, there's that Canadian standard that calls it out.

There's a standard in New Zealand, I believe that calls it out.

And in the United States there is a nist paper on doing what they still refer to in that paper as whitelisting and where you see allowed listing pop up in the States is generally in threat intelligence, the logs of countermeasures to nation state type attacks.

So if there's a big campaign which which there was recently, I think volt typhoon Daniel was it?

Yeah, and that was, that was really interesting to us as well because I guess you've seen that with cybersecurity agencies across the different five eyes countries have been now doing sort of joint press releases quite frequently.

And for the volt typhoon one, then you know, there was a specific call out in that one saying that, you know, allow this will be an effective control, which is the first time we've seen that particularly with that one being sort of maybe more sourced out of the US.

So we're seeing more guidance there in the US.

We also saw, we had a lot of seen a lot of interest and uplift around the CM MC, which is sort of the maturity model that's used in the supply chain to, you know, use military industrial fleet.

They've just done our version two of that now and it seems to be in flux a little bit and it relies on the NIST framework which is quite, quite a detailed document with many controls and such.

But then you have different levels of maturity, there's different levels of importance on and not allow this thing as a control there.

Now, do you have a theory why those organizations haven't like c for example, hasn't mandated something like allow listing, I guess they just don't mandate things perhaps.

Yeah, II, I think that's kind of it.

I, I just feel like in Australia what really helped of all work was, yeah, you know, it said must next to it and there it was, you know, also put into contracts in similar ways saying, hey, like if you want to do business with us, you need to meet these or implement these controls.

And I feel like just culturally, it's, it's a little bit different over there.

And yeah, I once asked some high ranking people in the US and they sort of came back and said, you know, we don't tell people how to suck eggs.

All the quote I got back.

That's that, that is quite funny because it assumes that everyone knows the same amount of information.

Whereas I guess the Australian assumption is that as d actually knows more than a lot of other network defenders.


And,, look, I would say, you know, definitely the United States, as far as industry goes, you, you've got the massive tech companies over there, you know, that have a huge amount of capability.

But I, I think the Australians, it, it's the approach that works really well because it, it's guiding everyone.

We, we sort of need to have, you know, rising tide to float all boats kind of thing where we need to get organizations that are even on the, the small to medium end of the industry to start getting good cyber security controls in place because that's represents a significant portion of the economy and doctor surgeries and M SPS that are delivering services to a huge amount of business need to implement these type of controls to better defend a large portion of the economy.

Yeah, and, and, and I, I I'd say that, you know, in my opinion, why I think the essential eight is really great is that it's eight things decided to be a bit simple and approachable.

The top four evolved into the essential eight.

So it's now the essential eight.

Yeah, you know, and they essentially, it added a few more things like, hey, you know, make sure you do backups and stuff like that like, you know, so that's good ideas.

But what's really good is my understanding is based on the A SD incident response that these are the things that were actually effective.

When I think like when we see a lot of things in the US markets or you look at something like NIST and you go OK, I've got two controls, but which ones are the most effective or which ones get, what's the most bang for your buck?

I think that's what, where that's really helped here in the local market and it's really been the adopted standard.

You know, it started as this government standard, but now it's borderline a national standard if you're on a board meeting in Sydney at some corporate and, you know, you get one of the big auditors in and say, well, should we do a subsidy, they'll say implement the essential eight.

So it's really amazing to see that outcome.

Yeah, I think you're right about it being based on incident response, which was why they were able to come up with an 87% figure and, and government departments don't put out random figures like that if they don't have some.

So it's, it's not like marketing where you would just make up 87% because it sounds good.

Yeah, and, and marketing is a big piece of this as well, right?

Because I think, you know, once the essential aid came out, everyone suddenly became an allow listing vendor, but the and then the A SD had to release some documents on what is and what isn't allow listing.

So, you know, it, it it's a really interesting that that's why the maturity model came out to your Yeah, everyone's allow listing vendor comment because suddenly people said, well, we're doing patching and then they still got breached or still had a problem.

And then it turns out that everyone's definition of doing patching well is different.

So I think the maturity model which overlaid those eight controls is really good at communicating that not all implementations are created equal.

And, and that's where the specifics came in for the tech audience to actually get each control nailed down.

So it provided that security outcome that you're looking for.

And I think the whole that standard package together, it had executive notes, it had sort of the management notes, which is he's the thing you need to do.

And then it had the technical guidance which backed onto that because it took that real approach across the business in order to drive adoption.

I was speaking to a, a sizer and he said, I love checklists because I can check them off and I don't necessarily need to even improve security.

I can just step through that process and maybe security has improved as a, a side effect.

So do you think that I, I and I'm sure you're gonna say no, do you think that having something like the top four where you have a LA listing as one of those air quotes check boxes.

Does that empower security teams or is it in a way allowing them to check the box without actually achieving anything?

I, I, I'd say on that, that's where I think what they've mentioned before, the maturity model is, is more prescriptive.

So it's not just going, yeah, it's, it's, it's not the tool or the, you know, it's, it's their strategies.

And so for example, you know, with the patching, let's say it might be like you must patch, you know, within 48 hours on internet facing servers for critical situations.

Are you doing that?

You know, it's easy to be audited, I guess.

But if you tick that, that's the thing, something I found really interesting is that like I said before, that we get like lots of these vendor security questionnaires and we also have to complete them ourselves with our partners and supply new people that we buy off.

Some of the ones I get are five  questions and it takes, it would take three days possibly to do, you know, doing it properly.

You sit there and you go through them all, you know, and we have tools that help automate and wizard some of the answers, but it really needs a sanity check.

But one of our customers once sent me the essential eight matrix of the maturity model and said, Mark where you are on this matrix and that was a probably a more thorough and probably had more value than these spreadsheets of  questions which just like, do you patch within this time on these servers?

Do you do a lot listing on your servers?

You know, do you manage privilege correctly?

The, the, the these were better questions.

I, I felt, I, well, that was actually made me think more and go whoa like let's go through these.


So I, I guess II I would say that, you know, any standard can be turned into a check box.

TK exercise.

The essential eights is quite a short, a short one.

But I, I think that what that standard tries to do to combat that is by tying it to actual real world process rather than necessarily the thing that you're doing.

So it's like, you know, patching within 48 hours that is a process that you need to implement in order to satisfy that.

And there's a reason that strategy is used because it's not a, it's not her control, it's not something that you implement and leave.

It's something that you strategically need to put as part of your business process that's managed over time.

That's what makes it secure.

And, and I think that's a big differentiator.

I think also the only way to combat the checklist is to have something that says, prove it.

And I think the security industry is getting better at this.

But I think that we as vendors also have a responsibility to prove that the things that we're implementing are effective, you know, by writing tools that actually test and validate what's being entered.

Because the best way to say that you're complying with the control.

If it's an action that you're undertaking, you need to prove that you're undertaking that action.

If it's a technical control saying is this configured, you need to prove and show evidence that that's configured.

And the only way you can do that is through testing or that type of validation.

So the more we as an industry can and make that process easier for auditors that the better results and the less tick and flicks you'll get David Cottingham and Daniel Shell.

Thanks a lot.