Analysis of safety setting and control measures for safety of enterprise

The number of devices running the Android system worldwide now exceeds the number of devices running iOS systems, at 2.4:1, according to the market intelligence firm ABI study. As a result, many employers are forced to allow the use of devices running a consumer-level mobile operating system to do business. Fortunately, the 4.0 version of the Android system supports local defenses. Here, we consider existing methods to centrally maintain and implement security policies on Android devices.

Unveil the security of the Android system

The Android system employs many of the defensive measures that people expect from modern mobile operating systems, including sandbox technology (sandboxing), Code-signing Technology (signing), OS-level enforced privilege management as well as (new in Android 4.0 system) addressing space layout randomization (address spaces layout randomization, ASLR) technology. New password features in the Android 2.2 release. The Android 3.0 version adds hardware encryption, but is limited to Tablet PCs. The Android 4.0 version also adds hardware encryption to smartphones.

To prevent data leaks due to loss of equipment or theft, businesses can enforce passwords and encryption policies, prevent business from passing through non-compliant devices, and remotely erase data on any missing devices. These requirements can be addressed through an Android Device Management API, this technique can be used to query and set the number of security settings for an Android system, including password control measures such as minimum length, alphanumeric blending requirements, special symbol requirements, password expiration, password history, maximum failed password attempts, and so on.

Most of these controls were introduced in the Android 3.0 version, and the camera function was added to the Android 4.0 version. As a result, IT managers may only be allowed to run an Android 3.0 or later version of the device. However, IT managers must also check the exact model and module of the device. Because it's older. The data cannot be encrypted even after it has been upgraded to version 4.0.

In addition, the Android API provides the ability to lock devices, prompt for password modifications, or reset devices to factory defaults (erasing internal storage but excluding any removable media that stores music, photos, and e-mail). The ability to reset a device to a factory default device does not pose any risk to devices that do not have a removable media, which can also be used as one of the specifications for business use.

Implement it control for Android system equipment

There are three methods available for it control of Android devices:

Users are able to directly set up security policies for some Android systems-most notably enabling encryption, which takes an hour to process. IT managers can recommend security settings, but this approach does not provide the enforcement of IT management.

EAS (Exchange activity Sync, Exchange Active Sync) properties can be used to verify and set policies when the enterprise mailbox synchronizes. The Android 4.0 version upgrades the EAS to V14 version, which expands the scope of the strategy. However, the diversity of equipment hinders the EAS control, and the results are different because of the model/module. In common cases, EAS can require a PIN or password to be set, a minimum password to be enforced, a set number of failures and timeout parameters, and revert to factory default settings.

The ability to enforce every strategy in the Android Device Management API through mobile device Management (MDM) agents, or other security programs installed on smartphones or tablets. Typically, users download MDM proxies from Google's Android Market, follow prompts to grant permissions and visit their company's MDM registration portal. Since then, IT managers have been able to use MDM to authenticate users, publish device certificates, provide equipment, and enforce organizational policies.

To fight malware on the Android system.

Many MDM products offer more it controls to complement the original Android system controls, such as detecting and isolating Android devices that are embedded in malware, querying blacklisted applications, and helping IT managers remotely install required or recommended applications. These can help detect malware on Android and improve the security of the enterprise's Android system.

Over the past year, malware has proliferated on Android, with malware writers leveraging Google's open Android Market and Android's "Gateway" to apps from third-party sites. Therefore, for IT managers, the first line of defense against malware is to gain insight into the installed applications on any device that is used for the business. For example, MDM can be used to block devices that run malware from accessing the enterprise or erasing data on it.

IT managers can also install Third-party security tools on Android devices, including antivirus scanners, SMS anti-spam filters, Phishing URL Checker, high-risk application scanners, and remote lock/Find/erase tools. It is common for these security programs to support several functions, but most are designed for consumer use-only a few are tailored to the needs of it control.

Create your own sandbox

Given the different capabilities of the device and the risk of Android malware, IT managers can choose to create a secure (encrypted and authenticated) business environment. For example, a secure enterprise communications application is installed in a self-encrypted container to store messages, contacts, schedules, and tasks. Control settings are usually done through EAS or MDM.

Finally, there is no shortage of methods and tools that can help meet the security expectations of the enterprise's Android devices. Although these controls may not fully meet the strategy of each organization, the Android 4.0 version system and MDM technology and other security products are narrowing the gap.

This column more highlights: http://www.bianceng.cnhttp://www.bianceng.cn/Network/Firewall/