Today, I saw this interesting piece on insider threats posted to CERT, and was somewhat baffled. I stewed on it a bit, but a Google Reader comment by Carnal0wnage spun up my rant engine. Here, people are actually being urged to spy on their peers then name them and shame then, as if it's totally normal to put bear traps in the server room and roll your own ECHELON, lynching in the commons anyone who dares to raise the ire of the great and awesome security team. They titled their session "What's working to stop these attacks?" It's us versus them.
When I was still a student, years before my real career in information security would take hold, it was commonplace to hear that some unfathomable percent of attacks are from malicious insiders. Maybe it was true in the 1990s. After years of leaving corporate workstations and academic lab computers hanging out on the Internet with public IP addresses and no firewalls, administrators were finally getting a clue, NATting workstations and putting up chintzy first-generation port-blocking firewalls. Students and curious employees were suddenly the ones with unrestricted access to internal systems protected -- if you wish to call it that -- by these prototypical security systems. Maybe this logic made sense back then.
Be that as it may, I've seen more data loss from people bypassing draconian security policy than I've seen data loss from the rare disgruntled trade-secret packrat with one hand in the cookie jar and one foot out the door. That's not to say these things don't happen. They do! But they're not the typical modern insider threat.
At my last job, I would occasionally have the option to work remotely for server maintenance, or instead drive 15 miles to the office at 11:00 PM on a Saturday night, and stay there until 4:00 AM Sunday morning. Working from home meant this:
- Firing up some proprietary piece of VPN software that only ran on Windows.
- Using a 2-factor authentication token to get into the VPN.
- Using RDP to access a "secure" sandbox server, which was pretty much the only thing the VPN would let you access remotely. This required the use of the 2-factor token again, but you had to wait to make sure you didn't use the same one-time key twice in a row.
- Using RDP from that server to get to my desktop, which also ran Windows.
- SSHing from my workstation to a central administration server that was dual-homed and could actually access the servers I needed to work on.
- Performing the work on the servers.