Omnissa WS1 UEM Server Security Technical Implementation Guide

Application management includes the ability to control the number of users and user sessions that utilize an application. Limiting the number of allowed users and sessions per user is helpful in limiting risks related to denial-of-service (DoS) attacks. This requirement may be met via the application or by utilizing information system session control provided by a web server with specialized session management capabilities. If it has been specified that this requirement will be handled by the application, the capability to limit the maximum number of concurrent single user sessions must be designed and built into the application. This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions must be defined based upon mission needs and the operational environment for each system. Satisfies: FMT_SMF.1.1(2) b Reference: PP-MDM-431010

A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system, but does not log out because of the temporary nature of the absence. Rather than relying on the user to manually lock their application session prior to vacating the vicinity, applications need to be able to identify when a user's application session has idled and take action to initiate the session lock. The session lock is implemented at the point where session activity can be determined and/or controlled. This is typically at the operating system level and results in a system lock, but may be at the application level where the application interface window is secured instead. Satisfies: FMT_SMF.1.1(2) c.8 Reference: PP-MDM-411047 Satisfies: SRG-APP-000003-UEM-000003, SRG-APP-000295-UEM-000169

Enterprise environments make application account management challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error. A comprehensive application account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated or by disabling accounts located in noncentralized account stores such as multiple servers. This requirement applies to all account types, including individual/user, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. The application must be configured to automatically provide account management functions and these functions must immediately enforce the organization's current account policy. The automated mechanisms may reside within the application itself or may be offered by the operating system or other infrastructure providing automated account management capabilities. Automated mechanisms may be comprised of differing technologies that when placed together contain an overall automated mechanism supporting an organization's automated account management requirements. Account management functions include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephonic notification to report atypical system account usage. Satisfies: SRG-APP-000023-UEM-000012, SRG-APP-000025-UEM-000014, SRG-APP-000148-UEM-000082, SRG-APP-000149-UEM-000083, SRG-APP-000319-UEM-000192, SRG-APP-000345-UEM-000218, SRG-APP-000400-UEM-000271, SRG-APP-000153-UEM-000087, SRG-APP-000157-UEM-000091, SRG-APP-000401-UEM-000272

By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. Satisfies: FMT_SMF.1(2)b. Reference: PP-MDM-431028

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both. Satisfies: FAU_ALT_EXT.1.1 Reference: PP-MDM-412059

All ports, protocols, and services used on DoW networks must be approved and registered via the DoW PPSM process. This is to ensure a risk assessment has been completed before a new port, protocol, or service is configured on a DoW network and has been approved by proper DoW authorities. Otherwise, the new port, protocol, or service could cause a vulnerability to the DoW network, which could be exploited by an adversary. Satisfies: FMT_SMF.1.1(2) Refinement b Reference: PP-MDM-431006

DoW sites may implement one "break-glass" WS1 UEM local account for the purpose of server recovery. This account must use two-factor authentication to provide secure access control. At the current time, WS1 UEM only supports OTP or SMS based authentication as the second authentication factor.

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity. Note: UEM server logs include logs of UEM events and logs transferred to the UEM server by UEM agents of managed devices. Satisfies: FMT_SMF.1.1(2) c.8, FAU_STG_EXT.1.1(1) Reference: PP-MDM-411054 Satisfies: SRG-APP-000358-UEM-000228, SRG-APP-000089-UEM-000050, SRG-APP-000125-UEM-000074, SRG-APP-000275-UEM-000157, SRG-APP-000515-UEM-000390, SRG-APP-000291-UEM-000165, SRG-APP-000292-UEM-000166, SRG-APP-000293-UEM-000167, SRG-APP-000294-UEM-000168, SRG-APP-000320-UEM-000193

If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. Time stamps generated by the application include date and time. Time is commonly expressed in UTC, a modern continuation of GMT, or local time with an offset from UTC. Satisfies: FAU_GEN.1.2(1) Satisfies: SRG-APP-000374-UEM-000244, SRG-APP-000375-UEM-000245

Without verification, security functions may not operate correctly and this failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. This requirement applies to applications performing security functions and the applications performing security function verification/testing. Satisfies: FAU_NET_EXT.1.1, FMT_SMF.1.1(2) c.3 Reference: PP-MDM-411057

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password. Satisfies: FMT_SMF.1(2)b Reference: PP-MDM-431018

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. Satisfies: FMT_SMF.1(2)b Reference: PP-MDM-431025

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Satisfies: FMT_SMF.1(2)b Reference: PP-MDM-431020 Satisfies: SRG-APP-000166-UEM-000096, SRG-APP-000167-UEM-000097, SRG-APP-000168-UEM-000098, SRG-APP-000169-UEM-000099

Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed at specific intervals. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. This requirement does not include emergency administration accounts, which are meant for access to the application in case of failure. These accounts are not required to have maximum password lifetime restrictions. Satisfies: FMT_SMF.1(2)b Reference: PP-MDM-431024

Having several administrative roles for the UEM server supports separation of duties. This allows administrator-level privileges to be granted granularly, such as giving application management privileges to one group and security policy privileges to another group. This helps prevent administrators from intentionally or inadvertently altering other settings and configurations of which they may not understand or approve, which can weaken overall security and increase the risk of compromise. Pre-Defined roles: System Administrator: Responsible for server installation, initial configuration, and maintenance functions. Responsible for the setup and maintenance of security configuration administrator and auditor accounts. Responsible for the maintenance of applications in the MAS. AirWatch Administrator: The AirWatch Administrator role allows comprehensive access to the Workspace ONE UEM environment. However, this access excludes the Administration tab under System Configuration, because that tab manages top-level UEM console settings. Device Manager: The Device Manager role grants users significant access to the UEM console. However, this role is not designed to configure most System Configurations. These configurations include Active Directory (AD)/Lightweight Directory Access Protocol (LDAP), Simple Mail Transfer Protocol (SMTP), device-UEM interface hubs such as the Omnissa Workspace ONE Intelligent Hub, and so on. For these tasks, use a top-tier role like the AirWatch Administrator or System Administrator. Read Only: The Read Only role provides access to most of the UEM console, but limits access to read-only status. Use this role to audit or record the settings in a Workspace ONE UEM environment. This role is not useful for system operators or administrators but is ideal for compliance auditors or scanners. Satisfies: FMT_SMR.1.1(1) Reference: PP-MDM-411058