Establishes requirements for controlling access to OCSI systems, applications, and CUI data — covering 22 controls per NIST SP 800-171 Rev 2.
OCSI shall limit system access to authorized users, processes, and devices, and to authorized types of transactions and functions. Access to CUI shall be controlled based on the principle of least privilege and shall be limited to individuals with a legitimate need-to-know.
| Control | Requirement | Implementation | Status |
|---|---|---|---|
| 3.1.1 | Limit system access to authorized users, processes acting on behalf of authorized users, and devices | PARTIAL. Command Center requires login with SHA-256 hashed credentials via Web Crypto API. However: password is hardcoded in plaintext in source code (critical gap), authentication is client-side only (bypassable via DevTools), and there is only one shared admin account (no individual user accounts). | Partial |
| 3.1.2 | Limit system access to the types of transactions and functions that authorized users are permitted to execute | PARTIAL. Single admin role has full CRUD access. Public visitors see marketing content only. However, no RBAC exists — all authenticated users have identical full access. No granular permission model. | Partial |
| 3.1.3 | Control the flow of CUI in accordance with approved authorizations | CUI (candidate PII, clearance data, contract details) flows only through authenticated Command Center sessions. Public pages contain no CUI. Data export requires authenticated session. | Implemented |
| 3.1.4 | Separate the duties of individuals to reduce the risk of malevolent activity | NOT IMPLEMENTED. Single hardcoded admin account shared by all users. No role separation in the system. President and Security Officer roles defined organizationally but not enforced technically. No RBAC. | Not Implemented |
| 3.1.5 | Employ the principle of least privilege | PARTIAL. Public pages have no CUI access. However, any authenticated user has full admin privileges — no privilege differentiation exists. FTP credentials restricted to deployment personnel. | Partial |
| 3.1.6 | Use non-privileged accounts when accessing nonsecurity functions | Public website browsing requires no authentication. Administrative functions require separate authenticated login to Command Center. | Implemented |
| 3.1.7 | Prevent non-privileged users from executing privileged functions | All CRUD operations, data export, and system configuration functions are gated behind authenticated session. No elevated functions accessible without login. | Implemented |
| 3.1.8 | Limit unsuccessful logon attempts | PARTIAL. Account lockout after 5 failed attempts with 15-minute lockout exists in code. However, lockout state is stored in localStorage (client-side) and can be bypassed by clearing browser storage or using a different browser/device. | Partial |
| 3.1.9 | Provide privacy and security notices consistent with CUI rules | Login page displays security notice: "Authorized access only. All activity is monitored and logged." CUI handling notice in security protocols documentation. | Implemented |
| 3.1.10 | Use session lock with pattern-hiding displays after inactivity | 30-minute inactivity timeout triggers automatic session termination and redirect to login page. All dashboard content hidden. Mouse/keyboard activity resets idle timer. | Implemented |
| 3.1.11 | Terminate (automatically) a user session after a defined condition | 8-hour absolute session maximum regardless of activity. 30-minute inactivity timeout. Visual countdown warning displayed at 5 minutes remaining. | Implemented |
| 3.1.12 | Monitor and control remote access sessions | PARTIAL. All access is remote (web-based). Sessions logged in localStorage with timestamps and activity. However, logs are client-side only (max 500 entries), can be deleted by the user, and no server-side monitoring exists. | Partial |
| 3.1.13 | Employ cryptographic mechanisms to protect the confidentiality of remote access sessions | PARTIAL. HTTPS/TLS in transit. SHA-256 hashing via Web Crypto API. However, the plaintext password is hardcoded in source code (negating the hash), and SHA-256 is not recommended for password hashing (bcrypt/Argon2 preferred). | Partial |
| 3.1.14 | Route remote access via managed access control points | All access routes through the single web application endpoint (ocsi.co). No alternate access paths. FTP access for deployment only. | Implemented |
| 3.1.15 | Authorize remote execution of privileged commands | Privileged operations (data management, export, configuration) require active authenticated session. Administrative commands executed only within Command Center context. | Implemented |
| 3.1.16 | Authorize wireless access prior to allowing such connections | Organizational policy: wireless access to OCSI systems must use WPA3 or VPN. Web application access follows standard HTTPS regardless of network type. | Implemented |
| 3.1.17 | Protect wireless access using authentication and encryption | All web access encrypted via TLS/HTTPS. Wireless-specific controls enforced by organizational network policy (WPA3 minimum). | Implemented |
| 3.1.18 | Control connection of mobile devices | Web application is responsive and accessible from mobile devices. Same authentication and session controls apply. No native mobile apps — web-only access reduces attack surface. | Implemented |
| 3.1.19 | Encrypt CUI on mobile devices and mobile computing platforms | NOT IMPLEMENTED. CUI in localStorage is stored in plaintext JSON — no application-level encryption at rest. Same-origin policy provides isolation but NOT encryption. Device-level encryption depends on user device configuration (not enforced). This is a critical gap. | Not Implemented |
| 3.1.20 | Verify and control/limit connections to and use of external systems | External connections limited to: Google Fonts (styling), FontAwesome (icons). No CUI transmitted to any external service. CSP headers restrict allowed external connections. | Implemented |
| 3.1.21 | Limit use of portable storage devices on external systems | Organizational policy: portable storage devices containing CUI must be encrypted. Data export from Command Center produces CSV files subject to CUI handling procedures. | Implemented |
| 3.1.22 | Control CUI posted or processed on publicly accessible systems | Public website pages contain zero CUI. All CUI (candidate records, job orders, client data) is isolated within the authenticated Command Center behind login. | Implemented |