<?xml version="1.0" encoding="UTF-8"?>

<Benchmark id="xccdf_eap_benchmark_eapBenchmark" xml:lang="en-US" style="SCAP_1.1" xmlns="http://checklists.nist.gov/xccdf/1.1" xmlns:cpe="http://cpe.mitre.org/language/2.0" xmlns:cpe-naming="http://cpe.mitre.org/naming/2.0" xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xhtml="http://www.w3.org/1999/xhtml" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.1 xccdf-1.1.4.xsd ">
	<status date="2012-07-06">accepted</status>	
	<title>Security Benchmark JBoss Enterprise Application Platform 5.x</title>
	<description>This XCCDF benchmark is used for evaluating the security of Red Hat JBoss Enterprise Application Platform 5.x.</description>
	<notice id="EAP5">This content was developed by Red Hat, Inc. for use by JBoss Enterprise Application Platform 5.x Administrators and is released under the Public Domain License.</notice>
	<front-matter xml:lang="en">
		<xhtml:p>JBoss Enterprise Application Platform is a popular Java Enterprise Edition application server platform by Red Hat. It is based on the open-source JBoss Application Server, Community Edition. Leveraging robust container architecture, JBoss EAP is capable of hosting a wide variety of applications - anything from simple, static HTML pages all the way to distributed, transaction-based Java Enterprise Edition applications. JBoss EAP is known for being dependable, fast, flexible, and cost-effective.</xhtml:p>
		<xhtml:p>This benchmark provides security guidance on JBoss EAP 5 running on Red Hat Enterprise Linux. OVAL content for this benchmark to be run on other platforms is in development. This document assumes that the reader is familiar with JBoss EAP 5 and Red Hat Enterprise Linux administration. This document also assumes that the baseline configuration of the operating system and JBoss EAP 5 are up-to-date in terms of installed patches. The content within this benchmark was tested for compatibility with multiple SCAP tools on Red Hat Enterprise Linux 5 and 6. The following compatibility matrix shows our results:</xhtml:p>
		
		<xhtml:table border="1" cellpadding="0" cellspacing="0">
			<xhtml:tr>
				<xhtml:td></xhtml:td>
				<xhtml:td><xhtml:b>XCCDFExec v1.1.4 Build 19</xhtml:b></xhtml:td>
				<xhtml:td><xhtml:b>SPAWAR Compliance Checker v3.0.3</xhtml:b></xhtml:td>
				<xhtml:td><xhtml:b>OpenSCAP v0.8.2</xhtml:b></xhtml:td>
			</xhtml:tr>
			<xhtml:tr>
				<xhtml:td><xhtml:b>RHEL 5 - i386</xhtml:b></xhtml:td>
				<xhtml:td bgcolor="#00AA00">Fully Compatible</xhtml:td>
				<xhtml:td bgcolor="#00AA00">Fully Compatible</xhtml:td>
				<xhtml:td bgcolor="#00AA00">Fully Compatible</xhtml:td>
			</xhtml:tr>
			<xhtml:tr>
				<xhtml:td><xhtml:b>RHEL 5 - x86_64</xhtml:b></xhtml:td>
				<xhtml:td bgcolor="#00AA00">Fully Compatible</xhtml:td>
				<xhtml:td bgcolor="#00AA00">Fully Compatible</xhtml:td>
				<xhtml:td bgcolor="#00AA00">Fully Compatible</xhtml:td>
			</xhtml:tr>
			<xhtml:tr>
				<xhtml:td><xhtml:b>RHEL 6 - i386</xhtml:b></xhtml:td>
				<xhtml:td bgcolor="#FFAA00">Additional Dependencies Needed</xhtml:td>
				<xhtml:td bgcolor="#00AA00">Fully Compatible</xhtml:td>
				<xhtml:td bgcolor="#00AA00">Fully Compatible</xhtml:td>
			</xhtml:tr>		
			<xhtml:tr>
				<xhtml:td><xhtml:b>RHEL 6 - x86_64</xhtml:b></xhtml:td>
				<xhtml:td bgcolor="#FFAA00">Additional Dependencies Needed</xhtml:td>
				<xhtml:td bgcolor="#00AA00">Fully Compatible</xhtml:td>
				<xhtml:td bgcolor="#00AA00">Fully Compatible</xhtml:td>
			</xhtml:tr>		
		</xhtml:table>
		
		<xhtml:p>The recommendations included in this benchmark have been derived from various government and industry sources. All rules include a rationale, validation instructions (for OCIL rules), remediation instructions, references, risk assessments, and NIST/DoD Control mappings. </xhtml:p>
	</front-matter>
	<rear-matter>
		<xhtml:p>For additional information regarding the JBoss EAP 5 SCAP benchmark, please visit <xhtml:a href="https://fedorahosted.org/scap-security-guide/">https://fedorahosted.org/scap-security-guide/</xhtml:a></xhtml:p>
		<xhtml:p>You may also contact the authors:</xhtml:p>
		<xhtml:ul>
			<xhtml:li><xhtml:a href="mailto:bsaunder@redhat.com">Bryan Saunders</xhtml:a></xhtml:li>
			<xhtml:li><xhtml:a href="mailto:tfalls@redhat.com">Tim Falls</xhtml:a></xhtml:li>
			<xhtml:li><xhtml:a href="mailto:jalopez@redhat.com">James Lopez</xhtml:a></xhtml:li>
			<xhtml:li><xhtml:a href="mailto:kpeeples@redhat.com">Kenneth Peeples</xhtml:a></xhtml:li>
		</xhtml:ul>
	</rear-matter>

	<platform idref="cpe:/a:redhat:jboss_enterprise_application_platform:5.0.0"/>
	<platform idref="cpe:/a:redhat:jboss_enterprise_application_platform:5.0.1"/>
	<platform idref="cpe:/a:redhat:jboss_enterprise_application_platform:5.1.0"/>
	<platform idref="cpe:/a:redhat:jboss_enterprise_application_platform:5.1.1"/>
	<platform idref="cpe:/a:redhat:jboss_enterprise_application_platform:5.1.2"/>

	<version>v1.0</version>
	<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
		<dc:title>Security Benchmark JBoss Enterprise Application Platform 5.x</dc:title> 
		<dc:creator>Timothy Falls</dc:creator>
		<dc:creator>Bryan Saunders</dc:creator>
		<dc:creator>Kenny Peeples</dc:creator>
		<dc:creator>James Lopez</dc:creator>
		<dc:publisher>Red Hat</dc:publisher> 
		<dc:subject>security for JBoss Enterprise Application Platform (EAP), version 5</dc:subject>
		<dc:contributor>Jason Wong</dc:contributor>
		<dc:contributor>Jesse Sightler</dc:contributor>
		<dc:source>JBoss Enterprise Application Platform 5 Security Guide, 2011</dc:source>
		<dc:source>Mallik, R. (2011, May). Jboss in the Trenches.</dc:source>
		<dc:source>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</dc:source>
		<dc:source>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</dc:source>
		<dc:source>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</dc:source>
		<dc:source>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</dc:source>
		<dc:source>U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guidelines on Securing Public Web Servers (800-44). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html</dc:source>
	</metadata>

	<Profile id="eap5_full">
		<title>JBoss Enterprise Application Platform 5 - Department of Defense</title>
		<description>Profile for testing a secure deployment of JBoss EAP 5 in a DoD environment.</description>
		<select idref="xccdf_com.redhat.eap5.scap_group_general_configuration" selected="true"/>
		<select idref="xccdf_com.redhat.eap5.scap_group_general_configuration_secure_platform" selected="true"/>
		<select idref="xccdf_com.redhat.eap5.scap_group_secure_deployed_applications" selected="true"/>
		<select idref="xccdf_com.redhat.eap5.scap_group_policy_architecture_and_practices_POLICY" selected="true"/>
		<select idref="xccdf_com.redhat.eap5.scap_group_policy_architecture_and_practices_ARCHITECTURE" selected="true"/>
		<select idref="xccdf_com.redhat.eap5.scap_group_policy_architecture_and_practices_PRACTICES" selected="true"/>
		<select idref="xccdf_com.redhat.eap5.scap_group_trimming" selected="true"/>
	</Profile>
	
	<!--<Value id="password_age" type="number" operator="less than or equal">
		<title>Maximum Password Age</title>
		<description></description>
		<value selector="selector_a">120</value>
		<value selector="selector_b">90</value>
		<value selector="selector_c">60</value>
		<value selector="selector_d">30</value>
		<default>180</default>
	</Value>
	
	<Value id="dod_mac_level" type="string" interactive="1">
		<title>DoD MAC Level</title>
		<description></description>
		<value selector="selector_a">MAC 1</value>
		<value selector="selector_b">MAC 2</value>
		<value selector="selector_c">MAC 3</value>
		<default>MAC 3</default>
		<choices mustMatch="1">
			<choice>MAC 1</choice>
			<choice>MAC 2</choice>
			<choice>MAC 3</choice>
		</choices>
	</Value>-->
	
	<Value id="warning_banner_text" type="string">
		<title>Warning banner content</title>
		<description>This value contains the content for a DoD warning banner.</description>
		<value selector="DoD">The DoD 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."</value>
		<default></default>
	</Value>

	<Group id="xccdf_com.redhat.eap5.scap_group_general_configuration" selected="false">
		<title>General Configuration</title>
		<description>The rules in this group validation general configuration items.</description>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2001"><!--JBoss Enterprise Application Platform should be the correct version-->
			<title>JBoss Enterprise Application Platform should be a vendor supported version</title>
			<description>Evaluated JBoss installation must be a vendor supported version of JBoss Enterprise Application Platform 5. Red Hat typically offers full and production support for the first 7 years following a release. Extended support options can be negotiated with the vendor directly through a separate subscription. Organizations using JBoss EAP must use a vendor supported version with an active support contract.</description>
			<reference>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</reference>	
			<rationale>
				<xhtml:p>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.</xhtml:p>
			</rationale>
			
			<profile-note tag="risk_score">7.5</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:L/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>To determine the version of JBoss EAP installed, perform the following actions: <xhtml:ul>
					<xhtml:li>Execute run.bat --version or run.sh --version located within JBOSS_HOME/bin</xhtml:li>
				</xhtml:ul></xhtml:p>
				<xhtml:p>The output of the command above will display a variety of information; including the version and build information for JBoss.</xhtml:p>
				<xhtml:p>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 (<xhtml:a href="https://access.redhat.com/home">https://access.redhat.com/home</xhtml:a>). 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.</xhtml:p>
			</profile-note>
			
			<fixtext>
				<xhtml:p>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 (<xhtml:a href="http://www.redhat.com">http://www.redhat.com</xhtml:a>).</xhtml:p>
				<xhtml:p>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.</xhtml:p>
			</fixtext>
			<!-- REMOVED, REWRITE TO OVAL AT A LATER TIME
				<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
					<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:200101"/>
				</check>-->
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:200001"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2002"><!--Ensure Java Runtime Environment in use is the correct version-->
			<title>Ensure Java Runtime Environment in use is a supported version</title>
			<description>Evaluated JBoss installation must use a vendor supported Java virtual machine - i.e., one that has not reached end-of-life. Migration strategies should be developed when end-of-life is impending.</description>
			<reference>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</reference>
			<rationale>Java installations should be a vendor supported version. If the Java virtual machine in use by JBoss is not supported by the vendor, this may result in outages, unresolvable problems, no access to security or functional updates, etc.</rationale>
			
			<profile-note tag="risk_score">7.5</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:L/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>To identify the JRE used by JBoss, perform the following actions:<xhtml:ul>
					<xhtml:li>Execute run.bat --version or run.sh --version located within JBOSS_HOME/bin</xhtml:li>
				</xhtml:ul></xhtml:p>
				<xhtml:p>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.</xhtml:p>
				<xhtml:p>Java Runtime Environments commonly used with JBoss include:
					<xhtml:ul>
						<xhtml:li>Sun JRE 1.6.x</xhtml:li>
						<xhtml:li>IBM JRE 1.6.x</xhtml:li>
						<xhtml:li>OpenJDK JRE 1.6.x</xhtml:li>
					</xhtml:ul></xhtml:p>
			</profile-note>
			
			<fixtext>
				<xhtml:p>Organizations should install a vendor supported Java Runtime Environment.</xhtml:p>
				<xhtml:p>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.</xhtml:p>
				<xhtml:p>Finally, organizations must develop migration plans for Java Runtime Environments that reach end-of-life within the next year.</xhtml:p>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:200201"/>
			</check>
		</Rule>
					
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2005"><!--Ensure all configurations are made to the appropriate server profile-->
			<title>Ensure all configurations are made to the appropriate server profile</title>
			<description>Production environments should utilize the production server profile. Development and test environments should choose the profile that best fits their needs.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">3</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>JBoss administrators should use the profiles as defined in the validation text.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:200501"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2018"><!--Ensure Technology Preview components are disabled-->
			<title>Ensure Technology Preview components are disabled in production environments</title>
			<description>Remove the PicketLink technology preview folder. By default, this folder is included at the same level as the JBoss-as folder. If you leave the picketlink folder as originally shipped in the EAP binary, PicketLink is unable to be launched, and subsequently interact with the certified configuration. </description>
			<reference>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</reference>
			<rationale><xhtml:p>Technology Preview components are not production-ready, vendor supported JBoss components.  They may be incomplete, contain bugs, insecure features or architecture, etc.</xhtml:p>
				</rationale>
			
			<profile-note tag="risk_score">3</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			
			<profile-note tag="nist_mapping">CM-7</profile-note>
			<profile-note tag="disa_mapping">DCPP-1</profile-note>
			
			<fixtext><xhtml:p>Delete the JBOSS_HOME/picketlink/ folder.</xhtml:p> </fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:201801"/>
			</check>
		</Rule>
						
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1130"><!--Disable Hot Deployment in production-->
			<title>Disable Hot Deployment in production</title>
			<description>Hot deployment should be disabled on production servers. Hot Deployment allows for automatic deployment of Java applications by simply placing Java applications into the deploy directory.</description>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">3.0</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			
			<profile-note tag="nist_mapping">CM-7</profile-note>
			<profile-note tag="disa_mapping">DCPP-1</profile-note>
			
			<fixtext><xhtml:p>Delete the following file:</xhtml:p>
				<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/hdscanner-jboss-beans.xml</xhtml:li></xhtml:ul> </fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:113001"/>
			</check>
		</Rule>
					
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1101"><!--Production applications should not implement the default SRPVerifierStore interface for the Secure Remote Password (SRP) protocol-->
			<title>Production applications should not implement the default SRPVerifierStore interface for the Secure Remote Password (SRP) protocol</title>
			<description>The SRP protocol is a public key exchange protocol similar to Diffie-Hellman. The default implementation of the SRPVerifierStore interface is not recommended for a production security environment because it requires all password hash information to be available as a file of serialized objects.</description>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>			
			<profile-note tag="risk_score">3</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>			
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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. </xhtml:p></profile-note>
			<fixtext><xhtml:p>Application developers should not use the default implementation for SRPVerifierStore, and should extend it to avoid the use of serialized password objects.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:110101"/>
			</check>
		</Rule>
						
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2039"><!--Declare an EJB Authorization Policy-->
			<title>Declare an EJB authorization policy for deployed applications</title>
			<description>When configuring your application specific security policy, you must declare one (or more) of the following authorization modules in the security domain &lt;policy-module&gt; element. 
				<xhtml:ul><xhtml:li>org.JBoss.security.authorization.modules.DelegatingAuthorizationModule</xhtml:li>
					<xhtml:li>org.JBoss.security.authorization.modules.JACCAuthorizationModule</xhtml:li></xhtml:ul>
				<xhtml:p>A security domain does not explicitly require an authorization policy. If an authorization policy is not specified, the default jboss-web-policy and jboss-ejb-policy authorization configured in jboss-as/server/$PROFILE/deploy/security/security-policies-jboss-beans.xml is used. If you do choose to specify an authorization policy, or create a custom deployment descriptor file with a valid authorization policy, these settings override the default settings in security-policies-jboss-beans.xml.</xhtml:p></description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p>
				</rationale>
			
			<profile-note tag="risk_score">3.5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			
			<profile-note tag="nist_mapping">AC-3,AC-4</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,EBBD-1,EBBD-2,EBBD-3</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>Review possible locations for definition of &lt;application-policy&gt; elements. Specifically, ensure that 'code' attributes for &lt;authorization&gt;&lt;policy-module&gt; elements are either 'org.JBoss.security.authorization.modules.DelegatingAuthorizationModule' or 'org.JBoss.security.authorization.modules.JACCAuthorizationModule'.</xhtml:p>
				<xhtml:p>These &lt;application-policy&gt; can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.</xhtml:p>
				<xhtml:ul>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul>
				<xhtml:p>NOTE: This applies even if the application is using Extensible Access Control Markup Language (XACML) Authorization Module.</xhtml:p> </profile-note>
			<fixtext>
				<xhtml:p>Applications deploying their own security policies must specify one of the following &lt;policy-module&gt; within their 'code' attributes:</xhtml:p>
				<xhtml:ul><xhtml:li>org.JBoss.security.authorization.modules.DelegatingAuthorizationModule</xhtml:li>
					<xhtml:li>org.JBoss.security.authorization.modules.JACCAuthorizationModule</xhtml:li></xhtml:ul>
				
				<xhtml:p>Example:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;application-policy name="demo"&gt;
	&lt;authorization&gt;
	&lt;policy-module code="org.JBoss.security.authorization.modules.JACCAuthorizationModule"&gt;&lt;/policy-module&gt;
	&lt;/authorization&gt;
&lt;/application-policy&gt;</xhtml:code></xhtml:pre> 
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:203901"/>
			</check>
		</Rule>
					
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2042"><!--Ensure appropriate permissions have been granted to Java Database Connectivity (JDBC) driver-->
			<title>Ensure appropriate permissions have been granted to Java Database Connectivity (JDBC) driver</title>
			<description>The security manager policy file may require permissions to be set for database drivers. The JBoss administrator can assign permissions to the database drivers that are needed by deployed applications. It is recommended that the most restrictive permissions are added. With some installations, permissions must be granted to database drivers that are not available to deployed applications; such as java.net.SocketPermission.</description>
			<reference>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</reference>
			<rationale><xhtml:p>Deployed applications requiring access to data sources should have limited permissions to interact with the database drivers.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">6.2</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:C/I:C/A:C)</profile-note>
			<profile-note tag="nist_mapping">AC-3,AC-6</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>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):</xhtml:p>
				<xhtml:ul><xhtml:li>java.home/lib/security/java.security</xhtml:li>
					<xhtml:li>JBOSS_HOME/bin/security_cc.policy</xhtml:li></xhtml:ul>
				<xhtml:p>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.</xhtml:p> </profile-note>
			<fixtext>
				<xhtml:p>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.</xhtml:p>
				<xhtml:pre><xhtml:code>// granting permissions to JDBC driver 
grant codeBase "file:${JBoss.server.home.dir}/lib/[JDBC.DRIVER]" { 
	//JDBC specific permissions to be granted go here
};</xhtml:code></xhtml:pre>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:204201"/>
			</check>
		</Rule>
						
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2044"><!--Ensure appropriate DefaultDS is enabled-->
			<title>Ensure appropriate DefaultDS is enabled</title>
			<description>Create a default data store file for the desired database. Templates are located in JBOSS_HOME/docs/examples/jca.<xhtml:br/>The DefaultDS must not be a HSQLDB.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">2.6</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:N/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">SC-4</profile-note>
			<profile-note tag="disa_mapping">ECRC-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>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 &lt;jndi-name&gt;DefaultDS&lt;/jndi-name&gt; element. OS text searching utilities can help find the DefaultDS. The DefaultDS CANNOT be HSQL. An HSQL data source will contain elements like: &lt;driver-class&gt;org.hsqldb.jdbcDriver&lt;/driver-class&gt; and &lt;type-mapping&gt;Hypersonic SQL&lt;/type-mapping&gt;.</xhtml:p>
				<xhtml:p>Linux: grep -Hri "&lt;jndi-name&gt;DefaultDS&lt;/jndi-name&gt;" $JBOSS_HOME/server/[PROFILE]/deploy/*-ds.xml</xhtml:p> </profile-note>
			<fixtext>
				<xhtml:p>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.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:204401"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_2157"><!--Deployed applications must not write data to DefaultDS-->
			<title>Deployed applications must not write data to DefaultDS</title>
			<description>Deployed applications (other than JBoss default applications) must not write information to the database defined by the DefaultDS data source. These applications must use a database specific to the application.</description>
			<reference>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</reference>
			<rationale><xhtml:p>Sharing databases between applications is a poor security practice that can create injection and leakage vulnerabilities that cross application boundaries.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">5.1</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:H/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">SC-4</profile-note>
			<profile-note tag="disa_mapping">ECRC-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p>
				<xhtml:p>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.</xhtml:p>
				<xhtml:p>NOTE: Using the same database server is acceptable, however the database must not be the same.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>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.</xhtml:p>
				<xhtml:p>Data source templates can be found in the JBOSS_HOME/docs/examples/jca/ directory.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:215701"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2045"><!--Ensure default HSQLDB is disabled-->
			<title>Ensure default HSQLDB is disabled</title>
			<description>The default development HSQL database included with JBoss should be removed.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">2.6</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:N/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">SC-4</profile-note>
			<profile-note tag="disa_mapping">ECRC-1</profile-note>
			
			<fixtext>
				<xhtml:p>Delete the following files that refer to the HSQLDB database:</xhtml:p>
				<xhtml:ul>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/hsqldb-ds.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/common/lib/hsqldb.jar</xhtml:li>
					<xhtml:li>JBOSS_HOME/common/lib/hsqldb-plugin.jar</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/messaging/hsqldb-persistence-service.xml</xhtml:li>
				</xhtml:ul>
				<xhtml:p>Delete the HSLQDB database files:</xhtml:p>
				<xhtml:ul>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/data/hypersonic/*</xhtml:li>
				</xhtml:ul>
			</fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:204501"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2046"><!--Ensure HSQLDB Security Domain is removed-->
			<title>Ensure HSQLDB Security Domain is removed</title>
			<description>The security domain for HsqlDbRealm should be removed from the JBOSS_HOME/server/[PROFILE]/conf/login-config.xml file.<xhtml:br/>
			</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">1</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			
			<profile-note tag="nist_mapping">SC-4</profile-note>
			<profile-note tag="disa_mapping">ECRC-1</profile-note>
			
			<fixtext>
				<xhtml:p>Remove the security domain for HsqlDbRealm in the JBOSS_HOME/server/[PROFILE]/conf/login-config.xml file as shown.</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;!-- Security domains for testing new jca framework
&lt;application-policy name = "HsqlDbRealm"&gt;
	&lt;authentication&gt;
		&lt;login-module code = "org.JBoss.resource.security.ConfiguredIdentityLoginModule" flag = "required"&gt;
		&lt;module-option name = "principal"&gt;sa&lt;/module-option&gt;
		&lt;module-option name = "userName"&gt;cctest&lt;/module-option&gt;
		&lt;module-option name = "password"&gt;cc1248&lt;/module-option&gt;
		&lt;module-option name = "managedConnectionFactoryName"&gt;JBoss.jca:service=LocalTxCM,name=DefaultDS&lt;/module-option&gt;
		&lt;/login-module&gt;
	&lt;/authentication&gt;
&lt;/application-policy&gt;
--&gt;</xhtml:code></xhtml:pre>
			</fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:204601"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2047"><!--Ensure the appropriate Java Messaging Service (JMS) persistence configuration file is in use-->
			<title>Ensure the appropriate Java Messaging Service (JMS) persistence configuration file is in use</title>
			<description>The [database]-persistence-service.xml file contains the persistence service definition for Java Messaging Service, for the database specified by the [database] in the filename. The database must not be HSQLDB.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>

			<profile-note tag="risk_score">2.6</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
				<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:N/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>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:</xhtml:p>
				<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/messaging</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rar</xhtml:li></xhtml:ul>
				<xhtml:p>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:</xhtml:p>
				<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/messaging/*persistence-service.xml</xhtml:li></xhtml:ul> </profile-note>
			<fixtext><xhtml:p>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.</xhtml:p> </fixtext>

			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:204701"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_2050"><!--Ensure Oracle Database persistence plugin is set correctly-->
			<title>Ensure Oracle Database persistence plugin is set correctly</title>
			<description>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.</description>
			<reference>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</reference>
			<rationale><xhtml:p>This is a performance optimization when using Oracle Database as the DefaultDS.</xhtml:p></rationale>
			<profile-note tag="risk_score">2.6</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
				<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:N/I:N/A:P)</profile-note>
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>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. 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:</xhtml:p>
					<xhtml:pre><xhtml:code>&lt;attribute name="DatabasePersistencePlugin"&gt;
	org.JBoss.ejb.txtimer.OracleDatabasePersistencePlugin
&lt;/attribute&gt;</xhtml:code></xhtml:pre>
			</profile-note>	
			<fixtext><xhtml:p>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:</xhtml:p>
<xhtml:pre><xhtml:code>&lt;attribute name="DatabasePersistencePlugin"&gt;
	org.JBoss.ejb.txtimer.OracleDatabasePersistencePlugin
&lt;/attribute&gt;</xhtml:code></xhtml:pre></fixtext>

			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:205001"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_2065"><!--Ensure IBM JRE 16 is configured correctly-->
			<title>Ensure IBM JRE 1.6 is configured correctly</title>
			<description><xhtml:p>When IBM JRE 1.6 is configured as the Java Runtime Environment, the following configuration changes must be made to ensure compatibility between JBoss EAP and IBM JRE.</xhtml:p>
<xhtml:p>IBM JRE 1.6 uses a default policy provider which does not work correctly with the JBoss Enterprise Application Platform security policy. The IBM JRE must be reconfigured to use the standard policy provider.</xhtml:p></description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>

			<profile-note tag="risk_score">3.5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
				<profile-note tag="dod_cat">CAT II</profile-note>
			
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p>
<xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>When IBM JRE 1.6 is configured as the Java Runtime Environment, the following configuration changes must be made for compatibility:</xhtml:p>
<xhtml:p>Edit the file JAVA_HOME/jre/lib/security/java.security and set the value of policy.provider to sun.security.provider.PolicyFile</xhtml:p> </fixtext>

			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:206501"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1100"><!--Configured security domains are recommended to secure production applications-->
			<title>Configured security domains are recommended to secure production applications</title>
			<description>SecurityDomain is an extension of the AuthenticationManager, RealmMapping, and SubjectSecurityManager interfaces. A java.security.KeyStore, and the Java Secure Socket Extension (JSSE) com.sun.net.ssl.KeyManagerFactory and com.sun.net.ssl.TrustManagerFactory interfaces are included in the class.</description>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">3.5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			
			<profile-note tag="nist_mapping">AC-3,IA,SC</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and application developers. Review application documentation. If a need has been identified to secure production applications, JAAS SecurityDomains should be used. </xhtml:p></profile-note>
			<fixtext><xhtml:p>Configure and apply SecurityDomains where appropriate for production applications.</xhtml:p>
				<xhtml:p>For example, an &lt;application-policy&gt; (SecurityDomain) can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.</xhtml:p>
				<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul>
				<xhtml:p>To determine which &lt;application-policy&gt; are in use by deployed applications, search for &lt;security-domain&gt; elements within the following deployment descriptors:</xhtml:p>
				<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss.xml </xhtml:li></xhtml:ul></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:110001"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2038"><!--The allRolesMode must be configured to "strict"-->
			<title>The allRolesMode must be configured to "strict"</title>
			<description>The allRolesMode within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml must be set to strict for production environments. This requires the authenticated user to be assigned to one of the web-app/security-role/role-name roles in order to be authorized. </description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">4.6</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:H/Au:S/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">AC-3,AC-6</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1</profile-note>
			
			<fixtext><xhtml:p>Update allRolesAttribute for the &lt;Realm&gt; 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:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;Realm className="org.jboss.web.tomcat.security.JBossWebRealm" certificatePrincipal="org.jboss.security.auth.certs.SubjectDNMapping" allRolesMode="strict" /&gt;</xhtml:code></xhtml:pre> </fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:203801"/>
			</check>
		</Rule>
					
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1092"><!--Define &lt;security-role&gt; elements-->
			<title>Define &lt;security-role&gt; elements</title>
			<description>Enable authorization and define &lt;security-role&gt; elements to control access to deployed applications.</description>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011 </reference>
			<rationale><xhtml:p>The specification of &lt;security-role&gt; elements is a recommended practice to ensure portability across application servers and for deployment descriptor maintenance.</xhtml:p></rationale>

			<profile-note tag="risk_score">3.5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
				<profile-note tag="dod_cat">CAT II</profile-note>
			
			<profile-note tag="nist_mapping">AC-3,AC-6</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Review the web.xml deployment descriptors for deployed applications. Ensure that &lt;security-role&gt; elements have been define that are referenced by &lt;security-constraint&gt;&lt;auth-constraint&gt; elements within the &lt;web-app&gt; root element.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>Working with application developers (or available documentation), determine the desired roles for controlling access to the deployed applications.</xhtml:p>
<xhtml:p>Next, create the roles within web.xml.</xhtml:p>
<xhtml:pre><xhtml:code>&lt;web-app&gt;
	&lt;security-role&gt;
		&lt;description&gt;The role required to access restricted content &lt;/description&gt;
		&lt;role-name&gt;AuthorizedUser&lt;/role-name&gt;
	&lt;/security-role&gt;
&lt;/web-app&gt;</xhtml:code></xhtml:pre>
<xhtml:p>Finally, require the roles within the application's deployment descriptor, web.xml:</xhtml:p>
<xhtml:pre><xhtml:code>&lt;web-app&gt;
	&lt;security-constraint&gt;
		&lt;auth-constraint&gt;
			&lt;role-name&gt;AuthorizedUser&lt;/role-name&gt;
		&lt;/auth-constraint&gt;
	&lt;/security-constraint&gt;
&lt;/web-app&gt;</xhtml:code></xhtml:pre> </fixtext>

			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:109201"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_3001"><!--Remove, rename, or comment out the default user accounts from production servers-->
			<title>Remove, rename, or comment out the default user accounts from production servers</title>
			<description><xhtml:p>Remove, rename, or comment out the default user accounts defined in .properties files and login-config.xml.</xhtml:p></description>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">6</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:M/Au:S/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">IA-5</profile-note>
			<profile-note tag="disa_mapping">IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Ensure the default user accounts in the default &lt;application-policy&gt; elements located within the configuration file: JBOSS_HOME/server/[PROFILE]/conf/login-config.xml have been removed, renamed, or commented out.</xhtml:p>
				<xhtml:pre><xhtml:code>
&lt;module-option name="principal"&gt;sa&lt;/module-option&gt;
&lt;module-option name="userName"&gt;sa&lt;/module-option&gt;
&lt;module-option name="password"&gt;&lt;/module-option&gt;

&lt;module-option name="principal"&gt;guest&lt;/module-option&gt;
&lt;module-option name="userName"&gt;guest&lt;/module-option&gt;
&lt;module-option name="password"&gt;guest&lt;/module-option&gt;
				</xhtml:code></xhtml:pre>
				<xhtml:p>Examine the .properties files located within the JBOSS_HOME/server/[PROFILE]/conf/props/ directory.
					<xhtml:p>By default, the following files exist:</xhtml:p>
					<xhtml:ul>
						<xhtml:li>jbossws-users.properties</xhtml:li>
						<xhtml:li>jmx-console-users.properties</xhtml:li>
						<xhtml:li>messaging-users.properties</xhtml:li>
					</xhtml:ul>
					<xhtml:p>Ensure the default user accounts have been removed, renamed, or commented out. This includes:</xhtml:p>
					<xhtml:ul>
						<xhtml:li>admin</xhtml:li>
						<xhtml:li>kermit</xhtml:li>
						<xhtml:li>guest</xhtml:li>
					</xhtml:ul></xhtml:p></profile-note>
			<fixtext><xhtml:p>Remove, rename, or comment out the default user accounts in the default &lt;application-policy&gt; elements located within the configuration file: JBOSS_HOME/server/[PROFILE]/conf/login-config.xml.
				<xhtml:pre><xhtml:code>
					&lt;module-option name="principal"&gt;sa&lt;/module-option&gt;
					&lt;module-option name="userName"&gt;sa&lt;/module-option&gt;
					&lt;module-option name="password"&gt;&lt;/module-option&gt;
					
					&lt;module-option name="principal"&gt;guest&lt;/module-option&gt;
					&lt;module-option name="userName"&gt;guest&lt;/module-option&gt;
					&lt;module-option name="password"&gt;guest&lt;/module-option&gt;
				</xhtml:code></xhtml:pre>
				<xhtml:p>Remove, rename, or comment out the default user accounts in properties files: JBOSS_HOME/server/[PROFILE]/conf/props/</xhtml:p>
				<xhtml:ul>
					<xhtml:li>jbossws-users.properties</xhtml:li>
					<xhtml:li>jmx-console-users.properties</xhtml:li>
					<xhtml:li>messaging-users.properties</xhtml:li>
				</xhtml:ul>
				<xhtml:p>The default user accounts include:</xhtml:p>
				<xhtml:ul>
					<xhtml:li>admin</xhtml:li>
					<xhtml:li>kermit</xhtml:li>
					<xhtml:li>guest</xhtml:li>
				</xhtml:ul>
				
				NOTE: If access is required to the services protected by the &lt;application-policy&gt;, be sure that valid accounts and roles exist!</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:300101"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_3002"><!--Remove, rename, or comment out the default roles from production servers-->
			<title>Remove, rename, or comment out the default roles from production servers</title>
			<description><xhtml:p>Remove, rename, or comment out the default role definitions in the default &lt;application-policy&gt; elements.</xhtml:p>
				<xhtml:p>Additionally, remove, rename, or comment out the default role assignments in various properties files from JBOSS_HOME/server/[PROFILE]/conf/props/</xhtml:p></description>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">6</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:M/Au:S/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">IA-5</profile-note>
			<profile-note tag="disa_mapping">IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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/
				<xhtml:ul>
					<xhtml:li>jbossws-roles.properties</xhtml:li>
					<xhtml:li>jmx-console-roles.properties</xhtml:li>
					<xhtml:li>messaging-roles.properties</xhtml:li>
				</xhtml:ul>
				<xhtml:p>The default role assignments are JBossAdmin, HttpInvoker, friend, and guest.</xhtml:p>
				
				<xhtml:p>Finally, ensure the default role assignments within application specific deployment descriptors have been removed, renamed, or commented out:</xhtml:p>
				<xhtml:ul>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/web.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/WEB-INF/web.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml</xhtml:li>
				</xhtml:ul>
				<xhtml:p>These role assignments will fall within &lt;auth-constraint&gt; elements and will look similar to the following:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;security-constraint&gt;
	&lt;web-resource-collection&gt;
		&lt;web-resource-name&gt;HtmlAdaptor&lt;/web-resource-name&gt;
		&lt;description&gt;An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application&lt;/description&gt;
		&lt;url-pattern&gt;/*&lt;/url-pattern&gt;
	&lt;/web-resource-collection&gt;
	&lt;auth-constraint&gt;
		&lt;role-name&gt;JBossAdmin&lt;/role-name&gt;
	&lt;/auth-constraint&gt;
&lt;/security-constraint&gt;</xhtml:code></xhtml:pre></xhtml:p>
			</profile-note>
			
			<fixtext><xhtml:p><xhtml:p>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/
				<xhtml:ul>
					<xhtml:li>jbossws-roles.properties</xhtml:li>
					<xhtml:li>jmx-console-roles.properties</xhtml:li>
					<xhtml:li>messaging-roles.properties</xhtml:li>
				</xhtml:ul>
				<xhtml:p>The default role assignments are JBossAdmin, HttpInvoker, friend, and guest.</xhtml:p>
				
				<xhtml:p>Finally, ensure the default role assignments within application specific deployment descriptors have been removed, renamed, or commented out:</xhtml:p>
				<xhtml:ul>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/web.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/WEB-INF/web.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml</xhtml:li>
				</xhtml:ul>
				<xhtml:p>These role assignments will fall within &lt;auth-constraint&gt; elements and will look similar to the following:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;security-constraint&gt;
	&lt;web-resource-collection&gt;
		&lt;web-resource-name&gt;HtmlAdaptor&lt;/web-resource-name&gt;
		&lt;description&gt;An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application&lt;/description&gt;
		&lt;url-pattern&gt;/*&lt;/url-pattern&gt;
	&lt;/web-resource-collection&gt;
	&lt;auth-constraint&gt;
		&lt;role-name&gt;JBossAdmin&lt;/role-name&gt;
	&lt;/auth-constraint&gt;
&lt;/security-constraint&gt;</xhtml:code></xhtml:pre></xhtml:p></xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:300201"/>
			</check>
			<!--<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
			<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:300201"/>
		</check>-->
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1093"><!--Security constraint elements should exist for all URLs in production environment-->
			<title>Security constraint elements should exist for all URLs in production environment</title>
			<description>The content to be secured is declared using one or more &lt;web-resource-collection&gt; elements. Each &lt;web-resource-collection&gt; element contains an optional series of &lt;url-pattern&gt; elements followed by an optional series of &lt;http-method&gt; elements. The &lt;url-pattern&gt; element value specifies a URL pattern against which a request URL must match for the request to correspond to an attempt to access secured content. The &lt;http-method&gt; element value specifies a type of HTTP request to allow.</description>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011 </reference>
			<rationale><xhtml:p>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..</xhtml:p></rationale>

			<profile-note tag="risk_score">6</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
				<profile-note tag="dod_cat">CAT II</profile-note>
			
			<profile-note tag="nist_mapping">AC-3</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Review application deployment descriptors for indications that &lt;http-method&gt; 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.</xhtml:p> JBoss administrators must take care when restricting HTTP verbs, as JBoss restricts no verbs by default. An incomplete whitelist/blacklist combination could allow circumvention of the intended security policy.</profile-note>
			<fixtext>Implement a whitelist for HTTP methods accepted by each deployed application.  This will generally take the form of two separate security constraints.<!--<xhtml:pre><xhtml:code></xhtml:code></xhtml:pre>--></fixtext>

			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:109301"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1096"><!--DefaultCacheTimeout must be configured properly for active security domains-->
			<title>DefaultCacheTimeout must be configured properly for active security domains</title>
			<description>Security domains in use must use DefaultCacheTimeout less than or equal to 1800 seconds.
If you want to disable caching of security credentials, set this to 0 to force authentication to occur every time. This has no affect if the AuthenticationCacheJndiName has been changed from the default value. </description>
			<reference>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</reference>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011</reference>

			<rationale><xhtml:p>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.</xhtml:p> </rationale>

			<profile-note tag="risk_score">4</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
				<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:H/Au:N/C:P/I:P/A:N)</profile-note>
			<profile-note tag="nist_mapping">SC-8,SC-9,SC-23</profile-note>
			<profile-note tag="disa_mapping">ECTM-1,ECTM-2</profile-note>
			
			<fixtext><xhtml:p>Open the JaasSecurityManagerService Mbean configuration file located at JBOSS_HOME/server/[PROFILE]/conf/jboss-service.xml</xhtml:p>
<xhtml:p>Find the element &lt;mbean code="org.jboss.security.plugins.JaasSecurityManagerService" name="jboss.security:service=JaasSecurityManager"&gt;</xhtml:p>
<xhtml:p>Change the &lt;DefaultCacheTimeout&gt; to 1800 or less.</xhtml:p> </fixtext>

			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:109601"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2009"><!--SNMP must not be deployed-->
			<title>snmp-adaptor.sar must not be deployed</title>
			<description>The file JBOSS_HOME/server/[PROFILE]/deploy/snmp-adaptor.sar should not exist. snmp-adaptor.sar is the default deployment package for JBoss SNMP.  The manager implements SNMP using joeSNMP, supporting only SNMP versions 1 and 2.</description>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">7.5</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:L/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">CM-6,CM-7</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>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/</xhtml:p><xhtml:p>If the exploded SAR exists, joeSNMP has been deployed and SNMP capabilities using this SNMP implementation still exist for the JBOSS server.</xhtml:p></profile-note>
			<fixtext><xhtml:p>Delete the directory JBOSS_HOME/server/[PROFILE]/deploy/snmp-adaptor.sar/</xhtml:p> </fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:200901"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_4011"><!--Harden Connector: limit maxPostSize-->
			<title>Harden Tomcat Connectors: limit maxPostSize</title>
			<description>The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the connectors can be taken quickly and easily. maxPostSize is the maximum size (in bytes) that the FORM URL parser can handle. Environments that pass large amounts of data through forms (such as file uploads), may need to increase this setting.</description>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">6.3</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:M/Au:S/C:N/I:N/A:C)</profile-note>
			<profile-note tag="nist_mapping">CM-6,CM-7</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>Review &lt;Connector&gt; elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check for &lt;Connector&gt; elements that define a maxPostSize attribute. If a maxPostSize attribute is defined, it should be 104857600 or less (100 MB).</xhtml:p></profile-note>
			<fixtext><xhtml:p>Ensure that all &lt;Connector&gt; elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured maxPostSize attributes (104857600 or less).</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:401101"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_4012"><!--Harden Connector: limit maxSavePostSize-->
			<title>Harden Tomcat Connectors: limit maxSavePostSize</title>
			<description>The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. maxSavePostSize is the maximum size (in bytes) that is buffered during CLIENT-CERT and FORM authentication. The default setting of 4096 (4 KB) is sufficient for most environments.</description>
			<rationale><xhtml:p>An overly high setting can inadvertently create a denial of service vulnerability in which many users are authenticated and tying up server resources.</xhtml:p></rationale>
			<profile-note tag="risk_score">6.3</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:M/Au:S/C:N/I:N/A:C)</profile-note>
			<profile-note tag="nist_mapping">CM-6,CM-7</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>Review &lt;Connector&gt; elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check for &lt;Connector&gt; elements that define a maxSavePostSize attribute. If a maxSavePostSize attribute is defined, it should be 12288 or less (12 KB).</xhtml:p></profile-note>
			<fixtext><xhtml:p>Ensure that all &lt;Connector&gt; elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured maxSavePostSize attributes (12288 or less).</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:401201"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_4013"><!--Harden Connector: set server header tags-->
			<title>Harden Tomcat Connectors: set server header tags</title>
			<description>The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. The server attribute controls the Server Header tag sent with each HTTP response. The default setting causes the server to return Apache-Coyote/1.1 with each HTTP response.</description>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">2.0</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="nist_mapping">CM-6,CM-7</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>Review &lt;Connector&gt; elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check each HTTP &lt;Connector&gt; 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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>Ensure that all HTTP &lt;Connector&gt; 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).</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:401301"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_4014"><!--Harden Connector: ciphers attribute-->
			<title>Harden Tomcat Connectors: ciphers attribute</title>
			<description>The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. The ciphers attribute controls the what ciphers are used to negotiate secure connections. The default setting causes the server to use the ciphers allowed by the running Java Virtual Machine.</description>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">6.0</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">CM-6,CM-7</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>Review &lt;Connector&gt; elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check each &lt;Connector&gt; element that contains a secure=true attribute. Ensure this connector does not define a ciphers attribute and instead inherits ciphers defined by the JVM.</xhtml:p></profile-note>
			<fixtext><xhtml:p>Ensure that all secure &lt;Connector&gt; elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have not defined cipher attributes.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:401401"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_4015"><!--Harden Connector: limit connectionTimeout-->
			<title>Harden Tomcat Connectors: limit connectionTimeout</title>
			<description>The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. connectionTimeout is the time (in milliseconds) that the container will wait for URI content after receiving a connection. The default setting is 60000.</description>
			<rationale><xhtml:p>An overly high setting can be easily exploited to create a denial of service condition by tying up server resources.</xhtml:p></rationale>
			<profile-note tag="risk_score">6.3</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:M/Au:S/C:N/I:N/A:C)</profile-note>
			<profile-note tag="nist_mapping">CM-6,CM-7</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>Review HTTP &lt;Connector&gt; 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).</xhtml:p></profile-note>
			<fixtext><xhtml:p>Ensure that all HTTP &lt;Connector&gt; elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured connectionTimeout attributes (20000 or less).</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:401501"/>
			</check>
		</Rule>
		
		
	</Group>
	

	<Group id="xccdf_com.redhat.eap5.scap_group_general_configuration_secure_platform" selected="false">
		<title>Securing JBoss platform</title>
		<description>The rules in this group are used to secure the JBoss platform and its dependencies.</description>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_2043"><!--Configure Java Security Manager to use an environment specific policy-->
			<title>Configure Java Security Manager to use an environment specific policy</title>
			<description>The Java Security Manager is a crucial piece of the Java security infrastructure. JBoss Enterprise Application Platform should be configured to load a Java security policy that has been vetted for use in the environment. This precludes the use of the simple default policy that ships with JBoss, but does not preclude the use of preconfigured policy files like the security policy designed for use in a Common Criteria environment (See JBoss Common Criteria Configuration Guide for details).</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">6.8</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:M/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">SA-13</profile-note>
			
			<fixtext><xhtml:p>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).</xhtml:p>
				<xhtml:pre><xhtml:code>JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==[PATH TO POLICY FILE]"</xhtml:code></xhtml:pre>
				<xhtml:p>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.</xhtml:p>
			</fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:204301"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_2051"><!--Ensure proper permissions are configured for interactions with JBoss JMX Kernel MBean-->
			<title>Ensure proper permissions are configured for interactions with JBoss JMX Kernel MBean</title>
			<description>Java permissions for MBeans should be carefully restricted to enforce the least privilege principle. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.</description>
			<reference>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</reference>
			<rationale>Java permissions for MBeans should be carefully restricted to enforce the least privilege principle. A JMX MBean server might have access to sensitive information and might be able to perform sensitive operations. JMX provides necessary access control that identifies which clients can access that information and who can perform those operations through the use of the Java Security Manager (JSM).  An MBean has a management interface consisting of Named and typed attributes that can be read and written, Named and typed operations that can be invoked and Typed notifications that can be emitted by the MBean.</rationale>
			
			<profile-note tag="validation_text"/>
			<profile-note tag="risk_score">3.7</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">AC-6</profile-note>
			<profile-note tag="disa_mapping">ECLP-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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):</xhtml:p>
				
				<xhtml:li>java.home/lib/security/java.security</xhtml:li>
				
				<xhtml:li>JBOSS_HOME/bin/security_cc.policy</xhtml:li>
				
				<xhtml:p>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)</xhtml:p>
				
				<xhtml:p>Review all JSM permissions granted to MBeans. Grant statements should be limited to specific users and specific methods.</xhtml:p>
				
				<xhtml:p>For example, permission A in the example below is allowed while permission B is not:</xhtml:p>
				<xhtml:pre><xhtml:code>//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";
}</xhtml:code></xhtml:pre></profile-note>
			<fixtext>The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for MBeans. This should be done in cooperation with system administrators, application developers and/or application documentation.</fixtext>			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:205101"/>
			</check>
		</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2052"><!--Ensure proper permissions are configured for deployed applications: java.io.FilePermission-->
			<title>Ensure proper permissions are configured for deployed applications: java.io.FilePermission</title>
			<description>Deployed applications must not be granted file permissions - except to those that are dedicated to the application only. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">6.2</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:C/I:C/A:C)</profile-note>
			<profile-note tag="nist_mapping">AC-6</profile-note>
			<profile-note tag="disa_mapping">ECLP-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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):</xhtml:p>
				<xhtml:ul><xhtml:li>java.home/lib/security/java.security</xhtml:li>
					<xhtml:li>JBOSS_HOME/bin/security_cc.policy</xhtml:li></xhtml:ul>
				
				<xhtml:p>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).
				</xhtml:p><xhtml:p>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.</xhtml:p> <xhtml:p>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.
				</xhtml:p>
				<xhtml:p>For example, permission A in the example below is allowed while permission B is not:</xhtml:p>
				<xhtml:pre><xhtml:code>//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";
};</xhtml:code></xhtml:pre> </profile-note>
			<fixtext>
				<xhtml:p>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.</xhtml:p>
				<xhtml:p>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.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:205201"/>
			</check>
		</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2053"><!--Ensure proper permissions are configured for deployed applications: java.net.NetPermission-->
			<title>Ensure proper permissions are configured for deployed applications: java.net.NetPermission</title>
			<description>Deployed applications must not be granted network permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.</description>
			<reference>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</reference>
			<rationale><xhtml:p>Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">5.2</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:P/I:P/A:C)</profile-note>
			<profile-note tag="nist_mapping">AC-6</profile-note>
			<profile-note tag="disa_mapping">ECLP-1</profile-note>					
			
				<profile-note tag="validation_text"><xhtml:p>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):</xhtml:p>
					<xhtml:ul><xhtml:li>java.home/lib/security/java.security</xhtml:li>
						<xhtml:li>JBOSS_HOME/bin/security_cc.policy</xhtml:li></xhtml:ul>
					<xhtml:p>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).
					</xhtml:p>
					<xhtml:p>Review all permissions granted to user deployed applications. Grant statements granting network permissions are not allowed and will look similar to the following:</xhtml:p>
					<xhtml:pre><xhtml:code>grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.net.NetPermission [specific permissions];
};</xhtml:code></xhtml:pre> </profile-note>
				<fixtext><xhtml:p>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.</xhtml:p>
					<xhtml:p>Permissions granted to applications via java.net.NetPermission should be removed.</xhtml:p> </fixtext>
				
				<check system="http://scap.nist.gov/schema/ocil/2">
					<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:205301"/>
				</check>
		</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2054"><!--Ensure proper permissions are configured for deployed applications: java.lang.RuntimePermission-->
			<title>Ensure proper permissions are configured for deployed applications: java.lang.RuntimePermission</title>
			<description>Deployed applications must not be granted runtime permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">6.2</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:C/I:C/A:C)</profile-note>
			<profile-note tag="nist_mapping">AC-6</profile-note>
			<profile-note tag="disa_mapping">ECLP-1</profile-note>
				<profile-note tag="validation_text"><xhtml:p>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):</xhtml:p>
					<xhtml:ul><xhtml:li>java.home/lib/security/java.security</xhtml:li>
						<xhtml:li>JBOSS_HOME/bin/security_cc.policy</xhtml:li></xhtml:ul>
					<xhtml:p>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)</xhtml:p>
					<xhtml:p>Review all permissions granted to user deployed applications. Grant statements granting runtime permissions are not allowed and will look similar to the following:</xhtml:p>
					<xhtml:pre><xhtml:code>grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.lang.RuntimePermission [specific permissions];
};</xhtml:code></xhtml:pre> </profile-note>
				<fixtext><xhtml:p>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.</xhtml:p>
					<xhtml:p>Permissions granted to applications via java.lang.RuntimePermission should be removed.</xhtml:p> </fixtext>
				
				<check system="http://scap.nist.gov/schema/ocil/2">
					<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:205401"/>
				</check>
			</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2055"><!--Ensure proper permissions are configured for deployed applications: java.net.SocketPermission-->
			<title>Ensure proper permissions are configured for deployed applications: java.net.SocketPermission</title>
			<description>Deployed applications must not be granted any socket permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.).</xhtml:p></rationale>
			
			<profile-note tag="risk_score">6.2</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:C/I:C/A:C)</profile-note>
			<profile-note tag="nist_mapping">AC-6</profile-note>
			<profile-note tag="disa_mapping">ECLP-1</profile-note>
				<profile-note tag="validation_text"><xhtml:p>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):</xhtml:p>
					<xhtml:ul><xhtml:li>java.home/lib/security/java.security</xhtml:li>
						<xhtml:li>JBOSS_HOME/bin/security_cc.policy</xhtml:li></xhtml:ul>
					<xhtml:p>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)
					</xhtml:p><xhtml:p>Review all permissions granted to user deployed applications. Grant statements granting socket permissions are not allowed and will look similar to the following:
					</xhtml:p>
					<xhtml:pre><xhtml:code>grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.net.SocketPermission [specific permissions];
};</xhtml:code></xhtml:pre> </profile-note>
				<fixtext><xhtml:p>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.</xhtml:p>
					<xhtml:p>Permissions granted to applications via java.net.SocketPermission should be removed.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:205501"/>
			</check>
		</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2056"><!--Ensure proper permissions are configured for deployed applications: java.security.AllPermission-->
			<title>Ensure proper permissions are configured for deployed applications: java.security.AllPermission</title>
			<description>Deployed applications must not be granted all permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">6.2</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:C/I:C/A:C)</profile-note>
			<profile-note tag="nist_mapping">AC-6</profile-note>
			<profile-note tag="disa_mapping">ECLP-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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):</xhtml:p>
					<xhtml:ul><xhtml:li>java.home/lib/security/java.security</xhtml:li>
						<xhtml:li>JBOSS_HOME/bin/security_cc.policy</xhtml:li></xhtml:ul>
					<xhtml:p>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)
					</xhtml:p><xhtml:p>Review all permissions granted to user deployed applications. Grant statements granting AllPermission are not allowed and will look similar to the following:
					</xhtml:p>
					<xhtml:pre><xhtml:code>grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.security.AllPermission;
};</xhtml:code></xhtml:pre> </profile-note>
			<fixtext><xhtml:p>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.</xhtml:p>
				<xhtml:p>Permissions granted to applications via java.security.AllPermission should be removed.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:205601"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_2028"><!--Ensure default system JAAS configuration is in use for JBoss Seam-->
			<title>Ensure default system Java Authentication and Authorization Service configuration is in use for JBoss Seam</title>
			<description>For JBoss Seam, the simplified Java Authentication and Authorization Service configuration provided by the Seam Security API must not be used. The default system JAAS configuration should be used instead. Using the default system JAAS configuration ensures user identification and authentication are performed by the JBoss Enterprise Application Platform. JBoss Seam provides additional interfaces for implementing other security functions such as authorization (for example, entity bean permissions). This functionality is controlled by JBoss Seam, and is therefore outside the scope of the evaluated product.</description>
			<reference>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</reference>
			<rationale><xhtml:p>Using an administrator specified JAAS configuration enables a more rigorous security posture.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">5.5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>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.</xhtml:p><xhtml:p>Within components.xml, the security identity should specify a JAAS security domain to override the default Seam configuration. See the example below:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;security:identity jaas-config-name="[security domain]"/&gt;</xhtml:code></xhtml:pre>
				<xhtml:p>The security domain must map to a valid JAAS security domain.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>Within components.xml, the security identity should specify a JAAS security domain to override the default Seam configuration. See the example below:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;security:identity jaas-config-name="[security domain]"/&gt;</xhtml:code></xhtml:pre>
				<xhtml:p>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.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:202801"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_2060"><!--Validate a password-protected JBoss keystore is configured in a loaded policy file-->
			<title>Validate keystore and keystorePasswordURL properties are defined and loaded by Java Security Manager</title>
			<description><xhtml:p>Ensure keystore and keystorePasswordURL properties exist and are loaded by Java Security Manager.</xhtml:p></description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">2.4</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:S/C:P/I:P/A:N)</profile-note>
			<profile-note tag="nist_mapping">SC-28,IA-5</profile-note>
			<profile-note tag="disa_mapping">ECCR-1,ECCR-2,ECCR-3,IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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:</xhtml:p>
				<xhtml:pre><xhtml:code>keystore "file:[PATH TO KEYSTORE]";
keystorePasswordURL "file:[PATH TO PASSWORD FILE]";</xhtml:code></xhtml:pre>
				<xhtml:p>NOTE: The file names and paths may vary.</xhtml:p></profile-note>
			<fixtext><xhtml:p>Add the following lines to any loaded policy file:</xhtml:p>
				<xhtml:pre><xhtml:code>keystore "file:[DESIRED PATH TO KEYSTORE]";
keystorePasswordURL "file:[DESIRED PATH TO PASSWORD FILE]";</xhtml:code></xhtml:pre>
				<xhtml:p>A typical configuration may look like the following:</xhtml:p>
				<xhtml:pre><xhtml:code>keystore "file:${JBoss.server.home.dir}/cc.keystore";
keystorePasswordURL "file:${JBoss.server.home.dir}/cc.password";</xhtml:code></xhtml:pre>
				<xhtml:p>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.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:206001"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2059"><!--Validate a keystore file for JBoss exists and is accessible to JBoss-->
			<title>Validate a keystore file for JBoss exists and is accessible to JBoss</title>
			<description>Validate a keystore for JBoss exists and is accessible to JBoss.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>		
			<profile-note tag="risk_score">3.5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">SC-8,IA-5</profile-note>
			<profile-note tag="disa_mapping">ECTM-1,ECTM-2,IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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:</xhtml:p>
				<xhtml:pre><xhtml:code>keystore "file:[PATH TO KEYSTORE]";</xhtml:code></xhtml:pre>
				<xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>To create a JBoss keystore, run the following command (you will be prompted to create a password):</xhtml:p>
				<xhtml:pre><xhtml:code>keytool -importcert -alias jboss -keystore [PATH TO KEYSTORE AS DEFINED IN POLICY FILE] -file [PATH TO TRUSTED CERTIFICATE TO IMPORT] -noprompt -trustcacerts</xhtml:code></xhtml:pre>
				<xhtml:p>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.</xhtml:p>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:205901"/>
			</check>
		</Rule>
								
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2160"><!--Validate a password file for keystore exists and is accessible to JBoss-->
			<title>Validate a password file for the Java keystore exists and is accessible to JBoss</title>
			<description><xhtml:p>Validate a password file for the keystore defined in the properties file exists and is accessible to JBoss.</xhtml:p></description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">3.7</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">SC-28,IA-5</profile-note>
			<profile-note tag="disa_mapping">ECCR-1,ECCR-2,ECCR-3,IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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:</xhtml:p>
			<xhtml:pre><xhtml:code>keystorePasswordURL "file:[PATH TO KEYSTORE PASSWORD FILE]";</xhtml:code></xhtml:pre>
			<xhtml:p>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. </xhtml:p></profile-note>
			<fixtext><xhtml:p>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.</xhtml:p>
			<xhtml:p>First, ensure the password file location is identified in the policy file being loaded by the Java Security Manager:</xhtml:p>
			<xhtml:pre><xhtml:code>keystorePasswordURL "file:[DESIRED PATH TO KEYSTORE PASSWORD FILE]";</xhtml:code></xhtml:pre>
			<xhtml:p>Next, add the plain-text password to file whose location you just defined.</xhtml:p>
			<xhtml:p>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.</xhtml:p>
			</fixtext>
		
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:216001"/>
			</check>
		</Rule>
	
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2158"><!--Validate JBoss keystore is password protected-->
			<title>Validate JBoss keystore is password protected</title>
			<description>Validate the keystore loaded by the Java Security Manager is password protected. Password protecting the Java keystore used by JBoss issued to protect the integrity of the keystore.  It does not prevent listing the content, but it does prevent modification of the keystore.  Private keys within the keystore are still protected by their own passwords to prevent disclosure.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">3.7</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">SC-28,IA-5</profile-note>
			<profile-note tag="disa_mapping">ECCR-1,ECCR-2,ECCR-3,IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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:</xhtml:p>
				<xhtml:pre><xhtml:code>keystore "file:${JBoss.server.home.dir}/cc.keystore";</xhtml:code></xhtml:pre>
				<xhtml:p>Next, access the contents of the keystore using the following command:</xhtml:p>
				<xhtml:pre><xhtml:code>keytool -list -keystore [PATH TO KEYSTORE]</xhtml:code></xhtml:pre>
				<xhtml:p>You should be prompted for a password (non-blank).</xhtml:p></profile-note>
			<fixtext><xhtml:p>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:</xhtml:p>
				<xhtml:pre><xhtml:code>keystore "file:[PATH TO KEYSTORE]";</xhtml:code></xhtml:pre>
				<xhtml:p>Add a password to the keystore:</xhtml:p>
				<xhtml:pre><xhtml:code>keytool -storepasswd -keystore [PATH TO KEYSTORE]</xhtml:code></xhtml:pre></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:215801"/>
			</check>
		</Rule>
	
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2061"><!--Ensure jboss alias is trusted within the JBoss keystore-->
			<title>Ensure jboss alias is trusted within the JBoss keystore</title>
			<description>The jboss alias must be a trustedCertEntry with the JBoss Java keystore. This allows code signed by with the default JBoss certificate to run when using a restrictive policy file.</description>
			<reference>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</reference>
			<rationale><xhtml:p>A keystore should be setup for production environments with JBoss as a trustedCertEntry for proper functioning of the JBoss Enterprise Application Platform.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">2.4</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:S/C:P/I:P/A:N)</profile-note>
			<profile-note tag="nist_mapping">IA-5</profile-note>
			<profile-note tag="disa_mapping">IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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:</xhtml:p>
				<xhtml:pre><xhtml:code>keystore "file:${JBoss.server.home.dir}/cc.keystore";</xhtml:code></xhtml:pre>
				<xhtml:p>Next, list the contents of the keystore using the following command:</xhtml:p>
				<xhtml:pre><xhtml:code>keytool -list -keystore [PATH TO KEYSTORE]</xhtml:code></xhtml:pre>
				<xhtml:p>The jboss alias must exist as a trustedCertEntry.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>To ensure the Jboss alias is a trustedCertEntry, the certificate must be imported to the keystore with the proper command:</xhtml:p>
				<xhtml:pre><xhtml:code>keytool -importcert -alias jboss -keystore [PATH TO KEYSTORE] -file JBOSS_HOME/bin/JBossPublicKey.RSA -noprompt -trustcacerts</xhtml:code></xhtml:pre>
				<xhtml:p>You can check the result with the following keytool command:</xhtml:p>
				<xhtml:pre><xhtml:code>keytool -list -keystore [PATH TO KEYSTORE]</xhtml:code></xhtml:pre>
				<xhtml:p>You should get similar results to those below:</xhtml:p>
				<xhtml:pre><xhtml:code>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</xhtml:code></xhtml:pre>
				
				<xhtml:p>Alternatively, the Jboss public key can be added to the Java keystore:</xhtml:p>
				<xhtml:pre><xhtml:code>keytool -importcert -alias jboss -keystore JAVA_HOME/jre/lib/security/cacerts -storepass changeit -file JBOSS_HOME/bin/JBossPublicKey.RSA -noprompt -trustcacerts</xhtml:code></xhtml:pre>
				<xhtml:p>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.</xhtml:p>
				<xhtml:pre><xhtml:code>keytool -storepasswd -keystore JAVA_HOME/jre/lib/security/cacerts</xhtml:code></xhtml:pre> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:206101"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_4005"><!--Ensure applications deployed by JBoss present valid DoD certificates where applicable-->
			<title>Ensure applications deployed by JBoss present valid DoD certificates where applicable</title>
			<description><xhtml:p>JBoss applications implementing encryption should present a valid DoD issued X.509 certificate for purposes of identifying the server.</xhtml:p></description>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">3.5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">IA-5</profile-note>
			<profile-note tag="disa_mapping">IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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:</xhtml:p>
				<xhtml:p>
					<xhtml:ul>
						<xhtml:li>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.</xhtml:li>
						<xhtml:li>The certificate must not be expired. This can be determined by reviewing the expiration dates on the server's certificate.</xhtml:li>
						<xhtml:li>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: <xhtml:a href="https://crl.gds.disa.mil/">https://crl.gds.disa.mil/</xhtml:a></xhtml:li>
						<xhtml:li>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.</xhtml:li>
						<xhtml:li>The certificate public key length must be at least 1024 bits.</xhtml:li>
					</xhtml:ul>
				</xhtml:p>
			</profile-note>
			<fixtext><xhtml:p>The JBoss administrator must work with the local security manager and certificate registrar to successfully request a certificate from a DoD Certificate Authority.</xhtml:p>
				<xhtml:p>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. 
					<xhtml:pre><xhtml:code>keytool -importkeystore -v -srckeystore KEYSTORE.p12 -srcstoretype PKCS12 -keystore NEW_KEYSTORE.jks</xhtml:code></xhtml:pre>
				</xhtml:p>
				<xhtml:p>The final step is to enable TLS on whichever Tomcat connector is used by the deployed application.</xhtml:p>
				<xhtml:pre><xhtml:code>
&lt;Connector protocol=&quot;HTTP/1.1&quot; SSLEnabled=&quot;true&quot;
	port=&quot;8443&quot; address=&quot;${jboss.bind.address}&quot;
	scheme=&quot;https&quot; secure=&quot;true&quot; clientAuth=&quot;false&quot;
	keystoreFile=&quot;${jboss.server.home.dir}/conf/NEW_KEYSTORE.jks&quot;
	keystorePass=&quot;KEYSTORE_PASSWORD&quot; sslProtocol = &quot;TLS&quot; /&gt;
				</xhtml:code></xhtml:pre>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:400501"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_4006"><!--Ensure JBoss trust store contains DoD approved Certificate Authorities-->
			<title>Ensure X.509 keystore utilized by JBoss for certificate trusts contains DoD approved Certificate Authorities</title>
			<description><xhtml:p>JBoss applications implementing encryption should utilize the DoD Public Key Infrastructure.</xhtml:p></description>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">3.5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">IA-5</profile-note>
			<profile-note tag="disa_mapping">IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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:</xhtml:p>
				<xhtml:pre><xhtml:code>keystore "file:${JBoss.server.home.dir}/jboss.keystore";</xhtml:code></xhtml:pre>
				<xhtml:p>List the contents of the keystore using the following command:</xhtml:p>
				<xhtml:pre><xhtml:code>keytool -list -keystore [PATH TO KEYSTORE]</xhtml:code></xhtml:pre>
				<xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>Download and install the DoD CA certificates. Currently, the CA certificates can be retrieved from https://crl.gds.disa.mil/.</xhtml:p>
			<xhtml:p>The keys can be added to the keystore with a command similar to the following:</xhtml:p>
				<xhtml:pre><xhtml:code>keytool -importcert -keystore [PATH TO KEYSTORE] -storepass [KEYSTORE PASSWORD] -file [PATH TO CERTIFICATE] -noprompt -trustcacerts</xhtml:code></xhtml:pre>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:400601"/>
			</check>
		</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_4007"><!--Ensure deployed applications requiring authentication utilizes DoD PKI Class 3 or Class 4 certificate and hardware security token or NSA-certified product (cert-based module)-->
			<title>Ensure deployed applications requiring authentication utilizes DoD PKI Class 3 or Class 4 certificate and hardware security token or NSA-certified product</title>
			<description><xhtml:p>JBoss applications implementing authentication should utilize the DoD Public Key Infrastructure. The DoD Public Key Infrastructure is designed to use hardware tokens such as the Common Access Card in conjunction with issued X.509 certificates.  These tokens are typically protected with a PIN that unlocks access to the private certificate stored on the token.</xhtml:p></description>
			<reference>JBoss Enterprise Application Platform Security Guide, 2011</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">IA-5</profile-note>
			<profile-note tag="disa_mapping">IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p>
				<xhtml:p>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:</xhtml:p>
				<xhtml:p><xhtml:pre><xhtml:code>&lt;security-domain&gt;java:/jaas/JBossTestRealm&lt;/security-domain&gt;</xhtml:code></xhtml:pre></xhtml:p>
				<xhtml:p>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 &lt;auth-method&gt; element MUST contain CLIENT-CERT in order to implement certificate-based authentication. For example:</xhtml:p>
				<xhtml:p><xhtml:pre><xhtml:code>&lt;security-constraint&gt;
	&lt;web-resource-collection&gt;
		&lt;web-resource-name&gt;TestResource&lt;/web-resource-name&gt;
		&lt;url-pattern&gt;/*&lt;/url-pattern&gt;
	&lt;/web-resource-collection&gt;
	&lt;auth-constraint&gt;
		&lt;role-name&gt;JBossTestRole&lt;/role-name&gt;
	&lt;/auth-constraint&gt;
&lt;/security-constraint&gt;
	
&lt;login-config&gt;
	&lt;auth-method&gt;CLIENT-CERT&lt;/auth-method&gt;
	&lt;realm-name&gt;Test realm&lt;/realm-name&gt;
&lt;/login-config&gt;

&lt;security-role&gt;
	&lt;role-name&gt;JBossTestRole&lt;/role-name&gt;
&lt;/security-role&gt;</xhtml:code></xhtml:pre></xhtml:p>
					<xhtml:p>Next, ensure that an &lt;application-policy&gt; element is defined that matches the &lt;security-domain&gt; referenced by the jboss-web.xml file. These &lt;application-policy&gt; can be defined
						in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.</xhtml:p>
					<xhtml:p><xhtml:ul>
						<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
						<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml</xhtml:li>
						<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml</xhtml:li>
						<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul></xhtml:p>
				<xhtml:p>Check the &lt;application-policy&gt; element to ensure it has modules defined for authentication. This &lt;login-module&gt; MUST contain the following attributes:</xhtml:p><xhtml:p><xhtml:ul><xhtml:li>code="org.jboss.security.auth.spi.BaseCertLoginModule"</xhtml:li><xhtml:li>flag="required"</xhtml:li></xhtml:ul></xhtml:p>
					<xhtml:p>Example of a satisfactory element:</xhtml:p>
						<xhtml:pre><xhtml:code>&lt;application-policy name="JBossTestRealm"&gt;
	&lt;authentication&gt;
		&lt;login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"&gt;
			&lt;module-option name="usersProperties"&gt;testUsers.properties&lt;/module-option&gt;
			&lt;module-option name="rolesProperties"&gt;testRoles.properties&lt;/module-option&gt;
		&lt;/login-module&gt;
	&lt;/authentication&gt;
&lt;/application-policy&gt;</xhtml:code></xhtml:pre>
				<xhtml:p>Additional modules can be included to shape the exact functionality desired.  For example, &lt;module&gt;s such as SubjectCNMapping can be included to perform attribute mapping.</xhtml:p>
				<xhtml:p>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:</xhtml:p>
<xhtml:pre><xhtml:code>&lt;mbean code=&quot;org.jboss.security.plugins.JaasSecurityDomain&quot; name=&quot;jboss.ch8:service=SecurityDomain&quot;&gt;
	&lt;constructor&gt;
		&lt;arg type=&quot;java.lang.String&quot; value=&quot;JBossTestRealm&quot;/&gt;
	&lt;/constructor&gt;
	&lt;attribute name=&quot;KeyStoreURL&quot;&gt;resource:localhost.keystore&lt;/attribute&gt;
	&lt;attribute name=&quot;KeyStorePass&quot;&gt;cleartext-password-that-should-be-masked&lt;/attribute&gt;
&lt;/mbean&gt;</xhtml:code></xhtml:pre></profile-note>
			<fixtext><xhtml:p>First, setup an &lt;application-policy&gt; that enforces certificate-based authentication.  This can be accomplished in the following files:</xhtml:p>
				<xhtml:p><xhtml:ul>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul></xhtml:p>
				<xhtml:p>The &lt;application-policy&gt; should resemble the example below:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;application-policy name="JBossTestRealm"&gt;
	&lt;authentication&gt;
		&lt;login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"&gt;
			&lt;module-option name="usersProperties"&gt;testUsers.properties&lt;/module-option&gt;
			&lt;module-option name="rolesProperties"&gt;testRoles.properties&lt;/module-option&gt;
		&lt;/login-module&gt;
	&lt;/authentication&gt;
&lt;/application-policy&gt;</xhtml:code></xhtml:pre>
				<xhtml:p>Next, add the &lt;application-policy&gt; to the deployment descriptors and setup the &lt;security-constraint&gt;.</xhtml:p>
				
				<xhtml:p>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml</xhtml:p>
				<xhtml:p><xhtml:pre><xhtml:code>&lt;security-domain&gt;java:/jaas/JBossTestRealm&lt;/security-domain&gt;</xhtml:code></xhtml:pre></xhtml:p>
				<xhtml:p>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/web.xml</xhtml:p>
				<xhtml:p><xhtml:pre><xhtml:code>&lt;security-constraint&gt;
	&lt;web-resource-collection&gt;
		&lt;web-resource-name&gt;TestResource&lt;/web-resource-name&gt;
		&lt;url-pattern&gt;/*&lt;/url-pattern&gt;
	&lt;/web-resource-collection&gt;
	
	&lt;auth-constraint&gt;
		&lt;role-name&gt;JBossTestRole&lt;/role-name&gt;
	&lt;/auth-constraint&gt;
&lt;/security-constraint&gt;
					
&lt;login-config&gt;
	&lt;auth-method&gt;CLIENT-CERT&lt;/auth-method&gt;
	&lt;realm-name&gt;Test realm&lt;/realm-name&gt;
&lt;/login-config&gt;
					
&lt;security-role&gt;
	&lt;role-name&gt;JBossTestRole&lt;/role-name&gt;
&lt;/security-role&gt;</xhtml:code></xhtml:pre></xhtml:p>
				<xhtml:p>Define a keystore to be used via the JaasSecurityDomain MBean:</xhtml:p>
				<xhtml:p>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/jboss-service.xml:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;mbean code=&quot;org.jboss.security.plugins.JaasSecurityDomain&quot; name=&quot;jboss.ch8:service=SecurityDomain&quot;&gt;
	&lt;constructor&gt;
		&lt;arg type=&quot;java.lang.String&quot; value=&quot;JBossTestRealm&quot;/&gt;
	&lt;/constructor&gt;
	
	&lt;attribute name=&quot;KeyStoreURL&quot;&gt;resource:test.keystore&lt;/attribute&gt;
	&lt;attribute name=&quot;KeyStorePass&quot;&gt;cleartext-password-that-should-be-masked&lt;/attribute&gt;
&lt;/mbean&gt;</xhtml:code></xhtml:pre>				
				<xhtml:p>Finally, import the client certificates into the keystore using the keytool command. For example:</xhtml:p>
				<xhtml:pre><xhtml:code>keytool -importcert -alias "DN ON THE CERTIFICATE" -keystore JBOSS_HOME/server/[PROFILE]/conf/test.keystore -file [PATH TO CERTIFICATE]</xhtml:code></xhtml:pre></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:400701"/>
			</check>				
		</Rule>
		
		<!--Ensure revocation checking is configured for two-way X.509 certificate exchanges-->
		
		<!--<Rule id="xccdf_com.redhat.eap5.scap_rule_4009">
			<title>Enable Federal Information and Processing Systems 140-2 (FIPS) compliant cryptographic modules for JBoss Tomcat connectors</title>
			<description>While JBoss itself has no need to load FIPS compliant modules, the underlying technologies such as Java and the Apache Tomcat webcontainer do. Utilizing only FIPS compliant modules decreases compatibility with applications that are not FIPS enabled.</description>
			<rationale><xhtml:p>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.</xhtml:p> </rationale>				
			<profile-note tag="risk_score">4.0</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">SC-13</profile-note>
			<profile-note tag="disa_mapping">DCNR-1,ECCR-1,ECCR-2,ECCR-3,ECCT-1,ECCT-2,ECNK-1,ECNK-2</profile-note>
			<profile-note tag="validation_text"></profile-note>
			<fixtext></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:400801"/>
			</check>
		</Rule>-->
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_4008"><!--Enable Federal Information and Processing Systems 140-2 (FIPS) compliant cryptographic modules for use by JBoss Java environment-->
			<title>Enable Federal Information and Processing Systems 140-2 (FIPS) compliant cryptographic modules for use by JBoss Java environment</title>
			<description>While JBoss itself has no need to load FIPS compliant modules, the underlying technologies such as Java and the Apache Tomcat webcontainer do. Utilizing only FIPS compliant modules decreases compatibility with applications that are not FIPS enabled.</description>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011 </reference>
			<rationale><xhtml:p>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.</xhtml:p> </rationale>				
			<profile-note tag="risk_score">4.0</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">SC-13</profile-note>
			<profile-note tag="disa_mapping">DCNR-1,ECCR-1,ECCR-2,ECCR-3,ECCT-1,ECCT-2,ECNK-1,ECNK-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Validating this rule is a multi-step process.</xhtml:p><xhtml:ol><xhtml:li>First, ensure that the FIPS compliant providers are enabled in the Java security files.
				<xhtml:p>For IBM JRE/JDK 6.x:</xhtml:p>
				<xhtml:p>Check for the following provider in the JAVA_HOME/jre/lib/security/java.security file:</xhtml:p>
				<xhtml:p><xhtml:ul><xhtml:li>security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPS</xhtml:li></xhtml:ul></xhtml:p>
				<xhtml:p>NOTE: The FIPS compliant provider MUST be at the top of the list as #1.</xhtml:p>
				<xhtml:p>Ensure the following line exists in the System.Defaults properties file:</xhtml:p><xhtml:p><xhtml:ul><xhtml:li>com.ibm.jsse2.usefipsprovider=true</xhtml:li></xhtml:ul></xhtml:p>
				<xhtml:p>Finally, ensure the following two properties are defined in JAVA_HOME/jre/lib/security/java.security:</xhtml:p><xhtml:p><xhtml:ul><xhtml:li>ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl</xhtml:li><xhtml:li>ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl</xhtml:li></xhtml:ul></xhtml:p>
				<xhtml:p>For Sun JRE/JDK 6.x:</xhtml:p>
				<xhtml:p>Check for the following providers in the JAVA_HOME/jre/lib/security/java.security file:</xhtml:p>
				<xhtml:p><xhtml:ul><xhtml:li>security.provider.1=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS</xhtml:li></xhtml:ul></xhtml:p>
				<xhtml:p>NOTE: The FIPS compliant provider MUST be at the top of the list as #1</xhtml:p>
				<xhtml:p>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.</xhtml:p>
			</xhtml:li>
				<xhtml:li>Lastly, perform a packet capture of the TLS handshake to ensure that only FIPS 140-2 algorithms are selected by the server (ServerHello message).</xhtml:li>
			</xhtml:ol>
			</profile-note>
			<fixtext><xhtml:p>As this check is not specific to JBoss, validation steps will vary dependent on the Java vendor in use.</xhtml:p>
				<xhtml:p>For IBM JRE/JDK 6.x:</xhtml:p>
				<xhtml:p>Add the following provider to the JAVA_HOME/jre/lib/security/java.security file:</xhtml:p>
				<xhtml:p><xhtml:ul><xhtml:li>security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPS</xhtml:li></xhtml:ul></xhtml:p>
				<xhtml:p>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.</xhtml:p>
				<xhtml:p>Ensure the following line exists in the System.Defaults properties file:</xhtml:p><xhtml:p><xhtml:ul><xhtml:li>com.ibm.jsse2.usefipsprovider=true</xhtml:li></xhtml:ul></xhtml:p>
				<xhtml:p>Finally, ensure the following two properties are defined in JAVA_HOME/jre/lib/security/java.security:</xhtml:p><xhtml:p><xhtml:ul><xhtml:li>ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl</xhtml:li><xhtml:li>ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl</xhtml:li></xhtml:ul></xhtml:p>
				<xhtml:p>For Sun JRE/JDK 6.x:</xhtml:p>
				<xhtml:p>Add the following provider to the JAVA_HOME/jre/lib/security/java.security file:</xhtml:p>
				<xhtml:p><xhtml:ul><xhtml:li>security.provider.1=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS</xhtml:li></xhtml:ul></xhtml:p>
				<xhtml:p>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.</xhtml:p>
				<xhtml:p>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.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:400801"/>
			</check>
		</Rule>	
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1136"><!--Eliminate clear-text passwords: data sources-->
			<title>Eliminate clear-text passwords: data sources</title>
			<description>Eliminate clear-text passwords in data source configuration files. The class org.jboss.resource.security.SecureIdentityLoginModule can be used to both encrypt database passwords and to provide a decrypted version of the password when the data source configuration is required by the server. The SecureIdentityLoginModule uses a hard-coded password to encrypt/decrypt the data source password.</description>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011 </reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>		
			<profile-note tag="risk_score">3.7</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">SC-28</profile-note>
			<profile-note tag="disa_mapping">ECCR-1,ECCR-2,ECCR-3</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Review data source file located within JBOSS_HOME/server/deploy/ and subdirectories. Data sources with encrypted passwords will no longer have &lt;user-name&gt; or &lt;password&gt; elements, and will instead reference a &lt;security-domain&gt;.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>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:</xhtml:p>
				<xhtml:ul><xhtml:li>Encrypt the data source password.</xhtml:li>
					<xhtml:li>Create an application authentication policy with the encrypted password.</xhtml:li>
					<xhtml:li>Configure the data source to use the application authentication policy.</xhtml:li></xhtml:ul> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:113601"/>
			</check>
		</Rule>		
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1163"><!--Eliminate clear-text passwords: Tomcat Connectors-->
			<title>Eliminate clear-text passwords: Tomcat Connectors</title>
			<description>Eliminate clear-text passwords in: Tomcat Connectors.</description>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011 </reference>
			<rationale><xhtml:p>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.</xhtml:p> </rationale>
			<profile-note tag="risk_score">3.7</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">SC-28</profile-note>
			<profile-note tag="disa_mapping">ECCR-1,ECCR-2,ECCR-3</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Review JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml for evidence of clear-text passwords in Connectors. These Connectors will contain a &lt;attribute name="KeyStorePass"&gt; or a keystorePass attribute as part of the &lt;Connector&gt; element, with a clear-text password. </xhtml:p></profile-note>
			<fixtext><xhtml:p>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:</xhtml:p>
					<xhtml:ul><xhtml:li>Configure JaasSecurityDomain MBean</xhtml:li>
						<xhtml:li>Generate encrypted password</xhtml:li>
						<xhtml:li>Update the Tomcat service MBean</xhtml:li> </xhtml:ul></fixtext>
				
				<check system="http://scap.nist.gov/schema/ocil/2">
					<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:116301"/>
				</check>
		</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1165"><!--Eliminate clear-text passwords: XML configuration files-->
			<title>Eliminate clear-text passwords: XML configuration files</title>
			<description>Using password masking, eliminate clear-text passwords in XML configuration files.</description>
			<reference>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</reference>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">3.7</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">SC-28</profile-note>
			<profile-note tag="disa_mapping">ECCR-1,ECCR-2,ECCR-3</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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).</xhtml:p></profile-note>
			<fixtext><xhtml:p>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.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:116501"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_4002"><!--Change default password: JBoss Messaging MessageSucker-->
			<title>Change default password: JBoss Messaging MessageSucker</title>
			<description><xhtml:p>JBoss Messaging ships with a default MessageSucker password located within the Messaging ServerPeer configuration. This password is used by JBoss to create connections and pass messages between nodes.</xhtml:p></description>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011 </reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">7.5</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:L/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">IA-5</profile-note>
			<profile-note tag="disa_mapping">IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Review the Jboss Messaging configuration file for the Messaging ServerPeer located here:</xhtml:p>
				
				JBOSS_HOME/server[PROFILE]/deploy/messaging/messaging-jboss-beans.xml
				
				<xhtml:p>Ensure the &lt;property name="suckerPassword" &gt; has been changed from the default of "CHANGE ME!".</xhtml:p></profile-note>
			<fixtext><xhtml:p>Open the Jboss Messaging configuration file for the Messaging ServerPeer located here:</xhtml:p> 
				
				JBOSS_HOME/server[PROFILE]/deploy/messaging/messaging-jboss-beans.xml
				
				<xhtml:p>Locate the element &lt;property name="suckerPassword" &gt; 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 &lt;'&gt;@" or escaping them if you do. For example:</xhtml:p>
				
				<xhtml:p>&lt;property name="suckerPassword" &gt;Lmf3SdntiDFF6(D5&lt;/property&gt;</xhtml:p>

				<xhtml:p>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.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:400201"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_4003"><!--Change default password: Java cacerts keystore-->
			<title>Change default password: Java cacerts keystore</title>
			<description><xhtml:p>The Java cacerts keystore is installed by default with most versions of Java. It contains X.509 public certificates for a set of default commercial Certificate Authorities.</xhtml:p></description>
			<rationale><xhtml:p>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.</xhtml:p><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">2.6</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:P/I:P/A:N)</profile-note>
			<profile-note tag="nist_mapping">IA-5</profile-note>
			<profile-note tag="disa_mapping">IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Attempt to access the contents of the Java cacerts keystore at the default location using the following command:</xhtml:p>
			<xhtml:pre><xhtml:code>keytool -list -keystore JAVA_HOME/lib/security/cacerts</xhtml:code></xhtml:pre>
			<xhtml:p>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.</xhtml:p>
			<xhtml:p>You should be prompted for a password (non-blank). Attempt to authenticate using the default password 'changeit'</xhtml:p>
			<xhtml:p>If you fail to authenticate, you will receive a warning message (and the contents of the keystore will still be displayed):</xhtml:p>
			<xhtml:p>***************** WARNING WARNING WARNING *****************</xhtml:p>
			<xhtml:p>* The integrity of the information stored in your keystore *</xhtml:p>
			<xhtml:p>* has NOT been verified! In order to verify its integrity, *</xhtml:p>
			<xhtml:p>* you must provide your keystore password.         *</xhtml:p>
			<xhtml:p>***************** WARNING WARNING WARNING *****************</xhtml:p>
			<xhtml:p>Using the default password 'changeit' should fail to authenticate and thus produce the warning. If the default password successfully authenticates, this check fails.</xhtml:p>
			</profile-note>
			<fixtext><xhtml:p>Add a password to the default Java cacerts keystore:</xhtml:p>
				<xhtml:pre><xhtml:code>keytool -storepasswd -keystore [PATH TO KEYSTORE]</xhtml:code></xhtml:pre>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:400301"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_2019"><!--Ensure Security Audit Appender is enabled-->
			<title>Ensure Security Audit Appender is enabled</title>
			<description>The Security Audit Appender must be enabled. The Security Audit Appender and the Security Audit Provider category together set up the audit infrastructure that allows deployed applications to easily audit authentication and authorization events. </description>
			<reference>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</reference>
			<rationale><xhtml:p>Enabling the Security Audit Appender is a necessary component of comprehensive auditing in a secure production environment.</xhtml:p></rationale>
			<profile-note tag="risk_score">4</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">AU-12</profile-note>
			<profile-note tag="disa_mapping">ECAT-1,ECAT-2</profile-note>
			<fixtext><xhtml:p>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.</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;!-- Security AUDIT Appender --&gt;
&lt;appender name="AUDIT" class="org.jboss.logging.appender.DailyRollingFileAppender"&gt;
	&lt;errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/&gt;
	&lt;param name="File" value="${JBoss.server.log.dir}/audit.log"/&gt;
	&lt;param name="Append" value="true"/&gt;
	&lt;param name="DatePattern" value="'.'yyyy-MM-dd"/&gt;
	&lt;layout class="org.apache.log4j.PatternLayout"&gt;
		&lt;param name="ConversionPattern" value="%d %-5p [%c] (%t:%x) %m%n"/&gt;
	&lt;/layout&gt;
&lt;/appender&gt;</xhtml:code></xhtml:pre>
			</fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:201901"/>
			</check>
		</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2020"><!--Ensure Security Audit Provider is enabled-->
			<title>Ensure Security Audit Provider is enabled</title>
			<description>The Security Audit Provider category must be enabled for production environments. The Security Audit Appender and the Security Audit Provider category together set up the audit infrastructure that allows deployed applications to easily audit authentication and authorization events. </description>
			<reference>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</reference>
			<rationale><xhtml:p>Enabling the Security Audit Provider category is a necessary component of comprehensive auditing in a secure production environment.</xhtml:p>
				</rationale>
			<profile-note tag="risk_score">4</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>				
			<profile-note tag="nist_mapping">AU-12</profile-note>
			<profile-note tag="disa_mapping">ECAT-1,ECAT-2</profile-note>				
			<fixtext><xhtml:p>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.</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;!-- Category specifically for Security Audit Provider --&gt;
&lt;category name="org.jboss.security.audit.providers.LogAuditProvider" additivity="false"&gt;
	&lt;priority value="TRACE"/&gt;
	&lt;appender-ref ref="AUDIT"/&gt;
&lt;/category&gt;</xhtml:code></xhtml:pre>
			</fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:202001"/>
			</check>
		</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2021"><!--Ensure Configure SecurityInterceptor logging level is set correctly-->
			<title>Ensure Configure SecurityInterceptor logging level is set correctly</title>
			<description>Production environments of JBoss require enhanced auditing on the SecurityInterceptor class. </description>
			<reference>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</reference>
			<rationale><xhtml:p>Enabling TRACE priority logging on the SecurityInterceptor class is a necessary component of comprehensive auditing in a secure production environment.</xhtml:p>
				</rationale>	
			<profile-note tag="risk_score">4</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">AU-12</profile-note>
			<profile-note tag="disa_mapping">ECAT-1,ECAT-2</profile-note>
			<fixtext><xhtml:p>Ensure a category is defined for SecurityInterceptor class with a priority of TRACE within JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml.</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;category name="org.jboss.ejb.plugins.SecurityInterceptor"&gt;
	&lt;priority value="TRACE" /&gt;
	&lt;appender-ref ref="AUDIT" /&gt;
&lt;/category&gt;</xhtml:code></xhtml:pre>
			</fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:202101"/>
			</check>
		</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2022"><!--Ensure logging is enabled for Microcontainer bootstrap operations-->
			<title>Ensure logging is enabled for Microcontainer bootstrap operations</title>
			<description>Production environments of JBoss require auditing for Microcontainer bootstrap operations. </description>
			<reference>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</reference>
			<rationale><xhtml:p>Logging Microcontainer bootstrap operations is a necessary component of comprehensive auditing in a secure production environment.</xhtml:p>
				</rationale>
			<profile-note tag="risk_score">4</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">AU-3,AU-12</profile-note>
			<profile-note tag="disa_mapping">ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECAT-1,ECAT-2</profile-note>
			<fixtext><xhtml:p>Set the priority and appender-ref levels for the Microcontainer bootstrap by adding the &lt;category&gt; block as specified to JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml.</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;category name="org.jboss.bootstrap.microcontainer"&gt;
	&lt;priority value="INFO"/&gt;
	&lt;appender-ref ref="AUDIT"/&gt;
&lt;/category&gt;</xhtml:code></xhtml:pre>
			</fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:202201"/>
			</check>
		</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2023"><!--Ensure logging is enabled for web-based requests if required by deployed applications-->
			<title>Ensure logging is enabled for web-based requests if required by deployed applications</title>
			<description>In the event that application requirements dictate additional logging for web-based requests, the AccessLogValve should be enabled.</description>
			<reference>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</reference>
			<rationale><xhtml:p>If application owners determine that additional logging of web-based requests is desired, it should be enabled.</xhtml:p>
				
			</rationale>
			
			<profile-note tag="risk_score">4</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			
			<profile-note tag="nist_mapping">AU-3,AU-12</profile-note>
			<profile-note tag="disa_mapping">ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECAT-1,ECAT-2</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>If logging of web-based requests has been required for deployed applications the AccessLogValve should be enabled. To check the status of the &lt;Valve&gt;, ensure the following element is defined within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml.</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;Valve className="org.apache.catalina.valves.AccessLogValve" prefix="localhost_access_log." suffix=".log" pattern="common" directory="${JBoss.server.home.dir}/log" resolveHosts="false" /&gt;</xhtml:code></xhtml:pre></profile-note>
			
			<fixtext>
				<xhtml:p>Ensure the following &lt;Valve&gt; exists within: JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. By default, this &lt;Valve&gt; simply needs to be uncommented.</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;Valve className="org.apache.catalina.valves.AccessLogValve" prefix="localhost_access_log." suffix=".log" pattern="common" directory="${JBoss.server.home.dir}/log" resolveHosts="false" /&gt;</xhtml:code></xhtml:pre>
				
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:202301"/>
			</check>
		</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2024"><!--Ensure all required information is displayed in &lt;layout&gt;-->
			<title>Ensure all required information is displayed in &lt;layout&gt;</title>
			<description>The Security Audit Appender must log all identified information. </description>
			<reference>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</reference>
			<rationale><xhtml:p>Logging full event information to the Security Audit Appender is a necessary component of comprehensive auditing in a secure production environment.</xhtml:p>
				</rationale>
			<profile-note tag="risk_score">3</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="nist_mapping">AU-12</profile-note>
			<profile-note tag="disa_mapping">ECAT-1,ECAT-2</profile-note>
			<fixtext>
				<xhtml:p>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:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;!--The full pattern: Date MS Priority [Category] (Thread:NDC) Message --&gt;
&lt;layout class="org.apache.log4j.PatternLayout"&gt;
	&lt;param name="ConversionPattern" value="%d %-5r %-5p [%c] (%t:%x) %m%n"/&gt;
&lt;/layout&gt;</xhtml:code></xhtml:pre>
			</fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:202401"/>
			</check>
		</Rule>
				
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1103"><!--Production applications should not log output to the JBoss console-->
			<title>Production applications should not log output to the JBoss console</title>
			<description>Turn off console logging in production. Console logging in a production environment is a needless drain on system resources. </description>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011 </reference>			
			<rationale><xhtml:p>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.</xhtml:p> </rationale>			
			<profile-note tag="risk_score">3</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>		
			<profile-note tag="nist_mapping">AU-9</profile-note>
			<profile-note tag="disa_mapping">ECTB-1,ECTP-1</profile-note>		
			<fixtext><xhtml:p>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 &lt;appender-ref&gt; element with a ref attribute value of 'CONSOLE'. This &lt;appender-ref&gt; element will be a child of the &lt;root&gt; element, typically located near the end of the document.</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;root&gt;
&lt;!--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.--&gt;
	&lt;priority value="${jboss.server.log.threshold}"/&gt;
		&lt;!-- appender-ref ref="CONSOLE"/ --&gt;
	&lt;appender-ref ref="ASYNC"/&gt;
&lt;/root&gt;</xhtml:code></xhtml:pre></fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:110301"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_4004"><!--Ensure JBoss process owner is executing with least privilege-->
			<title>Ensure JBoss process owner is executing with least privilege</title>
			<description>Operating environment permissions assigned to the JBoss process owner should be in compliance with the principle of least privilege.</description>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">5.1</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:H/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">AC-6</profile-note>
			<profile-note tag="disa_mapping">ECLP-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p>
				<xhtml:p>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).</xhtml:p>
				<xhtml:p>This check fails if the JBoss process owner is not executing with least privileges. The following list identifies common scenario failures:</xhtml:p>
				<xhtml:p>
					<xhtml:ul>
						<xhtml:li>The JBoss process owner is a privileged account such as root or administrator.</xhtml:li>
						<xhtml:li>The JBoss process owner is a member of a privileged group, such wheel, root, administrators, power users, domain admins, backup operators, etc.</xhtml:li>
						<xhtml:li>The JBoss process owner is used by multiple applications via use of username and password or group membership.</xhtml:li>
						<xhtml:li>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.</xhtml:li>
					</xhtml:ul>
				</xhtml:p>
			</profile-note>
			<fixtext><xhtml:p>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)..</xhtml:p>
				<xhtml:p></xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:400401"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1099"><!--Deny the JBoss process owner console access-->
			<title>Deny the JBoss process owner console access</title>
			<description>The JBoss Application Server process owner should not have interactive console login access.</description>
			<reference>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</reference>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011</reference>
			<rationale><xhtml:p>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. </xhtml:p></rationale>
			<profile-note tag="risk_score">4.1</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:M/Au:S/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">AC-6</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Steps for validating this configuration will vary, dependent upon operating system:</xhtml:p>
				<xhtml:p>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).</xhtml:p>
				<xhtml:p>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.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>Steps for implementing this configuration will vary, dependent upon operating system:</xhtml:p>
				<xhtml:p>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:</xhtml:p>
				<xhtml:pre><xhtml:code>jboss:x:494:494:JBossAS:/var/lib/jbossas:/sbin/nologin</xhtml:code></xhtml:pre>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:109901"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1162"><!--Set JBoss file ownership-->
			<title>Set JBoss file ownership</title>
			<description>All JBoss Enterprise Application Platform files within JBOSS_HOME should be owned by the JBoss process owner account.</description>
			<rationale><xhtml:p>To prevent unauthorized modification or disclosure of JBoss configuration settings, all files within JBOSS_HOME should be owned by the JBoss process owner account.</xhtml:p> </rationale>
			<profile-note tag="risk_score">3.7</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">AC-3</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p>
				<xhtml:p>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.</xhtml:p>
			</profile-note>
			<fixtext><xhtml:p>Steps for implementing this configuration will vary, dependent upon operating system. </xhtml:p>
				<xhtml:p>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.</xhtml:p>
				<xhtml:p>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).</xhtml:p>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:116201"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1098"><!--Set JBoss file permissions-->
			<title>Set JBoss file permissions</title>
			<description>All JBoss Enterprise Application Platform files within JBOSS_HOME should be readable by the JBoss Application Server process owner and JBoss administrators only.</description>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">4.3</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:L/Au:S/C:P/I:P/A:P)</profile-note>
			<profile-note tag="nist_mapping">AC-3,AC-6</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p>
				<xhtml:p>Red Hat Enterprise Linux: Use the ls command to check basic file permissions. The getfacl command can be useful as well.</xhtml:p>
			</profile-note>
			<fixtext><xhtml:p>Steps for implementing this configuration will vary, dependent upon operating system. </xhtml:p>
				<xhtml:p>Red Hat Enterprise Linux: Use chmod to restrict permissions on files to at least 660 for all files in JBOSS_HOME and subdirectories.</xhtml:p>
				<xhtml:p>Windows environments can use the explorer GUI or cacls/xcacls to restrict permissions for all files in JBOSS_HOME and subdirectories.</xhtml:p>
				<xhtml:p>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.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:109801"/>
			</check>
		</Rule>
			
	</Group>

	<Group id="xccdf_com.redhat.eap5.scap_group_secure_deployed_applications" selected="false">
		<title>Securing deployed applications</title>
		<description>The rules in this group are used to secure applications deployed on JBoss EAP. This includes applications that JBoss packages and deploys by default.</description>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2006"><!--Ensure JMX Console is either secured or removed-->
			<title>Ensure JMX Console is either secured or removed</title>
			<description>The JMX Console application must be secured so it is accessible by trusted administrators only. If this condition is not met, the application must be removed (deleted) from deployment.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">8</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:L/Au:S/C:P/I:P/A:C)</profile-note>
			<profile-note tag="nist_mapping">AC-3</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>This rule can be checked for compliance by either:</xhtml:p>
				<xhtml:ol>
					<xhtml:li>Determine the console is not deployed.</xhtml:li>
					<xhtml:ol>
						<xhtml:li>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/</xhtml:li>
					</xhtml:ol>
					<xhtml:li>If the console is deployed, it must require authentication. Review the defined &lt;security-domain&gt; for the console.</xhtml:li>
					<xhtml:ol>
						<xhtml:li>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: &lt;security-domain&gt;java:/jaas/jmx-console&lt;/security-domain&gt;).</xhtml:li>
						<xhtml:li>Next, ensure that an &lt;application-policy&gt; element is defined that matches the &lt;security-domain&gt; referenced by the jboss-web.xml file. These &lt;application-policy&gt; can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.
							
							<xhtml:ul>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/META-INF/*-jboss-beans.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/*-jboss-beans.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul></xhtml:li>
						
						<xhtml:li>Check the &lt;application-policy&gt; element to ensure it requires authentication. Example of a satisfactory element:
							<xhtml:pre><xhtml:code>&lt;application-policy name="jmx-console"&gt;
	&lt;authentication&gt;
		&lt;login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"&gt;
			&lt;module-option name="usersProperties"&gt;props/jmx-console-users.properties&lt;/module-option&gt;
			&lt;module-option name="rolesProperties"&gt;props/jmx-console-roles.properties&lt;/module-option&gt;
		&lt;/login-module&gt;
	&lt;/authentication&gt;
&lt;/application-policy&gt;</xhtml:code></xhtml:pre></xhtml:li>
					</xhtml:ol>
				</xhtml:ol></profile-note>
			<fixtext>
				<xhtml:p>This rule can be made compliant by either:</xhtml:p>
				<xhtml:ol>
					<xhtml:li>Require authentication for access to the JBoss JMX Console.</xhtml:li>
					<xhtml:ol>
						<xhtml:li>First, ensure that an &lt;application-policy&gt; element is defined that requires authentication. Default policies exist for jmx-console and web-console. Example of a satisfactory element:
							<xhtml:pre><xhtml:code>&lt;application-policy name="jmx-console"&gt;
	&lt;authentication&gt;
		&lt;login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"&gt;
			&lt;module-option name="usersProperties"&gt;props/jmx-console-users.properties&lt;/module-option&gt;
			&lt;module-option name="rolesProperties"&gt;props/jmx-console-roles.properties&lt;/module-option&gt;	
		&lt;/login-module&gt; 
	&lt;/authentication&gt; 
&lt;/application-policy&gt;</xhtml:code></xhtml:pre>
							<xhtml:p>These &lt;application-policy&gt; can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.</xhtml:p>
							<xhtml:p>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml<xhtml:br/>
								JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/META-INF/*-jboss-beans.xml<xhtml:br/>
								JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/*-jboss-beans.xml<xhtml:br/>
								JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:p></xhtml:li>
						
						<xhtml:li>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: &lt;security-domain&gt;java:/jaas/jmx-console&lt;/security-domain&gt;). If no &lt;security-domain&gt; element exists, add it as a child of &lt;jboss-web&gt;.</xhtml:li>
						<xhtml:li>Next, review the JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/web.xml. The &lt;security-constraint&gt; must not contain the default limitations on HTTP verbs. For example: &lt;http-method&gt;GET&lt;/http-method&gt; or &lt;http-method&gt;POST&lt;/http-method&gt;. The default limitations were shown to allow side channel access to malicious users.</xhtml:li>
						
						<xhtml:li>Finally, configure the usersProperties defined in the application policy to manage accounts. Example editing JBOSS_HOME/server/[PROFILE]/conf/props/jmx-console-users.properties: <xhtml:br/>
							<xhtml:pre><xhtml:code># A sample users.properties file for use with the UsersRolesLoginModule
admin=1qaz!QAZ2wsx@WSX</xhtml:code></xhtml:pre></xhtml:li>
					</xhtml:ol>
					<xhtml:li>Remove the JBoss JMX Console from deployment.</xhtml:li>
					<xhtml:ol><xhtml:li>To remove the JMX Console from deployment, delete the exploded WAR located here: JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/</xhtml:li></xhtml:ol>
				</xhtml:ol>
			</fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:200601"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2007"><!--Ensure Web Console is either secured or removed-->
			<title>Ensure Web Console is either secured or removed</title>
			<description>The Web Console application must be secured so it is accessible by trusted administrators only. If this condition is not met, the application must be removed (deleted) from deployment.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">8</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:L/Au:S/C:P/I:P/A:C)</profile-note>
			<profile-note tag="nist_mapping">AC-3</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>This rule can be checked for compliance by either:</xhtml:p>
				<xhtml:ol>
					<xhtml:li>Determine the console is not deployed.	</xhtml:li>
					<xhtml:ol><xhtml:li>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/</xhtml:li></xhtml:ol>
					<xhtml:li>If the console is deployed, it must require authentication. Review the defined &lt;security-domain&gt; for the console.</xhtml:li>
					<xhtml:ol><xhtml:li>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: &lt;security-domain&gt;java:/jaas/web-console&lt;/security-domain&gt;).</xhtml:li>
						<xhtml:li>Next, ensure that an &lt;application-policy&gt; element is defined that matches the &lt;security-domain&gt; referenced by the jboss-web.xml file. These &lt;application-policy&gt; can be defined
							in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.
							<xhtml:ul>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/META-INF/*-jboss-beans.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy//management/console-mgr.sar/web-console.war/WEB-INF/*-jboss-beans.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul></xhtml:li>
						<xhtml:li>Check the &lt;application-policy&gt; element to ensure it requires authentication. Example of a satisfactory element:
							<xhtml:pre><xhtml:code>&lt;application-policy name="web-console"&gt;
	&lt;authentication&gt;
		&lt;login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"&gt;
			&lt;module-option name="usersProperties"&gt;web-console-users.properties&lt;/module-option&gt;
			&lt;module-option name="rolesProperties"&gt;web-console-roles.properties&lt;/module-option&gt;
		&lt;/login-module&gt;
	&lt;/authentication&gt;
&lt;/application-policy&gt;</xhtml:code></xhtml:pre></xhtml:li></xhtml:ol>
				</xhtml:ol></profile-note>
			
			<fixtext>
				<xhtml:p>This rule can be made compliant by either:</xhtml:p>
				<xhtml:ol>
					<xhtml:li>Require authorization for access to the JBoss Web Console.</xhtml:li>
					<xhtml:ol>
						<xhtml:li>First, ensure that an &lt;application-policy&gt; element is defined that requires authentication. Default policies exist for jmx-console and web-console. Example of a satisfactory element:
							<xhtml:pre><xhtml:code>&lt;application-policy name="web-console"&gt;
	&lt;authentication&gt;
		&lt;login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"&gt;
			&lt;module-option name="usersProperties"&gt;web-console-users.properties&lt;/module-option&gt;
			&lt;module-option name="rolesProperties"&gt;web-console-roles.properties&lt;/module-option&gt;
		&lt;/login-module&gt;
	&lt;/authentication&gt;
&lt;/application-policy&gt;</xhtml:code></xhtml:pre>
							<xhtml:p>These &lt;application-policy&gt; can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.</xhtml:p>
							<xhtml:ul>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/META-INF/*-jboss-beans.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/*-jboss-beans.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul></xhtml:li>
						
						<xhtml:li>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: &lt;security-domain&gt;java:/jaas/web-console&lt;/security-domain&gt;). If no &lt;security-domain&gt; element exists, add it as a child of &lt;jboss-web&gt;.</xhtml:li>
						
						<xhtml:li>Next, review the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml. The &lt;security-constraint&gt; must not contain the default limitations on HTTP verbs. For example: &lt;http-method&gt;GET&lt;/http-method&gt; or &lt;http-method&gt;POST&lt;/http-method&gt;. The default limitations were shown to allow sidechannel access to malicious users.</xhtml:li>
						<xhtml:li>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:
							<xhtml:pre><xhtml:code># A sample users.properties file for use with the UsersRolesLoginModule
admin=1qaz!QAZ2wsx@WSX</xhtml:code></xhtml:pre></xhtml:li>
					</xhtml:ol>
					<xhtml:li>Remove the JBoss Web Console from deployment.</xhtml:li>
					<xhtml:ol><xhtml:li>To remove the Web Console from deployment, delete the exploded SAR located here: JBOSS_HOME/server/[PROFILE]/deploy/management/</xhtml:li></xhtml:ol>
				</xhtml:ol>
			</fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:200701"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2008"><!--Ensure Administration Console is either secured or removed-->
			<title>Ensure Administration Console is either secured or removed</title>
			<description>The Administration Console application must be secured so it is accessible by trusted administrators only. If this condition is not met, the application must be removed (deleted) from deployment.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">8</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:L/Au:S/C:P/I:P/A:C)</profile-note>
			<profile-note tag="nist_mapping">AC-3</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>This rule can be checked for compliance by either:</xhtml:p>
				<xhtml:ol>
					<xhtml:li>Determine the console is not deployed.</xhtml:li>
					<xhtml:ol><xhtml:li>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/</xhtml:li></xhtml:ol>
					<xhtml:li>If the console is deployed, it must require authentication. Review the defined &lt;security-domain&gt; for the console.</xhtml:li>
					<xhtml:ol><xhtml:li>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: &lt;security-domain&gt;java:/jaas/jmx-console&lt;/security-domain&gt;).</xhtml:li>
						<xhtml:li>Next, ensure that an &lt;application-policy&gt; element is defined that matches the &lt;security-domain&gt; referenced by the jboss-web.xml file. These &lt;application-policy&gt; can be defined in the server
							profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.
							<xhtml:ul>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/META-INF/*-jboss-beans.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/*-jboss-beans.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul></xhtml:li>
						<xhtml:li>Check the &lt;application-policy&gt; element to ensure it requires authentication. Example of a satisfactory element (this example leverages the pre-existing jmx-console policy):
							<xhtml:pre><xhtml:code>&lt;application-policy name="jmx-console"&gt;
	&lt;authentication&gt;
		&lt;login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"&gt;
			&lt;module-option name="usersProperties"&gt;props/jmx-console-users.properties&lt;/module-option&gt;
			&lt;module-option name="rolesProperties"&gt;props/jmx-console-roles.properties&lt;/module-option&gt;
		&lt;/login-module&gt;
	&lt;/authentication&gt;
&lt;/application-policy&gt;</xhtml:code></xhtml:pre></xhtml:li>
						<xhtml:li>Finally, review the JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/web.xml. The &lt;security-constraint&gt; must not contain the default limitations on HTTP verbs. For example: &lt;http-method&gt;GET&lt;/http-method&gt; or &lt;http-method&gt;POST&lt;/http-method&gt;. The default limitations were shown to allow sidechannel access to malicious users.</xhtml:li> 
					</xhtml:ol></xhtml:ol></profile-note>
			
			<fixtext>
				<xhtml:p>This rule can be made compliant by either:</xhtml:p>
				<xhtml:ol>
					<xhtml:li>Require authorization for access to the JBoss Administration Console.</xhtml:li>
					<xhtml:ol>
						<xhtml:li>First, ensure that an &lt;application-policy&gt; element is defined that requires authentication. Default policies exist for jmx-console and web-console. Example of a satisfactory element:
							<xhtml:pre><xhtml:code>&lt;application-policy name="jmx-console"&gt;
	&lt;authentication&gt;
		&lt;login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"&gt;
			&lt;module-option name="usersProperties"&gt;web-console-users.properties&lt;/module-option&gt;
			&lt;module-option name="rolesProperties"&gt;web-console-roles.properties&lt;/module-option&gt;
		&lt;/login-module&gt;
	&lt;/authentication&gt;
&lt;/application-policy&gt;</xhtml:code></xhtml:pre>
							<xhtml:p>These &lt;application-policy&gt; can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.</xhtml:p>
							<xhtml:ul>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/META-INF/*-jboss-beans.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/*-jboss-beans.xml</xhtml:li>
								<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul></xhtml:li>
						
						<xhtml:li>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: &lt;security-domain&gt;java:/jaas/web-console&lt;/security-domain&gt;). If no &lt;security-domain&gt; element exists, add it as a child of &lt;jboss-web&gt;.</xhtml:li>
						
						<xhtml:li>Next, review the JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/web.xml. The &lt;security-constraint&gt; must not contain the default limitations on HTTP verbs. For example: &lt;http-method&gt;GET&lt;/http-method&gt; or &lt;http-method&gt;POST&lt;/http-method&gt;. The default limitations were shown to allow sidechannel access to malicious users.</xhtml:li>
						<xhtml:li>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:
							<xhtml:pre><xhtml:code># A sample users.properties file for use with the UsersRolesLoginModule
admin=1qaz!QAZ2wsx@WSX</xhtml:code></xhtml:pre></xhtml:li>
					</xhtml:ol>
					<xhtml:li>Remove the JBoss Administration Console from deployment.</xhtml:li>
					<xhtml:ol><xhtml:li>To remove the Administration Console from deployment, delete the exploded SAR located here: JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/</xhtml:li></xhtml:ol>
				</xhtml:ol>
			</fixtext>
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:200801"/>
			</check>
		</Rule>
	
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2029"><!--The JMXInvokerServlet servlet must be secured against web attacks-->
			<title>The JMXInvokerServlet servlet must be secured against web attacks</title>
			<description>The httpha-invoker.sar found in the deploy directory is a service that provides RMI/HTTP access for EJBs and the JNDI Naming service. By default older JBoss versions ship with a default set of &lt;http-method&gt; that allow attackers to bypass the security policy for JMX Invoker.</description>
			<reference>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</reference>
			<rationale><xhtml:p>Removing the default &lt;http-method&gt; 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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">8.3</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:M/Au:N/C:P/I:P/A:C)</profile-note>
			<profile-note tag="nist_mapping">AC-3</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>Review JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar/invoker.war/WEB-INF/web.xml to ensure the following lines have been removed:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;http-method&gt;GET&lt;/http-method&gt;
&lt;http-method&gt;POST&lt;/http-method&gt;</xhtml:code></xhtml:pre>
			</profile-note>
			<fixtext><xhtml:p>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:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;http-method&gt;GET&lt;/http-method&gt;
&lt;http-method&gt;POST&lt;/http-method&gt;</xhtml:code></xhtml:pre>
			</fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:202901"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2030"><!--The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authentication-->
			<title>The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authentication</title>
			<description>The jmx-invoker-service.xml is a service that exposes the JMX MBeanServer interface via an RMI compatible interface using the RMI/JRMP detached invoker service. This interface must be made unavailable to unprivileged users which can be done by using the org.jboss.jmx.connector.invoker.AuthenticationInterceptor interceptor for performing identification and authentication using JAAS. </description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">8.3</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:M/Au:N/C:P/I:P/A:C)</profile-note>
			<profile-note tag="nist_mapping">IA-2,IA-3</profile-note>
			<profile-note tag="disa_mapping">EBRU-1,IAIA-1,IAIA-2,IAGA-1</profile-note>
			
			<fixtext>
				<xhtml:p>Open JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml, and ensure the &lt;operation&gt; element with child element &lt;name&gt;invoke&lt;/name&gt; also contains the following &lt;interceptor&gt;:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;interceptors&gt;
	&lt;interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/&gt;
&lt;/interceptors&gt;</xhtml:code></xhtml:pre>
				
				<xhtml:p>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:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;application-policy name="jmx-console"&gt;
	&lt;authentication&gt;
		&lt;login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"&gt;
			&lt;module-option name="usersProperties"&gt;props/jmx-console-users.properties&lt;/module-option&gt;
			&lt;module-option name="rolesProperties"&gt;props/jmx-console-roles.properties&lt;/module-option&gt;
		&lt;/login-module&gt;
	&lt;/authentication&gt;
&lt;/application-policy&gt;</xhtml:code></xhtml:pre>
				<xhtml:p>NOTE: By default, this forces the invoker to authenticate against the jmx-console-users.properties file, located here: JBOSS_HOME/server/PROFILE/conf/prop/
					<xhtml:br/>NOTE: The securityDomain does not have to be called jmx-console.</xhtml:p> </fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:203001"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2031"><!--The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authorization-->
			<title>The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authorization</title>
			<description>The jmx-invoker-service.xml is a service that exposes the JMX MBeanServer interface via an RMI compatible interface using the RMI/JRMP detached invoker service. Access control for authenticated users must be configured using the interceptors of either org.jboss.jmx.connector.invoker.RolesAuthorization or org.jboss.jmx.connector.invoker.ExternalizableRolesAuthorization. </description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p>
				</rationale>
			
			<profile-note tag="risk_score">8.3</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:M/Au:N/C:P/I:P/A:C)</profile-note>
			<profile-note tag="nist_mapping">AC-3,AC-6</profile-note>
			<profile-note tag="disa_mapping">ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1</profile-note>
			
			<fixtext><xhtml:p>Open JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml, and ensure the &lt;operation&gt; element with child element &lt;name&gt;invoke&lt;/name&gt; also contains the following &lt;interceptor&gt;:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;interceptors&gt;
	&lt;interceptor code="org.jboss.jmx.connector.invoker.AuthorizationInterceptor" authorizingClass="org.jboss.jmx.connector.invoker.RolesAuthorization"/&gt;
&lt;/interceptors&gt;</xhtml:code></xhtml:pre>
				
				<xhtml:p>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:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;application-policy name="jmx-console"&gt;
	&lt;authentication&gt;
		&lt;login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"&gt;
			&lt;module-option name="usersProperties"&gt;props/jmx-console-users.properties&lt;/module-option&gt;
			&lt;module-option name="rolesProperties"&gt;props/jmx-console-roles.properties&lt;/module-option&gt;
		&lt;/login-module&gt;
	&lt;/authentication&gt;
&lt;/application-policy&gt;</xhtml:code></xhtml:pre>
				<xhtml:p>NOTE: By default, this forces the invoker to authenticate against the jmx-console-users.properties file, located here: JBOSS_HOME/server/PROFILE/conf/prop/<xhtml:br/>NOTE: The securityDomain does not have to be called jmx-console. </xhtml:p>
			</fixtext>
			
			<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
				<check-content-ref href="eap5-oval.xml" name="oval:com.redhat.eap5.scap:def:203101"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_3006" selected="false"><!--Deployed applications should display a system use banner upon access-->
			<title>Deployed applications should display a system use banner upon access</title>
			<description><xhtml:p>Upon accessing the system, a notification banner, consent to use, or policy warning banner should be displayed to alert system users of the system use details. This may include items such as implied consent to monitor, privacy practices, or liability waivers.</xhtml:p></description>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">2.0</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="nist_mapping">AC-8</profile-note>
			<profile-note tag="disa_mapping">ECWM-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Access all deployed applications to determine if a warning banner is displayed. A code review showing the functional code will also suffice.</xhtml:p><xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>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.</xhtml:p>
				<xhtml:p>On DoD systems, the warning banner should read:</xhtml:p>
				<xhtml:p>You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.</xhtml:p>
				<xhtml:p>By using this IS (which includes any device attached to this IS), you consent to the following conditions:</xhtml:p>
				<xhtml:p>-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.</xhtml:p>
				<xhtml:p>-At any time, the USG may inspect and seize data stored on this IS.</xhtml:p>
				<xhtml:p>-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.</xhtml:p>
				<xhtml:p>-This IS includes security measures (e.g., authentication and access controls) to protect USG interests—not for your personal benefit or privacy.</xhtml:p>
				<xhtml:p>-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.</xhtml:p>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<!--<check-export value-id="warning_banner_text" export-name="ocil:com.redhat.eap5.scap:variable:300601"/> SCC does not recognize OCIL variables-->
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:300601"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_3007" selected="false"><!--Deployed applications should display a classification banner when required-->
			<title>Deployed applications should display a classification banner when required</title>
			<description><xhtml:p>Deployed applications should present classification banners at the header and footer of each page in accordance with the applicable DoD classification guide for the environment (or in accordance with local security policies).</xhtml:p></description>
			<reference>Department of Defense, (1997). Information Security Program (DoD 5200.1-R)</reference>
			<rationale><xhtml:p>Prominent classification banners reduce the risk of inadvertent information disclosure or data spillage across different classification levels.</xhtml:p></rationale>
			<profile-note tag="risk_score">2.0</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
			<profile-note tag="nist_mapping">AC-8</profile-note>
			<profile-note tag="disa_mapping">ECWM-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p><xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>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.</xhtml:p>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:300701"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_2015"><!--Password hashing must be enabled within the appropriate login module-->
			<title>Password hashing must be enabled within the appropriate login module</title>
			<description>A Security Domain is a set of authentication, authorization, and mapping policies defined in XML and are available to applications at runtime using Java Naming and Directory Interface (JNDI).</description>
			<reference>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</reference>
			<rationale><xhtml:p>Failure to enable password hashing within a login module can result in plain-text exposure client passwords used for authentication.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">4.3</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:A/AC:M/Au:N/C:P/I:P/A:N)</profile-note>
			<profile-note tag="nist_mapping">SC-8,SC-9</profile-note>
			<profile-note tag="disa_mapping">ECTM-1,ECTM-2,ECCT-1,ECCT-2,ECNK-1,ECNK-2</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>To determine which &lt;application-policy&gt; are in use by deployed applications, search for &lt;security-domain&gt; elements within the following deployment descriptors:</xhtml:p>
				<xhtml:p>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml<xhtml:br/>
					JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss.xml</xhtml:p>
				
				<xhtml:p>An &lt;application-policy&gt; can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.</xhtml:p>
				<xhtml:ul>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul>
				
				<xhtml:p>The element below should be included within a deployed application's &lt;application-policy&gt;&lt;login-module&gt;:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;module-option name="hashUserPassword"&gt;true&lt;/module-option&gt;</xhtml:code></xhtml:pre> </profile-note>
			<fixtext>
				<xhtml:p>Add the following child element to any &lt;application-policy&gt;&lt;login-module&gt; in use:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;module-option name="hashUserPassword"&gt;true&lt;/module-option&gt;</xhtml:code></xhtml:pre>
				<xhtml:p>An &lt;application-policy&gt; can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.</xhtml:p>
				<xhtml:ul>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:201501"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2017"><!--A password hashing algorithm must be defined within the appropriate login module-->
			<title>A password hashing algorithm must be defined within the appropriate login module</title>
			<description>A Security Domain is a set of authentication, authorization, and mapping policies defined in XML and are available to applications at runtime using Java Naming and Directory Interface (JNDI). An &lt;application-policy&gt; can be defined in the server profile or in an application deployment descriptor.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">4.3</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:A/AC:M/Au:N/C:P/I:P/A:N)</profile-note>
			<profile-note tag="nist_mapping">SC-8,SC-9</profile-note>
			<profile-note tag="disa_mapping">ECTM-1,ECTM-2,ECCT-1,ECCT-2,ECNK-1,ECNK-2</profile-note>
			<profile-note tag="validation_text">
				<xhtml:p>To determine which &lt;application-policy&gt; are in use by deployed applications, search for &lt;security-domain&gt; elements within the following deployment descriptors:</xhtml:p>
				<xhtml:p>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml<xhtml:br/>
					JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss.xml<xhtml:br/></xhtml:p>
				<xhtml:p>An &lt;application-policy&gt; can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.</xhtml:p>				
				<xhtml:ul>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul>
				<xhtml:p>The element should be included within a deployed application's &lt;application-policy&gt;&lt;login-module&gt;:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;module-option name="hashAlgorithm"&gt;SHA&lt;/module-option&gt; </xhtml:code></xhtml:pre></profile-note>
			<fixtext>
				<xhtml:p>Add the following child element to any &lt;application-policy&gt;&lt;login-module&gt; in use:</xhtml:p>
				<xhtml:pre><xhtml:code>&lt;module-option name="hashAlgorithm"&gt;SHA&lt;/module-option&gt;</xhtml:code></xhtml:pre>
				<xhtml:p>An &lt;application-policy&gt; can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.</xhtml:p>				
				<xhtml:ul>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/login-config.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml</xhtml:li></xhtml:ul>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:201701"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2068"><!--Enterprise JavaBeans Specification v2.1 must be strictly followed-->
			<title>Enterprise JavaBeans Specification v2.1 must be strictly followed</title>
			<description>The programming restrictions mandated by the Enterprise JavaBeans Specification v2.1 must be strictly followed. For more information, refer to JSR-000153 Enterprise JavaBeans 2.1 specification. (Section 25.2, pages 562-564).</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">6</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p>
				<xhtml:ul><xhtml:li>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.</xhtml:li>
					<xhtml:li>An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances.</xhtml:li>
					<xhtml:li>An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.</xhtml:li>
					<xhtml:li>An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.</xhtml:li>
					<xhtml:li>An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.</xhtml:li>
					<xhtml:li>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.</xhtml:li>
					<xhtml:li>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.</xhtml:li>
					<xhtml:li>The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.</xhtml:li>
					<xhtml:li>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.</xhtml:li>
					<xhtml:li>The enterprise bean must not attempt to directly read or write a file descriptor.</xhtml:li>
					<xhtml:li>The enterprise bean must not attempt to obtain the security policy information for a particular code source.</xhtml:li>
					<xhtml:li>The enterprise bean must not attempt to load a native library.</xhtml:li>
					<xhtml:li>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.</xhtml:li>
					<xhtml:li>The enterprise bean must not attempt to define a class in a package.</xhtml:li>
					<xhtml:li>The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).</xhtml:li>
					<xhtml:li>The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.</xhtml:li>
					<xhtml:li>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.</xhtml:li></xhtml:ul>
			</profile-note>
			<fixtext><xhtml:p>Developers must follow Enterprise JavaBeans Specification v2.1.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:206801"/>
			</check>
		</Rule>
		
		</Group>

	<Group id="xccdf_com.redhat.eap5.scap_group_policy_architecture_and_practices_POLICY" selected="false">
		<title>Policy</title>
		<description>The rules in this group are used to manage JBoss servers in a secure manner. These rules are policy related.</description>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_2062"><!--Ensure adequate physical protections are in place-->
			<title>Ensure adequate physical protections are in place</title>
			<description>The hardware and software executing JBoss Enterprise Application Platform, as well as the software critical to security policy enforcement must be protected from unauthorized modification including unauthorized modifications by potentially hostile outsiders. Reasonable physical security measures to ensure that unauthorized personnel do not have physical access to the hardware running the JBoss Enterprise Application Platform software must be implemented.</description>
			<reference>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</reference>
			<rationale><xhtml:p>Many software security precautions can easily be bypassed by personnel with physical access to hardware storing data or executing an application.</xhtml:p></rationale>		
			<profile-note tag="risk_score">6.9</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:M/Au:N/C:C/I:C/A:C)</profile-note>
			<profile-note tag="nist_mapping">PE-1,PE-2,PE-3,PE-7,PE-18</profile-note>
			<profile-note tag="disa_mapping">PEPF-1,PEPF-2,PECF-1,PECF-2,PEPS-1,PEVC-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and security personnel. Visually inspect physical security precautions. Review space certifications where appropriate.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>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.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:206201"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2063"><!--Assign a JBoss administrator-->
			<title>Assign a JBoss administrator</title>
			<description>There must be one or more competent individuals who are assigned to manage JBoss Enterprise Application Platform, its environment and the security of the information it contains.</description>
			<reference>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</reference>
			<rationale><xhtml:p>Incompetent, careless, or negligent JBoss administrators can completely invalidate a secure JBoss configuration and create numberless problems for JBoss.</xhtml:p></rationale>
			<profile-note tag="risk_score">8</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="nist_mapping">AT-2,AT-3,AT-4</profile-note>
			<profile-note tag="disa_mapping">PRTN-1,PETN-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators. Review credentials and qualifications. JBoss Administrators should possess a basic level of proficiency with the software.</xhtml:p>
				<xhtml:p>Additionally, they must not be carelessly or willfully negligent, or hostile, and must follow the instructions provided by the administrator documentation.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>Ensure a minimum level of competency / expertise has been established for JBoss administrators before granting them access to production systems.</xhtml:p>
				<xhtml:p>Ensure documentation and procedures exist (and are followed) for routine administrative tasks.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:206301"/>
			</check>
		</Rule>			

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1129"><!--Document incident response procedures-->
			<title>Document incident response procedures</title>
			<description>Ensure well developed procedures exist for incident handling. Incidents include any events that are anomalous to the environment, which typically include:
				<xhtml:ul><xhtml:li>Intrusions (possibly including attempts)</xhtml:li>
					<xhtml:li>Application failures</xhtml:li>
					<xhtml:li>Unexpected platform activity such as restarts or configuration changes</xhtml:li>
					<xhtml:li>Unusual network traffic to or from the server</xhtml:li></xhtml:ul></description>
			<reference>Mallik, R. (2011, May). Jboss in the Trenches. </reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">6</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">IR-1,IR-8</profile-note>
			<profile-note tag="disa_mapping">VIIR-1,VIIR-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>Draft formal incident response policies and procedures. Utilize national and international standards such as ISO/IEC TR 18044 or NIST Special Publication 800-61.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:112901"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1133"><!--Perform periodic incident response exercises-->
			<title>Perform periodic incident response exercises</title>
			<description>Production environments should exercise incident response procedures at least annually. Environments requiring higher assurances of security should test incident response procedures more often, possibly quarterly or even monthly. Incident response procedures should cover all anomalous events.</description>
			<rationale><xhtml:p>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.</xhtml:p> </rationale>		
			<profile-note tag="risk_score">4</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>	
			<profile-note tag="nist_mapping">IR-3</profile-note>
			<profile-note tag="disa_mapping">VIIR-1,VIIR-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>Draft a schedule to ensure that documented procedures are exercised at least annually. More frequent exercises may be needed for some environments.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:113301"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1132"><!--Document disaster recovery procedures-->
			<title>Document disaster recovery procedures</title>
			<description>Robust disaster recovery documentation and procedures should exist. This documentation should include provisions for the JBoss platform, deployed applications, required source code, and supporting applications (such as authentication stores or database servers).</description>
			<rationale><xhtml:p>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.</xhtml:p> </rationale>	
			<profile-note tag="risk_score">6</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">CP-1,CP-2</profile-note>
			<profile-note tag="disa_mapping">CODP-1,CODP-2,CODP-3,COEF-1,COEF-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>Draft formal disaster response policies and procedures. Utilize national and international standards such as ISO 17799 or NIST Special Publication 800-34.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:113201"/>
			</check>
		</Rule>
						
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1134"><!--Perform periodic disaster recovery exercises-->
			<title>Perform periodic disaster recovery exercises</title>
			<description>Production environments should exercise disaster recovery procedures that include provisions for the JBoss platform, deployed applications, and any required source code at least annually. Environments requiring higher assurances of disaster recovery ability should test procedures more often, possibly quarterly or even monthly.</description>
			<rationale><xhtml:p>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. </xhtml:p></rationale>
			<profile-note tag="risk_score">4</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">CP-4</profile-note>
			<profile-note tag="disa_mapping">DCSS-2,COED-1,COED-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>Draft a schedule to ensure that documented procedures are exercised at least annually. More frequent exercises may be needed for some environments.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:113401"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1135"><!--Identify and document application data flows-->
			<title>Identify and document application data flows</title>
			<description>It is recommended to identify and document application data flows. This will allow insight into what paths sensitive information takes through the application environment and what data source connections need to be encrypted.</description>
			<rationale><xhtml:p>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. </xhtml:p></rationale>
			<profile-note tag="risk_score">4.3</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:A/AC:M/Au:N/C:P/I:P/A:N)</profile-note>
			<profile-note tag="nist_mapping">SC-8,SC-9,SC-23</profile-note>
			<profile-note tag="disa_mapping">ECTM-1,ECTM-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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:</xhtml:p>
				<xhtml:ul><xhtml:li>Relevant protocol information (for instance, TCP traffic should record port information)</xhtml:li>
					<xhtml:li>Traffic destination</xhtml:li>
					<xhtml:li>Purpose</xhtml:li>
					<xhtml:li>Sensitivity of traffic</xhtml:li>
					<xhtml:li>Applicable security information, such as encryption types, specific vulnerabilities in transport or application protocols, etc.</xhtml:li></xhtml:ul>
			</profile-note>
			<fixtext><xhtml:p>Work with JBoss administrators and application developers to document data flows for deployed applications. Information documented should include:</xhtml:p>
				<xhtml:ul><xhtml:li>Relevant protocol information (for instance, TCP traffic should record port information)</xhtml:li>
					<xhtml:li>Traffic destination</xhtml:li>
					<xhtml:li>Purpose</xhtml:li>
					<xhtml:li>Sensitivity of traffic</xhtml:li>
					<xhtml:li>Applicable security information, such as encryption types, specific vulnerabilities in transport or application protocols, etc.</xhtml:li></xhtml:ul>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:113501"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1159"><!--Java permissions for deployed applications should be documented and reviewed prior to deployment-->
			<title>Java permissions for deployed applications should be documented and reviewed prior to deployment</title>
			<description>Java permissions for applications should be documented and carefully reviewed prior to deployment. Developers and administrators should strive to balance application permissions and application functionality.</description>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">AC-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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):</xhtml:p>
				<xhtml:ul><xhtml:li>java.home/lib/security/java.security</xhtml:li></xhtml:ul>
				<xhtml:p>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)</xhtml:p> </profile-note>
			<fixtext><xhtml:p>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.</xhtml:p>
				<xhtml:p>Further, documentation should exist for all applications that have been granted specific permissions.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:115901"/>
			</check>
		</Rule>
						
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1146"><!--Regular backups should be performed-->
			<title>Regular backups should be performed</title>
			<description>JBoss applications and configuration files should be backed up at least weekly, possibly more if needed by the environment.</description>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">6</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">CP-9</profile-note>
			<profile-note tag="disa_mapping">DCSW-1,COBR-1,CODB-1,CODB-2,CODB-3,COSW-1,DCWH-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>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.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:114601"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1153"><!--Auditing policy should exist-->
			<title>Auditing policy should exist</title>
			<description>In order to effectively audit and review system logs, an audit policy should be written to identify data and trends of interest.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">4</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">AU-1,AU-2,AU-3,AU-5</profile-note>
			<profile-note tag="disa_mapping">ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECND-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>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.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:115301"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1164"><!--Access control policy and procedures-->
			<title>Access control policy and procedures</title>
			<description>JBoss administrators must have access to guidance regarding account creation, permissions assignments, role assignments, etc.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">AC-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>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.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:116401"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_3003"><!--Define an appropriate minimum and maximum password length requirement-->
			<title>Define an appropriate minimum and maximum password length requirement</title>
			<description><xhtml:p>Organizations should create an authenticator management policy that defines minimum and maximum password sizes for user accounts accessing JBoss and its deployed applications.</xhtml:p></description>
			<reference>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</reference>
			<reference>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</reference>
			<rationale><xhtml:p>In brute force scenarios, passwords of extended lengths increase password security and the length of time required to decrypt the password.</xhtml:p><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">5.0</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">IA-5</profile-note>
			<profile-note tag="disa_mapping">IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Work with JBoss administrators and security team members to identify and review relevant documentation. Minimum and maximum password lengths should be defined.</xhtml:p></profile-note>
			<fixtext><xhtml:p>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.</xhtml:p>
				<xhtml:p>
					For example:
				</xhtml:p>
				<xhtml:ul>
					<xhtml:li>User accounts shall require password lengths of between 8 and 24 characters</xhtml:li>
					<xhtml:li>Administrator shall require password lengths of 24 characters</xhtml:li>
					<xhtml:li>Web service accounts shall require password lengths of 24 characters</xhtml:li>
				</xhtml:ul>
				<xhtml:p>
					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.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:300301"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_3004"><!--Define an appropriate minimum password complexity requirement-->
			<title>Define an appropriate minimum password complexity requirement</title>
			<description><xhtml:p>Organizations should create an authenticator management policy that defines a minimum level of complexity for user accounts accessing JBoss and its deployed applications. These requirements should also restrict passwords from containing dictionary words and reusing previous passwords.</xhtml:p></description>
			<reference>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</reference>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">5.0</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">IA-5</profile-note>
			<profile-note tag="disa_mapping">IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>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.</xhtml:p>
				<xhtml:p>
					For example:
				</xhtml:p>
				<xhtml:ul>
					<xhtml:li>User accounts shall require passwords containing at least 1 lowercase alphanumeric character, 1 uppercase alphanumeric character, and 1 number</xhtml:li>
					<xhtml:li>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: !@#$%^&amp;*()</xhtml:li>
					<xhtml:li>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: !@#$%^&amp;*()</xhtml:li>
				</xhtml:ul>
				<xhtml:p>
					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.</xhtml:p></fixtext>			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:300401"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_3005"><!--Define an appropriate minimum password expiration interval-->			
			<title>Define an appropriate minimum password expiration interval</title>
			<description><xhtml:p>Organizations should create an authenticator management policy that defines a maximum password age for user accounts accessing JBoss and its deployed applications.</xhtml:p></description>
			<reference>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</reference>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p><xhtml:p>
				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.</xhtml:p></rationale>
			<profile-note tag="risk_score">5.0</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">IA-5</profile-note>
			<profile-note tag="disa_mapping">IAIA-1,IAIA-2,IATS-1,IATS-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>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.</xhtml:p>
				<xhtml:p>
					For example:
				</xhtml:p>
				<xhtml:ul>
					<xhtml:li>Passwords for user accounts must expire every 90 days</xhtml:li>
					<xhtml:li>Passwords for administrator accounts must expire every 30 days</xhtml:li>
					<xhtml:li>Passwords for web service accounts must expire every 180 days</xhtml:li>
				</xhtml:ul>
				<xhtml:p>
					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.</xhtml:p></fixtext>			
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:300501"/>
			</check>
		</Rule>
			
	</Group>
				
	<Group id="xccdf_com.redhat.eap5.scap_group_policy_architecture_and_practices_ARCHITECTURE" selected="false">
		<title>Architecture</title>
		<description>The rules in this group are used to manage JBoss servers in a secure manner. These rules are related to deploying a secure architecture.</description>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_4001"><!--Production JBoss EAP installations should reside on a dedicated platform-->
			<title>Production JBoss EAP installations should reside on a dedicated platform</title>
			<description>Production JBoss servers in production environments should be hosted on dedicated operating systems and not sharing a host operating system with other service applications.</description>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>Installations of JBoss should reside on a dedicated operating system. If not, ensure the configuration, rationale, and risk assessment is well documented. </xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:400101"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1124"><!--Avoid multiple JBoss instances per server-->
			<title>Avoid multiple JBoss instances per server</title>
			<description>Multiple instances of JBoss deployed onto a single server should be avoided whenever possible to reduce environmental complexity and administrative burdens. However, occasionally circumstances require that multiple JBoss instances are deployed to the same server. In this scenario, the configurations and justifications should be documented along with the rest of the system's documentation. </description>
			<reference>Mallik, R. (2011, May). Jboss in the Trenches.</reference>
			<rationale><xhtml:p>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.</xhtml:p> </rationale>
			<profile-note tag="risk_score">5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>Limit JBoss Enterprise Applications Platform instances to one per server if possible. If not, ensure the configuration, rationale, and risk assessment is well documented. </xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:112401"/>
			</check>
		</Rule>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1131"><!--Bind multiple JBoss instances per server to different IPs-->
			<title>Bind multiple JBoss instances per server to different IPs</title>
			<description>If multiple JBoss instances are installed, the servers should be set to bind to different IP addresses on the server rather than changing the default port configuration.</description>
			<reference>Mallik, R. (2011, May). Jboss in the Trenches. </reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">3.5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p></profile-note>
			<fixtext><xhtml:p>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:</xhtml:p>
				<xhtml:pre><xhtml:code>run.sh -c public -b 10.10.10.75</xhtml:code></xhtml:pre> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:113101"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2064"><!--Packet filtering should be emplaced around JBoss Enterprise Application Platform-->
			<title>Packet filtering should be emplaced around JBoss Enterprise Application Platform</title>
			<description>JBoss Enterprise Application Platform must operate in a network segment that is logically separated from any other network segment using a packet filtering mechanism. This packet filter 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.</description>
			<reference>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</reference>
			<rationale><xhtml:p>Packet filtering is a basic security technique for securing TCP/IP and UDP/IP communications.</xhtml:p></rationale>
			<profile-note tag="risk_score">9.3</profile-note>
			<profile-note tag="risk_level">High</profile-note>
			<profile-note tag="dod_cat">CAT I</profile-note>
			<profile-note tag="risk_formula">(AV:N/AC:M/Au:N/C:C/I:C/A:C)</profile-note>
			<profile-note tag="nist_mapping">SC-7</profile-note>
			<profile-note tag="disa_mapping">DCSS-2,EBBD-1,EBBD-2,EBBD-3,EBPW-1,ECID-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p>
				<xhtml:p>When JBoss Enterprise Application Platforms are clustered, all outgoing communication from the JBoss Enterprise Application Platform instance must be allowed.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>Install and/or configure a TCP/IP and UDP/IP packet filtering device to logically separate the JBoss Enterprise Application Server from other networks. </xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:206401"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1094"><!--Do not transmit sensitive information over unsecured HTTP connections-->
			<title>Do not transmit sensitive information over unsecured HTTP connections</title>
			<description>Sensitive information should not be transferred over insecure means. This includes plaintext credential information, application information deemed sensitive, or other information that may be valuable to a malicious entity.
				The &lt;auth-method&gt; child element specifies the authentication mechanism for the web application. Using the BASIC authentication method causes the exchange of credentials in clear-text.</description>
			<reference>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</reference>
			<reference>JBoss Enterprise Application Platform 5 Security Guide, 2011</reference>
			
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			
			<profile-note tag="risk_score">4.3</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:A/AC:M/Au:N/C:P/I:P/A:N)</profile-note>
			<profile-note tag="nist_mapping">SC-8</profile-note>
			<profile-note tag="disa_mapping">ECTM-1,ECTM-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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).</xhtml:p>
				<xhtml:p>Real-world tests using a browser, wget, and a packet capture utility may also assist in validating the level of encryption for sensitive information.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>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.</xhtml:p>
				<xhtml:p>To setup SSL or TLS, proceed as follows:</xhtml:p>
				<xhtml:ul><xhtml:li>Ensure a valid keystore is being loaded by JSM</xhtml:li>
					<xhtml:li>Load the JBoss server's public/private key pair into the keystore</xhtml:li>
					<xhtml:li> Add a secure connector to JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml
						<xhtml:pre><xhtml:code>&lt;Service name="jboss.web"&gt;
	&lt;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" /&gt;
&lt;/Service&gt;</xhtml:code></xhtml:pre></xhtml:li></xhtml:ul>
			</fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:109401"/>
			</check>
		</Rule>	
	</Group>
				
	<Group id="xccdf_com.redhat.eap5.scap_group_policy_architecture_and_practices_PRACTICES" selected="false">
		<title>Policy</title>
		<description>The rules in this group are used to manage JBoss servers in a secure manner. These rules are related to general best practices.</description>
		
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1104"><!--Use a version control repository-->
			<title>Use a version control repository</title>
			<description>All configuration files (such a data sources, custom connectors, etc) and any scripts used for modifications and deployments should be stored in the version control repository. Typical repositories include applications such as SVN or Git.
				Additionally, a hash-validated 'Gold' version of the JBoss installation package should also be stored in the version control system.</description>
			<reference>Mallik, R. (2011, May). Jboss in the Trenches. </reference>
			<rationale><xhtml:p>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.</xhtml:p>
				<xhtml:p>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.</xhtml:p> </rationale>
			<profile-note tag="risk_score">5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">CM-3,CM-5</profile-note>
			<profile-note tag="disa_mapping">DCCB-1,DCCB-2,ECPC-1,ECPC-2,DCSL-1,ECSD-1,ECSD-2</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. Review evidence of version control system and its use.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>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.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:110401"/>
			</check>
		</Rule>
						
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1125"><!--Automate JBoss Deployments-->
			<title>Automate JBoss Deployments</title>
			<description>Scripts or other software tools should be used to automatically configure and deploy JBoss applications in environments.</description>
			<reference>Mallik, R. (2011, May). Jboss in the Trenches. </reference>
			<rationale><xhtml:p>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.</xhtml:p> </rationale>
			<profile-note tag="risk_score">5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>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. </xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:112501"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1127"><!--Application performance testing-->
			<title>Application performance testing</title>
			<description>Ensure routine performance testing is completed before applications are deployed to production. Establish and document performance profiles.</description>
			<reference>Mallik, R. (2011, May). Jboss in the Trenches. </reference>
			<rationale><xhtml:p>Without adequate performance testing, production applications may fail to perform to expectations - resulting in a denial of service.</xhtml:p> </rationale>
			<profile-note tag="risk_score">3.5</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">SA-3</profile-note>
			<profile-note tag="disa_mapping">DCSP-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>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.</xhtml:p> </fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:112701"/>
			</check>
		</Rule>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1128"><!--Monitor JBoss servers-->
			<title>Monitor JBoss servers</title>
			<description>JBoss Enterprise Application Platform servers in production environments should be monitored real-time. Information monitored and alarm thresholds will vary. Common monitoring tools include:
				<xhtml:ul><xhtml:li>JBoss Operations Network (JON)</xhtml:li>
					<xhtml:li>Foglight</xhtml:li>
					<xhtml:li>HP Openview</xhtml:li>
					<xhtml:li>Nagios</xhtml:li></xhtml:ul> </description>
			<reference>Mallik, R. (2011, May). Jboss in the Trenches. </reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>	
			<profile-note tag="risk_score">6</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">AU-3,AU-6,AU-7,AU-12</profile-note>
			<profile-note tag="disa_mapping">ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECAT-1,ECAT-2,ECRG-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>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.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>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:</xhtml:p>
				<xhtml:ul><xhtml:li>JBoss Operations Network (JON)</xhtml:li>
					<xhtml:li>Foglight</xhtml:li>
					<xhtml:li>HP Openview</xhtml:li>
					<xhtml:li>Nagios</xhtml:li></xhtml:ul>
				<xhtml:p>Common metrics include:</xhtml:p>
				<xhtml:ul><xhtml:li>Active threads on the application server</xhtml:li>
					<xhtml:li>Threads on the front-end http/ajp web connector</xhtml:li>
					<xhtml:li>Database connection pools</xhtml:li>
					<xhtml:li>JVM metrics such as memory usage and GCs</xhtml:li>
					<xhtml:li>Typical host platform metrics such as available hard drive space, CPU usage, etc. </xhtml:li></xhtml:ul></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:112801"/>
			</check>
		</Rule>
					
		<Rule id="xccdf_com.redhat.eap5.scap_rule_2057"><!--Ensure all downloaded software is authentic-->
			<title>Ensure all downloaded software is authentic</title>
			<description>Software and packages should be downloaded from redhat.com, and hash validated.</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">6.2</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="risk_formula">(AV:L/AC:H/Au:N/C:C/I:C/A:C)</profile-note>
			<profile-note tag="nist_mapping">CM-6</profile-note>
			<profile-note tag="disa_mapping">DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators. JBoss administrators must demonstrate proficiency in securely acquiring JBoss Enterprise Application Platform installation materials.</xhtml:p> </profile-note>
			<fixtext><xhtml:p>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.</xhtml:p>
				<xhtml:p>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.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:205701"/>
			</check>
		</Rule>	
	
		<Rule id="xccdf_com.redhat.eap5.scap_rule_4010"><!--Ensure JBoss is configured in accordance with Common Criteria configuration guides-->
			<title>Ensure JBoss is configured in accordance with Common Criteria configuration guides</title>
			<description>JBoss deployments in government and DoD organizations require JBoss be deployed in a Common Criteria certified configuration. The Common Criteria configuration is a list of technical configuration items, policy requirements, and other configurations required to certify a JBoss installation at the EAL4+ protection level. Red Hat maintains configuration guidance available online to assist administrators during the installation and configuration of JBoss (<xhtml:a href="http://docs.redhat.com/docs/en-US/index.html">http://docs.redhat.com/docs/en-US/index.html</xhtml:a>).</description>
			<reference>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</reference>
			<rationale><xhtml:p>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.</xhtml:p></rationale>
			<profile-note tag="risk_score">6.2</profile-note>
			<profile-note tag="risk_level">Medium</profile-note>
			<profile-note tag="dod_cat">CAT II</profile-note>
			<profile-note tag="nist_mapping">SA-4</profile-note>
			<profile-note tag="disa_mapping">DCAS-1,DCSR-1,DCSR-2,DCSR-3</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and review on-site documentation. Review the JBoss Common Criteria Configuration Guide (available <xhtml:a href="http://docs.redhat.com/docs/en-US/index.html">here</xhtml:a> from Red Hat's website) to ensure JBoss has been installed and configured in accordance with the Common Criteria requirements.</xhtml:p></profile-note>
			<fixtext><xhtml:p>Configure JBoss in its Common Criteria certified configuration. The configuration guide can be found <xhtml:a href="http://docs.redhat.com/docs/en-US/index.html">here</xhtml:a> on Red Hat's website.</xhtml:p></fixtext>
			
			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:401001"/>
			</check>
		</Rule>		
		
	</Group>		
		
	<Group id="xccdf_com.redhat.eap5.scap_group_trimming" selected="false">
		<title>Trimming</title>
		<description>The rules in this group concern trimming JBoss EAP.</description>
			
		<Rule id="xccdf_com.redhat.eap5.scap_rule_1106">
			<title>Unused features should be disabled or deleted: Java Universal Description, Discovery, Integration (JUDDI)</title>
			<description>Features and services not in use should be removed. JUDDI is an open source Java implementation of the Universal Description, Discovery, and Integration (UDDI v3) specification for (Web) Services.</description>
			<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
			<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
			<reference>JUDDI; An Apache Project. (February 6, 2012). </reference>
			<rationale><xhtml:p>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.</xhtml:p> </rationale>

			<profile-note tag="risk_score">3</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
				<profile-note tag="dod_cat">CAT III</profile-note>
			
			<profile-note tag="nist_mapping">CM-7</profile-note>
			<profile-note tag="disa_mapping">DCPP-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following directory:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/juddi-service.sar</xhtml:li></xhtml:ul> </profile-note>
			<fixtext>In order to completely disable the this component, take the following actions:
<xhtml:p>Delete this directory:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/juddi-service.sar</xhtml:li></xhtml:ul> </fixtext>

			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:110601"/>
			</check>
		</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1107"><!--Unused features should be disabled or deleted: Enterprise Java Beans (EJB) Services-->
		<title>Unused features should be disabled or deleted: Enterprise Java Beans (EJB) Services</title>
		<description>Features and services not in use should be removed.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>

		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following directory:</xhtml:p>
			<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/ejb3-connectors-jboss-beans.xml</xhtml:li>
			<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/ejb3-container-jboss-beans.xml</xhtml:li>
			<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/ejb3-interceptors-aop.xml</xhtml:li>
			<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/ejb3-timerservice-jboss-beans.xml</xhtml:li>
			<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/profile-service-secured.jar</xhtml:li>
			<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/ejb2-container-jboss-beans.xml</xhtml:li>
			<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml</xhtml:li>
			<xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/jboss-ejb3-endpoint-deployer.jar</xhtml:li>
			<xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/ejb3-deployers-jboss-beans.xml </xhtml:li></xhtml:ul>
		</profile-note>
		<fixtext><xhtml:p>In order to completely disable the this component, Delete the following files and directories:</xhtml:p>
			<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/ejb3-connectors-jboss-beans.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/ejb3-container-jboss-beans.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/ejb3-interceptors-aop.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/ejb3-timerservice-jboss-beans.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/profile-service-secured.jar</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/ejb2-container-jboss-beans.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/jboss-ejb3-endpoint-deployer.jar</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/ejb3-deployers-jboss-beans.xml </xhtml:li></xhtml:ul> </fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:110701"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1108"><!--Unused features should be disabled or deleted: Universal Unique Identifier (UUID) Generator-->
		<title>Unused features should be disabled or deleted: Universal Unique Identifier (UUID) Generator</title>
		<description>Features and services not in use should be removed. UUID Generator allows for the generation of unique identifiers for hosted Java applications.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following directory:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/uuid-key-generator.sar</xhtml:li></xhtml:ul> </profile-note>
		<fixtext><xhtml:p>In order to completely disable the this component, Delete this directory:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/uuid-key-generator.sar</xhtml:li></xhtml:ul> </fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:110801"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1109"><!--Unused features should be disabled or deleted: Java Message Service (JMS)-->
		<title>Unused features should be disabled or deleted: Java Message Service (JMS)</title>
		<description>Features and services not in use should be removed. Java Message Service is a component of Java Enterprise Edition that enables application to send and receive messages. It is a cornerstone service that many distributed applications are built on.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/props/messaging-roles.properties</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/props/messaging-users.properties</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/messaging</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rar</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/quartz-ra.rar</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/messaging-definitions-jboss-beans.xml</xhtml:li></xhtml:ul>
<xhtml:p>Validate changes to the following files:</xhtml:p>
<xhtml:ul><xhtml:li>Ensure all elements with references to JMS have been removed from: JBOSS_HOME/server/[PROFILE]/conf/standardjboss.xml</xhtml:li>
<xhtml:li>Ensure the following &lt;property&gt; element has been removed from JBOSS_HOME/server/[PROFILE]/conf/jbossts-properties.xml
<xhtml:pre><xhtml:code>&lt;property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/&gt;</xhtml:code></xhtml:pre></xhtml:li></xhtml:ul>
		</profile-note>
		<fixtext>
			<xhtml:p>In order to completely disable this component, take the following actions:</xhtml:p>
			
			<xhtml:p>Delete these files and directories:</xhtml:p>
			<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/props/messaging-roles.properties</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/props/messaging-users.properties</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/messaging</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rar</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/quartz-ra.rar</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/messaging-definitions-jboss-beans.xml</xhtml:li></xhtml:ul>
			
			<xhtml:p>Make the identified changes to the following files:</xhtml:p>
			<xhtml:ul><xhtml:li>Remove all elements with references to JMS from: JBOSS_HOME/server/[PROFILE]/conf/standardjboss.xml</xhtml:li>
			<xhtml:li>Remove the following &lt;property&gt; element from JBOSS_HOME/server/[PROFILE]/conf/jbossts-properties.xml
				
<xhtml:pre><xhtml:code>&lt;property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/&gt;</xhtml:code></xhtml:pre></xhtml:li></xhtml:ul>
					
		</fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:110901"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1110"><!--Unused features should be disabled or deleted: JBoss Mail-->
		<title>Unused features should be disabled or deleted: JBoss Mail</title>
		<description>Features and services not in use should be removed. JBoss Mail is a deployed package for Java Mail - a set of Java API's implementing an email server supporting the SMTP, POP3, and IMAP protocols.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/mail-ra.rar</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/mail-service.xml</xhtml:li></xhtml:ul> </profile-note>
		<fixtext><xhtml:p>In order to completely disable the this component, Delete the following files and directories:</xhtml:p>
			<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/mail-ra.rar</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/mail-service.xml</xhtml:li></xhtml:ul> </fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:111001"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1111"><!--Unused features should be disabled or deleted: JBoss Scheduling-->
		<title>Unused features should be disabled or deleted: JBoss Scheduling</title>
		<description>Features and services not in use should be removed. JBoss Scheduling implements a JBoss service that supports scheduling and running jobs for deployed Java applications.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/schedule-manager-service.xml</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/scheduler-service.xml </xhtml:li></xhtml:ul></profile-note>
		<fixtext><xhtml:p>In order to completely disable the this component, Delete the following files:</xhtml:p>
			<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/schedule-manager-service.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/scheduler-service.xml </xhtml:li></xhtml:ul> </fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:111101"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1112"><!--Unused features should be disabled or deleted: Hypersonic SQL Database (HSQLDB)-->
		<title>Unused features should be disabled or deleted: Hypersonic SQL Database (HSQLDB)</title>
		<description>Features and services not in use should be removed. HSQLDB is the default datasource configured to run with JBoss Enterprise Application Platform out of the box. It is not recommended for production usage.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/hsqldb-ds.xml</xhtml:li>
<xhtml:li>JBOSS_HOME/common/lib/hsqldb.jar</xhtml:li>
<xhtml:li>JBOSS_HOME/common/lib/hsqldb-plugin.jar</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/messaging/hsqldb-persistence-service.xml</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/data/hypersonic/</xhtml:li></xhtml:ul> </profile-note>
		<fixtext><xhtml:p>In order to completely disable the this component, Delete the following files and directories:</xhtml:p>
			<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/hsqldb-ds.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/common/lib/hsqldb.jar</xhtml:li>
				<xhtml:li>JBOSS_HOME/common/lib/hsqldb-plugin.jar</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/messaging/hsqldb-persistence-service.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/data/hypersonic/</xhtml:li></xhtml:ul> </fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:111201"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1113"><!--Unused features should be disabled or deleted: BeanShell (BSH) Deployer-->
		<title>Unused features should be disabled or deleted: BeanShell (BSH) Deployer</title>
		<description>Features and services not in use should be removed. The BSH Deployer allows for the hot deployment of one use execution scripts or services.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/bsh.deployer</xhtml:li></xhtml:ul> </profile-note>
		<fixtext><xhtml:p>In order to completely disable the this component, Delete the following files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/bsh.deployer</xhtml:li></xhtml:ul> </fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:111301"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1114"><!--Unused features should be disabled or deleted: JBossWS-->
		<title>Unused features should be disabled or deleted: JBossWS</title>
		<description>Features and services not in use should be removed. JBossWS is a web service framework for use with the JBoss Enterprise Application Platform.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/jax-ws-catalog.xml</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-roles.properties</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-users.properties</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jbossws.sar</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jbossws-console.war</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/jbossws.deployer</xhtml:li></xhtml:ul> </profile-note>
		<fixtext><xhtml:p>In order to completely disable the this component, Delete the following files and directories:</xhtml:p>
			<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/jax-ws-catalog.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-roles.properties</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-users.properties</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jbossws.sar</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jbossws-console.war</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/jbossws.deployer</xhtml:li></xhtml:ul> </fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:111401"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1115"><!--Unused features should be disabled or deleted: Seam-->
		<title>Unused features should be disabled or deleted: Seam</title>
		<description>Features and services not in use should be removed. Seam is an application framework for Java designed to reduce application complexity.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/seam.deployer</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/webbeans.deployer</xhtml:li></xhtml:ul> </profile-note>
		<fixtext><xhtml:p>In order to completely disable the this component, Delete the following files and directories:</xhtml:p>
			<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/seam.deployer</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/webbeans.deployer</xhtml:li></xhtml:ul> </fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:111501"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1116"><!--Unused features should be disabled or deleted: JBoss Internet Inter-ORB Protocol (IIOP)-->
		<title>Unused features should be disabled or deleted: JBoss Internet Inter-ORB Protocol (IIOP)</title>
		<description>Features and services not in use should be removed. JBoss IIOP implements a standards compliant CORBA server for JBoss.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/jacorb.properties</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/iiop-service.xml</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/ejb3.deployer/META-INF/ejb3-iiop-deployers-jboss-beans.xml</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/lib/jacorb.jar</xhtml:li></xhtml:ul>

<xhtml:p>Validate changes to the following files:</xhtml:p>
<xhtml:p>In JBOSS_HOME/server/[PROFILE]/conf/jndi.properties, Replace:</xhtml:p>
<xhtml:pre><xhtml:code>java.naming.factory.initial=org.jboss.iiop.naming.ORBInitialContextFactory</xhtml:code></xhtml:pre>
<xhtml:p>with</xhtml:p>
<xhtml:pre><xhtml:code>java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory</xhtml:code></xhtml:pre> </profile-note>

		<fixtext><xhtml:p>In order to completely disable this component, Delete these files and directories:</xhtml:p>
			<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/conf/jacorb.properties</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/iiop-service.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deployers/ejb3.deployer/META-INF/ejb3-iiop-deployers-jboss-beans.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/lib/jacorb.jar</xhtml:li></xhtml:ul>

			
<xhtml:p>Make the identified changes to the following files:</xhtml:p>
<xhtml:p>In JBOSS_HOME/server/[PROFILE]/conf/jndi.properties, Replace:</xhtml:p>
<xhtml:pre><xhtml:code>java.naming.factory.initial=org.jboss.iiop.naming.ORBInitialContextFactory</xhtml:code></xhtml:pre>
<xhtml:p>with</xhtml:p>
<xhtml:pre><xhtml:code>java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory</xhtml:code></xhtml:pre>
<xhtml:p>In JBOSS_HOME/server/[PROFILE]/conf/standardjboss.xml, Delete text:</xhtml:p> <xhtml:pre><xhtml:code>invoker-proxy-binding iiop</xhtml:code></xhtml:pre> </fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:111601"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1117"><!--Unused features should be disabled or deleted: Miscellaneous-->
		<title>Unused features should be disabled or deleted: Miscellaneous</title>
		<description>Miscellaneous features and services not in use should be removed.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]deployers/xnio.deployer</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]deployers/hibernate-deployer-jboss-beans.xml</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jboss-xa-jdbc.rar</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/profileservice-jboss-beans.xml</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/sqlexception-service.xml</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/xnio-provider.jar </xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/management/</xhtml:li></xhtml:ul></profile-note>
		<fixtext><xhtml:p>In order to completely disable these components, Delete these files and directories:</xhtml:p>
			<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]deployers/xnio.deployer</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]deployers/hibernate-deployer-jboss-beans.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jboss-xa-jdbc.rar</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/profileservice-jboss-beans.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/sqlexception-service.xml</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/xnio-provider.jar </xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/management/</xhtml:li></xhtml:ul>
</fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:111701"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1118"><!--Unused features should be disabled or deleted: HTTP Invokers-->
		<title>Unused features should be disabled or deleted: HTTP Invokers</title>
		<description>Features and services not in use should be removed. HTTP invocation allows the JBoss server to receive and act on remote instructions. This can be useful for administrators - especially in large or distributed environments.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>

		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:</xhtml:p>
<xhtml:p>For HTTP Invoker for JNDI, EJB and JMX:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/http-invoker.sar</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar</xhtml:li></xhtml:ul>
<xhtml:p>For JMS HTTP Invoker:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jms/jbossmq-httpil.sar</xhtml:li></xhtml:ul> </profile-note>
		<fixtext><xhtml:p>In order to completely disable HTTP Invoker for JNDI, EJB and JMX, Delete these files and directories:</xhtml:p>
			<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/http-invoker.sar</xhtml:li>
				<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar</xhtml:li></xhtml:ul>
<xhtml:p>In order to completely disable HTTP Invoker for JMS, Delete this directory:</xhtml:p>
			<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jms/jbossmq-httpil.sar</xhtml:li></xhtml:ul> </fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:111801"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1119"><!--Unused features should be disabled or deleted: Java Management Extensions (JMX) Invoker-->
		<title>Unused features should be disabled or deleted: Java Management Extensions (JMX) Invoker</title>
		<description>Features and services not in use should be removed. The JMX Invoker exposes the JMX MBeanServer interface via Remote Method Invocation compatible interface. This can be useful for administrators - especially in large or distributed environments.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml</xhtml:li></xhtml:ul> </profile-note>
		<fixtext><xhtml:p>In order to completely disable this component, Delete these files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml</xhtml:li></xhtml:ul> </fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:111901"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1120"><!--Unused features should be disabled or deleted: Pooled Invoker-->
		<title>Unused features should be disabled or deleted: Pooled Invoker</title>
		<description>Features and services not in use should be removed. The org.jboss.invocation.pooled.server.PooledInvoker provides RMI over a custom socket implementation of the Invoker interface.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate changes to the following files:</xhtml:p>
<xhtml:p>In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml Ensure the &lt;mbean&gt; with name attribute of "jboss:service=invoker,type=pooled" has been deleted. </xhtml:p></profile-note>
		<fixtext><xhtml:p>In order to completely disable this component, take the following actions:</xhtml:p>
<xhtml:p>In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml, Delete the &lt;mbean&gt; with name attribute of "jboss:service=invoker,type=pooled" </xhtml:p></fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:112001"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1121"><!--Unused features should be disabled or deleted: Java Remote Method Protocol (JRMP) Invoker-->
		<title>Unused features should be disabled or deleted: Java Remote Method Protocol (JRMP) Invoker</title>
		<description>Features and services not in use should be removed. The org.jboss.invocation.jrmp.server.JRMPInvoker provides the RMI/JRMP implementation of the Invoker interface.</description>
		<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
		<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
		<rationale><xhtml:p>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.</xhtml:p> </rationale>

		<profile-note tag="risk_score">3</profile-note>
		<profile-note tag="risk_level">Low</profile-note>
			<profile-note tag="dod_cat">CAT III</profile-note>
		
		<profile-note tag="nist_mapping">CM-7</profile-note>
		<profile-note tag="disa_mapping">DCPP-1</profile-note>
		<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate changes to the following files:</xhtml:p>
<xhtml:p>In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml, Ensure the &lt;mbean&gt; with name attribute of "jboss:service=invoker,type=jmrp" has been deleted.</xhtml:p> </profile-note>
		<fixtext><xhtml:p>In order to completely disable this component, take the following actions:</xhtml:p>
<xhtml:p>In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml, Delete the &lt;mbean&gt; with name attribute of "jboss:service=invoker,type=jmrp" </xhtml:p></fixtext>

		<check system="http://scap.nist.gov/schema/ocil/2">
			<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:112101"/>
		</check>
	</Rule>

		<Rule id="xccdf_com.redhat.eap5.scap_rule_1123"><!--Unused features should be disabled or deleted: Clustering-->
			<title>Unused features should be disabled or deleted: Clustering</title>
			<description>Features and services not in use should be removed. Clustering allows deployed applications to run distributed across multiple JBoss Enterprise Application Platform servers.</description>
			<reference>Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming</reference>
			<reference>DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf</reference>
			<rationale><xhtml:p>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.</xhtml:p> </rationale>

			<profile-note tag="risk_score">3</profile-note>
			<profile-note tag="risk_level">Low</profile-note>
				<profile-note tag="dod_cat">CAT III</profile-note>
			
			<profile-note tag="nist_mapping">CM-7</profile-note>
			<profile-note tag="disa_mapping">DCPP-1</profile-note>
			<profile-note tag="validation_text"><xhtml:p>Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:</xhtml:p>
<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy-hasingleton/</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/farm/</xhtml:li>
<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/cluster/</xhtml:li></xhtml:ul>
<xhtml:p>Validate this change to the following file:</xhtml:p>
<xhtml:p>In JBOSS_HOME/server/[PROFILE]/conf/bootstrap/profile.xml, Delete the following from "BootstrapProfileFactory":</xhtml:p>
<xhtml:pre><xhtml:code>&lt;property name="farmURIs"&gt;
	&lt;list elementClass="java.net.URI"&gt;
		&lt;value&gt;${jboss.server.home.url}farm&lt;/value&gt;
	&lt;/list&gt;
&lt;/property&gt;</xhtml:code></xhtml:pre> </profile-note>
			<fixtext><xhtml:p>In order to completely disable this component, take the following actions:</xhtml:p>
<xhtml:p>Delete these files and directories:</xhtml:p>
				<xhtml:ul><xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy-hasingleton/</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/farm/</xhtml:li>
					<xhtml:li>JBOSS_HOME/server/[PROFILE]/deploy/cluster/</xhtml:li></xhtml:ul>
<xhtml:p>In JBOSS_HOME/server/[PROFILE]/conf/bootstrap/profile.xml, Delete the following from "BootstrapProfileFactory":</xhtml:p>
<xhtml:pre><xhtml:code>&lt;property name="farmURIs"&gt;
	&lt;list elementClass="java.net.URI"&gt;
		&lt;value&gt;${jboss.server.home.url}farm&lt;/value&gt;
	&lt;/list&gt;
&lt;/property&gt;</xhtml:code></xhtml:pre> </fixtext>

			<check system="http://scap.nist.gov/schema/ocil/2">
				<check-content-ref href="eap5-ocil.xml" name="ocil:com.redhat.eap5.scap:questionnaire:112301"/>
			</check>
		</Rule>
	</Group>
</Benchmark>
