Slashdot Mirror
Fired Techie Created Virtual Chaos At Pharma Co.
itwbennett writes "Using a secret vSphere console, Jason Cornish, formerly an IT staffer at the U.S. subsidiary of drug-maker Shionogi, wiped out most of the company's computer infrastructure earlier this year. Cornish, 37, pleaded guilty Tuesday to computer intrusion charges in connection with the attack."
For those wondering how he got caught, he accessed the servers from his home also for the McDonalds just before he accessed them he purchased some food using this credit card.
What's to stop you from backing up their sensitive data and creating your back doors before you hand in your letter of resignation? If you treat your employees well, and create an atmosphere of mutual respect, when the time does come to part ways, the last month or two of employment can be constructively used to tie up loose ends and easing the transition to the next guy. If you, as an employer, have a policy of escorting someone from their workstation the moment they hand in their resignation, you're basically paying someone to twiddle their thumbs while your remaining employees scramble to cover for the guy who now is suddenly gone with no warning, while they must be thinking whether it's really worth it, just to get the same treatment when they are leaving. The "Perp walk" is just as petty a show of revenge as the guy in TFA and as damaging to the future your remaining employees to do their job. The only difference is that it is unfortunately not illegal.
Yes... it's the "how can you get away with it?" question that boggles the mind. If you can't think at least that far ahead, then you should refrain from doing more than "wish damage." (You know, I wish something bad would happen to them because I hate them kinda thing?)
If it were me, I would do something more subtle... something based on a cron job perhaps ... something that runs, clears out logs and other things, mounts VMDKs, deletes random files, exchanges the file names of various random pairs of documents and things like that. It would be weirdness that people would dismiss at first as human error which give the trail time to grow colder and bad backup data to get worse and then at some point just go all-out, destroying itself and the systems -- preferably killing the hardware in some way. Even then the chances of getting caught are pretty good as it would be a careful balance of luck and planning to create this gradual corruption of data that wouldn't go noticed until it was too late... perhaps only corrupt files older than a certain date which are not as likely to be accessed for a long while.I suppose that would be enough to allow the corruption of backups and such along the way...
Anyway, the first thing should always be to plan not to get caught or even suspected.
Here is one small step that was taken by a high end hosting provider
All the systems had locked root passwords; nobody knew the actual root passwords; and they were different for each system.
All root is done via sudo except for the system console, which is in the locked server room
To gain sudo access, this is what happens
First you go onto a secure database that is tied in with the trouble ticket system. You log in using a token. You request root access to server x. The system checks to see that you are supposed to be able to have root for server x and it checks to see that you are working on a currently open trouble ticket for an application on server x.
If the secure database is happy, it sends a message to another secure server (in a different machine room). That system, which has yet another secure database, pulls an ssh private key from the database, installs it as a ssh private key in order to do an ssh shell session with the server you want to get on. That session runs a script that changes the /etc/sudoers to add your name. Along with that, it sets off a cron job that forces the /etc/sudoers fill back to its original configuration after a set ammount of time.
You log in, do sudo, and do your stuff. All logging is done to what I call a toilet paper machine (paper log) in yet another secure room. You are through and log off. You close the ticket. The entire process as described above is done but to restore the /etc/sudoers file back to the way it was. Even if you 'forget' to close the ticket, the timer cron noted above will still revoke your access to sudo and send an email to security.
The secure database servers noted above, each located in its own secure location, require two people authentication to access root. For those machines, the root password is split in half. One half is known by each of two key people. They both need to log in at the same time.
This is about the most paranoid root access that I am aware of.
Most Respectfully Yours Mark Allyn Bellingham, Washington