Double-Edged Sword of Cloud Security
•Download as PPTX, PDF•
0 likes•211 views
GS네오텍 Amazon CloudFront Day 2019 FireEYE - 오진석 이사 Cloud Expert Group - GS네오텍
Recommended
Recommended
More Related Content
Similar to Double-Edged Sword of Cloud Security
Similar to Double-Edged Sword of Cloud Security (20)
More from GS Neotek
More from GS Neotek (15)
Recently uploaded
Recently uploaded (6)
Double-Edged Sword of Cloud Security
- 1. Jinsuk Oh Double-Edged Sword of Cloud Security 클라우드 보안의 양날의 검
- 2. 클라우드 도입 관련 동향
- 3. ©2019 FireEye©2019 FireEye 클라우드는 안전하지 않다 우리 조직은 클라우드를 사용하지 않는다 나의 클라우드 사업자는 나를 안전하게 관리해줄 것이다 클라우드는 단지 다른 누군가의 컴퓨터에 불과하다 공격자는 클라우드를 공격하지 않을 것이다 클라우드에 대한 근거 없는 믿음 TOP 5 3 Source: FireEye – Top 5 Cloud Myths
- 4. ©2019 FireEye©2019 FireEye 클라우드 플랫폼 사용 주요 이유 4 Source: Cloud Endure
- 5. ©2019 FireEye©2019 FireEye 클라우드 플랫폼 선정 시 고려사항 5 Source: Cloud Endure
- 6. ©2019 FireEye©2019 FireEye 클라우드 마이그레이션시 시간 소요 항목 6 Source: Cloud Endure
- 7. ©2019 FireEye©2019 FireEye Recent Cloud Breaches 7 ENGADGET Amazon AWS error exposes info on 31,000 GoDaddy servers AUG. 9, 2018 ZDNet 198 million Americans hit by 'largest ever' voter records leak JUN. 19, 2017 GIZMODO Millions of Time Warner Cable Customer Records Exposed in Third-Party Data Leak SEPT. 1, 2017 WSJ Dow Jones Inadvertently Exposed Some Customers’ Information JUL. 16, 2017 FORBES Massive WWE Leak Exposes 3 Million Wrestling Fans' Addresses JUL. 6, 2017 ARSTECHNICA Defence contractor stored intelligence data in Amazon cloud unprotected JUN 1, 2017 THE REGISTER Massive US military social media spying archive left wide open in AWS S3 buckets NOV. 17, 2017
- 8. ©2019 FireEye©2019 FireEye “Through 2022, at least 95% of cloud security failures will be the customer’s fault.” — Jay Heiser Research VP, Gartner 8 “2022년까지 클라우드 보안 장애의 최소 95%는 사용자의 실수에 의해 발생할 것이다.”
- 9. 클라우드의 위협 및 취약점
- 10. ©2019 FireEye©2019 FireEye Cloud에 대한 일반적인 위협 및 취약점 10 Storage misconfigurations – AWS S3 buckets with sensitive information publicly exposed GhostWriter attacks – Buckets with “write access” exploited with malicious files, code and ads Accidental GitHub commits – Exposes keys to the kingdom – Credentials, API keys/secrets Insecure APIs
- 11. ©2019 FireEye©2019 FireEye OAuth 피싱을 통한 2FA 인증 우회 11 The attacker registered and created a malicious Google application Source: FireEye M-Trends 2017 The attacker sent phishing emails containing a link to register the malicious application to their Google account
- 12. ©2019 FireEye©2019 FireEye OAuth 피싱을 통한 2FA 인증 우회 12 Once the attacker’s malicious application had permission, it could access the user’s data, even after an account password reset Source: FireEye M-Trends 2017
- 13. ©2019 FireEye©2019 FireEye OAuth 피싱을 통한 2FA 인증 우회 13 Source: FireEye M-Trends 2017
- 14. ©2019 FireEye©2019 FireEye 기밀정보의 획득 – 주요 거래정보 – 금융거래 기록 – 고객/임직원의 개인정보 추가 공격의 발단으로 사용 유출한 데이터의 외부 배포 암호화 화폐 채굴을 위해 클라우드 인프라 사용 공격 이후 공격자가 원하는것은? 14
- 15. ©2019 FireEye©2019 FireEye 일반적인 공격은 어떻게 진행되는가? 15 Source: FireEye M-Trends 2017 초기정찰 최초 감염 공격 거점 확보 권한 상승 내부 정찰 정보 유출 연결유지 내부 전파
- 16. ©2019 FireEye©2019 FireEye 클라우드에 대한 공격은 어떻게 진행되는가? 16 • Determine cloud presence • Find email addresses • Discover company domains • Social engineering • Phishing • Exploit misconfiguration • OAUTH deception • Create rogue delegation • Create mail forwarding rules • Exploit weak role permissions to grant additional privileges • Enumerate infrastructure using cloud API’s • Enumerate accounts and roles to find delegations and privileges • Copy data to attacker-controlled blob storage • Change permissions on documents to world-readable • Delete or alter files for Cloud • Intercept emails showing suspicion of compromise • Create additional accounts • Use privileges to uncover config files with auth keys • Leverage access for additional phishing 초기정찰 최초 감염 공격 거점 확보 권한 상승 내부 정찰 정보 유출 연결유지 내부 전파
- 17. ©2019 FireEye©2019 FireEye Mandiant Case Study: Cloud Compromise 17 Day 1 Day 2 Day 3 48Hours Average time to exfiltrate data 204D Average dwell time in APAC
- 18. ©2019 FireEye©2019 FireEye Mandiant Case Study: Cloud Compromise 18 Day 1 Day 2 Day 3 Booted a VM in another subnet, mounted a DB snapshot, instead of logging in Audit trail for business layer logic, API security, proactive hunting
- 19. 클라우드 보안 전략
- 20. ©2019 FireEye©2019 FireEye Shared Responsibility Model 20 Always your responsibility!
- 21. ©2019 FireEye©2019 FireEye Categories: • Initial Access • Execution • Persistence • Privilege Escalation • Defense Evasion • Credential Access • Discovery • Lateral Movement • Collection • Exfiltration • Command and Control On-premise, you need to guard against the entire MITRE ATT&CK framework (270 techniques) MITRE ATT&CK – On-premise 21
- 22. ©2019 FireEye©2019 FireEye Categories: • Initial Access • Execution • Persistence • Privilege Escalation • Defense Evasion • Credential Access • Discovery • Lateral Movement • Collection • Exfiltration • Command and Control In the cloud, attackers are limited to a subset (58) of the overall techniques (about 20%) MITRE ATT&CK – Cloud 22
- 23. ©2019 FireEye©2019 FireEye 기본적 고려사항 – 종합적인 계획 수립 – 네트워크 인프라 및 엔드포인트 보호 – 자산에 대한 하드닝 및 안전한 통신 채널 확보 – 역할기반 엑세스 제어 관리 – 자격증명 도난으로부터 사용자 보호 추가 고려요소 – 클라우드 플랫폼 이벤트, 로그 수집 분석 – 웹 어플리케이션 보안 평가 클라우드 보안의 고려요소 23 Source: Firegen Analytics – Mapping On-Premises Controls vs Cloud Providers
- 24. ©2019 FireEye©2019 FireEye24 클라우드의 보안 전략은 기존 보안 위협이 클라우드에도 적용 가능하며, 완벽하게 안전할 수 없다는 가정에서 시작해야 합니다.
- 25. FireEye 클라우드 보안
- 26. ©2019 FireEye©2019 FireEye26 FireEye는 전 세계 7,700여 고객에게 위협에 대응을 위한 제품과 서비스를 제공하는 사이버보안 전문 기업입니다.
- 27. ©2019 FireEye©2019 FireEye The FireEye Ecosystem 27
- 28. ©2019 FireEye©2019 FireEye FireEye Technologies Working Together 28 Analytics & ML File Delivery & Payload Signature Indicators of Compromise Analytics Rule SmartVision Global Cache Binocolo Riskware MalwareGuard Callback Multi-Vector Execution MVX Behavior MVX Static MVX Correlation MVX FUME SmartLauncher FAUDE FAUDE Kraken FAUDE PhishEye Binocolo Phishing Binocolo Central Domain Reputation ExploitGuard Signature Detection Ent. – Search Dynamic Threat Intelligence Skyfeed FireEye Helix FireEye Email Security FireEye Network Security FireEye Endpoint Security Threat Intelligence Helix Rules
- 29. ©2019 FireEye©2019 FireEye Email Threat Prevention – Provides several different mechanisms for security cloud-delivered email as a secure mail gateway CloudHX Endpoint Security – Fully-managed, cloud-hosted Endpoint Security controllers Helix Cloud SIEM – Upload events into our cloud SIEM for rules, analytics, intel, and compliance/reporting features FireEye Products from the Cloud 29
- 30. ©2019 FireEye©2019 FireEye Email Threat Prevention – The number one way attackers are compromising clouds is with stolen credentials via phishing Endpoint Security – Our endpoint agents work on cloud assets Helix Cloud SIEM – We have rule packs and analytics for cloud providers, including compliance rule packs FireEye Products for the Cloud 30
- 31. ©2019 FireEye©2019 FireEye Network Security (NX) for AWS – Route traffic through our vNX in AWS for inline protection Network Forensics (PX) for AWS – Use the new vTAP features in AWS to get a copy of traffic sent to Network Forensics FireEye Products for the Cloud (Preview) 31 * We have network products in private preview which will be generally available in July:
- 33. ©2019 FireEye©2019 FireEye FireEye 클라우드 보안 플랫폼 33 Intelligence Application of threat intelligence indicators to telemetry Analytics Organization of telemetry to show anomalies Rules Application of known threat patterns to telemetry Hunting Hypothesis-based searching
- 34. ©2019 FireEye©2019 FireEye 클라우드의 보안은 정확한 목적과 계획을 통해 클라우드를 사용하는 모든 현업, 개발, 운영, 보안 담당자 모두가 함께 만들어 가야합니다. 클라우드는 안전하지만 잘못된 설정으로 인해 사고 발생 안전하게 설정되었더라도 사회공학적 피싱 위협에 취약 기존의 모든 보안기술이 클라우드에 적용되지 않음 효율적인 클라우드 위협 대응을 위해서는 가시성 및 자동화 필요 클라우드 보안은 누가.. 34
- 35. 감사합니다.
Editor's Notes
- https://content.fireeye.com/top-5-cloud/eb-top-5-cloud-security-myths
- 2번째 그래프 - 클라우드 플랫폼 선정시 고려사항 (2016년도 조사시 Reliability 22% / 가용성 20% / 보안 17%)
- 2번째 그래프 - 클라우드 플랫폼 선정시 고려사항 (2016년도 조사시 Reliability 22% / 가용성 20% / 보안 17%)
- 2번째 그래프 - 클라우드 플랫폼 선정시 고려사항 (2016년도 조사시 Reliability 22% / 가용성 20% / 보안 17%)
- The Russian hacking group blamed for targeting U.S. and European elections has been breaking into email accounts, not only by tricking victims into giving up passwords, but by stealing access tokens too.
- There is only 48 hour period between when the attacker logged in and grabbed/stole the data. So if you think about dwell time, our Mtrends data shows 498 days in APAC, this is just 2 days. The threat here is very different and the timelines is very different. It means that people will have to be on their toes about it that means automating as much as possible. Day 1 -> they login with stolen credentials. They then use the API of the Cloud provider against you by doing things such as mounting a db snapshot instead of logging into the database If you think about the normal security controls people have in place for a database, we have passwords, some credential blocking and some firewall rules around that. None of that matters, if you could just boot a box in another subnet, mount a snapshot and then steal all the data – this bypasses all the traditional controls. So if you are not watching for interesting API calls, you’d be totally blind to that. Somehow you’d find your data exposed on the dark web and you’ll look at your connection records for the db server and say that nobody ever stole that from the db server and you’d be right cos they have totally bypassed that workflow. Because of the cloud infrastructure they have gone around that You could see that in some ways cloud made it easier to run that database, because it might have been a serverless or managed db, the OS is easier to patch it etc, but if you are not doing that additional bit of security where you are thinking about the audit trail for this stuff and not thinking about the business logic layer, you are going to completely miss it. So if you want to think about opportunities for detection, Day 1, this is where we have some low severity alerts good for hunting but not a whole lot else – you don’t want to wake somebody in the middle of the night for this. Day 2 - > this is where the snapshot thing comes into the picture, where our rule packs pay off.
- There is only 48 hour period between when the attacker logged in and grabbed/stole the data. So if you think about dwell time, our Mtrends data shows 498 days in APAC, this is just 2 days. The threat here is very different and the timelines is very different. It means that people will have to be on their toes about it that means automating as much as possible. Day 1 -> they login with stolen credentials. They then use the API of the Cloud provider against you by doing things such as mounting a db snapshot instead of logging into the database If you think about the normal security controls people have in place for a database, we have passwords, some credential blocking and some firewall rules around that. None of that matters, if you could just boot a box in another subnet, mount a snapshot and then steal all the data – this bypasses all the traditional controls. So if you are not watching for interesting API calls, you’d be totally blind to that. Somehow you’d find your data exposed on the dark web and you’ll look at your connection records for the db server and say that nobody ever stole that from the db server and you’d be right cos they have totally bypassed that workflow. Because of the cloud infrastructure they have gone around that You could see that in some ways cloud made it easier to run that database, because it might have been a serverless or managed db, the OS is easier to patch it etc, but if you are not doing that additional bit of security where you are thinking about the audit trail for this stuff and not thinking about the business logic layer, you are going to completely miss it. So if you want to think about opportunities for detection, Day 1, this is where we have some low severity alerts good for hunting but not a whole lot else – you don’t want to wake somebody in the middle of the night for this. Day 2 - > this is where the snapshot thing comes into the picture, where our rule packs pay off.