Protecting APIs from Mobile Threats- Beyond Oauth
•Download as PPTX, PDF•
0 likes•735 views
This document discusses securing APIs and mobile applications from threats. It covers API security topics like OAuth, mutual TLS, rate limiting and intrusion detection. For mobile security, it addresses threats involving developer screens, hardcoded keys, bypassing purchases and demoing Bluebox mobile security solutions. The key takeaways are to follow best practices for API and mobile security, use edge policies to protect backends, and augment mobile data security with solutions like Bluebox.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to Protecting APIs from Mobile Threats- Beyond Oauth
Similar to Protecting APIs from Mobile Threats- Beyond Oauth (20)
More from Apigee | Google Cloud
More from Apigee | Google Cloud (20)
Recently uploaded
Recently uploaded (20)
Protecting APIs from Mobile Threats- Beyond Oauth
- 1. 1 Protecting APIs from Mobile threats - Beyond OAuth Subra Kumaraswamy, Apigee Caleb Sima, Bluebox
- 2. Agenda 2 1111. API Security – Threats & Protection Subra Kumaraswamy 2. Mobile Security – Threats & Protection Caleb Sima ©2015 Apigee. All Rights Reserved.
- 3. Securing the APIs – End-to-End 3 - Managing Identities in world of APIs – Tomorrow @10.50 am - Data Driven Security – Tomorrow @ 11:40 am - Securing the API Lifecycle – Tomorrow @ 2.00 pm
- 4. Securing the API – Run-time 4
- 5. Secure Your Assets 5 Backend Mutual TLS IP Access control Apps API key OAuth2 TLS IP Access Control Hardened App APIs Spike Arrest Rate Limits Threat Protection Intrusion Detection DDoS
- 6. Secure Your Access Developers Federation & SSO Auditing Mediation Masking RBAC Access Block Revoke SSO RBAC Users OAuth2 MFA Federated Login P A I API Team
- 7. Mobile Security 7©2015 Apigee. All Rights Reserved.
- 8. Developer/Debug Screens & Hidden APIs
- 9. Static Crypto Keys & CC numbers
- 10. Private API tokens & Access to Private Betas
- 11. Bypass In-App-Purchase & Cheat in Games
- 12. Demo 12©2015 Apigee. All Rights Reserved.
- 13. Mobile App Security : Best Practices Secure • API key & OAuth2 • Open source encryption packages like SQL Cipher • SSL/TLS Pin your connections Defend •Android: Check your signatures •iOS: Check for Apples signature Respond • Rotate API Keys • Suspend/Kill App • Detection/Analysis Secure data at rest & in transit Eliminate attack surface & make it expensive for attackers Real time threat intelligence & response to active attacks
- 14. Key Takeaways • Follow API security best practices for both Mobile and API security –SSO, Access control (OAuth, SAML), Two-way TLS –Protect sensitive data stored in mobile end points • Use Edge Policies to protect your backend from OWASP Top 10 threats. • Augment Mobile data security using Open source or commercial solutions e.g. Bluebox 14
- 15. Thank You! Q&A Demo of Bluebox at Innovation Labs
- 16. APPENDIX
- 17. API Specific Threats – How we mitigate? 17 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
Editor's Notes
- Lots of definitions of governance. Two camps – “financial” and “operational” Financial are about identifying what’s most important to work on, and quantifying business value Operational are about the mechanics of getting things done in accordance with legal/regulatory requirements, best practices, etc., or about ensuring that people don’t mess up. Example: Large customer; many business units, all doing their own thing. Multiple APIs that do essentially the same thing. Some of this is organizational, but a lot is that people want to do the right thing but don’t realize duplicates exist. “Balkanized” organizations don’t help. Other key scenarios resolve around impact assessment, cost allocation, and so on Sometimes, unfortunately, governance is intended to enable assessment of blame. It all boils down to control. ------------- From WSO2 article: Metadata is the design and development time information used to describe a service or API. Policies are used to map metadata to deployed service instances and endpoints. Metadata can span the following concerns: Overview (e.g. name, description) Lifecycle Attributes (e.g. version, version relationships, lifecycle status) Classification (e.g. basic, composite, infrastructure, business) Endpoint Deployment Attributes (e.g. protocols, location, WS-* specifications) Data Model (e.g. JSON Schema, RAML, XML Schema, WSDL, version, semantics, validation) Service Level Requirements and Policies (e.g. availability, capacity, responsiveness, security, transaction rate) Mediation (e.g. routing, queuing, caching, transformation) Dependency Attributes (e.g. APIs, services, databases, directories, frameworks) Physical Instance Dependencies (e.g. application platform, security, management) Business Process Model (e.g. UML diagram, business classification) Contract information (e.g. consumers, providers, utilization) Usage Guidelines (e.g. time of day, availability, # of users. throughput) Accounting or remuneration options (e.g. pay per use, subscription, chargeback amount)
- Lots of definitions of governance. Two camps – “financial” and “operational” Financial are about identifying what’s most important to work on, and quantifying business value Operational are about the mechanics of getting things done in accordance with legal/regulatory requirements, best practices, etc., or about ensuring that people don’t mess up. Example: Large customer; many business units, all doing their own thing. Multiple APIs that do essentially the same thing. Some of this is organizational, but a lot is that people want to do the right thing but don’t realize duplicates exist. “Balkanized” organizations don’t help. Other key scenarios resolve around impact assessment, cost allocation, and so on Sometimes, unfortunately, governance is intended to enable assessment of blame. It all boils down to control. ------------- From WSO2 article: Metadata is the design and development time information used to describe a service or API. Policies are used to map metadata to deployed service instances and endpoints. Metadata can span the following concerns: Overview (e.g. name, description) Lifecycle Attributes (e.g. version, version relationships, lifecycle status) Classification (e.g. basic, composite, infrastructure, business) Endpoint Deployment Attributes (e.g. protocols, location, WS-* specifications) Data Model (e.g. JSON Schema, RAML, XML Schema, WSDL, version, semantics, validation) Service Level Requirements and Policies (e.g. availability, capacity, responsiveness, security, transaction rate) Mediation (e.g. routing, queuing, caching, transformation) Dependency Attributes (e.g. APIs, services, databases, directories, frameworks) Physical Instance Dependencies (e.g. application platform, security, management) Business Process Model (e.g. UML diagram, business classification) Contract information (e.g. consumers, providers, utilization) Usage Guidelines (e.g. time of day, availability, # of users. throughput) Accounting or remuneration options (e.g. pay per use, subscription, chargeback amount)
- Traditional security model is based on locking down access to backend systems But, in the world of APIs, those backend systems have to be available all the time. So, instead of blocking access to internal systems, API security must: Protect the endpoints and all points of engagement along the value chain Integrate with existing corporate security standards and systems
- Traditional security model is based on locking down access to backend systems But, in the world of APIs, those backend systems have to be available all the time. So, instead of blocking access to internal systems, API security must: Protect the endpoints and all points of engagement along the value chain Integrate with existing corporate security standards and systems
- What does bluebox do? It enable an enterprise to have a zero trust model for their mobile apps. We do that by accomplishing three things (For a quicker walkthru just read the text at the bottom of the boxes and don’t bother going thru explanation) Secure the app: ensure all data is encrypted. Nothing written to disk is stored in the clear. Also ensure that attackers cannot man in the middle the app. Defend the app: No matter how you try to encrypt things you must protect the it. Both from a static & dynamic attacks Respond. We collect security analytics to create a trust score that can be sent to the enterprise to help determine risk