D315 Network and Security - Foundations: Section 3 Network Security Operations

Zero-trust model

-a security model where no user or device is trusted automatically, even if they are inside the network; everything must be continuously verified

-Purpose: prevent unauthorized access, reduce internal and external threats, and stop lateral movement inside a network

Economy of mechanism (simplicity)

-security designs should be SIMPLE, not overly complex; simple systems are easier to understand, test, and secure

-Purpose: reduce errors, make it easier to audit and maintain, and lower the attack surface

Fail-safe defaults (fail secure)

-systems should deny access by default and only grant access when explicitly allowed

-if a system fails, it should fail in a secure way, not an open way

-Purpose: prevent unauthorized access

Least common mechanism

-systems should avoid sharing mechanisms or resources whenever possible; shared resources create more attack vectors and risks

-Purpose: reduce the risk of one user affecting another, limit attack spread, and improve separation between users

Principle of least privilege

-users and systems should have only the minimum permissions required to do their job, nothing extra

-Purpose: reduce damage if an account is compromised, limit mistakes, and prevent misuse of privileges

Separation of duties

-critical tasks should be divided between multiple people or systems, so no single person has full control

-Purpose: prevent abuse of power, prevent fraud, and reduce insider threats

Defense in depth

-multiple layers of security are used so that if one layer fails, others still protect the system

-Purpose: provide redundancy, slow down attackers, and protect against different attack types

Complete mediation

-every access request must be checked every time, not cached or assumed

-Purpose: prevent privilege escalation and ensure changes to permissions take effect immediately

Open design

-security should not depend on keeping the design secret; only keys and passwords should be secret, not the system architecture

-Purpose: allow public review, reduce hidden flaws, and improve trustworthiness

Least astonishment (psychological acceptability)

-security mechanisms should be easy for users to understand and follow

-Purpose: reduce user mistakes, improve compliance, and make security natural and intuitive

Data Handling Policy (Most Critical)

-focus on how data is classified, protected, used, and disposed of

-Defines who can access data and whether it's public or restricted

Identifies legal and regulatory requirements

-Uses data classification levels like: public, confidential, private, and secret/top secret

-Define roles like: owner (accountable for data), custodian (technical protection), steward (business handling)

-Secure archives, cloud storage, and physical storage

-Secure disposal of data when no longer needed

-Stay aware of new data-related risks

Data Handling Policy Core Principles

-Data minimization: collect only what's necessary

-Least privilege: give the minimum access required

-Protection methods:

1. Data in transit → TLS, IPSec, SSH

2. Data at rest → AES-256

3. Data in use → protect memory (RAM, Redis, etc.)

Password Policy

-focus on securing access when passwords are used

-Balances strong security with user usability

-Addresses the risk of users writing passwords down

Password Policy Common Requirement

-Minimum length (often 10-15 characters, not just 8)

-Password complexity like uppercase, lowercase, numbers, and special characters

-Avoid predictable substitutions like using @ for a

-Password expiration (30-60 days)

-Password history (prevents reuse)

-Users allowed to change their own passwords

Acceptable Use Policy (AUP)

-focus on how users are allowed to use systems and networks

-Agreement between the organization and users

-Defines allowed and prohibited behavior

-Often accepted via: login banners, captive portals, and checkboxes before access

-Protects the organization from misuse and legal risk

Common AUP Elements

-Data access and disclosure

-Data retention

-Asset management (laptops, phones, asset tags)

-Password usage

-System access rules

-Clean desk policy

-Removable media rules (USB drives, phones)

-Internet/web usage

-AR apps like Pokemon Go

-BYOD policy

BYOD (Bring Your Own Device) policy

focus on personal devices accessing company resources

BYOD Common Approaches

1. Unlimited access (rare, high risk)

2. Access only to non-sensitive data

3. IT-controlled access using enterprise mobility management

4. Controlled access without local data storage using partitioning or MDM tools

Privacy Policy

-focus on protecting sensitive information

-protects:

1. Intellectual Property (IP)

-Trade secrets

-Copyrights

-Research

-Future products

2. PII (Personally Identifiable Information)

-IDs, addresses, personal data

3. PHI (Personal Health Information)

Configuration Management

-keeping systems consistent, secure, and predictable

-Ensures systems, servers, and applications remain in a desired and known state

-Compares current system settings to a baseline

-A mature configuration management program makes it harder for attackers and auditors to find vulnerabilities

-Baseline creation is a core part of configuration management

Baselines, Drift, and Assessments

-focus on detecting unwanted or risky changes

-Baseline: the approved, known-good configuration

-Configuration assessments: check if systems match the baseline

-Drift analysis: identifies changes over time that move systems away from the baseline

-Used to determine what systems need:

1. Updates

2. reconfiguration

3. patching

Configuration Items (CIs)

-focus on what is being managed and tracked

-A CI is any item under configuration control

-Examples:

1. Servers (SharePoint, SQL)

2. Wireless access points

3. Applications

4. Virtual machines

5. Containers

6. Logical constructs (like portfolios)

-CIs are the core building blocks of configuration management

Configuration Management Database (CMDB)

-focus on central source of truth for IT configurations

-CMDB is a purpose-built, centralized database

-Stores information about all CIs and their relationships

-Acts as a data warehouse for the IT environment

-Supports many IT processes:

1. Change management

2. Release management

3. Incident management

4. Service requests

5. Problem management

6. Configuration management

CI Discovery and Data Collection

-focus on keeping the CMDB accurate

-Data import tools automatically discover CIs

-These tools populate and update the CMDB

-Reduces human error and keeps data current

CMDB vs CMS (Configuration Management System)

-focus on broader systems that may include a CMDB

-A CMDB may be part of a larger CMS

-CMS can also function as:

1. Inventory engines

2. Asset management systems

-Example: used in Zero Trust architectures (like Google)

CI Data structure (key-value concept)

-focus on how CI data is organized

-CIs are typically stored as key-value pairs

-Example:

1. Key: Server (CI)

2. Values:

-Location

-Lifecycle status

-Vendor

-SLA

-Physical vs virtual

3. CIs can link to IT asset records:

-Procurement

-Financial data

-Contracts

-vendors

Change Management

-focus on making changes safely, successfully, and with accountability

-Works closely with configuration management

-Goal: maximize successful changes while minimizing risk

-Provides: visibility, auditing, and accountability

-Ensures change risk is assessed, authorized, and tracked

-Uses tools such as: change log, change register, change ledger, and CMDB

"Controlled, documented, and approved changes"

Standard Changes

-low-risk, routine changes

-Key points: pre-authorized, low-risk, common and repeatable, often automated, follow standard operating procedures (SOPs), and rarely reviewed individually by the CAB

-Examples: password changes based on policy, routine system updates

Normal Changes

-medium-risk, planned changes

-Key points: not pre-approved, not urgent, require review and approval, must go through the Change Advisory Board (CAB), more flexible than emergency changes, default category if not standard or emergency

-Examples: provisioning a new laptop or mobile device, planned system upgrades

Emergency Changes

-urgent, high-priority changes

-Key points: must be implemented AS SOON AS POSSIBLE, triggered by things like security incidents, disaster recovery, and incident response, CAB involvement may be expedited or bypassed to reduce delay

-Examples: patching a zero-day vulnerability, mitigating a large-scale DDoS attack

-Prioritize speed over process, but still require documentation afterward

Role of the Change Advisory Board (CAB)

-risk review and approval

-Key points: reviews normal changes, sets protocols for Standard changes, helps assess risk and impact, may be bypassed or streamlined during Emergency changes

Change Management Lifecycle

-how a change moves from idea to completion (understand the flow)

-Key characteristics: iterative (can move backward), not always linear, not all steps are required for every change

Change Management Phase 1: Submitting

-Change is proposed

-Risk and impact are analyzed

-May require more information or escalation

Change Management Phase 2: Approving

-Reviewed by: CAB, steering committee, C-suite/leadership

-Decision made to approve, reject, or modify

Change Management Phase 3: Documenting

-Change is recorded in: Change log, CMDB

-Documentation updated as the change progresses

Change Management Phase 4: Testing

-Change is tested and verified

-Identifies: problems, dependencies, and impact on other systems

Change Management Phase 5: Implementing

-Change is deployed according to a schedule

-May involve: project managers, agile or PMP practices

-Milestones and timelines are tracked

Change Management Phase 6: Reporting

-Results reported to management

-Negative impacts trigger: review, rollback, return to earlier lifecycle phases

Authentication

-the process of VERIFYING who a user is

-Purpose: to confirm the user's identity and prevent unauthorized people from entering the system

-Username + password = user is legitimate

-MFA: a code sent to the phone = user is legitimate

-Who you are

Authorization

-deciding what the authenticated user is ALLOWED to do

-Purpose: limit access based on roles, protect sensitive data, and prevent privilege misuse

-What you can do

Accounting

-RECORDING and TRACKING a user's actions and usage

-Purpose: create logs for security analysis, detect suspicious activity, and support auditing and compliance

-If a file is deleted, the logs show WHO deleted it and WHEN

-What you see

Why AAA matters

-Protects systems from unauthorized access

-Ensures users only do what they are supposed to

-Helps investigate incidents

-Supports compliance (HIPAA, PCI-DSS, SOX)