Princeton Identity Security Hardening Guidelines

FOUNDATIONAL SECURITY & PHYSICAL/VIRTUAL ENVIRONMENT 

• Dedicated System & Isolation:

   

  • Dedicated Hardware/VM: The IDS and its database must run on a dedicated physical machine or virtual machine (VM). No other applications or services should share this host. 
  • Network Segmentation: Place the server on a dedicated, isolated network segment (VLAN or DMZ) with strict firewall rules. This segment should ideally not be directly accessible from the internet. 

  • Physical Security: For physical servers, ensure the machine is in a secure, locked, and monitored server room with restricted access.  o Hypervisor Security (for VMs): If a VM, ensure the hypervisor itself is hardened, updated, and secured with strong access controls.

     

• Full Disk Encryption (OS Drive and Data Drive): 

   

  • BitLocker/FDE: Encrypting the entire OS drive and any separate data drives where the database files reside provides a strong defense against physical theft or unauthorized copying of storage media 
  • Ensure BitLocker is configured for maximum security (e.g., TPM + PIN/USB key). 

OPERATING SYSTEM HARDENING (WINDOWS SERVER)  

Operating System Updates and Patch Management: 

• Automated Updates (Controlled): Configure Windows Update to automatically download and install critical and security updates. However, for a production server, it's recommended to have a patch management system (e.g., WSUS, SCCM, or a third-party tool) to test patches in a staging environment before deploying to production. 
• Regular Patching: Establish a strict schedule for applying all security patches, hotfixes, and service packs for Windows Server. 

• Unsupported Versions: Ensure the Windows Server OS is a currently supported version. Running outdated OS versions introduces significant vulnerabilities. 

   

• Remove Unnecessary Components & Services: 
  • Minimal Server Installation: Perform a minimal installation of Windows Server, installing only necessary roles and features. 
  • Disable Unused Services: Review and disable any Windows services that are not absolutely essential for the IDS software or the PostgreSQL database. Use services.msc and set the startup type to "Disabled" or "Manual" if only occasionally needed. 
  • Remove Unnecessary Software: Uninstall any applications, tools, or runtimes not directly required by the IDS or PostgreSQL.

• User Account and Authentication Management: 
  • IDS Accounts (for web page access) 
    • Built-in IDS Account: Use the built-in IDS account for initial setup and as a strictly controlled "break glass" account. 

    • LDAP/SSO Integration: Manage user accounts externally via LDAP/SSO. This centralizes identity management and allows for stronger authentication mechanisms (like MFA) at the identity provider level. Ensure secure communication (LDAPS) for this integration. 

       

• Strong Password Policy (System-Wide & IDS): 
  • Enforce Complex Passwords: Use Group Policy Objects (GPOs) for domain joined servers or Local Security Policy for standalone servers to enforce strong password requirements: minimum length (e.g., 14+ characters), complexity (uppercase, lowercase, numbers, symbols), history (prevent reuse of last X passwords), and regular expiration (e.g., 60-90 days). 

  • Implement Account Lockout: Configure account lockout policies (e.g., 3-5 failed attempts) to prevent brute-force attacks. 

     

• Least Privilege for All Accounts: 
  • No General User Access: No regular user accounts should have direct interactive logon access to the server unless absolutely necessary for specific administrative tasks. 
  • Dedicated Service Accounts: Create dedicated, low-privilege domain or local service accounts for the PostgreSQL database service and any other IDS-related services. These accounts should only have the minimum necessary file system and registry permissions. Crucially, these service accounts should NOT be members of the local "Administrators" group. 
  • Administrator Access: Limit administrative access (RDP, console) to only a very small, authorized group of IDS administrators. These administrators should use unique, complex passwords. 
  • Rename/Disable Default Accounts: Disable the built-in "Guest" account. Consider renaming the "Administrator" account. 

• Multi-Factor Authentication (MFA): Implement MFA for all administrative access to the Windows server (e.g., RDP via VPN with MFA, or a privileged access management solution). +

   

Network Security (Windows Firewall & Configuration): 

• Enable & configure Windows Firewall: Ensure Windows Firewall is fully enabled and configured to block all incoming and outgoing connections by default. 
• Whitelist Specific Ports & IPs: 
  • IDS Web Interface (8443, 443): 
    • Allow inbound on ports 8443 and 443 only from the specific IP addresses or subnets that legitimately need to access the IDS web interface. 
  • PostgreSQL Port (Default 5432): 
    • Crucial: The PostgreSQL port (default 5432) should NOT be directly accessible from the internet. It should only be accessible from the IDS application itself (localhost) and potentially from trusted internal application servers if the IDS architecture involves separate app servers. 
    • Configure inbound rules to allow 5432 only from localhost (127.0.0.1) or the specific internal IP address(es) of the IDS application components if they run separately on the same machine. 
• Remote Desktop (RDP): If RDP is enabled for administration (recommended only for admin access), restrict inbound RDP (port 3389) to only allow connections from trusted administrator workstations/IPs, ideally over a VPN connection. 
• Outbound Rules: Limit outbound connections to only what is absolutely necessary (e.g., patch management servers, LDAP/SSO servers, NTP servers, IDS licensing servers, centralized logging/SIEM).