by clicking on the page. A slider will appear, allowing you to adjust your zoom level. Return to the original size by clicking on the page again.
the page around when zoomed in by dragging it.
the zoom using the slider on the top right.
by clicking on the zoomed-in page.
by entering text in the search field and click on "In This Issue" or "All Issues" to search the current issue or the archive of back issues respectively.
by clicking on thumbnails to select pages, and then press the print button.
this publication and page.
displays a table of sections with thumbnails and descriptions.
displays thumbnails of every page in the issue. Click on a page to jump.
allows you to browse through every available issue.
FCW : October 2016
E NSURING MOBILE SECURITY is a multi-step process. Besides developing the right policies, it requires choosing mobile devices w ith rigid secu- rity features and the ability to configure them for specific use cases and to suppor t security policies. Effective, automated device configuration tools are the best way to limit access to cer tain applications or par ts of the device for specific situations, roles and responsibilities, and locations. Mobile Device Management (MDM) systems are critical, as are highly configurable, easy to use auto-enroll- ment tools to ensure a common operating baseline, reduce administrative overhead, and eliminate the human compo- nent of device configuration. “Dev ice configuration isn’t something anybody should take for granted,” says Craig Ano, Senior Manager for Federal at Samsung. “ The best way to ensure that dev ices are set up quickly and correctly is by eliminating the human element—in other words, by using auto-enrollment or customization tools for dev ices whenever possible.” At its most basic level, an MDM solution should anchor the device management process. This is then layered on top of any type of mobile device. MDM/EMM is there to provide flexible policies and ongoing management of the devices. All policies are not the same, though, and each organiza- tion should look at what data they are trying to protect and assign policies appropriately. For example, an inspector w ill have different data than a warehouse worker or an agency executive. Policies that agencies can customize and config- ure for each data protection use case are essential. The goal is to put enough security to protect the data without overly burdening the dev ices w ith security controls. MDM systems can also prevent mobile dev ices from installing unapproved applications, track devices, enforce application whitelists and blacklists, prov ide geo-fencing, enforce data sharing restrictions and remotely wipe dev ices if they have been lost or compromised. To prov ide even more granular protection, some agencies use containers. These are a software-based system that separates sensitive data and applications from personal data and applications, even when they’re stored on the same dev ice. They prevent sensitive data from leaking out, as well as malicious data and applications from entering. While this is cer tainly useful and effective on government- issued dev ices, it’s especially important for agencies that let employees use their ow n dev ices. For the most stringent containerization, consider dev ices where the container technology is built on top of the hard- ware security instead of the application or operating system layer. When containers are built on top of hardware security, the information inside is better protected against malware. The exact restrictions imposed on any device depend on the specific agency and user security requirements. For the majority of government users—those using mobile dev ices to improve productivity—the most important dev ice configuration capabilities most likely revolve around data encr yption (at rest and in transit), authentication, dev ice feature restrictions, and wireless network controls. Whether dev ices can connect to public WiFi networks or are restricted to approved WiFi networks; and whether Bluetooth is acceptable or should be blocked, are examples of commonly enforced security policies. These configuration factors along with containerization are the most common use cases for most government mobile users. For more secure env ironments or those dealing with classified data, there are many more possibilities. For example, for users who regularly enter classified areas, agencies can configure dev ices to immediately put the phone into secure mode where it can’t transmit or receive data, gather or disseminate data, and the camera is inoperable. There are many other secure use ca ses and situations as well. That’s where enrollment tools to automate device configuration become more critical. A n agency supporting 10,000 users, for example, probably has many categories of employees w ith different security clearances. Each will have different configuration needs. There are use ca ses where a dev ice may not need to be connected to an MDM system, but still benefits from automated enrollment and customization to ensure security. The device of a field inspector, for example, w ill have a different configuration from a first responder. “It’s important to make sure your deploy ment and config- uration tools match the problems you’re trying to solve, and your user base,” says Ano. “ The more granular the control you can get with device configuration, the more ef fective it w ill be.” USER-DRIVEN DEVICE CONFIGURATION Automating mobile device configuration can ensure the right policies are enforced. SPONSORED REPORT Download the Full Report at fcw.com/SamsungSecurityMandate
September 30, 2016
November and December 2016