Доклад «Чертовски хороший Compromise Assessment»

Main ideas, concepts, and lessons

The speaker defines a “compromise assessment” as a structured way to answer the core security question:

“Does the attacker live in our infrastructure/network?”

It is presented as a non-chaotic, hypothesis-driven approach—not “search everything and hope to find something.” The workflow is designed to be:

• Repeatable and multi-stage
• Able to improve detection over time
• Capable of evolving into incident response when active threats are identified

What the approach emphasizes

• Asset inventory, including “shadow”/forgotten systems
• Telemetry evaluation (understanding what you can and cannot see)
• Threat modeling aligned to the organization’s reality (including regulated/biotech constraints)
• Evidence-based hypothesis testing using specific artifacts and log sources
• Remediation and documentation so the organization becomes safer over time

Key limitations to remember

• If logging/telemetry is weak or missing, compromise assessment cannot fully compensate.
• “No evidence” is not proof of “no compromise.” It may simply reflect telemetry gaps.

Practical guidance included

• Change management
• Cross-functional involvement (e.g., legal/compliance)
• Supplier risk considerations
• Automation where reasonable

---

Methodology: the “7 stages” of compromise assessment

The speaker describes the workflow as seven main stages:

1. Asset inventory (start here)

Purpose: identify what exists on the network, including shadow assets and systems not properly recorded.

• In a biotech/pharma context, inventory includes both:
  • IT systems
  • Lab equipment
• Key focus areas:
  • Workstations/servers/lab devices
  • Who has access
  • Service accounts created locally but unknown to security
  • Legacy systems that cannot be removed (e.g., older lab OS versions required for operations)

2. Build telemetry understanding (what data you can collect)

Evaluate what data sources are available to determine detection coverage.

Example sources mentioned:

• Active Directory
• Security logs
• Backup/archive-derived information
• Cloud logs / mail telemetry
• EDR and other security tool telemetry

Special note: some production segments may be poorly logged due to constraints and legacy support issues.

3. Select tools (tools are means; people are key)

Decide what tools support the process (commercial or open source).

A key practice:

• Work with copies/backups of what you will analyze:
  • Take a backup first
  • Then collect information from target hosts

4. Threat modeling

Not done “for the sake of process,” but to improve security decisions.

Goal: understand relevant threats and then adjust:

• Detection logic
• Tooling and security-tool coverage

The threat model includes organization-specific realities, notably biotech/pharma risks:

• Threats relevant to IP collection
• Expertise tied to pharmaceutical development
• Industrial espionage
• Insider risks
• Attacks via suppliers and contractors

The speaker also mentions using a visualization approach/tool (e.g., navigator from “MROTC”) based on intelligence/vendor reports and infrastructure behavior.

5. Form hypotheses + define coverage

Core principle: hypothesis-driven, not random searching.

For each hypothesis, define:

• The set of artifacts
• The log sources needed to verify/confirm it

Hypotheses can be triggered by real signals (e.g., contractor compromise or abnormal behavior).

6. Analyze logs/artifacts; forensics and escalation

Collect data from potentially involved systems (e.g., VMs, workstations), then perform forensic analysis to reconstruct the compromise chain.

Escalation rule:

• If the threat appears still active (e.g., ongoing suspicious external connections or exfiltration at abnormal times), the process can shift into full incident response.

7. Reporting + remediation (must end with actions)

Every assessment should produce a practical outcome, including:

• A correction/remediation plan
• Updates to detection logic
• Extended log storage depth
• Installation or adjustment of security systems on certain hosts
• Review/change of backup scope and frequency
• Review of contractor access and related controls

It also includes regulatory/legal considerations:

• Engage cross-functional colleagues (IT + lawyers/compliance) for evidence and auditability in regulated environments.

---

Checklist: integrating compromise assessment into daily processes

Practical recommendations include:

• Mandatory first step: inventory
  • Don’t assess what you cannot see.
• Evaluate telemetry before hypotheses
  • Understand blind spots and logging gaps first.
• Use a risk-oriented approach
  • Prioritize based on business context (e.g., production segments first).
• Run compromise assessment regularly
  • If one run finds nothing, continue refining hypotheses and improving detection.
• Discuss findings with the business
  • Ensure remediations are implementable; involve stakeholders.
• Work with suppliers/contractors
  • Treat supplier/contractor access and risk as part of threat modeling and mitigation.
• Document everything
  • Supports continuity over time and prevents restarting from scratch.
• Choose sensible automation
  • Automate where justified to reduce labor costs without losing quality.
• Manage expectations
  • It’s not a “magic pill,” but it reduces risk by improving visibility, detection logic, and response readiness.

---

Case studies / practical examples mentioned

Case 1: Contractor-related lab system slowdown

• A contractor reported that lab equipment became slow.
• Hypothesis development led to finding suspicious long-term connections from unusual locations within the R&D segment tied to the contractor account.
• Remediation included:
  • Tighten segmentation
  • Improve control of contractor sessions
  • Restrict services/IPs and enable session auditing
• The hypothesis moved from assessment into active response.

Case 2: “Murky device update” (possible tampered update/bootloader mimic)

• After a contractor-performed update, suspicious behavior was observed (bootloader mimicking legitimate software).
• Executable hashes from the update sources differed, indicating tampering/maliciousness.
• Remediation included:
  • Implement integrity control for binaries
  • Revise the update/install process

Case 3: Researchers’ workstation compromise

• Suspicious behavior triggered collecting memory and hard-drive dumps.
• Analysis showed scripts exfiltrating files to external resources at a regular frequency.
• Remediation:
  • Close/contain the incident quickly (the assessment escalated into investigation/response)

---

Speakers or sources featured

Speaker/Presenter

• An unnamed main speaker (the talk author/host introducing and delivering the compromise assessment report)

Speakers in the Q&A (names mentioned)

• Vladislav
• Zaynura
• Danil
• Egor Filatov
• Helen
• Stanislav

Tools/Products referenced

• Falcon Discover
• Velociraptor
• “MROTC navigator” (for visualizing threat model data)
• CMDB
• Nmap/network scanning (implied by scanning and comparing to CMDB/golden image)
• DNS / NetFlow (noted as “nafow,” likely NetFlow)
• iREGENTs (for host control)
• “Discoverovery” (asset discovery solution mentioned by name)