Double-Edged Sword of Cloud Security

Editor's Notes

• #4: https://content.fireeye.com/top-5-cloud/eb-top-5-cloud-security-myths
• #5: 2번째 그래프 - 클라우드 플랫폼 선정시 고려사항 (2016년도 조사시 Reliability 22% / 가용성 20% / 보안 17%)
• #6: 2번째 그래프 - 클라우드 플랫폼 선정시 고려사항 (2016년도 조사시 Reliability 22% / 가용성 20% / 보안 17%)
• #7: 2번째 그래프 - 클라우드 플랫폼 선정시 고려사항 (2016년도 조사시 Reliability 22% / 가용성 20% / 보안 17%)
• #12: 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. 
• #18: 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.
• #19: 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.