Advance Diploma in Information Technology
Networking & Cloud Computing
•
Advance Diploma
Network and Cloud Security
Introduction
Network and cloud security is the disciplined protection of communication systems, computing resources, applications, data, identities and services against unauthorized disclosure, alteration, disruption and misuse. Modern organizations rarely operate a single, clearly bounded network. Users connect from homes, offices and mobile devices; applications run across public and private clouds; data moves between data centres, branch offices, software-as-a-service platforms and partner environments. Consequently, security must be designed as an integrated system rather than added as a perimeter device.
The central security objectives are confidentiality, integrity and availability, commonly called the CIA triad. Confidentiality prevents unauthorized access to information. Integrity ensures that information and systems are accurate, complete and not improperly modified. Availability ensures that authorized users can access systems and data when required. These objectives must be balanced: an extremely restrictive system may be confidential but unusable, while a highly available system with weak access controls may expose sensitive information.
This chapter develops the principles and practical controls required to secure enterprise networks and cloud environments. It covers defense in depth, zero trust, segmentation, firewalls, virtual private networks, identity and access management, encryption, certificates, key management, secure configuration, vulnerability management and incident response.
Learning Objectives
By the end of this chapter, a learner should be able to:
Explain confidentiality, integrity, availability, authentication, authorization and accountability.
Apply defense-in-depth and zero-trust principles to network and cloud designs.
Design basic network segmentation using firewalls, security groups and access-control policies.
Distinguish between VPN technologies and select an appropriate approach.
Explain IAM, multi-factor authentication, least privilege and role-based access control.
Select suitable encryption, certificate and key-management practices.
Apply secure-configuration and vulnerability-management processes.
Describe a practical incident-response lifecycle and the responsibilities of technical teams.
Evaluate security, governance, privacy and operational trade-offs in a cloud deployment.
1. Security Foundations
1.1 The CIA triad and supporting properties
Confidentiality is achieved through access controls, encryption, data classification and secure handling procedures. Integrity depends on authorization, hashing, digital signatures, checksums, audit logs, version control and controlled change management. Availability depends on redundancy, capacity planning, backups, disaster recovery, patching, monitoring and protection against denial-of-service attacks.
Other important properties complement the triad:
Authentication verifies an identity or system claim.
Authorization determines what an authenticated subject may do.
Accountability connects actions to identifiable users, services or devices through logging.
Non-repudiation provides evidence that an action or message originated from a particular party, although no technical mechanism alone removes all legal or operational disputes.
Resilience is the ability to continue operating, or recover quickly, when controls fail or an attack succeeds.
Security objectives can conflict. Encrypting every data path may increase processing and operational complexity. Aggressive availability measures may keep compromised services online. Good security engineering therefore begins with risk assessment, business requirements, regulatory duties and the value of protected assets.
1.2 Threats, vulnerabilities and risk
A threat is a potential cause of harm, such as ransomware, credential theft, insider abuse or a natural disaster. A vulnerability is a weakness that a threat may exploit, such as an unpatched service, excessive privilege or exposed storage. Risk is the possibility that a threat will exploit a vulnerability and produce an unwanted impact.
A qualitative risk statement can be expressed as:
Risk increases when threat likelihood, vulnerability exposure or business impact increases.
Organizations often rank risk as low, medium or high using likelihood-impact matrices. Such matrices are useful communication tools, but they are not precise measurements. Risk decisions should also consider uncertainty, dependencies, regulatory penalties, recovery cost and the effectiveness of existing controls.
1.3 Assets and trust boundaries
Assets include data, identities, endpoints, applications, virtual machines, containers, network devices, APIs, cryptographic keys and business processes. A trust boundary is a point where security assumptions change. Examples include the boundary between the public internet and a web service, between a user workstation and a database, or between an organization and a cloud provider.
Security architecture should identify:
what assets exist and who owns them;
where data is stored, processed and transmitted;
which identities and services require access;
which controls enforce the access decision;
how activity is logged and reviewed; and
how the organization will recover from failure or compromise.
2. Defense in Depth and Zero Trust
2.1 Defense in depth
Defense in depth uses multiple, partially independent controls so that failure of one control does not expose the entire environment. A layered design may include physical security, secure configuration, identity controls, endpoint protection, network segmentation, encryption, application security, monitoring, backups and trained personnel.
The layers should not merely duplicate one another. They should address different failure modes. For example, a firewall may restrict inbound traffic, while application authorization prevents an authenticated user from viewing another customer’s records. Encryption protects data if storage is copied, while logging helps detect abnormal access.
Defense in depth has limitations. More controls increase cost, configuration complexity and the possibility of contradictory policies. Controls must therefore be tested, monitored and assigned to accountable owners.
2.2 Zero-trust security
Zero trust is an architectural approach based on the principle that no user, device, network location or workload should receive implicit trust. Access is granted only after an explicit decision based on identity, device condition, requested resource, context and policy.
A practical zero-trust decision considers:
Identity: Who or what is requesting access?
Authentication strength: Has the identity been verified using an appropriate method, preferably phishing-resistant multi-factor authentication?
Device posture: Is the device managed, patched, encrypted and free from known security failures?
Resource sensitivity: What is the classification and business importance of the requested resource?
Context: What are the location, time, network, risk signals and request purpose?
Authorization: Is the requested action permitted for this identity and context?
Continuous evaluation: Should access be revoked or re-evaluated if risk changes?
Zero trust does not mean that every packet must be individually authenticated in the same way, nor that network segmentation is unnecessary. It means that network location is not treated as sufficient evidence of trust. Identity-aware proxies, strong IAM, microsegmentation, device management and centralized policy evaluation are common implementation components.
Layered zero trust security architecture
Figure: Layered zero trust security architecture
Figure: A simplified zero-trust access decision flow.
3. Network Segmentation and Firewalls
3.1 Segmentation principles
Segmentation divides a network into security zones with controlled communication between them. A common enterprise arrangement includes an internet edge, a demilitarized zone (DMZ) for public-facing services, an application zone, a database zone, a management zone and a user or endpoint zone.
Segmentation limits lateral movement. If an internet-facing web server is compromised, the attacker should not automatically reach database servers, domain controllers or backup systems. Segmentation can be implemented with VLANs, routed subnets, network access-control lists, internal firewalls, cloud virtual networks, security groups, service meshes and host-based firewalls.
Good segmentation is based on communication requirements rather than convenience. Policies should specify source, destination, protocol, port, direction, identity where supported, and business justification. “Allow all internal traffic” is easy to administer but creates a large blast radius.
3.2 Firewalls
A firewall enforces traffic policy between interfaces, networks or services. Traditional packet-filtering firewalls examine addresses, protocols and ports. Stateful firewalls track connection state. Next-generation firewalls may add application identification, intrusion prevention, URL filtering, malware analysis and user context.
A secure rule base normally follows these principles:
deny by default where practical;
permit only required flows;
place specific rules before broad rules;
restrict both source and destination;
avoid unnecessary administrative exposure;
log meaningful denied and accepted events;
remove obsolete rules; and
review rules against owners and business requirements.
Firewalls are not substitutes for secure applications. They cannot reliably determine whether an authorized request is logically appropriate inside an application, and they may be bypassed by compromised credentials or an authorized but malicious user.
3.3 Cloud network controls
Cloud providers commonly offer virtual networks, subnets, route tables, network security groups, private endpoints, managed firewalls and web application firewalls. A security group may be stateful and attached to a virtual interface, while a network access-control list may be stateless and applied at subnet boundaries; exact behavior varies by provider and must be verified in current documentation.
Cloud security also requires attention to control-plane access. A private database can still be exposed if its administrative identity is compromised, its backup is public, or a permissive API policy allows unauthorized changes. Network design and IAM design must therefore be evaluated together.
4. VPNs and Secure Communication
A virtual private network creates an authenticated and cryptographically protected tunnel across an untrusted network. Site-to-site VPNs connect networks, while remote-access VPNs connect individual devices or users. Common technologies include IPsec and TLS-based VPNs. WireGuard is another modern tunnel technology, but organizational suitability depends on platform support, governance and operational capability.
A VPN typically provides:
peer or user authentication;
confidentiality through encryption;
integrity protection to detect alteration; and
replay protection in many protocols.
A VPN does not make an endpoint trustworthy. A stolen credential, infected laptop or excessive internal permission can still be dangerous after the tunnel is established. Remote access should therefore use MFA, managed devices, least privilege, split-tunnel decisions based on risk, strong logging and timely session revocation.
TLS protects application sessions such as HTTPS. IPsec commonly protects traffic at the network layer. The choice depends on whether the requirement is application-specific access, broad network connectivity, device compatibility, performance and administrative control. Deprecated protocols, weak ciphers, shared secrets and certificate-validation bypasses should not be used.
5. Identity and Access Management
5.1 IAM concepts
Identity and access management establishes who may perform which action on which resource under what conditions. Its major functions are identity proofing, authentication, authorization, provisioning, deprovisioning, federation, privileged-access management and auditing.
Authentication factors are commonly grouped as:
something the user knows, such as a password;
something the user has, such as a hardware security key; and
something the user is, such as a biometric characteristic.
Multi-factor authentication combines independent factors. A password and a second password are not independent factors. Phishing-resistant methods, including hardware security keys using modern public-key protocols, provide stronger protection than one-time codes against many credential-phishing attacks.
5.2 Authorization models
Role-based access control (RBAC) assigns permissions to roles and users to roles. It is manageable when job functions are stable. Attribute-based access control (ABAC) evaluates attributes such as department, device status, data classification, location and time. ABAC can express fine-grained policies but requires reliable attributes and careful governance.
The principle of least privilege gives a subject only the permissions required for its duties and only for as long as needed. Privileged accounts should be separate from ordinary accounts, protected with MFA, monitored and preferably managed through just-in-time elevation. Service accounts require owners, limited permissions, credential rotation and non-interactive restrictions where possible.
Joiner-mover-leaver processes are essential. Access should be granted when a person joins, adjusted when responsibilities change and removed promptly when employment or authorization ends. Periodic access reviews should examine actual use, not merely documented job titles.
6. Encryption, Certificates and Key Management
6.1 Encryption concepts
Encryption transforms plaintext into ciphertext using an algorithm and key. Symmetric encryption uses the same secret key for encryption and decryption and is efficient for large data volumes. Asymmetric cryptography uses a public-key and a private-key pair. It supports key exchange, digital signatures and identity mechanisms, but is generally more computationally expensive for bulk data.
Authenticated encryption, such as a modern authenticated-encryption mode, provides confidentiality and integrity together. Nonces or initialization values must be generated and used according to the algorithm’s requirements; accidental nonce reuse can seriously weaken security for some modes.
Encryption should be applied to data in transit and, where appropriate, data at rest. It does not protect data after an authorized application has decrypted it, nor does it correct weak authorization or insecure endpoints.
6.2 Hashing and digital signatures
A cryptographic hash produces a fixed-length digest from input data. Secure hashes are designed to make it computationally difficult to find collisions or recover the input. Hashes are useful for integrity checking and password-processing systems, but a plain hash is not encryption and cannot be decrypted.
A digital signature is created with a private key and verified with the corresponding public key. It provides evidence of integrity and key possession. Signature verification alone does not prove that a public key belongs to a trusted organization; that relationship requires a certificate or another trust mechanism.
6.3 Certificates and PKI
A digital certificate binds a public key to an identity through a certificate authority (CA). Public-key infrastructure includes certificate authorities, registration processes, certificate policies, validation mechanisms, repositories and revocation or status services.
When a browser validates a secure website certificate, it checks factors such as the chain to a trusted root, the subject name, validity period, signature and status. Administrators must maintain accurate system time, protect private keys, monitor expiry and plan renewal. A certificate that has expired, has the wrong name or has an untrusted chain may cause service failure or encourage dangerous validation bypasses.
6.4 Key management
Key management is often more important than the choice between reputable modern algorithms. A lifecycle includes generation, distribution, storage, use, rotation, backup, recovery, revocation and destruction. Keys should be separated by environment and purpose; development keys should not protect production data.
Hardware security modules or cloud key-management services can protect key material and provide controlled cryptographic operations. However, managed services do not eliminate governance responsibilities. Organizations must define owners, access policies, separation of duties, recovery procedures, audit requirements and the consequences of key loss.
7. Secure Configuration and Vulnerability Management
A secure baseline specifies approved settings for operating systems, network devices, databases, cloud services and applications. Baselines may include removal of unnecessary services, restricted management interfaces, strong authentication, secure logging, time synchronization, encryption, endpoint protection and controlled administrative access.
Configuration should be managed as code where practical. Version-controlled templates allow peer review, repeatable deployment and detection of unauthorized drift. Secrets must not be embedded in source code, images or configuration files. They should be stored in an approved secrets-management system with access logging and rotation.
Vulnerability management is a lifecycle rather than a single scan:
discover and inventory assets;
identify vulnerabilities through scanning, advisories, testing and supplier information;
validate relevance and exploitability;
prioritize using asset value, exposure, active exploitation and compensating controls;
remediate through patching, configuration change, isolation or replacement;
verify that the weakness is closed; and
report trends and unresolved risk to accountable owners.
A vulnerability scanner may produce false positives and may miss application logic flaws, unknown assets or vulnerabilities requiring authentication. Scanning should therefore be combined with penetration testing, secure development, code review, configuration assessment and threat intelligence. Emergency patching must still be tested sufficiently to avoid creating a larger outage.
8. Monitoring, Logging and Incident Response
Security monitoring converts events into evidence and decisions. Important log sources include identity providers, firewalls, endpoints, cloud control planes, applications, databases, DNS, VPNs and vulnerability systems. Logs should include reliable timestamps, relevant identities, source and destination information, actions and outcomes. Time synchronization is essential for reconstructing events.
A security information and event management platform can aggregate and correlate events, while detection and response tools may monitor endpoints and cloud workloads. Logging must be proportionate: collecting everything without retention, access control, analysis and storage planning produces cost without dependable detection.
Incident response commonly follows these stages:
Preparation: establish plans, contacts, tools, authority, backups and exercises.
Detection and analysis: validate alerts, determine scope, classify severity and preserve evidence.
Containment: limit damage, for example by disabling credentials, isolating hosts or blocking indicators.
Eradication: remove malware, close exploited weaknesses and eliminate persistence.
Recovery: restore services carefully, monitor for recurrence and validate business functions.
Lessons learned: identify control, process and communication improvements.
Containment decisions involve trade-offs. Disconnecting a compromised server may protect the organization but destroy volatile evidence or interrupt critical services. Legal, privacy, regulatory and contractual requirements may also govern evidence handling and notification. An incident plan should identify decision-makers before a crisis occurs.
A fictional online retailer, Northstar Retail, operates a public web application in a public cloud. Its web tier is internet-facing, application services run in private subnets, and customer records are stored in a managed database. Developers use a separate environment, but several administrative accounts use password-only authentication.
Problem
A developer accidentally commits a cloud access key to a public code repository. Automated attackers use the key to enumerate storage and query cloud APIs. Monitoring detects unusual API calls, but logs are incomplete and the organization cannot immediately determine which resources were accessed.
Analysis
The incident exposes several weaknesses: long-lived credentials, excessive permissions, insufficient secret scanning, weak separation between development and production, incomplete audit logging and inadequate incident rehearsal. The network is segmented, but the compromised identity can operate through legitimate cloud APIs; therefore, network controls alone are insufficient.
Approach and solution
The response team first disables and rotates the exposed key, preserves repository and cloud audit evidence, and identifies all actions performed by the identity. They temporarily restrict high-risk API operations and review storage access logs. Affected credentials are replaced with short-lived, workload-specific identities. MFA is required for administrators, and privileged access is routed through a controlled identity platform.
The retailer then applies least-privilege policies, separates development and production accounts, enables continuous secret scanning, centralizes immutable audit logs and creates alerts for unusual API activity. Sensitive storage is private by default, and access is granted through narrowly defined roles. The organization conducts a recovery exercise and documents notification decisions based on the type of data involved and applicable law.
Outcome
The retailer confirms that a test storage location was accessed but finds no evidence that production customer records were downloaded. The organization reduces the exposure window for credentials, improves detection and establishes accountable owners for cloud identities and logs.
Learning points
Cloud security includes control-plane identities, not only network traffic.
Long-lived credentials create avoidable exposure.
Segmentation reduces blast radius but cannot replace IAM.
Logging must be enabled before an incident.
Recovery and communication are technical and governance activities together.
Governance, Ethics and Professional Practice
Security professionals handle data that may reveal health, financial, employment or personal information. They should collect and retain only what is justified, restrict access, protect evidence and respect privacy obligations. Monitoring should be transparent, proportionate and governed by policy. Biometric and behavioural systems require particular care because errors and misuse can affect individuals significantly.
Cloud contracts should clarify data location, subcontractors, breach notification, audit rights, service availability, deletion at termination and shared-responsibility boundaries. The cloud provider secures parts of the underlying service, but the customer remains responsible for its identities, configurations, data and many applications. Responsibility varies by service model and must be documented rather than assumed.
Artificial intelligence can assist anomaly detection, alert triage, malware analysis and configuration review. It can also produce false positives, expose sensitive data through poorly governed prompts, or encourage unjustified automated blocking. Human oversight, explainability appropriate to the decision, access controls and testing against adversarial input remain necessary.
Contemporary Developments and Best Practices
Important current directions include identity-centric security, software supply-chain protection, confidential-computing techniques, passwordless authentication, workload identity, infrastructure-as-code security and extended detection and response. These developments are valuable when integrated into risk management rather than adopted as fashionable labels.
A practical security programme should:
maintain an accurate asset and data inventory;
classify information and define owners;
enforce MFA, especially for privileged access;
use least privilege and periodically review permissions;
segment networks and workloads according to communication needs;
encrypt sensitive data in transit and at rest;
manage certificates, secrets and keys through controlled lifecycles;
establish secure configuration baselines and change control;
prioritize vulnerabilities using exposure and business impact;
centralize important logs and test detection;
maintain tested backups and recovery procedures;
exercise incident-response plans; and
measure improvement through meaningful indicators such as remediation age, MFA coverage, privileged-access review completion, backup recovery results and time to contain validated incidents.
No metric proves that an organization is secure. Metrics should reveal exposure, control coverage and recovery capability while avoiding incentives to hide incidents or close alerts without investigation.
Challenges and Limitations
Security controls can fail because of misconfiguration, unsupported legacy systems, weak governance, supplier dependence, human error and organizational pressure for speed. Zero trust can become an expensive collection of products if policies, identity data and ownership are unclear. Microsegmentation can create operational outages when application dependencies are unknown. Encryption can complicate lawful access, recovery and performance. Vulnerability scanning can create a false sense of completeness. Incident response can be impaired by poor logging or unclear authority.
The appropriate response is not to abandon controls but to engineer them with testing, staged deployment, rollback plans, documentation and continuous review. Security is a socio-technical discipline: technology, people, processes, law and business priorities must operate together.
Chapter Summary
Network and cloud security protects confidentiality, integrity and availability while supporting authentication, authorization, accountability and resilience. Defense in depth combines independent layers of protection, whereas zero trust removes implicit trust based on network location and evaluates access explicitly and continuously. Segmentation and firewalls limit communication and reduce lateral movement, but they must be combined with secure applications and IAM.
VPNs protect traffic across untrusted networks but do not make compromised endpoints safe. IAM depends on strong authentication, least privilege, role or attribute-based authorization, lifecycle management and privileged-access controls. Encryption, hashes, digital signatures, certificates and key-management processes serve different purposes and must be operated through complete lifecycles. Secure baselines, vulnerability management, logging and incident response transform security principles into operational practice. Finally, cloud security requires shared-responsibility awareness, governance, privacy protection, tested recovery and continuous improvement.
Key Terms
Confidentiality: Protection of information from unauthorized disclosure.
Integrity: Assurance that data and systems are not improperly altered.
Availability: Reliable access to authorized services and information.
Defense in depth: Use of multiple complementary security layers.
Zero trust: Security approach that grants no implicit trust and evaluates access explicitly.
Trust boundary: Point where security assumptions or control requirements change.
Segmentation: Division of a network or environment into controlled security zones.
Firewall: System that enforces traffic rules between networks, interfaces or services.
VPN: Encrypted and authenticated tunnel across an untrusted network.
Authentication: Verification of an identity claim.
Authorization: Decision about permitted actions on resources.
Least privilege: Granting only the access required for an authorized task.
RBAC: Authorization model based on roles and assigned permissions.
Encryption: Transformation of plaintext into protected ciphertext using a key.
Hash: Fixed-length digest used for integrity and other cryptographic purposes.
Digital certificate: Signed binding between a public key and an identity.
Key management: Governance of cryptographic keys throughout their lifecycle.
Vulnerability management: Process of discovering, prioritizing, remediating and verifying weaknesses.
Incident response: Structured process for detecting, containing, resolving and learning from security incidents.
Shared responsibility: Division of security duties between a cloud provider and its customer.
Review Questions
Short Answer Questions
Define confidentiality, integrity and availability.
What is the purpose of network segmentation?
Distinguish authentication from authorization.
Why is a plain cryptographic hash not encryption?
List the main stages of incident response.
Long Answer Questions
Explain how defense in depth and zero trust complement one another in a cloud environment.
Compare RBAC and ABAC, including situations in which each may be appropriate.
Describe the lifecycle of a cryptographic key and explain the risks of poor key management.
Explain how firewalls, security groups and host controls can be combined to protect a three-tier application.
Discuss the shared-responsibility model and the security duties that remain with a cloud customer.
Analytical / Application Questions
A public web server has been compromised, but the database is in a private subnet. Identify the controls that should limit further damage and the evidence that responders should collect.
An organization discovers that an administrator’s password was reused on several cloud accounts. Develop a prioritized response and a longer-term IAM improvement plan.
A business wants to deploy a remote-access VPN for contractors using unmanaged personal laptops. Evaluate the risks and recommend a secure access design.
Multiple Choice Questions with Answers
Question 1
Which security objective is primarily concerned with preventing unauthorized disclosure of information?
A. Availability
B. Confidentiality
C. Integrity
D. Accountability
Correct Answer: B. Confidentiality
Question 2
What is the central assumption of a zero-trust architecture?
A. Internal network traffic is always trusted
B. Users are trusted after one successful login
C. No subject receives implicit trust based only on network location
D. Firewalls are unnecessary
Correct Answer: C. No subject receives implicit trust based only on network location
Question 3
Which control most directly limits lateral movement after a web server is compromised?
A. Network segmentation
B. Increasing monitor brightness
C. Disabling data classification
D. Using a longer application name
Correct Answer: A. Network segmentation
Question 4
What does multi-factor authentication require?
A. Two passwords from the same password manager
B. Two independent categories of authentication evidence
C. A username and an email address
D. A firewall and a VPN
Correct Answer: B. Two independent categories of authentication evidence
Question 5
Which statement about a cryptographic hash is correct?
A. It is normally reversible with a public key
B. It provides a fixed-length digest and is not encryption
C. It always proves the identity of the sender
D. It replaces authorization controls
Correct Answer: B. It provides a fixed-length digest and is not encryption
Question 6
What is the primary purpose of a digital certificate?
A. To bind a public key to an identity through a trusted authority
B. To compress network packets
C. To replace all firewall rules
D. To store passwords in plaintext
Correct Answer: A. To bind a public key to an identity through a trusted authority
Question 7
Which vulnerability-management activity should follow remediation?
A. Deleting the asset inventory
B. Verifying that the weakness has been closed
C. Disabling all logging
D. Granting broader permissions
Correct Answer: B. Verifying that the weakness has been closed
Question 8
During incident response, which activity belongs primarily to containment?
A. Limiting spread by isolating a compromised host
B. Writing the original application requirements
C. Issuing certificates to all users
D. Removing all historical logs
Correct Answer: A. Limiting spread by isolating a compromised host
Question 9
Why is a VPN alone insufficient to secure remote access?
A. A VPN cannot encrypt any traffic
B. A VPN makes all users anonymous to the organization
C. A compromised endpoint or stolen credential can still misuse the tunnel
D. A VPN can operate only inside one building
Correct Answer: C. A compromised endpoint or stolen credential can still misuse the tunnel
Question 10
Which practice best reflects least privilege?
A. Giving every developer administrator rights permanently
B. Granting only the permissions required for an authorized task
C. Allowing all internal traffic by default
D. Sharing one account among a whole team
Correct Answer: B. Granting only the permissions required for an authorized task