2.2.1 Confidentiality

• Assurance that information is not disclosed to unauthorized individuals, programs, or processes.

• Ensures that the necessary level of secrecy is enforced at each junction of data processing and prevents unauthorized disclosure.

• Some information is more sensitive than other information and requires a higher level of confidentiality.

• The military and intelligence organizations classify information according to multilevel security designations such as Secret, Top Secret, and so forth that require protection from disclosure.

• Individuals have personally identifiable information such as social security numbers that also require protection from disclosure to unauthorized individuals.

• Attacks against confidentiality perpetrated by individuals tend to be about personal gain, so they go after credit card numbers that they use themselves or sell on the black market.

• On the other hand, Nation States may be after corporate confidential information like plans for a new fighter jet or national or corporate secrets.

• Either individuals, corporations, or government information may be the target of insider attacks, who have a variety of motives for accessing information they are not authorized to.

2.2.2 Integrity

• Assures that the accuracy and reliability of information and systems are maintained and any unauthorized modification is prevented.

• Must make sure data, resources, are not altered in an unauthorized fashion.

• Modification of data on disk, or in transit would violate integrity.

• Modification of any programs, computer systems, and network connections would also violate integrity.

• Vandals may try to change or destroy data just to create confusion or fear.

• Nation states may try to change data to affect outcomes beneficial to them. The military would fear an attack that changes battlefield recognizance information or command directives. These would be integrity attacks.

2.2.3 Availability

• Ensures reliability and timely access to data and resources to authorized individuals.

• Information systems to be useful at all must be available for use in a timely manner so productivity is not affected.

• A system that loses connectivity to its database would become useless to most users.

• A system that runs so slowly that users cannot get their work done becomes useless as well.

• Denial of service attacks have a wide variety of forms but all tend to keep some aspect of a system so busy responding to the DoS traffic that it no longer functions for its legitimate users.

Computer security is necessary because there are threats. The best way to think about what types of security is needed is to establish a model for those threats. This will get us into some basic vocabulary that is used to describe threats.

2.3.1 Vulnerability

A vulnerability is a software, hardware, procedural, or human weakness that provides a hacker an open door to a network or computer system to gain unauthorized access to resources in the environment. Weak passwords, lax physical security, unmatched applications, an open port on a firewall, or bugs in software enable an attacker to leverage that flaw to gain access to the computer that software is running on. The Heartbleed bug was a vulnerability deployed on 66% of servers on the Internet [2] (not counting email, chat or VPN servers, or any embedded devices) created by a programmer’s failure to verify the bounds of a buffer that allowed unlimited external access to a server’s internal memory. For years, the vast majority of home wireless access points were shipped with the administration password of “password” and most users never changed that creating a huge vulnerability.

2.3.2 Threat

A threat is a potential danger to information or systems. The danger is that someone or something will identify a specific vulnerability and use it against the company or individual. A hacker or attacker coming into a network from across the internet is a threat agent. The entity that takes advantage of a vulnerability is a threat agent. A threat agent might be an intruder accessing the system through an open port on firewall. Or it could be a process accessing data in a way that violates security policy. An employee making a mistake that exposes confidential information is an (inadvertent) threat agent. The insider who, for their own reasons, wants to cause harm or steal information taking advantage of their insider access privileges is a threat agent.

2.3.3 Risk

Risk is the likelihood of a threat agent being able to take advantage of a vulnerability and the operational impact if they do. Risk ties together the vulnerability, threat and likelihood of exploitation to the resulting operational loss. If firewall ports are open, if users are not educated on proper procedures, if an intrusion detection system is not installed or configured correctly, risk goes up. If a known vulnerability is not addressed, risk goes up because bad guys pay attention to discovered vulnerabilities, they did not discover themselves.

2.3.4 Asset

Assets can be physical, information, monetary, or reputation. A physical asset includes computers, network equipment, or attached peripherals. Information assets are things such as customer data, proprietary information, and secret information. Monetary assets include the fines or direct expenses from a breach or loss of stock value in the stock market. And reputation asset is what is lost due to the poor perceptions of a company that has suffered a high visibility breach.

2.3.5 Exposure

Exposure is an instance of being subjected to losses or asset damage from a threat agent. A vulnerability exposes an organization to possible damages. Just as failure to have working fire sprinklers exposes an organization not only to fire danger but also losses of physical assets and potential liabilities, poor password management exposes an organization to password capture by threat agents who would then gain unauthorized access to systems and information.

2.3.6 Safeguard

A safeguard (or countermeasure) mitigates potential risk. It could be software, hardware, configurations, or procedures that eliminate a vulnerability or reduce likelihood a threat agent will be able to exploit a vulnerability.

The relationships between all of these concepts form a threat model: A threat agent creates a threat, which exploits a vulnerability that leads to a risk that can damage an asset and causes an exposure, which can be remedied through a safeguard or countermeasure.

If no one and nothing had access to our computers and networks we would be done with this discussion and this would be a very short chapter. Threats exist because there is access (usually through a network a system is connected to but also even when a system is air-gapped), so the next thing we need to include, when thinking about what security is, has to be access control. Readers who are aware of embedded systems that are not connected to any network or are on a network that is air-gapped from any network, where threat agents are active and think those devices are safe from threat just need to remember how Stuxnet was able to destroy 2000 uranium processing centrifuges that were air-gapped from the Internet.

2.4.1 Identification

All access control, and all of security for that matter, hinges on making sure with high confidence we know who is requesting access to a resource. If everyone can claim to be Barack Obama and gains access as such, there is little hope we will have much security in our systems. Identification is the method for ensuring that a subject is the entity it claims to be. Once an authoritative body has accepted the entity is who they say they are, that information is mapped to something that can be used to claim that identity such as a login user name or account number.

2.4.2 Authentication

A weakness in most systems is that identification is quite easy to spoof. Stronger defense against what are called social engineering attacks requires a second piece of the credential beyond identification such as password, passphrase, cryptographic key, personal identification number, anatomical attribute (biometric), token, or answers to a set of shared secrets.

2.4.3 Authorization

Authorization asks the question: Does the subject have the necessary rights and privileges to carry out the requested actions? If so, the subject is authorized to proceed.

2.4.4 Accountability

Keeping track by identity of what each subject did in the system is called accountability. It is used for forensics, to detect attacks, and to support auditing.

Clearly, different organizations have different needs when it comes to security. The national intelligence and defense organizations need to protect confidential, secret, and top secret information in separate buckets and people without sufficient clearance must never be allowed to see higher level information. A bank must not allow customer social security numbers to get to unauthorized individuals. These are examples of security policies.

2.8.1 Mistakes in software

Mistakes are a big part of how cyber attackers ply their trade. Programmers make a mistake, that becomes a bug in an application and the cyber attackers exploit that bug as a cyber vulnerability. Many mistakes in the software in the SCADA controllers, and the Windows-based systems commonly used to program them, were leveraged to destroy 2000 centrifuges in the 2008 Stuxnet attack. Similarly, it was mistakes in various aspects of the systems at Sony, Target, Home Depot, and hundreds of others that allowed those famous cyber attacks to proceed. Stuxnet, however, is in a new class of dangerous attacks designed to destroy physical assets from across the Internet but this category also includes the Shamoon attack on Saudi Aramco that destroyed 30,000 desktop computers and in late 2014 hackers struck an unnamed steel mill in Europe. They did so by manipulating and disrupting control systems to such a degree that a blast furnace could not be properly shut down, resulting in “massive”—though unspecified—damage.

According to Lloyd’s of London, businesses lose $400B per year due to cyber attacks but due to potential lawsuits and liability issues, much cybercrime goes unreported and so is presumably much higher than $400B. According to the US Department of Homeland Security, about 90% of security breaches originate from defects in software. The embedded processors in mobile devices and the applications built for them are becoming the most common vector of attack on companies. These mobile apps typically have poor security because developers rush to bring them to market before properly implementing security protocols. More on software bugs and vulnerabilities to cyber attack is discussed later in this chapter.

2.8.2 Opportunity scale created by the Internet

The sheer size of the Internet, the existence of malcontents, determined nation-state adversaries, and the financial gains now possible from cyber attacks, are all reasons for growth of cyber crime.

Size of the Internet as measured by domains is 271 M, [6] servers, and as measured by users is 3.17B users.¹ There has been an exponential explosion of smart phones that are Internet connected. In 2015, there were 2B smart phone users worldwide and that is expected to grow to over 6B by 2020.¹ GE estimates the “Industrial Internet” has the potential to add $10 to $15 trillion² to global GDP over the next 20 years. Cisco states that its forecast for the economic value of the IoT is $19 trillion³ in the year 2020.

2.8.3 Changing nature of the adversaries

The first cyber-criminals were purely vandals. The previous generation’s graffiti is hacking into a site and scribbling on their home page. There is an aspect of Haves vs. Have-nots on the Internet where the have-nots can be across borders and oceans and still attack the rich people in the rich countries. Thus phase two of cyber-crime became identity theft and wholesale thefts of credit cards which are re-sold as in the Target POS credit card theft. This phase also included a rash of cyber-ransom attacks against individuals and small businesses. Meanwhile increasing steadily are the actions of nation-states, where the aim is to steal secrets and to obtain an advantageous posture for a future action that will include cyber-war as part of an overall strategy. These nation states steal identities of government employees, and contractors in order to blackmail individuals into turning over secrets, they are behind Flame—an attack against the embedded devices in personal computers (e.g., Keyboard, microphone, camera)—whose mission is espionage and is considered by many to be the most complex malware ever found. The US’s main adversaries have penetrated critical infrastructure and have, it is believed, left behind mechanisms allowing them to take action against that infrastructure when it suits their overall aims.

2.8.4 Financial gain opportunities

The Target attack, enabled by the HVAC-contractor vulnerability, ultimately compromised the POS systems where consumer's credit cards are swiped. The foreign organized crime hackers who perpetrated the attack were highly enriched by their ability to resell those credit cards on the black market [7]. Those stolen cards were being offered at “card shops” starting at $20 each, up to more than $100. Between 1 and 3 million of those credit cards were ultimately sold on the black market, raising an estimated $53.7 million for the hackers.⁴ The attack costs Target $148 million, and costs credit card issuers institutions $200 million. The CEO lost his job and company profits fell 46% the quarter after the breach.

2.8.5 Ransomware

Ransomware is malware that locks your keyboard or computer to prevent you from accessing your data until you pay a ransom, usually demanded in Bitcoin. The digital extortion racket is not new—it’s been around since about 2005, but attackers have greatly improved on the scheme with the development of ransom cryptoware, which encrypts your files using a private key that only the attacker possesses, instead of simply locking your keyboard or computer.

It is not the case that ransomware just affects desktop machines or laptops; it also targets mobile phones and if it became more lucrative, the IoT would be next (think: control of your Nest thermostat during very cold weather).

Symantec gained access to a C&Cl server used by the CryptoDefense malware and got a glimpse of the hackers’ haul based on transactions for two Bitcoin addresses the attackers used to receive ransoms. Out of 5700 computers infected with the malware in a single day, about 3% of victims appeared to shell out for the ransom. At an average of $200 per victim, Symantec estimated that the attackers hauled in at least $34,000 that day. Extrapolating from this, they would have earned more than $394,000 in a month. This was based on data from just one command server and two Bitcoin addresses; the attackers were likely using multiple servers and Bitcoin addresses for their operation.

Conservatively, at least $5 million is extorted from ransomware victims each year. But forking over funds to pay the ransom doesn’t guarantee attackers will be true to their word and victims will be able to access their data again. In many cases, Symantec reports, this doesn’t occur.

2.8.6 Industrial espionage

Worldwide, around 50,000 companies a day are thought to come under cyberattack with the rate estimated as doubling each year. One of the means perpetrators use to conduct industrial espionage is by exploiting vulnerabilities in computer software. Malware and spyware as a tool for industrial espionage, are designed to transmit digital copies of trade secrets, customer plans, future plans and contacts. Newer forms of malware include devices which surreptitiously switch on mobile phones camera and recording devices and in some cases, to monitor every keystroke at the keyboard.

Operation Aurora was a series of cyber attacks conducted by advanced persistent threats such as the Elderwood Group based in Asia [8]. The attack has been aimed at dozens of organizations, including Adobe Systems, Juniper Networks, Rackspace, Yahoo, Symantec, Northrop Grumman, Morgan Stanley, and Dow Chemical. The primary goal of the attack⁵ was to gain access to and potentially modify source code repositories at these high tech, security and defense contractor companies. The Source Code Management systems were found to be wide open even though these were the crown jewels of these companies, in many ways more valuable than any financial or personally identifiable data that they may have and spend so much time and effort protecting.

2.8.7 Transformation into cyber warfare

Since 2010, when the cyberweapon Stuxnet was finally understood—and the damage a cyber attack could affect was fully absorbed—it has become clear that cyberwarfare was possible. At the very least, if not used as a weapon directly, cyber attacks were now part of any adversarial nation’s foreign policy. The target most frequently cited is our critical infrastructure which in general is heavily dependent on embedded systems such as programmable logic controllers (PLCs) and SCADA controllers. This is exactly what Stuxnet targeted. And this is why this chapter is so important.

2.9.1 Asymmetrical

A DARPA review of 9000 distinct pieces of malware in 2010 found that the average size of each independent attack component was only 125 lines of code. Meanwhile, the defensive systems enterprises use to protect their systems including intrusion detection continue to grow and some of these systems have reached 10 million lines of code. That is so complex—and these systems by nature have to have privileged access to the systems they are protecting—that they have become a desirable target for attack. Like all software, the larger it is the more bugs it has. Steve Maguire in his book Writing Secure Code found that across all deployed software regardless of application domain or programming language, one finds between 15 and 50 bugs per thousand lines of code (abbreviated KLOC). Rough estimates have been suggested that 10% of all bugs are potential cyber vulnerabilities. Given this, a 10-million lines of code defensive system has 150,000 bugs at best and potentially 15,000 security vulnerabilities that could enable an attacker entry into the network and all the systems the defensive system was designed to protect.

Size of malware compared to the increasing complexity of defensive software.

Malware over almost a 25-year span has remained at about 125 lines of code measured over 9000 samples. But in that same period, defensive systems have gotten increasing more complex to the point where they are over 10 million lines of code. Since studies have shown that there are consistently 15 bugs per KLOC, this means the threat and we are diverging. Figure credit DARPA.

2.9.2 Architectural flaws

The crux of the matter is that we are losing the cyber war mostly because the architecture of our computer processors has no support for cybersecurity, so it is practically child’s play to attack them and have them do the bad guys bidding. No matter what virus protection, firewalls, or number of patches we apply, software is written by people and people cannot write perfect software, so vulnerabilities will always exist in any reasonably complex software. Bad guys are smart, they are patient, and they can win with very simple attack software.

Our legacy processor architectures are built around what many in the cyber security community call “Raw Seething Bits.” That is their description of what it means to have a single undifferentiated memory, where there is no indication what each word in that memory is. There is no way to tell—and most importantly, no way for the processor to tell—if a word is an instruction or an integer or a pointer to a block of memory storing data. There is an important reason processors started out having a single undifferentiated memory: it was simple to build. Simple was important when logic was performed by vacuum tubes or, a bit later, by just a few really expensive transistors: it was easier and cheaper to build.

That architecture—still in use in all our computing devices whether servers, laptops, or embedded devices—is Von Neumann’s 1945 stored-program computer (see Fig. 1). Having worked out the simplest architecture that worked, the industry started to perfect it, made transistors smaller and smaller, and ultimately started to see a trend that became known as Moore’s Law take hold. Moore’s Law stated that every 18th month the number of transistors occupying the same area would double. In fact the reason for the explosion of the Internet, mobile devices, the coming IoT, and information processing in general, is Moore’s Law leveraging this simple architecture and driven by a mantra of smaller, cheaper, faster. Moore’s Law has given us an iPhone more powerful than all computers NASA owned when it landed men on the moon. Transistors are now incredibly cheap, and while Moore’s Law may have reached its limit, the 2000 transistors for the first microprocessor in 1971 has become 5.5 billion transistors in the current model. Ironically, it’s the connectedness of everything enabled by Moore’s Law that has made cyber threats so prevalent and so serious.

In 1945, Von Neumann and others described a simple but powerful processor architecture with a single internal memory. This architecture continues to dominate the architecture of processors in billions of devices today. This single memory where instructions, data, pointers, and all the data structures needed by an application are stored with no way to tell what is what. It is this memory sometimes called “raw, seething bits” that prevents the processor from cooperating with the program to enforce security. Figure under the Creative Commons Attribution-Share Alike 3.0 by Kapooht.

As our processors became much more powerful and sophisticated, people began to trust them to protect increasingly valuable things. As processor power made more things possible, people’s expectations also grew and so software size has grown exponentially to keep up. All the while programming languages like C and C++ continued to provide direct access to the “raw, seething bits” of memory without manifest identity, types, boundaries, or permissions to help explain what each word in memory was for. Even Java—12 years newer than C++ and 23 years newer than C—which was designed to be safer and more helpful to the programmer, retains the C/C++ risks because it builds on libraries written in C and C++ and that unsound foundation leaves it vulnerable to bugs and attacks. This has left everything up to the programmer. When programming in C/C++/Java, the default is unsafe. As we have seen, a buffer when allocated does not protect itself from being overwritten; the programmer always has to do extra work (write more code) to make it safe. This is not so much the fault of the programming language as it is of things below the level of the language the programmer is writing in. It is this undefined behavior of the language, where most of the problems (which become cyber vulnerabilities) arise.

As cybersecurity started to become a concern, there were important constraints that had to be enforced in every program by every programmer to avoid cyber attack. But those vital constraints would only be enforced when every programmer got everything right on every single line of code. Any single mistake could become a vulnerability and sink the ship.

2.9.3 Software complexity—many vulnerabilities

NIST maintains a list of the unique software vulnerabilities (see https://nvd.nist.gov). Across all the world’s software, whenever a vulnerability is found that has not been identified anywhere before, it is added to this list. As of this writing, that list was approaching 76,000 unique vulnerabilities. This means attackers have 76,000 things they can leverage to compromise the systems they attack. Vulnerabilities are how attackers get in. Bugs (or weaknesses) are how the software is written so that vulnerabilities are created.

The common weakness enumeration list contains a rank ordering of software errors (bugs) that can lead to a cyber vulnerability. Top 25 most dangerous software errors is a list of the most widespread and critical errors that can lead to serious vulnerabilities in software. They are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.

Rank ordered by a score based on factors including technical impact, attack surface, and environmental factors as determined by NIST and MITRE who maintain the list. Each item in the list has its ID listed with it for cross-reference to the list maintained at http://cwe.mitre.org.

Layer upon layer of software increases the “attack surfaces” that attackers can probe for weaknesses. Every layer is subject to the same 15–50 bugs per KLOC and the corresponding exploitable vulnerabilities. This has led many to conclude that while perimeters are absolutely necessary to keep the vandals and script-kiddies out, they are far from sufficient to keep out the determined and sophisticated hackers that nation-states now deploy.

2.9.4 Complacence, fear, no regulatory pressure to act

Another factor making today’s security strategies not work is the simple fact that it is too easy to do nothing. There is the erroneous thinking that systems that are air-gapped are safe (the Stuxnet SCADA controllers were air-gapped). There is the fear and hoping that someone else gets hacked instead of you. In almost all situations for embedded systems there are few if any regulations that force one to act combined with a competitive environment that makes one not want to be first as it cuts into profit margins. The regulations we do have are mostly advisory in nature and have no teeth to require industry to act. It is a situation that is heading for a major catastrophe before serious action is taken.

2.9.5 Lack of expertise

Finally, security is not working for a huge number of organizations—especially smaller ones—simply because these organizations are not experts at IT, and expecting them to be on the cutting edge of IT security is totally unreasonable. Even if they outsource their IT function to a supposed expert, the IT outsourcing companies that service small organizations are themselves small businesses that cannot keep pace with the rapid change in the cybersecurity domain.

2.11.1 Stuxnet

Stuxnet was a 500-kilobyte computer worm that infected the software of at least 14 industrial sites in the country it was targeted at, including a uranium-enrichment plant. While a computer virus relies on an unwitting victim to install it, a worm spreads on its own, often over a computer network [14].

This worm was an unprecedentedly masterful and malicious piece of code that attacked in three phases. First, it targeted Microsoft Windows machines and networks, repeatedly replicating itself as it infected system after system. From there it sought out Siemens Step7 software, which is also Windows-based system used to program ICSs that operate equipment, such as centrifuges. Finally, it compromised the PLCs that are directly connected to and in control of the centrifuge motors. The worm’s authors could thus spy on the industrial systems and even cause the fast-spinning centrifuges to tear themselves apart, unbeknownst to the human operators at the plant. The Stuxnet victim never confirmed that the attack destroyed some of its centrifuges but satellite images show 2000 centrifuges being rolled out of the facility into the trash heap.

Stuxnet could spread stealthily between computers running Windows—even those not connected to the Internet. If a worker stuck a USB thumb drive into an infected machine, Stuxnet could jump onto it, then spread onto the next machine that read that USB drive. Because someone could unsuspectingly infect a machine this way, letting the worm proliferate over local area networks, experts feared that the malware had perhaps gone wild across the world. Basically it did but Stuxnet was highly selective in terms of location, host, and SCADA controller it had its sights set on so its spread was harmless except to one facility it was designed to target.

For several years the authors of Stuxnet were not officially acknowledged, but the size and sophistication of the worm led experts to believe that it could have been created only with the sponsorship of a nation-state, leading candidates being the United States and one of its allies [15]. Then in Jun. 2012, Obama announced that the United States had been involved. Since the discovery of Stuxnet many computer-security engineers have been fighting off other weaponized viruses based on Stuxnet design principles, such as Duqu, Flame, and Gauss, an onslaught that shows no signs of abating. The callout outlines the 12 steps that the Stuxnet malware went through. The most detailed analysis of how Stuxnet worked was done by Ralph Langer [16].

Put the following in a callout:

1. Stuxnet was initially launched into the wild as early as Jun. 2009, and its creator updated and refined it over time, releasing three different versions. An indication of how determined they were to remain anonymous was that one of the virus’s driver files used a valid signed certificate stolen from RealTek Semiconductor, a hardware maker in Taiwan, in order to fool systems into thinking the malware was a trusted program from RealTek.

2. Several layers of masking obscured the zero-day exploit inside, requiring work to reach it, and the malware was huge—500 k bytes, as opposed to the usual 10–15 k. Generally malware this large contained a space-hogging image file, such as a fake online banking page that popped up on infected computers to trick users into revealing their banking login credentials. But there was no image in Stuxnet, and no extraneous fat either. The code appeared to be a dense and efficient orchestra of data and commands.

3. Normally, Windows functions are loaded as needed from a DLL file stored on the hard drive. Doing the same with malicious files, however, would be a giveaway to antivirus software. Instead, Stuxnet stored its decrypted malicious DLL file only in memory as a kind of virtual file with a specially crafted name. It then reprogrammed the Windows API—the interface between the operating system and the programs that run on top of it—so that every time a program tried to load a function from a library with that specially crafted name, it would pull it from memory instead of the hard drive. Stuxnet was essentially creating an entirely new breed of ghost file that would not be stored on the hard drive at all, and hence would be almost impossible to find.

4. Each time Stuxnet infected a system, it “phoned home” to one of two domains—http://www.mypremierfutbol.com and http://www.todaysfutbol.com hosted on servers in Malaysia and Denmark—to report information about the infected machines. This included the machine’s internal and external IP addresses, the computer name, its operating system and version, and whether Siemens Simatic WinCC Step7 software, also known simply as Step7, was installed on the machine. This approach let the attackers update Stuxnet on infected machines with new functionality or even install more malicious files on systems.

5. Out of the initial 38,000 infections, about 22,000 were in the targeted country. The next most infected country was a distant second, with about 6700 infections, and the third-most had about 3700 infections. The United States had fewer than 400.

6. All told, Stuxnet was found to have at least four zero-day attacks in it. That had never been seen before. One was a Windows print spooler vulnerability that allowed the worm to spread across networks using a shared printer. Another attacked vulnerabilities in a Windows keyboard driver and a Task Scheduler process to perform a privilege escalation to root. Finally, it was exploiting a static password Siemens had hard-coded into its Step7 software, which it used to gain access to and infect a server hosting a database used with the Step7 programming system.

7. Stuxnet was not spreading via the Internet like every other worm before it had. It was targeting systems that were not normally connected to the Internet at all (air-gapped) and instead was spreading via USB thumb drives physically inserted into new machines.

8. The payload Stuxnet carried was three main parts and 15 components all wrapped together in layers of encryption which would only be decrypted and extracted when the conditions on the newly infected machine were just right. When it found its target—a Windows machine running Siemens Step7—it would install a new DLL that impersonated a legitimate one Step7 used.

9. Step7 was a Windows-based programming environment for the Siemens PLC used in many industrial control automation applications. The malicious DLL would intercept commands going from Step7 to the PLC and replace them with its own commands. Another portion of Stuxnet disabled alarms as a result of the malicious commands. Finally, it intercepted status messages sent from the PLC to the Step7 machine stripping out any signs of the malicious commands. This meant workers monitoring the PLC from the Step7 machine would see only legitimate commands and have no clue the PLC was being told to do very different things from what they thought Step7 had told it to do. At this moment, the first ever worm designed to do physical sabotage was born.

10. Stuxnet, it turns out, was a precision weapon sabotaging a specific facility. It carried a very specific dossier with details of the target configuration at the facility it sought. Any system not matching would be unharmed. This made it clear the attackers were a government with detailed inside knowledge of its target.

11. In the final stage of Stuxnet’s attack, it searched for the unique part number for a Profibus and then for one of two frequency converters that control motors. The malware would sit quietly on the system doing reconnaissance for about 2 weeks, then launch its attack swiftly and quietly, increasing the frequency of the converters to 1410 Hz for 15 min, before restoring them to a normal frequency of 1064 Hz. The frequency would remain at this level for 27 days, before Stuxnet would kick in again and drop the frequency down to 2 Hz for 50 min. The drives would remain untouched for another 27 days, before Stuxnet would attack again with the same sequence. The extreme range of frequencies suggested Stuxnet was trying to destroy whatever was on the other end of the converters. Satellite images show that approximately 2000 centrifuges—one-fifth of their total—were removed from the targeted country’s nuclear facility suggesting they were indeed destroyed.

12. Recently it was discovered there were even older versions of Stuxnet that went undiscovered for many years. The first targeted gas valves in nuclear reactors and the second targeted the reactors’ cores.

The 2010 Stuxnet worm used at least three separate zero-day exploits—an unprecedented feat—to damage industrial controllers and disrupt the uranium enrichment facility.

The zero-day vulnerabilities included the following from the list of CVEs [9]:

• CVE-2010-2568—Executes arbitrary code when user opens a folder with maliciously crafted.LNK or .PIF file.

• CVE-2010-2729—Executes arbitrary code when attacker sends a specially crafted remote procedure call message.

• CVE-2010-2772—Allows local users to access a back-end database and gain privileges in Siemens Simatic WinCC and PCS 7 SCADA system.

The attack also exploited already patched vulnerabilities, suggesting that the attackers knew the systems likely would not have been updated.

2.11.2 Flame, Gauss, and Duqu

Flame, Gauss, and Duqu are cousins of Stuxnet but did not focus on embedded systems. Still it is useful to understand what serious attackers are interested in doing and because the distinction between embedded systems and nonembedded systems will lesson over time.

2.11.3 Routers

Routers are attractive to hackers because they operate outside the perimeter of firewalls, antivirus, behavioral detection software, and other security tools that organizations use to safeguard data traffic. Until now, they were considered vulnerable only to sustained denial-of-service attacks using barrages of millions of packets of data. It has been “common knowledge” that they were not very vulnerable to outright takeover. However, a recent very dangerous attack against routers called SYNful has proven this commonly held belief is wrong. SYNful is a reference to SYN, the signal a router sends when it starts to communicate with another router, a process which the implant exploited.

If one seizes control of the router, that attacker owns the data of all the companies and government organizations that sit behind that router. Takeover of the router is considered the ultimate spying tool, the ultimate corporate espionage tool, the ultimate cybercrime tool. Router attacks have hit multiple industries and government agencies.

Cisco has confirmed the SYNful attacks but said they were not due to any vulnerability in its own software. Instead, the attackers stole valid network administration credentials from targeted organizations or managed to gain physical access to the routers. Mandiant has found at least 14 instances of the router implants [24]. Because the attacks actually replace the basic software controlling the routers, infections persist when devices are shut off and restarted. If found to be infected, basic software used to control those routers has to be re-imaged, a time-consuming task for IT engineers.

SYNful Knock is a stealthy modification of the router’s firmware image that can be used to maintain persistence within a victim’s network. It is customizable and modular in nature and thus can be updated once implanted. Even the presence of the backdoor can be difficult to detect as it uses nonstandard packets as a form of pseudo-authentication.

The initial infection vector does not appear to leverage a zero-day vulnerability. It is believed that the credentials are either default or discovered by the attacker in order to install the backdoor. However, the router’s position in the network makes it an ideal target for re-entry or further infection. It is a significant challenge to find backdoors within one’s network but finding a router implant is even more so. The impact of finding this implant on one’s network is severe and most likely indicates the presence of other footholds or compromised systems. This backdoor provides ample capability for the attacker to propagate and compromise other hosts and critical data using this as a very stealthy beachhead.

The implant consists of a modified Cisco IOS image that allows the attacker to load different functional modules from the anonymity of the internet [25]. The implant also provides unrestricted access using a secret backdoor password. Each of the modules are enabled via the HTTP (not HTTPS), using specially crafted Transfer Control Protocol (TCP) packets sent to the routers interface. The packets have a nonstandard sequence and corresponding acknowledgment numbers. The modules can manifest themselves as independent executable code or hooks within the routers IOS that provide functionality similar to the backdoor password. The backdoor password provides access to the router through the console and Telnet.

This very sophisticated, powerful, and dangerous attack on such an important embedded device is emblematic of what any embedded device developer has to be prepared for.

2.14.1 Electric grid

The people who carried out the Dec. 2015 first known hacker-caused power outage, used highly destructive malware to gain a foothold into multiple regional distribution power companies in an Eastern European country and delay restoration efforts once electricity had been shut off. The malware, known as BlackEnergy, allowed the attackers to gain a foothold on the power company systems, said the report, which was published by a member of the SANS ICSs team. The still-unknown attackers then used that access to open circuit breakers that cut power. After that, they likely used a wiper utility called KillDisk to thwart recovery efforts and then waged denial-of-service attacks to prevent power company personnel from receiving customer reports of outages.

The attackers demonstrated planning, coordination, and the ability to use malware and possible direct remote access to blind system dispatchers, cause undesirable state changes to the distribution electricity infrastructure, and attempt to delay the restoration by wiping SCADA servers after they caused the outage. This attack consisted of at least three components: the malware, a DoS to the phone systems, and the missing piece of evidence of the final cause of the impact. Analysis indicates that the missing component was direct interaction from the adversary and not the work of malware. Or in other words, the attack was enabled via malware but consisted of at least three distinct efforts.

2.16.1 Spoofing email

An example of spoofing email might be that an attacker changes the name in the From field to be the name of the network administrator and sends the message to the CEO’s assistant. The message says the IT department is having trouble with the CEO’s account and to please help them out by supplying the CEO’s confidential password. Seeing the correct name of the network administrator and not knowing how to look deeper at the inner workings of the email message, the admin is likely to comply and provide the password. With the CEO’s credentials messages can be sent to many people in the company that they would believe that might allow the attacker to get at critical embedded systems within the company’s operations.

2.16.2 Phishing

Phishing is closely related to spoofing email. Phishing is used to install and execute CryptoLocker, which is a very malicious form of ransomware that encrypts files on the user’s machine and across their entire connected network and demands a ransom to provide the key to decrypt those files. One way it enters is via a spoofed email message that pretends to originate from a source the user trusts and has a relationship with. The message has an attached Word document with a name and a message in the email body that makes the user want to open the document. Once the document is opened, it starts running some embedded Word macros. As those macros begin to execute CryptoLocker installs itself into the user’s Documents and Settings folder, using a randomly generated name, and adds itself to the list of programs in the registry that Windows loads automatically every time one logs on. It produces a lengthy list of random-looking server names in the domains .biz, .co.uk, .com, .info, .net, .org, and .ru. It tries to make a web connection to each of these server names in turn, trying one each second until it finds one that responds. Once it has found a server that it can reach, it uploads a small file that is essentially the “CryptoLocker ID.” The server then generates a public-private key pair unique to that ID, and sends the public key part back to the source computer. The private key part is tucked away impossible for the victim to access. The malware on the computer uses this public key to encrypt all the files it can find that match an extensive list of extensions, covering file types such as images, documents, and spreadsheets. At this point, the bad guys won and the victim has lost. CryptoLocker then pops up a “pay page,” giving the victim a limited time, typically 72 hours, to buy back the private key for their data, typically for 2 bitcoins or $300. Since the ransomers are using modern cryptography, once they have encrypted the victim's disk, there are no back doors or shortcuts to help the victim out. What the ransomers have encrypted can only be decrypted using their private key. Therefore, if they don’t provide that private key, the data is as good as gone. There are many situations where this could directly or indirectly affect embedded devices that are within the same network as the original victimized machine. Also other types of phishing can more directly target embedded devices such as those used widely in critical infrastructure.

2.16.3 Password guessing

It may not sound like an attack category but by far the easiest attack against embedded systems is still password guessing. Many devices like routers, PLCs, and even automotive diagnostic ports have factory-defined passwords that are supposed to be changed by the owner at the time of installation but frequently are not. Thus, passwords like “12345,” “password,” and “admin” are prevalent on millions of devices. As these devices increasingly are put on the Internet for legitimate purposes, those passwords leave a wide open pathway from the outside world into whatever the embedded device is attached to.

Many people use very simple easy to remember passwords such as “123456” or their pet’s name. These are extremely easy to guess. This type of behavior will affect consumer IoT devices going forward and with the enormous number of these devices projected into the future, weak passwords could create great problems if a coordinated attack were launched against a lot of these devices simultaneously.

Weak passwords keep getting weaker. That’s because ordinary desktop computers can now test over a hundred million passwords per second using password cracking tools that run on a general purpose CPU and over 350 billion passwords per second using GPU-based password cracking tools. A user-selected eight-character password with numbers, mixed case, and symbols, reaches an estimated 30-bit strength, according to NIST; 2○30 is only 1 billion permutations and would take an average of 16 min to crack. If a hacker can access the encrypted passwords (Unix used to place them in /etc/password) then they can bypass any schemes that limit the number of failed attempts before a lockout. All they have to do is run a high-speed password cracker and encrypt that and compare the result to the items in the encrypted password file.

Until two-factor authentication becomes ubiquitous and most device’s sole protection is passwords, the best plan of action is to use a password generator (such as SecureSafe) that stores the password in a reliable digital vault that does require two-factor authentication. That vault should have a very strong password that is not stored anywhere. The recommendation for generating solid passwords that have to be remembered is to use a passphrase approach such as a poem you know well where the first letter of each of 12–16 words is remembered and where a few letters are turned into numbers and special characters. For example, You could turn an “l” into a 1, an “o” into a 0, an “a” into a & and separate two phrases with an “=” or “;”.

Now that we have looked at what types of embedded devices have had high profile attacks against them and how those attacks have worked, in the next section we will put into context how bad things could get with certain types of attacks against key embedded devices.

2.17.1 Heartbleed

Heartbleed is a security bug disclosed in Apr. 2014 in the OpenSSL cryptography library, which is a widely used implementation of the transport layer security (TLS) protocol. SSL (secure sockets layer) and TLS are frequently used interchangeably but TLS is the newer version of the protocol. The “s” in https is from SSL and is what displays the padlock symbol in one’s browser and protects transmission of confidential or private data such as social security or credit card numbers. Heartbleed has been shown to have affected 17% of the servers on the Internet and the clients that connect to them. Heartbleed may be exploited regardless of whether the party using a vulnerable OpenSSL instance for TLS is a server or a client. It results from improper input validation (due to a missing bounds check) in the implementation of the TLS heartbeat extension [36] designed to keep sessions in browsers alive and thus the bug’s name derives from “heartbeat.” The vulnerability is classified as a buffer overread, a situation where more data can be read than should be allowed, meaning data can be exfiltrated.

The Heartbeat Extension keeps the session alive by having a computer at one end of a connection to send a “Heartbeat Request” message, consisting of a payload, typically a text string, along with the payload’s length as a 16-bit integer. The receiving computer then must send exactly the same payload back to the sender. The affected versions of OpenSSL allocate a memory buffer for the message to be returned based on the length field in the requesting message, without regard to the actual size of that message’s payload. Because of this failure to do proper bounds checking, the message returned consists of the payload, possibly followed by whatever else happened to be in memory after the allocated buffer.

Heartbleed is exploited by sending a malformed heartbeat request with a small payload and large length field to the vulnerable party (usually a server) in order to elicit the victim’s response, permitting attackers to read up to 64 kilobytes of the victim’s memory that was likely to have been used previously by OpenSSL. Where a Heartbeat Request might ask a party to “send back the four-letter word ‘bird’,” resulting in a response of “bird,” a “Heartbleed Request” (a malicious heartbeat request) of “send back the 500-letter word ‘bird’” would cause the victim to return “bird” followed by whatever 496 characters the victim happened to have in active memory. Attackers in this way could receive sensitive data, compromising the confidentiality of the victim’s communications. Although an attacker has some control over the disclosed memory block’s size, it has no control over its location, and therefore cannot choose what content is revealed.

The problem can be fixed very simply by ignoring Heartbeat Request messages that ask for more data than their payload needs.

Heartbleed is registered in the CVEs system as CVE-2014-0160. A fixed version of OpenSSL was released on Apr. 7, 2014, on the same day Heartbleed was publicly disclosed.

At the time of disclosure, some 66% of the Internet’s secure web servers certified by trusted authorities were believed to be vulnerable to the attack, allowing theft of the servers’ private keys and users’ session cookies and passwords. The Electronic Frontier Foundation, Ars Technica, and Bruce Schneier [37] all deemed the Heartbleed bug “catastrophic.” Forbes cybersecurity columnist Joseph Steinberg wrote, “Some might argue that [Heartbleed] is the worst vulnerability found (at least in terms of its potential impact) since commercial traffic began to flow on the Internet” [38].

Although the bug received more attention due to the threat it represents for servers, TLS clients using affected OpenSSL instances are also vulnerable. Relevant to the embedded device world, a “reverse Heartbleed” has malicious servers exploiting Heartbleed to read data from a vulnerable client’s memory. This shows that Heartbleed is not just a server-side vulnerability but also a client-side vulnerability because the server, or whomever you connect to, is as able to ask you for a heartbeat back as you are to ask them. Those clients are in many cases embedded systems so contrary to many people’s initial assumptions, Heartbleed is not just an issue for Web servers and other purely computer systems. OpenSSL is very popular in client software and somewhat popular in networked appliances which have most inertia in getting updates.

To wit, Cisco Systems has identified 75 of its products as vulnerable, including IP phone systems and telepresence (video conferencing) systems [39]. Games including Steam, Minecraft, Wargaming.net, League of Legends, GOG.com, Origin, Sony Online Entertainment, Humble Bundle, and Path of Exile were affected and subsequently fixed as well [40].

2.17.2 Shellshock

Shellshock, also known as Bashdoor, is a family of security bugs in the widely used Unix Bash shell, the first of which was disclosed on Sep. 24, 2014. Many Internet-facing services, such as some web server deployments, use Bash to process certain requests, allowing an attacker to cause vulnerable versions of Bash to execute arbitrary commands. This can allow an attacker to gain unauthorized access to a computer system [41].

In Unix-based operating systems, and in other operating systems that Bash supports, each running program has its own list of name/value pairs called environment variables. When one program starts another program, it provides an initial list of environment variables for the new program. Separately from these, Bash also maintains an internal list of functions, which are named scripts that can be executed from within the program. Since Bash operates both as a command interpreter and as a command, it is possible to execute Bash from within itself. When this happens, the original instance can export environment variables and function definitions into the new instance. Function definitions are exported by encoding them within the environment variable list as variables whose values begin with parentheses (“()”) followed by a function definition. The new instance of Bash, upon starting, scans its environment variable list for values in this format and converts them back into internal functions. It performs this conversion by creating a fragment of code from the value and executing it, thereby creating the function “on-the-fly,” but affected versions do not verify that the fragment is a valid function definition. Therefore, given the opportunity to execute Bash with a chosen value in its environment variable list, an attacker can execute arbitrary commands or exploit other bugs that may exist in Bash’s command interpreter. Increasingly, embedded systems run Unix variants and some run the bash shell making this dangerous bug relevant to embedded systems.

The discoverer of Shellshock contacted Bash’s maintainer reporting their discovery of the original bug called “Bashdoor.” Together the discoverer and maintainer developed a patch. The bug was assigned the CVE identifier CVE-2014-6271. Once Bash updates with the fix were ready for distribution, it was announced to the public. Within days of the publication of this, intense scrutiny of the underlying design flaws discovered a variety of related vulnerabilities which the developers addressed with a series of further patches.

Attackers exploited Shellshock within hours of the initial disclosure by creating botnets of compromised computers to perform distributed denial-of-service attacks and vulnerability scanning. Security companies recorded millions of attacks and probes related to the bug in the days following the disclosure.

Shellshock could potentially compromise millions of unpatched servers and other systems. Accordingly, it has been compared to the Heartbleed bug in its severity [42].

2.17.3 Blackouts

One of the most critical applications of embedded systems has to be across the broad expanse of the US power grid. However this system is quite old and vulnerable to attack. In Oct. 2012, US defense secretary Leon Panetta warned that the United States was vulnerable to a “cyber Pearl Harbor” that could derail trains, poison water supplies, and cripple power grids. The next month, Chevron confirmed the speculation by becoming the first US Corporation to admit that Stuxnet had spread across its machines.

A doomsday blackout scenario is not far-fetched. Meanwhile, the asset owners across the power grid know that their SCADA controllers are vulnerable but will not move without regulations forcing them too. Their profit margins are thin and no one wants to incur the costs of cyber-motivated upgrades that would cost them dearly while their competitors wait and don’t incur those costs.

Let’s examine the potential impact of a massive blackout by examining the (noncyber-attack instigated) Aug. 2003 Northeast blackout. On that Aug. 14, an electrical disruption caused a loss of electrical service to consumers in New York, Michigan, Ohio, Pennsylvania, New Jersey, Connecticut, Vermont, Massachusetts, and substantial parts of the Canadian province of Ontario. In total, about 50 million US residents lost electrical power. Many also lost water service, and still more found it difficult or impossible to get gasoline for automobiles and trucks. The total impact on US workers, consumers, and taxpayers was a loss of approximately $6.4 billion.

If we extrapolate to a full US blackout that lasts for a week the numbers are staggering. Instead of affecting 50M people it would affect all 319M people in the United States. Assume worst case that it hits on a Monday morning which, if it was intentional, is what would happen, and further assume it lasts a full 7 days before we can recover. That makes the economic impact jump to $185.8B in 2003 dollars. Adjusting to 2015 (assumes 27.6% cumulative rate of inflation) increases that number to $237B in 2015 dollars. Attempting to take a guess at how much the increased dependence on computers and the Internet has on every aspect of the economy, we will assume 3 × what it was in 2003 and the final damage estimate is at least $711B. That represents 4% of 2014’s GDP. To put that in perspective, the worst quarterly drop of the 2009 Great Recession was about 4%, so a blackout of that magnitude would send the country into a tailspin of unprecedented proportions leading perhaps to something much worse than the Great Recession.

What may be most frightening is that the United States could suffer a coast-to-coast blackout if saboteurs knocked out just nine of the country’s 55,000 electric-transmission substations on a scorching summer day, according to a study by the Federal Energy Regulatory Commission, which concluded that coordinated attacks in each of the nation’s three separate electric systems could cause the entire power network to collapse [43]. Frighteningly, the FERC analysis indicates that knocking out nine of those key substations could plunge the country into darkness for weeks, if not months. We know that nation-state adversaries have probed the electric grid and have demonstrated the ability to attack various parts of the system making many believe they could shut down parts or all of it if they were prepared for the consequences of doing so.

About once every 4 days, part of the power grid is struck by a cyber or physical attack. Although the repeated security breaches have never resulted in the type of cascading outage that swept across the Northeast in 2003, they have sharpened concerns about vulnerabilities in the electric system. A widespread outage lasting even a few days could disable devices ranging from ATMs to cellphones to traffic lights, and could threaten lives if heating, air conditioning, and health care systems exhaust their backup power supplies.

3.5.1 μ-Policies enforce security

The programming model for μ-policies involves abstracting the hardware. At the hardware level, as we have shown, there are metadata bits attached to each word. There is a hardware PIPE whose job it is to resolve this metadata.

The programmer should not have to worry about limits such as the number of bits of metadata or the complexity of the rule logic inside the PIPE. The metadata tag will be viewed as a pointer that can point to a data structure of arbitrary size.

A policy therefore is a collection of rules that take the form

$\left(\mathrm{opcode},{\mathrm{P}\mathrm{C}}_{\mathrm{tag}},{\mathrm{INST}}_{\mathrm{tag}},\mathrm{OP}{1}_{\mathrm{tag}},\mathrm{OP}{2}_{\mathrm{tag}},{\mathrm{M}\mathrm{R}}_{\mathrm{tag}}\right)\Rightarrow \left(\mathrm{allow}?,{\mathrm{P}\mathrm{C}}_{\mathrm{tag}},{\mathrm{Result}}_{\mathrm{tag}}\right)$

which we call a transfer function. The abstract function of the PIPE is diagramed here

3.5.2 Memory safety μ-policy

The memory safety policy is designed to enforce spatial and temporal safety. Since in the rankings of the top vulnerability categories of 2014, according to Verizon, memory misuse accounted for 70% of all exploits, this is the first and probably most important one to consider.

This policy will work for both heap-allocated data as well as compiler stack-based allocations. We want this policy to protect against both spatial safety violations (e.g., accessing an array out of its bounds) and temporal safety violations (e.g., referencing through a pointer after the region has been freed). Such violations are a common source of serious security vulnerabilities such as heap-based buffer overflows, confidential data leaks, and exploitable use-after-free, and double-free bugs.

Many μ-policies will require assistance to perform their functions. That assistance is called a monitor service. For memory safety, the monitor services for heap memory are the allocation and freeing routines that are part of the set of operating system services. The allocation and freeing monitor services are parameterized by two functions, malloc() and free(), that are assumed to satisfy certain high-level properties: the malloc monitor service first searches the list of block descriptors for a free block of at least the required size, cuts off the excess if needed, generates a fresh color, initializes the new memory block with each word’s metadata having that color, and returns the address of the start of the block which is a pointer to the newly allocated memory (or buffer). The free monitor service reads the pointer color, deallocates the corresponding block, tags its cells with a special freed tag F, and updates the block descriptors. The F tags prevent any remaining pointers to the deallocated block from being used to access it after deallocation. If a later allocation reuses the same memory, it will be tagged with a different (larger) color, so these dangling pointers will still be unusable.

The method we will use for this μ-policy, shown in Fig. 4, is to give each pointer a unique “color” and then to color each memory slot in the allocated buffer with the same color. When the memory is later freed all slots are re-colored to the uncolored value (i.e., 0). A “color” is just a numeric value equal to 2number-of-bits where number-of-bits is the size of the metadata tag available for this purpose (typically 32 bits which provides over 4 billion unique values).

The transfer function for this μ-policy is

$\left(\mathrm{LOAD},{\mathrm{P}\mathrm{C}}_{\mathrm{tag}},-,\mathrm{R}{1}_{\mathrm{tag}},-,{\mathrm{M}\mathrm{R}}_{\mathrm{tag}}\right)\Rightarrow \left.\left.\left({\mathrm{M}\mathrm{R}}_{\mathrm{tag}}==\mathrm{R}{1}_{\mathrm{tag}}\right)\&\&\left({\mathrm{P}\mathrm{C}}_{\mathrm{tag}}=={\mathrm{INST}}_{\mathrm{tag}}\right)\right),-,-\right)$

which says that the LOAD instruction being executed will be allowed only if the tag on the memory reference (MR, the address in memory that is about to be written) is the same (represented as ) as the tag on the pointer (R1). We additionally require that the PC tag matches the color of the block to which the PC points. This ensures that the PC cannot be used to leak information about inaccessible frames by loading instructions from them.

All other slots in the formula are do-not-cares for this instruction. We do allow adding and subtracting integers from pointers. The result of such pointer arithmetic is a pointer with the same color. The new pointer is not necessarily in bounds, but the rules for LOAD and STORE opcodes will prevent invalid accesses. (Computing an out-of-bounds pointer is not a violation per se, reading or writing through it is and will be handled by the rules for LOAD and STORE.)

This simple μ-policy, in conjunction with support from the operating system malloc() and free(), and from the compiler as it creates stack frames as functions are called, provides very powerful memory safety, which prevents buffer overflows when both reading and writing into memory.

3.5.3 Control flow integrity μ-policy

The memory safety policy just discussed leads people to apply the policy to make code nonwriteable. However, that didn’t stop attackers. They figured out that they could use your own code against you using return-oriented programming (ROP) attacks. These are a relatively new type of attack that has grown in popularity with attackers and is very dangerous. ROP is a computer security exploit technique that allows an attacker to execute code even when memory protection is in place. In this technique, an attacker gains control of the call stack to hijack program control flow and then executes carefully chosen machine instruction sequences, called “gadgets.” Each gadget typically ends in a return instruction and is located in a subroutine within the existing program and/or shared library code. Chaining these gadgets together enables an attacker to perform any computation just with these return sequences. To understand the policy to prevent ROP attacks, it is important to understand that these attacks work by returning into the middle of sequence of code—returns (i.e., control-flow-branches) that did not exist in the original program. Current processors will blindly run the code for the attacker.

The control flow integrity (CFI) policy dynamically enforces that all indirect control flows (computed jumps) adhere to a fixed control flow graph (CFG) most commonly obtained from a compiler. This policy is another interlock that prevents control-flow-hijacking attacks by locking down control transfers to only those intended by the program.

The sample code we will use to illustrate this is shown in Fig. 5. While in function foo(), function bar() is called. The address at which that call occurs is t1. The address where bar() begins is t2. And the address in bar() where it is about to return to its caller is t3. Somewhere else in the program assume bar() is also called from address t42 as well as a few other places. Thus the full list of legal address locations bar() can be called from includes t1, t42, and a few others as shown at the bottom of the figure. As you will see, CFI uses tags to distinguish the memory locations containing instructions and the sources and targets of indirect jumps, while using the PC tag to track execution history (the sources of indirect jumps).

On a call to a the function bar() from the address t1 the μ-policy that governs what happens is described by the following transfer function

$\left(\mathrm{CALL},\mathrm{none},\mathrm{t}1,\mathrm{R}{1}_{\mathrm{tag}},-,-\right)\Rightarrow \left(\mathrm{true},\mathrm{t}1,-\right)$

which declares that the tag from the call instruction (which is t1) must be copied to the tag for the PC as a result of the CALL instruction (that is, the PC which is now at the first instruction for bar() which is t2). The second half of CFI enforcement comes from the following transfer function

$\left(/\mathrm{CALL},\mathrm{t}1,\mathrm{t}2,-,-,-\right)\Rightarrow \left(\mathrm{t}1\mathrm{in}\mathrm{t}2,\mathrm{none},-\right)$

which says whenever the processor is not executing a CALL instruction and the PC is tagged (in this case t1 because we are in a previous CALL that began at t1), check that the tag on the PC is in the list of “legal caller tags” (t2 is in that list) on the current instruction (which must be the target of a call). The PIPE will also untag the PC as shown by the none in the PC tag spot on the right-hand side of the transfer function. These two transfer functions direct the PIPE to strictly enforce the CFG and only allow control transfers to those locations specified in the program thus creating another interlock that thwarts ROP attacks.

3.5.4 Taint tracking μ-policy

Here we will show how a taint tracking policy can be used quite generally to “taint” data such that certain rules can be enforced throughout the system. Taint tracking can enforce rules like “if the data is not public it may not leave the system unencrypted” and “at this critical decision juncture, if the data about to be used is untrusted do not proceed.” Taint tracking can also be used for a safety policy that might be used in a medical device like “if you are about to pump insulin and more than N milligrams have been pumped in 24 h do not pump any, alert the user, and shut down the processor.” The policy, as applied to the ADD instruction, would be represented by the following transfer function

$\left(\mathrm{ADD},{\mathrm{P}\mathrm{C}}_{\mathrm{tag}},{\mathrm{INST}}_{\mathrm{tag}},\mathrm{OP}{1}_{\mathrm{tag}},\mathrm{OP}{2}_{\mathrm{tag}},-\right)\Rightarrow \left(\mathrm{true},\mathrm{P}\mathrm{C},\mathrm{union}\left(\mathrm{P}\mathrm{C},\mathrm{INST},\mathrm{OP}1,\mathrm{OP}2\right)\right)$

where the tag on the Result is formed from the union of the tag on all the operands including the PC, INST, OP1, and OP2.

3.5.5 Composite policies

It is important that for any given metadata tag there not be just one policy that can be enforced. An arbitrary number of policies may be required and this is easily supported by our model by using the tag as a pointer to a tuple of μ-policies. There is no hardware limit on the number of μ-policies supported in this fashion.

To propagate tags efficiently, the processor is augmented with a rule cache that operates in parallel with instruction execution. On a rule cache miss, control is transferred to a trusted miss handler which, given the tags of the instruction’s arguments, decides whether the current operation should be allowed and, if so, computes appropriate tags for its results. It then adds this set of argument and result tags to the rule cache so that when the same situation is encountered in the future, the rule can be applied without slowing down the processor. In performance tests on accurate machine simulators, the overall performance overhead for security enforcement is less than 10%.

A partial list of the types of safety and security policies that can be implemented using the mechanisms just described is listed in the following table.

Returning to the analogy of metadata + PIPE + μ-policies being interlocks, one of their advantages is that policies are small (few 100–1000 lines of code), but they are protecting millions of lines of code. So, while a programmer has no chance of having millions of lines of code be bug free, she does have a chance of making the interlocks be bug free. Just to be certain, since these bits of software are small and highly important, they are amenable to and worth verifying formally.

3.6.1 Metadata protection

In our architecture, data and metadata do not mix. Metadata is not addressable; not by the user-level application, not by the operating system. In the hardware, data paths for data and metadata do not cross. No user-accessible instructions read or write metadata. Metadata is only transformed through the PIPE.

Separation of data and metadata is important for maintaining strong protection of the PIPE and policy mechanisms. Metadata rule misses could be processed on a separate processor. We could store the metadata structures that the metadata tags point to in separate memory. Then this separate metadata processor would only need to access metadata memory and would never access standard data (and vice versa for the standard processing structures). But to avoid a second processor we want to process a miss on the same processor albeit in an isolated subsystem. In this metadata processing subsystem metadata tags become “data,” that is, they are just pointers into metadata memory space.

The mechanism to accomplish this on the RISC-V uses special PIPE control and status registers (CSRs) for rule inputs and outputs. On a PIPE miss trap the PIPE tag inputs are stored in the PIPE CSRs. Now these tags have just become data to the metadata processing subsystem. Here the PIPE CSRs are read and processed. If a result is allowed the tag result is written to the PIPE CSRs which triggers a rule insertion for this PIPE transfer function (same inputs mapped to same outputs) making this a simple lookup next time this rule hits the PIPE.

3.6.2 PIPE protection

We can use the PIPE itself both to implement the symbolic μ-policy and, at the same time, to enforce the restrictions above (which we call monitor self-protection). To achieve this, we use the special Monitor tag to mark all of the monitor’s code and data (remember, malloc() and free() are monitors), allowing the miss handler to detect when untrusted code is trying to tamper with it.

Every instruction causes a rule cache lookup, which results in a fault if no corresponding rule is present (i.e., a miss). Since the machine has no special “privileged mode,” this applies even to monitor code. To ensure that monitor code can do its job, we set up cache ground rules (one for each opcode) saying that the machine can step whenever the PC and INST tags in the input vector of a rule are tagged Monitor; in this case, the next PC and any result of the instruction are also tagged Monitor. Monitor code never changes or overrides these rules.

3.6.3 The Dover processor

Draper Laboratory in Cambridge Massachusetts is an independent not-for-profit research and development laboratory that is developing an inherently secure processor for embedded systems called Dover (short for do-over). In early 2016, the processor achieved its first stage of demonstrability by showing it was immune to the Heartbleed attack and could automatically protect memory from a buffer overflow. The processor will be developed as either an FPGA or an ASIC depending on the requirements of the embedded system it is intended for. As embedded devices adopt an inherently secure processor more and more broadly, infrastructure, the IoT, transportation systems, weapons systems and all other embedded systems will become much more difficult for attackers to overwhelm.