Profile based security assurance for service
0 likes405 views
This document discusses research problems with enabling service consumers to select software services that meet their specific security requirements. It proposes a framework with three main processes: 1) Reflecting security assurances of services using security profiles to characterize properties from multiple stakeholder perspectives. 2) Allowing consumers to select preferred assurances. 3) Automatically checking compatibility between services' security properties and requirements. The goal is to make security transparent and allow compatibility verification to empower consumers to build secure applications.
Profile based security assurance for service
- 1. IESS 1.1 Geneva 2011 Profile-based Security Assurances for Service Software Khaled Khan Computer Science and Engineering Qatar University Qatar
- 2. Overview • Context • Stakeholders of services • Research problems • Motivating Example • Proposed framework • Conclusion
- 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)
- 14. Abstraction Level of Security Properties
- 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.