CCT 190: Integrating Security in Software Development - Exploring SDLC, Agile, and DevSecOps for the CISSP (Domain 8.1)
Nov 04, 2024Unlock the secrets of integrating security within every phase of software development as we tackle Domain 8 of the CISSP exam. Our exploration begins with a deep dive into the software development lifecycle (SDLC) and its various methodologies like Agile, Waterfall, DevOps, and DevSecOps. Through a gripping tale of a Disney World IT insider's digital manipulation, we underscore the critical importance of safeguarding systems, especially when skilled employees exit the stage. This episode promises to arm you with the knowledge to fortify your organization's cybersecurity posture effectively.
We then navigate the contrasting landscapes of software development models, weighing the structured order of the Waterfall model against the adaptive flexibility of Agile and the risk-focused Spiral model. Each approach comes with its own set of challenges and benefits, particularly concerning security integration and usability. Through the lens of iterative feedback and prototype development, we highlight how these methodologies can help refine requirements and minimize ambiguities, ensuring that security and functionality walk hand in hand.
Finally, explore how the IDEAL model can transform your organization's security practices. Designed to improve cybersecurity and risk management, this structured improvement approach offers clear phases: Initiating, Diagnosing, Establishing, Acting, and Learning. We also discuss the impactful mission behind CISSP training, where proceeds support a nonprofit for adoptive children. This initiative not only enhances your cybersecurity skills but also contributes to a cause greater than yourself. Join us as we unpack these strategies, providing insights that could significantly shape your cybersecurity career.
Gain access to 60 FREE CISSP Practice Questions each and every month for the next 6 months by going to FreeCISSPQuestions.com and sign-up to join the team for Free. That is 360 FREE questions to help you study and pass the CISSP Certification. Join Today!
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. Let's go.
Speaker 2:
Cybersecurity knowledge All right, let's get started. Hey, I'm Sean Gerber with CISSP Cyber Training, and hope you all are having a beautifully blessed day today. Today is an amazing day. Yes, we are going to be getting into Domain 8 and we're going to be delving deep into the overall development methodologies that are associated in Domain 8. And this comes down to your agile, your waterfall, your spiral and so forth. So, yes, hang on, put your seat belt on. It's going to be an amazing ride, way more than I could ever imagine. Yeah, make sure your seat belt is on, because you're probably driving into work.
Speaker 2:
But, that being aside, before we get started, real quick, there is an article in wired magazine from a matt burgess and a lily hay Newman, and they talk about a couple of different aspects. But there was one aspect in here that I thought I just wanted to bring to your attention, and the reason is is because, as many of you are listening to this podcast, you probably come from an IT background. Well, obviously, if you're sitting for the CISSP, you have some level of IT so that you can get the prerequisites to get the exam or the certification. But there was an article in here about an individual who changed the menus at Disney World and the point of it came into is like, well, you're like, okay, so what right, he's changed the menu? Well, he changed the menu and he? The reason he did this was because, well, well, one of the parts he was fired from the company, but he still had access to the passwords. Well, I would have wonders. Okay, what else did he have access to, right? So he had access to the passwords and before he left, he ended up changing them to the Wingdings font, which basically isn't completely consisted of symbols. So the menus went all to symbols and that caused all kinds of chaos and pandemonium because people could not get their nachos and cheese with Mickey Mouse Right. So that's a terrible thing to happen.
Speaker 2:
A great exit strategy so that when the person is leaving your organization, they are actually, instead of in case of just walked out, their credentials are terminated and ended at the same time Because you know what. You don't know what they can do after they leave the organization, especially if they're in IT and they have the ability to remote back into your organization. So it's interesting how this happened. But the federal complaint that they set out there was that he had changed the menu listings to say that foods with peanuts in them were safe for people with allergies, which that could have been really bad. Right, somebody takes that under advisement, and then they end up eating it and getting very, very sick or potentially even dying in some cases. So that is a huge deal.
Speaker 2:
He locked 14 employees out of their accounts, trying to log in with an automated script. So obviously he had some IT skills and so therefore, yes, that would have been someone you'd been on your radar and watch list, and then he also maintained a folder of personal information about employees that turned up at one person's home. So, again, this individual is someone who is a malicious insider, who had plans to do something to the organization. Now the question is he knew how to do scripts. Did he do a logic bomb? Did he do any of those different aspects to your organization that you now have to go in and dig out, which causes lots of time, lots of energy, and I wouldn't put it past him If he's able to do these things. Could he have done something else like that? So something to consider if you have employees that have IT skills in your organization. Right, it's always something to consider, all right, so we're going to move into domain eight. So let's get into it. Okay, domain eight 8.1.
Speaker 2:
This is how to understand and integrate security into the software development lifecycle. So your SDLC. So we're going to get into some different topics and these are the ones that I will tell you. In many ways kind of really cause some consternation with folks just because of the fact that it's a lot to put in place and if you don't deal in the development world, it can be a little bit overwhelming. Okay, development methodologies this deals with Agile, waterfall, devops and DevSecOps. So we're going to be dealing with the software development lifecycle. Now, if you all have dealt with software development lifecycle, if you have, or if you haven't, something for you to really get good at understanding. And the reason I say this is because in today's world, as you see, everything has some level of IT in it, right From development standpoints to IT connectivity. You name it, it's in there, and so understanding of the software development lifecycle is an important factor because it's highly likely you will have developers working with you and for you in the future, if you do not already.
Speaker 2:
So the one thing around SDLC is the fact that there's some key activities you need to understand from the conceptual design, functional requirements. You know what is the purpose of it. Conceptual design, as why it's made. The control specifications and what are those requirements specifically set around the controls, the design review, your code review and how you're going to do code review and user acceptance, training and then maintenance and change management. These are key activities that you'll hear words for. And UAT I actually, when I first started in the development space and trying to understand it, I didn't quite understand what UAT was. But it's a really good topic, obviously, for users have to accept this the amount of information that's coming to them. They have to test it. They have to accept this, the amount of information that's coming to them. They have to test it. They have to accept it and then from there they decide which way they want to go. So we'll kind of walk through this a little bit and see, understand how each of these work.
Speaker 2:
So your conceptual design. It's agreed upon by all of your stakeholders. So what is the overall design for your development plan? It's a high level, clear and succinct point of what you're trying to accomplish. The goal is not to make this too complicated when you're first designing it, the conceptual aspects of it, because what will happen is when you work with your users and with the stakeholders, they may have changes to it. So you want to avoid making this way more complicated than it needs to be. It needs to be abstract or an introduction of how things are going to happen. So this is like your pitch design what do you want it to do? And then it defines your end goal and the output of what you want to accomplish with the overall design itself.
Speaker 2:
So what are the functional requirements? There are system functional requirements that have to be defined, and this is where you would do them. These would be how they're going to interoperate with other systems. What's going to happen, how do they communicate with each other, how are they going to act for the user, and so forth. Now the stakeholders need to be connected with the functionality, because they need to know how it's going to work. One thing to be considering is, when you're talking with the stakeholders, make sure they understand what are they trying to accomplish with this tool If they don't know. So I've had multiple times where the stakeholders are senior leaders. They have an idea of what they want, but they don't truly understand how they want it to work. Make sure that you bring in somebody else in the conversation with you. That understands it a little bit more granular, so that they can help connect the senior leaders with what the functionality is going to be, and then it's referred to during their development process. That's the functional requirements.
Speaker 2:
When you're developing it, you're going to come back to the functional piece. What do you want it to do? How do you want it to operate? How do you want it to interact? Okay, so what are the control specifications? Now? The control specifications these are additional step with functional requirements. What do they have to happen? It adds security controls to the design function.
Speaker 2:
When you're doing the different specific controls that you have in place, you want to make sure that you're continually bringing up security in this conversation. It's important, it's imperative, realistically. One, there could be compliance requirements and legal requirements for this. Two, it's just good business sense that you want to do that. Now, the one thing you have to avoid and this can happen is if you have a bunch of security people in the room and they're all secure developers and they've done it for a while. They really know it, and I'm not saying this is bad. I think this is good. But if you're a stakeholder, you need to weigh the risk of the security controls you have in place with what you're trying to accomplish, because the security controls can add extra stuff to your overall plan, which, if it does, then can add challenges to your individuals that are using the tool. So you got to weigh out the risk versus reward on this piece of it. Now you want to incorporate encryption where you can or it's appropriate, and then you want to be proactive in re-evaluating during the major revisions. So what that means is that as you go back and do a revision, you want to make sure that you stay proactive with these controls and that you're constantly trying to fix them.
Speaker 2:
Now the design review this is where user interface and user experience are designed, and then this is where the stakeholders will review the work and approve the overall design. So this is what you have a plan, you have a review. You're going to walk through it the user interface, how it's going to play out, or the UEI, the user experience and how that's going to play out and then you're also going to make sure that the stakeholders are aligned with the plan. Once they're aligned with the plan, they sign off on it. Then work can begin.
Speaker 2:
Now the code review this was where the developers begin coding. Now you want to make sure that you connect with your coders on this so that you have a good plan, and you have to watch them, and I don't mean that in a bad way, but I mean what will happen is coders will add more information to it potentially than what is necessarily needed, so you need to make sure that you have all that under control. Now this is where the different methodologies come into play the agile, the waterfall and so forth. These will allow updates to it as you go forward, but you need to make sure that you stay connected with how the coders are developing your code, and this would be a code review walkthrough, and this is where you have specific milestones set up. You could have a code review walkthrough once a week. It could be part of your sprint. It could be once every two weeks. It depends upon your overall plan and how you have it set up, but it should have milestones in what you're trying to accomplish from a development point of view. Now you have a security review walkthrough of the code as well, and this is where you would have individuals look at it from a security perspective and make sure that it meets the needs that you're trying to accomplish. That were spelled out in the requirements earlier set. So, again, developers begin coding, you have a code review walkthrough and then your security is tied into the overall code review User acceptance testing.
Speaker 2:
This is completed prior to going to production. So, prior to you pushing the mash in the big green button to send the thing into production, you want to make sure the users accept what you have created, and it's imperative to do this, because the last thing you want to have go out there is you send it into production and then the users go yeah, that's not what I wanted. You don't want that. Have I had that happen to me? It's very uncomfortable and it's yeah, it's not good.
Speaker 2:
So you want to make sure that they test it before or they try it the users try it before you actually put it into production. You're looking for any obvious errors that you may come up with. You know the button's supposed to be green, but errors that you may come up with. You know the button's supposed to be green, but it was blue, right? You want to make sure that it opens up the web page and the fonts are not windings or they're normal cabriolet, whatever that is. You want to make sure that they have those obvious errors that you're trying to fix. You're not trying to find all the errors in it, though you want the users to try to understand it. Does it make sense, does it flow, does it meet their needs? And this includes where they're testing every little menu going yep, uh-huh, yep, no, I don't like that font color, I don't like that background color, those types of things.
Speaker 2:
Then, once it's once complete, the code is then deployed to production, and then that's where the fun begins. You have your maintenance and change management. This will have this window here that ensures that maintenance is built into the planning process, vulnerabilities and updated code are sent out, and then you need to have a formalized change management process to make changes to your code. It's imperative that you do that as well. So you've got to have the change management piece. We've talked about this a lot in the CISSP training, that you have to have a good formalized change management process, and the reason isn't just to make a bureaucratic challenge, it's to follow have course changes, have documented changes, you know it's occurring, and then when things go sideways which they always do you have a way to be able to go back and look at what happened and then make modifications based on it.
Speaker 2:
So let's get into the different life cycle models. What are these? Okay, so we're going to talk about waterfall, spiral, agile and software capability, maturity model, and then that's more of a framework, and then ideal. Okay, so these are the ones we're going to get into. These are the ones I pull out of the CISSP cyber not CISSP cyber training book, isc squared cyber training yeah, no, I can't even speak the ISC squared CISSP book. This is where we pulled them out of there. There are other life cycle models, but these are the ones we focused on specifically because they're called out in the ISC squared book. So, the waterfall model so if you're able to video or see the video on this, you'll see how the waterfall model works and it all just kind of flows downhill. That's the ultimate purpose of it. And so we'll get into some of the positives and the negatives that roll with this model. I've dealt with both uh, with this one and with agile, my two primary ones that I've focused on. Uh, the spiral I've dealt with a little bit, and a couple other ones that are just on tacit kind of activities. So this one was developed in the 1970s.
Speaker 2:
The waterfall model. It's a series of iterative activities, okay, and these activities are basically seven different steps. So you have the system requirements and we'll get into each of these here in just a minute and you have your software requirements, you have your preliminary design, you have your detailed design, you have code and debug, you have testing and then you have operations and maintenance. So, as you know, we just talked about this at the beginning we kind of went through the same level of steps, different names, different kinds of terms, but overall it's a very similar process than what we just mentioned just a little while ago.
Speaker 2:
So what is the waterfall model? What does it do? It provides feedbacks for defects that are found. So the goal is that, as this thing goes through each of these steps the system requirements, the software requirements it's looking for feedback on the defects and then it goes back up to the next step and we'll kind of get into. But it's like your system requirements, okay, you move it. It's you got all the requirements you need. Okay, now let's go to the software requirements and then if the software requirements there are errors, it will go back. It'll step back one level. It'll go back up to system requirements now if errors are discovered later down the fall, later down the steps, such as in the code and debug area. Well, no, you can't. There's not a whole lot. You can go back to the system requirement. You have to follow through with the fall, unless it's something that is like oh my gosh, terribly bad that you have to go back and fix. But for the most part, if it's a small design change or something along those lines, it has to keep on going and then you'll come back and reiterate it with a, with a new version. So the result is verification and validation process you must have in place before you move on to the next step.
Speaker 2:
So what are some of the strengths with your waterfall methodology in your model? It's predictable and you can have control. So the waterfall structure does approach that minimizes the unexpected changes you may have, providing a more foundational or more stable foundation for enforcing security policies and reducing your overall risk. It's predictable. You have a plan, you follow the plan and you operate with the plan. There's detailed documentation that goes with this. So with each of the waterfall projects, they have a very clear and very specific audit trail, which is very beneficial when you're dealing with compliance and regulatory standards. Now you'll come to find out. There are various regulatory standards that are going to require you, especially in the development space, to have that audit record in place, so you need to have that done. They also have defined testing phases. These are distinct testing phases that allow for comprehensive security testing to ensure your requirements are met before it's actually deployed. So you having this defined testing phase is an important part. And then, lastly, because we mentioned earlier change management, it does have a really strong change management policies as well. Once the changes are limited, once your phase is completed.
Speaker 2:
So it doesn't allow you to go back. If you get halfway down the line, you go oh no, I forgot my screwdriver. Well, that's really not appropriate, but screwdriver drink or screwdriver as your screwdriver. You forgot your screwdriver at the top. Okay, it doesn't even make any sense, but that's okay. You forgot something really important to you. You forgot it. What did you do? Well, I want to go back to the top. You cannot. So the change management process allows you to only go up one more step, but for the most part, you have to follow through, and this does help aid in reducing the likelihood of introducing new vulnerabilities late in the project.
Speaker 2:
So what are some limitations in agile security. It's inflexible. It does involve with involving the various security threats that are in place. So let's just say, hypothetically, you are mid-flight into this waterfall model and you realize, oh no, we have a big security threat. It doesn't. It doesn't have the flexibility that you may need for iterative improvements and the rigidity can delay the adoption of new security measures or fixes. If a threat pops up Now, you'll have to go back through the whole process if you find something that is really bad. But at the end of the day now, granted, I say this if you got halfway through and you went and realized, oh no, omg, we have like the worst hack ever, okay, you're not going to continue, you'll back it up, right, but the ultimate goal is that you don't back it up for just normal fixes or for security vulnerabilities that you find that may not. You don't really know the effect of them, you don't know what's going on, because to stop a waterfall sprint lack of a better term in midstream is very challenging and it causes a lot of confusion. So you really want to follow all the way through with this process.
Speaker 2:
The rigidity can delay the adoptive if security measures are fixed, which we kind of talked about. Now it does have limited response to the change. So waterfall does not accommodate iterative updates, making it challenging to respond when you have security requirements or emerging threats. And then, for long-term projects, this limitation can require revisiting earlier phases, which can be costly, especially from opportunity costs or, if you're hiring contractors, from an actual capital loss cost. They can add up and, depending upon the leadership, they may not want to do it right. Because just say, for instance, this development process took a gazillion dollars and now like, hey, sir, I need to go and ask for some more money and they're going to go. No, you can't have any more money. So, yes, it's one of those things that causes some challenges and then delayed security testing. Testing can only occur after the implementation phase, which can lead to higher costs as well if the vulnerability is discovered late in the development process. So it can add a lot of different things it does. It does work very well, though.
Speaker 2:
The waterfall model works very well. It allows you to get to a point. It has milestones. It's a really good program or project management type of model because it's step one, step two, step c, step four, step c I said step c, step three. My wife gets on my case. I can, can't speak, most days Must be having like mini strokes or something.
Speaker 2:
Okay, so now we're going to get into waterfall versus agile and DevSecOps. So the waterfall is best suited for project with the stable requirements and regulatory constraints. It's a one that you'll want to have when you're dealing with it because of the thorough documentation and predefined security checkpoints that you place in here, and that's an important part. It works well in a highly regulated industry such as government healthcare and where documentation and adherence is important. I'm working in the healthcare industry right now and oh yeah, baby, you got to have lots of documentation. It's to the point where you just kind of want to throw up because it's a lot of stuff and you have a lot of really great people working really hard, but they don't get it very far very quickly because of all the extra stuff that has to happen, so it causes a little bit of a challenge. Agile and DevSecOps so now what's the difference with them? They're better suited for projects where security needs to adapt quickly to evolving threats and requirements. It does allow for continuous testing and integration, and they're more suitable for dynamic environments where it must be continuously tested and the response to new vulnerabilities are highlighted. So that's the difference between it. So you've got to kind of think about which way works best for you, depending upon the environment that you're trying to get into versus waterfall, versus agile and DevSecOps.
Speaker 2:
Next one we're going to be getting into is the spiral model. Yes, as you look at this diagram, you'll see my beautiful drawing on the right hand side. Yes, it's very pretty. It looks like a second grader used a crayon. Did not turn out so well. I didn't know how to make little circle thingies with PowerPoint. So you get what you get. I think you'll figure it out. It's pretty easy.
Speaker 2:
So the point of it is it's in an iterative development cycles. These project passes through multiple phases or multiple times, allowing for gradual refinement of each cycle or iteration. This does incorporate the planning, the risk assessments, development and evaluations that are occurring. Now. Risk management is an important part of all of this and it's a significant emphasis on risk, which, because each iteration begins with an identification, analysis and mitigation planning for risk specifically, and it focuses on this early identification and resolution of a potential critical issues. Now, I've never really used the spiral method, I've just looked at it and read the book on it, but it makes sense how it works, would say it. I personally really like the agile and devsec ops methods in the overall plan, but it's mainly because, probably because I've worked with them and I've never really actually dealt with the spiral model, so some people must really like it.
Speaker 2:
Phases of the spiral you have a planning, risk analysis, engineering and evaluation. Now the planning is helping helps to identify objectives, gather requirements, planning the specific goals and activities for each of these cycles, each of the little pinwheel cycles. It gathers that and then the risk analysis assesses the risk, with the objectives for evaluating alternatives. And, like we mentioned, the SPIRO method is focused strongly on risk, so that's a great time to do that. It's during that second phase. Engineering helps develop the product incrementally through implementation, and this could be you have different types of models and so forth built out, and then evaluation reviews the process with the stakeholders, gathering feedback and deciding whether to move to the next cycle or adjust the priorities as needed. Now there's a flexibility in the feedback are really important with the spiral model. This incorporates changes in feedback at the end of each cycle, making it adaptable to the changing requirements or unforeseen changes and challenges that occur within your network. It's important on projects with evolving requirements and allows for the team to pivot or adjust as it's going around the pinwheel on the valuations at the end of each spiral, around the pinwheel on the valuations at the end of each spiral.
Speaker 2:
So you basically have phase one. You do your little whoop-de-woo and you come back and you hit it phase two, phase three and so on and so forth, and each of these times, these iterations, you will make modifications to it. So again, it's very similar, right? You just you go, take a couple steps. You then re-evaluate, take some steps, re-evaluate Very similar to all of these different models, except you just did like in the waterfall. You can't re-evaluate and reassess. You have to go through the entire process. This one you re-evaluate and reassess before you move on.
Speaker 2:
Now there's a prototype development that can occur in the engineering phase. Now this is used to validate ideas, functionality or explore specific risks that you're finding. So the overall engineering you're dealing with a prototype. It could just be with some prototype of the development that you have, your code that you've created. These prototypes provide tangible, testable models for stakeholders to review and there would be some level of user acceptance testing in this and help them, refine the requirements and reduce ambiguity of the earlier life cycles, of the earlier spins around the pinwheel, and that's the ultimate goal is just to help get that kind of feedback loop from your people.
Speaker 2:
There's defined entry and exit criteria. Each phase with the spiral iteration will have a specific entry and exit criteria, meaning the objectives must be met before moving forward. You can't move forward unless you go. You've met the objectives that you highlighted at the beginning of this process, because otherwise then you, instead of having a nice clean pinwheel, you have a pinwheel that looks more like my pinwheel that I have on my graphic. No, not quite that good. It's actually pretty impressive actually for a guy that's my age my dementia came in. It's got a clear criteria to help ensure the phase is completed, to set standard risks at each step and avoiding moving forward with unresolved issues. So that's the ultimate point is you have to find entry and exit criteria.
Speaker 2:
On the specific model that you're working on Now, there's a cost and schedule estimation per cycle. This is an important part as well is you're going to have to make sure that you have proper resources set aside and you'll need to make sure you have estimates on the time and the amount of money that's going to have to make sure that you have proper resources set aside, and you'll need to make sure you have estimates on the time and the amount of money that's going to take for these specific reach. Just reach these specific and attainable goals. You have an incremental estimation approach allows for more accurate planning and budgeting as well, and then you have a cumulative process. Each iteration builds on the progress of the previous cycles, leading to a development and refinement of the overall product itself, and it allows you to adapt and evolve, moving closer to the final product, even with the changes along the way.
Speaker 2:
Now the Agile method. Let's go into that one. So we were dealing with Agile method. It was developed in the 1990s.
Speaker 2:
In 2001, there was a manifesto for Agile software development. It's a big $10 word to make you sound really smart, but it's basically a document, right? Manifesto. There's 12 key principles with working with this and it does work. Software is primarily the measure of progress. A working product that you have at the end is usually the measure of success. When you're dealing with agile and with all these, they really are. But Agile tends to you have something and then you start iterating on it.
Speaker 2:
Now there are many different variants of the Agile methodology. There's Scrum, there's Agile UP, which is Unified Processes. There's Dynamic Systems Development Model, dsdm, and then there's Extreme Programming XP Not XP, the Windows XP, but Extreme Programming XP. So there's different types of Agile that are available and we're not going to go into all those. We'll focus a little bit on Scrum, because Scrum I've worked with, but you may want to understand a little bit more of all of this, just so that you understand how they work and what's the purpose behind them. Okay, agile Scrum this is the security integration of the Agile environment. So you've got some different topics we're going to go over when relating to the overall scrum process.
Speaker 2:
But collaboration is a key factor. This allows for continuous communication and collaboration between security development and the operations team. It's a collaborative meeting. You would have daily stand-ups and these stand-ups you would collaborate and talk about. What are some of the changes you need to make? There's security in user stories. So what are user stories? It outlines the requirements from the end user's perspective. It integrates security into these stories, into each of these, and it helps ensure security is part of the development from the onset, such as security acceptance criteria. Then you have the definition of DUN D Done can incorporate security criteria ensuring that all the tasks meet a specific security requirement before they get marked complete.
Speaker 2:
So you have to have that done before you can actually move on. If they're not, they don't meet the criteria then you don't move on and then you may have to set up another sprint that deals specifically with those criterias that were missed. Now the sprints for security testing basically the iterative sprints, allow for regular security testing and feedback. These should be short. They should be really quick, no more than two weeks. Ideally, a week sprint would be awesome, but they kind of tend to be about a week to two weeks in duration. This does enable the team to identify and resolve security issues as the project progresses rather than once the development is complete, such as in the waterfall method.
Speaker 2:
Now you're going to deal with some artifacts of dealing with overall scrum. You have backlogs. You have your product backlog, sprint backlog and then you have the increment, the product backlog. This is where things are added directly to this backlog, ensuring they are prioritized and addressed systematically. So what does that mean? So that means you have different requirements in your product backlog that need to be made. Then these user stories might include tasks such as threat modeling, pen testing, code review. All of those aspects might be within your product backlog that you need to occur, your product backlog that you need to occur. And then you will just use a menu and you will pick through those to decide based on risk and based on what you can accomplish in that scrum, what, and that sprint, what you can do. You will then call that into it.
Speaker 2:
Now, the sprint backlog this is where tasks are prioritized and assigned to ensure they're completed within the sprints framework, so within the timeframe you have. So you take from the backlog, you put it in the sprint backlog which is in this sprint we're going to accomplish. So the backlog has got, let's say, 50 different things you have to get done. The sprint backlog, the sprint that you're going to focus on, this one week, two week thing, is got X amount right, so it's got less than the overall gazillion that are in the backlog. But those are prioritized. Then on which ones can you do this sprint? So if you can get them all done, awesome, that's great. But if you can't, which ones are the best prioritized? And that's the sprint backlog. Then you increment each increment that should be delivered to meet the organization's secure requirements, such as what is the definition of done? This ensures that security is progressively integrated throughout the entire development lifecycle.
Speaker 2:
So what are some of the roles and responsibilities of Scrum? So you have a product owner. This person is responsible for the requirements, ensuring that everything is prioritized, security-related user stories are put in place and they'll work with the security teams to understand and communicate the implications to the Scrum team. So if you're the product owner for the full-up development, you will own the overall development plan. If you're the product owner for the full up development, you will own the overall development plan. If you're the product owner for security, you will then make sure security is embedded within the development piece. You have your scrum master this this person advocates for best practices within the scrum team and they ensure that that the secure coding and testing is completed. They also help identify and remove obstacles to security tasks, facilitating more secure environment. Then you have your overall development team. They are the ones that are directly responsible for the secure coding practices, conduct peer reviews, perform unit tests and so forth. They're the ones that do all the work and they help gain a clear understanding of what the requirements are. Now I will tell you, you're going to have to be well invested within the development team if you want to incorporate your security mechanisms into it. It's an important part that you do this. You stay embedded and, in fact, you are working with them closely, so you need to be part of the overall scrum that's going on Now.
Speaker 2:
Scrum is part of a. I think what is it? What is that football game? Oh, it's gosh, I can't. It's rugby. It's part of rugby. So same kind of concept. You're working together, try to get the ball down the field. Kind of like football, but different. Same, but different. Rugby. Actually, football came from rugby. From what I understand, the american football, not soccer. Um, so the scrum events and security enhancements. So, sprint planning you have different pieces. You have your sprint planning.
Speaker 2:
This was an opportunity to address some priority security tasks for the upcoming sprint, to ensure that your requirements are ready for the plan. And then you have your daily stand-ups. Done these, oh, so many times. They're great, they're wonderful. Yeah, no, they suck a lot of time. But no, they shouldn't. They should be very quick. They should be like 15 minutes in and out. Nobody gets hurt. That's the ultimate point of them. But they're designed to discuss any challenges, update and encourage culture, and then, if there's any security blockers that can be flagged and resolved, they'll help with the overall process in compromising and fixing that. There's a sprint review.
Speaker 2:
This is done by your security teams, your stakeholders and the developers. They all participate to assess whether the security standards have been met and they have met the deliverables. You need to allow your security professionals the ability to give feedback, and so forth. The same with the developers. Let them give you feedback as well. If they say this security control you want me to put in place is only for an idiot, do not do it. Then you need to listen to them. Do not discount what they have to say. At the same time, they may say this kind of security control is going to add all kinds of drama with the end user. Listen to them. They know in many cases, better than you do, and so, therefore, it's important that you understand that.
Speaker 2:
The software capability maturity model Okay, so the CMM or the SCMM, so this came from the software engineering Institute at Carnegie Mellon, sei. And, yes, carnegie Mellon big brains, very smart people. So, yes, they came up with some really neat stuff. This is the quality of the software is directly associated with the quality of the development, and their point is that it was a process improvement framework. And this provides organizations with a structured path to improve their process, their software process, versus an ad hoc, chaotic practice to structured, mature and reliable processes. Now, everything I'm telling you here, you guys, they're all structured and reliable, right? That's the ultimate goal. You just have to figure out which one works best for you and your overall company. Now the primary goal is to improve the quality and predictability and control the software development process, again ultimately leading to higher quality software with reduced costs and risk.
Speaker 2:
Now the applicability yeah, that big word that's how this works is. It's initially designed for software development, right, but it also can be applied to other areas, such as systems engineering, acquisition and security practices as well. So it's very applicable. See, I can't even say that word, it's too early, it's 5.30 in the morning, so, yes, it's quite early for me.
Speaker 2:
Moving on, what are some levels of the CMM maturity model that they have? So we're going to walk through each of the different levels so you understand them. And there's different key process areas, or KPAs, that are associated with this. So level one is the initial. It's the chaotic, it's the oh craziness, we don't know what we're going to do. Its process are unpredictable, poorly controlled and reactive, and its success will depend on the individual effort rather than an established process. This is the beginning phases of it.
Speaker 2:
Now, the ultimate goal of this is to move away from the chaotic process to an established basic process discipline. So, when you get something started, a lot of times there is some chaotic mess that you're trying to figure out. The next level is you take it to a repeatable or managed process, and this is where you have project management. Practices are established, the processes are repeatable for similar projects, and then they become even though they might still be a little bit reactive. Now, this is where the first security controls are introduced, and this is where you add security-related tasks such as vulnerability management, patching, and all those are added to it. The KPAs on this would be. It includes requirements, management, project planning, project tracking, configuration management and so forth. So you go from chaotic to managed, and then you move into a defined Okay, this is where your processes are documented, standardized and integrated into a unified organizational process. Okay, you have structure, structure, yes, proactive approach for developing security, and then the ultimate goal of this, then, is that your practices are formally integrated into development lifecycle and this is where their policies and standards are created. That's what the focus of those is, so that in this space you now have that ability to document and have those policies flushed and vetted out. Kpas will focus on an organizational-wide standards and training and an integrated software engineering plan. It emphasizes a well-defined development life cycle.
Speaker 2:
Then you have level four, your managed, quantitatively controlled piece. See my third grade. Education just struggles with these. It just truly does. So the characteristics of these are they're quantitatively measured and controlled. This is where you get metrics. Metrics are incorporated into this and it helps identify many areas for improvement. You have security enhancements, such as metrics, and are all collected in a very proactive managed risks. Then you have kpas, which deal with quantitative project management and process monitoring, helping organizations make data-driven decisions. That's again. That's the goal, right. So now you got into managed level a, level four and then level five, the final melon with the levels.
Speaker 2:
This one focuses on continuous process improvement, or KPIs, using the feedback back from the previous levels to refine and enhance the process. Okay again. So you have the five levels, you work through the five levels and then you begin to optimize this. This is where your continuous security improvement is an important factor and this is where you refine the measures, adopt the latest security innovations and so forth. Your KPAs will include change management, defect prevention and continuous improvement. This may be regular threat intelligence, if you're dealing with security, and then your adaptive security measures that are built into it. So that's how you optimize it.
Speaker 2:
This is the levels of the CMM maturity model, based on what Carnegie Mellon came up with. Now the CMM and security and software development. What are some of the benefits of this? Now, that's predictable and there is control. Again, organizations with mature processes level three and above have a very predictable and controlled, repeatable process. That's the ultimate goal. They have something. And again, these guys, these frameworks, are just designed to help you. You may already figure some of this stuff out, but they're designed to give you something to go to, like a touchstone, to come back to a framework that you can bring to your people and put it in front of them so they understand what you're trying to accomplish. It has improved security posture, obviously, because the different levels will lead to stronger security measures and their security is formalized and embedded into the overall development process. It does enhance compliance, right, because there is standard documentation. Now you get to level three and above. That's where you have that. That will be. Compliance is very valuable there because you have that defined, and then it can make it a much more efficient incident response process, especially when you're dealing with teams that have clear processes and metrics for responding to the overall threats.
Speaker 2:
What are some challenges with using the CMM? It can be resource intensive. Reaching a higher maturity levels, particularly four and five, can have significant investments in development, training and tooling that people will have to have be trained on how to do all this stuff, whereas it's just more of a. You move from one level to the next level, to the next level as an organization. As you get up there, it takes more and more money and more and more resources to do so. There is complexity and resistance to change. Again, moving from the ad hoc processes, which is level one which most people operate in and all of these will be very valuable if you're trying to move from the ad hoc process to a managed or optimized level does require cultural changes and it's going to take significant cultural feedback and invaluable information from your senior leaders to help you get to this potential issue or get you to where you want to go.
Speaker 2:
Now, the potential for bureaucracy obviously that various levels lead to excessive documentation or processes, which I'm running into now, and what ends up happening is it can slow down development if it's not balanced properly. You've got to have it, but You've got to make sure that you don't go and create documentation for the sake of documentation. One of the things when I worked at Koch Industries, charles Koch made a comment to some of his leaders not to me, obviously, but he made it to the point of charts for Charles. People would just make charts just for Charles specifically and he's like that's wasteful. Why are you doing that? So you don't want to have too much over bureaucracy. It helps cause lots. It actually looks very wasteful.
Speaker 2:
The ideal model so what is that? So the ideal model is a process of improvement model that provides structure, phased approach for implementing organizational improvements and it what it stands for is initiating, diagnosing, establishing, acting and learning. Yes, the ideal is capitalized, not just because someone forgot to leave the, the lock off. It's because it actually stands for something Initiating, diagnosing, establishing, acting and learning. Now, this was developed by SCI and it's used for software engineering that can be applied to cybersecurity and risk management practices. It helps organizations implement improved security practices systematically. So, again, another model for you to put in your toolbox and determine if it's something you want to use.
Speaker 2:
Okay, so there are three phases within the ideal model. We're going to start with. Number one is the initiating phase. This is where you lay the groundwork for the improvement process by setting the goals, ensuring you have stakeholder buy-in, you have sponsorship and you've established commitment from your stakeholders on what they're going to do. Now. The key activities that come into this is that it's an improvement initiative which includes strengthening your security controls. It needs to have executive support right, like all of these really do. They all do and then identify and engage your key stakeholders, including IT security and your business leaders. These are some of the key activities that go with it.
Speaker 2:
Now, diagnosing phase. This assesses the current state to identify gaps, weaknesses and areas for improvement. Your gap analysis will be done to identify your current strength and deficiencies, and then you'll also perform a risk assessment to identify and prioritize your security risk. That's in the diagnosing phase. And then you'll document these findings to provide a baseline understanding of your current state. So, again, you'll create some documentation. Where are we at? We initiated it. We diagnosed ourselves Doctor, where are we? And the doctor says the patient will live. That is the diagnosing phase.
Speaker 2:
Established phase. This develops a detailed action plan and defines specific goals for improvement initiative. You'll develop a roadmap with action plans and outline steps. You'll set measurable goals and milestones to track progress and then you'll define your resource requirements, including budget, personnel and tools to ensure you happen. This is an establishing phase. You'll establish your policies and procedures and metrics that align with your industry standards and regulatory requirements Again establishing what you need to have accomplished. That's the establishing phase.
Speaker 2:
Now, each of these phases do not happen very quickly. It will take time. It will take time for you to develop this and as you develop it. Again, this takes resources, but there's various phases you have to go through with this ideal model. Then you have the acting phase not acting on the stage as an actor, no, you're actually putting things into place. So this is the execute the action plan to implement improvements and achieve the desired security objectives, these changes to security processes and policies and technologies according to the action plan. And you'll ensure that your employees are understanding of what's going on, because you're going to have to raise awareness with them.
Speaker 2:
During this phase, the acting phase, you're going to monitor progress against milestones and adjust as needed, and then you'll develop, test and validate the security improvements to ensure they meet the established requirements. That's the acting phase. And then the last phase is the learning phase. This is where you evaluate the results, improved effort and identify the lessons learned and refine your improvement initiatives. Now, some key activities in this area is that you're going to obviously analyze the performance data and understand what's going on. You're going to gather feedback from the stakeholders to determine what worked well and what challenges did you run into. You'll document your lessons learned and improve future initiatives and then you'll make adjustments to security based on your overall insights gained.
Speaker 2:
So again, that's the ideal model. That's the five levels. So what are some benefits of the ideal model? Clear structure and accountability. It provides a structured approach and assigns clear responsibilities and objectives, helping to ensure accountability at each step. It's improved resource management right. The ideal model does help with your resource management and ensuring that you have executive support. Now I will say, on all of these, you have to have some level of executive support. So you know what it's kind of one that blends across all models, but I would say that in the sprint planning and so forth, the different models there I've been able to develop those without executive leadership buy-in the resource model. You're going to need that because you're going to end up doing a lot of training and you need to have a lot of people involved in this, so you'll have to have budget, tools and the personnel needed to make sure that this is done correctly, and then you'll have a long-term security. Maturity is going to need to be built and ensure that it's put in place effectively. All right, that is all I have for you today. I hope you guys have a wonderful day.
Speaker 2:
Please go to CISSP Cyber Training. Go check out the products I've got there available for you. As you can tell, there's lots of change happening on CISSP Cyber Training. There's always new content being posted in the site. It's growing. It's amazing because you know what I got. Great people like you all that listen to the podcast as well as go to the training and give me feedback. Go there.
Speaker 2:
Anything you purchase at CISSP Cyber Training goes to our nonprofit for adoptive kids. So, again, all the money is going to that. So that's a great cause, great way for you to be able to give back a little bit and get some great CISSP training. It is, it's really good, and I know all of you are worried about money. It's understandable and I get it, totally get it. So that's why the price point to get into it is very, very low. I mean, it really is. It's like going out for dinner kind of low. And the purpose is I want to have you guys have the ability to get the training that you need as quickly as you possibly can and get at it. So again, go to CISSP Cyber Training and hope you have a wonderful day and we will catch you on the flip side, see ya.
CISSP Cyber Training Academy Program!
Are you an ambitious Cybersecurity or IT professional who wants to take your career to a whole new level by achieving the CISSP Certification?
Let CISSP Cyber Training help you pass the CISSP Test the first time!
