Security Requirement Specification Model for Cloud Computing Services
•Download as PPTX, PDF•
2 likes•760 views
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (17)
Similar to Security Requirement Specification Model for Cloud Computing Services
Similar to Security Requirement Specification Model for Cloud Computing Services (20)
Recently uploaded
Recently uploaded (20)
Security Requirement Specification Model for Cloud Computing Services
- 1. S Security Requirement Specification Model for Cloud Computing Services SECONDA UNIVERSITA’ DI NAPOLI FACOLTA’ DI INGEGNERIA Relatore Prof. Massimo Ficco Candidato Matteo Leonetti Matricola A18/064 Anno Accademico 2012/2013
- 2. S Contents • Main Cloud Computing Issues • Security Requirement Specification for Cloud • Existing Security Specification Languages • Why a New Model? • Modeling Secure Interactions • Use Case and Misuse Case • Stereotypes • Component and Deployment Diagram • IDPS Rule Description • Case Study • Intrusion Detection Architecture for Cloud • Suggestions for Future Works
- 3. Main Cloud Computing Issues 3
- 4. 4 Security Requirement Specification for Cloud • Considering from the the early stage of SDLC; • Highliting ; • Considering to adopt; • Helping to define ; • Allowing Provider and Consumer to agree on ;
- 6. 6 Why a New Model? framework; • Describing both ; • Allowing to analyse different ; • Helping Cloud Consumer and Cloud Provider to agree on ; • Providing UML . with stereotypes for security concepts; • Allowing managing and replicas. • Presenting an useful model to describe ;
- 7. 7 Modelling Secure Interactions (1/2) An is defined as every kind of data exchange among actors in a Cloud System. It is made of the triple: <INVOKER, PROVIDER, TARGET> CC Cloud Consumer CP Cloud Provider S Service R Resource Interaction Description Interaction Type Interaction Modalities Securit y Level First CC’s registration to CP <CC,CP,CP> Web Console with username and password 1 - - Web Console with OTP 2
- 8. 8 Modelling Secure Interactions (2/2) are characterized by the triple: <THREAT, SECURITY REQUIREMENT, SECURITY MECHANISM> Threat Security Requirement Security Mechanism Packet Sniffing Confidentiality Routing Control Denial Of Service Availability Access Monitoring Wrapping Attack Authenticity Digital Signature SQL Injection Integrity, Confidentiality Parameterized Queries Man In The Middle Non repudiation Digital Signature
- 9. 9 Use Case and Misuse Case (1/2) model all kind of legitimate interactions that describe the whole application behaviour. Some issues can affect these interactions and it is important to specify security mechanism in order to prevent failures. model all the malicious behaviours witch can occur to the Cloud System. Misuse Case is meant as a sequence of action that a Cloud Consumer should not be able to perform. Hackers are able to perform a whole range of attacks to harm the Cloud environment, independently of the Use Case. These kinds of attacks are completely uncorrelated from Use Cases Interaction and can be expressed by Misuse Case.
- 10. 10 Use Case and Misuse Case (1/2)
- 11. 11 Stereotypes Stereotype Base class Description Web Service Subsystem, Component Service made available to users or developers on demand via the Internet from a Service Provider. Intrusion Detection Component Any kind of Intrusion Detection System that that monitors network or system activities for malicious behaviour or policy violations and produces reports to a management station. “Mode” attribute specify if it is used “Standalone”, as a “Probe” that only collects information or as a “Manager” that only receive information and correlates them to take decisions. “Type” attribute can specify the resource to monitor: “Network”, “Host” or “Hybrid” Load Balancer Node, component Software that distributes processing and communications activity evenly across a virtual computer network so that no single virtual machine is overwhelmed. Virtual Machine Node Resource that can be used to run applications and workloads. Disaster Recovery Component Actions to minimize the negative effects of a disaster and maintain or quickly resume critical functions. Data Loss Prevention (DLP) Component System designed to detect potential data breach and prevent them by monitoring, detecting and blocking sensitive data. Replica Component, Node, Subsystem Data or computation replication can be adopted in order to provide fault tolerance solutions. “Mode” attribute specify the replication mechanism: “Active”, “Passive”. “Type” attribute specify different passive replicas: “Primary”, “Backup”.
- 12. 12 Component and Deployment Diagram
- 13. 13 IDPS Rule Description (1/2) An can be expressed by three basic elements:
- 14. 14 IDPS Rule Description (2/2) IDS rule a . The condition that make true the considered rule is composed by events and rules using OR (+) and AND (X) operator. A rule or an event in grey means the negation of that.
- 16. 16 Case Study: Interaction Diagram
- 17. 17 Case Study: Use Case and Misuse Case : End User sends pictures to the Cloud service. : Hacker intrudes into a Virtual Machine and steals data from the storage.
- 18. 18 Case Study: Security Requirement Specification
- 19. 19 Case Study: IDPS Rules Description
- 20. 20 Case Study: Component and Deployment Diagram
- 21. 21 IDS Architecture for Cloud Computing receives information from Probes or lower-level SM; normalizes and correlates the events following rules; alerts Admin or sends alert to higher-level SM. Host Intrusion Detection System (HIDS) Network Intrusion Detection System (NIDS)
- 22. 22 IDS Prototype for Cloud Computing Security Information Event Management (SIEM) Host Intrusion Detection System (HIDS) Network Intrusion Detection System (NIDS) IDMEF IDMEF
- 23. 23 • Deriving all the and , splitting them in multiple interactions; • Considering all for each interaction specifying ; • Choosing the that match Cloud Consumer needs and Cloud Provider offers. • Making sure Cloud Provider adopt valid for each malicious interaction or think about additional security solution; • Representing application in the ; • Adding required to the diagram; • If required, designing new for detect and prevent the attack described; • If required, specifying type for a fault tolerance solution. Security Requirement Specification Model Briefly
- 24. 24 • Tool witch that best meets Cloud Consumer needs; • Software that analyses Security Reuirement and to adopt; • Automated Tool witch components to cover vulnerabilities; • Smart tool that for the adopted IDPS; • Engine witch from past events and adds new Rules. Suggestions for Future Works
- 25. Thank you for your attention
- 26. S Security Requirement Specification Model for Cloud Computing Services SECONDA UNIVERSITA’ DI NAPOLI FACOLTA’ DI INGEGNERIA Relatore Prof. Massimo Ficco Candidato Matteo Leonetti Matricola A18/064 Anno Accademico 2012/2013
- 27. What is Cloud Computing? (1/3) “Cloud computing is a model for enabling to a shared pool of configurable computing that can be rapidly provisioned and released with or service provider interaction.” NIST 27
- 28. What is Cloud Computing? (2/3) self-service • Broad access • Rapid service 28
- 29. What is Cloud Computing? (3/3) 29
Editor's Notes
- I vantaggi dell’utilizzo Cloud Computing sono noti a tutti, ma questo lavoro di tesi si è concentrato sui problemi più gravi di questo paradigma e sugli attacchi di cui è vulnerabile. Attualmente, in ordine di gravità, i problemi riscontrati sono: Il furto dei dati si verifica quando gli hacker riescono a prelevare dati sensibili come password o carte di credito. Nell’ultimo anno ad i server Nasdaq, Apple, Google e Facebook sono state vittime di questo attacco. 2) La perdita dei dati a causa di errori del Cloud Provider o di eventi catastrofici, nel Cloud, dove i dati non sono disponibili localmente, è un altro problema di non poco conto. 3) Tramite SQL Injection o Cross Site Scripting è possibile rubare l’identità di un Cloud Consumer e accedere a servizi altrimenti privati. L’account hijacking è possibile in ogni web application, ma nel cloud questo attacco può avere effetti più devastanti se l’account rubato è quello di un amministratore del cloud provider. 4) Il cloud ha più interraccie esposte ad attacchi esterni rispetto alle altre architetture. A seconda del service model vi sono api e intrfacce diverse. Queste permettono ad esempio di sviluppare applicazioni oppure gestire virtual machine o storage. Ovviamente più interfacce ci sono, più aumenta il rischio di attacchi. 5) L’attacco più frequente a qualsiasi sito web è sicuramente il denial of service in cui gli hacker inviano una quantità di richieste al servizio fuori dal comune, in modo da congestionare il servizio. Nel Cloud Computing questo attacco ha un triplice effetto: 1) il servizio è inaccessibile per tutti gli utenti e questo viola la qualità del servizio stipulata nelle SLA; 2) in un contratto pay-per-use, il consumer si trova a pagare una bolletta salatissima per l’elevato consumo; 3) a causa dell’elasticità, il provider assegna più risorse al servizio attaccato, privandone agli altri servizi che diverranno anch’essi irraggiungibili. 6) A livello infrastructure, platform o service gli hacker possono introdursi nel sistema e provocare danni o prelevare dati. E’ quello che è successo ad esempio nel 2013 a Verizon, il noto operatore telefonico statunitense. 2.12
- Quelli che abbiamo visto sono solo alcuni dei problemi che possono causare gli attacchi ad un sistema Cloud. Ma bastano per capire quanto sia importante la sicurezza in questo ambito. Questo lavoro di tesi vuole dare un contributo al campo della specifica dei requisiti di sicurezza. Perché è così importante? Innanzitutto la sicurezza è un aspetto trasversale da tenere in conto fin dal primo step del ciclo di vita di un software; Permette di evidenziare le vulnerabilità del sistema; Permette di definire i meccanismi di sicurezza da adottare e prevenire gli attacchi; Aiuta a definire la Qualità del Servizio Documento per la stipulazione delle SLA tra Cloud Provider e Cloud Consumer
- è stato effettuato uno studio su tutti i più rilevanti linguaggi di specifica dei requisiti di sicurezza proposti in letteratura. Tra i tanti modelli studiati, ce ne sono sicuramente alcuni molto validi, ma che non ricoprono pienamente gli obbiettivi proposti. Alcuni di questi li vediamo in questa slide. Si possono suddividere in base alla caratteristica principale che li cotraddistingue. Le due più grandi famiglie sono la prima, che mira a una specifica dei requisiti semplice e chiara anche per i non esperti. Ne fanno parte abuse case, misuse case e secure tropos. Lo svantaggio è che propongono diagrammi che diventano troppo complessi e difficilmente consultabili se i requisiti devono essere descritti in dettaglio. Poi ci sono i linguaggi mirati esclusivamente a descrivere gli attacchi come AntiGoal, AsmlSec e STATL. Sono itili per l’utilizzo di Intrusion Detection System, ma non per la specifica dei requisiti. Alcuni dei linguaggi forniscono un’estensione di UML come SecureUML e UMLIntr, il primo relativo alla specifica dei requisiti, l’altro agli scenari di attacco. Ma risultano piuttosto limitanti nelle loro caratteristiche. e infine c’è CORAS che fornisce un valido strumento per l’analisi dei rischi. 4 min
- Il modello che verrà presentato in questo lavoro ha alcune caratteristiche che lo rendono utile per la descrizione dei requisiti di sicurezza in ambiente cloud, ma può anche essere applicato in altri contesti. Il framework prentato in questo lavoro è stato pensato per essere indipendentemente dal service model e dal deployment model utilizzato, è applicabile sia dal punto di vista del cloud provider che da quello dello sviluppatore, ed è universale per tutti i cloud provider o il tipo di servizio che si vuole sviluppare. Si possono specificare sia le vulnerabilità insite nelle funzioni offerte dal servizio, sia i comportamenti malevoli e gli attacchi che si vogliono evitare; Ogni strumento garantisce un dato livello di sicurezza ed è importante analizzarli e scegliere quello che incontra i requisiti richiesti Risulta quindi più facile contrattare i Service Level Agreenment tra Cloud Consumer e Cloud provider; Il framework propone anche di descrivere tutti i servizi ed i componenti distribuiti nell’ambiente cloud tramite un diagramma uml; Grazie all’estensione fornita, il diagramma può essere infatti arricchito da nuovi stereotipi sui concetti di sicurezza; Questo permette di includere nella specifica dei requisiti anche concetti come Intrusion detection System e Falult Tolerance; Infine viene presentato un modello per la descrizione di regole valido per qualsiasi Intrusion Detection System
- Il modello per la specifica dei requisiti si basa sulle interazioni. Un’interazione è qualsiasi scambio di dati tra gli attori del sistema Cloud. Ad alto livello gli attori principali sono CC, CP, S, R. L’interazione è composta da Invoker (colui che invia la richiesta), Provider (colui che fornisce il servizio o è responsabile della risorsa), Target (l’oggetto o l’azione coinvolta nella richiesta) Ogni interazione può essere implementata con diverse modalità, ognuno con il suo livello di sicurezza offerto, che viene valutato utilizzando una delle tecniche proposte in letteratura.
- Un’interazione può essere affetta da un particolare problema di sicurezza, THREAT Il modello prevede quindi di specificare i requisiti di sicurezza per ogni interazione e proporre dei meccanismi validi per risolverli. La tabella ne mostra alcuni esempi
- Utilizzando le interazioni andremo a specificare Use Case e Misuse Case. Gli Use Case esprimeranno azioni legittime, essenziali per il corretto funzionamento del servizio. Queste possono essere affette da vulnerabilità e perciò ne esprimiamo i requisiti di sicurezza. I Misuse Case sono tutti quei comportamenti malevoli che potrebbero verificarsi in un’architettura cloud, indipendenti dagli Use Case. Questi attacchi devono essere considerati per adottare quindi struemnti di sicurezza adeguati.
- In questa slide vediamo un esempio della rappresentazione di use case e misuse case tramite le interazioni e come, nella terza colonna sia possibile specificare i requisiti di sicurezza e i meccanismi di sicurezza da applicare.
- Un altro strumento che offre questo modello è il component e deployment diagram che può essere arricchito di nuovi stereotipi riguardanti il l’architettura cloud e la sicurezza in generale. Questo ci consente quindi di rappresentare i componenti che fanno parte dell’applicazione, i servizi esterni e i meccanismi di sicurezza che si dovranno implementare nelle fasi successive dello sviluppo.
- In questa slide vediamo un esempio di quello che dovrebbe essere il component and deployment diagram arricchito dei nuovi stereotipi. In seguito lo analizzeremo meglio facendo riferimento ad un caso di studio.
- Se si utilizza un Intrusion detection and prevention system come meccanismo di sicurezza, sarà sicuramente utile definirne le regole sin dalla fase di requisiti e design. I tool che permettono l’aggiunta di nuove regole e la correlazione tra esse adottano formalismi diversi. In questo lavoro si è voluto trovare un modello per esprimere le regole che fosse generico e indipendente dal tool utilizzato. Gli elementi in comune in tutte le regole sono dati da: Attributi che caratterizzano la regola, come ad esempio il protocollo, il file log o la rete interessata, le condizioni affinché la regola sia vera, composti da eventi e regole correlate con logica booleana e l’azione da adottare nel caso in cui le condizioni si verifichino, espresse tramite una lista di operazioni.
- Se le regole da correlare sono molte viene proposta anche una rappresentazione ad albero che aiuta ad analizzare la composizione.
- Nel caso di studio prendiamo in considerazione un servizio cloud che permette agli utenti di inviare le foto da diversi dispositivi, e ricevere le stampe dopo aver effettuato il pagamento. Oltre al’interfaccia grafica e ai componenti interni, vengono sfruttati due servizi esterni per il pagamento e la stampa delle foto.
- Le interazioni tra i componenti sono le seguenti: l’end user invia le foto attraverso la GUI, queste vengono poste in una coda, poi vengono prelevate, ridimensionate e salvate nello storage da un apposito componente. L’end user può pagare attraverso la GUI che rimanda la richiesta al servizio esterno e una volta fatto si può inviare la richiesta di stampa al secondo servizio esterno che stamperà el foto ricevute e le invierà all’indirizzo dell’utente.
- Prendiamo in considerazione come Use Case l’utente che invia le foto al servizio cloud. Come Misuse Case un hacker che riesce ad introdursi in una virtual machine e ruba dati dallo storage. L’use case coinvolge cloud consumer (questa volta l’end user) che vuole sfruttare un srrvizio, il target di questa interazione. L’use case può essere affetto da un attacco di flooding o da malware injection. Il Misuse case coinvolge il cloud consumer (questa volta un un end user malizioso) che vuole sfruttare una risorsa fornita dal cloud provider. Questo misuse case ci permette di definire l’intrusione e la diffusione dei dati, che in questo caso vogliamo evitare.
- Use Case e Misuse Case vengono poi suddivisi in interazioni elementari che coinvolgono componenti interni al sistema. Qusto ci permette di specificare altri requisiti di sicurezza come ad esempio evitare flooding anche nella coda. I meccanismi di sicurezza che possono essere implementati sono: un controllo sulle richieste e un filtro sui file inviati per evitare flooding e malware injection. Un controllo sulla coda. E infine un Intrusion Detection System per evitare intrusioni e furto di dati.
- Per evitare l’intrusione si può specificare la regola che dovrà poi essere implementata nelle fasi successive dello sviluppo. La regola è vera quando si verificano due eventi: traffico sospetto rilevato dalla rete e prelievo di dati inusuale rilevato dallo storage. La reazione potrebbe essere quella di disconnettere la VM compromessa, attivare una istanza pulita del servizio e segnalare l’amministratore.
- Successivamente è possibile realizzare Il Component and Deployment diagram distribuendo i componenti dell’applicazione in diverse virtual machine. Una che riceve le richieste e tramite load balancer le smista a diverse istanze del servizio. Poi notiamo i servizi esterni che inseriamo nel grafico ma vengono visti un po’ come delle black box. Questo grafico serve per aggiungere i componenti di sicurezza richiesti grazie agli stereotipi forniti in questo lavoro. Vediamo ad esempio un componente di sicurezza software che dovrà essere sviluppato per controllare le richieste e filtarre i file caricati. Le tre repliche attive dello storage, pronte per essere sostituite se lo storage utilizzato smette di funzionare. Vediamo poi i componenti di un intrusion detection sistem distribuito. In cui c’è un manager centrale che riceve dati delle sonde, network e host che li raccolgono.
- L’architettura di IDS a cui si fa riferimento in questo lavoro è quindi quella dove vi sono Security Manager che ricevno informazioni dalle sonde o da SM di livelli inferiori, normalizzano e correlano eventi, per riconoscere gli attacchi attraverso delle regole salvate nel database. Eventualemnte avvisano l’amministratore o inviano la segnalazione alle SM di alto livello; Le probe non delle sonde che collezionano informazioni utili agli attacchi e le inviano al SM. Una Host Probe può essere realizzata con un Host IDS mentre una Network Porbe con un Network IDS.
- Infine è stato realizzato anche un prototipo di questa architettura, utilizzando solo tool open source. Prelude come SIEM per il Security Manager; OSSEC, un HIDS come Host Probe SNORT, un NIDS come Hetwork Probe. I tool collegati assieme, comunicano attraverso intrusion detection message excange format. Prelude tra i vari componenti ha Prewikka, un’interfaccia grafica utile all’amministratore per tenere sotto controllo il sistema.
- Cloud Computing è un termine che si utilizza per definire un insieme di tecnologie che permettono l’accesso a un insieme risorse disribuite, fornite da un provider al cliente. Possiamo distinguere due attori principali, il Cloud Consumer che ha delle necessità e utilizza servizi e risorse on line. E un Cloud Provider che fornisce servizi e risorse ai clienti finali.
- Le caratteristiche che ci consentono di riconoscere un sistema cloud sono essenzialmente 4: Il consumatore può richiedere i servizi quando li necessita, in modo automatico I srrvizi devono essere accessibili tramite internet da diverse piattaforme Il provider assegna risorse fisiche e virtuali in base alle richieste dei consumer L’elasticità permette di aumentare o diminuire in modo automatico la quantità di risorse in base alle reali esigenze L’utilizzo delle risorse può essere controllato e misurato sia dal provider che dal consumer
- Infine è importante menzionare i modelli con cui si possono classificare i sistemi cloud. Nel service model vediamo come alla base ci sia l’Infrastracture as a Service in cui il Cloud Provider fornisce le risorse basilari per permettere al Consumer di sviluppare la sua personale applicazione. Nel modello Platform as a Service invece il Consumer ha a disposizione librerie e diversi tool per lo sviluppo. Mentre al vertice della piramide vi è il modello “Software as a Service” in cui il Consumer non è a conoscenza delle risorse utilizzate dal Provider, ma ne sfrutta solo le applicazioni messe a disposizione. Risulta chiaro come più si sale nella piramide, più le responsabilità del Consumer diminuiscono e quelle del Provider aumentano perché deve garantire la qualità del servizio offrendo sempre funzioni sempre più complesse. Il deployment model indica come l’infrasruttura cloud possa essere accessibile a diversi gruppi di consumer. Una singola organizzazione nel caso del modello Private. Più organizzazioni nel caso del Community, pubblico oppure un modello ibrido.