1
00:00:05,040 --> 00:00:16,800
Staying still is moving backwards and then
the security I think. Welcome listeners to

2
00:00:16,879 --> 00:00:21,359
the Industrial Security Podcast. My name
is Nate Nelson. I'm here with Andrew

3
00:00:21,359 --> 00:00:26,359
Ginter, the vice president of Industrial
Security at Waterfall Security Solutions, who's going

4
00:00:26,399 --> 00:00:29,760
to introduce the subjects in guests of
our show to day. Andrew, how

5
00:00:29,760 --> 00:00:33,039
are you? I'm well, Thank
you, Nate. Our guest today is

6
00:00:33,159 --> 00:00:38,479
Jake Hawkes. He is a senior
product manager at Aviva and his topic is

7
00:00:38,520 --> 00:00:45,200
going to be doing product security for
Aviva Enterprise Skata. And you know,

8
00:00:45,240 --> 00:00:48,439
this is the product that he's the
product manager for. And you know,

9
00:00:48,640 --> 00:00:54,679
I know this product line for a
long time as as the industry leader in

10
00:00:55,000 --> 00:00:59,679
control systems for oil and gas pipelines
and today I know they have many other

11
00:00:59,719 --> 00:01:03,399
industy that they're involved with, but
the oil and gas pipeline thing that was

12
00:01:03,960 --> 00:01:07,040
in my recollection. How they how
they got started? You know, fifteen

13
00:01:07,120 --> 00:01:11,359
twenty years ago. They used to
be called tel vent Oasis, but Aviva

14
00:01:11,480 --> 00:01:15,319
bought Televint or at least bought the
product line a'm week on the details,

15
00:01:15,159 --> 00:01:19,319
and they renamed it to a Viva
Enterprise Skata. So that's what we're going

16
00:01:19,400 --> 00:01:25,519
to be talking to Jake about how
they do cybersecurity for a Viva Enterprise Skata.

17
00:01:26,200 --> 00:01:29,400
Then, without further ado, let's
listen in to you with Jake.

18
00:01:32,120 --> 00:01:34,359
Hello Jake, and thank you for
joining us. Before we get started,

19
00:01:34,400 --> 00:01:38,480
can you give us a few words
of introduction about yourself and about the good

20
00:01:38,480 --> 00:01:42,200
work that you're doing at Aviva.
You bet yeah. I'm a senior product

21
00:01:42,200 --> 00:01:47,359
manager at Aviva based here in Calgary, and I'm in charge of the Enterprise

22
00:01:47,560 --> 00:01:55,319
Skat product which was formerly known as
Oasis Skata and it predates Aviva when Aviva

23
00:01:55,319 --> 00:02:01,599
bought Telvent. Essentially that's how they
acquired this product. They acquired this so

24
00:02:01,920 --> 00:02:07,560
Aviva acquired Enterprise Skater as part of
the carve out of the software business from

25
00:02:07,560 --> 00:02:12,280
Schneider Electric. Me myself personally,
I started my skated journey about twenty three

26
00:02:12,439 --> 00:02:16,520
years ago as an intern for a
pipeline operator in Australia, where I was

27
00:02:16,560 --> 00:02:21,759
first exposed to the Unix version of
Oasis. Since then, I have held

28
00:02:21,759 --> 00:02:27,800
positions in customer support, technical sales, proposal support, project management, and

29
00:02:27,840 --> 00:02:31,039
now product management. Most of my
career I've been in oil and gas,

30
00:02:31,080 --> 00:02:35,840
but because our products are used in
water and wastewater. I've spent some time

31
00:02:35,879 --> 00:02:39,919
over there as well as transportation,
agriculture, and then I took a brief

32
00:02:40,080 --> 00:02:46,039
hiatus from oil and gas and did
some advanced weather systems, still using Oasis

33
00:02:46,240 --> 00:02:51,680
and using some of my computer systems
engineering degree with a bit of hardware thrown

34
00:02:51,719 --> 00:02:55,439
in for some fun. So I've
come a full circle starting out as an

35
00:02:55,439 --> 00:03:00,520
intern on this product for which I
am now the product manager. So very,

36
00:03:00,639 --> 00:03:06,560
very satisfying arc of my career.
Thanks for that. Our topic today

37
00:03:06,919 --> 00:03:12,199
is sort of the approach for cybersecurity
that two folks are using in the Enterprise

38
00:03:12,680 --> 00:03:16,800
Skat product. But you know,
before we dive into security, you know,

39
00:03:17,000 --> 00:03:21,120
I'm familiar with the product. You
guys are here in Calgary. I've

40
00:03:21,159 --> 00:03:24,199
sort of watched you from the outside
for a very long time. But for

41
00:03:24,240 --> 00:03:28,719
everybody else, can you say a
few words about what is Enterprise Skata?

42
00:03:28,919 --> 00:03:31,159
Who uses it this kind of thing? Yeah? Thank you? Yeah.

43
00:03:31,240 --> 00:03:36,199
So previously it was known as Oasis, and it has been known as that

44
00:03:36,280 --> 00:03:39,520
for longer, so perhaps your listeners
know it by that name. When we

45
00:03:39,520 --> 00:03:45,199
were Intellgent and before that val Met, We've had a lot of names over

46
00:03:45,240 --> 00:03:51,120
the years. It is a SKATER
system. So SKATA is an acronym supervisory

47
00:03:51,199 --> 00:03:57,800
control and data acquisition. It is
a computer system or a system of systems

48
00:03:57,879 --> 00:04:02,000
really that does supervisory controlling data acquisition. Not to repeat myself, but that

49
00:04:02,240 --> 00:04:08,759
is what it does. It acquires
data from across the entire asset, and

50
00:04:09,639 --> 00:04:14,000
it provides that situational awareness to the
operator who is sitting in a control room

51
00:04:14,080 --> 00:04:18,959
operating the asset twenty four to seven, and enables them to send commands to

52
00:04:19,120 --> 00:04:26,199
the field to operate the asset.
So their job is primarily to move product

53
00:04:26,399 --> 00:04:30,279
through the pipeline, but secondarily to
keep it all in the pipeline. And

54
00:04:30,879 --> 00:04:35,360
so the system starts with bringing back
the raw data and allowing controls from the

55
00:04:35,439 --> 00:04:42,000
operator to the field. But then
that's really its starting point. And then

56
00:04:42,079 --> 00:04:46,399
on top of that we layer applications
that make it easier for the operator to

57
00:04:46,079 --> 00:04:50,360
manage and operate a pipeline. There
are many SCATA systems on the market.

58
00:04:50,839 --> 00:04:57,759
Ours comes out of the box with
all of these heightened pipeline applications layered on

59
00:04:57,879 --> 00:05:00,800
top of it and integrated into it. On top of that or next to

60
00:05:00,839 --> 00:05:04,759
it, if you will, coming
out of our same product group are other

61
00:05:05,279 --> 00:05:11,920
pipeline industry applications. We sort of
know these as the advisor application. So

62
00:05:12,000 --> 00:05:16,040
we have Measurement Advisor, we have
Gas day Advisor, Commercial Advisor. These

63
00:05:16,800 --> 00:05:23,560
products then are ancillary products around this
SKATA system and they bridge between the OT

64
00:05:23,759 --> 00:05:29,199
space the control room with say the
commercial aspects of buying and selling product from

65
00:05:29,279 --> 00:05:32,959
your suppliers and customers, as well
as then accounting for the product as it

66
00:05:33,040 --> 00:05:40,600
goes through your pipe. So Measurement
Advisor is a gas measurement system. We're

67
00:05:40,639 --> 00:05:45,240
working on a liquid enhancement to that
so that we'll be able to measure engls

68
00:05:45,439 --> 00:05:48,199
and other things like that. But
the gas measurement accounting system then is a

69
00:05:48,279 --> 00:05:54,120
way for you know, the company
to build based on an energy value,

70
00:05:54,680 --> 00:05:58,920
not just a volume. So so
there was an example of some of the

71
00:05:59,240 --> 00:06:02,639
layered applications on top. But fundamentally, enterprise SKATA is a skater system.

72
00:06:03,160 --> 00:06:10,639
Skater systems differ from DCS systems direct
control systems mostly by the way in which

73
00:06:11,000 --> 00:06:15,959
the communications is arranged, and dcs
is are usually on site with the actual

74
00:06:16,000 --> 00:06:19,839
field equipment, like at a compressor
station or something like that, whereas a

75
00:06:19,879 --> 00:06:26,199
skater system is meant to control the
entire pipeline, and we'll often interface with

76
00:06:26,319 --> 00:06:30,240
the DCS systems, you know,
in the form of talking to the PLC

77
00:06:30,600 --> 00:06:33,439
and so on directly. So yeah, so a skater system primarily, but

78
00:06:33,759 --> 00:06:39,000
for us, it's the platform on
top of which we layer other pipeline specific

79
00:06:39,120 --> 00:06:46,439
applications. So just a little side
note there to give you some insight into

80
00:06:46,480 --> 00:06:54,240
the industry. Ate in my recollection, it was Valmet created Oasis, and

81
00:06:54,319 --> 00:07:01,319
then Telvent a conglomerate bot Valvement,
and then later on Schneider Electric bought tel

82
00:07:01,399 --> 00:07:08,199
Vend and then you know, as
Jake Relates uh spun off you know,

83
00:07:08,319 --> 00:07:15,279
or sold off their software businesses to
Aviva. So this product went to Aviva,

84
00:07:16,360 --> 00:07:24,199
and very recently Schneider Electric bought Aviva
back. So the product line has

85
00:07:24,279 --> 00:07:28,240
has bounced into an out of Schneider
Electric for a while. There's Schneider Electric

86
00:07:28,360 --> 00:07:32,360
is is a behemoth. They've they've
purchased a lot of stuff, including Aviva

87
00:07:32,399 --> 00:07:38,639
recently. You know, it's a
it's a truism of the industry that the

88
00:07:38,879 --> 00:07:42,079
the industry is very fragmented there are
you know, you ask, what is

89
00:07:42,199 --> 00:07:47,360
what's the world's most best known I
don't know relational database. Well it probably

90
00:07:47,399 --> 00:07:50,879
Oracle, maybe SQL server, you
know, maybe my sequel, which is

91
00:07:50,959 --> 00:07:55,519
the free one that everyone uses under
the hood of of you know big web

92
00:07:55,560 --> 00:07:58,639
applications. Three of them. That's
it. That's those those are sort of

93
00:07:58,680 --> 00:08:01,439
your choices. Yeah. Yeah,
there's other databases in the world, but

94
00:08:01,519 --> 00:08:03,839
none of them have the market share
that those three do. What's the top

95
00:08:05,399 --> 00:08:11,800
industrial control system in the world.
Don't know, highly fragmented market. Really

96
00:08:11,920 --> 00:08:16,439
don't know what's the top. But
you know, nowadays, because Schneider Electric

97
00:08:16,480 --> 00:08:22,199
has bought so many other businesses,
nobody knows what is the world's most popular

98
00:08:22,279 --> 00:08:26,839
industrial control system. But we know
that whatever it is, Schneider Electric probably

99
00:08:26,920 --> 00:08:31,159
owns it. So that's that's the
world we live in. Thanks for the

100
00:08:31,240 --> 00:08:35,039
intro. I've as I said,
I'm here in the same city. I've

101
00:08:35,039 --> 00:08:37,519
been watching you folks for some time. I know you. I know you

102
00:08:37,600 --> 00:08:43,519
know telvend and Oasis and now a
Viva and Enterprise Skata. I know you

103
00:08:43,639 --> 00:08:48,399
folks as pioneers in this space.
I know you've been doing this this cybersecurity,

104
00:08:48,600 --> 00:08:50,519
you know, in the product space
for a very long time. You

105
00:08:50,559 --> 00:08:54,480
know, I see you as leaders
in the space from the very beginning,

106
00:08:54,759 --> 00:08:58,639
Can you talk about I don't know
if you want to go into the history,

107
00:08:58,679 --> 00:09:01,360
but can you talk about the big
what are you doing with you know,

108
00:09:01,559 --> 00:09:05,240
cybersecurity in your in your product line
right now? What approach are you

109
00:09:05,360 --> 00:09:11,879
taking to that? Yeah, great
question. Our approach is for sure not

110
00:09:13,080 --> 00:09:16,919
one of complacence. You know,
we we became you know, I mentioned

111
00:09:16,960 --> 00:09:22,879
that my started back in the Unix
versions. So when the big big switch

112
00:09:22,960 --> 00:09:26,879
in the early nineties came where we
went from Unix to NT, we did

113
00:09:26,919 --> 00:09:30,440
it for many reasons, not least
of which were the fact that it was

114
00:09:30,519 --> 00:09:37,279
now just a single operating system to
support the Unix flavors back then were different

115
00:09:37,440 --> 00:09:41,159
enough that you know, it really
posed some problems for us, but also

116
00:09:41,279 --> 00:09:46,759
also the switch to NT, which
was controversial back in the early nineties.

117
00:09:46,879 --> 00:09:50,679
But we did it so that we
could leverage active directory, curb barols,

118
00:09:50,679 --> 00:09:56,639
authentication, and and other parts that
the operating system would bring to bear for

119
00:09:56,840 --> 00:10:01,519
us, so that we didn't have
to and that has proved very smart in

120
00:10:01,679 --> 00:10:09,639
hindsight. When we first started deploying
NT systems with active directory, fully admit,

121
00:10:09,679 --> 00:10:13,360
I don't think we did it right
the first time, but we we

122
00:10:13,720 --> 00:10:18,159
you know, learned more about active
directory and started to use ATOM, the

123
00:10:18,480 --> 00:10:22,240
Lightweight Directory Service or a d l
DS that goes on top of active directory,

124
00:10:22,240 --> 00:10:28,840
and that really helped our PSR our
performance, stability and reliability. But

125
00:10:30,039 --> 00:10:31,759
you know, prior to that,
the security mindset at the time, I

126
00:10:31,840 --> 00:10:37,080
think in the in our company and
throughout the industry, even myself, was

127
00:10:37,320 --> 00:10:41,120
you know, mostly security through obscurity. No one thought that a Unix server

128
00:10:41,399 --> 00:10:46,919
behind locked doors and air gap for
the Internet was a risk. And you

129
00:10:46,000 --> 00:10:52,080
know, ironically today that actually might
be true. Some old legacy Unich system

130
00:10:52,120 --> 00:10:56,080
behind locked doors air gap from the
Internet probably isn't really a risk anymore,

131
00:10:56,120 --> 00:11:00,080
except it is, and I probably
shouldn't have said that. But we we

132
00:11:00,200 --> 00:11:03,240
now have a very robust security model
that was ahead of its time back then,

133
00:11:03,919 --> 00:11:09,759
but now is becoming the emerging standard
in the ICs space. I've attended

134
00:11:09,799 --> 00:11:16,120
a couple of Department of Homeland security
working groups where they're looking at you know,

135
00:11:18,000 --> 00:11:22,519
formalizing I guess or formalizing might not
be the quite right word, but

136
00:11:22,559 --> 00:11:26,879
they're essentially centralizing what would be the
best practice for a topology and network topology.

137
00:11:26,960 --> 00:11:30,519
And and it only took a couple
of those sessions for me to realize

138
00:11:30,559 --> 00:11:33,360
that, oh, they're kind of
catching up to where we've been for several

139
00:11:33,440 --> 00:11:37,399
years now. So we follow the
Purdue model, you know, segmentation,

140
00:11:37,639 --> 00:11:41,639
network segmentation, and you know,
and you know, I could go on

141
00:11:41,720 --> 00:11:46,440
and on about what our security model
is, but our approach to security in

142
00:11:46,519 --> 00:11:50,799
Aviva is interesting, I think.
So as a product manager, I get

143
00:11:50,919 --> 00:11:54,240
to decide what R and D does. Right, We have a fixed capacity

144
00:11:56,159 --> 00:12:00,360
in terms of hours of development time
we can do per year, and at

145
00:12:00,519 --> 00:12:03,240
this time of year, frankly,
here in November, we're looking at how

146
00:12:03,320 --> 00:12:07,600
to spend it next year. One
thing that I actually don't have much say

147
00:12:07,679 --> 00:12:13,840
over is security. That capacity is
sliced away from me, and it is

148
00:12:13,000 --> 00:12:20,440
managed by a dedicated security team in
Aviva who are constantly looking at the security

149
00:12:20,519 --> 00:12:26,919
industry and the security landscape and are
finding things to do and prioritizing them according

150
00:12:26,960 --> 00:12:33,000
to a standardized score, and they
decide what the R and D is going

151
00:12:33,080 --> 00:12:39,600
to do with that percentage of the
capacity. Then at the end of the

152
00:12:39,840 --> 00:12:43,360
release cycle, when we're getting to
release again, the security mindset in Aviva

153
00:12:43,480 --> 00:12:50,960
is so prevalent that they actually have
released veto Power on my product. So

154
00:12:50,159 --> 00:12:56,320
if we don't meet the right security
progressive so if we don't meet the right

155
00:12:56,840 --> 00:13:01,559
security score, or if we haven't
made sufficient progress, or if our internal

156
00:13:01,720 --> 00:13:07,240
code scanning tools reveal a vulnerability that
scores high enough, that's it. The

157
00:13:07,360 --> 00:13:11,759
release is on hold until those things
are resolved. And it is one area

158
00:13:11,840 --> 00:13:15,639
where you know, there's always a
little bit of give and take between the

159
00:13:15,720 --> 00:13:18,799
business and R and D in terms
of balancing priorities and capacities and pressures.

160
00:13:20,080 --> 00:13:22,679
But this is one that is not
off a debate, and I'm very happy

161
00:13:22,840 --> 00:13:28,840
to have experts that are, you
know, full time watching the the industry

162
00:13:28,919 --> 00:13:33,000
and making sure that the product is
as secure as it can be. I'm

163
00:13:33,679 --> 00:13:39,399
you know, without trying to sound
too immodest, my product moves a lot

164
00:13:39,480 --> 00:13:43,799
of petroleum in the world, and
it you know, I go to bed

165
00:13:43,039 --> 00:13:46,679
with the surety that my product is
not going to end up on the front

166
00:13:46,720 --> 00:13:50,759
page of the newspaper in the following
day. And I take that very seriously,

167
00:13:50,840 --> 00:13:54,200
and we all do as well.
It's a concerted effort the product group.

168
00:13:54,759 --> 00:13:58,039
Obviously, when we put out our
release, we package up our MSIs

169
00:13:58,519 --> 00:14:03,720
and we're on But then that's the
beginning of how our develop sorry, our

170
00:14:03,840 --> 00:14:07,399
delivery group what they take it from
there, and they deploy it in a

171
00:14:07,480 --> 00:14:13,399
secure way, a secure process so
that there's no chance of supply chain infiltration.

172
00:14:13,480 --> 00:14:18,279
And then the last layers of security
are the customers. And I think

173
00:14:18,399 --> 00:14:22,279
this podcast is probably delved into that
topic many times around the people, processes

174
00:14:22,360 --> 00:14:28,360
and procedures that customers need to do
to secure their system. You know,

175
00:14:28,440 --> 00:14:31,399
I like to say that the system
is only as secure as the last person

176
00:14:31,440 --> 00:14:37,320
who touched it, and so it
has to be a comprehensive and holistic approach

177
00:14:37,759 --> 00:14:41,120
otherwise, you know, otherwise the
cracks will form and then it's game over.

178
00:14:45,200 --> 00:14:48,559
Andrew, I maybe I'm just making
an obvious assumption here. I would

179
00:14:50,200 --> 00:14:54,960
have assumed that in the kind of
case that we're talking about here, management

180
00:14:54,320 --> 00:14:58,840
tends to run the show. But
it sounds to me, based on what

181
00:15:00,080 --> 00:15:05,240
Jake is saying, that the developers
have a lot more say in control in

182
00:15:05,279 --> 00:15:09,679
this process. That is true,
and it's it's not that unusual. I

183
00:15:09,720 --> 00:15:16,360
mean, I've only worked in a
handful of businesses in my career doing product

184
00:15:16,399 --> 00:15:20,840
development, but where I've worked and
a lot of this was sort of pre

185
00:15:22,440 --> 00:15:26,039
cybersecurity. I'm thinking way back to
the early nineteen nineties. You know,

186
00:15:26,120 --> 00:15:31,840
when I joined Hewlett Packard pre security. You know, security wasn't the thing

187
00:15:31,960 --> 00:15:35,320
back then, but quality was huge
because we were producing control systems. And

188
00:15:37,080 --> 00:15:39,879
you know, in Jake's case,
the control system is controlling natural gas pipelines

189
00:15:39,919 --> 00:15:43,799
and other infrastructure. In our case
it was oil pipelines and power grids.

190
00:15:45,519 --> 00:15:50,559
And you know, when we're developing
the control system, we're developing new features.

191
00:15:50,600 --> 00:15:56,080
We're adding tens hundreds, sometimes of
thousands of lines of new code into

192
00:15:56,120 --> 00:16:00,639
the product every release. Well,
I'm sorry, people are huge. They

193
00:16:00,720 --> 00:16:03,519
make mistakes. If you've added one
hundred thousand lines of code, you've probably

194
00:16:03,639 --> 00:16:08,440
added you know, five hundred or
one thousand defects into the product as well,

195
00:16:10,039 --> 00:16:12,440
and now you've got to go through
and painfully clean them all out.

196
00:16:14,600 --> 00:16:19,200
And so we had a quality decision
making process that sounded analogous to what Jake

197
00:16:19,320 --> 00:16:25,200
is talking about on the cybersecurity side. Yeah, the management team set the

198
00:16:25,240 --> 00:16:29,840
goal it has to be, you
know, this level of quality so that

199
00:16:30,000 --> 00:16:33,080
we're not embarrassed when we release it, so that our customers don't you know,

200
00:16:33,600 --> 00:16:37,600
scream blue murder because their control system
is falling over dead every ten minutes.

201
00:16:38,799 --> 00:16:41,480
And then it was up to the
end. But you know, the

202
00:16:41,559 --> 00:16:45,080
managers did not They weren't face down
into the code all day long. The

203
00:16:45,159 --> 00:16:49,440
engineers were, the software developers were, and you know, we were the

204
00:16:49,559 --> 00:16:53,200
ones that had to say, okay, there's the bar that's been set for

205
00:16:53,320 --> 00:16:56,679
quality. Have we met that bar
yet? And if we came back and

206
00:16:56,720 --> 00:17:00,200
said no, we're not there yet, didn't matter if we were late,

207
00:17:00,320 --> 00:17:04,160
it didn't matter how much the manager
screamed. They were not going to overrule

208
00:17:04,279 --> 00:17:08,519
us because they knew that if they
released, if they overruled us, the

209
00:17:08,640 --> 00:17:11,880
business would be majorly embarrassed. Their
next would be on the line. And

210
00:17:12,000 --> 00:17:15,319
so yeah, the people who are
close to the problem, you know,

211
00:17:15,599 --> 00:17:21,799
very technically, staring at the security
holes, staring at the quality defects,

212
00:17:22,240 --> 00:17:26,680
they're the ones, you know,
that have to assess whether you've met the

213
00:17:26,319 --> 00:17:30,839
standard, you know, the requirement. Management can set the requirement, but

214
00:17:32,200 --> 00:17:37,079
they generally don't want to vary that
for schedule reasons because they're going to be

215
00:17:37,119 --> 00:17:38,960
majorly embarrassed. So this is not
that unusual. It's you know, it

216
00:17:40,039 --> 00:17:45,319
sort of jives with my own experience
in the space. A lot of people

217
00:17:45,720 --> 00:17:49,000
in the supply chain world, you
know, NERKSIP has standards saying are your

218
00:17:49,119 --> 00:17:56,000
suppliers trustworthy? Did you buy software
or hardware components from untrustworthy suppliers who might

219
00:17:56,039 --> 00:18:00,400
have embedded a backdoor? That's not
what you mentioned, you know, lots

220
00:18:00,440 --> 00:18:03,599
of other people are talking about.
Well, I embedded a library from a

221
00:18:03,640 --> 00:18:10,480
trustworthy supplier in my product a year
ago and released the product, and today

222
00:18:11,200 --> 00:18:15,039
the vendor of that library has announced
a vulnerability. Can I track that?

223
00:18:15,279 --> 00:18:18,000
How do I get that out?
That's another thing, you know, that's

224
00:18:18,000 --> 00:18:22,079
sort of the s bomb topic,
the software bill of materials topic that everyone's

225
00:18:22,119 --> 00:18:26,400
talking about. Nobody is talking about
what I see as the biggest problem,

226
00:18:26,440 --> 00:18:30,440
which is the solar wind scenario,
which is the bad guys get into your

227
00:18:30,519 --> 00:18:37,720
system and tamper with the product under
development. Yet that's the first thing you

228
00:18:37,880 --> 00:18:42,119
mentioned, So I'm a little surprised. Can you go deeper on what you're

229
00:18:42,200 --> 00:18:48,200
doing on supply chain and especially this
the last element, how you you know,

230
00:18:48,359 --> 00:18:53,200
sort of secure your development process?
Yeah, yeah, supply chain it

231
00:18:53,359 --> 00:18:56,319
can mean I think a lot of
different things, So to take those in

232
00:18:56,880 --> 00:19:04,119
random order as part of of our
FSR Final Security Final Security Review. There

233
00:19:04,200 --> 00:19:10,079
are a number of scans that get
run against the codebase. One of them

234
00:19:10,400 --> 00:19:17,160
is a third party library and open
source attribution checks. So the open source

235
00:19:17,200 --> 00:19:22,359
attribution checks are interesting because when I
first learned about them, it included things

236
00:19:22,400 --> 00:19:26,640
that I hadn't thought about. For
example, we don't like to use open

237
00:19:26,680 --> 00:19:33,279
source projects that aren't actively under development, so no abandon where Obviously we have

238
00:19:33,400 --> 00:19:36,680
to attribute the open source licenses and
our product, which we also do and

239
00:19:36,759 --> 00:19:38,960
we know where they all are.
But I thought that was interesting too that

240
00:19:40,160 --> 00:19:44,839
only open source that are under active
development, and then of course that code

241
00:19:44,880 --> 00:19:49,039
gets scanned with our tools as well. The third party libraries is another thing

242
00:19:49,240 --> 00:19:56,799
that is in the FSR process,
and we have a hard rule that says

243
00:19:56,880 --> 00:20:02,160
that third party libraries have to remain
current and for exactly the reasons that you

244
00:20:02,279 --> 00:20:06,240
mentioned. We have quite a few
third party libraries in our product, and

245
00:20:06,519 --> 00:20:10,839
if any vulnerability is found, it
is up. We have an obligation to

246
00:20:10,960 --> 00:20:15,799
our customers to take the updated third
party library and spin it into a service

247
00:20:15,880 --> 00:20:19,279
pack, well, bring it into
the next service pack, and those rules

248
00:20:19,319 --> 00:20:23,200
manifest for us in this way,
which is that if you have third party

249
00:20:23,279 --> 00:20:29,240
libraries that are not current. You
have to update them when you release your

250
00:20:29,240 --> 00:20:33,000
service pack. It's a non negotiable. Then. The last part of this

251
00:20:33,160 --> 00:20:37,680
then is really I think driven by
some of our customers who maybe have some

252
00:20:37,839 --> 00:20:44,559
of the NERKSIP sensitivities, because not
all of our customers do. And this

253
00:20:44,759 --> 00:20:48,240
is you know, some people call
it the double glove. Essentially, it's

254
00:20:48,279 --> 00:20:52,599
how do I trust that the software, the MSI package, the ZIP file,

255
00:20:52,680 --> 00:20:56,759
the VM image, whatever, how
do I trust that I can accept

256
00:20:56,839 --> 00:21:00,920
that into my secure clean zone if
you will, I'm now the customer.

257
00:21:02,759 --> 00:21:07,119
And because that's like a major vector
for infection, right, is that I'm

258
00:21:07,200 --> 00:21:11,440
now accepting some large piece of binary
software through all of my firewalls and so

259
00:21:11,559 --> 00:21:17,160
on. So some customers have taken
an extreme approach where they don't want to

260
00:21:17,240 --> 00:21:22,240
accept our vms and they don't want
us to build their vms. So this

261
00:21:22,319 --> 00:21:25,839
is where the double glove approach comes
in, where instead of our project team

262
00:21:25,920 --> 00:21:29,000
building vms, which is normal,
you know, previously to this, we

263
00:21:29,119 --> 00:21:33,640
used to bring hardware to our office
here in Calgary, stage the customer's hardware,

264
00:21:34,119 --> 00:21:37,319
put this, put the bespoke software
on it, tear it all down

265
00:21:37,400 --> 00:21:41,720
after fat ship at the site and
reassemble it. With the advent of virtue

266
00:21:41,759 --> 00:21:47,279
machines, that's basically gone completely by
the wayside, and we're in that.

267
00:21:47,400 --> 00:21:52,279
We regularly move VM images around,
but some customers are saying, no,

268
00:21:52,720 --> 00:21:56,200
we would rather that VM image be
built from the ground up here in our

269
00:21:56,240 --> 00:22:02,119
clean room, and we'd actually don't
want you touching it at all. So

270
00:22:02,240 --> 00:22:06,000
the double glove becomes you know,
gloves behind glass, if you will,

271
00:22:06,319 --> 00:22:10,519
where we sit there and watch the
customer and instruct and mentor them and say,

272
00:22:10,599 --> 00:22:14,279
you know, step them through the
installation process that we would normally provide.

273
00:22:15,079 --> 00:22:18,039
That's an extreme example. There was
one customer that went even more extreme

274
00:22:18,119 --> 00:22:22,000
to the point where we were sitting
around with our lawyers scratching our heads like,

275
00:22:22,039 --> 00:22:26,000
I'm not actually sure how we will
ever get any software to you because

276
00:22:26,039 --> 00:22:33,519
you've kind of closed every potential way
in which we could deliver software to you.

277
00:22:33,640 --> 00:22:36,720
I'm not quite sure how you would
ever take it. So that was

278
00:22:36,799 --> 00:22:41,319
an interesting negotiation as well. But
yeah, it's an interesting concept in terms

279
00:22:41,319 --> 00:22:47,200
of how to protect our code base. Obviously, we have code reviews so

280
00:22:47,519 --> 00:22:51,000
with pool requests and so on,
so they would have to they would have

281
00:22:51,119 --> 00:22:56,839
to infiltrate you know, identity hack
or something. Our developer, so Viva.

282
00:22:56,960 --> 00:23:03,440
It has locked our environments down very
very hard. We have multi factor

283
00:23:03,480 --> 00:23:08,839
authentication for everything that we do.
Some things are also behind VPNs as well.

284
00:23:10,599 --> 00:23:14,599
You know, we take that very
very seriously obviously, because if we

285
00:23:14,720 --> 00:23:18,720
were to have been breached, then
you know, it puts a lot of

286
00:23:18,640 --> 00:23:22,119
I don't even want it. I'm
coming out in hives just thinking about it,

287
00:23:22,680 --> 00:23:25,519
but we would have a we have
an instant in response that would kick

288
00:23:25,599 --> 00:23:29,680
in at that point. We've I
think we've only had to do it once

289
00:23:30,279 --> 00:23:33,680
and it was a it was a
it ended up being nothing, but it

290
00:23:34,119 --> 00:23:37,240
boy, it was. It was
a panic. That was quite a few

291
00:23:37,319 --> 00:23:41,200
years ago now though I want to
assure your listeners that it was a bit

292
00:23:41,240 --> 00:23:45,160
of a false alarm. But since
then, you know, we we'd take

293
00:23:45,240 --> 00:23:49,720
that very seriously. H and we
have regularly responded to the S bomb kind

294
00:23:49,759 --> 00:23:53,799
of questions in RFPs and with customers. We have a very open relationship with

295
00:23:53,880 --> 00:23:59,079
our customers with regards to security.
So if they do a penetration test,

296
00:23:59,119 --> 00:24:02,240
they want to know that we are, you know, going to be interested

297
00:24:02,279 --> 00:24:04,960
in their results. And of course
we are happy to say that the penetration

298
00:24:06,119 --> 00:24:10,440
tests that our customers are performing are
not turning up anything, or if they're

299
00:24:10,519 --> 00:24:12,000
they're turning up some minor things that
we're like, yep, that's safe to

300
00:24:12,079 --> 00:24:15,279
ignore. That's that's reasons that you
Yep, you can turn that off,

301
00:24:15,359 --> 00:24:18,039
that kind of thing. And so, like I said at the very beginning,

302
00:24:18,240 --> 00:24:23,400
it's a constant evolutionary process here where
every time we put out a release,

303
00:24:23,440 --> 00:24:27,960
we're always updating our GPOs from the
Center of Internet Security and so on.

304
00:24:29,119 --> 00:24:33,319
But I think I'm now straying off
the topic of the of the supply

305
00:24:33,440 --> 00:24:37,160
chain question. So yeah, suffice
to say, it starts like I said,

306
00:24:37,160 --> 00:24:40,480
it starts from the bottom layer,
how we manage our code, how

307
00:24:40,519 --> 00:24:42,960
we access our code, how we
accept changes, all the way to how

308
00:24:44,039 --> 00:24:48,480
we actually get binaries to cite for
the customer. And this is just the

309
00:24:48,559 --> 00:24:52,960
Aviva on prem experience, right.
The cloud is a is a different beast

310
00:24:52,359 --> 00:25:00,000
and it but it has the same
kind of security oversight and more because because

311
00:25:00,039 --> 00:25:07,160
of the nature of cloud. The
point that you made in your question there

312
00:25:07,319 --> 00:25:10,799
and then Jake's response are kind of
interesting. I mean, the subject of

313
00:25:11,039 --> 00:25:17,119
supply chain security is not new to
our podcast. If I recall in Not

314
00:25:17,359 --> 00:25:19,799
So Far Away episodes, we've been
talking about s bomb a few times.

315
00:25:21,839 --> 00:25:27,039
S bomb is just a way to
account for what the heck kind of software

316
00:25:27,079 --> 00:25:30,319
you're dealing with. And it seems
like the point that Jake was making there,

317
00:25:30,400 --> 00:25:37,039
among among others, is that maybe
beyond just knowing what's in your product,

318
00:25:37,039 --> 00:25:42,640
using only the kinds of software that
you can hold to account that's continuously

319
00:25:42,720 --> 00:25:47,880
updated, so that you know that
all the components of your product are ultimately

320
00:25:48,160 --> 00:25:53,759
just as securable and enforceable as all
the others. Yes, the the the

321
00:25:53,880 --> 00:26:00,160
thing is that you know, in
my recollection supply chain is is like four

322
00:26:00,200 --> 00:26:03,839
different things. Three of them in
a sense are verifiable. The vendor can

323
00:26:04,000 --> 00:26:07,240
prove to the customer that they've done
it right, and the fourth one is

324
00:26:07,400 --> 00:26:11,440
just hard. You know, the
three that are verifiable are you know things

325
00:26:11,559 --> 00:26:18,440
like did you buy your components hardware
and software from trustworthy sources or you know,

326
00:26:18,799 --> 00:26:22,359
did you buy them from band sources? Well, you can look at

327
00:26:22,400 --> 00:26:26,160
the components, you can see the
labels on them, you can look at

328
00:26:26,200 --> 00:26:27,880
your contracts, you can you know, in the worst case, bring a

329
00:26:27,920 --> 00:26:33,599
lawyer into review the contracts under non
disclosure and prove that you purchase your stuff

330
00:26:33,640 --> 00:26:38,640
from you know, trustworthy sources.
Another sort of gotcha is did you buy

331
00:26:38,880 --> 00:26:44,240
you know, even if you the
stuff was manufactured by somebody trustworthy, did

332
00:26:44,279 --> 00:26:48,240
you buy it from an intermediary who
is criminal, who is you know,

333
00:26:48,720 --> 00:26:52,440
taking some of the profits and funding
terrorism or something horrible like this? And

334
00:26:52,519 --> 00:26:56,480
again, you know you can prove
with your contracts and with your paper trail

335
00:26:56,559 --> 00:27:00,880
that you haven't done this. The
third one is you're your your you know,

336
00:27:00,920 --> 00:27:03,440
are there vulnerabilities in the libraries that
you've used? And there are tools

337
00:27:03,480 --> 00:27:07,079
that can scan the product that can
figure out which libraries you've used and which

338
00:27:07,200 --> 00:27:12,240
versions. They can verify the customer
can verify that you know what you've advertised

339
00:27:12,240 --> 00:27:15,519
in terms of your libraries and versions
are the ones that are in the product,

340
00:27:15,839 --> 00:27:19,880
can go and look to the cve
the vulnerability database and prove to themselves

341
00:27:19,960 --> 00:27:23,480
that none of these libraries have known
vulnerabilities. You can prove all of this.

342
00:27:25,400 --> 00:27:27,440
The thing that you can't prove is
what I asked about, which is

343
00:27:30,759 --> 00:27:33,200
uh and in a sense was Jake's
first answer, that the thing that you

344
00:27:33,759 --> 00:27:37,799
can't prove is that you know,
the bad guys haven't snuck a sleeper,

345
00:27:38,039 --> 00:27:45,359
a terrorist or you know, a
spy into your development organization who is inserting

346
00:27:45,440 --> 00:27:49,119
malware into the product as one of
the developers, you know, how do

347
00:27:49,200 --> 00:27:55,000
you prove that hasn't happened. That's
really hard and you know what you have

348
00:27:55,200 --> 00:27:59,960
to do to deal with that risk. You just have to be really paranoi

349
00:28:00,240 --> 00:28:03,000
from one end of your development process
to the other. It's just it's just

350
00:28:03,200 --> 00:28:08,559
hard. And yet that's exactly the
behavior. That's exactly the attitude that Jake

351
00:28:08,599 --> 00:28:11,599
has described here. So you know, these folks have been doing this for

352
00:28:11,680 --> 00:28:15,200
a long time. You know,
they've wrapped their heads around the degree of

353
00:28:15,319 --> 00:28:19,839
paranoia you need in your development process
to assure that you know with a high

354
00:28:19,880 --> 00:28:23,880
degree of confidence that the bad guys
aren't sneaking something in under the hood,

355
00:28:25,240 --> 00:28:29,559
so you know, good on them. So that's a lot. I mean,

356
00:28:29,599 --> 00:28:33,559
it's you know, reassuring to hear
a vendor with with you know,

357
00:28:33,680 --> 00:28:38,559
such a what's the right word,
A broad approach to cybersecurity and the product.

358
00:28:41,319 --> 00:28:45,680
You know, we're again, you're
the leading provider for at least natural

359
00:28:45,759 --> 00:28:52,319
gas pipeline control systems and you know, active in lots of other space.

360
00:28:52,519 --> 00:28:55,759
But when we talk, when we
say the word pipeline, you know,

361
00:28:55,839 --> 00:28:57,920
the elephant in the room is the
Colonial incident. Do you want to talk

362
00:28:57,920 --> 00:29:02,880
about that? What was sort of
the the consequences of that of that incident

363
00:29:03,039 --> 00:29:07,559
for for Aviva and for the whole
industry. Yeah, you know, we

364
00:29:07,720 --> 00:29:11,920
had the skated director from Colonial join
us on stage at our recent pipeline summit

365
00:29:12,000 --> 00:29:18,319
here in Calgary. I hosted a
cybersecurity panel and it was the second time

366
00:29:18,400 --> 00:29:22,480
we had done it. And uh, mister Warrenburger from Colonial, he he

367
00:29:22,559 --> 00:29:27,279
had joined me previously last year in
San Francisco at the Aviva World Conference and

368
00:29:27,400 --> 00:29:33,440
for the same thing, a cybersecurity
panel for our midstream user group, you

369
00:29:33,519 --> 00:29:36,279
know, and when he when he
agreed to volunteer for that panel, the

370
00:29:36,319 --> 00:29:38,559
first question I asked him is,
oh, are you sure? Do you

371
00:29:38,680 --> 00:29:41,839
want to get up in front of
everybody? And he's one hundred percent.

372
00:29:41,920 --> 00:29:45,519
And the first thing he says is, We're sorry, but you're also welcome.

373
00:29:47,359 --> 00:29:51,480
You know, we we kind of
forced us all to become secure and

374
00:29:51,720 --> 00:29:55,200
and you should you should be taking
this seriously, and of course we all

375
00:29:55,279 --> 00:29:57,960
are. I don't know you know, and of course you know, this

376
00:29:59,160 --> 00:30:00,880
limits to what I can talk about, and there's limits to what I know

377
00:30:02,119 --> 00:30:07,079
about what happened at Colonial, But
our understanding is that the enterprise gated system

378
00:30:07,160 --> 00:30:11,279
wasn't compromised and that the shutdown of
the pipe was due to an abundance of

379
00:30:11,319 --> 00:30:17,400
caution. You know, our system
being air gap from the corporate network and

380
00:30:17,480 --> 00:30:22,599
designed to operate independently, and everything
is all well and good until your entire

381
00:30:22,720 --> 00:30:27,680
business operations depend on applications that are
not in the control room and cannot be

382
00:30:27,759 --> 00:30:33,680
air gapped. So so that's you
know, that's an interesting thing that the

383
00:30:33,759 --> 00:30:40,279
industry is grappling with right now is
how to how to survive an ongoing cyber

384
00:30:40,400 --> 00:30:45,359
incident and not be fine for shutting
down, which was sort of the Colonial

385
00:30:45,440 --> 00:30:51,000
takeaway that surprised me. So that's
very interesting is how resilient do we need

386
00:30:51,079 --> 00:30:55,920
to be? How how does your
disaster recovery or business continuity which is slightly

387
00:30:55,960 --> 00:31:02,039
different, how does your business continuity
now change given the idea that maybe you

388
00:31:02,160 --> 00:31:04,279
can't you can't shut down now.
Colonial may have been able to go to

389
00:31:04,359 --> 00:31:07,839
manual operations, but some of our
larger customers there there just might not be

390
00:31:08,000 --> 00:31:14,559
enough people to send out to the
field to operate manually right and in fact,

391
00:31:14,839 --> 00:31:17,680
do you even have h a you
know, when was the last time

392
00:31:17,720 --> 00:31:22,799
you tested your manual operation procedure?
So so these are these are some of

393
00:31:22,880 --> 00:31:26,359
the interesting lessons learned. And like
I said, you know, being very

394
00:31:26,400 --> 00:31:33,240
transparent about this and and the corrective
actions that we're making. It's it's extremely

395
00:31:33,279 --> 00:31:36,680
important for the industry to to share
this kind of knowledge back and forth.

396
00:31:37,720 --> 00:31:41,319
So so as a result, the
TSA rule came out that had a bunch

397
00:31:41,359 --> 00:31:45,240
of guidelines and so on, and
and what we were uh so we struck

398
00:31:45,279 --> 00:31:49,279
a team, struck a little committee
that met daily to discuss the progression of

399
00:31:49,359 --> 00:31:53,880
these rules and to understand how are
our customers are going to be impacted.

400
00:31:55,319 --> 00:32:00,559
Happy to report that because of our
topology deposit, because of our design and

401
00:32:00,680 --> 00:32:04,359
our approach that I've detailed already,
our customers didn't have to do much.

402
00:32:06,160 --> 00:32:08,559
One thing that they did have to
do was to cycle their system passwords,

403
00:32:08,599 --> 00:32:15,359
which for the older versions of our
product was a little bit labor intensive perhaps

404
00:32:15,400 --> 00:32:22,240
and a little bit risky. But
our but our technical support team was able

405
00:32:22,319 --> 00:32:28,960
to to work with our customers to
get those passwords rotated without causing downtime.

406
00:32:29,839 --> 00:32:34,119
The later versions of our product we
leveraged group Managed Service Accounts, which is

407
00:32:34,160 --> 00:32:42,200
an active directory Microsoft Windows feature that
rotates these system passwords automatically for you.

408
00:32:43,240 --> 00:32:47,680
So so going forward again, our
customers have to do nothing there to comply

409
00:32:47,839 --> 00:32:53,720
with that rule. However, one
other major change for me that affected me

410
00:32:53,759 --> 00:33:00,519
as product manager here was was the
how our products interacted with the various third

411
00:33:00,599 --> 00:33:07,160
party security tools. So previously we
had been quite prescriptive. It's a long

412
00:33:07,240 --> 00:33:12,559
story, but we had got into
the situation where we were uh in testing,

413
00:33:12,759 --> 00:33:20,599
integrating, and certifying one third party
security tool, and overwhelmingly our customers

414
00:33:20,880 --> 00:33:23,359
said that, well, we don't
want to use that tool because our IT

415
00:33:23,680 --> 00:33:28,039
department is forcing us to use this
other tool. And so just a note

416
00:33:28,079 --> 00:33:30,839
on that IT OT convergence. Sometimes
it's a swear word, sometimes it's the

417
00:33:30,880 --> 00:33:35,160
answer to your problem. In this
case, you know, the guidance that

418
00:33:35,200 --> 00:33:38,640
we've been giving here is don't fight
your IT department when picking a security tool.

419
00:33:38,720 --> 00:33:44,119
You have to work with them because
ultimately you need a holistic response to

420
00:33:44,880 --> 00:33:49,640
the to the entire operations of your
business, which includes IT and OT so

421
00:33:50,200 --> 00:33:55,000
it is in your best interest to
have an overarching response to this. It

422
00:33:55,039 --> 00:33:58,960
doesn't have to be a single tool. You don't want to violate any you

423
00:33:59,039 --> 00:34:02,880
know, any network security rules or
guidelines or best practices. But to have

424
00:34:04,559 --> 00:34:07,960
a common response and perhaps a common
tool, if not just a single instance

425
00:34:08,000 --> 00:34:12,960
of that tool, we think is
probably the better way to go. And

426
00:34:13,039 --> 00:34:17,039
so as a result, we announced
that we were not going to be endorsing

427
00:34:17,119 --> 00:34:21,840
any individual tools, nor were we
going to be testing them, because there's

428
00:34:21,840 --> 00:34:25,519
obviously too many and we can't test
them all. So instead we pivoted and

429
00:34:25,639 --> 00:34:30,360
we documented in great detail the elements
of our product that you need to know

430
00:34:30,480 --> 00:34:35,960
about when you're shopping for, configuring, testing, and operating a third party

431
00:34:36,039 --> 00:34:38,840
security tool. So I'm talking anti
virus, I'm talking allow listing, I'm

432
00:34:38,880 --> 00:34:45,199
talking multi factor authentication, I'm talking
host firewalls. So there's several chapters now

433
00:34:45,239 --> 00:34:50,880
in our administration guide that step you
through what you need to know about our

434
00:34:51,000 --> 00:34:55,360
product so that you can pick those
third party tools and then work with your

435
00:34:55,400 --> 00:35:01,480
I T department to consolidate and collect
aborate on on the tools, and then

436
00:35:01,639 --> 00:35:06,920
the overarching processes that you need to
be you know, to be safe and

437
00:35:07,400 --> 00:35:13,400
to sleep well at night. So
Nate, let me add just a bit

438
00:35:13,440 --> 00:35:15,599
of background here. I mean,
back in the in the early days of

439
00:35:15,719 --> 00:35:21,920
industrial cybersecurity, I was working for
a control system vendor, one of Jake's

440
00:35:22,039 --> 00:35:25,800
competitors. But every vendor in the
industry was facing the same problems, the

441
00:35:25,880 --> 00:35:30,679
same demands from customers, the same
sort of changing landscape. You know.

442
00:35:30,960 --> 00:35:36,639
One of the big issues back then
was that the customers were demanding that the

443
00:35:36,800 --> 00:35:44,360
vendors support the customer's anti virus system
of choice, the customer's whitelisting vendor of

444
00:35:44,519 --> 00:35:49,039
choice, the customer's file system change
tracking vendor of choice, the files you

445
00:35:49,079 --> 00:35:52,880
know, the host firewall for whatever
host, uh, the customers wanting the

446
00:35:52,920 --> 00:35:57,719
software on, you know, any
kind of network firewall the customer chose.

447
00:35:57,800 --> 00:36:04,559
Because, of course, you know, enterprise security teams were dictating security choices

448
00:36:04,599 --> 00:36:08,119
company wide, and they would dictate
to the you know, the ot folks,

449
00:36:08,159 --> 00:36:12,199
the engineering teams. You know,
you want to use an antivirus,

450
00:36:12,280 --> 00:36:15,360
you have to use this one.
It's the company standard, which meant that

451
00:36:15,599 --> 00:36:21,119
the control system vendors had to support
everything. You know, back in the

452
00:36:21,199 --> 00:36:23,079
day, the control system vendors were
told you have to support antivirus. So

453
00:36:23,119 --> 00:36:29,719
every one of us picked and one
anti virus vendor, you know, and

454
00:36:29,840 --> 00:36:32,840
you have to support firewalls. So
we picked one firewall vendor, and we

455
00:36:34,119 --> 00:36:40,599
tested our stuff exhaustively against that one
vendor's products, and we documented our stuff

456
00:36:40,920 --> 00:36:45,960
for that one vendors product so that
the customer could get some some security going.

457
00:36:45,960 --> 00:36:49,960
And the customers came back and said, no, we don't want your

458
00:36:50,159 --> 00:36:54,360
vendor. We've already standardized on this
other vendor. But you know, if

459
00:36:55,119 --> 00:37:01,480
the control system vendors, you know, if we had to support everything,

460
00:37:02,000 --> 00:37:06,880
there was enormous costs. I mean, were we supposed to buy one of

461
00:37:06,920 --> 00:37:09,119
each antivirus? I mean buying the
antivirus wasn't the cost. The cost was

462
00:37:09,239 --> 00:37:15,039
testing against all of the anti virus
vendors, all of the antivirus systems,

463
00:37:15,519 --> 00:37:19,880
to make sure that nothing malfunctioned.
You know, there were there were malfunctions.

464
00:37:20,000 --> 00:37:22,239
I mean, if you run a
full anti virus scan, everything slows

465
00:37:22,280 --> 00:37:25,280
down and stops. And you can't
do that with you know, a power

466
00:37:25,320 --> 00:37:30,639
plant or a pipeline. You know, were we supposed to test our stuff

467
00:37:30,719 --> 00:37:37,480
with one of every kind or all
of every kind of control system? Security

468
00:37:37,639 --> 00:37:42,280
potential product on the market, all
the filesystem changed, tracking vendors, all

469
00:37:42,320 --> 00:37:45,079
the white listing vendors, all the
different firewalls, and if we get a

470
00:37:45,119 --> 00:37:49,280
support called what are we supposed to
do? You know, the engineers on

471
00:37:49,360 --> 00:37:54,000
the other end of the line did
not know how to operate the security technology.

472
00:37:54,119 --> 00:38:00,320
Nine times out of ten we had
to teach them how to operate therecurity

473
00:38:00,360 --> 00:38:05,519
stuff because they hadn't taken training.
You know, enterprise firewalls, you might

474
00:38:05,559 --> 00:38:07,119
be used to doing a little bit
of you know if if you have to

475
00:38:07,159 --> 00:38:10,639
do something tricky on your home firewall, well it's got six screens, it's

476
00:38:10,719 --> 00:38:15,599
not that hard. I'm sorry,
enterprise grade firewalls, you need to take

477
00:38:15,719 --> 00:38:20,239
training to figure out how to use
this morass of screens too. So it

478
00:38:20,400 --> 00:38:27,119
was a real problem back then,
and over time, you know, everyone

479
00:38:27,239 --> 00:38:30,519
had to change. The vendors had
to change. Of Viva was one of

480
00:38:30,559 --> 00:38:34,920
the leaders in you know, leading
change in that space. But the customers

481
00:38:34,960 --> 00:38:37,519
had to change. They had to
learn, you know, the enterprise the

482
00:38:37,599 --> 00:38:40,920
engineering teams had to learn that,
they had to take training. You know,

483
00:38:42,159 --> 00:38:45,280
the vendors had to learn that.
We had to support everything, We

484
00:38:45,400 --> 00:38:52,239
had to document everything, so that
you could use the firewall of your choice

485
00:38:52,280 --> 00:38:55,039
because we documented what ports you need. You know, the vendors had to

486
00:38:55,119 --> 00:39:00,559
take training on how to operate their
security gear. They had to take training

487
00:39:00,639 --> 00:39:05,679
on how to test their security gear
so that they didn't call us and say,

488
00:39:05,760 --> 00:39:08,440
oh, your stuff is broken,
when in fact they'd fumble fingered the

489
00:39:08,559 --> 00:39:14,519
firewall configuration. And you know,
all of us had to learn to cut

490
00:39:14,599 --> 00:39:17,400
each other a bit of slack.
You know, if the engineering team had

491
00:39:17,440 --> 00:39:22,840
taken the training and still had a
problem and we had tested the stuff and

492
00:39:22,199 --> 00:39:25,880
our stuff still wasn't working, well, well, you know we had to

493
00:39:25,920 --> 00:39:29,760
come together. So it was.
It was a difficult time. Today,

494
00:39:30,559 --> 00:39:36,840
you know, the leading vendors in
the space support a lot more than they

495
00:39:36,960 --> 00:39:39,280
used to back in the day.
Maybe not everything. Everyone's learned to make

496
00:39:39,320 --> 00:39:45,039
a few compromises, but it was
it was a difficult period for a number

497
00:39:45,079 --> 00:39:51,320
of years as we figured this out. Can I ask you one detail you

498
00:39:51,400 --> 00:39:57,559
haven't haven't really touched on? The
security directors out of the TSA talked about

499
00:39:57,719 --> 00:40:02,559
shared trusts and about documenting these things. You know, in my understanding,

500
00:40:02,639 --> 00:40:07,599
shared trust is code for active directory
on the IT side. In a sense,

501
00:40:07,639 --> 00:40:13,800
you know, controlling or you know, being having the power to create

502
00:40:13,920 --> 00:40:19,320
users and manage permissions on the OT
side, Can you talk about shared trusts

503
00:40:19,360 --> 00:40:22,440
in the enterprise skate of product?
Sure, yeah, we were. I

504
00:40:22,599 --> 00:40:27,960
was really excited personally for the idea
of single sign on from the IT domain

505
00:40:28,239 --> 00:40:35,880
into the OT domain. It seemed
like such an obvious user experience improvement.

506
00:40:37,840 --> 00:40:40,880
But you know, to skip to
the end, I would say that,

507
00:40:42,000 --> 00:40:45,880
you know, trusts between domains is
now not best practice, right, But

508
00:40:45,960 --> 00:40:50,000
if I was to back up a
little bit, you know, using using

509
00:40:50,079 --> 00:40:55,719
active directory has I think we're largely
over it at this point. But when

510
00:40:55,760 --> 00:41:01,519
we first started to deploy active directory, you know, the IT OT relationship

511
00:41:01,599 --> 00:41:06,559
with the customer would really come to
bear. Uh, it's active directory,

512
00:41:06,639 --> 00:41:09,039
therefore it should be in charge of
it, right and in charge of that

513
00:41:09,119 --> 00:41:15,679
domain. Now, I don't want
to start like a debate amongst your listeners,

514
00:41:15,719 --> 00:41:21,320
but you know, there clearly is
ways in which you can bring it

515
00:41:21,719 --> 00:41:24,159
into your OT zone to do this
management. And obviously you know and take

516
00:41:24,159 --> 00:41:27,960
advantage of the fact that they've got
all the extra stuff. They may have

517
00:41:28,079 --> 00:41:30,920
DBAs on stuff and so on,
but you do need to give them that

518
00:41:30,079 --> 00:41:35,760
OT training. They do need to
become aware of the differences between OT and

519
00:41:35,840 --> 00:41:39,679
I. So when we started using
IT systems like Active Directory, you know,

520
00:41:39,760 --> 00:41:46,840
we had to politely but firmly insist
that they do not put our product

521
00:41:46,920 --> 00:41:52,639
into an IT domain. We don't
have that. We don't have that debate

522
00:41:52,679 --> 00:41:55,039
anymore. And now in terms of
you know, and we were also at

523
00:41:55,079 --> 00:41:59,679
the time, you know, really
that many firewalls, that many different domains,

524
00:42:00,320 --> 00:42:02,599
really that seems like overkill. We
we don't. We don't hear that

525
00:42:02,679 --> 00:42:07,320
complaint anymore, you know now that
it's become best practiced, so uh,

526
00:42:07,599 --> 00:42:12,239
you know, trusts were seen as
a great way of giving corporate users access

527
00:42:12,360 --> 00:42:15,039
to the Decision Support System, which
is that read only skater, a system

528
00:42:15,119 --> 00:42:19,760
that sits in the DMZ between O
T and I T. You know,

529
00:42:19,840 --> 00:42:23,960
we thought, and it's still true, that it removes the burden from the

530
00:42:24,000 --> 00:42:29,280
SKATE administrators for things like accounts and
password resets. And then with single sign

531
00:42:29,360 --> 00:42:32,239
on access to the historian in the
d s S, they have access to

532
00:42:32,320 --> 00:42:37,360
all the historical data they could ever
want. However, you know that the

533
00:42:37,559 --> 00:42:40,920
the the user persona of who uses
the d s S is changing, and

534
00:42:40,960 --> 00:42:45,360
I'm happy to talk about that further
if you'd like, and and all.

535
00:42:45,519 --> 00:42:47,360
But but you know, the the
net net of all of this is that

536
00:42:47,679 --> 00:42:52,239
without a trust between your I T
domain and your OT even the OT D

537
00:42:52,400 --> 00:42:55,039
S S domain, there is no
single sign on. So the d S

538
00:42:55,159 --> 00:43:01,440
S now is essentially out of reach
from your your core users outside of you

539
00:43:01,519 --> 00:43:08,679
know, pre defined reports and perhaps
a well other things that we have in

540
00:43:08,760 --> 00:43:13,679
our product, like a remote HMI
that you can peer into it. So,

541
00:43:14,119 --> 00:43:15,840
yeah, the future of the DSS
is is an interesting one as a

542
00:43:15,880 --> 00:43:21,719
result of the security landscape changing.
Just a quick clarification, you've used the

543
00:43:21,719 --> 00:43:24,239
word DSS a number of times.
Decision support system. Is that sort of

544
00:43:25,480 --> 00:43:30,480
the new branding or a superset of
functionality sort of around the historian or is

545
00:43:30,760 --> 00:43:37,840
the historian a different animal than DSS, So certainly a historian would be in

546
00:43:37,000 --> 00:43:44,280
the DSS. The DSS Decision Support
system is a you know, not to

547
00:43:44,360 --> 00:43:47,039
be repetitive, but it is a
system to help people make decisions. So

548
00:43:47,320 --> 00:43:53,039
for us, this is a replica
of the control system that is in the

549
00:43:53,199 --> 00:43:57,679
secure zone, right, so the
main scate system that the operators are using

550
00:43:57,719 --> 00:44:01,719
to send commands to the field.
We've implicate that into the DMZ network zone,

551
00:44:02,079 --> 00:44:07,599
and we call it the DSS.
The DSS has no abilities to send

552
00:44:07,880 --> 00:44:13,320
commands to the field, so it's
a read only system, but it contains

553
00:44:13,719 --> 00:44:17,599
both historical data and real time data. So our product has a real time

554
00:44:17,679 --> 00:44:21,880
side and on a historical side,
our real time side is obviously what brings

555
00:44:21,920 --> 00:44:24,800
back the data from the field and
shows it to the operator and then allows

556
00:44:24,840 --> 00:44:30,239
the commands to be sent. The
SKATA administrator will configure which of those points

557
00:44:30,360 --> 00:44:36,960
in the real time servers need to
be historized, and so we will historize

558
00:44:37,000 --> 00:44:44,320
that data into a smaller historian in
the secure zone purely for trending and for

559
00:44:44,440 --> 00:44:47,599
operator trending. Then all of that
data is also sent to the DSS,

560
00:44:47,719 --> 00:44:52,639
along with all the real time data, and the historian in the DSS will

561
00:44:52,679 --> 00:44:59,159
then usually contain a lot more data, a lot older data. But now

562
00:45:00,199 --> 00:45:05,760
and also now we're seeing that there
is another historian outside of that zone,

563
00:45:06,639 --> 00:45:12,239
in the corporate zone, and you
know, Aviva having purchased OSIsoft, we're

564
00:45:12,280 --> 00:45:16,119
seeing we're seeing PIE. I mean, we would recommend PIE and putting Pie

565
00:45:16,239 --> 00:45:23,400
outside of the ot zones, be
it Zone three or three point five to

566
00:45:23,559 --> 00:45:28,880
use the produe nomenclature. Putting pie
outside of all of that means it can

567
00:45:28,960 --> 00:45:32,199
be the destination for all of your
corporate data, not just data from the

568
00:45:32,280 --> 00:45:36,360
field. So, getting back to
the question, DSS, Yes, it

569
00:45:36,440 --> 00:45:39,239
contains a historian, but it also
contains a read only replica of the real

570
00:45:39,320 --> 00:45:46,400
time allowing non operators to see operator
screens without without the ability to actually do

571
00:45:46,559 --> 00:45:52,880
anything other than navigate and see data. So the DSS then, because it's

572
00:45:52,679 --> 00:45:58,119
was designed at the time with a
trust for the corporate users, any corporate

573
00:45:58,239 --> 00:46:04,119
user then could essentially pretend to be
a skata operator with the exception of being

574
00:46:04,159 --> 00:46:07,679
able to send commands and change configuration
or whatever, just read only. But

575
00:46:08,559 --> 00:46:12,920
because the trusts have gone away,
the DSS now is inaccessible to them.

576
00:46:13,000 --> 00:46:15,679
So we are needing to find a
different solution for the DSS to make it

577
00:46:16,239 --> 00:46:20,000
to get it back to what it
needs to be to help people outside the

578
00:46:20,039 --> 00:46:23,760
control room make decisions. Interesting.
I mean, some of the features you

579
00:46:23,840 --> 00:46:30,280
talk about, you know, giving
the the anyone with access to the DSS

580
00:46:30,440 --> 00:46:32,559
on the outside on the enterprise network, giving them the ability to see the

581
00:46:32,639 --> 00:46:36,960
same screens that the operators would have
seen if they if they'd clicked through to

582
00:46:37,039 --> 00:46:40,000
them this. Uh, you know, I've heard the word digital twin.

583
00:46:42,519 --> 00:46:45,920
You know, I've heard the word
digital twin usually applied to a system in

584
00:46:46,039 --> 00:46:52,480
the cloud that in some sense emulates
the control system, you know, in

585
00:46:52,599 --> 00:46:54,519
the in the OT network, or
the physical process in the OT network.

586
00:46:55,639 --> 00:47:00,559
Can you talk about you know,
is this a digital twin? And can

587
00:47:00,599 --> 00:47:02,559
you talk about the cloud? What? What is the future of the cloud.

588
00:47:02,599 --> 00:47:07,000
Are we talking about operating the pipeline
from the cloud? What? What?

589
00:47:07,280 --> 00:47:12,320
What does the cloud mean security wise? Yeah? Straight for the jugular,

590
00:47:12,519 --> 00:47:15,519
Yeah, skated in the cloud.
So it used to be that making

591
00:47:15,639 --> 00:47:21,719
reference to cloud in my user's presence
would have me politely but firmly shown the

592
00:47:21,800 --> 00:47:27,679
door. Time marches on and the
cloud is not as scary as it once

593
00:47:28,000 --> 00:47:31,719
was. The cloud, remember,
is just somebody else's computer. So with

594
00:47:31,960 --> 00:47:38,159
our product as it is today on
prem on premise, you know, sometimes

595
00:47:38,239 --> 00:47:43,400
the computers are not belonging to the
O T. They're belong to the IT.

596
00:47:43,840 --> 00:47:46,400
Sometimes the data center is and a
different building across town that is a

597
00:47:46,440 --> 00:47:51,480
cloud. It's just your private cloud. So I think that the concept of

598
00:47:51,719 --> 00:47:57,599
understanding, you know, the risks
and and so on of on prem software

599
00:47:57,719 --> 00:48:02,320
versus the cloud. We're seeing a
shift, so definitely digital twin. You

600
00:48:02,400 --> 00:48:07,360
know, it's it's a bit buzzworthy, of course, but the DSS is

601
00:48:07,599 --> 00:48:13,559
essentially like a twenty year old version
perhaps of the digital Twins. So yet,

602
00:48:13,760 --> 00:48:15,800
just like you say, the digital
twin is supposed to be a virtual

603
00:48:15,880 --> 00:48:22,199
representation of the entire asset. So
I think, for example, that the

604
00:48:22,320 --> 00:48:25,079
digital twin will have a big role
to play in how we manage and reduce

605
00:48:25,159 --> 00:48:29,719
the cost of point to point checkouts. If you were able to show to

606
00:48:29,840 --> 00:48:34,920
a regulator that you have paperwork all
the way from instrument to eyeball, then

607
00:48:35,079 --> 00:48:37,840
that you can prove that you know
where the changes have been made. You

608
00:48:37,960 --> 00:48:40,960
ought to then be able to reduce
the amount of effort it takes to do

609
00:48:42,039 --> 00:48:45,639
a P two P a point to
point checkout, and then that information,

610
00:48:45,960 --> 00:48:47,920
you know, should be stored in
a digital twin. But digital Twin is

611
00:48:47,920 --> 00:48:52,639
a lot more than that, and
Aviva is definitely investing heavily in this concept.

612
00:48:53,599 --> 00:49:00,000
Aviva wants to be a cloud first
SaaS business, but that would see

613
00:49:00,199 --> 00:49:02,559
to be at odds with uh,
you know the world's leading oil and gas

614
00:49:02,599 --> 00:49:08,239
control system. So what what I
have done then is we're gonna We're gonna

615
00:49:08,280 --> 00:49:12,840
put our toe in the water with
d s S in the cloud. So

616
00:49:13,320 --> 00:49:19,679
with ds AS being almost useless now
to non control room people, Aviva brings

617
00:49:19,719 --> 00:49:24,639
to bear a bunch of products that
replace what the on premise d s S

618
00:49:24,960 --> 00:49:29,599
used to do and still does for
those that are using which is everybody.

619
00:49:30,639 --> 00:49:35,880
So products like Aviva Insight, which
which allows you know, ad hoc user

620
00:49:36,159 --> 00:49:43,320
access to analytics UH and UH and
dashboarding, Aviva Reports which is Dream Reports

621
00:49:43,719 --> 00:49:51,159
UH rebranded, and then Aviva Teamwork, which is a workforce workforce automation tool.

622
00:49:51,480 --> 00:49:54,360
These are just the first three products
that I think we want to bring

623
00:49:54,480 --> 00:50:00,119
to the midstream industry, and all
of it would be back by Aviva Data

624
00:50:00,199 --> 00:50:06,039
Hub, which is the OSI soft
Pie technology. But in our Aviva Cloud.

625
00:50:07,440 --> 00:50:12,400
There are other regions in the world
that are actually a little bit more

626
00:50:12,480 --> 00:50:16,920
progressive with their thinking about cloud.
I have several Latin American customers that are

627
00:50:16,960 --> 00:50:22,760
thinking about backup as a service.
So a backup control center would know only

628
00:50:22,880 --> 00:50:30,880
be like a direct replica of your
primary control center with you know, building

629
00:50:30,480 --> 00:50:35,119
cooling, ups, rax power,
internet supply, all of the rest of

630
00:50:35,199 --> 00:50:38,199
it. They're there because of they're
a little bit on the smaller side.

631
00:50:38,800 --> 00:50:45,400
They're interested in in the in shifting
that backup server to the cloud in order

632
00:50:45,440 --> 00:50:50,239
to reduce their operating costs, and
so I'm actively looking into what it would

633
00:50:50,280 --> 00:50:55,920
take too to make it easier to
run enterprice KATA in the cloud. But

634
00:50:57,039 --> 00:51:00,719
I am not advocating for North americ
and oil and gas customers to put their

635
00:51:00,760 --> 00:51:07,239
primary control center in the cloud.
In fact, I'm not quite sure what

636
00:51:07,480 --> 00:51:10,280
the future will bring. I have
some visions that I'm working on in terms

637
00:51:10,320 --> 00:51:14,280
of the next twenty years or ten
years for enterprise SKATA and the cloud,

638
00:51:14,960 --> 00:51:17,599
but suffice to say, we will
always have to have some sort of fallback

639
00:51:17,679 --> 00:51:22,719
to on prem I think, if
no other reason, then that's usually where

640
00:51:22,719 --> 00:51:28,360
all of your communications infrastructure is,
you know, originating from. But I

641
00:51:28,440 --> 00:51:34,159
can see a future where the cloud
has demonstrated its stability and security and reliability

642
00:51:34,239 --> 00:51:37,960
to the point where there are customers
that are are happy to run their SCAT

643
00:51:38,079 --> 00:51:42,199
system in the cloud. Now,
having said that, there we have many

644
00:51:42,320 --> 00:51:46,800
SKA customers that are running our product
in an infrastructure as a service, which

645
00:51:46,880 --> 00:51:51,360
is a form of cloud. Right. The difference though, is that that's

646
00:51:51,360 --> 00:51:54,840
still just vms I lift and shift
approach. So so, yeah, the

647
00:51:54,880 --> 00:51:59,920
cloud is the cloud is coming for
sure. And you know, and even

648
00:52:00,119 --> 00:52:02,360
within North America, we have users
that are saying, we want to know

649
00:52:04,039 --> 00:52:07,079
how you're going to move skated to
the cloud, and then we have other

650
00:52:07,280 --> 00:52:09,920
customers which are saying, don't say
cloud in my presence, and then we

651
00:52:10,000 --> 00:52:14,400
have some in the middle. And
I would say that second one very few

652
00:52:14,519 --> 00:52:17,199
now. In fact, at our
pipeline summit, I mentioned it already,

653
00:52:17,280 --> 00:52:22,760
but I'll say another anecdote from that
event was someone come up to me and

654
00:52:22,880 --> 00:52:27,920
say, yeah, your DSS in
the cloud presentation was very interesting, but

655
00:52:28,400 --> 00:52:30,079
I just don't think we'd ever be
able to do it. And I was

656
00:52:30,119 --> 00:52:35,199
getting ready for the usual list of
reasons why we couldn't go to the cloud,

657
00:52:35,360 --> 00:52:38,559
right security, latency, data,
privacy, data, sovereignty, these

658
00:52:38,679 --> 00:52:45,360
kinds of things, but instead the
customer surprised me with the actual reason why

659
00:52:45,480 --> 00:52:51,559
they would probably be hesitant to go
to the cloud, which is that it

660
00:52:51,599 --> 00:52:58,199
would require having to run proxies within
the IT DMZ and they don't have a

661
00:52:58,320 --> 00:53:02,199
healthy relationship with their IT and that
really threw me for a loop. Right,

662
00:53:02,360 --> 00:53:06,559
like Like I said, I was
expecting a whole bunch of other pushback

663
00:53:06,639 --> 00:53:08,239
as to why we couldn't move to
the cloud. But the real reason is

664
00:53:08,280 --> 00:53:12,840
because they don't have a healthy relationship
with their I T department, right,

665
00:53:13,480 --> 00:53:15,320
And the reasons behind that, I
hope are clear. And obviously we have

666
00:53:15,440 --> 00:53:20,119
several firewalls to transverse to get to
the cloud and back, and so we

667
00:53:20,199 --> 00:53:24,559
need proxies and and secure proxies and
other things to live in these other network

668
00:53:24,679 --> 00:53:30,679
zones outside of OT. I was
kind of shocked to hear that that there

669
00:53:30,719 --> 00:53:34,840
could be customers out there. These
were largely and this was a large customer

670
00:53:34,920 --> 00:53:38,320
too, that that still have such
an unhealthy relationship with their I T department.

671
00:53:38,880 --> 00:53:44,159
That to me is as alarming and
as an industry, I think we

672
00:53:44,239 --> 00:53:50,400
ought to be trying to close that
gap somehow. Jake said a lot there,

673
00:53:50,559 --> 00:53:54,079
but it sounds like maybe the overall
point is that the cloud is complicated

674
00:53:54,199 --> 00:53:58,679
or maybe just too complicated for me. Well, he did make the point

675
00:53:58,719 --> 00:54:01,880
that, you know, the end
of tree, the customers who are using

676
00:54:02,000 --> 00:54:07,199
these control systems seem to be all
over the map. You know, some

677
00:54:07,440 --> 00:54:10,400
are saying over my dead body,
read my lips you know, some are

678
00:54:10,519 --> 00:54:15,280
saying, you know, let's do
this. Everybody else is somewhere in between,

679
00:54:15,840 --> 00:54:20,119
you know, and it is complicated, you know, relationship wise with

680
00:54:20,280 --> 00:54:23,840
it. Reliability wise, Is the
Internet reliable enough to do a cloud based

681
00:54:23,880 --> 00:54:29,440
control system? Security wise? You
know, is it wise to have your

682
00:54:29,519 --> 00:54:35,519
control system that exposed to the internet
by operating across the internet? You know,

683
00:54:35,760 --> 00:54:37,800
something new that I heard in his
answer that I'm still thinking about is

684
00:54:38,360 --> 00:54:43,480
the possibility of a backup control center
in the cloud, because you know,

685
00:54:43,599 --> 00:54:47,360
these control centers, the physical buildings
with you know, wiring coming into them,

686
00:54:47,440 --> 00:54:53,519
computers throughout that sit there basically idle
through the entire possible sometimes through the

687
00:54:53,639 --> 00:55:00,360
entire life of the facility unless you're
unless you're testing the backup system a big

688
00:55:00,440 --> 00:55:06,679
investment. And if you can host
your backup in the cloud, you know,

689
00:55:06,800 --> 00:55:10,199
in the life of a facility,
you might never use it. Does

690
00:55:10,440 --> 00:55:15,519
you know, are you exposed?
Can you design the backups so that,

691
00:55:15,480 --> 00:55:22,239
you know, a cloud based backup
so that you're not exposed to the security

692
00:55:22,320 --> 00:55:25,960
problems unless you switch over, and
you might never switch over. These are

693
00:55:27,000 --> 00:55:30,079
all to me, these are all
interesting questions that you know, I'd have

694
00:55:30,159 --> 00:55:34,599
to think about that the idea of
a backup in the cloud security wise,

695
00:55:34,679 --> 00:55:38,599
what does that mean? You know, is something new and you know something

696
00:55:39,079 --> 00:55:45,119
I'm certainly going to be going to
be thinking about going forward. Thank you

697
00:55:45,239 --> 00:55:47,519
for joining us. Before we let
you go, can you sum up for

698
00:55:47,639 --> 00:55:52,840
us what are the most important you
know, lessons that that you think we

699
00:55:52,840 --> 00:55:55,480
should be we should be taking away
about, you know, the product security

700
00:55:55,519 --> 00:56:00,719
and especially product security in you know, the your perspective, the way that

701
00:56:00,920 --> 00:56:07,639
you folks do it. Sure,
yeah, definitely. Security is as a

702
00:56:07,760 --> 00:56:13,039
layered approach. Security and depth is
essential, and it starts before you've even

703
00:56:13,119 --> 00:56:17,000
written a single line of code,
through your design, and then all the

704
00:56:17,039 --> 00:56:22,599
way through deployment and then the the
you know, the the last person who

705
00:56:22,679 --> 00:56:28,519
touched it. So it is a
collective exercise. It starts years before you

706
00:56:28,760 --> 00:56:31,559
need it, and you have to
invest in it, and you have to

707
00:56:31,639 --> 00:56:37,280
continuously invest in it. You know. I mentioned how we pivoted from our

708
00:56:37,480 --> 00:56:40,920
guidance on third party security tools.
One of the things that we mentioned in

709
00:56:42,039 --> 00:56:45,719
there is, you know, be
sure to understand the resource requirements in terms

710
00:56:45,760 --> 00:56:51,239
of human staffing, because if you'd
buy a third party tool, test it

711
00:56:51,400 --> 00:56:54,079
and deploy it, and then never
check it. It's not there. It's

712
00:56:54,159 --> 00:56:58,800
not doing anything for you. If
you're not actively looking at the results and

713
00:56:59,039 --> 00:57:06,199
chasing down the phone positives and and
and so on and constantly improving that you're

714
00:57:07,119 --> 00:57:10,000
you're not progressing. You know,
staying still is moving backwards in the security

715
00:57:10,199 --> 00:57:14,960
I think, So you have to
keep on top of it. And then

716
00:57:15,000 --> 00:57:16,880
I would say, you know,
really, in terms of cloud, you

717
00:57:16,960 --> 00:57:21,800
know, this is my chance,
I guess to to uh to talk a

718
00:57:21,840 --> 00:57:23,639
little bit about where we want to
go with the product into the future.

719
00:57:24,280 --> 00:57:30,920
Is I guess, you know,
maybe introspectively look at some of the prejudices

720
00:57:30,079 --> 00:57:35,079
that you have about cloud and really
and really ask yourselves the kind of questions

721
00:57:35,079 --> 00:57:37,119
that you're going to get for me
if you challenge me in person, right,

722
00:57:37,159 --> 00:57:42,719
which is latency and data privacy,
data security, so you know,

723
00:57:42,760 --> 00:57:45,320
the data security one. It's like, do you think that you have more

724
00:57:45,400 --> 00:57:50,360
people on your security task force than
Aviva does, because I can tell you

725
00:57:50,480 --> 00:57:53,679
we have quite a few people looking
at you know, at DevOps and and

726
00:57:53,840 --> 00:57:58,760
the security landscape, as I've mentioned
many times. So it's you know,

727
00:57:58,920 --> 00:58:04,239
maybe have that have that introspection and
challenge some of your internal prejudices. But

728
00:58:04,440 --> 00:58:07,039
you know, security, like I
said, it's it's extremely important, and

729
00:58:07,440 --> 00:58:10,880
it's a it's a group effort.
It needs to be a collective effort.

730
00:58:12,519 --> 00:58:15,400
Uh and uh and yeah. And
if you want to know more about how

731
00:58:15,440 --> 00:58:19,920
Aviva is keeping the world secure,
I guess is to reach out to your

732
00:58:20,000 --> 00:58:22,760
account manager if you're already a customer, or hit me up on LinkedIn and

733
00:58:22,880 --> 00:58:27,159
I'd be happy to start this discussion
with you and put you in charge and

734
00:58:27,280 --> 00:58:30,639
put you in touch with people who
can who can you know, continue this

735
00:58:30,760 --> 00:58:35,239
discussion with you. We're only a
software vendor. You need to be having

736
00:58:35,320 --> 00:58:38,840
this discussion with all of your vendors, your POC vendors, your your your

737
00:58:38,920 --> 00:58:44,400
payroll vendor and so on. It's
like it's it's no point locking only one

738
00:58:44,480 --> 00:58:45,639
door of your house, right,
you have to look at all of your

739
00:58:45,679 --> 00:58:50,480
doors and that starts with even finding
them. There are there are companies out

740
00:58:50,480 --> 00:58:54,960
there that that will help you even
just understand what your security footprint is before

741
00:58:54,960 --> 00:58:59,920
you even start figuring out how to
secure it. So so yeah, I

742
00:59:00,159 --> 00:59:02,320
think it. But you know what, we have a great industry, lots

743
00:59:02,360 --> 00:59:07,960
of fantastic people like for yourself that
are promoting these kinds of security concepts.

744
00:59:08,159 --> 00:59:13,119
It's extremely important that we all get
on board and do have those conversations with

745
00:59:13,239 --> 00:59:16,480
your IT team. Try to make
them friends instead of enemies. No back

746
00:59:16,519 --> 00:59:20,679
to back firewalls because you don't trust
the other guys firewall right, and I

747
00:59:20,800 --> 00:59:24,519
have seen that multiple times, which
is you know, sad, but there

748
00:59:24,559 --> 00:59:28,760
it is. But yeah, you
know, our product is secure. Come

749
00:59:28,800 --> 00:59:31,079
and have a look. We have
our Aviva conference next year. We're going

750
00:59:31,159 --> 00:59:37,719
to do our pipeline summit again in
Calgary, I think again, so watch

751
00:59:37,760 --> 00:59:39,079
out for that. And yeah,
hit me up on LinkedIn and let's take

752
00:59:39,119 --> 00:59:43,920
this conversation deeper. I want to
know more about why we don't want to

753
00:59:43,960 --> 00:59:47,719
go to cloud because I need I
need to start formalizing a strategy for that.

754
00:59:47,960 --> 00:59:51,480
So yeah, very interested. Thanks
for having me on, Andrew.

755
00:59:53,760 --> 00:59:58,400
Andrew, that was the conclusion of
your interview with Jake Hawks. Do you

756
00:59:58,480 --> 01:00:02,159
have anything else you'd like to take
today? Yeah, I mean I was

757
01:00:02,199 --> 01:00:07,559
impressed. I asked hard questions and
I heard a lot of the right answers.

758
01:00:07,599 --> 01:00:13,119
I mean, you know, deep
transparent documentation so people can make informed

759
01:00:13,159 --> 01:00:15,880
decisions about, you know, using
the security tools of their choice. This

760
01:00:15,000 --> 01:00:17,760
is, this is the right answer. You know, vendors used to push

761
01:00:17,840 --> 01:00:23,880
back on this, and a Viva
isn't anymore. You know, a security

762
01:00:24,000 --> 01:00:29,280
budget for the development team is sounds
really interesting. This is you know,

763
01:00:29,360 --> 01:00:32,039
it sounds like the right answer.
You know, if you don't have that,

764
01:00:32,719 --> 01:00:39,320
the push for features, the push
for schedule tends to muscle out security

765
01:00:40,679 --> 01:00:45,920
investments and you can't afford to do
that. So you know, you give

766
01:00:45,079 --> 01:00:49,559
that decision making authority over to the
development team. You take it out of

767
01:00:49,599 --> 01:00:54,440
the hands of management in a sense
deliberately because management wants security as well.

768
01:00:55,440 --> 01:01:00,239
You know, paranoia is the right
answer to assure the integrity of the development

769
01:01:00,280 --> 01:01:07,079
process, you know. And he's
right, you know, Aviva, he

770
01:01:07,239 --> 01:01:10,400
at Aviva looks at one thing,
the product, but you know his point

771
01:01:10,480 --> 01:01:15,079
that that owners and operators have to
have this security conversation with all of their

772
01:01:15,199 --> 01:01:17,800
vendors, with all of their teams, with with their IT teams and their

773
01:01:17,840 --> 01:01:22,039
engineering teams day. You know,
it's it's a big picture and we all

774
01:01:22,159 --> 01:01:24,079
need to be you know, talking
to each other and doing the right thing.

775
01:01:24,199 --> 01:01:29,000
So you know, again I'm very
impressed. Well, thank you to

776
01:01:29,239 --> 01:01:31,559
jay Hawks for all of that and
Andrews always thank you for speaking with me.

777
01:01:32,039 --> 01:01:35,599
It's always a pleasure. Thank you, Nate. This has been the

778
01:01:35,719 --> 01:01:40,000
Industrial Security podcast from Waterfall. Thanks
to everyone out there listening.