Newsflash: we’re all human. Mistakes will be made. Unfortunately in IT security, when you’re dealing with company, employee and customer systems and data, it’s likely that a mistake will be harmful to one or all of those stakeholders.
GitLab: a great example of transparency and a reminder of insider risk and threat
This week we learned that GitLab, a San Francisco based startup that provides a virtual workspace for programmers, had lost nearly 4.5 GB of customer data because a system administrator had mistakenly deleted a primary database and the backup systems weren’t working.
Most of the news articles I’ve read have focused on the backup issue. No one has really addressed the security and operational risk side of the story, other than to say the sysadmin was tired and working overtime.
And that’s exactly a great example of what elevates the insider risk and the need for “guardrails” – a system of checks and balances that put operational controls around privileged users, their access and activity.
This becomes even more important as the industry faces an incredible shortage of skilled IT security professionals. Those on the job will be forced to work more hours and asked to handle more duties, increasing the risk of mistake.
Important note: The transparency and openness that GitLab used when notifying and correcting their data loss problem should be (and has been) commended by the industry. The transparency helped their customers help themselves.
Managing the activity of those privileged users with all-access passes
Sysadmins and other privileged users have the equivalent of an all-access pass to your favorite concert. They have unfettered access to systems and resources in order to do their job. But that access doesn’t mean there shouldn’t be operational checks and balances and monitoring of what they’re doing. That is a must! Imagine if the GitLab sysadmin or Terry Childs had been:
- prevented from running certain commands on specific databases or servers (such as the production server)
- prompted for additional confirmation before the command was executed
- required to use different passwords for different databases
- had sessions recorded and reviewed for accuracy and data loss prevention (leading to at least one of the backup failures being caught beforehand)
The same privileged access tools used to secure and protect against malicious, outsider attacks are also tools to safeguard against errant legitimate operations and help ensure insider mistakes are prevented or caught before the damage is done. One tool, multiple uses – just like a Swiss Army Knife.
Look at it this way: There are controls that prevent us all from accidently copying a file over one that already exists with the same name; wouldn’t it makes sense to add similar safeguards for an operation that attempts to delete an entire production database from a system?