1 / 10

Web Services, SOA and Security

Web Services, SOA and Security. May 11, 2009 Michael Burnett. Role of Web Services. Mechanism for sharing resources Functional Data Hardware (including Sensors) Isolates responsibility Organizationally, Location, Technology Enables new way of assembling applications Less Stovepiping

jeffreydiaz
Download Presentation

Web Services, SOA and Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Services, SOA and Security May 11, 2009 Michael Burnett

  2. Role of Web Services • Mechanism for sharing resources • Functional • Data • Hardware (including Sensors) • Isolates responsibility • Organizationally, Location, Technology • Enables new way of assembling applications • Less Stovepiping • Increased reuse through shared services • Within an SOA • Platform for Publication, Discovery, Access, Processing, Orchestration and Control

  3. The Need for Security • As a Service Provider, you may not know: • Who • You are dealing with, who is consuming your offering • Potentially within the enterprise, other businesses, and end users • What • They are being used for • Services, by design, are often agnostic to the development and evolution of end user facing applications. • In a SOA world, a poorly implemented client application has the ability to compromise the entire SOA infrastructure and potentially the enterprise itself. Without control over the usage, need to protect the resources.

  4. Impacts and Vulnerabilities

  5. Response - Strategy • Multifaceted – must leverage all layers of the SOA • Hardware • Securing machines (physical and administrative) • Network • Firewalls • Web Appliances: Governance Rules converted on IP source, message, content • Interface • Token passing • Application • ACLs • Database • Robustness – Redundancy, Disaster Recovery Planning, B/U & Restore • Authentication and Authorization • User Account management services • “Special Arrangement” across NASA DAAC data/service providers • Exposes a Single-Sign-On capability that can be leveraged by 3rd party apps to take advantage of ECHO’s ACLs, rules, and group membership to ensure all ecosystem applications have the same understanding of permissions and data access. • Example: Client gets token from ECHO. Client passes token directly to external partner. Partner asks ECHO if token owner is a member of a specific group (for internal authorization) • ASTER works in this model

  6. Response – Resource Hogs • Automated firewall blocking for IPs • Denial of Service Attacks • Client identification • Application Tier Requires IP and ClientAppID (like Google, Amazon, etc.) • Shutdown session if a bad client • At the database level, maximum SQL query execution time before abandoning • No SQL runs longer than x minutes.

  7. Response - Information Protection • Deliberately avoid PII and payment information • Use of side channels for payment, if required. • Access Control Lists (ACLs) • All data, multi-level, visibility, restrictions at group level. • Provider (3rd party) control over their data using PUMP, ACLs, Provider Policies, SSL certifications, etc. • User authentication using token approach. Similar to WS-* • Standard security practices of controlled database accounts, SQL Injection prevention, encryption of passwords in database, etc. • Potentialuse appliance level message scrubbing.

  8. Response - Destructive attacks • Vulnerabilities are significant • Ruin data/data integrity • Control of resources • Computing • Sensor • Flexible access control mechanism splitting users and permission roles across multiple levels of the architecture • Auditability with offsite log archival and searching • Well defined, public APIs – even to our own clients – no back doors (which offer additional vulnerability and risk) • The usual best practices of backups, snapshots, etc.

  9. Future Security topics • FISMA 2.0 (Federal Information Security Management Act) • Security Delegation • Enterprise Authentication • Appliance-based security enforcement • End-to-end message integrity and confidentiality • XSS/CSRF vulnerabilities in provider data • Debatable topic. Trusting data from registered partners. Significant performance impact to include.

  10. Summary • Does Security Matter? • As we move away from stovepipes and experiments to shared services and operational infrastructure, we have different needs to protect our resources • Socially - More popular, more vulnerable • Need to establish and incorporate Best Practices as a part of our responsibilities • As we get better at managing the server-side issues, exploitation moves towards the client • Protect the information, resources, reputation

More Related