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 2

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

4. Impacts and Vulnerabilities 4 ImpactVulnerabilities Disruption in ability to serve consumers Operational robustness Disaster Recovery, Backup and Recovery, Continuity of Operations (COOP) Inability to meet performance expectations/requirements Resource Hogs Legitimate and Malicious Improper Information exposureInformation Protection Personally Identifiable Information (PII) Operational data exposure/visibility Data integrityDestructive Use – Data System ProtectionDestructive Use – Services Resource misuse/destructionDestructive Use – Control SocialReputation / Good Citizenry Man-in-the-middle: Sourcing or propagating attacks on other resources

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 3 rd 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 5

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

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 (3 rd 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. Potential use appliance level message scrubbing. 7

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

9. Future Security topics 9 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 10