Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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.