DOCSEARCHbyAlgolia
Submit Docs

Stand der Technik Bibliothek

repository·main·Indexed 43 days ago

https://github.com/bsi-bund/stand-der-technik-bibliothek

A library of machine-readable BSI security regulations provided in OSCAL (Open Security Controls Assessment Language) format. It features a Control Layer for security requirements (catalogs, profiles, and mappings), an Implementation Layer for reusable component definitions, and an Assessment Layer for audit artifacts. The library includes controlled vocabularies and namespace definitions in CSV and TXT formats to ensure uniform categorization and linking of security content.

Tokens
3.5K
Snippets
1
Records
18
Agent score
57%

What's inside Stand der Technik Bibliothek

  1. Overview of Namespace Definitions

    main

    The Namespace Definitions provide controlled vocabularies and supplementary term definitions for the Stand der Technik Bibliothek. They are used to ensure uniform description, categorization, and linking of machine-readable content.

    These definitions act as a glossary rather than an exhaustive list of allowed field contents. For example, in the result field of a sentence template, free text is permitted. A term is only included in result.csv if it is not defined in the Duden or German Wikipedia, or if it is used there with a deviating meaning.

  2. Overview of the Stand der Technik Bibliothek

    main
    The Stand der Technik Bibliothek provides structured collections of BSI security regulations following the current state of the art in information and cyber security. The content is published as machine-readable OSCAL (Open Security Controls Assessment Language) documents. This framework enables a data-centric approach to security documentation and compliance processes. For detailed information on the data structure, refer to the OSCAL documentation.

  3. Overview of the Control Layer

    main

    The Control Layer provides machine-readable, standardized collections of security requirements. It serves as a structured data foundation to document control specifications in an unambiguous and automatable way using the OSCAL (Open Security Controls Automation Framework) standard.

    The layer consists of:

    • OSCAL Catalogs: Collections containing individual security requirements.
    • OSCAL Profiles: Used to select and customize specific requirements from catalogs.
    • Resolved OSCAL Catalogs: Catalogs that have been expanded/resolved from profiles.
    • Mapping Collections: Used to map different catalogs to one another.

    By using OSCAL catalogs, the traditional manual process of security documentation is replaced with a data-centric approach, enabling more efficient and consistent management of security and compliance requirements.

  4. Overview of the Assessment Layer

    main

    The Assessment Layer is designed to handle machine-readable OSCAL (Open Security Controls Assessment Language) artifacts used for the planning, execution, and follow-up of assessments.

    Key artifact types supported or intended for this layer include:

    • Assessment Plans
    • Assessment Results
    • Plans of Action and Milestones (POA&M)

    Note: As of the current version, no specific artifacts have been published in this area.

  5. What is OSCAL and how does it work?

    main

    The Open Security Controls Assessment Language (OSCAL) is a standardized, machine-readable framework developed by NIST to improve the efficiency and consistency of information security documentation. It transforms static documents into structured data (XML, JSON, or YAML), enabling automation across the entire compliance lifecycle.

    Core Functionality

    • Structured Data: Uses XML, JSON, or YAML to represent requirement catalogs, implementation plans, and assessment plans.
    • Automation: Enables automated validation, analysis, and reporting of security controls.
    • Interoperability: Allows consistent information sharing across different systems and teams.

  6. Locate usable artifacts and source files in the Control Layer

    main

    Directly usable artifacts (such as resolved catalogs or mappings) are located in subdirectories assigned to specific subject areas (fachlich zugeordnet).

    If a subject area contains its own machine-readable source catalogs and profiles, they are stored within that subdirectory under the sources/ folder.

  7. Structure of an OSCAL file

    main

    OSCAL files (Catalogs, Profiles, or SSPs) are typically written in XML, JSON, or YAML. A standard file consists of three main parts:

    1. Metadata: General information such as title, last-modified, and organization.
    2. Main Body: The core content, which varies by type:
      • Catalog: A list of controls organized into groups.
      • Profile: Instructions on which catalog to import and which controls to include/modify.
      • SSP: System information, system components, and the implementation status/evidence for each requirement.
    3. Back-Matter (Optional): References to additional resources like policy documents or diagrams.
    metadata:
  title: "Grundschutz++ Kompendium 2026"
  last-modified: 2025-09-10
  organization: "Bundesamt für Sicherheit in der Informationstechnik"

controls:
  - id: "BER.1.1"
    title: "Verfahren und Regelungen"
    description: "Regelt die Verwaltung von Benutzerkonten."

back-matter:
  resources:
    - title: "Zugriffsrichtlinien"
      href: "https://example.com/zugriffsrichtlinien.pdf"

  8. Understand the main components of OSCAL

    main

    OSCAL is organized into several document structures that model different aspects of security controls:

    1. Catalogs: A collection of security requirements (e.g., ISO 27001 Annex A or BSI Grundschutz++) organized into groups or families. All other OSCAL documents are based on these catalogs.
    2. Profiles: Used to select and customize requirements from one or more catalogs. Profiles allow you to import, remove, or modify requirements and set specific parameter values while maintaining traceability to the original catalog.
    3. Implementation Layer: Describes how requirements are actually met.
      • System Security Plan (SSP): Documents how selected requirements are fulfilled in a specific system, including technical configurations and organizational policies/procedures.
      • Component Definition: Reusable templates describing the properties of a component (hardware, software, policy, process, etc.) that can be referenced in multiple SSPs.
    4. Assessment Layer: Focused on audits and evidence.
      • Assessment Plan: Describes how an assessment should be conducted (steps, criteria, responsibilities).
      • Assessment Results: Documents the actual results of assessments (manual or automated).
      • POA&M (Plan of Action & Milestones): Defines measures, deadlines, and responsibilities for remediating identified gaps or vulnerabilities.

  10. Understand OSCAL Component Definitions

    main

    An OSCAL Component Definition is a collection of components that describes how specific implementations (hardware, software, services, policies, processes, or procedures) support or implement requirements from OSCAL catalogs or profiles.

    Key characteristics:

    • Descriptive, not functional: They do not provide the actual implementation; they describe an implementation that can be used within an information system (e.g., describing that "SSH over TLS 1.3 is used" rather than providing the SSH service itself).
    • Reference material: They serve as references to help organizations build comprehensive and consistent System Security Plans (SSP) by importing solution descriptions instead of creating them from scratch.
    • Use cases: They are used by product/service providers and policy owners to exchange information about how requirements are met.

    Examples of components include:

    • TLS configurations
    • Apache Webserver settings
    • Debian Linux OS configurations
    • End-user training programs

  11. Understanding the library layers

    main

    The library is organized into distinct layers representing different stages of security documentation and assessment:

    • Control Layer: Contains catalogs, profiles, resolved catalogs, and mappings. This is the primary source for security requirements.
    • Implementation Layer: Contains reusable descriptions of concrete implementations (e.g., products, services, or workflows).
    • Assessment Layer: Reserved for future machine-readable artifacts intended for the planning, execution, and follow-up of security audits/assessments.