cve-dashboard/.kiro/steering/archer-template-gen.md

inclusion

inclusion
manual

Archer Template Content Generator

When this steering file is active, the user will provide a brief, informal description of a network device and its environment. Your job is to expand that into three formal Archer Risk Acceptance sections suitable for direct paste into the Archer application or into the STEAM Dashboard's Archer Template Library.

IMPORTANT: Web Search Step

Before generating content, you MUST use the web search tool to look up the specific vendor and model mentioned by the user. Search for:

1. "[Vendor] [Model] datasheet" — to get hardware specs, supported protocols, OS details, and form factor
2. "[Vendor] [Model] network security" or "[Vendor] [Model] hardening guide" — to find security-relevant capabilities

Use the search results to enrich the generated content with accurate, model-specific details such as:

• Exact OS name and base (e.g., "Junos OS Evolved" vs "Junos OS", "IOS-XR 7.x", "AOS-W")
• Supported interface types and throughput capacity
• Built-in security features (MACsec, hardware encryption, TPM, secure boot)
• Typical deployment role per vendor documentation
• Protocol support relevant to the environment (segment routing, EVPN, VXLAN, etc.)

If the search returns useful specs, weave them naturally into the Environment Overview. Do NOT just dump raw specs — integrate them into the Archer prose format.

Output Sections

Generate exactly three sections:

1. Environment Overview
2. Segmentation
3. Mitigating Controls

Rules

• Infer reasonable technical details from the device type, vendor, and role. If you know the platform OS (Junos for Juniper, IOS-XR for Cisco, EOS for Arista, embedded Linux for RPDs, ADTRAN-specific OS for OLTs), include it.
• Fill in standard security posture details based on the environment described (CTEC lab vs production field, internet-facing vs isolated behind VPN, etc.).
• Write as continuous prose with paragraph breaks between logical subsections. No bullets, no markdown headers, no formatting — this gets pasted directly into Archer text fields.
• If something is unknown from the input, make a reasonable assumption for the device class and state it naturally.
• Always include CrowdStrike/SentinelOne status — assume NOT installed on network infrastructure unless told otherwise.
• Always end Mitigating Controls with the authentication method (TACACS, ISE, RADIUS, local, etc.).

Section Structure

Environment Overview must include:

• What the device is and its function
• Operating system
• Typical deployment location
• Data categories: processed/transmitted (in transit) and stored (on device)
• General data processing flow: ingress, processing, egress, disposition
• Application/environment description with service/functionality
• Geographic deployment
• Applications in use

Segmentation must include:

• Network segmentation controls (VLANs, VRFs, routing policies, prefix lists, ASN isolation)
• Perimeter firewalls/PE ACLs with explicit deny/allow patterns
• Private addressing (RFC1918, no NAT to internet)
• Transport protection (MPLS, optical, IPsec, MACsec as applicable)
• Service hardening (disabled unused services, SSH v2, SNMPv3, TLS)
• Access controls restricting communications

Mitigating Controls must include:

• Internet accessibility posture (not accessible from public internet)
• External-facing services (none, or list what's internal-only)
• Controls restricting external access (ACL rules with specific allow/deny)
• Administrative access isolation (jump host/bastion, MFA, PAM, break-glass, OOB management)
• Endpoint security agent status (CrowdStrike Falcon, SentinelOne — typically not installed on network infra)
• Authentication method (TACACS+/Cisco ISE, RADIUS, local, etc.)

Reference Context

These are from approved Charter Red Network Archer exceptions for similar device classes:

• RPDs (Harmonic, Vecima): R-PHY devices in the field, embedded Linux, DOCSIS traffic, not internet-accessible, MPLS transport, TACACS/ISE auth
• OLTs (Adtran): PON service devices in CTEC, ADTRAN-specific OS, Blue VPN access only, null-routed external paths, TACACS auth
• vCMTS (Harmonic CableOS): Virtual CMTS cores, Linux-based, headend/datacenter, DOCSIS downstream/upstream, private MPLS transport

How to Use

The user will type something informal like:

Juniper PTX10003, Hub Core Router in CTEC. Backbone of the lab. Access behind Blue VPN. Routing policies and prefix lists limited to CTEC ASN. Junos.

You respond with the three generated sections, each clearly labeled, ready to copy into the template library.