Access control - Basic SE and ISSE Principles

Exam: ISC CISSP - Certified Information Systems Security Professional

Access Control

Concepts/methodologies/techniques

Basic SE and ISSE Principles
When using the SE approaches, it is important to not only build the system right, but also to build the right system. The distinction is important to understand; most ISSEPs can remember projects where the organization spent time and money to design and develop a system that worked correctly. However, the system did not solve the problem and therefore the organization did not build the right system.

SE must be used for the total development effort necessary to establish a system (or component) design that can be tested, manufactured, supported, operated, distributed, and disposed of. It also includes the training for operation, support, distribution, and disposal. The process of engineering a system to satisfy the combination of either organizational or customer expectations, enterprise policies, legal constraints, and social or political restrictions requires a structured methodology. This method should allow for exploring options in system alternatives that will ensure that the design is cost-effective and practical.

Principle 1: Always keep the problem and the solution spaces separate.
The problem is defined as what the system is supposed to do. The solution is defined as how the system will do what it is supposed to do. If we begin by looking at the solution, we may lose sight of the problem, which can result in solving the wrong problem and thus building the wrong system. For example, if the client wants high-speed encryption, the client is defining the solution, which may not be the right solution for the problem. Common sense tells us that nothing is more inefficient than solving the wrong problem and building the wrong system.

Principle 2: The problem space is defined by the customer's mission or business needs.
The problem space is defined in terms of the customer's mission or business needs in combination with and taking into consideration the constraints of the organization, such as legal or regulatory restrictions. The customer usually has a method and capability of doing business or accomplishing the mission. The focus of the ISSEP is to work with the customer to understand the underlying business needs and, based on those needs, the ISSEP determines the best solutions. Typically, customers will recognize the need to change their methods or capabilities needed to accomplish their missions. The customer then talks to system engineers in terms of technology and their notion of solutions to their problems, rather than in terms of the problem. Those individuals tasked with helping the customer, such as systems engineers and information systems security engineers, must set these solutions aside and discover the customer's underlying problem.

Defining the problem space in terms of needs is not only important, it is critical; there are years of failed projects within the USG (and private industry) because the system requirements and problems were not correctly defined. Look at your own experiences; you can probably think of projects you were involved with or completed that did not solve the customers' requirements because the needs were not defined adequately in the beginning.

Understanding needs is important because it can provide a direction for the solution, an objective criterion to measure progress, and a method of determining whether the solution is good enough. Knowing what you want the system to do can provide a direction to your search for the solution. It can also help create boundaries for the scope of the problem.

Principle 3: The systems engineer and information systems security engineer define the solution space driven by the problem space.
The solution space is where the systems engineer addresses how to meet the needs within the confines of the constraints and the organization's mission. Thus, it is critical to have a complete picture of the problem space in order to formulate a good, thorough solution that will meet all the requirements.

Another aspect of this principle is that the customer must recognize the important role of the systems engineer. This principle can be stated another way, as "the solution is defined by the systems engineer and the problem is defined by the customer." The customer is the expert on the problem and the engineer is the expert on the solution. Thus, the systems engineer must be seen as the expert that is there to help the customer achieve a reasonable solution. If a customer insists on intervening in the design of the solution, the customer may actually place unnecessary constraints on the solution and limit the flexibility or capability of the systems engineer to develop a system that meets the user's requirements.

This is not to say that the customer is not kept informed of the process and is not involved in the process. Simply put, systems engineers are there to support and provide expertise on the design of the solution, and in this role they must be leaders of the process.

At the same time, systems engineers must recognize that their task is to meet the customer's needs, not the engineer's. It is the systems engineer's responsibility to get clearly defined needs or requirements from the customer. The customer is the expert on the customer's mission and business needs, not the systems engineer. Thus, the systems engineer must have the skills to discover and capture the mission needs as defined by the customer. In some cases, the engineer will need to help the customer discover and define the mission needs and the system requirements.