CISSP Cyber Training Podcast - CISSP Training Program

CCT 293: CISSP Rapid Review - Domain 8

• Shon Gerber, vCISO, CISSP, Cybersecurity Consultant and Entrepreneur • Season 3 • Episode 293

Share episode

Send us a text

Quantum threats aren’t waiting politely on the horizon, and neither should we. We kick off with Signal’s bold move to deploy post-quantum encryption, unpacking the “belt and suspenders” approach that blends classical cryptography with quantum-resistant algorithms. No jargon traps—just clear takeaways on why this matters for privacy, resilience, and the pressure it puts on other messaging platforms to evolve. We point you to smart reads from Ars Technica and Bruce Schneier that make the technical guts approachable and actionable.

From there, we switch gears into a focused CISSP Domain 8 walkthrough: how to weave security into every phase of the software development lifecycle. We talk practical integration across waterfall, agile, and DevOps; show why change management, continuous monitoring, and application-aware incident response are non-negotiable; and explain how maturity models like CMMI and BSIMM help teams move from reactive to repeatable. We also break down the developer’s toolbox—secure language choices, vetted libraries with SCA, hardened runtimes, and IDE plugins that surface issues in real time—so teams can ship faster without trading away safety.

Speed meets rigor in the CI/CD pipeline, where shift-left security comes alive with SAST, DAST, and SOAR-driven checks. We cover repository hygiene, secret scanning, and how to measure effectiveness with audit trails and risk analysis that map code issues to business impact. You’ll get a clear view of third-party risk across COTS and open source, the shared responsibility model for SaaS, PaaS, and IaaS, and the daily practices that keep APIs from leaking data: least privilege, strict authorization, input validation, and rate limiting. We close with software-defined security—policies as code—bringing consistency, versioning, and automation to your defenses. Subscribe, share with a teammate who owns your pipeline, and leave a review to tell us the next Domain 8 topic you want us to deep-dive.

Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

Join now and start your journey toward CISSP mastery today!

SPEAKER_00:

CISP sniper screen screen and CISP Hi my name is Sean Gerber the information you need. CISP and roll your cyber checker in the way.

SPEAKER_01:

Good morning, everybody. It's Sean Gerber with CISSP Cyber Trading and hope you all are having a beautifully blessed day today. Today is CISSP question Thursday. But today we are going to finish up our rapid review domain or exam prep for domain eight. Yes, the final one, the final melon, the final one we're gonna go after is domain eight, and this is of the CISSP rapid review provided to you by CISSP Cyber Training. You can get all of that at CISSP Cyber Training. Okay, but before we do, before we get started on that, wanted to talk about an article that I saw in the news today, which was awesome. It's actually super good. I mean, if you guys are use any sort of encryption, this is a great thing. And uh this is from SI basically Ars Technica, and it's about some post-equantum encryption that Signal is going to deploy, or is in the process of deploying. Now, I'm not going to try to elaborate on this more than my little pea brain can provide you because it's pretty in-depth, and I highly recommend that you go and you read it. It makes sense when you read it, but tried for me to explain it to you, I would probably butcher it, and somebody would, when my audience would go, uh yeah, dude, you're wrong. Uh no, so I'm not even going to attempt to do that. However, I'm going to bring you out some of the big buckets, some of the big things for you to take away from this so that you have a good plan and understanding of what this article is about. So it's in Ars Technica. I will warn you that there is all kinds of advertising that will drive your mind or numb, and uh there's so much flickering lights that you may actually may go into a spasm. But that being aside, um, the ultimate point of this is that they're talking about the fact that we know encryption at this point is breakable. With the quantum computers that are coming out, it's close to being to a point where at least in the lower level of encryption is crackable through quantum computing. It hasn't been able to get up to the 256 and so forth, but the higher numbers, but at this point, the US government, through the National Institute of Tech Technologies, uh, Standard and Technologies, has recommended that you will look at some sort of post-encryption capability for your tools. Well, Signal has done that. And what they did was is they they added I'm not just gonna quickly brush over some of the key points here, but there's a double ratchet and then there's a triple ratchet. And what they really basically did was they added, they blended both of these products, old school crypto and new school crypto, and they created this third ratchet. And it has the ability to run with that capability, with both the algorithms working together, as well as if one of the algorithms breaks, it can operate and degrade or go to a lower level. So it's not it can actually still operate if the uh higher algorithm works and the lower algor one of the lower algorithms does not work. So it's got a good way to mix all of that together. And they call it the Belt and Suspenders approach. Uh, but bottom line is that they are working with PQS Shield, AIS, Japan, and New York University to be able to get all of this done and publicly uh disclosed for everybody so you can actually see what they're doing. So now why is this such a big deal? Um, it's one of the first large-scale real-world messaging systems, obviously, if you use Signal, uh, that is quantum safe encryption. That is true. So you don't have the the metas of the world and you don't have the the apples of the world. Those are all there, right? They're fine, then people use them, but it's not quantum safe encryption. And Signal has always set themselves apart by kind of pushing the envelope in this space. And I I moved off of um my Apple type of uh texting for my normal business activities because I just didn't like the welln't like the way it felt and the the aspect around the encryption piece of this. And now that Signal is moving, I'm gonna begin moving my family over to Signal, at least the ones that I care most about, because I really do feel that this is a really great move, a super great move. Um, it does help keep the the regular classical machinery in place, like the the double ratchet that they have, but they also layer the quantum uh resistance algorithms on top of it. So it does, it works really good for the old school and the new school, supposedly. I have yet to test it. So I'm just giving you what the article is talking about here. Now, one of the big aspects that they say is that obviously we have to, as a as a group, as security professionals, we need to make sure that we are pushing this type of activity out to our vendors. We need to push them on them to say, you need to up your game when it comes to encryption. We as enterprise architects and and as CISOs and as security professionals for various companies need to demand that one from external vendors, but two also from our internal staff and not just say, okay, well, we've protected our outer donut. You know, we're everything's good and hardened on the outside, but once you get on the inside, it's soft and gooey. We need to make sure that the areas inside that need this kind of layered protection are getting the encryption they need to be able to protect the data transfers between points inside the network. So again, it's a double-edged sword here. It's really important that we do this. It's gonna take some time and energy, but now that the fact that uh signal has done this, it's only gonna you're only gonna get more pressure on the other messaging platforms that are out there. WhatsApp, uh when you're dealing with Apple, you're dealing with Google, all of those are gonna all start getting more pressure to incorporate this level of security within their tools as well. So it's super good. I love it. It's a great, great concept, a great article. I would definitely recommend reading it. Just take some time and go through it and give yourself a little bit of extra time doing this. Um, the other thing you want to may want to read is an article from um Schneer. I can never say his name. Schneier. Uh, this is another one where he's kind of goes through it a little bit more in depth. I really like him. He breaks down crypto in a way that makes much more sense to people like myself that's got a third grade education. Uh, so it's it's really good. And um, so I would recommend you read his article, then from there, he's got some links into the Rs Technica article as well. So good place, good place to start. But let's get started about what we're gonna talk about today. Okay, this is CISSP Rapid Review Exam Prep Domain Eight, Software Development Security. Okay, so these are the question questions per domain breakdown, like we've talked about so many other times. But this is domain eight. There's about 11% of the CISSP questions that are available on that test. Now, like we've talked about, this is computer-aided testing, and so it's going to uh work with you. And if you make start making mistakes, it's going to start adding more questions that are harder onto you. But about 11% of the overall question bank is considered part of the software development security. Now, I will tell you that this is probably one of the areas that people struggle with most in the CISSP exam. And the reason is because they just don't deal with it. And they just don't, they don't really deal with it on a daily basis. Now, this is obviously isn't everybody. There's many people out there that deal with software development routinely, but as an overall whole, it is probably one of the least known areas of the security space. And that is actually changing dramatically because as we see all of this software development that's occurring now, everything is running on some sort of application. That is even more important that you understand software development. Uh, and looking back at myself in a previous life, as a CISO, I didn't have really much background in software development. So I went to my CIO and said, hey, there was a software development team that was in our multinational that we had, and it was global, and they were dealing with all kinds of fun stuff. I said, I want to take those guys on. I want to lead them, I want them to be part of my team, and it was done for two specific reasons. One, they needed a leader, so I wanted to show that I could help lead this group. Two, they didn't, I didn't understand software development. And since I didn't understand software development, I wanted to have an opportunity to learn how to grow my knowledge in software development and be able to pass on security to them. So that was the purpose of around me doing this with my the development team that I worked with. Now, that being said, it was a great opportunity and I loved it, and I learned a lot from it, and I also learned what I didn't really truly know. And since then I've learned to grow that knowledge. However, my knowledge is very small in relation to many others, and so I would highly recommend that you go out and you get as much knowledge around the software development side as you can, especially before you go and take the CISSP, because there will be questions on it, and if you're not prepared for those, they will bite you pretty hard. But before we get into what we're gonna talk about today, I wanted to throw out my free resources and paid resources at CISSP Cyber Training. So there are the free resources. I have got tons of information out there for you. I've got a three to five month study plan. I've got questions, over 360 questions that are available to you. All of the rapid review content is there. You can get access to my blog. Everything is accessible through CISSP Cyber Training. Great, great content out there and available for you. If you need a little extra help and you want a bit more of uh hand holding and a bit more knowledge and depth, then you want to look at my paid resources. And again, I've got over 50 hours of video covering all the CISSP content, over 1,500 CISSP questions. I've got a 250 question quiz that is at you'll get at the end of your training, uh curated audio and video content. I got deep dive topics, all of those that are available to you. If you're needing virtual CISO, any sort of IT leadership or consulting, I have that through my through my partners that I work with that can help you from red teaming all the way up to virtual CISO to in SOC implementations. So everything is there, it's available to you at CISSP Cyber Training. So go check it out, go sign up for my free content. It does not cost you anything, and there's a lot of free stuff out there that I guarantee you will help you with your CISSP. And even if you're not taking your CISSP, it will help you in your cybersecurity training knowledge as you build this within your own organization. Okay, so let's start with domain 8.1. So this is 8.1, and we're gonna understand and integrate security in the software development lifecycle. Now, like we've talked about this about life cycles throughout these rapid reviews and throughout the CISSP training, they are an important part, and that's basically from birth to death. The ultimate point is you want to have some sort of development plan on how you're gonna birth something and then how you're going to put it in the ground. And this is an important part when you're dealing with development methodologies as well. So you need to understand the various software development approaches, obviously, waterfall, agile, DevOps, all of those you need to understand while integrating your security activities into each phase of this chosen methodology. So, what methodology you want, waterfall, agile, whatever it might be, you want to then incorporate security activities into these. Now, one thing you need to avoid is do not do where some people are kind of gravitating toward I'm seeing at least, is they'll implement security within these methodologies, within these frameworks. And what ends up happening is they just set it and forget it. And they don't actually then tweak the security implementations here, and it can then cause more drama down the road. So you're gonna have to, it isn't something you just throw in place and move on to the next topic. You need to put it in and you need to have some care and feeding with it. Now, there's maturity models that go along with this. These frameworks are used to assess and improve the maturity of your organization's software development security processes. And you as you start off, you're not gonna be very mature. You're barely gonna be able to walk. But as you get better walking, then you'll get to running, and then you'll get to sprinting, and that's the whole point of it. Now, there's examples would be the CMMI, which is your Capability Maturity Model Integration, or BSIMM. This is your building security in maturity model. These are different examples that are part of the maturity models for uh DevOps. Now, you need to ensure that the ongoing security in the software is deployed, or after you deploy it, you need to make sure you maintain it and keep it up and going. This includes activities like continuous monitoring, incident response for application-specific issues, and performance management. So the the whole once you put these, it's like everything else, you put the tools in place, you do have to continue the care and feeding, the monitoring of it. You need to make sure you have incident response in place in the event that something bad happens. You can respond to it. Uh, if you're a fully set up software development shot shop, your incident response needs to mirror how that would work. If you have on-prem, you're in a hybrid model or on-prem and cloud, how does that work? Do you have third parties involved that are doing your development work and then how do you report to them and to give them notification that something's occurred? And then on the flip side, how do you then notify your regulators that something has occurred and your customers? So all of that has to be done and created for your organization to be successful in this SDLC. You also have to have change management, which we've mentioned over and time again, is that you have to have a formal process that's implemented to control and track all modifications to your software. And this is this can be done through tools, um, this can be done through even spreadsheets, but you need to have a way to track what modifications have you done to it. Because there's one, you're going to get audited. Two, if something goes sideways, you have the ability to go back and look at what happened with it. What did you do? What changes did you implement? So you really need to make sure that that is a formalized process. Do not do this off the hip. You need to make sure that no matter if you start off and you say, hey, we're starting our brand new development team, begin this process with understanding your change management to begin with. Do not just go, well, hey, we're gonna start making some stuff and we'll just kind of throw stuff on the wall and see how it works. Yeah, that getting things started and doing that is is fine. I say that out of both sides of my mouth, because you want to show some sort of work. However, if you're doing that, you need to make sure that you at least have some sort of documented change management. Even if it is just a spreadsheet, what did you do and how did you do it and why did you do it? You need to ensure that security impact assessments are performed for every change. So this is something where, depending upon the location of where it's at, especially in software development, you need to understand the security assessment that may go into that. And do you it could be a very large change or a security assessment that you feel you need to do, or it could be just a couple questions that you need to ask yourself. So you need to understand what would that security impact assessment look like. Work with your CISO if you're a developer. If you are the developer and the CISO and the security guy and the analyst and the engineer, then just kind of think about what are some questions that you should ask yourself about before you deploy anything like this. The other thing to consider is that at some point, if you are just that one person or two people, you're gonna grow at some point, hopefully. So if you do that, you want to at least put some of these processes in place now. So that way when the team comes on, they understand what they're doing. Integrated product teams is IPTs, these are multiple distant multiple multiple. Yeah, they're a bunch of people that can know how to do stuff. They have lots of disciplines, right? They're a team that's responsible for the entire life cycle of the product system. So we would have product teams, and these product teams would come in and you'd have a person from HR, you'd have a person from finance, you'd have a person from whatever, and they'd all be part of this integrated team. So when you're deploying this product, they have insight into what they want it to be. Now there's user acceptance training or testing that occurs at the end, and if the user that is going to be accepting it is HR, then you'd always just work with them. But in so many cases, when you're dealing with applications that are touching HR, legal compliance, um, you know, production, operations, all of those, you'll want people from each of those sections in the development process, at least in some form or fashion. The reason is because if they've got it, if they got any skin in the game, if they have any sort of insight, that would be the time for them to tell you that, hey, no, don't do that, because if you do that, it will cause an impact over here. That's why these integrated product teams are really important. Uh, and again, but they do add a lot of headaches because it's a lot of opportunity cost to bring all these people together to be able to go over these types of development changes. So use them sparingly, use them wisely, but they are extremely valuable, especially if your applications do touch multiple areas. So this would include security professionals working alongside developers, operations, business stakeholders, all of them, so that security is embedded in the start. And it also is very helpful for the operations folks so that they understand what is security. Why should I be concerned? So often my operations teams wouldn't understand security. And so what would they do? They would then ask me questions or they would just ignore us because they're like, that's a security guy. It's the geek sitting in the corner. Um, that you need to make sure that everybody is engaged and involved. Now, this will take leadership from the top down. I mean the CEO down is going to have to be the one that's going to help to help direct this because in many cases the the minions won't want to do it because it's just added time. It's more time and more energy for them. Okay, domain 8.2. Identify and apply security controls in the development environments. So programming languages. The choice choice of a programming language can impact security substantially. Some languages do offer more memory safety or built-in security features than others. And so understanding language-specific vulnerabilities and secure coding patterns is crucial. So, what does this mean? If you're already developing in C, which is really old, but let's say you're doing that, you will have to work through some of the security challenges that may go along with that. And you say, I've been working this for years. We cannot migrate anybody off of C. We're stuck with it. Well, then that's a different conversation versus going, we're Greenfield, let's get started. We can do all of this immediately. So those are different types of conversations that you may have to have. You need to understand the languages being used. And understanding language-specific vulnerabilities and secure coding patterns is an important part because you, if you know the vulnerabilities out there, you can then head off any sort of questions that your development team may have. And it helps them to understand how should they do secure coding from the beginning. Now, libraries, these are reusable, not reusable, reusable blocks of code that provide specific functionality. And you'll see this where there's just a repository that are all sitting there with different types of capabilities in these libraries, and you can pull from these libraries to put that in your code. The thing is with this is that there's code libraries you've created, and then there's open source libraries that were created by the masses. The problem is that if you grab open source libraries, they can be very, very valuable. They also can be very buggy. They also can have lots of issues with them, potentially malware. So you need to keep that in your back of your mind as you're moving this forward. You also must be very carefully vetting on any known vulnerabilities that could be potentially out there. There's software composition analysis tools or SCA tools, and they can help work through your libraries to determine if you have some sort of vulnerabilities that might be associated with those. Tool sets, you need a collection of software tools used by developers. This is obviously your compilers, your debuggers, any sort of automation tools that are out there. These must be secured and configured to support secure development practices. We had user acceptance training testing tools, and these user acceptance tools would automatically do push buttons, they would automatically run the code, but you want to make sure that those are actually secure as well. Because if you run some sort of development code in there, it depending upon where your development area is at, if it's in, if you're just testing on production, uh these tools could actually cause substantial challenges to your organization. Not that you would actually do that. Testing on production is not a good idea. I would highly dissuade you from doing that, but it has happened and I do see people doing it. They're like, well, let's just give it a shot and see what happens. Don't do that. Uh integrated development environment or IDE. This is where software applications that provide comprehensive facilities to computer programmers for software development. That's lots of big words. It's basically an area that they can operate in and that the computer programmers can play in to create their product. It's an IDE. They can integrate security plugins such as SaaS tools, uh, Linters, and also to provide real-time security feedback for your developers. So an integrated development environment is an area set up specifically for them to develop their tools and for them to develop their programs and have them available to test and to run. Runtime. This is the environment in which the program actually executes, right? So and you secure the runtime environment basically through container security, virtual machine hardening, et cetera. Those are different ways you can do it. And it's critical to prevent code execution and vulnerabilities. So you it's an area that's like a sandbox where you would operate and run your virtual code in a virtual machine or a virtual type environment. And then that is what you typically in a test type environment. Once you do all of that and everything looks good, then you would migrate that out of test uh into production. So it's like lab, test, production. It's usually the typical environments that people are operating out of. Now you have continuous integration and continuous delivery, CICD. So continuous integration, this is where you automatically, automatically uh merges code changes into a central repository, followed by automated builds and tests. So in the past, you would build it, you then would test it, you would then uh make two tweaks to it, put roll it back through the cycle, and then you would build it, you would modify it, throw it and build, roll it and test, and you just keep reiterating on this. That was very manually, very time consuming. Now it does this where it merges it all together and puts it in a one big format for you. It's pretty amazing. C D is the automation of delivery of these validated code to production environments. So you can have it set up, we we did at least, where once we dated out a test and everything was good, it automatically would push to production. Once someone agreed, all the tests ran, no vulnerabilities, no issues. They just smash a button and then it deploys to production. And it was pretty awesome. It worked really, really well. Uh, the first days we did this before we got into a CI CD pipeline, it was laborious. It was painful. It was like, okay, now we move one step. Ready, push the button, good. Everything good now? Yeah, everything's good. Okay, now we move to the second step. Okay, push the button, yep, good. So you can see it's just very very painful. So the point was is that we you can now mash a button, it runs it through test, comes back and says, any issues? Nope, no issues. Okay, push the button, we're into production. Awesome. It worked really, really well. Security is now shifted left by integrating automated security testing such as SaaS, DAS, and SCA into the pipeline. And now the pipeline has security testing in it. So you can actually put your code in there and you can have the security tools will come out and flag saying, Hey, the way you have this coded is going to allow for a cross-site scripting attack, or it's going to allow for uh whatever. You can add JavaScript to this line. So it's going to tell you that before you even do it. So it's pretty doggone cool. Security orchestration automation and response. SOR. So now SOAR, you can do this within the development space as well as your security operations center. Now it automates security workflows and tasks. It often responds to security alerts. SOR, if you can correct it, correctly connect it and do it well, it can save your people a lot of time. The challenge is you got to set it up right and do it well. It can be used to automate security checks within the CICD pipeline or to respond to application security incidents. So again, it's a SOAR tool, works great in the development space as well as in other areas where you might need some level of orchestration and automation and response, i.e. the SOC. Software Configuration Management, SCM. This manages and controls changes to software, including source code, documentation, and configurations. So like SCCM, it's very similar. It manages the controls and changes. It ensures integrity, traceability, version control, and all on all the software assets. Again, really great tool, really great capabilities. Your code repositories, this is a centralized system for storing and managing all your source code, such as Git, SVN. It must be secure with strong access controls and vulnerability scanning and secret detection. Secret detection is a big factor where you're using your repository and now you have people that are putting passwords within their code to make their code run. Well, you need some level of secret detection within that repository to make sure that people are not doing that. So that's an important piece of this as well. You need to really consider that. Application security testing, this is where you can get into static and dynamic testing. The static testing, this analyzes your source code, your bytecode, or your binary for security vulnerabilities without executing the actual code. Air quotes white box testing. So this is SAST. This is what you call your static application security testing. DAST, which is your dynamic application security testing, this analyzes the running application from the outside, such as what an attacker would do to find vulnerabilities. This is air quotes black box testing. So each of these are essential for identifying security flaws throughout the entire development process. You really need to utilize SAST at a minimum. If you're not doing anything else and you don't have a DAST or you don't have a SAST, start with SAST. Get SAS in place within your organization. Once it's running and you get at least gets those initial vulnerabilities done, then you can roll into DAST and look at that from the outside. But step one would be SAST, step two would be DAST. So domain 8.3, assess the effectiveness of software security. So this is what we're going to talk about is audit and logging changes. So you need to implement any sort of mechanism to record all modifications made to the code. It's imperative that you do this. I can't stress this enough because this comes down to any changes to the code, the configurations, or the development environment. You have to have a log of what happened. Because if you don't, when you go back when things break, which they will, you're going to go, I don't know what we did. How did we do that? Why did that happen? You have to track these changes. It needs to be very methodical. It needs to be very much attention to detail. And I just can't stress that enough. It ensures traceability, accountability, and provides data and forensics analysis. So you just make sure you know what has actually occurred with the overall development that you've done. Risk analysis and mitigation. This is where you're conducting systematic assessments to identify and evaluate security risks within the development environment and the overall processes. And you're implementing appropriate controls and strategies to reduce identified risk to an acceptable level. You need to analyze it from a risk standpoint. If you have developers, you need to work with them very hard on understanding risk analysis and mitigation. They need to understand risk. So often it's the senior leaders that understand risk for the company, and they don't really communicate that to the minions that work in there. But if you help people understand risk to the company, risk to the organization, risk to the data, now the people that are working on these systems will utilize the appropriate level of protections to ensure that they reduce the risk to their company. Commercial off-the-shelf. So this is pre-packaged software products widely available from vendors. So if you go out and buy a package or your software is a service type package, this is software that's available from vendors. Most places you can get all this, right? Your QuickBooks, your whatever it might be. I mean, right, anything you can get online. Now the security relies heavily on the vendor's development practices and their patch management. That's all hidden behind the scenes. You're just assuming they're doing what they're supposed to be doing. Unfortunately, the news is littered with plenty of places that don't do that. But this is where you're dealing with commercial off-the-shelf type of software, COTS. Open source, this is software with a publicly available source code allowing for the community to review and modify, make modifications to it. There's benefits, obviously, from a transparency standpoint, but it does require diligent vulnerability management and license compliant. So you really need to understand how your licenses are. You can't just express to your people, your developers, hey, you just can't go out and grab a library you want. One, maybe there's some sort of legal requirements around it, you know, some terms and conditions. Two, what where did this come from? Who gave it to you? It's like the guy in the street going, hey, little girl, I've got some candy for you. You don't know where the candy came from. So probably not a good idea to eat the candy. Uh I'm not saying open source is bad. I'm not saying that at all. Open source is used everywhere, right? I'm just saying you need to be diligent with it and make sure that you have a plan on how you're going to utilize and orchestrate open source software within your environment. Third party, this is any software component obtained from an external entity, including COTS, open source, or custom developed by the vendor. So basically you're buying it from somebody, right? That's that's the third party aspects. This requires a robust vendor risk management, consent contractual security clauses, and ongoing monitoring. So again, if you get you've you're dealing with purchasing third party software for your company, you need to make sure that all of your documentation matches up and that there are security clauses in place, especially. Especially if this third-party software is running critical data or critical applications within your environment. You need to have a security clause within your legal review of your legal contracts. Highly suggest this. Okay. Again, one great thing about these rapid reviews and also about CISSP, cyber training in general, is the fact that you're getting experience with all the content. If you take any one nugget out of this, if this free stuff is make sure that you talk to your legal team and ensure that you have security clauses in place for your critical applications. Knock on wood, stomp foot, important part. Big, big important part. If you don't really know, if you're like, say this is I'm just working to get my CISSP stuff and I'm just happy with that, go talk to your CISO. Tell them, say, hey, I've just been studying for my CISP. Do we have any security clauses in our contracts? And ask them. And if they he or she goes, uh no, then you go, Great. Have you considered that? If they go, yeah, we're on top of it, awesome. Thanks, boss, boss, whatever. And then now they go, Oh, hey, this person's pretty smart. He's looking into stuff. That's good. So again, I'm telling you that that's one great area that you can do right now, depending upon where you're at, that can help protect your company and also show that you have a big brain and you are very good at what you do. That was a lot of talking there. Sorry. All right, so 8.4, assess security impact of required software. So we have managed services such as software as a service, infrastructure as service, and platform as a service. SaaS, this is a cloud-based application that are accessed over the internet, such as Salesforce, Microsoft 365, etc. IaaS, these are cloud infrastructure services such as virtual machines, storage, or networking devices, obviously your AWS EC2, which is your Elastic Cloud Compute, Amazon virtual machines, and so forth. So this is your overall virtual aspect within the various cloud environments. PaaS is a platform allowing for customers to develop, run, and manage applications without building and maintaining the infrastructure. So it's basically it's all set up, all ready to go for you. You don't have to do the infrastructure to make sure it works. AWS Elastic Beanstock, Azure App Service, and so forth. Now the shared responsibility model applies where cloud providers manage security of the cloud and the customer manage security in the cloud. So as an example, AWS is responsible to make sure that their infrastructure is secure. That's what they do. But they provide you these security, these different servers and virtual machines and whatever else. It's yours, baby. You get to do whatever you want with it. However, so you need to make sure that you have it properly secured for you. Amazon is not liable if your site gets hacked because that is not what they're doing. Now, if their infrastructure gets hacked overall, yes, they are liable for that. But that's what they have their security teams designed to do. They're just giving you platforms, something you can go and play with and have fun, and you can give yourself as much rope to hang yourself or not. Depends upon what you want to do. Domain 8.5, define and apply security coding guidelines and standards. This is where security weaknesses and vulnerabilities at your source code level. This includes common flaws like buffer overflows, integer overflows, race conditions, all of those aspects are there. And this covers injection flaws such as SQL, Command, LDAP, all of those types of injection flaws, as well as cross-site scripting and insecure deserilization. So again, those are just different kinds of weaknesses that you can have at the source code level. This encompasses insecure direct object references and improper error handling leading to information disclosure. So you need to understand what is a security weakness around at the source code point. Now, security of application programming interfaces, APIs. If you've been listening to CISSP cyber training for any period of time, you know I love slash hate APIs. And the reason behind it is obviously because they are a great tool to provide data in and out of your organization. They're also a great tool to provide data in and out of your organization. So they're just like VPNs on steroids. This is focused for authentication and authorization of API endpoints. It's a big factor. Authentication and authorization of API endpoints. This includes rate limiting, input-output validation, protection against mass assignment, and as well as address API specific vulnerabilities like a broken object level authorization or excessive data exposure. What that basically means is that is it authenticated? And if it if it is authenticated API, if it breaks, will it still work? And then excessive data exposure basically means are you allowing a lot of data to be shipped out of your organization and you're not inspecting it. So again, APIs are amazing. They work great, they help everything just kind of connect together. They're the connective tissue that makes everything run. However, yeah, they also can make your life extremely painful because now instead of having maybe a VPN between one vendor, you now have VPNs between 50 vendors. And that was that's a challenge. So uh APIs, they're awesome. You will live or/slash die by APIs. Secure coding practices. This is where you adhere to the principles like least privilege, defense in depth, and secure defaults. This is where you implement robust input validation, whitelisting, and proper output encoding and secure error handling. This ensures secure memory management as well as control and cryptographic best practices in your code. Again, you want secure coding practices, come up with them at the beginning. Make sure your people are aware of them. You want to make sure that they understand how to properly code in a secure environment. Software-defined security, SDSs. This is where you manage security policies, configuration, and controls as code. So if you have a policy, instead of having a typical application where you'll go in and you'll click buttons to actually implement some level of policy, this is where the policy is set up specifically around code. So it's in the JSON format that you might be already setting up the policy for it. This leverages infrastructure as code and principles for security provisioning and automation. It enables consistent, repeatable, and audible security deployments through the version control and automated testing. It's a much better solution than having to go in there and click buttons if it's already built into the code. That being said, not everybody can do that. And so, therefore, you have to be able to understand what applications can I do this with, what applications can I not do this with. So, again, software-defined security, very, very good uh capability for your organization to help secure your software. Okay, thank you so much for joining me. That is all I have today for domain eight of the CISSP Rapid Review. Again, this is the final one of all of those. If you want access to my CISSP rapid reviews, head on over to CISSP Cyber Training. You can gain access to all of my rapid reviews, and you can get every single one of them there. You can go to my blog, get access to it on my blog, you can get access to them in my free content that I provide. Again, all you got to provide is an email address. That's it. And you can get access to all my questions, or not all my questions, the 360 questions. You can get access to my study plan, you get access to my weekly podcast, you get access to the rapid review just by having an email address. Never before has an email address been so useful and so valuable to you that are studying for the CISSP exam, right? Now, that being said, if you need more help and you need more questions, like more questions, you need the ability to have a better plan that kind of walks you through the using the book, using my content, using other outside entities, just kind of step by step. The one thing I never had when I studied for the CISSP was a step-by-step approach. If you want a step-by-step blueprint, that is the product for you to get and some of my paid resources. I got over 50 hours of CISSP content that's available to you, video content that's just covering all the CISSP domains. That doesn't include any video content tied to the podcast. There's 1500 CISSP questions with another 250 question test at the end that's just being developed right now. And then I've got curated audio and video content. If you need something more, such as some sort of consulting capabilities, I've got VCISO, uh IT leadership kind of consulting, and any sort of red teaming, you name it, I can get it for you with my partners uh with CISSP Cyber Training. So all of that is available to you. Just reach out to me at contact at CISSP Cyber Training, and I'm happy to help you out on anything here. Again, that's all I've got. Have a wonderful, wonderful day, and we'll catch you on the flip side. See ya. Thanks so much for joining me today on my podcast. If you like what you heard, please leave a review on iTunes as I would greatly appreciate your feedback. Also, check out my videos that are on YouTube, and just head to my channel at CISSP Cyber Training, and you will find a plethora or a conocopia of content to help you pass the CISSP exam the first time. Lastly, head to CISSP Cyber Training and sign up for 360 free CISSP questions to help you in your CISSP journey. Thanks again for listening.

Contributor

Shon Gerber

Host