Hello, and welcome back. Let's turn our attention to participating in asset management. Within the security operations and administration module that we're discussing the general topics in, we've been discussing a lot about the different ways that as a security practitioner we should go about conducting ourselves. How should we deal with things? What's the perspective we should have? How should we look at them? How should we administer them? How should we account for them? When we think about participating in asset management, we really have to think about all the things, the stuff, that we have in the business that we have to account for. We probably have servers, we have laptops, desktops, most likely today, mobile devices, there's mobile phones, there's tablets, there's all sorts of different solutions. In addition to all that stuff, we have routers, we have switches, we have IDS and IPS systems, firewalls, all sorts of things that we would ultimately, as security practitioners, have to be focused on. Understand the configuration of, understand the deployment of, understand the current state of. And these are all things that we need to be aware of. When we think about asset management and participating in asset management from an operations and an administration perspective, we have to be able to identify and define the things that we need to consider an asset. First thing we need to figure out. We then have to understand how to account for them, inventory them in effect, and understand where they are. We then have to look at their current state, understand how they're configured today, keep track of that in some way. And ultimately, manage those devices, manage those assets to some sort of desired state. Going from as-is, what it is today, to the to-be, where we want it to be over time, patch managed, up to date with firmware updates and all the guidance from the vendors that we may receive, in terms of configuration, whatever that may entail. And so we consider, as you see the module topics on the screen, what we call a life cycle. How do we go through the asset management life cycle? What does that look like and what is it going to be? Those are some of the things we'll be discussing. We'll take a look at both hardware and software based solutions. And, in general, we'll reflect on the concepts of data, and how assets and data together really become important with regards to asset management. Knowing what we have is important, understanding how to describe it, manage it, define it is also important. And the two together are obviously going to give us a much stronger capability in terms of reporting and ultimately accountability for our assets. Let's jump in and start by talking about some of the models that help us, from a development perspective, to look at assets in terms of their creation. When we think about asset management, we have to define what an asset is. An asset could be a piece of hardware, could be a software item, some sort of program. Or something we may either build ourselves internally, usually in a development team of some kind, or we may go out and buy what we call COTS, commercial off-the-shelf software, would typically fall into this category. However we get software, somebody somewhere had to build it. However we get hardware, somebody somewhere had to put it together and create a system. However that's done is going to involve what's called an SDLC, a system or software, interchangeable for the S, system or software development life cycle. Depends on what we're doing. If we're building software, the S stands for software. If we're building a system, hardware being combined to create a desktop computer, a server, a laptop, whatever it may be, we're focusing on the system concept. So the SDLC is all about how we build software or systems. And we have what are called different methodologies or different approaches that we can use. We'll talk about some of the standard ones. The waterfall model on the screen in front of you is one of the most common ones you often hear about. There are several others, and we'll come to those in just a couple of minutes. When we think about waterfall model, in terms of the SDLC, the development life cycle, we're thinking about a structure, a framework that allows us to walk logically through a set of steps. You can see them outlined on the screen in front of you. There are six steps we typically associate with the waterfall model. And we walk through them linearly. One system, or one step rather, will lead to the next, the output of one becomes the input of the next. And as a result of that, we have a progressive process that through the linear progression as we move through the steps allows us to, at every stage along the way, figure out exactly what we're doing, come up with a very specific output, measure success by producing that output. And then giving that output to the next stage to act as input as we progress through the system. And over time, as we go through the whole life cycle, at the backend we ultimately not only have an operational product, but we are then able to maintain it. And ultimately, through the use of that product over time, or that system over time, dispose of it when we no longer need it. Or refresh it through some sort of iteration. So let's quickly talk about what the steps are. You can see them on the screen in front of you. We start with requirements gathering and analysis. We have to figure out what it is we're looking to do. Somebody comes to us and says, hey, Adam, I want you to build me a sprocket. Okay, I'll say to John, if John comes to me and says, I need a sprocket. John, what in your mind is a sprocket? Help me to define that because I'm not sure what a sprocket is. There's three or four options for sprockets. Let's look at the different designs I have that represent what a sprocket may be. There's A, B, C, and D, do any of these look like the sprocket you had in mind? John may look at them and say, Adam, I'm kind of partial to B but we can modify that a little bit? Because I like this one thing over here that's in the design that you called D, and I want to add that to the design that you're now referring to as B. And if we can combine those two together you've nailed my requirements. You got exactly what I need. I want you to produce that sprocket based on the design from B, but add that little feature from D, let's call it B plus. And as a result of that, if you could build that for me I'm going to be happy. So I've gotta interview John, I've gotta talk to John as my customer, my stakeholder in the process. John has to tell me what his requirements are, the things he needs to have when we're done at the end of this process are the requirements. I've gotta gather those. So I'm going to interview him. I'm going to go out and speak to probably other people that build sprockets, other people that use sprockets. I'm going to speak to other people in the organization besides John, understand what their vision of a sprocket is. What's motivating John, in other words? And why does John want a sprocket that's B plus instead of D, just D, with all the features that D entails? I gotta understand that. Because if I don't really understand that, I'm not going to be able to build John the sprocket that he envisions and that he wants. So I'm going to requirement gather, I'm going to requirement analyze. Does B plus the feature from D equal a functional sprocket? That's really important. John may envision that and say, well, that's what I want. But we may go to build that and find out that that feature, that item he wants from the D design, really doesn't work in the B design. It's just not going to sit well. The sprocket's going to get all jammed up when it goes to turn. And it's just not going to be a good design. We gotta figure that. Now we may start to figure that out in requirements gathering and analysis. But we may not really see that totally until a little bit later in the process. because it may not be apparent on paper, as we look at those requirements and try to piece them together. At this stage, we're just really sketching in our mind and maybe drawing out some basic things and documenting them. But we have no real conception yet of what this is going to look like. We haven't designed it, we haven't really gone through and put it all together and seen what it will look like. We're just writing a bunch of stuff down and trying to generate a picture in our mind to start the process. It may not become apparent to us that we have a design problem based on the requirements chosen. But we're going to try to be as analytical as we can at this stage, understand as much about what John wants. And if we can nail those requirements and really make them work, we're hopefully going to have success at the far side of the process.
