2022 APIsecure_Hackers with Valid Credentials
•Download as PPTX, PDF•
0 likes•14 views
Hackers are exploiting APIs to steal data and access accounts by using valid credentials obtained through phishing, purchase, or partnerships. This poses a challenge as hackers can blend in with real users while maliciously accessing API services. To protect APIs, organizations need visibility into activity across all API gateways and clouds on a per user identity basis. They should also implement authentication, authorization, monitoring for abnormal behavior using machine learning, and automated remediation when risks are detected. Applying a zero trust model with these strategies can help secure APIs.
Recommended
More Related Content
Similar to 2022 APIsecure_Hackers with Valid Credentials
Similar to 2022 APIsecure_Hackers with Valid Credentials (20)
More from APIsecure_ Official
More from APIsecure_ Official (20)
Recently uploaded
Recently uploaded (20)
2022 APIsecure_Hackers with Valid Credentials
- 1. Hackers with Valid Credentials Bernard Harguindeguy – SVP bharguindeguy@pingidentity.com Twitter: @bernardh_
- 2. 2 Data theft with phished/stolen or purchased credentials API Hackers Are Real Users too! 2 Hackers exploit API to take over accounts, steal data and commit fraud Partner repurposes credit score company internal API Millions of credit scores were accidentally exposed through by a partner
- 3. API Challenges –Evolving API Attacks 3 Attacks • Credential stuffing attacks • Authentication attacks • Application attacks • Data theft attacks • Control system attacks Hackers • Attack tailored to each API • No signature or pattern to “lock in” • Hacker is real user – stolen or legitimate credentials Protect your enterprise against external threats
- 4. API Challenges –Many Threats 4 Inadvertent data exposure can result from: • API design flaws and bugs • Rogue APIs and Zombie APIs • Misuse from authorized users • Abuse by partners – they have valid credentials too The growing threat from the inside and partners
- 5. 5 API Security –A Difficult Problem • High number of sessions across many APIs • Various API gateways and clouds • Large mix of inbound clients and activity • Legitimate clients • High velocity attackers disrupt services • Hackerswithvalidcredentialsblendin while maliciouslyaccessingAPI services Looking for“needle in haystack” IP Geolocation Time /Day Session Length ... API 1 API 2 API 3 API 4
- 6. API Challenges –Consistent Visibility is Difficult Enterprise API Gateways Unmanaged/ other APIs APIs Cloud APIs Most organizations support multiple API environments … and can’t track access across byuser identity! 6
- 7. TheState of API Security Organizations rely on API Gateways and WAF/WAAP to protect their enterprise However, this is not enough! 7 WAFs/WAAPs New threats require new API security measures: processes and tools
- 8. SecuringAPIs 8 Unknown User Known user with credentials Authenticate Access Authorize APIs Bots Credential stuffing Hacker with stolen credentials Successful Login Hacker creates new accounts Successful Login
- 9. Apply Zero Trust Model • ContinuouslymonitoractivityonAPI/Data • Remediatewhenriskisdetected APIs 9 Authorize and monitor session thereafter Authenticate • Right device for that user? • Device trustworthy? • Normal time of day? • Usual location? Where was it last? • Challenge user with MFA! Do risk analysis on user!
- 10. Apply Zero Trust Model –Track by User Identity APIs 10 Who is doing what with each API? Across all gateways! Same device used to create more than one account? Is someone using an abnormal number of tokens? Was a token manipulated? Is a partner data mining one of your APIs? API Gateway 1 API Gateway 2 API Gateway 3 API Gateway 4 ……. Authenticate Can you tell?
- 11. API Infrastructure Protection 11 Detect Bots on APIs Strongly authenticate Access/Authorization Enforcement Token anomaly detection Payload inspection API activity monitoring/reporting per user Detection of abnormal activity and attacks Authenticate Access Consume API APIs Unknown User User risk + MFA Automated remediation: • Block user • Re-authenticate user • or MFA step up user
- 12. API Activity Monitoring: Modeling & Behavioral Analysis 12 Continuous API activity analysis API behavior modeling for each API Identity-based behavior modeling Cross-API behavior modeling All tokens and IPs used to access APIs on different gateways and clouds need to be associated to each user identity for end-to-end analysis AI/ML to detect abnormalities and hackers …/API1 …/API2
- 13. Guidelines and Recommendations –in Dev 1. Assemble Team to oversee API security 2. Continuous security mindset a must – mix teams / embed security experts 3. Test APIs for vulnerabilities – automate security scans and tests 4. Prevent app servers from sending error messages with system traces 5. Enforce flow control and TLS (https) encryption 6. Implement a strong authentication system – use step-ups / MFA 7. Limit the scope of what APIs can access 8. Treat all APIs as external APIs!
- 14. Guidelines and Recommendations –in Prod 1. Deploy anti-Bot and DDoS tools 2. Authenticate and Authorize each access 3. Use tools to automate discovery of APIs – track forgotten versions, shadow APIs 4. Track all API transaction per user – not just tokens, cookies, IPs, keys, etc. 5. Single pane of glass to monitor activity across all gateways and clouds accessed 6. Track APIs and traffic globally for regular Audits and Governance Reports 7. Use ML to monitor activity for abnormalities – and automate remediation 8. Control API data flow and block PII data, protected data, etc.
- 15. Leverage Zero Trust Model • Visibility – know your APIs and track by user identity • Anti-Bot tools • Use AI/ML to detect abnormal activity • Automate remediation / blocking Key Take-Aways for API Infrastructure Protection 15
- 16. For questions and/or more information: Bernard Harguindeguy bharguindeguy@pingidentity.com Twitter: @bernardh_
Editor's Notes
- Hackers and bad actors use valid creds. Most breaches involve hackers with real credential Either they stole them via phishing, were successful with a credential stuffing attack, bought them, And you have the case when APIs were abused by partners – and data exposed via a promotion or stolen: Experian and Facebook/Cambridge Analytica. They did not have to find a vulnerability to exploit, or break
- Typically a hacker will probe the API, bypass the UI, reverse engineer the API to identify the vulnerability to breach and take over accounts. These attacks are hard to detect has they are custom crafted to each API – reason rule based security does not work / not adapted. And them imagine the hacker with no attack --- he just logs in. He has credentials already, phished or bought Or they simply created their own accounts: social, financials, healthcare etc. – so they just login and take over. 1) Corporate, employee and customer data exposed and/or sold 2) Account takeover fraud 3) Compromised control
- As mentioned previously it is not just external unknown people you need to worry about. What about that partner on your API. Could they do something stupid that simply exposed your information – no hacking involved at that point either. Or they might just mine your data or take over – using they credentials
- So why is it hard to detect and counter?
- And here is another complication. Clouds and datacenters with various gateway platforms. What’s refer to hybrid cloud environment. And then you have zombie and shadow APIs to worry about. Do you know about all your APIs? And one more thing – when you have some visibility, it is rarely at the user level – can you tell if someone accessed that Apigee onprem, those AWS APIs, and the NGINX APIs yesterday? What tokens did they use, what IP addresses?
- Let’s take a look at hacking with valid credential You may have a successful Bot in – got lucky with cred stuffing You may have the hacker creating a fake account on that shopping site, buys a bunch of stuff, get that gift card and then returns the merchandise … How do you deal with these situations – how do you recognize and block them?
- What is involved? API Gateway = per token At a user level they might need multiple tokens per session NOT fragmented visibility by token Why is this so hard?!!!!!!!!!!!!!