We come to our final section, section seven, in which we're going to assess the software acquisition security and our supply chain process. So we're going to look at the introduction, the assurance phases, the development of a policy and the acquisition process.

Now, software assurance is the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle, and that it functions in the intended manner. Software assurance is not trying to guarantee perfection. It is trying to guarantee that all of these different attributes of the software are known to the users, to the buyers, and so nothing should come as a surprise. Now, the software assurance process includes these four basic steps: planning, contracting for software that we're going to have built for us, the monitoring and acceptance process, and the follow-on that occurs after the software is implemented and operating.

Now, in our planning phase, what we need to do in-house is we need to sit down and decide, literally, what do we need? What do we need it to do? What should it look like? How should it perform? And so we go through our requirements collection, sifting, sorting, and finalizing process. We have to create an acquisition strategy. How are we going to buy this? What do we want it built as? What do we want our terms and conditions of support to be? And then we have to develop the criteria by which we're going to measure the software's quality. And develop the plan through which that criteria will be employed so that we can evaluate a competitor's product against another product so that we know we're getting exactly what we have paid for.

So in the contracting phase, and many of you may have been part of this, we're going to create or issue a solicitation or a request for a proposal. Based on how many we get, we'll evaluate the supplier proposals, see which one aligns with what our needs are as we know them and then, after having vetted the various offerers of these products, we'll make a selection and then we will finalize our contract negotiation process and sign someone up to do the task.

Now, in the monitoring and acceptance phase, the organization that has been selected to do it will establish their process, they will design and build, and at various points, they will confer with us and we will review and we will agree to proceed. The contract work will follow a schedule of deliveries. There will be a change control process. And, in each case, there will be a process to review and accept software deliverables, either as a final, finished product or in a modular form. More often today, it's in more of a modular form.

A secondary matter, of equal importance however, is the sustaining engineering. How will the software be maintained? What is its expected life span? How will this process be done? And, of course, many of the same subjects. What will be the change control process? Will it be supported in-house or will it be supported by the builder? Or will it be done by another party? And then at the end, there will come the question of how will it be disposed or decommissioned at the end of its life? And that, of course, begs the question, what will replace it? And how will our decommissioning process go if questions of compliance and sanitizing have to be answered?

So to begin this process, we first must develop a software acquisition policy. It needs to be well-documented and it needs to be sure to cover the various topics that we've addressed: security, development, compliance, and a host of others. And this must be the policy that guides how we will do this to make sure that we get what we paid for and that it works as well as expected. Through the process of software acquisition, we have to be sure that our quality assurance process, both proactively for what we will build into the contract arrangements, and for the analysis process that we will do as each module or as the final product is being delivered.

There must be a process for assessing and coping with the risks that occur during the software build and delivery process. Our contracting language needs to deal with the unintentional errors, potential insertion of malicious code, theft of vital information or even intellectual property, theft of personal information, controlled or unauthorized change of the product, any form of inserted agents or any form of corrupted information. Now the contract language and the processes that we build and implement and perform driven by that language need to be sure that our review and change processes account for testing and evaluation of each of these and a host of other related items to ensure that these unwanted attributes are not embedded in the program so that we can trust that it will perform as securely with all the integrity that we've bought and paid for.

Now, the acquisition process itself needs to look at the system and software assurance so that we focus on the management of risk, the assurance of safety and security, dependability and a host of other related attributes including compliance within the context of the system and the software life cycles. These are some examples of useful questions that should be asked of potential suppliers through the vetting process and through the design, build and delivery: How does the supplier ensure that an infrastructure for safety and security is established and maintained? How does the supplier ensure that safety and security risks are identified and managed? How does the supplier ensure safety and security requirements are satisfied? How does the supplier ensure that activities and products are managed to achieve safety and security requirements and objectives? And what escrow provisions are contained within the contract arrangements?

Now, these may seem like very obvious questions to ask, but all too often, they're not. These are very much integrated with the entire idea of supply chain management and security and they give you, the buyer, the sense of how mature and how well-developed the process is that your potential supplier has in place and how much they consider the level of security that you need to be part of what they're going to produce.

So in this particular domain, we've gone through the software development life cycle and how to apply security to it. We've looked at general subject areas where security controls have been outlined and how we discuss them in their appropriateness for the development environment. And then we've concluded with a discussion on how to assess the effectiveness of software and development security. And with this slide, we conclude Domain 9, Software Development Security, and this concludes the presentation of the Cloud Academy course in the CISSP exam preparation review seminar. We thank you very much for being part of this. We look forward to your success in passing the CISSP exam and we encourage you to do all the work necessary to be successful in that. Thank you.