10. Security Operations, Detection and Incident ResponseIntroduction and ContextSecurity operations is the organizational capability through which cyber risk is observed, interpreted, and managed in real time. It connects technical telemetry with human judgment, business priorities, and incident-management authority. A security operations function is not simply a room containing analysts and dashboards. It is a socio-technical system involving logging architecture, detection rules, threat intelligence, investigation methods, response playbooks, governance, and continual improvement. The central operational problem is uncertainty. An organization rarely receives a complete and unambiguous account of an attack. Instead, it receives fragments: an unusual authentication, a suspicious process, a changed firewall rule, an endpoint alert, or an employee report. Analysts must determine whether these fragments represent normal activity, a misconfiguration, a policy violation, or an intrusion. They must then decide what action is proportionate, timely, lawful, and least disruptive to the business. This chapter presents an applied lifecycle for security operations: collecting and protecting evidence, engineering useful detections, hunting for hidden threats, triaging incidents, containing compromise, applying forensic principles, restoring services, and learning from the event. The emphasis is on operational reasoning rather than on any particular vendor platform. Learning ObjectivesBy the end of this chapter, students should be able to: 1. Explain the role of security operations, SIEM, logging, detection engineering, and threat hunting. 2. Design a practical process for collecting, normalizing, protecting, and using security telemetry. 3. Distinguish alerts, events, incidents, and problems during operational triage. 4. Apply detection-engineering principles to reduce false positives while preserving meaningful coverage. 5. Use a structured incident-response lifecycle involving preparation, analysis, containment, eradication, recovery, and learning. 6. Describe forensic principles concerning preservation, integrity, scope, documentation, and chain of custody. 7. Evaluate business, technical, legal, ethical, and governance considerations during response. 8. Recommend improvements after an incident using measurable lessons learned. The Operational Picture: From Events to DecisionsAn event is an observable occurrence, such as a successful login, a process starting, or a file being modified. An alert is an event or combination of events that a detection mechanism has identified as potentially significant. An incident is a confirmed or reasonably suspected violation of security policy or compromise of confidentiality, integrity, or availability. A problem is the underlying condition that causes one or more incidents, such as a vulnerable service, weak identity control, or flawed backup process. The distinction matters because not every alert deserves the same response. Treating every alert as an incident overwhelms analysts and interrupts business operations. Treating genuine incidents as routine alerts allows attackers to continue operating. Effective operations therefore require a decision process that combines technical evidence with context: asset criticality, user role, timing, known business activity, threat intelligence, and potential impact. A useful operational model contains five connected layers. The first is visibility, which concerns what the organization can observe. The second is interpretation, in which events are correlated and assessed. The third is decision, in which analysts establish priority and response authority. The fourth is action, including containment, eradication, and recovery. The fifth is learning, through which the organization modifies controls, procedures, and assumptions. This model also reveals a common weakness: organizations often invest in visibility without investing in interpretation and response. Collecting large volumes of data does not automatically produce security. Data becomes operationally valuable only when it is reliable, appropriately retained, accessible to authorized personnel, and connected to decisions. Logging and Telemetry ArchitectureLogging is the systematic recording of activities by applications, operating systems, network devices, identity services, cloud platforms, and security controls. Telemetry is a broader term that includes logs as well as metrics, traces, endpoint observations, packet metadata, alerts, and other signals. A mature program begins with questions rather than with a list of available products. For example: Can the organization determine who accessed a sensitive database? Can it identify the initial execution of malware? Can it establish whether privileged credentials were used from an unusual location? Important sources commonly include: - identity and authentication systems, including single sign-on, multifactor authentication, directory services, and privileged-access platforms;
- endpoint telemetry, such as process creation, command execution, persistence mechanisms, file changes, and security-control status;
- network and application sources, including DNS, proxy, firewall, VPN, email, web, API, and database logs;
- cloud-control-plane records showing changes to accounts, permissions, storage, virtual machines, and security configurations; and
- business and physical-access systems when they help establish user activity or operational context.
Logs should be evaluated for coverage, quality, timeliness, retention, and protection. Coverage asks whether relevant systems are represented. Quality asks whether fields are complete, consistent, and meaningful. Timeliness concerns clock synchronization and delivery delay. Retention must reflect investigative, regulatory, and business requirements. Protection requires access control, encryption where appropriate, tamper resistance, and monitoring of the logging infrastructure itself. Time synchronization is particularly important. An investigation that combines endpoint, identity, and network records cannot reliably reconstruct a sequence if systems use inconsistent clocks. Centralized time services, documented time zones, and preservation of original timestamps help analysts create an accurate timeline. Logging also creates privacy and governance responsibilities. Logs may contain usernames, device identifiers, IP addresses, commands, email subjects, or sensitive application data. Collection should therefore follow purpose limitation, access minimization, retention schedules, and applicable law. More logging is not automatically better if it increases exposure, cost, or unauthorized surveillance without improving a defined security decision. SIEM and Security AnalyticsA security information and event management system, or SIEM, aggregates, normalizes, stores, searches, correlates, and presents security-relevant data. Its value lies not merely in central storage but in enabling analysts to connect events across systems. A failed login followed by a successful login, a new administrator account, and a large data transfer may be unremarkable when examined separately but significant as a sequence. A practical SIEM architecture usually includes collection agents or connectors, transport mechanisms, parsing and normalization, enrichment, correlation, storage, detection logic, dashboards, case management, and interfaces to response tools. Normalization maps different source formats into a common analytical vocabulary. Enrichment adds context such as asset criticality, user department, geographic information, vulnerability status, ownership, and threat-intelligence indicators. Correlation should be designed carefully. A rule that generates an alert for every failed login may create excessive noise. A rule that identifies repeated failures followed by a successful login from an unfamiliar device, especially against a privileged account, is more meaningful. Correlation can be temporal, statistical, identity-based, asset-based, or behavioral. SIEM implementation presents a trade-off between detection value and operational cost. High-volume sources can consume storage and analyst attention. Low-volume but high-value sources, such as privileged-access logs or cloud configuration changes, may deserve stronger retention and monitoring. Organizations should define data tiers, retention periods, ingestion priorities, and ownership instead of attempting to store everything indefinitely. Detection Engineering as a LifecycleDetection engineering is the disciplined design, testing, deployment, monitoring, and improvement of mechanisms that identify suspicious or harmful behavior. It is not equivalent to copying rules from a threat-intelligence feed. A useful detection has a stated purpose, a defined data dependency, an expected signal, known limitations, an owner, and a response path. A detection can be designed from several sources: threat models, attack techniques, previous incidents, vulnerability assessments, regulatory requirements, intelligence reports, and observed normal behavior. The analyst should first define the behavior of concern. For example, the objective might be to identify unauthorized credential dumping, creation of persistence through a scheduled task, or mass deletion of cloud resources. The detection should then specify required telemetry, logic, severity, exclusions, validation tests, and the action expected from the analyst. Detection quality is often discussed using precision and recall. Precision concerns the proportion of alerts that are genuinely relevant; low precision produces false positives. Recall concerns the proportion of relevant malicious activity that is detected; low recall produces false negatives. Improving one can reduce the other. A highly broad rule may increase recall but create too many alerts, while a narrow rule may be precise but miss variations of the behavior. Detections should be tested against known benign activity, simulated adversary behavior, historical data, and changes in the environment. Analysts should monitor alert volume, investigation time, escalation rate, closure reasons, and missed detections. Rules require version control and change management. When an alert is repeatedly closed as expected administration, the correct response may be to improve context or create a narrowly defined exception, not simply to disable the rule. A mature detection catalogue maps detections to business assets, attack behaviors, data sources, severity, response procedures, and known gaps. This makes coverage visible to management and helps prioritize engineering effort. Coverage, however, should not be treated as proof of security. A mapped technique may still be poorly detected because the relevant telemetry is incomplete or the adversary uses an unanticipated method. Threat Hunting and Hypothesis-Based InvestigationThreat hunting is a proactive, analyst-led search for malicious or suspicious activity that has not necessarily generated an alert. It differs from routine monitoring because it begins with a question or hypothesis. Examples include: “Could an attacker be using legitimate remote-management tools to move between servers?” or “Are any service accounts authenticating interactively from workstations?” A hunt normally proceeds through hypothesis formation, data selection, query development, investigation, validation, and improvement. The analyst uses knowledge of the environment and attacker behavior to search for anomalies, weak signals, and relationships. The result may be a confirmed incident, a benign explanation, a new detection, a telemetry gap, or a refined hypothesis. Hunting should not be confused with unstructured searching. A defensible hunt documents its scope, assumptions, time period, data sources, queries, limitations, findings, and follow-up actions. Analysts must distinguish unusual behavior from malicious behavior. For example, a rare administrative command may be legitimate during a planned migration. Interviews with system owners and examination of change records are often essential. Threat hunting is especially valuable where attackers use valid credentials, native operating-system tools, encrypted channels, or low-and-slow activity. It can reveal control weaknesses that automated detections do not yet cover. It also provides feedback to detection engineering and security architecture. Incident Triage and PrioritizationTriage is the rapid assessment of an alert or report to determine credibility, scope, urgency, and required action. The objective is not to solve the entire incident immediately. It is to make a sound next decision while preserving evidence and reducing risk. A practical triage sequence asks: 1. What was observed, and how reliable is the source? 2. Which identities, devices, applications, and data are involved? 3. Is the activity authorized, expected, or explained by a change record? 4. What evidence indicates compromise, and what evidence argues against it? 5. Is the activity ongoing, and could delay increase harm? 6. What is the potential business, legal, safety, or regulatory impact? 7. Which response authority and specialist teams must be engaged? Severity should reflect impact and urgency rather than alert volume alone. A suspicious event on an isolated test machine may be low priority, while a similar event involving a domain administrator or a safety-critical system may require immediate escalation. Organizations commonly use severity categories, but the criteria must be explicit and consistently applied. Case records should document the alert source, timestamps, analyst actions, evidence reviewed, decisions, communications, and current status. Good documentation supports handover, quality assurance, legal review, and later lessons learned. It also prevents the investigation from depending on an individual analyst’s memory. Incident Response: From Containment to RecoveryIncident response is a coordinated process for managing the consequences of a security event. Widely used lifecycle models differ in terminology, but they generally include preparation; detection and analysis; containment; eradication; recovery; and post-incident activity. Preparation includes policies, roles, contact lists, playbooks, technical capabilities, backups, exercises, legal arrangements, and relationships with external providers. Preparation determines whether the organization can act when normal communication channels, credentials, or systems are affected. Detection and analysis establish whether an incident exists, identify affected assets and identities, estimate scope, and preserve initial evidence. Analysts should avoid premature certainty. Early statements should distinguish facts, working hypotheses, assumptions, and unknowns. Containment limits spread and reduces immediate harm. Actions may include isolating an endpoint, disabling a compromised account, blocking malicious infrastructure, restricting network paths, suspending an access token, or placing a vulnerable service behind additional controls. Containment decisions involve trade-offs. Disconnecting a system may prevent further compromise but may destroy volatile evidence or interrupt a critical service. The response team should select the least disruptive action that sufficiently reduces risk, while escalating when safety or major business impact is involved. Eradication removes the cause and persistence of compromise. It can involve deleting malicious accounts, removing unauthorized scheduled tasks, resetting credentials, patching exploited vulnerabilities, rebuilding systems, and eliminating unauthorized access paths. Eradication should be based on adequate scope analysis. Cleaning one visible file while leaving an attacker’s persistence mechanism intact creates false recovery. Recovery returns systems to trusted operation. It includes restoration from verified backups, integrity checks, heightened monitoring, phased reconnection, user communication, and confirmation by system owners. Recovery is not complete merely because a system is online. The organization must establish that security controls are functioning and that the business process is operating safely. Post-incident activity examines causes, control failures, response performance, and improvement actions. It should be a learning process rather than a search for blame. Actions require owners, deadlines, priorities, and measures of completion. Forensic Principles in Operational ResponseDigital forensics applies systematic methods to identify, preserve, collect, examine, analyze, and report digital evidence. In operational response, forensic work must balance the need for rapid risk reduction with the need to preserve reliable evidence. The first principle is integrity. Investigators should preserve original evidence where practical, use write-protected or controlled acquisition methods, calculate cryptographic hashes, and document transformations. A hash supports later verification that a collected item has not changed, although it does not by itself prove who created the item or how it was obtained. The second principle is documentation. Investigators should record who collected evidence, when and where it was collected, the method used, the systems involved, and any handling or transfer. This record is commonly described as chain of custody. Its rigor should match the anticipated use of the evidence, organizational policy, and legal requirements. The third principle is order of volatility. Some evidence disappears quickly, including memory contents, active network connections, running processes, and temporary data. Other evidence, such as disk images or centralized logs, may persist longer. Collection priorities depend on the scenario, but responders should avoid actions that unnecessarily destroy volatile evidence. The fourth principle is scope and proportionality. Investigators should collect what is relevant and authorized. Copying unrelated personal material or examining systems outside the defined scope can create privacy, legal, and ethical problems. Evidence should be interpreted in context, with alternative explanations considered. Forensic conclusions should distinguish observation from inference. “A process executed under the service account at 02:14” is an observation. “The attacker used the service account to establish persistence” is an inference requiring supporting evidence. This distinction improves the credibility of technical reports and executive communication. A Detailed Illustrative Case: Compromise of a Cloud Administrator AccountBackgroundNorthbridge Health Services, a fictional regional healthcare provider, operates a hybrid environment with cloud applications, on-premises identity services, and a centralized SIEM. Administrative activity is monitored, but cloud audit logs are retained for only a short period, and the security team has limited visibility into unmanaged devices. SituationAt 02:10 on a Sunday, the SIEM raises an alert for a successful multifactor authentication event involving a cloud administrator account from an unfamiliar device and location. Thirty minutes later, a new application credential is created and assigned elevated permissions. A storage repository containing operational reports is then accessed repeatedly. No malware alert is generated. AnalysisThe initial alert is not treated as proof of compromise. The analyst checks the administrator’s schedule, confirms that no maintenance was planned, and compares the device, location, and authentication method with historical behavior. The identity owner confirms that the administrator was asleep and had not approved the activity. The team identifies a sequence: unusual authentication, creation of a persistent cloud credential, privilege assignment, and data access. The incident commander classifies the event as high severity because it involves privileged access and potentially sensitive information. The response team preserves relevant cloud audit records, identity logs, and case notes. It also records the current configuration before making changes. Approach and StrategyThe team first revokes active sessions and disables the compromised administrator account. Because the attacker may have created additional access paths, responders enumerate recently created users, applications, keys, role assignments, forwarding rules, and changes to logging. They use a separate trusted administrative account to avoid relying on potentially compromised credentials. The suspicious application credential is removed after its details are preserved for evidence. All privileged credentials associated with the account are rotated, and conditional-access controls are temporarily strengthened to require approved devices and additional verification. Cloud audit-log retention is extended to support scoping. Analysts hunt for the same indicators across other accounts and subscriptions. The investigation finds that the administrator had approved a malicious consent request several days earlier through a phishing message. No evidence shows modification of clinical systems, but the storage repository was accessed and several reports were downloaded. Legal, privacy, and senior management teams are engaged to assess notification duties and contractual obligations. OutcomeThe organization restores trusted administrative access, removes unauthorized permissions, confirms that logging is functioning, and monitors privileged activity for an extended period. It improves application-consent governance, requires phishing-resistant authentication for administrators where feasible, increases cloud-log retention, and creates detections for unusual application-credential creation and privilege assignment. Learning PointsThe case demonstrates that incidents may involve identity and cloud-control-plane abuse without traditional malware. It also shows the importance of sequence-based detection, privileged-access context, preservation before alteration, and coordination between technical responders, management, legal advisers, and privacy personnel. A single alert became meaningful only when combined with contextual and behavioral evidence. Operational Challenges, Risks, and Common MistakesOne persistent challenge is alert fatigue. Excessive low-quality alerts encourage analysts to close cases quickly or ignore warnings. The remedy is not simply to hire more analysts; it includes improving rule logic, enrichment, prioritization, data quality, and feedback processes. Another challenge is incomplete visibility. Encrypted traffic, unmanaged devices, unsupported legacy systems, third-party services, and short log-retention periods can create investigative blind spots. Organizations should document these gaps rather than assume that the absence of evidence proves the absence of activity. A further risk is overreliance on automation. Automated isolation or account disabling can limit damage, but incorrect automation may interrupt critical services, destroy evidence, or lock out legitimate users. High-impact actions should have carefully defined conditions, approvals, exceptions, and rollback procedures. Common response mistakes include changing systems before collecting volatile evidence, failing to preserve original logs, communicating unverified conclusions, neglecting business owners, resetting one credential while leaving tokens active, and declaring recovery when monitoring has not been restored. Another mistake is treating the post-incident review as a blame exercise. Fear discourages reporting and conceals control weaknesses. Governance, Ethics, and Professional ResponsibilitySecurity operations involves authority over identities, communications, systems, and potentially personal information. Analysts must operate within documented authorization. Monitoring should be proportionate, transparent where required, and restricted to legitimate security purposes. Access to cases and evidence should follow least privilege and separation of duties. Incident response may trigger contractual, regulatory, employment, privacy, or law-enforcement considerations. Technical teams should not independently make legal conclusions. They should provide accurate facts to designated legal, compliance, privacy, and executive authorities. Notification decisions require careful assessment of jurisdiction, affected information, materiality, and applicable deadlines. Professional communication is itself a security control. Incident reports should be clear, factual, time-stamped, and explicit about uncertainty. Analysts should avoid exaggerated claims, unsupported attribution, and unnecessary disclosure of sensitive details. External communication should be coordinated through authorized channels. Automation, Analytics, and Artificial IntelligenceSecurity orchestration, automation, and response platforms can enrich alerts, open cases, query multiple systems, revoke sessions, isolate endpoints, and document actions. Automation is most reliable for repetitive, reversible, and well-understood tasks. Irreversible or high-impact actions require stronger validation and human oversight. Behavioral analytics can identify deviations from a baseline, such as unusual login times, impossible travel patterns, abnormal data access, or atypical administrative actions. Baselines must account for legitimate change, travel, shift work, seasonal activity, and business events. Otherwise, analytics may reproduce the same false-positive problem as poorly designed static rules. Machine-learning systems can assist with prioritization, clustering, anomaly detection, and natural-language investigation support. They can also introduce opaque reasoning, biased baselines, adversarial manipulation, privacy concerns, and automation bias. Analysts should be able to inspect relevant evidence, validate recommendations, and override model outputs. AI should support, not replace, accountable operational judgment. Current Developments and Best PracticesCloud adoption, identity-centric attacks, software supply-chain compromise, ransomware, and attacks on operational technology continue to influence security operations. Telemetry is increasingly distributed across multiple cloud providers, SaaS platforms, endpoints, and third parties. This makes identity context, asset inventory, API security, and control-plane monitoring central to modern detection. Effective practice includes maintaining an accurate asset and identity inventory; prioritizing telemetry according to risk; synchronizing time; protecting logs; documenting detection ownership; testing response playbooks; exercising offline communication and backups; and measuring improvement rather than merely counting alerts. Useful operational measures include mean time to acknowledge, mean time to contain, time to recover, percentage of high-priority alerts meeting service targets, false-positive rates, detection coverage for priority attack paths, log-source availability, and completion of corrective actions. Metrics must be interpreted carefully. A low response time may indicate efficiency, but it may also indicate premature closure if investigation quality is not assessed. A mature security operations program combines technology with disciplined practice. It knows what it is trying to detect, what it cannot see, who has authority to act, how evidence will be preserved, how services will be restored, and how learning will change future behavior. Chapter SummarySecurity operations transforms technical observations into decisions and coordinated action. Logging and telemetry provide the evidence base, while SIEM platforms support aggregation, normalization, correlation, and investigation. Detection engineering creates tested and maintained mechanisms for identifying suspicious behavior; threat hunting proactively examines hypotheses that automated alerts may miss. Triage determines credibility, scope, urgency, and priority. Incident response then applies preparation, analysis, containment, eradication, recovery, and post-incident learning. Forensic principles require integrity, documentation, attention to volatility, proportionality, and a clear distinction between observation and inference. Effective response also depends on governance, privacy, legal coordination, professional communication, and responsible use of automation and AI. The most capable organizations do not measure success only by the number of alerts processed. They measure whether important activity can be seen, understood, contained, recovered from, and used to improve future resilience. Key TermsEvent: An observable occurrence in a system, network, application, or process. Alert: A notification that an event or event pattern may require investigation. Incident: A suspected or confirmed violation of security policy or compromise of information assets. Security operations: The people, processes, and technologies used to monitor and manage cybersecurity risk. Telemetry: Security-relevant observations, including logs, metrics, traces, alerts, and endpoint data. SIEM: A platform that collects, normalizes, stores, correlates, and analyzes security events. Normalization: Mapping different data formats into a consistent analytical structure. Enrichment: Adding contextual information, such as asset ownership, user role, or threat intelligence, to an event. Detection engineering: The lifecycle of designing, testing, deploying, and improving security detections. False positive: An alert indicating suspicious activity when the underlying activity is benign. False negative: Malicious or policy-violating activity that a detection fails to identify. Threat hunting: Proactive, hypothesis-driven investigation for previously unidentified threats. Triage: Initial assessment of an alert or report to determine credibility, scope, priority, and action. Containment: Actions taken to limit the spread or impact of an incident. Eradication: Removal of malicious artifacts, persistence, vulnerabilities, or unauthorized access. Recovery: Restoration of systems and business operations to a trusted state. Digital forensics: Systematic collection, preservation, examination, and interpretation of digital evidence. Chain of custody: The documented history of evidence collection, handling, transfer, and storage. SOAR: Security orchestration, automation, and response technology used to coordinate and automate operational actions. Lessons learned: A structured review of an incident used to improve controls, processes, and preparedness. Review QuestionsShort Answer Questions1. Distinguish an event, an alert, an incident, and a problem. 2. Why are time synchronization and log integrity important during an investigation? 3. What is the difference between threat hunting and routine alert monitoring? 4. Define precision and recall in the context of detection engineering. 5. State two principles that should guide digital evidence handling. Long Answer Questions1. Explain how a SIEM supports security operations from collection through investigation, and discuss the importance of normalization and enrichment. 2. Describe the complete incident-response lifecycle and explain the principal decisions involved in containment, eradication, and recovery. 3. Discuss how an organization can design, test, measure, and improve a detection without creating unsustainable alert fatigue. 4. Explain the forensic challenges that arise when responders must reduce immediate risk while preserving evidence. 5. Evaluate the governance, privacy, legal, and professional responsibilities of a security operations team during a major incident. Analytical / Application Questions1. A privileged account logs in from an unfamiliar device, creates a new application credential, and accesses a sensitive repository. Design a triage and containment plan, identifying evidence that should be preserved before corrective action. 2. A detection generates 2,000 alerts per week, but analysts confirm that only 2 percent represent suspicious activity. Analyze possible causes and propose an improvement plan using detection engineering principles. 3. During a ransomware investigation, business leaders demand immediate system shutdown while forensic analysts request time to collect volatile evidence. Explain how the incident commander should evaluate and communicate this trade-off. 22. Multiple Choice Questions with AnswersQuestion 1Which condition most clearly distinguishes an incident from an alert? A. The event was recorded in a centralized log B. The event was generated by an automated detection rule C. There is reasonable evidence of a security-policy violation or compromise D. The event involved a user account Correct Answer: C. There is reasonable evidence of a security-policy violation or compromise Question 2What is the primary operational value of SIEM normalization? A. It eliminates the need for analysts B. It maps different source formats into a consistent structure for analysis C. It guarantees that every attack will be detected D. It permanently encrypts all log data Correct Answer: B. It maps different source formats into a consistent structure for analysis Question 3A detection rule identifies every failed login as a high-severity alert. Which improvement is most appropriate? A. Disable all authentication logging B. Correlate failures with context such as subsequent success, privilege, device, and timing C. Delete alerts after one hour D. Treat every failed login as a confirmed breach Correct Answer: B. Correlate failures with context such as subsequent success, privilege, device, and timing Question 4What is the defining feature of threat hunting? A. It only investigates alerts already classified as incidents B. It is a proactive, hypothesis-driven search for suspicious activity C. It replaces the need for logging D. It is limited to malware analysis Correct Answer: B. It is a proactive, hypothesis-driven search for suspicious activity Question 5Which action best reflects sound containment practice? A. Immediately rebuild every system without recording evidence B. Select an action that reduces risk while considering business impact and evidence preservation C. Wait for complete certainty before taking any action D. Publicly attribute the attack before investigation is complete Correct Answer: B. Select an action that reduces risk while considering business impact and evidence preservation Question 6Why should responders distinguish observations from inferences in forensic reporting? A. To make reports longer B. To prevent technical evidence from being collected C. To separate directly supported facts from conclusions requiring interpretation D. To avoid documenting uncertainty Correct Answer: C. To separate directly supported facts from conclusions requiring interpretation Question 7Which example is most likely to require high-priority escalation? A. A blocked connection from a known scanner to a test server B. A failed login to an inactive laboratory account C. A suspicious action involving a privileged account and sensitive data D. A routine software update recorded in endpoint logs Correct Answer: C. A suspicious action involving a privileged account and sensitive data Question 8What is a major danger of high-impact automated response actions? A. They always increase false negatives B. They can interrupt critical services or destroy evidence when triggered incorrectly C. They prevent all future detection engineering D. They make logs impossible to store Correct Answer: B. They can interrupt critical services or destroy evidence when triggered incorrectly Question 9Which measure best supports evidence integrity? A. Editing original logs to remove irrelevant entries B. Copying evidence without recording who handled it C. Calculating hashes and documenting collection and handling procedures D. Relying solely on an analyst’s memory Correct Answer: C. Calculating hashes and documenting collection and handling procedures Question 10In the illustrative cloud-account case, why was the sequence of events more significant than the initial login alone? A. The login was automatically confirmed as malicious B. The sequence connected unusual authentication with credential creation, privilege assignment, and data access C. Cloud logins are always incidents D. The account was not protected by multifactor authentication Correct Answer: B. The sequence connected unusual authentication with credential creation, privilege assignment, and data access
|
