Slashdot Mirror
How to Prepare for an IT Security Disaster (Video)
What should you do if your company's servers are hacked and your customers' credit card info or other data are stolen? Neill Feather, president of SiteLock, says you should have a plan of action tested and ready to go, the same way it's wise to hold fire drills so that everyone knows what to do in case of fire. Neill also recommends checking out the Online Trust Alliance and the many resources it makes available to businesses of all sizes whether or not they are OTA members. One document that would be a good place to start is their Data Protection & Breach Readiness Guide, which covers topics including liability and insurance considerations; basic forensics (to help catch the evildoers -- and prevent them from doing evil to you again); and even what information you should include in a letter to customers after a Target or Home Depot-type data theft. We can sum all of this up with the old saying, 'An ounce of prevention is worth a pound of cure,' but you should also know what to do if a problem happens, whether that problem is data theft, a ransomware attack or anything in between.
...not some nodding donkey pumps. That would be a good start.
But only practical for the it dept. And direct staff. I have never once succeeded in getting realistic ds involvement outside of primary it. Even massive banks sign only the most lowly of other departments to check legally required and audited dr runs, let alone scenario testing. Oh for it utopia.
If these drills make the pointy haired bosses stop thinking IT security purely as a cost to be minimized it would do some good. If an IT dept works well and prevent disasters they never get credited for it. It they slip up and make a huge mistake, they get fired. If the best reward you can hope for is "not getting fired", it will attract a level of talent that considers "not getting fired" an achievement and goal. Unless the management mentality changes IT disasters will keep happening. At least if we fired the top management too along with IT disasters and sue the corporate board for mismanagement, then they might pay attention.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Keep your resume up to date, and off site.
Don't have any data that you don't actually need. Like Credit Card data. Most companies don't need that info. The companies I worked for let the credit card payment being handled by others.
So what we had was basically their adress and what they orderd. That didn't mean we were not trying to protect anything, because we did not wanted to be hacked, but we made ourselves much less of a target.
And if you do need the credit card numbers, you should not be reading this article, you should be writing it.
Don't fight for your country, if your country does not fight for you.
Go to the press, say "we got hacked! not our fault! hackers did it!".
Everyone'll believe you and won't blame you. Always works. Just look in the press, plenty succesful examples.
And yeah, this is stupid. Then again, confuse hackers and crackers, paint yourself stupid. Say "cyber" while at it, too.
Since IT has so many facets, I have a nice buffet of choices to choose from for IT disaster scenarios:
1: A bad guy gets access to the SAN, drops all LUNs, then resyncs all drives as empty mirrored pairs, overwriting all data in the array with garbage.
2: Someone logs onto the HID card reader server and deletes all users from all doors. Much fun ensues as a lot of the doors have no backup mechanical keys, and the ones that do, someone stuffed half a key in.
3: Someone logs on remotely to the HVAC system and shuts it off in the middle of the night, then kills the door locks. All servers are now thermally shut down or off because they barbecued themselves.
4: Someone changes the master tape password on the silo... six months later, the silo is then reset, so all tapes in the meantime are not accessible.
5: Someone erases your KMS server and forces a "slmgr /upk" on all boxes in the domain forest.
6: Someone purged the config from your fabric, and the TFTP server has all backup configs erased.
7: Someone uses your Netbackup master server to force restores from random client "A" to client "B", hosing everything, without a single admin password or AD cred needed.
8: Your BlueCoat device now ships its SSL interception logs offshore, so personal banking of employees and everything else can be easily sifted through.
9: Someone logs on as employees, then sends bogus E-mails to all clients.
10: Your SecurID server is purged, as well as the backup. Now the admins can't log onto the routers.
Lots of disasters to chose from. Main thing to do is defense in depth, and isolate/segment.
My plan for billing data is to put the whole thing on a separate off-line system dedicated to the job. The customer-facing system for updating billing information won't have complete information, credit-card numbers and such will be masked (assuming we need them, as much as possible I plan to offload that to services that do payments for a living). Customer updates will be split, masked data will be used to update the customer-facing system's data while the complete copy will go through a write-only interface to the back-end systems after being encrypted using a solid public-key system so any encryption keys an attacker could get hold of won't permit decryption even if they get their hands on the change data in transit.
Out front the database will be handled by a back-end Web service so the front-ends that handle Web browser requests won't have direct access to the database. All requests get session-authenticated so a compromise of a front end doesn't give unlimited access to the back end. And the whole system's designed so any front-end or back-end node that's compromised can be instantly killed off without causing problems for the overall system. If I can get the time to re-image a node from a clean image low enough, I should be able to buy enough time by blowing their footholds out from underneath them to identify the attack and block it. Engineer the interfaces so I can do security updates to the nodes on-the-fly without disrupting things and that all should make life utterly miserable for anyone trying to get access to the data. DoS is a separate matter, but there's solutions for that I can use too.
"I'm a denizen of a.s.r, of course I'm paranoid. The question is am I paranoid enough?"
01) Keep regular backups.
02) Assume the opposition already jhave full access to your network.
03) Keep regular backups.
And I guarantee you'll have yourself an IT security disaster in no time!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I once worked with a small web site owner to help clean up phishing sites that were on his site. We had a bit of trouble finding the last one on the server, a mix of my inexperience with web server configs and lacklustre support from his web host. Site Lock were convinced his site was 100% clean, even when the owner kept giving them the URL of the phishing site which was still working. They kept saying his site was clean, he has nothing to worry about! And to keep your site clean, why don't you pay us $LOL to help keep it secure?
Quit?
I art more snarky, and terse than thou. I art Slashdot!
Bloody Mary's and Bloody Geisha's alternating for at least 20 days.
Ha ha
FU
Video fine very wonderfull thank you
nice post