Oracle Java Runtime Environment (JRE) 8 STIG for UNIX

By default no deployment.config file exists; thus, no system-wide deployment.properties file exists. The file must be created. The deployment.config file is used for specifying the location and execution of system-level properties for the Java Runtime Environment. Without the deployment.config file, setting particular options for the Java control panel is impossible.

The deployment.config configuration file contains two keys. The "deployment.properties" key includes the path of the "deployment.properties" file and the "deployment.properties.mandatory" key contains either a TRUE or FALSE value. If the path specified to "deployment.properties" does not lead to a "deployment.properties" file, the value of the “deployment.system.config.mandatory” key determines how JRE will handle the situation. If the value of the "deployment.system.config.mandatory" key is TRUE and if the path to the "deployment.properties" file is invalid, the JRE will not allow Java applications to run. This is the desired behavior.

By default no deployment.properties file exists; thus, no system-wide deployment exists. The file must be created. The deployment.properties file is used for specifying keys for the Java Runtime Environment. Each option in the Java control panel is represented by property keys. These keys adjust the options in the Java control panel based on the value assigned to that key. Without the deployment.properties file, setting particular options for the Java control panel is impossible.

Java Web Start (JWS) applications are the most commonly used. Denying these applications could be detrimental to the user experience. Whitelisting, blacklisting, and signing of applications help mitigate the risk of running JWS applications.

Java applets exist both signed and unsigned. Even for signed applets, there can be many sources, some of which may be purveyors of malware. Applet sources considered trusted can have their information populated into the browser, enabling Java to validate applets against trusted sources. Permitting execution of signed Java applets from untrusted sources may result in acquiring malware, and risks system modification, invasion of privacy, or denial of service.

Java applets exist both signed and unsigned. Even for signed applets, there can be many sources, some of which may be purveyors of malware. Applet sources considered trusted can have their information populated into the browser, enabling Java to validate applets against trusted sources. Permitting execution of signed Java applets from untrusted sources may result in acquiring malware, and risks system modification, invasion of privacy, or denial of service. Ensuring users cannot change settings contributes to a more consistent security profile.

Online certificate validation provides a real-time option to validate a certificate. When enabled, if a certificate is presented, the status of the certificate is requested. The status is sent back as “current”, “expired”, or “unknown”. Online certificate validation provides a greater degree of validation of certificates when running a signed Java applet. Permitting execution of an applet with an invalid certificate may result in malware, system modification, invasion of privacy, and denial of service.

Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed, downloaded, or executed on all endpoints (e.g., servers, workstations, and smart phones). This requirement applies to applications that execute, evaluate, or otherwise process mobile code (e.g., web applications, browsers, and anti-virus applications).

Utilizing a whitelist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting. Verification of whitelisted software can occur either prior to execution or at system startup. This requirement applies to configuration management applications or similar types of applications designed to manage system processes and configurations (e.g., HBSS and software wrappers).

Utilizing a whitelist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting. Verification of whitelisted software can occur either prior to execution or at system startup. This requirement applies to configuration management applications or similar types of applications designed to manage system processes and configurations (e.g., HBSS and software wrappers).

A certificate revocation list is a directory which contains a list of certificates that have been revoked for various reasons. Certificates may be revoked due to improper issuance, compromise of the certificate, and failure to adhere to policy. Therefore, any certificate found on a CRL should not be trusted. Permitting execution of an applet published with a revoked certificate may result in spoofing, malware, system modification, invasion of privacy, and denial of service.

Certificates may be revoked due to improper issuance, compromise of the certificate, and failure to adhere to policy. Therefore, any certificate found revoked on a CRL or via Online Certificate Status Protocol (OCSP) should not be trusted. Permitting execution of an applet published with a revoked certificate may result in spoofing, malware, system modification, invasion of privacy, and denial of service. Ensuring users cannot change these settings assures a more consistent security profile.

Mobile code can cause damage to the system. It can execute without explicit action from, or notification to, a user. Actions enforced before executing mobile code include, for example, prompting users prior to opening email attachments and disabling automatic execution. This requirement applies to mobile code-enabled software, which is capable of executing one or more types of mobile code.

Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by adversaries. Some information technology products may remove older versions of software automatically from the information system.