RapidIdentity Security Statement Addendum

This addendum is part of the RapidIdentity Security information that describes the security set up behind RapidIdentity Cloud.

1. Penetration Testing

Identity Automation enlists the use of third parties to perform testing on a periodic basis. Results can be provided on a limited basis upon request. An overall finding will be produced for customers; however, we will not directly provide complete details or any findings unless or until Engineering has had time to review and rectify any issues. Even then, specifics will generally not be provided, as our findings are internal and not publicly disclosed (such as via Mitre or NIST), enabling us to minimize the impact due to early public disclosure before customers have time to be contacted to address the issues.

2. Software Development Lifecycle (SDLC) Controls

At Identity Automation, we employ various controls throughout our development process to deliver secure and stable software.
Throughout the conceptual, functional, technical requirement and design phases, we ensure that ideas are thoroughly analyzed for usability and security via group discussion and peer review. These take into account current information on security industry standards and methodologies.
In coding, our engineering staff performs peer review to ensure security and conformity to standards. Additionally, Engineering works with and involves our Information Security team for additional resources on any questions that arise regarding findings or processes that might require refinement for vulnerability, compliance, and regulatory issues.
Solution Testing is performed by Quality Assurance engineers and technical support to determine any issues while security-specific testing (vulnerability scanning or penetration testing) is periodically performed by certified third parties in order to find and eliminate security issues both before (design), during (deployment), and after (maintenance) phases of the release cycle.
During software implementations, or as questions arise, the Support, Engineering, and Information Security teams discuss any additional security needs, such as backup, access control, encryption of data, etc. that are relevant to our specific customer environment.
Identity Automation has a bug tracking system in place, wherein our bugs are entered, reviewed, and remediated, and then go through a workflow process through which testing and validation occur before fixes, patches, or upgrades are released.
Finally, Identity Automation uses strict version control, and does internal development nightly builds that are committed on a consistent basis to give our teams adequate time to test and validate all changes.

3. Integration with Splunk and other SEIM Systems

Direct Splunk or Security Information and Event Management (SEIM) specific usage information is outside the area of focus for Identity Automation as a company. However, identity events that occur with RapidIdentity Portal can be sent to any syslog device, as well as to our database, and syslog can be integrated into Splunk, just as any other syslog data can be, for analysis. Additionally, RapidIdentity Connect actions provide the ability to customize what data our actions send to our audit log database and other syslog/event logging systems. Configuration for syslog can be found within Configuration > Audit Logging > Audit Types. Further Splunk-specifi information pertaining to syslog can be found in their documentation at http://docs.splunk.com/Documentation/Splunk/6.2.2/Data/SysgTCP.

4. Information that is Logged

Most event types, actions, and other data (including perpetrator, target, IP address, timestamp, and other action-specific details can be logged directly to the audit database. Additionally, using RapidIdentity Connect, data of any type can be sent to various systems such as databases, SEIM solutions, event logs, text files, email, etc.

5. Logstash

Audit logging can also be configured to audit to file (as with database and syslog). When the audit file is being utilized, Logstash and Kibana can be used for fast indexing and searching of centralized audit data.

6. MFA Controls for Privileged Accounts

Multi-factor authentication can be enabled based on any number of Authentication Policies and configured through the RapidIdentity Appliance interface. This option can be found in Configuration > Policies > Authentication Policies. The policies may be applied based on LDAP filter (such that any valid search filter that yields administrative or privileged accounts can be selected) as well as providing configurable options for Time of Day, Day of Week, Source Network, and whether or not the browser is expected to present a Kerberos token. Supported authentication methods include Password, TOTP, SMS OTP, Kerberos, Biometrics (via mobile push), challenge responses, and social (e.g. Facebook, Twitter, LinkedIn).

7. RapidIdentity Cloud

RapidIdentity Cloud is the cloud-based version of RapidIdentity that is not used in on-premise environments.
Identity Automation supports privately hosted solutions and offers multi-tenant as a service solution utilizing Amazon Web Services.

Segregation of Traffic Between Customers

Customer data (and virtual environments) are completely segregated in our private RapidIdentity Cloud deployments through containerized encryption standards. Additionally, RapidIdentity databases reside on Relational Database Service instances, connected directly to their specific customer tenant. As such, each customer environment is separated from others. Additionally, Identity Automation provides a RapidIdentity Bridge service with the RapidIdentity tenant that provides a highly available endpoint for customers on-premises resources to communicate with securely. RapidIdentity Bridge replaces the need for a VPN between Cloud and On-Premise resources.
The only external (outbound) access required for RapidIdentity Bridge to function securely is port 443 from the on-premises endpoint to the RapidIdentity Cloud. The only external facing components of RapidIdentity Cloud, beyond the Bridge endpoint, are the public-facing web services for RapidIdentity Portal and RapidIdentity Federation. These allow third-party SAML integrations and off-site user access to the Portal.

Encryption for Privacy Protection

Data transmission (end user-to-appliance, appliance-to-appliance, or appliance-to-remote systems) encryption is dependent upon the systems in use. The web interfaces to the appliances are secured via HTTPS (SSL) encryption, and the majority of traffic passed between any of the appliances (integrated cross-appliance functionality) occurs over the HTTPS as well. Other data transmission encryption (for instance, between RapidIdentity Connect and connected systems) is dependent upon the security allowed and provided by those systems. RapidIdentity supports the following security protocols: FTPS, SSH, LDAPS, and HTTPS.

Prevention of Tampering by Cloud Service Providers

Amazon maintains the ability to shut down or deny access to services should they find evidence of a security issue (they've been known to lock down ACLs and/or disable hosts). If they find a security misconfiguration that causes problems; for example, if a host on their networks is participating in a Distributed Denial of Service (DDoS) attack, all access on the appliances is restricted to the VPC and any allowed Security group permissions -- all while authentication to the appliances (local SSH for Linux or obtaining the Administrator password for Windows) requires Private keys.

SLA Contract and Uptime for RapidIdentity Cloud

In partnership with AWS, RapidIdentity adheres to a 99.9% uptime standard. The RapidIdentity Cloud product design and hosting options allow us to provide that standard, and we support high availability through the use of elastic computing, elastic load balancing, and other mechanisms within the AWS product offering. The terms and conditions for defining SLAs are customer-specific and subject to contractual agreement.
For more information about AWS's SLAs, please visit https://aws.amazon.com/ec2/sla/.

Third Party Attestations, Security Certifications (SOC 1/SSAE-16, SOC2, ISO), Reference Architecture

RapidIdentity holds numerous certifications around data privacy that can be viewed in the Identity Automation trust center. Requests for reports and RapidIdentity reference architecture can be submitted from the Trust Center. Visit https://www.identityautomation.com/trust-center.

8. Data Storage and Transfer

Aside from any audit data and job logs, the vast majority of data is stored only on the remote systems for which it is intended. Audit logs are stored in a secured database, and job logs are stored in a compressed format in RapidIdentity Connect (or configured remote filestore if clustered, etc.), and are accessible via system interface only to users who are granted RapidIdentity Connect Administrator role(s). If stored on a remote file system, access permissions on that file system apply (e.g., stored on SMB share, Windows file system permissions apply to users of that storage server).

9. Security Controls of SDLC

1. Documentation of Encryption Strategy:
   RapidIdentity uses the RSA algorithm to encrypt passwords when necessary. TLS 256-bit AES encryption is also used for storing sensitive items in the configuration database.

2. Describe controls used to prevent cross-site scripting, SQL injection, etc.
   RapidIdentity uses the Hibernate platform for database access, which has built-in SQL injection prevention, meaning we never construct SQL statements with string concatenation. ESAPI for XSS is used for additional protection: escaping values used in javascript.

10. Customer Testing of the UI Using Non-Destructive Techniques for Vulnerabilities

1. Access to Administrator Console as a Privileged User
   For RapidIdentity Cloud, the customer is NOT permitted, in any way, to perform vulnerability scanning or penetration testign against our appliances. These activities are specifically restricted by AWS, and require us to schedule specifi timeframes and get express permission in order to even test our own appliances, as well as imposing limitations to prevent impact to the overall environment. Therefore, we do not allow customers to perform these activities against Cloud tenants.

2. Load Tests
   Load tests are discouraged against production environments, as they may cause an impact to the operation of the tenant or integrated systems.

3. Reporting Security Vulnerabilities
   Vulnerability reporting should be done via contact with the Support team at Identity Automation (support@idauto.net or 281-220-0021, option 4) who will engage the Information Security Team as necessary for analysis and review.