Skip to content

AGENTS.md

Latest commit

 

History

History
51 lines (36 loc) · 2.97 KB

AGENTS.md

File metadata and controls

51 lines (36 loc) · 2.97 KB
Raw

Security Target Contribution Guide

This document outlines the requirements and logic for completing the Security Target (ST) for the IoT Platform (SecurityTargetN5GEH.md). Its purpose is to ensure that the information provided to the external security evaluators is technically sound, consistent, and covers all necessary boundaries.

1. Document Objective

The goal of the ST document is to define the Target of Evaluation (TOE). This is not just a product description; it is a formal boundary that tells evaluators exactly what is being tested (and what is excluded) to ensure the security evaluation is focused and cost-effective.

2. Core Section Guidance

Phase 1: Definition (Sections 1 & 2)

  • Goal: Provide the "Who, What, and Where."
  • Requirements:
    • TOE Identification: Use specific version numbers for firmware, hardware revisions, and cloud software modules.
    • Usage & Environment: Clearly distinguish between the Internal Environment (what we control) and the Operational Environment (the customer’s network, physical site, or third-party cloud).

Phase 2: The Security Perimeter (Section 3)

This is the most critical part of the document. It must follow a logical "Traceability Chain":

  1. Assets (3.3): Identify what is valuable (e.g., User Credentials, Firmware Integrity, PII, Sensor Data).
  2. Threat Model (3.4): Define who wants to attack (e.g., Remote Hacker, Malicious Insider) and how they might do it.
  3. Security Functions (3.5): List the technical defenses (e.g., AES-256 Encryption, Secure Boot, OAuth 2.0).
  4. Threats vs. Assets Mapping (3.6): This table must prove that for every Threat, there is a Security Function protecting the Asset.

Phase 3: Scope (Sections 4)

  • Limits of Evaluation: Be explicit about what is out of scope. If the evaluation is for the IoT Gateway hardware, the mobile app used to configure it might be excluded to save time/budget.

3. Reference Standards

All contributors should align their descriptions with the following standards (also referenced in the template):

  • RFC 8446: For TLS 1.3 implementations.
  • Common Criteria (ISO/IEC 15408): The foundational logic for the "Target of Evaluation" terminology.
  • Platform Specifics: Any industry-specific regulations (e.g., ETSI EN 303 645 for consumer IoT).

4. Maintenance & Versioning

  • Updates: Any change in the IoT platform’s features or architecture must trigger a review of the "Threats vs. Assets" matrix.
  • Drafting: Use the Document History table in the main template to track technical changes during the pre-evaluation phase.

Quick Checklist for Final Review

  • Is the TOE version clearly identified?
  • Are the "Assumptions" realistic (e.g., "The user will not share their password")?
  • Does every identified Threat have a corresponding Security Function?
  • Are the "Limits of Evaluation" clearly defined to prevent "scope creep" during the audit?