CCT 064: Agile, Scrum, Kanban, Waterfall, Spiral- Mastering Software Development Methodologies (CISSP Domain 8.1)

Are you ready to navigate the maze of software development methodologies and their security implications? Well, that's exactly what we're about to do! We're unpacking everything from the waterfall development model, with its linear steps, to the agile model's flexible and adaptable nature, perfect for managing complex projects in an evolving landscape of threats and challenges.

In this captivating cyber training episode, we also dissect the scrum methodology, providing insights into the roles within a scrum team and the concept of 'shifting left' – a strategy to integrate security into the development process. We discuss the importance of the security professional's role, emphasizing the necessity of spearheading security efforts within an organization. Plus, we also examine the pros and cons of the scrum methodology and its role in agile development.

But we won't stop there. We're ushering in DevOps into the conversation, highlighting how its security implications can foster a culture of collaboration, automate tasks, and measure application performance. We'll also be venturing into the intricacies of the spiral development methodology, an approach used for larger, complex projects. And let's not forget about the kanban development method, a visually engaging approach to workflow management and bottleneck identification in security-related tasks. Buckle up, folks! We promise it's going to be a thrilling ride into the depths of cybersecurity knowledge.

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. 

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 this is Sean Gerber, with CISSP Cyber Training. How are you all doing this beautiful day? I know it's beautiful here in Kansas. Actually, it's been a gorgeous couple of days, but now it's starting to heat back up again in the throes of summer, so it's all just beginning once again. Yeah, for whatever reason, we've had a very mild couple of days here in Wichita Kansas, but it has now gotten a little bit warmer than what it has been in the past Well, actually, what it has been in the past but it's starting to go back up. So it's time for I'm Ready for Fall. I don't know about you all, but I'm ready for fall. So I'm not sure if any of you know where Wichita Kansas is. One person I had on my podcast asked the question around where is Wichita Kansas? It's in the United States, but where? So we are in the central of the United States. So if you look, pretty much if you dropped a pin or dropped a ball in the middle of the United States, we are not very far from that location. So pretty much in the heart, dab in the middle of everything. But so that's not what we're here to talk about today. Today we are going to be talking about the different development methodologies, and this is going to be totally connected to a couple of products or a couple of different methodologies out there. One is called Agile, scrum, kanban, waterfall and Spiral, and we're going to get into some of those. Now. We'll do an overview of all of those, but then we'll do a little bit of a deep dive into just a couple of them to kind of understand what are they and what are the main ones that you may run into Now for the CISSP exam. You may have to deal with all of these types. They may ask you questions that are very different than what even the questions I'm asking you, but the overall purpose of this is to give you an idea and understanding of each of these models and what are they used for. One, so that it helps you in your security career, but then also two, is it that it helps you when you are taking the CISSP exam, right? Okay, so let's get started Now. The first one we have is the waterfall development model. Now, as you'll notice, as I talked through this real quick on the podcast there are also videos available. I'm recording this as a video, so the content and all the outline is available at CISSP Cyber Training, so you'll be able to see the content as well, and then eventually, at some point, some of this data information will be released on YouTube so you can check it out there. But the waterfall development model this is the first one we're going to start with, and this one has been primarily around for many years. I actually had heard about it since, you know, I'm like I'm an old guy, but it's been in place since I think the 70s, if I'm not mistaken. And the waterfall development model is a linear, sequential approach to software development. Now the key on this is the projects themselves, the specific projects that you have when you set up a waterfall project. It's broken down into very distinct stages, so you have stage one, two and three, and these are completed in a very specific order. Now you cannot, with waterfall, go around like if you all of a sudden say you know what, I'm starting this process and I want to begin this process, and then you realize halfway into it that you want to make a change. Waterfall does not allow you to do that. So this is a model that's best suited for projects where requirements are well understood in advance. A key point if you know the projects in advance, this is a really good model. Now it doesn't work well for on the fly type of model, type of development work. So it's easy to manage and each stage has a very specific deliverable and a review process. So you'll go through this process with the waterfall and then at the end of it you have a review process on how it went. Now the security implications as it relates to the waterfall method, is the fact that it must be built in the security must be built in the initial requirements and the design phases of it. So what does that mean when you go to have let's just say, you wanted to have a piece of software developed, or maybe you had a project in place that you wanted to have developed, if you get halfway into it and then realize, oh, our input, validations for the name, user name, for the person's name, address, and all of this information needs to be protected in a certain manner. You won't be able to do it Now. You can, but what will happen is you'll have to throw away all that you've done. That's the problem with waterfall is that if you have anything that goes into it at somewhere midstream, you have to start back over. So, again, if this model is not well suited for responding to evolving security threats, such as you may see in the world today. So that's why it's important that if you do the waterfall model, you need to have those requirements well defined and well built out ahead of time. The next one is an agile development model. Now, the agile development model is basically a development process designed to manage complexity and uncertainty. So what does that really mean? So when you have something that's tied to the name, if the name says I got to be agile, so like me in a really old guy trying to catch a football, I'm not very agile, but I am in a situation where, if I fall over, I could be more agile, that doesn't really make any sense. But okay, young people are more agile than me. So what I mean by that is that my two year old granddaughter can run all over the place and she's just, she's super, make all kinds of changes and she's good to go. The point is that the agile methodologies, as a group of processes designed to manage complex and uncertain software development projects, and these methodologies prioritize flexibility and collaboration. That I've worked in agile a lot and agile is a very collaborative process that you can use to do development within your work, within your company, and so it's. The work is done in small increments. Now this product and the progress is reassessed at the end of each iteration. So what does that mean? You set up a process, usually about a two week process, and you begin it and then, as you're working through it, you may have changes to it. Well then, you can make, adapt to those changes during that two week sprint. Now I'm kind of incorporating the term sprint, but what you're happening is that you can then make small, modified changes to that environment at that time. So again, that's the key factor with it is that you can make it. In an agile space, you can make changes. It's very flexible. Now, when you're dealing with security agile again, very good that the threat is changing on a daily basis. So what can you do? You can be agile with this development process. So if, for some reason, something comes in that says there's a security issue with whatever product you're making, you do have the flexibility to be able to add it to the backlog, then add it to the development life cycle and then, in turn, it can be incorporated into the overall process. So it's really good right Now. The focus on rapid development can sometimes lead, though, to some security issues. One is that you can overlook the security aspects because you're so focused on getting it done that you don't take care and manage the security, and therefore you can miss aspects of it. So there are some downsides with that. So the Kanban development method that's K-A-N-B-A-N is a workflow management methodology designed to visualize your work. So what does that basically mean? What it means is that when I've used Kanban, I will have like note cards, and these note cards you will pick them up and move them from, let's say, the backlog into testing, into operations, into actually completion. You will move these cards as you get aspects done. So it just gives you a workflow in a visual format. Unlike Scrum, there is no fixed length iteration and we'll talk about Scrum here in a minute but instead the work items are continuously pulled from the backlog as the team has capacity. Now the Kanban can help identify if security related tasks are causing bottlenecks. So if you're seeing a bottleneck with something, say something slowing it down, what the bottleneck means is, then you can tell that. Is it a security item that's doing that, because maybe it takes longer to complete. However, as with agile methodologies, there is a risk of overlooking security in the push for efficiency. It also is a bit of a well, you get excited when you actually move cards out of one area into another, so you can, in some cases, make a very general statement and overlook security. So it's just something to consider when you're dealing with the Kanban development cycle. Okay, the next one is what we call the Scrum development method. Now, the Scrum is typically what we've talked about is as it relates to rugby. Rugby, there is a group of people working together to try to kick this ball, I guess, down the field. My friends from the UK. They know rugby well. He's my friend. It's a very good rugby player. I do not understand the sport Whatsoever, other than to know that it was probably, I think, one of the precursors to American football. That being said, that's probably way more than you want to know. Scrum is an agile framework, so it works very well hand in hand with agile and it's used for complex product development. It's designed to add energy, focus, clarity and transparency to the project planning in the implementation. Now it uses a fixed length iteration, which we call a sprint Now you heard me mention it before a sprint and it's designed to basically be a period of time where you start at a period of time that ends, and it's used to bring in multiple teams. You have cross-functional teams, you have goal setting and set up. You also will deliver very value incremental aspects that will then make basically move the ball the proverbial ball down the field. Now there's three roles in Scrum that are important that you'll hear about and they may call these out in the CISSP exam. One is a product owner, there's a Scrum master and then there's the development team. So again, product owner, scrum master and the development team. Now the product owner is someone who defines the product vision. They prioritize the work. They more or less are the leader, to kind of help give a direction on where to go. The Scrum master, on the other hand, is someone who facilitates and optimizes the entire process. The Scrum master will also help remove barriers that may be in their way. So if you're having an issue with I don't know, say, some networking issue, you then can reach out to the Scrum master. The Scrum master will then coordinate on the back end with other people to help remove these barriers and get them out of your way. Now, when you're dealing with security implications around Scrum, as with other agile methodologies, security needs to be built into the product backlog and then considered part of the we call it air quotes definition of done. Now, that's a big factor is that when that is the definition of done, that's what calls it to be complete. The Scrum framework also provides opportunities for teams to discuss and adaptation around security issues in various meetings. So what that basically means is you have your sprint planning, you'll have your daily Scrum, which we'll talk about here in just a minute, and you can get to and address security issues in those daily meetings. That works out really well. I've done it many times where you say something will come up and then you can go ahead and add that to your Scrum. Now you have dealing with the DevOps development method. Now, the DevOps is a set of practices that aim to combine software development and IT operations to shorten the system development lifecycle. You'll hear DevOps used a lot in today's world and this, basically DevOps, emphasizes culture, automation, measurement and then the sharing part of this, and they break this down into an acronym called CAMS, c-a-m-s. That's culture, automation, measurement and sharing. Now this is aimed to build the culture of collaboration between your teams and it's designed to be basically keep people out of the we call them the silos, but it means one team team A is working on its aspect, team B is working on its aspect, team C is working on what it does. It's designed to help keep people out of those various lanes, those various silos, and it's also helped use to help automate tasks, measure application performance and share outcomes to the overall group. Now, when you're dealing with security and DevOps the nice part about DevOps Securities you can integrate it into the overall DevOps scheme, which is great. But, like Agile, the problem is with the speed of DevOps. It can set a situation where security can be overlooked unless it's fully integrated into the overall development pipeline. And we'll talk about a little bit later the CICD pipeline, and that's where it's a really good place for you to integrate the overall development aspects of this. Now the spiral development methodology. The spiral methodology combines the idea of an iterative development with systematic control aspects of the waterfall method or model. It's a risk driven approach, and it's a key term there risk driven process framework that is used for really large, expensive or complicated projects. Now, the spiral method does not seem to work really well with this. With a very small Agile type of environment, it's usually a risk based, very large, very expensive endeavor, and what it does is it's in the spiral method, developers will start small, so they'll basically begin in a very small state, but then they'll explore the risks involved with the projects and then make a plan to handle the various risks. This happens over and over again, hence the spiral approach, and as you do that, you then understand where a lot of the risks may lie with your overall development plan. The downside is it takes time and it isn't easy to change, but, basically, the key around this, though, is that if security is a very big concern, it will focus only on the risk management of that, and it's the design around. It is that it allows the development team to build increasingly secure versions of the product when you're dealing with overall development aspects. Okay, so now I'm going to take a quick deep dive into just a couple models. So we're going to look at them and we've talked about a lot of it, so I'm going to just focus on some of the areas that are the key factors around waterfall and agile. Now the waterfall model this is what we call the software development lifecycle or SDLC approach, and this is where this term comes up substantially. You also may see the term SSDLC, which is the Secure Software Development Lifecycle. Now it's named waterfall again, because it visualizes progression from one phase to another, like we talked about before, and it's a very linear or sequential lifecycle model which basically each phase of the process happens in a sequential order, once you cannot start the next process until the first one is finished and you cannot go back to a previous stage without starting over from the beginning. So understanding the requirements at the beginning is a very important part, and it's important that you set this up so that when you do go through this process, you meet the requirements you need, because you won't be coming back to this and addressing these same requirements at another time. So, as an example, you come up with your plan, you define your requirements, you get ready to go, you begin the process and then you're halfway through. You realize wait a minute, there's another requirement that I have. You're not going to be able to go back and get it. You're going to have to put it in the backlog and then at some point when you reevaluate the development of this space, you can come back, or possibly in the next waterfall meth stage you might be able to incorporate it. But depending upon if it had interdependencies in that first waterfall stage, you may not have to do it. You may just say you know what. We're not going to be able to implement this piece of it. If that happens, especially if it's a security issue, it can be very problematic because you can't go back and fix it. So it's important that you really truly get these requirements done at the beginning. It's very important that the requirements are defined at the beginning. Now, when you're dealing, there's various stages of this and we're going to talk about there's basically six different stages. There's the requirement stage, there's the system stage, implementation stage, integration, deployment and then maintenance. So there's six main stages in there. We talked about the requirements phase already and how important that is. The design phase basically takes the system and the software design requirements from the previous phase and integrates them into a complete system. Design so basically comes up with the plan how are you going to do it, how are you going to implement it and what is it going to look like. Then you begin the implementation phase. This is where the actual software code is generated, is in the implementation phase and you take the design that you created. So you have the requirements, you have your design. Now you take that design and you then build your implementation around that, and this is where you begin the process. Once that's complete, then you move into the integration and testing phase. The software is first integrated. The individual programs are tested during this phase, so you want to integrate them. You then begin the testing process. Once that testing is complete, then you deliver it to the user and that's where you deploy the actual product to the user and to everybody else that wants to see it. The key thing around this, then, is that's where it's put into its actual production environment when the testing has been completed. Now any minor modifications would occur in this deployment phase, but in most cases that they will be minor only, they will not be substantial. And then maintenance. That is the last phase where it's carried out any large scale failures or downtime is where they would deal with the maintenance that comes up. So if you have an issue with the software, that you have to take it down for whatever reason. That is where you deal with it. So now, what are some security implications of doing the actual waterfall method? Security must be addressed from the onset on set again in the requirements phase. That's where you have to do it. So getting security put together, understanding what you're trying to accomplish, any security vulnerabilities that you want to address, that's where you figure it out in the requirement stage, because once you move beyond, there's really it's very hard to add these requirements back in. Now this model it allows for thorough documentation. That's a great positive that it has and this can be included in the security requirements. So if you have a requirement in your waterfall method that says I must have detailed documentation around this software and the security methodology that it's built into, that is where you would actually define that and that's when you would build that. And what it's saying now, that is, you couldn't move on to the next iteration until that documentation is done. Now a con that are some issues that it runs into is the inflexibility that it has. So that's one of the major drawbacks of it. Also, if there is a vulnerability discovered in the system when it's deployed or there's new security threats that come up, it's very difficult and it can be costly to go back and make changes to address those issues. So that's the challenge with that. If you have an area that is going to be more iterative, that you want to make changes more frequently, waterfall is not the best option for you. You want to move into a agile or DevOps methodology. Those are more agile. They're much more flexible in making changes. But again, it's important for you to understand the waterfall model and some of the security implications that you can run into, because you may get asked on your CISSP around those specific ones. You may not do much development work with waterfall. I say that because I've just dealt with agile and I see people talking about agile, but I'm sure it's still out there and there are still development shops that like to use it. The next one I'm going to get into is the agile development model. Now, the agile development model we talked about earlier. It's a lightweight methodology that really helps you respond to changes quickly and efficiently. So this works really well when you deal with a little bit of uncertainty. Now the methods this agile refers to what they call and I'm doing this in air quotes, but I've heard this a lot when I was studying for the agile piece the methods and practices based on the values and principles expressed in the agile manifesto. The agile manifesto is more or less the Bible of the agile method. It's the document in which you must follow the agile methodology. Now the thing with agile is it's very. There's some key aspects I want to kind of get into with that. It's iterative and incremental and what that means. Like we mentioned before, everything is referred to in what we call sprints. Now you'll see the term sprints in agile and you'll also see it in the term scrum. But what it does is it allows, it sets up a period of time for you to operate, usually a two-week period. You two, three weeks. I've seen them, we've gone as long as three weeks with them, but three weeks kind of pushes it. You give a two-week sprint where you start and you end in that two-week period and it allows you to give workable products in a very short period of time. Now, keep in mind, most of these products, unless you have a very large development team, are not Monumental, they're not massive, they're small, incremental Projects. However, the good part about these incremental projects is you actually have, you see, you're that you're accomplishing something, you're moving forward, and so it does give them some sort of it actually is very helpful for me because I actually see that I'm making progress. Now, the other part around it is very collaborative. So you will bring in multiple team members from various areas to help in this overall process. I've had product owners, individuals that own, let's say, the product of I don't know. I want to develop my development team, develop software that measures the amount of grain. Let's just say we'll focus on the farming aspect, the level of grain that comes out of a Device of some kind. Right, you say it's out of your combine and it's. I want to measure the amount of grain that comes out of that device. Well, because I can, I make the program. You say I'm not a farmer, I don't understand farming. I can develop the program, but unless I get input from people that are the actual product owners, the guys and gals that actually are farmers, they tell me what they're looking for with this code, I will not make the code correctly. So therefore, they way cut, come in and collaborate with me to make me understand if you're going to develop software. These are the key factors that I want developed out of this software. So that's the collaboration piece. It's very, very helpful. The other part around it is adaptive planning. So, rather than to define all requirements at the beginning, agile methods promote frequency of reassessment and Project direction, helps you move in one direction or the other and it does help you provide early delivery. So If you have situations where maybe you're done with this product in an early stage, you can have, you can call it quits early, or you can have a situation where you know you're going to be done early with these requirements. You could either call the end to the sprint so your two week sprint, you could maybe end it in a week or you could even add items, pull items from the backlog in that sprint to address some of those. The other part of it is it deals a lot with continuous improvement, so there's regular reflections on how to become more effective and adjusting basically come, which comes back to the fundamental part of agile, and these are what we call retrospectives, and they happen at the end of each sprint. So you spend your two weeks, you go in, you have your sprint and and then you'll incorporate the scrum methodology when you'll have the sprint, you'll have your morning meetings. You'll have your morning meetings. Your morning meetings will will tell you how you're doing, left or right. Are you doing okay? Then from there you'll go back and do the development again. The next morning You'll meet. You do this iterative process day after day after day, and at the end of that two week sprint you will then have a retrospective and that retrospective will say did we do well today? Did we find what we did? We finish what we were supposed to do during this two week sprint? So again, it's a very methodical, very step by step process in which to help you make development aspects. Now, when you're dealing with security around the agile methodology, you can incorporate security practices into the development process from the beginning and then you can add them as they achieve and go forward. So what happens is, if I have a situation, I will then take that, put it in the backlog, like I mentioned before, and they'll take it out of the backlog and they'll add it into that week sprint. Now, if they can't get to it, they then well, it'll move to the next sprint that they do in a couple weeks. So, again, agile emphasizes speed and flexibility, and it is possible for security to be overlooked, though, because you're going so fast, you're not paying attention to security and you may under undervalue it. So to prevent this challenge, agile teams often adopt the principle of shifting left. So I'm saying air quotes, shifting left. Now this is where security practices are built into the early stages and the requirement stage of the overall development lifecycle. Again, you're going to have to help. If you're working on your CISP, you may or may not have a development team that works for you in the future, but if you do, you're going to have to work very hard to ensure that they understand security. You're going to have to be the advocate and the leader to provide that into their daily sprints. Now the pros and the cons. An agile documentation can be less emphasized, as it was with, potentially, the waterfall method. It's also doing important to know that when you're dealing with security requirements, design decisions and the changes they are need to be properly documented to avoid confusion and potential vulnerabilities. So if it isn't getting documented, that can be a bit of a problem. Now agile's flexibility and their development style basically being able to be quick on their feet Does be does allow it to be well suited for projects where requirements may change or evolve, and in today's development world that happens a lot, especially if you're putting any sort of development product out there for the consumer to be able to use. Now, agile's fast-paced environment does mean security must be a high priority and it isn't Left behind. So it's going to take you to help Understand and deal with all of those aspects. Okay, the last part that we are going to talk about is the scrum development method. Now, scrum is a popular agile framework that's often used to manage complex product development, and the scrum obviously is tied to the old rugby aspects, but it is designed to give you that Interactive and incremental delivery of a product. Now, there's a set. We talked about the roles a little bit and we're going to kind of get a little bit deeper into that on as it relates to scrum. But the main part of this is that you you have those three aspects we mentioned. You have your product owner, your scrum master and your development team and, as a refresher, the product owner is the person who maximizes the value of the product. The product owner manages the product backlog, ensures the team understands all the items that are in it and what is the overall plant. They are the leader to kind of help guide and direct this overall development process. The scrum master is the person who understands the process that's enacted and it were again like I mentioned before Helps the, the overall group, overcome Obstacles. And then, lastly, the development team is a self organizing professionals. Well, and what that means is you, you, everybody just jumps in and helps. There isn't bill has this Jumping in and helps. There isn't bill has this aspect of it. Joe has this aspect of it. Everybody is working together as a team and it's a very self-organizing group of people. Now you have your events. Now the events are. You have the sprint planning, you have your daily scrum, you have your sprint review and you have your sprint retrospective. So your sprint planning happens at the beginning and this defines the work, the strategy for the next sprint. So you're doing this prep ahead before you actually start the sprint. You then have a daily scrum so that you start the sprint, you're going, you're doing your thing Well, each day. You're going to have a daily scrum where everybody gets together and there's a 15 minute stand-up meeting to assess the daily progress. Now, in the past, the stand-up meeting was literally that you were standing up in the room because you didn't want to sit down. Because the ultimate goal is to keep this meeting short and to the point. If people are standing, they're ready to leave. If they're sitting down, they tend to take longer. So that's what they call it 15 minute stand-up. Now the sprint review. This is held at the end and this is to inspect the and the incremental aspects of it, and then you adapt what happens and put those into the product backlog. So basically, did we do good? Did we get done, what we wanted to get done? What didn't we get done? And now can we put that in the product backlog. The last part is the sprint retrospective. This reflects on the past sprint and then plans for improvements on to the next sprint. So it's just you're looking back. What can we've done better? That's the ultimate point. When you're dealing with the various artifacts, you have a product backlog and this backlog is where things are put. This is where it's maintained and it is maintained by the product owner. The sprint backlog is a list of items selected from the product backlog to be completed in the next sprint. So you have your product backlog, you have your sprint backlog and your product is the overall arching one. Your sprint one is which ones that are going to be used in the upcoming sprint. The increment, this is the sum of all completed backlog items. So that's what actually have occurred. These are the increments of each of the previous sprints and then your sprint itself. These are fixed length iterations, typically one to four weeks long. Again, like I said, I usually do them two weeks. I've done them as short as a week. We did a month one, I did a couple of month ones. Those are painful. It's usually two to three weeks is usually the sweet spot for a sprint, but again, depends on what you're trying to accomplish. Now, what are some of the security implications of the overall scrum? Now, the scrum, the security, is a part of the definition of done. When we talked about that earlier is what is done, what you got to define. When is this done? When is it complete? And security needs to be part of that Because, again, if it's not part of the requirements, it's not part of what is the deliverable, it will not get completed. Continuous evaluation of the security needs is an important factor and the scrums iterative process does allow you to be able to look at the security needs that you may have and then integrate those within your overall game plan, so that's a great aspect to it. So you need to make sure, though, that, as you are doing your scrum, you are constantly looking at the security pieces of it and important incorporating and helping your development team understand that, specifically, there's also potential oversight of security. This is similar to the agile method. It does emphasis emphasize on rapid development, and security, potentially, could get overlooked, so you need to have some level of oversight into the overall development process. You include it into the product backlog. Again, security items should be added into the product backlog, and then you, as a security professional, can work with the team to make sure they are added to the backlog. And then, from a collaborative risk management standpoint, you do have collaborative folks that are involved in this process, and so, therefore, you can then discuss some of the risks that they may have and then incorporate those within the overall scrum methodology. So, when it comes right down to it, there's a lot of things that are similar is between scrum and agile, but bottom line is, is that it's up to you, as the CISSP, as the security leader for your organization, to lead this for your company and ensure that it's not forgotten about. All right, that's all I've got for today. I just want you to have a great, wonderful week. If you are interested, you can get this video and this podcast on CISSP cyber training or any podcast location you may be able to find it. You know you obviously your Pandora's, your Apple, your iTunes, all that kind of stuff. It's all out there. Also, go to CISSP cyber training, where you can get access to free CISSP cyber or free CISSP questions. You can go to free CISSP questionscom and get access to 30 free CISSP questions every single month. You can just get those easy peasy and then go check out the site. There's a lot of great aspects that you can have to help you walk you through getting ready to test and study for the CISSP exam. I hope you all have a wonderful day and we'll catch you on the flip side, see ya.