Скачать презентацию Service-Oriented Architecture Security Computer Science and Engineering 1 Скачать презентацию Service-Oriented Architecture Security Computer Science and Engineering 1

a1b3b1b8436882de49fed3b6bfdda167.ppt

  • Количество слайдов: 47

Service-Oriented Architecture Security Computer Science and Engineering 1 Service-Oriented Architecture Security Computer Science and Engineering 1

Reading 1. 2. 3. 4. 5. T. Erl, SOA Design Patterns, Chapter 13 F. Reading 1. 2. 3. 4. 5. T. Erl, SOA Design Patterns, Chapter 13 F. A. Cummins: Building the Agile Enterprise with SOA, BPM, and MBM, Chapter 6 G. Mc. Graw, Software Security and SOA: Danger, Will Robinson!, IEEE Security and Privacy, 2006, http: //www. cigital. com/papers/download/bsi 12 soa. doc. pdf Organization for the Advancement of Structured Information Standards (OASIS), http: //www. oasis-open. org/ (SOA, Security, WS, XML, etc. ) World Wide Web Consortium (W 3 C), http: //www. w 3. org/ (Web design and applications, Web architecture, Semantic Web, XML, WS, etc. ) Computer Science and Engineering 2

SOA Security Components 1. Software-level (single service) security 2. Business-level (service composition) security 3. SOA Security Components 1. Software-level (single service) security 2. Business-level (service composition) security 3. Network-level security Computer Science and Engineering 3

Security Concerns • • Expanded number of service points Expanded number of users Perimeter Security Concerns • • Expanded number of service points Expanded number of users Perimeter security is not sufficient Dynamic service relationships Access across trust domains Electronic documents Indirect access via service invocation

Web Services • Goal: enable autonomous and distributed entities to Goal collaborate efficiently, reliably, Web Services • Goal: enable autonomous and distributed entities to Goal collaborate efficiently, reliably, cost-effectively, and comply with regulations • Characteristics: open and heterogeneous environment, Characteristics loose coupling, code reuse, standard-based interfaces, platform independent & language neutral • Support for: for – Data & Information Sharing – Automated processing – Web with a meaning – Express business logic Computer Science and Engineering 5

Secure SOA Development • Inherent Security of Web Services • Security granularity Security Software Secure SOA Development • Inherent Security of Web Services • Security granularity Security Software Security Computer Science and Engineering 6

WS Security Standards • OASIS Web Services Security (WSS) – Integrity and authentication: sign WS Security Standards • OASIS Web Services Security (WSS) – Integrity and authentication: sign SOAP msgs. – Confidentiality: encrypt SOAP msgs. – Attach security tokens • Security tokens • • • Security Assertion Markup Language (SAML) assertions Kerberos tickets User credentials X. 509 certificate Custom defined tokens Computer Science and Engineering 7

Software Security Computer Science and Engineering 8 Software Security Computer Science and Engineering 8

SOA Applications • Aggregated services each component is vulnerable • What is the level SOA Applications • Aggregated services each component is vulnerable • What is the level of security provided by the aggregate? – Trust management • Security Patterns (REFERENCE #1) – – Exception Shielding Message Screening Trusted subsystem Service Perimeter Guard Computer Science and Engineering 9

Secure Software Development • Develop software that is free of flaws – Software engineering Secure Software Development • Develop software that is free of flaws – Software engineering – functional requirements – Security, reliability, Qo. S – non-functional requirements • Protect against malicious code • Reading: Reading – G. Mc. Graw, Software Security , http: //www. cigital. com/papers/download/bsi 1 -swsec. pdf – US National Security Agency: System Security Engineering CMM (SSE CMM), http: //www. sse-cmm. org/index. html Computer Science and Engineering 10

Software Security during SDLC External Review 6. Security Requirements 2. Risk Analysis 4. Risk-Based Software Security during SDLC External Review 6. Security Requirements 2. Risk Analysis 4. Risk-Based Security Tests 3. Penetration Testing 1. Code Review (Tools) 5. Abuse cases Requirement and Use cases 2. Risk Analysis Architecture and Design Test Plans Code Tests and Test Results 7. Security Operations Feedback from the Field From: G. Mc. Graw, Software Security Computer Science and Engineering 11

Open Web Application Security Project (OWASP) • Non-for-profit, worldwide organizations • Goal: improve the Open Web Application Security Project (OWASP) • Non-for-profit, worldwide organizations • Goal: improve the security of application software Goal • All materials: available under a free and open software license • Common Weakness Enumeration (CWE): list of software weaknesses – Full dictionary view – Development view – Research view Computer Science and Engineering 12

Exception Shielding • Goal: prevent the disclosure of information about the Goal service’s internal Exception Shielding • Goal: prevent the disclosure of information about the Goal service’s internal implementation via exception data • Problem: Problem – Exception data released by a service may contain internal implementation details – Malicious users may exploit this data to compromise the service and its environment • Solution: replace unsafe data with data that is safe by Solution design Computer Science and Engineering 13

Improper Error Handling • OWASP “A 7 Improper Error handling, ” 2007, http: //cwe. Improper Error Handling • OWASP “A 7 Improper Error handling, ” 2007, http: //cwe. mitre. org/data/definitions/728. html • Variants: – Yielding too much information – Ignoring errors – Misinterpreting errors – Using useless error values – Handling the wrong exception – Handling all exceptions together Computer Science and Engineering 14

Redemptions – SDLC • • Handle exceptions in application code Do not group exceptions Redemptions – SDLC • • Handle exceptions in application code Do not group exceptions Check return values when appropriate Time to target problem: – Design – Code review – Testing Computer Science and Engineering 15

Redemption – SOA pattern • Unsafe data is “sanitized” sanitized • Routines added to Redemption – SOA pattern • Unsafe data is “sanitized” sanitized • Routines added to the service logic to perform the sanitization • Need: pre-defined exception details that are “safe by design” • During: – Design time – Run time Computer Science and Engineering 16

Sanitization Process Server Customer submits a request message Server: attempts to process The request Sanitization Process Server Customer submits a request message Server: attempts to process The request and throws an Exception Shielding Routines: Evaluates exception data and Replaces it if unsafe Customer Server returns safe exception message Computer Science and Engineering 17

Exception Shielding • A form of utility logic • Supported by: Service Agent, Utility Exception Shielding • A form of utility logic • Supported by: Service Agent, Utility Abstraction, and Service perimeter Guard • Impact: Impact – Extra processing cost – Targets dangerous vulnerability – Incorrect application (e. g. , only some of the exceptions are addressed) may lead to a false sense of security Computer Science and Engineering 18

Message Screening • Goal: protect a service from malformed or malicious Goal input • Message Screening • Goal: protect a service from malformed or malicious Goal input • Problem: Problem – Malicious user may violate service security or take over the control of the service and its environment • Solution: assume all input data is harmful and screen Solution before using it Computer Science and Engineering 19

Input Validation • OWASP: CWE-20: improper Input Validation, http: //cwe. mitre. org/data/definitions/20. html • Input Validation • OWASP: CWE-20: improper Input Validation, http: //cwe. mitre. org/data/definitions/20. html • Problem: no or improper validation of input that can affect Problem control flow or data flow of a program • Variants: Variants – Buffer overrun – Integer overflow – Command injection – SQL injection • Reading: G. Hoglund and G. Mc. Draw, Exploiting Software: How to Break Code, Chapter 7 Buffer Overflow, http: //searchsecurity. techtarget. com/search. Security/downloads/E xploiting Software-Ch 07. pdf Computer Science and Engineering 20

Impact • Availability: malicious input may Availability – Crash the program – Exhaust resources Impact • Availability: malicious input may Availability – Crash the program – Exhaust resources (e. g. , memory, CPU) • Confidentiality: attacker may be able to access Confidentiality confidential resources • Integrity: attacker may Integrity – Modify data – Alter control flow – Execute arbitrary commands Computer Science and Engineering 21

Redemption – SDLC • • • Always validate data Stop using unsafe commands, e. Redemption – SDLC • • • Always validate data Stop using unsafe commands, e. g. , strcpy, strncat, etc. Understand casting and operators Use “white list” list Static analysis tool Manual analysis – design level Computer Science and Engineering 22

Redemption – SOA Pattern • Assume all input data is harmful until proven otherwise Redemption – SOA Pattern • Assume all input data is harmful until proven otherwise • Use specialized threat screening routines • Routines invoked when input data is received by any service capability • Standard screening tasks: – Compare the size of the input against the allowable size – Parse the entire input for malicious content Computer Science and Engineering 23

Other Considerations about Screening Routines • Screening requires the decryption of encrypted traffic • Other Considerations about Screening Routines • Screening requires the decryption of encrypted traffic • Must be able to handle all types of attachments to evaluate malicious content • Must be very efficient – not a bottleneck • Related to Utility Abstraction and Service Agent isolate message screening routine into a separate utility service • Vulnerabilities of XML messages (data types, data content, limited XML parser support) Computer Science and Engineering 24

2010 CWE/SANS Top 25 Most Dangerous Programming Errors • URL: http: //cwe. mitre. org/top 2010 CWE/SANS Top 25 Most Dangerous Programming Errors • URL: http: //cwe. mitre. org/top 25/ • List of 25 most dangerous programming errors leading to software vulnerable to malicious attacks • Result of collaboration between the SANS Institute, MITRE, and many top software security experts in the US and Europe • Aims to help – – Programmers to prevent well known software vulnerabilities Software customers to ask for more secure software Researchers to focus on important problems Software managers and CIOs to measure their improvement in software security Computer Science and Engineering 25

Network-Level Security • Authentication and identification • Access Control • Messaging middleware – Communication Network-Level Security • Authentication and identification • Access Control • Messaging middleware – Communication security – End point security • Protocol assurance • Security Patterns – Trusted subsystem – Service Perimeter Guard Computer Science and Engineering 26

Authentication using Digital Certificate • Simplified network protocol to support authentication between Requesing party Authentication using Digital Certificate • Simplified network protocol to support authentication between Requesing party (R ) and Service (S) 1. R → S: submits digital certificate 2. S: checks validity of certificate: issuer, time, revocation info. If the certificate is valid, then 3. S → R: sends a “nonce” encrypted with the public key in the certificate 4. R → S: returns the “nonce” and other info 5. S: verifies “nonce” • • Result: S authenticates R Two-Way Authentication

Single Sign-On • Authentication of a user within multiple systems: use Digital Certificates and Single Sign-On • Authentication of a user within multiple systems: use Digital Certificates and private keys • Reduces security administration • Services can pass requester’s identity to other services

Access Control Extended RBAC • Extend RBAC with authorization attributes • Attributes are referenced Access Control Extended RBAC • Extend RBAC with authorization attributes • Attributes are referenced within policies – Credentials, certifications, etc. • Role hierarchy: inheritance of privileges • Security roles vs. access control roles • SOA: need to authorize people as well as systems • Other issues: – Grant and revoke – Delegation of privileges

Access Control Administration • Centralized access control – Role engineering – Optimal role allocation Access Control Administration • Centralized access control – Role engineering – Optimal role allocation and assignments – Protecting access control documents – Dealing with grant and revoke, and delegation • Distributed access control – Global consistency – User identification – Role assignments/subject switching

Federation of Trust Domains • • • Participants from multiple trust domains Establish trustworthiness Federation of Trust Domains • • • Participants from multiple trust domains Establish trustworthiness using other domains WS-Federation – Cooperative relationship between trust domains – Simplified protocol for cross domain credentials: 1. 2. 3. 4. 5. 6. P: Participant (P) requests access to domain (R) R: locates the participant’s (P) home domain (H) H: provides P’s credentials according to sharing policy R: accept the identity of P (temporary entry) R: transforms P’s credentials from H to its local requirements, preserves credentials for subsequent requests R: responds to P’s initial request

Trusted Subsystem • Goal: prevent customers from circumventing a service Goal and directly accessing Trusted Subsystem • Goal: prevent customers from circumventing a service Goal and directly accessing the resources of the service • Problem: Problem – Customer may perform incorrect modifications – May lead to undesirable forms of implementation coupling • Solution: service is designed to use own credentials for Solution authentication with backend resources Computer Science and Engineering 32

Impact • Compromised service may allow access to unauthorized users • Protocol for accessing Impact • Compromised service may allow access to unauthorized users • Protocol for accessing remote resources 1. Authenticate and authorize the message 2. Send a request to the remote resource, accompanied with the services’ own credentials 3. Issue the appropriate issue to the customer Computer Science and Engineering 33

Implementation Variants • Service accounts within the trusted subsystem • Local accounts are used Implementation Variants • Service accounts within the trusted subsystem • Local accounts are used on each host • Use digital certificate (e. g. , X 509 PKI) for authentication in the trusted subsystem • Use IPSec to provide secure communications. Computer Science and Engineering 34

Perimeter Guard • Goal: protect internal resources from users that Goal remotely access internal Perimeter Guard • Goal: protect internal resources from users that Goal remotely access internal computers • Problem: Problem – External attacker may gain access to services running within a private network, and thus to the resources within the private network • Solution: establish an intermediate service at the Solution perimeter of the private network as a secure contact point Computer Science and Engineering 35

Demilitarized Zone (DMZ) • Perimeter Service: – Operates at application layer – Work in Demilitarized Zone (DMZ) • Perimeter Service: – Operates at application layer – Work in conjunction with existing firewall technologies – Hide internal service details • External customer: corresponds with the perimeter customer service’s external contracts • Internal service: response is relayed to the customer by service the perimeter service

Impact • Extra cost of – Processing overhead – Complexity • Single point of Impact • Extra cost of – Processing overhead – Complexity • Single point of failure • Perimeter service represents a point of isolation. Effects: direct authentication, brokered authentication, Effects and message screening

Service-Composition Security • Ongoing activities: activities – Business process execution across heterogeneous domains – Service-Composition Security • Ongoing activities: activities – Business process execution across heterogeneous domains – Identity management – Trust management • Upcoming research areas: areas – Web Services Composition – Web Service Transactions – Service-Level Dependencies Computer Science and Engineering 38

Web Services Composition • Create complex applications on the fly from individual services • Web Services Composition • Create complex applications on the fly from individual services • BPEL 4 WS, WSBPEL • How to express security and reliability needs? • How to verify that these needs are satisfied? • How to resolve conflict between business needs and security requirements? Computer Science and Engineering 39

Web Services Transactions • Traditional database transaction managements vs. SOA application needs • How Web Services Transactions • Traditional database transaction managements vs. SOA application needs • How can we evaluate correct execution? ACID properties? Serializability? • WS transaction framework: – Atomic (short-term) transactions – Business activity (long-term) transactions transac • What are the security implications of WS transactions? Computer Science and Engineering 40

Service-Level Dependencies • Old threats reappearing in new context: deadlocks, denial-of-service, network flooding, etc. Service-Level Dependencies • Old threats reappearing in new context: deadlocks, denial-of-service, network flooding, etc. • How to detect and prevent the occurrence of these threats? • In composition, independently developed services are dependent on each other • No information about internal processing of the workflow components Computer Science and Engineering 41

New Approaches to Improve Security and Reliability • Develop criteria to evaluate correctness of New Approaches to Improve Security and Reliability • Develop criteria to evaluate correctness of composite application execution – E. g. , WS transactions: compensation-based transactions • Increase reliability using redundant services • Offer security as service • Develop defense models using distributed and collaborative components – E. g. , detect malicious behavior based on collaborative nodes, verify execution correctness by comparing outcome of different services, deploy intelligent software decoy, etc. Computer Science and Engineering 42

Research Area 1. • N. Brehm and J. Marx, Secure Service Rating in Federated Research Area 1. • N. Brehm and J. Marx, Secure Service Rating in Federated Software Systems based on SOA – Dynamic composition of WSs puts the customer at risk: trustworthiness and reliability of services – Current approach: trust negotiation – Proposed approach: message-based service evaluation between two nodes in the network

Research Area 2. • M. Gunestas, D. Wijesekera, A. Singhal, Forensics over Web Services Research Area 2. • M. Gunestas, D. Wijesekera, A. Singhal, Forensics over Web Services – How to trace back evidences of WS misuse – Relies on service interdependencies – User transactional history

Research Area 3. • A. Jain, C. Farkas, Ontology-based Authorization Model for XML Data Research Area 3. • A. Jain, C. Farkas, Ontology-based Authorization Model for XML Data in Distributed Systems – Represent XML content semantics as RDF – Express security needs on RDF and map this policy to the XML – Provide syntax independent access control for XML

Conclusion and Future Work • All aspects of SOA security must be addressed • Conclusion and Future Work • All aspects of SOA security must be addressed • Standards are not enough to provide security! • New security concepts applicable to SOA environment must be developed • Security must be incorporated during the system development process • Requires collaboration among SOA developers, business experts, and security professionals Computer Science and Engineering 46

Questions? Computer Science and Engineering 47 Questions? Computer Science and Engineering 47