Welcome to Domain Two of the CSSLP, the Certified Secure Software Lifecycle Professional examination review seminar. This particular domain covers secure software requirements. And in this module, we will cover foundational knowledge and ideas about what informs the designing and building of secure software. This domain covers the chapters five, six, and seven in the course text.

First, let's set the stage a little bit and orient how we're going to approach and think about this chapter's information. It is important to establish the fact that without software requirements, software will fail and without secure software requirements, it will be attacked successfully by hostile parties. Without properly understood and well-documented and tracked software requirements, one cannot expect the software to function without failure, or even to meet expectations. It is therefore vital to define and explicitly articulate the requirements of software that is to be built, and those kinds of software that will be acquired.

Software development projects that lack software requirements suffer from a myriad of issues. These issues include, but are not limited to, poor product quality, extensive timelines, and the ofttimes extensive timeline overruns, scope creep, increased cost to redesign and include the missed aspects and fix errors, and customer and end user dissatisfaction with the final product when it is delivered.

Software development projects that lack security requirements additionally suffer from the threats to confidentiality, integrity and availability, which include unauthorized disclosure, alteration, and destruction. It is really not a question of if, but when, as we know all too well, because it is only a matter of time before software built without security considerations will get hacked, provided the software is of any value whatever to the attacker.

It would, of course, be extremely difficult to find a building architect who would engage in building any sort of a building without a blueprint or a chef who will bake world famous pastries and cakes without a recipe that lists out the ingredients. However, we often observe that when software is built, security requirements are not explicitly stated.

Security is first and foremost viewed by the party wanting to design and build the software and the parties wanting to use it as a nonfunctional set of requirements in the software, and that the organization already has to deal with functional requirements within the constraints posed by budget, scope and security requirements are usually considered to be an additional complication and even more so, expense. Such an attitude is what leaves secure software requirements on the sidelines, if they're collected at all.

Secondly, incorporating security in software is often misconstrued as being an impediment to business agility, instead of being the enabler that it is to produce improved quality and more secure performance. The importance of incorporating security requirements, therefore, into the software requirements gathering and design phases is absolutely critical for the reliability, resilience, and recoverability of the software intended. It is therefore extremely important to explicitly articulate security requirements for the software in the software requirements specifications documents.

Now in this particular domain, we need to understand what our objectives are going to be. And as you see here on the slide, it's going to be a case of understanding how policies should be deconstructed and then transformed into requirements. We need to examine the specific attributes of the CIA triad that drive policy, and that must be re-expressed as drivers of non-functional requirements. Then we need to look at the examination of the specific attributes of the so-called Triple A Services that drive policy and themselves must be re-expressed as drivers of functional requirements. And of course, we're going to delve into the relationship between security and audit and how these translate into requirements also.

Now, as we've said before, this is not a course in secure programming. There are as many ways to compose software as there are languages in which to write it and developers who choose to build in them. This is intended as a course that programmers should use to help them build more secure, more resilient, and more resistant software while achieving the necessary balance between security and functionality. Taken in this vein, the concepts presented here are applicable, no matter what language environment is in use or what system is being built.

There can be little doubt that software, being the primary point of impact for the various attacks, flaws and other disruptions that it is subject to would greatly benefit from better, more secure methods of conceiving, designing and constructing it. Those benefits would begin with better reliability, better resilience, and improved performance. In this module, we're going to explore the origins of those benefits, which will be found in the requirements it will satisfy when it performs its work.