{
  "name": "stig_blackberry_bes_12.5.x_mdm",
  "date": "2017-06-05",
  "description": "This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.",
  "title": "BlackBerry BES 12.5.x MDM Security Technical Implementation Guide",
  "version": "1",
  "item_syntax": "^\\w-\\d+$",
  "section_separator": null,
  "items": [
    {
      "id": "V-68685",
      "title": "Before establishing a user session, the BES12 server must display an administrator-specified advisory notice and consent warning message regarding use of the BES12 server.",
      "description": "Note: The advisory notice and consent warning message is not required if the General Purpose OS or Network Device displays an advisory notice and consent warning message when the administrator logs on to the General Purpose OS or Network Device prior to accessing the MDM server or MDM Server platform.\n\nThe MDM server/server platform is required to display the DoD-approved system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. This ensures the legal requirements for auditing and monitoring are met. \n\nThe approved DoD text must be used as specified in KS referenced in DoDI 8500.01.\n\nThe non-bracketed text below must be used without any changes as the warning banner.\n\n[A. Use this banner for desktops, laptops, and other devices accommodating banners of 1300 characters. The banner must be implemented as a click-through banner at logon (to the extent permitted by the operating system), meaning it prevents further activity on the information system unless and until the user executes a positive action to manifest agreement by clicking on a box indicating “OK”.]\n\nYou are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. \nBy using this IS (which includes any device attached to this IS), you consent to the following conditions: \n-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. \n-At any time, the USG may inspect and seize data stored on this IS. \n-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. \n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. \n-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.\n\nSFR ID: FMT_SMF_EXT.1.1(2) Refinement",
      "severity": "low"
    },
    {
      "id": "V-68687",
      "title": "The BES12 server must be configured with the Administrator roles: a. MD user b. Server primary administrator c. Security configuration administrator d. Device user group administrator e. Auditor.",
      "description": "Having several roles for the MDM 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 they may not understand or approve of, which can weaken overall security and increase the risk of compromise.\n\nRoles\na. MD user: able to log onto the application store and request approved applications\nb. Server primary administrator: primary administrator for the server, including server installation, configuration, patching, and setting up admin accounts\nc. Security configuration administrator: has the ability to define new policies but not to push them to managed mobile devices\nd. Device user group administrator: has the ability to set up new user accounts, add devices, push security policies, and issue administrative commands to managed mobile devices or MDM agents\ne. Auditor: has the ability to set audit configuration parameters and delete or modify the content of logs\n\nSFR ID: FMT_SMR.1.1(1) Refinement",
      "severity": "medium"
    },
    {
      "id": "V-68689",
      "title": "The BES12 server must be configured to enable all required audit events: a. Failure to push a new application on a managed mobile device; b. Failure to update an existing application on a managed mobile device.",
      "description": "Failure to generate these audit records makes it more difficult to identify or investigate attempted or successful compromises, potentially causing incidents to last longer than necessary.\n\nSFR ID: FAU_GEN.1.1(2) Refinement",
      "severity": "medium"
    },
    {
      "id": "V-68691",
      "title": "The BES12 server must leverage the BES12 Platform user accounts and groups for BES12 server user identification and authentication.",
      "description": "A comprehensive account management process that includes automation helps to ensure the accounts designated as requiring attention are consistently and promptly addressed. If an attacker compromises an account, the entire MDM server infrastructure is at risk. Providing automated support functions for the management of accounts will ensure only active accounts will be granted access with the proper authorization levels. These objectives are best achieved by configuring the MDM server to leverage an enterprise authentication mechanism (e.g., Microsoft Active Directory Kerberos).\n\nSFR ID: FIA",
      "severity": "medium"
    },
    {
      "id": "V-68693",
      "title": "The BES12 server must initiate a session lock after a 15-minute period of inactivity.",
      "description": "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.\n\nThe 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.\n\nSFR ID: FMT_SMF.1.1(1) Refinement",
      "severity": "medium"
    },
    {
      "id": "V-68695",
      "title": "The BES12 server platform must be protected by a DoD-approved firewall.",
      "description": "Most information systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Unneeded services and processes provide additional threat vectors and avenues of attack to the information system. The MDM server is a critical component of the mobility architecture and must be configured to only those ports, protocols, and services (PPS) necessary to support functionality, all others must be expressly disabled or removed. A DoD-approved firewall implements the required network restrictions. A host-based firewall is appropriate where the MDM server runs on a standalone platform. Network firewalls or other architectures may be preferred where the MDM server runs in a cloud or virtualized solution.\n\nSFR ID: FMT_SMF.1.1(1) Refinement",
      "severity": "medium"
    },
    {
      "id": "V-68697",
      "title": "The firewall protecting the BES12 server platform must be configured to restrict all network traffic to and from all addresses with the exception of ports, protocols, and IP address ranges required to support BES12 server and platform functions.",
      "description": "Most information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations. Since MDM server is a critical component of the mobility architecture and must be configured to only those ports, protocols, and services (PPS) necessary to support functionality, all others must be expressly disabled or removed. A firewall installed on the MDM server provides a protection mechanism to ensure unwanted service requests do not reach the MDM server and outbound traffic is limited to only MDM server functionality.\n\nSFR ID: FMT_SMF.1.1(1) Refinement",
      "severity": "medium"
    },
    {
      "id": "V-68703",
      "title": "The BES12 server must be configured to disable a users capability to perform self-service tasks.",
      "description": "The security posture of a BlackBerry device or the DoD BlackBerry service could be compromised if users are able to perform self-service tasks, including activating unauthorized devices. In the DoD environment, strict configuration management of the security posture is required to protect sensitive DoD data and network security.\n\nSFR ID: FMT",
      "severity": "medium"
    },
    {
      "id": "V-68705",
      "title": "The server PKI digital certificate installed on the BES12 Server to support Consoles and BlackBerry Web Services authentication must be a DoD PKI issued certificate. A self-signed certificate will not be used.",
      "description": "When a self-signed PKI certificate is used, a rogue BDS server can impersonate the DoD BDS server during SA connections to the BAS or when a BlackBerry user uses BWDM to connect to the BAS. In addition, DoDI 8520-02 requires that PKI certificates come from a trusted DoD PKI.\n\nSFR ID: FIA",
      "severity": "medium"
    }
  ]
}