Security Configuration Guide Samsung Galaxy S9 and S9+ Devices · implementing Samsung Galaxy S9 devices in their fleet. The guide also contains instructions and techniques to configure

Security Configuration Guide Samsung Galaxy S9 and S9+ Devices Using Samsung Knox 3.1 with Android 8.0 or higher

SEPTEMBER 2019

2

2

Table of Contents

Introduction 5

Audience 5

Purpose 5

Samsung, Android and the Australian Government Information Security Manual 6

Evaluation status 6

General advice 7

Introduction to mobile device security 7

Samsung Knox container 8

Samsung encryption 8

Samsung Knox Platform for Enterprise Premium Key 8

Advice to authorising officers 9

S9 platform and the Essential Eight 9

S9 platform feature summary and risk considerations 11

Knox container 11

Knox container passcode 11

Device passcode 12

Non-native applications inside the Knox container 12

Non-native applications outside the Knox container 12

Mobile Device Management 13

Mobile Application Management 13

Bring Your Own Device 14

Virtual Private Network 14

3

3

Unknown sources 14

SDP aware email applications running inside Knox container 15

Non-SDP aware email application running inside Knox container 15

All email applications running outside Knox container 16

Document preview running inside Knox container 16

External storage 16

Application whitelist 17

Daily backups 17

Office for Android for government documents 17

Mobile device administration 19

Managing mobile device security 19

Purchasing and enrolling devices 19

Revoking use, end of life and device disposal 19

Self-assessment of non-native applications 20

Topics to guide user behaviour 21

Data spill 21

Peripherals and other connectivity 21

Charging 21

Android Debug Bridge, USB debugging and developer mode 21

Direct Memory Access 21

USB storage 21

Bluetooth 21

Wi-Fi 22

Personal assistants 22

Display output or casting 22

4

4

Recommended device settings 23

Knox Workspace settings 23

Non-Workspace device settings 28

Glossary of cyber security terms 36

Further information 39

Contact details 40

5

Introduction This guide has been provided by the Australian Signals Directorate (ASD)’s Australian Cyber Security Centre (ACSC).

ASD provides guidance and other assistance to Australian federal and state organisations on matters relating to the security and integrity of information that is processed, stored or communicated by electronic or similar means.

The ACSC is located within ASD and leads the Australian government’s efforts to improve cyber security. Its role is to help make Australia the safest place to connect online.

The ACSC has developed this guidance to assist Australian Government and industry partners to understand the risks of deploying the S9 platform and the requirements for the S9 platform to handle Australian government data.

Audience

To use this guide, readers should be familiar with basic networking concepts, be an experienced mobile device system administrator, and be or have access to an experienced network administrator.

Parts of this guide will make reference to product features that will require the engagement of other software, networking equipment, firewall or Mobile Device Management (MDM) vendors. While every effort has been made to ensure content involving any third party vendor products is correct at time of writing, organisations should always check with these vendors when planning their system implementation.

Note: Mention of third party products is not a specific endorsement of that vendor over another, and they are mentioned for illustrative purposes only.

Some security configuration instructions within this guide are complex, and if implemented incorrectly could reduce the security of the device, the network or the organisation’s overall security posture. These instructions should only be interpreted by experienced systems administrators and should be used in conjunction with thorough testing.

Purpose

This guide provides information for Australian government organisations on Australian Samsung Galaxy S9 and S9+ mobile devices and their security risks that should be considered before being introduced into an organisation’s mobile fleet. The content can be widely applied by commercial organisation and enterprises.

This guide provides information and an outline of risks for Australian government organisations to consider before implementing Samsung Galaxy S9 devices in their fleet. The guide also contains instructions and techniques to configure the security of Samsung Galaxy S9 models SM-G960F and S9+ SM-G965F. These devices use the Exynos mobile processor and run Samsung Knox 3.1, Android 8.0 or higher. Throughout this guide, these devices and software combinations will be referred to as the ‘S9 platform’.

The advice in this guide has been written for use of the S9 platform within Australia. Organisations and individuals seeking to use S9 platform devices overseas should also refer to Travelling Overseas with Mobile Devices at https://www.cyber.gov.au/publications/travelling-overseas-with-electronic-devices.

Implementing the settings advised in this guide can significantly reduce system functionality and user experience. Authorising officers are encouraged to consider the balance of user requirements and security, as not all advice may be appropriate for every user or environment.

Organisations should seek approval from their authorising officer to allow for the formal acceptance of the risks involved. Refer to the applying a risk-based approach to cyber security section of the Australian Government Information Security Manual (ISM) for more information.

https://www.cyber.gov.au/publications/travelling-overseas-with-electronic-devices

6

Samsung, Android and the Australian Government Information Security Manual

This guide reflects ISM policy. Currently, not all ISM requirements can be implemented on the S9 platform. In these cases, risk mitigation measures are provided in the Advice to authorising officers section.

The Recommended device settings section provides recommended passcode settings for the S9 platform. The recommendations have been developed based on a security risk assessment of the S9 platform, and takes precedence over the non-platform specific advice in the ISM.

Evaluation status

ASD has performed an ASD Cryptographic Evaluation (ACE) of Australian Samsung Galaxy S9 SM-G960F and S9+ SM-G965F mobile devices running Samsung Knox 3.1 and Android 8.0 (the ‘S9 platform’). When configured appropriately, the S9 platform is suitable for downgrading the handling requirements for PROTECTED and OFFICIAL: Sensitive data at rest and data in transit information to that of OFFICIAL.

This guide is based on the findings of ASD and provides policy advice that must be enforced for OFFICIAL: Sensitive and PROTECTED deployments of the evaluated device. Guidance in this document will also assist organisations to comply with existing policies when deploying S9 platform devices at lower classifications.

Under the Common Criteria, the handsets have undergone evaluation against the Protection Profile for Mobile Device Fundamentals (MDFPP) version 3.1. More information may be obtained from the Common Criteria portal at https://www.commoncriteriaportal.org/.

A core requirement for an evaluated product is ongoing vendor support. Once the S9 platform is considered end-of-life by Samsung, and is no longer receiving updates, it is no longer considered to be evaluated. Deployments of the platform should be migrated to supported and evaluated platforms.

https://www.commoncriteriaportal.org/

7

General advice When newer versions of Android are released, ASD will assess their security implications and provide additional guidance if required. In the absence of additional guidance, ASD advises:

Upgrade to the latest version of Android as new versions provide security enhancements and address known vulnerabilities. This is consistent with ASD’s advice to install the latest versions of software and patch operating system vulnerabilities as communicated in the ISM and the Strategies to Mitigate Targeted Cyber Intrusions .

Implement the most current version of this guide. The existing guide applies to new versions of the S9 platform. Updated guidance will contain additions in response to new features, rather than wholesale changes to existing advice.

Samsung and Google provide explanatory notes regarding the content of Android security updates. This information may help organisations quantify the risk posed if they do not update.

Introduction to mobile device security

In this guide, mobile device security advice is centred on the three security tenets of data at rest, data in transit and device integrity.

ASD evaluates device cryptographic implementations, to determine the device configuration necessary to reduce handling requirements of devices used for the processing or storing of Australian government data. It is each organisation’s responsibility to configure the device according to ASD advice, and assess that the applications implemented by an organisation utilise the available cryptographic protections appropriately.

Configuration advice regarding device integrity, aims to provide a level of protection suitable for an Australian government mobile device, assuming an adversary has physical access to the device whilst it is powered on and in a locked state. Configuration advice and device evaluation draws upon a key hierarchy and architecture evaluation, cryptographic implementation assessment, operating system architecture and configuration assessment under typical deployment scenarios. It is the organisation’s responsibility to configure the device according to this advice in order to achieve the desired integrity outcomes.

Configuration advice regarding the protection of data at rest, aims to provide a level of protection suitable for Australian government data stored on an S9 platform device. This advice assumes an adversary has physical access to the device whilst it is powered on and in a locked state. Configuration advice and device evaluation draws upon a cryptographic evaluation, configuration assessment and details of application implementation including availability of security features.

Configuration advice regarding the protection of data in transit, aims to provide a suitable level of protection for the Australian government data traversing a network whilst assuming an adversary is able to intercept traffic. Configuration advice and device evaluation draws upon the S9 platform device’s Virtual Private Network (VPN) cryptographic evaluation, VPN implementation assessment and device configuration assessment.

It is each organisation’s responsibility to configure the device according to ASD advice and support/maintain appropriate VPN infrastructure to support the device’s VPN tunnel. Such infrastructure is out of scope of this guide.

8

Samsung Knox container

In order to strengthen the security of the native Android operating system, Samsung make available Knox containers in a number of formats and configurations.

A Knox container provides security for information held in memory and applications that run inside the Knox container. A Knox container can be considered a secure ‘region’ of the device with its own file system, and where applications that run inside the Knox container have a level of separation from the rest of the device. An application that is run inside the Knox container is a separate instance to one outside of the Knox container. There are also strong security separations between application memory internal to and external to the Knox container. The Knox container file system has an additional directory called ‘Chamber’, which marks all files within the directory to be encrypted with the Knox Sensitive Data Protection, offering stronger security when compared to the default Samsung Protected Data encryption.

Samsung encryption

The S9 platform supports Samsung’s On-Device Encryption and Knox Sensitive Data Protection (SDP), which provide hardware backed encryption and validation of data-at-rest. The S9 Platform provides two levels of protection; ‘Samsung Protected Data’ and ‘Knox Sensitive Data’, which should not be confused with ‘AGSCS PROTECTED’ or ‘AGSCS OFFICIAL: Sensitive’ in the Australian Government Security Classification System (AGSCS):

Samsung Protected Data: Is the default level of protection for every file on the device. Keys are not evicted from memory at Knox container lock; they stay in memory until the device is powered off.

Knox Sensitive Data: Applications must specifically mark files as Knox Sensitive Data, or specifically place the files in the Chamber directory responsible for marking all of its contents as Knox Sensitive Data. Keys are evicted from memory at Knox container lock, and data is only accessible when the Knox container is unlocked.

Further details regarding the Knox container and Chamber are below in the Samsung Knox container section. Vendor information about Knox Sensitive Data Protection can be found at https://docs.samsungknox.com/whitepapers/knox-platform/sensitive-data-protection.htm.

On S9 platform devices configured according to this guide, AGSCS PROTECTED information must be stored as ‘Knox Sensitive Data’. This is in order to provide sufficient protection of the data to downgrade the handling requirements of the device.

This means that only applications that specifically opt-in to Knox Sensitive Data-level encryption are permitted to carry AGSCS PROTECTED information. When selecting applications to run in the Knox container and carry AGSCS PROTECTED; the organisation must have assurance that all AGSCS PROTECTED information written to storage by the application is encrypted with Knox Sensitive Data-level encryption. The Samsung Email Client is an example of an application that supports SDP.

Samsung Knox Platform for Enterprise Premium Key

In order to access Samsung’s Knox API’s to make security configurations on device, such as deploying Knox containers, organisations will be required to purchase a Knox Platform for Enterprise (KPE) Premium Key from a Knox reseller. Once obtained, the KPE Premium Key must be passed and declared in the MDM solution, to enable Knox functionality across the S9 platform deployment. More information about Knox License Keys can be found at https://docs.samsungknox.com/Knox-Premium-Getting-Started/Content/premium-intro.htm.

https://docs.samsungknox.com/whitepapers/knox-platform/sensitive-data-protection.htm

https://docs.samsungknox.com/whitepapers/knox-platform/sensitive-data-protection.htm

https://docs.samsungknox.com/Knox-Premium-Getting-Started/Content/premium-intro.htm

9

Advice to authorising officers The ACSC has developed the Strategies to Mitigate Cyber Security Incidents to help organisations and their authorising officers mitigate cyber security incidents caused by various cyber threats. The most effective set of these mitigation strategies is known as the Essential Eight. While the strategies were developed for workstations and servers, much of the functionality described exists on modern smartphones. Consequently, the risks are just as important to consider on mobile devices. In order to assist authorising officers with understanding security implications, the S9 platform, when configured as advised by this guide, has been assessed against the three maturity levels defined for each mitigation strategy:

Maturity Level One denotes that the security control is partly aligned with the intent of the mitigation strategy.

Maturity Level Two denotes that the security control is mostly aligned with the intent of the mitigation strategy.

Maturity Level Three denotes that the security control is fully aligned with the intent of the mitigation strategy.

Maturity Level Three is the recommended standard that an organisation should aim for. The Essential Eight Maturity Model can be found at https://www.cyber.gov.au/publications/essential-eight-maturity-model.

S9 platform and the Essential Eight

Application whitelisting

Finding: Does not yet meet Maturity Level One - Not aligned with the intent of the mitigation strategy.

When configured in accordance with this guidance, the S9 platform only implements application whitelisting that is enforced via the software application’s package name.

The S9 platform does not offer granular configuration so that applications can be whitelisted for specific versions or via application package hashes (A unique cryptographic fingerprint for that particular version of software).

Consequently, it is not advisable to permit an S9 platform device that has access to AGSCS PROTECTED systems or data to interact with rich application ecosystems, such as the Google Play Store or Galaxy App Store, or be configured so that applications can be installed via unknown sources. This is to ensure that only organisationally vetted and approved applications are permitted to run on these devices.

Patch applications

Finding: Maturity Level Three - Fully aligned with the intent of the mitigation strategy.

When configured in accordance with this guidance, the S9 platform generally receives patches to applications as soon as they are available.

It is recommended that user education is provided to ensure that users update applications when prompted by the device.

Configure Microsoft Office macro settings


Currently, Microsoft Office for Android cannot open documents with macros enabled. Therefore, macros are not able to be executed or run on the S9 platform.

However, new versions of Microsoft Office for Android may introduce macro functionality and will not be separated from bundled security enhancement patches. Authorising officers will need to be aware that further configuration and reassessment of their exposure to this risk may be required in the future.

https://www.cyber.gov.au/publications/essential-eight-maturity-model

10

User application hardening

Finding: Maturity Level One - Partly aligned with the intent of the mitigation strategy.

When configured in accordance with this guidance, the S9 platform does not display or run Adobe Flash content, and is configured to not allow Java to execute or to run Pop-Ups. However, these settings can be manually disabled by the user.

Restrict administrative privileges


When configured in accordance with this guidance, the S9 platform is suitably managed by a MDM solution and performs self-attestation checks to ensure the correct permissions are set and current.

Authorising officers are encouraged to ensure that the MDM solutions used in deployment fully support the security features recommended in this guide.

Patch operating systems

Finding: Maturity Level One - Partly aligned with the intent of the mitigation strategy.

The S9 platform is an Android-based platform; consequently, there are many stakeholders involved in the patching cycle for operating systems. This includes Google’s Android Open Source Project, Samsung and Australian telecommunications providers.

Users should be advised to ensure that operating system software updates are applied when prompted by the device.

Multi-factor authentication


When configured in accordance with this guidance, the user authenticates to the S9 platform locally, and mutual authentication is then performed through various Remote Server infrastructure (e.g. MDM, VPN) utilising usernames, passwords and certificates. Whilst this is not a traditional model for multi-factor authentication, the useability and security considerations are appropriately satisfied for the intent of the mitigation strategy.

Daily backups

Finding: Does not yet meet Maturity Level One - Not aligned with the intent of the mitigation strategy.

When configured in accordance with this guidance, the S9 platform does not allow for backup of data held within the suitably encrypted portion of the device, without allowing access by untrusted third party applications.

If the mobile device is only used to access corporate data hosted on remote servers such as email, the requirement to backup handset data is reduced to configurations required to rebuild the device, such as those hosted in an MDM.

For scenarios where it may be necessary to generate a backup of locally stored data, it is possible that system managers can develop their own trusted application, or vet existing solutions, in line with existing ACSC guidance to enable suitable backup procedures.

11

S9 platform feature summary and risk considerations

Knox container

AGSCS OFFICIAL: Sensitive AGSCS PROTECTED

Required Required

Risks

Refer to the Samsung encryption section for a description of Knox Sensitive Data and Samsung Protected Data and their applicability towards Australian government data.

A user or an application may store files outside of the Application Private Directory, or the Chamber directory. Files stored outside of these locations are encrypted by the Samsung Protected Data mechanism, and will not have the suitable key management or encryption required to handle Australian government data.

The Knox container is the only logical storage area that meets the requirements to handle AGSCS OFFICIAL: Sensitive or AGSCS PROTECTED data. The Knox container implements suitable encryption and key management. Users must be trained in how to store information inside the Chamber appropriately.

When utilising applications inside the Knox container, organisations should assess the Android Package capabilities against the Knox SDK to ensure that functionality is supported by the application to handle Australian government data.

In order to downgrade the handling requirements of the S9 platform device containing Australian government data, the Knox container must be locked. Set the Knox container lock to the device lock screen in order to appropriately evict keys.

Knox container passcode


Required Required

Risks

The security of the Knox container is limited by the strength of the device and Knox container passcodes. If these passcodes can be guessed or brute-forced, all AGSCS PROTECTED information stored on the device could be viewed or modified by a malicious actor, who would not necessarily require physical access to the device.

A password or passphrase must be used for both the device and Knox container unlock; personal identification number (PIN) codes, pattern/swipe codes and built-in biometric sensors should not be used.

The organisation should set and enforce policies in accordance with the ISM and the password policy requirement outlined later in this guide. This policy should be reviewed annually and updated as required.

12

Device passcode


Required Required

Risks

The security of the device is limited by the strength of the device passcode. If this passcode can be guessed or brute-forced, all AGSCS PROTECTED information stored on the device could be decrypted or manipulated by a malicious actor, who would not necessarily require physical access to the device.

A password or passphrase must be used for the device unlock; PIN codes, pattern/swipe codes and built-in biometric sensors should not be used.

The organisation should set and enforce policies in accordance with the ISM and the password policy requirement outlined later in this guide. This policy should be reviewed annually and updated as required.

Non-native applications inside the Knox container


Organisation decision Organisation decision

Risks

Applications that do not handle Australian government data appropriately or afford a suitable level of encryption are at risk of disclosing or mishandling of Australian government data.

Native applications are applications that come pre-installed on the device. Non-native applications can be third party or applications developed in-house within the organisation.

In vetting an application, organisations should conduct a rigorous assessment of that application. This should include determining whether Australian government data is appropriately handled within the Knox container, and that SDP is appropriately applied in line with ACSC guidance.

Not allowing applications other than vetted applications prevents disclosure of Australian government data stored inside the Knox container.

Applications should be assessed in detail before being allowed to run inside the Knox container and handle Australian government data.

Applications should not be installed inside the Knox container without a genuine need for access to Australian government data.

Refer to the Self-assessment of non-native applications section.

Non-native applications outside the Knox container


Organisation decision Not recommended

13

Risks

In general, Android applications may perform or contain hidden functionality that contravenes an organisation’s policy, or impacts user privacy, user experience and productivity. The Android security model does not provide sufficiently granular application controls to give a high level of confidence that an application is trusted and unmodified.

The Knox container provides security for data held inside the Knox container. However, it is possible to install vetted non-native applications outside of the Knox container with support and risk acceptance from the authorising officer.

For AGSCS PROTECTED deployments where the authorising officer has accepted use of vetted non-native applications outside of the Knox container, the application must never handle AGSCS PROTECTED data or interact with applications within the Knox container.

It is not recommended that non-native applications be installed on devices handling AGSCS PROTECTED data where the application has not been vetted.

Refer to the Self-assessment of non-native applications section.

Mobile Device Management


Required Required

Risks

Without an MDM, devices may not always comply with an organisation’s controls and misplaced devices are unable to be secured remotely.

MDM solutions are important configuration and deployment tools for Android devices, providing security features, management and logging. Devices that handle Australian government data, whether Bring Your Own Device (BYOD) or provided by the organisation, must enrol in an MDM that is configured in line with ACSC guidance and allow the MDM to be a Device Administrator.

A core function provided by an MDM should be the ability to remotely disable or wipe lost or stolen devices, and perform fleet wide compliance checks with required controls.

Refer to MDFPP guidance for detailed considerations.

Mobile Application Management


Recommended Required

(Where non-native applications are available)

Risks

Using Mobile Application Management (MAM) allows an organisation to vet and deploy applications without needing to enable riskier accesses such as unknown sources and public app store, such as Google Play. MAM also provide a platform for organisations to deploy application updates without requiring access to public app stores.

MAM servers (usually a part of a MDM solution) are important tools for deploying applications to devices.

14

Devices which will not use non-native applications do not need an MAM.

Bring Your Own Device


Organisation decision Not permitted

Risks

BYOD have a higher risk of introducing malware into an organisation’s networks, and are at risk of being infected with malicious applications or software prior to configuration for handling of Australian government data. As such, organisations should understand the risks around allowing personal devices onto an organisation’s networks, and ensure they follow ACSC guidance.

As long as a device is enrolled in an MDM and appropriately configured, devices handling AGSCS OFFICIAL: Sensitive data can be BYOD.

https://www.cyber.gov.au/publications/risk-management-of-enterprise-mobility-including-bring-your-own-device

Virtual Private Network


Required Required

Risks

Not all data travels through the VPN. ACSC has observed plain-text (unencrypted) device identifying information such as User-Agent strings outside of the VPN, even in an Always On configuration. Such information can be used by adversaries to identify device and software version information and build profiles about an organisation’s hardware, software and their user base.

All data communications for the S9 platform handling Australian government data must be through an Always On StrongSwan VPN.

The S9 platform offers two versions of VPN client – OpenVPN and StrongSwan. The StrongSwan client is enforced via the kernel and as such offers a stronger security claim for the VPN tunnel.

Unknown sources


Not recommended Not permitted

Risks

Devices that allow unknown sources have less control over the applications that are installed on the device. An organisation that allows unknown sources no longer controls where an application is installed from. This, in combination with insufficient granular application controls, drastically increases the risk profile of these devices.

https://www.cyber.gov.au/publications/risk-management-of-enterprise-mobility-including-bring-your-own-device

15

The use of an MDM and an MAM can permit the appropriate installation of in-house organisation applications without the requirement to enable unknown sources.

Allowing unknown sources is not recommended for AGSCS OFFICIAL: Sensitive deployments and not permitted for AGSCS PROTECTED.

SDP aware email applications running inside Knox container



Risks

Email headers may not be handled in accordance with its protective marking. Email clients may not apply protective markings appropriately. Email attachments may be subsequently stored by users without appropriate protection.

SDP aware email applications (such as the Samsung Mail Client) can offer appropriate protections for the encryption and handling of Australian government data up to AGSCS PROTECTED. Currently, ACSC have not seen any solutions that give a full promise of data security, and as such Mail Clients should be considered on a case by case basis.

If an email client does not provide protective markings of emails, organisations should consider configuring email servers to handle marking of emails that are not appropriately manually marked.

Organisations should consider whether to allow attachments to or from the S9 platform devices based upon the risks surrounding the storage and handling of Australian government data on the devices.

Due to performance considerations, some email clients encrypt header information with the Samsung Protected Data mechanism; as opposed to the Knox Sensitive Data marking. The header information of an email can include the Subject Line, To and From fields, Attachment Metadata and the first 150 characters of the email message.

Organisations should carefully consider the risks associated with the diminished protections afforded to the header information, and any impact this would have on Australian government data.

Authorising officers should be aware that the handling of attachments on mobile devices increases the risk profile of a deployment. This increase in risk results from a reduction in the security controls for handling the information, similar in risk to when Australian government data is printed.

Organisations must deliver a high level of user training to ensure that users understand that any attachments moved outside of the application must be stored inside the Chamber directory, as the files are not marked as Knox Sensitive Data if stored in other locations.

Non-SDP aware email application running inside Knox container



Risks

The use of non-SDP aware email applications introduce a high degree of risk for Australian government data due to the lack of appropriate encryption.

Non-SDP aware applications do not provide appropriate levels of encryption required to handle Australian government data.

16

As such it is not recommended for AGSCS OFFICIAL: Sensitive deployments and not permitted for AGSCS PROTECTED.

All email applications running outside Knox container



Risks

The use of email applications outside of the Knox container introduce a high degree of risk for Australian government data, both due to the lack of appropriate encryption, and the management of Australian government data in memory.

These lack suitable encryption and key management for attachments that may be moved outside of the application. It is not recommended to utilise email applications outside of the Knox container at AGSCS OFFICIAL: Sensitive, and is not permitted for AGSCS PROTECTED deployments.

Document preview running inside Knox container



Risks

Australian government data may be stored inappropriately after that data is opened in a document preview application.

Viewing documents opens the file outside of the parent application, for example, outside the file explorer or mail client. There are no guarantees of correct file handling and marking if these document preview applications are used to save or edit files. While open, the Knox model still protects the file in memory, however there is considerable risk associated with saving or editing Australian government data using document preview applications.

If organisations permit the use of document preview applications for Australian government data, user training should be given reduce the risk of inappropriate storage. Educating users in how to save files to Chamber where they are appropriately marked as Knox Sensitive Data would help reduce this risk.

External storage


Organisation decision Not permitted

Risks

Any data stored or accessed on external media will not be encrypted as Knox Sensitive Data, and therefore such media are not suitable for Australian government data. External media such as microSD cards should be treated the same as other external media, such as unauthorised Universal Serial Bus (USB) storage, in traditional desktop computing environments.

The use of external media such as microSD cards and storage connected by USB was not included in the scope of the ACE evaluation of the S9 platform.

17

Application whitelist


Required Required

Risks

Applications are only vetted against the whitelist at installation – the whitelist is not queried at execution time. Therefore, applications could be modified after the whitelist is checked.

Android whitelists are defined via an MDM and enforce the control of the installation of applications.

Current Android versions whitelist via package name or developer certificate, with most common MDM’s offering package name only whitelisting.

It should be noted that whitelisting via developer certificate permits all applications signed with the whitelisted developer certificate.

For most MDM solutions, Android whitelist implementations first require a blacklist explicitly configured to prevent the installation of all applications, with the allowed applications permitted via the whitelist.

Due to the lack of granularity and control surrounding Android whitelisting implementations, organisations are encouraged to disable the installation of applications via unknown sources and only permit vetted and patched applications to be installed via a MAM solution.

Daily backups



Risks

Without regular backups, Australian government data may be irrecoverable should only a local copy of the data exist and become inaccessible.

With unapproved backup solutions, Australian government data may be extracted and then stored on or transit systems which are not suitable for the sensitivity of the data.

Daily backups are recommended for all Australian government data that is held on the device.

Currently there is not an Android or Samsung implementation of automated backup from within the Knox container. A backup process would need to either be manual or enabled by a non-native application.

If the mobile device is only used to access corporate data hosted on remote servers, such as email, the requirement to backup handset data is reduced to only configurations required to rebuild the device, such as those hosted in an MDM.

Office for Android for government documents



18

Risks

Android devices do not currently run Office macros and therefore many of the risks associated with handling Office documents are not relevant at this time. As this is a feature of a third-party vendor, continual monitoring of this risk will need to be undertaken. The ability for Office for Android to expose the enterprise to macros should also be considered when implementing mail gateway architectures. Additionally, users will require training in saving files appropriately to the Chamber in order to make use of the appropriate encryption for Australian government data as provided by SDP.

The ACSC has not vetted or approved the Office for Android application suite to handle Australian government data.

19

Mobile device administration

Managing mobile device security

A MDM and MAM solutions are an integral part of implementing any smartphone solution for an organisation. Any S9 platform device that handles classified Australian government data will require an appropriate MDM and MAM solution to satisfy the security requirements outlined in this guide and the ISM. MDM and MAM solutions should be hosted by an organisation inside of their trusted network as opposed to a cloud solution being implemented (otherwise known as an On-Premise MDM solution). An organisation’s authorising officers and system managers should work together to select the best MDM and MAM solution for the organisation’s implementation, whilst giving careful consideration to the functionality of the solution and its ability to meet the requirements outlined in this guide and the ISM. Samsung publishes a list of MDM vendors that Samsung supports, and the features that each MDM is compatible with.

In order to deploy some of the Samsung security features such as Knox containers organisations will require a KPE Premium key. This key is registered via an MDM, and allows an organisation to access and implement the Samsung security features outlined in this guide. Samsung publish a list of resellers for the key on their website.

Purchasing and enrolling devices

It is important that organisations purchase S9 platform devices, and only allow BYOD that match the version of the device that has been evaluated and are purchased from within Australia.

Devices from other regions and/or different version numbers have hardware, firmware and software differences. These differences mean that the advice in this guide may not be directly applicable, and may present risks not considered in this guide.

Each MDM solution has its own way of enrolling devices, however the general theme for the Samsung Galaxy suite is for a client application to be installed manually and configured to enrol the device into the MDM and associate the device with a user. It is recommended that this enrolment process is undertaken before the devices are provided to a user, or in the case of BYOD, that enrolment is verified before the device is allowed to handle Australian government data. Devices should be enrolled into the MDM from within an organisation’s trusted network. MDM client applications will need to be permitted the ‘Device Administrator’ permission. Once enrolled, the device will undergo self-attestation and make changes in accordance with the organisation’s policies and settings pushed via the MDM, with any non-compliant devices reported via the MDM Administrator Console.

Revoking use, end of life and device disposal

An organisation may wish to consider the following to aid the development of processes and procedures when devices are at end of life and are to be disposed, or cease to be used by an individual.

Australian government data

When the device is removed or unenrolled from the MDM, the associated Knox container is automatically destroyed and the data deleted. When Australian government data has been stored on the device in accordance with the boundaries specified in the device summary for its entire life, this process satisfies the requirement for device sanitisation.

Australian government access

Credentials must be revoked from both the handset and the organisation’s VPN server. Should a user be reinstated, new credentials must be generated.

20

All remaining UNOFFICIAL data and accesses

A factory data reset is required. UNOFFICIAL data, including personal data, contacts and accesses, may be removed before a reset. Additional utilities may aid in further sanitising the data, at the user’s discretion.

Self-assessment of non-native applications

An organisation may wish to consider the following non-exhaustive list of issues to aid in a self-assessment of non-native applications:

Trusted developer: A developer with a history of producing quality and widely used applications is less likely to have malicious components in their applications that would impact the security of the data that the application handles.

Trusted source: Large application stores, such as the Google Play Store, are more likely to host unmodified applications without bloatware or malware. Where possible, applications should be sourced directly from the trusted developer.

Application signed correctly: Applications should be verified to be signed by the trusted developer to ensure that they are unmodified and do not contain extra software packages or components that may be malicious.

Review code and libraries: Application may be developed specifically for an organisation’s use or are uncommon or bespoke. Organisations should review the software libraries contained in the application to ensure that they are up to date and do not contain known vulnerabilities. Commercially available tools can be used to determine the software libraries of Android applications.

Distribute application via MDM: Applications should be deployed via a Mobile Application Manager. This is typically a component of a Mobile Device Manager. This allows system managers to ensure that the chosen version of the chosen application that has been assessed is being deployed to devices.

Review application updates and changes before pushing the updated application to MDM: While ASD advice is to update to the most recent version of an application, system managers should conduct the above checks on updated applications before deploying them to the organisation’s fleet of devices.

21

Topics to guide user behaviour

Data spill

When Australian government data has not been stored in accordance within the boundaries specified in the device summary, it is deemed a data spill. Users must report the incident to their system manager at their earliest instance. Remedial action must satisfy the ISM control for sanitisation of non-volatile flash memory.

Peripherals and other connectivity

An organisation may wish to consider the following to aid developing user policy on the use of peripherals and other connectivity features integrated into the S9 platform.

Charging

It is recommended that only the supplied charger be used by users. Users should not use public chargers and cables and reconsider the use of gifted chargers and battery power banks. Users should not be charging from other devices, for example, personal computers, televisions.

Android Debug Bridge, USB debugging and developer mode

Android devices typically allow some low-level access to a device, such as via Android Debug Bridge, USB debugging or Android’s developer mode. To reduce the attack surface presented by the S9 platform, these in-built functionality may be disabled. This may not be available in all MDMs.

Direct Memory Access

Mobile devices can be susceptible to Direct Memory Access, even with modern preventative measures. Mobile devices should not be left unlocked and unattended, or be connected to unapproved or non-Australian government owned devices.

USB storage

If a mobile device is unlocked and connected to a non-approved or malicious system then files or applications may be transferred to the device via USB. Examples of potentially malicious connections include to printers, USB flash media and computers. These may compromise the security of the data that it holds and compromise the security of future communications. USB storage functionality must also be disabled via MDM controls as outlined later in this guide.

Bluetooth

Disabling Bluetooth when not required, and by using it only when necessary reduces the attack surface.

Connecting to vehicles, Android Auto, headsets and speakers

Pairing typically allows access to messages and contacts on the device. In vehicles there may be the ability to interact with applications. Bluetooth peripherals may retain a copy of private correspondence and official contact details. This may present a risk, particularly when using rental vehicles.

22

File transfer

This is intended for the transfer of media such as videos and music, however may be misused to either exfiltrate data from the device, or introduce data to the device that may compromise the security of the data it holds and future communications.

Wi-Fi

Avoid connecting electronic devices to any open or untrusted Wi-Fi networks. Examples of such networks include airport lounge, in-flight, municipal and shopping centre networks. Regardless, use an approved VPN connection to encrypt all internet traffic. Alternatively, use per-application VPNs for all web browsing, email and instant messaging applications.

File transfer over Wi-Fi

As this feature has not been assessed, there may be security considerations and risks that have not been mitigated in this guide. It is recommended that files not be transferred over Wi-Fi.

Samsung specific Wi-Fi features

As these features have not been assessed, any Samsung or Android features that enables sharing media, data or device information should not be allowed due to the unmitigated security risks.

Personal assistants

Personal assistant applications generally carry out the user’s command by voice input. These should be disabled at the MDM. These applications may process conversation taking place around the device at any time. Should these applications be used, there is a risk that classified conversations will be transmitted, and that data stored and processed by the voice assistant servers with insufficient protection for Australian government data.

Display output or casting

S9 platform devices have various wired and wireless methods to share the display of the device to other displays. These casting and sharing methods have not been assessed, and present the opportunity for Australian government data, if stored on or accessed by the device, to be viewed or modified when sharing. As such, devices holding Australian government data should not be used for casting or sharing the display.

23

Recommended device settings The following list contains settings that you might find an in MDM. This is not an exhaustive list of settings available via an MDM solution, just those considered settings that are relevant to the security of the device and its ability to handle Australian government information appropriately.

The recommended settings listed are considered suitable for Australian government owned devices carrying data at AGSCS PROTECTED, however these settings should be thoroughly reviewed and accepted by an organisation’s authorising officers and their system managers.

Knox Workspace settings

Knox Workspace passcode

Setting Recommendation

Fingerprint Authentication Disallow

Multifactor Authentication Disable

Minimum Passcode Length 8

Maximum Number of Failed Attempts 5

Passcode Content Complex

Maximum Passcode Age 90 days

Passcode History 8

Lock Timeout (in Minutes) Immediately on Device Lock 60 second timeout from inactivity

Maximum Length of Numeric Sequences 5

Minimum Number of Characters Changed 4

Forbidden Strings Organisation decision

(Recommended list of common passwords and passcodes)

Password Visibility Disabled

Knox Workspace Samsung Browser


24

Allow Pop-Ups Disallow

Allow Cookies Allow

Allow Auto Fill Allow

Allow JavaScript Allow

Force Fraud Warning Enable

Knox Workspace VPN

Organisations should implement a Non-Workspace (device wide) VPN to ensure that all device traffic traverses the VPN, noting the exceptions identified in the Advice to authorising officers section. Organisations may decide to implement a Knox Workspace VPN in addition to the Device Wide VPN to separate organisation specific application traffic.

Knox Workspace Samsung Email


Incoming Mail

Use SSL Enable

Protocol Set which server the email client uses to receive and send emails.

Username Define the Username for the authentication credentials using lookup values.

Password Leave the Password blank to allow end-users to set their own password.

Ignore SSL Errors Disable

Outgoing Mail

Use SSL Enable

Protocol Set which server the email client uses to receive and send emails.

Username Define the Username for the authentication credentials using lookup values.

Password Leave the Password blank to allow end-users to set their own password.

25

Ignore SSL Errors Disable

Knox Workspace Exchange Active Sync


Mail Client Select the native email client to be used on the device from the drop-down menu.

Login Information

Domain Use lookup values to define the domain for authentication credentials.

User Use lookup values to define the user for authentication credentials.

Email Address Use lookup values to define the email address for authentication credentials.

Password Leave this text box blank to allow end-users to create their own password.

Path Prefix Enter your path prefix.

Identity Certificate Select an Identity Certificate from the drop-down if you require the end-user to pass a certificate to connect to the Exchange ActiveSync, otherwise select None (default).

Settings

Retrieval Size Indicate the maximum email size that is automatically delivered to your device without having to download the message.

Period Calendar Select frequency from the drop-down menu.

Accept Certificates Enable to allow certificates for email authentication.

Enable HTML Email Enable to allow HTML formatted emails.

Peak Days for Sync Schedule

Use SSL Enable

26

Default Account Assign the EAS account as the default for sending email messages.

Knox Workspace credentials

When uploading credentials, enable the option to have them stored in the device’s TIMA Keystore.

Knox Workspace application control


Prevent Installation of Blacklisted Apps Enable, Blacklist all

Only Allow installation of Whitelisted Apps Enable

Prevent Un-installation of Required Apps Enable

Knox Workspace device restrictions


Allow Camera Organisation decision

Allow Video Recording if Camera is Allowed Organisation decision

Allow USB Disable

Allow Microphone Organisation decision

Allow Audio Recording if Microphone is Allowed Organisation decision

Allow Display of Share Via List Disable

Force Secure Keypad Usage Enable

Allow Contact Info Outside the Container Disable

Allow Account Addition Disable

Allow Google Account Activation Disable

Allow Screen Capture Disable

Enable Allow Clipboard Organisation decision

Allow Mock Locations Disable

27

Allow Bluetooth Disable

Security

Enforce Container Keyguard Enable

Prevent New Admin Activation Enable

Set Common Criteria CC Mode Enable

Enable Application Move Disable

Enable File Move Disable

Enable OCSP Check Turn on to allow use of Online Certificate Status Protocol during certificate revocation for application SSL connections.

Application

Allow Google Crash Report Disable

Allow S Voice (Bixby) Disable

Allow User to Stop System Signed Applications Disable

Allow GMS Applications in Container Disable

Sync and Storage

Allow Google Accounts Auto Sync Disable

Allow Change Data Sync Policy Disable

Allow SD Card Move Disable

Hardware

Allow Settings Change Disable

Allow Reset Container on Reboot Disable

28

Non-Workspace device settings

Non-Workspace (device wide) VPN


Connection Info

Client Type Native Samsung Internet Protocol Security (IPsec) Client (com.samsung.sVpn)

Enforce Service Validation Enable

Server Suffix Designate the domain in which the authenticating server must belong.

Authentication

User Authentication Enable this text box to require user credentials for VPN access. The selected Client Type determines applicable text boxes displayed in this section.

The following text boxes displays upon selection:

Username – Enter the username users are required to enter at setup.

Password – Leave blank to allow Users to input their password.

Connection Type StrongSwan Certificates

Identity Certificate Use the drop down to select the credentials for authenticating the connection.

Root Certificate Specify the trust certificate authority.

Advanced

Enable Advanced Configurations Select the check box to display more options to configurable your VPN profile based on the selected client type.

Backup Server Name Enter the name of the server to connect to in the event the primary VPN gateway fails.

Default Route Enabled Enable to ensure that all network traffic goes through the tunnel.

29

IKE Version Internet Key Exchange (IKE) protocol version for setting up security association. Ensure to use either ‘IPsec Xauth RSA’ and ‘IPsec IKEv2 RSA’.

Dead Peer Detection Enable dead peer detection to allow the KeyVPN client to detect a dead IKE peer.

PFS Exchange To be enabled if the session key should be protected.

Suite B Use Suite B cryptography for connecting to VPN for higher security.

Phase 1 Mode Sets up a secure tunnel to authenticate and secure the IKE tunnel. If the MDM presents the option for ‘Aggressive Mode’ for IKEV1 this should be disabled.

DH Group Sets the key strength used in phase 1 during key exchange. The higher the group number, the more secure the key exchange.

Organisations should implement at minimum group 14. Organisations should refer to the ISM to ensure implementation of an ASD Approved Cryptographic Algorithm.

Split Tunnel Type Disallow

Forward Routes Enter an alternate destination for the split tunnel to be directed. This text box is only displayed if Split Tunnel Type is set to Manual.

Authentication Type Certificate-based should be selected.

Proxy

Proxy Type Select whether the proxy connects by Static Proxy or Proxy Auto Configuration.

Server Enter the Host name or IP address for the proxy server.

Port Specify the target port for the proxy server.

Username Enter user credentials.

Password Enter user credentials.

Assignment Level

30

Assignment (For consideration in Container VPN implementation)

Select the assignment level as All Container Applications or Individual Applications.

For Individual Applications, enter the application package name (app identifier) for the Applications you want to have Application level VPN. Examples include:

Container application – sec_container_1.airwatchEmailClient.xxx.

Application outside the container – com.airwatch.androidagent.

Logs and Warnings

Enable Debug Logging Include more detailed information in the diagnostics reports for troubleshooting.

Show Warnings Show message in case of connectivity problems or when server name can not be resolved.

Non-Workspace passcode


Minimum Passcode Length 8

Passcode Content Complex

Maximum Number of Failed Attempt 8

Maximum Passcode Age (days) 90 days

Passcode History 5

Device Lock Timeout (in Minutes) Immediately on Device Lock 60 second timeout from inactivity

Enable Passcode Visibility Disable

Allow Fingerprint Unlock Disallow

Require Storage Encryption Require

Require SD Card Encryption Require

31

Non-Workspace device restrictions


Allow Camera Organisation decision

Allow Microphone Organisation decision

Allow Factory Reset Disallow

Allow Screen Capture Organisation decision

Allow Mock Locations Disallow

Allow Clipboard Organisation decision

Allow USB Media Player Disallow

Allow NFC Disallow

Allow NFC State Change Disallow

Allow Email Account Addition Organisation decision

Allow Email Account Removal Organisation decision

Allow Google Account Addition Organisation decision

Allow POP / IMAP Email Organisation decision

Allow Notifications Organisation decision

Allow Audio Recording if Microphone is Allowed Organisation decision

Allow Video Recording of Camera is Allowed Organisation decision

Allow Ending Activity When Left Idle Organisation decision

Allow User to Set Background Process Limit Disallow

Allow Headphones Organisation decision

Allow All Local Services Organisation decision

Allow Fingerprint Authentication Disallow

32

Allow Deactivate Device Admin Disallow

Non-Workspace sync and storage restrictions


Allow USB Debugging Disallow

Allow USB Mass Storage Disallow

Allow Google Backup Disallow

Allow Google Account Auto Sync Disallow

Allow SD Card Access Disallow

Allow OTA Upgrade Allow

Allow SD Card Write Disallow

Allow USB Host Storage Disallow

Allow SD Card Move Disallow

Non-Workspace application restrictions


Allow Google Play Disallow

Allow YouTube Disallow

Allow Access to Device Settings Allow

Allow Developer Options Disallow

Allow Non-Market App Installation Disallow

Allow Google Crash Report Disallow

Allow Android Beam Disallow

Allow S Beam Disallow

Allow S Voice (Bixby) Disallow

33

Allow Copy & Paste Between Applications Organisation decision

Allow User to Stop System Signed Applications Disallow

Non-Workspace Bluetooth restrictions


Allow Bluetooth Organisation decision

Allow Bluetooth Pairing Organisation decision

Enable Bluetooth Device Restrictions If Bluetooth enabled - Allow

Enable Bluetooth Secure Mode Allow

Non-Workspace tethering restrictions


Allow All Tethering Disallow

Allow Wi-Fi Tethering Disallow

Allow Bluetooth Tethering Disallow

Allow USB Tethering Disallow

Non-Workspace browser restrictions


Allow Native Android Browser Allow

Allow Pop-Ups Disallow

Allow Cookies Allow

Enable Autofill for Android Allow

Enable JavaScript For Android Allow

Force fraud warning Enable

34

Device-wide location services restrictions


Allow GPS Location Services Organisation decision

Allow Wireless Network Location Services Organisation decision

Allow Passive Location Services Organisation decision

Non-Workspace security restrictions


Allow Activation Lock Allow

Allow Firmware Recovery Disallow

Allow Lock Screen Settings Organisation decision

Allow User Creation (Requires Allow Multiple Users to be enabled)

Disallow

Allow User Removal (Requires Allow Multiple Users to be enabled)

Disallow

Allow Multiple User Disallow

Allow Keyguard Allow

Allow Trusted Agent Disallow

Allow Camera on Keyguard Screen Organisation decision

Allow Fingerprint on Keyguard Screen Disallow

Allow Notifications on Keyguard Screen Organisation decision, as long as redacted only.

Allow Un-redacted Notifications on Keyguard Screen Disallow

Allow Fingerprint Unlock Disallow

Non-Workspace network restrictions

These are device-wide, apply to the both the workspace as well as the rest of the device.

35


Allow Wi-Fi Organisation decision

Allow Cellular Data Organisation decision

Allow Wi-Fi Profiles Allow

Allow Wi-Fi Changes Organisation decision

Allow Unsecure Wi-Fi Organisation decision

Allow Auto Connection Wi-Fi Organisation decision

Allow Prompt for Credentials Allow

Minimum Wi-Fi Security Level Organisation decision

Allow Only Secure VPN Connections Allow

Block Wi-Fi Networks by SSID Organisation decision

Allow Native VPN Allow

Allow Wi-Fi Direct Disallow

Set Global HTTP Proxy Organisation decision

36

Glossary of cyber security terms

Term Meaning

application whitelisting An approach in which only an explicitly defined set of applications are permitted to execute on system.

ASD Cryptographic Evaluation The rigorous investigation, analysis, verification and validation of cryptographic software and equipment by ASD against a stringent security standard.

authorising officer An executive with the authority to formally accept the security risks associated with the operation of a system and to authorise it to operate.

blacklist A list of things that are considered to be unacceptable and should not be trusted. A blacklist is the opposite of a whitelist.

classification The categorisation of information or systems according to the business impact level associated with that information or system.

Common Criteria An international standard for software and ICT equipment evaluations.

cryptographic software Software designed to perform cryptographic functions.

cyber security Measures used to protect systems and information processed, stored or communicated on such systems from compromise of confidentiality, integrity and availability.

cyber security incident An occurrence or activity that may threaten the confidentiality, integrity or availability of systems or information.

data at rest Information that resides on media or a system.

data in transit Information that is being communicated across a communication medium.

ICT equipment Any device that can process, store or communicate electronic information.

integrity The assurance that information has been created, amended or deleted only by authorised individuals.

37

Internet Protocol Security A suite of protocols for secure communications through authentication or encryption of Internet Protocol packets as well as including protocols for cryptographic key establishment.

key management The use and management of cryptographic keys and associated hardware and software. It includes their generation, registration, distribution, installation, usage, protection, storage, access, recovery and destruction.

media A generic term for hardware, often portable in nature, which is used to store information.

mobile device A portable computing or communications device. For example, a laptop, mobile phone or tablet.

passphrase A sequence of words used for authentication.

password A sequence of characters used for authentication.

patch A piece of software designed to remedy security vulnerabilities, or improve the usability or performance of software and ICT equipment.

product A generic term used to describe software or hardware.

protective marking An administrative label assigned to information that not only shows the value of the information but also defines the level of protection to be provided.

Protection Profile A document that stipulates the security functionality that must be included in Common Criteria evaluation to meet a range of defined threats. Protection Profiles also define the activities to be taken to assess the security function of an evaluated product.

security risk Any event that could result in the compromise, loss of integrity or unavailability of information or resources, or deliberate harm to people measured in terms of its likelihood and consequences.

server A computer that provides services to users or other systems. For example, a file server, email server or database server.

system A related set of hardware and software used for the processing, storage or communication of information and the governance framework in which it operates.

38

system manager An individual that the system owner has delegated the day-to-day management and operation of a system.

system owner The executive responsible for a system.

user An individual that is authorised to access a system.

Virtual Private Network A private data network that maintains privacy through a tunnelling protocol and security procedures. VPNs may use encryption to protect traffic.

workstation A stand-alone or networked single-user computer.

39

Further information The Australian Government Information Security Manual (ISM) assists in the protection of information that is processed, stored or communicated by organisations’ systems. It can be found at https://www.cyber.gov.au/ism.

The Strategies to Mitigate Cyber Security Incidents complements the advice in the ISM. The complete list of strategies can be found at https://www.cyber.gov.au/publications/strategies-to-mitigate-cyber-security-incidents.

https://www.cyber.gov.au/ism

https://www.cyber.gov.au/publications/strategies-to-mitigate-cyber-security-incidents

40

Contact details Organisations or individuals with questions regarding this advice can email [email protected] or call 1300 CYBER1 (1300 292 371).

mailto:[email protected]

Documents

Security Configuration Guide Samsung Galaxy S9 and S9+ Devices · implementing Samsung Galaxy S9 devices in their fleet. The guide also contains instructions and techniques to configure