1
00:00:03,759 --> 00:00:05,679
Speaker 1: The mission of our company is to be the digital

2
00:00:05,719 --> 00:00:07,960
backbone of the world's critical infrastructure.

3
00:00:11,000 --> 00:00:15,039
Speaker 2: Welcome listeners to the Industrial Security Podcast. My name is

4
00:00:15,160 --> 00:00:18,760
Nate Nelson. I'm here with Andrew Ginter, the vice president

5
00:00:18,879 --> 00:00:23,079
of Industrial Security at Waterfall Security Solutions, who's going to

6
00:00:23,120 --> 00:00:26,199
introduce the subject and guests of our show today. Andrew,

7
00:00:26,359 --> 00:00:26,839
how's it going.

8
00:00:27,640 --> 00:00:30,359
Speaker 3: I'm very well, Thank you, Nate. Our guests today, we

9
00:00:30,440 --> 00:00:34,320
have two of them, are Daily Brown and Nick Foubert.

10
00:00:36,079 --> 00:00:41,159
Daily is the CEO, Nick is the Chief Technology Officers CTO.

11
00:00:41,719 --> 00:00:46,560
They are both co founders of Metropolitan Technologies, and they

12
00:00:46,560 --> 00:00:50,240
are working on a new and more secure platform, a

13
00:00:50,240 --> 00:00:54,719
whole new way of doing industrial control systems.

14
00:00:55,359 --> 00:00:58,920
Speaker 2: Then, without further ado, let's jump right into your interview.

15
00:01:01,880 --> 00:01:06,200
Speaker 3: Hello Daily, Hello Nick, Welcome to the podcast. Thank you

16
00:01:06,239 --> 00:01:09,840
for joining us. Before we get started, can I ask

17
00:01:09,959 --> 00:01:12,200
each of you to tell our listeners a little bit

18
00:01:12,280 --> 00:01:15,280
about yourselves, about your background, and about the good work

19
00:01:15,280 --> 00:01:17,400
that you're doing at Metropolitan Technologies.

20
00:01:18,040 --> 00:01:20,799
Speaker 1: Yeah, sounds good, so I guess i'll start. Thanks for

21
00:01:20,840 --> 00:01:23,599
having us on, Andrews. I'm Daily, I'm the co founder

22
00:01:23,640 --> 00:01:27,799
and CEO of Metropolitan Technologies. Just a bit about my background,

23
00:01:27,879 --> 00:01:30,159
so I have about fifteen years of experience in the

24
00:01:30,159 --> 00:01:33,439
aerospace and defense industry as a system in software engineer.

25
00:01:34,200 --> 00:01:36,959
Prior to founding our startup, I worked for a big

26
00:01:37,000 --> 00:01:39,680
company called General Dynamics Mission Systems, and I had roles

27
00:01:39,719 --> 00:01:42,439
such as a product owner, technical lead, and senior engineer. There,

28
00:01:43,920 --> 00:01:47,200
I was responsible for design, development, testing, and deployment of

29
00:01:47,239 --> 00:01:51,200
various mission critical applications on airborne platforms, and they also

30
00:01:51,319 --> 00:01:55,680
led research collaborations with academia in artificial intelligence, machine learning,

31
00:01:55,799 --> 00:01:59,799
target tracking, and information fusion. And I let Nick introduce himself.

32
00:02:00,519 --> 00:02:02,879
Speaker 4: Yeah, Hi, Andrew, thanks for having us on the podcast.

33
00:02:03,359 --> 00:02:05,719
I'm Nick Foubert and the other co founder and the

34
00:02:05,719 --> 00:02:09,719
CTO of Metropolitan Technologies. I have roughly fourteen to fifteen

35
00:02:09,759 --> 00:02:12,240
years of experience in industry as a systems and software

36
00:02:12,240 --> 00:02:16,439
developer and like Daily. Before founding Metropolitan, I also worked

37
00:02:16,479 --> 00:02:19,159
at General Dynamics Mission Systems as a technical lead and

38
00:02:19,240 --> 00:02:23,560
senior software developer. I worked on mission critical applications on

39
00:02:23,680 --> 00:02:26,439
airborne platforms, and Daily and I actually worked pretty closely

40
00:02:26,479 --> 00:02:28,599
together there for four or five years before leaving to

41
00:02:28,639 --> 00:02:32,520
start Metropolitan. Before General Dynamics, I had done some other

42
00:02:32,560 --> 00:02:36,319
work in biometric security and biomedical applications of machine learning.

43
00:02:37,080 --> 00:02:37,360
Speaker 3: Right on.

44
00:02:37,520 --> 00:02:38,960
Speaker 1: Yes, So I guess I'll talk a bit about our

45
00:02:38,960 --> 00:02:42,240
startup or I'll introduce it anyways. So, Metropolitan Technologies is

46
00:02:42,280 --> 00:02:46,039
an early stage Canadian startup. Were based in Ottawa, Ontario, Canada.

47
00:02:47,120 --> 00:02:49,439
We founded the company to build reliable and secure commercial

48
00:02:49,439 --> 00:02:52,360
products based on our experience in the aerospace and defense industry.

49
00:02:53,560 --> 00:02:56,080
When we first started the company, our first idea was

50
00:02:56,080 --> 00:02:58,400
to build smart city products with a focus on privacy

51
00:02:58,439 --> 00:03:01,439
and equity. After you would have been a market research

52
00:03:01,560 --> 00:03:04,360
for a platform to build upon, we didn't find anything

53
00:03:04,360 --> 00:03:08,039
that met our actual standards for security, privacy, and reliability,

54
00:03:08,439 --> 00:03:10,840
so we decided to build our own. It also became

55
00:03:10,840 --> 00:03:13,599
apparent at the time the market opportunities for our own

56
00:03:13,639 --> 00:03:16,919
platform were greater than the smart city applications we first

57
00:03:16,960 --> 00:03:19,400
sought to build, so we did a bit of a

58
00:03:19,400 --> 00:03:21,759
pivot and to focus our concentration on building out the

59
00:03:21,759 --> 00:03:25,759
platform and expand beyond cities, just broader critical infrastructure and

60
00:03:25,800 --> 00:03:29,400
industrial security market. And so consequently we end up building

61
00:03:29,400 --> 00:03:33,479
a secure by design and default decentralized IoT connectivity and

62
00:03:33,520 --> 00:03:38,400
cybersecurity platform help organizations connect and secure their OT networks

63
00:03:39,000 --> 00:03:41,400
and yeah, so that's a brief introduction about us.

64
00:03:42,199 --> 00:03:45,599
Speaker 3: You guys are doing some stuff that sounds really interesting.

65
00:03:45,680 --> 00:03:48,120
I mean, this is why I asked you to join

66
00:03:48,199 --> 00:03:52,680
us on the show. You've mentioned zero trust and IoT

67
00:03:53,000 --> 00:03:57,000
Internet of things. You're talking about a platform, you know,

68
00:03:57,120 --> 00:04:00,000
I know that you're also touching on stuff like mesh

69
00:04:00,120 --> 00:04:05,280
networks and formal methods. You know, it's it's a bit

70
00:04:05,280 --> 00:04:07,800
of a buzzword soup. But you know, if you're doing

71
00:04:07,840 --> 00:04:09,840
this all I thought I got to have these people on,

72
00:04:10,560 --> 00:04:13,520
can you break it down for us? You know, you

73
00:04:13,719 --> 00:04:19,160
have a product line? What do you have? What is it?

74
00:04:19,199 --> 00:04:19,800
What does it do?

75
00:04:20,720 --> 00:04:23,600
Speaker 1: Yeah, so I'll start a bit about that. I get

76
00:04:23,600 --> 00:04:26,360
carried away. Actually sometimes with the buzzards and slogans. I

77
00:04:26,360 --> 00:04:28,439
think it's indoctrinated in me for my time working in

78
00:04:28,439 --> 00:04:31,399
the defense industry. I'm pretty sure there's conversations we actually

79
00:04:31,480 --> 00:04:33,680
used to have where we only spoken acronyms or buzzy

80
00:04:33,680 --> 00:04:36,480
slogans and so old habits die hard. But I'll try

81
00:04:36,519 --> 00:04:38,279
to be speak like more of a human so that

82
00:04:38,319 --> 00:04:41,519
people can understand and be cognizant of it. So, like

83
00:04:41,560 --> 00:04:44,279
I mentioned in the opening, we're building a decentralized IoT

84
00:04:44,399 --> 00:04:48,519
connectivity and OT cybersecurity platform. We're also working on a

85
00:04:48,519 --> 00:04:51,199
pre integrated edge appliance to simplify the integration of our

86
00:04:51,240 --> 00:04:55,040
technology with existing OT networks. And so many of the

87
00:04:55,079 --> 00:04:57,639
ideas that are built into our platform are based on

88
00:04:57,680 --> 00:05:00,959
our experience in defense and aerospace industry. We wanted to

89
00:05:01,000 --> 00:05:04,600
combine the resilience and security of tactical battlefield networks and

90
00:05:04,639 --> 00:05:09,120
the reliability of safety riabilia and safety of avionic software

91
00:05:09,160 --> 00:05:11,240
that we used to work on. And so it just

92
00:05:11,240 --> 00:05:14,000
so happens that equation leads to a parade of buzzwords.

93
00:05:14,680 --> 00:05:16,519
And I'll let Nick maybe go into a bit more

94
00:05:16,560 --> 00:05:18,079
about what that means right now.

95
00:05:18,639 --> 00:05:21,319
Speaker 4: Yeah, So we're using a number of techniques to build

96
00:05:21,319 --> 00:05:23,800
our platform, and I guess these are kind of getting

97
00:05:23,839 --> 00:05:25,879
back into buzzwords here, but we can dive into some

98
00:05:25,959 --> 00:05:28,439
of them as we continue the conversation. But so things

99
00:05:28,519 --> 00:05:33,279
like zero trust security model, data centric encryption, formal methods,

100
00:05:33,600 --> 00:05:38,040
mash networking, among other things. We're using similar types of

101
00:05:38,040 --> 00:05:41,600
technologies you might find in battlefield networks in the military.

102
00:05:42,279 --> 00:05:45,560
So one example of that. We're a software platform, but

103
00:05:45,600 --> 00:05:48,920
we're building our platform to support different networking topologies like

104
00:05:48,959 --> 00:05:51,519
mesh networks that you don't typically find in the traditional

105
00:05:51,639 --> 00:05:55,879
enterprise IT network. So our software components communicate peer to

106
00:05:55,959 --> 00:05:58,800
peer and that helps us minimize the amount of centralized

107
00:05:58,839 --> 00:06:03,319
infrastructure need to rely on. So even when the peers

108
00:06:03,360 --> 00:06:06,360
in the network need to communicate with a central service

109
00:06:06,399 --> 00:06:08,720
like a cloud service, for example, and they might need

110
00:06:08,759 --> 00:06:11,839
to do that to do things like help discover other

111
00:06:11,920 --> 00:06:15,439
peers in the network, even those more centralized services are

112
00:06:15,439 --> 00:06:18,399
designed to be distributed and tolerant to network outages and

113
00:06:18,439 --> 00:06:23,160
network changes. The data plane in our platform uses a

114
00:06:23,199 --> 00:06:27,000
publish subscribe paradigm. What that means is that our software

115
00:06:27,000 --> 00:06:30,839
components don't need to know specifically which other components they're

116
00:06:30,839 --> 00:06:34,639
communicating with, but rather they just advertise what types of

117
00:06:34,720 --> 00:06:37,439
data they can provide and what types of data that

118
00:06:37,480 --> 00:06:40,160
they want to consume, and then our software takes care

119
00:06:40,199 --> 00:06:43,680
of actually moving the data between the components. This lets

120
00:06:43,720 --> 00:06:46,519
us do things like tune quality of service and enforced

121
00:06:46,519 --> 00:06:50,399
security controls, among a bunch of other benefits. And the

122
00:06:50,439 --> 00:06:52,439
reason we're building it this way is because we want

123
00:06:52,439 --> 00:06:55,959
our platform to be usable in the most challenging industrial environments,

124
00:06:56,079 --> 00:06:59,319
whether that's on a battlefield, deep in a mine or

125
00:06:59,439 --> 00:07:03,199
monitoring remote asset in the Arctic. So yeah, I think

126
00:07:03,240 --> 00:07:04,920
that kind of gives you a high level picture of

127
00:07:05,279 --> 00:07:08,120
what we're doing as far as MESH networking is concerned.

128
00:07:11,199 --> 00:07:14,279
Speaker 2: So Daily just there promised us a parade of buzzwords,

129
00:07:14,399 --> 00:07:17,000
and they very much followed through. One of them that

130
00:07:17,040 --> 00:07:21,959
stood out to me and trew the publish subscribe paradigm.

131
00:07:22,120 --> 00:07:23,399
Do you want to help me out with that one?

132
00:07:24,519 --> 00:07:26,399
Speaker 3: I got sort of two things out of it, mesh

133
00:07:26,439 --> 00:07:28,560
and published subscribe. I let me start with mesh first

134
00:07:28,600 --> 00:07:31,839
and then I'll come to pub sub Mesh is sort

135
00:07:31,879 --> 00:07:35,920
of the concept that not everything I mean, on an

136
00:07:35,959 --> 00:07:39,360
IT network generally speaking, you know, give or take a firewall,

137
00:07:39,720 --> 00:07:42,079
everything can talk to everything. Anything wants to send a

138
00:07:42,079 --> 00:07:44,480
message to anything else, You open a connection and there

139
00:07:44,519 --> 00:07:48,079
you are with you know, with industrial networks, frequently you

140
00:07:48,079 --> 00:07:51,199
have devices in the field, well you know, solar powered.

141
00:07:51,959 --> 00:07:54,360
They might not be on the cellular network. They might

142
00:07:54,480 --> 00:07:57,040
have sort of a local radio link to an aggregator

143
00:07:57,079 --> 00:07:59,439
that's on the cellular network across blah blah blah. It

144
00:07:59,480 --> 00:08:03,079
gets complete, and so it's generally not the case that

145
00:08:03,240 --> 00:08:05,639
things can talk to each you know, it rather can

146
00:08:05,680 --> 00:08:09,160
talk to anything, They can talk to their neighbors, and

147
00:08:09,199 --> 00:08:11,759
they can pass messages along. And this is the essence

148
00:08:11,759 --> 00:08:15,959
of mesh networking. You see it used sometimes in meter

149
00:08:16,120 --> 00:08:20,079
reading where not every you know, meter might have a

150
00:08:20,120 --> 00:08:22,199
sin card that lets you on the Internet, or not

151
00:08:22,279 --> 00:08:25,439
every meter might be wired into something and a local

152
00:08:25,920 --> 00:08:29,360
community of you know, smart meters might talk to each

153
00:08:29,399 --> 00:08:32,200
other and find the one that has the connection to

154
00:08:32,279 --> 00:08:35,000
the you know, the fiber optic backbone and send all

155
00:08:35,000 --> 00:08:37,399
of their readings into there. So this, this idea of

156
00:08:37,440 --> 00:08:40,679
a mesh network where you know, devices cooperate in a

157
00:08:41,039 --> 00:08:44,639
challenging communications environment, is something you see in sort of

158
00:08:44,960 --> 00:08:49,639
limited applications of industrial networks. And you know, these folks

159
00:08:49,639 --> 00:08:52,960
at Metropolitan Technology they want to make this sort of intrinsic.

160
00:08:53,120 --> 00:08:57,080
It's the natural way that everything in their system communicates.

161
00:08:57,559 --> 00:09:02,600
And when they communicate, they don't make connections like TCP connections.

162
00:09:02,600 --> 00:09:05,279
They don't connect to each other. It's hard to figure

163
00:09:05,279 --> 00:09:08,480
out who to connect to. When they communicate, they just

164
00:09:08,559 --> 00:09:11,200
say here's what i've got. I've got meta readings for

165
00:09:11,240 --> 00:09:15,440
this address. Here they are, and anybody who wants that

166
00:09:15,519 --> 00:09:18,879
information subscribes to it. So sending it out is called publishing.

167
00:09:18,919 --> 00:09:21,879
You give it a tag, you know, meta reading DASH

168
00:09:22,039 --> 00:09:25,679
for dash this address, and you push it out and

169
00:09:25,759 --> 00:09:29,679
anyone who wants that subscribes. They say, I want all

170
00:09:29,720 --> 00:09:33,440
of the tags that start with meta reading. And because

171
00:09:33,480 --> 00:09:36,759
this is the consumer the accounting system. So this is

172
00:09:36,799 --> 00:09:40,360
the concept of mesh. This is the concept of published subscribe.

173
00:09:40,519 --> 00:09:43,200
You don't connect to things. You just push out what

174
00:09:43,279 --> 00:09:47,720
you have and other people, you know, consume it. And

175
00:09:48,600 --> 00:09:50,840
you know this, you know the pup pup sub is

176
00:09:50,840 --> 00:09:53,600
is also used in industrial networks. Some you know, a

177
00:09:53,639 --> 00:09:58,320
small number of big name industrial vendors, like twenty maybe

178
00:09:58,320 --> 00:10:00,600
even thirty years ago when pup sub just sort of

179
00:10:00,720 --> 00:10:05,720
was invented, adopted pub sub wholesale and one or two

180
00:10:05,799 --> 00:10:09,399
of the big vendors out there use it internally everywhere,

181
00:10:10,080 --> 00:10:15,960
but even everybody else in the industrial world, most of

182
00:10:16,000 --> 00:10:20,240
them use published subscribe to talk to the cloud because

183
00:10:20,799 --> 00:10:26,600
the MQTT protocol has emerged as you know, the dominant

184
00:10:26,639 --> 00:10:30,080
way to talk to the industrial cloud or the Internet

185
00:10:30,120 --> 00:10:36,360
of things cloud, and MQTT is intrinsically pub sub you know,

186
00:10:36,440 --> 00:10:38,879
So when I don't know, a smart watch talks to

187
00:10:38,919 --> 00:10:42,240
the cloud, or you know, any smart device talks to

188
00:10:42,279 --> 00:10:45,320
the cloud three times out of four. It's using MQTT,

189
00:10:45,480 --> 00:10:48,720
it's using pub subs. So these are not alien concepts

190
00:10:49,080 --> 00:10:52,600
in industrial automation. But what Metropolitan Technology has said is

191
00:10:53,120 --> 00:10:55,639
this is the right way to do this, and they've

192
00:10:55,639 --> 00:11:02,200
made it the default. It is the way their stuff communicates. So,

193
00:11:02,679 --> 00:11:05,279
if I may a clarifying question, I heard you use

194
00:11:05,320 --> 00:11:08,279
the phrase data plane, and I hear people use that

195
00:11:08,519 --> 00:11:12,600
phrase from time to time, and I've never figured out

196
00:11:12,919 --> 00:11:18,039
really what it means. You know, in my understanding in

197
00:11:18,200 --> 00:11:22,000
deep history, it might have come from telecoms, where you

198
00:11:22,639 --> 00:11:27,759
tended to have maybe two sets of wires, one for communicating,

199
00:11:27,960 --> 00:11:31,679
you know, the voice communications the phone calls back fifty

200
00:11:31,759 --> 00:11:37,200
years ago, and a separate kind of communications mechanism for

201
00:11:37,320 --> 00:11:42,159
communicating you know, metadata like call setup or billing or

202
00:11:42,200 --> 00:11:47,720
who knows what today. You know, we're talking the Internet.

203
00:11:49,039 --> 00:11:51,840
What's the difference between a data plane and any other

204
00:11:51,919 --> 00:11:53,360
plane in the Internet?

205
00:11:53,679 --> 00:11:57,039
Speaker 1: If you can, yeah, so I can jump in right here.

206
00:11:57,679 --> 00:11:59,720
So we kind of divide our system up into two

207
00:11:59,759 --> 00:12:01,799
different planes, or we call them planes. We call it

208
00:12:01,840 --> 00:12:05,039
when's the data plane and one's the management and control plane.

209
00:12:05,720 --> 00:12:08,039
And the reason we differentiate. This is because the actual

210
00:12:08,080 --> 00:12:10,840
means of communication are slightly different. So when we say

211
00:12:10,840 --> 00:12:13,759
our systems decentralized, we mean the data plane of our

212
00:12:13,799 --> 00:12:16,639
systems decentralized and the data We consider the data plane

213
00:12:16,679 --> 00:12:19,840
all the operational technology data, so sensor data, actuator and

214
00:12:19,879 --> 00:12:22,440
control data, and the other type of data you would

215
00:12:22,480 --> 00:12:26,039
find when when, for example, working with an industrial control system,

216
00:12:26,840 --> 00:12:30,960
the management and control plane, we consider that things like

217
00:12:31,039 --> 00:12:35,759
access control, security policies, remote the health and monitoring of

218
00:12:35,799 --> 00:12:39,200
the actual application, things like that, and so that part

219
00:12:39,240 --> 00:12:43,840
of our platform can be centrally managed and locally enforced.

220
00:12:43,440 --> 00:12:47,080
But that's why we differentiate between the two. And I

221
00:12:47,080 --> 00:12:48,480
don't know, Nick, did you want to jump in there

222
00:12:48,480 --> 00:12:49,399
and clarify anything.

223
00:12:50,440 --> 00:12:52,639
Speaker 4: Yeah, I think you've covered most of the points, and

224
00:12:53,000 --> 00:12:55,919
we'll get into a little bit more about our zero

225
00:12:55,919 --> 00:13:00,240
trust security model. But I think Daily mentioned our PM

226
00:13:00,279 --> 00:13:03,679
is a software platform, but we organize it in two

227
00:13:03,759 --> 00:13:06,320
layers as far as the communication infrastructure goes, and we

228
00:13:06,360 --> 00:13:10,000
have an outer layer that kind of provides a level

229
00:13:10,039 --> 00:13:12,840
of perimeter security. So there's an encrypted outer layer, and

230
00:13:12,879 --> 00:13:16,639
then the inter layer of that is another separately encrypted

231
00:13:16,720 --> 00:13:19,879
layer of data, and that's just that's typically what we

232
00:13:19,919 --> 00:13:22,360
refer to when when we're talking about the data plane.

233
00:13:23,000 --> 00:13:25,480
Speaker 3: Just so I'm clear, Like I said, I'm old school,

234
00:13:25,639 --> 00:13:29,039
I never I've for decades, I've wondered what this stuff means.

235
00:13:30,440 --> 00:13:32,480
What I'm hearing you say is that in the modern world,

236
00:13:33,440 --> 00:13:38,240
it's more or less all Internet protocol at the core,

237
00:13:38,799 --> 00:13:42,240
but we're talking maybe a different set of TCP ports

238
00:13:42,399 --> 00:13:47,360
or maybe even UDP ports, different set of protocols for

239
00:13:47,559 --> 00:13:49,720
the data plane, which is sort of a collection of

240
00:13:50,240 --> 00:13:53,240
protocols and services that are focused on moving the data

241
00:13:53,279 --> 00:13:56,360
around or managing the data. And the management plane that

242
00:13:56,559 --> 00:14:00,879
is more a set of protocols and services focused on

243
00:14:01,320 --> 00:14:07,039
managing the system, configuring the system, rather than dealing second

244
00:14:07,080 --> 00:14:09,519
by second with the data. Is that fair in terms

245
00:14:09,559 --> 00:14:10,960
of terminology.

246
00:14:11,120 --> 00:14:13,080
Speaker 1: Yeah, I'd say that's a pretty good way of describing it.

247
00:14:13,559 --> 00:14:16,159
Speaker 3: Okay, sweet, because I've always wondered if it's, you know,

248
00:14:16,879 --> 00:14:20,519
something much more exotic. So thank you for that.

249
00:14:20,639 --> 00:14:22,759
Speaker 1: You have it right, and it's a good The example

250
00:14:22,799 --> 00:14:24,919
you gave earlier about the wires and the metadata for

251
00:14:24,960 --> 00:14:27,519
the telephone system and then the actual voice over the

252
00:14:27,559 --> 00:14:29,879
vice part of that is a pretty good analogue to that.

253
00:14:30,159 --> 00:14:34,799
Speaker 3: So let's dig into some of your your your other concepts. So,

254
00:14:35,039 --> 00:14:42,799
you know you've you've mentioned mesh. You know you've mentioned Mesh,

255
00:14:42,840 --> 00:14:48,200
You've mentioned cloud, you've you've defined a mesh communications system.

256
00:14:49,159 --> 00:14:51,000
What are you using it for? Sort of what's the

257
00:14:51,039 --> 00:14:54,279
next layer of functionality you're building in.

258
00:14:55,039 --> 00:14:57,360
Speaker 1: Yeah, so let's maybe talk about the zero trust security

259
00:14:57,360 --> 00:14:59,679
model of it, because that'll that'll describe a bit about

260
00:14:59,679 --> 00:15:01,960
the kind of the shell of how it works, and

261
00:15:02,000 --> 00:15:03,440
then we can kind of dive deeper into some of

262
00:15:03,440 --> 00:15:06,799
the other technologies that we're applying to make the system secure.

263
00:15:07,679 --> 00:15:11,159
And so just related to zero trust our platform, we

264
00:15:11,200 --> 00:15:13,360
built it from the beginning to have a zero trust model,

265
00:15:14,080 --> 00:15:16,759
and the idea of relying on something like perimeter security

266
00:15:16,799 --> 00:15:19,720
for a software system never sat well with me, even

267
00:15:19,759 --> 00:15:23,720
before the term zero trust became sort of mainstream, and

268
00:15:23,759 --> 00:15:25,200
so it's one of the reasons we sought to build

269
00:15:25,200 --> 00:15:28,440
our own activity platform is that when we're doing market research,

270
00:15:28,519 --> 00:15:30,840
we found that there was too much implicit trust in

271
00:15:30,919 --> 00:15:35,000
many of the existing solutions, and so we built our platform,

272
00:15:35,120 --> 00:15:38,039
as Nick mentioned, to consist of two independent security layers,

273
00:15:38,080 --> 00:15:42,080
each with their own zero trust security model. The outer

274
00:15:42,200 --> 00:15:45,080
Mesh network layer that we've built can overlay untrusted and

275
00:15:45,120 --> 00:15:48,879
unsecured networks, and so each node in that network is

276
00:15:49,000 --> 00:15:53,200
mutually authenticated continuously, whether it's a service user device, and

277
00:15:53,240 --> 00:15:56,639
so this provides broad protection against what we'd call like

278
00:15:56,679 --> 00:16:00,919
outside threats to an OT network. We have an inner

279
00:16:01,039 --> 00:16:04,600
peer to peer layer that provides data centric encryption, ensuring

280
00:16:04,639 --> 00:16:07,039
that all data in our OT network is accessed on

281
00:16:07,080 --> 00:16:09,759
a need to know basis. And so this inner layer

282
00:16:09,840 --> 00:16:12,759
provides very fine grain control over who sees what and

283
00:16:12,799 --> 00:16:15,679
who can connect to whom, helping protect what we would

284
00:16:15,720 --> 00:16:19,000
say the OT network against insider threats. And so these

285
00:16:19,039 --> 00:16:22,120
access control policies are locally enforced at each node in

286
00:16:22,120 --> 00:16:24,679
our network, and this ensures that the zero trust security

287
00:16:24,679 --> 00:16:28,279
model is enforced even if we face network partitions or outages.

288
00:16:29,080 --> 00:16:30,720
And so we take the idea of zero trust even

289
00:16:30,720 --> 00:16:33,519
further than that, actually further than the conventional definition that

290
00:16:33,559 --> 00:16:36,559
includes only users, assets and resources, and we bring it

291
00:16:36,600 --> 00:16:39,159
to the actual granular data level, so that even within

292
00:16:39,200 --> 00:16:42,000
a software process, there is zero trust regarding what data

293
00:16:42,279 --> 00:16:46,559
can be read or read or written by that software process.

294
00:16:47,879 --> 00:16:50,279
And I'll just say there's actually some other practical benefits

295
00:16:50,360 --> 00:16:53,360
of our approach to this too, especially at the convergence

296
00:16:53,519 --> 00:16:58,120
of IT and OT networks. The outer layer provides like

297
00:16:58,159 --> 00:17:01,879
a well defined perimeter in which to hunt for threats,

298
00:17:02,240 --> 00:17:04,480
and so nodes in the in the network outside of

299
00:17:04,519 --> 00:17:08,519
our software defined perimeter, I'll say, could be considered outsider threats,

300
00:17:08,720 --> 00:17:11,160
and we're mostly concerned about preventing sort of like denial

301
00:17:11,200 --> 00:17:13,640
of service attacks there and those types of those types

302
00:17:13,640 --> 00:17:17,559
of threats, and then nodes that inside the perimeter could

303
00:17:17,559 --> 00:17:20,400
be considered insider threats. And then in addition to sort

304
00:17:20,400 --> 00:17:24,279
of denial service attacks, we're concerned about the confidentiality and

305
00:17:24,359 --> 00:17:27,920
integrity of that data that's being passed around. But because

306
00:17:27,960 --> 00:17:30,200
of our security model, it makes a problem of intrusion

307
00:17:30,240 --> 00:17:33,880
detection easier inside are inside our mesh network, and so

308
00:17:34,160 --> 00:17:37,160
and the data centric security part of our system preserves

309
00:17:37,160 --> 00:17:40,119
the integrity of the data even if somehow some sort

310
00:17:40,160 --> 00:17:42,680
of node were to be compromised, and so we have

311
00:17:42,720 --> 00:17:46,279
a pretty our defense in depth architecture provides a lot

312
00:17:46,279 --> 00:17:49,640
of almost have guarantees, but as much to the extent

313
00:17:49,720 --> 00:17:54,160
as possible protecting the actual integrity and of the data

314
00:17:54,200 --> 00:17:55,160
that is being passed around.

315
00:17:57,920 --> 00:18:00,799
Speaker 2: At this point, I think the term zero trust has

316
00:18:00,839 --> 00:18:03,799
been used at least a dozen times in your interview, Andrew,

317
00:18:03,880 --> 00:18:07,079
and it always makes me cringe because of how that

318
00:18:07,160 --> 00:18:10,000
term is thrown around in IT. Are we using the

319
00:18:10,079 --> 00:18:12,359
term zero trust here in the same way that I'm

320
00:18:12,440 --> 00:18:15,799
used to it in IT spaces? Kind of?

321
00:18:15,920 --> 00:18:18,920
Speaker 3: I mean, zero trust has evolved. My original understanding of

322
00:18:19,000 --> 00:18:21,079
zero trust was basically what you do on the Internet.

323
00:18:21,240 --> 00:18:22,599
If you want to log into if you want to

324
00:18:22,599 --> 00:18:26,400
connect to anything sensitive that you know involves money, you

325
00:18:26,440 --> 00:18:28,440
have to give a password, you have to have an

326
00:18:28,519 --> 00:18:32,480
encrypted connection. That was zero trust. You don't give someone

327
00:18:32,519 --> 00:18:34,880
money just because you like their IP address, the way

328
00:18:35,400 --> 00:18:39,400
you might trust someone on an IT network old school.

329
00:18:40,200 --> 00:18:44,599
The modern sort of vision for zero trust has evolved into,

330
00:18:44,799 --> 00:18:49,680
you know, something that's loosely sort of marketing talk for

331
00:18:49,799 --> 00:18:52,480
active directory. If you look at a lot of the

332
00:18:52,839 --> 00:18:55,519
zero trust standards that are coming out of NISS, the

333
00:18:55,640 --> 00:18:58,440
US National Institute of Standards and Technology, they're talking about

334
00:18:59,079 --> 00:19:02,680
you know zero trust as single sign on, where instead

335
00:19:02,680 --> 00:19:07,640
of sending your username and password around to every machine

336
00:19:07,680 --> 00:19:10,599
everything you want to do, you sign on once to

337
00:19:10,680 --> 00:19:13,920
a zero trust broker, which is an active directory server,

338
00:19:13,960 --> 00:19:16,440
and you get back a Kerberos ticket, which is sort

339
00:19:16,440 --> 00:19:20,920
of an encrypted thing that represents you and your credentials.

340
00:19:20,920 --> 00:19:22,799
And now you can go to the print server or

341
00:19:22,839 --> 00:19:26,039
you can go to the SAP server and you know

342
00:19:26,240 --> 00:19:29,799
not have not be challenged for another password. That's sort

343
00:19:29,799 --> 00:19:36,440
of the thing on IT networks. What I heard Daily

344
00:19:36,480 --> 00:19:38,519
and Nick talking about here was sort of zero trust

345
00:19:38,519 --> 00:19:43,519
taken to an extreme, where every message that is exchanged

346
00:19:43,599 --> 00:19:47,079
in the system is authenticated somehow, not just every log in,

347
00:19:47,119 --> 00:19:50,640
every message, not just every connection. There are no connections.

348
00:19:50,759 --> 00:19:53,480
It's all published subscribed, so you can do really fine

349
00:19:53,519 --> 00:19:57,079
grained permissions. You can say, you know, these kinds of

350
00:19:57,160 --> 00:20:02,720
users have permission to subscrib to these topics this data

351
00:20:02,720 --> 00:20:04,640
that I'm putting out, but not that data that I'm

352
00:20:04,640 --> 00:20:08,119
putting out. Every topic can have different permissions, and you know,

353
00:20:08,160 --> 00:20:11,799
every message where you exchange you know, a topic and

354
00:20:11,839 --> 00:20:14,559
a piece of data has to be signed. And so

355
00:20:14,920 --> 00:20:18,440
in a sense, it's the IT style of zero trust,

356
00:20:18,839 --> 00:20:23,319
let's say, taken to an extreme. So thanks for that.

357
00:20:23,400 --> 00:20:26,680
So you know, we've we've talked about mesh. We're talking

358
00:20:26,680 --> 00:20:30,480
about you know, authentication, constant authentication within the mesh. This

359
00:20:30,680 --> 00:20:34,839
is in a sense the nature of zero trust you've

360
00:20:34,960 --> 00:20:38,160
also you know, I know that you guys touch on

361
00:20:38,400 --> 00:20:42,200
formal methods, and this, you know, drew my attention. I mean,

362
00:20:44,160 --> 00:20:46,759
correct me if I'm wrong, you know, can you tell

363
00:20:46,839 --> 00:20:49,000
us what are you doing with formal methods, and you know,

364
00:20:49,279 --> 00:20:52,640
if you might sort of correct my misconception if there

365
00:20:52,680 --> 00:20:56,160
is one. When I hear formal methods, I imagine we're

366
00:20:56,279 --> 00:21:00,680
proving things correct. Now, I know formal methods actually be

367
00:21:01,039 --> 00:21:03,359
a little different from that. You know, can you talk about,

368
00:21:04,079 --> 00:21:06,920
for you what is formal methods and what are you

369
00:21:07,039 --> 00:21:09,240
applying it to, What's what's the goal? What are you

370
00:21:09,319 --> 00:21:11,599
achieving with that? Yeah?

371
00:21:11,640 --> 00:21:15,359
Speaker 4: So in short, you're right. In essence, formal methods is

372
00:21:15,400 --> 00:21:20,400
about proving things correct. So formal methods essentially are rigorous

373
00:21:20,400 --> 00:21:27,240
mathematical techniques to specify, analyze, design, implement, or verify a system.

374
00:21:27,319 --> 00:21:29,400
And I know a lot of people get scared or

375
00:21:29,440 --> 00:21:31,640
maybe bored when the topic of math comes up, so

376
00:21:31,720 --> 00:21:33,880
I'll try to keep it more high level here for

377
00:21:33,920 --> 00:21:38,559
your listeners. So under the umbrella of formal methods is

378
00:21:38,839 --> 00:21:42,119
another concept called formal verification, and that's where you're proving

379
00:21:42,160 --> 00:21:45,440
the correctness of a system with respect to some formal

380
00:21:45,480 --> 00:21:49,279
specification or property of that system. So examples of that

381
00:21:49,319 --> 00:21:54,720
typically are like safety or security properties, and traditionally, outside

382
00:21:54,720 --> 00:21:58,160
of academia anyways, formal methods have been used mainly in

383
00:21:58,200 --> 00:22:02,759
the most safety and security critical systems like avionics. That's

384
00:22:02,799 --> 00:22:05,359
mainly due to the expertise and the specialized tools that

385
00:22:05,400 --> 00:22:08,920
are needed or were needed anyways. But we're starting to

386
00:22:08,920 --> 00:22:12,039
see more traction across industry as awareness grows of these

387
00:22:12,079 --> 00:22:14,559
tools and the tools are actually becoming easier to use

388
00:22:14,559 --> 00:22:18,319
and to apply. So one example of their use in

389
00:22:18,440 --> 00:22:22,519
industry actually comes from our home province of Ontario, where

390
00:22:22,559 --> 00:22:25,839
formal methods were used from the design through the verification

391
00:22:26,039 --> 00:22:29,720
of a software based shutdown system for the Darlington Nuclear

392
00:22:29,759 --> 00:22:33,119
Generating Station. So I think they spent about a decade

393
00:22:33,160 --> 00:22:38,119
working on formal methods again across design through verification to

394
00:22:38,240 --> 00:22:42,400
ensure that the shutdown system was in fact safe. So

395
00:22:42,440 --> 00:22:45,319
there's many different techniques that fall under the umbrella of

396
00:22:45,359 --> 00:22:49,440
formal methods, and today there's lots of tools that actually

397
00:22:49,480 --> 00:22:52,359
help developers automate those techniques. So some of the ones

398
00:22:52,440 --> 00:22:57,480
we're using at Metropolitan include things like static analysis, model checking,

399
00:22:57,640 --> 00:23:00,279
and automated proof tools. And I'll dig in to these

400
00:23:00,279 --> 00:23:02,000
a little bit so your listeners understand a bit what

401
00:23:02,039 --> 00:23:06,519
those are. So static analysis is quite widely known actually

402
00:23:07,000 --> 00:23:10,960
in the software development world, and it essentially consists of

403
00:23:11,039 --> 00:23:15,759
automatically checking certain properties of a computer program at compile time,

404
00:23:15,839 --> 00:23:18,279
so before you're actually running it in a test environment

405
00:23:18,400 --> 00:23:23,480
or running it in a production environment. So examples of

406
00:23:23,519 --> 00:23:25,799
the types of properties that can be checked by static

407
00:23:25,799 --> 00:23:29,200
analysis include things like that the programmer who route the

408
00:23:29,200 --> 00:23:34,759
program isn't using language features that are potentially unsafe because

409
00:23:34,759 --> 00:23:37,279
programming languages in general allow you to do a lot

410
00:23:37,319 --> 00:23:41,359
of things with the underlying hardware, and in safety critical systems,

411
00:23:41,519 --> 00:23:44,119
sometimes you don't want to use that full feature set

412
00:23:44,160 --> 00:23:47,119
because you can introduce errors into the program that can

413
00:23:47,160 --> 00:23:50,440
cause safety or security issues. Some other things you can

414
00:23:50,519 --> 00:23:54,759
check with static analysis are that well known program weaknesses

415
00:23:54,839 --> 00:23:59,680
or vulnerabilities aren't actually in the program. So there's databases

416
00:23:59,720 --> 00:24:04,000
that are available publicly that actually lists the types of

417
00:24:04,039 --> 00:24:06,759
weaknesses and vulnerabilities that are often found in software, and

418
00:24:07,240 --> 00:24:10,400
some of these static analysis tools can actually check those

419
00:24:10,480 --> 00:24:14,039
databases and check it against your source code to make

420
00:24:14,039 --> 00:24:18,599
sure that the programs aren't actually implementing those weaknesses or vulnerabilities,

421
00:24:19,880 --> 00:24:24,160
and then also things like linters, which essentially means analysis

422
00:24:24,200 --> 00:24:26,519
tools where that look at the source code of your

423
00:24:26,519 --> 00:24:30,559
program and make sure that they meet a certain quality specification.

424
00:24:30,640 --> 00:24:32,799
So this is often used to make sure that the

425
00:24:32,839 --> 00:24:36,799
source code can be read, maintained, and updated by somebody

426
00:24:36,799 --> 00:24:39,400
other than the original programmer. And this kind of thing

427
00:24:39,480 --> 00:24:43,200
is really important in software systems that have to live

428
00:24:43,400 --> 00:24:45,920
for quite a long time, so the original developers of

429
00:24:45,960 --> 00:24:49,319
the system might not be around anymore, and you need

430
00:24:49,400 --> 00:24:52,160
programmers to make updates or to make fixes to the software,

431
00:24:52,200 --> 00:24:53,680
so you want to make sure that they can actually

432
00:24:53,759 --> 00:24:56,119
read and maintain that software. So we have tools that

433
00:24:56,200 --> 00:24:58,839
help us ensure the quality even of the source code.

434
00:25:00,000 --> 00:25:03,079
One that I mentioned was model checking, so that refers

435
00:25:03,119 --> 00:25:07,799
to automatically and exhaustively checking that certain logical properties of

436
00:25:07,799 --> 00:25:11,960
a system are true or false for all reachable states

437
00:25:11,960 --> 00:25:15,000
in that system or for some specific state of that system.

438
00:25:15,759 --> 00:25:18,200
And usually we use simplified models of the system, but

439
00:25:18,440 --> 00:25:21,000
we ensure that they include the essential states of that

440
00:25:21,079 --> 00:25:24,319
system and how they might change over time. So in

441
00:25:24,400 --> 00:25:27,200
model checking, one type of property you would want to

442
00:25:27,279 --> 00:25:29,920
prove is called the safety property, and that's something that

443
00:25:30,240 --> 00:25:33,759
the system should not do, should never do. So. Examples

444
00:25:33,759 --> 00:25:36,799
of that might be like, in a financial transaction system,

445
00:25:36,839 --> 00:25:39,920
you want to prevent double spending, so someone can't spend

446
00:25:39,920 --> 00:25:44,920
the same money twice simultaneously on different transactions. In an

447
00:25:44,960 --> 00:25:47,279
electronic medical record system, you want to ensure that you're

448
00:25:47,279 --> 00:25:52,079
not leaking private personal data. Or in an industrial control system,

449
00:25:52,119 --> 00:25:54,039
you want to make sure that you're not issuing your

450
00:25:54,079 --> 00:25:56,480
system's not issuing a command that could cause physical harm

451
00:25:56,599 --> 00:26:01,880
or system damage. And then automated proof tools layer on

452
00:26:01,920 --> 00:26:04,240
top of that, and they can do things like automatically

453
00:26:04,319 --> 00:26:08,279
prove the absence of any runtime errors in your software implementation.

454
00:26:09,119 --> 00:26:11,839
So most people familiar with software development are aware of

455
00:26:11,880 --> 00:26:15,319
software testing, and software developers spend a lot of time

456
00:26:16,160 --> 00:26:19,440
writing tests against their software, and that's great, but software

457
00:26:19,480 --> 00:26:24,160
testing cannot be exhaustive. But we do have proof tools

458
00:26:24,160 --> 00:26:28,359
that actually can prove conclusively and exhaustively that there are

459
00:26:28,440 --> 00:26:31,680
no bugs in your software that will cause runtime errors. So,

460
00:26:31,720 --> 00:26:35,519
and you can prove other things like specified data dependencies

461
00:26:35,519 --> 00:26:37,839
and flows in the program. So you want to ensure

462
00:26:37,880 --> 00:26:41,119
that certain software modules data only flows from one to

463
00:26:41,160 --> 00:26:44,200
the other and doesn't leak back out the other way.

464
00:26:44,359 --> 00:26:47,440
Or you can prove that a software implementation is correct

465
00:26:47,519 --> 00:26:51,400
with respect to like a functional specification. So your customer

466
00:26:51,440 --> 00:26:53,839
has some functional specification of what they want the piece

467
00:26:53,839 --> 00:26:57,119
of software to do. You can write that specification in

468
00:26:57,640 --> 00:27:01,480
a programming language, and that same programming language can actually

469
00:27:01,480 --> 00:27:04,680
be used to prove that your implementation of that is

470
00:27:04,799 --> 00:27:08,000
correct with respect to that specification. So again, typically that's

471
00:27:08,000 --> 00:27:13,400
done with testing and demonstration to your customers, and sometimes

472
00:27:13,400 --> 00:27:18,279
by analysis or inspection of the code itself. So these

473
00:27:18,319 --> 00:27:22,720
proof tools add another level of assurance that because they

474
00:27:22,720 --> 00:27:26,920
can do sound reasoning, you can get assurance that your

475
00:27:26,920 --> 00:27:29,400
software actually does what the specification wants it to do.

476
00:27:30,079 --> 00:27:31,519
So the last thing I want to say about formal

477
00:27:31,519 --> 00:27:34,240
methods is that awareness of formal methods is growing pretty

478
00:27:34,319 --> 00:27:37,559
rapidly in industry. So for instance, last year, the White

479
00:27:37,599 --> 00:27:40,119
House released a report called Back to the Building Blocks,

480
00:27:40,480 --> 00:27:43,519
which is part of the United States National Cybersecurity Strategy,

481
00:27:43,559 --> 00:27:46,240
and it explicitly calls on industry to start adopting formal

482
00:27:46,279 --> 00:27:49,119
methods into their software engineering. And if your listeners do

483
00:27:49,160 --> 00:27:51,720
a quick Google search, they'll be able to find examples

484
00:27:51,720 --> 00:27:53,799
of how formal methods are being adopted by some of

485
00:27:53,839 --> 00:27:57,400
the giants in computing like Amazon, Google and Nvidia, and

486
00:27:57,440 --> 00:27:59,720
of course metropolitan technologies.

487
00:28:00,119 --> 00:28:06,039
Speaker 3: Might dumb it down. In my understanding, it's very difficult

488
00:28:06,079 --> 00:28:10,319
to apply formal methods to very large software artifacts. I mean,

489
00:28:10,359 --> 00:28:12,599
you know, the Windows operating system is said to have

490
00:28:12,720 --> 00:28:14,680
I don't know, something like one hundred million lines of

491
00:28:14,720 --> 00:28:18,759
code in it. You know, a web browser has I

492
00:28:18,759 --> 00:28:20,880
think more than ten million lines of code in it.

493
00:28:21,279 --> 00:28:25,000
The industrial control system products I worked on back twenty

494
00:28:25,039 --> 00:28:27,480
years ago in my youth were you know, two three

495
00:28:27,519 --> 00:28:33,119
million lines of code. It's difficult for me to imagine

496
00:28:33,119 --> 00:28:37,319
applying formal methods to a body of software that large,

497
00:28:37,799 --> 00:28:42,599
and so in my dim understanding, you know, dumbing it down,

498
00:28:42,960 --> 00:28:49,400
we use these techniques on smaller software artifacts, or possibly

499
00:28:49,440 --> 00:28:53,079
even with a larger artifact with a specific goal. So

500
00:28:53,200 --> 00:28:58,319
for example, you know, Waterfall produces a unidirectional gateway. Now

501
00:28:58,559 --> 00:29:01,799
we don't to mind all which I'm not part of

502
00:29:01,799 --> 00:29:04,240
the dev team. To my knowledge, we're not doing formal methods,

503
00:29:04,319 --> 00:29:09,240
but we you know, we have been certified against you know,

504
00:29:09,519 --> 00:29:13,559
common criteria. Common criteria is a kind of certification. The

505
00:29:13,599 --> 00:29:17,359
way it works is the vendor makes a claim we

506
00:29:17,480 --> 00:29:21,440
claim the hardware is truly unidirectional. It does not matter

507
00:29:21,680 --> 00:29:25,119
what you do to the software, it's not physically possible

508
00:29:25,160 --> 00:29:27,319
to send any information back in the other direction. So

509
00:29:27,359 --> 00:29:33,119
you make a very specific claim. The common criteria tests

510
00:29:33,160 --> 00:29:36,599
the system against that claim. In my understanding, it's analogous

511
00:29:37,240 --> 00:29:39,599
you know, correct me if I'm wrong to formal methods

512
00:29:39,599 --> 00:29:42,880
where you say this is what we're going to prove,

513
00:29:42,920 --> 00:29:47,279
and you state that thing, whatever it is, reasonably Simply,

514
00:29:47,359 --> 00:29:49,880
it has to be reasonably simple to have a high

515
00:29:49,880 --> 00:29:52,920
degree of confidence in your proof, and then you set

516
00:29:52,960 --> 00:29:57,759
about using formal methods to establish that property. Can I

517
00:29:57,799 --> 00:30:03,319
ask you, you know, what properties have you focused on

518
00:30:03,640 --> 00:30:07,079
in your use of formal methods. What is it that

519
00:30:07,279 --> 00:30:11,480
you believe that your customers or the marketplace are going

520
00:30:11,559 --> 00:30:14,599
to want, you know, to have a high degree of

521
00:30:14,640 --> 00:30:17,000
assurance for you.

522
00:30:17,279 --> 00:30:21,240
Speaker 1: Make a good point. You know, formally proving properties of

523
00:30:21,279 --> 00:30:24,200
a whole industrial control system or an operating system with

524
00:30:24,400 --> 00:30:27,079
millions and millions of lines of code is an enormous undertaking,

525
00:30:27,960 --> 00:30:31,279
and so we're very aware of that. We started with

526
00:30:31,319 --> 00:30:33,599
proving the absence of rent time errors of what we

527
00:30:33,680 --> 00:30:37,079
identified as critical components of our software. And our long

528
00:30:37,160 --> 00:30:39,519
term view is to prove as much as humanly possible

529
00:30:39,599 --> 00:30:43,039
that our code has no vulnerabilities, as that means like

530
00:30:43,480 --> 00:30:46,799
making a foundation, building a foundation, a software foundation in

531
00:30:46,880 --> 00:30:49,759
libraries and small building blocks that we've formally proven that

532
00:30:49,759 --> 00:30:53,160
we could build on top of. And so we believe

533
00:30:53,160 --> 00:30:55,000
that proving at least part of your code is a

534
00:30:55,000 --> 00:30:57,519
step in the right direction for security. Is this one

535
00:30:57,519 --> 00:30:59,680
of the best techniques available to us for us to

536
00:30:59,680 --> 00:31:03,480
reason about software? And so I'll let NIC colaborate adate

537
00:31:03,519 --> 00:31:05,680
on the couple of focus areas that we're working on

538
00:31:05,920 --> 00:31:07,720
to prove and where we think that's valuable.

539
00:31:09,000 --> 00:31:11,160
Speaker 4: Yeah, to get a little bit more specific, So, yeah,

540
00:31:11,160 --> 00:31:15,599
we're focused right now essentially in two areas. First at

541
00:31:15,599 --> 00:31:18,440
the points where our software consumes or ingests data from

542
00:31:18,480 --> 00:31:21,400
other systems, and where our software produces and publishes data

543
00:31:21,400 --> 00:31:25,000
to other systems. So, because interaction between software components is

544
00:31:25,119 --> 00:31:29,400
generally governed by protocol and format specification, they can either

545
00:31:29,440 --> 00:31:34,640
be standardized or sometimes they're proprietary. But most software developers

546
00:31:34,680 --> 00:31:38,160
will know that poor input validation, whether that inputs from

547
00:31:38,200 --> 00:31:41,599
a human in a guy or from another piece of software,

548
00:31:42,319 --> 00:31:44,440
is the source of many vulnerabilities and it's a common

549
00:31:44,480 --> 00:31:48,240
attack vector. So a core part of our platform's value

550
00:31:48,480 --> 00:31:52,400
is in connecting and translating between many different communication protocols

551
00:31:52,440 --> 00:31:57,279
and formats. So we're using specification and cogeneration tools that

552
00:31:57,359 --> 00:32:00,359
cannot prove that our data input and output more models

553
00:32:00,440 --> 00:32:03,720
will only accept and create valid data, and that those

554
00:32:03,759 --> 00:32:07,960
modules themselves are free of runtime error. So for instance,

555
00:32:08,039 --> 00:32:12,519
you can't bad input data won't cause a buffer overrun

556
00:32:12,559 --> 00:32:16,480
in the software and cause the software to crash. The

557
00:32:16,599 --> 00:32:20,200
second area we're focused on really is our overall software

558
00:32:20,200 --> 00:32:24,519
engineering tooling and practice. So for example, all of our

559
00:32:24,559 --> 00:32:29,079
own software is written using the Spark programming language, And

560
00:32:29,720 --> 00:32:32,240
just to not confuse your listeners, it's not the Apache

561
00:32:32,240 --> 00:32:35,400
Spark tool, but it's it's a programming language that's been

562
00:32:35,440 --> 00:32:39,880
around for quite a while. It's part of a subset

563
00:32:39,920 --> 00:32:41,880
of what's known as the Ada programming language, which was

564
00:32:41,920 --> 00:32:46,079
originally designed for the United States Department of Defense, and

565
00:32:46,119 --> 00:32:49,720
it's a mature but modern language designed for the most

566
00:32:49,759 --> 00:32:52,640
safety and security critical system So using Spark as a

567
00:32:52,640 --> 00:32:55,559
programming language gives us a high level of software assurance

568
00:32:55,880 --> 00:32:59,119
as a baseline, because the language itself was designed for

569
00:32:59,440 --> 00:33:01,839
critical systems, and it includes a bunch of features that

570
00:33:02,160 --> 00:33:05,799
help programmers write error free programs. But on top of that,

571
00:33:05,839 --> 00:33:09,640
it also allows you to progressively apply additional methods to

572
00:33:09,680 --> 00:33:14,240
prove critical data flows, program integrity, and functional correctness, things

573
00:33:14,240 --> 00:33:18,200
I was talking about earlier. And so the ability to

574
00:33:18,240 --> 00:33:21,720
progressively apply these methods means that you don't have to

575
00:33:22,000 --> 00:33:24,839
fully prove a program or an entire system from the

576
00:33:24,880 --> 00:33:28,440
get go. You can focus on your critical components first.

577
00:33:28,440 --> 00:33:32,400
So again in our case, we're mainly focused on where

578
00:33:32,480 --> 00:33:34,720
data comes in and how data goes out because those

579
00:33:34,759 --> 00:33:37,480
are aspects of the system that we have less control over,

580
00:33:38,839 --> 00:33:41,680
and we're using the higher assurance proof tools on those

581
00:33:41,720 --> 00:33:44,759
components first. But we're building all of our software using

582
00:33:44,799 --> 00:33:47,599
this language. That's going to allow us to progressively increase

583
00:33:47,640 --> 00:33:50,680
the assurance in areas that we deem to be of

584
00:33:50,880 --> 00:33:51,799
higher criticality.

585
00:33:52,880 --> 00:33:56,200
Speaker 3: Let me ask you, though a hard question. I remember

586
00:33:56,279 --> 00:34:02,240
this was maybe close to a decade ago, the SSH protocol.

587
00:34:02,400 --> 00:34:06,240
A bunch of mathematicians proved the protocol correct. What does

588
00:34:06,279 --> 00:34:13,199
that mean? They proved that if an implementation complies with

589
00:34:13,239 --> 00:34:17,039
the protocol, if there's no defects in the implementation, then

590
00:34:17,199 --> 00:34:22,559
the protocol could not leak key information into the Internet

591
00:34:22,639 --> 00:34:25,519
into anybody, so that you know, the keys for the

592
00:34:25,719 --> 00:34:29,119
communication will always be secure. A year later, they broke

593
00:34:29,159 --> 00:34:34,840
the protocol. Not an implementation, they broke the protocol. They

594
00:34:34,960 --> 00:34:41,599
demonstrated how every compliant implementation of the SSH protocol could

595
00:34:41,679 --> 00:34:45,079
be manipulated into leaking the first fourteen bits of the

596
00:34:45,159 --> 00:34:49,519
key information. How did they do that? It turned out that,

597
00:34:49,599 --> 00:34:55,199
you know, the mathematical proof proved an assertion. You know,

598
00:34:55,280 --> 00:34:58,519
no key information leaked proved the assertion at a certain

599
00:34:58,639 --> 00:35:03,440
level of abstraction. What they did was they said, well,

600
00:35:03,480 --> 00:35:07,840
you know, we're using the Internet, we're using TCP. And

601
00:35:07,880 --> 00:35:12,039
they modeled TCP mathematically as sort of a tube where

602
00:35:12,039 --> 00:35:14,559
you stick characters in one end and they come out

603
00:35:14,559 --> 00:35:18,400
the other end, either in the same order the same characters,

604
00:35:18,559 --> 00:35:21,440
or the connection is torn down. That's sort of the

605
00:35:23,039 --> 00:35:26,559
assumption the mathematical model they had of the TCP protocol.

606
00:35:26,840 --> 00:35:30,599
And of course everyone knows TCP's messages, and you can

607
00:35:30,639 --> 00:35:34,760
fit multiple characters into a single message. It's not one

608
00:35:34,920 --> 00:35:37,280
character at a time, it's sort of messages at a time.

609
00:35:37,679 --> 00:35:41,440
And they used a timing attack to prove that every

610
00:35:41,719 --> 00:35:47,920
compliant SSH implementation could leak the first fourteen character fourteen

611
00:35:48,280 --> 00:35:55,599
bits by taking advantage of information about you know, messages

612
00:35:55,639 --> 00:35:58,039
that are sent back and forth and the time stamps

613
00:35:58,199 --> 00:36:03,119
in those messages, and so really, you know, they attack

614
00:36:03,199 --> 00:36:06,840
the protocol below the level of the proof, below that

615
00:36:06,920 --> 00:36:11,599
level of abstraction. Can you talk about, you know, can

616
00:36:11,639 --> 00:36:17,000
you talk about sort of applying this principle to your system?

617
00:36:17,039 --> 00:36:20,599
What is you know, at what level of abstraction are

618
00:36:20,639 --> 00:36:28,280
your proofs? You know what? Bluntly you know, should we

619
00:36:28,320 --> 00:36:29,360
believe these proofs?

620
00:36:30,039 --> 00:36:33,639
Speaker 1: Yeah, so you make some good points. Formal methods can

621
00:36:33,679 --> 00:36:36,920
be applied at multiple levels. So, like you mentioned, at

622
00:36:36,920 --> 00:36:40,760
the specification of the protocol in this case SSH, you

623
00:36:40,760 --> 00:36:43,119
can apply them at the systems level, for example, proving

624
00:36:43,119 --> 00:36:46,559
a distributed system has various properties, and you can apply

625
00:36:46,559 --> 00:36:48,480
them at the implementation level, and this is where we

626
00:36:48,559 --> 00:36:52,000
are concentrating. But also, like you mentioned, they're only as

627
00:36:52,000 --> 00:36:54,480
good as a specification in which they're proving, so it's

628
00:36:54,480 --> 00:36:57,840
not a panacea. One of our main assumptions, though, is

629
00:36:57,880 --> 00:37:01,119
the cost of integrating formal methods into our engineering processes

630
00:37:01,519 --> 00:37:03,960
are coming down to the point where the benefits outweigh

631
00:37:04,000 --> 00:37:07,000
the costs. Even for a startup. So even though you

632
00:37:07,079 --> 00:37:10,440
might it's true that if there's a flawed assumption the specification,

633
00:37:11,119 --> 00:37:15,519
then even the implementation improving the proof and improving implementation

634
00:37:15,559 --> 00:37:21,159
itself against that specification could also have flaws. We are human,

635
00:37:21,199 --> 00:37:25,000
after all, writing these specifications. It does, though, give us

636
00:37:25,000 --> 00:37:29,760
the best defense to the extent possible that reguarding against

637
00:37:29,760 --> 00:37:35,360
certain security and safety vulnerabilities, And the tooling is getting

638
00:37:35,400 --> 00:37:37,039
better to allow us to identify some of these, and

639
00:37:37,079 --> 00:37:38,559
maybe Nick, you can talk a bit about that.

640
00:37:39,920 --> 00:37:41,920
Speaker 4: Yeah, So, I mean the tooling has improved to the

641
00:37:41,960 --> 00:37:44,880
point where you can progressively adopt that the techniques of

642
00:37:45,239 --> 00:37:47,599
formal methods. But and it is best to start as

643
00:37:47,639 --> 00:37:51,039
early as possible. So at Metropolitan we started right from

644
00:37:51,079 --> 00:37:54,519
the beginning, from day zero, and our platform is not

645
00:37:54,760 --> 00:37:57,199
fully proven yet, as we mentioned before. But I mean,

646
00:37:57,239 --> 00:37:59,639
think about it. Would you rather use a tool that

647
00:37:59,719 --> 00:38:02,920
has proven to be correct with respect to some set

648
00:38:02,960 --> 00:38:06,559
of assumptions, and where the developers are working on proving

649
00:38:06,559 --> 00:38:09,320
more and more of it correct with respect to even

650
00:38:09,320 --> 00:38:11,679
more conservative assumptions, Or would you rather use something that

651
00:38:11,880 --> 00:38:14,119
is just as secure as the human developers can think

652
00:38:14,119 --> 00:38:16,599
to make it before they move on to their next task.

653
00:38:16,679 --> 00:38:19,880
So we don't use well, sorry, where we don't use

654
00:38:19,880 --> 00:38:23,519
formal verification, yet we cover everything else with automated testing

655
00:38:23,599 --> 00:38:26,760
to help ensure the reliability of our platform. And we

656
00:38:26,800 --> 00:38:30,400
think this hybrid approach of mixing formal methods on the

657
00:38:30,400 --> 00:38:34,239
most critical components first and filling in gaps with automated

658
00:38:34,280 --> 00:38:37,079
testing is the most practical approach for us right now,

659
00:38:38,039 --> 00:38:40,880
and it's acceptable for the highest level of certification for

660
00:38:40,920 --> 00:38:44,880
functional safety, for example in avionics. So we're not the

661
00:38:44,880 --> 00:38:47,400
only ones who believe in this approach. So I think

662
00:38:47,440 --> 00:38:49,599
maybe to get back to the example you give and

663
00:38:49,679 --> 00:38:51,639
just to bring this back up to a high level.

664
00:38:51,960 --> 00:38:54,280
One thing I think is important to bear in mind

665
00:38:54,440 --> 00:38:57,920
is that I think adopting formal methods into your engineering

666
00:38:57,920 --> 00:39:03,920
process forces you to do a bit of thinking in advance. So,

667
00:39:04,079 --> 00:39:07,480
for instance, in the cybersecurity space, you know your your

668
00:39:07,519 --> 00:39:09,440
formal proofs are only going to be as good as

669
00:39:09,480 --> 00:39:13,440
the models you've developed to eventually develop your software and

670
00:39:13,559 --> 00:39:17,199
prove that software correct. But when you're developing your model,

671
00:39:17,199 --> 00:39:19,159
you need to make sure that you're accounting for things

672
00:39:19,199 --> 00:39:22,559
like your threat model. So there are things there are

673
00:39:22,639 --> 00:39:25,320
unknown unknowns in the world, you know, and we have

674
00:39:25,360 --> 00:39:28,159
to do some deep thinking at the start of our

675
00:39:28,159 --> 00:39:30,760
design to try to capture you know, the full threat

676
00:39:30,840 --> 00:39:33,800
landscape as best as we can. And you know, these

677
00:39:33,840 --> 00:39:36,800
tools will help you prove that your software implementation is

678
00:39:36,920 --> 00:39:39,800
robust against those threats. But again, like Daily said, it's

679
00:39:39,840 --> 00:39:43,599
not a panacea. There again are unknown unknowns and sometimes

680
00:39:43,599 --> 00:39:46,639
your models don't account for certain threats that you could

681
00:39:46,639 --> 00:39:47,440
not have predicted.

682
00:39:50,400 --> 00:39:52,599
Speaker 3: So there's been some long answers here, Nate. You know,

683
00:39:53,400 --> 00:39:57,039
I asked a complicated question. I got a bit of

684
00:39:57,039 --> 00:40:00,559
a complicated answer that was very carefully couch saying, well,

685
00:40:00,599 --> 00:40:02,960
you know, nothing is ever perfect. We're not guaranteeing that

686
00:40:03,039 --> 00:40:07,519
our stuff is perfect. You know. They had sort of

687
00:40:07,519 --> 00:40:09,559
the bottom line buried in a paragraph I wanted to

688
00:40:09,559 --> 00:40:14,559
emphasize in my mind. The bottom line is this, when

689
00:40:14,599 --> 00:40:19,360
you are looking for a software platform, a technology platform

690
00:40:20,159 --> 00:40:23,679
to build an important function on a safety critical function,

691
00:40:24,039 --> 00:40:27,039
a function that's you know, essential to critical infrastructure. When

692
00:40:27,039 --> 00:40:30,039
you've got something important to do, you have two choices.

693
00:40:30,400 --> 00:40:33,719
You can either use a bunch of software as your

694
00:40:33,760 --> 00:40:37,480
foundation that a bunch of developers have worked on and

695
00:40:37,519 --> 00:40:39,599
then moved away, you know, did what they could and

696
00:40:39,679 --> 00:40:43,400
moved on. Or you could use a bunch of software

697
00:40:43,559 --> 00:40:46,719
that has been proven correct under a bunch of assumptions

698
00:40:46,840 --> 00:40:49,400
against a bunch of threats in light of, you know,

699
00:40:49,440 --> 00:40:54,239
a bunch of contingencies, and the development team continues to

700
00:40:54,519 --> 00:40:57,400
prove the thing correct and evolve it to become more

701
00:40:57,400 --> 00:41:01,360
correct against more threats and more condition Which would you

702
00:41:01,480 --> 00:41:03,320
rather the one that people kind of do what they

703
00:41:03,360 --> 00:41:05,800
do and move on or the one where you know

704
00:41:05,880 --> 00:41:12,079
you're determinedly proving it against a bigger and bigger body

705
00:41:11,840 --> 00:41:16,480
of potential gotchas, I'd rather use the platform that's been

706
00:41:16,519 --> 00:41:19,920
proven correct. No, it's not perfect, but it sures a

707
00:41:19,920 --> 00:41:21,760
big step in the right direction, is what it sounds

708
00:41:21,800 --> 00:41:26,960
like to me. What you're building is in a sense

709
00:41:27,000 --> 00:41:31,920
of platform, It is software that other developers can use

710
00:41:32,400 --> 00:41:35,840
to develop industrial control systems. And when you have sort

711
00:41:35,880 --> 00:41:39,559
of infrastructure like that. In my experience of the marketplace

712
00:41:39,760 --> 00:41:44,519
in you know what vendors I've worked for, you tend

713
00:41:44,559 --> 00:41:51,400
to see programming platforms adopted by vendors who are building

714
00:41:51,440 --> 00:41:56,400
industrial control systems when there's sort of a compelling need.

715
00:41:56,599 --> 00:42:00,239
The compelling need might be the threat environment changes. Don't

716
00:42:00,239 --> 00:42:04,239
know you know, a gazillion stucksns hit everybody next year.

717
00:42:04,920 --> 00:42:08,320
Or it might be that, you know, there is a

718
00:42:08,360 --> 00:42:11,159
new kind of application I don't know, you know, smart

719
00:42:11,239 --> 00:42:14,639
car chargers or something that demand a new way of

720
00:42:15,159 --> 00:42:19,079
doing things, or you know it. It might be that

721
00:42:19,159 --> 00:42:21,920
it solves a long standing industry problem and the whole

722
00:42:21,960 --> 00:42:24,000
industry looks at it and says that's the right way

723
00:42:24,039 --> 00:42:25,840
to solve this problem, and all of their new development

724
00:42:25,880 --> 00:42:29,239
switches to the new platform. You know, Java was a

725
00:42:29,320 --> 00:42:33,639
little bit like that. Can I ask you, you know,

726
00:42:34,360 --> 00:42:37,480
how's it going in terms of adoption? Do you see

727
00:42:37,800 --> 00:42:40,880
a triggering event? Do you see a new industry? Do

728
00:42:40,960 --> 00:42:45,039
you see a killer app for this platform that you're producing.

729
00:42:45,760 --> 00:42:50,760
Speaker 1: I'll say that, you know, the digital transformation of industry

730
00:42:50,960 --> 00:42:53,840
is happening, and so you know, historically a lot of

731
00:42:53,840 --> 00:42:57,400
these OT networks, industrial control systems, et cetera, have been

732
00:42:57,440 --> 00:42:59,599
isolated and they've been off the Internet, and for valid

733
00:42:59,599 --> 00:43:04,039
reasons for cybersecurity and other reasons as well. But there's

734
00:43:04,079 --> 00:43:07,360
there's new requirements coming out and I think it's you

735
00:43:07,400 --> 00:43:10,920
can't ignore the fact that increasingly OT networks are becoming

736
00:43:10,920 --> 00:43:13,320
connected to the Internet, and there's reasons people want to

737
00:43:13,320 --> 00:43:19,119
do this, you know, compliance with new cybersecurity requirements asset management,

738
00:43:19,199 --> 00:43:22,119
so remote monitoring and management of all the assets in

739
00:43:22,159 --> 00:43:27,920
the network, applications like predictive maintenance become possible. And so

740
00:43:28,280 --> 00:43:30,880
with this digital transformation, though, there's a lot of new threats,

741
00:43:31,079 --> 00:43:35,960
cyber threats possible to the existing infrastructure and architectures of

742
00:43:36,559 --> 00:43:39,920
these oteen networks, and so say in addition to that,

743
00:43:40,039 --> 00:43:43,239
there's incoming macro triggers, and one, for example, could be

744
00:43:43,400 --> 00:43:47,360
quantum computers and the threat of quantum computers against traditional cryptography.

745
00:43:48,159 --> 00:43:50,599
And so having a platform that can address some of

746
00:43:50,639 --> 00:43:55,000
these emerging requirements of connected oteen networks and some of

747
00:43:55,039 --> 00:43:59,000
the existing vulnerabilities of the of the solutions that exist today,

748
00:43:59,840 --> 00:44:02,960
I think is valuable. And so we're trying to address that.

749
00:44:03,400 --> 00:44:06,519
And at the same time, we're also cognizant and sensitive

750
00:44:06,639 --> 00:44:10,079
to to being as non disruptive as possible to the

751
00:44:10,199 --> 00:44:14,239
existing networks, because we know people organizations buy these and

752
00:44:14,239 --> 00:44:17,159
they expect to operate their their networks, their ot devices

753
00:44:17,199 --> 00:44:21,239
for decades, and so the sales cycle and and and

754
00:44:21,239 --> 00:44:24,400
and the lifetime of these of these devices and systems

755
00:44:24,480 --> 00:44:27,800
is very long, and so we have a platform, but

756
00:44:27,840 --> 00:44:31,639
we also have a means of less disruptive integration of

757
00:44:31,639 --> 00:44:34,880
our technologies and we've kind of alluded it to it earlier,

758
00:44:34,920 --> 00:44:36,199
and we'll talk a bit a bit more about this

759
00:44:36,239 --> 00:44:39,440
in a bit about having it pre integrated on an

760
00:44:39,519 --> 00:44:40,960
edge appliance where you can just sit in front of

761
00:44:40,960 --> 00:44:43,079
an OT network to get a lot of the benefits

762
00:44:43,079 --> 00:44:47,559
that we've talked about without without having the fully without

763
00:44:47,559 --> 00:44:51,039
having to fully disrupt the current operations of the OT environment.

764
00:44:52,239 --> 00:44:54,599
And so to that point, Yeah, I think there's triggers coming,

765
00:44:54,639 --> 00:44:57,159
and I think there's there's value in our platform moving forward,

766
00:44:57,239 --> 00:44:59,599
and there's ways of getting the benefits of it without

767
00:44:59,599 --> 00:45:03,039
being very disruptive to the existing networks and systems.

768
00:45:03,800 --> 00:45:07,000
Speaker 3: You folks are a startup. You've got a bunch of

769
00:45:07,000 --> 00:45:09,199
stuff that you're done. You've got a bunch of stuff

770
00:45:09,199 --> 00:45:13,480
that you're doing. How's it coming? You know? Have you

771
00:45:14,039 --> 00:45:17,159
is there? Is there? Adoption? Is there technology? You know?

772
00:45:17,519 --> 00:45:18,280
How are things going?

773
00:45:20,000 --> 00:45:22,400
Speaker 1: Yeah? So you know, as a startup founder, it's a

774
00:45:22,480 --> 00:45:25,639
roller coaster, but you know it's rewarding that you're building

775
00:45:25,679 --> 00:45:27,760
a product that you think will make a difference, especially

776
00:45:27,760 --> 00:45:30,000
in an industry that has such an impact on people's

777
00:45:30,039 --> 00:45:32,440
day to day lives, and so in terms of where

778
00:45:32,440 --> 00:45:35,519
we're at, we're doing ongoing customer discoveries. So we're talking

779
00:45:35,519 --> 00:45:39,880
to industrial control system vendors, we're talking to operational technology operators.

780
00:45:40,679 --> 00:45:43,000
We're making sure we provide a solution that's desirable and

781
00:45:43,039 --> 00:45:46,159
feasible and trying to best position ourselves in the market.

782
00:45:46,639 --> 00:45:50,280
We're also building partnerships with industries, so these include multinational

783
00:45:50,280 --> 00:45:55,119
system and integrators, security companies, and other technology partnerships to

784
00:45:55,159 --> 00:45:58,119
go to market with. And Nick, you want to talk

785
00:45:58,159 --> 00:45:59,559
a bit about R and D stuff we're doing in

786
00:45:59,599 --> 00:46:00,000
the pilotday.

787
00:46:00,920 --> 00:46:03,000
Speaker 4: Yeah, so we're still in the research and development and

788
00:46:03,039 --> 00:46:04,159
piloting phase of our product.

789
00:46:04,239 --> 00:46:04,639
Speaker 1: Right now.

790
00:46:05,280 --> 00:46:07,039
Speaker 4: We have a beta release that's actually out in the

791
00:46:07,039 --> 00:46:10,519
wild in a controlled test environment, and that allows us

792
00:46:10,599 --> 00:46:14,480
to rapidly iterate and test our platform. We're working towards

793
00:46:14,639 --> 00:46:17,480
what you'd call maybe a version one release later this year,

794
00:46:17,519 --> 00:46:20,199
probably in the fourth quarter. We're also working on a

795
00:46:20,280 --> 00:46:23,119
pre integrated edge appliance that can sit in your OT

796
00:46:23,280 --> 00:46:26,159
network just in front of a device, like a bump

797
00:46:26,159 --> 00:46:29,480
in the wire, to provide as non disruptive as possible.

798
00:46:29,559 --> 00:46:32,880
Integration of our edge technology, and we feel like this

799
00:46:32,920 --> 00:46:35,559
is the path of least resistance to getting our technology

800
00:46:35,599 --> 00:46:38,679
deployed in the most critical of infrastructures where people tend

801
00:46:38,719 --> 00:46:40,159
to be a lot more risk averse.

802
00:46:41,159 --> 00:46:44,800
Speaker 3: This is, in a sense, so different from what I

803
00:46:44,880 --> 00:46:46,960
do every day. I'm not even sure I've asked you

804
00:46:47,239 --> 00:46:50,239
the right questions. So let me ask you an open question.

805
00:46:50,360 --> 00:46:52,079
You know, what else do you want to talk about?

806
00:46:52,119 --> 00:46:53,840
What have I missed? What didn't I ask you that

807
00:46:53,880 --> 00:46:54,360
I should have?

808
00:46:55,039 --> 00:46:57,480
Speaker 1: Yeah, actually that's a good question. And there's a really

809
00:46:57,480 --> 00:47:00,559
cool pilot project that we're working on. So we're working

810
00:47:00,599 --> 00:47:03,000
on a quantum state version of our platform specifically for

811
00:47:03,079 --> 00:47:07,039
industrial control systems, and we're using the DNP three ecosystem,

812
00:47:07,039 --> 00:47:10,199
which is a pretty standard protocol used in utilities, as

813
00:47:10,239 --> 00:47:12,679
the first use case for this new configuration of our platform,

814
00:47:13,159 --> 00:47:15,599
and we're ensuring the protocol is secure against existing and

815
00:47:15,639 --> 00:47:20,000
emerging threats such as quantum computers. It's a very exciting project,

816
00:47:20,039 --> 00:47:22,960
and we're working with really bleeding edge security technologies and

817
00:47:22,960 --> 00:47:26,519
we're integrating a brand new state of cryptography which has

818
00:47:26,559 --> 00:47:30,440
been independently proven to have information theoretical security, and so

819
00:47:30,480 --> 00:47:33,519
what that means is as a system that secure against

820
00:47:33,599 --> 00:47:37,199
adversaries with unlimited computing resources and time, such as a

821
00:47:37,280 --> 00:47:40,400
quantum computer. And I just want to clarify this is

822
00:47:40,440 --> 00:47:43,960
not the same thing as post quantum cryptography, which has

823
00:47:44,079 --> 00:47:46,000
been quite a bit in the news lately and which

824
00:47:46,079 --> 00:47:50,000
NIST has recently standardized and also which OT operators will

825
00:47:50,039 --> 00:47:52,760
be expected to adopt in the future, and which we

826
00:47:52,800 --> 00:47:56,119
also actually also support. But it's actually using a different

827
00:47:56,119 --> 00:48:00,159
type of key distribution technology altogether. And so we're of

828
00:48:00,159 --> 00:48:02,239
a consortium of a bunch of world class companies and

829
00:48:02,320 --> 00:48:06,079
universities delivering this capability. And I'm just going to shout

830
00:48:06,079 --> 00:48:10,119
out our partners, and so it's TALIS Digital, Identify, Talis

831
00:48:10,159 --> 00:48:14,760
Digital and Identify Identity Services, which is a group of

832
00:48:14,800 --> 00:48:18,159
from the Talis multinational French company, Quantum Bridge, which is

833
00:48:18,199 --> 00:48:23,239
a Canadian startup and university at Toronto, and funding has

834
00:48:23,239 --> 00:48:26,239
been contributed by one of Canada's most prestigious funds as well.

835
00:48:26,599 --> 00:48:28,599
And there's actually gonna be a public announcement in the

836
00:48:28,639 --> 00:48:29,920
next few weeks about the project.

837
00:48:30,400 --> 00:48:33,159
Speaker 3: Well, Nick Daily, this has been educational. I love I

838
00:48:33,159 --> 00:48:36,039
love episodes where I learned something you know before we

839
00:48:36,119 --> 00:48:37,840
let you go. Can can I ask you, can you

840
00:48:37,880 --> 00:48:40,320
sum up for us what you know, what what should

841
00:48:40,320 --> 00:48:43,320
we be be, you know, thinking about learning about in

842
00:48:43,360 --> 00:48:43,880
this space.

843
00:48:45,360 --> 00:48:47,039
Speaker 4: Yeah, thanks a lot for having us, Andrew. This has

844
00:48:47,039 --> 00:48:50,079
been a great experience. So I guess what I'll end

845
00:48:50,119 --> 00:48:52,920
off saying, though I might be preaching to the converted,

846
00:48:53,760 --> 00:48:57,719
is that cybersecurity shouldn't be an afterthought, especially in critical

847
00:48:57,719 --> 00:49:01,280
infrastructure systems. These systems are essential to our day to

848
00:49:01,320 --> 00:49:03,400
day life, and I think that we as in the

849
00:49:03,400 --> 00:49:08,079
general public, often take their reliability for granted. It should

850
00:49:08,159 --> 00:49:12,360
be table stakes that cybersecurity is intrinsic in the development

851
00:49:12,480 --> 00:49:16,400
of any operational technology, and we take that very seriously

852
00:49:16,519 --> 00:49:19,639
when we say that we are secure by design and default.

853
00:49:20,280 --> 00:49:22,039
I don't know daily if you want to wrap it.

854
00:49:22,039 --> 00:49:25,039
Speaker 1: Up, Yeah, so I'll just say, you know, the vision

855
00:49:25,079 --> 00:49:27,239
of our company is to be the digital backbone of

856
00:49:27,280 --> 00:49:30,559
the world's critical infrastructure, and we don't consider ourselves like

857
00:49:30,599 --> 00:49:34,239
a traditional cybersecurity company. We're a connectivity company to take

858
00:49:34,280 --> 00:49:37,440
cybersecurity seriously, and we aim to market a product that's

859
00:49:37,480 --> 00:49:39,320
easy to integrate and to secure from the ground up,

860
00:49:39,519 --> 00:49:43,000
allowing organizations to reap the full benefits of their digital transformation.

861
00:49:43,880 --> 00:49:46,639
And at the same time increase the resilience of their infrastructure.

862
00:49:47,400 --> 00:49:49,559
And so I'll just send by inviting all the listeners

863
00:49:49,559 --> 00:49:51,840
to connect with us on LinkedIn or send us an

864
00:49:51,840 --> 00:49:53,679
email to schedule a demo or just chat some more

865
00:49:53,719 --> 00:49:57,079
about the technology we're building. And we're always looking to collaborate,

866
00:49:57,400 --> 00:50:01,440
partner or proather technologies with other organization. So we hope

867
00:50:01,440 --> 00:50:03,679
that what we've discussed resonates with some of the listeners

868
00:50:03,719 --> 00:50:06,400
out there and we can continue this conversation. And so

869
00:50:06,440 --> 00:50:08,440
thanks again for having us, Andrew, and we'd love to

870
00:50:08,519 --> 00:50:10,480
come back on the podcast in the future to catch up.

871
00:50:13,800 --> 00:50:17,719
Speaker 2: Andrew. That just about concludes your interview with Daily Brown

872
00:50:18,000 --> 00:50:22,320
and Nick Fubert from Metropolitan Technologies. Do you want to

873
00:50:22,360 --> 00:50:25,840
take us out now with a final word for our listeners?

874
00:50:26,840 --> 00:50:30,800
Speaker 3: Sure? You know, I I love episodes like this where

875
00:50:30,800 --> 00:50:34,719
I learned stuff and I've you know, heard of formal

876
00:50:34,760 --> 00:50:37,679
methods for a long time and you know, they slowly

877
00:50:37,760 --> 00:50:41,000
are making our making inroads in different industries. So it's

878
00:50:41,079 --> 00:50:43,840
you know, I was keenly interested to see how how

879
00:50:43,880 --> 00:50:46,440
these folks were using it in the industrial control system space,

880
00:50:47,800 --> 00:50:51,079
you know, to me the challenge and you know, in

881
00:50:51,400 --> 00:50:53,119
the in the interview here, it's clear that that Nick

882
00:50:53,159 --> 00:50:56,079
and Daily understand the challenge. The challenge business wise with

883
00:50:56,119 --> 00:50:59,559
this kind of endeavor is that you're not selling the

884
00:50:59,599 --> 00:51:03,760
platform form to end users, Okay, to power companies. Power

885
00:51:03,760 --> 00:51:06,920
companies don't buy this kind of platform because as much

886
00:51:06,920 --> 00:51:11,679
as possible, power companies really try hard to avoid writing code.

887
00:51:11,840 --> 00:51:15,239
They want to buy stuff, not write stuff themselves. You've

888
00:51:15,280 --> 00:51:18,760
got to sell this stuff to people who write a

889
00:51:18,800 --> 00:51:22,039
lot of code. So you know who in the industrial

890
00:51:22,119 --> 00:51:24,360
space is writing a lot of code right now? Well,

891
00:51:25,079 --> 00:51:30,920
to me, the huge opportunity is renewables. You know, it's

892
00:51:31,000 --> 00:51:34,079
taking what you know, the oil and gas sector that

893
00:51:34,159 --> 00:51:38,159
is being transformed, taking the electric sector that's being transformed.

894
00:51:38,840 --> 00:51:41,440
There's a lot of new code being written, not just

895
00:51:41,639 --> 00:51:44,199
you know, existing control systems that have a new feature

896
00:51:44,199 --> 00:51:48,199
of six. We're talking brand new stuff for electric vehicle,

897
00:51:48,480 --> 00:51:52,559
high speed chargers and you know, load balancers within the

898
00:51:52,599 --> 00:51:55,639
grid for the high speed chargers. A whole bunch of

899
00:51:55,719 --> 00:51:59,079
new code being written. And you know, to me, that's

900
00:51:59,119 --> 00:52:03,199
that's an opportunity is these developers, these businesses who write

901
00:52:03,199 --> 00:52:06,800
in that code are looking around for the platforms they're

902
00:52:06,800 --> 00:52:08,840
going to use. Is it the same old or is

903
00:52:08,880 --> 00:52:11,920
there something new and better? Because you know, when you

904
00:52:12,000 --> 00:52:15,920
start the process, that's the huge opportunity for embedding a

905
00:52:15,960 --> 00:52:18,119
new platform in a new way of thinking about it.

906
00:52:18,159 --> 00:52:22,079
So you know, that sector strikes me as ripe for

907
00:52:22,719 --> 00:52:25,599
innovation like this and it's you know, lovely to see

908
00:52:25,599 --> 00:52:28,199
that there's options like this in the marketplace. Well, we'll

909
00:52:28,199 --> 00:52:29,719
have to see how they shake out over time.

910
00:52:30,559 --> 00:52:34,639
Speaker 2: Well, thanks to Daily and Nick for elucidating all that. Andrew,

911
00:52:34,719 --> 00:52:35,920
thank you for speaking with me.

912
00:52:36,519 --> 00:52:37,840
Speaker 3: It's always a pleasure. Thank you, Nate.

913
00:52:38,320 --> 00:52:42,400
Speaker 2: This has been the Industrial Security Podcast from Waterfall. Thanks

914
00:52:42,400 --> 00:52:44,480
to everyone out there listening.