Get a copy of our Security Statement here.

DATA CENTER AND NETWORK SECURITY

Physical Security

Contrast's security application services and data are currently hosted on servers in Amazon Web Services (AWS) facilities in the United States, Europe, UK and Japan. AWS is routinely audited and believes in transparent security. A few of AWS’s Assurance Programs are as follows: FedRAMP, ISO 27001, FIPS, SOC2/Type 2, FERPA, and HIPAA. Contrast also monitors AWS’s compliance posture with respect to the GDPR, the CPRA and other key Privacy regulations as referenced on their website:

 A full list of AWS certifications is available here: http://aws.amazon.com/compliance/.

Amazon Web Services has published the Shared Responsibility Model where they describe the division of responsibilities between AWS and the Customer. In general, AWS is responsible for security of the cloud and the Customer is responsible for security in the cloud.  No Contrast employees have physical access to AWS Data Centers.

DATA BACK UPS

We perform multiple database backups each day. These backups are stored in geographically distributed object storage AWS Simple Storage Service (S3) buckets for 7 days; they are only accessible by automated processes and a limited number of employees who require access to support critical business functions. All access is role based and follows the principle of least privilege. Data is encrypted in transit and at rest. Data in transit is TLS 1.2. Data at rest is AWS KMS with AES 256 GCM. Backup integrity is automatically tested daily, and backup data is retained for 7 days.

OPERATING SYSTEM, NETWORK AND FIREWALL CONFIGURATION

Operating Systems are hardened using Center for Internet Security standards and other industry best practices depending on the host's role.  Operating systems are hardened based on the Amazon Machine Images (AMI provided by the Center for Internet Security (CIS)). In addition to standards and software from CIS, additional industry best practices are followed depending on the host's role. 
System configuration and patches occur through both scheduled and ad-hoc processes that are driven by configuration management tools.  The code is committed, tested, and peer reviewed before deployment. 

Security patch management is an automated task for all images. Should a security patch be needed outside this process, we can apply patches in bulk to all images.  If an urgent patch needs to be applied outside the regular schedule, we first verify that our infrastructure is vulnerable and then apply the patch.    

We observe communications from cert.org, us-cert.gov, and our own software processes to alert us of vulnerabilities that should be patched.

Our network is engineered and designed to limit access by origin and port between hosts and services (AWS Security Groups). Where possible, separate private networks (AWS VPCs) are created and are completely separate from other networks. All network and firewall rules are checked into our source code repository and reviewed by staff via Pull Requests and only deployed once tested and reviewed. The network is designed with limited public facing systems. 
In addition to our own product, we deploy several monitoring solutions to measure the health of our service:

PRODUCT SECURITY

Minimal Data Collection

Contrast Security only collects the data necessary to provide the analysis and metrics we offer. Our agents minimize the amount of data collected by reporting only confirmed vulnerabilities to the Contrast Team Server. Scan Local Engine behaves in a similar manner. Importantly, your source code and binaries never leave your servers when you use Contrast Assess, Protect, Scan (using Scan Local Engine) or SCA. Contrast collects the following types of data:

• Vulnerability and attack data that includes HTTP request data and a series of method invocations.
• Summary information about what libraries and classes are required and loaded by each application.
• Sitemap information, including URLs but not parameters.
• Software architecture information about back-end components and connection.
• Site usage analytics (opt-out).
• Site usage metrics (opt-out).
• Source code and binaries (when using the Contrast Scan product in SaaS and CodeSec).
• Stack traces.
• IAM permission information (when using the Contrast Serverless product).
• Audit and debug logs.
   

Confidential information could also be present in attack tracing and/or if a support ticket is opened and the customer inadvertently includes confidential information. In this instance, Contrast support would redact the information and advise the customer.
 
All Contrast employees are required to acknowledge and sign off on the Privileged User Agreement and Acknowledgement of Responsibilities Policy (predicated on NIST’s Rules of Behavior).

Encryption

Our primary defenses keep out attackers and control access, but we also use strong encryption to ensure that all of the data we store is inaccessible to attackers. All Contrast data is stored on encrypted volumes or object storage. We extend the use of encryption to backups, logs, and any other data associated with the Contrast service.

We utilize Amazon's Key Management Service to generate and rotate keys used across our services.  Amazon’s overall key management infrastructure uses Federal Information Processing Standards (FIPS) 140-2 approved cryptographic algorithms and is consistent with the NIST 800-57 recommendations.

Contrast uses strong encryption and mutual authentication on all connections. This protects against sniffing, spoofing, and other communications attacks. The connection from the Contrast Agents’ to the Contrast backend uses an SSL socket connection that can be configured to use an outbound proxy. The Contrast Agents verify the Contrast TeamServer certificate and send the client authorization key to the TeamServer to establish mutual authentication. Back-end connections are also both encrypted and mutually authenticated.  Any attempt to access our service over a non-SSL connection is redirected to use https.

We leverage the following AWS services related to encryption:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html

https://aws.amazon.com/kms/

https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingEncryption.html

https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html

https://aws.amazon.com/certificate-manager/

Permissions

We enable administrator, manager, or individual contributor permission levels within the app to be set for your individual users. Permission levels determine the user’s ability to change settings, view information, and edit, delete, or export data. These are configurable by Customer.

Authentication

We believe that everything that happens within Contrast should be fully authenticated and traceable to a particular individual and we prohibit the use of shared logins. We do not charge or limit the number of users within an organization. We check password strength and failed login lockouts to ensure that Contrast is not susceptible to brute force attacks. We allow organizations and users to configure our Two Step Verification process that leverages time-based one-time passwords ("TOTP"). We also provide organizations the ability to utilize their own Single-Sign-On (SSO) mechanism for authentication.

Access Control

Role based access is built into the Contrast Platform, and you can limit/ grant users the privilege to administer your organization or only make API calls.

All of the security defenses in the Contrast Platform are centralized into a security API based on the widely used OWASP Enterprise Security API (ESAPI) that we designed and contributed to the open source community through OWASP. Contrast data is accessible by a limited number of Contrast Employees who administer the Contrast Service. All employees have background checks and are under strict confidentiality agreements.

All Contrast Security product application logins are written to an audit log. The logs are ingested into SumoLogic for analysis and automated alerts when privileged escalation occurs. These logs expire in 30 days from the SumoLogic system but are kept by Contrast (AWS S3) for 2 years.

Secure Coding 

Contrast was designed from the ground up to be resilient against injection attacks like SQL injection, cross-site scripting (XSS), LDAP injection, XML entity attacks, command injection, and other risks. Our software architecture requires strict input validation on all input before it can be used. Where possible, We minimize the use of interpreters and use parameterized interfaces, if available.

Contrast Software Engineers are required to undergo annual secure code training.

Contrast identifies, tracks, and remediates known security vulnerabilities during the Software Development Life Cycle.  All code commits and pull requests require a minimum of 2 approvers, of which the application security team is a part.

The Contrast agent runs in both automated testing and manual verification environments, we perform ad-hoc threat modeling of newly proposed software/functionality and also when significant changes occur to existing functionality. Additionally we verify that our 3rd party libraries are not exposed to vulnerabilities on a continuous basis. This helps determine vulnerabilities early in the life cycle and ensures robust controls to protect our customer data and environment.

Secure Design Reviews (SDRs)

Security Design Reviews (SDRs) provide a structured and comprehensive approach to understanding the security in an application architecture and help to identify any potential security risks. The SDR process is designed to help facilitate the identification of application risk in a timely and cost-efficient manner. Our process can be applied to various architectures and development groups without introducing significant overhead that accompanies many other methodologies. Analysis of the existing or proposed application architectures allows us to quickly identify threat agents and organizational impacts of attacks against key infrastructure services.

Threat modeling

Threat modeling is a process utilized by our security team wherein we discuss and document potential threats, threat actors, vulnerabilities, controls or the absence of controls. The security team uses the results of a threat model to help identify potential sensitive or higher-risk areas to focus on in future assessments and also helps with prioritization of any future mitigations. Through a practical threat-modeling process, the analysis allows for the identification and prioritization of architectural risks and the associated mitigation strategies. We assess the architectures and systems for a broad range of common application vulnerabilities, including those detailed in the OWASP Top Ten Most Critical Web Application Vulnerabilities and the SANS Top 25. Best judgment is used to determine where serious security vulnerabilities are most likely to be uncovered.

Third-party network and cloud security assessment

We engage with a third party to perform an external network and cloud security assessment on a quarterly basis. The third party assesses the security posture of our external-facing network presence and cloud security controls. The purpose of the external network assessment is to discover, validate and document security-related issues in Contrast Security’s public infrastructure. The environment is assessed for various security issues including insecure open services, insecure settings, outdated software, known CVEs, security misconfiguration, unpatched software and other security-related issues. Additionally, Domain Name System (DNS) brute-forcing and open-source intelligence gathering are performed on the Contrast Security external presence. The assessment is performed using automated and manual techniques to fully discover and validate security vulnerabilities. The assessment is performed against IP addresses gathered from our production and staging AWS accounts. The purpose of the AWS assessment is to discover, validate and document security-related issues in the Contrast Security cloud environment. The environment is assessed for various security issues including security misconfiguration, lack of encryption and other security issues with the many cloud services in use.

Third-party AppSec assessment

The goal of performing a third-party AppSec assessment is to provide a neutral party review of the most common AppSec vulnerabilities in our externally facing web application. Specifically, this annual assessment focuses on the OWASP Top Ten and CWE/SANS Top 25 vulnerabilities and control families. Contrast works with the third party to outline the areas of most concern, which are identified during a kickoff meeting. Once a prioritized list has been formulated, the third party will begin with the most important areas and continue testing until all of the areas have been covered or the allotted time has expired. 

Continuous AppSec Assessment

Contrast’s application vulnerability detection is active in nature and reports any vulnerabilities on a real-time basis. Contrast’s CISO, VP of Operational Risk and Director of Product Security review the report quarterly. This report is not disseminated externally except in summary and after approval from Contrast’s CISO or Director of Product Security if any high or critical vulnerabilities are found. Once the vulnerabilities have been remediated, the report is rerun and reviewed by Contrast’s CISO and/or Director of Product Security to confirm previous vulnerabilities have been successfully remediated.

SCA

Contrast’s SCA is active in nature and reports any detected libraries and any associated CVEs on a real-time basis. We then verify that our third-party libraries are not exposed or exploitable to any detected vulnerabilities on a continuous basis. Our build processes also utilize open-source security technologies such as scanning tools and automated dependency update tools.

Network Assessment

On a quarterly basis, our internal security team executes an external network security assessment. The purpose of the external network security assessment is to discover, validate and document security-related issues in Contrast Security’s public-facing infrastructure. The environment is assessed for various security issues including insecure open services, insecure settings, outdated software, known CVEs, security misconfiguration, unpatched software, and other security-related issues. The assessment is performed using Tenable.io as an automated scan to discover and validate security vulnerabilities. The assessment is performed against IP addresses gathered from our production and staging AWS accounts.

Container Image Scanning

Container image scanning is the process of checking a base container image for known CVEs. The process is defined by taking a container image from the container registry and then running a scanner to determine the number of vulnerabilities and their associated risks.

Firewall Assessments

The cloud security team performs quarterly reviews of the AWS firewalls, specifically reviewing all security groups created in the past quarter, all security groups currently in use and if there are any open security groups. These reviews are documented by quarter.

Bug bounty program

The Contrast Security team utilizes Bugcrowd’s bug bounty platform to invite external security researchers to find security vulnerabilities in our Contrast platform and associated agents. The researchers have their own instance of the Contrast Platform, and they report the security vulnerabilities to the Bugcrowd system. Once triaged and validated by Bugcrowd, our internal security team follows our internal vulnerability management process with the reported vulnerabilities. See our vulnerability disclosure policy for more information.

Monitoring

Contrast restricts access to Our production environment on a need-to-know basis and maintains a comprehensive logging system to track access and events. Contrast closely monitors potential attacks both at a network and application security level with automated alerting to internal chat and paging systems.

Get a copy of our Security Statement here.