A copy of this work was available on the public web and has been preserved in the Wayback Machine. The capture dates from 2017; you can also visit the original URL.
The file type is
This paper introduces our work around combining machine virtualization technology with Trusted Computing Group technology. We first describe our architecture for reducing and containing the privileged code of the Xen Hypervisor. Secondly we describe our Trusted Virtual Platform architecture. This is aimed at supporting the strong enforcement of integrity and security policy controls over a virtual entity where a virtual entity can be either a full guest operating system or virtual appliancedoi:10.1145/1496909.1496918 fatcat:3zuiuas72ncdhfmryuplb6otoe
more »... ing on a virtualized platform. The architecture includes a virtualization-specific integrity measurement and reporting framework. This is designed to reflect all the dependencies of the virtual environment of a guest operating system. The work is a core enabling component of our research around converged devicesclient platforms such as notebooks or desktop PCs that can safely host multiple virtual operating systems and virtual appliances concurrently and report accurately on the trustworthiness of the individually executing entities.
Despite the deployment of preventive security mechanisms to protect the assets and computing platforms of users, intrusions eventually occur. We propose a novel intrusion survivability approach to withstand ongoing intrusions. Our approach relies on an orchestration of fine-grained recovery and per-service responses (e.g., privileges removal). Such an approach may put the system into a degraded mode. This degraded mode prevents attackers to reinfect the system or to achieve their goals if theydoi:10.1145/3419471 fatcat:3kelxw4m6zebhj5toquv73xo7i
more »... anaged to reinfect it. It maintains the availability of core functions while waiting for patches to be deployed. We devised a cost-sensitive response selection process to ensure that while the service is in a degraded mode, its core functions are still operating. We built a Linux-based prototype and evaluated the effectiveness of our approach against different types of intrusions. The results show that our solution removes the effects of the intrusions, that it can select appropriate responses, and that it allows services to survive when reinfected. In terms of performance overhead, in most cases, we observed a small overhead, except in the rare case of services that write many small files asynchronously in a burst, where we observed a higher but acceptable overhead. The idea of Intrusion Detection Systems (IDSs) dates back to the 1980s [1, 21] . Since then, more intrusion detection approaches were introduced, refined, and transferred from academia to industry. Most of today's commodity Operating Systems (OSs) can be deployed with some kind of Intrusion Detection System (IDS). However, as the name suggests, IDSs only focus on the detection and do not provide the ability to survive or withstand an intrusion once it has been detected. To limit the damage done by security incidents, intrusion recovery systems help administrators restore a compromised system into a sane state. Common limitations are that they do not preserve availability [31, 35, 44] (e.g., they force a system shutdown) or that they neither stop intrusions from reoccurring nor withstand reinfections [31, 35, 44, 84, 87] . If the recovery mechanism restores the system to a sane state, the system continues to run with the same vulnerabilities and nothing stops attackers from reinfecting it. Thus, the system could enter a loop of infections and recoveries. Existing intrusion response systems, however, apply responses  to stop an intrusion or limit its impact on the system; but existing approaches apply coarse-grained responses that affect the whole system and not just the compromised services  (e.g., blocking port 80 for the whole system, because a single compromised service uses this port maliciously). They also rely on a strong assumption of having complete knowledge of the vulnerabilities present and used by the attacker [27, 73] to select responses. These limitations mean that they cannot respond to intrusions without affecting the availability of the system or of some services. Whether it is due to business continuity, safety reasons, or the user experience, the availability of services is an important aspect of a computing platform. For example, while web sites, code repositories, or databases are not safety-critical, they can be important for a company or for the workflow of a user. Therefore, the problem that we address is the following: How to design an Operating System (OS) so its services can survive ongoing intrusions while maintaining availability? Our approach distinguishes itself from prior work on three fronts. First, we combine the restoration of files and processes of a service with the ability to apply responses after the restoration to withstand a reinfection. Second, we apply per-service responses that affect the compromised services instead of the whole system (e.g., only one service views the file system as read-only). Third, after recovering a compromised service, the responses we apply can put the recovered service into a degraded mode, because they remove some privileges normally needed by the service. The degraded mode is introduced on purpose. When the intrusion is detected, we do not have precise information about the vulnerabilities exploited to patch them or we do not have a patch available. The degraded mode allows the system to survive the intrusion for two reasons. First, after the recovery, the degraded mode either stops the attackers from reinfecting the service or from achieving their malicious goals. Second, it keeps as many functions of the service available as possible, thus maintaining availability while waiting for a patch. We maintain the availability by ensuring that core functions of services are still operating, while non-essential functions might not be working due to some responses. For example, a web server could have "provide read access to the website" as core function and "log accesses" as non-essential. Thus, if we remove the write access to the file system it would degrade the service's state (i.e., it cannot log anymore), but we would still maintain its core function. We developed a cost-sensitive response selection where administrators describe a policy consisting of cost models for responses and malicious behaviors. Our solution then selects a response that maximizes the effectiveness while minimizing its impact on the service based on the policy. This approach gives time for administrators to plan an update to fix the vulnerabilities (e.g., wait for a vendor to release a patch). Finally, once they patched the system, we can remove the responses, and the system can leave the degraded mode. Contributions. Our main contributions are the following: • We propose a novel intrusion survivability approach to withstand ongoing intrusions and maintain the availability of core functions of services (Sections 3.1 and 4). Intrusion Survivability for Commodity Operating Systems • 21:3 • We introduce a cost-sensitive response selection process to help select optimal responses (Section 5). • We develop a Linux-based prototype implementation by modifying the Linux kernel, systemd , CRIU , Linux audit , and snapper  (Section 6). • We evaluate our prototype by measuring the effectiveness of the responses applied, the ability to select appropriate responses, the availability cost of a checkpoint and a restore, the overhead of our solution, and the stability of the degraded services (Section 7). Outline. The rest of this article is structured as follows: First, in Section 2, we mention related concepts about our work, and we review the state-of-the-art on intrusion recovery and response systems. In Section 3, we give an overview of our approach, and we define the scope of our work. In Section 4, we specify the requirements and architecture of our approach. In Section 5, we describe how we select cost-sensitive responses and maintain core functions. In Section 6, we describe a prototype implementation that we then evaluate in Section 7. In Section 8, we discuss some limitations of our work, and we give a summary of the comparison with the related work. We conclude and give the next steps regarding our work in Section 9.
Lecture Notes in Computer Science
Verifiable trust is a desirable property for computing platforms. Current trusted computing systems developed by Trusted Computing Group (TCG) provide verifiable trust by taking immutable snapshots of the whole set of platform components. It is, however, difficult to use this technology directly in virtualized platforms because of complexity and dynamic changes of platform components. In this paper, we introduce a novel integrity management solution based on a small Software-based Root of Trustdoi:10.1007/978-3-642-14597-1_11 fatcat:tlybtwkm45adfdz2nsbqunzo5u
more »... for Measurement (SRTM) that provides a trusted link to the integrity measurement chain in the TCG technology. Our solution makes two principal contributions: The first is a key management method, by which a verifier can be convinced that the SRTM is a trusted delegatee of a Trusted Platform Module (TPM). The second is two integrity management services, which provides a novel dependency relation between platform components and enables reversible changes to measured components. This extended abstract of the paper focuses on the key management method and shows the high level idea of these two services. Details of the dependency relation, the reversible changes, and the Xen implementation may be found in the full version of the paper.
This paper describes a method of increasing the trust in open computing platforms, such that a person can have confidence in producing a digital signature using open platforms.doi:10.1145/508171.508184 dblp:conf/nspw/BalacheffCPP01 fatcat:6d7cufh6nngefnhlfhigyka5vy
Proceedings of the 2001 workshop on New security paradigms - NSPW '01
This paper describes a method of increasing the trust in open computing platforms, such that a person can have confidence in producing a digital signature using open platforms.doi:10.1145/508181.508184 fatcat:zde7bnfa7jambolc2q76lebisy
Despite the deployment of preventive security mechanisms to protect the assets and computing platforms of users, intrusions eventually occur. We propose a novel intrusion survivability approach to withstand ongoing intrusions. Our approach relies on an orchestration of fine-grained recovery and per-service responses (e.g., privileges removal). Such an approach may put the system into a degraded mode. This degraded mode prevents attackers to reinfect the system or to achieve their goals if theydoi:10.1145/3359789.3359792 dblp:conf/acsac/ChevalierPDH19 fatcat:b33z6bmnjrcdnaaqzi7qhfldce
more »... anaged to reinfect it. It maintains the availability of core functions while waiting for patches to be deployed. We devised a cost-sensitive response selection process to ensure that while the service is in a degraded mode, its core functions are still operating. We built a Linux-based prototype and evaluated the effectiveness of our approach against different types of intrusions. The results show that our solution removes the effects of the intrusions, that it can select appropriate responses, and that it allows services to survive when reinfected. In terms of performance overhead, in most cases, we observed a small overhead, except in the rare case of services that write many small files asynchronously in a burst, where we observed a higher but acceptable overhead.
Highly privileged software, such as firmware, is an attractive target for attackers. Thus, BIOS vendors use cryptographic signatures to ensure firmware integrity at boot time. Nevertheless, such protection does not prevent an attacker from exploiting vulnerabilities at runtime. To detect such attacks, we propose an event-based behavior monitoring approach that relies on an isolated co-processor. We instrument the code executed on the main CPU to send information about its behavior to thedoi:10.1145/3134600.3134622 dblp:conf/acsac/ChevalierVPH17 fatcat:jizvvr647rgmpfbvc7xp7x7rsu
more »... . This information helps to resolve the semantic gap issue. Our approach does not depend on a specific model of the behavior nor on a specific target. We apply this approach to detect attacks targeting the System Management Mode (SMM), a highly privileged x86 execution mode executing firmware code at runtime. We model the behavior of SMM using invariants of its control-flow and relevant CPU registers (CR3 and SMBASE). We instrument two open-source firmware implementations: EDK II and coreboot. We evaluate the ability of our approach to detect state-of-the-art attacks and its runtime execution overhead by simulating an x86 system coupled with an ARM Cortex A5 co-processor. The results show that our solution detects intrusions from the state of the art, without any false positives, while remaining acceptable in terms of performance overhead in the context of the SMM (i.e., less than the 150 μs threshold defined by Intel).
Edwards Winsome Gloria Johansen Joyce Susan Pocha (Denham) Pauline Blanche Marie Plaquin MaryLee A. Saiz! ... Lynn Dowse Susan Jennifer Eastham Marilyn Louise King David R. May L. Rose Mink Gillian Margaret Starling Marie E. ...
. • "This is a new focus for the security community," said David Aucsmith, security architect for chip maker Intel "The actual user of the PC -someone who can do anything they want -is the enemy." ...fatcat:msfiwtadezaapnb7lhuvlkdduu
Lecture Notes in Computer Science
Acknowledgments Boris Balacheff, Joe Pato, David Plaquin, and Martin Sadler of HP Labs helped orient this work in relation to the TPM environment. ...doi:10.1007/978-3-540-24725-8_23 fatcat:g4uos7hp7nbgndgliphjryeytq
Lecture Notes in Computer Science
Acknowledgments We like to thank Thomas Fischer and David Plaquin from HP Labs for their input and contributions. ...doi:10.1007/978-3-642-14597-1_10 fatcat:gxjxnfiqlrd3rk3mwene7aunja
The author would like to thank Lawrence Case, Bob DiFazio, David Greiner, Louis Guccione, Dolores Howry, and Michael V. Meyerstein, for many useful discussions and comments. ... Several mechanisms for migration are discussed in the context of virtualisation architectures (Plaquin et al., 2009) and could be applied to the presented solution. ...doi:10.1504/ijitst.2011.043133 fatcat:q3ylrwkjnbedbkix6h5phnhltq
elegir entre los ejemplos bíblicos, las leyes del Reino y las disposiciones canónicas y toma partido por éstas: el riepto desemboca normalmente en duelo o combate de uno contra uno como el que enfrentó a David ... Cota de armas, tinicla y plaquín, «una misma cosa son, pues en cada una dellas van las armas del que las trae, e solamente difieren en la fación o fechura, como parece por sus patrones». ...doi:10.5944/etfiii.4.1991.3526 fatcat:rykwsfuu2rgqlbas5fwb27jhxu
Chen & Ho, 2001; Ishibuchi & Murata, 1998; Ishibuchi, Yoshida, & Murata, 2003; Mansouri, Moattar-Husseini, & Zergudi, 2003; Pierreval & Plaquin, 1998; Younes, Ghenniwar, & Areibi, 2003) , to cite just ...doi:10.1007/s10845-005-6641-3 fatcat:lhadvcoulfbqvcuofd54amz5jy
cela arrive, l'officier d'armes doit recevoir 100 francs sur les biens du condamné. existent trois sortes de cottes d'armes, la cotte (cota de armas), la jaque de mailles (tinicla) et le haubergeon (plaquín ... tous ces éléments qui se lisent dans l'héraldique doivent se compter jusqu'à 10 et pas plus, car le nombre de 10 est parfait, car Notre Seigneur donna sa loi à Moïse en 10 commandements, et le prophète David ...doi:10.4000/bulletinhispanique.649 fatcat:5zukeo44bbefhle24xw7iibzg4
« Previous Showing results 1 — 15 out of 17 results