Maintaining reliable audit logs for physical access events is a core requirement of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (PE.L2-3.10.4); this post provides a practical, step-by-step approach to configuring door access control systems and integrating them with a SIEM so small and mid-sized organizations can produce, protect, and retain the audit evidence required for compliance and incident response.
\n\nPE.L2-3.10.4 requires organizations to generate and retain audit records that capture physical access attempts and events relevant to Controlled Unclassified Information (CUI) protection. Practically, this means your door controllers, readers, controllers, and associated sensors must log who attempted access, when, where (which door), the result (granted/denied), and supporting context (credential type, reader ID, sensor triggers), and these logs must be collected, time-synchronized, protected against tampering, and retained according to your policy.
\n\nStart at the source: confirm that each access control device (panel, reader, controller, management server) is configured to log all relevant event types (access granted/denied, door forced, door held open, credential enrollment/deletion, admin logins). Turn on verbose logging where available, and disable local log rotation that loses entries prematurely. Enable secure management (HTTPS/SSH) for the admin interfaces and ensure the device firmware is current to avoid known logging bugs. Example fields to capture for each event: timestamp (UTC), device_id, reader_id, card_id/user_id, event_type/event_id, event_result, operator_account (if admin action), and correlator IDs for video or alarms.
\n\nUse secure, reliable transport for forwarding logs. Preferred options: syslog over TLS (RFC 5425), HTTPS-based API forwarding, or an authenticated SFTP/SMB drop when APIs aren't available. If devices can't natively speak TLS syslog, deploy a local collector (small VM or appliance) that receives plain syslog from the controller on an internal network and then forwards to the SIEM over TLS. Always enforce firewall rules so access control systems can only reach the collector/SIEM endpoints and not the public internet.
\n\n# Example syslog-ng destination to a SIEM over TLS\ndestination d_siem {\n tcp(\"10.0.2.10\" port(6514) tls(\n ca-dir(\"/etc/ssl/certs\")\n key-file(\"/etc/syslog-ng/cert.key\")\n cert-file(\"/etc/syslog-ng/cert.crt\")\n ));\n};\nlog { source(s_local); destination(d_siem); };\n\n\nNormalize raw messages into a consistent schema so you can query \"access granted/denied\" across multiple vendors. Map vendor fields to canonical names: deviceVendor, deviceProduct, deviceEventClassId, userId, objectId (door), outcome, eventTime, and sourceIPAddress (if applicable). Use CEF/LEEF or JSON mappings if your SIEM supports them. Enrich access events by correlating userId with Active Directory (or your IdP) to attach employee roles and CUI access privileges, and correlate door events with motion sensors or video system timestamps for forensic context.
\n\n# Example normalized CEF-style output your SIEM should accept\nCEF:0|ACME|DoorControl|1.2|1001|Access Attempt|5|dvc=door-controller-01 src=reader-3 suser=jsmith outcome=success cs1Label=cardId cs1=123456 cs2Label=doorName cs2=\"Server Room\"\n\n\n
Configure SIEM rules to alert on critical physical events: repeated denied attempts (brute force), access outside of authorized schedules, door forced/open alarms, admin account changes, or badge cloning anomalies (same badge in two doors at impossible times). Implement time synchronization (NTP/chrony) across controllers, collectors, and SIEM so event order and correlation are reliable. Protect logs with immutability measures (WORM storage or object-lock), encrypt logs at rest, restrict log access with RBAC, and retain logs according to an organizational policy tied to CUI handling — a common operational baseline is 1 year readily accessible and 3–6 years archived, subject to contract or regulatory demands.
\n\nExample: A 50-person engineering firm managing CUI has a cloud-hosted access control system (e.g., Kisi/Openpath) and an on-prem door controller for the server room. The firm deploys a lightweight collector VM that (1) receives syslog from the on-prem controller, (2) polls the vendor API for cloud events, (3) normalizes both feeds to JSON and forwards them to the corporate SIEM over TLS. They map badge IDs to AD usernames nightly and create SIEM alerts for server-room access outside core hours and for \"credential revoked\" events that still produce access-granted outcomes — an immediate sign of stale permissions or cloning. This arrangement provides demonstrable, searchable chains of custody for CUI-area access events during audits.
\n\nCompliance tips: maintain a written logging policy that references PE.L2-3.10.4, perform periodic log integrity checks and retention audits, document the end-to-end flow (device → collector → SIEM → archive), and include physical logs in your incident response tabletop exercises. Best practices include using vendor-neutral fields for event normalization, implementing tamper-evident storage, and ensuring privileged access to logs is logged itself. Risks of not implementing include inability to investigate incidents (lost forensic trail), failure in compliance audits (leading to contract loss or remediation orders), and increased likelihood of undetected physical breaches that can lead to CUI exposure.
\n\nIn summary, meeting PE.L2-3.10.4 requires deliberate configuration of access control logging, secure and time-synchronized forwarding to a SIEM, normalization and enrichment of events, and controls for alerting, retention, and integrity; for small businesses this is achievable with a collector + SIEM pattern, disciplined policies, and a few key technical controls (TLS syslog, NTP, RBAC, and immutable storage) that collectively provide the audit trail auditors and incident responders need.
", "plain_text": "Maintaining reliable audit logs for physical access events is a core requirement of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (PE.L2-3.10.4); this post provides a practical, step-by-step approach to configuring door access control systems and integrating them with a SIEM so small and mid-sized organizations can produce, protect, and retain the audit evidence required for compliance and incident response.\n\nUnderstanding PE.L2-3.10.4 and what it means in practice\nPE.L2-3.10.4 requires organizations to generate and retain audit records that capture physical access attempts and events relevant to Controlled Unclassified Information (CUI) protection. Practically, this means your door controllers, readers, controllers, and associated sensors must log who attempted access, when, where (which door), the result (granted/denied), and supporting context (credential type, reader ID, sensor triggers), and these logs must be collected, time-synchronized, protected against tampering, and retained according to your policy.\n\nImplementation steps — component by component\nEnable and harden logging on the access control system\nStart at the source: confirm that each access control device (panel, reader, controller, management server) is configured to log all relevant event types (access granted/denied, door forced, door held open, credential enrollment/deletion, admin logins). Turn on verbose logging where available, and disable local log rotation that loses entries prematurely. Enable secure management (HTTPS/SSH) for the admin interfaces and ensure the device firmware is current to avoid known logging bugs. Example fields to capture for each event: timestamp (UTC), device_id, reader_id, card_id/user_id, event_type/event_id, event_result, operator_account (if admin action), and correlator IDs for video or alarms.\n\nTransport logs securely to your SIEM\nUse secure, reliable transport for forwarding logs. Preferred options: syslog over TLS (RFC 5425), HTTPS-based API forwarding, or an authenticated SFTP/SMB drop when APIs aren't available. If devices can't natively speak TLS syslog, deploy a local collector (small VM or appliance) that receives plain syslog from the controller on an internal network and then forwards to the SIEM over TLS. Always enforce firewall rules so access control systems can only reach the collector/SIEM endpoints and not the public internet.\n\n# Example syslog-ng destination to a SIEM over TLS\ndestination d_siem {\n tcp(\"10.0.2.10\" port(6514) tls(\n ca-dir(\"/etc/ssl/certs\")\n key-file(\"/etc/syslog-ng/cert.key\")\n cert-file(\"/etc/syslog-ng/cert.crt\")\n ));\n};\nlog { source(s_local); destination(d_siem); };\n\n\nNormalize, parse, and enrich events in the SIEM\nNormalize raw messages into a consistent schema so you can query \"access granted/denied\" across multiple vendors. Map vendor fields to canonical names: deviceVendor, deviceProduct, deviceEventClassId, userId, objectId (door), outcome, eventTime, and sourceIPAddress (if applicable). Use CEF/LEEF or JSON mappings if your SIEM supports them. Enrich access events by correlating userId with Active Directory (or your IdP) to attach employee roles and CUI access privileges, and correlate door events with motion sensors or video system timestamps for forensic context.\n\n# Example normalized CEF-style output your SIEM should accept\nCEF:0|ACME|DoorControl|1.2|1001|Access Attempt|5|dvc=door-controller-01 src=reader-3 suser=jsmith outcome=success cs1Label=cardId cs1=123456 cs2Label=doorName cs2=\"Server Room\"\n\n\nAlerting, retention, and integrity controls\nConfigure SIEM rules to alert on critical physical events: repeated denied attempts (brute force), access outside of authorized schedules, door forced/open alarms, admin account changes, or badge cloning anomalies (same badge in two doors at impossible times). Implement time synchronization (NTP/chrony) across controllers, collectors, and SIEM so event order and correlation are reliable. Protect logs with immutability measures (WORM storage or object-lock), encrypt logs at rest, restrict log access with RBAC, and retain logs according to an organizational policy tied to CUI handling — a common operational baseline is 1 year readily accessible and 3–6 years archived, subject to contract or regulatory demands.\n\nSmall business scenario — practical example\nExample: A 50-person engineering firm managing CUI has a cloud-hosted access control system (e.g., Kisi/Openpath) and an on-prem door controller for the server room. The firm deploys a lightweight collector VM that (1) receives syslog from the on-prem controller, (2) polls the vendor API for cloud events, (3) normalizes both feeds to JSON and forwards them to the corporate SIEM over TLS. They map badge IDs to AD usernames nightly and create SIEM alerts for server-room access outside core hours and for \"credential revoked\" events that still produce access-granted outcomes — an immediate sign of stale permissions or cloning. This arrangement provides demonstrable, searchable chains of custody for CUI-area access events during audits.\n\nCompliance tips, best practices, and risks of non-implementation\nCompliance tips: maintain a written logging policy that references PE.L2-3.10.4, perform periodic log integrity checks and retention audits, document the end-to-end flow (device → collector → SIEM → archive), and include physical logs in your incident response tabletop exercises. Best practices include using vendor-neutral fields for event normalization, implementing tamper-evident storage, and ensuring privileged access to logs is logged itself. Risks of not implementing include inability to investigate incidents (lost forensic trail), failure in compliance audits (leading to contract loss or remediation orders), and increased likelihood of undetected physical breaches that can lead to CUI exposure.\n\nIn summary, meeting PE.L2-3.10.4 requires deliberate configuration of access control logging, secure and time-synchronized forwarding to a SIEM, normalization and enrichment of events, and controls for alerting, retention, and integrity; for small businesses this is achievable with a collector + SIEM pattern, disciplined policies, and a few key technical controls (TLS syslog, NTP, RBAC, and immutable storage) that collectively provide the audit trail auditors and incident responders need." }, "metadata": { "description": "Step-by-step guide to configure door access systems and integrate them with SIEM to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 PE.L2-3.10.4 audit logging requirements.", "permalink": "/how-to-configure-and-integrate-door-access-systems-with-siem-to-maintain-audit-logs-for-nist-sp-800-171-rev2-cmmc-20-level-2-control-pel2-3104.json", "categories": [], "tags": [] } }