Guide to the Secure Configuration of JBoss Fuse 6

with profile Standard System Security Profile for JBoss
This profile contains rules to ensure standard security baseline of JBoss Fuse. Regardless of your system's workload all of these checks should pass.
This guide presents a catalog of security-relevant configuration settings for JBoss Fuse 6. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the scap-security-guide package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.

Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for JBoss Fuse 6, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

Profile Information

Profile TitleStandard System Security Profile for JBoss
Profile IDxccdf_org.ssgproject.content_profile_standard

CPE Platforms

  • cpe:/a:redhat:jboss_fuse:6.0
  • cpe:/a:redhat:jboss_fuse:6.1.0
  • cpe:/a:redhat:jboss_fuse_service_works:6.0

Revision History

Current version: 0.1.43

  • draft (as of 2019-02-21)

Table of Contents

  1. JBoss Fuse 6
    1. Apache ActiveMQ Configuration
    2. Apache Karaf Configuration

Checklist

Group   Guide to the Secure Configuration of JBoss Fuse 6   Group contains 4 groups and 67 rules
Group   JBoss Fuse 6   Group contains 3 groups and 67 rules

[ref]   JBoss Fuse is an open source Enterprise Service Bus (ESB) with an elastic footprint that supports integration beyond the data center. The lack of license fees and the ability to deploy JBoss Fuse in several different configurations advances intelligent integration to all facets of your business – on premise or in the Cloud.

JBoss Fuse combines Apache Camel, Apache CXF, Apache ActiveMQ, Apache Karaf and Fuse Fabric in a single integrated distribution. Core messaging is provided by Apache ActiveMQ, services framework (SOAP, XML/HTTP, RESTful HTTP) is provided by Apache CXF and integration framework is provided by Apache Camel. Apache Karaf provides a lightweight OSGI-based runtime container.

Group   Apache ActiveMQ Configuration   Group contains 10 rules

[ref]   The rules in this group validate Apache ActiveMQ related items.

Rule   All PKI Certificates Are Valid DoD Certificates   [ref]

All PKI Certificates in use should be valid at the time of use.

Rationale:

By using invalid certificates the server may allow unauthorized users access to the system.

Severity: 
high
Identifiers and References

Rule   Ensure Administrators Can Only Change Security Related Configuration Attributes   [ref]

Security attributes are typically associated with internal data structures and configuration (e.g., application deployment, logging, monitoring) within the application server and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the organizational information security policy.

Rationale:

If unauthorized entities were able to change security attributes, the integrity and/or confidentiality of the server could be compromised.

Severity: 
medium
Identifiers and References

Rule   Ensure ActiveMQ Web Console is using PKI   [ref]

PKI should be enabled for the Web Console.

Rationale:

All applications requiring user authentication to access sensitive data must be PKI-enabled in compliance with DoDI 8520.2 PKI and PKI Enabling and are required to credentials approved under the DoD PKI program.

Severity: 
medium
Identifiers and References

Rule   Ensure Default System Java Authentication and Authorization Service Is In Use   [ref]

Using the default system JAAS configuration ensures user identification and authentication are performed by JBoss Fuse.

Rationale:

Using an administrator specified JAAS configuration enables a more rigorous security posture.

Severity: 
medium
Identifiers and References

References:  CM-6

Rule   Ensure No Default User Accounts Exist   [ref]

Remove, rename, or comment out the default user accounts defined in .properties files.

Rationale:

Default configurations are commonly leveraged by attackers to gain entry into closed systems. Removing, renaming, or commenting out default user accounts makes malicious exploitation more complex.

Severity: 
medium
Identifiers and References

References:  IA-5

Rule   SSL Is Enabled on the ActiveMQ Web Console   [ref]

The server must utilize cryptography to protect the confidentiality of remote access management sessions.

Rationale:

If cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised.

Severity: 
medium
Identifiers and References

Rule   Ensure No Default Roles Exist   [ref]

Remove, rename, or comment out the default roles defined in .properties files.

Rationale:

Default configurations are commonly leveraged by attackers to gain entry into closed systems. Removing, renaming, or commenting out default roles makes malicious exploitation more complex.

Severity: 
medium
Identifiers and References

References:  IA-5

Rule   Ensure Only Administrators Can Modify Configuration Files   [ref]

Server should be protected with permission sets which allow only an application administrator to modify application resource configuration files.

Rationale:

An access control flaw exists if users or processes can view or modify data to which they should not be permitted. This could result in situations ranging from information disclosure to system compromise and could potentially result in the compromise of other systems on the network.

Severity: 
medium
Identifiers and References

Rule   Disable or Remove Clear-Text Passwords   [ref]

Eliminate clear-text passwords in JBoss configuration files. All passwords should be encrypted and all password files should have restricted file permissions.

Rationale:

Clear-text passwords are an unnecessary security vulnerability. While risk of exposure can be mitigated through configured permissions and file ownership, these methods do not completely remediate the risk.

Severity: 
medium
Identifiers and References

References:  SC-28

Rule   Stored Passwords Must Be Encrypted   [ref]

Stored passwords must be encrypted.

Rationale:

Passwords need to be protected at all times and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised.

Severity: 
high
Identifiers and References
Group   Apache Karaf Configuration   Group contains 1 group and 57 rules

[ref]   The rules in this group validate Apache Karaf related items.

Group   Apache Karaf Policies and Procedures   Group contains 14 rules

[ref]   The rules in this group validate Apache Karaf policies and procedures.

Rule   Identify and Document Application Data Flows   [ref]

It is recommended to identify and document application data flows. This will allow insight into what paths sensitive information takes through the application environment and what data source connections need to be encrypted.

Rationale:

Failure to document an application's data flows reduces security, increases the chance for architectural and configuration errors, and can impede performance. Many applications use network services that are not immediately apparent.

Severity: 
medium
Identifiers and References

References:  SC-8, SC-9, SC-23

Rule   Document Incident Response Procedures   [ref]

Ensure well developed procedures exist for incident handling. Incidents include any events that are anomalous to the environment.

Rationale:

Planning for incidents prior to real-life scenarios increases incident response time and mitigates damages. Failure to adequately prepare, plan, and exercise for these scenarios can result in extensive losses.

Severity: 
medium
Identifiers and References

References:  IR-1, IR-8

Rule   Ensure Adequate Physical Protections   [ref]

The hardware and software executing JBoss Fuse, as well as the software critical to security policy enforcement must be protected from unauthorized modification including unauthorized modifications by potentially hostile outsiders. Reasonable physical security measures to ensure that unauthorized personnel do not have physical access to the hardware running the JBoss Enterprise Application Platform software must be implemented.

Rationale:

Many software security precautions can easily be bypassed by personnel with physical access to hardware storing data or executing an application.

Severity: 
high
Identifiers and References

References:  PE-1, PE-2, PE-3, PE-7, PE-18

Rule   Ensure Auditing Policy Exists   [ref]

In order to effectively audit and review system logs, an audit policy should be written to identify data and trends of interest.

Rationale:

Without a comprehensive audit policy and review procedures, organizations risk missing critical events or event trends within their environment. These missed events may indicate system anomalies ranging from malicious attacks, system instabilities, system misuse, etc.

Severity: 
medium
Identifiers and References

References:  AU-1, AU-2, AU-3, AU-5

Rule   Perform Periodic Disaster Recovery Exercises   [ref]

Production environments should exercise disaster recovery procedures that include provisions for the JBoss platform, deployed applications, and any required source code at least annually. Environments requiring higher assurances of disaster recovery ability should test procedures more often, possibly quarterly or even monthly.

Rationale:

Planning for disasters and extended outages prior to a real-life scenario helps mitigate losses associated with identified disasters. Failure to adequately prepare, plan, and exercise for these scenarios can result in extensive losses.

Severity: 
medium
Identifiers and References

References:  CP-4

Rule   Assign A JBoss Administrator   [ref]

There must be one or more competent individuals who are assigned to manage JBoss Fuse, its environment and the security of the information it contains.

Rationale:

Incompetent, careless, or negligent JBoss administrators can completely invalidate a secure JBoss configuration and create numberless problems for JBoss.

Severity: 
high
Identifiers and References

References:  AT-2, AT-3, AT-4

Rule   Access Control Policy and Procedures   [ref]

JBoss administrators must have access to guidance regarding account creation, permissions assignments, role assignments, etc.

Rationale:

A consistent, cohesive access control policy is impossible to attain without a well-documented access control policy and related procedures. Failure to do so typically results in over-assignment of access permissions for users and applications, stale access for users and applications, and other access control misconfigurations that reduce the effectiveness of the security policy.

Severity: 
medium
Identifiers and References

References:  AC-1

Rule   Define Minimum and Maximum Password Length Requirement   [ref]

Organizations should create an authenticator management policy that defines minimum and maximum password sizes for user accounts accessing JBoss and its deployed applications.

Rationale:

In brute force scenarios, passwords of extended lengths increase password security and the length of time required to decrypt the password. However, there are risks associated with requiring passwords of great lengths, as users may take steps to circumvent policy; such as using repetitive passwords, writing password reminders, or writing down their passwords.

Severity: 
medium
Identifiers and References

References:  IA-5

Rule   Deployed Applications - Java Permission Deployment Docs   [ref]

Java permissions for applications should be documented and carefully reviewed prior to deployment. Developers and administrators should strive to balance application permissions and application functionality.

Rationale:

Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Careful documentation, along with a thorough review will help prevent needlessly insecure permission assignments for applications. An overabundance of Java permissions can allow applications to circumvent one of Java's strongest security features - the Java Security Manager sandbox.

Severity: 
medium
Identifiers and References

References:  AC-1

Rule   Define Minimum Password Complexity Requirement   [ref]

Organizations should create an authenticator management policy that defines a minimum level of complexity for user accounts accessing JBoss and its deployed applications. These requirements should also restrict passwords from containing dictionary words and reusing previous passwords.

Rationale:

Complex passwords increase password security and the length of time required to decrypt the password. Additionally, complex passwords are less likely to be found in password dictionaries. However, there are risks associated with requiring overly complex passwords, as users may take steps to circumvent policy; such as using repetitive passwords, writing password reminders, or writing down their passwords.

Severity: 
medium
Identifiers and References

References:  IA-5

Rule   Ensure Regular Backup Schedule   [ref]

JBoss applications and configuration files should be backed up at least weekly, possibly more if needed by the environment.

Rationale:

Failure to regularly backup JBoss configuration files and deployed applications can result in extensive downtime or information losses in the event of a disaster or other system outage.

Severity: 
medium
Identifiers and References

References:  CP-9

Rule   Perform Periodic Incident Response Exercises   [ref]

Production environments should exercise incident response procedures at least annually. Environments requiring higher assurances of security should test incident response procedures more often, possibly quarterly or even monthly. Incident response procedures should cover all anomalous events.

Rationale:

Planning for incidents and practicing procedures to be followed prior to real-life scenario improves response time and mitigates damages/losses that occur with incidents.

Severity: 
medium
Identifiers and References

References:  IR-3

Rule   Document Disaster Recovery Procedures   [ref]

Robust disaster recovery documentation and procedures should exist. This documentation should include provisions for the JBoss platform, deployed applications, required source code, and supporting applications (such as authentication stores or database servers).

Rationale:

Planning for disasters and extended outages prior to a real-life scenario helps mitigate losses associated with identified disasters. Failure to adequately prepare, plan, and exercise for these scenarios can result in extensive losses.

Severity: 
medium
Identifiers and References

References:  CP-1, CP-2

Rule   Define Minimum Password Expiration Interval   [ref]

Organizations should create an authenticator management policy that defines a maximum password age for user accounts accessing JBoss and its deployed applications.

Rationale:

In combination with password length and complexity, regularly changing passwords can defeat many attacks. If a password or password hash is intercepted by a malicious party, changing the password can remove access or render invalid a cracking attempt on the hash. However, there are risks associated with frequently changing passwords. Users may take steps to circumvent policy such as using repetitive passwords or using password derivatives. Additionally, changing passwords for system or application accounts introduces an element of configuration risk. Poorly coordinated or documented changes can result in system outages or create other problems.

Severity: 
medium
Identifiers and References

References:  IA-5

Rule   Configure JBoss Logs Number of Days Retained   [ref]

Logging should be configured to maintain logs for a organization defined continuous number of days.

Rationale:

If adequate online audit storage capacity is not maintained, intrusion monitoring, security investigations, and forensic analysis can be negatively affected.

Severity: 
medium
Identifiers and References

Rule   All PKI Certificates Are Valid DoD Certificates   [ref]

All PKI Certificates in use should be valid at the time of use.

Rationale:

By using invalid certificates the server may allow unauthorized users access to the system.

Severity: 
high
Identifiers and References

Rule   Ensure Deployed Applications Do Not Have Network Permissions   [ref]

Deployed applications must not be granted network permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.

Rationale:

Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle.

Severity: 
medium
Identifiers and References

References:  AC-6

Rule   Enable FIPS for User and Process Authentication   [ref]

The Application Server must utilize FIPS 140-2 approved encryption modules when authenticating users and processes.

Rationale:

Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified, and cannot be relied upon to provide confidentiality or integrity and DoD data may be compromised due to weak algorithms. FIPS 140-2 is the current standard for validating cryptographic modules and NSA Type-X (where X=1, 2, 3, 4) products are NSA certified hardware-based encryption modules.

Severity: 
medium
Identifiers and References

Rule   Disable Runtime Permissions for Deployed Applications   [ref]

Deployed applications must not be granted runtime permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.

Rationale:

Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Granting RuntimePermission to applications allows these applications to modify classloaders or modify the running security manager. Either of these actions can be used to elevate permissions and increase the number of potential damaging actions that can be taken.

Severity: 
medium
Identifiers and References

References:  AC-6

Rule   Ensure Administrators Can Only Change Security Related Configuration Attributes   [ref]

Security attributes are typically associated with internal data structures and configuration (e.g., application deployment, logging, monitoring) within the application server and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the organizational information security policy.

Rationale:

If unauthorized entities were able to change security attributes, the integrity and/or confidentiality of the server could be compromised.

Severity: 
medium
Identifiers and References

Rule   Ensure Only Administrators Can Modify Configuration Files   [ref]

Server should be protected with permission sets which allow only an application administrator to modify application resource configuration files.

Rationale:

An access control flaw exists if users or processes can view or modify data to which they should not be permitted. This could result in situations ranging from information disclosure to system compromise and could potentially result in the compromise of other systems on the network.

Severity: 
medium
Identifiers and References

Rule   Disable and Remove Clear-Text Passwords   [ref]

Eliminate clear-text passwords in JBoss configuration files. All passwords should be encrypted and all password files should have restricted file permissions.

Rationale:

Clear-text passwords are an unnecessary security vulnerability. While risk of exposure can be mitigated through configured permissions and file ownership, these methods do not completely remediate the risk.

Severity: 
medium
Identifiers and References

References:  SC-28

Rule   Enable Encrypted Passwords   [ref]

Password hashing should be enabled in all security realms where plain-text passwords are currently in use.

Rationale:

Failure to enable password hashing within a login module can result in plain-text exposure client passwords used for authentication.

Severity: 
medium
Identifiers and References

References:  SC-8, SC-9

Rule   Ensure Default Roles Have Been Removed   [ref]

Remove, rename, or comment out the default roles defined in .properties files.

Rationale:

Default configurations are commonly leveraged by attackers to gain entry into closed systems. Removing, renaming, or commenting out default roles makes malicious exploitation more complex.

Severity: 
medium
Identifiers and References

References:  IA-5

Rule   Disable All Permission for Deployed Applications   [ref]

Deployed applications must not be granted all permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.

Rationale:

Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Using AllPermissions is essentially disabling the Java security sandbox and is inadvisable in nearly every scenario.

Severity: 
medium
Identifiers and References

References:  AC-6

Rule   Enable CAC Card Usage for Deployed Applications   [ref]

JBoss applications implementing authentication should utilize the DoD Public Key Infrastructure. The DoD Public Key Infrastructure is designed to use hardware tokens such as the Common Access Card in conjunction with issued X.509 certificates. These tokens are typically protected with a PIN that unlocks access to the private certificate stored on the token.

Rationale:

Leveraging the DoD Public Key Infrastructure increases the security of an application because the DoD PKI raises the bar for exploitation of user identities. Applications that require authentication and do not utilize PKI must then rely on a less secure form of authentication, such as username and password. Additionally, current DoD guidance requires the use of DoD PKI over username and password.

Severity: 
medium
Identifiers and References

References:  IA-5

Rule   Ensure Java Runtime Environment Is A Vendor Supported Version   [ref]

Evaluated JBoss installation must use a vendor supported Java virtual machine - i.e., one that has not reached end-of-life. Migration strategies should be developed when end-of-life is impending.

Rationale:

Java installations should be a vendor supported version. If the Java virtual machine in use by JBoss is not supported by the vendor, this may result in outages, unresolvable problems, no access to security or functional updates, etc.

Severity: 
high
Identifiers and References

References:  CM-6

Rule   Disable Socket Permissions for Deployed Applications   [ref]

Deployed applications must not be granted any socket permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.

Rationale:

Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Most well-designed applications will not need to directly manipulate sockets for network access (access to datasources should be handled through datasources, which can be assigned SocketPermission.

Severity: 
medium
Identifiers and References

References:  AC-6

Rule   Enable SSL On The Web Console   [ref]

The server must utilize cryptography to protect the confidentiality of remote access management sessions.

Rationale:

If cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised.

Severity: 
medium
Identifiers and References

Rule   Ensure All Downloaded Software Is Validated   [ref]

Software and packages should be downloaded from redhat.com, and hash validated.

Rationale:

Without validating downloaded files are authentic, malicious users may compromise software before it has even been installed. Attackers may redirect traffic to alternate download locations and attempt to trick administrators into downloading modified software.

Severity: 
medium
Identifiers and References

References:  CM-6

Rule   Enable The Web Console To Use PKI   [ref]

PKI should be enabled for the Web Console.

Rationale:

All applications requiring user authentication to access sensitive data must be PK-enabled in compliance with DoDI 8520.2 PKI and PK Enabling and are required to credentials approved under the DoD PKI program.

Severity: 
medium
Identifiers and References

Rule   Disable Hot Deployment   [ref]

Hot deployment should be disabled on production servers. Hot Deployment allows for automatic deployment of Java applications by simply placing Java applications into the deploy directory.

Rationale:

Hot deployments are not a recommended best practice for production environments. By requiring the additional step of restarting the JBoss server, application deployments become more deliberate and purposeful.

Severity: 
low
Identifiers and References

References:  CM-7

Rule   Ensure JBoss Fuse Is A Vendor Supported Version   [ref]

Evaluated JBoss installation must be a vendor supported version of JBoss Fuse 6. Organizations using JBoss Fuse must use a vendor supported version with an active support contract.

Rationale:

Failure to utilize a supported version of JBoss in a production environment can lead to outages, unresolvable problems, no access to security or functional updates, etc.

Severity: 
medium
Identifiers and References

References:  CM-6

Rule   Ensure Default User Accounts Have Benn Removed   [ref]

Remove, rename, or comment out the default user accounts defined in .properties files.

Rationale:

Default configurations are commonly leveraged by attackers to gain entry into closed systems. Removing, renaming, or commenting out default user accounts makes malicious exploitation more complex.

Severity: 
medium
Identifiers and References

References:  IA-5

Rule   Ensure JBoss Files Are Owned By Appropriate Users   [ref]

All JBoss Fuse files within the installation directory should be owned by the JBoss process owner account.

Rationale:

To prevent unauthorized modification or disclosure of JBoss configuration settings, all files within the installation directory should be owned by the JBoss process owner account.

Severity: 
medium
Identifiers and References

References:  AC-3

Rule   Secure Remote Access Via SSH   [ref]

The server must utilize cryptography to protect the confidentiality of remote access management sessions.

Rationale:

If cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised.

Severity: 
medium
Identifiers and References

Rule   Enable FIPS Compliant Modules   [ref]

While JBoss itself has no need to load FIPS compliant modules, the underlying technologies such as Java do. Utilizing only FIPS compliant modules decreases compatibility with applications that are not FIPS enabled.

Rationale:

Enabling FIPS compliant algorithms ensures that the underlying technologies that JBoss works through are using cryptographic modules that have been vetted by NIST for security, stability, and strength. Failure to utilize FIPS certified modules may cause the underlying technologies used by JBoss to utilize older, less secure algorithms. Failure to enable only FIPS compliant modules may also have regulatory consequences, as FIPS 140-2 requires the use of FIPS compliant modules by all federal agencies.

Severity: 
medium
Identifiers and References

References:  SC-13

Rule   Disable All Unused Ports, Protocols, And services   [ref]

The server must prohibit or restrict the use of unauthorized functions, ports, protocols, and/or services.

Rationale:

The server provides numerous processes, features and functionalities that utilize TCP/IP ports. Some of these processes may be deemed to be unnecessary or too insecure to run on a production system.

Severity: 
medium
Identifiers and References

Rule   Ensure Only Approved Administrators Can Change System Configurations   [ref]

The server must enforce logical access restrictions associated with changes to application configuration.

Rationale:

When dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to server components for the purposes of initiating changes, including upgrades and application modifications.

Severity: 
high
Identifiers and References

Rule   Ensure Log Files Are Only Accessed By Authorized Users   [ref]

Only authorized personnel may view log files.

Rationale:

If the application provides too much information in error logs and administrative messages to the screen, this could lead to compromise. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Severity: 
medium
Identifiers and References

Rule   Ensure JBoss Files Have Correct Permissions   [ref]

All JBoss files within the installation directory should be readable by the JBoss process owner and JBoss administrators only.

Rationale:

To prevent unauthorized modification or disclosure of JBoss configuration settings, access to all files within the installation directory should be restricted to the JBoss process owner account and Jboss administrators.

Severity: 
medium
Identifiers and References

References:  AC-3, AC-6

Rule   Disable Or Secure Remote Access   [ref]

Remote access must be secured so it is accessible by trusted administrators only. If this condition is not met, the access must be disabled from the deployment.

Rationale:

Failure to secure against unauthorized access can quickly lead to system compromise. The default access included with JBoss is a well-known attack vector that can be leveraged to load malicious code to be executed on the server.

Severity: 
high
Identifiers and References

References:  AC-3

Rule   Ensure Stored Passwords Are Encrypted   [ref]

Stored passwords must be encrypted.

Rationale:

Passwords need to be protected at all times and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised.

Severity: 
high
Identifiers and References

Rule   Deny JBoss Process Owner Console Access   [ref]

The JBoss process owner should not have interactive console login access.

Rationale:

In order to limit access in the event of an exploitation of the Jboss or one of its deployed applications, the account owning the Jboss process should be limited in its ability to interact with the supporting operating system where possible. Thus, the JBoss process owner account should not have interactive console access.

Severity: 
medium
Identifiers and References

References:  AC-6

Rule   Secure or Remove Web Console   [ref]

The Web Console application must be secured so it is accessible by trusted administrators only. If this condition is not met, the application must be removed (deleted) from deployment.

Rationale:

Failure to secure the default consoles against unauthorized access can quickly lead to system compromise. The default consoles included with JBoss are a well-known attack vector that can be leveraged to load malicious code to be executed on the server.

Severity: 
high
Identifiers and References

References:  AC-3

Rule   Remove All Non-Essential Bundles And Features   [ref]

All non-essential bundles and features should be removed from production servers.

Rationale:

The server provide a myriad of differing processes, features and functionalities. Some of these processes may be deemed to be unnecessary or too insecure to run on a production DoD system. Servers must provide the capability to disable or deactivate functionality and services that are deemed to be non-essential to the server mission or can adversely impact server performance.

Severity: 
medium
Identifiers and References

Rule   Ensure Java Authentication and Authorization Service Is Configured   [ref]

Using the default system JAAS configuration ensures user identification and authentication are performed by JBoss Fuse.

Rationale:

Using an administrator specified JAAS configuration enables a more rigorous security posture.

Severity: 
medium
Identifiers and References

References:  CM-6

Rule   Secure or Disable JMX Access   [ref]

JMX access must be secured so it is accessible by trusted administrators only. If this condition is not met, the access must be disabled from the deployment.

Rationale:

Failure to secure JMX against unauthorized access can quickly lead to system compromise. The default access included with JBoss is a well-known attack vector that can be leveraged to load malicious code to be executed on the server.

Severity: 
high
Identifiers and References

References:  AC-3

Rule   Configure Java Security Manager To Use An Environment Policy   [ref]

The Java Security Manager is a crucial piece of the Java security infrastructure. JBoss Fuse should be configured to load a Java security policy that has been vetted for use in the environment.

Rationale:

A weak, default, or incomplete Java Security Manager policy file can completely compromise the security of a Java installation by granting excessive permissions to applications running within the sandbox. These permissions can be leveraged (maliciously or not) to run code against the operating system.

Severity: 
medium
Identifiers and References

References:  SA-13

Rule   Ensure Deployed Applications Have Restricted File Permissions   [ref]

Deployed applications must not be granted file permissions - except to those that are dedicated to the application only. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.

Rationale:

Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Granting unrestricted access to the host operating system creates a large attack vector for malicious users that have penetrated the JBoss server.

Severity: 
medium
Identifiers and References

References:  AC-6

Rule   Reduce Logging To Decrease Storage Capacity Limitations   [ref]

The server must configure auditing to reduce the likelihood of storage capacity being exceeded.

Rationale:

The server auditing capability is critical for accurate forensic analysis. Alerting administrators when audit log size thresholds are exceeded helps ensure the administrators can respond to heavy activity in a timely manner. Failure to alert increases the probability that an adversary's actions will go undetected. The server or the configured Network Attached Storage Device (SAN) must alert administrators when audit log usage reaches a defined percentage of overall capacity.

Severity: 
low
Identifiers and References

Rule   Ensure Only Authorized Users Can Associate PKI Information   [ref]

Throughout the course of normal usage, authorized users of application servers will have the need to associate security attributes in the form of PKI credentials with information. The server utilizes a role based authentication model when managing server resources and limits access according to user role.

Rationale:

The server must ensure that only the users who are authorized to associate security attributes with information are allowed to do so.

Severity: 
medium
Identifiers and References

Rule   Configure LDAP To Fail Securely   [ref]

The server must fail securely in the event of an operational failure.

Rationale:

Fail secure is a condition achieved by the server in order to ensure that in the event of an operational failure, the system does not enter into an unsecure state where intended security properties no longer hold.

Severity: 
medium
Identifiers and References

Rule   Ensure JBoss Process Owner Executes with Least Privilege   [ref]

Operating environment permissions assigned to the JBoss process owner should be in compliance with the principle of least privilege.

Rationale:

In order to reduce the potential impact of exploitation against the JBoss application server (and the rest of the operating environment), the JBoss process owner should execute with as few permissions as possible in the environment (if the account is not local to the operating system or is distributed across multiple operating systems). Failure to limit permissions can dramatically increase the severity of exploits against the JBoss server, such as the execution of arbitrary code.

Severity: 
medium
Identifiers and References

References:  AC-6

Rule   Configure DoD or CNS approved PKI Class 3 and Class 4 Certificates   [ref]

The server must use DoD or CNS approved PKI Class 3 or Class 4 certificates.

Rationale:

Class 3 PKI certificates are used for servers and software signing rather than for identifying individuals. Class 4 certificates are used for business-to-business transactions. Utilizing unapproved certificates not issued or approved by DoD or CNS creates an integrity risk.

Severity: 
high
Identifiers and References

Rule   Enable SSL When LDAP Is Configured   [ref]

The server must utilize encryption when using LDAP for authentication.

Rationale:

Passwords need to be protected at all times and encryption is the standard method for protecting passwords during transmission.

Severity: 
high
Identifiers and References

Rule   Ensure JBoss Logging Is Secured   [ref]

Only error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages should be generated.

Rationale:

Any application providing too much information in error logs and in administrative messages to the screen risks compromising the data and security of the application and system. The structure and content of error messages needs to be carefully considered by the organization and development team.

Severity: 
medium
Identifiers and References
Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.