CCT 099: CISSP Practice Questions - Understanding APIs and the Security Principles (CISSP Domain 8.5)

re you prepared to crack the code on API security and sail through your CISSP exam? If yes, then embark on this enlightening journey with me, Sean Gerber, as we decipher the intricacies of API and REST API security. We’ll tackle questions about securing API keys, delve into the pivotal function of an API gateway, and demystify common API security threats. You’ll also get a grip on the role of OAuth 2.0 and input validation in protecting APIs. 

Hold on to your seats as we traverse the digital landscape, picking up REST API security best practices along the way. We’ll delve into the gravity of TLS and SSL, and shed light on the significance of OAuth 2 in RESTful APIs. You'll gain insights on secure API design and learn about data masking, the principle of least privilege, and secure endpoint design. But that's not all - we'll discuss API logging and how an API gateway can beef up security in a microservices architecture. We’ll round off with a sprinkle of career counseling to guide you in your cybersecurity journey. Tune in, soak up the knowledge, and let's ace that CISSP exam together!

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, all of you, sean Gerber, with CISSP Cyber Training, how are you all doing this amazing day? Today is the epic day that you all have been waiting for. Today is CISSP Question Thursday. Yes, yes, today we're going to be talking about CISSP questions as it relates to APIs. Now, if you've been new to the CISSP Cyber Training Podcast, one thing that we do is we, on Mondays, we'll go over content and then, on Thursdays, we will then talk about the CISSP questions that go along with that. So today we're going to be getting into what we call basically how I haven't laid out in my CISSP courseware is in various groups. So I have all these gobs of questions that you can go and get at CISSP Cyber Training and you can get access to them to be able to study for the exam, and it'll actually give you quizzes you can go through and then take the test and then from there you can go and see how you do. As it relates to the questions Now, I've got right now hundreds I'm approaching probably close to a thousand questions that I have on the CISSP Cyber Training site. It's probably more like about 700 is probably what we're at, and it has got everything you could ever need to study for the CISSP exam. So what we're going to do is we're going to go over a group of questions that are going to be focused on domain eight and we're dealing with eight dot five, and this kind of focuses on API security. So some of the questions are and we're just going to roll through these and then we can talk through them as the explanation comes around, alright. So question one which of the following is a best practice for securing API keys? A embedding them in a client side code. B hard coding them in the server side application. C storing them in a secure server side environment variable or. D sending them via email for easy access. Now, if you're not connected with APIs, you think of it just as no difference. It's just an automated process. It's allowing connections between two points. So if you want to have the best practice for securing these API keys, that would be storing them in a secure server side environment variable. Now what that really basically means is you don't want these to be exposed to the client side, basically the code on the back end. You don't want to have people having access to the overall security or the code, that themselves, the credentials, so that those can be intercepted in the conversation that is communicating between the APIs. So you want to have that set up in a server side environment variable where it reaches out and grabs those and then utilizes them and then they're destroyed at that point. So it's not a situation where it's actually hard coded within the actual API key itself or the API connection. I should say I've seen this happen with cloud environments. It's really cool where it'll actually. You have the variable called out in the code. It then reaches out into a key management system, uses that from that variable, uses the key itself and authenticates, and so it's never actually physically exposed in the API transmission whatsoever. I know there's a lot of stuff there, but it's a secure server side environment is where you want it. So if you're bearing through these questions and you're trying to figure it out, one of the things is hard coding that's bad. Embedding that's bad. Sending them via email that's bad. So you can narrow it down to that. Third question or third answer. I should say what is the primary function of an API gateway in API security? A rate limiting, b data encryption, c user authentication or D both rate limiting and user authentication. Again, what is the primary function of an API gateway in API security? And the answer is D both rate limiting and user authentication. When you deal with an API gateway, it does serve multiple functions, which would include rate limiting to prevent API abuse, and user authentication as part of the access control that allows access in and out. Okay, so when it comes right down to it, the overall secure environment, data encryption is not a primary function of the API gateway. It's a method, it's used, but it is not the primary function of the overall API gateway. And three, which of the following is not a common API security threat? A injection attacks. B man in the middle attacks. C data encryption. Or d broken authentication. So if you look at all of those, the only one that doesn't sound like an actual threat would be data encryption. So, again, which of the following is not a common API security threat? And that would be data encryption. That is a security measure, not a threat. Injection attacks, man in the middle attacks and broken authentication are common security threats that are faced by APIs. Question four in API security, what does OAuth 2.0 provide? Again, in API security, what does OAuth 2.0 primarily provide? A data encryption, b authentication, c authorization or D data integrity. Again, what does OAuth 2.0 provide? Now, if you think about OAuth, what is OAuth? Oauth deals with authorization, so the answer would be C. Oauth 2.0 is an authorization framework that does enable an application to obtain access to the user accounts through the HTTP service. So it deals with authorization, not authentication, encryption or data or the overall data integrity. So you wanna make sure that you're dealing with. Oauth is authentication, or I should say authorization, not authentication. Sorry, it's even challenging for me. All right, what type of attack might be mitigated by implementing input validation in APIs? A D-DOS attacks. B SQL injection, c phishing or D eavesdropping. Again, what type of attack can be mitigated by implementing input validation in APIs? So, again, input validation. You have an input that you're putting in. How does it validate that? What's going being put inside it? And that would be a SQL injection. That those again, that's answer B. Input validations do help prevent SQL injection attacks by ensuring that input data does not contain malicious SQL code that could be executed on the various databases. Question six what is the primary purpose of rate limiting in API security? A data encryption, b reducing server load, c preventing API abuse or. D user authentication. So what is the primary purpose of rate limiting in API security? And the answer is C preventing API abuse. Rate limiting is implemented to prevent API abuse, such as DDoS attacks, and to ensure the fair usage among consumers by limiting the number of requests that are being occurred through the users at any given time that they're producing. So it is preventing API abuse. Question seven what which is not recommended best practice for API error handling? A providing detailed error messages, b logging errors for monitoring, c custom error handling or D masking sensitive error details. Again, which is not recommended practice for API error handling? And the answer is A providing detailed error messages. Why is that a bad idea? Because in many cases, you can provide or expose sensitive information or system details to potential attackers. I used to do this when I was working as a red teamer. We would try to see what we call it burp, or throw up what information it could give us about the overall server that we're trying to hack and therefore, if you give out those that key pieces of information, it could give the attackers details on the system that it's residing on. So you want to avoid those types of things. I mean maybe kind of a direct contact trash to what you're thinking, because if there's an issue you want to provide that information to them. But it can give the attackers information they do need to get able to craft their attack a little bit better. In the question eight, in the context of API security, what is the main benefit of implementing an IP whitelist? A increase API's performance. B allows only requests from known and trusted sources. C encrypts the data in transit. Or D provides user authentication. Again in context of API security, what is the main benefit of implementing an IP whitelist? And the answer is B allows only requests from known and trusted sources. So whitelisting again in API security does allow for access to only requests to come in from the known and trusted sources and therefore everything else would be blacklisted, would be blocked and dropped. So it's a great way if you know where your connections are coming from, it's a great way to add another level of protection. Question nine what is the primary security concern when using RESTful APIs? Okay, so you have to understand what a RESTful API is. So A excessive data exposure through the broad endpoints. B high computational overhead. C lack of support for HTTP methods. Or D automatic encryption of data. So RESTful API, the way I understand it, is basically it's always waiting for a call and it's it's resting, but resting is not the right word, but it rest stands for an acronym that goes with it but a RESTful API. Again, one of the things that happens is that they are constantly there waiting for data to come to them. So one of the security concerns with a RESTful API is the potential for excessive data exposure through poorly or broad design endpoints, which does give the attacker access to more data than is specifically necessary. And I've seen it with some of my developers when they'll put in a RESTful API connection, it will provide more data if they don't limit it to what it can do. So again, the answer is a expect excessive data exposure through broad endpoints. Question 10, what does the role? What role does TLS and SSL play within API security? Question 10, what role does TLS and SSL play within API security? A authentication of users. B encryption of data in transit. C authorization authorization of requests. And D storage of API keys. Okay, so what role does TLS and SSL play in API security? So you need to know and understand what TLS and SSL do. So what do they do? They deal with encryption right. So that would be B encryption of data in transit. Tls is transport layer security and SSL obviously is secure socket layer. These are both protocols that are designed to provide communication security over computer networks. Now SSL has been deprecated and they are highly recommending TLS in all these conversations or all these communication paths. However, it still is out there being used. So you want to ensure that if you are using SSL, you try to migrate to a TLS type environment as fast, as soon as you possibly can. But again, they're designed for encryption between the client and the server. In Q1 11, in API security, what is the purpose of implementing OAuth 2? Okay, and API security was the purpose of implementing OAuth2. We might be thinking, oh well, I just had this question. Haha, you did, but it was a different answer. So one of the questions is answer is encrypting stored data. B is invalidating user inputs. C delegated authorization. Or D logging security events. Okay, so when we talk about OAuth. We're talking about the fact of authorization, not authentication, and authorization would be C delegated authorization. Oauth2 is used for delegated authorization, allowing third-party apps to access user data or perform actions on behalf of the user without exposing the user's credentials. Question 12, which is a following is not a component of API, of secure API design? A data masking, b principle of least privilege, c secure endpoint design or D rate limiting. So which is not a component of secure API design? I can focus on the word secure, and the answer is D rate limiting. Even though it's a part of API management right, we talked about that earlier it is not a component that is around itself as a secure method for API designs. Data masking, principle of least privilege, secure endpoint designs those are all part of a secure API overall design plan. Question 13, which is a key aspect of API logging for security purposes? A storing user passwords for accountability. B logging sensitive information such as API keys. C detailed logging of all API transactions. And D avoid logging of personal information or personal identifiable information, or also known as PII, which is the key aspect of API logging for security purposes. Why would you log API calls? And the answer is D avoiding logging of personal identifiable information, so let's keep part of that. So, while logging is important, it's crucial to avoid logging of any sensitive information, such as PII and the API keys that you may have as well. That protects the security of the connection as well as helps with the privacy aspects of the API connection themselves. Question 14, what is the main advantage of using an API gateway in microservices architecture? So you got to understand what the API gateway is. We talked about that in a question earlier and you got to understand what microservices are A reduces the number of microservices needed. B centralizes user authentication and rate limiting. C encrypts data stored in microservices. Or. D automatically writes API documentation. Okay, so again understanding what is the gateway. It's just basically a central point and microservices are basically code that's running servers and server type activities. So it's B centralizes user authentication and rate limiting. The microservices architecture and the API gateway will centralize common tasks such as authentication and rate limiting, thereby avoiding these individual microservices and of multiple places and then reducing redundancy. And also by having that centralized point, you do allow security to be focused in one central spot, versus having to ensure each of these connections is secure. Again, when you're dealing with API connections, api connections individually are fine as long as you can control them. But as soon as you can have the ability to start growing these API connections beyond just a few, then it becomes very problematic and quickly you will lose control of the security of these systems because unless you have a very good process in place to ensure that security is enabled in all of these APIs that are being produced for your company. Question 15, the last melon, the last question why is regular key rotation important in API security? Well, that kind of makes sense, right? You want to kind of think about a key rotation on anything, but let's talk about API security. A it enhances the performance of encryption algorithms. B it reduces the complexity of encryption process. C it minimizes the risk of key compromise over time. Or, d it's a requirement for all encryption standards. It's again why is it a regular key rotation important within API security? And it is C it minimizes the risk of key compromise over time. Like everything else, if you do key rotation or passive rotation, it does help minimize the risk of a compromise. If a key is compromised, rotating it ensures that the compromise key is invalidated after a period of time, thus reducing the window of an opportunity where an attacker could potentially exploit it. So it's important to do key rotations with APIs. Now, if you can do this automatically, that is ideal because it's starting as you like we've mentioned before, as soon as you start getting a lot of APIs, that becomes extremely problematic. So think of APIs and no different than service accounts. They're all very similar, just in a different architecture. Okay, I hope you guys enjoyed this. Again, the CISP cyber training has got all the stuff you need to be successful and pass the CISP exam. In addition, I've got some counseling or I should say consulting coming up, as it relates to how your career is going to go. I am here to help you with your CISP journey. I get asked on a weekly basis what would you do about this? What would you do about that? Let me help you with your CISP and your cybersecurity journey. I am here for you, bottom line. That's what we're here for. All right, have a wonderful day and we will catch you on the flip side, see you.