RSA 2016 Realities of Data Security
1 like284 views
This document discusses the realities of data security and provides recommendations. It notes that while data is needed to perform many jobs, it also presents security risks. Issues include human error and the wide distribution of data. The document recommends finding data within an organization, securing it through techniques like encryption and access controls, and ongoing monitoring of both systems and data flows. It stresses applying a multi-layered approach and treating data security as an ongoing process rather than a fixed state due to the dynamic nature of data.
RSA 2016 Realities of Data Security
- 1. SESSION ID: #RSAC Scott Carlson Realities of Data Security PDAC-T09 Director – Security Solutions PayPal @relaxed137
- 3. #RSAC Why should we trust anyone with our Data? 3
- 4. #RSAC People actually need data to do their job Email Marketing Customer Support Business Analytics Financial Analyst Marketing Software Developer Network Operations Security Operations HR / Payroll Fraud Control 4
- 6. #RSAC “Think of how stupid the average person is, and realize half of them are stupider than that.” -- George Carlin The People Problem 6
- 7. #RSAC http://xkcd.com used with permission under Creative commons License 7
- 8. #RSAC So Now What ?? When you are thinking about solving this dilemma, you cannot just worry only about the data itself 8
- 9. #RSAC Data security should strive to Data repositories with restricted/PII data Business work flows & data flows Identify owners, does data leave your network Delete or move into a secure network zone Encrypt data when it is found insecure Create access rights controls & fix bad process Secure It Find It Ongoing monitoring with $tool – users & systems Data scanning tools for compliance Inbound/outbound flow monitoring kill data streams & wall of shame Monitor It 9
- 10. #RSAC Find It Ask Hey, where is our data? Where did this come from? Where is it going? Where Else could It be ? Are you caching anything ? How many copies are there? Has anyone taken it home? Did anyone stick it “in the cloud” Validate Buy Stuff or Build Stuff Data tools haven’t caught up with data systems You cannot find everything with Tagging, sometimes you have to sniff it out Don’t forget your logging systems, file shares, and desktops To sample or not to sample 10
- 11. #RSAC Secure It Zones Build network zones in the right places to house the data where it needed Separate employee zones from customer zones from analytics zones If zones exist, uplift controls to match your new standard Build a common Bill of materials & definition of “Run the business” Encrypt Deploy Hardware Security Modules (HSM) where required Make sure your tools can decrypt where appropriate Keys should be as unique as you need them to be once you encrypt the data, make sure that the data entry point is encrypted too 11
- 12. #RSAC Monitor It Logging Build use cases “Log all activity from DBA’s and watch for select from application tables” Log All the Things; keystroke log if required positive & negative testing required for tools tap, syslog, integrated, custom, modules, … In-Line Detection decrypt data if required deploy at all ingress and egress points that matter tap, DLP, proxies, email, … 12
- 13. #RSAC Multi-Layer Trust Model Data Center ZoneAccess Zone ServerBastion Host Citrix PortalDesktop Data Repository Data User Zone Application Network Applications 13
- 14. #RSAC Controls required around Data Centralized Logging N, H, A Vulnerability Scanning N, H, A Intrusion Detection N Patching Updates N, H, A Web Proxy N Anti-Malware N, H Time Synchronization N Data Loss Prevention N Firewalls N Role-Based Access N, H, A VDI / Citrix / Bastion N Packet Capture N File Integrity H Configuration Control H N=Network H=Host A=Application 14
- 15. #RSAC Risks of Direct Data Controls No one can use the data if its always encrypted Tagging Data on Content? Good luck with that Tagging Data with Users? Easier, but still DLP is only as good as your Regex foo Be ready to customize for NoSQL Solutions Vendors design for “most common”... Know anyone like that ? 15
- 16. #RSAC Monitor the human too 16
- 17. #RSAC Threat Behavior Buckets •No one should EVER do this •No machine should EVER do this Never Anyone (Always Prohibit) •This type of person should never do •This type of machine should never do •This type of data should never go Never This (Point Prohibit) •(Source Location)+(Source Machine)+ (Source Person)+(Target)+(Action) •One of these items is irregular Never Seen (Watch and React) 17
- 18. #RSAC Don’t say NO Say HOW 18
- 19. #RSAC Data Security is not a permanent state 19
- 20. #RSAC Data Security can not work effectively unless you have agility (there’s nothing static about data) 20
- 21. #RSAC Pulling it all off Build technical and business standards related to use of data and control of data - “The Law” Build technical standards related to the controls expected of secure, restricted zones & related to the encryption / access to data – “The How” Find restricted data throughout the company, and scan for locations that should have NO data Identify method to protect the data once found – delete / relocate / protect / encrypt & execute Implement technical controls at the endpoint and network and repository Apply continuous monitoring controls to data & people Build solutions and processes that outlast the people building them 21
- 22. #RSAC For more information, please contact: Scott Carlson sccarlson@paypal.com @relaxed137