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 secure private social networks and preserve the integrity and confidentiality of user data. For more information, please visit http://www.tibbr.com/

1. Security Overview

2. Purpose
The 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 tibbr
will 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 secure
private social networks and preserve the integrity and confidentiality of user data.
Scope
The security principals outlined within this document are relevant for both our Software as
a Service and on-premise based tibbr offering.
Intended Audience
This document is for all TIBCO tibbr employees and consultants involved with tibbr development,
support and operations.
Development Processes
Throughout the software development lifecycle of tibbr, application security is considered an
extremely 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 potential
security 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’s
state-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 release
procedure 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

3. Deployment Options
The tibbr platform has been designed in order to be deployed in a variety of ways. This flexibility
of 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

4. 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 employees
to be involved.
The tibbr SaaS deployment is hosted on the Amazon AWS platform. Amazon allows for data
and 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)
Availability
Zone A
Availability
Zone B
Availability
Zone C
EU Region
(IRE)
Availability
Zone A
Availability
Zone B
U.S. West Region
(N. CAL)
Availability
Zone A
Availability
Zone B
APAC Region
(SINGAPORE)
Availability
Zone A
Availability
Zone B
APAC Region
(TOKYO)
Availability
Zone A
Availability
Zone B

5. AWS Physical Security
Amazon has many years of experience in designing, constructing, and operating large-scale
datacenters. This experience has been applied to the AWS platform and infrastructure. AWS
datacenters 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 Privacy
All 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.
Authentication
All user credentials, when using the default database authentication mechanism, are stored in
the dedicated database using a one-way hash algorithm to ensure that a user’s password is not
at 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

6. Data Storage
Data 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 Resources
If 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 a
SaaS deployment of tibbr.
Figure 1 - Exposing internal resources
In 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 Premise
The on premise tibbr deployment option allows all components of tibbr to be run within your
organizations 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 meet
corporate requirements.
5

7. Componentized Architecture
tibbr 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 RSS
Server
Salesforce Email
server
Video
Conferencing
RSS Salesforce SAP
Oracle
Order Mgmt
Oracle
Expenses Email
App Runner
tibbr core
WebServer(apache)
Chat Server
(Prosody)
Search
(Solr)
Analytics
Notifications
(Cassandra)
tibbr Workers
Delayed job
Profile Data
Cache
(memcached)
tomcat
tibbr server
Database
(MySQL/
ORACLE)
LDAP
(AD)
Apple
Push 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
iPhone
iPad
App
Android
app
Desktop
client
Gadgets
Webparts
6

8. 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, performs
offline 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

9. Transport Level Security
As 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 Model
for details on the various network layers). These protocols are commonly used by web-based
applications, email, VoIP, etc.
Before a tibbr instance can be secured with SSL/TLS a certificate, preferably one issued by a
trusted 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

10. Data at Rest
tibbr 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 the
database using AES-256 bit encryption.
Entitlement
Securing 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 subjects
not 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 your
enterprise environment.
• Public subjects, as the name implies, are areas of collaboration and sharing which
are 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

11. User Authentication
tibbr 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 Authentication
With 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

12. LDAP Authentication
Most organizations leverage a directory server (LDAP) as a repository for structured data, such
as 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

13. SSO Authentication
tibbr 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 SAML2
Single 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

14. 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 other
resources, 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 tibbr
with SAML token
SAML
Access tibbr
Contacts tibbr
with SAML token
SSO Credentials
Access tibbr
Response
Figure 7 - SSO via SAML2 Authentication
13

15. 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 assigning
them directly to individual users.
Not only can users be assigned to roles, but Active Directory groups can also be assigned to
roles, 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