Earlier this month, Tesla CEO Elon Musk learned of a security breach perpetrated by one of his own employees. The incident was described by Musk as an employee “making direct code changes to the Tesla Manufacturing Operating System under false usernames and exporting large amounts of highly sensitive Tesla data to unknown third parties.” The Tesla employee was thought to have done this because he felt that the company were acting inappropriately and saw himself as a whistle-blower of sorts.
The breach is the latest in a long line of examples of how organizations, both large and small, still are not taking insider threats seriously enough. Whatever the motivations were for the breach, the origin is the same; inappropriate access to sensitive data granted to an untrustworthy employee. It’s a simple enough concept to implement across your systems, yet so many organizations continue to operate on a policy of trust.
So, as we like to do with security breaches of this kind, what lessons can we learn from Tesla to ensure your organization doesn’t repeat the same steps?
Who Has Access to Your Sensitive Data?
First, you need to know where your sensitive data resides (i.e. files and folders containing Personally Identifiable Information or confidential and trade secret related information). If your organization stores data in File Servers, then you should be able to use the in-built File Classification Infrastructure to discover, classify and rank your data in order of criticality.
Once you’ve found where your sensitive data is you’ll need to know who has permissions to access and modify this data. These are your most critical employees to monitor. Many IT security solutions will enable you explore who has these permissions, how they were granted and compare them to historic permissions.
Are You Enforcing a Policy of Least Privilege?
So, you now know who has access to PII in your organization, but, does everyone that has the permission need it? There are only a handful of employees in most organizations that genuinely need access to your most critical files and folders, and these are usually limited to C-level. Ensure that all your employees only have access to the data they need to do their job, nothing more.
Be sure to keep a close eye on whenever job roles change or when employees leave the business. Permissions will need to be modified in these cases to minimize the risk of privilege abuse. The Tesla breach would seem to suggest that they were not operating on a policy of least privilege and were seriously lacking in adequate user monitoring practices.
Do You Know What Your Users Are Doing with Your Data?
If you have adopted the first two points in this article, then you know where your sensitive data is, who has access to it and have enforced a policy of least privilege. However, the job isn’t done quite yet. Perhaps the most important thing you will need to do is ensure that you are monitoring user behaviour in relation to your sensitive data. If ever a change is made to a file or folder containing PII, you need to know the details of that change (who, what, where and when – as a minimum).
Now, for this point, native auditing simply isn’t going to get the job done. It’s too reactive, too difficult to derive meaning from raw logs and generally too time consuming. If you’re serious about cyber-security, you need to implement a change auditing solution, like LepideAuditor. LepideAuditor is a comprehensive auditing solution that will help you avoid privilege abuse, discover, classify and run reports on sensitive data and audit changes made to your IT systems and data in real time. For more on how LepideAuditor can help your organization, contact us today.
Let’s not allow the Tesla breach to just be another high profile, avoidable breach that is doomed to be repeated. At least, ensure your organization is doing everything in its power not to let that happen.