1
00:00:00,000 --> 00:00:13,720
all right so um this week we have a special guest Wim Remes from wire security and then

2
00:00:13,720 --> 00:00:19,800
co-hosting with me this week is my esteemed colleague Brian McLean Wim why don't you go

3
00:00:19,800 --> 00:00:23,600
ahead and introduce yourself and and tell us a little bit about who you are and wire security

4
00:00:24,240 --> 00:00:32,640
definitely I'm very bad at talking about myself by the way I'm Wim Remes I live in Belgium with my

5
00:00:32,640 --> 00:00:42,760
family I run a company called wire security I've been in IT and computer security since 1997 so

6
00:00:42,760 --> 00:00:50,680
more than 20 years I started out at a very low level basically as a computer installer for for a

7
00:00:50,680 --> 00:00:57,960
bank um and then work my way up to help desk service desk uh system engineering and then at some point

8
00:00:57,960 --> 00:01:04,820
I think around 2000 I started to get an interest for security there wasn't a lot of um stuff out there

9
00:01:04,820 --> 00:01:11,360
uh and I just started to learn by myself and in the end I started my own company called wire security

10
00:01:11,360 --> 00:01:19,880
um trying to focus on what uh what is called wicked problems so um it's easy for companies to uh to find

11
00:01:19,880 --> 00:01:25,300
a lot of people that can install firewalls that can manage ideas uh but companies are still struggling

12
00:01:25,300 --> 00:01:29,740
with very complicated problems and I'm more interested in helping companies address those

13
00:01:29,740 --> 00:01:34,940
problems than uh the the basic stuff so we we do penetration testing we do basic consulting

14
00:01:34,940 --> 00:01:40,520
uh but where I get most of my enjoyment is trying to figure stuff out that nobody has figured out

15
00:01:40,520 --> 00:01:46,080
yeah well and with the pace that stuff is changing these days I can imagine that that that scope

16
00:01:46,080 --> 00:01:53,880
kind of of of what gets complicated and is beyond sort of the the easy grasp of well we know we already

17
00:01:53,880 --> 00:02:00,340
know how to do that we already know how to set up the firewall like that keeps growing um so you know

18
00:02:00,340 --> 00:02:08,760
you recently published um I I came across it on twitter an api security maturity model and and let me just

19
00:02:08,760 --> 00:02:16,980
pause there and get some clarification is it uh security api maturity model like apis that are

20
00:02:16,980 --> 00:02:22,180
specific to security or is it an api security maturity model where it's about securing

21
00:02:22,180 --> 00:02:29,920
any and all apis um so I probably have to go back to where I started with this um I got really frustrated

22
00:02:29,920 --> 00:02:37,460
uh because um I deliver virtual CISO services where I work with um companies security team to to build

23
00:02:37,460 --> 00:02:44,560
their security program uh and security engineers are consuming apis a lot of um the products in the

24
00:02:44,560 --> 00:02:50,760
security area are um are point solutions so there's a lot of little things that you have to pull

25
00:02:50,760 --> 00:02:57,980
together to get uh one unified view um and those apis were um I'm trying to find a nice word

26
00:02:57,980 --> 00:03:07,420
not that they're lacking lacking yeah that's that's that's the right word um so I start thinking about

27
00:03:07,420 --> 00:03:14,320
how can we solve this um obviously you can um frustrate developers um or security engineers and

28
00:03:14,320 --> 00:03:22,940
and let them scrape websites or or work with apis that are um not a two-par um or we can try to work

29
00:03:22,940 --> 00:03:27,460
with different allies within the organization and I'm thinking about uh procurement people but telling

30
00:03:27,460 --> 00:03:33,600
procurement people that they should buy um usable apis is not something that they understand so I tried

31
00:03:33,600 --> 00:03:39,820
to come up with a simple model um that I could use that my security engineers could use uh if they were

32
00:03:39,820 --> 00:03:46,340
evaluating products um to check the boxes but basically the basic uh functionality uh of what

33
00:03:46,340 --> 00:03:53,800
is needed but also that could be included in in rfps or tenders um so vendors would actually see it and

34
00:03:53,800 --> 00:04:00,140
maybe question themselves and that's the idealist to me uh questioning themselves and see how they can

35
00:04:00,140 --> 00:04:06,780
make their apis better okay so this from different perspectives I try to move not from the top but

36
00:04:06,780 --> 00:04:13,220
uh try to influence different areas to get where I want the industry to be yeah that that makes a lot

37
00:04:13,220 --> 00:04:18,100
of sense and and of course you know you're this all being kind of born out of frustration right like uh

38
00:04:18,100 --> 00:04:23,660
uh necessity is the the mother of invention so yeah that's those are sometimes where the best things

39
00:04:23,660 --> 00:04:29,300
come from is when you're just absolutely ready to throw your laptop at the wall yeah um and then

40
00:04:29,300 --> 00:04:38,160
obviously um I I built it um an api security maturity model uh but I've recently started uh to use it to

41
00:04:38,160 --> 00:04:42,820
develop in teams in organizations that I work with uh because they're developing apis as well uh and

42
00:04:42,820 --> 00:04:47,780
they're they found it very useful as a guide on how they uh need to develop non-security apis

43
00:04:47,780 --> 00:04:53,520
it was born out of frustration with security products uh but it's applicable to to any product

44
00:04:53,520 --> 00:04:58,200
that has an api yeah so that that's interesting and it makes a lot of sense because when I looked at it

45
00:04:58,200 --> 00:05:04,180
I was like well this just I mean this sort of just looks like it could be generic for any apis

46
00:05:04,180 --> 00:05:09,500
about how to apply security best practices but then there was something in the wording that sort of

47
00:05:09,500 --> 00:05:15,480
made me think maybe maybe this is different and it sounds like it is actually kind of both um

48
00:05:15,480 --> 00:05:25,060
so and I I like the sort of uh multi-vector thinking that you have around how publishing a

49
00:05:25,060 --> 00:05:31,820
maturity model can help solve for not only the people who have to use the products but those who are

50
00:05:31,820 --> 00:05:37,660
needing to make decisions about procuring the products and and then of course back to those who have to

51
00:05:37,660 --> 00:05:44,040
build the products so um and then I think there's almost been a another vector discovered with just

52
00:05:44,040 --> 00:05:50,780
general developers and is it so there's my next question you sort of already answered was going

53
00:05:50,780 --> 00:05:55,120
to be around is this more for the people building the apis or more for the people using them but

54
00:05:55,120 --> 00:06:01,340
you've kind of explained that it it it really is for both um for those building it gives them some

55
00:06:01,340 --> 00:06:06,600
sort of uh a checklist of goals that they can put on their roadmap and for those consuming it's those

56
00:06:06,600 --> 00:06:12,980
things that they need to look for before they pick up a tool or um or some such it's okay it's

57
00:06:12,980 --> 00:06:18,120
funny some uh a person on twitter uh someone I really respect uh Ian Coldwater I don't know if you're

58
00:06:18,120 --> 00:06:25,560
uh aware of them yeah um uh they they posted something earlier today uh where their kids um

59
00:06:25,560 --> 00:06:32,600
watched one of their talks on on kubernetes uh and their kids told them that they understood uh kubernetes now

60
00:06:32,600 --> 00:06:39,440
um and that's basically the thinking in basically everything that I that I tried to share uh that

61
00:06:39,440 --> 00:06:45,560
your technical technical knowledge shouldn't um or your lack of technical knowledge should not

62
00:06:45,560 --> 00:06:51,280
prohibit you from understanding what we're trying to do right uh so it should be usable for for somebody

63
00:06:51,280 --> 00:06:56,580
that is very technical as a checklist of this is what I need to do but also from uh for instance that

64
00:06:56,580 --> 00:07:02,280
accountant that is involved in your procurement department that can that can understand what is

65
00:07:02,280 --> 00:07:05,460
on that document and what what is necessary from a product we're going to buy

66
00:07:05,460 --> 00:07:14,020
yeah um I I love giving paths for for folks who aren't technical to be able to wrap their head

67
00:07:14,020 --> 00:07:18,920
around something because I think that's also useful for folks who who are technical but because things

68
00:07:18,920 --> 00:07:26,260
are evolving and changing so fast and it's so hard to keep up with so much change on so many fronts that

69
00:07:26,260 --> 00:07:32,640
even if you know you're a technical domain expert in one area if you know having a way to be able to

70
00:07:32,640 --> 00:07:36,820
quickly get up to speed and know what you should be looking for in another area that can be very

71
00:07:36,820 --> 00:07:44,800
valuable so yeah really something that that spans that now um I'd love to start diving in a little bit to

72
00:07:44,800 --> 00:07:52,740
to the different pieces of the maturity model there's about 20 factors if you will um but I also want to

73
00:07:52,740 --> 00:07:58,820
see if Brian had any other questions on kind of the the genesis of of the maturity model yeah no I think

74
00:07:58,820 --> 00:08:02,780
we kind of lucked out because I had a had a few questions that I think we kind of accidentally stumbled

75
00:08:02,780 --> 00:08:08,300
on I guess really what what I was thinking of when I was first looking at this what stood out to me was

76
00:08:08,300 --> 00:08:13,180
looking at kind of the higher level points I'm like okay yeah I know I need documentation that makes

77
00:08:13,180 --> 00:08:17,580
sense I know I need to do this in my implementation but there are some things that even as someone who's

78
00:08:17,580 --> 00:08:23,420
been implementing APIs for my career now you know I'm looking at some of these things and and

79
00:08:23,420 --> 00:08:27,920
there's still things that I I forget right you know there are things like oh yeah you know I need to

80
00:08:27,920 --> 00:08:34,380
make sure my documentation covers proper examples of workflows right um you know something I feel like I

81
00:08:34,380 --> 00:08:40,880
don't do a good job of um so I I think this is you know something that's really interesting for for

82
00:08:40,880 --> 00:08:45,360
really everyone you know you mentioned the procurement the procurement side of things but also the

83
00:08:45,360 --> 00:08:50,160
implementation for uh you know maybe someone who's been doing this their whole life it's a very

84
00:08:50,160 --> 00:08:56,220
interesting model yeah what uh what I think is important um especially I I assume you're a developer

85
00:08:56,220 --> 00:09:02,400
yourself uh since you said so um I I work with different development teams in in clients that I that I work

86
00:09:02,400 --> 00:09:09,840
with uh and as security we usually come in and uh come come come with a big amount of documents about

87
00:09:09,840 --> 00:09:15,920
policy and uh and how you should do things and over the last let's say two years I've moved more to a

88
00:09:15,920 --> 00:09:22,720
system where I understand how I try to understand how you do things uh and I provide checklists of what

89
00:09:22,720 --> 00:09:29,760
what you need to do uh but you you are smart enough to um to implement it in the right way so how how you do it doesn't

90
00:09:29,760 --> 00:09:34,960
matter to me uh what needs to be done uh needs to be available in the checklist that you can uh refer

91
00:09:34,960 --> 00:09:42,240
to and okay did I do all the things uh and that that's all that is needed um so that that's what

92
00:09:42,240 --> 00:09:47,040
I tried with this as well just provide a checklist not not a long document of 200 pages that you need

93
00:09:47,040 --> 00:09:54,240
to read um that as as a as an expert you you really don't need just just a checklist and uh keep it as

94
00:09:54,240 --> 00:10:02,560
simple as possible yeah I think I love it that and that totally plays into um the whole model of like

95
00:10:02,560 --> 00:10:07,360
you know shifting security left right how do you shift it so that it's happening earlier in the

96
00:10:07,360 --> 00:10:13,120
development cycle and not something that has to get bolted on or becomes a huge roadblock to getting into

97
00:10:13,120 --> 00:10:18,640
production later because someone's going to throw that 250 page book at you I mean someone being

98
00:10:18,640 --> 00:10:24,560
someone in the security department and there's not actually a 250 page book but you get the idea um

99
00:10:24,560 --> 00:10:32,240
and uh what maybe one thing to interject I I really don't like the term um shift shift lift oh okay

100
00:10:33,840 --> 00:10:40,160
I I know it's very very much used in um in application security and uh application development in general

101
00:10:40,160 --> 00:10:46,880
but if you look at a business process it is never a linear process it goes up and down left and right

102
00:10:47,440 --> 00:10:54,240
uh and it uh even even moves in in in different dimensions so there for me there is no left if I as

103
00:10:54,960 --> 00:11:01,920
as a security professional want to influence security within a development life cycle I'm touching um I'm

104
00:11:01,920 --> 00:11:11,440
touching processes in uh in in a 3d model so there is no left I need to influence everywhere uh and I

105
00:11:11,440 --> 00:11:18,400
need to be able to shift in all directions I'm smiling because that is such a security person way to answer

106
00:11:18,400 --> 00:11:26,000
that question so I mean I'll be honest like security is one of those areas that as I was coming in and

107
00:11:26,000 --> 00:11:31,840
learning infrastructure software that I was like wow this is I can't you know other stuff had sort

108
00:11:31,840 --> 00:11:37,440
of a logical order to it that I could understand in the application stack and you know how applications

109
00:11:37,440 --> 00:11:41,920
would talk to databases and where the operating systems fit in and then someone would bring up

110
00:11:41,920 --> 00:11:47,760
security and I felt like there was you couldn't get any leverage points because you couldn't build

111
00:11:47,760 --> 00:11:52,480
upon something and then achieve it was there was always like oh but there's this other way you could come in

112
00:11:52,480 --> 00:12:00,560
and it's it sort of left me with this impression that security experts they really are thinking

113
00:12:00,560 --> 00:12:06,480
about the world in a in a different way in this sort of three-dimensional way whereas like other folks

114
00:12:06,480 --> 00:12:13,040
trying to just make order out of stuff do want to put things in a linear model um and so whether that's

115
00:12:13,040 --> 00:12:19,760
you know the up and down of the app stack or the left to right of a of a delivery cycle um it's it's this

116
00:12:19,760 --> 00:12:26,960
mental sort of uh mode that security is going to see things in 3d and look at multiple vectors and

117
00:12:26,960 --> 00:12:33,520
there's not necessarily a way to completely block everything out with a few moves you know you could

118
00:12:33,520 --> 00:12:40,720
constantly be looking for new openings that are created etc so um I just have to smile that like

119
00:12:40,720 --> 00:12:47,760
of course shift left wouldn't like appeal to someone who's a security expert um it's so easy for you know

120
00:12:47,760 --> 00:12:52,880
someone like me to wrap my head around but I I totally understand what you're saying I think

121
00:12:52,880 --> 00:13:00,000
my point is though that if you're trying to sort of disperse and diffuse the responsibility of security

122
00:13:00,640 --> 00:13:08,560
into uh developers who are not security experts but of course they they want their application to be

123
00:13:08,560 --> 00:13:15,120
secure their their service to be secure um making it easy uh making the the right thing the easy thing to

124
00:13:15,120 --> 00:13:22,480
do and something like a checklist tends to work for stuff like that so yeah I'll try to expunge shift

125
00:13:22,480 --> 00:13:29,760
left from my vocabulary for at least it can it can definitely be useful term uh talking to to uh

126
00:13:29,760 --> 00:13:34,640
different different audiences uh but I always try to make sure when I talk to executives and stuff like

127
00:13:34,640 --> 00:13:41,440
that um that we make clear that there is no linear process and there are no dimming cycles that work

128
00:13:41,440 --> 00:13:45,840
everything moves in organized scale yeah I think that's that's something I've actually

129
00:13:46,800 --> 00:13:49,920
it's really interesting point right because I feel like this is something I've been seeing kind of across

130
00:13:50,480 --> 00:13:56,240
the different components of tech right is um it's becoming less and less about okay I've done my

131
00:13:56,240 --> 00:14:00,880
development now we're going to do our security check okay now it's been gone through security

132
00:14:00,880 --> 00:14:05,840
let's send it to operations and not just the collaboration between those teams but just

133
00:14:06,480 --> 00:14:12,960
the sort of melding of that education has been kind of spreading over those uh specialties

134
00:14:12,960 --> 00:14:19,040
I think and it's it's uh community you brought up uh in cold water because they gave a talk

135
00:14:19,920 --> 00:14:23,040
um I believe it was near the beginning of the year that talked about this

136
00:14:23,040 --> 00:14:28,560
um I really wish I could remember the name of the talk it's it's so good but um that's what got me really

137
00:14:28,560 --> 00:14:33,920
thinking is you know okay as a developer I need to really start understanding security for example

138
00:14:33,920 --> 00:14:39,280
you know I know I need a single sign-on I know I need to encrypt this data but past that like how

139
00:14:39,280 --> 00:14:44,640
are attackers you know what vulnerabilities are they are they exploiting yeah what does that look like

140
00:14:44,640 --> 00:14:50,080
so I know how to write more secure code yeah I do a lot of threat modeling with the development teams

141
00:14:50,080 --> 00:14:56,880
and it's um trend modeling isn't that hard it's um it's basically thinking thinking like an attacker

142
00:14:56,880 --> 00:15:03,120
uh so I usually see when I when I do training uh it's usually a two-day training uh I see uh the

143
00:15:03,120 --> 00:15:09,040
developers take take on that knowledge and immediately start thinking about the uh the the stuff they're

144
00:15:09,040 --> 00:15:15,520
working on right now um and and start applying that knowledge uh and they they find it useful to to give

145
00:15:15,520 --> 00:15:21,520
push push back to product managers to actually say uh well we're developing this but uh due to security

146
00:15:21,520 --> 00:15:28,400
we cannot do this and this uh and threatening gives them the tools to build that argument they they know

147
00:15:28,400 --> 00:15:35,040
it is there uh but without the threat modeling knowledge and the ability to um basically gather

148
00:15:35,040 --> 00:15:40,720
the data and gather the evidence uh they they have no way to push back um against other forces within

149
00:15:40,720 --> 00:15:45,760
the organization so they're they're really happy when they uh when they have those tools uh and you see

150
00:15:45,760 --> 00:15:51,920
them running with it yeah like they're empowered to sort of be able to say no to certain things which is

151
00:15:51,920 --> 00:15:59,520
really hard um okay let's dive into the to the model a little bit there's three sections i'm going to kind

152
00:15:59,520 --> 00:16:06,400
of try to refer to it as if someone maybe hasn't seen it um and we'll include a link in the in the show

153
00:16:06,400 --> 00:16:13,360
notes but it there's three sections the the first section has four points all around documentation

154
00:16:14,080 --> 00:16:21,040
um now the you set up at least kind of the the the quick diagram that i saw

155
00:16:21,920 --> 00:16:31,680
um you've got like kind of a one to five scale what what sort of moves something down that scale to

156
00:16:31,680 --> 00:16:37,760
sort of how you would measure their maturity and you know not everything's going to be a five but how

157
00:16:37,760 --> 00:16:42,880
do you understand if you're like is when you're talking about for example those examples or that

158
00:16:42,880 --> 00:16:48,640
it's um something like it's available for all the languages it's like well that's that's a little bit

159
00:16:48,640 --> 00:16:55,040
more binary you can kind of you know tick off we've covered the you know three biggest languages and

160
00:16:55,040 --> 00:17:02,320
then you know now we need to cover like more exotic languages um yeah but something like you know you've

161
00:17:02,320 --> 00:17:08,000
provided exhaustive documentation it's like well what does exhaustive mean how do i get the five how do

162
00:17:08,000 --> 00:17:17,280
i get the egg in that class yes um so starting with point one uh being publicly available um obviously the

163
00:17:17,280 --> 00:17:23,680
zero is where there's no documentation available um the the one would be where documentation is available

164
00:17:23,680 --> 00:17:30,640
but i need to have a paid account to um to reach the documentation uh so it's available but only uh

165
00:17:30,640 --> 00:17:36,640
only if i pay uh i i strongly believe that putting your api out there uh will get you much more feedback

166
00:17:36,640 --> 00:17:43,920
and ability to improve on your um uh documentation and obviously the five is when i can just access the

167
00:17:43,920 --> 00:17:50,400
documentation from your website right without any authentication or paywall or uh or data wall

168
00:17:50,400 --> 00:17:56,880
exhaustive um you see documentation where they uh don't give any explanation about the different

169
00:17:56,880 --> 00:18:05,040
endpoints at all um they just uh tell you which did um which data is mandatory which uh which is optional

170
00:18:05,600 --> 00:18:15,040
uh and at best they they give an example uh using curl now as an api developer i i hope that people use my um

171
00:18:15,040 --> 00:18:20,720
my api with more than curl alone um but obviously that is not uh exhaustive enough

172
00:18:22,720 --> 00:18:27,040
okay so what would what would more exhaustive look like you you're covering

173
00:18:27,760 --> 00:18:36,080
all the different endpoints you're providing more examples what else should be aspiring to um give

174
00:18:36,080 --> 00:18:43,280
give enough um explanation about the purpose of the of the of the endpoint um is potential limitations uh

175
00:18:43,280 --> 00:18:52,080
what data is uh um supposed to uh give back um one one important thing in uh api calls for for me

176
00:18:52,080 --> 00:18:56,720
for instance is the content type there there's a lot of uh api documentation that doesn't provide

177
00:18:56,720 --> 00:19:00,160
information about what content type should be requested and what they should expect back

178
00:19:01,520 --> 00:19:08,480
those are those are little things that um that would influence that uh exhaustiveness factor

179
00:19:08,480 --> 00:19:12,880
okay all right that's yeah that's great then people can kind of measure themselves

180
00:19:12,880 --> 00:19:17,120
moving along that curve yeah okay and then i think after that are some examples so you mentioned

181
00:19:17,120 --> 00:19:23,600
sort of at best an example in curl right is sort of like you know i don't know if that's a passing grade

182
00:19:23,600 --> 00:19:30,560
even yeah so i'm i'm i'm i'm not a well-trained developer i can uh write some proof of concept code but

183
00:19:30,560 --> 00:19:39,920
i'm definitely not uh um up to par uh delivering um production ready um production ready codes um but

184
00:19:39,920 --> 00:19:47,040
translating documentation um using a curl call to a python or a javascript implementation is a lot of

185
00:19:47,040 --> 00:19:53,280
work so either um providing the documentation with examples of the most common languages uh and then

186
00:19:53,280 --> 00:20:00,160
i'm mostly thinking about javascript uh ruby python that that is really useful for uh for developers i believe

187
00:20:00,160 --> 00:20:07,120
yeah absolutely agree i mean i i like you said i've seen so many uh api documentation where it's just

188
00:20:08,080 --> 00:20:13,520
if you're lucky there's a curl command and then uh you know there's some specifics on how curl handles

189
00:20:13,520 --> 00:20:25,040
requests to with specific flags you can or maybe omit so yeah i totally agree exactly um would um like if

190
00:20:25,040 --> 00:20:30,480
if people are looking at documentation and then and they're finding it deficient and and kind of any

191
00:20:30,480 --> 00:20:36,080
of the ways you described whether it's you know how exhaustive it is and and the the availability of the

192
00:20:36,080 --> 00:20:45,760
examples is like having a mechanism to to provide feedback um or to be able to submit like hey you

193
00:20:45,760 --> 00:20:52,560
know i actually i you don't have an example of how to do this in ruby or spring and and i have that

194
00:20:52,560 --> 00:21:00,320
example here's a way for me to actually provide that back to you is that even that availability of

195
00:21:00,320 --> 00:21:05,760
collecting that feedback or allowing people to i don't know if you would use a like how it's just

196
00:21:05,760 --> 00:21:11,440
some way to be able to get like yes you can that would be awesome or documentation is that is that

197
00:21:11,440 --> 00:21:18,320
itself something that's sort of along that maturity curve um i believe so if that kind of functional

198
00:21:18,320 --> 00:21:24,640
functionality exists that would definitely um push push you up um one or two uh one or two slots

199
00:21:25,840 --> 00:21:33,120
obviously doesn't uh absolve you from providing good documentation um relying on your users to provide

200
00:21:33,120 --> 00:21:39,360
uh to create the documentation for you is not is definitely not the win uh but having that feedback

201
00:21:39,360 --> 00:21:47,600
loop is uh very important i believe yes yeah okay um and then there was another one more section i think

202
00:21:47,600 --> 00:21:54,720
in the documentation yes workflow examples so explain a little bit about what that means so um taking the

203
00:21:54,720 --> 00:22:01,360
example of um for instance that there's a product that i know and i will not do product placement uh but

204
00:22:01,360 --> 00:22:09,680
they uh provide honeypots um that you can deploy in your network um and they report to a central console

205
00:22:09,680 --> 00:22:16,000
uh that you call can call with an api uh and you can call the current alerts uh the the alerts come back

206
00:22:16,000 --> 00:22:23,120
uh every every the list of alerts come comes back you can uh call every alert and get details of the alert

207
00:22:23,600 --> 00:22:30,240
uh and then you can um take data from the alert and and push it to uh for instance a firewall to block

208
00:22:30,240 --> 00:22:37,600
a certain id right okay um that kind of workflow uh needs to be documented um and that doesn't only

209
00:22:37,600 --> 00:22:42,240
help the people that use it uh because they will realize that okay i can use this product for more

210
00:22:42,240 --> 00:22:49,440
things than uh than i imagine uh but it also helps the developer to understand if there's any break in in

211
00:22:49,440 --> 00:22:54,240
in that type of workflow for uh for a user so it's really about understanding almost like the use case

212
00:22:54,880 --> 00:23:04,080
for that api okay so if we come back now the next section is around um authentication uh and and

213
00:23:04,080 --> 00:23:08,800
authorization so you know this was definitely something i remember you know brian called out in

214
00:23:08,800 --> 00:23:15,360
in his his write-up that i was reading recently um what's sort of the the the high level kind of

215
00:23:15,360 --> 00:23:20,160
reminders around the different points that you have in the in the authentication section

216
00:23:21,760 --> 00:23:29,200
um so when i look at authentication uh within an api as it is now within uh several products

217
00:23:29,760 --> 00:23:34,160
uh they will let you do a call with a username and password um every time

218
00:23:34,720 --> 00:23:39,600
that's a basic authentication instead of authenticating once getting a token and then

219
00:23:39,600 --> 00:23:47,200
using that token for the duration that you needed um they would basically do um basic basic http

220
00:23:47,200 --> 00:23:53,440
authentication uh and you're sending the credentials back and forth every time which increases the risk

221
00:23:53,440 --> 00:24:00,480
because um at any point somebody can do a man in the middle attack and get those credentials uh and use

222
00:24:00,480 --> 00:24:11,680
those credentials uh forever so um in my ideal worlds um a user can self-generate an api token uh so within

223
00:24:11,680 --> 00:24:17,920
their uh web interface they have the ability to create uh an api token but it is displayed only once

224
00:24:19,040 --> 00:24:25,200
they can copy paste it uh when it is displayed after that uh you don't want to be want them to be able to

225
00:24:25,200 --> 00:24:35,040
retrieve that uh ever again uh the reason for that is uh simple if they lose the api so uh or uh it is

226
00:24:35,040 --> 00:24:42,720
compromised the moment they regenerate um an api key the old one is invalidated so anybody that was able to

227
00:24:42,720 --> 00:24:51,760
obtain that that key can no longer use it right uh if you would allow them to um display display that token

228
00:24:51,760 --> 00:24:59,680
again uh there would be no blocking factor there would be no indicator that an uh an api token is compromised

229
00:25:00,640 --> 00:25:05,920
and it becomes the user's responsibility to protect that token uh with everything they have so there we are

230
00:25:06,880 --> 00:25:15,760
on the self-generating uh of api tokens um i think in itself uh generating it for them so displaying it um

231
00:25:16,800 --> 00:25:24,880
in in in your web interface is is not necessarily a a huge problem uh but i think the responsibility uh

232
00:25:24,880 --> 00:25:31,040
needs to be with the user to protect that uh to protect that key uh and you don't want to be blamed at

233
00:25:31,040 --> 00:25:39,280
some point um if they lose their key uh and somebody access their data um maliciously then um you you don't

234
00:25:39,280 --> 00:25:44,480
want to take that blame right uh explain that a little bit more to me so it's the user's responsibility to

235
00:25:44,480 --> 00:25:54,640
protect their key what happens if a user's not sort of doing that what's at risk for the the api provider

236
00:25:54,640 --> 00:26:03,040
will say if the user's not actually protecting their key and following best practices uh that that would

237
00:26:03,040 --> 00:26:09,520
mean that that key um for instance ends up in uh in code published on github uh and there's people

238
00:26:09,520 --> 00:26:15,600
people actually um constantly looking for uh for keys or key material there uh so they they can use that

239
00:26:15,600 --> 00:26:22,720
to uh to access data within within your product so how do we avoid that by um educating um the the

240
00:26:22,720 --> 00:26:31,280
users that i think that's the only way i've i've uh often uh heard um examples of why for instance uh

241
00:26:31,280 --> 00:26:37,840
keys are kept on the server side as well um and um the explanation then is well sometimes users lose keys

242
00:26:37,840 --> 00:26:44,160
and then we have to send them uh the keys again um but in in the end it's it's an access token

243
00:26:45,040 --> 00:26:52,960
you you don't keep 10 copies of your house key um everywhere around your house so in case you forget uh

244
00:26:52,960 --> 00:26:58,560
forget your key you can find another one that's not a smart thing to do so you shouldn't do that with the api keys either

245
00:26:58,560 --> 00:27:05,920
okay so it's sort of akin to oh i've i've left my keys at the restaurant or whatever uh i'm not

246
00:27:05,920 --> 00:27:11,600
going to go and just go get it that same key remade i'm going to change the law yeah brian feel free to

247
00:27:11,600 --> 00:27:15,360
jump in with smarter questions this starts to get out of my depth

248
00:27:18,560 --> 00:27:23,200
this is all good i mean this is um you know i'm as we're kind of going through this i'm just thinking of

249
00:27:23,200 --> 00:27:28,880
trends i've seen in some public apis um and of course these are the the trends we're seeing more

250
00:27:28,880 --> 00:27:34,960
and more of um because of the reasons you said right you know basic authentication where you're

251
00:27:34,960 --> 00:27:40,880
using it in password just going off in plain text that's just a ticking time bomb until someone sniffs

252
00:27:40,880 --> 00:27:46,800
that out and uh you know starts uploading files to your storage provider for example runs up your bill

253
00:27:47,520 --> 00:27:53,040
100 brands um so i know i think these are all again it's sort of what i mentioned earlier is

254
00:27:53,040 --> 00:27:58,400
these are things that even if if you've been developing apis for or consuming apis for for

255
00:27:58,400 --> 00:28:03,760
years i think kind of gets lost on people because it's like okay yeah you know i'm sure it does

256
00:28:03,760 --> 00:28:09,920
authentication and authorization properly but i don't think enough people kind of sit down and analyze

257
00:28:09,920 --> 00:28:14,640
that and say oh no they're not really handling these tokens correctly like like you said i can go

258
00:28:14,640 --> 00:28:18,960
and i can just get my token in plain text it turns out yeah i didn't even know i could do that and

259
00:28:18,960 --> 00:28:26,720
until i i dove into it so and why why not include an example of uh how to protect your um your keys

260
00:28:26,720 --> 00:28:32,720
using maybe aws uh key management system or an azure key management system or an hashycorp vault

261
00:28:33,840 --> 00:28:41,120
and add that to your documentation not not focus on one product preferably but um or at least on um on a

262
00:28:42,080 --> 00:28:47,600
on a logical level um you're working with key material uh this is the best way um or this is

263
00:28:47,600 --> 00:28:53,840
a recommended way to protect those things so don't put them in your binaries uh like at lessons this

264
00:28:53,840 --> 00:28:59,600
last week i think or two weeks ago that kind of stuff okay yeah i mean anytime there's kind of that

265
00:28:59,600 --> 00:29:07,120
shift of responsibility you're you're sort of asking someone else to do things responsibly then that

266
00:29:07,120 --> 00:29:12,560
immediately raises questions for me of like well how are you making it easy for them like if if you're

267
00:29:12,560 --> 00:29:20,720
making it their responsibility like your like things will go wrong um and so i think this almost comes

268
00:29:20,720 --> 00:29:26,960
back to you know so in the documentation providing that education around how to do this securely and how

269
00:29:26,960 --> 00:29:36,160
to handle your um your keys and tokens correctly yeah um and so yeah in an ideal world everyone would know

270
00:29:36,160 --> 00:29:43,040
not to store things in plain text in their in their code but we know that that's not the case so we

271
00:29:43,040 --> 00:29:48,400
don't want to we don't want that you know mistake on the part of our users or someone consuming our

272
00:29:48,400 --> 00:29:55,200
service to to happen so how do we how do we avoid that even though it's essentially their responsibility

273
00:29:55,200 --> 00:30:03,600
exactly okay all right that helps um all right so if we skip ahead to start to look at unless there's

274
00:30:03,600 --> 00:30:09,520
anything else just i'm looking at the time um if we want to jump ahead to the implementation section

275
00:30:09,520 --> 00:30:16,720
which has uh probably about 10 or so different points in it and this you know correct me if i'm

276
00:30:16,720 --> 00:30:23,520
wrong brian this kind of seemed to map to um your sort of section around like just design like api design

277
00:30:23,520 --> 00:30:29,440
right adhering to rest principles um following the http verbs like those kind of being your

278
00:30:30,000 --> 00:30:36,800
your core best practices around basic api design is that a fair characterization to think about this

279
00:30:36,800 --> 00:30:42,560
implementation section yeah no i i think that's exactly right i mean um something i've been really

280
00:30:42,560 --> 00:30:47,680
kind of mulling over the last couple days preparing for this conversation was um what are those

281
00:30:47,680 --> 00:30:53,360
ramifications of a well-designed api kind of following these these principles right you know

282
00:30:53,360 --> 00:30:59,440
obviously there's it's easy to use which is the first and foremost uh you know the important part

283
00:31:00,160 --> 00:31:05,280
but i also sort of think about this when it comes to things like operations and and security you know i

284
00:31:05,280 --> 00:31:11,680
keep harping on that but um you know as an operator if i know that this is a well-designed api that's going

285
00:31:11,680 --> 00:31:18,080
to be uh returning proper status codes i can hook my monitoring tools into that and and my learning

286
00:31:18,080 --> 00:31:25,760
tools into that um if and from a few years of experience of operations as well um to me this all

287
00:31:25,760 --> 00:31:32,480
kind of screams predictability um and maybe you can chime in from a from a security standpoint but for

288
00:31:32,480 --> 00:31:38,720
me predictability was like that that was everything to me like i mean i could i could monitor it i could

289
00:31:38,720 --> 00:31:46,160
i could um you know i could measure it and i could plan for growth um so that's that's sort of the the

290
00:31:46,160 --> 00:31:51,360
general thought i get when it comes to actual implementation of uh of apis whether they're

291
00:31:51,360 --> 00:31:59,440
rust api or not but i'm curious on your thoughts on that yeah what were the goals um yes i i i think you

292
00:32:00,480 --> 00:32:07,120
you captured it better than um when i was thinking when i wrote it uh predictability definitely is a

293
00:32:07,120 --> 00:32:12,400
thing and if i look at the the things that i uh value most in in a well-designed uh designed api

294
00:32:12,400 --> 00:32:20,080
definitely 3g um standard application uses the same api if your application doesn't use the api that

295
00:32:20,080 --> 00:32:25,920
you uh publish to your uh to your users uh if those are separate then you'll probably have a problem

296
00:32:26,560 --> 00:32:32,160
um uh eat your eat your own dog food uh in europe we say drink your own champagne um

297
00:32:33,200 --> 00:32:37,920
i prefer champagne to dog food i'm just going to point that out exactly well that depends on the

298
00:32:37,920 --> 00:32:46,960
people um i prefer champagne as well um that i i think that is a very good um approach to developing

299
00:32:46,960 --> 00:32:51,600
applications and basically any any product that you would create if you don't want to use your own

300
00:32:51,600 --> 00:32:55,520
product then why are you selling it to customers from a security point of view uh definitely the logging

301
00:32:55,520 --> 00:33:01,680
in the audit trail um being available through the api uh and not having to jump through hoops uh or

302
00:33:02,480 --> 00:33:08,000
login to an admin interface to see to see the logging i want to be able to consume that logging and push

303
00:33:08,000 --> 00:33:15,520
it into an analysis engine um just through code so integrated as as well as possible uh and then

304
00:33:15,520 --> 00:33:23,920
uh definitely the the versioning as well um if you just change your endpoints uh and um change the way

305
00:33:23,920 --> 00:33:30,960
they uh have to interact with them uh that's gonna throw off my my whole um automated workflow uh and

306
00:33:30,960 --> 00:33:40,160
that's just gonna be hell so i i guess that plays definitely into the uh predictability uh paradigm yeah i feel

307
00:33:40,160 --> 00:33:46,720
like there's been uh almost wars fought over versioning and how to properly do that but yeah

308
00:33:46,720 --> 00:33:55,840
you know at least some strategy is is better than not right uh i fully agree there um and again the the

309
00:33:55,840 --> 00:34:03,120
the checklist um hopefully allows developers to uh to think think about it um when they start developing an

310
00:34:03,120 --> 00:34:09,360
api um i think it's useful when an api already exists and then you want to grow it um i've i've done

311
00:34:09,360 --> 00:34:17,200
assessments on i think two security products um that allowed me to basically do a litmus test of uh of

312
00:34:17,200 --> 00:34:24,560
this framework uh or maturity model uh whatever you want to want to call it um and they they were very

313
00:34:24,560 --> 00:34:32,400
happy with the feedback so i think it kind of works yeah i mean and a lot of these as as i sort of

314
00:34:32,400 --> 00:34:40,160
implied before was these look like they are generic to just any kind of security best practices for

315
00:34:40,160 --> 00:34:48,160
any kind of api not necessarily strictly speaking for security products or or services are there any i

316
00:34:48,160 --> 00:34:52,560
mean but it was something like for example the logging in on a trail that you mentioned i can see

317
00:34:52,560 --> 00:35:01,920
absolutely how in a security product that would be essential is that as critical in you know just any

318
00:35:01,920 --> 00:35:10,240
generic api that could be out there um i believe it is i believe it is more and more um because uh for

319
00:35:10,240 --> 00:35:16,320
instance in europe you have the general data protection uh regulation as well where the audit trail is a

320
00:35:16,320 --> 00:35:23,440
mandatory requirement um make making it possible for me as uh as an organization uh to create that audit

321
00:35:23,440 --> 00:35:29,760
trail uh to an api instead of going through a web interface um is going to make my life much much easier

322
00:35:29,760 --> 00:35:34,720
because i'm not using just your product but i'm using dozens of other products that also produce

323
00:35:34,720 --> 00:35:41,120
audit trails copying and pasting all of that to an excel sheet and then trying to sort uh sort it out

324
00:35:41,120 --> 00:35:46,960
um it's not going to work if i can automate that uh with with a python script i'm i'm going to want to do

325
00:35:46,960 --> 00:35:55,760
that gotcha okay that makes sense so these things that that may once have been really you know critical

326
00:35:55,760 --> 00:36:02,320
for security but optional elsewhere are increasingly becoming uh sort of critical everywhere um

327
00:36:03,440 --> 00:36:09,760
so uh and i mean we could go through each one of these and and work on defining you know what the

328
00:36:09,760 --> 00:36:14,800
one versus the five scale is i'm not sure we have time to go through all of these but are there any that

329
00:36:15,520 --> 00:36:19,600
jump out at you that you'd like want to put on people's radar is like this is what

330
00:36:20,240 --> 00:36:29,840
a five looks like versus a one in one of these implementation points um i i think right right

331
00:36:29,840 --> 00:36:37,040
now the way the way i've written written that i um i really meant it um as a checklist and it depends

332
00:36:37,040 --> 00:36:45,920
on uh on on the person that is looking at it um to to judge what uh what a one and a five is uh

333
00:36:45,920 --> 00:36:54,240
i i i didn't want to be very strict in in those categorization um so depending on what the product

334
00:36:54,240 --> 00:37:02,080
product is the maturity of the of the user uh and what a product will be used for uh the the values of

335
00:37:02,080 --> 00:37:08,880
one and five can can shift a bit i'm still working on the uh on the documentation of the um of the

336
00:37:08,880 --> 00:37:15,120
the maturity model itself uh so i'm probably gonna gonna figure out what what it exactly means uh

337
00:37:15,120 --> 00:37:20,240
the difference between a one and a two and a five uh but right now i don't really have an answer to that

338
00:37:20,240 --> 00:37:25,760
okay yeah i can imagine for each one of these like that's it's a different answer um so that's like

339
00:37:26,400 --> 00:37:33,520
20 different uh one in five definitions that you have to go right i i think for instance if you look at

340
00:37:33,520 --> 00:37:40,400
3b uh no url parameters are used uh that seems like a very strict requirement uh but i think from a

341
00:37:40,400 --> 00:37:46,800
checklist perspective uh it's a good starting point saying we cannot use uh url parameters but in some

342
00:37:46,800 --> 00:37:52,080
cases you're going to have to use them right uh but at least makes you think okay we're uh we're not

343
00:37:52,080 --> 00:37:57,280
supposed to uh to use them in this case we really need them um and you can justify why you need them

344
00:37:57,920 --> 00:38:01,520
but at least you're thinking about it yeah and it doesn't become your default solution

345
00:38:02,160 --> 00:38:08,560
for uh something that you can probably solve in another way okay yeah i think that that point

346
00:38:08,560 --> 00:38:12,960
specifically i saw there was a really interesting uh that sparked a really interesting conversation on

347
00:38:12,960 --> 00:38:18,480
twitter um and uh like you say it got me thinking i was like okay this isn't so much of a

348
00:38:19,120 --> 00:38:24,640
um you know strict you know you have to do this or your product's awful it's

349
00:38:24,640 --> 00:38:28,640
think about these things let's let's justify why we're making the decisions rather than just

350
00:38:29,360 --> 00:38:35,120
you know throw it at a wall and see what sticks yes uh for me the thinking was uh mostly if i have

351
00:38:35,120 --> 00:38:41,040
to build a request uh purely using url parameters uh that is hell in no matter what language i want

352
00:38:41,600 --> 00:38:48,400
even if i can structure a request body uh using json or whatever that makes my life much much easier

353
00:38:48,400 --> 00:38:54,960
where would you recommend folks go next if they want to learn more i mean you will include the

354
00:38:55,680 --> 00:39:01,040
the link to where you have this maturity model published and your your twitter handle where they

355
00:39:01,040 --> 00:39:06,720
can keep up with you where what else would you recommend folks who want to learn more about some of these

356
00:39:07,440 --> 00:39:17,120
um uh kind of factors and and just want to get get stronger in and how they're applying security principles

357
00:39:17,120 --> 00:39:23,600
what would you recommend that they they sort of do as a next step uh well definitely what once i start

358
00:39:23,600 --> 00:39:29,280
um building the documentation will it will probably be during the christmas holidays um provide as much

359
00:39:29,280 --> 00:39:37,920
feedback as possible um there is some uh api guidance uh on the oas site that's uh oas.org

360
00:39:38,560 --> 00:39:47,920
uh but other than that i've not found a lot um out there uh the so i i i didn't think about this as a

361
00:39:47,920 --> 00:39:53,200
maturity model to start from um it's only when when we started calling that that it became that

362
00:39:53,680 --> 00:40:00,160
uh and apparently the the only other um api maturity model model that exists is something called the

363
00:40:00,160 --> 00:40:05,520
the richardson maturity model i don't know if you've ever heard uh about it but it's from 2010

364
00:40:06,160 --> 00:40:12,240
uh and it's mostly about rest maturity so it's not about the functional uh and definitely not about

365
00:40:12,240 --> 00:40:20,640
the documentation um so definitely i would say i would say oas um and and try to look at uh different

366
00:40:20,640 --> 00:40:28,480
apis uh from um similar products uh out there uh things you find on github uh other products that

367
00:40:28,480 --> 00:40:34,240
publish their uh api and uh try to learn from there all right well this has been you know a really

368
00:40:34,240 --> 00:40:39,440
interesting and an educational chat so i think this is a this is going to be a really useful

369
00:40:39,440 --> 00:40:46,480
checklist for a lot of folks um as as you described and um brian i don't know if you have any final

370
00:40:46,480 --> 00:40:57,920
questions uh but uh definitely thank you for for joining us on on the conversation thank you