Security Benchmark JBoss Enterprise Application Platform 5.x

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.

CVSSv2 Risk Assessment: 7.5 / High - CVSSv2 Formula: (AV:N/AC:L/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT I

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

To determine the version of JBoss EAP installed, perform the following actions:

• Execute run.bat --version or run.sh --version located within JBOSS_HOME/bin

The output of the command above will display a variety of information; including the version and build information for JBoss.

Next, review support documentation and interview JBoss administrators. Work with JBoss administrators to access the Red Hat Network customer portal in order to review and validate active subscriptions (https://access.redhat.com/home). Additionally, ensure the version of JBoss has not reached end-of-life. Organizations using JBoss EAP must use a vendor supported version with an active support contract.

Other environments should install a vendor supported version of Red Hat JBoss Enterprise Application Platform and maintain an active subscription. Contact Red Hat directly to subscribe to the JBoss software channel (http://www.redhat.com).

Ensure downloaded software is checked against vendor supplied hashes to ensure the software has not been modified in transit. Tools such as sha1sum or md5sum (Linux) or File Checksum Integrity Verifier (FCIV) for Windows can be used to generate hash checksums for downloaded files.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:200001
File: eap5-ocil.xml

CVSSv2 Risk Assessment: 7.5 / High - CVSSv2 Formula: (AV:N/AC:L/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT I

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

To identify the JRE used by JBoss, perform the following actions:

• Execute run.bat --version or run.sh --version located within JBOSS_HOME/bin

The output of the command above will display a variety of information; including the vendor and version information for the JRE in use by JBoss. Search the vendor's website and support documentation to ensure the vendor actively supports the version of Java virtual machine in use. If the software will reach end-of-life within the next year, ensure the organization is developing a migration plan.

Java Runtime Environments commonly used with JBoss include:

• Sun JRE 1.6.x
• IBM JRE 1.6.x
• OpenJDK JRE 1.6.x

Organizations should install a vendor supported Java Runtime Environment.

Ensure downloaded software is checked against vendor supplied hashes to ensure the software has not been modified in transit. Tools such as sha1sum or md5sum (Linux) or File Checksum Integrity Verifier (FCIV) for Windows can be used to generate hash checksums for downloaded files.

Finally, organizations must develop migration plans for Java Runtime Environments that reach end-of-life within the next year.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:200201
File: eap5-ocil.xml

The JBoss server profiles are preconfigured with various deployed applications. Using a more restrictive profile ensures that less applications are deployed, minimizing the attack surface of the JBoss server and decreasing the amount of trimming that must be performed.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Ensure that all configuration changes and deployments are made to the appropriate server profile. Production environments should utilize the production server profile. Development and test environments should choose the profile that best fits their needs.

JBoss administrators should use the profiles as defined in the validation text.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:200501
File: eap5-ocil.xml

Technology Preview components are not production-ready, vendor supported JBoss components. They may be incomplete, contain bugs, insecure features or architecture, etc.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Delete the JBOSS_HOME/picketlink/ folder.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:201801
File: eap5-oval.xml

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. Additionally, the JBoss Hot Deployment feature has been known to become unstable over time - consuming additional memory and resources.

CVSSv2 Risk Assessment: 3.0 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Delete the following file:

• JBOSS_HOME/server/[PROFILE]/deploy/hdscanner-jboss-beans.xml

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:113001
File: eap5-oval.xml

Serializing objects is not a recommended practice for Java applications. Object serialization shows poor performance and is not typically scalable for production. Additionally, object serialization creates dependency concerns within the object hierarchy.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Interview application developers and review application documentation. If deployed applications utilize SRP and/or source code is available for reference, review evidence that the default SRPVerifierStore interface is not in use and that the existing code does not use serialized objects for persistence.

Application developers should not use the default implementation for SRPVerifierStore, and should extend it to avoid the use of serialized password objects.

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:110101
File: eap5-ocil.xml

Explicitly referencing one of the identified authorization modules ensures that applications extend the security policies defined in security-policies-jboss-beans.xml. This allows JBoss administrators to set a secure baseline that can be tuned on a per-application basis.

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3,AC-4

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,EBBD-1,EBBD-2,EBBD-3

Review possible locations for definition of <application-policy> elements. Specifically, ensure that 'code' attributes for <authorization><policy-module> elements are either 'org.JBoss.security.authorization.modules.DelegatingAuthorizationModule' or 'org.JBoss.security.authorization.modules.JACCAuthorizationModule'.

These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

• JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

NOTE: This applies even if the application is using Extensible Access Control Markup Language (XACML) Authorization Module.

Applications deploying their own security policies must specify one of the following <policy-module> within their 'code' attributes:

• org.JBoss.security.authorization.modules.DelegatingAuthorizationModule
• org.JBoss.security.authorization.modules.JACCAuthorizationModule

Example:

<application-policy name="demo">
	<authorization>
	<policy-module code="org.JBoss.security.authorization.modules.JACCAuthorizationModule"></policy-module>
	</authorization>
</application-policy>

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:203901
File: eap5-ocil.xml

Deployed applications requiring access to data sources should have limited permissions to interact with the database drivers.

CVSSv2 Risk Assessment: 6.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:C/I:C/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3,AC-6

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1

To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

• java.home/lib/security/java.security
• JBOSS_HOME/bin/security_cc.policy

Other environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Permissions required for JDBC drivers will vary and should be configured according to vendor documentation. In general, JDBC drivers should not be granted AllPermission.

The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) to applications accessing defined data sources. This should be done in cooperation with application developers or application documentation. Substitute the directory name of the JDBC driver where [JDBC.DRIVER] is specified in the code sample.

// granting permissions to JDBC driver 
grant codeBase "file:${JBoss.server.home.dir}/lib/[JDBC.DRIVER]" { 
	//JDBC specific permissions to be granted go here
};

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:204201
File: eap5-ocil.xml

To help ensure robust server operations, a DefaultDS that does not use HSQLDB should be specified. DefaultDS is used by some JBoss components by default.

CVSSv2 Risk Assessment: 2.6 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:N/I:P/A:P)

DoD Risk Category: CAT III

NIST 800.53 Mapping: SC-4

DoD 8500.2 Mapping: ECRC-1

Review defined data sources in the JBOSS_HOME/server/[PROFILE]/deploy directory. Data sources will be suffixed as -ds.xml. Search for a data source with a <jndi-name>DefaultDS</jndi-name> element. OS text searching utilities can help find the DefaultDS. The DefaultDS CANNOT be HSQL. An HSQL data source will contain elements like: <driver-class>org.hsqldb.jdbcDriver</driver-class> and <type-mapping>Hypersonic SQL</type-mapping>.

Linux: grep -Hri "<jndi-name>DefaultDS</jndi-name>" $JBOSS_HOME/server/[PROFILE]/deploy/*-ds.xml

Create a default DS file for the desired database at JBOSS_HOME/server/[PROFILE]/deploy/DefaultDS.xml. Examples of this file are located in JBOSS_HOME/docs/examples/jca. The DefaultDS must not be a HSQLDB.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:204401
File: eap5-ocil.xml

Sharing databases between applications is a poor security practice that can create injection and leakage vulnerabilities that cross application boundaries.

CVSSv2 Risk Assessment: 5.1 / Medium - CVSSv2 Formula: (AV:N/AC:H/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-4

DoD 8500.2 Mapping: ECRC-1

Interview the application developers and/or review source code to identify when data sources are used. Ensure that the application is not storing data within the DefaultDS.

Next, review the data source definition files (files suffixed *.xml) used by the deployed user applications to ensure they do not reference the same database used by the DefaultDS.

NOTE: Using the same database server is acceptable, however the database must not be the same.

Create and deploy a data source in addition to the DefaultDS to store application data. This new data source must not point to the same database as the DefaultDS data source.

Data source templates can be found in the JBOSS_HOME/docs/examples/jca/ directory.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:215701
File: eap5-ocil.xml

HSQL is not meant for production environments - it is there to speed development and enable faster application prototyping. Thus, it is not a full-featured data source intended for production use.

CVSSv2 Risk Assessment: 2.6 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:N/I:P/A:P)

DoD Risk Category: CAT III

NIST 800.53 Mapping: SC-4

DoD 8500.2 Mapping: ECRC-1

Delete the following files that refer to the HSQLDB database:

• JBOSS_HOME/server/[PROFILE]/deploy/hsqldb-ds.xml
• JBOSS_HOME/common/lib/hsqldb.jar
• JBOSS_HOME/common/lib/hsqldb-plugin.jar
• JBOSS_HOME/server/[PROFILE]/deploy/messaging/hsqldb-persistence-service.xml

Delete the HSLQDB database files:

• JBOSS_HOME/server/[PROFILE]/data/hypersonic/*

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:204501
File: eap5-oval.xml

HSQL is not meant for production environments - it is there to speed development and enable faster application prototyping. Thus, it is not a full-featured data source intended for production use.

CVSSv2 Risk Assessment: 1 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: SC-4

DoD 8500.2 Mapping: ECRC-1

Remove the security domain for HsqlDbRealm in the JBOSS_HOME/server/[PROFILE]/conf/login-config.xml file as shown.

<!-- Security domains for testing new jca framework
<application-policy name = "HsqlDbRealm">
	<authentication>
		<login-module code = "org.JBoss.resource.security.ConfiguredIdentityLoginModule" flag = "required">
		<module-option name = "principal">sa</module-option>
		<module-option name = "userName">cctest</module-option>
		<module-option name = "password">cc1248</module-option>
		<module-option name = "managedConnectionFactoryName">JBoss.jca:service=LocalTxCM,name=DefaultDS</module-option>
		</login-module>
	</authentication>
</application-policy>
-->

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:204601
File: eap5-oval.xml

In order to function properly, JMS should be configured to use the appropriate datastore. Production environments require a persistence service definition for JMS that does not use HSQLDB.

CVSSv2 Risk Assessment: 2.6 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:N/I:P/A:P)

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Interview the JBoss administrators and application developers to determine if JMS is in use. A quick check can also be performed by checking for the existence of the following files:

• JBOSS_HOME/server/[PROFILE]/deploy/messaging
• JBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rar

If JMS is installed, a persistence-service.xml file must exist that does not use HSQLDB. This persistence file will be located in the following location:

• JBOSS_HOME/server/[PROFILE]/deploy/messaging/*persistence-service.xml

Copy the [database]-persistence-service.xml file that corresponds to the database you are using from the JBOSS_HOME/docs/examples/jms directory to JBOSS_HOME/server/[PROFILE]/deploy. Make any required content changes to fit the persistence service to the environment.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:204701
File: eap5-ocil.xml

This is a performance optimization when using Oracle Database as the DefaultDS.

CVSSv2 Risk Assessment: 2.6 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:N/I:N/A:P)

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Review defined data sources in the JBOSS_HOME/server/[PROFILE]/deploy directory. Data sources will be suffixed as -ds.xml. Search for a data source with a DefaultDS element. Review the DefaultDS datasource. If the DefaultDS is Oracle Database, review the persistence plugin located at JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml. The DatabasePersistencePlugin attribute must be configured like below:

<attribute name="DatabasePersistencePlugin">
	org.JBoss.ejb.txtimer.OracleDatabasePersistencePlugin
</attribute>

When using the Oracle Database as the DefaultDS, the database persistence plugin definition must be updated in JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml to:

<attribute name="DatabasePersistencePlugin">
	org.JBoss.ejb.txtimer.OracleDatabasePersistencePlugin
</attribute>

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:205001
File: eap5-ocil.xml

The IBM JRE 1.6 default policy provider does not work correctly with the JBoss EAP security policy. Failure to assign the correct policy can lead to system instability.

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Review the run.bat or run.sh file as appropriate to determine how JBoss Enterprise Application Platform is calling the Java Runtime Environment. By default, these files are configured to locate the JRE installation through the JAVA_HOME environment variable. If the JAVA_HOME environment variable is not configured, you must track the JRE installation path using information from the run.bat/run.sh file and the operating system PATH variables.

Open JAVA_HOME/jre/lib/security/java.security and review the entry for policy.provider. If the entry is not set to sun.security.provider.PolicyFile, this is a failure.

When IBM JRE 1.6 is configured as the Java Runtime Environment, the following configuration changes must be made for compatibility:

Edit the file JAVA_HOME/jre/lib/security/java.security and set the value of policy.provider to sun.security.provider.PolicyFile

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:206501
File: eap5-ocil.xml

SecurityDomain is the recommended way to implement security in components, because of the advantages the JAAS Subject offers, and the increased support offered to ASP-style application and resource deployments.

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3,IA,SC

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

Interview JBoss administrators and application developers. Review application documentation. If a need has been identified to secure production applications, JAAS SecurityDomains should be used.

Configure and apply SecurityDomains where appropriate for production applications.

For example, an <application-policy> (SecurityDomain) can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

• JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

To determine which <application-policy> are in use by deployed applications, search for <security-domain> elements within the following deployment descriptors:

• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss.xml

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:110001
File: eap5-ocil.xml

This rule enforces strict authorization, requiring authenticated users to be members of defined roles. This allows JBoss administrators to create a simpler, tighter security policy.

CVSSv2 Risk Assessment: 4.6 / Medium - CVSSv2 Formula: (AV:N/AC:H/Au:S/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3,AC-6

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1

Update allRolesAttribute for the <Realm> element with className="org.jboss.web.tomcat.security.JBossWebRealm" in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Set the attribute value to "strict". By default, the allRolesAttribute is set to "authOnly". For example:

<Realm className="org.jboss.web.tomcat.security.JBossWebRealm" certificatePrincipal="org.jboss.security.auth.certs.SubjectDNMapping" allRolesMode="strict" />

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:203801
File: eap5-oval.xml

The specification of <security-role> elements is a recommended practice to ensure portability across application servers and for deployment descriptor maintenance.

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3,AC-6

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1

Review the web.xml deployment descriptors for deployed applications. Ensure that <security-role> elements have been define that are referenced by <security-constraint><auth-constraint> elements within the <web-app> root element.

Working with application developers (or available documentation), determine the desired roles for controlling access to the deployed applications.

Next, create the roles within web.xml.

<web-app>
	<security-role>
		<description>The role required to access restricted content </description>
		<role-name>AuthorizedUser</role-name>
	</security-role>
</web-app>

Finally, require the roles within the application's deployment descriptor, web.xml:

<web-app>
	<security-constraint>
		<auth-constraint>
			<role-name>AuthorizedUser</role-name>
		</auth-constraint>
	</security-constraint>
</web-app>

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:109201
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 6 / Medium - CVSSv2 Formula: (AV:N/AC:M/Au:S/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

Ensure the default user accounts in the default <application-policy> elements located within the configuration file: JBOSS_HOME/server/[PROFILE]/conf/login-config.xml have been removed, renamed, or commented out.

<module-option name="principal">sa</module-option>
<module-option name="userName">sa</module-option>
<module-option name="password"></module-option>

<module-option name="principal">guest</module-option>
<module-option name="userName">guest</module-option>
<module-option name="password">guest</module-option>
				

Examine the .properties files located within the JBOSS_HOME/server/[PROFILE]/conf/props/ directory.

By default, the following files exist:

• jbossws-users.properties
• jmx-console-users.properties
• messaging-users.properties

Ensure the default user accounts have been removed, renamed, or commented out. This includes:

• admin
• kermit
• guest

Remove, rename, or comment out the default user accounts in the default <application-policy> elements located within the configuration file: JBOSS_HOME/server/[PROFILE]/conf/login-config.xml.

					<module-option name="principal">sa</module-option>
					<module-option name="userName">sa</module-option>
					<module-option name="password"></module-option>
					
					<module-option name="principal">guest</module-option>
					<module-option name="userName">guest</module-option>
					<module-option name="password">guest</module-option>
				

Remove, rename, or comment out the default user accounts in properties files: JBOSS_HOME/server/[PROFILE]/conf/props/

• jbossws-users.properties
• jmx-console-users.properties
• messaging-users.properties

The default user accounts include:

• admin
• kermit
• guest

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:300101
File: eap5-ocil.xml

Default configurations are commonly leveraged by attackers to gain entry into closed systems. Renaming, removing, or commenting out default roles can make exploitation more complex. These steps can also prevent inadvertent assignment of permissions.

CVSSv2 Risk Assessment: 6 / Medium - CVSSv2 Formula: (AV:N/AC:M/Au:S/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

Ensure the default role assignments have been removed, renamed, or commented out from the default properties files located in JBOSS_HOME/server/[PROFILE]/conf/props/

• jbossws-roles.properties
• jmx-console-roles.properties
• messaging-roles.properties

The default role assignments are JBossAdmin, HttpInvoker, friend, and guest.

Finally, ensure the default role assignments within application specific deployment descriptors have been removed, renamed, or commented out:

• JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/web.xml
• JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/WEB-INF/web.xml
• JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml

These role assignments will fall within <auth-constraint> elements and will look similar to the following:

<security-constraint>
	<web-resource-collection>
		<web-resource-name>HtmlAdaptor</web-resource-name>
		<description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application</description>
		<url-pattern>/*</url-pattern>
	</web-resource-collection>
	<auth-constraint>
		<role-name>JBossAdmin</role-name>
	</auth-constraint>
</security-constraint>

Ensure the default role assignments have been removed, renamed, or commented out from the default properties files located in JBOSS_HOME/server/[PROFILE]/conf/props/

• jbossws-roles.properties
• jmx-console-roles.properties
• messaging-roles.properties

The default role assignments are JBossAdmin, HttpInvoker, friend, and guest.

Finally, ensure the default role assignments within application specific deployment descriptors have been removed, renamed, or commented out:

• JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/web.xml
• JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/WEB-INF/web.xml
• JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml

These role assignments will fall within <auth-constraint> elements and will look similar to the following:

<security-constraint>
	<web-resource-collection>
		<web-resource-name>HtmlAdaptor</web-resource-name>
		<description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application</description>
		<url-pattern>/*</url-pattern>
	</web-resource-collection>
	<auth-constraint>
		<role-name>JBossAdmin</role-name>
	</auth-constraint>
</security-constraint>

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:300201
File: eap5-ocil.xml

Whitelisting allowed HTTP methods against all URL's is a recommended security practice to minimize the attack surface of deployed applications. This must be done carefully to ensure that security loopholes are not created, as JBoss allows all HTTP methods by default..

CVSSv2 Risk Assessment: 6 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

Review application deployment descriptors for indications that <http-method> has been used to whitelist HTTP verbs. Application deployment descriptors will be located at JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/web.xml All deployed applications should restrict HTTP verbs.

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:109301
File: eap5-ocil.xml

Production applications should be carefully evaluated to determine the appropriate level of cache credential timeouts. Overuse of cached credentials can leave applications vulnerable to stale authentication stores.

CVSSv2 Risk Assessment: 4 / Medium - CVSSv2 Formula: (AV:N/AC:H/Au:N/C:P/I:P/A:N)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-8,SC-9,SC-23

DoD 8500.2 Mapping: ECTM-1,ECTM-2

Open the JaasSecurityManagerService Mbean configuration file located at JBOSS_HOME/server/[PROFILE]/conf/jboss-service.xml

Find the element <mbean code="org.jboss.security.plugins.JaasSecurityManagerService" name="jboss.security:service=JaasSecurityManager">

Change the <DefaultCacheTimeout> to 1800 or less.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
2. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:109601
File: eap5-oval.xml

The default SNMP package (snmp-adaptor.sar) implements joeSNMP, which itself implements SNMP versions 1 and 2. Both versions of the SNMP protocol have many flaws and known vulnerabilities that can leveraged by attackers. Often these are simple remote exploitations that can be easily used by attackers to penetrate a network.

CVSSv2 Risk Assessment: 7.5 / High - CVSSv2 Formula: (AV:N/AC:L/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT I

NIST 800.53 Mapping: CM-6,CM-7

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1

To determine if SNMP capabilities have been completely removed, check for the existence of the SNMP adaptor located here: JBOSS_HOME/server/[PROFILE]/deploy/snmp-adaptor.sar/

If the exploded SAR exists, joeSNMP has been deployed and SNMP capabilities using this SNMP implementation still exist for the JBOSS server.

Delete the directory JBOSS_HOME/server/[PROFILE]/deploy/snmp-adaptor.sar/

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:200901
File: eap5-oval.xml

An overly high setting can create a denial of service vulnerability in which an attacker simultaneously performs several large POSTS - tying up server resources and network bandwidth.

CVSSv2 Risk Assessment: 6.3 / Medium - CVSSv2 Formula: (AV:N/AC:M/Au:S/C:N/I:N/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6,CM-7

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1

Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check for <Connector> elements that define a maxPostSize attribute. If a maxPostSize attribute is defined, it should be 104857600 or less (100 MB).

Ensure that all <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured maxPostSize attributes (104857600 or less).

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:401101
File: eap5-ocil.xml

An overly high setting can inadvertently create a denial of service vulnerability in which many users are authenticated and tying up server resources.

CVSSv2 Risk Assessment: 6.3 / Medium - CVSSv2 Formula: (AV:N/AC:M/Au:S/C:N/I:N/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6,CM-7

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1

Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check for <Connector> elements that define a maxSavePostSize attribute. If a maxSavePostSize attribute is defined, it should be 12288 or less (12 KB).

Ensure that all <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured maxSavePostSize attributes (12288 or less).

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:401201
File: eap5-ocil.xml

Failure to set the server attribute aids malicious users in fingerprinting a web server. However, the server attribute is also used legitimately by some applications for identification.

CVSSv2 Risk Assessment: 2.0 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-6,CM-7

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1

Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check each HTTP <Connector> element to ensure it defines a server attribute. A server attribute should be defined, and it should be set to something other than Apache-Coyote/1.1.

Ensure that all HTTP <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured server attributes (set to something other than Apache-Coyote/1.1).

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:401301
File: eap5-ocil.xml

In an environment where FIPS mode has been enabled for the JVM, overriding those settings can lead to system instability or the use of non-FIPS algorithms.

CVSSv2 Risk Assessment: 6.0 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6,CM-7

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1

Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check each <Connector> element that contains a secure=true attribute. Ensure this connector does not define a ciphers attribute and instead inherits ciphers defined by the JVM.

Ensure that all secure <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have not defined cipher attributes.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:401401
File: eap5-ocil.xml

An overly high setting can be easily exploited to create a denial of service condition by tying up server resources.

CVSSv2 Risk Assessment: 6.3 / Medium - CVSSv2 Formula: (AV:N/AC:M/Au:S/C:N/I:N/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6,CM-7

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1

Review HTTP <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check to ensure they define a connectionTimeout attribute. The connectionTimeout attribute should be 20000 or less (20 seconds).

Ensure that all HTTP <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured connectionTimeout attributes (20000 or less).

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:401501
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 6.8 / Medium - CVSSv2 Formula: (AV:N/AC:M/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SA-13

To load an environment specific security policy, simply append the following line to JBOSS_HOME/bin/run.conf or JBOSS_HOME/bin/run.conf.bat as appropriate (depending on the host operating system).

JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==[PATH TO POLICY FILE]"

NOTE: Using a prepackaged policy file is acceptable, as long as the policy file has been reviewed for compatibility and security within the current environment.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:204301
File: eap5-oval.xml

CVSSv2 Risk Assessment: 3.7 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT III

NIST 800.53 Mapping: AC-6

DoD 8500.2 Mapping: ECLP-1

To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

Other environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)

Review all JSM permissions granted to MBeans. Grant statements should be limited to specific users and specific methods.

For example, permission A in the example below is allowed while permission B is not:

//Permission A
grant principal javax.security.auth.x500.X500Principal "CN=Administrator,OU=JBoss,O=RedHat,L=Raleigh,ST=NC,C=US"
{
	permission javax.management.MBeanPermission
	"className#member[objectName]",
	"invoke";
}
grant principal javax.management.remote.JMXPrincipal "guest"
{
	permission javax.management.MBeanPermission "*", "queryNames";
	permission javax.management.remote.SubjectDelegationPermission;

//Permission B
grant {
	permission javax.management.MBeanPermission "*","invoke";
}

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:205101
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 6.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:C/I:C/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-6

DoD 8500.2 Mapping: ECLP-1

To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

• java.home/lib/security/java.security
• JBOSS_HOME/bin/security_cc.policy

Other environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy).

Review all permissions granted to user deployed applications. The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications.

Grant statements granting file permissions are permitted only when the file permission targets are located within the user application's directory and dedicated for use by the deployed application.

For example, permission A in the example below is allowed while permission B is not:

//Permission A
grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.io.FilePermission "${JBoss.server.home.dir}/deploy/userApplication/temp.txt", "read";
};
//Permission B
	grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.io.FilePermission "/etc/shadown", "read";
};

The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.

Application access granted to files by java.io.FilePermission must be located within the deployed application's directory path and be dedicated for use by the deployed application. Grant statements in conflict with this guidance should be modified or removed.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:205201
File: eap5-ocil.xml

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

CVSSv2 Risk Assessment: 5.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-6

DoD 8500.2 Mapping: ECLP-1

To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

• java.home/lib/security/java.security
• JBOSS_HOME/bin/security_cc.policy

Other environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy).

Review all permissions granted to user deployed applications. Grant statements granting network permissions are not allowed and will look similar to the following:

grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.net.NetPermission [specific permissions];
};

The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.

Permissions granted to applications via java.net.NetPermission should be removed.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:205301
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 6.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:C/I:C/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-6

DoD 8500.2 Mapping: ECLP-1

To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

• java.home/lib/security/java.security
• JBOSS_HOME/bin/security_cc.policy

Other environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)

Review all permissions granted to user deployed applications. Grant statements granting runtime permissions are not allowed and will look similar to the following:

grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.lang.RuntimePermission [specific permissions];
};

The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.

Permissions granted to applications via java.lang.RuntimePermission should be removed.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:205401
File: eap5-ocil.xml

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.).

CVSSv2 Risk Assessment: 6.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:C/I:C/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-6

DoD 8500.2 Mapping: ECLP-1

To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

• java.home/lib/security/java.security
• JBOSS_HOME/bin/security_cc.policy

Other environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)

Review all permissions granted to user deployed applications. Grant statements granting socket permissions are not allowed and will look similar to the following:

grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.net.SocketPermission [specific permissions];
};

The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.

Permissions granted to applications via java.net.SocketPermission should be removed.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:205501
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 6.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:C/I:C/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-6

DoD 8500.2 Mapping: ECLP-1

To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

• java.home/lib/security/java.security
• JBOSS_HOME/bin/security_cc.policy

Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)

Review all permissions granted to user deployed applications. Grant statements granting AllPermission are not allowed and will look similar to the following:

grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.security.AllPermission;
};

The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.

Permissions granted to applications via java.security.AllPermission should be removed.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:205601
File: eap5-ocil.xml

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

CVSSv2 Risk Assessment: 5.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Check for components.xml. These files are typically located within the WEB-INF director of a deployed WAR. However, components.xml can also be located within the META-INF directory of a JAR or any JAR directory containing classes with a @Name annotation.

Within components.xml, the security identity should specify a JAAS security domain to override the default Seam configuration. See the example below:

<security:identity jaas-config-name="[security domain]"/>

The security domain must map to a valid JAAS security domain.

Within components.xml, the security identity should specify a JAAS security domain to override the default Seam configuration. See the example below:

<security:identity jaas-config-name="[security domain]"/>

Components.xml is typically located within the WEB-INF director of a deployed WAR. However, components.xml can also be located within the META-INF directory of a JAR or any JAR directory containing classes with a @Name annotation.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:202801
File: eap5-ocil.xml

A keystore should be setup for production environments. Defining a keystore is a basic step towards implementing security and allowing for the use of public/private key cryptography for JBoss. The keystore should be password protected to protect the integrity of the keystore and prevent unauthorized modification.

CVSSv2 Risk Assessment: 2.4 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:S/C:P/I:P/A:N)

DoD Risk Category: CAT III

NIST 800.53 Mapping: SC-28,IA-5

DoD 8500.2 Mapping: ECCR-1,ECCR-2,ECCR-3,IAIA-1,IAIA-2,IATS-1,IATS-2

In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Ensure the following lines exist within the any loaded policy file:

keystore "file:[PATH TO KEYSTORE]";
keystorePasswordURL "file:[PATH TO PASSWORD FILE]";

NOTE: The file names and paths may vary.

Add the following lines to any loaded policy file:

keystore "file:[DESIRED PATH TO KEYSTORE]";
keystorePasswordURL "file:[DESIRED PATH TO PASSWORD FILE]";

A typical configuration may look like the following:

keystore "file:${JBoss.server.home.dir}/cc.keystore";
keystorePasswordURL "file:${JBoss.server.home.dir}/cc.password";

NOTE: The file names and paths may be different. Those shown are the defaults. If the keystore or password file are in different locations, the policy should reflect that.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:206001
File: eap5-ocil.xml

A keystore should be setup for production environments. Defining a keystore is a basic step towards implementing security and allowing for the use of public/private key cryptography for JBoss. The keystore should be password protected to protect the integrity of the keystore and prevent unauthorized modification.

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-8,IA-5

DoD 8500.2 Mapping: ECTM-1,ECTM-2,IAIA-1,IAIA-2,IATS-1,IATS-2

Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:

keystore "file:[PATH TO KEYSTORE]";

Next, validate that the keystore exists at the specified path and that the JBoss process owner account and JBoss administrators have READ/WRITE access to the keystore.

To create a JBoss keystore, run the following command (you will be prompted to create a password):

keytool -importcert -alias jboss -keystore [PATH TO KEYSTORE AS DEFINED IN POLICY FILE] -file [PATH TO TRUSTED CERTIFICATE TO IMPORT] -noprompt -trustcacerts

Setting permissions will vary by operating system, but typically commands like cacls, xacls, chmod, setfacl, etc can all be used to restrict permissions on the keystore. Only the JBoss process owner and JBoss administrators should have READ/WRITE access to the keystore.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:205901
File: eap5-ocil.xml

A password-protected keystore should be setup for production environments. The password for the keystore should be stored in a password file to facilitate automated startup of JBoss Enterprise Application Platform.

CVSSv2 Risk Assessment: 3.7 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-28,IA-5

DoD 8500.2 Mapping: ECCR-1,ECCR-2,ECCR-3,IAIA-1,IAIA-2,IATS-1,IATS-2

Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:

keystorePasswordURL "file:[PATH TO KEYSTORE PASSWORD FILE]";

Next, validate that the password file exists at the specified path, that only JBoss process owner account and JBoss administrators have READ/WRITE access to the file, and the correct password for the JBoss keystore is in the file.

To add a password file for a JBoss keystore, simply add the plain-text password to a file and then specify that file in a loaded Java Security Manager policy.

First, ensure the password file location is identified in the policy file being loaded by the Java Security Manager:

keystorePasswordURL "file:[DESIRED PATH TO KEYSTORE PASSWORD FILE]";

Next, add the plain-text password to file whose location you just defined.

Finally, restrict permissions on the password file so that only the JBoss process owner account and JBoss administrators have READ/WRITE access. Setting permissions will vary by operating system, but typically commands like cacls, xacls, chmod, setfacl, etc can all be used to restrict permissions on the keystore. Only the JBoss process owner and JBoss administrators should have READ/WRITE access to the password file.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:216001
File: eap5-ocil.xml

Failure to protect the integrity of the keystore used by JBoss can result in authorized modification of the keystore and subsequent certificate trust compromises for JBoss.

CVSSv2 Risk Assessment: 3.7 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-28,IA-5

DoD 8500.2 Mapping: ECCR-1,ECCR-2,ECCR-3,IAIA-1,IAIA-2,IATS-1,IATS-2

Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:

keystore "file:${JBoss.server.home.dir}/cc.keystore";

Next, access the contents of the keystore using the following command:

keytool -list -keystore [PATH TO KEYSTORE]

You should be prompted for a password (non-blank).

Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:

keystore "file:[PATH TO KEYSTORE]";

Add a password to the keystore:

keytool -storepasswd -keystore [PATH TO KEYSTORE]

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:215801
File: eap5-ocil.xml

A keystore should be setup for production environments with JBoss as a trustedCertEntry for proper functioning of the JBoss Enterprise Application Platform.

CVSSv2 Risk Assessment: 2.4 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:S/C:P/I:P/A:N)

DoD Risk Category: CAT III

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:

keystore "file:${JBoss.server.home.dir}/cc.keystore";

Next, list the contents of the keystore using the following command:

keytool -list -keystore [PATH TO KEYSTORE]

The jboss alias must exist as a trustedCertEntry.

To ensure the Jboss alias is a trustedCertEntry, the certificate must be imported to the keystore with the proper command:

keytool -importcert -alias jboss -keystore [PATH TO KEYSTORE] -file JBOSS_HOME/bin/JBossPublicKey.RSA -noprompt -trustcacerts

You can check the result with the following keytool command:

keytool -list -keystore [PATH TO KEYSTORE]

You should get similar results to those below:

Your keystore contains 1 entry
jboss, May 17, 2012, trustedCertEntry,
Certificate fingerprint (MD5): 93:F2:F1:8B:EF:8A:E0:E3:D0:E7:69:BC:69:96:29:C1

Alternatively, the Jboss public key can be added to the Java keystore:

keytool -importcert -alias jboss -keystore JAVA_HOME/jre/lib/security/cacerts -storepass changeit -file JBOSS_HOME/bin/JBossPublicKey.RSA -noprompt -trustcacerts

If the system Java keystore is used, the password should be changed with the following command. This may affect the functioning of other applications using the system Java keystore.

keytool -storepasswd -keystore JAVA_HOME/jre/lib/security/cacerts

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:206101
File: eap5-ocil.xml

Establishing trust between clients and servers is an important part of information security. Presenting a valid X.509 certificate leverages the mutually-trusted DoD Public Key Infrastructure. Failure to present a valid DoD certificate undermines user confidence, presents an inconsistent user experience for security, and creates potential for abuse of trust by malicious entities.

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

Using a web browser or similar tool, access deployed JBoss applications that implement encryption and certificate exchange. Examine the X.509 certificate presented to the browser by the server. The certificate must meet the following requirements:

• The certificate must match the domain name of the webserver being accessed. This can be determined by comparing the DNS name used in the browser to the DNS name on the presented certificate.
• The certificate must not be expired. This can be determined by reviewing the expiration dates on the server's certificate.
• The certificate must be issued by a DoD approved Certificate Authority. This can be determined by examining the issuing hierarchy of the presented certificate. Valid Certificate Authorities can be found here: https://crl.gds.disa.mil/
• The certificate must not be revoked. This can be determined by enabling revocation checking on the web browser or manually reviewing the revocation list identified by the certificate.
• The certificate public key length must be at least 1024 bits.

The JBoss administrator must work with the local security manager and certificate registrar to successfully request a certificate from a DoD Certificate Authority.

Once a valid X.509 certificate has been obtained from a Certificate Authority within the DoD PKI, the certificate and associated private key can be installed in the JBoss keystore. The following example imports a PCKS12 public/private key pair into a Java Key Store.

keytool -importkeystore -v -srckeystore KEYSTORE.p12 -srcstoretype PKCS12 -keystore NEW_KEYSTORE.jks

The final step is to enable TLS on whichever Tomcat connector is used by the deployed application.

<Connector protocol="HTTP/1.1" SSLEnabled="true"
	port="8443" address="${jboss.bind.address}"
	scheme="https" secure="true" clientAuth="false"
	keystoreFile="${jboss.server.home.dir}/conf/NEW_KEYSTORE.jks"
	keystorePass="KEYSTORE_PASSWORD" sslProtocol = "TLS" />
				

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:400501
File: eap5-ocil.xml

Establishing trust between clients and servers is an important part of information security. Validating client X.509 certificates against the DoD Public Key Infrastructure leverages the enterprise trust system. Failure to validate client certificates undermines the enterprise trust infrastructure and makes the JBoss server vulnerable to trust abuse exploits.

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

Determine which keystore is being used by JBoss. Check for keystore definition lines within any .policy files loaded by the Java Security Manager to determine the path to the keystore. For example:

keystore "file:${JBoss.server.home.dir}/jboss.keystore";

List the contents of the keystore using the following command:

keytool -list -keystore [PATH TO KEYSTORE]

All currently active DoD Certificate Authorities must exist as trustedCertEntry. At the time of this writing, there were 39 separate Certificate Authorities controlled by DoD that should be trusted.

Download and install the DoD CA certificates. Currently, the CA certificates can be retrieved from https://crl.gds.disa.mil/.

The keys can be added to the keystore with a command similar to the following:

keytool -importcert -keystore [PATH TO KEYSTORE] -storepass [KEYSTORE PASSWORD] -file [PATH TO CERTIFICATE] -noprompt -trustcacerts

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:400601
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

There are many options for implementing this rule on deployed applications. Authentication using DoD's PKI can be accomplished using JBoss itself, the webserver underneath JBoss, or a traffic aggregator in front of JBoss. This rule focuses on configuration of JBoss to authenticate users with a PKI. This rule requires multiple steps to validate.

First, determine if authentication is required by the deployed application. Review the deployed application's jboss-web.xml (JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/) file to ensure that a security domain has been referenced. For example:

<security-domain>java:/jaas/JBossTestRealm</security-domain>

Next, review the deployed application's web.xml (JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/) file to ensure that resources within the web application have been identified to be secured. The <auth-method> element MUST contain CLIENT-CERT in order to implement certificate-based authentication. For example:

<security-constraint>
	<web-resource-collection>
		<web-resource-name>TestResource</web-resource-name>
		<url-pattern>/*</url-pattern>
	</web-resource-collection>
	<auth-constraint>
		<role-name>JBossTestRole</role-name>
	</auth-constraint>
</security-constraint>
	
<login-config>
	<auth-method>CLIENT-CERT</auth-method>
	<realm-name>Test realm</realm-name>
</login-config>

<security-role>
	<role-name>JBossTestRole</role-name>
</security-role>

Next, ensure that an <application-policy> element is defined that matches the <security-domain> referenced by the jboss-web.xml file. These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

• JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

Check the <application-policy> element to ensure it has modules defined for authentication. This <login-module> MUST contain the following attributes:

• code="org.jboss.security.auth.spi.BaseCertLoginModule"
• flag="required"

Example of a satisfactory element:

<application-policy name="JBossTestRealm">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">testUsers.properties</module-option>
			<module-option name="rolesProperties">testRoles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>

Additional modules can be included to shape the exact functionality desired. For example, <module>s such as SubjectCNMapping can be included to perform attribute mapping.

Finally, the client certificate's Distinguished Name field must be mapped to a certificate alias stored in the a keystore. The keystore will be defined in the JaasSecurityDomain MBean. For example:

<mbean code="org.jboss.security.plugins.JaasSecurityDomain" name="jboss.ch8:service=SecurityDomain">
	<constructor>
		<arg type="java.lang.String" value="JBossTestRealm"/>
	</constructor>
	<attribute name="KeyStoreURL">resource:localhost.keystore</attribute>
	<attribute name="KeyStorePass">cleartext-password-that-should-be-masked</attribute>
</mbean>

First, setup an <application-policy> that enforces certificate-based authentication. This can be accomplished in the following files:

• JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

The <application-policy> should resemble the example below:

<application-policy name="JBossTestRealm">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">testUsers.properties</module-option>
			<module-option name="rolesProperties">testRoles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>

Next, add the <application-policy> to the deployment descriptors and setup the <security-constraint>.

JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml

<security-domain>java:/jaas/JBossTestRealm</security-domain>

JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/web.xml

<security-constraint>
	<web-resource-collection>
		<web-resource-name>TestResource</web-resource-name>
		<url-pattern>/*</url-pattern>
	</web-resource-collection>
	
	<auth-constraint>
		<role-name>JBossTestRole</role-name>
	</auth-constraint>
</security-constraint>
					
<login-config>
	<auth-method>CLIENT-CERT</auth-method>
	<realm-name>Test realm</realm-name>
</login-config>
					
<security-role>
	<role-name>JBossTestRole</role-name>
</security-role>

Define a keystore to be used via the JaasSecurityDomain MBean:

JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/jboss-service.xml:

<mbean code="org.jboss.security.plugins.JaasSecurityDomain" name="jboss.ch8:service=SecurityDomain">
	<constructor>
		<arg type="java.lang.String" value="JBossTestRealm"/>
	</constructor>
	
	<attribute name="KeyStoreURL">resource:test.keystore</attribute>
	<attribute name="KeyStorePass">cleartext-password-that-should-be-masked</attribute>
</mbean>

Finally, import the client certificates into the keystore using the keytool command. For example:

keytool -importcert -alias "DN ON THE CERTIFICATE" -keystore JBOSS_HOME/server/[PROFILE]/conf/test.keystore -file [PATH TO CERTIFICATE]

1. JBoss Enterprise Application Platform Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:400701
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 4.0 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-13

DoD 8500.2 Mapping: DCNR-1,ECCR-1,ECCR-2,ECCR-3,ECCT-1,ECCT-2,ECNK-1,ECNK-2

Validating this rule is a multi-step process.

1. First, ensure that the FIPS compliant providers are enabled in the Java security files.

   For IBM JRE/JDK 6.x:

   Check for the following provider in the JAVA_HOME/jre/lib/security/java.security file:

   • security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPS

   NOTE: The FIPS compliant provider MUST be at the top of the list as #1.

   Ensure the following line exists in the System.Defaults properties file:

   • com.ibm.jsse2.usefipsprovider=true

   Finally, ensure the following two properties are defined in JAVA_HOME/jre/lib/security/java.security:

   • ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl
   • ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl

   For Sun JRE/JDK 6.x:

   Check for the following providers in the JAVA_HOME/jre/lib/security/java.security file:

   • security.provider.1=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS

   NOTE: The FIPS compliant provider MUST be at the top of the list as #1

   Next, review the application source code to ensure that the proper constructors are utilized for FIPS compliant algorithms. Review the constructor used to initialize SunJSSE and ensure that the FIPS compliant mode has been enabled.

2. Lastly, perform a packet capture of the TLS handshake to ensure that only FIPS 140-2 algorithms are selected by the server (ServerHello message).

As this check is not specific to JBoss, validation steps will vary dependent on the Java vendor in use.

For IBM JRE/JDK 6.x:

Add the following provider to the JAVA_HOME/jre/lib/security/java.security file:

• security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPS

NOTE: There will be a list of several providers already in place, numbered 1 to X. The FIPS compliant providers MUST go at the top of the list as #1 and #2. The other providers must be re-numbered.

Ensure the following line exists in the System.Defaults properties file:

• com.ibm.jsse2.usefipsprovider=true

Finally, ensure the following two properties are defined in JAVA_HOME/jre/lib/security/java.security:

• ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl
• ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl

For Sun JRE/JDK 6.x:

Add the following provider to the JAVA_HOME/jre/lib/security/java.security file:

• security.provider.1=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS

NOTE: There will be a list of several providers already in place, numbered 1 to X. The FIPS compliant provider MUST go at the top of the list as #1. The other providers must be re-numbered.

Now the deployed applications must be written to take advantage of the FIPS enabled providers. The Sun SunJSSE provider must be initialized at run-time with the FIPS boolean value as true.

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:400801
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 3.7 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-28

DoD 8500.2 Mapping: ECCR-1,ECCR-2,ECCR-3

Review data source file located within JBOSS_HOME/server/deploy/ and subdirectories. Data sources with encrypted passwords will no longer have <user-name> or <password> elements, and will instead reference a <security-domain>.

Following the extensive instructions located within Chapter 17, "Encrypting Data Source Passwords" of the JBoss Enterprise Application Platform 5 Security Guide, 2011. While too lengthy to contain here, the summarized steps include:

• Encrypt the data source password.
• Create an application authentication policy with the encrypted password.
• Configure the data source to use the application authentication policy.

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:113601
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 3.7 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-28

DoD 8500.2 Mapping: ECCR-1,ECCR-2,ECCR-3

Review JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml for evidence of clear-text passwords in Connectors. These Connectors will contain a <attribute name="KeyStorePass"> or a keystorePass attribute as part of the <Connector> element, with a clear-text password.

Following the extensive instructions located within Chapter 18, "Encrypting the Keystore Password in a Tomcat Connector" of the JBoss Enterprise Application Platform 5 Security Guide, 2011. While too lengthy to contain here, the summarized steps include:

• Configure JaasSecurityDomain MBean
• Generate encrypted password
• Update the Tomcat service MBean

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:116301
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 3.7 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-28

DoD 8500.2 Mapping: ECCR-1,ECCR-2,ECCR-3

Review configuration files for evidence of clear-text passwords. No clear-text passwords should exist in XML configuration files (password masking should be used instead).

Follow the extensive instructions located within Chapter 16, "Masking Passwords in XML Configuration" of the JBoss Enterprise Application Platform 5 Security Guide, 2011. These instructions are too lengthy to summarize here.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
2. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:116501
File: eap5-ocil.xml

The SuckerPassword ships with a default clear-text password that can be used by attackers to pass messages to default installations of Jboss. The exact content and ramifications of these messages will depend on the listening applications (application logic, input validations, etc.). Failure to change this password can allow an attacker to create connections and pass messages to nodes.

CVSSv2 Risk Assessment: 7.5 / High - CVSSv2 Formula: (AV:N/AC:L/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT I

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

Review the Jboss Messaging configuration file for the Messaging ServerPeer located here:

Ensure the <property name="suckerPassword" > has been changed from the default of "CHANGE ME!".

Open the Jboss Messaging configuration file for the Messaging ServerPeer located here:

Locate the element <property name="suckerPassword" > and change the contents to a new password generated in accordance with your organization's password security requirements, restricting the use of predefined XML entities such as <'>@" or escaping them if you do. For example:

<property name="suckerPassword" >Lmf3SdntiDFF6(D5</property>

The encrypted version of this password can be added to JBOSS_HOME/server[PROFILE]/deploy/messaging/messaging-service.xml by following the directions located in Follow the extensive instructions located within Chapter 16, "Masking Passwords in XML Configuration" of the JBoss Enterprise Application Platform 5 Security Guide, 2011.

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:400201
File: eap5-ocil.xml

To prevent compromise of the server's X.509 trust chains, the well-known default password on the cacerts keystore should be changed. Failure to change this password could lead to the malicious modification of trusted X.509 CA's.

This would allow attackers to create connections as trusted entities, sign malicious could as a trusted entity, or create any other number of X.509 certificate abuses.

CVSSv2 Risk Assessment: 2.6 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:N)

DoD Risk Category: CAT III

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

Attempt to access the contents of the Java cacerts keystore at the default location using the following command:

keytool -list -keystore JAVA_HOME/lib/security/cacerts

If the cacerts file cannot be found in your JAVA_HOME/lib/security/, try searching the system for the file named cacerts located in the Java install path.

You should be prompted for a password (non-blank). Attempt to authenticate using the default password 'changeit'

If you fail to authenticate, you will receive a warning message (and the contents of the keystore will still be displayed):

***************** WARNING WARNING WARNING *****************

* The integrity of the information stored in your keystore *

* has NOT been verified! In order to verify its integrity, *

* you must provide your keystore password. *

***************** WARNING WARNING WARNING *****************

Using the default password 'changeit' should fail to authenticate and thus produce the warning. If the default password successfully authenticates, this check fails.

Add a password to the default Java cacerts keystore:

keytool -storepasswd -keystore [PATH TO KEYSTORE]

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:400301
File: eap5-ocil.xml

Enabling the Security Audit Appender is a necessary component of comprehensive auditing in a secure production environment.

CVSSv2 Risk Assessment: 4 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AU-12

DoD 8500.2 Mapping: ECAT-1,ECAT-2

Ensure the Security Audit Appender is defined within JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml. By default, the Security Audit Appender exists and just needs to be uncommented.

<!-- Security AUDIT Appender -->
<appender name="AUDIT" class="org.jboss.logging.appender.DailyRollingFileAppender">
	<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
	<param name="File" value="${JBoss.server.log.dir}/audit.log"/>
	<param name="Append" value="true"/>
	<param name="DatePattern" value="'.'yyyy-MM-dd"/>
	<layout class="org.apache.log4j.PatternLayout">
		<param name="ConversionPattern" value="%d %-5p [%c] (%t:%x) %m%n"/>
	</layout>
</appender>

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:201901
File: eap5-oval.xml

Enabling the Security Audit Provider category is a necessary component of comprehensive auditing in a secure production environment.

CVSSv2 Risk Assessment: 4 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AU-12

DoD 8500.2 Mapping: ECAT-1,ECAT-2

Ensure the Security Audit Provider category is defined within JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml. By default, the Security Audit Provider category exists and just needs to be uncommented.

<!-- Category specifically for Security Audit Provider -->
<category name="org.jboss.security.audit.providers.LogAuditProvider" additivity="false">
	<priority value="TRACE"/>
	<appender-ref ref="AUDIT"/>
</category>

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:202001
File: eap5-oval.xml

Enabling TRACE priority logging on the SecurityInterceptor class is a necessary component of comprehensive auditing in a secure production environment.

CVSSv2 Risk Assessment: 4 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AU-12

DoD 8500.2 Mapping: ECAT-1,ECAT-2

Ensure a category is defined for SecurityInterceptor class with a priority of TRACE within JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml.

<category name="org.jboss.ejb.plugins.SecurityInterceptor">
	<priority value="TRACE" />
	<appender-ref ref="AUDIT" />
</category>

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:202101
File: eap5-oval.xml

Logging Microcontainer bootstrap operations is a necessary component of comprehensive auditing in a secure production environment.

CVSSv2 Risk Assessment: 4 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AU-3,AU-12

DoD 8500.2 Mapping: ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECAT-1,ECAT-2

Set the priority and appender-ref levels for the Microcontainer bootstrap by adding the <category> block as specified to JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml.

<category name="org.jboss.bootstrap.microcontainer">
	<priority value="INFO"/>
	<appender-ref ref="AUDIT"/>
</category>

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:202201
File: eap5-oval.xml

If application owners determine that additional logging of web-based requests is desired, it should be enabled.

CVSSv2 Risk Assessment: 4 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AU-3,AU-12

DoD 8500.2 Mapping: ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECAT-1,ECAT-2

If logging of web-based requests has been required for deployed applications the AccessLogValve should be enabled. To check the status of the <Valve>, ensure the following element is defined within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml.

<Valve className="org.apache.catalina.valves.AccessLogValve" prefix="localhost_access_log." suffix=".log" pattern="common" directory="${JBoss.server.home.dir}/log" resolveHosts="false" />

Ensure the following <Valve> exists within: JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. By default, this <Valve> simply needs to be uncommented.

<Valve className="org.apache.catalina.valves.AccessLogValve" prefix="localhost_access_log." suffix=".log" pattern="common" directory="${JBoss.server.home.dir}/log" resolveHosts="false" />

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:202301
File: eap5-ocil.xml

Logging full event information to the Security Audit Appender is a necessary component of comprehensive auditing in a secure production environment.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: AU-12

DoD 8500.2 Mapping: ECAT-1,ECAT-2

Enable server startup and shutdown events by making the following change to JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml. Update the ConversionPattern parameter in the Security Audit Appender to show thread information by replacing the default ConversionPattern with the pattern below:

<!--The full pattern: Date MS Priority [Category] (Thread:NDC) Message -->
<layout class="org.apache.log4j.PatternLayout">
	<param name="ConversionPattern" value="%d %-5r %-5p [%c] (%t:%x) %m%n"/>
</layout>

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:202401
File: eap5-oval.xml

Logging to console is a potentially resource intensive activity that should be disabled in production environments. Additionally, disabling console logging removes a potential source of information leakage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: AU-9

DoD 8500.2 Mapping: ECTB-1,ECTP-1

In order to prevent JBoss from logging to console, open the JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml file. Next, remove or comment out the <appender-ref> element with a ref attribute value of 'CONSOLE'. This <appender-ref> element will be a child of the <root> element, typically located near the end of the document.

<root>
<!--Set the root logger priority via a system property. Note this is parsed by log4j,
so the full JBoss system property format is not supported; e.g.
setting a default via ${jboss.server.log.threshold:WARN} will not work.-->
	<priority value="${jboss.server.log.threshold}"/>
		<!-- appender-ref ref="CONSOLE"/ -->
	<appender-ref ref="ASYNC"/>
</root>

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:110301
File: eap5-oval.xml

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.

CVSSv2 Risk Assessment: 5.1 / Medium - CVSSv2 Formula: (AV:N/AC:H/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-6

DoD 8500.2 Mapping: ECLP-1

Work with the JBoss administrator to identify the JBoss process owner account. Determine if the account is local to the host operating system or is elsewhere in the environment. On Red Hat or Linux systems look for a service definition for JBoss within /etc/init.d/. On Windows systems, check for a service definition within the Services console (services.msc). Assuming JBoss is running, either operating system can also determine the JBoss process owner by examining the currently executing process.

Next, work with the JBoss administrator to identify the permissions the JBoss process owner executes with. This procedure will vary based on the host operating system. On Red Hat or Linux systems, check the group membership for the account. On Windows systems, review the User Rights Assignments within the Local Security Policy console (secpol.msc).

This check fails if the JBoss process owner is not executing with least privileges. The following list identifies common scenario failures:

• The JBoss process owner is a privileged account such as root or administrator.
• The JBoss process owner is a member of a privileged group, such wheel, root, administrators, power users, domain admins, backup operators, etc.
• The JBoss process owner is used by multiple applications via use of username and password or group membership.
• The JBoss process owner account has unnecessary network access to other operating systems or other network nodes, typically through the use of a directory based account with no logon restrictions.

Steps for implementing this configuration will vary dependent upon operating system. On Red Hat or Linux systems, use /etc/group and /etc/passwd to assign the JBoss process owner a unique local account and group (and limit its group membership). Windows systems can create local accounts through the Computer Management console (compmgmt.msc) and User Rights Assignments managed through the Local Security Policy console (secpol.msc)..

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:400401
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 4.1 / Medium - CVSSv2 Formula: (AV:L/AC:M/Au:S/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-6

Steps for validating this configuration will vary, dependent upon operating system:

Red Hat Enterprise Linux: Interview JBoss administrators or review running processes with ps to identify the JBoss process owner account. Next, review the /etc/passwd file to ensure that the JBoss process owner account is not assigned a login shell (the shell field should read /sbin/nologin).

Windows: Interview JBoss administrators, review the configured JBoss service, review running process with WMI or task manager to identify the JBoss process owner account. Next, using Local Security Policy Microsoft Management Console or Resultant Set of Policy MMC, ensure the JBoss process owner account has been added to the 'Deny logon locally' security policy and 'Deny log on through Remote Desktop Services' security policy.

Steps for implementing this configuration will vary, dependent upon operating system:

Red Hat Enterprise Linux: To prevent users from gaining interactive access to the system console, simply ensure that they are assigned no shell interpreter via the /etc/passwd file. For instance, a properly configured passwd entry for the JBoss account owner may resemble this:

jboss:x:494:494:JBossAS:/var/lib/jbossas:/sbin/nologin

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
2. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:109901
File: eap5-ocil.xml

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

CVSSv2 Risk Assessment: 3.7 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

Validate file ownership for JBOSS_HOME files and subdirectories . Owner is required to be the JBoss process owner account. The JBoss administrators may have group ownership for operating systems that support it.

Use the ls command to ensure the JBoss process owner owns all JBoss configuration files (JBOSS_HOME and subdirectories); JBoss administrators should be the group owners.

Steps for implementing this configuration will vary, dependent upon operating system.

On Red Hat and Linux, use chown to ensure the JBoss process owner owns all JBoss configuration files (JBOSS_HOME and subdirectories); JBoss administrators may be the group owners.

Windows environments can use the explorer GUI or cacls/xcacls to ensure the JBoss process owner owns all JBoss configuration files (JBOSS_HOME and subdirectories).

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:116201
File: eap5-ocil.xml

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

CVSSv2 Risk Assessment: 4.3 / Medium - CVSSv2 Formula: (AV:L/AC:L/Au:S/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3,AC-6

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1

Validate file permissions for JBOSS_HOME files and subdirectories. File permissions should be restricted to READ/WRITE for JBoss process owner and JBoss administrators. Other accounts that may require READ access include version control accounts or process owners for backup software.

Red Hat Enterprise Linux: Use the ls command to check basic file permissions. The getfacl command can be useful as well.

Steps for implementing this configuration will vary, dependent upon operating system.

Red Hat Enterprise Linux: Use chmod to restrict permissions on files to at least 660 for all files in JBOSS_HOME and subdirectories.

Windows environments can use the explorer GUI or cacls/xcacls to restrict permissions for all files in JBOSS_HOME and subdirectories.

File permissions should be restricted to READ/WRITE for JBoss process owner and JBoss administrators. Other accounts that may require READ access include version control accounts or process owners for backup software.

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:109801
File: eap5-ocil.xml

The JMX Console should require authentication or be removed. Failure to require authentication may allow unauthenticated users to invoke commands or gather information on the JBoss server. This access can be leveraged to do many things, including loading additional code from a malicious source.

CVSSv2 Risk Assessment: 8 / High - CVSSv2 Formula: (AV:N/AC:L/Au:S/C:P/I:P/A:C)

DoD Risk Category: CAT I

NIST 800.53 Mapping: AC-3

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

This rule can be checked for compliance by either:

1. Determine the console is not deployed.
1. To determine if the JMX Console is deployed, check to see if the exploded WAR located is located here: JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/
2. If the console is deployed, it must require authentication. Review the defined <security-domain> for the console.
1. To determine if authentication is required, first check the JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain has been referenced (example: <security-domain>java:/jaas/jmx-console</security-domain>).
2. Next, ensure that an <application-policy> element is defined that matches the <security-domain> referenced by the jboss-web.xml file. These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.
   • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/META-INF/*-jboss-beans.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/*-jboss-beans.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml
3. Check the <application-policy> element to ensure it requires authentication. Example of a satisfactory element:

   <application-policy name="jmx-console">
   	<authentication>
   		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
   			<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
   			<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
   		</login-module>
   	</authentication>
   </application-policy>

This rule can be made compliant by either:

1. Require authentication for access to the JBoss JMX Console.
1. First, ensure that an <application-policy> element is defined that requires authentication. Default policies exist for jmx-console and web-console. Example of a satisfactory element:

   <application-policy name="jmx-console">
   	<authentication>
   		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
   			<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
   			<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>	
   		</login-module> 
   	</authentication> 
   </application-policy>

   These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

   JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
   JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/META-INF/*-jboss-beans.xml
   JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/*-jboss-beans.xml
   JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

2. Next, check the JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain requiring authentication has been referenced (example: <security-domain>java:/jaas/jmx-console</security-domain>). If no <security-domain> element exists, add it as a child of <jboss-web>.
3. Next, review the JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/web.xml. The <security-constraint> must not contain the default limitations on HTTP verbs. For example: <http-method>GET</http-method> or <http-method>POST</http-method>. The default limitations were shown to allow side channel access to malicious users.
4. Finally, configure the usersProperties defined in the application policy to manage accounts. Example editing JBOSS_HOME/server/[PROFILE]/conf/props/jmx-console-users.properties:
   

   # A sample users.properties file for use with the UsersRolesLoginModule
   admin=1qaz!QAZ2wsx@WSX

2. Remove the JBoss JMX Console from deployment.
1. To remove the JMX Console from deployment, delete the exploded WAR located here: JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:200601
File: eap5-oval.xml

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.

CVSSv2 Risk Assessment: 8 / High - CVSSv2 Formula: (AV:N/AC:L/Au:S/C:P/I:P/A:C)

DoD Risk Category: CAT I

NIST 800.53 Mapping: AC-3

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

This rule can be checked for compliance by either:

1. Determine the console is not deployed.
1. To determine if the Web Console is deployed, check to see if the exploded SAR located is located here: JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/
2. If the console is deployed, it must require authentication. Review the defined <security-domain> for the console.
1. To determine if authentication is required, first check the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain has been referenced (example: <security-domain>java:/jaas/web-console</security-domain>).
2. Next, ensure that an <application-policy> element is defined that matches the <security-domain> referenced by the jboss-web.xml file. These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.
   • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/META-INF/*-jboss-beans.xml
   • JBOSS_HOME/server/[PROFILE]/deploy//management/console-mgr.sar/web-console.war/WEB-INF/*-jboss-beans.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml
3. Check the <application-policy> element to ensure it requires authentication. Example of a satisfactory element:

   <application-policy name="web-console">
   	<authentication>
   		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
   			<module-option name="usersProperties">web-console-users.properties</module-option>
   			<module-option name="rolesProperties">web-console-roles.properties</module-option>
   		</login-module>
   	</authentication>
   </application-policy>

This rule can be made compliant by either:

1. Require authorization for access to the JBoss Web Console.
1. First, ensure that an <application-policy> element is defined that requires authentication. Default policies exist for jmx-console and web-console. Example of a satisfactory element:

   <application-policy name="web-console">
   	<authentication>
   		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
   			<module-option name="usersProperties">web-console-users.properties</module-option>
   			<module-option name="rolesProperties">web-console-roles.properties</module-option>
   		</login-module>
   	</authentication>
   </application-policy>

   These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

   • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/META-INF/*-jboss-beans.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/*-jboss-beans.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml
2. Next, check the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain requiring authentication has been referenced (example: <security-domain>java:/jaas/web-console</security-domain>). If no <security-domain> element exists, add it as a child of <jboss-web>.
3. Next, review the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml. The <security-constraint> must not contain the default limitations on HTTP verbs. For example: <http-method>GET</http-method> or <http-method>POST</http-method>. The default limitations were shown to allow sidechannel access to malicious users.
4. Finally, configure the usersProperties and rolesProperties files defined in the application policy to manage users and roles. Example editing JBOSS_HOME/server/[PROFILE]/conf/props/web-console-users.properties:

   # A sample users.properties file for use with the UsersRolesLoginModule
   admin=1qaz!QAZ2wsx@WSX

2. Remove the JBoss Web Console from deployment.
1. To remove the Web Console from deployment, delete the exploded SAR located here: JBOSS_HOME/server/[PROFILE]/deploy/management/

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:200701
File: eap5-oval.xml

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.

CVSSv2 Risk Assessment: 8 / High - CVSSv2 Formula: (AV:N/AC:L/Au:S/C:P/I:P/A:C)

DoD Risk Category: CAT I

NIST 800.53 Mapping: AC-3

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

This rule can be checked for compliance by either:

1. Determine the console is not deployed.
1. To determine if the Administration Console is deployed, check to see if the exploded WAR located is located here: JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/
2. If the console is deployed, it must require authentication. Review the defined <security-domain> for the console.
1. To determine if authentication is required, first check the JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain has been referenced (example: <security-domain>java:/jaas/jmx-console</security-domain>).
2. Next, ensure that an <application-policy> element is defined that matches the <security-domain> referenced by the jboss-web.xml file. These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.
   • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/META-INF/*-jboss-beans.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/*-jboss-beans.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml
3. Check the <application-policy> element to ensure it requires authentication. Example of a satisfactory element (this example leverages the pre-existing jmx-console policy):

   <application-policy name="jmx-console">
   	<authentication>
   		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
   			<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
   			<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
   		</login-module>
   	</authentication>
   </application-policy>

4. Finally, review the JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/web.xml. The <security-constraint> must not contain the default limitations on HTTP verbs. For example: <http-method>GET</http-method> or <http-method>POST</http-method>. The default limitations were shown to allow sidechannel access to malicious users.

This rule can be made compliant by either:

1. Require authorization for access to the JBoss Administration Console.
1. First, ensure that an <application-policy> element is defined that requires authentication. Default policies exist for jmx-console and web-console. Example of a satisfactory element:

   <application-policy name="jmx-console">
   	<authentication>
   		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
   			<module-option name="usersProperties">web-console-users.properties</module-option>
   			<module-option name="rolesProperties">web-console-roles.properties</module-option>
   		</login-module>
   	</authentication>
   </application-policy>

   These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

   • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/META-INF/*-jboss-beans.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/*-jboss-beans.xml
   • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml
2. Next, check the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain requiring authentication has been referenced (example: <security-domain>java:/jaas/web-console</security-domain>). If no <security-domain> element exists, add it as a child of <jboss-web>.
3. Next, review the JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/web.xml. The <security-constraint> must not contain the default limitations on HTTP verbs. For example: <http-method>GET</http-method> or <http-method>POST</http-method>. The default limitations were shown to allow sidechannel access to malicious users.
4. Finally, configure the usersProperties and rolesProperties files defined in the application policy to manage users and roles. Example editing JBOSS_HOME/server/[PROFILE]/conf/props/jmx-console-users.properties:

   # A sample users.properties file for use with the UsersRolesLoginModule
   admin=1qaz!QAZ2wsx@WSX

2. Remove the JBoss Administration Console from deployment.
1. To remove the Administration Console from deployment, delete the exploded SAR located here: JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:200801
File: eap5-oval.xml

Removing the default <http-method> security constraints allows JBoss to apply configured security settings to all HTTP verbs instead of only those specified. This is a well-known attack vector and failing to remove these constraints may allow attackers to gain authenticated or unauthorized access to the JMXInvokerServlet.

CVSSv2 Risk Assessment: 8.3 / High - CVSSv2 Formula: (AV:N/AC:M/Au:N/C:P/I:P/A:C)

DoD Risk Category: CAT I

NIST 800.53 Mapping: AC-3

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

Review JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar/invoker.war/WEB-INF/web.xml to ensure the following lines have been removed:

<http-method>GET</http-method>
<http-method>POST</http-method>

Within the JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar/invoker.war/WEB-INF/web.xml file, the following lines must be removed from the web-app/security-constraint/web-resource-collection node:

<http-method>GET</http-method>
<http-method>POST</http-method>

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:202901
File: eap5-oval.xml

The JMXInvokerServlet should require authentication. Failure to require authentication may allow unauthenticated users to invoke commands on the JBoss server. This access can be leveraged to do many things, including loading additional code from a malicious source.

CVSSv2 Risk Assessment: 8.3 / High - CVSSv2 Formula: (AV:N/AC:M/Au:N/C:P/I:P/A:C)

DoD Risk Category: CAT I

NIST 800.53 Mapping: IA-2,IA-3

DoD 8500.2 Mapping: EBRU-1,IAIA-1,IAIA-2,IAGA-1

Open JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml, and ensure the <operation> element with child element <name>invoke</name> also contains the following <interceptor>:

<interceptors>
	<interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
</interceptors>

Next, ensure a valid authentication module is enabled for the security domain. For example, the following elements exist within logon-config.xml and implement authentication using the UsersRolesLoginModule:

<application-policy name="jmx-console">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
			<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>

NOTE: By default, this forces the invoker to authenticate against the jmx-console-users.properties file, located here: JBOSS_HOME/server/PROFILE/conf/prop/
NOTE: The securityDomain does not have to be called jmx-console.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:203001
File: eap5-oval.xml

The JMXInvokerServlet should require authorization. Failure to require authorization may allow unauthenticated users to invoke commands on the JBoss server. This access can be leveraged to do many things, including loading additional code from a malicious source.

CVSSv2 Risk Assessment: 8.3 / High - CVSSv2 Formula: (AV:N/AC:M/Au:N/C:P/I:P/A:C)

DoD Risk Category: CAT I

NIST 800.53 Mapping: AC-3,AC-6

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1

Open JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml, and ensure the <operation> element with child element <name>invoke</name> also contains the following <interceptor>:

<interceptors>
	<interceptor code="org.jboss.jmx.connector.invoker.AuthorizationInterceptor" authorizingClass="org.jboss.jmx.connector.invoker.RolesAuthorization"/>
</interceptors>

Next, ensure a valid authorization module is enabled for the security domain. For example, the following elements exist within logon-config.xml and implement authorization using the UsersRolesLoginModule:

<application-policy name="jmx-console">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
			<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>

NOTE: By default, this forces the invoker to authenticate against the jmx-console-users.properties file, located here: JBOSS_HOME/server/PROFILE/conf/prop/
NOTE: The securityDomain does not have to be called jmx-console.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:203101
File: eap5-oval.xml

Failing to provide adequate notification of system use details to users accessing the system can create legal troubles in the event of a civil lawsuit or criminal investigation.

CVSSv2 Risk Assessment: 2.0 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: AC-8

DoD 8500.2 Mapping: ECWM-1

Access all deployed applications to determine if a warning banner is displayed. A code review showing the functional code will also suffice.

This warning banner should be presented to the user prior to accessing any deployed application - commercial applications, in-house applications, or applications deployed by JBoss.

Create a system use notification message for all users who access the system. This can be done in a variety of ways, but a simple JavaScript alert(); containing a warning message will suffice. This warning banner should be presented to the user prior to accessing any deployed application - commercial applications, in-house applications, or applications deployed by JBoss. The contents of the system use notification should be clear, concise, in keeping with the organizational security policy, and should have been reviewed by the organization's legal team.

On DoD systems, the warning banner should read:

You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests—not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:300601
File: eap5-ocil.xml

Prominent classification banners reduce the risk of inadvertent information disclosure or data spillage across different classification levels.

CVSSv2 Risk Assessment: 2.0 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: AC-8

DoD 8500.2 Mapping: ECWM-1

Access all deployed applications to determine if classification banners are displayed in accordance with the authoritative classification guide or local security policies. A code review showing the functional code will also suffice.

These classification banners should be presented to the user on all deployed applications - commercial applications, in-house applications, and even default applications deployed by JBoss. The exact banner requirements such as text, color, and placement will vary dependent on the system classification. See the classification guide or local security manager for further guidance.

Create system classification banners for all deployed applications. This can be done in a variety of ways, but using a simple linked JavaScript to create header/footer SPAN tags with inline CSS will fit the requirements.

1. Department of Defense, (1997). Information Security Program (DoD 5200.1-R)

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:300701
File: eap5-ocil.xml

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

CVSSv2 Risk Assessment: 4.3 / Medium - CVSSv2 Formula: (AV:A/AC:M/Au:N/C:P/I:P/A:N)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-8,SC-9

DoD 8500.2 Mapping: ECTM-1,ECTM-2,ECCT-1,ECCT-2,ECNK-1,ECNK-2

To determine which <application-policy> are in use by deployed applications, search for <security-domain> elements within the following deployment descriptors:

JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml
JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss.xml

An <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

• JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

The element below should be included within a deployed application's <application-policy><login-module>:

<module-option name="hashUserPassword">true</module-option>

Add the following child element to any <application-policy><login-module> in use:

<module-option name="hashUserPassword">true</module-option>

An <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

• JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:201501
File: eap5-ocil.xml

By default, a hashing algorithm is not identified for hashing clear-text passwords. DoD organizations should use the SHA algorithm or higher whenever possible to prevent collision attacks against captured password hashes.

CVSSv2 Risk Assessment: 4.3 / Medium - CVSSv2 Formula: (AV:A/AC:M/Au:N/C:P/I:P/A:N)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-8,SC-9

DoD 8500.2 Mapping: ECTM-1,ECTM-2,ECCT-1,ECCT-2,ECNK-1,ECNK-2

To determine which <application-policy> are in use by deployed applications, search for <security-domain> elements within the following deployment descriptors:

JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml
JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss.xml

An <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

• JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

The element should be included within a deployed application's <application-policy><login-module>:

<module-option name="hashAlgorithm">SHA</module-option> 

Add the following child element to any <application-policy><login-module> in use:

<module-option name="hashAlgorithm">SHA</module-option>

An <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

• JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:201701
File: eap5-ocil.xml

Deployed applications should follow identified standards, procedures, and best practices. Compliance has many benefits, including helping applications stay interoperable with other programs and containers, implementing strong security and code standards, and improving performance and efficiency.

CVSSv2 Risk Assessment: 6 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Interview developers or review product documentation to determine if deployed applications were developed in accordance with Enterprise JavaBeans 2.1 specifications. The list below denotes the restrictions identified by the specification.

• An enterprise bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.
• An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances.
• An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.
• An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
• An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.
• The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language. The enterprise bean must not attempt to use the Reflection API to access information that the security rules of the Java programming language make unavailable.
• The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.
• The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.
• The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.
• The enterprise bean must not attempt to directly read or write a file descriptor.
• The enterprise bean must not attempt to obtain the security policy information for a particular code source.
• The enterprise bean must not attempt to load a native library.
• The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language make unavailable to the enterprise bean.
• The enterprise bean must not attempt to define a class in a package.
• The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).
• The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.
• The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must pass the result of SessionContext.getEJBObject, Session-Context.getEJBLocalObject, EntityContext.getEJBObject,or Entity-Context.getEJBLocalObject instead.

Developers must follow Enterprise JavaBeans Specification v2.1.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:206801
File: eap5-ocil.xml

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

CVSSv2 Risk Assessment: 6.9 / High - CVSSv2 Formula: (AV:L/AC:M/Au:N/C:C/I:C/A:C)

DoD Risk Category: CAT I

NIST 800.53 Mapping: PE-1,PE-2,PE-3,PE-7,PE-18

DoD 8500.2 Mapping: PEPF-1,PEPF-2,PECF-1,PECF-2,PEPS-1,PEVC-1

Interview JBoss administrators and security personnel. Visually inspect physical security precautions. Review space certifications where appropriate.

Implement reasonable physical access controls to protect the hardware running and storing information for JBoss Enterprise Application Platform. Typically, these sorts of protections will include locked doors, locked server cabinets, security alarms, cameras, door guards, etc. What is considered 'reasonable' will scale with the importance of the JBoss server and the sensitivity of the information it processes.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:206201
File: eap5-ocil.xml

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

CVSSv2 Risk Assessment: 8 / High

DoD Risk Category: CAT I

NIST 800.53 Mapping: AT-2,AT-3,AT-4

DoD 8500.2 Mapping: PRTN-1,PETN-1

Interview JBoss administrators. Review credentials and qualifications. JBoss Administrators should possess a basic level of proficiency with the software.

Additionally, they must not be carelessly or willfully negligent, or hostile, and must follow the instructions provided by the administrator documentation.

Ensure a minimum level of competency / expertise has been established for JBoss administrators before granting them access to production systems.

Ensure documentation and procedures exist (and are followed) for routine administrative tasks.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:206301
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 6 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: IR-1,IR-8

DoD 8500.2 Mapping: VIIR-1,VIIR-2

Interview JBoss administrators. Review system documentation, incident response documentation, contingency documentation, and any other relevant documentation. Determine if the incident response procedures in place are robust, up-to-date, and clear.

Draft formal incident response policies and procedures. Utilize national and international standards such as ISO/IEC TR 18044 or NIST Special Publication 800-61.

1. Mallik, R. (2011, May). Jboss in the Trenches.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:112901
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 4 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: IR-3

DoD 8500.2 Mapping: VIIR-1,VIIR-2

Interview JBoss administrators. Review system documentation, incident response documentation, and any other relevant documentation. Review lessons-learned, after-action reports, or other historical documentation. Determine if the incident response procedures are meaningfully exercised at least annually.

Draft a schedule to ensure that documented procedures are exercised at least annually. More frequent exercises may be needed for some environments.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:113301
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 6 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CP-1,CP-2

DoD 8500.2 Mapping: CODP-1,CODP-2,CODP-3,COEF-1,COEF-2

Interview JBoss administrators. Review system documentation, disaster recovery documentation, contingency documentation, and any other relevant documentation. Determine if the disaster recovery procedures in place are robust, up-to-date, and feasible.

Draft formal disaster response policies and procedures. Utilize national and international standards such as ISO 17799 or NIST Special Publication 800-34.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:113201
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 4 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CP-4

DoD 8500.2 Mapping: DCSS-2,COED-1,COED-2

Interview JBoss administrators. Review system documentation, disaster recovery documentation, contingency documentation, and any other relevant documentation. Review lessons-learned, after-action reports, or other historical documentation. Determine if the disaster recovery procedures are meaningfully exercised at least annually.

Draft a schedule to ensure that documented procedures are exercised at least annually. More frequent exercises may be needed for some environments.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:113401
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 4.3 / Medium - CVSSv2 Formula: (AV:A/AC:M/Au:N/C:P/I:P/A:N)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-8,SC-9,SC-23

DoD 8500.2 Mapping: ECTM-1,ECTM-2

Examine application documentation, system architecture documentation, and any other pertinent diagrams. Interview JBoss administrators and application developers. Application data flows should be identified for all deployed applications, including the following information:

• Relevant protocol information (for instance, TCP traffic should record port information)
• Traffic destination
• Purpose
• Sensitivity of traffic
• Applicable security information, such as encryption types, specific vulnerabilities in transport or application protocols, etc.

Work with JBoss administrators and application developers to document data flows for deployed applications. Information documented should include:

• Relevant protocol information (for instance, TCP traffic should record port information)
• Traffic destination
• Purpose
• Sensitivity of traffic
• Applicable security information, such as encryption types, specific vulnerabilities in transport or application protocols, etc.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:113501
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-1

Review documentation for an application's permission requirements. Review policy files to determine if applications are in compliance with their documentation. In a default JBoss deployment the following policy file will be utilized by JSM (review run.conf or run.conf.bat for more):

• java.home/lib/security/java.security

Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)

The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.

Further, documentation should exist for all applications that have been granted specific permissions.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:115901
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 6 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CP-9

DoD 8500.2 Mapping: DCSW-1,COBR-1,CODB-1,CODB-2,CODB-3,COSW-1,DCWH-1

Interview JBoss administrators. Review backup policies, procedures, and other applicable documentation. Review backup media and validate presence of JBoss configuration files and deployed applications. Determine if JBoss configuration files and deployed applications are backed up at least once a week - or as specified by organization documentation.

Ensure backups are conducted regularly (at least once a week) in accordance with the organization backup-policy. All JBoss configuration files and deployed applications should be backed up.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:114601
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 4 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AU-1,AU-2,AU-3,AU-5

DoD 8500.2 Mapping: ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECND-2

Interview JBoss administrators. Review any available auditing documentation. Determine if the auditing policy is comprehensive and the auditing procedures are usable and up-to-date.

JBoss system administrators should work security team members to draft a comprehensive audit policy. Along with this auditing policy, a set of written procedures should be created that details what events or trends must be monitored, reactions, etc.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:115301
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-1

Interview JBoss administrators. Review all relevant documentation. Determine if an access control policy exists that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance. There should be an associated set of procedures with implementation details for specific tasks such as assigning user roles, creating user accounts, or assigning Java Security Manager permissions.

Draft an access control policy to address purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance. There should be an associated set of procedures with implementation details for specific tasks such as assigning user roles, creating user accounts, or assigning Java Security Manager permissions.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:116401
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 5.0 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

Work with JBoss administrators and security team members to identify and review relevant documentation. Minimum and maximum password lengths should be defined.

JBoss system administrators should work security team members to draft a comprehensive password policy. Minimum and maximum password lengths should be defined. Further, accounts may be categorized in order to define varying length requirements for particular types of accounts.

For example:

• User accounts shall require password lengths of between 8 and 24 characters
• Administrator shall require password lengths of 24 characters
• Web service accounts shall require password lengths of 24 characters

Password storage software and password generation software are recommended for organizations to assist in managing a secure password policy. NIST Special Publication 800-118 (Draft) and NIST Special Publication 800-53 both contain extensive guidance on creating a password policy document.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
2. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guide to Enterprise Password Management (Draft) (800-118). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:300301
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 5.0 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

Work with JBoss administrators and security team members to identify and review relevant documentation. Password complexity requirements should be defined. The policy should not allow passwords to be reused or contain dictionary words.

JBoss system administrators should work security team members to draft a comprehensive password policy. Password complexity requirements should be defined. The policy should not allow passwords to be reused or contain dictionary words. Further, accounts may be categorized in order to define varying complexity requirements for particular types of accounts.

For example:

• User accounts shall require passwords containing at least 1 lowercase alphanumeric character, 1 uppercase alphanumeric character, and 1 number
• Administrator accounts shall require passwords containing at least 2 lowercase alphanumeric characters, 2 uppercase alphanumeric characters, 2 numbers, and 2 special characters. Special characters include: !@#$%^&*()
• Web service accounts shall require passwords containing at least 3 lowercase alphanumeric characters, 3 uppercase alphanumeric characters, 3 numbers, and 3 special characters. Special characters include: !@#$%^&*()

Password storage software and password generation software are recommended for organizations to assist in managing a secure password policy. NIST Special Publication 800-118 (Draft) and NIST Special Publication 800-53 both contain extensive guidance on creating a password policy document.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
2. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guide to Enterprise Password Management (Draft) (800-118). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:300401
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 5.0 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

Work with JBoss administrators and security team members to identify and review relevant documentation. Password complexity requirements should be defined. The policy should not allow passwords to be reused or contain dictionary words.

JBoss system administrators should work security team members to draft a comprehensive password policy. Password expiration requirements should be defined. Further, accounts may be categorized in order to define varying length requirements for particular types of accounts.

For example:

• Passwords for user accounts must expire every 90 days
• Passwords for administrator accounts must expire every 30 days
• Passwords for web service accounts must expire every 180 days

Password storage software and password generation software are recommended for organizations to assist in managing a secure password policy. NIST Special Publication 800-118 (Draft) and NIST Special Publication 800-53 both contain extensive guidance on creating a password policy document.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
2. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guide to Enterprise Password Management (Draft) (800-118). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:300501
File: eap5-ocil.xml

Co-locating JBoss EAP with other critical infrastructure components in an organization can have multiple negative impacts on an organization's security posture. Applications sharing host operating systems cumulatively increase the surface area of attack for the other (including indirectly), increase the likelihood of resource contention, and increase the severity of any problems that do occur on the platform at a business process level.

CVSSv2 Risk Assessment: 5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Interview JBoss administrators, review system documentation and architecture diagrams. Review applications hosted by the same operating system as JBoss. Determine if JBoss Enterprise Application Platform installations are hosted on dedicated operating systems. JBoss installations should not be hosted by the same operating system that may be hosting other organization resources such as name resolution servers, directory servers, or database servers.

Installations of JBoss should reside on a dedicated operating system. If not, ensure the configuration, rationale, and risk assessment is well documented.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:400101
File: eap5-ocil.xml

Multiple JBoss instances on a single server may occasionally become necessary due to resource or design constraints. However, this practice increases the complexity and administrative burden for the application servers - potentially leading to unforeseen problems and increasing chance of misconfigurations.

CVSSv2 Risk Assessment: 5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Interview JBoss administrators, review system documentation and architecture diagrams. Determine if JBoss Enterprise Application Platform installations are limited to one per server. If they are not limited to one per server, ensure the configuration, rationale, and risk assessment is well documented.

Limit JBoss Enterprise Applications Platform instances to one per server if possible. If not, ensure the configuration, rationale, and risk assessment is well documented.

1. Mallik, R. (2011, May). Jboss in the Trenches.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:112401
File: eap5-ocil.xml

Binding to different IP addresses eases administrative and maintenance burdens by reducing the number of variables between instances. In turn, this increases reliability and reduces the chances for configuration errors.

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Interview JBoss administrators and review system documentation. Examine running JBoss servers and bound ports using commands like netstat. If multiple JBoss instances are deployed to a single server, it is a best practice to bind each instance to its own IP address.

If multiple JBoss Enterprise Application Platforms are deployed to a single server, the binding IP address can be specified at server startup using the -b argument to specify the binding IP. Example:

run.sh -c public -b 10.10.10.75

1. Mallik, R. (2011, May). Jboss in the Trenches.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:113101
File: eap5-ocil.xml

Packet filtering is a basic security technique for securing TCP/IP and UDP/IP communications.

CVSSv2 Risk Assessment: 9.3 / High - CVSSv2 Formula: (AV:N/AC:M/Au:N/C:C/I:C/A:C)

DoD Risk Category: CAT I

NIST 800.53 Mapping: SC-7

DoD 8500.2 Mapping: DCSS-2,EBBD-1,EBBD-2,EBBD-3,EBPW-1,ECID-1

Interview JBoss administrators and architects. Review system network diagrams. Work with JBoss administrators to review ipfilter rulesets to ensure the TCP/IP and UDP/IP packet filters are protecting the JBoss Enterprise Platform. The packet filters must only allow incoming communication that is TCP with destination ports of 8080 or 8443. This packet filter can be resident on the host operating system or a completely separate system entirely.

When JBoss Enterprise Application Platforms are clustered, all outgoing communication from the JBoss Enterprise Application Platform instance must be allowed.

Install and/or configure a TCP/IP and UDP/IP packet filtering device to logically separate the JBoss Enterprise Application Server from other networks.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:206401
File: eap5-ocil.xml

Sensitive information being transmitted without strong encryption creates possible exposure for the deployed application and users connecting to it. Plain text transmission of authentication credentials over insecure channels (such as HTTP) exposes credential information to any entity capable of intercepting packets from the connection.

CVSSv2 Risk Assessment: 4.3 / Medium - CVSSv2 Formula: (AV:A/AC:M/Au:N/C:P/I:P/A:N)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-8

DoD 8500.2 Mapping: ECTM-1,ECTM-2

Interview JBoss administrators and application developers. Review application documentation. Descriptive information for sensitive data used by the application should be readily available. Ensure this information is secured with SSL 3.x or TLS. There are multiple ways to secure the connections - the most common being configuration of the Apache Tomcat container (JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml).

Real-world tests using a browser, wget, and a packet capture utility may also assist in validating the level of encryption for sensitive information.

Applications passing sensitive data should use a secure channel such as SSL or TLS. There are several ways to secure traffic with SSL, the method below uses the underlying Apache Tomcat technology to handle the connection.

To setup SSL or TLS, proceed as follows:

• Ensure a valid keystore is being loaded by JSM
• Load the JBoss server's public/private key pair into the keystore
• Add a secure connector to JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml

  <Service name="jboss.web">
  	<Connector protocol="HTTP/1.1" SSLEnabled="true"
  		port="8443" address="${jboss.bind.address}"
  		scheme="https" secure="true" clientAuth="false"
  		keystoreFile="${jboss.server.home.dir}/conf/bp.keystore"
  		keystorePass="KEYSTORE_PASSWORD" sslProtocol = "TLS" />
  </Service>

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
2. JBoss Enterprise Application Platform 5 Security Guide, 2011

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:109401
File: eap5-ocil.xml

Configuration management is an essential part long-term success for any software application - especially for complex software or collaborative environments. Using a versioning system allows for tighter control and accountability of application server changes.

Maintaining a 'Gold' version of JBoss is useful for environments that may need to periodically or dynamically deploy JBoss instances. This can also be useful for static environments that simply desire to have a known baseline to deploy from.

CVSSv2 Risk Assessment: 5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-3,CM-5

DoD 8500.2 Mapping: DCCB-1,DCCB-2,ECPC-1,ECPC-2,DCSL-1,ECSD-1,ECSD-2

Interview JBoss administrators and/or platform administrators. Review evidence of version control system and its use.

Initiate a version control repository such as Git or SVN for JBoss maintenance and deployments. This will likely be a multi-stage process requiring planning and implementation.

1. Mallik, R. (2011, May). Jboss in the Trenches.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:110401
File: eap5-ocil.xml

As much as possible new application deployments to JBoss should be scripted. This increases standardization in deployments and reduces the possibility of errors and misconfigurations. Smaller environments may see less benefit from implementing an automated process.

CVSSv2 Risk Assessment: 5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Interview JBoss administrators and review procedural documentation. Determine if applications are deployed to JBoss Enterprise Application Platforms in an automated manner. The level of automation should be assessed vs. the costs for implementation.

Utilize custom scripts and/or software to automate application deployments to JBoss. Popular applications in this field include Cargo, ANT, JBoss Tools, and Hudson. Software in this category is quickly evolving and adding new features.

1. Mallik, R. (2011, May). Jboss in the Trenches.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:112501
File: eap5-ocil.xml

Without adequate performance testing, production applications may fail to perform to expectations - resulting in a denial of service.

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: SA-3

DoD 8500.2 Mapping: DCSP-1

Interview JBoss system administrators and application developers. Review product documentation related to performance testing and load limits. Review policy and procedural documents related to performance testing. Production environments should have documented and established performance profiles. Applications should be performance tested prior to deployment to production environments.

Ensure routine performance testing is completed before applications are deployed to production. Establish and document performance profiles. Attempt to test against anticipated peak demands as well as load averages. Individual tests will vary, but commonly consist of testing message throughputs (various message types), application inputs, connections open/closed/expired, data transactions completed, method calls, objects persisted, etc.

1. Mallik, R. (2011, May). Jboss in the Trenches.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:112701
File: eap5-ocil.xml

Production environments should be carefully monitored to ensure the any problems on the server are detected as quickly as possible. Identifying and isolating a problem when it is small may prevent downtime or other problems on the network.

CVSSv2 Risk Assessment: 6 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AU-3,AU-6,AU-7,AU-12

DoD 8500.2 Mapping: ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECAT-1,ECAT-2,ECRG-1

Interview JBoss system administrators. Review server documentation and system architecture diagrams. Review documents related to server monitoring. Production environments should have a real-time monitoring solution in place.

Research and implement an appropriate monitoring solution for the production environment. Different environments will have different requirements owing to sensitivity to downtime, regulatory requirements, service agreements, and other factors. Be careful when implementing a monitoring solution to minimize performance impact on the servers where possible. Common monitoring tools include:

• JBoss Operations Network (JON)
• Foglight
• HP Openview
• Nagios

Common metrics include:

• Active threads on the application server
• Threads on the front-end http/ajp web connector
• Database connection pools
• JVM metrics such as memory usage and GCs
• Typical host platform metrics such as available hard drive space, CPU usage, etc.

1. Mallik, R. (2011, May). Jboss in the Trenches.

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:112801
File: eap5-ocil.xml

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.

CVSSv2 Risk Assessment: 6.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:C/I:C/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Interview JBoss administrators. JBoss administrators must demonstrate proficiency in securely acquiring JBoss Enterprise Application Platform installation materials.

When downloading software, first ensure it is coming from the site you expect it to. For instance, when downloading JBoss Enterprise Application Platform from Red Hat, JBoss administrators should review the X.509 certificate presented by the remote server to ensure the authenticity of the site.

Next, JBoss administrators should hash validate files after completed downloads. Hash generation will vary depending on operating system. These hashes should be compared to one of the hashes available on the Red Hat website.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:205701
File: eap5-ocil.xml

By deviating from a Common Criteria configuration, JBoss will no longer be considered certified against any protection level - this may have legislative or regulatory consequences that must be identified and risk assessed dependent on your environment.

CVSSv2 Risk Assessment: 6.2 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: SA-4

DoD 8500.2 Mapping: DCAS-1,DCSR-1,DCSR-2,DCSR-3

Interview JBoss administrators and review on-site documentation. Review the JBoss Common Criteria Configuration Guide (available here from Red Hat's website) to ensure JBoss has been installed and configured in accordance with the Common Criteria requirements.

Configure JBoss in its Common Criteria certified configuration. The configuration guide can be found here on Red Hat's website.

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:401001
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following directory:

• JBOSS_HOME/server/[PROFILE]/deploy/juddi-service.sar

Delete this directory:

• JBOSS_HOME/server/[PROFILE]/deploy/juddi-service.sar

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf
3. JUDDI; An Apache Project. (February 6, 2012).

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:110601
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following directory:

• JBOSS_HOME/server/[PROFILE]/deploy/ejb3-connectors-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/ejb3-container-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/ejb3-interceptors-aop.xml
• JBOSS_HOME/server/[PROFILE]/deploy/ejb3-timerservice-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/profile-service-secured.jar
• JBOSS_HOME/server/[PROFILE]/deploy/ejb2-container-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml
• JBOSS_HOME/server/[PROFILE]/deployers/jboss-ejb3-endpoint-deployer.jar
• JBOSS_HOME/server/[PROFILE]/deployers/ejb3-deployers-jboss-beans.xml

In order to completely disable the this component, Delete the following files and directories:

• JBOSS_HOME/server/[PROFILE]/deploy/ejb3-connectors-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/ejb3-container-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/ejb3-interceptors-aop.xml
• JBOSS_HOME/server/[PROFILE]/deploy/ejb3-timerservice-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/profile-service-secured.jar
• JBOSS_HOME/server/[PROFILE]/deploy/ejb2-container-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml
• JBOSS_HOME/server/[PROFILE]/deployers/jboss-ejb3-endpoint-deployer.jar
• JBOSS_HOME/server/[PROFILE]/deployers/ejb3-deployers-jboss-beans.xml

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:110701
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following directory:

• JBOSS_HOME/server/[PROFILE]/deploy/uuid-key-generator.sar

In order to completely disable the this component, Delete this directory:

• JBOSS_HOME/server/[PROFILE]/deploy/uuid-key-generator.sar

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:110801
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

• JBOSS_HOME/server/[PROFILE]/conf/props/messaging-roles.properties
• JBOSS_HOME/server/[PROFILE]/conf/props/messaging-users.properties
• JBOSS_HOME/server/[PROFILE]/deploy/messaging
• JBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rar
• JBOSS_HOME/server/[PROFILE]/deploy/quartz-ra.rar
• JBOSS_HOME/server/[PROFILE]/deployers/messaging-definitions-jboss-beans.xml

Validate changes to the following files:

• Ensure all elements with references to JMS have been removed from: JBOSS_HOME/server/[PROFILE]/conf/standardjboss.xml
• Ensure the following <property> element has been removed from JBOSS_HOME/server/[PROFILE]/conf/jbossts-properties.xml

  <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/>

In order to completely disable this component, take the following actions:

Delete these files and directories:

• JBOSS_HOME/server/[PROFILE]/conf/props/messaging-roles.properties
• JBOSS_HOME/server/[PROFILE]/conf/props/messaging-users.properties
• JBOSS_HOME/server/[PROFILE]/deploy/messaging
• JBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rar
• JBOSS_HOME/server/[PROFILE]/deploy/quartz-ra.rar
• JBOSS_HOME/server/[PROFILE]/deployers/messaging-definitions-jboss-beans.xml

Make the identified changes to the following files:

• Remove all elements with references to JMS from: JBOSS_HOME/server/[PROFILE]/conf/standardjboss.xml
• Remove the following <property> element from JBOSS_HOME/server/[PROFILE]/conf/jbossts-properties.xml

  <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/>

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:110901
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

• JBOSS_HOME/server/[PROFILE]/deploy/mail-ra.rar
• JBOSS_HOME/server/[PROFILE]/deploy/mail-service.xml

In order to completely disable the this component, Delete the following files and directories:

• JBOSS_HOME/server/[PROFILE]/deploy/mail-ra.rar
• JBOSS_HOME/server/[PROFILE]/deploy/mail-service.xml

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:111001
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

• JBOSS_HOME/server/[PROFILE]/deploy/schedule-manager-service.xml
• JBOSS_HOME/server/[PROFILE]/deploy/scheduler-service.xml

In order to completely disable the this component, Delete the following files:

• JBOSS_HOME/server/[PROFILE]/deploy/schedule-manager-service.xml
• JBOSS_HOME/server/[PROFILE]/deploy/scheduler-service.xml

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:111101
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

• JBOSS_HOME/server/[PROFILE]/deploy/hsqldb-ds.xml
• JBOSS_HOME/common/lib/hsqldb.jar
• JBOSS_HOME/common/lib/hsqldb-plugin.jar
• JBOSS_HOME/server/[PROFILE]/deploy/messaging/hsqldb-persistence-service.xml
• JBOSS_HOME/server/[PROFILE]/data/hypersonic/

In order to completely disable the this component, Delete the following files and directories:

• JBOSS_HOME/server/[PROFILE]/deploy/hsqldb-ds.xml
• JBOSS_HOME/common/lib/hsqldb.jar
• JBOSS_HOME/common/lib/hsqldb-plugin.jar
• JBOSS_HOME/server/[PROFILE]/deploy/messaging/hsqldb-persistence-service.xml
• JBOSS_HOME/server/[PROFILE]/data/hypersonic/

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:111201
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

• JBOSS_HOME/server/[PROFILE]/deployers/bsh.deployer

In order to completely disable the this component, Delete the following files and directories:

• JBOSS_HOME/server/[PROFILE]/deployers/bsh.deployer

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:111301
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

• JBOSS_HOME/server/[PROFILE]/conf/jax-ws-catalog.xml
• JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-roles.properties
• JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-users.properties
• JBOSS_HOME/server/[PROFILE]/deploy/jbossws.sar
• JBOSS_HOME/server/[PROFILE]/deploy/jbossws-console.war
• JBOSS_HOME/server/[PROFILE]/deployers/jbossws.deployer

In order to completely disable the this component, Delete the following files and directories:

• JBOSS_HOME/server/[PROFILE]/conf/jax-ws-catalog.xml
• JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-roles.properties
• JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-users.properties
• JBOSS_HOME/server/[PROFILE]/deploy/jbossws.sar
• JBOSS_HOME/server/[PROFILE]/deploy/jbossws-console.war
• JBOSS_HOME/server/[PROFILE]/deployers/jbossws.deployer

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:111401
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

• JBOSS_HOME/server/[PROFILE]/deployers/seam.deployer
• JBOSS_HOME/server/[PROFILE]/deployers/webbeans.deployer

In order to completely disable the this component, Delete the following files and directories:

• JBOSS_HOME/server/[PROFILE]/deployers/seam.deployer
• JBOSS_HOME/server/[PROFILE]/deployers/webbeans.deployer

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:111501
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

• JBOSS_HOME/server/[PROFILE]/conf/jacorb.properties
• JBOSS_HOME/server/[PROFILE]/deploy/iiop-service.xml
• JBOSS_HOME/server/[PROFILE]/deployers/ejb3.deployer/META-INF/ejb3-iiop-deployers-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/lib/jacorb.jar

Validate changes to the following files:

In JBOSS_HOME/server/[PROFILE]/conf/jndi.properties, Replace:

java.naming.factory.initial=org.jboss.iiop.naming.ORBInitialContextFactory

with

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

In order to completely disable this component, Delete these files and directories:

• JBOSS_HOME/server/[PROFILE]/conf/jacorb.properties
• JBOSS_HOME/server/[PROFILE]/deploy/iiop-service.xml
• JBOSS_HOME/server/[PROFILE]/deployers/ejb3.deployer/META-INF/ejb3-iiop-deployers-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/lib/jacorb.jar

Make the identified changes to the following files:

In JBOSS_HOME/server/[PROFILE]/conf/jndi.properties, Replace:

java.naming.factory.initial=org.jboss.iiop.naming.ORBInitialContextFactory

with

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

In JBOSS_HOME/server/[PROFILE]/conf/standardjboss.xml, Delete text:

invoker-proxy-binding iiop

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:111601
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

• JBOSS_HOME/server/[PROFILE]deployers/xnio.deployer
• JBOSS_HOME/server/[PROFILE]deployers/hibernate-deployer-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/jboss-xa-jdbc.rar
• JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war
• JBOSS_HOME/server/[PROFILE]/deploy/profileservice-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/sqlexception-service.xml
• JBOSS_HOME/server/[PROFILE]/deploy/xnio-provider.jar
• JBOSS_HOME/server/[PROFILE]/deploy/management/

In order to completely disable these components, Delete these files and directories:

• JBOSS_HOME/server/[PROFILE]deployers/xnio.deployer
• JBOSS_HOME/server/[PROFILE]deployers/hibernate-deployer-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/jboss-xa-jdbc.rar
• JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war
• JBOSS_HOME/server/[PROFILE]/deploy/profileservice-jboss-beans.xml
• JBOSS_HOME/server/[PROFILE]/deploy/sqlexception-service.xml
• JBOSS_HOME/server/[PROFILE]/deploy/xnio-provider.jar
• JBOSS_HOME/server/[PROFILE]/deploy/management/

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:111701
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

For HTTP Invoker for JNDI, EJB and JMX:

• JBOSS_HOME/server/[PROFILE]/deploy/http-invoker.sar
• JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar

For JMS HTTP Invoker:

• JBOSS_HOME/server/[PROFILE]/deploy/jms/jbossmq-httpil.sar

In order to completely disable HTTP Invoker for JNDI, EJB and JMX, Delete these files and directories:

• JBOSS_HOME/server/[PROFILE]/deploy/http-invoker.sar
• JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar

In order to completely disable HTTP Invoker for JMS, Delete this directory:

• JBOSS_HOME/server/[PROFILE]/deploy/jms/jbossmq-httpil.sar

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:111801
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

• JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml

In order to completely disable this component, Delete these files and directories:

• JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:111901
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate changes to the following files:

In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml Ensure the <mbean> with name attribute of "jboss:service=invoker,type=pooled" has been deleted.

In order to completely disable this component, take the following actions:

In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml, Delete the <mbean> with name attribute of "jboss:service=invoker,type=pooled"

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:112001
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate changes to the following files:

In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml, Ensure the <mbean> with name attribute of "jboss:service=invoker,type=jmrp" has been deleted.

In order to completely disable this component, take the following actions:

In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml, Delete the <mbean> with name attribute of "jboss:service=invoker,type=jmrp"

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:112101
File: eap5-ocil.xml

Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

• JBOSS_HOME/server/[PROFILE]/deploy-hasingleton/
• JBOSS_HOME/server/[PROFILE]/farm/
• JBOSS_HOME/server/[PROFILE]/deploy/cluster/

Validate this change to the following file:

In JBOSS_HOME/server/[PROFILE]/conf/bootstrap/profile.xml, Delete the following from "BootstrapProfileFactory":

<property name="farmURIs">
	<list elementClass="java.net.URI">
		<value>${jboss.server.home.url}farm</value>
	</list>
</property>

In order to completely disable this component, take the following actions:

Delete these files and directories:

• JBOSS_HOME/server/[PROFILE]/deploy-hasingleton/
• JBOSS_HOME/server/[PROFILE]/farm/
• JBOSS_HOME/server/[PROFILE]/deploy/cluster/

In JBOSS_HOME/server/[PROFILE]/conf/bootstrap/profile.xml, Delete the following from "BootstrapProfileFactory":

<property name="farmURIs">
	<list elementClass="java.net.URI">
		<value>${jboss.server.home.url}farm</value>
	</list>
</property>

1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:112301
File: eap5-ocil.xml