football/docs/SECURITY-POLICY.md

Football Secure Access System - Security Policies

Document Information

• System Name: Football Secure Access System
• Classification: Controlled Unclassified Information (CUI)
• Version: 1.0
• Effective Date: 2024-01-13
• Review Date: 2025-01-13
• Compliance Standards: CIS Debian 13, CMMC Level 3, FedRAMP Moderate, NIST SP 800-171

---

Table of Contents

1. Information Security Policy
2. Access Control Policy
3. Network Security Policy
4. Incident Response Policy
5. Change Management Policy
6. Audit and Logging Policy
7. Password Policy
8. Acceptable Use Policy
9. Physical Security Policy
10. Data Classification Policy

---

1. Information Security Policy

1.1 Purpose

This policy establishes the framework for protecting Controlled Unclassified Information (CUI) and ensuring the confidentiality, integrity, and availability of the Football Secure Access System.

1.2 Scope

This policy applies to:

• All Football Secure Access Systems deployed to Tier0 infrastructure
• All users accessing the system
• All administrators maintaining the system
• All contractors and third parties with system access

1.3 Policy Statements

1.3.1 All systems must be configured in accordance with CIS Debian 13 Benchmark

1.3.2 All CUI stored on or transmitted through the system must be protected via encryption

1.3.3 All access to the system must be logged and audited

1.3.4 All security incidents must be reported within 1 hour of discovery

1.3.5 All users must complete security awareness training before system access is granted

1.3.6 All systems must undergo annual security assessments

1.3.7 All security controls must be verified quarterly for compliance

---

2. Access Control Policy

2.1 Purpose

To establish controls for granting, managing, and revoking access to the Football Secure Access System.

2.2 Access Principles

2.2.1 Principle of Least Privilege

• Users are granted only the minimum access necessary to perform their duties
• Access is reviewed quarterly and revoked when no longer required

2.2.2 Separation of Duties

• No single individual has complete control over security functions
• Administrative and operational duties are separated

2.2.3 Need-to-Know

• Access to CUI is restricted to individuals with a verified need
• Access requests must be documented and approved

2.3 User Access Requirements

2.3.1 All users must have a unique user account

2.3.2 All accounts must be associated with an individual (no shared accounts)

2.3.3 All accounts must be protected with a password conforming to the Password Policy

2.3.4 All accounts must be automatically locked after 5 failed login attempts

2.3.5 All accounts must be automatically locked after 90 days of inactivity

2.4 Administrative Access

2.4.1 Administrative access requires physical access to the system (no remote SSH)

2.4.2 All administrative actions must be logged

2.4.3 All administrators must complete security training annually

2.4.4 Administrative access must be granted via documented authorization

2.5 Access Revocation

2.5.1 Access must be revoked immediately upon:

• Termination of employment
• Change in job duties
• Suspicion of security compromise
• Completion of assigned project

2.5.2 Access revocation must be logged and audited

2.5.3 Immediate supervisors must be notified of access revocation

---

3. Network Security Policy

3.1 Purpose

To establish network security controls for protecting CUI during transmission.

3.2 Network Architecture

3.2.1 The system implements a WireGuard-only networking model:

• All outbound network traffic MUST pass through a WireGuard VPN tunnel
• Direct network access from the physical interface (eth0) is BLOCKED
• Only traffic to the configured WireGuard endpoint is permitted on eth0
• Inbound traffic from the internet is BLOCKED (except WireGuard keepalives)

3.2.2 Permitted Traffic:

• WireGuard VPN traffic to configured endpoint (UDP only)
• DHCP for initial IP acquisition
• All traffic through the WireGuard tunnel (wg0)

3.2.3 Prohibited Traffic:

• Direct internet access
• SSH, Telnet, or other remote access protocols
• File sharing protocols (NFS, SMB)
• Email protocols (SMTP, IMAP, POP)
• Web server traffic
• Any traffic not explicitly permitted

3.3 Network Isolation

3.3.1 The system is networkly isolated from the public internet

3.3.2 All CUI transmission occurs only through the encrypted WireGuard tunnel

3.3.3 The system has no inbound network services

3.4 Remote Access Prohibition

3.4.1 Remote access is STRICTLY PROHIBITED:

• No SSH server
• No Telnet server
• No RDP server
• No VNC server
• No remote administration capabilities

3.4.2 Local console access is the ONLY permitted administrative method

3.4.3 Any remote access tools are removed from the system

---

4. Incident Response Policy

4.1 Purpose

To establish procedures for detecting, responding to, and recovering from security incidents.

4.2 Incident Classification

4.2.1 Category I - Emergency

• Active compromise or attack in progress
• Data breach suspected or confirmed
• System availability critical

Response Time: Immediate (within 15 minutes)

4.2.2 Category II - Urgent

• Suspicious activity detected
• Potential compromise
• Security control failure

Response Time: Within 1 hour

4.2.3 Category III - Routine

• Policy violation
• Minor security event
• Required reporting

Response Time: Within 24 hours

4.3 Incident Detection

4.3.1 All security incidents are detected via:

• Automated monitoring alerts
• Audit log review
• User reports
• Vulnerability scan results

4.3.2 The following events trigger incident response:

• Failed login attempts (5+ within 15 minutes)
• Unauthorized system changes
• File integrity monitoring alerts
• Security control failures
• Suspicious network activity

4.4 Incident Response Process

4.4.1 Detection and Reporting

• Incident is detected and reported immediately
• Incident is classified by security team
• Response team is notified

4.4.2 Containment

• System is isolated if necessary
• Affected systems are identified
• Incident scope is determined

4.4.3 Eradication

• Root cause is identified
• Malicious artifacts are removed
• Vulnerabilities are remediated

4.4.4 Recovery

• Systems are restored from clean backups
• Normal operations resume
• Post-incident monitoring is implemented

4.4.5 Lessons Learned

• Post-incident review is conducted within 7 days
• Root cause analysis is documented
• Procedures are updated if necessary
• Findings are communicated to stakeholders

4.5 Incident Notification

4.5.1 Internal Notification

• Security team: Immediate
• Management: Within 1 hour
• Affected users: Within 4 hours

4.5.2 External Notification

• If CUI breach: Within 72 hours
• If personal data breach: Within 72 hours
• If law enforcement required: As soon as practicable

---

5. Change Management Policy

5.1 Purpose

To establish procedures for managing changes to the Football Secure Access System.

5.2 Change Categories

5.2.1 Standard Changes

• Pre-authorized changes with low risk
• Routine security updates
• Configuration adjustments within approved parameters

5.2.2 Normal Changes

• Non-standard changes with moderate risk
• New security controls
• System upgrades

5.2.3 Emergency Changes

• Critical security patches
• Incident response actions
• System availability issues

5.3 Change Management Process

5.3.1 Request

• Change request is submitted
• Change category is determined
• Risk assessment is conducted

5.3.2 Review and Approval

• Change request is reviewed by security team
• Impact analysis is conducted
• Change is approved or rejected

5.3.3 Testing

• Change is tested in non-production environment
• Back-out plan is verified
• Test results are documented

5.3.4 Implementation

• Change is scheduled (except emergency)
• Change is implemented
• System is verified

5.3.5 Post-Implementation

• System is monitored for issues
• Change is documented
• Procedures are updated if necessary

5.4 Change Controls

5.4.1 All changes must be approved prior to implementation

5.4.2 All changes must be tested before implementation

5.4.3 All changes must be documented

5.4.4 All changes must be auditable

5.4.5 Back-out plans must be prepared for all changes

---

6. Audit and Logging Policy

6.1 Purpose

To establish requirements for system auditing and log management.

6.2 Audit Scope

6.2.1 The following events MUST be audited:

• All login attempts (successful and failed)
• All administrative actions
• All privilege escalations (sudo usage)
• All file access and modifications to CUI
• All system configuration changes
• All network connection attempts
• All security control modifications

6.3 Audit Requirements

6.3.1 Audit logs must capture:

• Timestamp
• User identity
• Event type
• Source address
• Object accessed
• Action taken
• Event outcome

6.3.2 Audit logs must be:

• Generated automatically
• Protected from unauthorized modification
• Retained for 365 days
• Available for review within 24 hours

6.4 Log Retention

6.4.1 Audit logs: 365 days

6.4.2 System logs: 365 days

6.4.3 Security logs: 365 days

6.4.4 Firewall logs: 90 days

6.4.5 Network logs: 90 days

6.5 Log Review

6.5.1 Audit logs are reviewed:

• Daily: Critical security events
• Weekly: Failed access attempts
• Monthly: Administrative activity
• Quarterly: Full audit review

6.5.2 Review findings are documented and tracked

6.5.3 Review findings result in corrective actions when necessary

---

7. Password Policy

7.1 Purpose

To establish requirements for password creation and management.

7.2 Password Requirements

7.2.1 Minimum Length: 14 characters

7.2.2 Complexity Requirements:

• At least 1 uppercase letter (A-Z)
• At least 1 lowercase letter (a-z)
• At least 1 digit (0-9)
• At least 1 special character (!@#$%^&*)

7.2.3 Prohibited Characteristics:

• Default passwords (e.g., "changeme", "password")
• Dictionary words
• Personal information (name, birthdate)
• Repeating characters (e.g., "aaaaaa")
• Sequential characters (e.g., "123456")
• Previous passwords

7.2.4 Maximum Age: 90 days

7.2.5 Minimum Age: 1 day (prevent immediate re-use)

7.2.6 Expiration Warning: 7 days

7.2.7 Failed Login Attempts: 5 attempts before lockout

7.2.8 Lockout Duration: 15 minutes

7.3 Password Management

7.3.1 Default passwords must be changed immediately upon first login

7.3.2 Passwords must not be shared

7.3.3 Passwords must not be written down or stored insecurely

7.3.4 Passwords must not be transmitted via email or chat

7.3.5 Suspicious password reset requests must be verified

---

8. Acceptable Use Policy

8.1 Purpose

To define acceptable use of the Football Secure Access System.

8.2 Authorized Use

8.2.1 The system is authorized for:

• Remote access to Privileged Access Workstations (PAW)
• Connecting to approved remote systems via Remmina
• Accessing necessary applications for job duties

8.3 Prohibited Use

8.3.1 The following uses are STRICTLY PROHIBITED:

• Personal activities
• Social media access
• Personal email access
• Downloading unauthorized software
• Storing personal data
• Sharing credentials
• Bypassing security controls
• Unauthorized data transfer

8.3.2 Prohibited activities include:

• Intentional disruption of system availability
• Unauthorized modification of system configuration
• Accessing systems without authorization
• Introducing malware or malicious code
• Interfering with security monitoring
• Violating privacy of other users

8.4 Monitoring

8.4.1 All system activity is monitored and logged

8.4.2 No expectation of privacy exists on this system

8.4.3 Monitoring data may be used for:

• Security investigations
• Compliance verification
• Performance analysis
• Incident response

---

9. Physical Security Policy

9.1 Purpose

To establish physical security controls for the Football Secure Access System.

9.2 Physical Access Controls

9.2.1 Systems must be located in secure, access-controlled areas

9.2.2 Physical access must be limited to authorized personnel

9.2.3 All physical access must be logged

9.2.4 Visitor access must be escorted

9.3 Device Security

9.3.1 Systems must be physically secured (locked)

9.3.2 Physical ports must be disabled or blocked when not in use:

• USB ports
• Ethernet ports
• Serial ports
• DisplayPort/HDMI ports

9.3.3 Systems must be monitored for physical tampering

9.3.4 Media devices must be controlled:

• USB storage devices must be blocked
• External drives must not be connected
• Optical drives must be disabled

9.4 System Disposal

9.4.1 Disposal must include:

• Complete data sanitization
• Destruction of storage media
• Removal of all labels and markings
• Documentation of disposal

9.4.2 Disposal must be approved by security team

9.5 Theft and Loss

9.5.1 Physical theft or loss must be reported immediately

9.5.2 Lost or stolen systems must be:

• Reported to security team within 1 hour
• Disabled from the network immediately
• Account credentials revoked immediately
• Investigated for data compromise

---

10. Data Classification Policy

10.1 Purpose

To establish classification requirements for data stored on or transmitted through the system.

10.2 Data Classification Levels

10.2.1 Controlled Unclassified Information (CUI)

• Information that requires safeguarding
• Information subject to CMMC/FedRAMP controls
• Information subject to export controls

10.2.2 Unclassified

• Information that does not require safeguarding
• Public information
• Routine administrative data

10.3 CUI Marking Requirements

10.3.1 All CUI must be marked with:

• "CUI" designation
• Distribution statement
• Handling instructions
• Exemption citation (if applicable)

10.3.2 CUI marking must be visible at all times

10.4 CUI Handling Requirements

10.4.1 All CUI must be:

• Encrypted at rest
• Encrypted in transit
• Accessible only to authorized personnel
• Protected from unauthorized disclosure

10.4.2 CUI must not be:

• Stored on unencrypted removable media
• Transmitted via unencrypted channels
• Shared with unauthorized individuals
• Disclosed outside approved channels

10.5 Data Retention

10.5.1 CUI must be retained according to:

• Legal requirements
• Contract requirements
• Operational needs
• Compliance requirements

10.5.2 CUI must be securely deleted when no longer required

---

Policy Violations

Violation Reporting

All suspected policy violations must be reported to:

• Security Team: security@knel.org
• Immediate Supervisor: Per organizational chart
• Incident Response Team: incidents@knel.org

Violation Consequences

Policy violations may result in:

• Access revocation
• Disciplinary action
• Legal action
• Criminal charges (if warranted)

Violation Investigation

All violations are investigated to:

• Determine root cause
• Assess impact
• Identify responsible parties
• Recommend corrective actions
• Update procedures if necessary

---

Policy Review and Updates

Review Schedule

All policies are reviewed:

• Annually: Comprehensive review
• As Needed: For compliance updates or changes

Update Process

Policy updates require:

• Security team review
• Management approval
• Documentation of changes
• Communication to affected parties
• Training on updated policies

---

Compliance References

This policy implements controls from:

• CIS Debian 13 Benchmark: Version 3.0.0
• CMMC Level 3: Department of Defense
• FedRAMP Moderate: Federal Risk and Authorization Management Program
• NIST SP 800-53: Security and Privacy Controls for Information Systems and Organizations
• NIST SP 800-171: Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations

---

Contact Information

For policy questions or clarifications:

• Security Team: security@knel.org
• Compliance Officer: compliance@knel.org
• Infrastructure Security: security@knel.org

---

Document Control

• Owner: Infrastructure Security Team
• Approver: CISO
• Distribution: Need-to-know
• Classification: CUI
• Version: 1.0
• Effective Date: 2024-01-13
• Next Review: 2025-01-13

---

End of Document