Modeling Security Requirements Through Ownership, Permission and
Delega=on
Paolo Giorgini, Fabio Massacci, John Mylopoulos University of Trento
Nicola Zannone
Eindhoven University of Technology DelA University of Technology
Mo=va=on • In 2005, mainstream approaches to security design focused
on iden=fying security requirements aDer system design; and even today an overwhelming focus is s=ll on system security.
• Security solu=ons have to fit a pre-‐exis=ng design – may not be able to accommodate them; – security requirements may conflict with func=onal and quality requirements;
• Social concepts are fundamental to building secure systems – Security is oDen compromised by exploi=ng vulnerabili=es in the social part of a socio-‐technical system.
Once upon a =me
Università degli Studi di Trento
Some Ideas… we don’t like • Idea 1
– Add primitives/constraints to Tropos/Kaos/name-your-pet-RE-formalism for the various security requirements
– Confidentiality, authentication, access controls or so on are security services and mechanisms NOT security requirements!
– ACID Transactions are a DB service not a IS requirement…
• Idea 2 – Model security requirements separately from functional requirements – This is exactly the problem everybody is ranting about
• Idea 3 – Model the goals of the attacker – They are not the goals of the security engineer!
Università degli Studi di Trento
Some ideas… we like • Hunch 1
– Security Requirements are social requirements • Hunch 2
– We must model at the same time Functional Requirements and Security Requirements
– So we can see the interplay of both and check one does not get in the way of the other
• Occam’s Razor – Add few primitive constructs – Other security requirements as patterns, services, mechs
We were not the first to address SRE
• Early RE models (SREs using “vanilla”RE) – [3] Anton, Privacy reqs with privacy goals. RE’02 – [6] Crook+. SREs as an=-‐reqs. RE’02. – [19] Liu+. SREs with goal models. RE’03 – [25] Toval+. Legal reqs. RE’02
• SRE specific graphical model but no logic – [9] Fredriksen+ CORAS for risk assessment. SAFE-‐COMP’02 – [22] McDermo_ & Fox. Abuse Cases. ACSAC’99 – [24] Sindre & Opdahl. Misuse Cases. TOOLS' 2000
• Logic and tool for security but no model – [11] Gans+. Trust and Distrust in Agents. AOIS’01 – [15] Jones & Sergot Formal Ins=tu=onalised Power. JGPL 1996. – [18] Li+. Trust-‐management Framework. IEEE SSP'02
• Logic, graphical model and tool but focus on system – [16] Jurjens. UMLSec. 2004. – [20] Lodderstedt+ SecureUML. UML’02 – [26] van Lamsweerde+ An=-‐Goals. RHAS’03
Contribu=ons of our proposal
• The first work providing (at the same =me): – a Security specific (and novel) ontology for talking about an important class of security requirements, namely ownership and permissions
– a coherent graphical representa=on for both func=onal and security requirements
– a reasoning technique for formal requirements analysis • CASE tool support • Cross communi=es
– Requirements Engineering – Security
Security-‐specific Ontology
• Permission != Execu=on – Authority vs. Responsibility
• Ownership != Provisioning – Dis=nguishing who can fulfill a goal from who is en=tled to decided who can fulfill a goal
• Trust rela=onship between actors – Dis=nguishing trusted actors from untrusted actors
• Delega=on rela=onship between actors – Formal transfer of authority/responsibility
Graphical Representa=on
O: owns P: provide R: request Dp: permission delegation De: execution dependency Tp: trust of permission Te: trust of execution
Trust diagram
Operational diagram
Formal Reasoning • Formal Model
– Answer Set Programming (aka Datalog¬) • Axioms
– Intensional proper=es and rules • Models (SI* diagrams)
– Extensional proper=es of classes (and instances) • Proper=es
– Formulas that may be in true or may not be true – Availability (3), Confiden=ality (1), Authoriza=on (3), Avail+Auth (3), Privacy (1)
– eg Need-‐to-‐know: all actors which have been delegated a permission to fulfill a goal has also been delegated the execu=on of the goal (directly or indirectly)
CASE tool support 2005-‐2006 -‐à RE’05 Tool Paper
2007-‐2011 2012…
Beyond the =p of the iceberg
Ontology Formal
Reasoning Meth. CASE tool Case studies
Security Pa_erns
Access Control Privacy
Risk Analysis
RE 2005
RE 2006
ASE (2007)
iTrust 2005 ESORICS 2005
FOSAD 2005
CS&I (2005)
iTrust 2005 (Demo)
RE 2005 (Demo)
IJSEKE (2007)
OTM 2008
RE 2007
ICAIL 2007
STM 2008
VLDB J (2006) CAiSE 2006
IJIS (2006)
ARES 2007
ASE (2008)
IJBIDM (2008)
ARES 2008
IJSEKE (2009)
IJSSE (2011)
MIT (2011)
AIL (2008)
Adv. in Int. Inf. Sys. 2010 CEC 2011
IDEA (2006)
EuroPKI 2004
Involving Industry • Several studies in joint research projects
– SAP (SERENITY, MASTER, TAS3) – Thales (SECURECHANGE, ANIKETOS) – ATOS (MASTER,ANIKETOS) – Engineering SpA (SERENITY, MASTER) – Bri=sh Telecom (MASTER) – DBlue (SERENITY, SECURECHANGE, ANIKETOS) – Na=onal GRID (SECONOMICS)
• A painful road to humility • The realm of measurable value and the academically unexpected…
What is important in a tool for industry?
• Our Expecta=on [RE’05] – “In addi=on, the tool provides a user-‐friendly interface to the DLV
system and permits a designer to select proper=es of each model and to specify addi=onal security policies. The resul=ng Datalog specifica=ons are automa=cally verified by the DLV system.”
• VM, former Air Traffic Controller, Expert in Human Factors for Safety, 35+ years of experience, CTO of small company – “Your tool has a bug. We were verifying a safety pa_ern and a window
popped up with… you know that Windows error… Ax07F12” – Well, it was not actually a bug, the window presented a datalog
formula showing how trusted delega=on would not hold • S=ll “debugging it” aDer 10 years
– E.g. Formal method is there but has to be “transparent”
tool != model stencil • Meta-‐Models not just Graphics
– Different Industries à different graphics conven=on • Air Traffic Management vs Business Processes
– Must have a flexible meta model for plugging different models • Interface with Reasoning Capabili=es
– Different applica=ons à different reasoning reqs • untangle trust rela=onships vs compute risk values
– Interface with different reasoners might be needed • Process Support
– Main lesson from eRISE Challenge • evalua=ng SRE methods with professionals and students
– You can’t just leave dudes figuring out what to do next and whether they wrote is a ‘model’ or a ‘pile of gibberish’
• Automa=c report genera=on in a pdf – Yes, that’s measurable value (wri=ng reports is expensive!)
Behind the =p of the iceberg
Ontology Formal
Reasoning Meth. CASE tool Case studies
Security Pa_erns
Access Control Privacy
Risk Analysis
RE 2005
RE 2006
ASE (2007)
iTrust 2005 ESORICS 2005
FOSAD 2005
CS&I (2005)
iTrust 2005 (Demo)
RE 2005 (Demo)
IJSEKE (2007)
OTM 2008
RE 2007
ICAIL 2007
STM 2008
VLDB J (2006) CAiSE 2006
IJIS (2006)
ARES 2007
ASE (2008)
IJBIDM (2008)
ARES 2008
IJSEKE (2009)
IJSSE (2011)
MIT (2011)
AIL (2008)
Adv. in Int. Inf. Sys. 2010
CEC 2011
IDEA (2006)
SoDware Engineering
EuroPKI 2004
Security
Impact of this work on others
• Legal requirements: our ontology provided a baseline for the defini=on of ontologies for modeling legal requirements
• Trust management: inspired methods for elicita=on, specifica=on and analysis of trust requirements
• Security paFerns: inspired the defini=on of security pa_erns at organiza=onal level
Google Scholar (200 cit.)
Security
Informa=on Systems and DB
Other
Sample Cita=on Venues (>2cit)
What happened next? RE’05 -‐ Modeling Security
Requirements
What to do with elicited SRs?
How to manage complexity?
How to close the gap to design?
Does it really work in prac=ce?
A MIT Press Book
You elicited, so what? • Realiza=on of security and trust requirements • Two inspiring follow-‐ups:
– (2008) A Model-‐Driven Approach for the Specifica=on and Analysis of Access Control Policies
– (2006) Hierarchical Hippocra=c databases with minimal disclosure for virtual organiza=ons
• Ongoing research direc=ons – Access control for distributed and collabora=ve systems
• automo=ve, cloud, smart grid, social networks, systems of systems – Privacy compliance – Anomaly detec=on and analysis – Trust management
• Creden=al-‐based, reputa=on-‐based
How to manage complexity? • You can’t just plug everything into a model • Mul=-‐view Socio-‐Technical Security (STS)
– Social, Informa=on and Authoriza=on views
• From STS specifica=on down to BP design and security enforcement – Security requirements refinement
• Visual Privacy (EU H2020 Project) – Visual models for informa=on owners
And the gap towards architecture?
• Vanilla security analysis focuses on the system level; in our RE’05 paper we focused on the social level.
• But a_acks oDen strike at the weakest link of a socio-‐technical system, social, system or infrastructure, and nowadays are oDen composite.
• Tong Li (PhD student, UniTN) is developing a holis=c security analysis framework that supports analysis across all three levels.
• His analysis uses an=-‐goals and a_ack pa_erns from public domain repositories.
Does it really work? • Full fledge security requirements engineering is oDen too
costly (Industry paper at ESEM’14) – We need empirical protocols to evaluate RE models & methods, and understand what works, what doesn’t work and why à K. Labunets (PhD @ UNITN)
• Is Process is more important than graphics? (NordSec’12) • Is Percep=on everything?
– Graphical SRE method are systema=cally perceived as superior to tabular SRE methods (ESEM’13,EMPIRE’14)
– But there is no diff in actual result when industry people evaluate the final outcome (EMPIRE’14)
– What about comprehension? (Watch this space) • Do catalogues make a difference? (REFSQ’15)
Take Away Messages • Security & func=onal reqs can be elicited together
• Social models have a place in Security RE • Representa=on, Reasoning, Running Code
– You need all three to make an impact – Just adding the label “S” for “Security” to your pet RE method doesn’t make it a SRE
• Industrial evalua=on is not the ‘last mile’ is the ‘last light year’
• Security & func=onal reqs can be elicited together • Social models have a place in security requirements analysis • Representa=on, Reasoning, Running Code
– You need all three to make an impact – Just adding the label “S” for “Security” doesn’t make it a SRE
• Industrial evalua=on is not the ‘last mile’ is the ‘last light year’
