CCT 098: Understanding APIs and the Security Principles Associated for the CISSP Exam (CISSP Domain 8.5)

Are you ready to unlock the secrets of API security? Prepare to be enlightened, as we tackle the burning issue of cybersecurity, with a special focus on recent hacker attacks targeting US water treatment facilities. Join us in a critical dialogue on fortifying our defenses and the role of cybersecurity education in our communities. Learn how to navigate the complexities of API security, from managing authentication to role-based access and the handling of tokens and API keys. 

Brace yourselves for a grand tour of the API ecosystem, where we demystify API gateways and their pivotal role in enhancing security. Discover the intricacies of managing authorized connections, safeguarding against denial of service attacks, and navigating the risks of exposing cloud infrastructure to the internet. We also delve into the importance of robust API usage policies and discuss the pros and cons of IP whitelisting and blacklisting. 

To put a cap on our security pilgrimage, we journey into the realm of API security testing practices. Familiarize yourself with various testing methods, the importance of keeping abreast with evolving threats, and the balance of security and functionality. Plus, for those of you preparing for the CISSP exam, we share a wealth of resources to aid in your success. So, gear up for an enriching experience that is sure to bolster your cybersecurity knowledge and equip you to ace the CISSP exam!

Gain access to 30 FREE CISSP Exam Questions each and every month by going to FreeCISSPQuestions.com and sign-up to join the team for Free. 

TRANSCRIPT

Welcome to the CISSP Cyber Training Podcast, where we provide you the training and tools you need to pass the CISSP exam the first time. Hi, my name is Sean Gerber and I'm your host for this action-packed, informative podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cybersecurity knowledge. All right, let's get started. Hey y'all, it's Sean Gerber with CISSP Cyber Training, and I hope you all are having a blessed day, this beautiful day here. I mean things are here in Kansas are doing very, very well. We're pretty excited about the weather. The weather's been absolutely amazing and now we have Christmas. Holidays are shortly coming and my new grand little granddaughter is heading into town, so we're excited about that. It's very fun to have her here and the energy that comes with a little two and a half three year old. We are pretty fired up about that piece, but we're more fired up about getting into. What you guys are listening for is the CISSP training and we're going to be getting into as it relates to API security today. Today, as you all know, monday is a Monday and Monday the training comes out for the specific topic and then on Thursday, you get a CISSP questions that are typically not all the time but in many cases, are associated with the overall training that occurs on Monday. But before we do one thing, I wanted to bring up a little bit of news article that I saw today Well, actually, I saw it a couple of weeks ago and that was as relates to the. Some various hackers have been hacking the industrial control systems at United States water facilities. They have brought this up. There was an authority of Equipa, equipa Pennsylvania, and they had been hacked recently, and this is the second time that I've seen something like the third where there have been attackers that have gone after water treatment facilities. Now, this, this treatment facility serves about 6600 customers, so it's about the size of the town I live in and they, as you and my friends that are in India, there are laughing 6600 people. They don't even have that. They have that on a block in India. But, that being said aside, there's about 6000 people and there were some folks that that actually hacked into this water treatment facility and they believe they were Iranian based hacktivists that were going after that facility. As a result, there was a PLC that's tied to it called unit unitronics. It's unitronics. This system was one that allowed them the foothold into that environment, and CISA came out with a article that is around the exploitation of this eulantronics PLCs and their recommendations on how to fix them. So if you're listening to this, and I if you're in the United States, it really doesn't matter where you're at. If they're having a water treatment facility that deals with your unitronics PLCs, you may want to get with them and ask them about how to upgrade those systems. I've talked to my local local town and I'm in the process of talking to a couple of towns that are outside of where I live just to make sure that they have the same understanding around the hack that's there. I think it's important that you, as cyber security professionals, do everything in your power to help individuals within your community to understand the security risks that they might be incurring within their country or within their community. So it's an interesting read. There are one that's on the CISA has it. That's the CISAgov and it's the unitronics. It's U-N-I-T-R-O-N-I-C-S. I know that's like the alphabet, but you can Google it unitronics PLCs with water and wastewater systems. Yeah, check it out, because one of the things that's come out of it is there's the P. I guess I'm looking at the article from CISA there's the password is 111. You know, I mean, these people are just fools. I'm sorry, but when your manufacturers make these things, I cannot believe they allow this to continue, require multi-factor, and then they obviously want you to disconnect the PLC from the open internet. The bottom line is you want to have a segregated network when you're dealing with anything in the manufacturing or, in this case, safety. You really want to avoid having it on a business network and then to have passwords that are basically four ones. It's just foolishness. So I highly recommend that you talk to people in your local community about how you can be of assistance to help them. We need you out there doing that. Okay, so now we're going to roll into understanding API securities and what is. What are some things you need to be aware of as a security professional? Now I'm going to go into this with a disclaimer. Obviously, that's usually when someone comes up with a disclaimer says they don't know anything, and that's probably true. I know enough in API security to be dangerous and enough to teach you and help you pass the CISP course, but I am not a developer and I would highly recommend if you really like APIs, then you get a little bit smarter on it and teach the hive the collective, because the bottom line is that this is an area that is continually growing. I was just on a phone call yesterday dealing with API security and it was interesting because it was coming out of a large company that was sending data using SFTP, which isn't bad, but we were able to get them on an API connection through an API gateway and that that was a great option to help them. And a lot of that comes down to what knowledge I have around. Api is very useful, but when you get into the specifics, that's where you really want to get in a developer to help you understand the overall API is as a whole, and your goal as a CISP is to basically be the one that can communicate with other individuals around different security topics. You do not have to be the expert on everything. You have to understand it enough that you can converse and then find the right answer. But in reality, there's so much information nobody can be an expert on everything. So when you're dealing with API, is you want to allow? These are basically allowing different secure or different software programs to communicate and protocols to communicate with each other. So, like a way to think of it is as a framework. So if you have a, you have one piece of software wants to talk to another piece of software. In the past you had to have both languages talk to each other using the same language or you had to have a program in the middle that would then basically convert one language into another language. But what APIs are? They're like a standard, they're like a framework that if you follow this framework and you follow the standard, then it will communicate between one program and another program and it allows you to have seamless connectivity with them. So you know, if you're a developer and you create a program with an output, if your output meets the level of what this framework for, this API, and then you're another developer of another program that takes an input and you, a lot, build your other program that is taking that input, based on the standard, then the data coming from one program to another program can work well and it allows this communication path between the two and it works amazingly well into the fact that almost everything out there in today's world is using APIs. Now I will tell you that the one thing that concerns me as a security professional is the use of APIs. Why? Because there's so many of them. In the past, we knew the exits and entrances into a network. Once you start connecting a bunch of APIs together, that visibility can go away and you don't have the same level of understanding of network of data leaving and coming into and leaving your network as you used to have. So what are some types of APIs that you're going to deal with Now? I'm just going to go into a couple that you will be aware of that you may see on your CISP exam. One is REST. Now, that's the representational state transfer. Now this is the most common type of an API and it really is known because it's simplicity and it's statefulness, which basically means it's always listening. It's a very I mean, my developers used to use the REST API all the time and it's just basically listening all the time so that information can come and go. It's typically used within HTTP and HTTPS protocols and you will see a lot of people talk about REST APIs. Now you have SOAP. Now SOAP is a simple object access protocol and this is a protocol based on APIs known for its high security and extensibility, which basically means it's it can really be used in many different ways. It is typically used within an enterprise solutions and I will say I've seen it in enterprise. But I also see a lot of REST APIs set up within the enterprises as well, but SOAP is probably one that's more common within a large organization. You have GraphQL, which is in like a quick, quick Lima, I guess what you would call it. This is a newer type of API that allows clients to request only the data they need. Now, that is a nice aspect to the API. In many cases, the APIs are set up just to kind of work as a fire hose and they just shovel data to and from. If you can have it set up where it's only taking the information that is necessary and needed, that is a great way in reducing the overall data transfer. It also helps with bandwidth and, in my case, of security. I like that because I don't want it to have all kinds of information sent, because what I've learned is developers will send data that they don't necessarily always need to have sent. They'll just turn it on and let the fire hose go. So you need to consider each of these different APIs and how do you want to secure them, because they each have different kinds of ways of doing so. Now there's some common API security threats that you need to understand one, and we'll get into just a few of these, but there's really four main ones to kind of consider injection attacks, broken authentication, sensitive data exposure and then man in the middle attacks. Now, your injection attack is typically what we've always dealt with is. An injection attack is where malicious code is injected into the API Right, and that by doing so, you could potentially have that code run, as it's based on what the API is, just going to run that actual code itself. The other one is broken authentication. This occurs when the authentication mechanisms that you're set up for your API are broken. They're not allowed, but yet the process is still allowed to work. This is where you can get into potential accidental exposure of data which could be sensitive in nature, and then that comes into another. Sensitive data exposure is when you do have this through APIs, is that now you have to understand what occurred and then you have to have the level of data that was exposed and how are the protection measures that you want to implement within them. And then, lastly, we're going to deal with man in the middle attacks. This is where the attacker intercepts the communication path between the client and the API server and they're able to listen to the information that goes in. Now think of it another way, is we have to deal with secure communication protocols. One of the big things that we deal with is as it relates to IPsec tunnels, and when you have an IPsec tunnel, it's an encrypted tunnel. Well, these API connections, these are not encrypted unless you incorporate additional security layers within these APIs to be able to do that. So just kind of keep in mind that it's just a better way of doing an IPsec tunnel between two locations. So, when you're dealing with secure APIs, one of the considerations you need to think about is how do you ensure that you have robust authentication enabled? So you have to have some level of strong authentication to make to have all of these work in a way that is beneficial for you and for your company. And if you don't understand the API connections and how they're authenticated, it's an important factor for you to kind of delve deeper into it. So, as the first thing you should see when you're dealing with APIs is how do I understand the authentication behind it? And then how am I ensuring that it is properly protected? Now, using OAuth or OpenID Connect. You need to understand that is a widely adopted standard when you're dealing with OAuth and it does. It provides a secure, delegated access that do allow the applications to act on behalf of a specific user, whereas OpenID Connect is an authentication layer on top of OAuth 2.0, which adds the identity. So a key thing to remember when you're dealing with test questions also is OAuth provides you the authorization to have this occur, whereas the OpenID provides the authentication layer on top of OAuth 2.0. And we've talked about this in a couple other podcasts, but you need to keep that in mind is, again, those are some key differences to understand between them. Now, token based authentication this is used to access tokens for maintaining a session state. So these, basically, if you want to keep your state enabled, such as an IPsec tunnel, where the tunnel is up and operational, that's, that session is there and available for you, and so this token based authentication can be set up to allow that to happen. It allows for more scalability, allows you to broaden that out and flexibility, and it does add for a level of security to ensure that that that session is still up and operational. Now, when we're dealing with access controls we've talked about these in the past Is role based access. Attribute based access are two key factors when you're dealing with API's. Now, role based access this is you understand is based on the individuals, based on your role. It could be within a user, could be within a manager. It's just based on specifically what your role is within that organization, and that would be the setup for the API. When you're dealing with attributes based controls, this is where you dynamic access is that set up Basically, that evaluates the attributes of the overall position, or overall, that the connection, and this would be the user, the resources, their environment. This is much more where are flexible and context aware than the role based access controls Now, because it is much more ability for you to be able to manage a little bit better. The interesting part, though, is is it does take a lot more, I'd say management of it, and I've used management a couple of times in that sentence, but you, you have to. I'm trying to use a good example of in the role based access, I can click it on and say Sean's got access, but when you're dealing with attributes, then I'm specifically picking out what attribute does Sean have access to which can add to the complexity which, in turn, because it's more complex, will cause issues with. If you, if you're trying to troubleshoot and find out why your access isn't working, if you get into attribute based access, you run in the risk of making it so granular that you end up breaking things, and then people get frustrated and so, rather than doing the granular security controls in which they want to do, they'll just open it all up just so that everybody has access to it. So that's where you, when you get into role based access, it can cause you some challenges. So another thing to consider is token management. Now, when you're going to deal with these, each of these API connections, they have a token and you want to have this token. Just think of it as a way is your security mechanism for your overall API connection. Now, when you're dealing with these tokens, transmitting them and storing them, is a very important factor in your overall protection of your API connection, and so what you'll do is that. I've seen it where people have automatically built it, where the token, more or less the password, is built into the API connection, and that's a bad idea, right? Because now you have this static password, the static authentication mechanism that is sitting inside your API connection, so it's real easy for it at some point to be compromised and now someone could connect into your environment with that API connection, with that token, and you would not know that it's a bad girl or bad guy doing that. So it's important that you have a good way to securely store those tokens and that they're only fetched when actually needed. You also need to have some sort of revocation around these tokens to ensure that when they like do password rotations, you will then expire these tokens and then reissue new ones. If you don't have a way to manage those, then, like I said before, the token will never expire, and if the token never expires, the password basically never expires. And so then you get into a situation where, if I'm a bad guy or gal, I take it, I take advantage of that token and now I can have unfettered access into your environment. So it's important that you have a plan on how to one store them, to revoke them, and then the third thing is is refresh them and get you new ones, basically do a password reset on those, because they do have. You want to limit the lifespan of these tokens so that they're not available indefinitely. So API key security you want to understand the fact, similar to the tokens, you want to have a way in which they're properly protected. Now API keys can be embedded within the API just simpler as similar as a token and this obviously makes it in a situation where it's much less secure than if you actually would have them in a repository where they're fetched when needed. So you need to make sure that you understand how do you store your API keys. This also can get very challenging when you're dealing with microservices and there's some challenges that get into the microservices architecture where you're dealing with the storage of these keys as well. So you want to always be looking for as you're monitoring how your API's are being used. One question that have seen is I've seen where folks have especially get lab or those types of code repositories where there's an API keys that are stored in the code repositories. So someone may have an API that they've created and they store it out there in a repository. Inside it they have left the key or maybe a token authentication token that is set up with inside that API key or API that they created and it's just sitting out there in that repository. Well, it's sitting out there just waiting for somebody to come along and grab it. So it's important that you are monitoring both the API and your code repositories and libraries to ensure that there aren't those secrets stored out there. Now I know I think GitLab has got a new product out that you will will actually gone, scan your code repositories looking for secrets, and it's a great thing to do and be able to use if it's possible. So I know that they're looking at new items for API's and some new trends that are kind of coming into that whole space. One is biometric authentication. They're using that in a relation to facial recognition and fingerprints as it relates to API's, especially in very sensitive locations. I think the only time you would have that is if you were pulling information from a server. I mean this probably the only time. I'm sure there's other places you would use this, but you're pulling information from a server. You want access to the information. Then you have to do a finger scan to be able to get access to that information. That would be one of one potential use case. Now they also have decentralized identity models. This is where they're using blockchain and other types of technology out there to help with API authentication. And again, it's a different kind of look at things A blockchain. You obviously don't know of that as it relates to the Bitcoin kind of world, but blockchain does have provide a lot of great way methods inside of it for allowing you to be able to use, especially in authentication pieces. That is unique and different, and I think it's pretty amazing how the blockchain piece can work. We've used it. I've used it and seen it used in various areas within companies that I've dealt with, and it's been very positive. That downside of it is it can be very clunky and kluji to work with, especially since it's all brand new and it's kind of like a technology trying to find a place to work, a place to home, and it's a bit of a challenge. But there is possibilities that it could be used within your environment If you really like that and you want to give that a shot. Another option is machine learning in authentication. This is where machine learning algorithms are being integrated into the authentication process to help detect if there's any anomalies that are occurring. I haven't seen this myself, but I've heard rumblings of it. It would be interesting to see how it plays out, but it's pretty cool if it can happen. So now we're going to get into what we call an API gateway and what, understanding what the process is around a gateway. So in this API gateway is basically a management tool that sits between the client and the collection of back end services. So, as an example, just think of it as a entry point into your environment. So if you have API, so you can either have an API that connects directly from the client to your server and you now have, let's say, 1000 different people and 1000 people set up API connections, and so now you have 1000 different connections into your environment. That's really hard to manage. Honestly, it's darn near impossible. So, rather than having that, what you would do is you'd have your employees or whoever's setting up these API connections, send them to what they call an API gateway, and this gateway acts as an intermediary, and now the all the information goes through the gateway, from one location to the gateway and then to another location. So it's just right. That's that stopping off point. The great point about a gateway is you allows you to do a lot of different things. One it gives you visibility into what is actually occurring within your environment. How many APIs do you have connected? Second thing is it also allows you to ensure that you have authentication that is enabled so that you can't just have anybody set up an API connection and they connect into your environment. So it's an important factor to to just force people down through this. In being a farm boy, the shoot where you would send the cows and the pigs, you would push them through us a center place is that you would run them through this shoot, and that's the same thing that the API is that you're pushing people through this API or through this gateway to ensure that they come into your environment in a way that is it's up to your security expectations. The other thing you can do is you can also throttle the connections that are coming in. So, like anything, if you have a connection coming into your environment, it takes bandwidth. Well, if it goes through a gateway, you can control the amount of data that's coming in and coming out, how fast it's coming in, and it allows you to give you some level is. I'm not going to go down the path of saying it provides DOS DDoS protection not DDoS, but DOS protection, denial of service protection but it can give you the ability to reduce that input. So if there is a lot of data coming in from your API connections, you can throttle that and a more or less rate limited. So there's a lot of benefits around that. Specifically, it also does simplify the API management, where you're not having to manage 1000 different connections and it's it can be very problematic. Now, one thing I want to warn you is that if you have a cloud infrastructure in place, one thing is if those cloud servers are exposed to the internet, anybody can set up an API connection, in most cases, to those servers. So you're going to want to really watch from a security perspective. How is the cloud connecting your cloud infrastructure? How are you allowing it access to the internet? If you're allowing it unfettered access, then you may have a bigger problem that you don't even know about and that that it might not be more than just the API is. But if you're allowing API connections and individuals to set up those connections to these systems, you may have a serious problem. So definitely keep an eye on what is your overall policy around allowing people to use APIs within your environment. So we're going to deal with rate limiting one thing around it. We talked about the aspects of the denial of service attacks and that this will help with that. Now, to be honest, we one of the things I've seen have seen API security folks talk about. Well, it will protect you against denial of service attacks and it may. I mean, I'm not the expert and there's other people that are the experts in their specific tools. The thing with with denial of service attacks is you have to have a way to dump the traffic. Now, if it's only limiting the traffic, the traffic gets coming in and it's only restricting it, it may not totally be stopping a denial of service attack. It may be stopping it inside your network but at the gateway you're still getting denied the service because there's just so much data that's coming in. You have to have a way to shunt it or send the data to a place that where it's basically dropped into a bucket that's never seen again. If it has that ability to do that, then you would have some level of denial of service protection against it. So when you're looking at evaluating API gateways, that's something to consider. The other thing around rate limiting that can happen is is it what it does? Is it allows the the different requests per second or per minute that are happening and it limits those to a specific users or specific IP addresses. So it will help that, in regards to what's coming in, to mitigate it or to shunt it Again. If you're looking at a good product out there to help you, you wanna make sure that you it does exactly as it says, because a lot of people say a lot of things but the technology may not actually do what you're asking for. And what you could do even is set it up so that they can demonstrate to you how that denial of service would potentially occur and then how their product would mitigate it. Another thing you're dealing with when you're talking about gateways is there's IP whitelisting and IP blacklisting. So basically comes down to is if there's an IP address that you want to allow no matter what to in your environment, you would put an IP whitelist within your API gateway. And the same goes for if there's an IP address that you do not want any access to coming into your environment, you would put a blacklist in place. Now the blacklist can get very problematic just because of the fact that you are specifying a specific IP address that you are not going to allow to communicate. Well, as we all know, ip addresses can change. The other thing is is that when you're coming in from different locations, if the IP address changes and you're trying to, you can't figure out why the connection is not occurring. It could be because of the fact that that IP was actually blacklisted. So most people will say don't blacklist unless you absolutely have to. Now whitelisting, on the other hand, can get out of hand because let's just say, for example, I'm gonna use the URL, but let's just go Googlecom, right, so Googlecom has its IP address of xxx, whatever that number is, and you go I'm gonna whitelist Googlecom. Well, you whitelist it and it's allowed into your environment, but Google's probably not the right word. Let's go sneakerstorecom. You allow this sneaker store into your environment but then, all of a sudden, the sneaker store is you know when it pays much attention to it and it gets hacked. Well, you've whitelisted the sneaker store and the sneak that individual is now has access directly into your environment, that company, because you whitelisted them and you don't even know that you did that because it happened, like three years ago. So IP whitelisting is a useful tool, but you need to manage it on a yearly basis and go through and make sure that these IP addresses that you had before are the same IP addresses that you still want to continue going forward with. So again, it's really important to do that. Now, the blacklisting works well when you're trying to deal with malicious sites. But we all know those IP addresses do change and unless you're really getting into a lot of challenges around that, where that site is just constantly hitting you, then you're gonna want to. You can blacklist it, but most people use the blacklisting with a little bit of caution. They just don't do it a lot, at least from my experience. Now that may be in other places that may not be the case. They may use it a lot. So one thing that happens a lot with APIs is the use in the microservices architecture, which is your cloud architecture, and using the cloud-based API gateways is a really good way for you to be able to funnel this traffic in through an AWS or Azure or Google Cloud platform. We've seen them. They're able to scale, they. You can put them on load balancers so they can spread out the load. So they're a really good way of doing that and I would highly recommend, if you're gonna have APIs, that would be a way to go about and push them into an actual cloud platform. You can have an on-prem environment where, but yet you have an API cloud or an API gateway in the cloud, so all of your APIs can go out to that gateway. They then can be shunted back into or sent back into your environment through that specific gateway. They work really, really well and they're just as all I've ever seen. I'm sure you can do it an on-prem version of that, but all I've ever dealt with are our cloud-based API gateways. Now they do have analytics that will help you with usage, that will help you with performance and also any security incidents that occur. This comes down to logging and monitoring as well. I would highly I've kind of mentioned it before I would highly recommend that you turn on some level of logging and monitoring within your API environment. You need to decide how much logs you wanna keep, just like everything else. The more logs you keep, the more you have to filter through. But with an API connection being that's coming from the outside, being the fact that there's thousands of them and you really don't have a good grasp of sometimes what are all those connections, a logging and monitoring on your gateway is really an important part, and then ensuring that you have proper protections around those logs that they're not tampered with In the event something bad would happen. Now there's various machine learning, or I should say machine learning capabilities or artificial intelligence capabilities, that are being utilized within API gateways to help mitigate some of the security risks that are associated with them. I haven't dealt with them personally myself, but I've read of them and heard of them, so there's different aspects you could potentially use and I feel the use of AI within security is going to be very revolutionary in the future. It's gonna get to the point where, with as many jobs that are missing that are we can't fill within the security spaces, ai is gonna have to fill that gap, just because, one, it can do a much better job than a human sorting through logs, but two, with the gap that we have in security, there's just no way you can fill it with people. They just can't train them fast enough. So the use of AI would be a very valuable tool in that. So when we're dealing with logging, we're gonna try to talk about some of the error handling that goes into that, and one of the things that you can deal with is I would recommend having a security audit done routinely of these logs and I would say routinely in the fact that probably about once a year, I would have that occur and I would do an audit of the logs just to see what is actually occurring Now. You could have a third party do that, or you could have your own security team do this, and you could look at what are the connections, how are the connections enabled, how are the authentication mechanisms enabled, and then you can also be able to dig into the logs to find out if the tokens are actually in the API connections themselves. And I would highly recommend you look at all of the different analytics that go along with the various API gateways that you have within your environment, and so it's probably good to do this at least once a year to ensure that you understand all these various connections. Another thing you can do is use automated or manual testing practices as well, and they have these automated tools that are like a dynamic application security testing tools or static application security testing tools that you can give to your developers to have them run through your code. So if they're creating an API connection, you can have this, these tools available. You have a developer and say, okay, what I want you to do is run your API through this tool. It'll run it through the tool, it will test it and then it will come back and tell you what are some of the potential errors that it may have when it does that. If you find gaps, then what you want it to do these are the processes in which you're going to fix them. In many cases I've seen time and again is that developers will embed the keys or the authentication tokens into the overall API connection, and so you're going to have to have a method to teach them how not to do that and what is what does good look like. So you want to have that as a potential testing platform for them. You could have manual testings as well that are set up that you could have a concept where, instead of having these tools, these these are the various testing platforms you can use, and I, from a manual standpoint, I'm not sure how you would do that other than going through the API connection specifically, one by one. One option is, from a manual testing point of view, is having it given to another developer and having them run your code and doing a code review on your API. By doing that, they may catch things that you would have missed. Api is typically their code is very small. It's very lightweight. There isn't a lot to it. So, unless you are specifically not paying a lot of attention. You would be able to see if the tokens or the the keys, are stored within the, the actual API code itself. But bottom line is having a code review done is a probably a good idea. If you do not have these access to these automated tools to help you with that, the other thing is through the use of a continuous integration and continuous deployment pipeline. You know GitLab has these pipelines and I would highly recommend that you use them. So they call them a CI CD pipeline. But bottom line is you put something in this pipeline, it goes through it and then it comes out the other end and it will tell you where there's errors within your code. If you have any sort of development shop out there, ci CD pipelines are a very important tool that they do use when they are in their development work. So if you don't know, I would highly recommend you talk to your development team and see what they have in place and then see how you can embed yourself from just maybe from an influence standpoint within your development team on how to ensure that they have proper coding practices, that it relates to both the API's and to any sort of development work that they're doing. You have to, as a security professional, it's important that you stay really connected to these folks. I have found more and more issues with my development guys and gals. Not because they don't. They don't want to do it good, they do. They want to develop really good code. They take pride in developing very good, very clean, very it's almost like an art form very pretty code, but they don't understand the security nuances around that and it's important that you help transport that or transpose that information to them. So just kind of keep that in mind as you're you're looking to help develop your security team and to help influence others within your organization. Last thing I want to bring up is just some of the challenges and best practices you want to deal as it relates to API's One. You want to keep up with this evolving threat. It's constantly changing. It will not, you will not be able to stop it. It's going to continue to change and so therefore, you, as a security professional, need to change as well and you need to stay abreast of these technology changes. So I'll tell you that, like I mentioned before, api's and development is not my strong suit, because that really just I learned more in the infrastructure space, but I've learned a lot having a development team work for me. I learned a lot about how development actually works. I am by no means an expert in development and there's a lot of people out there that are way smarter, way smarter, and so therefore you need to lean on those individuals when you are in the security space of how can they help teach you what you don't know. So you need to keep a ball up on any evolving threats as it relates to the development world. You also need to balance security with functionality. So we talk about this a lot that a system may be super secure but it is not functional. If you people can't use it, it's of no good to the company. So you need to allow it to be functional, but just secure enough that it protects the company from risks. Now you have to, as a security professional, have to ask yourself is it protecting me from all the risks or some of the risks? And then you have to be able to communicate those risks to the stakeholders. So you're senior leaders of going yes, this is the risk you're incurring by doing this. As long as you're okay with that level of risk and what could potentially happen to you, then let's move forward. We put security mechanisms in place to mitigate everything else, but these are the risks you're going to have to either live with or I can add even more additional security, but it will cut down on the function functionality, and then that's where the stakeholders have to make the decision which way to go. So you have to balance that out between security and functionality. And then, last thing, is training and awareness. You need to teach people how to make this work. It isn't intuitive. They're not IT. They don't understand it. And even if you have folks that are IT individuals that are doing API development, they may not understand it, but always assume goes to the lowest common nominator. Do not think of them as how to stump the dummy, how to teach the idiot. We don't talk on those terms because, in reality, they're very smart in what they do. They just do something different, and I learned that when it came to the finance space. I had an individual setting up API connections, and he's in finance. Okay, one. He didn't understand the API, so we had to walk through that, and I also brought in somebody who was an API expert to talk to him about that. The other thing is, though, he understands finance really well way better than I could ever dream of understanding finance and so it was a really good marriage between the two of us so that we could learn something about finance and how they wanted to use the API connection. He, in turn, was able to learn how to better secure it and how an API connection actually works. So it's important that you don't go into the assumption that these people just aren't very smart and I know that my listening audience they're not thinking that way, but I've seen IT individuals think that the user just isn't very smart. Well, they're not very smart in many cases around IT, but they're really intelligent in areas that are outside of IT. So if you're going with that attitude, you will have much higher success when working with the actual customer, which is what our ultimate goal is. All right, that's all I have today for API security and API protections. So again, today is Monday, so you get the training around this the API Thursday. Make sure you tune in. On Thursday you will have the questions that are going to be associated with today's training. All right, I hope you guys have a wonderful day. You can catch me out at CISSPcybertrainingcom CISSPcybertrainingcom. There's some great content. All this content is out there and available for you. It's going to be. You can just go out there and you can get it. There's a lot of free CISSP questions that are available to you on CISSP, cyber training, as well as courseware to help you pass the CISSP exam the ultimate goals. I've got more students that are passing the CISSP, and the training that's provided through these podcasts and through the training that I have out there has been invaluable to help them pass the exam. I have a blueprint that walks you through step by step by step, on what you need to do to study for it. I'm developing an accountability program that will help keep you accountable, and then there's also some new training that's coming out and some new interactions one-on-one with me that you can get access to as well. Other than that, that's all I've got. I hope you all have a wonderful day and we will catch you all on the flip side, see ya.