Summary and Call to Action

Abstract

We all have choices about how we implement and use technology, making our own personal cost/benefit calculation about our appetite for risk versus convenience and prioritizing actions (or inactions) accordingly. Hacks are continually evolving, forcing updates to mitigation approaches that combat the hacks. The number of WAPs and mobile devices are increasing (with some devices acting as both access points and mobile devices) as the IoT, self-driving cars and self-flying drones become a reality. New hacks will be created for these new environments. Because of this, mobile device risk management is an ongoing journey, not a destination. Money is not a reasonable excuse for not having a security plan for your devices. Start by thinking like a hacker with the objective of countering classic attack methodology steps—reconnaissance, scanning, access and escalation, exfiltration, obfuscation. The consequences of failing to act, or failing to think while acting, are too disturbing.

Keywords

Risk management; attack methodology; reconnaissance; scanning; access and escalation; shadow IT; exfiltration; obfuscation; VPN; white list; black list; air gap

People go through life performing a series of actions (e.g., visiting Grandma) and inactions1 (e.g., staying home). The benefits and rewards of chosen actions are typically well understood (e.g., enjoying time with Grandma). The risks associated with chosen actions are typically less well understood (e.g., encountering a wolf in the woods on the way to Grandma’s house). This is because there are levels of risk (e.g., encountering wolf, getting eaten by wolf) with associated probabilities (e.g., 100% of meeting wolf in forest in fairy tales). If a risk is encountered, a person may perform a contingency action (e.g., drop basket of food for wolf to eat while running away) to escape serious harm. Security consultants call these contingency actions risk mitigation, and the overall process of determining the risks and rewards of certain activities, risk management. People subconsciously perform risk management continually, as it proves beneficial for the survival of the human race.

The goal of this book is to help you, the reader, understand the risks and possible mitigations associated with using mobile devices in your personal and business environments. Hacks are continually evolving, forcing updates to mitigation approaches that combat the hacks. The number of WAPs and mobile devices are increasing (with some devices acting as both access points and mobile devices) as the IoT, self-driving cars, and self-flying drones become a reality. New hacks will be created for these new environments. Because of this, mobile device risk management is an ongoing journey, not a destination.

Taking a pessimist approach and assuming that the good guys can never win so why try and invest in security assures that the bad guys will win. Assuming that with a sufficient budget you will be completely secure (the Big Budget Theory) is overly optimistic; the bad guys will occasionally win as data breaches or network compromises at Target, Sony, Chase Bank, the Federal Office of Personnel Management (OPM), and the Ukrainian Government indicate. Thus one needs to secure personal and business mobile devices as well as possible given time and budget constraints. Since security is a journey and not a destination, one’s goal is to be more secure tomorrow than today, and more secure today than yesterday. The message, the call to action, is to get started. In Harry S Truman’s legendary counsel, “imperfect action is better than perfect inaction.”

Protecting against cracking, hacking, skyjacking, juice jacking means starting with the end in mind. Of course, there are at least two ends in competition here: one to protect and preserve assets, and the other to compromise and capture assets. For this reason, it is important to think like a potential attacker and work backwards, rather than getting caught up in the catchy names for different hacking techniques that will continue to proliferate. Successful attack modi operandi will beget others—just as imperfections in tools to detect, disrupt, delay, or deny attacks will beget other tools. Full employment on either side of the security good guy/bad guy divide would seem assured (especially given human frailty and unmerited optimism).

Thinking Like a Hacker: Aligning With Attack Methodologies

Money is not a reasonable excuse for not having a security program. There are low-cost efforts that can be done to improve security, which is a journey, not a destination. A simple way to get started is to think PEAR: preparation, execution, awareness, repetition. The first four attack steps correlate loosely with preparation and execution. Awareness is the desired state of being well-informed about assets that are connected in some way to WAPs—and that includes those using the connected assets. Because of constantly changing environmental factors like user adaptation of technology and attacker prowess and targets, repetition of secure practices, even after they become habits, is necessary. When I ask my students to “think like hackers” some are initially uncomfortable … and then they get creative (and, at times, just a bit scary). A discussion of PEAR and standard attack steps follows.

Step 1: Reconnaissance

Preparation encompasses more than just purchasing the cyber equivalent of an off-the-shelf first aid kit. If this Big Bandage Theory were sufficient, information assurance professionals would be worried about redefining their brand (and perhaps pursuing another career). Preparation involves thinking like an attacker and following the classic attacker methodology. So, step one: reconnaissance. Knowing what you have that you value is just a partial step; knowing what others value will get you closer. As was discussed in Chapter 3, Blurred Edges: Fixed and Mobile Wireless Access Points, attacker motivations vary. Identifying the most likely motivations is a good start toward understanding how to prioritize assets for protection.

One of my favorite illustrations of the failure to understand fully what should be considered an asset is in the series of YouTube videos from penetration (i.e., pen) tester Chris Nickerson and his team, “Tiger Team—The Car Dealer Takedown.”2

Hired to test their clients’ (a luxury car dealership) state-of-the-art security system, the team thwarted passcode-protected touchpad access control devices, surveillance cameras, motion detectors, and traditional, heavy-duty locks to break into the facility and pwn (power own) not just one of the gorgeous cars for a round-the-block joy ride—which were, of course, covered by insurance to cover damage or theft—but also the PII and financial records for the HNWI clients of the dealership. The videos show clearly how various attack techniques (physical, network penetration, password breaking, social engineering) can be used to satisfy objectives: The attacker has many choices. It also shows the problem of not recognizing truly irreplaceable assets that should be protected most effectively: client trust, personal identity, detailed financial information.

Step 2: Scanning

Organizations and individuals often object that they do not have the resources to bring in a professional pen testing team, so that preparation step is moved to the indefinite future (e.g., when required by a prospective customer, mandated by legislation or industry standard, or triggered by an incident). Meanwhile, doing an interactive exercise within the work group can at least help identify top priority assets that must be protected. Then one can determine whether assets are finite—like a car or an original, signed contract—or replicable—like digital content that can be extruded and yet still be in place.

This is also the stage in which vulnerability assessments are performed. This is comparable to attack methodology step two: scanning. As either a hacker or an authorized pen tester would do, staff can be challenged to find weaknesses in the way current physical or digital assets are protected, even if they are not members of the IT or security teams. The whole organization can be involved with a low-key incentive—perhaps a gift card for lunch at a favorite eatery. After all, security really is a team sport, and the more engaged the whole organization is the better.

One can think of this exercise as a kind of group SWOT analysis (an “assumptions analysis” could also be revealing) of your organizational assets. Encourage group members to think around the corner and to consider alternative ways of completing critical business or mission processes. The real value of the Y2K processes that organizations endured in the late 1990s, I believe, was the gain in understanding about information flow and how work was done under standard operating conditions and how it could get done if the standard approach was no longer feasible. This should be part of organizational business continuity/disaster recovery planning anyway: defining what must be done, even if on a reduced basis, for a limited period of time. Of course, the Y2K certification benefits actually tended to go to the outsourced consultants doing the actual work. They were the ones to become well educated (on their client’s dime) about the operational environment. That knowledge, although documented in often excruciating detail, too often left with the consultants or was captured in pristine binders, duly shelved: snapshot proof that due diligence and due care were honored and respected by the organization.

Steps 3 and 4: Access and Escalation

With work and information flow defined by actual work teams—a useful exercise for continuous process and quality improvement, not just for security—one can more easily see who and what (if an automated process) should and do have access to specific information and system resources. The area of access and credentials management is the sweet spot for an attacker (step three: access and escalation) when not controlled effectively. Examining this area offers opportunities for asking why, especially when certain permissions and privileges do not align with an individual’s (or department’s) role, responsibilities, or “need to know.” This may be due to personnel reassignment, privilege creep, a one-time exception that became permanent, or other organizational historical artifacts.

Credential misuse was an attack vector in 63% of the confirmed data breaches examined in the “2016 Verizon Data Breach Investigations Report,”3 meanwhile 60% of those companies responding to a Rapid7 survey acknowledged that they could not distinguish between compromised and legitimate credentials.4

Other attractive attack surfaces to be explored at this stage are ghost IT accounts and shadow IT. An example of the former from my experience was found in a research institution that had enabled guest access accounts for the wireless network and some of its data resources. According to policy, these guest accounts were to be enabled for the duration of a researcher’s participation on a grant team, then disabled after the grant work was fulfilled. In practice, however, these accounts were not disabled “just in case” the researcher should need access to them at some time in the distant future (even from the grave, apparently, since at least one of the researchers had already departed this physical world).

Shadow IT is, basically, rogue IT infrastructure. Although it is closely associated with bring your own device practices—as when staff use personal, unsegmented laptops or cell phones for business communications—it can also include unauthorized wireless routers and signal boosters (“I just needed better connectivity”) and nonstandard software. Frequently shadow IT is less a symptom of malice on the part of staff and more a symptom of a dysfunctional relationship between the technology and user groups. IT and security teams must be perceived as being an enabler of work group performance and not an impediment.5

Step 4: Exfiltration

Guarding against data exfiltration requires comprehensive knowledge of what data exists; how it should be protected and monitored in its various states (in process, in transit, at rest); who interacts with the data (as creator, user, custodian, owner); where it is located (including media storage format); what is its volatility (frequency changes, declassification schedule, destruction schedule); where is it most vulnerable; and so forth. By adopting the perspective of the typical opportunistic (non-nation-state) attackers, you can identify the data that will be most attractive and the conditions under which that data will be most vulnerable.

Steps 5, 6, 7: Sustainment, Assault, Obfuscation

Incremental Security Actions

Frequently organizations and individuals object that they are not big enough or financially stable (flush) enough or important enough to deploy security solutions beyond tepid passwords and somewhat up-to-date AV software on the network. Such organizations and individuals promote, in effect, that sorry risk management strategy that no one likes to admit because it sounds (and is) inconsistent with reasonable care: denial. I do believe that denial is practiced regularly as a risk management strategy alongside the prescribed ones: mitigate, transfer, accept, avoid.

To avoid an information and network access free-for-all, WAPs should not be construed—nor configured—as being free for all. Takeaways from Chapter 2, Wireless Adoption, Chapter 3, Blurred Edges: Fixed and Mobile Wireless Access Points, Chapter 4, Hacks Against Individuals, Chapter 5, WAPs in Commercial and Industrial Contexts, Chapter 6, WAPs in Medical Environments, Chapter 7, Hacking Wireless Access Points: Governmental Context, and Chapter 8, Non-Civilian Government Context, are summarized below under general categories for individuals, organizations, and automated controls systems (potentially relevant to individuals and organizations). Their order of presentation does not indicate recommended priorities: Individuals and organizations should make their own decisions about where to start. Multiple objectives are addressed within these takeaways; guaranteed, hack-free security is not one of them.

The first objective for implementing these practices is to raise the level of cost and inconvenience to the attacker so that his or her attack cost/benefit calculation is no longer attractive. The second objective is to mitigate the effects of loss or compromise of assets so that one is not vulnerable to ransomware demands, for example, or so that protected information is rendered practically unusable (i.e., is encrypted). The third objective is to encourage shared responsibility, whether across all organizational groups (not just IT or security teams), with device manufacturers (e.g., build security in, force changes to default passwords), or throughout the business partner network and supply chain. The fourth objective is to share information about potential issues (e.g., possible precursor activity, IoC, IoA, product or service vulnerability) and report incidents to appropriate clearinghouses (e.g., National Center for White Collar Crime <https://www.nw3c.org/>). The fifth objective is to choose good WAP hygiene over convenience and encourage others to do so.

Call to Action for Organizations

Essential considerations for reducing one's WAP vulnerability profile are least privilege access to network resources, network segmentation, user and device authentication, application control (including patch and default setting maintenance), contractually defined secure supply chain, data protection, incident response and recovery. The following is a kind of checklist of recommended actions for different components of a wireless communications system.

Mobile and Fixed Devices

ent Secure loaner and dedicated mobile devices for remote travel use with secure VPN connectivity (1024-bit encryption or better)

ent Examine devices upon return for malware presence

ent Revise security functions as deemed necessary

ent Wipe and re-image the device for future use

ent Provision secure mobile devices for a single, VPN-only connection to the agency portal, which then manages connectivity to Internet resources (per US Government secure mobile computing initiative)

Network Architecture

ent Layer digital and analog control mechanisms to reduce attractiveness as a target

ent Implement air gaps between digital devices in commercial facilities

ent Require physical access to mechanical systems for administration

ent Harden remote access (even by legitimate administrators) to prevent lateral movement across networks (otherwise, if the administrator’s credentials are compromised, your network is)

ent Segregate critical communications (consider the following as examples)

ent Medical categories: patient, clinician, procedural (e.g., M2M for remote surgery)

ent Power/utility categories: ICS device control, ICS and SCADA data capture, mechanical system control

ent Military categories: administrator, field combatant, commander

ent Emergency/public safety: dispatch, field response team member, device (e.g., wearable or fixed surveillance cameras) data capture

Credentials and Access Control

Data Protection

Security-Conscious Culture6

Incident Response

Call to Action for Individuals

Individual users should consider implementing restricted physical access to devices, trusted communications channels, hardened home-based infrastructure, and off-device data storage. Basic recommended checklist items for an individual's wireless communications system are listed below.

Mobile and Fixed Devices

Networks

Data Protection

Call to Action for Automated Systems

Automated controls system should be characterized by network separation of functions, strong controls of information flows across networks, secure remote communications. Recommended checklist items for wireless communications systems are captured below.

Devices

Network Architecture

Data Protection

The Importance of Thinking Earnestly

We all have choices about how we implement and use technology, making our own personal cost/benefit calculation about our appetite for risk versus convenience and prioritizing actions (or inactions) accordingly. As dorm room posters in the late 1960s posters proclaimed, “Not to decide is to decide.”8 Although we’ve not touched much on ethical considerations in these chapters, new technologies and new uses for technologies invite such considerations. The ongoing debate about autonomous cars, for example, poses ethical questions about how these vehicles would be programmed to act in situations when it is inevitable that someone will be hurt.9

Continuing with the autonomous car example, which is so dependent on wireless technologies as a system of components, we can analyze it from an engineering perspective as described in “How Might a Security Engineer Look at Autonomous Vehicles?”

Making risk calculations requires inviting multiple perspectives—ethical, engineering, business, legal, technological—and thinking earnestly. Security decisions, actions, and inactions require the whole team.

Conclusion

WAPs are everywhere: in or around our pockets, cars, coffee shops, cameras, streetlights. They rely on chatty technology that is often undiscriminating about the intentions of those receptors to which they are transmitting information or allowing access. We can choose to give them up (unlikely answer) or choose to use them responsibly (good answer). We must respect their power and learn to control it to our advantage and not abdicate that control to others. Although security is an incremental, often experimental, process—it’s worth the investment. The consequences of failing to act, or failing to think while acting, are too disturbing—whether considered at the level of the individual, organization, or nation-state.

Thank you for taking the time to consider.

How Might a Security Engineer Look at Autonomous Vehicles?

First, the engineer would look at the system components:

ent Highways and streets with smart sensors (e.g., speed sensors, cameras) and C&C center (AKA the smart grid)

ent Vehicles without any ability to communicate with the smart grid or other vehicles (e.g., 1970 Mustang)

ent Vehicles with an ability to communicate and act in concert with the smart grid and other vehicles (best-case scenario is all vehicles are this way—dream on)

ent Vehicles with an ability to communicate with the smart grid and other vehicles but will not act in concert with them. These vehicles include those used in motorcades, fire, police, and emergency management activities, which will be piloted by human beings to get around problems not programmed into the smart grid

ent Vehicles with an ability to communicate with the smart grid and other vehicles but will not act in concert with them. In addition, these vehicles have the ability to direct the smart grid and other vehicles. These select vehicles will belong to presidential motorcades, and police and fire commanders

Next the engineer would look at how the components interact:

ent How does the smart grid communicate, identify, and track each vehicle on its grid?

ent How does each vehicle communicate with the smart grid?

ent How does each vehicle communicate, identify, and track each vehicle surrounding it?

ent What does the smart grid do when the communications it receives from a vehicle does not match its sensor input?

ent What does each vehicle do when the communications it receives from the smart grid does not match its sensor input?

ent What does each vehicle do when the communications it receives from other vehicles does not match its sensor input?

ent What does each vehicle do when no communications are received from the smart grid?

ent How does the smart grid validate and act on commands from “priority” vehicles (e.g., presidential motorcades)?

ent How does each vehicle validate and act on commands from “priority” vehicles (e.g., presidential motorcades)?

Interactions must be analyzed for normal conditions and for systems under stress. An example of a stress condition is a city being told it has X hours to evacuate before a disaster strikes. In this case, one needs to determine:

Next, the engineer needs to think like a criminal to determine:

And the engineer needs to think like a terrorist to determine:

The engineer looks for countermeasures to protect against criminal and terrorist activity. The countermeasures need to be vetted to ensure they do not adversely impact the functions of the smart grid and autonomous vehicles. Then they need to be vetted to see if and how criminals and terrorists could make use of the countermeasures if they are hacked.

Although some may believe that the above will keep security engineers awake at night, in reality they sleep like a baby knowing that they have employment for as long as they want.

Endnotes