Headlines about the data breach on Facebook continue to abound.
Entirely unlike site hacks where credit card information was stolen at major retailers, the company in question, Cambridge Analytica, had the right to use this information.
Unfortunately, they used this information without permission and in a way that is blatantly misleading to both Facebook users and Facebook itself.
Facebook CEO Mark Zuckerberg has promised to make changes to prevent this type of information misuse from happening in the future, but it looks like many of those adjustments will be made internally.
Individual users and businesses must still take their own steps to ensure that their information remains as protected and secure as possible.
For individuals, the process to improve online protection is quite simple. This can range from leaving sites like Facebook altogether to avoiding so-called free quiz and game sites where you are asked to provide access to your and your friends’ information.
A separate approach is to employ different accounts. One could be used to access major financial sites. A second and others could be used for social media pages. Using a variety of accounts can lead to more work, but adds additional layers to keep an insider out of your key data.
Businesses, on the other hand, need an approach that is more holistic. While nearly everyone employs firewalls, access control lists, account encryption, and more to prevent an attack, many companies fail to maintain the framework that leads to the data.
An example is a company that employs user accounts with rules that require regular password changes, but are lax about changing credentials to their infrastructure devices for firewalls, routers, or password switches. In fact, many of these never change.
Those who use web data services must also modify their passwords. A username and password or API key is required to access them, which are created when the app is created, but are rarely changed. A former staff member who knows the API security key for your credit card processing portal could access that data even if he was no longer employed by that business.
Things can get even worse. Many large companies use additional signatures to help with application development. In this scenario, the software is copied to additional companies’ servers and may contain the same API keys or username/password combinations that are used in the production application. Since most are rarely changed, a disgruntled worker at a third-party company now has access to all the information he needs to get to the data.
Additional processes must also be taken to prevent a data breach from happening. These include…
• Identify all devices involved in public access to 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 of any ACL on this path leaves the company.
• Identify all passwords for embedded applications that access data. These are passwords that are “built in” to the applications that access the data. Change these passwords frequently. Change them when anyone working on one of these software packages leaves the company.
• When using third-party companies to assist in application development, set up separate third-party credentials and change them frequently.
• If you use an API key to access web services, request a new key when the people 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 themselves from this? It’s a little tricky but not out of reach. Most database systems have auditing built in and unfortunately it is not used correctly or not used at all.
An example would be if a database had a data table that contained customer or employee data. As an app developer, one would expect an app to access this data; however, if an ad-hoc query was performed that queried a large portion of this data, properly configured database auditing should, at a minimum, provide an alert that this is happening. .
• Use change management to control change. Change management software should be installed to make it easier to manage and track. Lock down all non-production accounts until a change request is triggered.
• Don’t trust internal audit. When a company audits itself, it usually minimizes potential defects. It is better to use a third party to audit your security and audit your policies.
Many companies provide auditing services, but over time, this writer found that a forensic approach works best. Analyzing all aspects of the framework, building policies and monitoring them is a must. Yes, it’s a hassle to change the entire device and built-in passwords, but it’s easier than taking on public opinion when a data breach occurs.