Data and Applications Security Developments and Directions

Data and Applications Security Developments and Directions Dr. Bhavani Thuraisingham The University of Texas at Dallas Building Trusted Applications on Untrusted Platforms for Mission Assurance

Outline • Mission Assurance • Our Approach • Acknowledgement • References

Mission Assurance • Mission Assurance includes the disciplined application of system engineering, risk management, quality, and management principles to achieve success of a design, development, testing, deployment, and operations process. Mission Assurance's ideal is achieving 100% customer success every time. Mission Assurance reaches across the enterprise, supply base, business partners, and customer base to enable customer success. • The ultimate goal of Mission Assurance is to create a state of resilience that supports the continuation of an agency's critical business processes and protects its employees, assets, services, and functions. Mission Assurance addresses risks in a uniform and systematic manner across the entire enterprise. • Mission Assurance is an emerging cross-functional discipline that demands its contributors (project management, governance, system architecture, design, development, integration, testing, and operations) provide and guarantee their combined performance in use.

Mission Assurance • The United States Department of Defense 8500-series of policies has three defined mission assurance categories that form the basis for availability and integrity requirements. A Mission Assurance Category (MAC) is assigned to all DoD systems. It reflects the importance of an information system for the successful completion of a DoD mission. It also determines the requirements for availability and integrity. • MAC I systems handle information vital to the operational readiness or effectiveness of deployed or contingency forces. Because the loss of MAC I data would cause severe damage to the successful completion of a DoD mission, MAC I systems must maintain the highest levels of both integrity and availability and use the most rigorous measure of protection.

Mission Assurance • MAC II systems handle information important to the support of deployed and contingency forces. The loss of MAC II systems could have a significant negative impact on the success of the mission or operational readiness. The loss of integrity of MAC II data is unacceptable; therefore MAC II systems must maintain the highest level of integrity. The loss of availability of MAC II data can be tolerated only for a short period of time, so MAC II systems must maintain a medium level of availability. MAC II systems require protective measures above industry best practices to ensure adequate integrity and availability of data. • MAC III systems handle information that is necessary for day-to-day operations, but not directly related to the support of deployed or contingency forces. The loss of MAC III data would not have an immediate impact on the effectiveness of a mission or operational readiness. Since the loss of MAC III data would not have a significant impact on mission effectiveness or operational readiness in the short term, MAC III systems are required to maintain basic levels of integrity and availability. MAC III systems must be protected by measures considered as industry best practices.

Problem • The Office of the Deputy Assistant Secretary of Defense (Information and Identity Assurance) has stated that “the Department of Defense's (DoD) policy, planning, and war fighting capabilities are heavily dependent on the information technology foundation provided by the Global Information Grid (GIG) • However, the GIG was built for business efficiency instead of mission assurance against sophisticated adversaries who have demonstrated intent and proven their ability to use cyberspace as a tool for espionage and criminal theft of data. GIG mission assurance works to ensure the DoD is able to accomplish its critical missions when networks, services, or information are unavailable, degraded, or distrusted.”

Problem • To meet the needs of mission assurance challenges, President’s cyber plan (CNCI) has listed the area of developing multi-pronged approaches to supply chain risk management as one of the priorities. CNCI states that the reality of global supply chains presents significant challenges in thwarting counterfeit, or maliciously designed hardware and software products. • To overcome such challenges and support successful mission assurance we need to design flexible and secure systems whose components may be untrusted or faulty. Our objective is to achieve the secure operation of mission critical systems constructed from untrusted, semi-trusted and fully trusted components for successful mission assurance.

Problem • In order to fight the global war on terror the DoD, federal agencies, coalition partners and first responders, among others have to use systems whose components may be attacked and untrustworthy. These components may include operating systems, database systems, application, networks and middleware. Yet in doing so, one must ensure mission assurance in that the system has to detect such attacks and be flexible so that it can provide overall security for the missions. • Furthermore, it is stated “the Defense Science Board task force assessed the Department of Defense’s (DoD) dependence on software of foreign origin and the risks involved. The task force considered issues with supply chain management; techniques and tools to mitigate adversarial threats; software assurance within current DoD programs; and assurance standards within industry, academia, and government.” • One major challenge is to provide mission assurance by developing flexible designs of secure systems whose components may be untrustworthy or faulty.

DoD Mission Assurance Policy • To ensure mission assurance in the presence of untrusted components and systems, DoD’s policy consists of the following: • “(i) To provide uncompromised and secure military systems to the warfighter by performing comprehensive protection of Critical Physical Infrastructure (CPI) through the integrated and synchronized application of Counter-intelligence, Intelligence, Security, systems engineering, and other defensive countermeasures to mitigate risk, and • (ii) To minimize the chance that the Department’s warfighting capability will be impaired due to the compromise of elements or components being integrated into DoD systems by foreign intelligence, foreign terrorists, or hostile elements through the supply chain or system design.” • Our goal is to provide solutions that would implement the above policy of the DoD.

Motivation • Various Air Force mission critical systems, including DCGS (Distributed Common Ground Systems), AWACS (Air Borne Warning and Control System) and Layered Sensing - a major research initiative at AFRL investigating techniques for total situation awareness will benefit from the solutions we will provide. Consider the AWACS system that may operate in a hostile environment. • In our experimental research for next generation AWACS for AFRL we designed an infrastructure, operating system, data manager and multi-sensor integration (MSI) application using commercial off-the-shelf technologies. Track data captured from sensors are intergraded and fused by the MSI module and stored and managed by the data manager. The middleware and operating systems provide services such as interprocess communication and memory management to support the data manager and MSI application. • The sensors may be attacked in a hostile environment. The COTS products for the middleware, operating system and data manager could be corrupted. The application subsystem may be attacked. Failure of any of the components could crash the entire system with disastrous and possibly fatal consequences. Therefore it is important for the system to operate even in the midst of component failures and attacks.

Principles • Addressing the challenges of protecting applications and data when the underlying platforms cannot be fully trusted dictates a comprehensive defense strategy. Such a strategy requires the ability to address new threats that are smaller and more agile and may arise from the components of the computing platforms. • Consequently, the Observe, Orient, Decide and Act (OODA) loop] on which conventional defense approaches are based needs to be expanded to anticipate threats. Our strategy, based on the three tenets shown in Figure 1, recognizes and addresses such a need. We emphasize that the adversaries can be components of the underlying platforms, in addition to the usual external adversaries.

Principles • The Three Tenets of our Approach • Move out of band and Confuse the Adversary Make what is critical and associated security elements less accessible to the adversary • Make it more difficult for the adversary to determine the target • Detect, React, Adapt Be ready to move mission critical tasks to uncompromised components within the same system or to other systems • Focus on what is critical • Reduce scope of what to protect • Minimize number of security elements

Principles Based on these tenets, we have identified a preliminary set of technical principles that applied in combination guide the development of secure environments for applications and data. The first technical principle, which we refer to as Increase Trust by Limiting and Isolating Functionality (abbreviated as Isolation Principle), directly follows from the first two tenets. This somewhat counter-intuitive claim of “less is more” is also based on well established security principles, such as the Principles of Least Privilege and Economy of Mechanism.

Principles • The second technical principle, which we refer to as Adaptive Multiple Independent Layers of Security (abbreviated as Independence Principle), applies the Isolation Principle both statically and dynamically by dividing the system software into several layers. These layers as well as the layering organization should be amenable to dynamic changes of the various system components. The Independence Principle directly follows from the third tenet. • The third technical principle, which we refer to as Artificial and Natural Diversity (abbreviated as Diversity Principle), directly follows from the second tenet. An example of artificial diversity approach is represented by compiler tools that generate obfuscated code (e.g., SharpToolbox.com lists 26 obfuscator tools). By natural diversity we mean the independently developed software systems that have similar functionality (e.g., Windows and Linux at OS level). To maximize diversity in system software, we apply the Diversity Principle to both implementation (mainly artificial diversity) and design (mainly natural diversity) of systems.

Architecture • Our overall architectural strategy is based on our technical principles. Our strategy addresses protection at various levels within a same system from the application layer down to the OS, Virtual Machine Monitor (VMM), and hardware. It is our contention that single-layer solutions typically improve one layer by pushing performance and security limitations to other layers, with questionable overall results. Key aspects of our strategy are the following: • Layered ATI Architecture. Conceptually, we organize the (untrusted) system software into layers, and for each layer, we propose the separation of a small, verifiable abstract trusted interface (ATI) from the functionality-rich remaining untrusted software components at that layer. This multi-layer separation can be seen as a generalization of the MILS (multiple independent levels of security) model, where the implementation of the ATI at each layer is analogous to the single-layer MILS separation kernel. We prefix a layer’s ATI with a two-letter acronym: HW-ATI for the hardware layer, VM-ATI for the virtual machine and hypervisor layer, OS-ATI for the operating system layer, MW-ATI for the middleware layer, DB-ATI for the database management system layer, and AP-ATI if an application is exporting a trusted application programmer interface. This is an application of the Isolation and Independence Principles. • Natural and Artificial Diversity. The ATI architecture does not mandate a uniquely defined ATI at each layer. There may be multiple, overlapping ATIs at any layer. Furthermore, concrete diverse implementations may exist for the same or different ATIs (e.g., Intel TXT and AMD SVM at the hardware layer). One of the main design goals of the ATI Architecture is the active incorporation of diverse designs and implementations at each layer. For diverse implementations, we will use artificial diversity tools (e.g., compiler tools for creating different program representations as discussed in [31]). For diverse designs, we will rely on natural diversity of different system components (e.g., variants of Unix and possibly Windows at the OS layer). This natural diversity offers protection beyond the implementation-level protection of artificial diversity tools. • Figure 2 The Abstract Trusted Interface (ATI) Architecture • HW-ATI (Intel TXT, AMD SVM, secure co-processors) • HW-Untrusted • VM-ATI (Xen, VMware) • VMM-Untrusted • OS-ATI (seL4 microkernel) • OS-Untrusted • MW-ATI (secure comm.) • Middleware-Unt1 • DB-ATI (co-DBMS) • DBMS-Untrusted • AP-ATI • Application-Untrusted • Composition of ATIs. The main constraint of the implementation of an ATI is that it may only use the facilities provided by ATIs of lower layers. This is indicated by the downward arrows on the right side of Figure 2. The advantage of this restriction is that by utilizing only trusted components, the implementation of ATI of higher layers remains trusted. The requirement is that the ATIs at each layer must have specific functionality, such that the resulting ATI implementation can be formally verified. This follows from the Isolation Principle. The ATI architecture is flexible and dynamically reconfigurable. As new software or hardware components are verified to be secure at each layer, that layer’s ATI may be expanded by incorporating the new components. Conversely, if a new vulnerability is discovered in some implementation of ATIs, the affected components (and higher level components that use this implementation) should be excluded from the trusted side. Until the problem is fixed, the system falls back to reduced ATI functionality that remains trusted. In real-time computing, when a precise computation is under the risk of missing a deadline, alternative modules implemented with reduced computational precision in an approach called Imprecise Computation [18] can still complete a simplified task within the time constraint. Analogously, we will explore alternative designs that use different underlying ATIs for a given critical functionality (perhaps more limited than the original one). When a full-functionality application is affected by attacks or newly discovered vulnerabilities, these alternative design and implementations based on different ATIs provide secure critical

Architecture • Natural and Artificial Diversity. The ATI architecture does not mandate a uniquely defined ATI at each layer. There may be multiple, overlapping ATIs at any layer. Furthermore, concrete diverse implementations may exist for the same or different ATIs (e.g., Intel TXT and AMD SVM at the hardware layer). One of the main design goals of the ATI Architecture is the active incorporation of diverse designs and implementations at each layer. For diverse implementations, we will use artificial diversity tools (e.g., compiler tools for creating different program representations as discussed in • For diverse designs, we will rely on natural diversity of different system components (e.g., variants of Unix and possibly Windows at the OS layer). This natural diversity offers protection beyond the implementation-level protection of artificial diversity tools.

Architecture • The Abstract Trusted Interface (ATI) Architecture • HW-ATI (Intel TXT, AMD SVM, secure co-processors) • HW-Untrusted • VM-ATI (Xen, VMware) • VMM-Untrusted • OS-ATI (seL4 microkernel) • OS-Untrusted • MW-ATI (secure comm.) • Middleware-Unt1 • DB-ATI (co-DBMS) • DBMS-Untrusted • AP-ATI • Application-Untrusted

Architecture • Composition of ATIs. The main constraint of the implementation of an ATI is that it may only use the facilities provided by ATIs of lower layers. • The advantage of this restriction is that by utilizing only trusted components, the implementation of ATI of higher layers remains trusted. The requirement is that the ATIs at each layer must have specific functionality, such that the resulting ATI implementation can be formally verified. • This follows from the Isolation Principle. The ATI architecture is flexible and dynamically reconfigurable. As new software or hardware components are verified to be secure at each layer, that layer’s ATI may be expanded by incorporating the new components. Conversely, if a new vulnerability is discovered in some implementation of ATIs, the affected components (and higher level components that use this implementation) should be excluded from the trusted side. Until the problem is fixed, the system falls back to reduced ATI functionality that remains trusted.

Architecture • In real-time computing, when a precise computation is under the risk of missing a deadline, alternative modules implemented with reduced computational precision in an approach called Imprecise Computation can still complete a simplified task within the time constraint. Analogously, we will explore alternative designs that use different underlying ATIs for a given critical functionality (perhaps more limited than the original one). When a full-functionality application is affected by attacks or newly discovered vulnerabilities, these alternative design and implementations based on different ATIs provide secure critical

Threat Model • Threats from hardware. Once hardware is compromised, many properties can be compromised. For example, if an adversary has access to the system bus or CPU chip connectors, then any application code and critical data (e.g., cryptographic keys) can be compromised. Although the introduction of trusted platform modules (TPM) alleviates the problem to some extent, we must bear in mind that TPM were designed to deal with software attacks, rather than hardware attacks. • Therefore, trustworthiness of hardware may be deemed as the last line of defense. Nevertheless, novel hardware architectures could better support secure computing from the perspectives of security, performance, and usability. For certain hardware devices such as expensive co-processors, we may assume they are tamper-resistant or even tamper-proof; for low-end hardware devices we may only assume they are fail-stop.

Threat Model • Threats from the hypervisor. If the hypervisor is compromised, then the guest OS or even the applications and data can be compromised. It would be desirable that only a tiny portion of hypervisor or microkernel is to be trusted. • Threats from the OS. There are a spectrum of threats that can be launched at the OS level to attack application and data: • Attacks exploiting OS vulnerabilities: For example, an attacker could gain access to a memory region from which critical secrets and passwords may be extracted. • Attacks exploiting backdoors in the OS to passively tap system states: such attacks can be launched by the developer of some components of the OS (e.g., a third-party device driver).

Threat Model • Corrupted OS: Threats could originate from attacks to services provided by the OS such as: • Attacks against the file system: The attacker can read, tamper with application binaries, or replace an application with code that simply prints out its sensitive data. S/he might also launch a replay attack by reverting a file to an earlier version, e.g., replacing a patched application with an earlier version that contains a buffer overflow. • Attacks against inter process communication: Although the OS may not interfere with program execution, it might be able to do so when a new process is started. For example, when a process forks, it might initialize the child’s memory with malicious code instead of the parent’s, or set the starting instruction pointer to a different location. Signal delivery also presents an opportunity for a malicious OS to interfere with program control flow, since the standard implementation involves the OS redirecting a program’s execution to a signal handler.

Threat Model • Attacks against memory management: The attacker may deliberately manipulate memory management so as to cause frequent context switches that may be exploited to launch side-channel attacks against cryptographic algorithms (for extracting cryptographic keys). • Attacks against the clock: A malicious OS could speed up or slow down the system clock, which could allow it to subvert expiration mechanisms that use clocks. • Attacks against randomness: A malicious OS can manipulate the randomness that is often demanded by cryptographic applications. • Attacks against I/O and trusted path: An application’s input and output paths to the external environment go through the OS, including display output and user input. The OS can observe traffic across these channels, capturing sensitive data as it is displayed on the screen, or as the user types it in (e.g., passwords). It could also send fake user input to a protected application, or display malicious output, such as a fake password entry windows.

Threat Model • Threats from the middleware. Trusted communications is a fundamental assumption in distributed applications. For example, if messages arrive corrupted or subtly altered, the application would be unable to provide the correct answer or take the right action. Also, if the attacker can prevent some key players from receiving certain data, the decision-making process can be undermined. • Threats from DBMS. Since data are often managed through DBMS, a malicious DBMS could undermine data integrity, confidentiality, and availability. Because a DBMS is often a large and complex software system, the security assurance of DBMS itself is questionable.

Trusted Architecture Components • Step 1: Evaluation of several design alternatives towards the definition of an abstract HW-ATI as the interface to HW-LSK. The goal of the abstract HW-ATI is to accommodate the functionality variations in the concrete alternatives such as Intel/TXT and AMD/SVM, among others. Other candidate HW-LSKs (implementations of HW-ATI) include: An on-die secure co-processor (part of a system-on-chip). • Special functions integrated into the processor’s pipeline for confidentiality and integrity. • Special hardware features for tracking critical or sensitive information flow to dynamically shepherd the legitimacy of an application’s execution path. • An isolated, dedicated core of a multi-core processor for interpreting hypervisor calls and managing physical resources under a virtualized computing environment. • A trusted platform module (TPM) that securely stores master keys. • In addition to the evaluation of security strength of the above potential techniques, a feasible secure component implemented at the hardware level must minimize the impact of design complexity as well as keep the performance degradation under a reasonable constraint. We will analyze such implications and demonstrate them using simulation or emulation. We expect that the evaluation of these hardware architecture alternatives will lead to the development of techniques and tools for better support of the ATI architecture. • Step 2: The evaluation of HW-LSKs will proceed in cooperation with the development of higher level ATIs and LSKs. For example, we plan to define an instance of VM-ATI based on the HW-ATI, and evaluate the several concrete implementations of VM-LSK (see the next section), built on the HW-LSKs (see the examples above). Using the multi-core alternative as an illustrative example, one “secure core” can be completely and securely isolated from the external network (i.e., creating a secure sandbox) while the other (untrusted) cores run service applications. All system level interactions such as I/O operations or memory allocation, however, will be monitored and scrupulously carried out by the isolated core. To protect the integrity of the VM-LSK, we will investigate the methods to securely sand-box this software module with the support of secure virtualization instruction extensions and their corresponding hardware techniques. • There are several examples of more tightly coupled interactions between higher level LSKs and HW-LSK. For example, instead of running the VM-LSK in a shared memory space, it can be isolated to execute in a protected memory region only accessible by the secure core. This complete, physical isolation of the VM-LSK memory from all other hypervisor functions and guest operating systems avoids potential tampering by malicious hypervisors (e.g., Blue Pill [1]) and untrusted OS’s. Another example is the need for protecting encryption master keys for mission-critical applications and Co-DBMS (Section ‎3.3), which can be implemented by TPM or similar facilities. A third example is the VM-ATI need for secure booting facilities such as AMD/SVM.

Trusted Architecture Components • Step 2: Development of higher level ATIs and LSKs. For example, we plan to define an instance of VM-ATI based on the HW-ATI, and evaluate the several concrete implementations of VM-LSK (see the next section), built on the HW-LSKs (see the examples above). Using the multi-core alternative as an illustrative example, one “secure core” can be completely and securely isolated from the external network (i.e., creating a secure sandbox) while the other (untrusted) cores run service applications. All system level interactions such as I/O operations or memory allocation, however, will be monitored and scrupulously carried out by the isolated core. • There are several examples of more tightly coupled interactions between higher level LSKs and HW-LSK. For example, instead of running the VM-LSK in a shared memory space, it can be isolated to execute in a protected memory region only accessible by the secure core. This complete, physical isolation of the VM-LSK memory from all other hypervisor functions and guest operating systems avoids potential tampering by malicious hypervisors and untrusted OS’s.

Trusted Microkernels and Hypervisors • Step 1: Given our assumption that OS’s cannot be trusted, we will consider a VMM as a natural component of the LSK. At the VMM level of the platform, the step 1 is also the evaluation of design alternatives towards the definition of an abstract VM-ATI including the following: • Verified secure microkernel interfaces • Secure subsets of current hypervisors • Custom execution environments ( • Although the assumption that an entire hypervisor can be trusted is quite common today, we do not consider it a valid alternative for the future. This is due to a combination of several trends: (1) the lack of a formal proof for any of the current hypervisors; (2) the expected growth of hypervisor code in general, which appears to outpace the capability increase of formal methods; and (3) already published vulnerabilities in Xen and malicious hypervisors

Trusted Microkernels and Hypervisors • Step 2: Choose a small set of winning designs and implementations for the definition of VM-ATI and the construction of corresponding VM-LSKs that implement the VM-ATI. The candidate platforms (include the L4 microkernel and a refactoring of hypervisors such as Xen and VMware (by implementing VM-ATI using their facilities). The alternative choices will be evaluated by studying the different vulnerabilities in design and implementation. In terms of natural diversity, we are particularly interested in implementations that have independent failure modes and vulnerabilities, since their combination can improve overall system security and availability. The VM-ATI and VM-LSKs will be used in our research at the hardware layer, as mentioned in the previous section. At the hardware/hypervisor interface, the performance penalty imposed by the mapping between VM-LSKs (e.g., subset of Xen) and HW-LSKs (e.g., SVM/TXT) will determine the suitability of each HW-LSK for the implementation of VM-LSKs. • Step 3: Adopt the best combination of HW-ATI/VM-ATI and HW-LSK/VM-LSK from the evaluation studies. (By best combination we mean both performance and independence of failure modes.) These layers will be experimentally evaluated along the dimensions mentioned in step 1 (e.g., performance and verifiability) through their use by higher layers (MW-ATI, DB-ATI, and applications).

Trusted Operating Systems and Software • A major “security bottleneck” in an untrusted system are the many ways a malicious OS kernel may damage both application software and data. Since both the typical OS code base (on the order of millions of lines of code) and APIs (on the order of thousands of kernel calls) have grown beyond the reach of formal verification methods, we must work on subsets of OS functionality. • Step 1: Combine a supply-side study with a demand-driven study to converge on the design choices of appropriate OS-ATIs and OS-LSKs that implement them. The supply-side study (a bottom-up approach) will start from verified microkernel APIs such as seL4, and carefully add small increments of critical functionality. This work will be done in cooperation with the development of VM-ATI/VM-LSK combinations outlined in the previous section. The demand-driven study (a top-down approach) will start from concrete trusted component from higher layers (applications, DBMS, or middleware) to determine the most useful facilities

Trusted Operating Systems and Software • Step 2: The OS-ATI chosen in step 1 is implemented and incorporated into OS-LSKs by carefully adding the desired functionality on top of underlying trusted components (concrete implementations of VM-ATI and HW-ATI). This work will proceed by careful refactoring of current OS kernels (including production kernels and custom kernels developed for secure applications) combined with the development from scratch of appropriate ATI functionality. Since the total size of OS-ATI/OS-LSK combinations is limited by the projected capabilities of formal verification methods, we anticipate a good implementation to be achievable within a reasonable time. • Step 3: Use the top-down study to define the ATIs and their implementations (LSKs) at the application , DBMS, and middleware layers. These concrete implementations (MW-LSK, DB-LSK, AP-LSK) will provide the concrete evaluation drivers of the OS-ATI design and OS-LSK implementation, along the dimensions mentioned above. Again, the choice of designs and implementations that have independent vulnerabilities will enhance the overall security and resilience of Layered Separation Kernels as a whole.

Secure Middleware/Data • Due to the relative advanced state of trusted communication services and the increasing capabilities of emerging systems, our work at the middleware level will focus on the evaluation of existing techniques and software tools for incorporation into MW-ATI. • Data represent a critical asset for systems such as the GIG. Current applications rely on the underlying DBMS and OS for querying and storing data. For instance, authentication and access control are often performed solely by the DBMS, whereas buffer management and persistent storage are jointly supported by the DBMS and the OS (e.g., shared memory and I/O are controlled by the OS kernel). However, the DBMS cannot be trusted, for two main reasons: first, it is a complex software system that cannot be formally verified, and therefore may contain security vulnerabilities; second, it is provided by third parties that are not fully trusted. A compromised DBMS may leak confidential data, or may prevent applications from computing correct results (e.g., the compromised DBMS introduces errors in the execution plan or drops query results). Our goal is to protect the confidentiality and integrity of the data used in mission-critical applications.

Secure Data • Securing data must address two equally-important aspects: • On-lineprotection is concerned with providing a correct and complete view of the data to applications. This aspect is crucial for the decision-making process in critical applications. An important part of on-line protection is access control enforcement, which must be performed by a trusted component in order to prevent leakage of critical data to unauthorized users. In addition, malicious processes (e.g., a compromised virtual memory manager) must be prevented from eavesdropping on the data contents. • Off-lineprotection is concerned with securely storing the data, even when it is not used by applications. This is a challenging aspect, since malicious entities have many opportunities to attack the data, either through the DBMS or through raw access at the OS level. As a matter of fact, most DBMSs rely on the underlying un-trusted OS to handle storage of data to disk, hence disclosing sensitive data. Data leakage must be prevented even in the worst-case scenario when the attacker gains unrestricted physical access to the storage media (e.g., by physically removing the disk). • We will address these requirements by developing a secure DB-ATI layer, which consists of trusted computing and storage modules. We also refer to the implementation of DB-ATI as Co-DBMS (a term used interchangeably with DB-LSK) to emphasize that it is a component to be coupled with a conventional DBMS to achieve high assurance data management and to isolate the critical data from a potentially malicious DBMS. The DB-ATI (Figure 7) acts as an intermediate tier between critical applications and the un-trusted DBMS. Applications send data access requests to the DB-ATI, together with runtime context information. Such runtime-specific data allows the Co-DBMS to verify that the application has the proper access credentials, and to distinguish between separate application instances/sessions (e.g., distinct encryption keys for each application instance can be handled transparently within the secure DB-ATI layer). From the system’s point of view, the Co-DBMS will run in user space managed by OS-LSK and using only lower-level ATIs (MW-ATI, OS-ATI, VM-ATI, and HW-ATI) discussed in Section ‎3.2. Although our main objective is to use the DB-ATI in conjunction with the LSK platform, we emphasize that the DB-ATI layer can also be deployed in other settings, such as: • Trusted OS: if the entire OS is trusted (e.g., an in-house developed OS kernel) a custom version of the Co-DBMS can be deployed directly on top of the custom OS. Thus, protection against an un-trusted DBMS engine can be achieved with lower performance overhead. • Trusted virtual machine environments: in scenarios in which a (presumed secure) VMM provides secure data management facilities (e.g., Overshadow [13]), the DB-ATI can be deployed on top of untrusted OS and remain protected by the secure VMM. • The Co-DBMS will interface with applications and DBMS in a transparent manner, without requiring significant changes to the existing infrastructure. We plan to encapsulate the DB-ATI functionality within a self-contained module, uniformly accessible by applications through an ODBC-like driver (part of DB-LSK).

Secure Data • We will address these requirements by developing a secure DB-ATI layer, which consists of trusted computing and storage modules. We also refer to the implementation of DB-ATI as Co-DBMS (a term used interchangeably with DB-LSK) to emphasize that it is a component to be coupled with a conventional DBMS to achieve high assurance data management and to isolate the critical data from a potentially malicious DBMS. The DB-ATI (Figure 7) acts as an intermediate tier between critical applications and the un-trusted DBMS. Applications send data access requests to the DB-ATI, together with runtime context information. Such runtime-specific data allows the Co-DBMS to verify that the application has the proper access credentials, and to distinguish between separate application instances/sessions (e.g., distinct encryption keys for each application instance can be handled transparently within the secure DB-ATI layer). From the system’s point of view, the Co-DBMS will run in user space managed by OS-LSK and using only lower-level ATIs (MW-ATI, OS-ATI, VM-ATI, and HW-ATI). Although our main objective is to use the DB-ATI in conjunction with the LSK platform, we emphasize that the DB-ATI layer can also be deployed in other settings, such as: • Trusted OS: if the entire OS is trusted (e.g., an in-house developed OS kernel) a custom version of the Co-DBMS can be deployed directly on top of the custom OS. Thus, protection against an un-trusted DBMS engine can be achieved with lower performance overhead. • Trusted virtual machine environments: in scenarios in which a (presumed secure) VMM provides secure data management facilities (e.g., Overshadow [13]), the DB-ATI can be deployed on top of untrusted OS and remain protected by the secure VMM. • The Co-DBMS will interface with applications and DBMS in a transparent manner, without requiring significant changes to the existing infrastructure. We plan to encapsulate the DB-ATI functionality within a self-contained module, uniformly accessible by applications through an ODBC-like driver (part of DB-LSK).

Secure Data • Although our main objective is to use the DB-ATI in conjunction with the LSK platform, at the DB-ATI layer can also be deployed in other settings, such as: • Trusted OS: if the entire OS is trusted (e.g., an in-house developed OS kernel) a custom version of the Co-DBMS can be deployed directly on top of the custom OS. Thus, protection against an un-trusted DBMS engine can be achieved with lower performance overhead. • Trusted virtual machine environments: in scenarios in which a (presumed secure) VMM provides secure data management facilities, the DB-ATI can be deployed on top of untrusted OS and remain protected by the secure VMM. • The Co-DBMS will interface with applications and DBMS in a transparent manner, without requiring significant changes to the existing infrastructure. We plan to encapsulate the DB-ATI functionality within a self-contained module, uniformly accessible by applications through an ODBC-like driver (part of DB-LSK).

Secure Data • In a typical client-server application, the Co-DBMS will mediate SQL calls from the application to a database server. Since the DB-ATI layer resides within the client, Co-DBMS can support full-fledged SQL data access. On the other hand, in a large-scale distributed environment setting, situations arise where data need to be re-located. For instance, to reduce access time, data may be cached at remote sites. In other cases, computational constraints may require data transfer (e.g., certain processing steps may only be performed by specialized hardware.) In such scenarios, it is necessary to design mechanisms that protect the data regardless of their physical location. This is addressed by developing light-weight self-contained secure DB-LSK implementations that will be packaged together with the data. Such sticky DB-LSK components will still provide standardized interfaces to the data, but may only support a restricted subset of data access operations.

Secure Data • The Co-DBMS will ensure correctness and completeness of database query results, and will secure storage by encrypting and signing the data before it is sent to the storage media. In addition, the Co-DBMS will verify (through efficient provable data possession protocols) that the data are not discarded due to a compromised OS or due to hardware failures. The trustworthiness of the Co-DBMS can be guaranteed due to several factors: • the DB-ATI will support standard specialized primitives for which it is possible to perform formal verification (e.g., encryption, digital signatures); • whenever it is viable, we will push down the DB-ATI functionality down to appropriate lower-level trusted ATI. This approach has two advantages: (i) code executed by specialized hardware is robust to ubiquitous attacks on standard computer architectures (e.g., buffer overflow); (ii) the operations implemented at lower ATI levels are faster.

Secure Data • The functionality provided by the secure DB-ATI will include: • Access control: this fundamental security primitive must be executed on a trusted component, and will be implemented in software. • Encrypting and signing data: such standard cryptographic primitives are essential for secure storage and will be implemented in hardware, where possible. In certain cases, if the MW-ATI layer supports such primitives, the DB-ATI can invoke these services directly. • Processing and indexing on top of encrypted data: these primitives are essential for query processing (e.g., comparisons on encrypted values), and will be implemented in software, using techniques such as functional encryption and oblivious RAM • Provable data possession primitives: a compromised OS may attempt to delete the data stored on disk. We will explore efficient methods (i.e., with low I/O and computational overhead) to check the integrity of storage on un-trusted media

Secure Applications • Complex software applications typically implement a mixture of security-critical and security-irrelevant functionality. For example, a sink for a wireless sensor network might implement a database for storing confidential data collected from sensors as well as implementing a graphical user interface. Unfortunately, due to the monolithic design of many of these applications, vulnerabilities in the security-irrelevant portion can lead to a compromise of the security-critical component. For instance, a buffer overflow vulnerability in the graphical user interface could be leveraged by an attacker to take control of the process and thereby access the secure database. Since it is generally not feasible to formally verify all components of large, production-level applications, some form of secure program partitioning is needed. • Our architecture design addresses this issue by dividing each system layer into a functionality-rich untrusted component and a smaller, functionality-limited abstract trusted interface (ATI). Application code in our architecture must therefore be likewise partitioned to isolate its non-critical components from its security-critical components, and to obtain trusted services exposed by the secure database system (DB-ATI), middleware (MW-ATI), and operating system (OS-ATI) layers.

Benefits of the approach • From the application point of view, our approach provides an end-to-end solution in protecting mission-critical applications and data from untrusted components at each layer of system software. This is achieved by a combination of small trusted interfaces at each layer (Isolation Principle), independently implemented trusted components for the trusted interfaces (Independence Principle), and variety of implementations (Diversity Principle), which is a powerful innovation at the system level.

Relevance to DoD Mission Assurance • Our research will be directly applicable to DoD’s Mission Assurance Objectives, as the systems that will be developed based on our principles will ensure security even if the components are compromised. • For example, consider the AWACS experimental system discussed in our scenario. Attacks may be at the sensor level, the application level or at any of the component level. Our approach will ensure that the system will be in operation even if the components such as middleware or the operating systems are attacked. We believe that the theories, tools and technologies to be developed under this project can be applied to build the next generation of mission assurance technologies for the military.

Acknowledgement • Investigation of Mission Assurance Carried out jointly with • Purdue University (Purdue) • Georgia Institute of Technology (GATech) • University of Texas at Dallas (UTD) • University of Texas, San Antonio (UTSA) • University of Dayton (UDayton) • University of California, Irvine (UCI)

References • Mission Assurance, http://en.wikipedia.org/wiki/Mission_assurance • Thuraisingham, et al, UTDCS-03-10, Securing the Execution Environment Applications and Data from Multi-Trusted Components, The University of Texas at Dallas, Technical Report, 2010.

Data and Applications Security Developments and Directions