Acme Federal System

The Acme Program Office maintains an Access Control policy and supporting procedures approved by the System Owner and issued to all AFS personnel through the program policy portal. The policy defines account types, authorization workflow, least-privilege expectations, and remote access rules for AFS. The ISSO reviews the policy annually and after any significant system change, and records the review in the program governance log.

AFS account management is performed by the ISSO and delegated System Administrators through the AFS Identity Console. Account types are Standard (case reviewer), Privileged (administrator), Service (system-to-system), and Emergency (break-glass). All account creations require a signed access request and supervisor approval recorded in the access management system. Standard accounts are reviewed quarterly; Privileged accounts are reviewed monthly. Accounts inactive for 35 days are automatically disabled; accounts inactive for 90 days are removed. Separation of personnel triggers same-day deprovisioning via the HR-to-AFS connector.

AFS enforces approved authorizations through role-based access control implemented in the application authorization layer. Each authenticated identity is mapped to exactly one AFS role (Case Reviewer, Supervisor, Administrator, or Auditor), and every API request is evaluated against the role's permission set before any case data is returned. Database access is restricted to the application service account; no interactive database logins are permitted for end users.

Information flows between AFS components and external partners are constrained by the API gateway policy set. Inbound partner submissions are accepted only over mTLS from allow-listed client certificates and are schema-validated before entering the workflow engine. Outbound flows are limited to audit forwarding to the enterprise SIEM; no other egress paths are permitted from the application subnets.

AFS separates duties by dividing case adjudication, supervisory approval, and system administration across distinct roles that cannot be held simultaneously by one account. Administrators can manage accounts and configuration but cannot adjudicate cases; reviewers and supervisors have no administrative privileges. Role assignments are approved by the System Owner and reviewed during the quarterly account review.

AFS applies least privilege by granting each role the minimum permissions required for its function and by issuing privileged accounts separately from a user's standard account. Privileged operations require re-authentication and are logged with the operator identity, action, and target. Service accounts are scoped to a single integration and hold no interactive login rights.

Authentication attempts are handled by the Lovable Federal Cloud identity-aware proxy, which locks an account after five consecutive invalid attempts within a 15-minute window and holds the lock for 30 minutes or until an administrator unlocks it. AFS records the lockout event in its own audit log and forwards it to the enterprise SIEM.

AFS displays the approved Acme Program Office system use notification banner before authentication completes. The banner states that the system is a U.S. Government information system, that use is monitored and recorded, and that unauthorized use may result in disciplinary or criminal action. The user must acknowledge the banner before the application session is established, and the acknowledgement is recorded in the audit log.

All AFS access is remote by design and is mediated by the LFC identity-aware proxy over TLS 1.2+ with PIV-backed authentication; there is no direct network path to AFS services from the public internet. Administrative access additionally requires membership in the privileged access group and originates from managed government workstations. Remote sessions are terminated after 15 minutes of inactivity.

The Acme Program Office maintains security awareness and training policy and procedures that apply to all AFS personnel, including contractors. The policy defines initial training requirements, annual refresh, and role-based training obligations, and is reviewed annually by the ISSM.

All AFS users complete agency security literacy and insider-threat awareness training before receiving an account and annually thereafter. Completion records are maintained in the agency learning management system; the ISSO reconciles the account roster against completion records each quarter and disables accounts that fall out of compliance.

Personnel with privileged AFS roles complete role-based training covering account management, secure configuration, audit review, and incident handling procedures before privileged access is granted and annually thereafter. Developers additionally complete secure coding training aligned to the program's SDLC requirements.

The Acme Program Office maintains an Audit and Accountability policy and procedures covering event selection, record content, retention, protection, and review responsibilities for AFS. The ISSO owns the procedures, and the ISSM approves them annually.

AFS generates audit records for authentication, authorization decisions, case lifecycle events, and administrator actions. Audit records are forwarded to the enterprise SIEM via the LFC audit pipeline. Coverage of read-only access events (queries, exports) is in progress and tracked as a POA&M item.

• [needs information] Audit coverage for read-only query and export events is not yet implemented

AFS audit records capture the event type, timestamp in UTC, originating source and client address, the authenticated subject identity, the affected case or object identifier, and the outcome of the event. Records are emitted in structured JSON so the enterprise SIEM can parse and correlate them without transformation.

The ISSO reviews AFS audit findings weekly using saved SIEM queries for failed authentications, privilege changes, and bulk case exports. Correlation rules generate real-time alerts for high-risk patterns, which route to the program security inbox and the on-call administrator. Review results and any follow-up actions are recorded in the monthly security posture report.

This control is inherited from the Lovable Federal Cloud FedRAMP-Moderate authorization package. See the LFC SSP, control AU-9, for implementation details. AFS configures the platform feature in accordance with LFC customer responsibilities.

Audit record generation is enabled at the application, API gateway, and database layers, and cannot be disabled by application users. The set of auditable events is defined in configuration managed under change control, and the ISSO is the only role authorized to request changes to audit event selection.

Configuration management policy and procedures for AFS are maintained by the Acme Program Office and define the change control board, change request workflow, emergency change handling, and baseline documentation requirements. The procedures are reviewed annually.

This control is inherited from the Lovable Federal Cloud FedRAMP-Moderate authorization package. See the LFC SSP, control CM-2, for implementation details. AFS configures the platform feature in accordance with LFC customer responsibilities.

AFS container images and infrastructure are built from hardened baselines defined as code and aligned to the applicable DISA STIG and CIS Benchmark settings for the underlying platform. Settings are enforced at deploy time by policy checks in the CI/CD pipeline; deviations require a documented exception approved by the ISSM. Configuration drift is detected by the platform compliance scanner and reported weekly.

AFS runs minimal container images with only the packages required by the application runtime; interactive shells, package managers, and compilers are excluded from production images. Network policy restricts each service to the specific ports and destinations it requires, and unused platform services remain disabled.

The AFS component inventory is generated from infrastructure-as-code state and the container registry on every deployment, and includes service names, image digests, versions, owners, and network exposure. The inventory is stored with the system record and reconciled against the platform asset inventory monthly.

Contingency planning policy and procedures for AFS are maintained by the Acme Program Office and define recovery roles, notification paths, plan testing requirements, and coordination with the LFC platform team. The plan and procedures are reviewed annually.

The AFS Contingency Plan documents a Recovery Time Objective of 8 hours and a Recovery Point Objective of 1 hour, identifies the recovery team and alternate contacts, and describes failover to the secondary LFC availability zone. The plan is exercised annually through a tabletop event with the System Owner, ISSO, and platform operations, and lessons learned are incorporated within 30 days.

AFS will use the LFC managed-database point-in-time recovery feature for the application database, with periodic logical exports to encrypted object storage in a separate account. Backup verification will be performed quarterly.

• [needs information] Backup frequency and retention period not yet defined
• [needs information] Off-site storage region not yet selected
• [needs information] Restoration test cadence not yet scheduled

AFS recovery is performed by redeploying infrastructure-as-code definitions into the recovery environment and restoring the application database from managed point-in-time recovery. Post-recovery validation includes configuration verification, an audit pipeline health check, and a sample case integrity review before the system is returned to service.

Identification and authentication policy and procedures for AFS are maintained by the Acme Program Office, covering identity proofing coordination, authenticator issuance, multifactor requirements, and account recovery. The ISSM approves the procedures annually.

Identification and authentication of organizational users is satisfied jointly by AFS and the Lovable Federal Cloud identity-aware proxy. Users authenticate to LFC using PIV credentials; LFC asserts a signed identity token to AFS over an authenticated channel. AFS verifies the token signature, maps the user to an AFS account, and enforces application-level role authorization. Multifactor authentication for privileged accounts is enforced by the LFC identity layer (PIV + cryptographic token).

Authenticators for AFS users are PIV credentials issued and managed under the agency's credentialing program; AFS itself stores no user passwords. Service account credentials are stored in the LFC key management service, rotated every 90 days, and are never embedded in source code or container images. Emergency break-glass credentials are sealed, stored in the program safe, and rotated after any use.

Non-organizational users do not access the AFS user interface. Partner agency systems authenticate as non-organizational entities using mutually authenticated TLS client certificates issued through the partner onboarding process, with each certificate bound to a single registered partner and revocable on request from the sponsoring agency.

Incident response policy and procedures for AFS are maintained by the Acme Program Office and align with the agency CSIRC handbook, defining severity classification, escalation timelines, evidence handling, and US-CERT reporting responsibilities. The procedures are reviewed annually.

Suspected AFS incidents are triaged by the ISSO with support from the agency CSIRC. Containment options include disabling affected accounts, revoking partner certificates, and isolating application services through platform network policy. Eradication and recovery follow the Contingency Plan, and every incident produces an after-action report with corrective actions tracked to closure.

Confirmed AFS incidents are reported to the agency CSIRC within one hour of determination, and the CSIRC handles onward US-CERT notification within federally required timelines. The System Owner and Authorizing Official are notified in parallel for any incident classified as moderate severity or higher.

Risk assessment policy and procedures for AFS are maintained by the Acme Program Office and define assessment scope, frequency, scanning requirements, and risk acceptance authority. The ISSM reviews the procedures annually.

A system-level risk assessment for AFS is performed at least annually and after significant changes, evaluating threats to the case-tracking workflow, partner interconnections, and hosted data. Results are documented in the AFS risk assessment report, and residual risks are presented to the Authorizing Official with recommended treatment.

AFS container images are scanned for known vulnerabilities on every build and daily in the registry; authenticated web application scans run monthly against the staging environment. Critical findings are remediated within 15 days, high within 30 days, and moderate within 90 days, with exceptions tracked as POA&M items approved by the ISSM.

System and communications protection policy and procedures for AFS are maintained by the Acme Program Office and describe boundary protection expectations, encryption requirements, key management responsibilities, and the division of responsibility with the LFC platform. The procedures are reviewed annually.

This control is inherited from the Lovable Federal Cloud FedRAMP-Moderate authorization package. See the LFC SSP, control SC-7, for implementation details. AFS configures the platform feature in accordance with LFC customer responsibilities.

Transmission confidentiality and integrity is inherited from the Lovable Federal Cloud platform, which terminates TLS 1.2+ with FIPS 140-validated cryptographic modules at the platform edge and enforces mTLS for all internal service-to-service traffic. See the LFC SSP, control SC-8, for implementation details.

Cryptographic keys used by AFS are generated, stored, and rotated within the LFC key management service using FIPS 140-validated modules. Application data-encryption keys are rotated annually and on personnel change affecting key custodians; partner mTLS certificates are issued for one year and revoked immediately on partner offboarding.

This control is inherited from the Lovable Federal Cloud FedRAMP-Moderate authorization package. See the LFC SSP, control SC-13, for implementation details. AFS configures the platform feature in accordance with LFC customer responsibilities.

This control is inherited from the Lovable Federal Cloud FedRAMP-Moderate authorization package. See the LFC SSP, control SC-28, for implementation details. AFS configures the platform feature in accordance with LFC customer responsibilities.

System and information integrity policy and procedures for AFS are maintained by the Acme Program Office and cover flaw remediation timelines, malicious code protection, monitoring responsibilities, and alert handling. The ISSM approves the procedures annually.

AFS dependencies and base images are monitored continuously by the pipeline's software composition analysis tooling, and patched images are rebuilt and deployed on the remediation timelines defined in the vulnerability management procedure. Emergency patches for actively exploited vulnerabilities may be deployed under the expedited change process with retroactive change board review.

Malicious code protection for the underlying compute platform is provided by LFC endpoint protection. AFS additionally scans every partner-submitted file attachment with the platform antimalware service before it is written to storage, and quarantines and alerts on any detection.

AFS is monitored through platform telemetry, application health checks, and SIEM correlation rules covering authentication anomalies, privilege escalation, unusual export volume, and integration failures. Alerts route to the on-call administrator and the program security inbox, and monitoring coverage is reviewed with the ISSO each quarter.