Introduction

The application of modern technologies is essential to the success of military logistics and sustainment. Computing technology makes it possible to evaluate data and execute repeatable processes under specified conditions much faster than humans under the same circumstances. This ability to crunch numbers enables many capabilities, such as consumption prediction, component failure prediction, and automatic supply dispatching. All of this can be (and was) accomplished by human labor, but computers can usually do the work faster and more accurately.

One of the modern approaches to implementing technological solutions is cloud computing. In cloud computing, a Cloud Service Provider (CSP) creates large computing resource pools—in other words, many processors and plenty of storage—and allocates those resources to customers as the customers’ needs increase and decrease. This consolidation of resources yields efficiencies, reduces unnecessary redundancy, and transfers much of the maintenance burden from the customer to the CSP. Modern Department of the Air Force (DAF) systems use the cloud computing model to obtain these benefits. For example, the Standard Base Supply System implemented cloud computing in 2018, saving $21M in the first year alone.[1]

However, the cloud computing model comes with its own set of unique cybersecurity concerns. The first part of this article discusses the history of computing with respect to the implementation of DAF systems, and the second discusses some of the cybersecurity issues that logistics systems users, architects, and cybersecurity professionals should consider when using a cloud-based logistics system.

Evolution of Computing

The Air Force’s computing technology today has evolved like any other technology. What were once massive mainframe computers, like WOPR from WarGames or HAL 9000 from 2001: A Space Odyssey, have become smaller and demand fewer resources. Each Air Force base could have its own computing resources available locally, first in a central location, then in each squadron and flight. Today, many Airmen and Guardians have individually issued computers to manage the numerous systems and processes that generate air and space power. While Airmen and Guardians have computers at their desks, the systems they manage are, for the most part, not.

A ubiquitous example is email. Not too long ago, Airmen would have email addresses that ended in “BaseName.af.mil” (e.g., john.snuffy@osan.af.mil). When Airman Snuffy fired up his computer, Outlook would interact with the base’s email server, which was also physically located at their base. Outlook on Airman Snuffy’s computer would simultaneously update with the latest information from the base’s email server while pushing new information to the server, such as a new calendar event. Although Airman Snuffy needs his computer to interact with the email system, the system is not on his computer.

Today, our email addresses end in us.af.mil and spaceforce.mil without reference to our bases. To the end user, this change is primarily seen in a new user interface and (eventually) a much larger mailbox size. Under the hood, the Air Force migrated to a Microsoft offering where Microsoft took over running email for the entire DAF rather than having airmen at each base running the previously mentioned email servers. Airman Snuffy still uses Outlook on his computer to access his email, but now Outlook is connecting to a central location, not at his base (in this case, wherever Microsoft has set up the DAF email system).

Virtually every logistics system the DAF uses is the same: Airmen and Guardians access the systems from their installations. One reason that DAF system owners use this model is that a key benefit of cloud computing is the ability to network computers together, so Yokota, Diego Garcia, Lakenheath, and Little Rock can all operate on the same data. Another reason is that centralizing the system’s core functions decreases unnecessary redundancy. Rather than having base A needing more resources while base B has excess resources, both can be allocated resources at a central location as needs change. This is somewhat analogous to the distribution of Non Commissioned Officer Academies (NCOAs) compared to Airmen Leadership Schools (ALSs). Most bases have a sufficient number of airmen to justify the presence of an ALS but have far fewer NCOs to warrant a NCOA. As a result, the Air Force has consolidated NCOAs to a much smaller number of bases.

Cloud Computing

This second reason, the reduction of excess resources, leads straight to the cloud computing model. As stated earlier, the general concept of cloud computing is that by consolidating resources in a central pool (in facilities called data centers), users can use (and pay for) only what they need at a specific time. These resources are generally 1: processing power, 2: Random Access Memory (RAM), and 3: storage space. For example, a retailer may need X processors and storage during most of the year but three times that amount on Black Friday. Having all those resources unused throughout the year would be a waste of money. In the cloud computing model, the retailer can instead only have X in use throughout the year and pay for the extra just during the Black Friday weekend. The CSP, meanwhile, can sell the computing resources to other customers throughout the year, reducing resource waste.

CSPs will offer specific amounts of each resource according to their business models and customer needs. In doing so, they abstract some of the technical details of the computer on which the system owners are putting their systems. This abstraction offers additional benefits in system portability and flexibility—a system owner can more easily move their system from one CSP to the next, or quickly expand or shrink their usage of a CSP as the need arises. One could see a parallel in the use of palletized cargo: so long as whatever is strapped onto the pallet fits size- and weight-wise, a C-17, C-130, or any other aircraft capable of taking pallets can take that cargo.

An additional benefit of cloud computing is that it takes the maintenance requirement away from the customer and moves it to the CSP. The customer then does not need to deal with physical and maintenance matters like Heating, Ventilation, and Air Conditioning (HVAC); hardware upgrades and replacements; or physical security. This benefit can vary from customer to customer. For example, a startup company with a handful of employees will greatly benefit from not needing to take valuable time away from directly meeting customer needs. However, a larger, more established company may still find some benefit in keeping computing resources on site, even if additional skillsets, resources, and time are required. This benefit is usually less of a monetary one and more a matter of allowing the organization’s resources to be focused on core functions.

A third key benefit of the cloud computing model with particular relevance to military applications is the option for system-level redundancy. Most CSPs have many data centers in widely separated locations and this distribution of data centers is good for user experience (trying to stream a video located at a data center in the US while being in Australia would be painfully slow). The distributive nature of cloud-computing also makes it possible to mitigate risks such as natural disaster or intentional destruction of resources in one area. If a particular logistics system is already built for a given CSP’s architecture, it is straightforward to deploy it to multiple data centers with designated primary and backup sites.

With all its benefits, cloud computing presents some unique cybersecurity issues. The remainder of this article examines a few of these issues. They are categorized into the five pillars of cybersecurity, as stated in National Security Presidential Directive 54/Homeland Security Presidential Directive 23; these pillars are availability, integrity, confidentiality, authentication, and non-repudiation.[2]

Availability

Data center availability: to run a cloud-based system, one must have the cloud infrastructure. Destruction or complete degradation of the data centers making up the CSP will cause a failure of service. One of the advantages of cloud computing is the portability of services, which mitigates this risk of failure. However, CSPs have created much smaller environments that comply with the various US federal government security requirements.[3] As an example, at time of writing, Amazon Web Services (AWS) has 105 availability zones in total, but the AWS GovCloud offering has only six.[4] The limited number of availability zones means there are fewer options in the event one or more data centers are unavailable—in other words, fewer targets for an adversary.

The worst-case scenario for a data center is that it is physically destroyed. However, while kinetically striking US soil is technically feasible for our near-peer adversaries, non-kinetic attacks on the infrastructure supporting the data center are much more likely. This can happen through:

• Denying/degrading utilities to the data center
• Manipulating the environmental controls of the data center to damage hardware
• Denying/degrading utilities to the networking infrastructure at the first network connection from the data center

CSPs, as a matter of business, mitigate these threats by implementing redundancies in utilities and networking. However, a motivated nation-state actor may be able to identify weak links in those redundancies to achieve large-scale effects. Additionally, some of these redundancies make assumptions about the timely availability of supplies like diesel for backup generators. A sufficiently wide-scale disruption of domestic activities could make these assumptions invalid. To mitigate these risks, system architects should review CSP Service Level Agreements (SLA) to identify what the CSP is committing to, and what actions the system operators may need to take if the CSP cannot meet that SLA. In short: how quickly can a system move when the cloud resources being used are no longer available?

Data center connectivity: A second issue of cloud resource availability is communications links. All US government-specific clouds identified are located in the continental US. In peacetime, connection quality to and from overseas locations is high enough to satisfy system needs. In wartime, those communications links will be high-priority targets. Attack vectors include severing undersea cables, jamming terrestrial and space-based communications, and compromising commercial network infrastructure on which the links ride. In particular, for commercial infrastructure, if some links go down, networking systems will attempt to identify alternate routes. It is possible that, given a sophisticated and large enough initial takedown effort, as traffic is rerouted, the new routes will be overloaded, leading to further rerouting, and the whole network ultimately will become seriously degraded.

The risk to a system in this environment is that connectivity to data centers may take much longer than normal, or they may not exist at all. This risk is also present in an older mainframe system implementation, but it’s important to remember that merely moving to “the cloud” does not inherently eliminate latency risk. In particular, because the cloud computing model abstracts some of the connectivity details, it can be easier to miss identifying specific critical assets. In short: how resilient is the system to delayed communications?

Integrity

Cybersecurity responsibility: By operating “as a service,” CSPs recognize they have an ongoing responsibility for cybersecurity measures, which is shared with the end user. The concept is called the “shared responsibility model,” where responsibility for particular aspects of cybersecurity is split between the CSP and system owner depending on the particular type of service offered (e.g., Infrastructure as a Service [IaaS], Platform as a Service [PaaS], or Software as a Service [SaaS]). The United Kingdom’s National Cyber Security Center has a useful chart, including a comparison to an on-premises setup:

Figure 1: CSP versus customer security responsibilities[5]

For example, CSPs assume responsibility for heating/cooling and fire protection, while the end user is responsible for integrating good user authentication into the application. The risk comes at the boundary between CSP and end user. Poor understanding of the breakdown of responsibility can lead to a gap an adversary can exploit; for example, a misunderstanding of who is logging what data could lead to unmonitored activity, allowing an adversary to compromise the system undetected. System architects should review the CSP’s System Security Plan (SSP), specifically the control implementation summary and customer responsibility matrix contained therein, to confirm that the system implements all expected cybersecurity controls. In short: are there any gaps between the CSP’s cybersecurity controls and the system’s?

Supply chain risks: CSPs assume responsibility for supply chain management of their products, including supply chains for hardware and software. On the hardware front, a US hardware manufacturer (with actual manufacturing outside the US) allegedly found a compromised network connector in a data center; the specific modification could only have been manipulated at time of manufacture.[6] This compromised component could have exfiltrated data and/or degraded or modified communications under particular conditions. On the software front, a best practice is to use common libraries to save time and reduce mistakes, including inside Operating Systems (OS). This practice almost led to a backdoor being made standard in very common Linux variants, which are frequently used in cloud computing environments.[7] Attacks against hardware and software can, at worst, result in the system and data being completely compromised and the attacker able to act at will inside the system.

CSPs are well aware of these concerns and work to mitigate them. End users are not in a position to do anything about the risk directly; the best option is to rely on DoD approval of CSP offerings, which occurs after the evaluation of security assessment packages. In short: has the CSP’s offering been approved for use by the DoD at the level the system needs?

Attacks from other cloud users: one of the fundamental premises of cloud computing is that resources are shared with other parties—this allows more efficient allocation of resources. It follows that one of the fundamental risks of cloud computing is that resources are shared with other parties. Thus, one’s security can be dependent on another customer’s correct implementation of security controls. For example, a poor password policy on a particular CSP customer’s system or a piece of software with a zero-day vulnerability could let an attacker gain full access to that customer’s system.

CSPs use various technologies, like hypervisors, to keep customers isolated from one another precisely for situations like this. Unfortunately, vulnerabilities have been found in these tools.[8] Fortunately, exploiting these vulnerabilities is difficult even for nation-states; at the time of writing, there are no publicly disclosed cases where an attacker compromised a system running in the cloud by gaining access to the system’s infrastructure.

Again, end users are not in a position to directly control these risks—one cannot force another CSP customer to do anything directly, even if one knows who that customer is. The best option is to rely on DoD evaluation of CSP practices.

However, system architects can design systems that are decomposed into a set of smaller, independent cloud services. This decomposition, in turn, increases the number of targets an adversary must compromise to access data or modify system behavior (to say nothing of potential advantages in system maintainability and extendibility). In short: does the system’s design mean that a compromise of one component directly results in access to another?

Data consistency: Critical systems can use hot or warm alternate locations to rapidly recover from a system breakdown, which includes database problems. If the system is not architected appropriately, an adversary can induce data inconsistencies between the primary and backups by selectively degrading or denying communications links from edge devices to the databases or between the databases and the system management system without having immediate access to the systems or data. Risks such as these are not cloud-unique, but the abstraction of cloud services and their locations may result in the oversight of anomalous system behaviors. In short: how can the system’s behavior be manipulated if the attacker controls network traffic, even without immediate access to the system?

Confidentiality

Cloud resource misconfiguration: cloud systems are tools with their own particular ways of doing things. Between terminology differences among CSPs, and the previously mentioned potential for gaps in CSP and end-user security responsibilities, cloud system configuration is a well-known attack vector; for example, the National Geospatial-Intelligence Agency (NGA) experienced a compromise via this attack method in 2017.[9] End users should implement in-depth defenses and ensure their operations team is well-trained on the CSPs to mitigate the threat of misconfiguration. In short: are all the system’s windows and doors locked, including the front door?

Authentication system configuration: as mentioned in the previous item, even if public access is blocked, cloud-based identity management systems can lead to excessively broad permissions. These broad permissions can present issues at the system user level (e.g., SSgt Snuffy in the 987 LRS) and the system management level (e.g., Ms. Doe in the program management office). For instance, complexity arises as the authentication source of truth (e.g., the DAF Active Directory File System (ADFS) single sign-on integration, which provides user data from the DAF’s records) is integrated with systems in development. Specific roles and their assigned functions must be carefully designed so that users can access only those things they need. Even if those roles and functions are well-defined, misconfiguration of the authentication system and its integration into the overall system could result in users having broader access than intended. In short: are data and functions properly labeled with the most appropriate roles?

Authentication and Non-repudiation

Authentication system choice: a system can include its own authentication system—for example, it may implement its own usernames and passwords, along with functions like password resetting. However, this can increase the system’s attack surface because now it depends on every user practicing good password hygiene. Poor authentication practices generally lead to the unattributable compromise of system confidentiality and integrity. A better practice is to rely on enterprise authentication systems for two reasons. First, an enterprise authentication system like the DAF ADFS mentioned above reduces the number of independent accounts users must remember and manage. Second, an enterprise authentication system is better positioned to manage user authentication practices centrally, like requiring a standard 2-factor authentication practice, in a way that a set of independent systems would struggle to implement consistently and effectively. In short: does the system offload as much responsibility for user authentication as possible?

Closing

The benefits of the cloud computing model usually outweigh the costs for DAF logistics and sustainment capability needs, even when factoring in the cybersecurity concerns addressed above. System architects should, as always, consider the specific requirements of their system’s capabilities, and ensure they implement measures that meet these requirements while addressing these issues.

References

[1] Ellis, T. L., Nicholson, R. A., Briggs, A. Y., Hunter, S. A., Harbison, J. E., Saladna, P. S., Garris, M. W., Ohnemus, R. K., O’Connor, J. E., & Reynolds, S. B. (2018). Lifting and shifting the Air Force retail supply system. Journal of Defense Analytics and Logistics, 1(2), 172–184. https://doi.org/10.1108/JDAL-08-2017-0016.

[2] National Security Presidential Directive 54/Homeland Security Presidential Directive 23: Cybersecurity Policy. (2008, January 8). US Government. https://irp.fas.org/offdocs/nspd/nspd-54.pdf.

[3] The cloud, after all, is just someone else’s computer. See the webcomic xkcd at https://xkcd.com/908; see https://explainxkcd.com/908 for an explanation. Some sources of these requirements are FedRAMP, DOJ Criminal Justice Information Systems Security Policy, International Traffic in Arms Regulations, Export Administration Regulations, DoD Cloud Computing Security Requirements Guide, and FIPS 140-2. See AWS GovCloud (US)—Amazon Web Services. (n.d.). Amazon Web Services, Inc. Retrieved July 2, 2024, from https://aws.amazon.com/govcloud-us/.

[4] An AWS availability zone has “one or more data centers with redundant power, networking, and connectivity in an AWS region”. See Global Infrastructure Regions & AZs. (n.d.). About AWS. Retrieved July 2, 2024, from https://aws.amazon.com/about-aws/global-infrastructure/regions_az.

[5] Cloud security shared responsibility model. (2018, November 17). National Cyber Security Centre. https://www.ncsc.gov.uk/collection/cloud/understanding-cloud-services/cloud-security-shared-responsibility-model.

[6] Robertson, J., & Riley, M. (2018, October 19). New Evidence of Hacked Supermicro Hardware Found in U.S. Telecom—Bloomberg. Bloomberg. https://www.bloomberg.com/news/articles/2018-10-09/new-evidence-of-hacked-supermicro-hardware-found-in-u-s-telecom.

[7] Goodin, D. (2024, April 1). What we know about the xz Utils backdoor that almost infected the world | Ars Technica. Ars Technica. https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/.

[8] For example, see CVE-2021-28476, targeting Microsoft’s Hyper-V hypervisor.

[9] Fazzini, K. (2017, June 13). A Technical Slip-up Exposes Cloud Collaboration Risks—WSJ. Wall Street Journal Pro. https://www.wsj.com/articles/a-technical-slip-up-exposes-cloud-collaboration-risks-1497353313.

The views expressed in this article are those of the author(s) and do not necessarily reflect the official policy or position of the Air Force, the Department of Defense, or the US Government.