Clarity SaaS Service Description
ClaritySaaS Service Description
This service description applies to all active releases of
ClaritySaaS is a web-based service that provides subscribers with access to the market-leading project and portfolio management system.
Service Delivery Standards
The components of
ClaritySaaS are compliant with various standards as follows:
- SSAE 18 compliant:ClaritySaaS is subject to an annual SSAE 18 compliance audit. The resulting Service Organization Controls (SOC) Report includes the auditor's opinion on the fairness of the presentation of the Broadcom description of controls that have been placed in operation and the suitability of the design of the controls to achieve the specified control objectives and the auditor's opinion on whether the specific controls were operating effectively during the period under review. To view Broadcom SaaS Audits and Compliance Reports, see Compliance Audit Reports. Statement on Standards for Attestation Engagements (SSAE) No. 18, Reporting on Controls at a Service Organization, was finalized by the Auditing Standards Board of the American Institute of Certified Public Accountants (AICPA) in May 2017. SSAE 18 effectively replaces SSAE 16 as the authoritative guidance for reporting on service organizations.
- Section 508: The nature and extent to whichClarityapplication enables compliance with the requirements of Section 508 of the Rehabilitation Act of 1973 are detailed in our Voluntary Product Accessibility Template, available at the end of the Clarity Accessibility section on Broadcom documentation site.
Availability and Monitoring:
- Continuous monitoring of all service components (infrastructure and application) is deployed to proactively identify any component or service trending towards failure or approaching capacity.
- Best-of-breed monitoring solutions are deployed.
- Supplemented with vendor-specific diagnostic tools where appropriate.
- 24x7 staffed network operation centre (NOC) to analyze and respond to automated monitoring alerts.
Service response times are analyzed and archived daily. This data is used to identify clients that require detailed performance reviews.
Upon review of performance data or notification from the client of performance concerns, Broadcom will:
- Work with the client and perform a detailed user by user, feature by feature review to determine any areas of concern.
- Work with the client to optimize their configuration.
- Work with the client to identify any issues within their network or ISP.
- Should additional infrastructure be required to meet the customer's subscription levels, Broadcom will provide as part of the service.
ClaritySaaS includes standard 24x7x365 support for critical incidents. The welcome email sent to current
ClaritySaaS customers providing service URLs contains information on how to obtain a Broadcom Support login. This login can be used to obtain support for any issues or service related questions. The following web sites provide access to detailed information on Clarity
- Support Knowledge Base: Links to user documentation, support policies, and a knowledge base of documents related to the service.
- Documentation: Access to the product documentation.
- SaaS Resource Center: Links to current SaaS specific policies and SaaS listings providing current delivery standards for Broadcom SaaS offerings.
- Communities Site: Post questions, share ideas and information regarding upgrades on Clarity SaaS, in general.
Maintenance falls into three categories:
- Monthly: Our monthly production maintenance calendar is published at least 30 days or more in advance and the maintenance windows normally occur the second Saturday of each month. Production maintenance windows are scheduled during local, data centre non-business hours. Service interruptions and/or performance degradation may be noted during these windows and accordingly all jobs and interfaces should be paused and no critical activities planned during these windows. There is limited client input over these scheduled windows as the infrastructure and operating system level maintenance that is performed during these periods may impact multiple or all clients. A reminder notification will be sent 7-10 days prior to these maintenance windows.
- Emergency or Critical Scheduled: Periodically, an emergency or critical scheduled maintenance involving security or system stability may be required. Minimum 72-hour notice for expected downtime will be provided to customers for these activities. Broadcom will provide reasonable accommodations for business needs for these types of maintenance periods where possible.
- Unplanned: Unplanned: Unplanned downtime is any loss of production system availability that is not noticed more than 72 hours in advance and initiated by Broadcom. These downtimes are generally system fault type issues but can also be proactive emergency maintenance performed to prevent a system failure from occurring. Notices will be sent as soon as the maintenance is scheduled or Broadcom’s monitoring process has determined a client’s system is unavailable. These types of downtime count against the client’s uptime SLA and, therefore, are infrequent.
Broadcom SaaS implements a defence-in-depth approach to the security of our environments which mitigates the impact of any one vulnerability. We leverage strong authentication, privileged access management, vulnerability and patch management, segmentation, and security monitoring to prevent or detect any malicious activity.
Broadcom SaaS continuously improves the security framework by doing the following:
- Risk management drives policy creation
- Policy shapes architecture
- Architecture drives engineering solutions
- Solutions are sustained by operations and administration.
- Operations and administration efforts are monitored for performance and compliance (depending on risk)
- Performance/compliance test results drive policy improvements
- Auditing:ClaritySaaS security architecture is comprised of controls and security measures across the facility, network, and server infrastructure which are audited annually under SSAE18 standards. Refer to the previous Certification and Compliance section for further SSAE18 details.
- Encryption: All web traffic is protected by SHA256 bit TLS 1.0, 1.1, or 1.2 encryption and 2048 bit RSA public keys. TheClaritySaaS application encrypts user session data.ClaritySaaS email services support opportunistic TLS encryption.
- Load Balancers: All internet traffic is terminated at a load balancer.
- Software: A suite of security software components are deployed including threat management, SIEM, IDS, and anti-virus to provide server security.
- Firewalls: In addition, “stateful” inspection firewalls are in place; these firewalls deny by default all incoming traffic, analyze it, and prevent standard internet attacks. Application servers are located in a demilitarized zone (DMZ), which is separated from the service database servers by a firewall. Only the necessary ports are opened between the DMZ and the internal trusted network.
- SQL Injections and XSS: The application manages illegal SQL injections by enforcing content-validation rules and Web use prepared statements exclusive to the application itself almost exclusively in Clarity application. Clarity also enforces XSS user input validation and XSS user input restrictions.
Broadcom contracts with an independent, third-party vendor to evaluate and validate the security of our service on an ongoing basis. Critical and high risks are identified, validated, and remediated before production systems are made available. Medium risks are evaluated and resolved on a priority basis. Ongoing scans are performed to ensure that no new risks have been introduced. Two types of scans are performed:
- Vulnerability Scans: Vulnerability tests are performed weekly in the production system. Patches and updates are scanned prior to deployment to production
- Penetration Scans: Penetration tests are performed upon significant service updates but no less than annually.
Application Security and User Management
- Data integrity: ClarityClaritySaaS customers are deployed in a stateless application environment. With failover at the application tier, the application data model is designed to guarantee data integrity by modelling data transactions into transaction units that are saved (committed) to the database in one batch. In the event a database instance goes offline, the pending transactions resume once the database is restored.
- Data segregation: Customer data is segregated in separate databases schemas that may reside on the same physical database server. All customer configurations and customer data are stored in the database.
- Authentication: Customer may utilize the standard Multi-Factor Authentication (MFA) utilizing a username, password, and a selected factor (email, SMS, soft token, or push to a smart device. Optionally a federated single sign-on (FedSSO) authentication is available for customers with the capability of producing SAML authentication packages; refer to the Integration section for more details. Federated SSO allows for greater customer control for authentication rules.
- Authorization: Within the Clarity SaaS application, individual rights/roles/groups can be used to secure application functionality and data records. Additionally, standard audit trail functionality can be configured for most objects and attributes to capture creation, edits, and deletions of selected data records or attributes.
ClaritySaaS service uses a session-based cookie that carries a token for accessing the session data that is transient in the cache (for a single application environment), or in the database (for a clustered environment). The only data that is kept in the cookie is the authentication token, which is a value in the database. Session data that is keyed off the cookie includes the user’s profile (username, language choice, locale choice, and time zone), global access rights of the user, and other shopping cart-like data.
Data Center Security
Broadcom contracts with world-class data centres that provide multiple levels of security to protect customer information. This protection includes physical and logical security measures.
All data centres have highly restricted access and use the following physical security measures:
- Systems and Monitoring: Secure perimeter defence systems, comprehensive camera coverage, biometric authentication, and a 24/7 guard staff is utilized to ensure a secure environment.
- Access: No public visitor access is permitted. Data centres enforce strict access and security policy and ensure the staff is fully trained. All-access is logged for audit purposes and retained for no less than one year.
- Testing: Security teams run year-round testing to ensure that teams are always prepared to respond to any situation.
- Risk Management: A robust enterprise risk management program is in place to proactively assess and mitigate any risks to the data centres.
The following security methods are employed:
- Hacker Monitoring: Systems are monitored 24x7x365 by an enterprise network intrusion detection solution (IDS). Audit logs are sent to a centralized log system and are continually reviewed to ensure that there is no unusual activity by a SIEM solution.
- Virus Protection: All Broadcom SaaS servers are protected by commercial Anti-Virus/Anti-Malware software. The environment undergoes regular vulnerability scans to protect against both internal and external network threats. Files being uploaded to the service are scanned for threats before being saved. Signatures are updated hourly.
- Ports: Only specific ports are opened for data traffic. Application data, including interface data, is directed through port 443.
- Application Security: During the development, QA, and deployment stages, the application undergoes security review and testing.
- Server Hardening: All servers are hardened in accordance with industry best practices. By running only the necessary services, Broadcom reduces its exposure to operating-system-level security issues. Servers undergo weekly vulnerabilities scans and standard quarterly maintenance.
- Server Patching: Security patches are applied monthly and critical patches are applied within 72 hours.
- Segregated Customer Data: Data is currently segregated within dedicated schema instance and security is enforced at the database level so that no cross schema access is available. Customers do not have logical access to database servers.
- Protection Controls: Unauthorized access to servers and changes to the operating system are monitored.
- Data Sanitization: Data storage and processing devices are sanitized or securely destroyed per DoD standards when the hardware is retired or otherwise removed from the data centre. Customer data is only stored on-network data storage, so there is no process necessary for removable media (for example, tape, USB, CD, DVD.
Broadcom SaaS performs daily backups of all customer data and configurations to create service recovery points. These recovery points can be utilized, along with additional client requested recovery points, to restore the service to a previous state upon client request.
Service Backup and Restore
Service backups are managed as follows:
- Recurring backups: A recovery point is automatically generated every 24 hours and consists of a full backup of all customer data and configuration.
- Retention period: Recurring backups are retained for 7 days. Backups past the retention period are programmatically deleted.
- Storage policies:
- Backups reside only on network storage within an authorized Broadcom data centre
- Removable media is not used to store backup files
- Backup copies cannot be provided to customers or other third parties
- Customer defined recovery points: Customers may define additional recovery points as needed. Customer defined recovery points can be retained for as long as required; the standard retention periods for these recovery points, in days, are 30, 60, or 90. Broadcom will maintain up to 5 customers defined recovery points in addition to the recurring backups defined above.
- Customer restore requests: Customers may request a restore to any recovery point within the retention period or any available customer-defined recovery point. All restore requests are processed as a complete environmental restore; restores of selective data instances cannot be requested as part of the standard service. When a customer requests a recovery, the restored system will be unavailable for a predetermined amount of time, which will be communicated to the customer.
SFTP Data Storage and Retention
SFTP folders are supported to temporarily store XML files or other flat file formats when exchanging data into and out of the service. Files stored in SFTP folders are not covered under the service backup and disaster recovery policies, therefore, only derived data that can be recreated should be stored in these folders. Clients are responsible for archiving files once they have been processed and deleting them.
Broadcom may delete any file that is stored in an SFTP folder and is older than 30 days or to reduce the amount of storage utilized to conform to the limit specified in the Service Listing.
Disaster Recovery and Business Continuity
In a force majeure event that results in a disaster being declared by Broadcom, Broadcom SaaS will recover the service to a cold standby, alternate data centre with a replicated copy of production data and configuration. See the regional SaaS listing for Recovery Point and Recovery Time Objectives.
For most hardware or software failure recovery scenarios, minimal or no customer action is required. Because of high availability and redundancy, there should be zero loss of data in these scenarios, but in rare cases, data may be lost up to the last available recovery point. Broadcom SaaS uses all commercially reasonable efforts to recover from any system failure.
Data Delivery at Termination
As noted above, ongoing client data retrieval is provided for via a web-based user interface (including reports and dashboards) or WSDL based API’s. Terminating clients have the following options to receive their data:
• API data extractions via HTTPS producing XML formatted flat files. See the user guide XOG Developer Guide for technical details.
• Database dump file containing only tables with client data.
• Database data pump generated file of the client’s entire
Claritydatabase schema. This option requires a valid, perpetual
ClaritySaaS is based on a J2EE application and has the following architectural details:
- To ensure high-performance and availability, the application runs on multiple Apache Tomcat application servers connecting to back-end databases.
- The application utilizes load balancing between a minimum of two Linux application containers using hardware-based SSL acceleration.
- The underlying J2EE application server controls web, integration, business logic and persistence services providing common application functions such as caching, security, globalization, configuration, and workflow.
- The service is accessed through a secure web interface.
- Customers are deployed in a stateless application. With failover at the application tier, the data model is designed to guarantee data integrity. Data transactions are modelled into transaction units that are saved (or committed) to the database in one batch. In the event a database instance goes offline, the pending transactions resume once the database is restored.
- The application limits the number of network resources consumed by compressing the data sent to the browser from the server using Java compression functionality. The browser can then uncompress the data stream using built-in gzip functionality.
Data Integrity and Management
Data between the client and database may be interrupted when an application server fails and the session is lost. Transactions complete if they are submitted before the application server goes down. If the database goes offline, the transactions complete once the database is restarted. The
ClaritySaaS application data model was designed to guarantee data integrity by modelling data transactions into transaction units that are saved (committed) to the database in one batch. All jobs and tasks that were cut off during the failure resume once the servers are activated.
User access to
ClaritySaaS requires only a supported web browser as noted in the current release notes. Depending on processing requirements, there are additional client workstation technologies that customers can use:
- XML Open Gateway (XOG): AClarityWeb service used for data import and export between external systems andClaritySaaS via HTTPS. Direct WSDL calls may also be initiated to service using a client developed SOAP call.
- REST APIs: Web-based and interactive API documentation to execute API commands against aClarityinstance.
- Microsoft Project/Open Workbench: These scheduling tools allow for a two-way interface of project plan data that is created or edited offline and subsequently uploaded toClaritySaaS.
Direct access to Broadcom SaaS environment servers using a VPN, remote desktop, or any other connection method is not permitted.
New service versions, including new functionality, are released one to two times per year. Patch versions of the service are released approximately monthly or as needed for the remediation of identified defects and vulnerabilities. Scheduled dates for new service versions and patches are published well in advance to provide clients adequate time to plan.
Technical upgrades to Clarity SaaS are included as part of the base subscription. For details of the upgrade process, see Clarity SaaS Upgrade Guide.
- Service Versions:All Clarity SaaS subscribers are required to be running the current version of the service. Before the published release date, clients will receive notification of their assigned upgrade dates giving them at least 30 days notice for their production upgrade. Critical, blocking issues discovered during non-production upgrade testing will be triaged via the support process to provide a patch prior to upgrading the production instance. New versions may include new or altered functionality which may require clients utilizing that functionality to execute their change management process. Clients are responsible for testing their business processes prior to each of their assigned production upgrade dates.
- Patches:Patches: are applied, as required, to resolve identified issues. Clients that have reported issues that a patch resolves will be scheduled to receive the patch. In the case of a critical security or stability issue, patches may be required for all clients. The same notification and issue resolution policies for version upgrades apply to patch application.
The Broadcom approach to integration is through the supply of an integration toolkit that enables field integrations to be performed easily. This toolkit consists of the RESTful APIs, XOG XML Web Services interface and GEL Scripting capabilities of the process management functionality. Clients may build integrations themselves, engage Broadcom Service partners to build integrations for them, or deploy any of the standard integrations described in the user guides; the work to build, deploy, or configure integrations is not part of the
ClaritySaaS subscription. The following are the different integration methodologies provided:
- Simple Object Access Protocol (SOAP) and WSDL
- XML Open Gateway (XOG) client
- REST APIs
- SFTP drop-off/pickup combined with GEL (Generic Execution Language) enabled processes
- SAML 2.0 Federated single sign-on (user authentication)
Note: The option to utilize SFTP is intended to support legacy integrations where the use of a direct integration method such as WSDL via HTTPS is not possible. Where possible, direct integration is the preferred method.
Broadcom SaaS solutions are delivered as a standardized service. This standardization allows Broadcom to deliver high-quality services in a repeatable and cost-effective manner. To achieve this standardization, certain design principles are enforced to limit customization that may cause instabilities in the delivery of the service. Allowing only supported configurations ensures the security, stability, and maintainability of the service for all clients.
Customization of the
Clarityapplication layer or alterations/insertions of any files on the application servers is not compatible with
Clarityleverages a uniform code base and, therefore, cannot support application customization. Customization under this policy includes, but is not limited to, the following:
- Custom Java code
- Alterations to the baseClaritycode set including XSL and JAVA files
- Placement of a parameter or any other file into the directory structure of a server.
Customization of the
Claritydatabase schema is not permitted. However,
ClaritySaaS solution allows and supports all configurations done through
ClarityStudio. Prohibited customizations under this policy include, but are not limited to the following:
- Stored procedures
- Custom tables or schemas