STRATEGY

DOCUMENT FOR
SOC SETUP AS AN
MSSP (MANAGED
SECURITY
SERVICE
PROVIDER)

BY IZZMIER IZZUDDIN
PHASE 1: PLANNING AND DESIGN

Planning and design are the foundational phases of setting up an MSSP SOC. This phase
ensures the SOC is aligned with client requirements, regulatory obligations and the
organisation’s long-term vision. Below is an elaboration on each key aspect:

Objective Definition

Defining the Scope of Services

• What to do: Identify the exact security services the SOC will offer and how they will
address client pain points.
• Why it matters: A clearly defined scope ensures no overlap or gaps in service
delivery, optimising resource allocation and meeting client expectations.
• Examples:
o Retail Client: Requires 24/7 log monitoring to ensure detection of malware
and fraud attempts, especially during peak shopping seasons.
o Healthcare Client: Needs compliance-focused reporting (HIPAA), such as
monitoring access to sensitive patient data and detecting unusual activities
in Electronic Medical Records (EMR) systems.
o Financial Client: Demands real-time threat intelligence and incident
response to mitigate risks like ransomware attacks or insider threats.

Stakeholder Involvement

Engaging with Clients to Identify Needs

• What to do: Collaborate with key stakeholders (CISOs, IT managers and auditors)
from potential client organisations to understand their unique requirements.
• Why it matters: Each client has specific business models, compliance regulations
and threat landscapes that influence their security needs.
• How to Execute:
1. Workshops:
§ Conduct workshops to map out client networks, identify critical
assets and understand business priorities.
§ Example: A bank prioritises transaction logs and payment gateway
security, while a government agency focuses on classified
document protection.
2. Surveys and Assessments:
§ Distribute questionnaires to gather information on current security
setups and pain points.
§ Example: A client reports that their legacy firewall cannot handle
advanced persistent threats (APTs), signalling the need for an
upgrade.
 3. Baseline Reporting:
§ Provide a baseline risk assessment report.
§ Example: A telecom client discovers that they lack proper DNS traffic
monitoring, leading to DNS tunnelling vulnerabilities.

Service Portfolio

Designing Services to Match Client Needs

• Core Services:
o Incident Detection: Continuous monitoring and alerting.
o Triaging: Initial analysis of incidents to determine severity.
o Reporting: Providing actionable insights to clients.
• Value-Added Services:
o Threat Hunting: Proactively searching for hidden threats.
o Vulnerability Management: Scanning and patching vulnerabilities.
o Compliance Reporting: Generating reports aligned with regulatory
frameworks.
• Examples:
o Basic Tier: Log monitoring for SMBs with limited budgets.
o Advanced Tier: Threat correlation and incident investigation for medium-
sised businesses.
o Premium Tier: 24/7 incident response with a dedicated account manager for
large enterprises.

Implementation Tip:

• Include flexibility in your service tiers to allow clients to scale up as their needs
grow. For instance, a client may start with the Basic Tier and later subscribe to
threat hunting as they expand their operations.

Technology Stack Selection

Choosing the Right Tools for Operations

• What to do: Select technologies that meet the technical and operational
requirements of an MSSP SOC.
• Why it matters: The right tools ensure effective detection, investigation and
response while maintaining efficiency and scalability.
• Examples:
1. SIEM Tools:
§ Splunk: Suitable for large-scale deployments requiring advanced
analytics.
§ IBM QRadar: Known for its integrated threat intelligence.
 §Azure Sentinel: Ideal for clients already using Microsoft’s ecosystem.
§Example: Deploy Splunk for a retail client requiring detailed
transaction log analysis and QRadar for a manufacturing client
monitoring IoT devices.
2. Endpoint Protection:
§ CrowdStrike Falcon: Known for its cloud-native EDR capabilities.
§ SentinelOne: Offers autonomous response capabilities.
§ Example: Use CrowdStrike to protect endpoints for a financial client
requiring advanced behavioural analysis.
3. SOAR Tools:
§ Palo Alto Cortex XSOAR: Automates workflows and integrates with
existing tools.
§ Example: Automate phishing email response for a client by integrating
XSOAR with email gateways.

Key Considerations:

• Opt for multi-tenant tools that can manage multiple client environments
seamlessly.
• Example: Use QRadar’s multi-tenancy feature to segregate client data while
reducing hardware costs.

Compliance Alignment

Ensuring Services Meet Regulatory Requirements

• What to do: Align SOC operations and reporting capabilities with relevant
compliance frameworks to meet client obligations.
• Why it matters: Many clients, especially in regulated industries like healthcare or
finance, have mandatory compliance requirements.
• Examples:
o ISO 27001:
§ Implement security controls and document processes.
§ Example: Design a client-specific Information Security Management
System (ISMS) to comply with ISO 27001 standards.
o GDPR:
§ Ensure log monitoring includes user access to personal data.
§ Example: Create GDPR-compliant reports showing access trends to
sensitive customer records for an e-commerce client.
o PCI DSS:
§ Monitor payment card data and ensure secure transmission.
§ Example: Provide real-time alerting on unauthorised attempts to
access cardholder data for a retail client.
• Implementation Tip:
 o Configure the SIEM to generate audit-ready reports based on compliance
templates.
o Example: Use Splunk to automate HIPAA reporting for a healthcare client,
detailing access logs and unusual activities.

Additional Example: Client-Specific Scenario

Scenario: Onboarding a Healthcare Client

• Objective: Ensure compliance with HIPAA while enhancing overall security.

• Steps:
1. Initial Workshop:
§ Understand critical assets like patient records stored in EMR
systems.
§ Identify key challenges, such as limited endpoint visibility.
2. Technology Selection:
§ Deploy Splunk for log aggregation and analysis.
§ Use CrowdStrike for EDR to monitor endpoints handling patient data.
3. Compliance Reporting:
§ Configure reports to detail who accessed patient records and when.
4. Service Customisation:
§ Add periodic vulnerability assessments and threat intelligence to
address emerging risks like ransomware.
PHASE 2: INFRASTRUCTURE SETUP

The infrastructure setup phase is critical to ensuring the SOC operates efficiently, securely
and at scale. This phase involves setting up both physical and cloud infrastructure,
ensuring secure connectivity with client networks and implementing robust data
segmentation to maintain client confidentiality.

1. Physical and Cloud Infrastructure

On-Premises SOC

An on-premises SOC is ideal for organisations that require complete control over their
infrastructure, such as government agencies or financial institutions.

• Key Components:
o Secure Facility:
§ Design a physically secure SOC with redundancy in power, cooling
and network connectivity.
§ Example: Use uninterruptible power supplies (UPS), diesel
generators and backup air conditioning to prevent downtime during
outages.
o Workstations:
§ Equip analysts with multiple monitors and ergonomic setups for
extended work hours.
o Network Architecture:
§ Implement firewalls, VLANs and intrusion detection systems (IDS) to
segment internal SOC traffic and prevent lateral movement in case of
compromise.
• Use Case Example:
o A banking client requiring strict compliance with local data residency laws
mandates an on-premises SOC. The SOC is equipped with biometric access
controls, CCTV monitoring and an isolated server room to store sensitive
transaction logs.

Cloud SOC

Cloud-based SOCs are cost-effective, scalable and flexible, making them ideal for MSSPs
managing multiple clients with varying needs.

• Key Components:
o Cloud Platforms: Leverage platforms like AWS, Azure and Google Cloud for
scalability and elasticity.
§ Example: Use AWS S3 for centralised log storage and AWS
Lambda for real-time log processing and alerting.
 o Disaster Recovery:
§ Configure automatic backups and geo-redundant storage to ensure
high availability.
§ Example: Use Azure's Zone Redundant Storage (ZRS) for replicating
logs across data centers.
o Hybrid Approach:
§ Combine on-premises and cloud setups for clients with both critical
systems and remote users.
§ Example: Deploy a cloud SIEM for monitoring remote employees and
an on-premises SIEM for internal systems.

Comparison Example

• Small Business Client: A retail client opts for a cloud-based SOC on AWS due to
lower costs and scalability needs. AWS services like CloudTrail and GuardDuty are
used for log collection and threat detection.
• Enterprise Client: A healthcare provider requires an on-premises SOC due to
HIPAA compliance and sensitivity of patient data.

2. Connectivity

Establishing secure and reliable connectivity between the SOC and client networks is
essential for real-time monitoring and response.

Secure VPNs

• Use VPN tunnels to securely connect client networks to the SOC, ensuring
encrypted transmission of logs and alerts.
• Implementation Example:
o Deploy IPsec VPN tunnels between client firewalls and SOC systems.
o Example: A retail client connects their POS systems to the SOC using an
IPsec VPN for real-time fraud monitoring.

Private Circuits

• For high-security environments, use private circuits like MPLS or SD-WAN.

• Implementation Example:
o A healthcare client uses an MPLS circuit to securely transmit patient record
access logs to the SOC, ensuring HIPAA compliance.

Cloud Connectivity

• Integrate client environments with the cloud SOC using secure APIs or cloud-native
connectivity solutions.
 • Example:
o An e-commerce client integrates their AWS environment with the SOC
via AWS PrivateLink, ensuring secure log transmission.

3. Data Segmentation

Multi-client environments require strict data segmentation to prevent data leakage and
maintain confidentiality.

Tenant Isolation

• Use logical and physical segregation techniques to ensure client data is isolated.
• Logical Isolation:
o Configure tenant-specific identifiers in multi-tenant platforms.
o Example: Use Splunk’s indexer clustering to maintain separate data
buckets for each client.
• Physical Isolation:
o Deploy separate SIEM instances or data stores for high-risk clients.
o Example: A government client demands a dedicated SIEM instance with no
shared resources.

Role-Based Access Control (RBAC)

• Restrict SOC analyst access to client data based on roles and responsibilities.
• Example: Only Level 3 analysts can access logs from a financial client due to data
sensitivity.

Encryption

• Encrypt client data both in transit and at rest to prevent interception.

• Example: Use TLS 1.2 or higher for data in transit and AES-256 for log storage.

Simulation Example

Scenario: Setting up secure connectivity and segmentation for a multi-tenant MSSP SOC.

1. Client A (Healthcare):
o Requirement: Secure transmission of logs with full data isolation.
o Solution:
§ Deploy a dedicated SIEM instance on-premises for compliance.
§ Use a private MPLS circuit for log transmission.
§ Configure Splunk to send alerts directly to the client’s compliance
team.
2. Client B (E-Commerce):
 o Requirement: Cost-effective monitoring of cloud assets.
o Solution:
§ Use AWS as the SOC infrastructure.
§ Enable log collection using AWS CloudWatch and forward to a multi-
tenant SIEM.
§ Enforce tenant isolation through logical segmentation in the SIEM.
3. SOC Team:
o Analysts have access only to their assigned client dashboards via RBAC.
o Incident playbooks are customised per client’s requirements, ensuring
response consistency and client-specific context.
PHASE 3: OPERATIONAL SETUP

Operational setup is the backbone of a successful SOC. It involves establishing well-

defined teams, creating actionable runbooks and playbooks and setting up robust
monitoring and dashboards to ensure smooth day-to-day operations. Below is an in-depth
elaboration of the phase.

1. People and Teams

A well-structured team is critical for handling various aspects of SOC operations. Divide
personnel into tiers to improve efficiency and response times:

Tier 1 (L1): Initial Triage

• Role:
o Monitor alerts generated by the SIEM or other detection tools.
o Perform basic triage, including identifying false positives and categorising
legitimate alerts.
• Skills:
oBasic cybersecurity knowledge.
oFamiliarity with SIEM platforms and common attack patterns.
• Example:
o A Tier 1 (L1) analyst reviews an alert for suspicious outbound traffic and
categorises it as "Low Severity" after validating it as an expected business
operation.

Tier 1 (L2): Advanced Investigation

• Role:
o Deep-dive investigation into escalated alerts from Tier 1 (L1).
o Analyse logs, correlate events and assess potential security breaches.
• Skills:
oExpertise in log analysis, malware analysis and intrusion detection.
oHands-on experience with tools like Splunk, Wireshark and Kibana.
• Example:
o An analyst receives an escalated alert for unusual file uploads to an external
server. They trace the source IP to a compromised internal machine and
escalate it to Tier 1 (L3).

Tier 1 (L3): Incident Responders and Threat Hunters

• Role:
o Manage confirmed incidents and oversee containment, eradication and
recovery processes.
 o Proactively hunt for threats within client environments.
• Skills:
o Advanced certifications (e.g., GCIH, OSCP and CISSP).
o Knowledge of incident response frameworks such as NIST or MITRE
ATT&CK.
• Example:
o A ransomware outbreak occurs. Tier 1 (L3) responders isolate affected
systems, initiate forensic analysis and coordinate with clients to restore
operations.

Team Simulation Example

• Scenario: A multi-tenant MSSP SOC handling alerts for healthcare, retail and
banking clients.
o Tier 1 (L1) Analyst: Flags a suspicious login from an unapproved country for
a retail client.
o Tier 1 (L2) Analyst: Correlates logs across endpoints and identifies
credential theft using a phishing campaign.
o Tier 1 (L3) Analyst: Contains the breach by revoking access and investigates
the phishing domain’s hosting provider.

2. Runbooks and Playbooks

Developing standardised procedures ensures consistent and efficient responses to

common threats.

Runbooks

• Purpose:
o High-level guidance for handling specific incidents, tailored to client
environments.
• Example:
o A Runbook for Malware Detection includes:
§ Steps to isolate the affected host.
§ Notify relevant stakeholders.
§ Submit malware samples for analysis in a sandbox.
§ Generate and share a report with the client.

Playbooks

• Purpose:
o Detailed, step-by-step procedures for responding to specific threats.
• Key Playbooks:
1. Phishing Response:
 § Validate the suspicious email headers.
§ Analyse links and attachments in a sandbox.
§ Add malicious domains to the client’s blocklist.
§ Notify users to avoid interacting with the email.
2. Ransomware Response:
§ Disconnect affected systems from the network.
§ Investigate the attack vector (e.g., phishing, RDP exploitation).
§ Engage backups and restore operations if possible.
3. Threat Hunting Playbook:
§ Analyse network traffic for anomalies.
§ Use threat intelligence feeds to correlate suspicious IPs or domains.
§ Investigate endpoints for unusual behaviour.

Example of Playbook in Action:

• Scenario: A phishing email targets a healthcare client.

o The Tier 1 (L1) analyst identifies the phishing email and escalates it.
o The Tier 1 (L2) analyst uses the phishing playbook to:
§ Identify the phishing site.
§ Report it to the hosting provider.
§ Block the domain in the client’s email gateway.

3. Monitoring and Dashboards

Centralised monitoring and insightful dashboards are essential for situational awareness
and decision-making.

Centralised Monitoring

• Leverage a SIEM platform to aggregate logs, correlate events and generate alerts.
• Configure log ingestion from various sources:
o Firewalls, IDS/IPS, endpoint agents, cloud platforms and application logs.
• Example:
o A retail client’s POS systems send logs to the SOC SIEM. Analysts configure
rules to detect unusual purchases or bulk transaction attempts.

Dashboards

• Create tailored dashboards for each client to provide actionable insights.

• Examples of Metrics to Track:
o Number of alerts generated vs. resolved.
o Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR).
o Number of false positives.
• Example Dashboard Use Cases:
 1. Healthcare Client Dashboard:
§ Highlight HIPAA compliance metrics, such as unauthorised access
attempts and successful logins by role.
2. Retail Client Dashboard:
§ Show payment fraud metrics, including flagged transactions and
geolocation anomalies.
3. Banking Client Dashboard:
§ Display wire transfer anomalies, failed login attempts and malicious
insider activities.

Simulation Example

Scenario: A SOC is managing a ransomware outbreak for a healthcare client.

1. Monitoring:
o SIEM alerts the Tier 1 (L1) team about suspicious file encryption activity
across endpoints.
o The Tier 1 (L1) analyst escalates the alert after confirming it as ransomware.
2. Response Using Runbook and Playbook:
o The Tier 1 (L2) analyst follows the ransomware playbook:
§ Disconnects affected systems.
§ Analyses logs to trace the infection source.
§ Identifies phishing as the attack vector.
o The Tier 1 (L3) analyst:
§ Engages threat hunters to check for additional signs of compromise.
§ Restores affected systems from backups.
§ Provides a detailed post-incident report.
3. Dashboard Insights:
o The client-specific dashboard displays:
§ Total systems affected.
§ MTTR for the incident.
§ Recommendations for improved defences (e.g., anti-phishing
training, endpoint security enhancements).
PHASE 3: OPERATIONAL SETUP

Operational setup focuses on the people, processes and technologies that form the
backbone of a SOC. This phase ensures that the SOC operates efficiently, delivering
consistent and high-quality services to clients.

1. People and Teams

The SOC team is typically divided into three tiers, each with distinct roles, skills and
responsibilities.

Tier 1 (L1): Analysts Handling Initial Triage

• Role:
o Monitor and triage alerts generated by security tools.
o Identify false positives and categorise legitimate alerts.
o Escalate complex cases to Tier 1 (L2) for deeper investigation.
• Certifications:
o CompTIA Security+, Certified Ethical Hacker (CEH) and equivalent.
• Daily Tasks:
o Monitor SIEM dashboards for high-severity alerts.
o Acknowledge and prioritise incidents based on client SLAs.
o Apply basic investigation methods, such as IP reputation checks and log
searches.
• Example:
o An alert for a brute-force login attempt is flagged. The Tier 1 (L1) analyst
identifies it as an automated script attack and blocks the source IP.

Tier 1 (L2): Analysts Investigating Escalated Alerts

• Role:
o Perform detailed investigations into escalated incidents.
o Correlate data across multiple sources to determine the scope and impact
of threats.
o Provide recommendations to mitigate risks.
• Certifications:
o GIAC Certified Incident Handler (GCIH), Certified SOC Analyst (CSA).
• Daily Tasks:
o Analyse escalated phishing emails using sandbox environments.
o Perform root cause analysis of a malware outbreak.
o Identify patterns from logs to detect lateral movement in a network.
• Example:
 o A Tier 1 (L1) analyst escalates an alert for suspicious data exfiltration. The
Tier 1 (L2) analyst identifies the compromised system and traces the
attacker’s lateral movement using network logs.

Tier 1 (L3): Incident Responders and Threat Hunters

• Role:
o Handle confirmed security incidents, including containment, eradication
and recovery.
o Hunt for unknown or advanced threats proactively.
o Collaborate with clients to improve security postures.
• Certifications:
o Certified Information Systems Security Professional (CISSP), Offensive
Security Certified Professional (OSCP).
• Daily Tasks:
o Respond to and mitigate ransomware attacks.
o Conduct forensic analysis on compromised endpoints.
o Develop and implement custom detection rules in the SIEM.
• Example:
o A Tier 1 (L3) analyst detects a previously unknown malware variant during a
threat hunt. They create a custom YARA rule and deploy it across the client’s
network to prevent further infections.

2. Runbooks and Playbooks

Runbooks

Runbooks provide high-level operational guidance for handling specific types of incidents
or processes. They ensure analysts follow consistent steps.

• Example: Runbook for Malware Detection:

o Step 1: Validate the alert by analysing hashes using tools like VirusTotal.
o Step 2: Quarantine affected systems using endpoint protection tools.
o Step 3: Notify the client with initial findings and recommendations.

Playbooks

Playbooks are more detailed, step-by-step guides for responding to specific threats. They
include pre-defined actions, escalation paths and expected outcomes.

• Key Playbooks:
1. Phishing Playbook:
§ Validate the email headers and identify anomalies (e.g., spoofed
domains).
 § Extract URLs and analyse them in a sandbox.
§ Notify users of phishing attempts and educate them on identifying
similar threats.
2. Ransomware Playbook:
§ Isolate the infected systems.
§ Identify the ransomware family and assess the encryption scope.
§ Restore affected systems using backups and harden endpoints to
prevent recurrence.
3. Threat Hunting Playbook:
§ Review unusual user behaviour or traffic patterns.
§ Correlate with threat intelligence feeds to identify potential threats.
§ Create custom detection rules for recurring patterns.

3. Monitoring and Dashboards

Monitoring and dashboards are critical for real-time situational awareness, enabling faster
detection and response.

Centralised Monitoring

• Utilise a SIEM platform to collect and correlate logs from:

o Firewalls, IDS/IPS, EDR, email gateways, cloud services and more.
• Ensure logs are ingested and normalised to facilitate effective analysis.
• Configure rules for detecting client-specific threats (e.g., PCI DSS-related
anomalies for a payment processor client).

Dashboards

Dashboards provide visual representation of key metrics and serve as a communication

tool with clients.

• Design Elements:
o Real-time alerts and open incident status.
o Client-specific KPIs such as MTTD (Mean Time to Detect) and MTTR (Mean
Time to Respond).
o Trending metrics like top attack types or frequently targeted assets.
• Examples:
1. Healthcare Client Dashboard:
§ HIPAA compliance metrics, including unauthorised data access
attempts.
§ Number of blocked phishing emails targeting healthcare staff.
2. Retail Client Dashboard:
§ Suspicious POS system activities and fraud detection alerts.
§ Anomalous transactions flagged and blocked.
 3. Banking Client Dashboard:
§ Wire transfer fraud alerts and geolocation anomalies.
§ Unusual login attempts on high-privilege accounts.

Simulation Example

Scenario: Simulating a Phishing Attack Response in a SOC.

1. Monitoring:
o A Tier 1 (L1) analyst identifies a high-priority alert in the SIEM: "Suspicious
Email Detected."
o Initial analysis reveals the email contains a URL flagged by a threat
intelligence feed.
2. Runbook Execution:
o The analyst isolates the suspicious email and performs header analysis.
o They escalate the alert to Tier 1 (L2) for deeper investigation.
3. Playbook Execution:
o The Tier 1 (L2) analyst uses the Phishing Playbook:
§ Extracts and tests the URL in a sandbox environment.
§ Confirms the URL is part of a credential harvesting campaign.
o Escalates the incident to Tier 1 (L3) for response coordination.
4. Incident Resolution:
o The Tier 1 (L3) analyst:
§ Blocks the phishing domain across all client firewalls.
§ Informs affected users and provides training material to prevent
future incidents.
§ Submits phishing indicators to threat intelligence platforms to aid
community defence.
5. Dashboard Metrics:
o Post-incident, the SOC dashboard reflects:
§ Incident timeline (detection, escalation, resolution).
§ Total users targeted by the phishing email.
§ Recommendations for improving email gateway rules.
PHASE 4: CLIENT ONBOARDING

The client onboarding phase ensures seamless integration of the client’s infrastructure
into the MSSP's SOC environment while aligning with their specific needs and compliance
requirements. It lays the foundation for delivering tailored security services.

1. Requirement Gathering

Objective:

Understand the client’s operational environment, critical assets and compliance

obligations to align SOC services with their security requirements.

• Steps:
1. Stakeholder Engagement:
§ Conduct workshops or meetings with key stakeholders such as IT
managers, compliance officers and CISOs.
2. Asset Inventory:
§ Identify the client’s critical systems, databases and applications.
3. Compliance Analysis:
§ Determine applicable standards and regulations (e.g., PCI DSS for
financial institutions, HIPAA for healthcare clients).
4. Threat Landscape Review:
§ Assess common threats to the client’s industry and location.
• Example:
o For a financial institution:
§ Critical Assets: Payment processing systems, ATM networks, online
banking portals.
§ Compliance: PCI DSS for cardholder data protection.
§ Threats: Credential theft, ransomware, DDoS attacks targeting
banking services.

2. Integration and Configuration

Objective:

Seamlessly connect the client’s infrastructure to the SOC environment, ensuring log
collection and quality assurance.

• Steps:
1. Log Source Integration:
§ Identify log sources (e.g., firewalls, endpoints, cloud services,
databases).
 § Configure the client’s systems to send logs to the MSSP’s SIEM
platform via secure channels (e.g., VPN, MPLS).
2. Validation:
§ Verify the completeness and accuracy of logs.
§ Check for log format compatibility with the SIEM.
3. Customisation:
§ Create client-specific dashboards, alert rules and report templates.
• Example:
o For a medium-sized enterprise:
§ Integration: Connect Office 365, endpoint detection tools (e.g.,
CrowdStrike) and firewalls (e.g., Palo Alto) to the SIEM.
§ Validation: Ensure Office 365 logs capture events such as login
anomalies and email forwarding rule changes.
§ Customisation: Configure a dashboard to display user login trends
and flagged phishing emails.

3. Baseline and Tuning

Objective:

Establish a baseline of normal behaviour for the client’s environment and fine-tune alerts
to reduce noise and increase accuracy.

• Steps:
1. Baseline Establishment:
§ Analyse the client’s historical logs (if available) to understand normal
activity patterns.
§ Use statistical methods to define thresholds for common metrics
(e.g., logon attempts per user).
2. Alert Tuning:
§ Suppress false positives caused by legitimate activities.
§ Refine alert thresholds to focus on high-confidence threats.
3. Testing:
§ Simulate attacks to test alert efficacy and ensure detection
mechanisms are functioning correctly.
• Example:
o Scenario: The client’s backup system runs nightly, accessing critical
databases.
§ Initial Alert: "Unauthorised Access to Critical Database."
§ Tuning Action: Suppress alerts triggered by the backup system’s
scheduled activity.
§ Testing: Perform a test run of the backup to confirm the rule
suppresses only these legitimate activities.
Simulation Example: End-to-End Client Onboarding

1. Requirement Gathering:
o A healthcare client requires monitoring for unauthorised access to patient
records and compliance with HIPAA.
o Critical assets include an electronic medical record (EMR) system and a
cloud-based patient portal.
2. Integration and Configuration:
o The MSSP configures the client’s EMR logs to send data to the SIEM over a
secure VPN.
o Log validation reveals that the EMR system logs user IDs but not the source
IPs. The MSSP recommends enabling IP logging for better traceability.
3. Baseline and Tuning:
o The MSSP establishes a baseline of user access patterns to the EMR system.
o Analysts identify that doctors frequently access patient records between 8
AM and 6 PM, while after-hours access is rare.
o A rule is created to alert only for after-hours access that includes IPs from
outside the organisation.
4. Testing and Handoff:
o The MSSP simulates unauthorised after-hours access to verify the alert
triggers correctly.
o The client reviews and approves the configuration and the MSSP transitions
the environment into active monitoring.

Deliverables

1. Requirement Document:
o Includes client-specific needs, identified threats and compliance
obligations.
2. Integration Report:
o Lists all configured log sources, validation results and any customisations
made.
3. Baseline Report:
o Details normal operational patterns and corresponding thresholds.
4. Tuning Report:
o Summarises adjustments made to alerting rules and any suppressed false
positives.
PHASE 5: OPERATIONS

The Operations phase is where the MSSP provides active security monitoring, incident
response and proactive threat intelligence to protect clients from cyber threats. This phase
ensures continuous vigilance and rapid response to security incidents.

1. 24/7 Monitoring

Objective:

Provide uninterrupted security monitoring to detect and respond to threats in real-time,

regardless of time zones or client business hours.

• Key Actions:
1. Shift Management:
§ Implement a "follow-the-sun" model with geographically distributed
teams to ensure seamless coverage.
§ Use automated alerting systems to reduce analyst fatigue and ensure
no incident goes unnoticed.
2. Alert Management:
§ Tier 1 (L1) analysts review SIEM alerts, triage incidents and escalate
only confirmed threats.
§ Use automated workflows in SOAR platforms to streamline alert
triage.
• Example:
o Scenario: A retail client in the US operates during business hours, while the
MSSP’s SOC is in Malaysia.
§ During US business hours, Tier 1 (L1) analysts monitor and triage
alerts for activities like suspicious logins or credit card fraud.
§ After-hours monitoring is outsourced or handled by the MSSP’s Tier 1
(L2) team, which investigates escalations.
• Simulation:
o Generate a simulated alert in the SIEM for "unusual login activity from
Russia."
§ Tier 1 (L1) Analyst Action: Reviews logs, confirms the activity is
unauthorised and escalates.
§ Tier 1 (L2) Analyst Action: Investigates further, determines the
compromise vector and drafts a containment recommendation.

2. Incident Response

Objective:
Deliver a structured and swift response to mitigate the impact of security incidents while
maintaining clear communication with the client.

• Key Actions:
1. Communication Protocol:
§ Assign a single point of contact (POC) for each client.
§ Use standardised incident reporting templates to provide updates.
2. Containment and Mitigation:
§ Isolate infected systems to prevent lateral movement.
§ Apply temporary controls like blocking malicious IPs or disabling
compromised accounts.
3. Recovery and Reporting:
§ Assist clients in recovering operations (e.g., restoring from backups).
§ Provide a post-incident report detailing the root cause, impact and
preventive measures.
• Example:
o Scenario: A ransomware attack encrypts a healthcare client’s patient
records.
§ Containment: MSSP isolates the affected systems and blocks
access to the Command and Control (C2) server.
§ Notification: The client’s incident response team is informed via a
pre-agreed escalation matrix.
§ Recovery: The MSSP assists the client in restoring files from offline
backups and recommends deploying endpoint protection to prevent
recurrence.
• Simulation:
o Simulated Incident: A phishing email delivers ransomware to a client’s HR
system.
§ Initial Alert: "Suspicious file download by HR workstation."
§ Tier 1 (L1): Confirms malicious activity and escalates.
§ Tier 1 (L2): Analyses the file hash, identifies ransomware and
recommends blocking the associated IP and isolating the infected
workstation.
§ Tier 1 (L3): Provides recovery steps, including restoring affected data
from backups.

3. Threat Intelligence

Objective:

Proactively monitor and analyse emerging threats to help clients stay ahead of potential
vulnerabilities and attacks.

• Key Actions:
 1. Threat Intelligence Feeds:
§ Use reputable feeds like Recorded Future, VirusTotal and
ThreatConnect to gather actionable intelligence.
§ Integrate these feeds with the SIEM to automate threat correlation.
2. Vulnerability Management:
§ Cross-reference client assets with newly discovered vulnerabilities
(CVEs).
§ Notify clients of relevant vulnerabilities and recommend mitigation
actions.
3. Threat Sharing:
§ Participate in Information Sharing and Analysis Centers (ISACs) for
industry-specific insights.
§ Share anonymised threat data with clients to improve their
understanding.
• Example:
o Scenario: A new vulnerability (CVE-2024-XXXXX) is reported in a widely used
VPN product.
§ Threat Identification: The MSSP’s intelligence team identifies that
two clients use the affected VPN.
§ Action: Analysts notify the clients, provide a risk assessment and
recommend immediate patching.
§ Follow-Up: Monitor for exploit attempts targeting the vulnerability in
client environments.
• Simulation:
o Threat Detection:
§ Inject fake threat data into the SIEM (e.g., a hash from a known
malware sample).
§ Analysts use VirusTotal to confirm the hash matches a ransomware
variant.
§ Correlate this data with client logs to determine if the malware is
present in the environment.

4. Metrics and Reporting

Objective:

Measure and demonstrate the effectiveness of SOC operations to clients through regular
reporting.

• Key Actions:
1. Key Performance Indicators (KPIs):
§ Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR).
§ Number of incidents resolved without escalation.
 § Client-specific metrics like failed login attempts or blocked phishing
attempts.
2. Client Reports:
§ Weekly and monthly reports with insights into detected threats,
trends and recommendations.
§ Post-incident reports with detailed analysis and preventive measures.
• Example:
o A monthly report for a financial client includes:
§ Number of phishing attempts blocked.
§ Trends in credential-stuffing attacks.
§ Recommendations for improving email security policies.
• Simulation:
o Generate a dashboard in the SIEM showing:
§ Alerts processed per client.
§ Top 10 blocked IPs or domains.
§ Heatmap of threats by time of day.

Deliverables

1. Operational Handbook:
o Includes shift schedules, incident response processes and escalation
matrices.
2. Incident Reports:
o Real-time and post-incident documentation with detailed findings.
3. Threat Intelligence Briefs:
o Regular updates on emerging threats and client-specific recommendations.
4. Performance Dashboards:
o Real-time and historical metrics demonstrating SOC efficiency.
PHASE 6: CONTINUOUS IMPROVEMENT

The Continuous Improvement phase is essential for ensuring that the MSSP remains
adaptive to evolving threats, enhances its operational efficiency and maintains a high level
of client satisfaction. This phase focuses on refining processes, upgrading technologies
and continuously enhancing the overall service offering.

1. Metrics and Reporting

Objective:

Track, measure and analyse operational metrics to identify areas for improvement,
optimise response times and ensure the effectiveness of security measures.

• Key Actions:
1. Measure Key Performance Indicators (KPIs):
§ Mean Time to Detect (MTTD): Time taken to identify an active threat
or incident.
§ Mean Time to Respond (MTTR): Time taken to mitigate the threat
after detection.
§ Incident Volume: Track the number of incidents detected, classified
by severity (low, medium, high).
§ False Positive Rate: Percentage of alerts that are determined to be
non-malicious after investigation.
2. Trend Analysis:
§ Identify patterns in alert volumes (e.g., spikes during holidays or
specific attack campaigns).
§ Assess trends in incident response times to identify bottlenecks or
delays.
3. Report Delivery:
§ Provide clients with periodic reports (weekly, monthly and quarterly)
to keep them informed of security posture and response metrics.
• Example:
o Scenario: Monthly reports for a healthcare client show:
§ MTTD has decreased by 15% due to improved log collection and alert
correlation.
§ MTTR has increased slightly during incidents with ransomware,
suggesting a need for better containment procedures.
§ Trend analysis reveals a 20% increase in phishing attacks, leading to a
recommendation for stronger email filtering and user awareness
training.
• Simulation:
o MTTD & MTTR Data Collection: Automatically collect and display data from
the SIEM and incident management system.
 § An alert is raised for a potential insider threat and MTTD is tracked
from detection to initial investigation.
§ Incident response times are measured from the point of detection
until containment and resolution.
• Improvements:
o If MTTR is high, the MSSP might find that response delays are due to a lack of
automated playbooks for containment or miscommunication between
teams, prompting an update to internal processes.

2. Client Feedback

Objective:

Maintain strong communication with clients to understand their satisfaction levels,

identify areas for improvement and ensure that the MSSP's services meet their evolving
needs.

• Key Actions:
1. Regular Check-ins:
§ Schedule quarterly or bi-annual review meetings to gather client
feedback on service performance.
§ Ensure a feedback loop is in place to continuously improve based on
client needs.
2. Client Satisfaction Surveys:
§ Collect structured feedback from clients to assess satisfaction with
the MSSP’s services (e.g., incident handling, communication quality,
reporting).
§ Use Net Promoter Score (NPS) or Customer Satisfaction Score (CSAT)
for quantitative measurement.
3. Actionable Insights:
§ Use client feedback to refine existing processes, improve reporting
capabilities and adapt to specific security requirements.
• Example:
o Scenario: A client in the finance sector requests more visibility into SOC
activities, including real-time alerts and deeper insights into ongoing
investigations.
§ Response: The MSSP sets up additional dashboards with advanced
filtering options to allow the client to monitor alerts more effectively.
§ The MSSP also adjusts reporting to provide more granular insights into
attack trends.
• Simulation:
o Client Feedback Session: After a quarterly review, a financial services client
expresses concerns about alert overload and false positives.
 § The SOC team gathers specific feedback on which types of alerts are
most frequently false positives and adjusts the SIEM’s alerting logic
accordingly.
• Improvements:
o After identifying that certain types of alerts are frequently ignored by clients
due to perceived low impact, the MSSP could introduce new filtering and
alert grouping strategies to streamline client-facing dashboards.

3. Technology Upgrades

Objective:

Continuously evaluate and update the technology stack to stay ahead of emerging threats,
improve operational efficiency and enhance the MSSP’s ability to detect and respond to
complex security incidents.

• Key Actions:
1. Tool Reviews:
§ Periodically assess the performance of the current security tools,
including SIEM, endpoint protection, threat intelligence feeds and
SOAR platforms.
§ Evaluate new technologies and features (e.g., machine learning, AI-
driven analytics, cloud-native security tools).
2. Security Tool Integration:
§ Ensure new tools can integrate with existing systems to provide a
seamless workflow. For example, integrating threat intelligence with
SIEM to enrich detection rules.
3. Proof of Concept (PoC):
§ Regularly run PoCs for new security tools, such as AI-based anomaly
detection or new threat intelligence platforms, to evaluate their
effectiveness and compatibility with current workflows.
4. Continuous Training:
§ Keep the team up-to-date with the latest security technologies and
methodologies through certifications, workshops and hands-on
training.
• Example:
o Scenario: The MSSP decides to implement an AI-based analytics tool to
enhance threat detection capabilities.
§ Implementation: The AI tool integrates with the SIEM and helps
identify emerging attack patterns based on data from multiple
sources.
§ Benefit: The AI tool identifies zero-day attacks faster, reducing the
time between detection and response.
• Simulation:
 o Tool Upgrade: A simulated threat is injected into the network and the SIEM
and AI-based detection tools are compared in terms of their ability to identify
the threat.
§ Result: The new AI-based analytics tool detects the threat 25% faster
than the traditional SIEM-based detection method.
• Improvements:
o If the PoC reveals issues with integration or false positives, the MSSP adjusts
the configuration or tests alternative solutions.
o Training for analysts on the new tool would include scenario-based exercises
and in-depth workshops to improve their understanding of the tool’s output.

4. Process Refinement and Scaling

Objective:

As the MSSP grows, continually refine processes and adapt them to handle increasing
workloads while maintaining high service quality.

• Key Actions:
1. Automating Repetitive Tasks:
§ Automate repetitive tasks, such as alert triaging and log parsing, using
SOAR tools to increase efficiency.
2. Scalability Planning:
§ Prepare for scaling operations by investing in cloud-native
technologies and elastic infrastructure to handle increased data
volumes from new clients.
3. Continuous Process Improvement:
§ Apply methodologies like Lean or Six Sigma to identify inefficiencies
and optimise processes (e.g., reducing the time between detection
and response).
• Example:
o Scenario: As the client base grows, the MSSP introduces automated
incident prioritisation to handle the increasing number of alerts and
incidents.
§ The SOC uses machine learning to automatically classify incidents
based on severity, reducing manual workload.
• Simulation:
o A new automation process is tested in a simulated environment, where non-
critical alerts are automatically categorised and filtered, allowing analysts to
focus on more pressing threats.

Deliverables for Continuous Improvement

1. Performance Metrics Dashboards:

 o Regularly updated reports showing metrics like MTTD, MTTR, false positive
rates and incident volume.
2. Client Feedback Reports:
o Actionable insights and follow-up actions based on client feedback, with
status updates on improvements made.
3. Technology Evaluation Reports:
o Documentation from PoC evaluations, including recommendations for tool
upgrades or replacements.
4. Training and Certification Records:
o Proof of ongoing team training, certifications and skill development
initiatives.
SIMULATION FOR MSSP SOC SETUP: PHISHING EMAIL DETECTION AND RESPONSE

Objective: To simulate the process of detecting and responding to a phishing attempt

targeting a client, focusing on the role of Tier 1 (L1) analysts and the escalation process to
Tier 1 (L2), along with client communication and post-incident review.

1. Alert Generation

• Source: Office 365 email security system flags a suspicious email.

• Details:
o Subject: "Urgent: Update your password"
o Sender: email appears to come from a legitimate domain
(e.g., [email protected]), but on inspection, the sender’s domain is
spoofed (e.g., [email protected]).
o Suspicious Indicators:
§ The subject is a common phishing tactic.
§ The sender domain doesn’t match the company’s known email
servers.
§ The email includes a hyperlink prompting the recipient to "update
your password" by clicking a link.
• Trigger: The Office 365 system flags the email based on a combination of domain
mismatch and suspicious URL pattern.

Alert Notification Example:

• Alert ID: 2456789

• Severity: High
• Source: Office 365 Email Filtering
• Description: Potential phishing attempt detected with suspicious sender domain
and malicious URL.

2. Triage by Tier 1 (L1) Analyst

• Action by Tier 1 (L1) Analyst:

1. Initial Review: The Tier 1 (L1) analyst opens the alert in the SIEM and
retrieves the details.
§ Subject line and sender domain are noted.
§ The email appears to be coming from an official-looking address but
with subtle domain inconsistencies.
2. Header Inspection:
§ The analyst inspects the email headers to verify the source. They find
that the "From" field shows a spoofed domain
(companny.com instead of company.com), which is a red flag.
 § The Return Path and DKIM/DMARC checks show mismatches
between the sender’s stated domain and the actual mail server.
3. URL Inspection:
§ The analyst examines the URL embedded in the email and notices
that it points to an external IP address (192.168.x.x) that is not
registered with the client’s known infrastructure.
§ The URL uses a URL shortener service, which is often a common
technique in phishing emails to disguise malicious links.
§ The analyst confirms this is a fake login page hosted on an external
server designed to steal user credentials.
4. Initial Decision:
§ Based on these findings, the Tier 1 (L1) analyst classifies the alert as a
phishing attempt and prepares to escalate the incident to Tier 1 (L2).
• Actions Taken:
o The analyst documents the findings in the ticketing system, including:
§ The email header mismatch.
§ The phishing URL and the external IP.
§ A summary of the threat.
o Escalation: The analyst escalates the ticket to Tier 1 (L2) with all relevant
details, marking it as high priority.

3. Escalation to Tier 1 (L2) Analyst

• Action by Tier 1 (L2) Analyst:

1. Validation: The Tier 1 (L2) analyst reviews the details provided by Tier 1 (L1).
§ They confirm the spoofed domain using DNS lookup tools and
validate that the email is not originating from any legitimate company
mail server.
§ The analyst also verifies the phishing URL by accessing it in a sandbox
environment and confirms it leads to a fake login page.
2. Containment:
§ The analyst blocks the suspicious URL in the client’s firewall and
updates any relevant web filtering policies to ensure the URL cannot
be accessed by users.
§ The URL is added to the organisation’s Threat Intelligence Feed so it
can be flagged in the future and added to other clients’ defenses.
3. Response Preparation:
§ The analyst documents the actions taken, including the URL block
and threat intelligence update and prepares to communicate findings
to the client.

4. Client Notification

• Communication:
 o The SOC team prepares a formal notification to inform the client of the
phishing incident.

Sample Client Notification:

Subject: Phishing Attempt Detected - Action Taken

Dear [Client Name],

Our Security Operations Center (SOC) has detected a phishing attempt

targeting your organisation. The email appeared to come from an official
domain, but it was later identified as a spoofed source. The email contained
a link leading to a fake login page hosted externally.

Actions Taken:

o We have blocked the malicious URL in your firewall and updated your
web filtering policies to prevent access.
o The malicious URL has been added to our threat intelligence feed for
future prevention.

Recommendations:

o Advise your users to be cautious with unsolicited emails asking for

sensitive information, especially those with urgency-based subjects
such as "Update your password."
o We recommend reinforcing awareness training to help users spot
similar phishing attempts in the future.

Please find attached a detailed report covering the incident and the
remediation steps taken.

If you have any questions or need further assistance, please do not hesitate
to contact us.

Sincerely,
[Your MSSP Name] SOC Team

• Incident Report:
o The SOC provides a detailed report containing:
1. Incident Overview: Timeline of events, including when the phishing
email was detected and the steps taken.
2. Remediation Steps: Actions taken to block the URL and update
threat intelligence.
 3. Scope: Explanation of how the phishing attempt was targeted (e.g., by
impersonating the client’s domain).
4. Recommendations: Steps the client should take (e.g., email filtering,
user awareness training).
5. Lessons Learned: Recommendations for improving detection
methods, including incorporating machine learning-based email
filtering.

5. Post-Incident Review

• Action by SOC Team:

1. Playbook Review:
§ The SOC team reviews the phishing detection playbook to ensure it
includes this type of phishing tactic (e.g., spoofed domains and fake
login pages).
§ The team updates the playbook with more specific steps, such as
verifying external IP addresses and leveraging DNS-based domain
validation.
2. Training Update:
§ The SOC team schedules training sessions for analysts to educate
them on the new phishing tactic, particularly the use of domain
spoofing and fake login pages hosted externally.
§ Analysts are provided with examples of these types of phishing emails
and educated on how to recognise and respond to similar incidents in
the future.
• Improvements:
1. Automation Enhancement:
§ The MSSP considers enhancing its email filtering system to better
detect domain spoofing and fake URLs using machine
learning and natural language processing (NLP).
2. Threat Intelligence Sharing:
§ The phishing URL and related indicators of compromise (IOCs) are
shared across the MSSP’s threat intelligence network to help other
clients stay protected.
§ A subscription to threat intelligence services like Recorded Future is
evaluated to enhance future detection.

6. Simulation Summary

• Incident Detected: Suspicious phishing email flagged by Office 365.

• Triage by Tier 1 (L1): Email header and URL inspected; confirmed phishing attempt.
• Escalation to Tier 1 (L2): URL blocked in firewall; threat feed updated.
• Client Notification: Client informed with findings, remediation steps and
recommendations.
 • Post-Incident Review: Playbook updated, training conducted and automation
improvements considered.

Results:

• The phishing attempt was successfully detected, mitigated and communicated to

the client.
• The SOC improved internal processes, including playbook updates and training, to
ensure more efficient responses to similar incidents in the future.