Data security lessons learned from the Facebook breach
The data breach at Facebook continues to make headlines.
Different than the site hackings where credit card information was actually stolen at major retailers, the company in question, Cambridge Analytica, actually had the right to use this data.
The problem is they used this information without permission in a way that was overtly deceptive to both Facebook users and Facebook itself.
While Facebook CEO Mark Zuckerberg has vowed to make changes to prevent these types of information grabs from happening in the future, many of those tweaks will be presumably made internally. Individuals and companies still need to take their own action to ensure their information remains as protected and secure as possible.
For individual users the steps to enhance online protection are fairly simple. This can range from leaving sites such as Facebook altogether, to avoiding free game and quiz sites that require you to provide access to your information and that of your friends.
Another approach is to employ different accounts, one for access to important financial sites and another for social media pages. Utilizing a variety of accounts can create more work but it adds additional layers to keep a hacker away from your key data.
Businesses on the other hand need to take a more comprehensive approach. While most employ firewalls, access control lists, encryption of accounts and more to prevent a hack, many fail to maintain the framework that leads to data.
For example, companies employ user accounts with rules that force changes to passwords regularly, but are lax in changing their infrastructure device credentials for firewalls, routers or switch passwords. Some of these, in fact, never change.
Passwords for web data services also need to be altered. A username and password or an API key are required for access to web data services. These are created when the application is built, and again they are rarely changed. A former staff member who knows the API security key for their credit card processing gateway, could access that data even if they were no longer employed at that company.
It can get even worse. Many large companies utilize additional firms to assist in application development. In these scenarios, the software is copied to the additional firms’ servers and may contain the same API keys or username/password combinations that are used in the production application. Since these are rarely changed, a disgruntled worker at a third party firm now has all the information they need to access the data.
Additional steps should also be taken to prevent a data breach from occurring. These include…
- 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.
Analyzing all aspects of the framework, building policies and monitoring them is a necessity. Yes it is a pain to change all the device and embedded passwords, but it is easier than facing the court of public opinion when a data breach occurs.