logs and backups

Download Logs And Backups

If you can't read please download the document

Upload: charles-southerland

Post on 18-May-2015

51 views

Category:

Technology


0 download

DESCRIPTION

An idea for a log and backup policy that reduces the possibility of and potential damage from insider threats. Presented at Information Warfare Summit 2013.

TRANSCRIPT

  • 1. Logs and BackupsLogs and Backups Charles Southerland (a.k.a. proidiot)Charles Southerland (a.k.a. proidiot) Stuph LabsStuph Labs Information Warfare Summit 2013Information Warfare Summit 2013

2. Imagine an outsider trying to deface yourImagine an outsider trying to deface your organization's website.organization's website. We'll say they're using SQL injection to do this.We'll say they're using SQL injection to do this. 3. The logs will likely give you a trove of informationThe logs will likely give you a trove of information about how the attack occurred, and the backupabout how the attack occurred, and the backup will allow you to revert the changes quickly.will allow you to revert the changes quickly. 4. Now imagine getting attacked by an insider.Now imagine getting attacked by an insider. 5. Those backups suddenly become a liability.Those backups suddenly become a liability. 6. And those logs, which can usually be modifiedAnd those logs, which can usually be modified with ease by an insider, will probably not help youwith ease by an insider, will probably not help you figure out who attacked, how they attacked, orfigure out who attacked, how they attacked, or perhaps even that they attacked at all.perhaps even that they attacked at all. 7. In fact, the logs might be almost as bad to leak asIn fact, the logs might be almost as bad to leak as your backups.your backups. 8. Unfortunately, there doesn't appear to be a goodUnfortunately, there doesn't appear to be a good one-size-fits-all way to deal with backups and logsone-size-fits-all way to deal with backups and logs with respect to insider threats at this time.with respect to insider threats at this time. 9. I have no doubt that there is some vendor outI have no doubt that there is some vendor out there that will sell you a security in a boxthere that will sell you a security in a box solution to this problem, but I seriously doubt suchsolution to this problem, but I seriously doubt such a solution would be a good choice for manya solution would be a good choice for many organizations.organizations. 10. ...but I have some ideas that might work for some...but I have some ideas that might work for some organizations.organizations. 11. First: rethink backupsFirst: rethink backups 12. Why you might need to recover from backups:Why you might need to recover from backups: Something went wrongSomething went wrong and you can recover quicklyand you can recover quickly Something catastrophic happenedSomething catastrophic happened and you must recover carefullyand you must recover carefully 13. The best solution to non-breach recoveryThe best solution to non-breach recovery is failover.is failover. After all, the time it takes to restore from aAfter all, the time it takes to restore from a backup is still downtime.backup is still downtime. 14. For the actual backups, separately backupFor the actual backups, separately backup sensitive user data, other business data, etc.sensitive user data, other business data, etc. 15. Use a configuration management system (e.g.Use a configuration management system (e.g. Chef, Puppet, CFEngine) and back up those filesChef, Puppet, CFEngine) and back up those files in a form that necessary personnel can quicklyin a form that necessary personnel can quickly decrypt and use as needed.decrypt and use as needed. 16. Encrypt all backups using a cryptosystem that isEncrypt all backups using a cryptosystem that is appropriate for the sensitivity of the particularappropriate for the sensitivity of the particular data, and be sure to always verify the authenticitydata, and be sure to always verify the authenticity of the data (e.g. md5sum).of the data (e.g. md5sum). 17. Limit access to the onsite backups to a handful ofLimit access to the onsite backups to a handful of people, and choose different people to grantpeople, and choose different people to grant access to the crypto keys for those onsiteaccess to the crypto keys for those onsite backups.backups. 18. Very closely monitor and log all access to theVery closely monitor and log all access to the onsite backups. These onsite backups shouldonsite backups. These onsite backups should preferably be kept somewhere that would be verypreferably be kept somewhere that would be very difficult to extract information unnoticed from (i.e.difficult to extract information unnoticed from (i.e. a computer with an air gap to the network).a computer with an air gap to the network). 19. Keep lots of backups in an offsite facility yourKeep lots of backups in an offsite facility your employees don't have access to (e.g. Amazonemployees don't have access to (e.g. Amazon Web Services, Rackspace).Web Services, Rackspace). 20. Amazon's Glacier would probably be a goodAmazon's Glacier would probably be a good choice.choice. 21. Again, profusely log all access to the offsiteAgain, profusely log all access to the offsite backups.backups. 22. Treat access to offsite backups like you do theTreat access to offsite backups like you do the onsite one: encrypt all data, assure differentonsite one: encrypt all data, assure different people have access to the data vs. the keys, etc.people have access to the data vs. the keys, etc. 23. Every 6 months and every time someone leavesEvery 6 months and every time someone leaves who had access to the key or data for the onsitewho had access to the key or data for the onsite backups, immediately destroy the key and data,backups, immediately destroy the key and data, create new keys for the new backups, and thencreate new keys for the new backups, and then randomly assign who will have access to whichrandomly assign who will have access to which keys and data.keys and data. 24. It would be best to have similar practices withIt would be best to have similar practices with regard to the keys and data for the offsiteregard to the keys and data for the offsite backups, but care must be taken not to handlebackups, but care must be taken not to handle these actions in an insecure way.these actions in an insecure way. 25. Next: rethink logsNext: rethink logs 26. It is vital to assure that none of the sensitive dataIt is vital to assure that none of the sensitive data leaks into the logs.leaks into the logs. 27. However, all other data, no matter how menial,However, all other data, no matter how menial, should be recorded into the logs.should be recorded into the logs. 28. Hard drive space is very cheap and big data canHard drive space is very cheap and big data can be extremely useful...be extremely useful... 29. ...so open the floodgates (e.g. this user requested...so open the floodgates (e.g. this user requested this page by following this link from this ip addressthis page by following this link from this ip address at this time from a browser with this agent string)at this time from a browser with this agent string) 30. You can use Apache Hadoop to analyze this dataYou can use Apache Hadoop to analyze this data and do cool things like...and do cool things like... 31. ...make graphs...make graphs 32. ...or determine user preferences...or determine user preferences 33. ...or better protect your network...or better protect your network 34. You will accumulate an incredible amount of logYou will accumulate an incredible amount of log data, but the sheer size could prove to be adata, but the sheer size could prove to be a deterrant to would-be attackersdeterrant to would-be attackers 35. Not to mention that all access to the onsite andNot to mention that all access to the onsite and offsite logs will also be heavily loggedoffsite logs will also be heavily logged 36. Access to the verbose offsite logs will rarely beAccess to the verbose offsite logs will rarely be time sensitive, so access to those keys could betime sensitive, so access to those keys could be much more heavily restricted apart from thosemuch more heavily restricted apart from those timestimes 37. Not all of these suggestions will not work for everyNot all of these suggestions will not work for every organizationorganization 38. The logs you keep on site do not need to be allThe logs you keep on site do not need to be all that verbosethat verbose 39. And you don't really need to keep the onsite logsAnd you don't really need to keep the onsite logs for very long (they're only needed to documentfor very long (they're only needed to document the things that the IT dept can fix in a short time)the things that the IT dept can fix in a short time) 40. Also, as these approaches would likely require aAlso, as these approaches would likely require a significant amount of resources to set up andsignificant amount of resources to set up and maintain, it would likely not be cost effective formaintain, it would likely not be cost effective for some organizationssome organizations 41. However, the kinds of organizations that InfragardHowever, the kinds of organizations that Infragard focuses on would have such a high potential costfocuses on would have such a high potential cost to an insider threat that alternate approaches toto an insider threat that alternate approaches to this problem must at least be consideredthis problem must at least be considered 42. While there is currently no best solution to theWhile there is currently no best solution to the problems that insider threats pose to logs andproblems that insider threats pose to logs and backups, I feel it would be negligent not tobackups, I feel it would be negligent not to continue looking for one.continue looking for one. 43. Questions?Questions?