In this module, you will learn to apply the Operations Security (OPSEC) process to a network deployment. You will evaluate how planned network operations might leak critical information to adversaries before applying defensive controls.
Your organization is preparing to deploy a new Centralized Log Management and SIEM infrastructure. The deployment is currently in the planning and staging phase.
The security team has already identified that the SIEM architecture, IP schemes, and staging domain names are Critical Information (Step 1). They have also established that the primary threat is an Advanced Persistent Threat (APT) group known to monitor public OSINT sources to map out target infrastructure (Step 2: Analysis of Threats).
As a Network Defender, you are reviewing the deployment plan to identify any observable indicators that might leak out, and matching them against the APT's known passive reconnaissance capabilities.
Deployment Plan Review - OPSEC Evaluation Phase
The network team is planning a deployment and intends to request a public SSL certificate for an internal staging server. The OPSEC review flagged this action because public certificates are logged in Certificate Transparency (CT) logs, which are observable by anyone on the internet.
The defender is proactively evaluating the deployment plan to find OPSEC indicators (the CT log entry) and comparing them against the adversary's capabilities (automated CT log scraping).
Analysis of Vulnerabilities is the 3rd step of the OPSEC process. A vulnerability exists when the adversary is capable of collecting an OPSEC indicator, analyzing it, and using it against you. This step strictly involves matching your exposed indicators with their collection capabilities.
Identification of Critical Information (Step 1) defines what needs protecting. Analysis of Threats (Step 2) identifies the adversary and their general intent. Assessment of Risk (Step 4) calculates the impact and probability of the vulnerability being exploited. Application of Appropriate OPSEC Measures (Step 5) is when you actually fix the issue.
Because this vulnerability was discovered during planning, the defensive action (Step 5) would be to use an internal private Certificate Authority (CA) or a wildcard certificate (*.corp.com) so the specific "siem-staging" hostname is never leaked to public CT logs.
Master storage protocols, disaster recovery, and network analysis.
Explore more CND simulations