Business
What we learned from the Facebook breach

What we learned from the Facebook breach

Headlines about the Facebook data breach continue to abound.

Totally different from the site hacks where credit card information was stolen at major retailers, the company in question, Cambridge Analytica, had a right to use this information.

Unfortunately, they used this information without permission and in a way that was openly misleading both to Facebook users and to Facebook itself.

Facebook CEO Mark Zuckerberg has promised to make changes to prevent this kind of data misuse from happening in the future, but it looks like a lot of those tweaks will be made internally.

Individual users and businesses still need to take their own steps to ensure that their information remains as safe and secure as possible.

For people, the process of improving online protection is quite simple. This can range from abandoning 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 be more work, but adds additional layers to keep an insider from your key data.

Companies, on the other hand, need an approach that is more comprehensive. While almost everyone employs firewalls, access control lists, account encryption, and more to prevent an attack, many companies fail to maintain the framework that leads to data.

An example is a company that employs user accounts with rules that require regular password changes, but are lax about changing credentials on their infrastructure devices through firewalls, routers, or password switches. In fact, many of these never change.

Those who use web data services must also change their passwords. A username and password or an 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 or she was no longer employed at 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 the data.

Additional processes must also be taken to prevent a data breach from occurring. 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 these devices. Again, change the passwords used to access these devices frequently, and change them when any member of any ACL in 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 who works on one of these software packages leaves the company.

• When using third-party companies to help with 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 bit 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 made 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. Block all non-production accounts until a change request is triggered.

• Don’t trust internal audit. When a company audits itself, it generally minimizes possible 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 has 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 your entire device and built-in passwords, but it’s easier than facing public opinion when a data breach occurs.

Leave a Reply

Your email address will not be published. Required fields are marked *