Security Overview

PurposeThe purpose of this document is to describe the built-in security controls in the tibbr system.With these security controls and processes at TIBCO, our users can rest assured that tibbrwill adhere to their organization’s security, privacy, governance and compliance standards.Our customers, many in highly regulated industries such as government, finance and healthcare,depend on TIBCO technology to keep their information secure every day.

tibbr features a comprehensive set of built-in security controls and mechanisms to secureprivate social networks and preserve the integrity and confidentiality of user data.

ScopeThe security principals outlined within this document are relevant for both our Software asa Service and on-premise based tibbr offering.

Intended AudienceThis document is for all TIBCO tibbr employees and consultants involved with tibbr development, support and operations.

Development ProcessesThroughout the software development lifecycle of tibbr, application security is considered anextremely high priority and thus continuously tested and improved. Below is a summary of the security checks that are performed:

a. Source code reviews - The tibbr engineering team audits all new features for potentialsecurity issues throughout the development phase. Existing features are audited for security vulnerability regressions.

b. Automated penetration testing - each release of the tibbr platform is tested with IBM’sstate-of-the-art security product. IBM Rational AppScan verifies against web vulnerabilities like Cross-Site-Scripting, SQL Injection etc. In all, roughly 40 different web-based security vulnerabilities are verified.

c. Vulnerability management - TIBCO Software operates its own documented releaseprocedure to manage vulnerabilities, which includes a timeline for fixing issues, communicat-ing them to customers, and providing patches.

d. Third-party audits - Third party components used by tibbr are researched and tracked over time for vulnerabilities.

1

Deployment Options

The tibbr platform has been designed in order to be deployed in a variety of ways. This flexibilityof choice gives organizations the freedom to choose a model that best meets their requirements. The deployment options that are available are listed here with further details:

Deployment Model Description

Software as a Service (SaaS) With this option TIBCO will provision and maintain a secure and scalable instance of tibbr in our Amazon based public cloud hosting environment.

This deployment model has become considerably more common with organizations of all sizes and industries due to the benefits of reduced administrative overhead, removal of the need for hardware provisioning and maintenance, and the increase in awareness of the capabilities of cloud technologies.

On Premise With this option tibbr can be deployed within an organization’s own datacenter and behind their firewall.

On premise deployments are typically chosen by organizations requiring their data and communications to be maintained within their own control at all times and within their own IT infrastructure. Due to the nature of this method of deployment, there are usually less security requirements that need to be reviewed before roll out.

This deployment model requires the following IT environmental components. • Standard Linux Server(s) • Enterprise Database and Email server

2

Software as a Service (SaaS)

The tibbr SaaS deployment option is the simplest from a tibbr platform provisioning standpoint.After a few configuration options are selected, the TIBCO hosting operations team will provision your private and secure tibbr instance without the need for any of your organizations employeesto be involved.

The tibbr SaaS deployment is hosted on the Amazon AWS platform. Amazon allows for dataand services to be hosted in a variety of different regions.

• US East (Virginia) • US West (Oregon) • US West (Northern California) • EU (Ireland) • Asia Pacific (Singapore) • Asia Pacific (Tokyo) • Asia Pacific (Sydney) • South America (Sao Palo, Brazil)

AWS is compliant with various certifications and third-party attestations. These include:

• SAS70 Type II. This report includes detailed controls AWS operates along with an independent auditor opinion about the effective operation of those controls. • PCI DSS Level 1. AWS has been independently validated to comply with the PCI Data Security Standard as a shared host service provider. • ISO 27001. AWS has achieved ISO 27001 certification of the Information Security Management System (ISMS) covering infrastructure, data centers, and services.

3

U.S. East Region(N. VA)

AvailabilityZone A

AvailabilityZone B

AvailabilityZone C

EU Region(IRE)

AvailabilityZone A

AvailabilityZone B

U.S. West Region(N. CAL)

AvailabilityZone A

AvailabilityZone B

APAC Region(SINGAPORE)

AvailabilityZone A

AvailabilityZone B

APAC Region(TOKYO)

AvailabilityZone A

AvailabilityZone B

AWS Physical SecurityAmazon has many years of experience in designing, constructing, and operating large-scaledatacenters. This experience has been applied to the AWS platform and infrastructure. AWSdatacenters are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access datacenter floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.

AWS only provides datacenter access and information to employees and contractors who have a legitimate business need for such privileges. When an employee no longer has a business need for these privileges, his or her access is immediately revoked, even if they continue to be an employee of Amazon or Amazon Web Services. All physical access to datacenters by AWS employees is logged and audited routinely.

AWS Storage Device Decommissioning When a storage device has reached the end of its useful life, AWS procedures include a decom-missioning process that is designed to prevent customer data from being exposed to unauthorized individuals. AWS uses the techniques detailed in DoD 5220.22-M (“National Industrial Security Program Operating Manual “) or NIST 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process. If a hardware device is unable to be decommissioned using these procedures, the device will be degaussed or physically destroyed in accordance with industry-standard practices.

Data PrivacyAll data is securely physically separated via single-instance deployments for each tenant, this includes the database and all other resources. This deployment model guarantees that data is not exposed to any other customer or third party.

AuthenticationAll user credentials, when using the default database authentication mechanism, are stored inthe dedicated database using a one-way hash algorithm to ensure that a user’s password is notat risk when at rest.

It is also possible to establish a secure connection to an enterprise directory server for authentica-tion; this removes the need to store any sensitive user credentials and ensures synchronization of user accounts between tibbr and your enterprise directory. As soon as an employee is no longer part of your organization’s directory they will no longer have access to the tibbr platform.

4

Data StorageData stored within tibbr leverages Amazon RDS with data encryption enabled, thus ensuring that unauthorized parties cannot view or access your data.

Connectivity to On Premise ResourcesIf the selected tibbr configuration incorporates resources behind your firewall, such as a corporate LDAP or SharePoint instance, then your organization’s IT department will be required to be involved in order to provide the appropriate access for the tibbr platform.

The following diagram illustrates the typical approach to exposing internal IT resources to aSaaS deployment of tibbr.

Figure 1 - Exposing internal resourcesIn the diagram above a proxy server deployed within the demilitarized zone (DMZ) is exposed to an external consumer, in this case the tibbr platform. The proxy server is also usually configured to restrict access based on IP filtering, thus ensuring that the tibbr platform is the only external resource with access. This approach avoids placing internal resources within the DMZ and thus exposing them to unnecessary security risk.

On PremiseThe on premise tibbr deployment option allows all components of tibbr to be run within yourorganizations IT infrastructure and behind any corresponding firewalls. The items of Data Privacy, Data Storage and connectivity to on premise resources subside as this method of deployment grants the organizations IT department complete control over how these are handled to meetcorporate requirements.

5

Componentized Architecturetibbr leverages a componentized architecture enabling horizontal scalability. Based on demand and usage, appropriate components can be scaled as required. All components communicate with one another via secure TCP(SSL) connections and best practice engineering techniques.

Figure 2 - Componentized architecture

Oracle SAP RSSServer

Salesforce Emailserver

VideoConferencing

RSS Salesforce SAP OracleOrder Mgmt

OracleExpenses Email

App Runner

tibbr core

Web

Ser

ver

(apa

che)

Chat Server(Prosody)

Search(Solr)

AnalyticsNotifications(Cassandra)

tibbr Workers

Delayed job

Profile Data

Cache(memcached)

tomcat

tibbr server

Database(MySQL/ORACLE)

LDAP(AD)

ApplePush Notification

Server

Ruby Rails Java C Obj C Lua Ruby/Java NA

Adobe Air css/html/js

HTTP(s) TCP(SSL)

Blackberry app

facebook

twitter

LinkedIn

RSS

browser

iPhoneiPadApp

Androidapp

Desktopclient

GadgetsWebparts

6

Component Description

Web Server An Apache web server used to proxy requests to the appropriate component based on the URI. The SSL certificate is also typically installed at this layer.

tibbr Core Server The tibbr server manages all the core tibbr services, including users, messages, and filtering. Within the server is an aggregation engine that offers such services as message delivery for subjects, management of people and subjects, authentication, authorization, auditing, and overall security.

The tibbr server provides a clear and secure Representational State Transfer

(REST) interface over HTTP for clients, event streams, and utilities. All content data including messages, subjects, and user information, is stored in the database by means of Java Database Connectivity (JDBC).

Cache Using a cache server to cache the user’s wall information for a specific interval, tibbr can respond quickly to client requests and reduce the database load.

Search An Apache Solr instance is used to index messages, people, subjects, etc.

Analytics An Apache Cassandra engine is used to store and manage user notifications& Notifications and access analytics.

App Runner The app runner is a daemon process that runs the event streams configured on a scheduled basis. With application data streams, you can configure and receive events into tibbr from enterprise applications that you run day to day. Each application data stream is a tibbr plug-in that integrates with a specific enterprise application.

tibbr Workers tibbr workers, a daemon process that runs in the background, performsoffline and scheduled tasks for the tibbr server. Examples of offline tasks are distribution of messages to specific user inboxes and dispatch of email notifications configured by the user.

7

Transport Level SecurityAs tibbr is a web-based application, it is possible to secure all data transmitted between endpoints using SSL 3.0/TLS. This ensures that all data exchanged between a client (mobile/desktop apps, API) and the tibbr server remains uncompromised. TLS and SSL are cryptographic protocols that encrypt the segments of network connections above the transport layer (refer to the OSI Modelfor details on the various network layers). These protocols are commonly used by web-basedapplications, email, VoIP, etc.

Before a tibbr instance can be secured with SSL/TLS a certificate, preferably one issued by atrusted Certificate Authority (CA), must be obtained. Once obtained, the Apache instance hosting tibbr can be configured to use the CA signed certificate. On a default installation of tibbr, both HTTPS and HTTP are enabled (port 443 and 80 respectively).

Note: It is possible to self-sign a certificate and leverage this certificate to enable secure communication between tibbr clients and the tibbr server, however web browsers will present warnings due to the inability to verify the authenticity of the certificate. It is common that an enterprise may have a CA and would want to use their CA to sign a tibbr SSL/TLS certificate.

Note: With transport level security, the data that is transmitted across the wire is just as secure as banking data that is transmitted over the Internet.

The tibbr mobile app leverages the same transport level security used by ecommerce/bank sites.

Figure 3 - Mobile application Trustee Certification

8

Data at Resttibbr stores a variety of data, including files, message content, user profiles, session tokens and transaction/audit logs.

Files attached to messages and profile/subject pictures are stored on the file system - typically a network attached storage device (or NFS). All other transactional data related to the operations of tibbr, including message content, subjects, people profiles, etc are stored in a RDBMS. For an on premise installation, this RDBMS can be SQL Server, Oracle or MySQL. For cloud deployments Amazon RDS is used and encryption can be enabled, thus ensuring the maximum level of security for all user-generated content.

It is important to note, regardless of the RDBMS chosen, all sensitive data is encrypted in thedatabase using AES-256 bit encryption.

EntitlementSecuring the communication layer of a tibbr installation is an extremely important part of appro-priately ensuring that your employees communications and information is kept private, however it alone is not enough. It may be that an enterprise requires more granular control, that is, control over which data should/shouldn’t be viewed by everyone within the organization.

For this reason, tibbr supports the concept of public, by approval and private subjects to ensure access of certain communications and information to only certain trusted users. Thus subjectsnot only help categorize conversations and allow users to follow relevant conversations, they also help protect sensitive conversations and documents. Subject access and privacy controls are a powerful, yet easy-to-use mechanism to control access and adjust privacy levels to fit yourenterprise environment.

• Public subjects, as the name implies, are areas of collaboration and sharing whichare discoverable and open for everyone to join and follow.

• By Approval subjects can be discovered by users in their searches or by browsing the

subject directory, however an employee cannot enter the subject until they are granted permission by the subject administrator

• Private subjects are not discoverable by any means, such as searching or browsing the subject directory, and employees would only be made aware of them—and enter them— if they are personally invited in to join. Users can be invited manually by subject adminis-trators or a subject can be synchronized with an LDAP group.

9

User Authenticationtibbr requires authentication prior to granting any user access to the platform. Authentication comes in a variety of forms, such as LDAP, SSO, SSO via SAML2 or tibbr database authentication. The default and easiest to configure is the database authentication model. However, the vast majority of enterprises leverage an LDAP server and repository for users, such as Microsoft Active Directory, and therefore utilize the LDAP Authentication method.

Database AuthenticationWith database authentication all user accounts are persisted within the tibbr database, and if a user account has not been explicitly added into the database the user will not be granted access to the tibbr instance. This is the easiest authentication model to configure. New user accounts can be scripted via a Rake task provided with the product or manually via the tibbr GUI by a user with Administrative access. All user credentials and session tokens are encrypted using AES-256 bit encryption. Refer to the following sequence diagram that shows a typical interaction.

Figure 4 - Database Authentication

Client/Browser

Intercepts and challenges

Username / password

Authenticates

Access tibbr

10

LDAP AuthenticationMost organizations leverage a directory server (LDAP) as a repository for structured data, suchas user accounts. The user accounts consist of common data elements, such as the full name, manager, address, phone number and other attributes associated with an employee.

tibbr supports the synchronizing of user accounts from LDAP, removing the need for an additional user account directory to be maintained. As tibbr has the ability to authenticate directly against an LDAP server it also ensures that only users in your corporate directory have access to the tibbr platform. The connection to the LDAP server can be both secure (encrypted) and non-secure.Refer to the following sequence diagram that shows a typical interaction.

Figure 5 - LDAP Authentication

Client/Browser

Intercepts and challenges

Username / password

Authenticates

LDAP

Access tibbr

Forwards credentials

Validates

11

SSO Authenticationtibbr supports enterprise-based SSO solutions such as NTLM authentication. This is accomplished via the use of a proxy that can interpret the authentication token within the HTTP header and validate the token/user credentials against a user directory (typically LDAP). Refer to the following sequence diagram that shows a typical interaction.

Figure 6 - SSO Authentication

SSO via SAML2Single Sign-on via SAML 2.0 provides a standards based mechanism for authenticating users across multiple applications. That is, an identity provider (which may utilize an organization’s direc-tory server to avoid user account replication) is used to authenticate a subject (user) and provide an assertion. The assertion is simply a signed package making one or more statements provided by a SAML authority. Assuming the tibbr server is confident of the assertion, the user is granted access and not required to perform yet another login.

There are two primary players in an SSO SAML2 solution – the identity provider and the service provider. The identity provider is the SAML authority and is responsible for issuing assertions (and performing the actual subject authentication), while the service provider is tibbr, the application pro-viding the desired service. For this to be successful the assertion generated by the SAML authority (the identity provider) must be signed and the service provider (tibbr) must understand and trust the identity provider’s signature.

Client/Browser

Intercepts and challenges

Credentials

Response

IIS/Apache

Access tibbr

Authenticates and forwards

Response

+ User nameRequest

12

Consider the following scenario where a user wishes to access tibbr:

a. User navigates to tibbr.b. tibbr redirects the user to the identity provider for authentication verification.c. The user already has a session with the identity provider or establishes a new identity

by providing credentials (the credentials can be validated against an LDAP server).d. The identity provider builds the authentication response in the form of an XML-document

containing the user’s email address, signs it using a X.509 certificate, and posts this information to tibbr.

e. tibbr, already having the fingerprint of the identity provider, validates the SAML assertion.The user is authenticated and granted access to tibbr.

If the session with the identity provider is maintained, the user needn’t manually login to otherresources, assuming the same identity provider is used across various resources.

When configuring SSO within tibbr, an identity provider fingerprint must be provided along with the SSO redirect URL and the email address location within the SAML assertion (this is used to identify the user who has been authenticated successfully). Refer to the following sequence diagram that shows a typical interaction.

Client/Browser

Redirects to SSO

Contacts SSO server

Redirects to tibbrwith SAML token

SAML

Access tibbr

Contacts tibbrwith SAML token

SSO Credentials

Access tibbr

Response

Figure 7 - SSO via SAML2 Authentication

13

Role Based Permissions

tibbr supports the concept of roles, in order to group specific capabilities within the platform.Subsequently the management of these permissions becomes much simpler than assigningthem directly to individual users.

Not only can users be assigned to roles, but Active Directory groups can also be assigned toroles, thus granting all users in a group the permissions defined by the associated tibbr role.

The following permissions can be granted to a tibbr role:

• User management – Create, delete and maintain users.• Subject management – Delete, move and edit subjects.• Subject creation – Create new subjects, except root-level subjects.• Root-level subject creation – The ability to create root-level subjects.• App management – Manage tibbr apps.• App creation – The ability to create new apps within the tibbr platform.• App Instance management – Management of existing apps.• Role management – Create, edit and assign users/groups to roles.• Message management – The ability to manage banned words and delete posts.• Analytics – Grants access to tibbr platform analytics. • Community Management – Create and manage tibbr communities.

14