Synoptix Access Control Policy

1. Purpose

The purpose of this Access Control Policy is to define requirements and best practices for granting, managing, monitoring, and revoking access to Synoptix’s systems, networks, applications, and data. By implementing robust access controls, Synoptix ensures that:

• Only authorized individuals (employees, contractors, and approved partners) can access specific resources.
• Access privileges follow the principle of least privilege (users only receive the minimum rights necessary to perform their job functions).
• Employee and partner accounts are provisioned and deprovisioned promptly, reducing risk of unauthorized access.
• Authentication mechanisms (e.g. Multi-Factor Authentication) and password requirements align with industry best practices.

This policy applies to all Synoptix information assets, including on-premises infrastructure, the Synoptix Cloud environment, third-party services, and any partner/demo systems.

2. Scope

This policy governs access to:

• All Synoptix systems and applications: production, staging, development, and demo environments.
• Network infrastructure: firewalls, VPN endpoints, jump boxes, routers, switches.
• Data repositories: databases (Synoptix Cloud, on-prem), file shares, and backups.
• Physical facilities: data center cages/rooms (for Synoptix Cloud operations), restricted network closets in corporate offices.
• Third-party vendor portals: any external service with Synoptix-managed credentials (e.g., support or monitoring consoles).
• All Synoptix personnel and approved partners: full-time employees, contractors, interns, “demo partners,” and any third party granted access.

3. Definitions

1. Account Owner: The individual or role responsible for approving, reviewing, and overseeing access privileges for a given user account.
2. Administrator (Admin) Account: An elevated account with rights to configure systems, manage user accounts, or change security settings.
3. Demo Partner: External partner or reseller given controlled access to a designated non-production/demo environment for product evaluation or sales demonstrations.
4. Least Privilege: An access-control principle whereby users are granted the minimum set of permissions necessary to perform their job functions.
5. Multi-Factor Authentication (MFA): An authentication method requiring two or more verification factors (e.g., password + authenticator code, hardware token).
6. Privileged Access: Elevated permissions that allow configuration changes, system administration, or direct access to sensitive data.
7. Role-Based Access Control (RBAC): Access management approach whereby permissions are assigned to roles rather than individual users; users are then assigned to roles.
8. Single Sign-On (SSO): An authentication mechanism that allows users to log in once (via Active Directory) and access multiple applications without re-authentication.
9. User Provisioning: The process of creating user accounts and assigning appropriate permissions when a new employee, contractor, or partner requires access.
10. User Deprovisioning: The process of disabling or removing access rights when a user’s employment ends or their role changes.

4. Roles & Responsibilities

5. Account Management

5.1 User Provisioning

1. Access Request Process:
   
   • All employees, contractors, or partners requiring Synoptix system access must submit an “Access Request” ticket in the internal ticketing system. The ticket must specify:
     
     1. Full name and role of the requester
     2. Systems or applications requested (e.g., Synoptix Cloud production database, demo environment)
     3. Justification/rationale (e.g., “Developer for feature X,” “Support engineer for Customer Y,” “Demo partner for sales calls”)
     4. Manager or partner sponsor’s approval
2. Approval Workflow:
   
   • Step 1: Manager (or partner sponsor, for external demo accounts) reviews and approves the request, confirming the requested access aligns with the requester’s job responsibilities.
   • Step 2: InfoSec Program Lead (or designee) verifies that granting these permissions does not violate separation-of-duties or risk standards.
   • Step 3: IT/DevOps Team creates the user account in Active Directory (AD), assigns an initial role adhering to RBAC policies (Section 7), and configures SSO integration.
3. Account Activation:
   
   • Upon account creation, the user receives a one-time activation link via email. The user must set a password meeting Synoptix’s password policy (Section 8).
   • MFA enrollment instructions are provided, and access is only granted once MFA is enabled for the account.

5.2 User Deprovisioning

1. Trigger Events:
   
   • Employment termination (voluntary or involuntary)
   • Role changes that no longer require previous access levels (e.g., a developer moving to a non-technical role)
   • Completion or revocation of partner/demo contracts
2. Deprovisioning Process:
   
   • HR Notification: HR notifies IT and the InfoSec Program Lead within 2 hours of a termination or role-change event.
   • Immediate Actions: Within 4 hours of notification:
     
     • Revoke all associated API tokens, SSH keys, and credentials.
     • For any privileged accounts, credentials are changed or removed immediately.
   • Demo Partner Accounts:
     
     • Demo partner credentials automatically expire at contract end.

5.3 Access Reviews

1. Semiannual Reviews:
   
   • Schedule: Every six months (January 1 and July 1)
   • Participants: Managers, Department Heads, and the InfoSec Program Lead
   • Process:
     
     1. Managers receive a report of all accounts assigned to their direct reports, along with roles and permissions.
     2. Managers validate each account’s access is still appropriate. If access is no longer needed, a Deprovisioning ticket is created.
     3. The InfoSec Program Lead compiles and audits all department attestation reports.
   • Remediation: Any unauthorized or stale accounts must be disabled or adjusted within five business days.

6. Roles & Permissions (RBAC)

6.1 Role Definitions

Synoptix uses predefined roles to categorize permissions. Below are core roles and their high-level permissions:

Note: Additional custom roles (e.g., “Marketing Analyst,” “QA Tester”) may be created as needed, following a formal change request to the InfoSec Program Lead.

6.2 Permission Assignment

• Least-Privilege Principle:
  
  • Every role’s permissions are reviewed annually to remove any unnecessary or outdated rights.
  • If a task requires elevated privileges outside the user’s normal role (e.g., a developer needing temporary production access), a Privileged Access Request must be submitted.
• Separation of Duties:
  
  • No single role may approve its own account provisioning or deprovisioning. For example, a DBA cannot grant administrative access to themselves without the InfoSec Program Lead’s approval.
  • Developers may not grant production database access; that must be performed by a separate Infrastructure Engineer under approval.

7. Authentication & Password Management

• Password Complexity:
  
  • Minimum length: 6 characters
  • Must include at least one lowercase letter, one uppercase letter, one number, and one special character (e.g., ! @ # $ % ^ & *)
  • Cannot contain easily guessed words (e.g., “Synoptix,” “password,” or the user’s name)
• Password Expiration:
  
  • Passwords do not automatically expire. In Synoptix the Administrator may require a user to reset their password.
• Account Lockout:
  
  • After three failed login attempts within 15 minutes, the account is locked until an Administrator unlocks it.
  • IT Support can manually unlock accounts upon verifying user identity.

8. Privileged Access Management

8.1 Admin & Elevated Accounts

• Designation & Approval:
  
  • Only select personnel (e.g., Infrastructure Engineers, DBA leads, InfoSec Program Lead) receive Admin privileges.
• Secure Credential Storage:
  
  • Administrative credentials (e.g., service-account passwords, API keys, shared secrets) are stored in a centralized, access-controlled Key Management System (KMS).
  • Only designated roles (e.g., Infrastructure Engineers, InfoSec Program Lead) have read-access to the KMS.

9. Network & Remote Access Controls

9.1 VPN & Remote Connectivity

• VPN Access:
  
  • Remote users must connect via the Synoptix IPsec VPN gateway.
  • VPN client software is restricted to managed images; personal or unapproved VPN clients are prohibited.
• Split-Tunnel vs. Full-Tunnel:
  
  • Synoptix enforces full-tunnel VPN: all network traffic routes through the Synoptix network to ensure traffic inspection and logging.
• Idle Timeout:
  
  • VPN sessions automatically disconnect after 30 minutes of inactivity.

9.2 Network Segmentation & Firewalls

• Perimeter Firewalls:
  
  • Hardware firewalls block all unnecessary inbound/outbound traffic by default; only required application ports are opened.
• Internal Segmentation:
  
  • Only specific subnets (e.g., jump box IP range) may access production servers on administrative ports.

10. Third-Party & Partner Access

• Access Requirements:
  
  • Any third-party vendor requiring access to Synoptix systems (e.g., for support or consulting) undergoes a risk assessment.
  • Approved third parties receive accounts with only the permissions necessary for their scope of work.
• Contractual Obligations:
  
  • Vendor contracts stipulate that vendor personnel must follow Synoptix’s access controls (e.g., MFA, SSO integration, password policy).
  • Vendors must notify Synoptix of any employee changes affecting system access.

11. Session Management

11.1 Session Timeouts

• Web Application Sessions:
  
  • Inactive user sessions to Synoptix Cloud or internal web applications automatically time out after 30 minutes of inactivity.

11.2 Session Termination

• All users must explicitly log out of portals or applications when finished. Leaving active sessions unattended is prohibited and may result in disciplinary action.

12. Access Logging & Monitoring

• Authentication Logs:
  
  • All login attempts (successful and failed) to AD, Synoptix Cloud, and VPN are logged with user ID, timestamp, IP address, and result (success/failure).
• Administrative Actions:
  
  • All privileged commands or configuration changes on production servers, network devices, and databases are recorded (e.g., commands run, files accessed).

13. Access Control for Physical Facilities

• Access Points:
  
  • Main office entrances require keys.
• Server & Network Closets:
  
  • These closets can be locked.
• Workstations & Mobile Devices:
  
  • All company-issued laptops and desktops can be encrypted and require unique user credentials to log in.
  • Employees must lock or log out of their workstations when stepping away.

14. Enforcement & Compliance

14.1 Violations & Disciplinary Actions

• Any user found to have violated this Access Control Policy (e.g., sharing credentials, ignoring MFA requirements, attempting unauthorized access) is subject to disciplinary action up to and including termination.

14.2 Audit & Review

• The InfoSec Program Lead conducts an annual access-control audit to verify:
  
  • All active accounts map to valid, active employees or approved partners
  • No accounts have excessive privileges beyond role requirements
  • MFA and password policies are enforced uniformly
• Findings are documented, and any gaps are remediated within 30 days.

15. Training & Awareness

• Onboarding: New employees and partners receive a mandatory orientation covering:
  
  • This Access Control Policy
  • Password and MFA requirements
  • How to request or modify access
  • Consequences of policy violations
• Ongoing:
  
  • Biannual refresher sessions on secure access practices (e.g., protecting credentials, recognizing phishing attempts).
  • Quarterly “Security Huddles” by Security Champions to discuss common access pitfalls and policy updates.

16. Related Policies & Documents

• Information Security Program (Document V1.0)
• Security Incident Response Program (Document V1.1)
• Media Use & Handling Policy (forthcoming Document)
• Acceptable Use Policy (describes acceptable use of Synoptix’s systems)
• Privacy Policy (customer-facing, outlines PII handling)

17. Revision History