Step two is system design. This is where we're going to take the requirements John has shared with us. I want B. I want this element from D, bring it in for me. Add it all together. Let's sketch it out. Let's kind of draft it, if you will. Let's take a look at it. In system design, we're going to lay out the blueprints, start figuring out exactly what's going to happen, how it's going to look, how we're going to build it, what the tolerances are, all the standard things you would think about. We're going to draft in other words, traditionally. And then with implementation, we're going to build individual components. We're not building the whole system yet. We're not building the sprocket. Let's theoretically say that, for our purposes, the sprocket is made up of three distinct pieces, three distinct parts or modules of functionality. Sprocket A, sprocket B and sprocket C. They all have to go together. So, in the implementation area, we're going to actually take the design we've drafted and designed, and we're going to build those three parts: sprocket A, sprocket B and sprocket C. We are going to stitch them all together. And what we're going to do is see that they actually work. But we're not putting the whole system together yet. We're building individual module or component parts. In integration and testing, that's where we actually join sprocket A, sprocket B and sprocket C together to, in theory, achieve the full design of what John has envisioned, this idea of sprocket B plus the feature from D, what we're calling sprocket B plus. So we're going to integrate. Take those individual parts, put them together so we have, in theory, a full sprocket. We're going to test those individual parts, and then we're going to test the whole thing. We have to test individual modules. We call that unit testing. We're then going to go ahead and test the entire system together. It's going to be functional testing. We're going to do all sorts of different testing to ensure that the individual parts, plus the whole or the system together, the entire sprocket, works not only as we've envisioned it but works specifically aligned with the requirements that John, our stakeholder, has specified he wants for the sprocket at the finish or at the end of this process. Once we're done with integrating and testing, assuming, of course, that everything goes well, we've integrated everything. It all does fit together. We've tested the individual parts. We've tested the whole. That all seems to work. Once we've done all that, then we actually deploy the system. The system is the whole sprocket, what we call sprocket B plus. We're giving that effectively to John. We're producing as many as John wants, whatever the order says, and we're putting those into production, whatever the sprocket does, whatever it would actually do. We're turning it on in effect. We're deploying it. And once we've done that, at that point, the system is live. Right now, we have to go into maintenance mode. We have to maintain that system. So, in other words, if there are any updates required, there's any maintenance to keep the sprockets running well. Maybe they have to be oiled once a month. Maybe they have to be turned every 60 days. They have to be flipped over so they wear evenly. You can imagine all sorts of things if it's a physical, mechanical device. If it's a computer, we have to keep up with patch management. We have to keep up with vulnerability assessments. We have to apply whatever best practice guidance the vendor recommends. There's lots of different ways you could approach the concept of maintenance. But the ideas that we have to effectively maintain that system in a healthy operating known state that is secure, that focuses on confidentiality, focuses on integrity, focuses on availability, throughout the lifecycle, the useful life of that system. When that system is no longer needed, we may decommission it. We may turn it off. We may see that the end of life is coming, but we have a problem. We may not be able to turn the system off just yet. We may need to extend its life. That may happen during maintenance with additional things that have to be done to keep the system running longer. We may decide, through this process, that we're going to go and update the system, give it some new features, some new functions, things of that nature. So, coming out of maintenance, we will go back and effectively start a requirements gathering and analysis process again, and we would step through all the stages to update the design through implementation test, integration and ultimately deployment, put new features into the system, and then we would maintain those. So we could see individual aspects of this model occurring at different stages. Stitching them together gives us the entire model, and we could see that we may go back through the model multiple times over the life cycle to produce new updates, new features and new functionality that may be required. The waterfall model is going to be model that moves in a linear fashion. We progress, remember, from one stage to the next. You can almost imagine it as a set of steps, and as we flow down each step, we are moving to the next stage towards the bottom of the model as we go down this way in theory. And the output from one stage becomes the input for the next. These are all hallmarks, characteristics, of the waterfall model. It would be important for you to understand the stages of any of the models in any of our discussions that we may go through. If we lay out a process of any kind, if we lay out a flow that is linear, that has demarcated steps associated with it that go from one to the next, it's your responsibility to understand what they are, as you prepare for the exam, as you ultimately look to become successful as an SSCP, both in the exam and out in the real world. You need to show mastery and be able to apply this knowledge so that you can use your skills, not only in the exam to answer questions but certainly in the real world as well. So you can go and potentially design a system using the waterfall model as your methodology. You may or may not choose to do that, but you need to, at least, understand how it would be done so the people that do engage in the SDLC methodology, in this case, the waterfall model methodology, can have a conversation with you about security. Where does security plug into this particular model? At what stages should we be focusing on security? That's a great question. And the SSCP should be able to sit down with system engineers that do this kind of work and have that conversation. You should be able to contribute to it. You should understand where to plug security in. And you should have valuable insights and valuable input that you can offer them to make sure they are added security in wherever and whenever appropriate. If you're not sure where to plug security in on the model, the answer to that question is secure early and secure often, generically, meaning, we always want to try to apply security at every stage of any model we engage in because the more security we lay in, the more likely it is the model will render a secure product on the back end. And so with something like waterfall, we should be thinking about security right at the very front of requirements gathering analysis. When John comes to me and says, "Adam, I need you to help me design a sprocket, and what I'd like to see is what models you have." And we walked through a whole conversation I laid out for you, and John says, "I want B with the element from D, what we'll call B plus." The next part of that conversation if we're thinking about security is, "Okay, John, let's talk about what's driving the need for you to have this sprocket work this way. Is there something specific you're trying to accomplish? Is there a business requirement you're looking to align with? Is there a need you're looking to address?" John may say, "Yeah, I've got this issue, and I was told that if we do it this way, then this should solve it." "Great John, what's that issue? Let's throw that out there. Let's make sure we both understand it. Let me examine it because I may be able to offer you some insight about the security implications of adding this function or this feature from D. This may or may not be a good idea. And we want to talk about that because adding it may be perfectly fine, may not impact confidentiality or potentially impact availability and/or integrity. Or you know what, John? When we add this in, guess what? We're not going to be able to ensure confidentiality of the data that the sprocket interacts with because this thing is going to expose the data, whatever the feature is from D that we're talking about. It's going to expose the data. Then we really don't have a good solution to deal with that." If we don't realize that upfront, we may not be able to see that until three or four stages in, where we get to integration and testing. We've already invested a tremendous amount of our time, potentially certainly resources like money, and we're almost at the point where John's expecting a fully functional sprocket. If we realize at that point that we've broken confidentiality by adding this feature that John wanted, we may have to go back to the drawing board and start over again. It's going to cause all sorts of delays and problems. That's really at that point, still good that we caught it but bad that we caught it so late in the process. And so the idea about building security in from the beginning is one of those things that becomes very critical for us as security practitioners to focus on because if we're not focused on security at every opportunity at every stage of the process, we're going to have a problem. We're going to act or react way too late in the cycle, and it's going to be very difficult for us to roll back and reassess and figure out how to do something at that point. So you have to be thinking about all these things at the same time you're talking to John as the customer, as a stakeholder, and John saying to you, "This is what I want." This is what goes through the mind of the CV SSCP when we sit down and have a conversation like this. If we're not doing this, if it's not us that's driving the SDLC in this case, but a systems engineer or design professional, whoever that may be, may be a business analyst or a project manager is gathering requirements initially because they tend to do that. That's one of the things they specialize in. They may then come back and work with members of a team to do design and implementation and certainly testing. These are all specialized skills. So if there's a team of people driving this methodology and engaging in this SDLC, you need to be a member of that team as the SSCP. You need to be the voice of reason. You ultimately need to be the voice that says, "Hey, what about security?" Because all those other people are going to specialize on the things that they know how to do. They're going to focus on them. They're going to be focused on testing. They're going to be focused on design. They're going to be focused on requirements gathering. They're not going to focus on security. It's not their specialty. It's typically not their forte. Just like design may not be yours. Testing may not be yours. That's why you need a team. So in this kind of an environment, where we use this kind of a methodology, it's really critical, very critical, for you as the SSCP to represent the voice of the security concern and to bring that voice up and bring it in as early and as often as possible. As I said, secure early and secure often. That's the mantra of the SSCP.
