Secure system design principles and the CISSP
This article is part of our CISSP certification prep series. For more CISSP-related resources, see our CISSP certification hub.
Developing an infrastructure that’s considerably secure is not an easy task with the ever-increasing sophistication of hackers. If you are to consider yourself an information security expert, however, you need to be aware of the tenets of a secure system; this is why security engineering is an important constituent of the CISSP CBK. Adequate R&D, experience, and skills are required to set up an architecture that upholds the principles of secure system design. In this article, the various system design principles that need to be known by a CISSP aspirant will be explored, along with the procedures and the standards that can be used for setting up secure infrastructures.
The field of security engineering is very broad and there are many principles that need to be adhered to in order to achieve rigorously secured systems; here are a few of them that should be kept in mind by CISSP exam takers:
1. The least privilege principle
According to the least privilege principle, any entity should be given the least possible set of privileges to perform an action. It can be said that:
- Identity doesn’t determine the control; rather the function does.
- Rights are added only when there is a need and are discarded right after use.
2. Fail-safe defaults
Unless access to an object has been explicitly given to a subject, it should be denied access to it.
- Access decisions are not made on exclusions; rather, they are made on permissions.
- The default action is to always deny (not grant) access.
- Even if the action fails, the system will still be as secure as it was when the action began.
3. Mechanism economy
All the mechanisms pertaining to the impartment of security should be kept as simple as possible. Complex mechanisms can be incorrectly: a) understood; b) configured; c) implemented; or d) modeled.
- Simpler models entail that “less can go wrong.”
- In case of an error, it is always easier to spot and remedy.
- Keep the operation, implementation, design, and the interaction with other constituents as simple as is possible. This makes the processes of analyzing, testing, and verifying simpler.
4. Full mediation
Access to all objects need to be checked to ensure that they are allowed.
- The performance vs. security issue often creates problems for system administrators. For instance, the access check results are often cached to increase performance, but what if the permissions have been changed since the last access request? In most systems, cache flushing mechanisms are absent.
- Access granting and management needs to be rigorous at all times.
- Access needs to be checked every single time without any exception.
5. The openness of the design
It’s a cliché in the field of secure system design that a mechanism’s security must never depend on its design (or implementation) being kept secret.
6. Separation of privilege
A system should never grant any permissions based on just one condition.
- This removes the existence of a single point of failure.
- Multiple conditions should be met before the granting of privileges. An example is two-factor authentication, in which both token recognition and biometric systems are used for authentication purposes.
This is a very interesting, yet less-understood principle. It dictates that, once security mechanisms get implemented, the resource should not get more difficult to access than it would have been if the mechanism were not present. Often people compromise on efficiency because of enhanced security, which is in direct violation of secure system design fundamentals.
Choosing the right security framework
A security framework is a series of standardized processes that can be used to define the procedures and policies around which the implementation of a system can be carried out. There are many security implementation frameworks that can help system architects and engineers in setting up infrastructures with sound security.
The frameworks can be looked upon as blueprints for building information security programs that can be implemented to reduce vulnerabilities and mitigate threats/risks. For an information security expert, the utilization of these frameworks should not be more difficult than a stroll in a park. Similar to the customization of building blueprints to achieve desired specifications, frameworks can also be customized to solve intriguing security problems. Different frameworks have different levels of complexity and scalability and choosing the right one depends on your needs and the expectations of the system. Following are some of the most famous security frameworks:
Control objectives for information and related technology or COBIT is a framework that was developed by ISACA (an organization comprising IT governance officials) around 1995. Initially, the framework was used only to reduce the presence of technical risks within organizations but, over the years, it has metamorphosed into COBIT 5, which provides the ability to align IT with the business goals of a firm. Most organizations these days use this framework to comply with the Sarbanes-Oxley Act.
NIST SP 800 series
NIST, or The National Institute of Standards and Technology of the United States, has been working to build extensive collections of security standards and recommended practices documentation. The NIST SP 800 series was published in 1990 for the first time and, since then, it has evolved into something that can be referred to as the bible of information security.
Many of the country’s governmental agencies use the NIST SP 800 to comply with the 200 requirements of the Federal Information Processing Standards (aka FIPS). Despite the overuse in the government sector, the NIST SP 800 should not be overlooked by private sector organizations that are looking to build rigorous information security systems.
ISO 27000 series
The ISO 27000 series was conceived by ISO (International Standards Organization). It is a gigantic information security framework that is applicable to organizations, regardless of their types and sizes. It can be considered the information security equivalent of the ISO 9000 manufacturing quality standards.
Depending on the content, it is divided into various sub-standards. For instance, the ISO 27001 highlights the program requirements, whereas the ISO 27000 comprises a vocabulary and an overview. The ISO 27002 lays out the procedural steps that need to be followed while building an information security system.
Sherwood Applied Business Security Architecture (SABSA) is a methodology and framework that can be used to develop security architectures and service management platforms at the enterprise level. It resembles the Zachman Framework in structure but was developed independently of it.
SABSA can be used to develop risk-driven security architectures that are supportive of critical business processes and initiatives. The rudimentary tenet of the model is that the derivation of everything must be made from the analysis of the enterprise requirements for security.
There are other frameworks, such as ITIL and TNS, that are also worth exploring in this regard. The choice of the framework needs to be made after adequate brainstorming to ensure that the subsequent customization of the blueprint leads to an apt security design. More information on the customization and importance of a blueprint can be found here.
No adjective trumps “Secure” in importance when we refer to modern-day information systems. If the proper framework and protocols are followed while keeping in mind the design principles at all times, an architect and/or an engineer can go a long way toward ensuring that their system is adequately devoid of risks and vulnerabilities.