Welcome back. Today we're going to begin our coverage of Domain 3, Security, Architecture and Engineering. The goal of the security architecture and engineering domain is to provide you with concepts, principles, structures and standards, used to design, implement, monitor, and secure operating systems, equipment, networks, applications and those controls used to enforce various levels of confidentiality, integrity, and availability. In this particular domain, we're going to cover a fairly wide variety of topics. We're going to cover things such as, processes using security design principles, fundamental concepts of security models, selecting controls based on system security requirements, security capabilities of information systems, vulnerabilities of various security architectures, designs and solution elements, cryptography, physical security. So that we cover the full range of topics, that would be considered by a security professional, in the course of designing, implementing and operating a security architecture to secure an enterprise's most precious assets, its information. So as you see, we have some fairly ambitious goals for this particular domain. In that it covers a very wide variety of topics. It's going to appear as fairly diverse here, and again, on the exam itself. But like the other domains, it will be equally represented, or very close to that with the other seven domains. And, it will treat in a fairly even handed way, the material that's covered here. 

So, we're going to look at comprehensive and rigorous methods for describing a current or future structure behavior of the organization's security processes. Examine the principles, means, and methods of applying mathematical algorithms, i.e. encryption. We will of course, focus on the threats, vulnerabilities, and countermeasures that can be utilized to physically protect an enterprise's resource and sensitive information. We're gonna start with section one, Implementing and Managing an Engineering Lifecycle Using Security Design Principles. So we're going to look at security engineering models and processes, securing information and systems, and secure lifecycle frameworks. So in thinking about security architectures, what do these things all have in common? We know that the various authors and creators of these security architectures and frameworks, all typically have their own opinions, their own approaches, and their own intentions about what the security framework they're considering, should address. Sometimes it's a deviation from one that they've encountered before and they feel they have a better idea. Sometimes, it really is seminal work that no one has really touched on in any kind of depth, or to any extent. But, in each case, they each have their own discrete methodology, as reflected by that author's opinion, knowledge, experience, and so forth. They build their own discrete views and viewpoints. They will address normative and non-normative flows of information through systems and among applications. They introduce their own normative flows through systems and among applications. Many times they will introduce unique and single purpose components into the design. And, as a consequence of these architectures being unique themselves, they will call for their operators, their designers and implementers, to have a unique set of skills and competencies in the particulars of that architecture framework. 

Now here, you see that there are several different documents coming from well recognized international sources, that describe the different architectural approaches. Now, as I've said in past modules, when it comes to the documents that you see expressed here, as international standards or as U.S. centric standards, these things will not be asked of you as though you're an expert in any one particular one. But what they will do, is they will present the commonalities that they all share, such that, presented in a given context, you would be able to answer the question recognizing the potential source. So, we have the ISO 15288 Systems and Software Engineering. We have INCOSE, the International Council on Systems Engineering and their V Model. We have the NIST SP 800-160, for System Security Engineering. Another ISO volume 15026, for Systems and Software Engineering, and the ISO 21287, The System Security Engineering Capability Maturity Model. Now these systems and system security engineering processes have converged across major sources. For example, NIST and INCOSE, recognize system security engineering as a specialty engineering function. ISO has published three works above. But what we see from all of these is that they are intending to apply commonly accepted system security engineering principles to the area of systems security, an area that is commonly thought of as being a series of point solutions, and not having the same kind of systems engineering rigor that normal systems engineering professionals and practices have developed over the decades. And this is, these are all attempts to bring that kind of rigor to system security engineering, in particular. 

Now, the 15288 of 2015, covers processes and system lifecycle stages. And in its contents, it defines four basic categories of activities. Agreement, organizational project enabling activities, the technical management, and then of course, the technicalities of putting the design together and then building it from the components available that have been selected. NIST publishes a guide that acts as a general guide to the approach to systems security engineering. The generally accepted principles and practices for securing information technology systems, is embodied in special publication 800-14. This document serves as a foundation upon which organizations can establish and review information technology security programs. And it captures eight principles and 14 practices that provide an organizational level perspective for technology security. Now, this is very important, as the low number indicates this document has been around for many years. But what it sought to do when it was originally published, was to elevate the status of system security engineering, by bringing the eight principles and 14 practices into a more common realm of acceptance. And elevating it further, by making it more of a business concern than has had commonly been perceived, a technological concern only. Having the business involved meant that business priorities were going to be addressed, that technical and non technical aspects would receive the appropriate level of attention in each case, so that a balanced but thorough approach would be made towards the subject area of system security engineering. 

Here you see the INCOSE V systems engineering model. Now as we walk through this, we see that across the top, there are phases, one minus, phase zero, and then the actual process of phases one through five, as they move through the common phases, from concept through the actual system refinement, system replacement, kinds of activities. So what we have, is we have the basic construction of an architectural concept. From there, in the language of project management, we go through progressive elaboration. We start the process at a very, very basic, very general level. And with each phase, we successively do progressive elaboration, to add detail, to add additional refinement, maybe change some of the requirements, add some requirements, discard some adding others, so that down the left hand side of the V, we're going through the process of developing our architecture. When we get to the bottom of the V, we're actually starting to build what we have designed. And then as we move up the right hand side of the V, we're doing integration, we're doing reconfiguration, we're doing additional forms of engineering to get the system that we've designed and built into operation and integrated with existing components. And then as we move across the top of the right hand side, we move to end of life, and we start to go through the process of designing this particular systems replacement. And by the time that's ready, and implemented, we start moving into, for this one, we start moving into the retirement phase. 

Now throughout this, there will be the technical processes that you see on this particular slide. And as you see starting out, business submission analysis processes are at the very beginning, because as I said, security at this point is no longer a technological problem, or a systems problem, or an engineering problem, it is a business problem, and it needs to be addressed in that sense. So we walk down the left hand column, business and mission analysis, stakeholder needs and requirements definition, because those are the people who are going to be making use of this resource when we finally get it finished and implemented. And so we need their requirements, obviously, to build it to their specifications, for their needs. Then we go through further refinement, system refinements and requirements definition, we build from that an architectural design, and then go through the progressive elaboration and increase detail of the design definition, systems analysis. And we first scope out and forecast what the implementation process will be, so that we know how to begin on the steps that we believe that we need to take. And then when we actually make contact with the production environment in which this will eventually go, then we start to go through the integration, the verification and validation. The transition process where we are putting the thing actually into operation, perhaps progressively, perhaps as though we've thrown a switch. Then we go into operation and maintenance, or O and M. Then when we get to end of life, and the replacement for this system is now present and ready to be implemented and operated, we start the decommissioning process, ultimately, to achieve a disposal level in which we will take this system out of operation, cleanse it, purge it from all sensitive attributes and information. And then we'll retire the system through some completion process. 

So the key topics, the key areas we're going to deal with will include these. We have to do requirements definition, obviously, we have to do requirements analysis to make sure that we actually understand what the requirements are, and how they fit together as materialized things, processes, components. From this, we begin an architectural design process where we're beginning to put these things together, picture yourself putting together LEGOS to produce the Millennium Falcon, you have to go through these kinds of things, knowing what sort of LEGOS you need, how many of each particular type or size you're going to require. And then you have to begin the thought of thinking through how you're going to put them together to arrive at the Millennium Falcon. Having conceived all of that, and verify that you do have the right idea, then you begin the implementation. In other words, you start building your model of the Millennium Falcon. You might start with various pieces, you put together the wings, the command module, and so on, then you bring each one of those major pieces together, and you begin to integrate them into what will be the shape of the Millennium Falcon. As you do it, you verify that what you thought was going to work does, or if it doesn't, that you adapt to the situation as it's changed. And then you make it fit properly. As you go through and successfully accomplish these things, you validate that what you've done, is in fact, the right thing. So that in the end, when you transition all of these pieces into their final form, what you've produced is indeed a LEGO version of the Millennium Falcon. 

All along the way you'll be performing these kinds of decisions. You have to analyze what decisions need to be made, how they need to be made. You actually have to decide whether or not you need to make a particular decision, and what the quality of your decision making is going to be. So that ultimately you can produce the thing that you have designed and are directed to produce. It will require technical planning, technical assessment, so that you have quality measures, timing measures, and so on that you've actually met. You'll always have to manage your requirements. Because all along the way, unless it's something that you simply buy or can produce in a matter of minutes or a day, you're going to have to deal with change. You want be sure that as you manage your requirements, that what you're managing, either remains the same, or that you control the rate of change that they're subject to. So that the rate of change at this point doesn't exceed the rate of forward progress. In which case, you'd actually be going backwards. That brings up the subject of risk management. 

As you go through each one of these processes, you need to think about the risks involved in doing or not doing what you're about to consider doing. There are consequences to each one, whether you do something or you don't do something, there needs to be a proper basis for that decision. So you will have to again, analyze each decision under consideration before you make it, to try to forecast what the results will be. And whether or not, it's actually the right thing to do. All along the way, you'll have to do configuration management of all the different pieces. And that means all the pieces that go into your design, plus all the documentation that describes your design. Interface management, both the political kind, where you have to speak to people about things, and the understanding of how that plays into this, as well as managing the technical interfaces to the various program and system components as they go together. And managing the technical data, it seems like a simple thing. But managing the technical data means that everybody is working, each one in their own way, in their own role from the proper, most current version of whatever the design documentation is. Otherwise, people are on different pages, possibly in the same book, possibly in different books entirely. So you have to be sure that you're managing the technical data to assure that everyone, is in fact singing from the same sheet of music. 

Now, the NIST special publication 800-160, describes the systems engineering process in the way that you see here in the diagram. In the context of systems engineering, systems security engineering will be a subset, but it's a major contributor to the systems engineering, because like all other components, the security must be appropriate to the need. It must be integrated with the design, which means it must be appropriate to the purpose as well as the structure and operation of the intended product. And the volumes that go along with the main volume 160, include the 160A, Systems Engineering Considerations for System Resilience, 160B, Considerations for Software Assurance and the Engineering of Trustworthy Secure Systems, and 160C, Considerations for Hardware Assurance. Between these four volumes is a compendium of how you go about looking at system security engineering, its integration, and the way of making it appropriate and properly operational within the entire systems engineering universe. 

Now in all of the cases of all of these frameworks, we'll have technical management processes. Without question, we're going to have to do project planning. We will have to assess the project at various stages and in various ways, as well as the controls that we place on it. We will have to manage our decisions as I've covered. The risk management process in this particular context is about risks to the project, risk that derives from the management processes, actions that we decide to take, actions that we decide not to take, or changes in the actions that we're planning to take or not planning to take. We have to consider each one of those four different types of decisions, because there will be consequences to the design and functionality of the finished product as it materializes. And we have to think this thing through carefully, because rework become increasingly expensive. As we move forward on the project timeline, the more consideration we give, the less rework, one hopes, we'll have to go through, and the more appropriate and proper the results will be. 

Configuration management, the information management, those things have to be done throughout the project cycle, to make sure that things are going together with the appropriate parts, and that we're working from the most proper and current set of information. We're going to have to measure our progress. This is, after all, a business project that we're undertaking, even if we're producing a very technical product or system at the end. So we have to measure our progress, we have to decide what metrics we need, that will illuminate, that our process is proceeding as we forecast. That if things are not proceeding, as we forecast, as we've planned, that we have a measurement that tells us what that is, and why that is, so that we can utilize management processes to correct them. And then we have to have a quality assurance process to ensure that what is being produced is exactly what it's supposed to be to the specifications that it's supposed to meet. There will be a host of enabling processes, lifecycle model management, this is where we're controlling perhaps the prototype that we're working from. We have to manage the infrastructure around the system that supports what we're building. 

We will have to do portfolio management across all the different pieces and the subsystems that may make up the different components of this. We have to do human resources management, we always have to have the proper person working on the proper thing at the proper time. Quality management, of course, and then knowledge management. We want to be sure that in our knowledge management process, we're not only managing, controlling, and capturing the knowledge that we are making use of, but we want to be sure that we capture anything that we learn through this process so that the next time, assuming we have a next time, we will have learned our lessons and we will do a better job and improve the quality of any subsequent product. Now the ISO 21827 of 2008 outlines the system security engineering Capability Maturity Model. This was an adaptation of the original concept of the Capability Maturity Model developed by Carnegie Mellon Software Engineering Institute. And what was attempted here, was to apply that logic and that process, that system of thinking, and behavioral modification, which is what a CMM actually is, to the idea of doing system security engineering to enhance the rigor of systems engineering processes brought to the security world. We want to bring this into project lifecycles, at every stage. We want to spread this into the entire organization. 

Now that's not to say that it's to take over everything up to the CEO's office, but this is a pervasive philosophy, the notion of a Capability Maturity Model, and it does have to have wider application to ensure that the systems security engineering processes, the systems engineering process, and the enabling processes all reflect the same process based logic. This needs to exist with the other disciplines that we have, again, those enabling and supporting processes that make this particular one possible. And it has to govern the interactions we'll have with other organizational elements, because it will drive what the acquisition people do, what the procurement folks do, the overall systems management folks, if we have certification and accreditation people, and then ultimately external auditors and evaluators.