Speaker 1: The mission of our company is to be the digital
backbone of the world's critical infrastructure.
Speaker 2: Welcome listeners to the Industrial Security Podcast. My name is
Nate Nelson. I'm here with Andrew Ginter, the vice president
of Industrial Security at Waterfall Security Solutions, who's going to
introduce the subject and guests of our show today. Andrew,
how's it going.
Speaker 3: I'm very well, Thank you, Nate. Our guests today, we
have two of them, are Daily Brown and Nick Foubert.
Daily is the CEO, Nick is the Chief Technology Officers CTO.
They are both co founders of Metropolitan Technologies, and they
are working on a new and more secure platform, a
whole new way of doing industrial control systems.
Speaker 2: Then, without further ado, let's jump right into your interview.
Speaker 3: Hello Daily, Hello Nick, Welcome to the podcast. Thank you
for joining us. Before we get started, can I ask
each of you to tell our listeners a little bit
about yourselves, about your background, and about the good work
that you're doing at Metropolitan Technologies.
Speaker 1: Yeah, sounds good, so I guess i'll start. Thanks for
having us on, Andrews. I'm Daily, I'm the co founder
and CEO of Metropolitan Technologies. Just a bit about my background,
so I have about fifteen years of experience in the
aerospace and defense industry as a system in software engineer.
Prior to founding our startup, I worked for a big
company called General Dynamics Mission Systems, and I had roles
such as a product owner, technical lead, and senior engineer. There,
I was responsible for design, development, testing, and deployment of
various mission critical applications on airborne platforms, and they also
led research collaborations with academia in artificial intelligence, machine learning,
target tracking, and information fusion. And I let Nick introduce himself.
Speaker 4: Yeah, Hi, Andrew, thanks for having us on the podcast.
I'm Nick Foubert and the other co founder and the
CTO of Metropolitan Technologies. I have roughly fourteen to fifteen
years of experience in industry as a systems and software
developer and like Daily. Before founding Metropolitan, I also worked
at General Dynamics Mission Systems as a technical lead and
senior software developer. I worked on mission critical applications on
airborne platforms, and Daily and I actually worked pretty closely
together there for four or five years before leaving to
start Metropolitan. Before General Dynamics, I had done some other
work in biometric security and biomedical applications of machine learning.
Speaker 3: Right on.
Speaker 1: Yes, So I guess I'll talk a bit about our
startup or I'll introduce it anyways. So, Metropolitan Technologies is
an early stage Canadian startup. Were based in Ottawa, Ontario, Canada.
We founded the company to build reliable and secure commercial
products based on our experience in the aerospace and defense industry.
When we first started the company, our first idea was
to build smart city products with a focus on privacy
and equity. After you would have been a market research
for a platform to build upon, we didn't find anything
that met our actual standards for security, privacy, and reliability,
so we decided to build our own. It also became
apparent at the time the market opportunities for our own
platform were greater than the smart city applications we first
sought to build, so we did a bit of a
pivot and to focus our concentration on building out the
platform and expand beyond cities, just broader critical infrastructure and
industrial security market. And so consequently we end up building
a secure by design and default decentralized IoT connectivity and
cybersecurity platform help organizations connect and secure their OT networks
and yeah, so that's a brief introduction about us.
Speaker 3: You guys are doing some stuff that sounds really interesting.
I mean, this is why I asked you to join
us on the show. You've mentioned zero trust and IoT
Internet of things. You're talking about a platform, you know,
I know that you're also touching on stuff like mesh
networks and formal methods. You know, it's it's a bit
of a buzzword soup. But you know, if you're doing
this all I thought I got to have these people on,
can you break it down for us? You know, you
have a product line? What do you have? What is it?
What does it do?
Speaker 1: Yeah, so I'll start a bit about that. I get
carried away. Actually sometimes with the buzzards and slogans. I
think it's indoctrinated in me for my time working in
the defense industry. I'm pretty sure there's conversations we actually
used to have where we only spoken acronyms or buzzy
slogans and so old habits die hard. But I'll try
to be speak like more of a human so that
people can understand and be cognizant of it. So, like
I mentioned in the opening, we're building a decentralized IoT
connectivity and OT cybersecurity platform. We're also working on a
pre integrated edge appliance to simplify the integration of our
technology with existing OT networks. And so many of the
ideas that are built into our platform are based on
our experience in defense and aerospace industry. We wanted to
combine the resilience and security of tactical battlefield networks and
the reliability of safety riabilia and safety of avionic software
that we used to work on. And so it just
so happens that equation leads to a parade of buzzwords.
And I'll let Nick maybe go into a bit more
about what that means right now.
Speaker 4: Yeah, So we're using a number of techniques to build
our platform, and I guess these are kind of getting
back into buzzwords here, but we can dive into some
of them as we continue the conversation. But so things
like zero trust security model, data centric encryption, formal methods,
mash networking, among other things. We're using similar types of
technologies you might find in battlefield networks in the military.
So one example of that. We're a software platform, but
we're building our platform to support different networking topologies like
mesh networks that you don't typically find in the traditional
enterprise IT network. So our software components communicate peer to
peer and that helps us minimize the amount of centralized
infrastructure need to rely on. So even when the peers
in the network need to communicate with a central service
like a cloud service, for example, and they might need
to do that to do things like help discover other
peers in the network, even those more centralized services are
designed to be distributed and tolerant to network outages and
network changes. The data plane in our platform uses a
publish subscribe paradigm. What that means is that our software
components don't need to know specifically which other components they're
communicating with, but rather they just advertise what types of
data they can provide and what types of data that
they want to consume, and then our software takes care
of actually moving the data between the components. This lets
us do things like tune quality of service and enforced
security controls, among a bunch of other benefits. And the
reason we're building it this way is because we want
our platform to be usable in the most challenging industrial environments,
whether that's on a battlefield, deep in a mine or
monitoring remote asset in the Arctic. So yeah, I think
that kind of gives you a high level picture of
what we're doing as far as MESH networking is concerned.
Speaker 2: So Daily just there promised us a parade of buzzwords,
and they very much followed through. One of them that
stood out to me and trew the publish subscribe paradigm.
Do you want to help me out with that one?
Speaker 3: I got sort of two things out of it, mesh
and published subscribe. I let me start with mesh first
and then I'll come to pub sub Mesh is sort
of the concept that not everything I mean, on an
IT network generally speaking, you know, give or take a firewall,
everything can talk to everything. Anything wants to send a
message to anything else, You open a connection and there
you are with you know, with industrial networks, frequently you
have devices in the field, well you know, solar powered.
They might not be on the cellular network. They might
have sort of a local radio link to an aggregator
that's on the cellular network across blah blah blah. It
gets complete, and so it's generally not the case that
things can talk to each you know, it rather can
talk to anything, They can talk to their neighbors, and
they can pass messages along. And this is the essence
of mesh networking. You see it used sometimes in meter
reading where not every you know, meter might have a
sin card that lets you on the Internet, or not
every meter might be wired into something and a local
community of you know, smart meters might talk to each
other and find the one that has the connection to
the you know, the fiber optic backbone and send all
of their readings into there. So this, this idea of
a mesh network where you know, devices cooperate in a
challenging communications environment, is something you see in sort of
limited applications of industrial networks. And you know, these folks
at Metropolitan Technology they want to make this sort of intrinsic.
It's the natural way that everything in their system communicates.
And when they communicate, they don't make connections like TCP connections.
They don't connect to each other. It's hard to figure
out who to connect to. When they communicate, they just
say here's what i've got. I've got meta readings for
this address. Here they are, and anybody who wants that
information subscribes to it. So sending it out is called publishing.
You give it a tag, you know, meta reading DASH
for dash this address, and you push it out and
anyone who wants that subscribes. They say, I want all
of the tags that start with meta reading. And because
this is the consumer the accounting system. So this is
the concept of mesh. This is the concept of published subscribe.
You don't connect to things. You just push out what
you have and other people, you know, consume it. And
you know this, you know the pup pup sub is
is also used in industrial networks. Some you know, a
small number of big name industrial vendors, like twenty maybe
even thirty years ago when pup sub just sort of
was invented, adopted pub sub wholesale and one or two
of the big vendors out there use it internally everywhere,
but even everybody else in the industrial world, most of
them use published subscribe to talk to the cloud because
the MQTT protocol has emerged as you know, the dominant
way to talk to the industrial cloud or the Internet
of things cloud, and MQTT is intrinsically pub sub you know,
So when I don't know, a smart watch talks to
the cloud, or you know, any smart device talks to
the cloud three times out of four. It's using MQTT,
it's using pub subs. So these are not alien concepts
in industrial automation. But what Metropolitan Technology has said is
this is the right way to do this, and they've
made it the default. It is the way their stuff communicates. So,
if I may a clarifying question, I heard you use
the phrase data plane, and I hear people use that
phrase from time to time, and I've never figured out
really what it means. You know, in my understanding in
deep history, it might have come from telecoms, where you
tended to have maybe two sets of wires, one for communicating,
you know, the voice communications the phone calls back fifty
years ago, and a separate kind of communications mechanism for
communicating you know, metadata like call setup or billing or
who knows what today. You know, we're talking the Internet.
What's the difference between a data plane and any other
plane in the Internet?
Speaker 1: If you can, yeah, so I can jump in right here.
So we kind of divide our system up into two
different planes, or we call them planes. We call it
when's the data plane and one's the management and control plane.
And the reason we differentiate. This is because the actual
means of communication are slightly different. So when we say
our systems decentralized, we mean the data plane of our
systems decentralized and the data We consider the data plane
all the operational technology data, so sensor data, actuator and
control data, and the other type of data you would
find when when, for example, working with an industrial control system,
the management and control plane, we consider that things like
access control, security policies, remote the health and monitoring of
the actual application, things like that, and so that part
of our platform can be centrally managed and locally enforced.
But that's why we differentiate between the two. And I
don't know, Nick, did you want to jump in there
and clarify anything.
Speaker 4: Yeah, I think you've covered most of the points, and
we'll get into a little bit more about our zero
trust security model. But I think Daily mentioned our PM
is a software platform, but we organize it in two
layers as far as the communication infrastructure goes, and we
have an outer layer that kind of provides a level
of perimeter security. So there's an encrypted outer layer, and
then the inter layer of that is another separately encrypted
layer of data, and that's just that's typically what we
refer to when when we're talking about the data plane.
Speaker 3: Just so I'm clear, Like I said, I'm old school,
I never I've for decades, I've wondered what this stuff means.
What I'm hearing you say is that in the modern world,
it's more or less all Internet protocol at the core,
but we're talking maybe a different set of TCP ports
or maybe even UDP ports, different set of protocols for
the data plane, which is sort of a collection of
protocols and services that are focused on moving the data
around or managing the data. And the management plane that
is more a set of protocols and services focused on
managing the system, configuring the system, rather than dealing second
by second with the data. Is that fair in terms
of terminology.
Speaker 1: Yeah, I'd say that's a pretty good way of describing it.
Speaker 3: Okay, sweet, because I've always wondered if it's, you know,
something much more exotic. So thank you for that.
Speaker 1: You have it right, and it's a good The example
you gave earlier about the wires and the metadata for
the telephone system and then the actual voice over the
vice part of that is a pretty good analogue to that.
Speaker 3: So let's dig into some of your your your other concepts. So,
you know you've you've mentioned mesh. You know you've mentioned Mesh,
You've mentioned cloud, you've you've defined a mesh communications system.
What are you using it for? Sort of what's the
next layer of functionality you're building in.
Speaker 1: Yeah, so let's maybe talk about the zero trust security
model of it, because that'll that'll describe a bit about
the kind of the shell of how it works, and
then we can kind of dive deeper into some of
the other technologies that we're applying to make the system secure.
And so just related to zero trust our platform, we
built it from the beginning to have a zero trust model,
and the idea of relying on something like perimeter security
for a software system never sat well with me, even
before the term zero trust became sort of mainstream, and
so it's one of the reasons we sought to build
our own activity platform is that when we're doing market research,
we found that there was too much implicit trust in
many of the existing solutions, and so we built our platform,
as Nick mentioned, to consist of two independent security layers,
each with their own zero trust security model. The outer
Mesh network layer that we've built can overlay untrusted and
unsecured networks, and so each node in that network is
mutually authenticated continuously, whether it's a service user device, and
so this provides broad protection against what we'd call like
outside threats to an OT network. We have an inner
peer to peer layer that provides data centric encryption, ensuring
that all data in our OT network is accessed on
a need to know basis. And so this inner layer
provides very fine grain control over who sees what and
who can connect to whom, helping protect what we would
say the OT network against insider threats. And so these
access control policies are locally enforced at each node in
our network, and this ensures that the zero trust security
model is enforced even if we face network partitions or outages.
And so we take the idea of zero trust even
further than that, actually further than the conventional definition that
includes only users, assets and resources, and we bring it
to the actual granular data level, so that even within
a software process, there is zero trust regarding what data
can be read or read or written by that software process.
And I'll just say there's actually some other practical benefits
of our approach to this too, especially at the convergence
of IT and OT networks. The outer layer provides like
a well defined perimeter in which to hunt for threats,
and so nodes in the in the network outside of
our software defined perimeter, I'll say, could be considered outsider threats,
and we're mostly concerned about preventing sort of like denial
of service attacks there and those types of those types
of threats, and then nodes that inside the perimeter could
be considered insider threats. And then in addition to sort
of denial service attacks, we're concerned about the confidentiality and
integrity of that data that's being passed around. But because
of our security model, it makes a problem of intrusion
detection easier inside are inside our mesh network, and so
and the data centric security part of our system preserves
the integrity of the data even if somehow some sort
of node were to be compromised, and so we have
a pretty our defense in depth architecture provides a lot
of almost have guarantees, but as much to the extent
as possible protecting the actual integrity and of the data
that is being passed around.
Speaker 2: At this point, I think the term zero trust has
been used at least a dozen times in your interview, Andrew,
and it always makes me cringe because of how that
term is thrown around in IT. Are we using the
term zero trust here in the same way that I'm
used to it in IT spaces? Kind of?
Speaker 3: I mean, zero trust has evolved. My original understanding of
zero trust was basically what you do on the Internet.
If you want to log into if you want to
connect to anything sensitive that you know involves money, you
have to give a password, you have to have an
encrypted connection. That was zero trust. You don't give someone
money just because you like their IP address, the way
you might trust someone on an IT network old school.
The modern sort of vision for zero trust has evolved into,
you know, something that's loosely sort of marketing talk for
active directory. If you look at a lot of the
zero trust standards that are coming out of NISS, the
US National Institute of Standards and Technology, they're talking about
you know zero trust as single sign on, where instead
of sending your username and password around to every machine
everything you want to do, you sign on once to
a zero trust broker, which is an active directory server,
and you get back a Kerberos ticket, which is sort
of an encrypted thing that represents you and your credentials.
And now you can go to the print server or
you can go to the SAP server and you know
not have not be challenged for another password. That's sort
of the thing on IT networks. What I heard Daily
and Nick talking about here was sort of zero trust
taken to an extreme, where every message that is exchanged
in the system is authenticated somehow, not just every log in,
every message, not just every connection. There are no connections.
It's all published subscribed, so you can do really fine
grained permissions. You can say, you know, these kinds of
users have permission to subscrib to these topics this data
that I'm putting out, but not that data that I'm
putting out. Every topic can have different permissions, and you know,
every message where you exchange you know, a topic and
a piece of data has to be signed. And so
in a sense, it's the IT style of zero trust,
let's say, taken to an extreme. So thanks for that.
So you know, we've we've talked about mesh. We're talking
about you know, authentication, constant authentication within the mesh. This
is in a sense the nature of zero trust you've
also you know, I know that you guys touch on
formal methods, and this, you know, drew my attention. I mean,
correct me if I'm wrong, you know, can you tell
us what are you doing with formal methods, and you know,
if you might sort of correct my misconception if there
is one. When I hear formal methods, I imagine we're
proving things correct. Now, I know formal methods actually be
a little different from that. You know, can you talk about,
for you what is formal methods and what are you
applying it to, What's what's the goal? What are you
achieving with that? Yeah?
Speaker 4: So in short, you're right. In essence, formal methods is
about proving things correct. So formal methods essentially are rigorous
mathematical techniques to specify, analyze, design, implement, or verify a system.
And I know a lot of people get scared or
maybe bored when the topic of math comes up, so
I'll try to keep it more high level here for
your listeners. So under the umbrella of formal methods is
another concept called formal verification, and that's where you're proving
the correctness of a system with respect to some formal
specification or property of that system. So examples of that
typically are like safety or security properties, and traditionally, outside
of academia anyways, formal methods have been used mainly in
the most safety and security critical systems like avionics. That's
mainly due to the expertise and the specialized tools that
are needed or were needed anyways. But we're starting to
see more traction across industry as awareness grows of these
tools and the tools are actually becoming easier to use
and to apply. So one example of their use in
industry actually comes from our home province of Ontario, where
formal methods were used from the design through the verification
of a software based shutdown system for the Darlington Nuclear
Generating Station. So I think they spent about a decade
working on formal methods again across design through verification to
ensure that the shutdown system was in fact safe. So
there's many different techniques that fall under the umbrella of
formal methods, and today there's lots of tools that actually
help developers automate those techniques. So some of the ones
we're using at Metropolitan include things like static analysis, model checking,
and automated proof tools. And I'll dig in to these
a little bit so your listeners understand a bit what
those are. So static analysis is quite widely known actually
in the software development world, and it essentially consists of
automatically checking certain properties of a computer program at compile time,
so before you're actually running it in a test environment
or running it in a production environment. So examples of
the types of properties that can be checked by static
analysis include things like that the programmer who route the
program isn't using language features that are potentially unsafe because
programming languages in general allow you to do a lot
of things with the underlying hardware, and in safety critical systems,
sometimes you don't want to use that full feature set
because you can introduce errors into the program that can
cause safety or security issues. Some other things you can
check with static analysis are that well known program weaknesses
or vulnerabilities aren't actually in the program. So there's databases
that are available publicly that actually lists the types of
weaknesses and vulnerabilities that are often found in software, and
some of these static analysis tools can actually check those
databases and check it against your source code to make
sure that the programs aren't actually implementing those weaknesses or vulnerabilities,
and then also things like linters, which essentially means analysis
tools where that look at the source code of your
program and make sure that they meet a certain quality specification.
So this is often used to make sure that the
source code can be read, maintained, and updated by somebody
other than the original programmer. And this kind of thing
is really important in software systems that have to live
for quite a long time, so the original developers of
the system might not be around anymore, and you need
programmers to make updates or to make fixes to the software,
so you want to make sure that they can actually
read and maintain that software. So we have tools that
help us ensure the quality even of the source code.
One that I mentioned was model checking, so that refers
to automatically and exhaustively checking that certain logical properties of
a system are true or false for all reachable states
in that system or for some specific state of that system.
And usually we use simplified models of the system, but
we ensure that they include the essential states of that
system and how they might change over time. So in
model checking, one type of property you would want to
prove is called the safety property, and that's something that
the system should not do, should never do. So. Examples
of that might be like, in a financial transaction system,
you want to prevent double spending, so someone can't spend
the same money twice simultaneously on different transactions. In an
electronic medical record system, you want to ensure that you're
not leaking private personal data. Or in an industrial control system,
you want to make sure that you're not issuing your
system's not issuing a command that could cause physical harm
or system damage. And then automated proof tools layer on
top of that, and they can do things like automatically
prove the absence of any runtime errors in your software implementation.
So most people familiar with software development are aware of
software testing, and software developers spend a lot of time
writing tests against their software, and that's great, but software
testing cannot be exhaustive. But we do have proof tools
that actually can prove conclusively and exhaustively that there are
no bugs in your software that will cause runtime errors. So,
and you can prove other things like specified data dependencies
and flows in the program. So you want to ensure
that certain software modules data only flows from one to
the other and doesn't leak back out the other way.
Or you can prove that a software implementation is correct
with respect to like a functional specification. So your customer
has some functional specification of what they want the piece
of software to do. You can write that specification in
a programming language, and that same programming language can actually
be used to prove that your implementation of that is
correct with respect to that specification. So again, typically that's
done with testing and demonstration to your customers, and sometimes
by analysis or inspection of the code itself. So these
proof tools add another level of assurance that because they
can do sound reasoning, you can get assurance that your
software actually does what the specification wants it to do.
So the last thing I want to say about formal
methods is that awareness of formal methods is growing pretty
rapidly in industry. So for instance, last year, the White
House released a report called Back to the Building Blocks,
which is part of the United States National Cybersecurity Strategy,
and it explicitly calls on industry to start adopting formal
methods into their software engineering. And if your listeners do
a quick Google search, they'll be able to find examples
of how formal methods are being adopted by some of
the giants in computing like Amazon, Google and Nvidia, and
of course metropolitan technologies.
Speaker 3: Might dumb it down. In my understanding, it's very difficult
to apply formal methods to very large software artifacts. I mean,
you know, the Windows operating system is said to have
I don't know, something like one hundred million lines of
code in it. You know, a web browser has I
think more than ten million lines of code in it.
The industrial control system products I worked on back twenty
years ago in my youth were you know, two three
million lines of code. It's difficult for me to imagine
applying formal methods to a body of software that large,
and so in my dim understanding, you know, dumbing it down,
we use these techniques on smaller software artifacts, or possibly
even with a larger artifact with a specific goal. So
for example, you know, Waterfall produces a unidirectional gateway. Now
we don't to mind all which I'm not part of
the dev team. To my knowledge, we're not doing formal methods,
but we you know, we have been certified against you know,
common criteria. Common criteria is a kind of certification. The
way it works is the vendor makes a claim we
claim the hardware is truly unidirectional. It does not matter
what you do to the software, it's not physically possible
to send any information back in the other direction. So
you make a very specific claim. The common criteria tests
the system against that claim. In my understanding, it's analogous
you know, correct me if I'm wrong to formal methods
where you say this is what we're going to prove,
and you state that thing, whatever it is, reasonably Simply,
it has to be reasonably simple to have a high
degree of confidence in your proof, and then you set
about using formal methods to establish that property. Can I
ask you, you know, what properties have you focused on
in your use of formal methods. What is it that
you believe that your customers or the marketplace are going
to want, you know, to have a high degree of
assurance for you.
Speaker 1: Make a good point. You know, formally proving properties of
a whole industrial control system or an operating system with
millions and millions of lines of code is an enormous undertaking,
and so we're very aware of that. We started with
proving the absence of rent time errors of what we
identified as critical components of our software. And our long
term view is to prove as much as humanly possible
that our code has no vulnerabilities, as that means like
making a foundation, building a foundation, a software foundation in
libraries and small building blocks that we've formally proven that
we could build on top of. And so we believe
that proving at least part of your code is a
step in the right direction for security. Is this one
of the best techniques available to us for us to
reason about software? And so I'll let NIC colaborate adate
on the couple of focus areas that we're working on
to prove and where we think that's valuable.
Speaker 4: Yeah, to get a little bit more specific, So, yeah,
we're focused right now essentially in two areas. First at
the points where our software consumes or ingests data from
other systems, and where our software produces and publishes data
to other systems. So, because interaction between software components is
generally governed by protocol and format specification, they can either
be standardized or sometimes they're proprietary. But most software developers
will know that poor input validation, whether that inputs from
a human in a guy or from another piece of software,
is the source of many vulnerabilities and it's a common
attack vector. So a core part of our platform's value
is in connecting and translating between many different communication protocols
and formats. So we're using specification and cogeneration tools that
cannot prove that our data input and output more models
will only accept and create valid data, and that those
modules themselves are free of runtime error. So for instance,
you can't bad input data won't cause a buffer overrun
in the software and cause the software to crash. The
second area we're focused on really is our overall software
engineering tooling and practice. So for example, all of our
own software is written using the Spark programming language, And
just to not confuse your listeners, it's not the Apache
Spark tool, but it's it's a programming language that's been
around for quite a while. It's part of a subset
of what's known as the Ada programming language, which was
originally designed for the United States Department of Defense, and
it's a mature but modern language designed for the most
safety and security critical system So using Spark as a
programming language gives us a high level of software assurance
as a baseline, because the language itself was designed for
critical systems, and it includes a bunch of features that
help programmers write error free programs. But on top of that,
it also allows you to progressively apply additional methods to
prove critical data flows, program integrity, and functional correctness, things
I was talking about earlier. And so the ability to
progressively apply these methods means that you don't have to
fully prove a program or an entire system from the
get go. You can focus on your critical components first.
So again in our case, we're mainly focused on where
data comes in and how data goes out because those
are aspects of the system that we have less control over,
and we're using the higher assurance proof tools on those
components first. But we're building all of our software using
this language. That's going to allow us to progressively increase
the assurance in areas that we deem to be of
higher criticality.
Speaker 3: Let me ask you, though a hard question. I remember
this was maybe close to a decade ago, the SSH protocol.
A bunch of mathematicians proved the protocol correct. What does
that mean? They proved that if an implementation complies with
the protocol, if there's no defects in the implementation, then
the protocol could not leak key information into the Internet
into anybody, so that you know, the keys for the
communication will always be secure. A year later, they broke
the protocol. Not an implementation, they broke the protocol. They
demonstrated how every compliant implementation of the SSH protocol could
be manipulated into leaking the first fourteen bits of the
key information. How did they do that? It turned out that,
you know, the mathematical proof proved an assertion. You know,
no key information leaked proved the assertion at a certain
level of abstraction. What they did was they said, well,
you know, we're using the Internet, we're using TCP. And
they modeled TCP mathematically as sort of a tube where
you stick characters in one end and they come out
the other end, either in the same order the same characters,
or the connection is torn down. That's sort of the
assumption the mathematical model they had of the TCP protocol.
And of course everyone knows TCP's messages, and you can
fit multiple characters into a single message. It's not one
character at a time, it's sort of messages at a time.
And they used a timing attack to prove that every
compliant SSH implementation could leak the first fourteen character fourteen
bits by taking advantage of information about you know, messages
that are sent back and forth and the time stamps
in those messages, and so really, you know, they attack
the protocol below the level of the proof, below that
level of abstraction. Can you talk about, you know, can
you talk about sort of applying this principle to your system?
What is you know, at what level of abstraction are
your proofs? You know what? Bluntly you know, should we
believe these proofs?
Speaker 1: Yeah, so you make some good points. Formal methods can
be applied at multiple levels. So, like you mentioned, at
the specification of the protocol in this case SSH, you
can apply them at the systems level, for example, proving
a distributed system has various properties, and you can apply
them at the implementation level, and this is where we
are concentrating. But also, like you mentioned, they're only as
good as a specification in which they're proving, so it's
not a panacea. One of our main assumptions, though, is
the cost of integrating formal methods into our engineering processes
are coming down to the point where the benefits outweigh
the costs. Even for a startup. So even though you
might it's true that if there's a flawed assumption the specification,
then even the implementation improving the proof and improving implementation
itself against that specification could also have flaws. We are human,
after all, writing these specifications. It does, though, give us
the best defense to the extent possible that reguarding against
certain security and safety vulnerabilities, And the tooling is getting
better to allow us to identify some of these, and
maybe Nick, you can talk a bit about that.
Speaker 4: Yeah, So, I mean the tooling has improved to the
point where you can progressively adopt that the techniques of
formal methods. But and it is best to start as
early as possible. So at Metropolitan we started right from
the beginning, from day zero, and our platform is not
fully proven yet, as we mentioned before. But I mean,
think about it. Would you rather use a tool that
has proven to be correct with respect to some set
of assumptions, and where the developers are working on proving
more and more of it correct with respect to even
more conservative assumptions, Or would you rather use something that
is just as secure as the human developers can think
to make it before they move on to their next task.
So we don't use well, sorry, where we don't use
formal verification, yet we cover everything else with automated testing
to help ensure the reliability of our platform. And we
think this hybrid approach of mixing formal methods on the
most critical components first and filling in gaps with automated
testing is the most practical approach for us right now,
and it's acceptable for the highest level of certification for
functional safety, for example in avionics. So we're not the
only ones who believe in this approach. So I think
maybe to get back to the example you give and
just to bring this back up to a high level.
One thing I think is important to bear in mind
is that I think adopting formal methods into your engineering
process forces you to do a bit of thinking in advance. So,
for instance, in the cybersecurity space, you know your your
formal proofs are only going to be as good as
the models you've developed to eventually develop your software and
prove that software correct. But when you're developing your model,
you need to make sure that you're accounting for things
like your threat model. So there are things there are
unknown unknowns in the world, you know, and we have
to do some deep thinking at the start of our
design to try to capture you know, the full threat
landscape as best as we can. And you know, these
tools will help you prove that your software implementation is
robust against those threats. But again, like Daily said, it's
not a panacea. There again are unknown unknowns and sometimes
your models don't account for certain threats that you could
not have predicted.
Speaker 3: So there's been some long answers here, Nate. You know,
I asked a complicated question. I got a bit of
a complicated answer that was very carefully couch saying, well,
you know, nothing is ever perfect. We're not guaranteeing that
our stuff is perfect. You know. They had sort of
the bottom line buried in a paragraph I wanted to
emphasize in my mind. The bottom line is this, when
you are looking for a software platform, a technology platform
to build an important function on a safety critical function,
a function that's you know, essential to critical infrastructure. When
you've got something important to do, you have two choices.
You can either use a bunch of software as your
foundation that a bunch of developers have worked on and
then moved away, you know, did what they could and
moved on. Or you could use a bunch of software
that has been proven correct under a bunch of assumptions
against a bunch of threats in light of, you know,
a bunch of contingencies, and the development team continues to
prove the thing correct and evolve it to become more
correct against more threats and more condition Which would you
rather the one that people kind of do what they
do and move on or the one where you know
you're determinedly proving it against a bigger and bigger body
of potential gotchas, I'd rather use the platform that's been
proven correct. No, it's not perfect, but it sures a
big step in the right direction, is what it sounds
like to me. What you're building is in a sense
of platform, It is software that other developers can use
to develop industrial control systems. And when you have sort
of infrastructure like that. In my experience of the marketplace
in you know what vendors I've worked for, you tend
to see programming platforms adopted by vendors who are building
industrial control systems when there's sort of a compelling need.
The compelling need might be the threat environment changes. Don't
know you know, a gazillion stucksns hit everybody next year.
Or it might be that, you know, there is a
new kind of application I don't know, you know, smart
car chargers or something that demand a new way of
doing things, or you know it. It might be that
it solves a long standing industry problem and the whole
industry looks at it and says that's the right way
to solve this problem, and all of their new development
switches to the new platform. You know, Java was a
little bit like that. Can I ask you, you know,
how's it going in terms of adoption? Do you see
a triggering event? Do you see a new industry? Do
you see a killer app for this platform that you're producing.
Speaker 1: I'll say that, you know, the digital transformation of industry
is happening, and so you know, historically a lot of
these OT networks, industrial control systems, et cetera, have been
isolated and they've been off the Internet, and for valid
reasons for cybersecurity and other reasons as well. But there's
there's new requirements coming out and I think it's you
can't ignore the fact that increasingly OT networks are becoming
connected to the Internet, and there's reasons people want to
do this, you know, compliance with new cybersecurity requirements asset management,
so remote monitoring and management of all the assets in
the network, applications like predictive maintenance become possible. And so
with this digital transformation, though, there's a lot of new threats,
cyber threats possible to the existing infrastructure and architectures of
these oteen networks, and so say in addition to that,
there's incoming macro triggers, and one, for example, could be
quantum computers and the threat of quantum computers against traditional cryptography.
And so having a platform that can address some of
these emerging requirements of connected oteen networks and some of
the existing vulnerabilities of the of the solutions that exist today,
I think is valuable. And so we're trying to address that.
And at the same time, we're also cognizant and sensitive
to to being as non disruptive as possible to the
existing networks, because we know people organizations buy these and
they expect to operate their their networks, their ot devices
for decades, and so the sales cycle and and and
and the lifetime of these of these devices and systems
is very long, and so we have a platform, but
we also have a means of less disruptive integration of
our technologies and we've kind of alluded it to it earlier,
and we'll talk a bit a bit more about this
in a bit about having it pre integrated on an
edge appliance where you can just sit in front of
an OT network to get a lot of the benefits
that we've talked about without without having the fully without
having to fully disrupt the current operations of the OT environment.
And so to that point, Yeah, I think there's triggers coming,
and I think there's there's value in our platform moving forward,
and there's ways of getting the benefits of it without
being very disruptive to the existing networks and systems.
Speaker 3: You folks are a startup. You've got a bunch of
stuff that you're done. You've got a bunch of stuff
that you're doing. How's it coming? You know? Have you
is there? Is there? Adoption? Is there technology? You know?
How are things going?
Speaker 1: Yeah? So you know, as a startup founder, it's a
roller coaster, but you know it's rewarding that you're building
a product that you think will make a difference, especially
in an industry that has such an impact on people's
day to day lives, and so in terms of where
we're at, we're doing ongoing customer discoveries. So we're talking
to industrial control system vendors, we're talking to operational technology operators.
We're making sure we provide a solution that's desirable and
feasible and trying to best position ourselves in the market.
We're also building partnerships with industries, so these include multinational
system and integrators, security companies, and other technology partnerships to
go to market with. And Nick, you want to talk
a bit about R and D stuff we're doing in
the pilotday.
Speaker 4: Yeah, so we're still in the research and development and
piloting phase of our product.
Speaker 1: Right now.
Speaker 4: We have a beta release that's actually out in the
wild in a controlled test environment, and that allows us
to rapidly iterate and test our platform. We're working towards
what you'd call maybe a version one release later this year,
probably in the fourth quarter. We're also working on a
pre integrated edge appliance that can sit in your OT
network just in front of a device, like a bump
in the wire, to provide as non disruptive as possible.
Integration of our edge technology, and we feel like this
is the path of least resistance to getting our technology
deployed in the most critical of infrastructures where people tend
to be a lot more risk averse.
Speaker 3: This is, in a sense, so different from what I
do every day. I'm not even sure I've asked you
the right questions. So let me ask you an open question.
You know, what else do you want to talk about?
What have I missed? What didn't I ask you that
I should have?
Speaker 1: Yeah, actually that's a good question. And there's a really
cool pilot project that we're working on. So we're working
on a quantum state version of our platform specifically for
industrial control systems, and we're using the DNP three ecosystem,
which is a pretty standard protocol used in utilities, as
the first use case for this new configuration of our platform,
and we're ensuring the protocol is secure against existing and
emerging threats such as quantum computers. It's a very exciting project,
and we're working with really bleeding edge security technologies and
we're integrating a brand new state of cryptography which has
been independently proven to have information theoretical security, and so
what that means is as a system that secure against
adversaries with unlimited computing resources and time, such as a
quantum computer. And I just want to clarify this is
not the same thing as post quantum cryptography, which has
been quite a bit in the news lately and which
NIST has recently standardized and also which OT operators will
be expected to adopt in the future, and which we
also actually also support. But it's actually using a different
type of key distribution technology altogether. And so we're of
a consortium of a bunch of world class companies and
universities delivering this capability. And I'm just going to shout
out our partners, and so it's TALIS Digital, Identify, Talis
Digital and Identify Identity Services, which is a group of
from the Talis multinational French company, Quantum Bridge, which is
a Canadian startup and university at Toronto, and funding has
been contributed by one of Canada's most prestigious funds as well.
And there's actually gonna be a public announcement in the
next few weeks about the project.
Speaker 3: Well, Nick Daily, this has been educational. I love I
love episodes where I learned something you know before we
let you go. Can can I ask you, can you
sum up for us what you know, what what should
we be be, you know, thinking about learning about in
this space.
Speaker 4: Yeah, thanks a lot for having us, Andrew. This has
been a great experience. So I guess what I'll end
off saying, though I might be preaching to the converted,
is that cybersecurity shouldn't be an afterthought, especially in critical
infrastructure systems. These systems are essential to our day to
day life, and I think that we as in the
general public, often take their reliability for granted. It should
be table stakes that cybersecurity is intrinsic in the development
of any operational technology, and we take that very seriously
when we say that we are secure by design and default.
I don't know daily if you want to wrap it.
Speaker 1: Up, Yeah, so I'll just say, you know, the vision
of our company is to be the digital backbone of
the world's critical infrastructure, and we don't consider ourselves like
a traditional cybersecurity company. We're a connectivity company to take
cybersecurity seriously, and we aim to market a product that's
easy to integrate and to secure from the ground up,
allowing organizations to reap the full benefits of their digital transformation.
And at the same time increase the resilience of their infrastructure.
And so I'll just send by inviting all the listeners
to connect with us on LinkedIn or send us an
email to schedule a demo or just chat some more
about the technology we're building. And we're always looking to collaborate,
partner or proather technologies with other organization. So we hope
that what we've discussed resonates with some of the listeners
out there and we can continue this conversation. And so
thanks again for having us, Andrew, and we'd love to
come back on the podcast in the future to catch up.
Speaker 2: Andrew. That just about concludes your interview with Daily Brown
and Nick Fubert from Metropolitan Technologies. Do you want to
take us out now with a final word for our listeners?
Speaker 3: Sure? You know, I I love episodes like this where
I learned stuff and I've you know, heard of formal
methods for a long time and you know, they slowly
are making our making inroads in different industries. So it's
you know, I was keenly interested to see how how
these folks were using it in the industrial control system space,
you know, to me the challenge and you know, in
the in the interview here, it's clear that that Nick
and Daily understand the challenge. The challenge business wise with
this kind of endeavor is that you're not selling the
platform form to end users, Okay, to power companies. Power
companies don't buy this kind of platform because as much
as possible, power companies really try hard to avoid writing code.
They want to buy stuff, not write stuff themselves. You've
got to sell this stuff to people who write a
lot of code. So you know who in the industrial
space is writing a lot of code right now? Well,
to me, the huge opportunity is renewables. You know, it's
taking what you know, the oil and gas sector that
is being transformed, taking the electric sector that's being transformed.
There's a lot of new code being written, not just
you know, existing control systems that have a new feature
of six. We're talking brand new stuff for electric vehicle,
high speed chargers and you know, load balancers within the
grid for the high speed chargers. A whole bunch of
new code being written. And you know, to me, that's
that's an opportunity is these developers, these businesses who write
in that code are looking around for the platforms they're
going to use. Is it the same old or is
there something new and better? Because you know, when you
start the process, that's the huge opportunity for embedding a
new platform in a new way of thinking about it.
So you know, that sector strikes me as ripe for
innovation like this and it's you know, lovely to see
that there's options like this in the marketplace. Well, we'll
have to see how they shake out over time.
Speaker 2: Well, thanks to Daily and Nick for elucidating all that. Andrew,
thank you for speaking with me.
Speaker 3: It's always a pleasure. Thank you, Nate.
Speaker 2: This has been the Industrial Security Podcast from Waterfall. Thanks
to everyone out there listening.