service-oriented architecture security
DESCRIPTION
Service-Oriented Architecture Security. Reading. T. Erl, SOA Design Patterns, Chapter 13 F. A. Cummins: Building the Agile Enterprise with SOA, BPM, and MBM, Chapter 6 - PowerPoint PPT PresentationTRANSCRIPT
Computer Science and Engineering 1
Service-Oriented ArchitectureSecuritySecurity
ReadingReading
1. T. Erl, SOA Design Patterns, Chapter 13
2. F. A. Cummins: Building the Agile Enterprise with SOA, BPM, and MBM, Chapter 6
3. G. McGraw, Software Security and SOA: Danger, Will Robinson!, IEEE Security and Privacy, 2006, http://www.cigital.com/papers/download/bsi12-soa.doc.pdf
4. Organization for the Advancement of Structured Information Standards (OASIS), http://www.oasis-open.org/ (SOA, Security, WS, XML, etc.)
5. World Wide Web Consortium (W3C), http://www.w3.org/ (Web design and applications, Web architecture, Semantic Web, XML, WS, etc.)
Computer Science and Engineering 2
Computer Science and Engineering 3
SOA Security ComponentsSOA Security Components
1. Software-level (single service) security
2. Business-level (service composition) security
3. Network-level security
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
Computer Science and Engineering 5
Web ServicesWeb Services
• GoalGoal: enable autonomous and distributed entities to collaborate efficiently, reliably, cost-effectively, and comply with regulations
• CharacteristicsCharacteristics: open and heterogeneous environment, loose coupling, code reuse, standard-based interfaces, platform independent & language neutral
• Support forSupport for:– Data & Information Sharing– Automated processing – Web with a meaning– Express business logic
Computer Science and Engineering 6
Secure SOA DevelopmentSecure SOA Development
• Inherent Security of Web Services
• Security granularity
Security Software Software Security
Computer Science and Engineering 7
WS Security Standards
• OASISOASIS Web Services Security (WSS) Web Services Security (WSS) – Integrity and authentication: sign SOAP msgs.– Confidentiality: encrypt SOAP msgs.– Attach security tokens
• Security tokensSecurity tokens• Security Assertion Markup Language (SAML) assertions• Kerberos tickets• User credentials• X.509 certificate• Custom defined tokens
Computer Science and Engineering 8
Software Security Software Security
Computer Science and Engineering 9
SOA ApplicationsSOA Applications
• Aggregated services each component is vulnerable
• What is the level of security provided by the aggregate?– Trust management
• Security Patterns (REFERENCE #1)Security Patterns (REFERENCE #1)– Exception Shielding
– Message Screening
– Trusted subsystem
– Service Perimeter Guard
Computer Science and Engineering 10
Secure Software DevelopmentSecure Software Development
• Develop software that is free of flawsDevelop software that is free of flaws
– Software engineering – functional requirements
– Security, reliability, QoS – non-functional requirements
• Protect against malicious code
• ReadingReading:
– G. McGraw, Software Security , http://www.cigital.com/papers/download/bsi1-swsec.pdf
– US National Security Agency: System Security Engineering CMM (SSE CMM), http://www.sse-cmm.org/index.html
Computer Science and Engineering 10
Computer Science and Engineering 11
Software Security during Software Security during SDLCSDLC
Requirement and Use cases
Architecture and Design
Test Plans Code Tests andTest Results
Feedback fromthe Field
5. Abuse cases
6. Security Requirements
2. Risk Analysis
External Review
4. Risk-Based Security Tests
1. Code Review(Tools)
2. Risk Analysis
3. Penetration Testing
7. Security Operations
From: G. McGraw, Software Security
Computer Science and Engineering 12
Open Web Application Security Open Web Application Security Project (OWASP)Project (OWASP)
• Non-for-profit, worldwide organizations• GoalGoal: improve the security of application software• All materials: available under a free and open software
license• Common Weakness Enumeration (CWE): Common Weakness Enumeration (CWE): list of
software weaknesses– Full dictionary view– Development view– Research view
Computer Science and Engineering 13
Exception ShieldingException Shielding
• GoalGoal: prevent the disclosure of information about the service’s internal implementation via exception data
• ProblemProblem: – Exception data released by a service may contain
internal implementation details – Malicious users may exploit this data to compromise
the service and its environment• SolutionSolution: replace unsafe data with data that is safe by
design
Computer Science and Engineering 14
Improper Error HandlingImproper Error Handling
• OWASP “A7 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 15
Redemptions – SDLCRedemptions – 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 16
Redemption – SOA patternRedemption – SOA pattern
• Unsafe data is “sanitizedsanitized”• Routines added to the service logicRoutines 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 17
Sanitization ProcessSanitization Process
Customer
Server
Customer submits a request message
Server: attempts to processThe request and throws anException
Exception Shielding Routines: Evaluates exception data and Replaces it if unsafe
Server returns safe exception message
Computer Science and Engineering 18
Exception ShieldingException Shielding
• A form of utility logic• Supported by: Service Agent, Utility Abstraction, and
Service perimeter Guard• ImpactImpact:
– 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 19
Message ScreeningMessage Screening
• GoalGoal: protect a service from malformed or malicious input
• ProblemProblem: – Malicious user may violate service security or take
over the control of the service and its environment• SolutionSolution: assume all input data is harmful and screen
before using it
Computer Science and Engineering 20
Input ValidationInput Validation
• OWASP: CWE-20: improper Input Validation, http://cwe.mitre.org/data/definitions/20.html
• ProblemProblem: no or improper validation of input that can affect control flow or data flow of a program
• VariantsVariants:– Buffer overrun– Integer overflow– Command injection– SQL injection
• Reading: G. Hoglund and G. McDraw, Exploiting Software: How to Break Code, Chapter 7 Buffer Overflow, http://searchsecurity.techtarget.com/searchSecurity/downloads/Exploiting Software-Ch07.pdf
Computer Science and Engineering 21
ImpactImpact
• AvailabilityAvailability: malicious input may– Crash the program– Exhaust resources (e.g., memory, CPU)
• ConfidentialityConfidentiality: attacker may be able to access confidential resources
• IntegrityIntegrity: attacker may– Modify data– Alter control flow– Execute arbitrary commands
Computer Science and Engineering 22
Redemption – SDLC Redemption – SDLC
• Always validate dataAlways validate data• Stop using unsafe commands, e.g., strcpy, strncat, etc.• Understand casting and operators• Use “white listwhite list”• Static analysis tool• Manual analysis – design level
Computer Science and Engineering 23
Redemption – SOA PatternRedemption – 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 24
Other Considerations about Other Considerations about Screening RoutinesScreening Routines
• Screening requires the decryptiondecryption of encrypted traffic• Must be able to handle all types of attachmentshandle all types of attachments to
evaluate malicious content• Must be very efficientefficient – not a bottleneck• Related to Utility Abstraction and Service Agent
isolate message screening routine into a separate utility separate utility serviceservice
• Vulnerabilities of XML messages (data types, data content, limited XML parser support)
Computer Science and Engineering 25
2010 CWE/SANS Top 25 Most 2010 CWE/SANS Top 25 Most Dangerous Programming Dangerous Programming
ErrorsErrors• URL: http://cwe.mitre.org/top25/
• List of 25 most dangerous programming errors 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 helpAims 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 26
Network-Level SecurityNetwork-Level Security
• Authentication and identification • Access Control• Messaging middlewaremiddleware
– Communication security– End point security
• Protocol assurance• Security PatternsSecurity Patterns
– Trusted subsystem– Service Perimeter Guard
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 AuthenticationTwo-Way Authentication
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 ControlExtended RBAC
• Extend RBAC with authorization attributes• AttributesAttributes are referenced within policies
– Credentials, certifications, etc.• Role hierarchy: inheritance of privileges• Security roles vs. access control roles• SOA:SOA: need to authorize people as well as systems • Other issues:
– Grant and revoke– Delegation of privileges
Access Control Administration
• Centralized access controlCentralized access control– Role engineering– Optimal role allocation and assignments– Protecting access control documents– Dealing with grant and revoke, and delegation
• Distributed access controlDistributed access control– Global consistency– User identification– Role assignments/subject switching
Federation of Trust Domains
• Participants from multiple trust domains• Establish trustworthinessEstablish trustworthiness using other domains• WS-FederationWS-Federation
– Cooperative relationship between trust domains– Simplified protocol for cross domain credentials:
1. P: Participant (P) requests access to domain (R)2. R: locates the participant’s (P) home domain (H)3. H: provides P’s credentials according to sharing policy4. R: accept the identity of P (temporary entry)5. R: transforms P’s credentials from H to its local requirements,
preserves credentials for subsequent requests6. R: responds to P’s initial request
Computer Science and Engineering 32
Trusted SubsystemTrusted Subsystem
• GoalGoal: prevent customers from circumventing a service and directly accessing the resources of the service
• ProblemProblem: – Customer may perform incorrect modifications– May lead to undesirable forms of implementation
coupling• SolutionSolution: service is designed to use own credentials for
authentication with backend resources
Computer Science and Engineering 33
ImpactImpact
• Compromised serviceCompromised service may allow access to unauthorized users
• Protocol for accessing remote resourcesProtocol 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 34
Implementation VariantsImplementation Variants
• Service accounts within the trusted subsystem• Local accounts are used on each host• Use digital certificate (e.g., X509 PKI) for
authentication in the trusted subsystem• Use IPSec to provide secure communications.
Computer Science and Engineering 35
Perimeter GuardPerimeter Guard
• GoalGoal: protect internal resources from users that remotely access internal computers
• ProblemProblem: – External attacker may gain access to services running
within a private network, and thus to the resources within the private network
• SolutionSolution: establish an intermediate service at the perimeter of the private network as a secure contact point
Demilitarized Zone (DMZ)
• Perimeter Service:– Operates at application layer– Work in conjunction with existing firewall
technologies– Hide internal service details
• External customerExternal customer: corresponds with the perimeter service’s external contracts
• Internal serviceInternal service: response is relayed to the customer by the perimeter service
Impact
• Extra cost ofExtra cost of– Processing overhead– Complexity
• Single point of failureSingle point of failure• Perimeter service represents a point of isolation.
EffectsEffects: direct authentication, brokered authentication, and message screening
Computer Science and Engineering 38
Service-Composition Service-Composition SecuritySecurity
• Ongoing activitiesOngoing activities:– Business process execution across heterogeneous
domains– Identity management– Trust management
• Upcoming research areasUpcoming research areas:– Web Services Composition– Web Service Transactions– Service-Level Dependencies
Computer Science and Engineering 39
Web Services CompositionWeb Services Composition
• Create complex applications on the fly from individual services
• BPEL4WS, 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 40
Web Services TransactionsWeb 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) transacBusiness activity (long-term) transactions
• What are the security implications of WS transactions?
Computer Science and Engineering 41
Service-Level DependenciesService-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 42
New Approaches to Improve New Approaches to Improve Security and ReliabilitySecurity 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.
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– 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 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
Computer Science and Engineering 46
Conclusion and Future WorkConclusion 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 collaborationcollaboration among SOA developers, SOA developers,
business experts, and security professionalsbusiness experts, and security professionals
Computer Science and Engineering 47
Questions?Questions?