{ "name": "stig_sun_ray_4", "date": "2015-04-02", "description": "The Sun Ray 4 Security Technical Implementation Guide (STIG) is published as a tool to improve the security of Department of Defense (DoD) information systems. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.", "title": "Sun Ray 4 STIG", "version": "1", "item_syntax": "^\\w-\\d+$", "section_separator": null, "items": [ { "id": "V-16061", "title": "Sun Ray Desktop Unit traffic is not isolated logically through the use of a dedicated VLAN or network segment.", "description": "Isolated LANs provide a greater degree of security than traditional LANs since only authorized users and devices are allowed to connect. Authorized users and devices are configured through the use of access control lists. This logical separation provides better performance through broadcast reduction, and reduced configuration management for Sun Ray Desktop Unit device moves, additions, and changes. ", "severity": "medium" }, { "id": "V-16062", "title": "User tokens are not forced to authenticate to the Sun Ray Server.", "description": "The Sun Ray Server must be configured to permit access only to smart cards that are registered in the Sun Ray Datastore.", "severity": "low" }, { "id": "V-16063", "title": "Users kiosk mode timeout is configured with no value.", "description": "If no value is specified for the number of seconds for a disconnected kiosk session, the termination of disconnected sessions will be disabled. This could potentially leave open sessions and may cause the kiosk sessions to start incorrectly or to crash due to lack of resources from many sessions being open. ", "severity": "low" }, { "id": "V-16064", "title": "Self-registration is permitted for users.", "description": "Sun Ray Desktop Unit users are not registered centrally for users by the system administrator. With self-registration, the system administrator does not assign registered tokens to the authorized users. This poses a security risk since users may be able to register themselves in the Sun Ray administration database. If an unauthorized user obtains access to a Sun Ray Desktop unit, then that user may be able to start a session without any intervention from the system administrator. ", "severity": "high" }, { "id": "V-16071", "title": "Default administrator account is used to access the administration tool.", "description": "The default administrator account, “admin”, does not provide an audit trail of who logged in and the default password may be easily guessed or be publicly known. If system administrators use the “admin” account, this could potentially allow modifications to the Sun Ray system with no user accountability. Also, unauthorized users may gain access to the administration tool and make modifications that disable the Sun Ray system. Therefore, system administrators will have individual user accounts to administer the Sun Ray Server, and the “admin” account will be removed to ensure that audit trails are present. ", "severity": "high" }, { "id": "V-16072", "title": "Unauthorized users have access to the Sun Ray administration tool. ", "description": "Unauthorized users accessing the Sun Ray administration tool could modify or disable the entire Sun Ray server or network. Unrestricted access may also give access to other operating system daemons and applications. Restricting access to only authorized users will ensure only approved users are able to access the Sun Ray administration tool.\n", "severity": "high" }, { "id": "V-16075", "title": "Sun Ray Server administrator session default timeout is used.", "description": "Administrator sessions to the Sun Ray Server are critical to the availability and integrity of the system. The default timeout for these sessions is 30 minutes of inactivity. This session timeout is longer than the 10 minutes required by the Operating System and Network STIGs. Therefore, all administrator sessions will be configured to 10 minutes of inactivity to ensure unauthorized users do not gain access to the system configuration. ", "severity": "medium" }, { "id": "V-16083", "title": "Sun Ray Desktop Units firmware is not at the minimum version.", "description": "All Sun Ray firmware is supported by the Sun Ray Desktop Units PROM. Therefore, older versions of the Sun Ray firmware may not be as secure as newer versions. In order to support encryption between the Sun Ray Desktop Unit and the Sun Ray server, the minimum firmware required is version 2.0. All previous Sun Ray Desktop Unit firmware sends traffic in plain text to the server", "severity": "medium" }, { "id": "V-16100", "title": "Sun Ray Server software patches are not tested in a development environment first before deploying to production.", "description": "Organizations need to stay current with all applicable Sun Ray Server software updates that are released from Sun Microsystems. New Sun Ray Server patches and updates should be reviewed for the Sun Ray Server before moving them into a production environment. Sun Ray Server patches will be tested first in a development environment and any issues or special precautions will be documented, as a patch could technically disable all Sun Ray Desktop Units, cause unexpected performance or availability issues.", "severity": "medium" }, { "id": "V-16103", "title": "The Sun Ray server software is not current with the latest available patches.", "description": "Sun Ray software patches mitigate many known vulnerabilities. To ensure that attackers cannot take advantage of known Sun Ray vulnerabilities, applicable software patches must be applied as they are released.", "severity": "medium" }, { "id": "V-16143", "title": "USB ports are not disabled for all Sun Ray Desktop Units. This requirement excludes the keyboard and mouse.", "description": "Enabled USB ports may be used by users to store files, scripts, and executables. USB thumb drives, USB hard drives, and USB appliances may be inserted into these ports. If unapproved executables, scripts, or malware reside on the USB device, executing these or moving these onto the network may cause a virus infection or unapproved applications running on the network. Classified data may be copied inadvertently to the unclassified network if ports have been enabled. Limiting the use of these ports will prevent these USB programs and files from accessing the network. ", "severity": "medium" }, { "id": "V-16145", "title": "The Sun Ray server console administration sessions are not encrypted.", "description": "Unencrypted Sun Ray server console sessions do not protect the information transmitted from being read or viewed by anyone. Unencrypted sessions are vulnerable to a number of attacks to include man-in-the-middle attacks, TCP Hijacking, and replay. ", "severity": "medium" }, { "id": "V-16146", "title": "Sun Ray Desktop Unit to server communication is not encrypted.", "description": "In earlier versions of Sun Ray Server Software, data packets on the Sun Ray interconnect were sent in the clear or in plaintext. This made it easy to “snoop” the traffic and recover vital and private user information, which malicious users might misuse. To avoid this type of attack, Sun Ray Server Software allows administrators to enable traffic encryption. The encryption algorithm used is the ARCFOUR or RC4. \n\nNOTE: Terminal Services for Windows 2000 uses the same RC4 encryption algorithm. RDP traffic is encrypted using 128 bit encryption. The algorithm used for encryption depends on the encryption mode. Windows 2003 is FIPS compliant. In FIPS mode, 3DES and SHA1 are used. In non-FIPS mode, RC4 (encryption) and MD5 (keyed hashing) are used. \n", "severity": "medium" }, { "id": "V-16148", "title": "Server Authentication is not configured on the Sun Ray server. ", "description": "It is possible to spoof a Sun Ray server or a Sun Ray client and pose as either. This leads to the man-in-the-middle attack, in which an impostor claims to be the Sun Ray server for the clients and pretends to be a client for the server. It then goes about intercepting all the messages and having access to all the secure data. Client and server authentication can resolve this type of attack. Server-side authentication is only supported, through the pre-configured public-private key pairs in Sun Ray Server Software and firmware. The Digital Signature Algorithm (DSA) is used to verify that clients are communicating with a valid Sun Ray server. This authentication scheme is not completely foolproof, but it mitigates man-in-the-middle attacks and makes it harder for attackers to spoof Sun Ray Server Software.", "severity": "medium" }, { "id": "V-16151", "title": "The Security Mode is not configured to “Hard” on the Sun Ray server.", "description": "Soft security mode ensures that every client requesting a session gets one, even if security requirements cannot be met. As a result, the soft security mode grants insecure sessions. Hard security mode ensures that every session is secure. If security requirements cannot be met, the session is refused. ", "severity": "high" }, { "id": "V-16153", "title": "The Sun Ray system is not configured for high availability. ", "description": "High availability is important when implementing the Sun Ray system since users authenticate and establish sessions with the Sun Ray servers. User data may also be stored on the Sun Ray server, and if this server should fail the entire user community will not be able to access the network. Providing a secondary server ensures the session and data availability for the user community. ", "severity": "medium" }, { "id": "V-16155", "title": "A failover group signature is not configured on all Sun Ray servers in the failover group. ", "description": "Without the use of a failover group signature, an unauthorized Sun Ray server may become a member of the group, thereby receiving replication traffic. Servers in a group authenticate one another using a common group signature. The group signature is a key used to sign messages sent between servers in a group, and it must be configured to be identical on each server.", "severity": "medium" }, { "id": "V-16157", "title": "The Sun Ray server does not record log files.", "description": "Logs form a recorded history or audit trail of the Sun Ray server system events, making it easier for system administrators to track down intermittent problems, review past events, and piece together information if an investigation is required. Without this recorded history, potential attacks and suspicious activity will go unnoticed. \n\nLogging must be comprehensive to be useful for both intrusion monitoring and security investigations. Setting logging at the severity notice should capture most relevant events without requiring unacceptable levels of data storage. The severity levels notice and debug are also available to organizations that require additional logging for certain events or applications.\n", "severity": "medium" }, { "id": "V-16158", "title": "The Sun Ray server logs are more permissive than 640.", "description": "The Sun Ray server logs should be appropriately secured, having file permissions that restrict unauthorized changes or viewing. Unauthorized users accessing the audit logs may delete, modify, or change data within the logs for malicious purposes. Any alternation in the audit logs will not give the system administrator an accurate history of the events that occurred.", "severity": "medium" }, { "id": "V-16159", "title": "The Sun Ray audit logs are not retained for a minimum of one year.", "description": "Storing log files for at least a year provides a way to recover these files in case an investigation is necessary. Typically these files are stored offline on tape media or external networks. Log files enable the enforcement of individual accountability by creating a reconstruction of events. They also assist in problem identification that may lead to problem resolution. If these log files are not retained, there is no way to trace or reconstruct the events, and if it was discovered the network was hacked, there would be no way to trace the full extent of the compromise. \nThe Sun Ray audit logs should be appropriately backed-up and stored in order for them to be examined at a future time. If audit logs are unavailable to be viewed at a later time, system compromises and/or attacks will not be traceable. Therefore, Sun Ray audit logs will retained for a minimum of 1 year. \n", "severity": "medium" }, { "id": "V-16349", "title": "The Sun Ray system backups are not performed in accordance with the assigned MAC level. ", "description": "The three MAC level has different requirements for backing up data. For MAC III systems it is necessary to ensure that backups are performed weekly. For MAC II systems backups are performed daily and the recovery media is stored off-site in a protected facility in accordance with its mission assurance category and confidentiality level. In MAC I systems backups are maintained through a redundant secondary system, not colocated, and can be activated without loss of data or disruption to the operation. \n\nNOTE: The MAC level indicates the criticality of an asset to the DoD mission based on its purpose and user community. The Sensitivity level of an asset must also be determined and is based on whether the data or resource is restricted or releasable to the public. There are three MAC and three Sensitivity levels. The MAC and Sensitivity level of the asset are an important factor in determining the security strength the access control solution must provide. MAC and Sensitivity Levels are further defined in Appendix C and DoDI 8500.2.\n", "severity": "medium" }, { "id": "V-16351", "title": "Administrative password is not configured for Desktop Units.", "description": "From a physical security perspective, the DTU pop-menu is accessible, therefore a username/password or administrative only password is recommended to protect the device from unauthorized changes made locally.", "severity": "medium" }, { "id": "V-16354", "title": "Sun Ray Desktop Units are not assigned with DHCP reserved IP addresses.", "description": "Sun Ray servers will not distribute DHCP addresses to non-Sun Ray Desktop Units. Configuring Sun Ray Desktop Units with reserved IP addresses will ensure no rogue desktop units are attached to the network and able to connect to the Sun Ray network. This will prevent unauthorized devices from receiving DHCP addresses from Sun Ray servers or external DHCP servers, and prevent access to the Sun Ray network.", "severity": "low" }, { "id": "V-16379", "title": "There is no documented baseline of the default setuid and setgid files. ", "description": "There are programs that have setuid and setgid flags set within the Sun Ray server. Setuid is a flag that allows an application to temporarily change the permissions of the user running the application by setting the effective user ID to the program owner’s user ID. Setgid is a flag that allows an application to temporarily change the permissions of the group running the application by setting the effective group ID to the program owner’s group ID. aseline of these applications will ensure that any unauthorized modifications to these files will detected.\n\nSeveral programs on the Sun Ray server have setuid and setgid flags installed by default. Disabling any of the setgid or setuid applications will result in problems with the Sun Ray system. Furthermore, having a documented baseline of these applications will ensure that any unauthorized modifications to these files will be detected.\n", "severity": "medium" }, { "id": "V-16393", "title": "Sun Ray server does not send logs to syslog server. ", "description": "Remote logging is essential in monitoring servers and detecting intrusion. If an intruder is able to obtain root on a host, they may be able to edit the system logs to remove all traces of the attack. If the logs are stored off the machine, they can be analyzed for suspicious activity and used for prosecuting the attacker. Centralized log monitoring and storage is a critical component of incident response and assuring the integrity of system logs. ", "severity": "low" }, { "id": "V-16394", "title": "The Sun Management Center does not monitor daemons, failover groups, and interconnects.", "description": "Without an on-line monitoring system in place, unusual or inappropriate activity will could go unnoticed or without detection. Activity could include system services stopping, starting, file changes, and so on. These changes may happen before the system administrator has time to review any logs. ", "severity": "medium" }, { "id": "V-16395", "title": "Sun Ray Server is not properly registered in VMS or database.", "description": "The Vulnerability Management System (VMS) was developed to interface with the DOD Enterprise tools to assist all DOD CC/S/As in the identification of security vulnerabilities and track the issues through the lifecycle of the vulnerabilities existence. To ensure both the emerging and known vulnerabilities are addressed on a system, VMS tracks the existence of all potential vulnerabilities based on the posture of an asset. As a result, all vulnerabilities are tracked through their lifecycle.\n\nVulnerability Management is the process of ensuring that all network assets that are affected by an IAVM notice are addressed and corrected within a time period specified in the IAVM notice. VMS will notify commands, services, and agencies of new and potential security vulnerabilities. VMS meets the DoD mandate to ensure information system vulnerability alert notifications are received and acted on by all SAs. Keeping the inventory of assets current allows for tracking of virtualization servers and resources, and supports a successful IAVM process. The ability to track assets improves the effective use of virtualization assets, information assurance auditing efforts, as well as optimizing incident response times.\n", "severity": "medium" }, { "id": "V-16396", "title": "Sun Ray servers are not configured with the correct posture in VMS.", "description": "Correctly configuring the Sun Ray asset in VMS will ensure that the appropriate vulnerabilities are assigned to the asset. If the asset is not configured with the correct posture, vulnerabilities may be open on the asset. These open vulnerabilities may allow an attacker to access the system. ", "severity": "medium" }, { "id": "V-17455", "title": "The Sun Ray Session Server (SRSS) is not located in a DMZ or screened subnet.", "description": "If the SSRS is configured to service external clients from the internal enclave, there is a potential that an external adversary can obtain information about internal hosts that could assist the adversary in an attack. Firewalls, ACLs, and DMZs are used to enforce these types of restrictions and are components in the defense-in-depth architecture. The SRSS must be located in a protected DMZ if the server is servicing clients outside the local enclave. If the SRSS is only servicing clients inside the local enclave, then it must be behind the enclave and not part of the DMZ that houses public servers.\nNote: A DMZ is a physical or logical subnetwork that usually contains an organization's external services to a larger, untrusted network, typically the Internet. The purpose of a DMZ is to add an additional layer of security to an organization's local area network (LAN). DoD Instruction 8500.2 requires a DMZ for confidentiality levels of High and Medium identified as classified and sensitive domains respectively. A DMZ provides boundary protection for architectures that interconnect enclaves.\n", "severity": "medium" } ] }