Skip to main content


How 2020 Presidential Candidates Can Guard Against Cyberattacks

The 2016 presidential election witnessed unprecedented Russian cyberattacks and disinformation campaigns designed to disrupt the U.S. electoral system by influencing public opinion. The Russian goal is intended to destabilize the U.S.  through ideological activism, advancing their interest and further their political agenda. Their methods compromised computer systems of candidates and political parties using the exfiltrated data to spread disinformation and influence presidential elections.

On January 6, 2017, the U.S. Director of National Intelligence released a declassified report “Assessing Russian Activities and Intentions in Recent U.S. Elections.” According to the report, Vladimir Putin ordered a massive campaign orchestrating attacks from multiple fronts that involved spreading pro-Trump propaganda on social media to hacking the Democratic National Committee (DNC). Their methods resulted in massive data breaches within the DNC that included access to John Podesta's email f…

Mobile Security Fundamentals

The explosive use of a smartphone, laptop computers, USB memory (thumb drives) is convenient and easy to use. They also introduce risk to personal privacy and to corporate data. Much demand is also seen with BYOD (Bring Your Own Device) into the corporate environments which expose companies to a multitude of risks. This article will outline basic security fundamentals and best practices regarding the use of these mobile devices in the corporate computing environment.

Risks of Mobile Computing

Smartphones and tablets are personal computers run on a general-purpose operating system (OS), and as such their basic threat model overlaps considerably with that of conventional desktops, laptops, and servers. Yet they differ in three respects, each of which changes the threat model as I will describe:
  1. All mobile devices are portable - The risk of them being lost or stolen is substantial, and it also increases the risk of adversaries gaining physical access. For example, when they are left unattended in a hotel room, gone in an automobile unattended, held for inspection by customs at the national border or held as ransom. The risk that sensitive information like passwords can be observed when they are used in a public area.
  2. All smartphones and many tablets can connect to the Internet over cellular networks - Even if they never leave the organization’s premises, they have a path to the Internet that cannot be observed or filtered by the enterprise’s network defenses, such as firewalls, proxies, and intrusion detection or prevention systems. Companies cannot rely on perimeter defenses alone to prevent or detect the compromise of mobile devices with cellular data connectivity.
  3. Mobile devices are generally equipped with many more physical sensors such as:
  • Cameras
  • Microphones
  • GPS receivers
  • Accelerometers
  • Bluetooth
These devices can collect information from the physical world, malicious software on a mobile device can compromise security even without ever connecting to the enterprise network. They can record video and audio during sensitive discussions and track the user’s location in real time. A compromised mobile device could be used by an adversary to collect valuable information in less obvious ways as well. For example, it is feasible to derive a keystroke log from an audio recording of a user typing on a nearby keyboard, many have Bluetooth capabilities where peripheral connectivity by other devices nearby can be executed. Bluetooth devices often have a pin to connect to a mobile device and use “0000” as the default. A few manufacturers allow to pin changes, yet others do not, and the general public users often are not aware of the eavesdropping capabilities of Bluetooth devices.

The Mobile Security Risks

  • Malicious software or hardware may be introduced by an adversary with brief physical access to the device. This is referred to as the “evil maid” attack since hotel housekeeping staff will have physical access to any devices left unattended in a hotel room. Just make sure that equipment is fully encrypted and shut down, utilize hotel safes for laptops and tablets or take the device with you at all times such as the smartphones.
  • Sensitive data could be recovered from a lost or stolen device. This includes data stored on the device, and also network data that can be accessed using credentials stored on the device. If the device is powered on when the adversary acquires it, information could be recovered from RAM in addition to permanent storage.
  • A remote attacker could exploit a software vulnerability to gain access to the device. Additional vulnerabilities could be used to execute code in the kernel, bypassing the OS’s security policies.
  • Unprivileged malicious applications, spyware or Trojan horses could collect sensitive information and send it to adversaries without exploiting any vulnerabilities in the OS.
  • Often times these devices are connected to an insecure network such as at any WiFi hotspot are considered vulnerable. The device’s communications could be passively collected, or actively intercepted and modified by a man-in-the-middle. This can lead to the compromise of sensitive data either directly, or indirectly by making it possible to install malicious software.
  • Sensitive information could be leaked inadvertently through the use of applications that are not malicious but were not designed with security in mind. For example, “social” or advertising software that makes use of a user’s location, contact list, or web history.

Protecting and Managing Mobile Devices

Mobil Device Management (MDM)

A security best practice within corporate environments to manage mobile devices is the deployment of a Mobile Device Management (MDM) system. These systems are used within the organizational context to administer the instruments and some of the typical functionality include:
  • Over the air distribution of applications
  • Data and configuration settings (all devices)
  • Bring Your Own Device (BYOD) support
The architecture and deployment of such a system without getting into technicalities are described in the above diagram. A well-configured MDM solution can mitigate some, but not all, of these risks as I will explain its complexity to keep in mind.

MDM systems typically involve an agent on the mobile devices, a server component used by administrative personnel within the enterprise enclave, and an intermediary service operated by the platform vendor. The on-device agent may be a hidden part of the mobile OS itself, or it may take the form of a 3rd party app distributed through online app repositories which are permitted to conduct its management activities. The platform vendor’s intermediary typically maintains a continuous connection to the devices to facilitate on-demand queries and commands from the enterprise. If the system includes additional major architectural components beyond those described above, for example, other servers within the enterprise’s enclave or additional intermediary servers.
Now as I have been involved in several architectural design discussions some of the critical questions one must ask to consider are:
  • What happens if a crucial component namely the device client is compromised by an attacker?
  • Devices are known to go offline what happens in that event?
  • Who has accountability for security and reliability of the 3 party or the company?
  • How many servers need to be deployed on the network, access to internal systems such as unstructured and unstructured data systems such as email and corporate directories?
  • What connections from the internet need to be opened up from the perimeter firewalls?
From a network developmental perspective, the MDM servers should be deployed in a network’s “Demilitarized Zone” (DMZ), with firewalls ensuring that they have the least privileged access to both the Internet and the organization’s intranet. The trust relationships between the various components should also be well-understood before making a decision to deploy. Fundamental questions to include in these discussions are:
  • Sensitive information must be encrypted at rest and in transit.
  • Which components of the product have access to which cryptographic keys?
  • Of importance, how are those keys to the kingdom managed?
  • Can it expose the cryptographic keys in the event of a misconfiguration?
  • Do they use strong, mutual cryptographic authentication, or can messages be easily spoofed?
  • Does it support bio-metrics such as fingerprint scanners and how, where are these credentials stored?
  • If a valid client is compromised, what degree of access to the server can the adversary gain by exploiting command protocols?

Most MDM systems have the following functionality:

1. Data-at-Rest Protection - Mobile device platforms offer a passcode lock feature, which is used to prevent unauthorized access to the device and also to generate a key to encrypt data stored on it, guarding against improper disclosure of confidential information if the device is lost or stolen.
Fundamental questions to consider the data-at-rest protection are:
  • Is the entire device encrypted, or only specific partitions?
  • Are files and per-application storage areas encrypted individually?
  • How are encryption keys derived from the user’s passcode? How high would an offline brute force attack be and has been tested in a laboratory setting?
  • Is there a recovery or critical escrow mechanism? Can it be disabled?
  • Are encryption keys cleared from RAM when no longer needed?
2. Application Policies - MDM systems allow administrators to create policies that govern which apps are installed on the managed devices. Depending on the features of the MDM system and the underlying OS, a variety of procedures can be supported. Decision makers evaluating an MDM should understand the app installation policies. The product supports and how they align with the organization’s mobile security goals. The key questions are:
  • Does it allow for white and blacklists for the installation of applications?
  • Can it also mandate that specifically required apps be installed on all managed devices?
  • Does the policy identify apps by name only, or can it also permit or deny apps by other attributes like their version, developer ID or certificate, or use of security sensitive OS services?
3. Remote Wipe - MDM systems also provide the ability for administrators to remotely erase a device. This is another countermeasure against the risk of sensitive data being improperly disclosed, but its effectiveness depends on the device being accessible via the network after it is lost. The time the method is known to have been lost to the time the user reports it is crucial as an adversary can compromise the device in short order by disabling the remote wipe feature. Similar to this recently introduced to the general public with new Android, iPhone and Windows mobile devices are the so-called kill switch that locks out and wipes the device rendering it useless. Critical questions regarding remote wipe features include:
  • How thorough is the wipe and how long does it take to complete?
  • Is all data on the device erased, or only data associated with specific applications?
  • Is the erased data overwritten with zeros, cryptographically made unavailable by deleting a decryption key, or just unlinked from the file system?
  • Can the device be configured to automatically wipe the device under certain conditions such as prolonged inactivity? Unusual activity?
  • How does the wipe feature operate with BYOD?
4. Enterprise App Deployment - Although app deployment isn’t necessarily related to MDM, some MDM systems can facilitate the implementation of in-house or specially approved apps over enterprise distribution channels. The Decision makers considering the use of these enterprise app distribution facilities should understand the infrastructure involved in setting up app distribution and its impact on their network attack surface. Key questions are:
  • Is app deployment handled by a separate server on the enterprise network, which must be maintained and secured?
  • Does this server need to accept requests directly from the Internet, or can the managed devices connect to it over a Virtual Private Network (VPN)?
  • How much control administrators have over the cryptographic signing of apps deployed through the system?
5. Version Reporting - A necessary feature offered by many MDMs is a capability to report which versions of the OS and applications are installed on each managed device. Most products should allow administrators to manually query version information; automation and integration can make this feature more effective. Key questions include:
  • Can the product automatically send alerts to administrators or end-users when a device has fallen behind on security patches?
  • Can it automatically revoke a device’s credentials, or even initiate a wipe, if a device has been left in an unmanaged or unattended state for an extended period of time?
  • Does the product offer a scripting interface so that enterprise administrators can create automated reports, alerts, and actions that are customized to the organization’s needs?
6. Detection of User-initiated Platform Modification - MDM products can perform limited inspections of the underlying mobile OS to detect the artifacts of user‑installed “jailbreak” or “root” tools. Since MDM agents typically run with limited privileges, they stand little chance of identifying sophisticated malicious software, but they can sometimes detect user misbehavior that significantly weakens the mobile device’s security posture. This an important issue many security professionals are not advocates of BYOD and rightfully so. Security professionals must stress the importance of a control mobile device security infrastructure where devices are issued and controlled by the organization. If this is not possible and in some cases, the acceptance of that risk will be accountable to the department requesting BYOD, then other mediation considerations should apply. Examples are, complete network segregation of these devices where they will not have access to sensitive internal systems and data.

VPN - Mobile OS does have built-in support for connecting to VPN’s. An MDM product can facilitate the deployment of consistent VPN configuration to all managed devices. Decision-makers should understand the capabilities of their mobile OS, and whether a given MDM product is an excellent complement to them. Key questions include:
  • Can the VPN be configured to connect automatically, or must the user manually initiate the connection?
  • Once the device is connected to the VPN, does all traffic pass through the encrypted tunnel, or is some traffic still transmitted in clear text?
  • Can the platform prevent the user from disabling the VPN?
  • Does the MDM have features to ease the management of those certificates?
  • Can it automatically revoke a user’s certificate if a security violation is detected, for example, a device is reported as stolen, falling too far behind on critical security patches, or having unapproved apps installed?
7. WiFi and Cellular Network Restrictions - In addition to using a VPN, preventing a device from connecting to insecure networks is another means of protecting sensitive network communications. Some mobile OS may allow MDM policy to restrict which WiFi networks, or which Access Point Names for cellular networks, a device can connect to. For enterprise‑controlled devices, the ability to specify a whitelist for WiFi networks remains highly desirable, despite potential incompatibility with the BYOD scenario.

8. Certificate Trust Management - The security of mobile devices depends in no small extent on PKI certificates, which can be used to authenticate VPN’s, websites, applications, and even MDM policy itself. The OS maintains a list of trusted certificate authorities; any certificate issued by one of those CAs is accepted by the OS as legitimate. An attacker who acquires a fraudulent document signed by a trusted CA, or who causes the OS to trust a fraudulent CA, can intercept, decrypt, and modify all of the device’s communications, and possibly install malicious software.

9. Policy for Connection to PCs - Most mobile devices can be connected to a personal computer for data transfer, debugging, and software installation or update. A method is connected to a malicious or compromised PC can, therefore, lead to the compromise of the data stored on the device, or the device itself. MDM policy should be able to limit the attack surface a device exposes to connect PCs, For instance, disabling debugging or requiring that a passcode is entered for access or limit which PCs can relate to the invention. Ideally, administrators would also be able to query a log of which PCs a device has been connected to.

In organizations that are contemplating mobile devices, their security is critical as their portability, and the loss of physical control elevate risk considerably. It is one the most significant breach vectors for sensitive data and because of this advanced management systems must be deployed within a corporate infrastructure. Having an MDM system is a best practice that can ensure that the built-in security features of an organization’s devices are always enabled and configured to meet the security needs.

Organizations should also understand that MDM doesn't add new security features to a platform. It serves as one cog to an efficient layered security platform in a way to automate the configuration of the security features already provided by the platform. Do understand that inherent residual risks that MDM alone cannot mitigate. The capability gaps for some high-security scenarios that MDM software cannot yet satisfy.