Ph.D. Thesis Defense - unipi.itgroups.di.unipi.it/~daniele/publications/PhD_Thesis...Ph.D. Thesis...

1/65 Measuring the Semantic Integrity of a Process Self

Measuring the Semantic Integrity of a Process Self

Ph.D. Thesis Defense

Daniele Sgandurra

Universita di Pisa

24 June 2010


Outline

Measuring the Semantic Integrity

Virtualization-Based Security

Description of the Process Self

Run-Time Architecture

Remote Attestation of Semantic Integrity

Code Obfuscation in a Virtual Environment

Trusted Overlays of Virtual Communities


Main Contributions of the Thesis

I Definition and evaluation of PsycoTrace, a security frameworkto protect a process from attacks against the process self:

I measuring the semantic integrity;I static analysis and run-time monitoring;I complete transparency of the proposed framework.

I Three applications of the proposed framework targeted atcloud computing:

I remote attestation;I code obfuscation;I secure sharing of cloud resources.


Part I

Background



Attacks

I Attacks against user-level processes:

I the attacker injects some code into a process;I the attacker diverges the original control-flow to execute the

injected code.

I Attacks against the kernel:

I modify some kernel functionalities;I final step of a complex attack (requires root privileges);I modify the kernel behavior to hide any sign of the attack.



Process Self

I The properties of a process that determine its run-time behavior definethe process self:

I the process self can be approximated through static analysis.

I We assume that if the process current behavior deviates from the processself then the process code has been altered by an attack.

I Measuring the semantic integrity: the act of approximating the processself and of monitoring the actual process behavior to assure that it iscoherent with the process self.

I P is a generic process that we want to protect.

I Self (P) refers to the process self of P:

I SourceCode(P) is the source code of the program executed by P.



Process Self



Alternative Descriptions of the Process Self

I Hashing or Memory Invariants; memory invariants to be evaluatedanytime P issues a given system call;

I Forbidden Calls: the set of system calls that P cannot issue;

I Forbidden Parameters: the set of system calls that P cannot issue andassertions on parameters it cannot transmit to a call;

I Allowed Calls: the set of system calls that P can issue and assertions onthe parameters;

I Enriched Traces: describe the sequence of system calls that P issues inone execution; each call may be coupled with a memory assertion.



Enriched Traces

I A set of enriched traces fully describes alternative legal behaviors of P.

I To support this strategy, PsycoTrace static tools map SourceCode(P)

into a description of the Self (P) that is CFG(P) and IT (P):

I CFG(P) is context-free grammar that defines the system call tracesthat P may issue during its execution.

I IT (P) is a set of invariants {I (P, 1), . . . , I (P, n)}, each associatedwith a program point i where P invokes a system call.



Virtualization

I Virtual Machine Monitor (VMM): manages Virtual Machines (VMs), i.e.execution environments that emulate, at software, the behavior of theunderlying physical machine.

I A real machine can support several VMs, each with a distinct OS.



Virtual Machine Introspection

I Virtual Machine Introspection (VMI) enables a privileged VM, orIntrospection VM (I-VM), to retrieve critical data structures in thememory of a Monitored VM (Mon-VM) at the kernel or at the user-level.

I An I-VM can analyze the state of the processes/kernel on a Mon-VM atthe HW/FW level, without introducing additional HW/FW units.

I Introspection is applied at a lower level than the one an attacker can gainand it is very complex to elude it.



Introspection VM



Advantages of Virtual Machine Introspection

I Full visibility of the system running inside the Mon-VM: the I-VM canaccess every Mon-VM component, such as the main memory or theprocessor’s registers.

I More robustness: the I-VM is isolated from the Mon-VM.

I Transparency: the security checks can be implemented without modifyingthe software on the Mon-VM and they are almost invisible.


Part II

Principles and Implementation



Static Tools

PsycoTrace static tools analyze SourceCode(P) to approximate the processself:

1. one tool implements Grammar Generating Algorithm, an algorithm thatbuilds CFG(P), the grammar that describes the traces of P;

2. the Assertion Generator generates the set of invariants IT (P).

A preliminary step of the static analysis builds Abstract Syntax Tree of P

(AST (P)), which is exploited by both tools.



Grammar Generating Algorithm

I PsycoTrace static tools generate CFG(P) by applying grammargenerating algorithm (GGA) while traversing AST (P).

I CFG(P) is a tuple < T ,F , S ,R >:

I T is a set of terminal symbols with one symbol for each distinctsystem call in SourceCode(P);

I F is a set of non-terminal symbols, one for each function defined inSourceCode(P); each symbol corresponds to a subset of T .

I S ∈ F is the starting symbol, which corresponds to main;I R is the set of production rules X → β, where X is a non-terminal

symbol and β a sequence of terminal and not-terminal symbols.



Grammar Generating Algorithm Rules

I GGA analyzes AST (P) and for each function fun defined inSourceCode(P) it inserts into F a new non-terminal symbol FUN and anew rule Rnew into R, where FUN is the left-hand-side of Rnew .

I To generate the right-hand side of the rule, GGA linearly scans thedefinition of fun in SourceCode(P).

I Distinct production rules may be generated, according to the type ofstatements met by GGA in the body of fun.

I For each statement, GGA generates a new rule and adds a new symbol tothe right-hand side of Rnew .

I In this way, CFG(P) represents the system calls that fun can invoke andthe ordering among the invocations in the body in fun.



1 f (){2 open ( ) ;3 r e a d ( ) ;4 g ( ) ;5 c l o s e ( ) ;6 }78 g (){9 g e t p i d ( ) ;

10 }

〈F〉→ open read 〈G〉 close;〈G〉→ getpid;

1 f (){2 open ( ) ;3 i f ( x )4 r e a d ( ) ;5 }

〈F〉→ open 〈ST1〉;〈ST1〉→ read | ε;

1 f (){2 open ( ) ;3 i f ( x )4 r e a d ( ) ;5 e l s e6 c l o s e ( ) ;7 }

〈F〉→ open 〈IFEL1〉;〈IFEL1〉→ 〈STIF2〉 |〈ELSE3〉;〈STIF2〉→ read;〈ELSE3〉→ close;



1 f (){2 open ( ) ;3 w h i l e ( x )4 r e a d ( ) ;5 }

〈F〉→ open 〈WHILE1〉;〈WHILE1〉→ 〈WHRE2〉〈WHILE3〉 | ε;〈WHRE2〉→ read;

1 f (){2 open ( ) ;3 r e a d ( ) ;4 i f ( e x e c l ( . . . ) != −1)5 f ( ) ;6 c l o s e ( ) ;7 }

〈F〉→ open read 〈STIF1〉close;〈STIF1〉→ execl 〈F〉 | ε;



SourceCode(P) Example

1 i n t main ( i n t argc , c h a r ∗∗a r g v ) {2 c h a r ∗ f i l e n a m e ;3 i n t f d ;4 f i l e n a m e = a r g v [ 1 ] ;5 f d = f o r k ( ) ;6 i f ( f o r k ( ) == 0) {7 i f ( e x e c l ( f i l e n a m e , NULL) == −1) {8 p r i n t f (”ERROR!\n ” ) ;9 }

10 e l s e {11 s t r c a t ( f i l e n a m e , ” . exec1 ” ) ;12 }13 }14 e l s e { . . . }1516 i f ( a r g c > 2) {17 f i l e n a m e = a r g v [ 2 ] ;18 s t r c a t ( f i l e n a m e , ” . exec2 ” ) ;19 }2021 e x e c l ( f i l e n a m e , NULL ) ;22 }



CFG (P) Example

〈MAINP〉→ 〈EXPR0〉〈EXPR1〉〈IFEL2〉〈STIF11〉〈EXPR14〉;〈EXPR0〉→ /*empty*/;〈EXPR1〉→ fork;〈IFEL2〉→ 〈STIF3〉 | 〈ELSE4〉;〈ELSE4〉→ fork 〈EXPR10〉;〈STIF3〉→ fork 〈IFEL5〉;〈IFEL5〉→ 〈STIF6〉 | 〈ELSE7〉;〈ELSE7〉→ execl 〈EXPR9〉;〈STIF6〉→ execl 〈IFEL8〉;〈EXPR8〉→ 〈PRINTFp〉;〈PRINTFp〉→ . . . ;〈EXPR9〉→ 〈STRCATp1

〉;〈STRCATp1

〉→ . . . ;

〈EXPR10〉→ . . . ;〈STIF11〉→ /*empty*/ | 〈EXPR12〉〈EXPR13〉〈EXPR12〉→ /*empty*/;〈EXPR13〉→ 〈STRCATp1

〉;〈EXPR14〉→ execl;



Assertion Generator

I The Assertion Generator traverses AST (P) and analyzes the variables,functions and language statements to build the invariant table (IT (P)).

I To simplify the analysis, we restrict to:

I integer variables: only files and socket descriptors to expressrelations among these variables and the system calls;

I string variables: in case of arrays of char statically declared,functions to manipulate strings are treated like assignments;

I struct members: only integer or string type field.



Classes of Assertion

Any assertion is the composition of any of the followings:

1. Parameters assertions. They express data-flow relations amongparameters of distinct calls, e.g. the file descriptor in a read call is theresult of a previous open call.

2. File Assertions. To prevent symlink and race condition attacks, theycheck, as an example, that the real file-name corresponding to the filedescriptor belongs to a known directory.

3. Buffer length assertions. They check that the length of the string passedto a vulnerable function is not larger than the local buffer to hold it.

4. Conditional statements assertions. They prevent problems due toimpossible paths by relating a system call and the expression in the guardof a conditional statement.



SourceCode(P) Example

1 /∗2 i n v a r i a n t g e n e r a t i o n example3 ∗/45 i n t main ( i n t argc , c h a r ∗∗a r g v ) {6 c h a r path1 [ 1 0 ] ;7 c h a r path2 [ 1 0 ] = ”B” ;8 i n t t e s t , f d ;9 i f ( a t o i ( a r g v [ 1 ] ) == 0) {

10 t e s t = 2 ;11 s t r c p y ( path2 , ”D” ) ;12 s t r c p y ( path1 , ”D” ) ;13 f d = open (” f i l e p a t h ” , ”RW” ) ;14 }15 i f ( a t o i ( a r g v [ 1 ] ) > 5) {16 t e s t = 1 ;17 s t r c p y ( path1 , ”A ” ) ;18 p r i n t f (”% s ” , path1 ) ;19 w r i t e ( fd , path1 , s i z e o f ( path1 ) ) ;20 }21 e l s e {22 t e s t = 0 ;23 e x e c l ( path2 , ” ” ) ;24 p r i n t f (”% s ” , path1 ) ;25 }26 }



Rule INVARIANT RT LOCPRMFUN@main argc = {-} RT 5

PRMFUN@main argv = {-} RT 5

main stringsSYS path1 = {-} - 6

STIF0 path1 = {-|"D"} - 12

STIF6 path1 = {-|"D"|"A"} - 17

STIF6 path1 = {-|"D"|"A"} - 18

ELSE7 path1 = {-|"D"|"A"} - 24

main stringsSYS path2 = {"B"} - 7

STIF0 path2 = {-|"B"|"D"} - 11

ELSE7 path2 = {-|"B"|"D"} - 23

main stringsSYS test = {-} - 8

STIF0 test = {-|2} - 10

STIF6 test = {-|2|1} - 16

ELSE7 test = {2|1|0} - 22

main stringsSYS fd = {-} - 8

STIF0 fd = {-|open} RT 13

STIF6 fd = {-|open} RT 19

EXPR2 path20@strcpy0 = {"B"} - 11

EXPR2 PRM1@strcpy0 = {"D"} - 11

EXPR3 path10@strcpy1 = {-} - 12

EXPR3 PRM1@strcpy1 = {"D"} - 12

EXPR4 PRM0@open2 = {"file path"} - 13

EXPR4 PRM1@open2 = {"RW"} - 13

EXPR8 path10@strcpy4 = {-|"D"} - 17

EXPR8 PRM1@strcpy4 = {"A"} - 17

EXPR9 PRM0@printf5 = {"%s"} - 18

EXPR9 path11@printf5 = {"A"} - 18

EXPR10 fd0@write5 = {-|OPEN@13} RT 19

EXPR11 path11@write6 = {"A"} - 19

EXPR12 path20@execl7 = {"B"|"D"} - 23

EXPR13 PRM1@execl7 = {""} - 23

EXPR14 PRM0@printf8 = {"%s"} - 24

EXPR15 path11@printf8 = {-|"D"} - 24



Run-Time Components

I The run-time architecture consists of two virtual machines:

1. the monitored VM (Mon-VM), i.e. the VM executing P;2. the introspection VM (I-VM), i.e. the VM monitoring P through

virtual machine introspection.

I The I-VM can access each component of the Mon-VM to inspect its

running state both to:

I check the process self of P;I verify the kernel integrity.



Checking the Process Self at Run-Time

I Provided that the integrity of the Mon-VM kernel is assured, the run-timesupport has to guarantee that the self of P is not altered.

I The HiMod in the Mon-VM is a module that hijacks the system calls:

I not needed anymore with VT extensions: full transparency.

I Every time P invokes a syscall, HiMod notifies the Analyst on the I-VM.



The Analyst

The Analyst in the I-VM verifies the integrity of the self of P through:

I Lexical Analyzer: it verifies that the system call that P wants to issuebelongs to the set of system calls returned by the static analysis ofSourceCode(P);

I Parser: it checks that the current trace of system calls issued by P iscoherent with CFG(P), i.e. it is a prefix of a word allowed by CFG(P);

I Assertion Checker: it checks whether the invariant coupled with thecurrent system-call holds.



The Analyst



Assertion Checker

I The I-VM runs an Assertion Checker that evaluates invariants on P;

I Access to the variables of P and the CPU of the Mon-VM is implementedthrough an Introspection Library;

I Every time P issues a system call the I-VM:

(i) retrieves the system call number and the value of its parameter;(ii) determines the invariant coupled with the issued system call;(iii) retrieves the values of the variables that the invariant refers to;(iv) evaluates the invariant and:

I kills P if the invariant is false;I otherwise it resumes the execution of P.



Invariant Evaluation



Performance Results

I The average time to map one page of the process into the Assertion

Checker address space is about 50µsecs:

I at least three pages (kernel stack, user stack, variable): 150µsecs.

I By exploiting a software TLB, each access requires 20µsecs, provided that

variables are stored in the same page;

I 60µsecs overhead for each evaluation.

I Taking into account the rate of system call invocations, the averageexecution time overhead is at most 20%.



Kernel Integrity

I Periodically, the I-VM checks the kernel integrity.

I Implemented functions:

I Detecting Kernel ModificationsI Running Processes CheckerI Open Files CheckerI Loaded Modules AuthenticatorI Promiscuous Mode CheckerI Anti-spoofing

I Context-Agent.



Context-Agent

I The I-VM can inject a context-agent inside a Mon-VM to bridge thesemantic-gap.

I The I-VM also protects the context-agent from modifications by anysoftware running in the Mon-VM

I The I-VM has to provide a trusted subset of the Mon-VM kernel through

the integrity functions:

I the context-agent relies on the integrity of some key-components onthe Mon-VM kernel.



Context-Agent


Part III

Applications of the Proposed Approach



Virtual machine Integrity Measurement System

I Virtual machine Integrity Measurement System (VIMS) runs on a cloudarchitecture to continuously attest the integrity of cloud nodes byapplying alternative integrity measurements.

I VIMS protects the integrity of a node by defining both a start-upattestation and a continuous monitoring that are applied when a nodejoins the overlay and as long as the node belongs to the overlay.

I To implement the corresponding measurements, VIMS applies PsycoTracestatic tools and extends the run-time ones.



Virtual machine Integrity Measurement System

I Each node of the overlay runs two VMs:

I the Assurance VM (A-VM), an extension of the I-VM;I the Mon-VM.

I The A-VMs cooperate to apply measurements on behalf of the overlay byaccessing the live state of the Mon-VM.

I Trust in VIMS measurements requires the correct configuration of boththe A-VM and the underlying VMM and it is guaranteed bymeasurements and controls of a Trusted Platform Module (TPM).

I One of the first frameworks that merges TPM and cloud computing.



VIMS Architecture



Overview

I Obfuscation targeted at cloud environments to separate the obfuscatedprogram from the deobfuscator.

I The proposed strategy:

1. decomposes a program into fragments;2. applies the encryption of fragments;3. randomizes the control-flow across fragments.



Overview (cont.)

I At anytime, exactly one program fragment, the current one, is stored inclear on the Mon-VM, whereas any other fragment is encrypted.

I As soon as the execution of the current fragment terminates the I-VM:

I encrypts the current one;I determines and decrypts the next fragment to be executed;I updates the program counter of the Mon-VM.



System Block

I If s is a system call or the first instruction of the program, a system block(SB) is the smallest program fragment that includes any instruction thatmay be executed in-between s (not included) and either the next systemcall (included) or the program end;

I There is a distinct exit point for each system call that can be executedimmediately after s, or for the program end if s is the last call that maybe executed before the end is reached.



System Block Graph

I A program may be described as a set of SBs and a system block graph(SBG) that denotes the execution order among these SBs.

I The SBG is an oriented graph where each node represents a distinct SBand each arc is coupled with a distinct system call among those executedby the program.

I In general, a node may be the source of several arcs, because there maybe several exit points for each SB, each corresponding to the execution ofa distinct system call.



Unit Block Graph

To map CFGraph into the SBG , we consider an intermediate representation:

I a unit block (UB) is any sequence of instructions that belong to the same

BB in-between two consecutive delimiters of the BB:

I a delimiter is either a syscall or the first/last instruction of the BB.

I a unit block graph (UBG) is a transformation of CFGraph in a graph that

contains a node for each UB and an arc from the node representing UB1

to the one representing UB2 if:

a) UB1 and UB2 belong to the same BB and UB2 is executedimmediately after UB1, or

b) UB1 is the last UB of BB1 and UB2 is the first UB of BB2 and BB2

may be executed after BB1.



Algorithm to Map CFGraph(P) into SBG (P)

1. splits each BB containing n > 0 system calls into n + 1 UBs;

2. generates UBG(P);

3. visits UBG(P) and, for each node n that represents a UB:

I starts a depth first visit of the graph;I determines Succ(n), the set that includes any node m that

represents either a UB that may be executed after n and that endswith a system call or the END block that terminates the program;

I merges all the UBs represented by nodes on the path from n to anynode in Succ(n) into the same SB, SB(n).



Example: Control-Flow Graph



Example: Unit Block Graph



Example: System Block Graph



Run-Time Architecture of the Obfuscation Mechanism

1 the control-flow logic of the program to be obfuscated is partitioned

between two VMs:

I the Mon-VM stores the obfuscated version of the SBs of P;I the I-VM stores the information to deobfuscate P;

2 the I-VM encrypts and decrypts SBs at run-time in the memory of theMon-VM so that only one SB is in clear.



Run-Time Architecture of the Obfuscation Mechanism(cont.)

3 To increase the complexity of an attack to rebuild the original code byaccessing any of the executed SBs in clear, the Mon-VM only stores theSBs without any information about their execution order.

4 Transfer of control among these blocks is implemented by the I-VM bydirectly updating the program counter of the Mon-VM.

5 The new value of this register is computed through the SBG and a jumptable that maps the SBs into their virtual address.



Virtual Interacting Network CommunIty

I Virtual Interacting Network CommunIty (Vinci) is a software architecturethat exploits virtualization to share in a secure way an ICT infrastructure.

I Vinci decomposes users into communities: a set of users, theirapplications, a set of services and of shared resources.

I Users with distinct privileges and applications with distinct trust levelsbelong to distinct communities.

I Each community is supported by a virtual community network (VCN), i.e.a structured and highly parallel overlay that interconnects VMs built byinstantiating one of a predefined set of VM templates.



VM Templates



A VINCI Node



Example: Communities and VCNs



Example: Tainting


Part IV

Final Remarks


Contributions

Contributions of the Thesis (1)

I The definition of the process self in terms of a context-free grammar of

system calls and invariants on the process state;

I merge the ability of constraining the sequence of system calls withthat of coupling memory assertions with such calls.

I PsycoTrace: a robust framework to check the process self in a fully

transparent way:

I no modifications either to the monitored process or the underlyingOS so that the process is unaware of being monitored;

I protect kernel integrity.


Contributions


I A mechanism to bridge the semantic gap by transparently injecting anagent into the memory of a virtual machine.

I A framework that extends PsycoTrace to remotely attest the integrity ofa node willing to join an overlay that generalizes the TPM that alsoconsiders the behavior of the node.

I The notion of system block and its adoption to both increase theaccuracy and reduce the complexity of a static analysis to computeinvariants of a program.


Contributions


I An extension of PsycoTrace to protect a process against physical attacksby a novel code-obfuscation strategy that exploits virtualization toeffectively split the program logic between two virtual machines.

I A strategy to manage and protect a cloud shared among users and

applications with distinct trust and reliability levels:

I the strategy exploits highly parallel overlays of virtual machines,where each virtual machine is an instance of a specialized templatecustomized to run a small set of software components.


Contributions

Ongoing Developments

The proposed measurements are security checks that are necessary but notsufficient. Currently, we are working on:

I definition of relation between accuracy and abstraction;

I formal results about the accuracy of the detection:

I theorem for completeness: every attack will be detected?I theorem for soundness: every failed check means an attack?


References

Integrity and Cloud Security

[1] Building Trustworthy Intrusion Detection through VM Introspection.

Fabrizio Baiardi and Daniele SgandurraIn Proceedings of the Third IEEE International Symposium on Information Assurance and Security (IAS07), 2007, Manchester (UK), pp. 209-214.

[2] Towards High Assurance Networks of Virtual Machines.

Fabrizio Baiardi and Daniele SgandurraIn Proceedings of the Third European Conference on Computer Network Defense (EC2ND 2007), Heraklion(Greece).

[3] Protezione del Kernel Tramite Macchine Virtuali. Best Student Paper Award

Daniele Sgandurra and Fabio CampisiIn Proceedings of Net&System Security, 2007.

[4] Cloud Security Is Not (Just) Virtualization Security.

Mihai Christodorescu, Reiner Sailer, Douglas Schales, Daniele Sgandurra, Diego Zamboni.In proceedings of the ACM Cloud Computing Security Workshop. November, 2009.

[5] Introspection-based Context Agent Injection.

Mihai Christodorescu, Reiner Sailer, Douglas Schales, Arvind Seshadri, Daniele Sgandurra, Diego Zamboni.In IBM AoT (Academy of Technology) Security and Privacy Symposium, June 22-26, 2009.


References

Process Self

[6] Semantics-Driven Introspection in a Virtual Environment.

Francesco Tamberi, Dario Maggiari, Daniele Sgandurra, Fabrizio BaiardiIn proceedings of the Fourth IEEE International Conference on Information Assurance and Security (IAS2008), Naples (Italy).

[7] Transparent Process Monitoring in a Virtual Environment.

Daniele Sgandurra, Fabrizio Baiardi, Dario Maggiari and Francesco TamberiIn Electronic Notes in Theoretical Computer Science, volume 236, pp. 85-100, 2009.

[8] PsycoTrace: Virtual and Transparent Monitoring of a Process Self.

Fabrizio Baiardi, Dario Maggiari, Daniele Sgandurra and Francesco TamberiIn Proceedings of the 17th Euromicro International Conference on Parallel, Distributed and network-basedProcessing (PDP 2009), Weimar, Germany.


References

Vinci

[9] Security and Integrity of a Distributed File Storage in a Virtual Environment.

Gaspare Sala and Daniele Sgandurra and Fabrizio BaiardiIn Proceedings of the 4th International IEEE Security in Storage Workshop (SISW 07), San Diego (USA).

[10] Managing Critical Infrastructures through Virtual Network Communities.

Fabrizio Baiardi and Gaspare Sala and Daniele SgandurraIn Proceedings of the 2nd International Workshop on Critical Information Infrastructures Security (CRITIS2007), Malaga (Spain), LNCS 5141.

[11] Virtual Interacting Network Community: Exploiting Multi-Core Architectures to Increase Security.

Fabrizio Baiardi and Daniele SgandurraIn Proceedings of the 2008 Computing Frontiers Conference, ACM 2008, Ischia (Italy), p. 111

[12] Secure Sharing of an ICT Infrastructure Through Vinci.

Fabrizio Baiardi and Daniele SgandurraIn Proceedings of the 2nd International Conference on Autonomous Infrastructure, Management andSecurity Resilient Networks and Services (AIMS 2008), Bremen (Germany), LNCS 5127, pp. 65-78.

[13] Securing Health Information Infrastructures through Overlays.

Fabrizio Baiardi, Dario Maggiari and Daniele SgandurraIn Proceedings of HEALTHINF 2009 - International Conference on Health Informatics, Porto (Portugal).

[14] Securing a Community Cloud

Fabrizio Baiardi, Daniele Sgandurra.To appear in ICDCS-SPCC 2010: First ICDCS Workshop on Security and Privacy in Cloud Computing, 2010


References

VIMS and Other Topics

[15] Measuring Semantic Integrity for Remote Attestation.

Fabrizio Baiardi, Diego Cilea, Daniele Sgandurra and Francesco CeccarelliIn Proceedings of the 2nd International Conference on Trusted Computing Technical Strand (Trust 2009),Oxford, UK.

[16] Hierarchical, Model-Based Risk Management of Critical Infrastructures.

Fabrizio Baiardi and Daniele Sgandurra and Claudio TelmonJournal of Reliability Engineering & System Safety Volume 94, Issue 9, September 2009

[17] Modeling and Managing Risk in Billing Infrastructures.

Fabrizio Baiardi, Claudio Telmon and Daniele Sgandurra.In proceedings of the Third Annual IFIP Working Group 11.10 International Conference on CriticalInfrastructure Protection, ISBN 978-3-642-04797-8, pp. 51-64, Springer Boston.

[18] Attestation of Integrity of Overlay Networks.

Fabrizio Baiardi and Daniele Sgandurra.To appear in Journal of System Architecture, Special Issue on Security and Dependability Assurance ofSoftware Architectures

[19] Virtualization-based Obfuscation in Cloud Computing.

Fabrizio Baiardi and Daniele Sgandurra.Submitted to CCSW 2010: The ACM Cloud Computing Security Workshop

Ph.D. Thesis Defense - unipi.itgroups.di.unipi.it/~daniele/publications/PhD_Thesis...Ph.D. Thesis...

Documents

Transcript of Ph.D. Thesis Defense - unipi.itgroups.di.unipi.it/~daniele/publications/PhD_Thesis...Ph.D. Thesis...