Security at Different Layers of Abstractions: Application, Operating Systems, and Hardware
In the field of computer security, it is important to take a threat-centric view of the world to understand who the malicious actors are, what they want, and how they achieve their goals. Computer systems are then evaluated in light of the perceived threats to understand the best defensive measures.
THREATS ACROSS COMPUTATIONAL ABSTRACTIONS
Researchers have extensively studied adversaries over the past two decades, and events in the news such as the Snowden revelations (Greenwald 2014) and attacks by the Equation Group (Kaspersky Lab 2015) have revealed much about threats posed by the most advanced adversaries.
Threat actors typically use the easiest path to achieve their goals. In some cases this involves manipulating an individual, a practice known as social engineering. Alternatively, on the technical side, a threat actor may choose to attack the victim’s hardware, operating system, or applications. Each option has tradeoffs covering a broad spectrum of sophistication, cost, likelihood of detection, feasibility, and more.
Application-level attacks are often the easiest target for attackers because they cover a broad space across servers, desktops, laptops, and mobile devices. Phishing attacks (Garera et al. 2007) convince a victim to visit a malicious web page that exploits a vulnerability in the user’s web browser or email software. The Heartbleed bug (http://heartbleed.com), a recent attack on the OpenSSL cryptographic software that mostly affected web servers, resulted in the disclosure of private information.
Operating system (OS) attacks can be more difficult to execute because modern operating systems have reasonably good default security practices. Even so, they remain an attractive target for attackers because software running at the operating system’s access level can view data from anything on the system, including all applications, files, and memory state. Typically these attacks install rootkits, malicious software designed to provide OS-level access for an attacker while hiding from the system’s users and applications. Because it can be difficult to compromise operating systems remotely, rootkits are usually installed after a successful application-level attack or by compromising the supply chain.
Hardware attacks are the most advanced. They may involve hardware replacement with a malicious version that appears the same to users but allows an attacker to access the system, or a firmware attack that can change programmable portions of hardware to the attacker’s benefit. Physical hardware replacement requires a supply chain attack or an onsite operative. Malicious firmware, however, can be installed from a rootkit to improve stealth and retain access across fresh installations of operating systems.
PLENTIFUL TARGETS
Upon hearing “hardware, operating systems, and applications,” many people constrain their thinking to the obvious computers in their lives, such as their laptop and smartphone. But computers are everywhere.
Computers called switches and routers manage network traffic on the Internet and mobile phone networks. Computers are in automobiles (Miller and Valasek 2015), medical devices (FDA 2015), smart watches, TVs, refrigerators—even some light bulbs (McMillan 2014). Each of these represents an attack option for malicious actors, whether as a useful target by itself or as a stepping stone to help attackers reach their ultimate goal(s).
The challenge for security professionals is to understand the broad scope of threats while building systems that provide meaningful security. For example, if one is concerned about network traffic monitoring on the Internet, then a reasonable countermeasure is to encrypt that traffic. Similarly, if one is worried about attackers using guessed or stolen passwords to access an online service, then a reasonable countermeasure is to use two-factor authentication (e.g., a code is sent to the user’s phone and must be provided along with the password for access). But when everything is interconnected and the threat landscape is enormous, it is not always obvious what protections are most important to implement.
In addition to rich interconnections, modern computing systems from companies such as Facebook, Google, and Netflix operate at an extremely large scale, with some managing millions of computers (Ballmer 2013). Such a scale shifts the security challenges considerably. Securing each piece of hardware and each operating system requires dedicated teams that must work closely to ensure that security problems do not arise on the boundaries. Even finding the application
data that require protection can be challenging. In addition, retrofitting security to an existing large ecosystem requires that the security not disrupt reliability or performance.
CASE STUDY: PROTECTING NETWORK TRAFFIC IN THE CLOUD
When using a web browser, most people know to look for a lock icon indicating a secure connection before making a credit card transaction or other sensitive operation. This security is enabled by a network protocol called transport layer security (TLS). It works because there is a preestablished trust relationship between the individual computer and a third party that has verified the authenticity of the visited website.
In addition to protecting the network traffic between a browser and a website, TLS is often used to protect the internal network traffic of a cloud or data center that supports the website’s operation. In these cases the technology is the same but the deployment strategies are different to reflect both the scale and the threats across many abstraction layers. The use of TLS in a cloud or data center mitigates threats both from malicious network switches “eavesdropping on” or altering network traffic and from the software virtualization layers used to enable cloud computing.
But deploying TLS at scale for a cloud application presents many challenges. Principal among these is the need to create trust relationships—like those used to make credit card transactions with a web browser—that are reliable and maintainable. This kind of trust relationship is based on a public key infrastructure (PKI), which comprises the hardware, software, and policies that manage the encryption that ensures security. Unfortunately, in practice, it can be very difficult to deploy and maintain a PKI; for example, critical security credentials may sometimes be lost or compromised. Traditionally this problem has been addressed using revocation lists, but these lists are difficult to maintain and do not scale well.
The use of short-lived credentials (Topalovic et al. 2012) in lieu of revocation lists has been growing in popularity. This approach can increase software complexity through the automation required to create and deploy the updated credentials (Clark 2014), raising the bar for an attacker and resulting in a more maintainable PKI.
The establishment of PKI and use of TLS to protect network traffic mitigate certain classes of attacks, as described above, but if malicious actors can access other levels in the computing ecosystem they can compromise the very data that TLS is designed to protect.
Security practitioners must estimate whether a particular threat actor is sufficiently capable and motivated to break the assumptions and compromise the system. This is why security is often considered to be both an art and a science.
CHALLENGES AND FUTURE DIRECTIONS
In practice, hardware-level security is a domain that only nation-state actors can afford to engage in both offensively and defensively. In general, the best strategy is to assume that the hardware is secure and leverage some of its security features. Building from this foundation, there are many opportunities to improve security at the OS and application layers.
Services that operate in the cloud today generally need to take a leap of faith and assume that the underlying infrastructure is secure. Often this is a very reasonable assumption because the major cloud providers have thus far demonstrated that they are better at infrastructure security than all but the largest data center operators. However, rather than merely trusting, it would be much safer to “trust and then verify” that cloud providers are in fact secure.
Another major challenge in security is simply that it is too difficult to achieve. Security design, including cryptographic engineering and designing to mitigate the impact of malicious adversaries, requires expertise that the average developer cannot possibly be expected to have. Complexity must be reduced at all levels, by reducing software engineering complexity, making security more science and less art, and providing secure building blocks for creating complex software.
These technical challenges are huge and critically important. The only way to solve them is with many talented computer security professionals. Unfortunately, the community has a massive talent shortage. As with the other challenges above, solving this will require close partnerships between academia and industry.
REFERENCES
Ballmer S. 2013. Keynote speech. Microsoft Worldwide Partner Conference, Houston, July 8. Available at http://news.microsoft.com/2013/07/08/steve-ballmer-worldwide-partner-conference-2013-keynote/.
Clark R. 2014. SSL everywhere with ephemeral PKI. OpenStack Summit, Paris, November 3–7. Available at https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/ssl-everywhere-with-ephemeral-pki.
FDA [US Food and Drug Administration]. 2015. Symbiq Infusion System by Hospira: FDA Safety Communication – Cybersecurity Vulnerabilities. Safety Alert for Human Medical Products, July 31. Silver Spring, MD. Available at http://www.fda.gov/Safety/MedWatch/SafetyInformation/SafetyAlertsforHumanMedicalProducts/ucm456832.htm.
Garera S, Provos N, Chew M, Rubin AV. 2007. A framework for detection and measurement of phishing attacks. Proceedings of the ACM Workshop on Recurring Malcode (WORM), Alexandria, VA, October 29–November 2.
Greenwald G. 2014. No Place to Hide: Edward Snowden, the NSA, and the US Surveillance State. New York: Metropolitan Books.
Kaspersky Lab. 2015. Equation Group: Questions and Answers (Version 1.5). February. Moscow. Available at https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf.
McMillan P. 2014. Attacking the Internet of Things using time. DEF CON 22, Las Vegas, August 7–10. Available at https://www.youtube.com/watch?v=uzGXxWuDwxc.
Miller C, Valasek C. 2015. Remote exploitation of an unaltered passenger vehicle. Black Hat USA. August. Available at http://illmatics.com/Remote%20Car%20Hacking.pdf.
Topalovic E, Saeta B, Huang L-S, Jackson C, Boneh D. 2012. Towards short-lived certificates. Proceedings of the Web 2.0 Security & Privacy Workshop (W2SP), San Francisco, May 24. Available at http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf.
This page intentionally left blank.
