Welcome to Domain One of the CSSLP entitled, Secure Software Concepts. In this module, we will cover foundational knowledge and ideas about what informs the designing and building of secure software. This is not a course in secure programming, but rather it is 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.

We plan to cover topics that will help us understand what underlies secure software, become more familiar with the practice of risk management, be able to supply security concepts throughout the development cycle, understand the various security models and how they apply, become familiar with the legal and regulatory factors and their effects, apply design methods to address issues of performance and resilience, and ultimately, to understand how security and assurance integrate into the acquisition process.

So to cover those objectives, we have our topic agenda. In section one, we're going to cover general security concepts. In section two, we'll discuss risk management and its process. Section three, we'll discuss the security policies and regulations, and we'll conclude with section four, software development methodologies.

So we're going to begin with section one on general security concepts in which we're going to talk about security basics, security models, and adversaries. Section one covers important and foundational concepts that every programmer should know, and that every security professional should understand about secure program development. For software to be secure and resilient against hackers, it must take into account certain foundational concepts of information security. These include confidentiality, integrity, availability, authentication, authorization, accountability, and management of sessions, exceptions, and errors, and configuration parameters.

The CSSLP candidate is expected to be familiar with these foundational concepts and how to apply them while developing software. They must be familiar with the principles of risk management and governance as it applies to software development. Regulatory, privacy, and compliance requirements that impose the need for secure software and the repercussions of non-compliance must also be understood. Trusted computing concepts that can be applied in software that is built-in-house or purchased are covered, and it is imperative that the candidate is also familiar with their applications. So here we have security basics and the much discussed well-known CIA Triad.

Now, as you know, confidentiality, integrity, and availability are the three vitally important qualities that all data must have in order to be considered authentic and trustworthy. In like manner, the systems and applications processing such data must possess the mechanisms and characteristics that will both produce and protect these qualities from exposure, corruption, and loss. For this to be the case, those systems and applications must be designed and built with these notions firmly in mind. That being so, designers, developers, and programmers may well be faced with the challenging task of finding a balance between operational utility and effective security in the end product.

Part of what the CSSLP CBK contains is knowledge about security and centrals, of course, but it goes beyond that by placing these in the context of the development process of a system. By giving security a place in that process, and then describing how to integrate the two, the CSSLP is better equipped to contribute information and guidance on how to achieve that optimal balance. Along with confidentiality, integrity, and availability, as part of our security basics, we have the AAA services, as they're commonly called. Now these are sets of functional requirements that ensure that the processes are performed well and that they are performed securely.

We have first, authentication, and these are integrated methods that are intended to validate the entities, making a claim of identity before being admitted to a system with some rights of access. Followed by authorization. And this is establishing and assigning access and capability in close alignment to the role needs as has been defined by the vetting process that puts the entity into the system in question. The third A is accountability, and this is made up of two activities performed in parallel. As the entity, the subject, is doing actions in a system, there is an accounting of all the activities produced as evidence of what that subject is doing. Then by following an auditing process, the accounting record is then verified to determine correct and compliant access and behaviors on the part of the subjects interacting with the objects that they believe to be a part of their access profile. The next day is authentication.

Now this first step is to confirm that the subject requesting access to this information asset is indeed confirmed regarding who it claims to be. And until this authentication process is successfully accomplished, it is nothing but a claim. To do this, we use the common authenticators that we all know. Type one authenticators, the something that you know; a password or other characteristic that you typically make up and remember, or that may be generated at random by a system for you. Then we have the type two authenticator: the something that you have, typically a token, either a hard, such as a mechanism, like a secure ID from RSA; or a soft token, like a challenge response code sent to your telephone. Then we have the type three token, or the something that you are or do, otherwise known as the biometric. There is also an other type of authenticator, which is a logical indicator of somewhere that you are, or the address.

Now proceeding this is establishing a registration process separate from the provisioning process with various ways of verifying claimed identity. And it is a necessary thing though outside of software development, that the process of considering the role, the individual, and the resources needed for its profile should be handled as a separate process from the act of going into a system and configuring that profile. The second critical step is authorization.

Once the subject has made a claim of identity and it goes through the process of authentication, then we have to connect that verified identity and its identity with the information, assets, and capabilities that correspond to those most appropriate and needed by the role associated with that subject. These would include attributes such as role definition, capabilities required, level of access needed. And of course, we need to follow the principle of least privilege.

Now instantiating the access requested should, as I described in the previous slide, be an independent endorsement by authority for greater assurance of the validity of the identity of that subject and as to for provisioning the access requested to be a separate process from the actual defining of what that access profile should be. In essence, we want to be sure that no party can authorize themselves. The third critical step is to establish accountability. Now, this step is made up of a couple of tasks.

First it is to record and then to review the verified entity's activities to ensure oversight of all the interactions with the information assets that have been granted as access by that to that subject. The activities are, first, accounting; and this is to produce record of all subject-object interactions and events. The reviewing of this accounting record is auditing, and the act is to apply a policy to ensure that we know that what that subject-object interaction has been corresponds to what is compliant and what is required. Thus, the accountability establishes a subject's behavior when accessing a system, its data, and the resources in order to determine the appropriateness and compliance.

Now, this is a process form of protection against repudiation. The process also examines the record for anomalous or unexplained events and for any form of problem discovery and resolution processes of an operational nature. Now, beyond these, we have other foundational elements. We have session management, and this gets more into the area of how we actually design and build an application or system. These are code elements that control how program components connect to each other and how these modules would pass information between them. It also ensures that this flow is protected from disruption or unauthorized access. And the modalities of that protection will be discussed later in this course.

We have to deal with exceptions and how to handle them. Exception management is to address the errors and other non-ordinary conditions. We first have to have a mechanism for detection and the handling to enable the resolution. We have to ensure that where possible, we institute provisioning so that we can prevent the failing of an into a non-secure state. And we have to ensure that no data leakage occurs in any of the resultant condition opportunities.

An area that is constantly cited as one of the more fault written ones and one that seems to be more in our control than any others is configuration management. The processes imposed to ensure that a system evolution follows the approved and prescribed pathway defined in the product or system roadmap. The operational activities to ensure that all system changes, parameters, and settings are changed only through management controls to ensure that all persist in authorized states. It also enforces separation of duties and roles to eliminate conflicts of interest and to reduce risks overall.

Lectures

Design Principles - Security Models - Security Models: Access Controls - Security Models: State & Mode - Threat/Adversary Analysis