On Security Requirements Analysis for MultiAgents Systems

1
On Security Requirements Analysis for
Multi-Agents Systems

• Paolo Bresciani
• ITC-irst, Trento (Italy)
• Paolo Giorgini
• University of Trento (Italy)
• Haralambos Mouratidis and Gordon Manson
• University of Sheffield (UK)

2
Presentation Layout

• Security in (AO) software engineering
• Security in Tropos
• The methodology
• Security in Tropos
• Proposed Extensions
• The eSAP example
• Future Work and Conclusions

3
Security in organizations and IS

• Organizations are for many reasons concerned with
  security issues, and adopts specific policies
  defined in terms of properties such as
• Confidentiality, Authentication, Access Control,
  Non-Repudation
• These organizational security properties can
  naturally be mapped into corresponding properties
  of the organization IS
• thus
• The security requirements of the IS can be
  obtained after studying the security policy of
  the organization

4
Security in Software Engineering

• Currently, in SE the definition of security
  requirements is usually considered after the
  design of the system
• This means that security enforcement mechanisms
  have to be fitted into a pre-existing design
• SE considers security requirements, as
  Non-Functional Requirements
• Security Requirements represent
• Quality characteristics
• Constraints under which the system must operate

5
Why Integrate Security?

• Security requirements affect the development of
  the system
• Restrict alternative design solutions
• Conflict with other requirements of the system
• Refine existing goals of the system or
  introducing new ones
• Taking security requirements into account
  throughout the development stages, since RE,
  helps to limit the cases of conflict, by
  identifying them very early in the system
  development and find ways to overcome them.
• Adopt a security focus through the overall system
  development, since RE

6
Security and AOSE

• The agent-oriented paradigm represents a feasible
  option for the integration of security to
  software engineering
• BUT
• None of the existing methodologies, have been
  demonstrated enough evidence to support claims of
  modelling security during the whole software
  development stages

7
Tropos

• Agent-Oriented Software Engineering Methodology
• It is strongly requirements driven and describes
  both the environment of the system and the system
  itself
• Covers four phases of development
• Early Requirements
• Late Requirements
• Architectural Design
• Detailed Design

8
Tropos Concepts

• Actor
• Entity that has strategic goals
• Social or Artificial (HW or SW) agent, role,
  position
• Goal
• Actors strategic interests
• Soft goal not clear criteria whether satisfied
• Task
• A way of doing something

9
Tropos Concepts (2)

• Resource
• A Physical or an informational entity
• Dependency
• Indicates that an actor depends on another in
  order to achieve some goal,

10
Security in Tropos

• Tropos is originally not conceived with security
  on mind
• Non-Functional (security) requirements can
  partially captured in terms of soft goals
• BUT
• Ad Hoc Process (soft goal are too generic)
• Fails to capture Constraints

11
Extending Tropos to Model Security

• Security Diagrams use the notions of
• Secure Entities (goals/tasks/resources)
• Secure Dependencies
• Security Constraints

12
Security Diagram

• Captures
• Security needs (e.g. desired security features)
• Problems related to the security of the
  system(e.g. threats)
• Possible solutions (e.g. security mechanisms)

13
An example the eSAP System

• an electronic system to deliver an integrated
  assessment of health and social care needs of
  older people
• different health care professionals, such as
  general practitioners, nurses and social workers,
  must cooperate together in order to provide
  patients (older people) with appropriate care

14
eSAP Actors

• Four main actors
• Older Person
• Professional
• Department of Health (DoH)
• Research and Development (RD) Agency

15
Actors Diagram
16
Security Constraints

• Constraint related to the security of the system
• Positive Security constraints
• E.g. Allow Access only to Personal Information
• Negative Security Constraints
• E.g Send Personal Information Plain Text
• Imposed by stakeholders (early requirements)
• Imposed by the security diagram (late
  requirements)
• Identify conflicts between security and other
  requirements

17
Professionals Goal Analysis
18
Criticality and Complexity

• Security Criticality
• how much the failure of a constraint may affect
  the global system security
• Security Complexity
• the cost of attaining a constraint by an actor
• System Complexity
• the cost of attaining a dependum
• Actors Criticality and Security/System
  Compelxity
• total incoming security criticality
• total security complexity / system complexity for
  give Actor

19
Actor load capability

• Each actor is characterized by a maximum load
  capability for
• security criticality (how important and reliable
  is that actor?)
• security complexity (how much can he deal with
  security?)
• system complexity (how much can he deal with his
  duties?)
• NOTE only system complexity is considered next.

20
The reconfiguration problem

• If in an actor diagram one (or more) actors
  exceeds its load capability, how can the diagram
  be reaconfigured?
• Reassign one or more dependums
• Introduce new actors
• In any case, minimal transformations are preferred

21
The solution

• Representing the problem
• Cost matrix CoM1..n,1..m
• Maximum load vector M_CoV1..n
• Assignment (boolean) var. matrix A1..n,1..m
• Actors load Compl(i,A)CoMi,jAi,j
• Local and global reassignment algorithmsRebalanc
  e_Intransitive, Try_one_Actor,Rebalance,
  Try_Transitive

22
Algorithms (just a sample)

• Function Reballance_Intransitive (var
  Aass_matrix)boolean
• Begin resultfail
• SET_OF_UNBALLANCEDiCompl(i,A)gtM_CoVi
  
• if empty(SET_OF_UNBALLANCED) then
  resultOK
• else begin
• copy_of_AA
• while resultfail and not
  empty(SET_OF_UNBALLANCED) do
• begin
• iPOP(SET_OF_UNBALLANCED)
• if Try_One_Actor(i,1,A)OK then
• begin resultReballance_Intransitive(
  A)
• if resultfail then
  Acopy_of_A
• end
• end
• end
• RETURN result
• end

23
Summary

• Security plays a relevant role in
  modern/distributed IS
• AOSE is a promising approach to deal with
  security since RE and along all the phases
• Tropos is a privileged candidate to provides such
  services
• An appropriate Tropos extension to deal with
  security issues has been introduced and here
  extended with computational services

24
Conclusions

• Work so far is promising
• Tropos facilitates the consideration of security
  requirements
• Main Aim
• To provide a clear well guided process of
  integrating security and functional requirements
  throughout the development stages

25
Future Work

• Prove algorithm properties, implement and test it
• Propagate the extension to other phases
• Assign Secure Capabilities
• In architectural Design
• Design the System considering the security
  analysis of the previous stages
• (Using AUML notation)