Learned From The Facebook Breach

  • Identifying all devices involved in public access of company data including firewalls, routers, switches, servers, etc. Develop detailed access-control-lists (ACLs) for all of these devices. Again change the passwords used to access these devices frequently, and change them when any member on any ACL in this path leaves the company.
  • Identifying all embedded application passwords that access data. These are passwords that are “built” into the applications that access data. Change these passwords frequently. Change them when any person working on any of these software packages leaves the company.
  • When using third party companies to assist in application development, establish separate third party credentials and change these frequently.
  • If using an API key to access web services, request a new key when persons involved in those web services leave the company.
  • Anticipate that a breach will occur and develop plans to detect and stop it. How do companies protect against this? It is a bit complicated but not out of reach. Most database systems have auditing built into them, and sadly, it is not used properly or at all.
    An example would be if a database had a data table that contained customer or employee data. As an application developer, one would expect an application to access this data, however, if an ad-hoc query was performed that queried a large chunk of this data, properly configured database auditing should, at minimum, provide an alert that this is happening.
  • Utilize change management to control change. Change Management software should be installed to make this easier to manage and track. Lock down all non-production accounts until a Change Request is active.
  • Do not rely on internal auditing. When a company audits itself, they typically minimize potential flaws. It is best to utilize a 3rd party to audit your security and audit your polices.