Access Control Policy

This Access Control Policy ("Policy") establishes the requirements and controls governing authentication, authorization, and accountability for all access to FindTheBreach information systems, applications, and data. The Policy ensures that access is granted on a least-privilege, need-to-know basis in alignment with SOC 2 CC6 (Logical and Physical Access Controls), ISO 27001 A.8.2 (Privileged Access Rights) and A.9 (Access Control), PCI DSS Requirements 7 and 8, and NIST AC control family.

Scope. This Policy applies to:

• All employees, contractors, consultants, and third-party service providers who access FindTheBreach systems
• All platform user accounts including Superadmin, Admin, Analyst, Viewer, and API-Only roles
• All system interfaces including the web application, REST API, CLI tools, and administrative consoles
• All computing environments: production, staging, development, and disaster recovery
• All authentication mechanisms including passwords, TOTP tokens, API keys, and JWT sessions

Violation of this Policy may result in immediate access revocation, disciplinary action up to and including termination, and may also result in civil or criminal penalties under applicable law.

FindTheBreach enforces role-based access control across the entire platform. Every user account is assigned exactly one role that determines the maximum permissions available. Access is granted according to the principle of least privilege — users receive only the minimum permissions necessary to perform their duties.

Role assignments are reviewed quarterly by organization Admins. Role escalation (e.g., Viewer → Analyst) requires written approval from an Admin or Superadmin and is logged in the audit trail.

All users must authenticate before accessing any FindTheBreach system or data. Authentication mechanisms are designed to verify identity with a high degree of assurance, aligned with NIST SP 800-63B (Digital Identity Guidelines) and PCI DSS Requirement 8.

• Password Policy: Passwords must be a minimum of 12 characters and include at least one uppercase letter, one lowercase letter, one digit, and one special character. Passwords are hashed using bcrypt with a minimum cost factor of 12. Reuse of the last 10 passwords is prohibited. Passwords are checked against known breach databases at creation time.
• Multi-Factor Authentication (MFA): TOTP-based multi-factor authentication is mandatory for all Superadmin and Admin accounts. MFA is strongly recommended for Analyst and Viewer accounts and can be enforced organization-wide by an Admin. MFA enrollment must be completed within 24 hours of account creation for privileged roles.
• JWT Token Policy: Authentication sessions are managed via JSON Web Tokens (JWT). Access tokens expire after 24 hours. Refresh tokens expire after 7 days and are rotated on each use. Tokens are signed using RS256 and include audience, issuer, and scope claims.
• Account Lockout: After 5 consecutive failed authentication attempts, the account is locked for 30 minutes. Lockout events are logged and trigger an alert to the account owner via email. Superadmin accounts trigger an additional alert to the security team. Persistent lockouts (3+ within 24 hours) require manual review before unlock.

Session management controls ensure that authenticated sessions are properly maintained, monitored, and terminated. These controls protect against session hijacking, fixation, and replay attacks.

• JWT-Based Sessions: All web and API sessions are managed through cryptographically signed JWT tokens. Tokens are transmitted via HTTP-only, Secure, SameSite=Strict cookies for web sessions and via the Authorization header for API requests.
• Token Revocation: Tokens are immediately revoked upon user logout, password change, role modification, or account deactivation. A server-side token deny list is maintained to enforce revocation before natural token expiry.
• Secure Cookie Flags: Session cookies are set with HttpOnly, Secure, and SameSite=Strict flags. Cookies are scoped to the findthebreach.com domain and are never transmitted over unencrypted connections.
• Idle Timeout: Web sessions are terminated after 30 minutes of inactivity. Users are presented with a session expiration warning 5 minutes before timeout. Re-authentication is required to resume an expired session.
• Concurrent Sessions: Each user account is limited to 3 concurrent active sessions. Establishing a new session beyond the limit automatically terminates the oldest session. Superadmin accounts are limited to 1 concurrent session.

API keys provide programmatic access to FindTheBreach services. All API keys are scoped, auditable, and subject to lifecycle management controls aligned with SOC 2 CC6.3 and NIST IA-5.

• Scoped Permissions: Each API key is created with explicit permission scopes — read, write, or admin. Keys cannot exceed the permissions of the issuing user's role. A read-scoped key cannot initiate scans; an admin-scoped key requires Superadmin approval.
• Key Rotation: API keys should be rotated every 90 days. Keys older than 180 days are flagged for mandatory rotation. Organizations can enforce automatic key expiration via policy settings. Rotation generates a new key and provides a 48-hour grace period for the old key.
• Rate Limiting: API requests are rate-limited per key: 1,000 requests per minute for standard keys, 5,000 for admin-scoped keys. Burst limits are enforced via a sliding window algorithm. Rate limit headers (X-RateLimit-Remaining) are included in all API responses.
• Key Storage: API keys are displayed once at creation and are stored as SHA-256 hashes. Keys cannot be retrieved after initial display. Lost keys must be revoked and re-issued. Keys must never be committed to source code repositories or shared via unencrypted channels.

Privileged access to FindTheBreach systems is subject to enhanced oversight and periodic review. These controls satisfy SOC 2 CC6.2, ISO 27001 A.9.2.5, and PCI DSS Requirement 7.2.

• Quarterly Access Reviews: All Superadmin and Admin accounts are reviewed quarterly by the CISO or designated security lead. Reviews verify that each privileged account remains necessary, that role assignments are appropriate, and that MFA is active. Review findings are documented and retained for audit purposes.
• Dormant Account Detection: Accounts with no login activity for 90 or more consecutive days are automatically flagged as dormant. Dormant accounts are disabled after a 14-day notification period. Reactivation requires identity verification and approval from an Admin or Superadmin.
• Mandatory MFA Enforcement: Multi-factor authentication is non-negotiable for all Admin and Superadmin roles. Accounts that do not complete MFA enrollment within 24 hours of role assignment are automatically suspended. MFA bypass is not permitted; exceptions require CISO written approval with a compensating control plan.
• Separation of Duties: No single user may both approve and execute privileged operations (e.g., user creation and role assignment must involve two separate individuals). Critical configuration changes require approval from at least one additional Admin.

All credentials, tokens, and sensitive access-control data are protected through encryption at rest and in transit. Cryptographic controls are aligned with SOC 2 CC6.7, ISO 27001 A.8.24, and PCI DSS Requirement 8.3.

• Data at Rest: Sensitive fields — including password hashes, API key hashes, TOTP secrets, and webhook signing keys — are encrypted using AES-256-GCM with per-field initialization vectors. Encryption keys are managed through a dedicated key management process with annual rotation.
• Data in Transit: All communications between clients and FindTheBreach services are encrypted using TLS 1.2 or higher. TLS 1.0 and 1.1 are disabled. HSTS headers are enforced with a minimum max-age of one year. Certificate transparency is monitored for unauthorized issuance.
• Database Encryption: PostgreSQL databases use transparent data encryption for at-rest protection. Database connections require TLS and certificate-based authentication. Backup files are encrypted with AES-256-GCM before transfer to off-site storage.
• Key Management: Cryptographic keys are generated using cryptographically secure random number generators. Keys are stored separately from the data they protect. Key access is restricted to authorized service accounts and is logged in the audit trail.

Comprehensive audit logging provides accountability and supports forensic investigation. All access-related events are recorded in the platform's ActivityLog, aligned with SOC 2 CC7.2, ISO 27001 A.8.15, and PCI DSS Requirement 10.

• Logged Events: All authentication attempts (successful and failed), role changes, permission modifications, API key creation and revocation, session creation and termination, password changes, MFA enrollment and bypass attempts, and administrative actions are logged with full context.
• Log Content: Each audit record includes: timestamp (UTC), user identity, source IP address, user agent, action performed, target resource, result (success/failure), and session identifier. Personally identifiable information in logs is minimized to what is necessary for investigation.
• Failed Login Tracking: Failed authentication attempts are tracked per account and per source IP. Patterns indicative of brute-force attacks (5+ failures in 10 minutes) trigger automated account lockout and security team alerting. Geographic anomalies in login patterns generate risk-based alerts.
• Immutable Audit Trail: Audit logs are append-only and cannot be modified or deleted by any user, including Superadmins. Logs are retained for a minimum of 12 months in hot storage and 7 years in archive storage. Log integrity is verified through cryptographic checksums.

Third-party integrations, webhooks, and sub-processor access are subject to the same access control principles as internal users. These controls are aligned with SOC 2 CC9.2 and ISO 27001 A.5.19 (Information Security in Supplier Relationships).

• Webhook HMAC Verification: All outbound webhooks are signed using HMAC-SHA256 with a per-integration secret key. Recipients must verify the signature before processing webhook payloads. Webhook secrets are rotatable and stored encrypted at rest.
• Integration Configuration Encryption: Third-party integration credentials (OAuth tokens, API keys, connection strings) are encrypted using AES-256-GCM before storage. Integration configurations are accessible only to Admin and Superadmin roles and are never exposed in API responses.
• Sub-Processor Controls: Third-party sub-processors that access FindTheBreach data are subject to security assessments prior to engagement and annually thereafter. Sub-processors must maintain equivalent access controls, encryption standards, and audit logging capabilities. A current list of sub-processors is maintained in our Privacy Policy.
• Least-Privilege Integration Scopes: Third-party integrations are granted the minimum permissions necessary for their function. Integration permissions are reviewed during quarterly access reviews and revoked immediately upon contract termination.

This Policy is a living document and will be reviewed and updated to reflect changes in the threat landscape, regulatory requirements, platform architecture, and business operations.

• Annual Review Cycle: This Policy is reviewed at least annually by the CISO and approved by executive management. Ad-hoc reviews are triggered by significant security incidents, material changes to the authentication or authorization architecture, new regulatory requirements, or organizational restructuring.
• Change Management: All changes to this Policy follow the formal Change Management Policy. Changes are documented with version history, rationale, impact assessment, and approval records. Stakeholders are notified of material changes within 5 business days.
• Version History: A complete version history is maintained for this Policy. Each version records the date of change, author, approver, and a summary of modifications. Previous versions are archived and available for audit review upon request.
• Exception Management: Exceptions to this Policy require written justification, a compensating controls plan, a defined expiration date (not to exceed 90 days), and approval from the CISO. Exceptions are documented in the risk register and reviewed at each quarterly access review.