Module 3:

Traditional Security, Business Continuity, Disaster Recovery, Risk of insider abuse, Security
baseline, Customers actions, Contract, Documentation, Recovery Time Objecåves (RTOs),
Customers responsibility, Vendor Security Process (VSP).

Introduction to Traditional Security

Traditional security, often referred to as on-premises security, focuses on protecting IT assets
within an organization's physical boundaries.

This involves securing everything from the physical data center to the applications and data
residing on servers and endpoints.

The organization has full control and responsibility over the entire security stack.

Core Principles of Traditional Security

 Perimeter Defense: Strong emphasis on firevvalls, intrusion detection/prevention

systems (IDS/IPS) at the network edge to prevent unauthorized access from the
outside.
 Layered Security (Defense-in-Depth): Implementing multiple security controls across
different layers of the IT infrastructure to create redundant defenses. If one control
fails, another provides protection.
 Physical Security: Securing the data center building, server racks, and network
equipment from unauthorized physical access.
 Security: Segmenting newvorks, implementing access controls (ACLs), VPNs, and
securing network devices.
 Host Security: Patching operating systems, configuring firewalls, antivirus, and host-
based intrusion detection on individual servers and workstations.
 Application Security: Secure coding practices, vulnerability testing, and secure
configuration of applications.
 Data Security: Encryption (at rest and in transit), access controls (permissions), and
data loss prevention (DLP).

Key Characteristics

 Full Control: The organization owns and manages all hardware, software, and
infrastructure.
 Defined Boundaries: Clear network perimeter, making it easier to define
ingress/egress points.
 Capital Expenditure (CapEx): Significant upfront investment in hardware, software
licenses, and infrastructure.
  Operational Overhead: High operational costs for maintenance, patching, monitoring,
and staffing.

Transition to Cloud Security

While the fundamental principles remain valid, their application shifts significantly in the
cloud.

The "perimeter" becomes less defined, and the Shared Responsibility Model (discussed later)
dictates who is accountable for what. Control moves from direct ownership to configuration
and management of cloud services.

Business Continuity (BC) - Ensuring Continuous Operations

Introduction to Business Continuity (BC)

Business Continuity (BC) is a proactive process of planning and preparing for potential
disruptions to ensure that critical business functions can continue operations with minimal
downtime and impact.

 It encompasses a broader scope than just IT, including people, processes, and
facilities.
 The goal is to ensure the organization's survival and resilience in the face of adverse
events.

Objectives of Business Continuity

 Minimize Downtime: Reduce the duration of service outages.

 Reduce Financial Losses: Prevent revenue loss and unplanned expenses.
 Maintain Customer Trust: Ensure consistent service delivery and reputation.
 Comply with Regulations: Meet legal and industry requirements for operational
resilience.
 o Protect Human Life and Safety: Prioritize the well-being of employees and
stakeholders.

Key Phases of a Business Continuity Plan (BCP)

A robust BCP typically involves several key stages:

Business Impact Analysis (BIA):

 Identifies critical business functions and processes.

 Determines the impact of disruptions (financial, reputational, legal).
 Establishes Recovery Time Objectives (RTOs) and Recovery Point Objectives
 (RPOs) for each critical function.

Strategy Development:
  Based on the BIA, develop strategies to restore critical functions. This might involve
alternative work locations, manual technology recovery.

Plan Development:

 Document the BCP, outlining roles, responsibilities, communication plans.

workarounds, or procedures, and

Testing and Maintenance:

 Regularly test the BCP through drills and exercises to identify gaps and ensure its
effectiveness.
 Update the plan periodically to reflect changes in the business environment or
technology.

Training and Awareness:

 Train employees on their roles in the BCP and ensure they are aware of emergency
procedures.

Business Continuity in the Cloud Context

The cloud can significantly enhance BC capabilities by offering:

 Geographic Diversity: Easily deploy resources in multiple regions/zones.

 Scalability: Rapidly scale resources up or down as needed during a crisis.
 Managed Services: Offload the burden of infrastructure management to the cloud
provider, allowing focus on core business.
 Cost Efficiency: Potentially lower costs for maintaining redundant infrastructure
compared to on-premises.

Risk of Insider Abuse

Insider abuse is a significant threat to an organization's security posture, potentially more

damaging than external attacks due to the inherent trust and access that insiders possess. In a
cloud environment, while some traditional risks are mitigated, new dimensions or
complexities can arise.

What is Insider Abuse?

• Insider abuse refers to any malicious or unintentional act by an individual who has
authorized access to an organization's systems, data, or physical premises, leading to
unauthorized disclosure, alteration, destruction, or denial of access to information or
resources.

Risk of Insider Abuse

Insider abuse is a significant threat to an organization's security posture, potentially more
damaging than external attacks due to the inherent trust and access that insiders possess. In a
cloud environment, while some traditional risks are mitigated, new dimensions or
complexities can arise.

What is Insider Abuse?

• Insider abuse refers to any malicious or unintentional act by an individual who has
authorized access to an organization's systems, data, or physical premises, leading to
unauthorized disclosure, alteration, destruction, or denial of access to information or
resources.

Types of Insiders

Insiders are not just current employees. They can include:

 Current Employees: Full-time, part-time, contractors.

 Former Employees: Individuals who retain residual access or knowledge.
 Third-Party Vendors/Contractors: Individuals or companies with privileged access
(e.g., cloud support engineers, managed service providers).
 Business Partners: Joint venture partners, suppliers, or customers with integrated
systems access.
 Privileged Users: Administrators, developers, or IT staff with elevated access rights,
posing a higher risk.

Motivations for Insider Abuse

Insider actions can be malicious or unintentional:

Malicious Intent (Deliberate):

 Financial Gain: Selling data, espionage, extortion.

 Revenge/Disgruntlement: Due to layoffs, disciplinary actions, perceived unfair
treatment.
 Ideology/Activism: Espionage for a cause, "hacktivism."
 Corporate Espionage: Stealing intellectual property for competitors.
 Intellectual Challenge: Testing security systems without malicious intent but causing
damage.

Unintentional/Negligent Actions (Accidental):

 Human Error: Misconfigurations, accidental deletion, sending data to the wrong

recipient.
 Lack of Awareness: Falling for phishing, using weak passwords, sharing credentials.
 Bypassing Security: Seeking convenience over security (e.g., using personal devices,
  unapproved software).
 Poor Training: Not understanding secure procedures or policies.

Types of Insider Abuse Actions

 Data Theft/Exfiltration: Copying, emailing, or uploading sensitive data to

unauthorized locations.
 Data Manipulation/Deletion: Modifying or destroying critical data, applications, or
configurations.
 System Sabotage: Causing denial-of-service, disrupting operations, or planting
malware.
 Misuse of Access: Accessing data or systems beyond their job responsibilities (e.g.,
snooping).
 Credential Abuse: Sharing or selling login credentials, or using stolen credentials.
 Intellectual Property Theft: Copying source code, trade secrets, customer lists.
 Circumvention of Controls: Disabling security software, firewall rules, or logging.

The NCS Insider Incident in Singapore (Kandula Nagaraju Case)

The incident involving Kandula Nagaraju, a former employee of NCS (a prominent IT

service company in Singapore), serves as a stark reminder of the risks posed by disgruntled
insiders, particularly when security protocols for offboarding are not rigorously followed.
This case highlights how a former employee, driven by anger over his termination,
systematically planned and executed a destructive act against his previous employer's IT
infrastructure, leveraging both his prior knowledge and a seemingly innocuous access point -
a friend's Wi-Fi network.

The Background: Kandula Nagaraju was a contract employee at NCS, part of a team
managing a quality assurance (QA) computer system comprising around 180 virtual servers.
His contract was terminated in October 2022 due to poor performance. Feeling "confused and
upset" by his dismissal, as he believed he had contributed well, Nagaraju developed a
malicious intent against the company.

The Act of Abuse: Crucially, despite his termination, Nagaraju's administrator login
credentials for the QA system were not immediately revoked due to a "human oversight" in
NCS's offboarding process for that specific standalone test environment. Between January
and March 2023, months after his employment ended, Nagaraju used his laptop to gain
unauthorized access to NCS's system multiple times.

A key detail in the execution of his plan was his return to Singapore in February 2023 for a
new job. While living there, he rented a room with a former NCS colleague. To mask his
activity and potentially evade detection, Nagaraju reportedly used his former colleague's Wi-
Fi network to connect to the NCS system. This tactic made it appear as if the login activity
was coming from a legitimate, active employee's network connection, thereby making
detection harder or delaying suspicion.

During these unauthorized access sessions, Nagaraju systematically wrote and tested
computer scripts designed to delete servers. In March 2023, he executed his programmed
script, deleting all 180 virtual servers in the QA system one by one. The damage, discovered
by NCS on a Monday, resulted in an estimated loss of S$917,832 (approximately
US$678,000) for recovery and remediation.

Security Baseline - Establishing the Foundation

Defining a Security Baseline

 A security baseline is a set of minimum-security controls, configurations, and best

practices that an organization establishes and enforces across its IT systems,
applications, and data.
 It represents the fundamental security posture that all components within an
environment must meet to reduce common risks and comply with basic requirements.
 It acts as a reference point or a "minimum acceptable security level" from which to
build further security layers.

Purpose and Importance of a Security Baseline

 Standardization: Ensures consistency in security configurations across diverse

systems and platforms, reducing configuration drift and security gaps.
 Risk Reduction: Mitigates common and well-understood vulnerabilities and threats by
ensuring fundamental controls are in place.
 Compliance Foundation: Provides a starting point for meeting regulatory
requirements (e.g., ISO 27001, NIST, PCl DSS) by outlining essential controls.
 Improved Efficiency: Streamlines security operations by defining repeatable and
auditable security configurations.
 Foundation for Defense-in-Depth: Serves as the first, foundational layer upon which
more advanced and adaptive security controls are built.
 Measurement and Auditing: Provides clear criteria against which security posture can
be regularly assessed and audited.

Key Components typically covered in a Security Baseline

Identity and Access Management (IAM):

 Strong password policies (complexity, length, rotation).

 Multi-Factor Authentication (MFA) requirements for all privileged accounts.
 Principle of Least Privilege (PoLP): Users and systems granted only
necessarypermissions.
 Role-Based Access Control (RBAC): Access defined by job function.
Network Security:

 Firewall rules: Explicitly deny all, then allow only necessary traffic.
 Network segmentation: Isolating sensitive systems.
 Secure remote access (VPNs, strong authentication).

Endpoint and Server Security:

 Regular patching and vulnerability management.

 Antivirus/Anti-malware deployment and regular updates.
 Host-based firewalls.
 Secure configuration of operating systems (OS hardening).

Application Security:

 Secure coding guidelines.

 Input validation to prevent common attacks (e.g., SQL injection, XSS).
 Use of Web Application Firewalls (WAFs).

Data Security:

 Encryption for data at rest and in transit.

 Data classification guidelines.
 Regular backup and recovery procedures.

Logging and Monitoring:

 Centralized logging of security events.

 Alerting for suspicious activities.
 Retention policies for logs.

Customer's Actions in Cloud Security

• In the cloud, the customer's active involvement in security is paramount, primarily driven
by the Shared Responsibility Model. While the cloud provider secures the underlying
infrastructure, the customer bears significant responsibility for what they build and store in
the cloud.

Key Areas of Customer Responsibility and Action:

Data Security and Management:

 Encrypting data at rest (e.g., using Key Management Services - KMS) and in transit
(e.g., TLS for network traffic).
 Implementing robust access controls for data storage (e.g., S3 bucket policies,
database permissions).
  Data classification: Understanding and tagging sensitive data.
 Data backup and recovery strategies, aligning with RPO/RTO.
 Data Loss Prevention (DLP) to prevent unauthorized exfiltration.
 Ensuring data residency and sovereignty requirements are met by selecting
appropriate regions.

Identity and Access Management (IAM):

 Managing user identities, groups, and roles.

 Implementing strong authentication mechanisms (MFA).
 Applying the Principle of Least Privilege (POLP) to all users and services.
 Regularly reviewing and auditing access permissions.
 Protecting root accounts or equivalent master credentials.

Network Configuration:

 Configuring virtual networks (VPCs/VNets), subnets, and netvork access control lists
(NACLs).
 Setting up security groups/firewalls to restrict traffic to necessary ports and protocols.
 Implementing secure network architecture, including segmentation and secure
gateways.
 Protecting public-facing endpoints.

Operating System, Application, and Middleware Security (for IaaS):

 Patching and updating guest operating systems.

 Installing and configuring security software (antivirus, host-based firewalls).
 Hardening operating systems and applications.
 Ensuring secure coding practices for custom applications.
 Managing vulnerabilities within applications.

Contract - The Legal Framework of Cloud Security

The contract between a cloud customer and a cloud service provider (CSP) is a critical
document that legally defines the scope of services, responsibilities, and the framework for
security and privacy. It extends beyond technical controls to establish accountability and risk
allocation.

Key Security-Related Clauses and Considerations in Cloud Contracts:

Service Level Agreements (SLAs):

 Define guaranteed levels of service availability (uptime percentages) and

performance.
  Outline responsibilities for downtime and associated penalties (e.g., service credits) if
guarantees are not met.
 While often focused on availability, implicit security measures are required to meet
availability.

Shared Responsibility Model Clarification:

Explicitly delineates the security responsibilities between the CSP and the customer for
various service models (IaaS, PaaS, SaaS). This is fundamental to avoid security gaps.

Data Ownership and Control:

 Clearly states that the customer retains ownership of their data.

 Defines how the CSP can access, process, or use customer data (typically only for
service provision, legal compliance).
 Addresses data deletion policies upon contract termination.

Data Protection and Privacy:

 Details the technical, administrative, and physical safeguards the CSP will implement
to protect customer data (e.g., encryption standards, access controls on their side).
 Addresses compliance with relevant data privacy regulations (e.g., GDPR, HIPAA,
CCPA) and the CSP's role as a data processor.
 Specifies data residency options or restrictions (where data can be stored/processed).
Often includes a Data Processing Addendum (DPA).

Security Incident Response and Notification:

 Outlines the CSP's procedures for detecting, responding to, and notifying customers
of security incidents or breaches affecting the cloud infrastructure.
 Specifies notification timelines and the information to be provided (e.g., nature of
breach, affected data).
 Defines the customer's responsibilities in responding to incidents that occur within
their own cloud configurations.

Audit Rights and Certifications:

 Customers may seek the right to audit the CSP's security controls or request third-
party audit reports (e.g., SOC 2, ISO 27001 certifications).
 These provide assurance that the CSP meets recognized security standards.

Disaster Recovery and Business Continuity:

 Describes the CSP's internal BC/DR plans for their infrastructure and services.
 Specifies how the CSP will ensure the resilience and recoverability of its core
platform.
  While the customer is responsible for their DR, the CSP's capabilities are
foundational.

Vendor Lock-in and Exit Strategy:

 Addresses provisions for data portability, migration assistance, and the process for
terminating the contract and retrieving data.
 Important to ensure the customer can transition services or data to another provider or
back on-premises without undue difficulty or cost.

Indemnification and Limitation of Liability:

 Clauses that define how financial liabilities for security breaches or service failures
are shared between the CSP and the customer.
 Crucial for understanding financial exposure in case of security incidents attributable
to either party.

Compliance and Regulatory Alignment:

 Ensures the CSP's services and their contractual terms support the customer's
industry-specific compliance requirements.
 May include specific clauses for highly regulated sectors.

Penetration Testing Policy:

Defines if and how customers are permitted to conduct penetration tests against their cloud
environments, and what permissions or notifications are required by the CSP.

Recovery Time Objectives (RTOs)

Recovery Time Objective (RTO) is a crucial metric in the realms of business continuity and
disaster recovery planning. It represents the maximum tolerable duration of time that a
business process, system, or application can be unavailable or offline after an incident or
disaster, before suffering unacceptable consequences. In simpler terms, it's the answer to the
question: "How quickly do we need this system back up and running?"

The RTO is determined during the Business Impact Analysis (BIA) phase of business
continuity planning, where the criticality of each business function and its supporting IT
systems is assessed. A shorter RTO implies a higher criticality for the system, as the business
cannot afford prolonged downtime.

 What RTO Measures: It measures the downtime or the duration of outage. For
example, an RTO of 4 hours means the system must be fully restored and operational
within four hours of a disruption occurring.
 Business Impact: The RTO is directly driven by the potential impact of an outage.
Systems supporting critical revenue-generating activities, emergency services, or legal
 obligations will typically have very short RTOs (minutes to a few hours), while less
critical systems might tolerate RTOs of several hours or even days.
 Influence on Disaster Recovery Strategy: The RTO largely dictates the choice of
disaster recovery strategy and the technology investments required.
 Near-zero RTOs often necessitate "hot site" or active-active multi-region architectures
with continuous data replication, which are the most expensive options.
 RTOs of a few hours might be achievable with "warm standby" environments or
advanced pilot light configurations. Longer RTOs (e.g., 24+ hours) could suffice with
basic "backup and restore" strategies.
 Relationship to Recovery Point Objective (RPO): While RTO focuses on the time to
recover, Recovery Point Objective (RPO) focuses on the maximum data loss
acceptable. Both are critical for a comprehensive recovery strategy, but they address
different aspects of resilience. A short RTO often requires a short RPO, as speedy
recovery is difficult without recent data.

Factors Influencing RTO:

 Cost: Shorter RTOs generally incur higher costs due to the need for more
sophisticated technologies, redundant infrastructure, and continuous replication.
 System Criticality: How essential is the system to core business operations, revenue,
or safety?
 Compliance: Regulatory requirements might mandate specific maximum downtimes.
 Reputation: The impact of prolonged downtime on customer trust and brand image.

Customer's Responsibility
In the cloud computing paradigm, understanding the Customer's Responsibility is paramount
for effective security and compliance. This responsibility is primarily defined by the Shared
Responsibility Model, which delineates the security obligations between the cloud service
provider (CSP) and the customer. The model changes based on the cloud service type:
Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service
(SaaS).

While the CSP is generally responsible for the "security of the cloud" (the underlying
infrastructure, physical security, global network, hypervisor, etc.), the customer is always
responsible for the "security in the cloud." This means the customer's actions and
configurations determine the security posture of their applications and data.

Key areas where the customer holds primary responsibility include:

Data Security and Management:

 Data Classification and Labeling: Identifying and categorizing sensitive information.

  Encryption: Implementing encryption for data at rest (e.g., using Key Management
Services - KMS) and data in transit (e.g., using TLS/SSL for all network
communications).
 Access Controls: Configuring granular permissions and policies for data access (e.g.,
S3 bucket policies, database user roles, storage account ACLs).
 Backup and Recovery: Defining and implementing appropriate backup strategies
anddisaster recovery plans for their data, ensuring RTOs and RPOs are met.
 Data Loss Prevention (DLP): Deploying tools and policies to prevent unauthorized
exfiltration of sensitive data.
 Data Residency: Ensuring data is stored in the correct geographic regions to meet
regulatory requirements.

Identity and Access Management (IAM):

 User and Group Management: Creating, managing, and de-provisioning user

identities and their access groups.
 Authentication: Enforcing strong authentication mechanisms, including Multi-Factor
Authentication (MFA) for all users, especially those with privileged access.
 Authorization: Applying the Principle of Least Privilege (POLP) and Role-Based
Access Control (RBAC) to ensure users and services only have the minimum
necessary permissions.
 Credential Management: Securely managing API keys, access tokens, and other
credentials.
 Auditing Access: Regularly reviewing and auditing user and service access
permissions for unnecessary or excessive rights.

Network and System Configuration:

 Virtual Network Configuration: Designing and configuring Virtual Private Clouds

(VPCs) or Virtual Networks (VNets), subnets, and routing tables.
 Security Group/Firewall Rules: Setting up network security groups, firewalls, and
network access control lists (NACLs) to restrict traffic to only necessary ports and IP
ranges.
 Application-Level Firewalls: Deploying Web Application Firewalls (WAFs) for
protection against common web vulnerabilities.
 Operating System and Application Hardening (IaaS): For virtual machines and
containers, patching, updating, and securely configuring the guest operating system,
applications, and middleware.
 Vulnerability Management Scanning and remediating vulnerabilities in customer-
managed applications and operating systems.

Security Monitoring and Incident Response:

  Logging and Auditing: Activating and configuring cloud logging services (e.g.,
CloudTrail, Azure Monitor, GCP Cloud Logging) to capture security events.
 Security Analytics: Centralizing and analyzing logs using Security Information and
Event Management (SIEM) systems or Cloud Native Security Posture Management
(CSPM) tools.
 Alerting: Setting up alerts for suspicious activities or security policy violations.
 Incident Response Plan: Developing and regularly testing an incident response plan
specific to cloud environments, including communication protocols with the CSP.

Vendor Security Process (VSP)

The Vendor Security Process (VSP) is an essential component of an organization's overall
risk management and security governance, particularly crucial when engaging with third-
party service providers, including cloud service providers (CSPs), software vendors, and
managed service providers. It is the systematic approach an organization takes to assess,
manage, and monitor the security risks associated with external entities that have access to its
systems, data, or processes.

The primary goal of a VSP is to ensure that third-party vendors meet the organization's
security standards and do not introduce unacceptable levels of risk into its ecosystem. For
cloud services, the VSP helps to validate the "security of the cloud" capabilities and
commitments made by the CSP.

Key phases and considerations within a robust Vendor Security Process include:

Vendor Selection and Initial Due Diligence:

 Risk Classification: Categorizing vendors based on the criticality of the services they
provide and the sensitivity of the data they will access (e.g., high-risk for cloud
providers handling sensitive customer data).
 Initial Assessment: Conducting preliminary security assessments, requesting security
questionnaires (e.g., CAIQ, SIC), and reviewing publicly available security reports
and certifications (e.g., SOC 2 Type II, ISO 27001, FedRAMP).
 Security Requirements: Defining clear security requirements that prospective vendors
must meet, aligned with the organization's policies and compliance obligations.

Contract Negotiation and Agreement:

 Service Level Agreements (SLAs): Ensuring that security commitments, availability

guarantees, incident notification timelines, and data protection clauses are explicitly
defined and legally binding.
 Data Processing Addendum (DPA): For vendors processing personal data, ensuring
compliance with privacy regulations like GDPR, CCPA, etc.
  Audit Rights: Negotiating rights to audit the vendor's security controls, or relying on
third-party audit reports from the vendor.
 Indemnifiation and Liability: Clarifying liability in case of security incidents or data
breaches.

Ongoing Monitoring and Management:

 Continuous Assessment: Periodically re-evaluating vendor security posture, especially

for high-risk vendors, to ensure ongoing compliance with contractual obligations and
evolving threat landscapes.
 Performance Monitoring: Monitoring vendor performance against agreed-upon
security SLAs.
 Vulnerability Management: Understanding the vendor's vulnerability management
processes and how they address newly discovered vulnerabilities.
 Incident Response Coordination: Establishing clear communication channels and
protocols for joint incident response in case of security breaches affecting shared
systems or data.
 Relationship Management: Regular security review meetings with the vendor to
discuss performance, concerns, and improvements.

Exit Strategy and Termination:

 Data Portability and Deletion: Defining clear processes for data retrieval and secure
deletion of customer data upon contract termination.
 Access Revocation: Ensuring all vendor access to organizational systems and data is
promptly and securely revoked.