Apply a minimal-exposure security baseline

Chapter overview

Bottom line: Use only offline worksheets to check secrets, permissions, network exposure, and approval records. You will not modify firewalls, credentials, accounts, networks, or running systems.

Purpose

Identify four categories of gaps in minimum exposure governance and assign responsibilities and stop states to each gap.

Prepare

A blank four-column worksheet with pinned sources; do not collect live-environment values.

Time

About 15 minutes

System change

Do not modify permissions, secrets, or networks; perform only an offline minimum-exposure review.

Expected result

Identify gaps in permissions, secrets, network exposure, and approval workflows without disclosing live-site data.

Stop conditions

• The task requires exposing credentials, tokens, endpoints, accounts, or network topology.
• The task requires relaxing permissions, opening a network, or disabling security controls.

Scope and safety boundaries

The worksheet is not a permission to change. Safe work is limited to offline, read-only pinned sources or placeholder classification that never accesses an execution environment. Read-only viewing of any live/running environment is approval-required.

• Safe: Only field categories, responsibility roles and gap status are sorted, and live-environment content is not read.
• Isolated test: The project must have clear written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan; not covered in this chapter.
• Approval required: Any proposal to view or change the running environment falls into this category, even if it is a read-only view.
• Never automate: Do not read or write groups, send a KNX telegram, perform ETS programming or downloads, connect a KNX interface or bus, or control physical equipment. The test bus is no exception.

Joining the repository, installing or starting also requires full isolation gates, written approval, approved immutable artifact/image digest and source-to-build attestation. Stop if any evidence is lacking.

Core concepts

Secrets grant access directly, while environment-identifying data reveals asset relationships. Neither belongs in public guides, screenshots, log excerpts, work orders, or submission records.

Preparation and prerequisites

Draw four columns before collecting any information. The column names are Secrets, Permissions, Network Exposure, and Approval Records.

• Each column has requirements, ownership roles, approval status, expiration policy, revocation method and evidence limit.
• The secret column only writes "exists", "not entered into the record", and "pending controlled review", and no values are copied.
• In the permission column, only the ability categories such as reading, changing, approving or reviewing are written, and the account number or person's name is not filled in.
• In the network column, only the trust boundary category, requirements, and deadline policies are filled in. Do not fill in the host, address, endpoint, or topology.
• In the approval column, only the approval role, controlled record reference, scope and abstract expiration status are written, and no signature or personal certification is included.

Time data rules: Environment/event timestamps, log timestamps, backup creation times, execution times, or any time that can be associated with family activities/system events are not allowed. When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, the reviewed formalized policy deadline or abstract expiration status can be used. When precise dates are not required, relative/status classifications such as "not expired", "to be renewed", and "expired" are preferred.

Immediately stop the worksheet process when secrets, environmental identification, unknown sources, requests to extend rights, or requests to modify security controls occur.

Steps

This review will only produce a list of gaps. It does not produce settings, commands, or live results.

1. State the necessary purpose first. Each column addresses only one requirement. Mark any item without an explainable purpose as a risk to remove.
2. Check the secret column. Confirm that public records only show confidential processing status. Sharing stops when any secret value appears.
3. Check the permissions column. Separate reads, changes, approvals and reviews. Record missing expiration policies, revocation methods, or owning roles as gaps.
4. Check the network-exposure column. Use trust boundary categories to describe necessary interfaces. Exposures that do not have a purpose, role, or duration policy are listed as gaps.
5. Check the Approval Record column. Verify that each exception has scope, approval role, expiration policy, revocation conditions, and controlled record references.
6. Do an independent review. Check four columns and data minimization by different roles. The conclusion should only be written as "complete", "with gaps" or "stopped due to insufficient data".

When filling in the deadline: Environment/event timestamps, log timestamps, backup creation times, execution times, or any time that can be associated with family activities/system events are not allowed. When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, the reviewed formalized policy deadline or abstract expiration status can be used. When precise dates are not required, relative/status classifications such as "not expired", "to be renewed", and "expired" are preferred.

Verification and evidence

The valid result is a de-identified governance list. It does not indicate that any controls have been applied in a production environment.

• The secret field has no credentials, tokens, sessions, passwords, cookies, or retrievable connection information.
• The permission column separates read, change, approval and review, and records deadline policies and cancellation responsibilities.
• The network exposure column contains only requirements, trust boundary categories, owning roles, and expiration policies.
• Each exception has an approval role, scope, abstract expiration status, and revocation conditions.
• The record has no host, endpoint, account, path, serial number, address, topology or environment name.
• Environment/event timestamps, log timestamps, backup creation times, execution times, or any time that can be associated with family activities/system events are not allowed.
• When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, the reviewed formalized policy deadline or abstract expiration status can be used. When precise dates are not required, relative/status classifications such as "not expired", "to be renewed", and "expired" are preferred.
• All field controls, execution environments, buses, ETS and integration results remain unproven.

Next step: Go to Chapter 19, put the link symptoms in the file into the offline distribution table.

Troubleshooting

• A field appears to require live values: Change it to a data category and mark “Controlled review required.” Do not bring values into the worksheet.
• A permission has no owning role: Mark it as a governance gap and stop adding new permissions.
• Network exposure has no expiration policy: Mark it incomplete. Do not replace a missing decision with permanent exposure.
• Only verbal approval exists: Treat the item as unapproved and keep it stopped.
• Someone asked to modify the firewall or credentials: Refuse. This chapter is an offline worksheet and does not provide firewall, credential or live system change procedures.
• The environment can still be identified after masking: Remove more context, or use text-only category summaries instead.

FAQ