Appearance
NIST 800-53 Configuration Management & System Integrity Policy (CM/SI)
Document ID: PLCY-NIST-CMSI-001
Version: 1.0
Effective Date: December 30, 2025
Last Review: December 30, 2025
Owner: Hop And Haul Team
CONFIDENTIAL
This document is CONFIDENTIAL and for internal use only. Do not distribute outside the organization.
1. Purpose
This document defines Hop And Haul' implementation of the NIST 800-53 Configuration Management (CM) and System and Information Integrity (SI) families for FedRAMP Moderate authorization. It establishes requirements for maintaining secure system configurations, managing changes, and ensuring system integrity.
2. Scope
This policy applies to:
- All Hop And Haul system components (application, database, infrastructure)
- All configuration items and baselines
- All software and firmware
- All change management processes
- All integrity monitoring systems
3. Configuration Management Policy (CM-1)
3.1 Policy Statement
Hop And Haul implements configuration management that:
- Establishes and maintains baseline configurations
- Controls and documents all system changes
- Restricts unauthorized configuration changes
- Monitors for configuration drift
3.2 Responsibilities
| Role | Responsibilities |
|---|---|
| Security Team | Define security baselines, approve security changes |
| DevOps Team | Maintain configurations, implement changes |
| Development Team | Application configuration, code changes |
| Change Advisory Board (CAB) | Review and approve significant changes |
4. Baseline Configuration (CM-2)
4.1 Configuration Baselines
| Component | Baseline Type | Update Frequency |
|---|---|---|
| EC2 instances | AMI golden image | Monthly |
| RDS PostgreSQL | Parameter groups | Quarterly |
| Application | Docker image + config | Per release |
| Network | Security groups, NACLs | Quarterly |
| Cloudflare | Zero Trust policies | Quarterly |
4.2 Baseline Contents
| Element | Documentation |
|---|---|
| Operating system | Version, patches, hardening |
| Installed software | Packages, versions |
| Security settings | Firewall rules, permissions |
| Network configuration | IPs, routes, DNS |
| Application settings | Environment variables, feature flags |
4.3 Golden Image Management
| Activity | Frequency | Owner |
|---|---|---|
| AMI creation | Monthly | DevOps |
| Security scanning | Before promotion | Security |
| Baseline testing | Before promotion | QA |
| Documentation update | With each AMI | DevOps |
4.4 Automation Support (CM-2(2))
| Tool | Purpose | Status |
|---|---|---|
| Terraform | Infrastructure as Code | Implemented |
| Ansible | Configuration management | Implemented |
| AWS Config | Configuration compliance | Implemented |
| Docker | Application packaging | Implemented |
5. Configuration Change Control (CM-3)
5.1 Change Categories
| Category | Definition | Approval | Examples |
|---|---|---|---|
| Standard | Pre-approved, low risk | Automated | Dependency updates |
| Normal | Scheduled, moderate risk | CAB | Feature releases |
| Emergency | Urgent, high impact | Post-approval | Security patches |
| Significant | Major architectural | CAB + Security | Infrastructure changes |
5.2 Change Process
Request → Impact Analysis → Approval → Implementation →
Verification → Documentation → Close5.3 Change Documentation
| Field | Requirement |
|---|---|
| Change ID | Unique identifier |
| Requestor | Person initiating change |
| Description | What is being changed |
| Justification | Business/technical reason |
| Impact analysis | Risk assessment |
| Rollback plan | How to revert if needed |
| Testing plan | Verification steps |
| Approvers | Required sign-offs |
| Implementation date | Scheduled time |
| Post-implementation review | Verification results |
5.4 Testing and Validation (CM-3(2))
| Change Type | Testing Required |
|---|---|
| Code changes | Unit, integration, security tests |
| Configuration changes | Validation in staging |
| Infrastructure changes | Terraform plan review |
| Security changes | Security team review |
6. Impact Analysis (CM-4)
6.1 Analysis Requirements
Before any change, assess:
| Factor | Consideration |
|---|---|
| Security impact | Does this affect security posture? |
| Availability impact | Will this cause downtime? |
| Performance impact | Will this affect response times? |
| Compliance impact | Does this affect compliance status? |
| Data impact | Does this affect data handling? |
6.2 Impact Levels
| Level | Definition | Approval |
|---|---|---|
| Low | Minimal impact, easily reversible | Team lead |
| Moderate | Some risk, rollback available | Manager |
| High | Significant risk, careful planning needed | CAB |
| Critical | Major impact, extensive testing required | CAB + Executive |
7. Access Restrictions for Change (CM-5)
7.1 Change Access Controls
| System | Who Can Change | How |
|---|---|---|
| Production code | Deployment pipeline only | CI/CD |
| Production config | DevOps (approved) | Infrastructure as Code |
| Database schema | DBA (approved) | Migration scripts |
| Security settings | Security team | Change request |
| Infrastructure | DevOps (approved) | Terraform |
7.2 Separation of Duties
| Activity | Cannot Be Same Person |
|---|---|
| Code commit | Code review approval |
| Change request | Change approval |
| Deployment initiation | Deployment verification |
| Security exception request | Exception approval |
8. Configuration Settings (CM-6)
8.1 Security Configuration Standards
| Component | Standard | Verification |
|---|---|---|
| Linux OS | CIS Benchmark Level 1 | Automated scanning |
| PostgreSQL | CIS PostgreSQL Benchmark | Configuration audit |
| Swift/Vapor | OWASP guidelines | Code review |
| AWS | CIS AWS Benchmark | AWS Config rules |
8.2 Configuration Parameters
| Parameter | Requirement |
|---|---|
| Password complexity | Managed by SSO provider |
| Session timeout | 15 minutes (access token) |
| TLS version | Minimum TLS 1.2, prefer 1.3 |
| Encryption | AES-256-GCM |
| Logging | Comprehensive audit logging enabled |
9. Least Functionality (CM-7)
9.1 Component Minimization
| Principle | Implementation |
|---|---|
| Minimal OS | Only required packages installed |
| Disabled services | Non-essential services disabled |
| Closed ports | Only required ports open |
| Removed tools | Development tools not in production |
9.2 Periodic Review (CM-7(1))
| Review | Frequency | Owner |
|---|---|---|
| Installed packages | Quarterly | DevOps |
| Open ports | Monthly | Security |
| Running services | Monthly | Operations |
| User accounts | Quarterly | Security |
10. System Component Inventory (CM-8)
10.1 Inventory Requirements
| Asset Type | Tracked Information |
|---|---|
| Hardware | Instance ID, type, region, tags |
| Software | Name, version, license |
| Data stores | Database, location, classification |
| Network | VPC, subnets, security groups |
| Endpoints | URLs, certificates, owners |
10.2 Inventory Management
| Status | Implementation |
|---|---|
| Current | AWS resource tagging |
| Planned | Automated CMDB (Phase 2) |
11. System and Information Integrity (SI-1)
11.1 Integrity Policy Statement
Hop And Haul implements integrity controls that:
- Detect and prevent malicious code
- Identify and remediate vulnerabilities
- Monitor system behavior for anomalies
- Validate input and output data
12. Flaw Remediation (SI-2)
12.1 Vulnerability Management
| Activity | Frequency | Tool |
|---|---|---|
| SAST scanning | Every commit | Integrated scanner |
| Dependency scanning | Daily | Dependabot |
| Container scanning | Every build | Container scanner |
| Infrastructure scanning | Weekly | AWS Inspector |
| Penetration testing | Annual | 3PAO |
12.2 Remediation SLAs
| Severity | Response Time | Remediation Time |
|---|---|---|
| Critical | 4 hours | 24 hours |
| High | 24 hours | 7 days |
| Medium | 72 hours | 30 days |
| Low | 7 days | 90 days |
12.3 Automated Status (SI-2(2))
| Automation | Implementation |
|---|---|
| Vulnerability tracking | Integrated with ticketing |
| SLA monitoring | Automated alerts |
| Patch deployment | Automated for standard patches |
| Status reporting | Dashboard and reports |
13. Malicious Code Protection (SI-3)
13.1 Protection Mechanisms
| Layer | Protection | Implementation |
|---|---|---|
| Application | Memory-safe language | Swift (Vapor) |
| Input validation | Schema validation | All API endpoints |
| Dependency | Vulnerability scanning | Automated CI/CD |
| Infrastructure | AWS native protections | GuardDuty, WAF |
| Network | WAF rules | Cloudflare WAF |
13.2 Update Frequency
| Protection | Update Frequency |
|---|---|
| WAF rules | Continuous (Cloudflare managed) |
| Dependency versions | Weekly review |
| OS patches | Monthly (standard), immediate (critical) |
14. System Monitoring (SI-4)
14.1 Monitoring Coverage
| Monitoring Type | Scope | Tool |
|---|---|---|
| Security events | All authentication, authorization | CloudWatch + SIEM |
| Application behavior | API calls, business logic | Application logging |
| Infrastructure | Resource utilization, health | CloudWatch |
| Network | Traffic patterns, anomalies | VPC Flow Logs |
| File integrity | Critical system files | Planned (Phase 3) |
14.2 Automated Tools (SI-4(2))
| Tool | Purpose | Alerts |
|---|---|---|
| CloudWatch | Infrastructure monitoring | PagerDuty |
| SIEM | Security event correlation | PagerDuty |
| WAF | Attack detection | CloudWatch |
| GuardDuty | Threat detection | Security team |
14.3 Traffic Monitoring (SI-4(4))
| Traffic Type | Monitoring |
|---|---|
| Inbound API | Request logging, rate analysis |
| Outbound | Connection tracking |
| Internal | Service-to-service logging |
| Database | Query logging (performance) |
14.4 System-Generated Alerts (SI-4(5))
| Alert Type | Threshold | Response |
|---|---|---|
| Failed authentication | 5 in 15 min | Account lockout, alert |
| Unusual access pattern | ML anomaly | Security review |
| Resource exhaustion | 80% capacity | Operations alert |
| Error rate spike | 5x baseline | Development alert |
15. Security Alerts (SI-5)
15.1 Alert Sources
| Source | Types of Alerts |
|---|---|
| AWS Security Hub | Security findings |
| US-CERT | Federal advisories |
| Vendor advisories | Product vulnerabilities |
| Threat intelligence | Emerging threats |
15.2 Alert Response
| Severity | Response Time | Action |
|---|---|---|
| Critical | Immediate | Emergency patch process |
| High | 24 hours | Assess and plan remediation |
| Medium | 72 hours | Schedule remediation |
| Low | 7 days | Add to backlog |
16. Software and Information Integrity (SI-7)
16.1 Integrity Verification
| Status | Implementation |
|---|---|
| Current | Code review, dependency checksums |
| Planned | Code signing, SBOM (Phase 3) |
16.2 Planned Enhancements
| Enhancement | Target | Timeline |
|---|---|---|
| Code signing | All releases | Phase 3 |
| SBOM generation | All builds | Phase 3 |
| Binary attestation | Container images | Phase 3 |
| Runtime integrity | Critical components | Phase 3 |
17. Information Input Validation (SI-10)
17.1 Validation Requirements
| Input Type | Validation |
|---|---|
| API requests | JSON schema validation |
| User input | Type, length, format validation |
| File uploads | Type verification, size limits, scanning |
| Configuration | Schema validation |
17.2 Validation Implementation
| Layer | Mechanism |
|---|---|
| API Gateway | Request schema validation |
| Application | Input sanitization |
| Database | Parameterized queries |
| Output | Encoding, escaping |
18. Error Handling (SI-11)
18.1 Error Response Standards
| Principle | Implementation |
|---|---|
| No sensitive data in errors | Generic error messages to clients |
| Detailed internal logging | Full context logged server-side |
| Graceful degradation | Fallback behavior defined |
| Error correlation | Request ID in all responses |
18.2 Error Categories
| Category | Client Response | Logging |
|---|---|---|
| Validation error | Specific field errors | Debug level |
| Authorization error | Generic "forbidden" | Warning level |
| System error | Generic "internal error" | Error level |
| Security event | Generic response | Alert + audit |
19. Information Management and Retention (SI-12)
19.1 Data Lifecycle
| Phase | Controls |
|---|---|
| Creation | Classification, encryption |
| Storage | Access controls, encryption at rest |
| Transmission | TLS encryption |
| Processing | Least privilege access |
| Retention | Per retention schedule |
| Disposal | Secure deletion/cryptographic erasure |
19.2 Retention Alignment
See PLCY-RET-001 for authoritative retention schedule.
20. Memory Protection (SI-16)
20.1 Memory Safety
| Protection | Implementation |
|---|---|
| Memory-safe language | Swift (application code) |
| Stack protection | OS-level protections enabled |
| ASLR | Enabled on all systems |
| NX bit | Non-executable stack |
21. FedRAMP-Specific Enhancements (Planned)
| Enhancement | Target Control | Timeline |
|---|---|---|
| FIPS 140-2 crypto modules | SC-13, SI-7 | Phase 3 |
| Code signing | SI-7 | Phase 3 |
| Automated CMDB | CM-8 | Phase 2 |
| File integrity monitoring | SI-7(1) | Phase 3 |
22. Related Documents
| Document | Relationship |
|---|---|
| PLCY-SEC-001 | Security controls baseline |
| PLCY-DRP-001 | Configuration recovery |
| PLCY-FED-005 | NIST control mapping |
23. Document Control
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | December 30, 2025 | Hop And Haul Team | Initial release |