Deep-Dive: Secure API Management
•Download as PPTX, PDF•
25 likes•13,408 views
Threat protection and application access controls are key security mechanisms that protect APIs when exposed to internal or external users and developers. In this technical deep-dive webcast, Apigee's security team, led by Subra Kumaraswamy, will discuss API threats and the protection mechanisms that every API and app developer must implement for safe and secure API management. This webcast will cover: - the API threat model - how to design and implement appropriate guardrails for API security using build-in policies and configuration - a demo of Apigee Edge threat protection features, including TLS encryption, XML/JSON/SQL injection attacks, and rate limiting Whether you're an IT security architect or an API or app developer, this webcast will help you understand secure API management. Download Podcast: http://bit.ly/1biiJQS Watch Video: http://youtu.be/ffs35w1RYRI
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (8)
Similar to Deep-Dive: Secure API Management
Similar to Deep-Dive: Secure API Management (20)
More from Apigee | Google Cloud
More from Apigee | Google Cloud (20)
Deep-Dive: Secure API Management
- 1. Deep Dive: Secure API Management Subra Kumaraswamy & Chris Von See
- 5. Agenda • API threats and Protection • API Access Control Considerations • Demo – OAuth “Hello, World!” • Operational Considerations • Demo – Handling Compromised Applications • Securing sensitive run-time data • Demo – Apigee Vault • Threat protection from the OWASP perspective • Demo – SQL Injection Attack • SSL/TLS configuration considerations • Certificate management • Key Takeaways • Questions 5
- 6. API Security Stakeholders 6 Product Manager How can I release features with built-in security? How I can reduce the release cycle? Business owner How to reduce risk while expanding API exposure? How to meet compliance? Ops How do I enforce consistent security policy across APIs? What controls I have to mitigate attacks like DoS? Developer What options I have to secure data in rest and transit? How can I securely manage keys? Security & Privacy Team How do I manage the PII life cycle of data exposed via APIs How do I govern APIs exposed to internal and external developers?
- 8. Threat Modeling and API/infrastructure Design • Your APIs are vulnerable to the typical Web application security attacks – Think OWASP Top 10 attacks • In addition you have to worry about: – API abuse via API key theft – Hackers reverse engineering Apps to access private APIs – Traffic spike protection by way of Bots or DoS attacks – Identity tracking across API sessions – XML/JSON injection type attacks – Token harvesting due to insecure communication or storage 8
- 9. Threat Modeling - APIs9
- 10. Threat Modeling – Apigee Edge10
- 11. API Deployment Architecture Edge ExternalFirewall Backend Service Enterprise Identity Store 3rd Party Security Services (AAA, Logs, Analytics) TLS HTTPS (Management services) TLS TLS TLS External Developers Apps InternalFirewall Partner • Identity • SAML • RBAC • LDAP • ACL • DDoS • XML/JSON Threats • Rate Limit • Log & Audit • Identity • OAuth • X.509 • API Key • Identity • SAML • RBAC • X.509 Internal Developers
- 12. Access Control
- 13. Identity for end-to-end security App Developer User APIApp Backend API Developer IT Manager Business User Authentication Authorization, Auditing (AAA) Services • OpenID Connect • Social Login • 2FA • X.509 Cert Enterprise Identity Stores • App Identity • OAuth • TLS • Key protection • Identity • SSO • RBAC • API Key • Threat Protection • Credential Mediation • Secure Token Storage • SAML/OAuth • Identity • SSO • RBAC • SAML • Audit
- 14. Demo: Hello World App (OAuth Client Credentials grant type) 14
- 16. Thinking about security from an operational perspective • How can I structure my Apigee instance to optimize access controls? • How do I know if an application has been compromised? • How do I mitigate risks from compromised applications? • How do I manage sensitive back-end system credentials? • How do I protect information from both internal and external threats while it’s in-flight? • Can I segregate and control access to content hosted on my Developer Portal? • Can I control access to entities in the Apigee system? • What options do I have for auditing API requests? for auditing Apigee management requests? 16
- 17. Logical partitioning through organizations and environments 17 Web Point of Sale Partner Mobile Backend Dev Environment Organization Test Environment Prod Environment Developers Applications API Team
- 18. Mitigating risks from compromised applications • How do you know you have a problem? – Strange source addresses – Unusual request types – Unusual request rates – Custom analytics showing unusual traffic for particular users • Actions you can take to mitigate impact: – Revoke/re-approve/delete an API key – Regenerate API keys and secrets – Revoke/re-approve/delete some or all active OAuth access and refresh tokens – Dynamic invalidation via code in API proxies, based on user IDs, device identifiers or other criteria 18 When this happens… What do you do?
- 19. Demo: Handling Compromised Applications 19
- 21. Sensitive data storage using Apigee Vault 21 Dev Environment Organization Test Environment Prod Environment Environment-specific vaults for back-end system credentials or other sensitive information that varies as proxies move through the development lifecycle Organization-specific vaults for sensitive information that is global to all environments or APIs Vaults are encrypted storage areas accessible for write access via the Management API and for read access by the Node.js runtime
- 23. Threat protection: the OWASP perspective
- 24. OWASP Top 10 Protection 24 OWASP Top 10 Threats Apigee Edge A1 – Injection Threat Protection Policy A2 – Broken Authentication TLS, Standard OAuth protection, LDAP, AD A3 – Cross-Site Scripting (XSS) Consistent JSON transformation A4 – Insecure Direct Object References Sanitize API A5 – Security Misconfiguration Hardened API Management Platform A6 – Sensitive Data Exposure Data Masking, Encryption, Key Mgmt A7 – Missing Function Level Access RBAC, OAuth Scope A8 – Cross-Site Request Forgery Use of tokens in API header, OAuth State Parameter A9 – Using Known Vulnerable Components Hardened API platform A10 – Unvalidated Redirects and Forwards API transformation with sanity checks
- 25. API Specific Threats 25 Threats to API Apigee Edge DoS Attacks Rate Limiting Policy Developer Abuse Quota Policy Token Harvesting 2-way TLS (Inbound and Outbound) Key Theft Secure Key Storage XML/JSON Bombs XML/JSON Injection policy Run-time Privilege escalation OAuth with API Products Management Privilege escalation RBAC for Management Team
- 26. Demo: Mitigating OWASP Top 10 Threats 26
- 28. Inbound Security – App to Edge Apigee Edge Threat Protectio n Policy Trust Store Key Store 2-Way TLS Backend All Channels TLS Cipher Config
- 29. SSL/TLS configuration – App to Edge <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <VirtualHost name="secure"> <HostAliases> <HostAlias>apiconnect.yourdomain.com</HostAlias> </HostAliases> <Interfaces/> <Port>443</Port> <SSLInfo> <Ciphers> <Cipher>TLS_RSA_WITH_AES_128_CBC_SHA</Cipher> <Cipher>TLS_DHE_DSS_WITH_AES_128_CBC_SHA</Cipher> <Cipher>SSL_RSA_WITH_3DES_EDE_CBC_SHA</Cipher> <Cipher>SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA</Cipher> <Cipher>SSL_DHE_DSS_WITH_DES_CBC_SHA</Cipher> <Cipher>TLS_KRB5_WITH_3DES_EDE_CBC_SHA</Cipher> <Cipher>TLS_KRB5_WITH_DES_CBC_SHA</Cipher> </Ciphers> <ClientAuthEnabled>True</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>mycorp</KeyAlias> <KeyStore>mycorp</KeyStore> <Protocols> <Protocol>TLSv1.1</Protocol> <Protocol>TLSv1.12</Protocol> </Protocols> </SSLInfo> </VirtualHost> 29
- 30. Outbound Security – Edge to API Apigee Edge Threat Protectio n Policy Trust Store Key Store Backend TLS Cipher Config 2-Way TLS
- 31. SSL/TLS configuration – Gateway to Backend (Southbound) - - <HTTPTargetConnection> <URL>http://mycorp.com</URL> <SSLInfo> <Enabled>true</Enabled> <ClientAuthEnabled>true</ClientAuthEnabled> <KeyStore>myKeystore</KeyStore> <KeyAlias>myKey</KeyAlias> <TrustStore>myTruststore</TrustStore> <Ciphers/> <Protocols/> </SSLInfo> </HTTPTargetConnection> 31
- 32. Certificate management • View keystore and trust store certificates in the UI • Add and manage keystore and trust store certificates via the Management API 32
- 33. Certificate management • View keystore and trust store certificates in the UI • Add and manage keystore and trust store certificates via the Management API 33
- 34. Key Takeaways • Follow API Threat Model and Security Operations best practice • Protect your backend from OWASP Top 10, DoS and API specific threats using threat protection policies • Build apps with built-in access control policies (OAuth, SAML, Cert) • Leverage built-in TLS to secure communications end-to-end • Prepared to respond to the next threat using API security configurations 34
- 35. Questions?
- 36. Thank you
- 37. Security Architecture Policy Store Log Store API Run-time Security Authentication Authorization Traffic Management Logging & Auditing API Management Security User Management RBAC Management Policy Management Certificate Management Keys/Token Management Threat Protection TLS DDoS Rate Limiting & Quota Payload Protection Analytics Compliance (SOC 2, PCI DSS, HIPAA) and Cloud Security Developers Apps IT Security /Architect Key Store Policy Enforcement
Editor's Notes
- Presenter: Numerous videos about APIs on our YouTube channel
- Presenter: Numerous presentations about APIs available on SlideShare
- Presenter: - Subra – ‘Tell our audience’ something about your background / experience, and your role here at Apigee -
- Main Points: Turning insight into action Sequential Story: Now What is (D) or What will be (U): U Analytical or Emotional connection: A Script: A cross functional API team has information needs relative to each role. API product managers are looking to understand program adoption and how API use can be improved. Business owners want to understand where to invest and how the program is effecting bottom line revenue. Operations needs to monitor the health and operation of the APIs as they are used by apps and developers Lastly app developers need to know how their apps are performing, the impact of the API on the app and what changes might help them. ISO New England is an independent, not-for-profit corporation responsible for keeping electricity flowing across the six New England states and ensuring that the region has reliable, competitively priced wholesale electricity. They are responsible for high voltage grid operation, whole sale energy market administration, and power system planning. For them, understanding where ISO is using analytics virtual dimensions which use analytics intelligence to derive ‘city’ to view by city where their API traffic is originating from. ISO To Go App that puts real-time wholesale electricity pricing and power grid information in the the hands of decision makers We did not have the ability to do so in analytics and gave them the usual run down of our geo-map feature. The day after this discussion, we announced the "virtual dimensions" feature which brought with it the native ability to run reports by city. Get the idea? Background Info: Apigee
- But some companies do well.. Our research arm, the Apigee Institute, recently published a report on this.
- Main Points: The path to securing the Digital World is along the Mobile Value Chain. Script: Let’s start with the architecture. A typical API-centric architecture is comprised of two tiers: The API infrastructure service, or “service exposure,” tier - Composed of API service providers (internal backend services and external partner services); services that securely transform existing backend capabilities into APIs; and new data services that power apps (mobile, social, web, and partner) and are aided by self-service API and management portals. The API developer service, or “API consumption,” tier - Includes services that enable developers to build and deploy apps in a secure way; engage with a developer community; and help manage application life cycles via self-service API and developer portals. Why is this view important? One of the key tenets that enable "defense in depth" security practices within an enterprise is “separation of concerns.” This design principle will make it easier to design security into the architecture and facilitate strong security management such as “separation of duties” between the service providers (the IT architect, IT security, and business) and service consumers (developers and end users). The key benefit of following a separation of concerns principle is that developers can continue to innovate and iterate with an app-centric security model while IT security architects and operations teams can safely expose the APIs without compromising on the enterprise security standards (authentication, authorization, message security, threat mitigation, logging, and auditing).
- Kill
- Mitigating risks from compromised applications -- general key management? -- access token operations? -- whitelisting/blacklisting specific users/apps/devices? -- invalidating tokens for specific users when their credentials are compromised? Protecting information in-flight -- thinking about trace masking -- SSL between components in on-prem
- Different Access control for different environment – Organization and environment flexible enough to give you the control Physical separation Why do I need to do this? Logical isolation; access control; give people exactly the access they need by slicing spheres of control
- Kill
- Illustrates the Secure Vault interaction Code
- Kill
- SQL or javascript Injection – Attack
- But some companies do well.. Our research arm, the Apigee Institute, recently published a report on this.
- <VirtualHost> Self-signed cert error – Ignore Validation Errors
- But some companies do well.. Our research arm, the Apigee Institute, recently published a report on this.
- <VirtualHost> Self-signed cert error – Ignore Validation Errors
- Script: So how can an enterprise deliver API-centric security to meet all of their stakeholder needs? The following best practices represent a great start: Create an API security architecture with both “API consumption” and “service exposure” perspectives and a threat model to support security controls on both tiers. Keep in mind that any API-centric architecture should support separation of concerns from the stakeholder responsibility point of view. Employ RBAC at every layer to implement “separation of duties” and protect sensitive information, including API keys, SSL certificates, OAuth tokens, and audit logs. Roll out a developer-centric security service aided by self-service and an API management layer. These services should be capable of configuring an API authentication scheme (OAuth, API key, OpenID, and two-way SSL), token management, policy enforcement, and logging. Note, however, that any coding of security into the application will create new vulnerabilities and long-term risk management challenges for IT security. Employ fine granular authorization using OAuth, API keys, and RBAC policies to provision the least privileges required by applications to manage the respective concerns. Protect both the communication and payload using SSL/TLS and threat protection features built into the API management products. Log relevant data that support security analytics and forensics analysis. Finally, any API-centric architecture should be capable of evolving with new business and developer requirements and be flexible to meet these without adding new attack surfaces. In other words, it should offer continuous API-centric security.