A Checklist for API Security with Wim Remes

Episode 159 · 41:01 · SRT · archive.org · all Tanzu Talk

all right so um this week we have a special guest Wim Remes from wire security and then co-hosting with me this week is my esteemed colleague Brian McLean Wim why don't you go ahead and introduce yourself and and tell us a little bit about who you are and wire security definitely I'm very bad at talking about myself by the way I'm Wim Remes I live in Belgium with my family I run a company called wire security I've been in IT and computer security since 1997 so more than 20 years I started out at a very low level basically as a computer installer for for a bank um and then work my way up to help desk service desk uh system engineering and then at some point I think around 2000 I started to get an interest for security there wasn't a lot of um stuff out there uh and I just started to learn by myself and in the end I started my own company called wire security um trying to focus on what uh what is called wicked problems so um it's easy for companies to uh to find a lot of people that can install firewalls that can manage ideas uh but companies are still struggling with very complicated problems and I'm more interested in helping companies address those problems than uh the the basic stuff so we we do penetration testing we do basic consulting uh but where I get most of my enjoyment is trying to figure stuff out that nobody has figured out yeah well and with the pace that stuff is changing these days I can imagine that that that scope kind of of of what gets complicated and is beyond sort of the the easy grasp of well we know we already know how to do that we already know how to set up the firewall like that keeps growing um so you know

you recently published um I I came across it on twitter an api security maturity model and and let me just pause there and get some clarification is it uh security api maturity model like apis that are specific to security or is it an api security maturity model where it's about securing any and all apis um so I probably have to go back to where I started with this um I got really frustrated uh because um I deliver virtual CISO services where I work with um companies security team to to build their security program uh and security engineers are consuming apis a lot of um the products in the security area are um are point solutions so there's a lot of little things that you have to pull together to get uh one unified view um and those apis were um I'm trying to find a nice word not that they're lacking lacking yeah that's that's that's the right word um so I start thinking about how can we solve this um obviously you can um frustrate developers um or security engineers and and let them scrape websites or or work with apis that are um not a two-par um or we can try to work with different allies within the organization and I'm thinking about uh procurement people but telling procurement people that they should buy um usable apis is not something that they understand so I tried to come up with a simple model um that I could use that my security engineers could use uh if they were evaluating products um to check the boxes but basically the basic uh functionality uh of what is needed but also that could be included in in rfps or tenders um so vendors would actually see it and maybe question themselves and that's the idealist to me uh questioning themselves and see how they can

make their apis better okay so this from different perspectives I try to move not from the top but uh try to influence different areas to get where I want the industry to be yeah that that makes a lot of sense and and of course you know you're this all being kind of born out of frustration right like uh uh necessity is the the mother of invention so yeah that's those are sometimes where the best things come from is when you're just absolutely ready to throw your laptop at the wall yeah um and then obviously um I I built it um an api security maturity model uh but I've recently started uh to use it to develop in teams in organizations that I work with uh because they're developing apis as well uh and they're they found it very useful as a guide on how they uh need to develop non-security apis it was born out of frustration with security products uh but it's applicable to to any product that has an api yeah so that that's interesting and it makes a lot of sense because when I looked at it I was like well this just I mean this sort of just looks like it could be generic for any apis about how to apply security best practices but then there was something in the wording that sort of made me think maybe maybe this is different and it sounds like it is actually kind of both um so and I I like the sort of uh multi-vector thinking that you have around how publishing a maturity model can help solve for not only the people who have to use the products but those who are needing to make decisions about procuring the products and and then of course back to those who have to build the products so um and then I think there's almost been a another vector discovered with just general developers and is it so there's my next question you sort of already answered was going to be around is this more for the people building the apis or more for the people using them but you've kind of explained that it it it really is for both um for those building it gives them some

sort of uh a checklist of goals that they can put on their roadmap and for those consuming it's those things that they need to look for before they pick up a tool or um or some such it's okay it's funny some uh a person on twitter uh someone I really respect uh Ian Coldwater I don't know if you're uh aware of them yeah um uh they they posted something earlier today uh where their kids um watched one of their talks on on kubernetes uh and their kids told them that they understood uh kubernetes now um and that's basically the thinking in basically everything that I that I tried to share uh that your technical technical knowledge shouldn't um or your lack of technical knowledge should not prohibit you from understanding what we're trying to do right uh so it should be usable for for somebody that is very technical as a checklist of this is what I need to do but also from uh for instance that accountant that is involved in your procurement department that can that can understand what is on that document and what what is necessary from a product we're going to buy yeah um I I love giving paths for for folks who aren't technical to be able to wrap their head around something because I think that's also useful for folks who who are technical but because things are evolving and changing so fast and it's so hard to keep up with so much change on so many fronts that even if you know you're a technical domain expert in one area if you know having a way to be able to quickly get up to speed and know what you should be looking for in another area that can be very valuable so yeah really something that that spans that now um I'd love to start diving in a little bit to to the different pieces of the maturity model there's about 20 factors if you will um but I also want to see if Brian had any other questions on kind of the the genesis of of the maturity model yeah no I think we kind of lucked out because I had a had a few questions that I think we kind of accidentally stumbled

on I guess really what what I was thinking of when I was first looking at this what stood out to me was looking at kind of the higher level points I'm like okay yeah I know I need documentation that makes sense I know I need to do this in my implementation but there are some things that even as someone who's been implementing APIs for my career now you know I'm looking at some of these things and and there's still things that I I forget right you know there are things like oh yeah you know I need to make sure my documentation covers proper examples of workflows right um you know something I feel like I don't do a good job of um so I I think this is you know something that's really interesting for for really everyone you know you mentioned the procurement the procurement side of things but also the implementation for uh you know maybe someone who's been doing this their whole life it's a very interesting model yeah what uh what I think is important um especially I I assume you're a developer yourself uh since you said so um I I work with different development teams in in clients that I that I work with uh and as security we usually come in and uh come come come with a big amount of documents about policy and uh and how you should do things and over the last let's say two years I've moved more to a system where I understand how I try to understand how you do things uh and I provide checklists of what 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 matter to me uh what needs to be done uh needs to be available in the checklist that you can uh refer to and okay did I do all the things uh and that that's all that is needed um so that that's what I tried with this as well just provide a checklist not not a long document of 200 pages that you need 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 simple as possible yeah I think I love it that and that totally plays into um the whole model of like

you know shifting security left right how do you shift it so that it's happening earlier in the development cycle and not something that has to get bolted on or becomes a huge roadblock to getting into production later because someone's going to throw that 250 page book at you I mean someone being someone in the security department and there's not actually a 250 page book but you get the idea um and uh what maybe one thing to interject I I really don't like the term um shift shift lift oh okay I I know it's very very much used in um in application security and uh application development in general but if you look at a business process it is never a linear process it goes up and down left and right uh and it uh even even moves in in in different dimensions so there for me there is no left if I as as a security professional want to influence security within a development life cycle I'm touching um I'm touching processes in uh in in a 3d model so there is no left I need to influence everywhere uh and I need to be able to shift in all directions I'm smiling because that is such a security person way to answer that question so I mean I'll be honest like security is one of those areas that as I was coming in and learning infrastructure software that I was like wow this is I can't you know other stuff had sort of a logical order to it that I could understand in the application stack and you know how applications would talk to databases and where the operating systems fit in and then someone would bring up security and I felt like there was you couldn't get any leverage points because you couldn't build upon something and then achieve it was there was always like oh but there's this other way you could come in and it's it sort of left me with this impression that security experts they really are thinking about the world in a in a different way in this sort of three-dimensional way whereas like other folks

trying to just make order out of stuff do want to put things in a linear model um and so whether that's 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 mental sort of uh mode that security is going to see things in 3d and look at multiple vectors and there's not necessarily a way to completely block everything out with a few moves you know you could constantly be looking for new openings that are created etc so um I just have to smile that like of course shift left wouldn't like appeal to someone who's a security expert um it's so easy for you know someone like me to wrap my head around but I I totally understand what you're saying I think my point is though that if you're trying to sort of disperse and diffuse the responsibility of security into uh developers who are not security experts but of course they they want their application to be secure their their service to be secure um making it easy uh making the the right thing the easy thing to do and something like a checklist tends to work for stuff like that so yeah I'll try to expunge shift left from my vocabulary for at least it can it can definitely be useful term uh talking to to uh different different audiences uh but I always try to make sure when I talk to executives and stuff like that um that we make clear that there is no linear process and there are no dimming cycles that work everything moves in organized scale yeah I think that's that's something I've actually it's really interesting point right because I feel like this is something I've been seeing kind of across the different components of tech right is um it's becoming less and less about okay I've done my development now we're going to do our security check okay now it's been gone through security let's send it to operations and not just the collaboration between those teams but just

the sort of melding of that education has been kind of spreading over those uh specialties I think and it's it's uh community you brought up uh in cold water because they gave a talk um I believe it was near the beginning of the year that talked about this 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 thinking is you know okay as a developer I need to really start understanding security for example you know I know I need a single sign-on I know I need to encrypt this data but past that like how are attackers you know what vulnerabilities are they are they exploiting yeah what does that look like so I know how to write more secure code yeah I do a lot of threat modeling with the development teams and it's um trend modeling isn't that hard it's um it's basically thinking thinking like an attacker uh so I usually see when I when I do training uh it's usually a two-day training uh I see uh the developers take take on that knowledge and immediately start thinking about the uh the the stuff they're working on right now um and and start applying that knowledge uh and they they find it useful to to give push push back to product managers to actually say uh well we're developing this but uh due to security we cannot do this and this uh and threatening gives them the tools to build that argument they they know it is there uh but without the threat modeling knowledge and the ability to um basically gather the data and gather the evidence uh they they have no way to push back um against other forces within the organization so they're they're really happy when they uh when they have those tools uh and you see them running with it yeah like they're empowered to sort of be able to say no to certain things which is really hard um okay let's dive into the to the model a little bit there's three sections i'm going to kind 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

notes but it there's three sections the the first section has four points all around documentation um now the you set up at least kind of the the the quick diagram that i saw um you've got like kind of a one to five scale what what sort of moves something down that scale to sort of how you would measure their maturity and you know not everything's going to be a five but how do you understand if you're like is when you're talking about for example those examples or that it's um something like it's available for all the languages it's like well that's that's a little bit more binary you can kind of you know tick off we've covered the you know three biggest languages and then you know now we need to cover like more exotic languages um yeah but something like you know you've provided exhaustive documentation it's like well what does exhaustive mean how do i get the five how do i get the egg in that class yes um so starting with point one uh being publicly available um obviously the zero is where there's no documentation available um the the one would be where documentation is available but i need to have a paid account to um to reach the documentation uh so it's available but only uh only if i pay uh i i strongly believe that putting your api out there uh will get you much more feedback and ability to improve on your um uh documentation and obviously the five is when i can just access the documentation from your website right without any authentication or paywall or uh or data wall exhaustive um you see documentation where they uh don't give any explanation about the different endpoints at all um they just uh tell you which did um which data is mandatory which uh which is optional 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

my api with more than curl alone um but obviously that is not uh exhaustive enough okay so what would what would more exhaustive look like you you're covering all the different endpoints you're providing more examples what else should be aspiring to um give give enough um explanation about the purpose of the of the of the endpoint um is potential limitations uh what data is uh um supposed to uh give back um one one important thing in uh api calls for for me for instance is the content type there there's a lot of uh api documentation that doesn't provide information about what content type should be requested and what they should expect back those are those are little things that um that would influence that uh exhaustiveness factor okay all right that's yeah that's great then people can kind of measure themselves moving along that curve yeah okay and then i think after that are some examples so you mentioned 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 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 i'm definitely not uh um up to par uh delivering um production ready um production ready codes um but translating documentation um using a curl call to a python or a javascript implementation is a lot of work so either um providing the documentation with examples of the most common languages uh and then i'm mostly thinking about javascript uh ruby python that that is really useful for uh for developers i believe yeah absolutely agree i mean i i like you said i've seen so many uh api documentation where it's just if you're lucky there's a curl command and then uh you know there's some specifics on how curl handles requests to with specific flags you can or maybe omit so yeah i totally agree exactly um would um like if

if people are looking at documentation and then and they're finding it deficient and and kind of any of the ways you described whether it's you know how exhaustive it is and and the the availability of the examples is like having a mechanism to to provide feedback um or to be able to submit like hey you know i actually i you don't have an example of how to do this in ruby or spring and and i have that example here's a way for me to actually provide that back to you is that even that availability of collecting that feedback or allowing people to i don't know if you would use a like how it's just some way to be able to get like yes you can that would be awesome or documentation is that is that itself something that's sort of along that maturity curve um i believe so if that kind of functional functionality exists that would definitely um push push you up um one or two uh one or two slots obviously doesn't uh absolve you from providing good documentation um relying on your users to provide uh to create the documentation for you is not is definitely not the win uh but having that feedback loop is uh very important i believe yes yeah okay um and then there was another one more section i think in the documentation yes workflow examples so explain a little bit about what that means so um taking the example of um for instance that there's a product that i know and i will not do product placement uh but they uh provide honeypots um that you can deploy in your network um and they report to a central console uh that you call can call with an api uh and you can call the current alerts uh the the alerts come back uh every every the list of alerts come comes back you can uh call every alert and get details of the alert uh and then you can um take data from the alert and and push it to uh for instance a firewall to block

a certain id right okay um that kind of workflow uh needs to be documented um and that doesn't only help the people that use it uh because they will realize that okay i can use this product for more things than uh than i imagine uh but it also helps the developer to understand if there's any break in in in that type of workflow for uh for a user so it's really about understanding almost like the use case for that api okay so if we come back now the next section is around um authentication uh and and authorization so you know this was definitely something i remember you know brian called out in in his his write-up that i was reading recently um what's sort of the the the high level kind of reminders around the different points that you have in the in the authentication section um so when i look at authentication uh within an api as it is now within uh several products uh they will let you do a call with a username and password um every time that's a basic authentication instead of authenticating once getting a token and then using that token for the duration that you needed um they would basically do um basic basic http authentication uh and you're sending the credentials back and forth every time which increases the risk because um at any point somebody can do a man in the middle attack and get those credentials uh and use those credentials uh forever so um in my ideal worlds um a user can self-generate an api token uh so within their uh web interface they have the ability to create uh an api token but it is displayed only once 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 retrieve that uh ever again uh the reason for that is uh simple if they lose the api so uh or uh it is

compromised the moment they regenerate um an api key the old one is invalidated so anybody that was able to obtain that that key can no longer use it right uh if you would allow them to um display display that token again uh there would be no blocking factor there would be no indicator that an uh an api token is compromised and it becomes the user's responsibility to protect that token uh with everything they have so there we are on the self-generating uh of api tokens um i think in itself uh generating it for them so displaying it um in in in your web interface is is not necessarily a a huge problem uh but i think the responsibility uh needs to be with the user to protect that uh to protect that key uh and you don't want to be blamed at some point um if they lose their key uh and somebody access their data um maliciously then um you you don't want to take that blame right uh explain that a little bit more to me so it's the user's responsibility to protect their key what happens if a user's not sort of doing that what's at risk for the the api provider will say if the user's not actually protecting their key and following best practices uh that that would mean that that key um for instance ends up in uh in code published on github uh and there's people people actually um constantly looking for uh for keys or key material there uh so they they can use that to uh to access data within within your product so how do we avoid that by um educating um the the users that i think that's the only way i've i've uh often uh heard um examples of why for instance uh keys are kept on the server side as well um and um the explanation then is well sometimes users lose keys

and then we have to send them uh the keys again um but in in the end it's it's an access token you you don't keep 10 copies of your house key um everywhere around your house so in case you forget uh 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 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 going to go and just go get it that same key remade i'm going to change the law yeah brian feel free to jump in with smarter questions this starts to get out of my depth 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 trends i've seen in some public apis um and of course these are the the trends we're seeing more and more of um because of the reasons you said right you know basic authentication where you're using it in password just going off in plain text that's just a ticking time bomb until someone sniffs that out and uh you know starts uploading files to your storage provider for example runs up your bill 100 brands um so i know i think these are all again it's sort of what i mentioned earlier is these are things that even if if you've been developing apis for or consuming apis for for years i think kind of gets lost on people because it's like okay yeah you know i'm sure it does authentication and authorization properly but i don't think enough people kind of sit down and analyze that and say oh no they're not really handling these tokens correctly like like you said i can go and i can just get my token in plain text it turns out yeah i didn't even know i could do that and until i i dove into it so and why why not include an example of uh how to protect your um your keys using maybe aws uh key management system or an azure key management system or an hashycorp vault and add that to your documentation not not focus on one product preferably but um or at least on um on a

on a logical level um you're working with key material uh this is the best way um or this is a recommended way to protect those things so don't put them in your binaries uh like at lessons this last week i think or two weeks ago that kind of stuff okay yeah i mean anytime there's kind of that shift of responsibility you're you're sort of asking someone else to do things responsibly then that immediately raises questions for me of like well how are you making it easy for them like if if you're making it their responsibility like your like things will go wrong um and so i think this almost comes back to you know so in the documentation providing that education around how to do this securely and how to handle your um your keys and tokens correctly yeah um and so yeah in an ideal world everyone would know not to store things in plain text in their in their code but we know that that's not the case so we don't want to we don't want that you know mistake on the part of our users or someone consuming our service to to happen so how do we how do we avoid that even though it's essentially their responsibility exactly okay all right that helps um all right so if we skip ahead to start to look at unless there's anything else just i'm looking at the time um if we want to jump ahead to the implementation section which has uh probably about 10 or so different points in it and this you know correct me if i'm wrong brian this kind of seemed to map to um your sort of section around like just design like api design right adhering to rest principles um following the http verbs like those kind of being your your core best practices around basic api design is that a fair characterization to think about this implementation section yeah no i i think that's exactly right i mean um something i've been really

kind of mulling over the last couple days preparing for this conversation was um what are those ramifications of a well-designed api kind of following these these principles right you know obviously there's it's easy to use which is the first and foremost uh you know the important part but i also sort of think about this when it comes to things like operations and and security you know i keep harping on that but um you know as an operator if i know that this is a well-designed api that's going to be uh returning proper status codes i can hook my monitoring tools into that and and my learning tools into that um if and from a few years of experience of operations as well um to me this all kind of screams predictability um and maybe you can chime in from a from a security standpoint but for me predictability was like that that was everything to me like i mean i could i could monitor it i could 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 general thought i get when it comes to actual implementation of uh of apis whether they're 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 you captured it better than um when i was thinking when i wrote it uh predictability definitely is a thing and if i look at the the things that i uh value most in in a well-designed uh designed api definitely 3g um standard application uses the same api if your application doesn't use the api that you uh publish to your uh to your users uh if those are separate then you'll probably have a problem um uh eat your eat your own dog food uh in europe we say drink your own champagne um i prefer champagne to dog food i'm just going to point that out exactly well that depends on the people um i prefer champagne as well um that i i think that is a very good um approach to developing

applications and basically any any product that you would create if you don't want to use your own product then why are you selling it to customers from a security point of view uh definitely the logging in the audit trail um being available through the api uh and not having to jump through hoops uh or login to an admin interface to see to see the logging i want to be able to consume that logging and push it into an analysis engine um just through code so integrated as as well as possible uh and then uh definitely the the versioning as well um if you just change your endpoints uh and um change the way they uh have to interact with them uh that's gonna throw off my my whole um automated workflow uh and that's just gonna be hell so i i guess that plays definitely into the uh predictability uh paradigm yeah i feel like there's been uh almost wars fought over versioning and how to properly do that but yeah you know at least some strategy is is better than not right uh i fully agree there um and again the the the checklist um hopefully allows developers to uh to think think about it um when they start developing an 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 assessments on i think two security products um that allowed me to basically do a litmus test of uh of this framework uh or maturity model uh whatever you want to want to call it um and they they were very happy with the feedback so i think it kind of works yeah i mean and a lot of these as as i sort of implied before was these look like they are generic to just any kind of security best practices for any kind of api not necessarily strictly speaking for security products or or services are there any i

mean but it was something like for example the logging in on a trail that you mentioned i can see absolutely how in a security product that would be essential is that as critical in you know just any generic api that could be out there um i believe it is i believe it is more and more um because uh for instance in europe you have the general data protection uh regulation as well where the audit trail is a mandatory requirement um make making it possible for me as uh as an organization uh to create that audit trail uh to an api instead of going through a web interface um is going to make my life much much easier because i'm not using just your product but i'm using dozens of other products that also produce audit trails copying and pasting all of that to an excel sheet and then trying to sort uh sort it out 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 that gotcha okay that makes sense so these things that that may once have been really you know critical for security but optional elsewhere are increasingly becoming uh sort of critical everywhere um so uh and i mean we could go through each one of these and and work on defining you know what the one versus the five scale is i'm not sure we have time to go through all of these but are there any that jump out at you that you'd like want to put on people's radar is like this is what a five looks like versus a one in one of these implementation points um i i think right right now the way the way i've written written that i um i really meant it um as a checklist and it depends 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 i i i didn't want to be very strict in in those categorization um so depending on what the product

product is the maturity of the of the user uh and what a product will be used for uh the the values of one and five can can shift a bit i'm still working on the uh on the documentation of the um of the the maturity model itself uh so i'm probably gonna gonna figure out what what it exactly means uh the difference between a one and a two and a five uh but right now i don't really have an answer to that okay yeah i can imagine for each one of these like that's it's a different answer um so that's like 20 different uh one in five definitions that you have to go right i i think for instance if you look at 3b uh no url parameters are used uh that seems like a very strict requirement uh but i think from a checklist perspective uh it's a good starting point saying we cannot use uh url parameters but in some cases you're going to have to use them right uh but at least makes you think okay we're uh we're not supposed to uh to use them in this case we really need them um and you can justify why you need them but at least you're thinking about it yeah and it doesn't become your default solution for uh something that you can probably solve in another way okay yeah i think that that point specifically i saw there was a really interesting uh that sparked a really interesting conversation on twitter um and uh like you say it got me thinking i was like okay this isn't so much of a um you know strict you know you have to do this or your product's awful it's think about these things let's let's justify why we're making the decisions rather than just you know throw it at a wall and see what sticks yes uh for me the thinking was uh mostly if i have to build a request uh purely using url parameters uh that is hell in no matter what language i want even if i can structure a request body uh using json or whatever that makes my life much much easier where would you recommend folks go next if they want to learn more i mean you will include the

the link to where you have this maturity model published and your your twitter handle where they can keep up with you where what else would you recommend folks who want to learn more about some of these um uh kind of factors and and just want to get get stronger in and how they're applying security principles what would you recommend that they they sort of do as a next step uh well definitely what once i start um building the documentation will it will probably be during the christmas holidays um provide as much feedback as possible um there is some uh api guidance uh on the oas site that's uh oas.org 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 maturity model to start from um it's only when when we started calling that that it became that uh and apparently the the only other um api maturity model model that exists is something called the the richardson maturity model i don't know if you've ever heard uh about it but it's from 2010 uh and it's mostly about rest maturity so it's not about the functional uh and definitely not about the documentation um so definitely i would say i would say oas um and and try to look at uh different apis uh from um similar products uh out there uh things you find on github uh other products that publish their uh api and uh try to learn from there all right well this has been you know a really interesting and an educational chat so i think this is a this is going to be a really useful checklist for a lot of folks um as as you described and um brian i don't know if you have any final questions uh but uh definitely thank you for for joining us on on the conversation thank you

Tanzu Talk · 🍕 Get more pizza.