3. Software Service, Composition and Security
• An increasing interest in deploying software applications as services
over the open communication channels
• A software offering a service exists independently - developed,
managed by third party service provider
• These services are aimed for direct integration with any application
system dynamically at run-time
• A service may be secure in one application system, but the same
service may not be secure in a different application due to different
security requirements
• The term `secure' is over-used and somehow misleading because it
does not state the specific type of security achieved
4. Research Problems
• End users with limited resources could compose application based on services which
are consistent with their security requirements.
• Services are normally associated with security features that are designed to withstand
certain security threats
• The representation of security properties for an end-user is quite different from those for
– a security expert, or
– a software engineer, or
– a different service consumer (end-user).
• The current practice may lead the service consumer to select a service that does not tell
much about its security assurances.
• The way the security features are implemented, embedded and presented is often too
complex for the service consumer to understand and use.
• Services most often use the notion of “one-size-fits-all’ security assurances.
• Consequently,
– Either service consumers do not use the services of which security properties are
not well understood, or
– The security properties remain unused or wrongly configured in the application
because these do not conform with the users security requirements.
5. Problems with Service Consumers
• Difficult for the service consumer to verify the conformity
of security properties between their security requirements
and the assurances of third party services.
• There are two explanations for this:
– Security properties are not specified in a form easily
comprehensible by the service consumer who perhaps has
limited knowledge of formal security technologies,
– A lack of a suitable framework with which they could select and
compose their application based on security profiles of services
and their security requirements.
• Service consumers may not have enough background
with formal education in computer science or security.
6. Research Issues
• How can a service consumer know that the
level of security assurances provided by the
selected service software would meet her
requirements?
and
• How can the consumer verify immediately that
the ensured security properties of the service
are consistent with her security requirements?
7. A Motivating Example
• Carol, a consumer, likes to book an item such as a hotel room, a car, or a
flight.
• The normal sequence of steps in a service-based application includes:
– Carol searches (a service) for her preferred reservation item, and selects
the item;
– Then she provides her details (another service to make the reservation);
– Makes online payment (a service too), and
– Finally receives a bar-coded digital receipt (a service) of reservation.
• In this journey of moving from one service to another in an integrated system
environment (composed of multiple services), Carol may have different security
requirements for each service she uses:
8. Security Requirements of Carol
a) For example, she wants her search parameters should not be used by anyone to
link with her identity (a security property called non-linkability).
b) She also prefers her name, phone number, email and home address kept
confidential (confidentiality).
c) She does not care if her suburb and street names are disclosed provided that
none could identify her or her home address with these two pieces of
information (non-deducability).
d) She also likes to have a guarantee that her credit card number is kept secret
(confidentiality), and on one should be able to alter the amount she paid
(integrity).
e) Carol also wants that no unauthorized entities are able to see (privacy) and make
a copy of her receipt (authorization).
f) Finally, she needs an assurance that none could observe her activities in the
Internet (non-observability).
• We can see that Carol has very specific security requirements in this scenario.
• Likewise, another consumer John, may have different requirements from Carol
of the same reservation software system.
• How do we handle these types of diverse security requirements?
9. Research Objectives and Approaches
• Our work attempts to address the following research challenges project:
– How to make security assurances of service software transparent to consumers
– How to enable consumer select their security choices; and
– How to check the security compatibility of the selected security for services.
Our approach has three main processes:
– Reflection of security assurances
– Selection of preferred assurances; and
– Checking of security compatibility.
10. Reflection of Security Assurances
• Mechanisms for reflecting the security assurances of services.
• Security provisions and requirements are published together with
their service descriptions
• Security characterization called security profiles
• Attaching the security profile with service interfaces.
• Stakeholder-based view
11. Levels of Implemented Security Functions
Development
Characterising ISO/IEC stage
Service
development security properties of 15408
services Common
criteria
Composition
stage
Establishing Reasonin
Systems
composition compositional g
security properties language
Operational
Execution Deriving consumer- Security stage
level security goals Goal
Time
12. Stakeholders of Services
Design and Development of
Service developers services Development
and
deployment
Security designer Analysis of security threats
and implementation policies
Software engineer Discovery of services and
functional integration Operation
and
Service consumer Composition
User of composed
application
Time
13. Four Perspectives of Service Security
Service consumer
Specific security objectives actually achieved at the system-level
(Operational time)
Software engineer
Interested in the compositional impact and conformity of the
security properties (Composition time)
Security designer
Focuses technical details of the component security such as
encryption
Identifies the threats of the component, define the security
policies and functions (service development time)
Service developer
Design, build, deploy and manage services. (service design deployment
time)
15. Selection of Preferred Assurances
• Services should provide a choice of security assurances.
• Capability that enables the consumer to select their preferred
security assurances
• Security profile must reflect the actual implementation of security
functions
16. Checking of Security Compatibility
• Security compatibility between interacting services are automatically
analyzed
• Conforms that they satisfy each other's security requirements.
• Ensure that the selected security properties work without
compromising service security provisions.
17. Concluding Remarks
• Our framework has three anticipated innovative aspects.
– The first innovative aspect is that we approach security from a (service-
based) software engineering perspective
• Adopt a proactive and predicative line of thinking.
• We emphasize on the service consumer's understanding and selection
capabilities of service security properties
– The second innovative aspect is that the framework provides a semantic
model that is essential to reason about the effectiveness of the selected
security assurances
– The final aspect is the formal analysis techniques for security compatibility
allow us to check automatically if the services in a composition are
compatible in terms of security features
• Leads to compatible security-aware composition. This is critical to
providing assurance to system users about the systems security
behavior,
• Nurtures confidence and trust in the business community about service-
based system security.
