service-oriented architecture security

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.)


http://www.cigital.com/papers/download/bsi12-soa.doc.pdf


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


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


Secure SOA DevelopmentSecure SOA Development

• Inherent Security of Web Services

• Security granularity

Security Software Software Security


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


Software Security Software Security


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


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



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


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


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


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


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


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


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


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


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


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


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


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


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


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)


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


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


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


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


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.


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


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


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?


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?


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


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


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


Questions?Questions?

service-oriented architecture security

Documents

engineeringcomputer

tokenscomputer science

level of security

ieee security

security requirements2

national security agency

web design

riskbased security tests1