Unit 3: Endpoint, SIEM, and Security Analytics - Subjective Questions

Endpoint Detection and Response (EDR) is a security technology that continuously monitors endpoint activities, detects suspicious behavior, records forensic data, and supports investigation and response.

Main components include:

• Endpoint agents: Collect process, file, network, user, and registry activity.
• Centralized data collection: Sends endpoint telemetry to a platform for storage and analysis.
• Detection engine: Identifies known indicators, suspicious behavior, and attack patterns.
• Investigation tools: Allow analysts to search historical activity and reconstruct attacks.
• Response capabilities: Isolate hosts, terminate processes, quarantine files, and remove persistence mechanisms.

EDR supports threat hunting by allowing analysts to search endpoint data for indicators of compromise, unusual processes, lateral movement, privilege escalation, and other signs of attack. It also provides timelines and contextual evidence for validating alerts and determining the scope of an incident.

Malware analysis is the systematic examination of malicious software to understand its behavior, capabilities, and impact.

Major stages include:

• Sample acquisition and preservation: Obtain the file safely and calculate hashes for identification.
• Static analysis: Examine strings, headers, imports, metadata, embedded resources, and disassembled code without executing the sample.
• Dynamic analysis: Execute the sample in an isolated sandbox and observe files, processes, registry changes, network traffic, and persistence behavior.
• Reverse engineering: Use debuggers and disassemblers to understand program logic, unpack protected code, and identify important functions.
• Reporting: Document indicators of compromise, behavior, attack objectives, and recommended defensive controls.

Static analysis is safer and can reveal structural information quickly, while dynamic analysis shows the actual runtime behavior. They complement each other because malware may hide important code during static inspection or behave differently depending on its environment during execution.

Risk models help organizations prioritize endpoint threats according to business impact and exposure.

Data-focused risk model:

• Prioritizes the confidentiality, integrity, and availability of sensitive data.
• Considers data classification, regulatory requirements, access rights, and potential loss.
• Example: A compromised endpoint containing customer financial records receives a high risk score even if it is not a critical server.

Asset-focused risk model:

• Prioritizes the importance, exposure, and operational role of the endpoint or system.
• Considers business criticality, network location, dependencies, and availability requirements.
• Example: A domain controller, industrial control system, or payment server receives a high risk score because its compromise could disrupt major operations.

The data-focused model emphasizes what could be lost, while the asset-focused model emphasizes which systems could be affected. Organizations commonly combine both models to calculate a more complete risk priority.

Endpoint security protects laptops, desktops, mobile devices, servers, and other connected systems from compromise.

Important principles include:

• Asset visibility: Maintain an accurate inventory of hardware, software, users, and configurations.
• Least privilege: Give users and processes only the permissions required for their tasks.
• Secure configuration: Disable unnecessary services, enforce strong settings, and remove unused software.
• Patch management: Apply operating system and application updates to reduce exploitable vulnerabilities.
• Application control: Allow only trusted or approved software to execute.
• Defense in depth: Combine antivirus, EDR, firewalls, encryption, access control, and network protections.
• Continuous monitoring: Detect suspicious behavior and policy violations quickly.
• Rapid response and recovery: Isolate compromised endpoints and restore them to a trusted state.

These principles reduce the number of exploitable services, limit attacker privileges, improve detection, and restrict the movement of threats across the environment.

A Security Information and Event Management (SIEM) system collects, normalizes, correlates, stores, and analyzes security events from across an organization.

Basic SIEM architecture:

• Data sources: Operating systems, applications, firewalls, identity systems, cloud services, endpoints, and network devices.
• Collection layer: Receives logs through agents, collectors, APIs, or network protocols.
• Normalization layer: Converts different log formats into a consistent structure.
• Correlation and analytics layer: Connects related events and identifies suspicious patterns.
• Storage layer: Retains searchable current and historical data.
• Presentation layer: Provides dashboards, alerts, investigations, and reports.

Core functions include:

• Centralized log management
• Real-time alerting
• Event correlation
• Threat detection and investigation
• Compliance reporting
• Incident response support

SIEM provides a unified view of security activity and helps analysts connect events that may appear unrelated when examined separately.

Distributed processing divides SIEM data collection, processing, analysis, and storage across multiple systems or nodes rather than relying on one central machine.

Typical distributed components include:

• Regional or departmental log collectors
• Stream-processing nodes
• Distributed indexing and storage clusters
• Separate correlation and analytics services
• High-availability management nodes

Benefits include:

• Scalability: Additional nodes can process increasing event volumes.
• Improved performance: Workloads are handled in parallel.
• Reduced latency: Data can be processed closer to its source.
• Fault tolerance: Failure of one node does not necessarily stop monitoring.
• Geographic support: Logs from multiple locations and cloud regions can be handled efficiently.
• Data locality: Sensitive data can remain within required jurisdictions.

Distributed processing is especially important when organizations generate millions or billions of events. It prevents bottlenecks and helps maintain timely detection and investigation.

SIEM accelerates threat hunting by making security data searchable, comparable, and available in one investigation environment.

• Normalization: Converts different log formats into common fields such as source address, destination address, username, timestamp, and event type.
• Correlation: Links related events, such as a suspicious login followed by privilege escalation and unusual data access.
• Search: Allows analysts to query large volumes of historical and real-time data using filters, field searches, and timelines.
• Enrichment: Adds context from threat intelligence, asset inventories, vulnerability scanners, identity systems, and geolocation services.
• Visualization: Presents trends, relationships, and event sequences through dashboards and graphs.
• Automation: Runs scheduled searches and creates alerts when hunting conditions are met.

These capabilities reduce manual data gathering and help analysts move from an initial hypothesis to evidence and response more quickly.

SIEM supports regulatory reporting by collecting evidence about access, system changes, authentication, administrative actions, and security incidents.

Reporting capabilities include:

• Generating reports for access control and privileged-user activity
• Demonstrating log collection and monitoring practices
• Recording incident timelines and response actions
• Supporting retention and audit requirements
• Producing evidence of policy violations and remediation

Controls required for reliable reports include:

• Accurate and synchronized timestamps
• Defined log sources and collection coverage
• Protection against log alteration or deletion
• Role-based access to reports and raw logs
• Documented retention and disposal policies
• Consistent field normalization and report definitions
• Regular validation of data completeness
• Audit trails for report creation and modification

A SIEM does not automatically guarantee compliance. Organizations must configure it according to the applicable regulation and maintain documented processes around monitoring, access, retention, and review.

SIEM infrastructure management ensures that the platform remains available, accurate, secure, and capable of handling current and future workloads.

Important requirements include:

• Capacity planning: Estimate event volume, ingestion rate, storage needs, and query workloads.
• Availability: Use clustering, replication, backups, and disaster recovery procedures.
• Health monitoring: Track collector status, processing delays, queue depth, storage capacity, and failed integrations.
• Data source management: Register, authenticate, test, and periodically review log sources.
• Configuration management: Control changes to parsers, correlation rules, dashboards, and permissions.
• Access security: Apply least privilege, multifactor authentication, and administrative separation.
• Performance tuning: Optimize indexing, parsing, searches, and retention tiers.
• Maintenance: Patch the SIEM platform and its supporting operating systems and databases.

Effective infrastructure management prevents data loss, excessive delays, false alerts, and service interruptions.

A SIEM log retention strategy defines what data is stored, where it is stored, how long it is retained, and how it is protected.

Key considerations include:

• Legal and regulatory requirements: Determine minimum retention periods for security, privacy, financial, and industry regulations.
• Investigation needs: Retain enough historical data to investigate delayed detection, long-term compromise, and recurring attacks.
• Log value: Store authentication, administrative, endpoint, network, and critical application logs according to their security importance.
• Storage tiers: Keep frequently queried logs in fast storage and older data in lower-cost archival storage.
• Integrity: Use access controls, encryption, hashing, immutability, and audit trails to protect logs.
• Privacy: Minimize unnecessary personal data and define approved access procedures.
• Cost and capacity: Estimate daily ingestion, compression, indexing, backup, and archive costs.
• Disposal: Securely delete data after the approved retention period.

A practical strategy classifies logs by importance and assigns different retention periods while preserving evidence integrity and accessibility.

Automated response and remediation use SIEM rules, playbooks, and integrations to perform predefined actions when a security condition is detected.

Examples include:

• Disabling or challenging a compromised account
• Isolating an endpoint through an EDR platform
• Blocking a malicious address or domain at a firewall
• Quarantining a suspicious file
• Opening an incident ticket and notifying responders
• Collecting additional forensic data

Advantages:

• Faster containment
• Reduced analyst workload
• Consistent execution of standard procedures
• Improved response to high-volume events

Risks:

• False positives may interrupt legitimate operations.
• Incorrect rules may cause widespread outages.
• Attackers may exploit automation to trigger denial-of-service actions.
• Poorly designed integrations may expose privileged credentials.

Safeguards include confidence thresholds, approval steps for high-impact actions, allowlists, rate limits, rollback procedures, detailed logging, testing, and periodic review of playbooks. Automation should be proportional to the confidence and potential impact of the alert.

A systematic SIEM threat hunt is a hypothesis-driven investigation intended to identify threats that automated alerts may have missed.

Process:

• Define a hypothesis: For example, assume that an attacker may be using valid credentials for unusual remote access.
• Identify required data: Select authentication, VPN, endpoint, identity, and network logs.
• Build search queries: Look for unusual times, locations, devices, privilege changes, and access patterns.
• Establish a baseline: Compare activity with normal user and asset behavior.
• Enrich findings: Add asset criticality, user role, vulnerability information, and threat intelligence.
• Investigate relationships: Trace activity backward and forward across users, hosts, processes, and connections.
• Validate and scope: Confirm whether activity is malicious and identify affected systems.
• Respond and document: Contain the threat, record evidence, and create new detections from the findings.

Threat hunting is iterative: every confirmed discovery should improve detection rules, logging coverage, and future hunting hypotheses.

An effective SIEM program requires more than installing a technology platform. It needs defined processes, skilled personnel, and measurable operating procedures.

Operational requirements include:

• Governance: Define ownership, responsibilities, policies, and escalation paths.
• Use-case management: Prioritize detection use cases according to business risks and threats.
• Reliable logging: Ensure important systems send complete, correctly formatted, and synchronized logs.
• Skilled analysts: Provide personnel who can triage alerts, investigate incidents, and conduct threat hunts.
• Alert tuning: Reduce false positives and regularly review detection performance.
• Incident integration: Connect SIEM workflows with ticketing, case management, SOAR, and response teams.
• Service-level objectives: Define response times, availability targets, and investigation standards.
• Continuous improvement: Measure coverage, mean time to detect, mean time to respond, false-positive rates, and unresolved alerts.
• Training and documentation: Maintain playbooks, procedures, and knowledge transfer.

These requirements make SIEM operations consistent, measurable, and aligned with organizational risk.

Behavioral analytics examines the normal patterns of users, devices, applications, and services and identifies significant deviations.

UEBA applies this concept specifically to users and entities such as hosts, service accounts, applications, and network devices.

UEBA commonly evaluates:

• Login time, location, and device
• Access frequency and resource selection
• Data transfer volume
• Privilege usage
• Administrative activity
• Process and network behavior
• Relationships between users and systems

A baseline is created from historical or peer-group behavior. New events are then compared with that baseline. For example, a user who normally accesses office documents during business hours may be considered suspicious if the account suddenly authenticates from a new country, accesses sensitive databases, and transfers a large volume of data.

UEBA provides context that simple rule matching may miss, but its results require careful tuning because unusual behavior is not always malicious.

Machine learning in security analytics identifies patterns in large volumes of security data and supports detection, prioritization, and investigation.

• Supervised learning: Uses labeled examples of benign and malicious activity to learn a classification model. It is useful when high-quality labeled data is available, such as known phishing messages or malware samples.
• Unsupervised learning: Finds structure or unusual patterns without requiring labeled attack data. Clustering and anomaly detection are common examples.
• Semi-supervised learning: Uses a small amount of labeled data together with a larger amount of unlabeled data. It is useful when attack labels are limited but normal activity is abundant.

Security applications include:

• Detecting unusual authentication behavior
• Classifying malware or phishing activity
• Finding suspicious network flows
• Prioritizing alerts
• Identifying compromised accounts

Machine learning should support analysts rather than replace them. Results must be evaluated for false positives, data drift, adversarial manipulation, explainability, and operational usefulness.

Deploying a predictive model in a SOC requires technical preparation, validation, integration, and continuous monitoring.

Deployment stages include:

• Define the objective: Specify the threat or event to predict and the desired operational action.
• Collect and prepare data: Gather relevant telemetry, remove errors, normalize fields, and handle missing values.
• Create features: Derive meaningful indicators such as login frequency, process relationships, or data-transfer statistics.
• Train and validate: Use representative data and separate training, validation, and test sets.
• Evaluate performance: Measure precision, recall, false-positive rate, detection delay, and business impact.
• Pilot deployment: Run the model in observation mode before allowing it to influence response.
• Integrate with SOC tools: Send scores and explanations to the SIEM, case-management system, or SOAR platform.
• Monitor and retrain: Detect model drift, changing attacker behavior, data-quality problems, and degraded performance.

A successful deployment must balance predictive accuracy with analyst trust, explainability, response cost, and system reliability.

Anomaly detection identifies observations that differ significantly from expected behavior in a security environment.

• Point anomaly: A single observation is abnormal by itself. Example: one endpoint generates an unusually large outbound data transfer.
• Contextual anomaly: An observation is abnormal in a particular context. Example: a login may be normal during working hours but suspicious at an unusual time or from an unexpected location.
• Collective anomaly: A group or sequence of individually normal events becomes suspicious when considered together. Example: repeated low-volume queries followed by gradual data collection may indicate reconnaissance or data exfiltration.

A SOC typically establishes baselines using historical, peer-group, statistical, or machine-learning methods. Analysts then examine the anomaly with asset, identity, vulnerability, and threat-intelligence context.

The main challenges are noisy data, changing business behavior, incomplete telemetry, and excessive false positives. Thresholds and models should therefore be tuned and reviewed continuously.

EDR and SIEM provide different but complementary security functions.

Integration allows the SIEM to use detailed EDR telemetry in broader correlations, while EDR can receive SIEM context about users, network events, or related affected systems. Together they improve detection accuracy, investigation scope, and response coordination.

A simple endpoint risk score can be defined as:

where:

• is the estimated likelihood of compromise,
• is the criticality of the affected asset,
• is the sensitivity or business value of the data,
• is the effectiveness of existing controls, represented on a normalized scale from to .

For example, an endpoint with high likelihood, critical asset value, and sensitive data will receive a high score. Strong controls reduce the residual risk because the term becomes smaller.

Use in response:

• High-risk incidents should receive immediate analyst attention and possible automated containment.
• Medium-risk incidents should be investigated promptly and monitored for escalation.
• Low-risk incidents may be queued, enriched, or handled through routine remediation.

This model is a prioritization aid, not an exact measurement. Organizations should validate its variables, weights, and thresholds against business requirements and incident outcomes.

A highly available distributed SIEM avoids dependence on a single collector, processor, storage node, or network path.

Design practices include:

• Deploying multiple collectors across network regions
• Using load balancing to distribute incoming events
• Maintaining queues or buffers during temporary processing failures
• Replicating indexes and critical event data across storage nodes
• Separating ingestion, search, correlation, and management workloads
• Monitoring node health and automatically redirecting traffic after failure
• Performing regular backups of configurations, rules, dashboards, and case data
• Maintaining a secondary site or cloud environment for disaster recovery
• Testing recovery procedures and defining recovery time and recovery point objectives

High availability aims to keep the service running during component failures, whereas disaster recovery restores operations after a major outage. Both require documented procedures, tested failover, capacity planning, and protection of replicated security data.