Understanding SOA Security Concerns in Computer Science and Engineering

1. Service-Oriented Architecture Security Computer Science and Engineering

2. Reading Reading: • T. Earl, SOA Principles, http://www.soaprinciples.com/ • For next classes: D. Akhawe, A. Barth, P. Lam, J.C. Mitchell and D. Song, Towards a formal foundation of Web security, Proc. IEEE Symposium on Computer Security Foundations, July 2010. Interesting read: • Layer7 Technologies, XML Firewall, http://www.layer7tech.com/index.php?q=products/xml-firewall&gclid=CKrGtIv9krMCFRKpnQodGUQACg • Microsoft, Web Service Security Patterns - Community Technical Preview, http://msdn.microsoft.com/en-us/library/ff648183.aspx Computer Science and Engineering

3. Additional Reading(not required) • Software Security: Building Security In by Gary McGraw, Publisher: Addison-Wesley Professional, February 2, 2006, ISBN-10: 0321356705 ISBN-13: 978-0321356703 • 24 Deadly Sins of Software Security by Michael Howard, David LeBlanc, John Viega, Publisher: McGraw-Hill Osborne Media, 1 edition (September 3, 2009), ISBN-10: 0071626751, ISBN-13: 978-0071626750 • Hacking the Code: ASP.NET Web Application Security, M. Burnett and J.C. Foster, Syngress; 1 edition (May 2004), ISBN-10: 1932266658 , ISBN-13: 978-1932266658 • Cryptography and Network Security: Principles and Practice, W. Stallings, Prentice Hall; 5 edition (January 24, 2010), ISBN-10: 0136097049 , ISBN-13: 978-0136097044 Computer Science and Engineering

4. SOA Security Concerns Computer Science and Engineering

5. SOA Background • Four SOA Type • Service, service composition, service inventory, SOA enterprise • Four SOA Characteristics • Business-driven, vendor neutral, enterprise-centric, composition-centric • Eight service orientation principles • Standardized service contract, service loose coupling, service abstraction, service reusability, service autonomy, service stateleness, service discoverability, service composability Computer Science and Engineering

6. What are the Security concerns regarding the SOA concepts? Computer Science and Engineering

7. Attack Models • Known attacks • Representation of misuse (false positives and false negatives) • Normal usage • Representation of normal usage • Detecting anomalies • Attacker’s model • What are the capabilities of the attacker? • Carry out steps for known attacks • Carry out steps for anomalous usage • Automated tools to detect 1 and/or 2 Computer Science and Engineering

8. Design Principles • Solutions for well known problems • Represent recommended activities – Hard to model! attack  detect  eliminate  harden  knowledge prevent • Security design patterns for SOA Computer Science and Engineering

9. SOA Security Patterns • Application-level • Data confidentiality • Data Origin Authentication • Direct Authentication • Brokered Authentication • Network-level • Exception Shielding • Message Screening • Trusted subsystem • Service Perimeter Guard Computer Science and Engineering

10. Exception Shielding • Goal: prevent the disclosure of information about the service’s internal implementation via exception data • 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 design Computer Science and Engineering

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

12. Redemption – SOA pattern • Unsafe data is “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

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

14. Exception Shielding • A form of utility logic • Supported by: Service Agent, Utility Abstraction, and Service perimeter Guard • 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

15. Message Screening • Goal: protect a service from malformed or malicious input • 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 before using it Computer Science and Engineering

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

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

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

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

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

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

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

23. Implementation 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

24. Service Perimeter Guard • Goal: protect internal resources from users that remotely access internal computers • 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 perimeter of the private network as a secure contact point Computer Science and Engineering

25. 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 service’s external contracts • Internal service: response is relayed to the customer by the perimeter service

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

27. Ongoing projects • Business process execution across heterogeneous domains • Identity management • Trust management • Upcoming research areas: • Web Services Composition • Web Service Transactions • Service-Level Dependencies Computer Science and Engineering

28. Problems for SOA security design Computer Science and Engineering