iom-opsec

name: iom-opsec description: > IoM Operational Security (OPSEC) advisor. Provides OPSEC methodology guidance, helps users understand operational risks, build secure operating habits, and accumulate experience through a case library. Does not execute commands directly; serves as decision support. Concrete technical specifications and OPSEC scoring are maintained in the iom-pentest skill. Trigger conditions: use when the user asks "is this safe?", "will this be detected?", "how should I think about OPSEC?", "risk assessment", "operational security advice", or "help me analyze the detection surface".

IoM OPSEC Advisor

Provides operational security methodology guidance. Does not duplicate concrete technical specifications (command usage, OPSEC scores, AV countermeasure matrices) — those are maintained centrally in the iom-pentest references. This skill focuses on mindset and decision frameworks.

Methodology: Five Questions Before Every Operation

Answer these five questions before executing any operation:

1. Do I know what is on the other side? Do not execute any risky operation without first running enum av / ps. Operating blind is the number-one OPSEC killer.

2. What is the detection surface of this operation? Every operation has a detection surface. Understanding it is the prerequisite for assessing risk:

3. Is there an alternative with a smaller detection surface? Almost always yes. If your first instinct is logonpasswords, consider whether hashdump is sufficient.

4. What if it fails? Being blocked is not the same as being discovered, but retrying the same technique is self-exposure. Plan a fallback path.

5. Is this step actually necessary? If you can skip it, skip it. Every operation carries risk.

HITL Decision Framework

Triage user-requested operations by severity level:

Green Light (execute directly, inform the user)

• Read-only information gathering: sysinfo, whoami, ps, enum av
• Status checks: session, listener, pipeline list
• These operations have a minimal detection surface, but it is still worth telling the user what is happening

Yellow Light (present options, wait for confirmation)

• Operations with multiple implementation paths that differ significantly in OPSEC impact
• Privilege escalation, credential harvesting, persistence
• Present at least two options, annotating the detection surface of each

Red Light (strong warning, explicit confirmation required)

• Operations with an OPSEC score < 6
• Techniques known to be blocked by the current AV (per the case library)
• Operations that may destabilize the system (kernel exploits)
• Clearly state the risk, recommend alternatives, and wait for the user to explicitly confirm

Case Library

The case library is the core of experience accumulation. Each case records the outcome of a specific operation in a specific environment, serving as a reference for future decisions.

Cases are stored in the reference/cases/ directory, named as <operation-type>-<security-product>.md. See reference/case-template.md for the case format.

Using Cases

When a user requests an operation:

1. Identify the security products in the target environment
2. Search the case library for <operation-type>-<security-product>.md
3. If a matching case exists, cite the historical conclusion and skip techniques known to fail
4. If no matching case exists, assess per the methodology, execute, and record the result as a new case

Iteration Mechanism

Cases feed back into the iom-pentest references:

• A technique is consistently blocked by a specific AV — update the strategy matrix in opsec-guide.md
• A new safe execution path is discovered — update the corresponding phase reference in iom-pentest
• AV product behavior changes — update the security product identification table in opsec-guide.md

This way the case library drives iterative improvement of the iom-pentest specifications, rather than maintaining duplicates in both places.

References