Jive Security

| Contents | 2

Contents

Jive Security.................................................................................................3Security and Internal Development Processes................................................................................... 3

In-product Security Features...............................................................................................................3

Jive and Cookies.................................................................................................................................7

Other Cookies....................................................................................................................................11

Security of Public Cloud Communities..............................................................................................12

Security of Private Cloud Communities............................................................................................ 13

Security of Cloud-Delivered Services................................................................................................13

Security Recommendations...............................................................................................................15

Security FAQ..................................................................................................................................... 18

| Jive Security | 3

Jive Security

Deployed inside or outside firewalls, Jive's security and privacy features are designed to meet the

requirements of the most tightly regulated global industries and government agencies. Jive Software

continually evaluates the security of current and past product versions to protect your organization's data.

Jive Software makes every effort to protect the confidentiality, integrity, and availability of its public and

private cloud communities, as well as its cloud-delivered services.

Jive Software's public cloud platform, private cloud platform, and cloud-delivered services use the same

core data center architecture and security model.

Note: This security section describes only the Jive application. It does not describe the security

features of third-party products.

Security and Internal Development ProcessesThroughout the product development lifecycle, application security is continuously tested and improved.

Jive Software audits all new feature designs for high-level security considerations. Implementations of

these features are validated for potential security issues throughout the development phase. Existing

features are audited for security vulnerability regressions. Application-wide audits are performed to ensure

that feature integration is secure. Third-party components used by Jive are researched and tracked over

time for vulnerabilities and license compliance.

Development includes the following security checks:

• Source code reviews - if you'd like to see screenshots from our source code review tool, contact your

Jive Software representative.

• Automated penetration testing - each release of the application is tested with IBM's state-of-the-art

security product, AppScan. In addition, we offer AppScan test results from your instance. Contact your

Jive Software representative about this service.

• Vulnerability management - Jive Software relies on its own documented release procedure to manage

vulnerabilities, which includes a timeline for fixing issues, communicating them to customers, and

providing patches.

• Third-party audits - Jive Software performs annual audits across the core product for each hosted

service, including black box and white box analyses. If you would like to see these reports, please

contact your Jive Software representative.

In-product Security FeaturesSeveral built-in security features allow you to configure your Jive community for the appropriate level of

security for your organization.

| Jive Security | 4

Authentication Features

Login Security Using the Admin Console, you can configure Jive to

strongly discourage automated (computer-driven)

registration and logins. Automated registration is

usually an attempt to gain access to the application

for malicious reasons. By taking steps to make

registering and logging in something that only

a human being can do, you help to prevent

automated attacks. We recommend using the

following tools, all of which are available as options

in the Admin Console:

• Login Throttling: Enabling login throttling slows

down the login process when a user has entered

incorrect credentials more than the specified

number of times. For example, if you set the

number of failed attempts to 5 and a forced

delay to 10 seconds and a user fails to log in

after more than 5 attempts, the application would

force the user to wait 10 seconds before being

able to try again.

• Login Captcha: Enabling login Captcha will

display a Captcha image on the login page. The

image displays text (distorted to prevent spam

registration) that the user must enter to continue

with registration. This discourages registration

by other computers to send spam messages.

The login Captcha setting is designed to display

the Captcha image when throttling begins. In

other words, after the number of failed attempts

specified for throttling, the Captcha image is

displayed and throttling begins. You cannot

enable the login Captcha unless login throttling

is enabled. The Captcha size is the number of

characters that appear in the Captcha image,

and which the user must type when logging in.

A good value for this is 6, which is long enough

to make the image useful, but short enough to

make it easy for real humans.

• Password Strength: You can choose to enforce

strong passwords via the Admin Console. The

following options are available out of the box:

| Jive Security | 5

• a minimum of 6 characters of any type

• a minimum of 7 characters including 2

different character types (uppercase,

lowercase, number, punctuation, and/or

special characters)

• a minimum of 7 characters including 3

different character types

• a minimum of 8 characters, including all 4

character types

To learn more about configuring login and password

security, see Configuring Login Security and

Configuring User Registration.

Email Validation You can configure Jive to require email validation

for all new accounts. This setting helps to prevent

bots from registering with the site and then

automatically posting content. When you configure

email validation, Jive will require a new user to

complete the registration form and retrieve an email

with a click-through link to validate their registration.

To learn how to enable this setting, see Configuring

User Registration.

Account Lockout Jive does not offer account lockout as an out-of-

the-box feature. However, you can configure Jive

to authenticate against a thirty-party IDP that will

perform account lockout. If this is not something you

want to implement, you can request the account

lockout feature from Jive's Professional Services

team as a customization.

SSO As of Jive 5.0, the application includes support for

SAML out-of-the-box and can also be implemented

as a customization from Jive's Professional

Services team, a Jive partner, or an engineer of

your choice. Be sure to read Getting Ready to

Implement SAML SSO.

Delegated Authentication When delegated authentication is enabled and

configured, Jive makes a simple Web Service

call out to the configured server whenever a user

attempts to log in. This allows administrators

to control the definition of users outside of

| Jive Security | 6

the community. To learn more about this, see

Configuring Delegated Authentication.

Authorization Features

Jive includes powerful built-in end user and admin permissions matrices, as well as customizable

permissions. Depending on the assigned role, users can see or not see specific places and the content

posted there. In addition, administrative permissions can be used to limit the access level of administrators.

Jive administrators control user and admin permissions through the Admin Console. To learn more about

how permissions work, see Managing Permissions.

Moderation and Abuse Features

Moderation Jive administrators can enable moderation so that

designated reviewers view and approve content

before it is published in the community. This can be

useful for places that contain sensitive information.

In addition to content moderation, administrators

can enable moderation for images, profile images,

avatars, and user registrations. For more about

moderation, see Moderating Content.

Abuse Reporting Administrators can enable abuse reporting so that

users can report abusive content items. To learn

more about abuse reporting, see Setting Up Abuse

Reporting.

Banning Users Administrators can block a person's access to

Jive so that they are no longer able to log in to the

community. For example, if someone becomes

abusive in their messages (or moderating their

content is too time-consuming), administrators may

choose to ensure that the user can no longer log in.

Users can be banned through their login credentials

or their IP address. Be sure to read Banning People

for more information.

Interceptors Interceptors can be set up to perform customizable

actions on incoming requests that seek to post

content. Administrators can set up interceptors to

prevent specific users from posting content or to

filter and moderate offensive words, anything from

specific IP addresses, or the posting frequency

of specific users. To learn more about how

interceptors work, see Configuring Interceptors.

| Jive Security | 7

Encryption

HTTPS and Browser Encryption You can configure Jive to encrypt HTTP requests

using SSL. Documentation and instructions for

configuring SSL is available in Enabling SSL

Encryption. Additionally, you can configure Jive to

use three different HTTP/HTTPS configurations:

• Allow both HTTP and HTTPS

• Force HTTPS

• Force HTTPS on secure pages (login,

registration, change password, etc.)

Data Encryption Jive supports anything the JVM does at the

application level and anything OpenSSL does at

the HTTPD level. We actively use Blowfish/ECB/

PKCS5P, AES-256 for symmetric key encryption,

SHA-256 for one-way hashing, and we support

and recommend Triple-DES ciphers at the HTTPD

server for TLS encrypted channels.

• SHA-256 -- Jive user passwords are stored in

the database as salted SHA-256 hashes.

• AES-256 -- Bridging credentials, License

Metering information, and iPhone UDIDs are all

encrypted with AES-256.

• Blowfish/ECB/PKCS5Padding -- Used for storing

LDAP administrator credentials and OpenSearch

credentials in the database.

Cookies

Jive uses HTTP cookies in several places in the application to provide a better user experience. To learn

more about how the application uses cookies, be sure to read Jive and Cookies.

Note: The Jive Professional Services team can deliver security customizations if the out-of-the-box

security features do not meet the specific requirements of your organization.

Jive and CookiesJive uses HTTP cookies in several places in the application to provide a better user experience.

Jive does not set third-party cookies as part of the core product offering; however, it is possible for you to

configure the application so that third-party cookies are set. For example, you can configure the application

| Jive Security | 8

to use a Web-tracking tool such as Google Analytics or Webtrends, each of whom may set a third-party

cookie.

Jive does not set the "domain" attribute of an HTTP cookie.

Starting with Jive version 4.5.7, all Jive cookies that are set by the server (not via the client or browser)

have the HttpOnly flag.

Setting Up Secure Cookies

Out of the box, Jive is not configured to set the "secure" attribute for cookies that should only be sent via

HTTPS connections. You can configure Jive to send only allowed, secure cookies through the following

process:

1. Set the Jive system property "jive.cookies.secure" to the value "true". This results in all Jive-specific

cookies (not including JSESSIONID) having the "secure" attribute set on the cookie (Admin Console:

System > Management > System Properties).

2. Configure both Apache and Tomcat to only allow HTTPS connections. To understand these

configurations, see Forcing Traffic to HTTPS and Enabling SSL Encryption.

3. Finally, configure Tomcat with the "secure" attribute set to "true" in the server.xml configuration file,

specifically the "server/connector" element.

How Jive Sets Cookies

Jive performs an audit by searching for all instances of "setCookie" in the source code, and then sets the

following cookies.

Note: Except where noted, all of the following cookies do not contain user-identifiable information.

This behavior meets European Union privacy laws.

SPRING_SECURITY_REMEMBER_ME_COOKIE This cookie is used on the front-end as part of the

security authentication process to denote whether

or not the user wants to have their credentials

persist across sessions. It is part of the Spring

Security specification; details are available here.

• Possible values: string, the Base64 encoded

username and expiration time combined with

an MD5 hex hash of the username, password,

expiration time, and private key.

• Expiration: defaults to 14 days.

• Encryption: none. This is an MD5 hex hash.

• Example:

SPRING_SECURITY_REMEMBER_ME_COOKIE="YWFyb246MTMxNTU4MjUzNTI3MDoyZDUyODNmZjhhNjExZTdlMTcyMGZhYjVhNWNkNjI0Yg"

| Jive Security | 9

JSESSIONID This cookie is used on the front-end and the Admin

Console to identify a session. It is part of the Java

Servlet specification.

• Possible values: string, the unique token

generated by Apache Tomcat.

• Expiration: at session end.

• Encryption: none.

• Example:

JSESSIONID="1315409220832msB9E3A98AA1F2005E61FA975963FA4D12.node01"

jive.server.info This cookie is used on the front-end in combination

with Content Distribution Networks (CDN) like

Akamai to associate the user with a specific server

(also known as "session affinity").

• Possible values: string, a combination of

the serverName, serverPort, contextPath,

localName, localPort, and localAddr.

• Expiration: at session end.

• Encryption: none.

• Example:

jive.server.info="serverName=community.example.com:serverPort=443:contextPath= :localName=localhost.localdomain:localPort=9001:localAddr=127.0.0.1"

jive.user.loggedin This cookie is used on the front-end in combination

with Content Distribution Networks (CDN) to denote

the status of the current request.

• Possible values: string, true if the current

request originates from a browser where the

user is logged in.

• Expiration: at session end.

• Encryption: none.

• Example: jive.user.loggedin="true"

jive_wysiwygtext_height This cookie is used on the front-end to persist the

height of the editor window across sessions.

• Possible values: integer, the height in pixels of

the editor after the user chooses to expand the

editor window.

• Expiration: one year.

• Example: jive_wysiwygtext_height="500"

| Jive Security | 10

jive_default_editor_mode This cookie is used on the front-end for guest/

anonymous users who choose to use an editor

mode other than the default editor mode.

• Possible values: string, advanced.

• Expiration: 30 days.

• Encryption: none.

• Example: jive_default_editor_mode="advanced"

clickedFolder This cookie is used in the Admin Console to persist

the open/closed status of the current folder as used

in various tree-view portions of the Admin Console.

• Possible values: string, true, or false.

• Expiration: at session end.

• Encryption: none.

• Example: clickedFolder="true"

highlightedTreeviewLink This cookie is used in the Admin Console to persist

the current folder as used in various tree-view

portions of the Admin Console.

• Possible values: integer, the DOM ID of the

clicked folder.

• Expiration: at session end.

• Encryption: none.

• Example: highlightedTreeviewLink="23"

jiveLocale This cookie is used on the front-end for guest/

anonymous users who choose a locale setting.

• Possible values: string, locale code.

• Expiration: 30 days.

• Encryption: none.

• Example: jiveLocale="en_US"

jiveTimeZoneID This cookie is used on the front-end for guest/

anonymous users who choose a timezone setting.

• Possible values: string, timezone ID.

• Expiration: 30 days.

• Example: jiveTimeZoneID="234"

jive-cookie This cookie is used in the Admin Console to

temporarily persist an encrypted username/

password when creating a bridge between two

| Jive Security | 11

sites. The information in the cookie is first encrypted

with AES/256 encryption and then Base64

encoded.

• Possible values: string, Base64 encoded,

encrypted username/password of remote site.

• Expiration: at session end.

• Encryption: yes.

• Example: jive-

cookie="YWFyb246MTMxNTU4MjUzNTI3MDoyZDUyODNmZjhhNjExZTdlMTcyMGZhYjVhNWNkNjI0Yg"

jive.user.lastvisited This cookie is used on the front-end to store the last

time the user visited the site.

• Possible values: long, value in milliseconds that

represents the time of the login.

• Expiration: 30 days.

• Encryption: none.

• Example: jive.user.lastvisited="1315292400000"

JCAPI-Token This cookie is used to avoid CSRF attacks when the

UI layer uses session-based authentication.

Other CookiesOther services attached to your instance may set their own cookies. You'll need to refer to their

documentation for more information about these cookies.

Google Analytics

The following Google Analytics cookies may set:

• __utma

• __utmb

• __utmc

• __utmv

• __utmz

F5 Load Balancer

The F5 load balancer used by Jive Software sets the following cookies on hosted and Cloud instances.

Note that the cookie names are dynamic, based on the name of F5's Big IP pool. Yours may be named

differently. You can read more about how F5 uses cookies here.

• BCSI-CS-f89c73c53b0f638a

• BIGipServerm2s4c5-3-pool

| Jive Security | 12

Security of Public Cloud CommunitiesThe application's secure data architecture and Safe Harbor certification ensures maximum security and

privacy of your public cloud (hosted) instance.

Secure Data Architecture

Virtualization technology and multi-tenancy architectures at the security, storage, and network layers

ensure separation between each public cloud instance and SaaS-delivered feature. Jive Software follows

several industry best practices to harden all cloud operating systems and databases that support all of

the layers of the platform. All hosts use security-hardened Linux distributions with non-default software

configurations and minimal processes, user accounts, and open network ports. Jive Software's cloud

engineers never execute at root and all log activity is stored remotely as an additonal security precaution.

Jive Software's public cloud instances and SaaS services hosts include various encryption methods to

protect data transmission over untrusted networks. We use SSL or HTTPS for all public cloud instances.

Additionally, Jive Software has implemented encryption for both the data transmission and storage of

offsite backups in our remote data center(s).

We use a variety of automatic tools and manual techniques to ensure our environment is secure.

Secure Data Center

All of Jive Software's hosting data centers have central surveillance monitoring, key cards for initial

access, and other mechanisms such as biometrics or two-factor authentication systems to ensure that

only authorized personnel have access to the physical machines. Only authorized data center personnel

are granted access credentials to our data centers. No one can enter the production area of the data

center without prior clearance and an authorized escort. All Jive Software office locations adhere to similar

security controls to limit access to active employees only.

Jive’s network infrastructure was designed to eliminate single points of failure. Each data center leverages

multiple internet feeds from multiple providers, ensuring that in the event of a carrier outage, our public

cloud (hosted) sites and SaaS-delivered services are still available. The switching and routing layers within

our data centers are designed so that device or network link failure does not impact service, and ensures

that public cloud customers have the highest level of availability.

Jive Software's public cloud and SaaS-delivered services are backed up regularly to guard against data

loss. All instances are backed up to an offsite location using an electronic backup and recovery system.

All backed-up information is transmitted and stored in an encrypted format. The Jive Software public cloud

team performs failure and redundancy testing during the implementation phase and as needed throughout

the equipment lifecycle.

Jive Software is Safe Harbor and TRUSTe certified and our data centers are either SAS 70, SSAE 16

SOC2, or ISO 27001 certified, depending on the location.

| Jive Security | 13

Public Cloud FAQ

For more questions and answers about our public cloud platform, see Public Cloud FAQ in the Jive

Community. You will need to be a registered user of the community to view this document.

Security of Private Cloud CommunitiesOur private cloud offering provides you with all of the features and security of the public cloud product, but

deployed behind your firewall.

Here's how it works (click the image to enlarge it):

Security of Cloud-Delivered ServicesSome of the application's services are cloud-delivered to your instance and updated regularly via our

private network.

Here's how it works (click the image to enlarge it):

| Jive Security | 14

Web Services Web services requests fully respect the configured

permissions of Jive. As such, if web services are

fully enabled for all users, there is no risk of private

content exposure or invalid content manipulation.

Users will only be able to view and modify content

they have access to in the application. However,

web services do give users a mechanism for

creating and downloading content en masse. If

you do not want users to have the ability to quickly

download all of the content they are able to access,

consider enabling web services only for specific

users. To learn how to do this, see Setting Access

for Web Service Clients.

Video Video Plugin Security

Mobile Mobile Security

Jive Apps Market Jive Apps Security

Jive Genius and Recommender Service Jive Genius Security

| Jive Security | 15

Security RecommendationsThese security recommendations depend on your community's specific configuration.

Caution: Each community can be configured differently. Because of this, not all of

these recommendations apply to all communities. If you have any questions about these

recommendations, please contact your Jive Software representative.

Internal communities are typically for employees only.

External communities are typically for customers, vendors, and other external audiences.

Security

Recommendation:

Applies to: Description:

Configure user login

security

External

Communities

Login security can include throttling, Captcha, and

password strength requirements.

For implementation details:

See Configuring Login Security and Configuring User

Registration.

Enable SSO Internal Communities A single-sign on solution can help you provide

a consistent login experience for your users

while providing identity management for your

organization via a third-party vendor. Jive Software

strongly recommends using a single sign-on

solution for access to internal communities. In

addition to the out-of-the-box SSO options in the

application, our Professional Services team can

create customizations to meet almost any single sign-

on requirement.

For implementation details:

See the Single Sign-On section, or, if you need

an SSO customization, contact your Jive Software

account representative.

| Jive Security | 16

Security

Recommendation:

Applies to: Description:

Add an extra layer of

security with SSL

External and Internal

Communities

SSL will enable you to encrypt HTTP requests. Over

the past few years it's become more common for

public sites that request a username and password

to give the user the option to browse the site in either

HTTP or HTTPS. For security and ease of use, we

believe that authenticated users should always be

browsing the community via HTTPS because it's

become commonplace to browse the Internet via

insecure wifi access points. Any community that

allows its authenticated users to browse via HTTP is

open to session hijacking.

For implementation details:

See Enabling SSL Encryption.

Add VPN Internal Communities If you use both SSO login and SSL/HTTPS user

access, you shouldn't need VPN, too. However, VPN-

only access to the community can be configured

for your community in both public and private cloud

communities.

For implementation details:

Contact your IT department to set up VPN-only

access to the Jive application.

Prevent spam in your

community

External

Communities

Everyone hates spam, and it can also present

security risks. Limit it in your community as much as

you can.

For implementation details:

Preventing Spam includes several suggestions for

dealing with spammers and preventing spam in your

community.

Understand administrative

permissions and how they

work

External and Internal

Communities

Administrative permissions can be a powerful tool for

limiting who can make changes to your community.

For implementation details:

See the Managing Administrative Permissions

section.

| Jive Security | 17

Security

Recommendation:

Applies to: Description:

Add an extra username/

password verification step

for Admin Console access

via Apache

External and Internal

Communities

Apache includes a couple of features that can help

you keep Jive more secure. Jive runs on Tomcat

behind an Apache HTTP web server. You can set

up Apache features such as IP restrictions or basic

authentication for specific URLs using standard

Apache HTTP configurations. The main Apache

HTTP configuration file for the Jive application

is /usr/local/jive/etc/httpd/conf/

httpd.conf.

For requests inside your network, Apache should

remain totally open. The security for specific requests

(admin pages, file attachments, hidden content) is all

executed at the Tomcat/Java level. For every request

that comes in, the user's account is looked up and the

permissions are checked against the specific request.

Because of this, users are only able to access URLs

which they have permission to view. Some system

administrators choose to set IP filtering or basic

authentication (via Apache) on the Admin Console.

This is primarily useful for externally-oriented Jive

communities (those that allow employees, as well as

vendors and customers as community users) so that

users are unaware of an Admin Console. There is no

security risk of leaving the /admin URL exposed. If

you implement this, users trying to access any of the

Admin Console pages must successfully enter their

external username/password combo to gain access.

For implementation details:

See Apache's documentation.

Understand the security

of the Jive Genius

Recommender Service

External and Internal

Communities

This cloud-delivered service communicates between

your community and Jive Software via a secure proxy

and state-of-the-art encryption protocols.

For more details:

See Jive Genius Security.

| Jive Security | 18

Security

Recommendation:

Applies to: Description:

Block search robots External

Communities

Search robots can wreak havoc in your community,

so it's a good idea to set up robot blockers.

For implementation details:

See this tutorial.

Security FAQ

Does Jive Software access data from my public cloud instance?

Jive Software aggregates data from our public cloud customer instances. The kinds of data we collect

include usage statistics, user travel patterns, adoption statistics, and other anonymous information.

Among other things, this information helps us to make decisions about future product development and

improvement. In addition, your contract sets forth how we protect your user-generated content (i.e., we

access this data solely to provide support and other services to you as you request).

How does the application prevent cross-site request forgeries (CSRF) using request-based tokens?

Every form throughout the application is protected from CSRF by a token scoped to each request which

prevents forgery attempts. The server requires the token on any request that can change data. If the token

is not present or does not match, the HTTP request will fail.

Are web services tested?

Yes. All web services are tested as part of an automated monthly security scan process.

Why do you zip or compress certain types of files when a user uploads them to Jive?

There are a number of known security issues with Internet Explorer (IE). In particular, IE will attempt

to display or execute a file even if the web server sends an HTTP header indicating that the browser

should download, instead of display, the file. This behavior, also known as "content sniffing" or "MIME

sniffing," allows attackers to upload seemingly okay files (for example, an MS Word file) that actually

contain malicious HTML. An IE user would then attempt to view the file. If the file is not zipped, IE will

"sniff" the contents of the file, determine that the file is HTML, and then attempt to render the HTML instead

of opening the file with MS Word.

The following types of files are zipped by Jive when they are attached to content: text/plain and text/HTML.

Jive uses a magic number process to determine the correct MIME type of an uploaded file. For example, if

a document called mydocument.doc is uploaded, the magic number process will validate the document. If

the file is actually an HTML file, then Jive zips the file as a security precaution.

| Jive Security | 19

Does Jive use Sun's Java Virtual Machine (JVM)?

Yes. Jive uses Sun's JVM 1.6 and the Java Secure Socket Extension (JSSE), which is FIPS 140-

compliant.

Which cryptographic technologies are used in Jive?

Jive supports anything the JVM does at the application level and anything OpenSSL does at the HTTPD

level. We actively use Blowfish/ECB/PKCS5P, AES-256 for symmetric key encryption, SHA-256 for one-

way hashing, and we support and recommend Triple-DES ciphers at the HTTPD server for TLS encrypted

channels.

• SHA-256 -- Jive user passwords are stored in the database as salted SHA-256 hashes.

• AES-256 -- Bridging credentials, License Metering information, and iPhone UDIDs are all encrypted

with AES-256.

• Blowfish/ECB/PKCS5Padding -- Used for storing LDAP administrator credentials and OpenSearch

credentials in the database.

If your product uses cryptography, has this cryptography been certified under the Cryptographic

Module Validation Program or is it in the process of CMVP certification? If yes, which

Cryptographic Module Testing (CMT) Laboratory are you using and what is your Cryptographic

Module Security Level?

Jive uses Sun's JVM 1.6 and the Java Secure Socket Extension (JSSE).

Is the product public-key enabled and is it interoperable with the DoD PKI?

Jive supports X.509-based PKI. However, extra configuration steps are required; we recommend a Jive

Professional Services customization.

I am a public cloud hosted customer. Can you encrypt my data at rest?

Yes. We can encrypt your dedicated databases that reside in our hosting data centers. Contact your Jive

Software representative to request this additional service and pricing schedules. Note that this service may

require additional lead time depending on the size and traffic of your community.