Unit 3: Secure Cloud Network Architecture, Resiliency and Vulnerability Management - Subjective Questions

Zero Trust Architecture (ZTA) is a security model based on the principle of "never trust, always verify." It assumes that no user, device, or network segment should be trusted by default, whether inside or outside the organizational perimeter.

Core Guiding Principle:

• Every access request must be authenticated, authorized, and continuously validated before granting access to resources.

Difference from Traditional Perimeter-Based Model:

Key Components of ZTA:

• Policy Decision Point (PDP) and Policy Enforcement Point (PEP)
• Identity and Access Management (IAM)
• Micro-segmentation
• Least privilege access
• Continuous monitoring and analytics

ZTA is especially critical in cloud and remote-work environments where a defined network perimeter no longer exists.

Zero Trust Architecture is logically divided into two planes that work together to enforce access decisions.

1. Control Plane:
The control plane is responsible for making and managing access decisions. Key components include:

• Policy Engine (PE): The brain that decides whether to grant, deny, or revoke access based on policy and inputs from external sources (threat intelligence, SIEM, identity systems).
• Policy Administrator (PA): Executes the decision made by the Policy Engine by establishing or terminating the communication path between subject and resource.
• Policy Decision Point (PDP): Combination of PE and PA.

2. Data Plane:
The data plane is where actual data communication happens after access is granted. Key component:

• Policy Enforcement Point (PEP): Enables, monitors, and terminates connections between a subject and an enterprise resource. It acts as the gatekeeper.

Supporting Concepts:

• Adaptive Identity: Dynamically adjusts trust based on context (location, device health, behavior).
• Threat Scope Reduction: Limiting the "blast radius" of an attack.
• Policy-Driven Access Control: Access governed by defined policies.
• Implicit Trust Zones: Minimized regions where entities trust each other.

Workflow:

1. Subject requests access to a resource.
2. Request routed through the PEP.
3. PE evaluates policy and context.
4. PA configures the PEP to allow/deny.
5. Session continuously monitored and re-evaluated.

Cloud Service Models:

• IaaS (Infrastructure as a Service): Provides virtualized computing resources (servers, storage, networking). Examples: AWS EC2, Azure VMs. The customer manages OS, applications, and data.
• PaaS (Platform as a Service): Provides a platform for developing, running, and managing applications without managing underlying infrastructure. Examples: Google App Engine, Heroku. The customer manages applications and data.
• SaaS (Software as a Service): Delivers software applications over the internet on a subscription basis. Examples: Gmail, Salesforce. The customer manages only user access and data.

Shared Responsibility Model:

Security responsibilities are split between the cloud provider and the customer, varying by service model.

Key Principle:

• The provider is responsible for security "of" the cloud (infrastructure).
• The customer is responsible for security "in" the cloud (data, configurations, access).

Misunderstanding this model is a leading cause of cloud breaches (e.g., misconfigured S3 buckets).

Asset Management is the process of identifying, tracking, and managing all hardware, software, and data assets within an organization throughout their lifecycle. You cannot protect what you do not know you have, making it foundational to security.

Asset Lifecycle Phases:

1. Acquisition/Procurement: Assets are purchased or acquired. Security requirements and vendor vetting begin here.
2. Assignment/Ownership: Each asset is assigned an owner responsible for its security.
3. Classification: Assets are categorized by sensitivity and criticality (e.g., public, confidential, restricted).
4. Operation/Monitoring: Assets are actively used, patched, and monitored.
5. Decommissioning/Disposal: Assets are securely retired through data sanitization, destruction, or certification.

Key Activities:

• Inventory & Tracking: Maintaining an up-to-date Configuration Management Database (CMDB).
• Enumeration: Identifying all devices on the network.
• Sanitization: Securely wiping data before disposal.
• Destruction & Certification: Physical destruction with documented proof.

Why Foundational:

• Enables accurate vulnerability management (knowing what to scan).
• Supports incident response (knowing what is affected).
• Ensures compliance and license management.
• Reduces shadow IT and unmanaged attack surface.

Redundancy is the duplication of critical components or functions to increase reliability and ensure continued operation despite failures. It is central to building resilient systems.

Categories of Redundancy:

• Geographic/Site Redundancy: Distributing resources across multiple physical locations (data centers, availability zones, regions) to survive site-wide disasters.
• Server Redundancy: Using clusters, load balancers, and failover servers.
• Network Redundancy: Multiple network paths, NICs, and ISPs to avoid single points of failure.
• Power Redundancy: UPS, dual power supplies, and backup generators.
• Data Redundancy: Backups, replication, and RAID.

RAID (Redundant Array of Independent Disks) Levels:

Related Concepts:

• High Availability (HA): Measured in "nines" of uptime (e.g., 99.999%).
• Load Balancing vs. Clustering: Distributing load vs. coordinated failover.
• Hot, Warm, Cold Sites: Levels of disaster recovery readiness.

These three concepts are related but address resilience at different levels.

1. High Availability (HA):

• Focuses on minimizing downtime to keep systems operational.
• Achieved via redundancy, clustering, and load balancing.
• Allows for brief interruptions during failover.
• Measured in uptime percentage (e.g., 99.99%).

2. Fault Tolerance:

• The ability of a system to continue operating without interruption even when a component fails.
• More stringent than HA — zero downtime.
• Requires full component duplication (e.g., redundant processors operating in lockstep).

3. Disaster Recovery (DR):

• The process of restoring systems and data after a major catastrophic event.
• Involves backups, alternate sites, and recovery plans.
• Reactive and focused on recovery after an outage.

Key Metrics:

• RTO (Recovery Time Objective): The maximum acceptable amount of time to restore a system after a disruption. "How long until we are back up?"
• RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time. "How much data can we afford to lose?"

Example: An RPO of 1 hour means backups must occur at least hourly; an RTO of 4 hours means recovery must complete within 4 hours.

Physical Security protects personnel, hardware, software, networks, and data from physical actions and events that could cause loss or damage. It is the first line of defense — logical controls are meaningless if an attacker has physical access.

Importance:

• Prevents theft, tampering, and destruction of equipment.
• Protects against unauthorized physical access to data centers.
• Mitigates environmental threats (fire, flood, power loss).

Key Physical Security Controls:

1. Fencing & Bollards: Perimeter barriers to deter and delay intruders and protect against vehicle attacks.
2. Access Control Vestibules (Mantraps): Two-door systems that prevent tailgating/piggybacking by allowing only one person at a time.
3. Surveillance (CCTV/Video): Monitoring and recording activity for detection and forensic evidence.
4. Security Guards: Human presence for deterrence, verification, and response.
5. Badges & Biometric Locks: Authentication using smart cards, PINs, fingerprints, or retina scans.
6. Lighting: Deters intruders and improves surveillance effectiveness.
7. Sensors: Infrared, pressure, microwave, and ultrasonic sensors to detect motion or presence.

Detective vs. Preventive:

• Preventive: Fences, locks, mantraps.
• Detective: Cameras, sensors, alarms.

Environmental Controls:

• Fire suppression, HVAC, humidity control, and hot/cold aisle containment.

Embedded Systems are specialized computing systems designed to perform dedicated functions within a larger mechanical or electrical system. Examples include medical devices, industrial controllers (ICS/SCADA), smart appliances, and automotive control units.

Characteristics:

• Purpose-built with limited resources (CPU, memory, power).
• Often run real-time operating systems (RTOS).
• Long operational lifespans.

Unique Security Challenges:

• Limited Compute Power: Insufficient resources to run traditional security software like antivirus or encryption.
• Difficult Patching: Many devices cannot be easily updated; some require physical access or downtime.
• Long Lifecycles: Devices stay in service for decades, outliving vendor support (end-of-life risk).
• Hardcoded/Default Credentials: Many ship with weak, unchangeable passwords.
• Lack of Visibility: Often invisible to standard IT asset management.
• Insecure Communication: Weak or no encryption of transmitted data.
• Physical Exposure: Frequently deployed in unsecured, remote locations.

Specialized Systems:

• ICS/SCADA: Control critical infrastructure; downtime can be catastrophic.
• IoT: Massive scale creates huge attack surfaces (e.g., Mirai botnet).
• RTOS: Timing-critical, limited security features.

Mitigations:

• Network segmentation/isolation.
• Wrappers and gateways for security.
• Strict access control and monitoring.

Device and OS vulnerabilities are weaknesses in the operating system, firmware, or hardware that can be exploited by attackers.

Common OS Vulnerabilities:

• Unpatched Systems: Missing security updates leave known vulnerabilities exploitable.
• Misconfigurations: Default settings, open ports, unnecessary services enabled.
• Privilege Escalation Flaws: Allow attackers to gain higher-level access.
• Buffer Overflows: Memory corruption bugs enabling code execution.
• Insecure Default Accounts: Default/weak credentials.

Firmware Vulnerabilities:

• Firmware is low-level software embedded in hardware (BIOS/UEFI, device controllers).
• Flaws are highly dangerous because firmware operates below the OS and is hard to detect/remove.
• Persistence: Malware in firmware survives OS reinstallation.
• TPM/Secure Boot bypass: Can undermine hardware root of trust.

End-of-Life (EOL) and Legacy Systems:

• EOL systems no longer receive security patches from the vendor.
• Legacy applications may run on unsupported platforms for business reasons.
• These become permanent vulnerabilities that cannot be remediated via patching.

Risk Mitigation:

• Compensating controls: Isolation, network segmentation, enhanced monitoring.
• Firmware signing & secure boot.
• Regular patch management and timely upgrades.
• Decommissioning EOL systems where possible.

Application vulnerabilities are flaws in software code or design that attackers exploit to compromise systems.

1. Memory Injection:

• Injecting malicious code into a running process's memory space.
• Enables arbitrary code execution within a trusted process.

2. Buffer Overflow:

• Occurs when data exceeds the allocated buffer size, overwriting adjacent memory.
• Can corrupt data, crash the program, or allow code execution.
• Example: overwriting the return address to redirect execution.

3. Race Conditions:

• Occur when system behavior depends on the timing/sequence of events.
• TOCTOU (Time-of-Check to Time-of-Use): A resource changes between the check and its use, enabling exploitation.

4. Injection Attacks:

• SQL Injection (SQLi): Inserting malicious SQL into input fields to manipulate databases.
• Cross-Site Scripting (XSS): Injecting malicious scripts into web pages viewed by others.
• Cross-Site Request Forgery (CSRF): Tricking a user into executing unwanted actions.
• Command Injection: Executing arbitrary OS commands via vulnerable input.

Other Common Flaws:

• Privilege Escalation: Gaining elevated access.
• Replay Attacks: Reusing captured valid data transmissions.
• Malicious Updates: Compromised software updates.

Mitigations:

• Input validation and sanitization.
• Parameterized queries (prepared statements).
• Secure coding practices and code review.
• Address Space Layout Randomization (ASLR) and stack canaries.

Cloud environments introduce vulnerabilities distinct from on-premises systems due to their shared, dynamic, and API-driven nature.

1. Misconfigurations:

• The leading cause of cloud breaches.
• Examples: publicly exposed storage buckets (e.g., AWS S3), overly permissive IAM roles, open security groups, disabled logging.
• Result from complexity and lack of expertise.

2. Insecure APIs:

• Cloud services are managed through APIs, which form a large attack surface.
• Vulnerabilities: weak authentication, lack of rate limiting, exposed API keys, insufficient input validation.
• Compromised APIs can grant full control over cloud resources.

3. Multi-Tenancy Risks:

• Multiple customers share the same physical infrastructure.
• Resource isolation failures could allow data leakage between tenants.
• Side-channel attacks exploit shared hardware.
• "Noisy neighbor" performance issues.

Other Cloud Vulnerabilities:

• Account Hijacking: Stolen credentials granting access.
• Insufficient IAM: Weak identity and access management.
• Data Breaches: Due to weak encryption or access control.
• Shadow IT: Unauthorized cloud service usage.
• Lack of Visibility: Limited monitoring of provider infrastructure.

Mitigations:

• Cloud Security Posture Management (CSPM) tools.
• Principle of least privilege in IAM.
• Encryption of data at rest and in transit.
• Regular configuration audits and API security testing.

Vulnerability Identification is the process of discovering security weaknesses in systems, networks, and applications using multiple techniques.

Primary Methods:

1. Vulnerability Scanning:

• Automated tools (e.g., Nessus, OpenVAS, Qualys) scan systems against databases of known vulnerabilities.
• Credentialed scans: Use login credentials for deeper, more accurate results.
• Non-credentialed scans: External view without login, like an attacker.

2. Active vs. Passive Scanning:

3. Penetration Testing:

• Simulated real-world attack to actively exploit vulnerabilities.
• Tests the actual impact of weaknesses, not just their presence.
• Types: Black box (no knowledge), White box (full knowledge), Gray box (partial).

Other Methods:

• Bug Bounty Programs: Crowdsourced vulnerability discovery with rewards.
• Threat Intelligence Feeds: External data on emerging threats.
• OSINT (Open Source Intelligence): Gathering public information.
• Static (SAST) & Dynamic (DAST) Application Security Testing.
• System/Log Review and Audits.

Importance: Combining methods provides comprehensive coverage, reducing blind spots.

The Vulnerability Management Lifecycle is a continuous, cyclical process for identifying, evaluating, treating, and reporting security vulnerabilities.

Phases:

1. Identification/Discovery:

• Discover vulnerabilities through scanning, pen testing, threat intel, and bug bounties.
• Maintain an accurate asset inventory as a prerequisite.

2. Analysis / Validation:

• Confirm vulnerabilities are real (eliminate false positives).
• Assess context, exploitability, and affected assets.

3. Prioritization:

• Rank vulnerabilities by risk (severity × likelihood × asset value).
• Use CVSS scores, exploit availability, and business impact.

4. Remediation / Treatment:

• Remediate: Fully fix (patch, reconfigure).
• Mitigate: Reduce risk with compensating controls.
• Accept: Acknowledge risk if cost of fix exceeds benefit.
• Transfer: Via insurance or third parties.

5. Verification / Rescanning:

• Confirm the fix was successful and introduced no new issues.

6. Reporting / Monitoring:

• Document findings, track metrics, and report to stakeholders.
• Continuous monitoring feeds back into identification.

Key Supporting Elements:

• CVE (Common Vulnerabilities and Exposures): Standardized identifiers.
• CVSS (Common Vulnerability Scoring System): Severity scoring.
• SLAs: Define remediation timelines by severity.

The cycle repeats continuously to adapt to the evolving threat landscape.

CVSS (Common Vulnerability Scoring System) is an open, industry-standard framework for rating the severity of security vulnerabilities, producing a numerical score from 0.0 to 10.0.

Metric Groups:

1. Base Metrics (intrinsic, constant):

• Exploitability metrics:
  • Attack Vector (AV): Network, Adjacent, Local, Physical.
  • Attack Complexity (AC): Low or High.
  • Privileges Required (PR).
  • User Interaction (UI).
• Impact metrics:
  • Confidentiality (C), Integrity (I), Availability (A) impact.
• Scope (S): Whether the vulnerability affects resources beyond its security scope.

2. Temporal Metrics (change over time):

• Exploit code maturity, remediation level, report confidence.

3. Environmental Metrics (organization-specific):

• Adjust the score based on the importance of the affected asset to a specific organization.

Score Interpretation (Severity Ratings):

Usage:

• Helps prioritize remediation efforts.
• A high CVSS score alone does not equal high risk — context (exposure, asset value) must also be considered alongside exploit availability.

Once a vulnerability is identified and prioritized, organizations choose a response strategy based on risk, cost, and business impact. These map to classic risk treatment options.

1. Remediation (Fix):

• Fully eliminating the vulnerability.
• Methods: applying patches, upgrading software, correcting configurations.
• The most desirable but sometimes costly or disruptive option.

2. Mitigation (Reduce):

• Reducing the risk or impact when full remediation is not immediately possible.
• Uses compensating controls: network segmentation, firewalls, IDS/IPS, disabling features, access restrictions.
• Common for legacy/EOL systems that cannot be patched.

3. Acceptance (Tolerate):

• Consciously accepting the risk when the cost of fixing exceeds the potential loss.
• Requires documented approval and ongoing monitoring.
• An exception is formally recorded.

4. Transference (Share):

• Shifting the risk to a third party.
• Examples: cyber insurance, outsourcing to a managed service provider.

5. Avoidance (Eliminate the activity):

• Discontinuing the risky activity or decommissioning the vulnerable system entirely.

Supporting Factors in Decision:

• Patch availability and testing requirements.
• System criticality and downtime windows.
• Legacy/proprietary constraints.
• Regulatory/compliance requirements.

Validation: After any action, rescan and verify that the vulnerability is resolved and no new issues were introduced.

Choosing between on-premises and cloud infrastructure involves fundamental trade-offs.

On-Premises Advantages:

• Complete data sovereignty and control.
• Easier to meet strict compliance/regulatory requirements in some cases.
• No dependence on internet connectivity.

On-Premises Disadvantages:

• High upfront and maintenance costs.
• Limited scalability; capacity planning challenges.

Cloud Advantages:

• Elasticity and rapid provisioning.
• Reduced maintenance burden.
• Global reach and built-in redundancy.

Cloud Disadvantages:

• Reduced visibility and control.
• Risk of vendor lock-in.
• Dependence on provider's security.

Hybrid Cloud: Many organizations adopt a hybrid model to balance control and flexibility.

Both concepts are core enablers of modern defense-in-depth and Zero Trust strategies.

1. Micro-segmentation:

• Dividing a network into small, isolated segments down to the individual workload or application level.
• Each segment has its own security policies and controls.

Benefits:

• Limits lateral movement: An attacker who breaches one segment cannot easily move to others.
• Reduces attack surface and contains breaches ("blast radius" reduction).
• Enforces granular access control between workloads.
• Implemented via software-defined networking (SDN) and host-based firewalls.

2. Principle of Least Privilege (PoLP):

• Users, processes, and systems should be granted the minimum level of access necessary to perform their functions — nothing more.

Benefits:

• Minimizes damage from compromised accounts.
• Reduces insider threat risk.
• Limits the scope of privilege escalation attacks.

Implementation Techniques:

• Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).
• Just-in-Time (JIT) access provisioning.
• Regular access reviews and privilege revocation.

Synergy with Zero Trust:

• Zero Trust assumes breach; micro-segmentation contains it, while least privilege limits what any compromised entity can do.
• Together they implement "threat scope reduction" — a cornerstone of ZTA.

A Secure Cloud Network Architecture uses layered controls to isolate, protect, and manage traffic within cloud environments.

Key Components:

1. Virtual Private Cloud (VPC):

• A logically isolated section of the cloud where resources are deployed.
• Provides control over IP addressing, subnets, and routing.
• Subnets can be public (internet-facing) or private (internal only).

2. Security Groups:

• Stateful virtual firewalls operating at the instance/resource level.
• Control inbound/outbound traffic by rules (port, protocol, source).
• Return traffic automatically allowed (stateful).

3. Network Access Control Lists (NACLs):

• Stateless firewalls operating at the subnet level.
• Evaluate rules in order; return traffic must be explicitly allowed.
• Provide a secondary defense layer.

4. VPN & Transit Gateways:

• VPN: Encrypted tunnel connecting on-premises networks to the cloud securely.
• Transit Gateway: Central hub connecting multiple VPCs and on-prem networks, simplifying routing.

Additional Controls:

• Bastion/Jump hosts for secure administrative access.
• Web Application Firewall (WAF).
• DDoS protection services.
• Private endpoints to avoid public internet exposure.

Principle: Combine isolation, layered firewalls, encryption, and least-privilege routing for defense in depth.

Data Sanitization is the process of permanently and irreversibly removing data from storage media to prevent unauthorized recovery. It is a critical final stage of the asset lifecycle (decommissioning).

Importance:

• Prevents data remanence — residual data recoverable after deletion.
• Ensures compliance with privacy regulations (GDPR, HIPAA).
• Protects against dumpster diving and recovered-drive breaches.

Methods:

1. Data Wiping / Overwriting:

• Overwriting storage with random data patterns (one or multiple passes).
• The media remains reusable.
• Standards: NIST 800-88 "Clear".
• Less effective on SSDs due to wear-leveling.

2. Degaussing:

• Using a strong magnetic field to disrupt the magnetic domains of a drive.
• Effective for magnetic media (HDDs, tapes).
• Not effective on SSDs (no magnetic storage).
• Renders the drive permanently unusable.

3. Physical Destruction:

• Physically destroying the media via shredding, crushing, incineration, or pulverizing.
• The most secure method; media is unusable.
• Required for highly sensitive data.

Supporting Practices:

• Certification/Documentation: A certificate of destruction proving the process occurred, maintaining chain of custody.
• Third-party disposal vendors should be vetted and certified.

Patch Management is the systematic process of acquiring, testing, and deploying updates (patches) to software and systems to fix vulnerabilities, bugs, and improve functionality. It is a primary remediation mechanism in vulnerability management.

Patch Management Process:

1. Inventory & Assessment: Identify all systems and their current patch levels.
2. Patch Identification: Monitor vendor advisories, CVE feeds for new patches.
3. Prioritization: Rank patches by severity (CVSS) and asset criticality.
4. Testing: Validate patches in a staging/test environment to avoid breaking production.
5. Deployment: Roll out patches, often in phases.
6. Verification: Confirm successful installation and functionality.
7. Documentation: Record patch status for audits.

Challenges:

• Downtime/Disruption: Patching may require reboots, impacting availability.
• Compatibility Issues: Patches can break applications or dependencies.
• Legacy/EOL Systems: No patches available.
• Scale & Diversity: Large, heterogeneous environments are hard to manage.
• Zero-Day Gaps: No patch exists yet for newly discovered flaws.
• Embedded/OT Systems: Difficult or risky to patch.

Best Practices:

• Maintain a regular patch cycle (e.g., Patch Tuesday) plus emergency patching for critical flaws.
• Always test before deploying.
• Use automated patch management tools (WSUS, SCCM, Intune).
• Define SLAs for patch timelines based on severity.
• Implement rollback plans for failed patches.
• Use compensating controls where patching is impossible.