CompTIA SecurityX

Security model

These models only work if the users are vetted.

The Bell La Padula model

Known for Confidentiality Access to read down but not read up and no write-down NOT designed to handle file sharing

The Biba Model

Access to read up but not read down and no write-up Known for Integrity NOT handle internal threats

Clark-Wilson Model

Known for Integrity

Constrained Data Item (CDI) Data type whose integrity we want to preserve. Unconstrained Data Item Data types beyond CDI, such as user and system input Transformation Procedures Programmed operations, such as read, write, and should maintain the integrity of CDI's Integrity Verification Procedures Check and ensure the validity of CDI's

---

Threat modeling

• Preparation
• Identification
• Mitigation
• Review

Threat Intelligence Asset identification Mitigation capabilities Risk Assessment

S.T.R.I.D.E

• Spoofing

  • Principle requires you to authenticate requests users accessing a system. Spoofing involves a malicious party falsely identifying itself as another. EXAMPLES:
  • Access Keys (API ) or signature via encryption helps remediate it.

• Tampering

  • Providing anti-tampering measures to a system or application, provide integrity to the data. Data that is accessed must be kept integral and accurate EXAMPLE
  • Shops use seals on food products
  • anti-tamper stickers on hardware

• Repudiation

  • Principle dictates the use of services as logging of activity for a system or application to track

• Information disclosure

  • Applications or services that handle information of multiple users need to be appropriately configured to only show information relevant to the owner.

• Denial of service

  • Applications and services use up system resources, these two things should have measures in place so that abuse of the application/service won't result in bringing the whole system down.

• Elevation of privilege

  • Worse case scenario for an application or service. User was able to escalate their authorization to that of a higher level. i.e. an administrator. Often leads to further exploitation or information disclosure.

---

• Incident (breach of security)

• Incident response (actions taken to resolve or remediate the threat) Incidents are classified

• High , medium , low (according the urgency)

Incident is responded to by CSIRT (Computer security incident response team)

• Pre-arranged group of employees with technical knowledge about systems and or/ current incident. To successfully resolve an incident steps are taken in phases (6 of them)

• Preparation Do we have resources in place to deal with security incident?

• Identification Has the threat and threat actor been correctly identified in order for us to respond to?

• Containment Can the threat/security incident be contained to prevent other systems or users from being impacted

• Eradication Remove the active threat

• Recovery Perform a full review of the impacted systems to return to business as usual operations

• Lessons Learned What can be learned from the incident? I.e. if due to phishing email , employee should be trained better to detect phishing.

---

Defense in Depth

Basically a way to add multiple layers of security to an object

---

ISO/IEC 19249 (International organization of standards and International electro technical commission) Information technology - security techniques - catalog of architectural and design principles for secure products,systems and applications

Five architectural principles

1. Domain Separation Components are grouped as a single entity, meaning every application, data or resource will have its own security attributes

2. Layering System is structured in many abstract levels or layers, like API abstractions - this is related to Defense in Depth*

3. Encapsulation Hide lower level access and use a high level API

4. Redundancy Ensures availability and integrity , High availability power supply , has two power supplies in case one goes down

5. Virtualization Using virtual machines instead of physical devices ensures easy back up and image backups. This also ensures better security through sand boxing applications and Operating systems.

five design principles

1. Least Privilege Need to know policies, provide the least amount of privileges to a system or entity

2. Attack Surface monitoring Hardening an application or OS, or turning off un-needed services

3. Centralized Parameter Validation User input , parameter validation put into a central library or system

4. Centralized General Security Services Centralize or security services

5. Preparing for Error and Exception Handling Designing systems to fail safe , meaning if a database gets overloaded, the service should not leak exceptions , error messages

---

Trust principles

Trust but verify Always verify when we trust an entity and its behavior

Zero trust Treat trust as a vulnerability, never trust always verify, every entity is un-trusted until verified trusted.