Leveling Up Security :: 2015 v 2018

In this talk, Mark will be discussing his 5+ years at Riot Games where the InfoSec team has developed a security program (https://engineering.riotgames.com/news/evolution-security-riot)
based on feedback and self-service, across a truly hybrid infrastructure.

Starting with a recap of his 2015 BruCON talk (Feedback Security), Mark will dive into where the team failed and succeeded in the years since the talk. He will dive into areas such as:

- internal RFCs
- developer education & collaboration on solutions
- receiving feedback when the team don't hit the bar and acting on it
- in-house tools designed and developed to provide visibility into the security posture of AWS
- open-sourcing tools and contributing to other open-source projects

An attendee should:

- see some pretty cool art (not created by Mark, obviously)
- understand where the Riot InfoSec team failed and succeeded
- learn about a self-service, feedback-driven approach to security, where the InfoSec team is embraced, not hated

Disclaimer :: There will be no cool exploits, 0days or buffer overloads in this talk.

Transcript

1. Leveling Up Security @ Riot 2015 v 2018
2. AGENDA Getting to the Nexus 2018 2015 Who
3. Older than I’d like to imagine Do InfoSec stuff Would rather be Who Am I? @markofu
4. 100 MILLION MONTHLY ACTIVE PLAYERS MORE THAN 27 MILLION DAILY ACTIVE PLAYERS MORE THAN 7.5 MILLION PEAK CONCURRENT PLAYERS
5. Aspire eSports
6. Aspire Who Are We?
7. AGENDA Who Getting to the Nexus 2015 2018
10. IR
11. !! # of VPNs VPC VPC VPC AWS
12. What brought us agility also brought us the Wild Wild West of Computing
15. RFCs=Tech Design
16. RFC Feedback Not an approval process, it’s about receiving advice! Becomes a standard through adoption @ scopes Received comments & iterate through the draft
17. Goal :: Alignment with Rioters on a secure standard for our office builds, with our offices being treated as code Why :: We had no visibility and couldn’t do Incident Response effectively How :: Document, Receive Feedback, Iterate & ultimately create a defendable network capable of alerting and forensics RFC0242
20. AGENDA 2015 Who 2018 Getting to the Nexus
23. Team
24. Where :: All offices worldwide (mandatory for code access) How :: Automation& lots of air miles What :: Centralisedlogging, Visibility, “Office as Code” & Threat Intel RFC0242
28. $
29. Prevention Deterrence Detection Strategy
34. Secrets
35. Provides temporary AWS API tokens (via STS) & activity monitoring MinimizeRemove the use of long-lived AWS API Keys => Less Impact Metrics AWSKey
39. Cloud is Magic
40. Storytime
41. Problem Statement While AWS is a great place to rapidly iterate and test new features, the vast number of accounts, instances and usage has no easy way of attributing a running instance back to an owner or feature. Ownership
42. Boil The Ocean
43. Why :: Incident Response is hard when you don’t know who owns what Why :: If you don’t need it, why is it running? What :: Tagging is incredibly easy to use to identify ownership What, where, who?
45. Shrink the change => No decision paralysis Feedback & moved to the adoption stage Standard across Riot Solution
46. Required Tags :: Name, Owner & Accounting Schedule At 0, 21 and 27 days => Notify Gatekeeper and owner (if possible) At 4 weeks => Shutdown Instance At 12 weeks => Terminate Instance Tagging Details
47. Removes incorrectly tagged & un-owned AWS objects Checks that security features are turned on throughout our AWS Infra DNS hijacking & IAM policy management Cinq Features
48. Code Time
49. MurderBot
50. Sad
51. Our communications & planning had gaps Confusion around RFC Adoption Our notification code had bugs Learnings
52. Feedback “By doing a RCA, the team has truly showed themselves to be part of Engineering. We all make mistakes - this is how we learn and improve. /fistbump ” Cam Dunn (Tech Director), Dec. 2016
53. 2nd Adoption, Yay! bcc Engineering “Thanks for everyone's input and consideration for RFC0026, aka MurderBot,over the last several weeks. This is now adopted at Riot scope.” Mike Seavers (Director of Engineering), Feb. 2017
56. The following resources are not compliant with the Required Tagging standards…….. Issues Resource Resource Type Account Region Missing tags Notes Alert Info i-0xyz EC2 Instance marky-mark us-west-2 owner, accounting No Notes 27 days alert i-1xyz EC2 Instance marky-mark us-west-2 owner, accounting No Note Resource stopped i-2xyz EC2 Instance marky-mark us-west-2 owner Owner tag is not valid Resource removed i-3xyz EC2 Instance marky-mark us-west-2 name No Notes 0 seconds Email Notify
57. OSS Cost
58. AGENDA 2015 Who Getting to the Nexus 2018
59. RFC0242 :: Our focus is changing from Riot to Rioter Auth :: No permanent credentials & enforced dynamic access policies Everywhere :: More attribution & platform-independent solutions Futures (1)
60. New & Shared :: Work with new products & try to solve with solutions that can be leveraged by many Measure :: Are we doing any good? If so, how and where? Collaboration :: Bug Bounty++, OSS++ , Tools & Blogs (Int& Ext) Futures (2)
61. Started :: DFIR & Emergent Next :: Visibility, Being Embraced, Collaboration & Tools Now :: Tools within Workflows, Occasional Blocking & Measurement Evolution
62. Thank You