> For the complete documentation index, see [llms.txt](https://mainekhacker-1.gitbook.io/mainekhacker/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mainekhacker-1.gitbook.io/mainekhacker/security-principles-notes.md). # Security Principles Notes: ## Security Principles Security Principles Learn about the security triad and common security models and principles. Security has become a buzzword; every company wants to claim its product or service is secure. ### CIA
#### Parkerian Hexad In 1998, Donn Parker proposed the Parkerian Hexad, a set of six security elements. They are: {% stepper %} {% step %} ### Availability Availability aims to ensure that the system or service is available when needed. {% endstep %} {% step %} ### Utility Utility focuses on the usefulness of the information. For instance, a user might have lost the decryption key to access a laptop with encrypted storage. Although the user still has the laptop with its disk(s) intact, they cannot access them. In other words, although still available, the information is in a form that is not useful, i.e., of no utility. {% endstep %} {% step %} ### Integrity Integrity aims to ensure that the data cannot be altered; moreover, we can detect any alteration if it occurs. {% endstep %} {% step %} ### Authenticity Authentic means not fraudulent or counterfeit. Authenticity is about ensuring that the document/file/data is from the claimed source. {% endstep %} {% step %} ### Confidentiality Confidentiality ensures that only the intended persons or recipients can access the data. {% endstep %} {% step %} ### Possession This security element requires that we protect the information from unauthorized taking, copying, or controlling. For instance, an adversary might take a backup drive, meaning we lose possession of the information as long as they have the drive. Alternatively, the adversary might succeed in encrypting our data using ransomware; this also leads to the loss of possession of the data. {% endstep %} {% endstepper %} * **Nonrepudiation**: Repudiate means refusing to recognize the validity of something. Nonrepudiation ensures that the original source cannot deny that they are the source of a particular document/file/data. This characteristic is indispensable for various domains, such as shopping, patient diagnosis, and banking. #### DAD * **Disclosure** is the opposite of confidentiality. In other words, disclosure of confidential data would be an attack on confidentiality. * **Alteration** is the opposite of integrity. For example, the integrity of a cheque is indispensable. * **Destruction/Denial** is the opposite of availability. ## Fundamental Concepts of Security Models We have learned that the security triad is represented by Confidentiality, Integrity, and Availability (CIA). How can we create a system that ensures one or more security functions? The answer would be in using security models. We will introduce three foundational security models. #### Bell-LaPadula Model The Bell-LaPadula Model aims to achieve **confidentiality.** * Simple Security Property * Star Security Property * Discretionary-Security Property #### Biba Model The Biba Model aims to achieve **integrity** by specifying two main rules: * Simple Integrity Property * Star Integrity Property #### Clark-Wilson Model The Clark-Wilson Model also aims to achieve integrity. * **Constrained Data Item (CDI)**: Data type requiring integrity preservation * **Unconstrained Data Item (UDI)**: All other data types, including input * **Transformation Procedures (TPs)**: Operations that maintain CDI integrity * **Integrity Verification Procedures (IVPs)**: Procedures that validate CDIs ## Defence-in-Depth **Defence-in-Depth** refers to creating a security system of multiple levels; hence it is also called Multi-Level Security. ## ISO/IEC 19249 The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) have created the ISO/IEC 19249. Below is a brief overview of ISO/IEC 19249:2017 Information technology - Security techniques - Catalogue of architectural and design principles for secure products, systems and applications. The purpose is to have a better idea of what international organizations would teach regarding security principles. * **Domain Separation**: Every set of related components is grouped as a single entity; components can be applications, data, or other resources. Each entity will have its own domain and be assigned a common set of security attributes. * **Layering**: When a system is structured into many abstract levels or layers. * **Encapsulation**: In object-oriented programming (OOP), we hide low-level implementations and prevent direct manipulation of the data in an object by providing specific methods for that purpose. For example, if you have a clock object, you would provide a method `increment()` instead of giving the user direct access to the `seconds` variable. * **Redundancy**: This principle ensures availability and integrity. There are many examples related to redundancy. Consider the case of a hardware server with two built-in power supplies: if one power supply fails, the system continues to function. * **Virtualization**: Cloud services enable sharing hardware among multiple operating systems, providing sandboxing capabilities for enhanced security boundaries and malware analysis. ISO/IEC 19249 teaches five design principles: * **Least Privilege**: Also phrased as “need-to basis” or “need-to-know basis.” Provide the least amount of permissions required to carry out a task and nothing more. * **Attack Surface Minimisation**: Every system has vulnerabilities that an attacker might use to compromise a system. These vulnerabilities represent risks that we should aim to minimize. * **Centralized Parameter Validation**: Many threats are due to the system receiving input, especially from users. Invalid inputs can be used to exploit vulnerabilities in the system, such as denial of service and remote code execution. * **Centralized General Security Services**: Centralize security services (for example, authentication) while taking measures to ensure availability and avoid single points of failure. * **Preparing for Error and Exception Handling**: When building a system, account for errors and exceptions (for example, handling attempts to place orders for out-of-stock items). ## Zero Trust versus Trust but Verify **Trust but Verify**: This principle teaches that we should always verify even when we trust an entity and its behaviour. An entity might be a user or a system. Verifying usually requires setting up proper logging mechanisms; verifying indicates going through the logs to ensure everything is normal. **Zero Trust**: This principle treats trust as a vulnerability, and consequently, it caters to insider-related threats. After considering trust as a vulnerability, zero trust tries to eliminate it. ## Action items * Introduction * CIA * DAD * Fundamental Concepts of Security Models * Defence-in-Depth * SO/IEC 19249 * Zero Trust versus Trust but Verify * Threat versus Risk * Conclusion --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://mainekhacker-1.gitbook.io/mainekhacker/security-principles-notes.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.