T44.2: Manages Security

InterSystems IRIS implements security through a comprehensive Role-Based Access Control (RBAC) model. At the core of this model are users and roles, which together define who can access the system and what they can do.

User Account Provisioning: User accounts represent individual people, applications, or services that need to access InterSystems IRIS. Each user account includes:

• Username: A unique identifier for the account
• Password or authentication configuration: Credentials for validating the user's identity
• Account type: Distinguishes between human users and service accounts
• Enabled/disabled status: Controls whether the account can currently authenticate
• Expiration settings: Supports temporary or time-limited access

Users are created through the Management Portal at System Administration > Security > Users, or programmatically using the Security.Users class. When provisioning users, consider:

• Following organizational naming conventions (e.g., firstname.lastname or employee ID)
• Setting appropriate password policies and expiration
• Disabling accounts that are no longer needed rather than deleting them immediately
• Using service accounts for application-to-application communication
• Documenting the purpose and owner of each account

Role Definitions: Roles are collections of privileges and permissions that define what actions users can perform. Roles enable administrators to:

• Group related permissions logically (e.g., "DatabaseAdmin", "ReportViewer")
• Assign permissions to multiple users consistently
• Implement separation of duties and least privilege principles
• Adapt to organizational structure changes without modifying individual users

When defining roles:

• Use descriptive names that clearly indicate the role's purpose
• Follow a hierarchical or functional naming scheme
• Document what each role permits and when it should be assigned
• Start with minimal permissions and add as needed
• Review role definitions periodically to prevent privilege creep

The RBAC model allows users to be assigned multiple roles, and roles can contain other roles, enabling flexible and maintainable security architectures. This approach scales from small single-server deployments to large enterprise environments with thousands of users.

After creating users and defining roles, the next step in implementing security is assigning roles to users and granting appropriate privilege levels. This process determines what each user can actually do within the system.

Role Assignment: Roles are assigned to users through the Management Portal or programmatically. When a user authenticates, they receive all privileges and permissions associated with their assigned roles. Key considerations for role assignment include:

• Assign only the roles necessary for each user's job function
• Regularly review and audit role assignments
• Remove roles when users change positions or responsibilities
• Use temporary role assignments for short-term access needs
• Document the business justification for privileged role assignments

Special Roles: InterSystems IRIS includes several built-in roles with specific purposes:

• %All: Grants complete system access; restrict to system administrators only
• %DB_[database]: Provides access to specific databases
• %Service_[service]: Controls access to system services
• Custom application roles: Define application-specific permissions

Privilege Levels: Within the RBAC model, different privilege levels control the type of access granted:

• USE: Allows basic access to a resource or service
• READ: Permits viewing data or configuration but not modification
• WRITE: Enables creating, modifying, or deleting data
• ADMIN: Grants full control including permission management

These privilege levels apply to various system resources:

• Databases: Control data access and modification
• Services: Determine who can use web services, client connections, etc.
• Applications: Define access to application functionality
• System resources: Control administrative operations

Implementing Least Privilege: The principle of least privilege dictates that users should receive only the minimum permissions necessary to perform their duties. This reduces security risk by:

• Limiting the damage from compromised accounts
• Preventing accidental data modification or deletion
• Creating clear separation of duties
• Simplifying compliance and auditing

When granting privileges:

• Start with read-only access and elevate only when required
• Use time-limited privilege escalation for administrative tasks
• Regularly review and recertify user privileges
• Implement approval workflows for high-privilege role assignments
• Monitor usage of administrative privileges through audit logs

The combination of well-defined roles, appropriate privilege levels, and careful assignment creates a security model that balances operational needs with risk management.

Resource-level permissions provide granular control over access to system assets in InterSystems IRIS. Resources are the fundamental units of access control, representing databases, applications, services, and administrative functions that need protection.

Types of Resources: InterSystems IRIS protects several categories of resources:

• Database resources: Control access to specific databases
• Service resources: Govern use of system services (web, JDBC, ODBC, etc.)
• Application resources: Protect application-specific functionality
• Administrative resources: Control management and configuration operations
• Custom resources: Application-defined protected assets

Resource Permissions: Each resource can have permissions assigned at multiple levels:

• Public permissions: Apply to all authenticated users
• Role-specific permissions: Grant access to users with particular roles
• Permission types: READ, WRITE, USE, ADMIN depending on resource type

Configuring Permissions: Resource permissions are configured through the Management Portal at System Administration > Security > Resources. The configuration process involves:

1. Identifying the resource to protect 2. Determining the required permission level 3. Deciding whether to use public or role-specific permissions 4. Setting the permission and testing access

For database resources, permissions control:

• READ: Query and view data
• WRITE: Insert, update, and delete data
• The combination of these permissions determines data access patterns

For service resources, USE permission controls:

• Whether users can connect via specific protocols
• Which authentication methods are permitted
• Network access restrictions

Hierarchical Permissions: Resources can be organized hierarchically, with permissions potentially inherited from parent resources. This enables:

• Logical grouping of related resources
• Efficient permission management across multiple resources
• Override capabilities for exceptional cases

Best Practices:

• Define resources that align with your data classification and security policies
• Use descriptive resource names that indicate what they protect
• Default to denying access (no public permissions) unless specifically needed
• Document the purpose and permission requirements for each resource
• Regularly audit resource permissions to detect overly permissive configurations
• Test permission changes in non-production environments first

Application Integration: Applications can create custom resources to protect specific functionality:

• Define resources for sensitive operations
• Check permissions programmatically before executing protected code
• Provide clear error messages when permission is denied
• Log access attempts to custom resources for auditing

Resource-level permissions, combined with roles and privileges, create a comprehensive authorization framework that enforces access policies throughout the system.

InterSystems IRIS provides multiple services that enable different types of access to the system. Managing these services is a critical security function that directly impacts the system's attack surface.

Available Services: InterSystems IRIS includes several categories of services:

• %Service_Console: Local console and terminal access
• %Service_Telnet: Remote terminal access via Telnet
• %Service_WebGateway: Web application access through Web Gateway
• %Service_CallIn: Access via programming language bindings (Python, Java, .NET)
• %Service_ComPort: Serial communication port access
• %Service_Bindings: SOAP and web service bindings
• Database access services: JDBC, ODBC connections

Service Management: Services are configured through the Management Portal at System Administration > Security > Services. For each service, administrators can:

• Enable or disable the service entirely
• Require authentication or allow unauthenticated access
• Configure which authentication methods are permitted
• Set network access restrictions (IP address allowlists/denylists)
• Specify allowed service-specific options

Enabling Services: When enabling a service, consider:

• Business requirement: Is this access method actually needed?
• Authentication: What authentication methods should be permitted?
• Network restrictions: Should access be limited to specific IP ranges?
• Audit requirements: Should connections via this service be logged?
• Resource permissions: What resources should be accessible via this service?

Disabling Services: Disabling unused services is a key security hardening measure:

• Reduces potential attack vectors
• Prevents unauthorized access methods
• Simplifies security monitoring and auditing
• Eliminates risks from vulnerabilities in unused protocols

Services that are commonly disabled in hardened environments:

• %Service_Telnet: Insecure protocol, prefer SSH or encrypted alternatives
• %Service_ComPort: Rarely needed in modern deployments
• Development-only services in production environments

Service-Specific Security: Each service type has unique security considerations:

Web Services:

• Require HTTPS for sensitive data
• Implement proper authentication (not Unauthenticated)
• Configure session timeouts
• Enable audit logging for web access

Database Connections (JDBC/ODBC):

• Require authentication for all connections
• Use network restrictions to limit source IPs
• Employ encrypted connections where possible
• Monitor for unusual connection patterns

CallIn Services:

• Authenticate application connections
• Use service-specific credentials, not shared accounts
• Implement connection pooling limits
• Log connection attempts

Best Practices:

• Inventory all services and document which are required
• Disable services before deploying to production if not needed
• Use the most secure authentication method for each service
• Implement network-level restrictions in addition to service controls
• Regularly review service configurations as part of security audits
• Test service changes in non-production environments
• Document the business justification for each enabled service

Service configuration is a foundational security control that should be established during initial system hardening and reviewed regularly as part of ongoing security management.

In InterSystems IRIS, applications represent logical groupings of functionality with their own security requirements. Applications provide a security boundary that enforces authentication, authorization, and other security policies for specific areas of functionality.

Application Types: InterSystems IRIS supports several application types:

• CSP applications: Web applications accessed through browsers
• REST applications: RESTful web services
• SOAP applications: SOAP-based web services
• User-defined applications: Custom application contexts

Application Security Configuration: Each application can be configured with specific security settings through the Management Portal at System Administration > Security > Applications. Key configuration options include:

Authentication Settings:

• Allowed authentication methods (Password, Kerberos, Delegated, etc.)
• Whether unauthenticated access is permitted
• Login page and authentication endpoints
• Session timeout and password policies

Authorization Settings:

• Roles required to access the application
• Resources that protect application functionality
• Permission requirements for different operations

Session Management:

• Session timeout duration
• Session persistence settings
• Cookie security attributes (HttpOnly, Secure flags)
• Cross-site request forgery (CSRF) protection

Application Resources: Applications can define custom resources to protect specific functionality within the application. This enables:

• Fine-grained access control within applications
• Separation between different functional areas
• Role-based feature enabling/disabling
• Audit logging of access to sensitive features

To implement application resources: 1. Define resources for protected functionality 2. Assign permissions to appropriate roles 3. Check permissions programmatically before executing protected code 4. Provide user-friendly error messages for permission denials 5. Log access attempts for security monitoring

CSP Application Security: Web applications accessed through CSP (Caché Server Pages) have additional security considerations:

URL Access Control:

• Configure which URL paths are protected
• Set authentication requirements per application path
• Define allowed HTTP methods

CORS Configuration:

• Configure Cross-Origin Resource Sharing policies
• Restrict which domains can access the application
• Control allowed headers and methods

Content Security:

• Implement Content Security Policy (CSP) headers
• Configure X-Frame-Options to prevent clickjacking
• Enable HTTPS-only access for sensitive applications
• Validate and sanitize all user inputs

Application Roles: Applications can specify which roles are permitted to access them. This creates a second layer of authorization: 1. User authenticates to InterSystems IRIS 2. System verifies user has one of the application's allowed roles 3. Within the application, resource permissions further restrict access 4. Application code can perform additional custom authorization checks

Best Practices:

• Define applications that align with functional boundaries and security zones
• Use different applications for public vs. internal functionality
• Require authentication for all applications handling sensitive data
• Implement the strongest authentication method appropriate for each application
• Configure appropriate session timeouts (shorter for sensitive applications)
• Enable audit logging for security-critical applications
• Regularly review application configurations and access logs
• Test authentication and authorization in development environments
• Document the security requirements and configuration for each application
• Use HTTPS for all applications transmitting sensitive data

Application-level security, combined with system-level controls, creates defense-in-depth that protects against unauthorized access and reduces the impact of security breaches.

InterSystems IRIS provides two complementary encryption approaches to protect sensitive data: block-level database encryption and application-level data element encryption.

Block-Level Database Encryption: Database encryption protects entire databases at the storage level using Advanced Encryption Standard (AES) encryption. This approach provides:

• Protection of all data within the database
• Transparent operation once configured
• Minimal performance overhead
• Protection against storage media theft or unauthorized access

Implementing Database Encryption: 1. Create or obtain an encryption key 2. Configure the database to use encryption 3. Encrypt existing data (for existing databases) 4. Manage and protect the encryption keys

Database encryption configuration involves:

• Selecting the AES key size (128-bit or 256-bit)
• Choosing a key management approach
• Planning for key rotation and backup
• Testing performance impact in your environment

Encryption applies to:

• Database files on disk
• Write Image Journal (WIJ) when database is encrypted
• Journal files when separately configured for encryption

Data Element Encryption: While database encryption protects the entire database, data element encryption focuses on specific sensitive fields within application data. This is useful when:

• Only certain fields contain sensitive information (SSN, credit cards, health data)
• Different fields require different encryption keys
• Compliance requirements mandate field-level encryption
• Applications need to search on some fields but not others

Implementing Data Element Encryption: Data element encryption is implemented at the application level: 1. Identify fields requiring encryption 2. Select appropriate encryption algorithms 3. Implement encryption/decryption in application code 4. Manage encryption keys for data elements 5. Update queries and indexes to accommodate encrypted data

The %System.Encryption class provides methods for:

• Encrypting and decrypting data elements
• Key management operations
• Algorithm selection

Encryption Key Management: Proper key management is critical for encryption security:

Key Storage Options:

• Key files: Encryption keys stored in protected files on the system
• KMIP servers: External key management using Key Management Interoperability Protocol
• Hardware Security Modules (HSM): Dedicated cryptographic hardware

Key Management Best Practices:

• Store keys separately from encrypted data
• Implement strict access controls on key files and key management systems
• Back up keys securely; lost keys mean permanently inaccessible data
• Plan and test key rotation procedures
• Use KMIP or HSM for high-security environments
• Document key management procedures and responsibilities
• Separate key management duties from database administration
• Regularly audit key access and usage

Key Rotation: Encryption keys should be rotated periodically:

• Establishes a schedule based on security policy and compliance requirements
• Plan for re-encryption of data with new keys
• Test rotation procedures before production implementation
• Maintain access to old keys for data encrypted with them

Performance Considerations: Modern processors include AES encryption instructions that minimize performance impact:

• Database encryption: Typically less than 10% overhead with AES-NI
• Data element encryption: Performance depends on implementation and frequency
• Test in your specific environment with representative workloads
• Consider hardware cryptographic acceleration for high-throughput systems

Compliance and Regulations: Encryption helps meet various regulatory requirements:

• HIPAA: Protects healthcare data
• PCI DSS: Secures payment card information
• GDPR: Safeguards personal data
• FISMA: Federal information security
• State data breach notification laws

Implementation Strategy: 1. Classify data to identify what needs encryption 2. Determine whether database or data element encryption is appropriate 3. Select key management approach based on security requirements 4. Implement encryption in development/test environment 5. Test application compatibility and performance 6. Create key management and recovery procedures 7. Deploy to production with proper change management 8. Document encryption configuration and key management 9. Train staff on encryption operations and key management

Encryption provides essential protection for sensitive data but must be implemented thoughtfully with proper key management to be effective.

Journal files in InterSystems IRIS record all database changes, enabling transaction processing, recovery, and data replication. Because journal files contain the same sensitive data as the databases they protect, journal encryption is essential when implementing data protection.

Purpose of Journal Encryption: Journal files contain:

• All database modifications (inserts, updates, deletes)
• Transaction details and metadata
• Potentially sensitive business data
• Recovery information for disaster scenarios

Without encryption, journal files represent a data leakage risk:

• Journal files might be backed up to less-secure storage
• Old journal files may remain after database encryption
• Journal files transferred for replication could be intercepted
• Archive journal files might have weaker access controls

Implementing Journal Encryption: Journal encryption is configured at the system level and applies to all journal files created after enablement. The configuration process involves:

1. Ensure database encryption is configured (journal encryption uses the same key management) 2. Enable journal encryption through the Management Portal or programmatically 3. Existing journal files remain unencrypted; new files are encrypted 4. Optionally re-encrypt old journal files for complete protection

Journal Encryption Configuration: Journal encryption settings are managed through System Administration > Configuration > Journal Settings. Key configuration options include:

• Enable/disable journal encryption
• Encryption key selection (uses database encryption keys)
• Handling of existing unencrypted journal files

Key Management for Journal Encryption: Journal encryption uses the same key management infrastructure as database encryption:

• Key files or KMIP servers store encryption keys
• Keys must be available for journal creation and reading
• Lost keys prevent journal recovery and restore operations
• Key backup and protection is critical for disaster recovery

Relationship to Database Encryption: When database encryption is enabled:

• Journal encryption is strongly recommended and often required
• Both database and journal use compatible key management
• Restoring encrypted databases requires encrypted journals
• Consistency between database and journal encryption is essential

Journal Encryption and System Operations:

Backup and Restore:

• Encrypted journal files remain encrypted in backups
• Restoration requires access to encryption keys
• Test restore procedures with encrypted journals
• Document key availability requirements for recovery

Replication:

• Encrypted journal files can be replicated
• Target systems need appropriate keys for journal dejournaling
• Network transfer of encrypted journals provides data protection
• Configure consistent encryption across replication topology

Performance Impact: Journal encryption has minimal performance overhead:

• Modern processors with AES-NI support provide hardware acceleration
• Journal write performance typically impacted less than 5%
• The slight overhead is offset by security benefits
• Test in your environment with representative workloads

Migration Considerations: When implementing journal encryption on existing systems:

• New journal files are encrypted immediately upon enablement
• Existing journal files remain unencrypted
• Consider re-encrypting archived journal files for complete protection
• Plan for key management before enabling encryption
• Test recovery procedures with encrypted journals

Best Practices:

• Enable journal encryption whenever database encryption is used
• Implement key management before enabling encryption
• Regularly backup encryption keys to secure, separate storage
• Test journal recovery procedures with encrypted journals
• Document encryption configuration and key locations
• Train operations staff on encrypted journal handling
• Monitor journal encryption status as part of security audits
• Include encryption keys in disaster recovery planning
• Maintain strict access controls on journal files and keys

Compliance Considerations: Journal encryption helps satisfy regulatory requirements:

• Protects data in transaction logs as required by many regulations
• Ensures complete data protection (database + journals)
• Demonstrates comprehensive security controls to auditors
• Prevents data leakage through backup and archive processes

Troubleshooting: Common journal encryption issues:

• Key availability: Ensure keys are accessible for journal operations
• Recovery failures: Verify correct keys are available for restore
• Performance: Monitor journal write performance and adjust as needed
• Replication: Confirm key synchronization across mirror members

Journal encryption is a critical complement to database encryption, ensuring that all copies of sensitive data receive appropriate protection throughout their lifecycle.

System-wide security policies in InterSystems IRIS provide centralized control over security behaviors that affect all users and applications. These policies enforce organizational security standards and compliance requirements consistently across the entire system.

Password Policies: Password policies control the strength and lifecycle of user credentials:

Password Complexity:

• Minimum password length (e.g., 8, 12, or more characters)
• Required character types (uppercase, lowercase, numbers, special characters)
• Prevention of common or weak passwords
• Restrictions on username in password

Password Expiration:

• Maximum password age (e.g., 90 days) before forced change
• Warning period before expiration
• Grace period after expiration
• Prevention of password reuse (password history)

Password Management:

• Minimum password age (prevents rapid password changes to bypass history)
• Number of previous passwords to remember
• Administrator password reset requirements
• Self-service password change options

Login and Authentication Policies: These policies control how users authenticate and what happens when authentication fails:

Failed Login Controls:

• Maximum allowed failed login attempts
• Account lockout duration after failed attempts
• Lockout reset mechanisms (automatic or manual)
• Administrator notification of lockouts

Session Management:

• Idle session timeout duration
• Absolute session maximum lifetime
• Concurrent session limits per user
• Session termination on password change

Authentication Requirements:

• Allowed authentication methods (Kerberos, LDAP, Instance, OS-based)
• Two-factor authentication requirements
• Password strength requirements at login
• Re-authentication for sensitive operations

Audit Policies: Audit policies determine what security events are logged:

Event Categories:

• Authentication events (login, logout, failed attempts)
• Authorization events (permission denials, privilege usage)
• Administrative actions (user changes, configuration modifications)
• Data access patterns (sensitive data queries)
• System events (service start/stop, security configuration changes)

Audit Configuration:

• Which event categories are enabled
• Level of detail captured for each event
• Audit log retention periods
• Audit database size limits and rotation

System Security Settings: Additional system-wide security configurations include:

Service Policies:

• Default service enabled/disabled state
• Allowed authentication methods per service type
• Network access restrictions
• Service-level encryption requirements

Application Policies:

• Default application security posture
• Required roles for application access
• Session security settings
• Web application security headers

Data Protection Policies:

• Encryption requirements for new databases
• Journal encryption defaults
• Backup encryption settings
• Data classification and handling rules

Implementing Security Policies: Security policies are configured through the Management Portal at System Administration > Security > System Security:

1. Access system security settings 2. Configure password policies based on organizational requirements 3. Set login and authentication policies 4. Enable appropriate audit categories 5. Configure additional security settings 6. Test policies in non-production environment 7. Document policy settings and rationale 8. Deploy to production systems 9. Monitor policy effectiveness 10. Review and update policies periodically

Policy Best Practices:

• Align policies with organizational security standards and compliance requirements
• Balance security with usability to prevent workarounds
• Document the business and compliance drivers for each policy
• Test policy changes before production deployment
• Communicate policy changes to users in advance
• Monitor policy violations and exceptions
• Regularly review policies as threats and standards evolve
• Use consistent policies across development, test, and production where appropriate
• Implement stricter policies for privileged accounts
• Provide clear error messages when policies prevent actions

Compliance Alignment: Security policies help meet various compliance requirements:

• NIST 800-53: Federal security controls
• ISO 27001: Information security management
• SOC 2: Trust services criteria
• HIPAA: Healthcare data protection
• PCI DSS: Payment card security
• GDPR: Privacy and data protection

Policy Monitoring and Enforcement:

• Review audit logs for policy violations
• Monitor failed login attempts and lockouts
• Track password expiration and changes
• Analyze authentication patterns for anomalies
• Report on policy compliance to management
• Investigate policy violation trends

Exception Handling:

• Document processes for policy exceptions
• Require approval for exception requests
• Time-limit exceptions where possible
• Monitor excepted accounts more closely
• Periodically review active exceptions

System-wide security policies provide the foundation for consistent security posture across InterSystems IRIS deployments, enforcing organizational standards and supporting compliance requirements.

InterSystems IRIS provides robust import and export capabilities for security configurations, enabling administrators to backup, replicate, and migrate security settings across systems. This functionality is essential for maintaining consistent security postures across development, test, and production environments.

Export Security Configurations: The export operation creates XML files containing security definitions. These exports can include:

Exportable Security Elements:

• User accounts (with or without passwords)
• Role definitions and role assignments
• Resources and their permissions
• Applications and their security settings
• Service configurations
• System security policies
• SSL/TLS configurations

Export Options:

• Full export: All security configurations in one file
• Selective export: Specific users, roles, resources, or applications
• Password inclusion: Choice to include or exclude password hashes
• Export format: XML structure for portability and version control

Performing Exports: Security exports are performed through the Management Portal at System Administration > Security > Export or programmatically using the Security.Export class:

1. Select security elements to export (all or selective) 2. Choose whether to include passwords 3. Specify output file location 4. Execute export operation 5. Verify export file contents 6. Store export file securely

Import Security Configurations: The import operation applies security settings from XML files to the target system:

Import Behavior:

• Create: Adds new security elements that don't exist
• Update: Modifies existing elements with new settings
• Replace: Removes existing elements and adds from import
• Merge: Combines imported settings with existing configurations

Import Options:

• Full import: Apply all settings from export file
• Selective import: Choose specific elements to import
• Conflict resolution: Specify how to handle conflicts with existing settings
• Validation: Check import file before applying

Performing Imports: Security imports are performed through the Management Portal at System Administration > Security > Import or programmatically using the Security.Import class:

1. Prepare import XML file 2. Review current security configuration 3. Select import file and import options 4. Preview changes (if supported) 5. Execute import operation 6. Verify imported configurations 7. Test security settings 8. Review audit logs for import activity

Use Cases for Import/Export:

Configuration Backup:

• Regular exports provide point-in-time security configuration backups
• Exports enable quick recovery from misconfigurations
• Version control of export files tracks configuration changes over time

Environment Promotion:

• Export security from development, import to test
• Promote tested configurations to production
• Maintain consistency across environment tiers
• Support automated deployment pipelines

Disaster Recovery:

• Include security exports in disaster recovery documentation
• Test security import as part of DR drills
• Ensure security configurations match data restores

System Cloning:

• Replicate security settings to new systems
• Standardize security across multiple instances
• Support rapid deployment of new environments

Compliance and Auditing:

• Export configurations for compliance reviews
• Provide evidence of security controls to auditors
• Track security configuration changes over time
• Document security posture at specific points in time

Best Practices:

• Schedule regular automated security exports
• Store export files in secure, backed-up locations
• Version control export files to track changes
• Document the purpose and contents of each export
• Test imports in non-production before production deployment
• Review imported configurations after import operations
• Use selective exports for specific migration scenarios
• Exclude passwords from exports when sharing configurations
• Validate export files before attempting imports
• Maintain separate exports for different security domains (users, applications, etc.)

Security Considerations:

• Export files may contain sensitive information:
• Password hashes (if included)
• Security architecture details
• Resource and application configurations
• Protect export files appropriately:
• Restrict file system access to exports
• Encrypt export files for long-term storage
• Use secure channels when transferring exports
• Audit access to export files
• Limit password inclusion to necessary scenarios

Migration Workflow: A typical security migration workflow:

1. Document current security configuration 2. Export security from source system 3. Review export file for accuracy 4. Prepare target system (verify compatibility) 5. Test import in non-production environment 6. Resolve any conflicts or issues 7. Schedule production import during maintenance window 8. Perform import with appropriate options 9. Validate imported configuration 10. Test authentication and authorization 11. Monitor for issues post-import 12. Document migration and any changes made

Automation and Integration: Security import/export can be integrated into automated workflows:

• CI/CD pipelines for application deployment
• Infrastructure-as-code tooling
• Configuration management systems
• Automated environment provisioning
• Scheduled backup operations

Troubleshooting: Common import/export issues:

• Version compatibility: Ensure export/import versions match
• Conflicts: Resolve conflicts between imported and existing configurations
• Dependencies: Import dependent objects in correct order
• Validation errors: Fix XML structure or content issues
• Permissions: Verify administrative permissions for import/export operations

Import and export capabilities provide essential tools for managing security configurations across the system lifecycle, from development through production, and support disaster recovery and compliance requirements.

Reducing the attack surface of InterSystems IRIS is a fundamental security principle that minimizes the number of ways an attacker can potentially compromise the system. A smaller attack surface means fewer potential vulnerabilities and a more defensible security posture.

Attack Surface Components: The attack surface of an InterSystems IRIS installation includes:

• Enabled services and protocols
• Open network ports
• Installed features and functionality
• Running processes
• Enabled authentication methods
• Active user accounts
• Accessible applications and web interfaces
• Administrative interfaces

Attack Surface Reduction Strategies:

Disable Unused Services:

• Review all enabled services through System Administration > Security > Services
• Disable services not required for business operations:
• %Service_Telnet (use SSH instead)
• Unused database access methods (JDBC, ODBC if not needed)
• Development services in production
• Legacy protocols and services
• Document which services are required and why
• Regularly audit enabled services

Remove Unnecessary Features:

• Uninstall or disable unused InterSystems components
• Remove sample applications and databases from production
• Disable development tools in production environments
• Remove default accounts and applications
• Eliminate test or demonstration functionality

Network Hardening:

• Close unused network ports at firewall level
• Implement network segmentation
• Restrict management interfaces to administrative networks
• Use VPNs for remote administrative access
• Disable unnecessary network protocols

Security Advisor Tool: InterSystems provides the Security Advisor tool to help identify and remediate security issues:

Security Advisor Capabilities:

• Scans system configuration for security weaknesses
• Provides prioritized list of security recommendations
• Offers guidance for remediation
• Tracks security improvement over time
• Generates security reports for management

Using Security Advisor: 1. Access Security Advisor through Management Portal 2. Run security scan of current configuration 3. Review identified issues and their severity 4. Prioritize remediation based on risk and impact 5. Apply recommended fixes 6. Re-scan to verify improvements 7. Schedule regular Security Advisor scans

Security Advisor Categories:

• User and authentication security
• Service and network security
• Application and web security
• Audit and logging configuration
• Database and data protection
• System configuration security

Installation Security Levels: InterSystems IRIS supports different security levels during installation:

Minimal Security:

• Permissive default settings
• Suitable only for isolated development
• Many services enabled by default
• Simplified authentication
• Not recommended for production

Normal Security:

• Balanced security and usability
• Appropriate for most deployments
• Requires explicit enablement of privileged access
• Standard production configuration

Locked Down Security:

• Maximum security posture
• Minimal enabled services
• Strict authentication requirements
• All non-essential features disabled
• Recommended for high-security environments

Implementing Locked Down Installation:

• Select locked down option during installation
• Further customize based on specific requirements
• Document all enabled features and justifications
• Use as baseline for security hardening

Ongoing Attack Surface Management:

Regular Security Reviews:

• Schedule quarterly or bi-annual security reviews
• Re-assess business requirements for enabled features
• Remove services and accounts no longer needed
• Update security configuration as threats evolve

Change Management:

• Review security impact of all system changes
• Require justification for enabling new services
• Document and approve deviations from baseline
• Periodically recertify enabled functionality

Monitoring and Detection:

• Monitor audit logs for unusual access patterns
• Alert on attempted use of disabled services
• Track failed authentication attempts
• Detect reconnaissance activities

Specific Attack Surface Reduction Measures:

User Accounts:

• Disable or remove unused accounts
• Eliminate default accounts (e.g., demo accounts)
• Implement account lifecycle management
• Require periodic account recertification
• Use service accounts instead of shared credentials

Authentication:

• Disable weak authentication methods
• Enforce strong authentication for all access
• Implement two-factor authentication
• Remove or restrict local accounts

Applications:

• Remove sample and demonstration applications
• Disable unused web applications
• Implement application allow-listing
• Restrict access to administrative interfaces

Ports and Protocols:

• Document all required ports
• Close unnecessary ports at firewall
• Use non-standard ports where appropriate
• Implement port scanning detection

Management Interfaces:

• Restrict Management Portal access to administrative networks
• Use separate administrative accounts
• Implement privileged access management
• Require MFA for administrative access
• Log all administrative activities

Best Practices:

• Start with minimal functionality and add as needed
• Document business justification for all enabled features
• Implement defense in depth (multiple security layers)
• Test security changes in non-production first
• Maintain current security patches and updates
• Subscribe to security advisories
• Participate in security communities
• Conduct periodic penetration testing
• Engage third-party security assessments

Compliance Considerations: Attack surface reduction supports compliance with:

• NIST 800-53: Least functionality principle (CM-7)
• CIS Controls: Secure configuration management
• PCI DSS: Removal of unnecessary functionality
• HIPAA: Access controls and minimum necessary
• ISO 27001: Asset management and access control

A reduced attack surface directly translates to improved security posture, easier compliance, and lower risk of successful attacks. Regular assessment and ongoing management ensure that the attack surface remains minimal as the system evolves.

Two-factor authentication (2FA), also called multi-factor authentication (MFA), significantly strengthens security by requiring users to provide two different types of credentials to authenticate. Even if one factor (like a password) is compromised, the attacker cannot access the system without the second factor.

Authentication Factors: Authentication factors fall into three categories: 1. Something you know: Passwords, PINs, security questions 2. Something you have: Smart cards, tokens, mobile devices, authenticator apps 3. Something you are: Biometrics (fingerprint, face recognition, retina scan)

Two-factor authentication requires factors from two different categories. Common combinations include:

• Password + SMS code
• Password + authenticator app code
• Password + hardware token
• Password + biometric
• Smart card + PIN

Two-Factor Authentication in InterSystems IRIS: InterSystems IRIS supports two-factor authentication through several mechanisms:

Delegated Authentication: The primary method for implementing 2FA in InterSystems IRIS is delegated authentication, which allows external identity providers to handle authentication:

• LDAP servers with 2FA capability
• Active Directory Federation Services (ADFS)
• SAML-based identity providers
• OAuth/OpenID Connect providers
• Custom authentication services

With delegated authentication: 1. User attempts to access InterSystems IRIS 2. System redirects to external identity provider 3. Identity provider performs authentication (including 2FA) 4. Upon successful authentication, identity provider returns token 5. InterSystems IRIS validates token and grants access

Kerberos Authentication: Kerberos can be part of a 2FA solution when combined with smart cards or other pre-authentication mechanisms:

• Smart card + PIN for Kerberos ticket acquisition
• Kerberos provides single sign-on after initial 2FA
• Common in enterprise Windows environments

Custom Authentication: Organizations can implement custom authentication logic that:

• Validates primary credentials (password)
• Prompts for second factor
• Validates second factor against authentication service
• Grants access upon successful validation

Implementation Approaches:

SMS-Based 2FA:

• User enters username and password
• System sends one-time code via SMS
• User enters code to complete authentication
• Pros: Widely available, familiar to users
• Cons: Vulnerable to SIM swapping, requires cellular coverage

Authenticator Apps:

• User installs authenticator app (Google Authenticator, Microsoft Authenticator, etc.)
• System provides QR code for app enrollment
• App generates time-based one-time passwords (TOTP)
• User enters current code to authenticate
• Pros: More secure than SMS, works offline
• Cons: Requires smartphone, user setup complexity

Hardware Tokens:

• User receives physical token device
• Token generates one-time codes
• User enters code during authentication
• Pros: Very secure, doesn't require smartphone
• Cons: Cost, token management, can be lost

Biometric Authentication:

• User enrolls biometric data (fingerprint, face, etc.)
• Authentication requires biometric verification
• Combined with password or other factor
• Pros: Convenient, difficult to forge
• Cons: Privacy concerns, requires specialized hardware

Push Notifications:

• User receives push notification on registered device
• User approves authentication request
• System grants access upon approval
• Pros: User-friendly, secure
• Cons: Requires internet connectivity, smartphone

Implementation Steps:

1. Select 2FA Approach:

• Assess organizational requirements and user population
• Evaluate technology options and costs
• Consider user experience and support requirements
• Pilot with small group before full deployment

2. Configure Identity Provider:

• Set up external authentication service if using delegated auth
• Configure 2FA methods in identity provider
• Test authentication flows
• Configure fallback and recovery options

3. Configure InterSystems IRIS:

• Set up delegated authentication configuration
• Specify identity provider details
• Configure authentication mapping
• Test integration with identity provider

4. User Enrollment:

• Develop enrollment process and documentation
• Provide user training and support
• Support users through initial enrollment
• Establish helpdesk procedures for issues

5. Policy Configuration:

• Define which users require 2FA (all, privileged, remote, etc.)
• Configure enforcement policies
• Set up exception processes
• Document policy rationale

6. Deployment:

• Phase deployment to manage support load
• Start with administrative accounts
• Expand to remote access users
• Eventually require for all access

Best Practices:

User Experience:

• Provide clear instructions for enrollment and usage
• Offer multiple 2FA options where possible
• Implement "remember this device" for trusted devices
• Balance security with usability

Recovery and Fallback:

• Establish recovery procedures for lost devices
• Provide backup codes for emergency access
• Document account recovery process
• Train helpdesk on 2FA support

Phased Implementation:

• Start with highest-risk accounts (administrators)
• Expand to remote access users
• Gradually extend to all users
• Monitor and address issues at each phase

Privileged Access:

• Require 2FA for all administrative access
• Use stronger 2FA methods for privileged accounts
• Limit 2FA exemptions
• Audit privileged access regularly

Monitoring and Compliance:

• Log all authentication attempts including 2FA
• Monitor for 2FA failures and anomalies
• Report on 2FA adoption and compliance
• Regularly review 2FA configuration

Security Considerations:

Backup Methods:

• Provide secure recovery mechanisms
• Limit recovery method usage
• Audit recovery method activations
• Periodically verify backup methods

Session Management:

• Implement appropriate session timeouts
• Re-authenticate for sensitive operations
• Terminate sessions on device change
• Monitor for session hijacking

Implementation Risks:

• User resistance and support burden
• Account lockouts from lost devices
• Recovery process abuse
• Deployment complexity

Mitigation Strategies:

• Comprehensive user communication and training
• Robust recovery procedures
• Gradual phased deployment
• Adequate support resources

Compliance Benefits: Two-factor authentication helps meet requirements from:

• NIST 800-63B: Digital identity guidelines
• PCI DSS: Multi-factor for administrative access
• HIPAA: Strong authentication for ePHI access
• GDPR: Appropriate technical measures
• FFIEC: Financial institution authentication guidance
• State data protection laws

Use Cases for 2FA:

• Administrative and privileged access (highest priority)
• Remote access to production systems
• Access to sensitive data
• Web-based application access
• Database administrator connections
• Third-party and vendor access

Two-factor authentication represents one of the most effective security controls available, dramatically reducing the risk from credential theft, phishing, and unauthorized access. While implementation requires planning and user support, the security benefits far outweigh the costs.

The InterSystems Web Gateway is a critical component that enables web applications hosted on external web servers (Apache, IIS, nginx) to communicate with InterSystems IRIS. Proper Web Gateway configuration is essential for both functionality and security of web-based applications.

Web Gateway Architecture: The Web Gateway consists of:

• Web server plugin/module installed on the external web server
• Configuration that maps URLs to InterSystems IRIS applications
• Network communication between web server and InterSystems IRIS
• Security controls for authentication and authorization

Supported Web Servers: InterSystems Web Gateway supports:

• Apache HTTP Server on Linux/Unix/Windows
• Microsoft IIS on Windows
• Other web servers via generic CGI interface

Installation and Configuration:

Web Gateway Installation: 1. Install Web Gateway software on web server system 2. Configure web server to load Web Gateway module 3. Create Web Gateway configuration files 4. Define connections to InterSystems IRIS instances 5. Test connectivity and basic functionality

Server Configuration: Define InterSystems IRIS server connections in Web Gateway configuration:

• Server name and IP address/hostname
• Web server port (typically 52773 or custom)
• Connection timeout settings
• Maximum connections (connection pooling)
• SSL/TLS settings for encrypted communication

Application Configuration: Map web URLs to InterSystems IRIS applications:

• URL path (e.g., /myapp/*)
• Target InterSystems IRIS application
• Application type (CSP, REST, SOAP)
• Security settings for the mapping

Security Configuration:

Web Gateway Security Features:

• SSL/TLS termination at web server
• Authentication integration
• IP address restrictions
• Request filtering and validation
• Connection security to InterSystems IRIS

SSL/TLS Configuration: External web servers can handle SSL/TLS termination:

• Configure SSL certificates on web server
• Set up HTTPS listeners
• Configure cipher suites and protocols
• Enable HTTP Strict Transport Security (HSTS)
• Optionally encrypt Web Gateway to IRIS communication

Authentication Integration: Web Gateway can integrate with various authentication methods:

• Web server native authentication (Basic, Digest, etc.)
• Active Directory/LDAP authentication
• Certificate-based authentication
• Pass-through to InterSystems IRIS authentication
• Delegated authentication to external providers

Application-Level Security: Configure security for each web application:

• Authentication requirements
• Allowed roles for access
• Session settings
• CORS policies
• Content security policies

Load Balancing and High Availability:

Load Balancing: Web Gateway supports distributing requests across multiple InterSystems IRIS instances:

• Round-robin load distribution
• Connection pooling to multiple servers
• Failover on server unavailability
• Session affinity (sticky sessions) when required

High Availability Configuration:

• Configure multiple InterSystems IRIS servers in Web Gateway
• Implement health checks to detect failures
• Set up automatic failover
• Monitor connection status
• Coordinate with mirroring or clustering

Performance Optimization:

Connection Pooling:

• Configure appropriate connection pool sizes
• Set connection timeout values
• Monitor connection utilization
• Adjust pools based on load patterns

Caching:

• Leverage web server caching capabilities
• Configure cache headers appropriately
• Use Content Delivery Networks (CDNs) for static content
• Cache CSP page output where appropriate

Request Handling:

• Configure request timeout values
• Set maximum request sizes
• Implement rate limiting at web server
• Monitor request patterns and performance

Management and Monitoring:

Web Gateway Management Page: Access Web Gateway management interface to:

• View server connection status
• Monitor active connections
• Review application mappings
• Test connectivity
• Update configuration

Logging and Monitoring:

• Enable Web Gateway logging
• Monitor web server access and error logs
• Track connection failures and errors
• Alert on availability issues
• Review performance metrics

Configuration Management:

• Version control Web Gateway configurations
• Document application mappings and purposes
• Test configuration changes before production
• Maintain consistency across environments

Best Practices:

Security Hardening:

• Use HTTPS for all production web applications
• Enable modern TLS protocols only (TLS 1.2+)
• Implement strong cipher suites
• Configure HSTS and other security headers
• Restrict Web Gateway management interface access
• Use encrypted connections between Web Gateway and IRIS
• Implement IP restrictions where appropriate

Deployment:

• Test Web Gateway configuration in non-production first
• Document all application mappings and their purposes
• Use consistent naming conventions
• Maintain separate configurations per environment
• Automate configuration deployment where possible

Monitoring:

• Monitor Web Gateway connectivity to InterSystems IRIS
• Alert on connection failures
• Track response times and performance
• Review logs for errors and security events
• Monitor connection pool utilization

Maintenance:

• Keep Web Gateway version current
• Apply security patches promptly
• Review and update SSL certificates before expiration
• Periodically review application mappings
• Remove obsolete applications and configurations

Troubleshooting:

Common Issues:

• Connection failures between Web Gateway and InterSystems IRIS
• Authentication problems
• SSL/TLS configuration errors
• Application mapping misconfigurations
• Performance problems under load

Diagnostic Steps:

• Check Web Gateway logs for errors
• Verify network connectivity
• Test application mappings in Web Gateway management
• Review InterSystems IRIS web server configuration
• Verify firewall rules allow required ports
• Check SSL certificate validity

Integration Scenarios:

Public Web Applications:

• External web server in DMZ handles public requests
• Web Gateway securely connects to InterSystems IRIS in internal network
• Firewall rules allow only required Web Gateway connections
• SSL termination at external web server

Internal Applications:

• Web server on internal network
• Direct connectivity to InterSystems IRIS
• May use less stringent security where appropriate
• Integration with internal authentication systems

Hybrid Deployments:

• Combination of public and internal web servers
• Different security requirements for each
• Separate Web Gateway configurations
• Coordinated application deployment

The Web Gateway is a critical component for deploying web applications with InterSystems IRIS. Proper configuration ensures security, performance, and reliability of web-based functionality, while enabling integration with enterprise web server infrastructure and security tools.