Transcript NASA ECHO Security Lessons Learned

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
– Increased reuse through shared services
• Within an SOA
– Platform for Publication, Discovery, Access, Processing,
Orchestration and Control
2
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
Impacts and Vulnerabilities
Impact
Vulnerabilities
Disruption in ability to serve
consumers
Operational robustness
Inability to meet performance
expectations/requirements
Resource Hogs
Improper Information exposure
Information Protection
• Disaster Recovery, Backup and Recovery,
Continuity of Operations (COOP)
• Legitimate and Malicious
• Personally Identifiable Information (PII)
• Operational data exposure/visibility
Data integrity
Destructive Use – Data
System Protection
Destructive Use – Services
Resource misuse/destruction
Destructive Use – Control
Social
Reputation / Good Citizenry
• Man-in-the-middle: Sourcing or propagating
attacks on other resources
4
Response - Strategy
•
Multifaceted – must leverage all layers of the SOA
–
Hardware
•
–
Network
•
•
–
•
•
ACLs
Database
Robustness – Redundancy, Disaster Recovery Planning, B/U & Restore
Authentication and Authorization
–
–
•
Token passing
Application
•
–
Firewalls
Web Appliances: Governance Rules converted on IP source, message, content
Interface
•
–
Securing machines (physical and administrative)
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
5
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
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.
• Potential use appliance level message scrubbing.
7
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
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.
9
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