I'm sure many of you are aware by now of the data breach at monster.com, which not only affects monster.com users, but also the subsidiary that serves the military, called Military Advantage. Also affected was usajobs.gov (I think I got that right).
As of yesterday Monster could not figure out the extent of the breach and the depth of the data theft (meaning, what kind of data - how granular). But it does appear that names, email addresses, and other such common information were uploaded to a rogue server, which M.com shut down once they figured out where the siphoned-off info was actually going.
They are not able to trace the hackers yet, but I'm sure they're working on it. I'd say they better get the NSA and other such people involved - that's the only way to use the government's brute power to get to the bottom of this mess.
How does this affect most people? One of the main, potentially dangerous, ramifications is that users may be subject to blackmail. Not only that, but knowing most details about a user, including possibly home address, the hackers could initiate the infamous 'Hit Man' scam, where random people got mail that they're on a hit list and if they didn't send a certain amount they'd be killed. Very few people fell for it (from those who actually came forward to report the embarrassing incident) but I'm quite sure a significant majority kept quiet.
So, the same thing could happen here; think about the millions of records that were probably taken, and if you assume that only 1% responded to the blackmail, that's still a very large amount of money for the taking.
Where does the responsibility lie in this case? No question at all -- it's with the CISO if there is one; if not, the COO and CTO.
It's really remarkable that a company such as M.com, which has the trust of millions of job seekers, could not figure out the problem early enough, which would have saved a whole bunch of people a whole bunch of problems.
You also have fake employers posting ads wanting people and then scamming money out of the gullible, or even the street-smart ones. I don't want to sound as if M.com is not a good place to further one's career interests, but I'm still a firm believer in networking - PHYSICAL, human networking.
You know why bin Laden has still not been caught? Lack of humint (human intelligence), that's why. I was reading a very nice article on Newsweek that talked about the hunt for this insanely elusive mass-murderer, and they cited how he uses money as well as punishement (the old carrot-and-stick approach) to get his way and evade the technological might of the most powerful nation in the world.
What does this have to do with data breach? Well, who commits these acts? Not a self-learning, self-aware machine like HAL in 2000: A Space Odyssey (although that's not difficult to do), but HUMANS. It's people like you, like me, like us, who indulge in such nasty acts of damage and destruction.
It's impossible to prevent it (just read about the most current hacking controversy, that China's military is behind the hacking of Pentagon - and UK military's - computers). In this age, data is king; but information is the emperor. Getting random bits and bytes won't accomplish much, but it's the intelligence that puts those bits and bytes together that causes the real damage to the data ecosystem.
Certainly, precautions MUST be taken. All kinds of anti-hacking software should be installed, and users (usually the weakest link) MUST be educated in depth. I've repeatedly stressed the power of education on this blog, but I'm sure nobody at such data-sensitive companies including the government - neither management nor employees - take it seriously. You cannot change such a mindset overnight, but you can certainly take a stab at it.
How?
a. Hire white-hat hackers (Especially a Certified Ethical Hacker) so they can form tiger teams to hunt down vulnerabilities (remember Kevin Mitnick?)
b. Perform vulnerability scans as often as possible
c. Keep AV/Anti Spam/Anti Malware etc software updated to the latest version
d. Educate, educate, educate your employees and raise their awareness to the imminent threat that is the WWW
e. Isolate weak machines (those with vulnerabilities and either fix them or take them down)
f. Have an internal email system and an external system, so even if the external is compromised (which at some point it will) it won't shut the company communciations down. There should be a clear demarcation between the two, and they should NEVER mix
I could go on forever, but I need to stop before this becomes more than a blog and ends up a novella!
Be safe!
Showing posts with label computer safety. Show all posts
Showing posts with label computer safety. Show all posts
Thursday, September 6, 2007
Wednesday, May 16, 2007
Not Again! Yes, Again
http://www.networkworld.com/news/2007/051507-ibm-contractor-loses-employee.html
The link tells the story. Again. Someone. Lost. Critical. Data.
This time the information was unencrypted on some tapes - which makes retrieval a snap for those with the right tools. I think the govt should really step in immediately and pass legislation that would make encryption of all employee-related data mandatory, especially if such data were being physically transported.
I'm going to stop here.
Be safe!
The link tells the story. Again. Someone. Lost. Critical. Data.
This time the information was unencrypted on some tapes - which makes retrieval a snap for those with the right tools. I think the govt should really step in immediately and pass legislation that would make encryption of all employee-related data mandatory, especially if such data were being physically transported.
I'm going to stop here.
Be safe!
Tuesday, May 8, 2007
TSA's Misstep
http://www.technewsworld.com/story/57281.html
So what's new, right?! This expression is becoming very common nowadays, from completely unforgivable sins such as not securing hardware to exposing sensitive data to the general public on an uncontrolled/unmoderated website (the Agriculture department comes to mind).
Let's analyze for a second how such a mishap could occur. Places such as the Los Alamos lab - famous for disappearing drives and dead-end investigations, don't seem to have a clue as to what to do and look for when a critical piece of hardware goes poof!
Lifecycle of a disk (bought separately, and assuming formal processes exist):
a. Requisition for purchase
b. Approval
c. Order
d. Delivery
e. Verification
f. Change Management process approval
g. Implementation/installation
h. Usage
i. Fault - Return to sender
j. EoL
Worker W requests Manager M for extra space and submits requisition, M approves it and sends it to Purchasing for placing the order.
Disk comes through, is verified by the appropriate personnel, and the CM team authorizes the installation of the disk (might involve downtime, reboot etc).
IT installs the disk and brings it online so users can store twenty-thousand copies of the same document so they run out of space way before the projected date and then place more orders.
Say an error crops up on this new disk, which by now has a lot of data, IT will be asked to look into it. IT will try to backup the data to another disk and try to fix it. In the meantime, since most workers have filled up this new backup disk and don't have any problems with it, they're likely to push for IT to delay installing the new disk, which has been fixed by now.
So, IT just waits around, and eventually something happens that causes them to lose track of it. This 'something' is the most dangerous aspect of IT and security because nobody knows what it is (and that's why it's called 'something'). It could be an employee with malicious intent to an ID thief to an innocent misplacing to out and out loss of the disk beyond recovery. This becomes much more of an issue if the disk is to be shipped elsewhere (ironically, for safekeeping or backup) and nobody really knows whether the destination received it, or whether they got the right material, or whether the disk was even sent!
Anyway, all through the steps above, there is no TRACKING of the material. If there were a CMDB in place, then much of this could have been part of its DB and then could be made a traceable and trackale entity.
Then, when a disk went missing, all one would have to do is search for the part number/brand/custom id/tracking number/dept id/destination -- you get the idea -- and take further action. The point is that not much is unknown at that time. Auditing, which should come in between 'h' and 'i' is the one process that people love to hate, but one which may save their (and our) lives one day. As long as regular auditing is done using the CMDB as an authoritative source of existing inventory, one can be assured that such 'issues' won't be so common as one's less likely to be lackadaisical when an audit is due.
Since most people don't even know what a CMDB is, it's going to be hard to convince them or educate them on the importance of such a database. The root problem thus lies in education and awareness. Get familiar with ITIL!
Security is all about education, training, and awareness. As Fox Mulder put it, TRUST NO ONE. This doesn't mean you incur the wrath of your boss for asking him 20 questions on why he wants to see your code, but that anyone that's not in your immediate circle of trust (something like PKI) should not be privy to your sensitive data. The idea is Need to Know comes before everything else.
Coming back to this intriguing case of the missing disk, here's how I'd do it (all of these trackable details such as tracking number etc would go into the CMDB):
a. Requisition generated by user (tracking number (tn) 1234)
b. Approval by manager (tn, approval id (aid) A45)
c. Order (tn, aid, order number (on) O858)
d. Delivery (tn, aid, on, delivery date (dd) 05/08/2007, shipper id (sid), dept id (did))
e. Verification (tn, aid, on, dd, sid, deptid, verification id (vid))
f. CM approval (tn, aid, on, dd, sid, deptid, vid, chg mgr approval id (cmid))
g. Ticket to install/installation (tn, aid, on, dd, sid, deptid, vid, cmid, iticket)
h. Usage
i. Fault (tn, aid, on, dd, sid, deptid, vid, cmid, fticket)
j. Shipping (tn, aid, on, dd, sid, deptid, vid, cmid, fticket(if fault), rticket (if request to ship), sid, sender deptid, receiver deptid, slaid (service level agreement id))
k. EoL
As you can see, everything here can be traced to the finest level - nothing can escape scrutiny, and accountability is preserved.
As for data structure, when I say verification id, the id should point to a table that contains at least the original requisition id, the id of the person performing the verification, the outcome, destination dept, contact who will pick up the disk, and anything else that may matter).
I realize it sounds like overkill, but try facing 10,000 workers after 'losing' their most precious and sensitive information. Their stares alone will jolt you into becoming an evangelist for data safety, if the govt/sanctions/bad reputation don't get there first.
Be safe!
So what's new, right?! This expression is becoming very common nowadays, from completely unforgivable sins such as not securing hardware to exposing sensitive data to the general public on an uncontrolled/unmoderated website (the Agriculture department comes to mind).
Let's analyze for a second how such a mishap could occur. Places such as the Los Alamos lab - famous for disappearing drives and dead-end investigations, don't seem to have a clue as to what to do and look for when a critical piece of hardware goes poof!
Lifecycle of a disk (bought separately, and assuming formal processes exist):
a. Requisition for purchase
b. Approval
c. Order
d. Delivery
e. Verification
f. Change Management process approval
g. Implementation/installation
h. Usage
i. Fault - Return to sender
j. EoL
Worker W requests Manager M for extra space and submits requisition, M approves it and sends it to Purchasing for placing the order.
Disk comes through, is verified by the appropriate personnel, and the CM team authorizes the installation of the disk (might involve downtime, reboot etc).
IT installs the disk and brings it online so users can store twenty-thousand copies of the same document so they run out of space way before the projected date and then place more orders.
Say an error crops up on this new disk, which by now has a lot of data, IT will be asked to look into it. IT will try to backup the data to another disk and try to fix it. In the meantime, since most workers have filled up this new backup disk and don't have any problems with it, they're likely to push for IT to delay installing the new disk, which has been fixed by now.
So, IT just waits around, and eventually something happens that causes them to lose track of it. This 'something' is the most dangerous aspect of IT and security because nobody knows what it is (and that's why it's called 'something'). It could be an employee with malicious intent to an ID thief to an innocent misplacing to out and out loss of the disk beyond recovery. This becomes much more of an issue if the disk is to be shipped elsewhere (ironically, for safekeeping or backup) and nobody really knows whether the destination received it, or whether they got the right material, or whether the disk was even sent!
Anyway, all through the steps above, there is no TRACKING of the material. If there were a CMDB in place, then much of this could have been part of its DB and then could be made a traceable and trackale entity.
Then, when a disk went missing, all one would have to do is search for the part number/brand/custom id/tracking number/dept id/destination -- you get the idea -- and take further action. The point is that not much is unknown at that time. Auditing, which should come in between 'h' and 'i' is the one process that people love to hate, but one which may save their (and our) lives one day. As long as regular auditing is done using the CMDB as an authoritative source of existing inventory, one can be assured that such 'issues' won't be so common as one's less likely to be lackadaisical when an audit is due.
Since most people don't even know what a CMDB is, it's going to be hard to convince them or educate them on the importance of such a database. The root problem thus lies in education and awareness. Get familiar with ITIL!
Security is all about education, training, and awareness. As Fox Mulder put it, TRUST NO ONE. This doesn't mean you incur the wrath of your boss for asking him 20 questions on why he wants to see your code, but that anyone that's not in your immediate circle of trust (something like PKI) should not be privy to your sensitive data. The idea is Need to Know comes before everything else.
Coming back to this intriguing case of the missing disk, here's how I'd do it (all of these trackable details such as tracking number etc would go into the CMDB):
a. Requisition generated by user (tracking number (tn) 1234)
b. Approval by manager (tn, approval id (aid) A45)
c. Order (tn, aid, order number (on) O858)
d. Delivery (tn, aid, on, delivery date (dd) 05/08/2007, shipper id (sid), dept id (did))
e. Verification (tn, aid, on, dd, sid, deptid, verification id (vid))
f. CM approval (tn, aid, on, dd, sid, deptid, vid, chg mgr approval id (cmid))
g. Ticket to install/installation (tn, aid, on, dd, sid, deptid, vid, cmid, iticket)
h. Usage
i. Fault (tn, aid, on, dd, sid, deptid, vid, cmid, fticket)
j. Shipping (tn, aid, on, dd, sid, deptid, vid, cmid, fticket(if fault), rticket (if request to ship), sid, sender deptid, receiver deptid, slaid (service level agreement id))
k. EoL
As you can see, everything here can be traced to the finest level - nothing can escape scrutiny, and accountability is preserved.
As for data structure, when I say verification id, the id should point to a table that contains at least the original requisition id, the id of the person performing the verification, the outcome, destination dept, contact who will pick up the disk, and anything else that may matter).
I realize it sounds like overkill, but try facing 10,000 workers after 'losing' their most precious and sensitive information. Their stares alone will jolt you into becoming an evangelist for data safety, if the govt/sanctions/bad reputation don't get there first.
Be safe!
Monday, April 16, 2007
Keeping Children Secure on the Net
http://www.mercurynews.com/business/ci_5677788
An inspiring read - however, the parents simply talk about online security. Here are the concerns:
1. Kids will be exposed to images/video/text that are totally inappropriate or even dangerous
2. Kids will download spyware and assorted malware/adware because they surf in ignorance
3. Kids are in danger from predators
4. Kids will communicate with anyone that seems friendly or offers comfort or shows interest or praises them (most kids nowadays are starved of love and attention because both parents typically work) - and provide easily identifiable information
How do you watch them?
Some tips:
1. Do not give them their own personal computer till they are at least 17
2. Do not let them take the computer to their room
3. Force them to interact with websites in 'public' - meaning the living room
4. Inform them that you have Internet monitoring software and that you know what they are doing anytime they're online
5. Monitor the sites they visit, noting down what they post and who they interact with on social networking sites
6. Have regular chats with them making them understand the dangers of being online without sufficient knowledge to protect oneself
7. Educate them on what the dangers are and how to spot them
8. Disable installation of all programs, and disable the USB ports
9. Give them a user id that has severely restricted access
10. Do not give them the password that'd enable them to go online
11. Do not let them go over an hour online per day - it's too much of a waste of time
12. And finally, watch out for any warning signs that may indicate unhealthy exposure of any sort
Be safe!
An inspiring read - however, the parents simply talk about online security. Here are the concerns:
1. Kids will be exposed to images/video/text that are totally inappropriate or even dangerous
2. Kids will download spyware and assorted malware/adware because they surf in ignorance
3. Kids are in danger from predators
4. Kids will communicate with anyone that seems friendly or offers comfort or shows interest or praises them (most kids nowadays are starved of love and attention because both parents typically work) - and provide easily identifiable information
How do you watch them?
Some tips:
1. Do not give them their own personal computer till they are at least 17
2. Do not let them take the computer to their room
3. Force them to interact with websites in 'public' - meaning the living room
4. Inform them that you have Internet monitoring software and that you know what they are doing anytime they're online
5. Monitor the sites they visit, noting down what they post and who they interact with on social networking sites
6. Have regular chats with them making them understand the dangers of being online without sufficient knowledge to protect oneself
7. Educate them on what the dangers are and how to spot them
8. Disable installation of all programs, and disable the USB ports
9. Give them a user id that has severely restricted access
10. Do not give them the password that'd enable them to go online
11. Do not let them go over an hour online per day - it's too much of a waste of time
12. And finally, watch out for any warning signs that may indicate unhealthy exposure of any sort
Be safe!
Even More Privacy Issues
http://www.buffalonews.com/185/story/54888.html?imw=Y
When you donate your old, pathetic, and mostly useless computer, keep one thing in mind: the disk. Forget everything else - just go after the data. Whitewash as much as possible. Many good software can accomplish the task painlessly, and they're worth the investment.
You simply do NOT want someone to have access to private data (SS numbers, medical records, employment details, financial data) etc. If they're a nice person as the one in the story above, you won't lose anything. However, if an ID thief buys up your computer from the local donation center, who knows what he can turn up? And imagine what he could do with it - a virtual goldmine of data begging to be (mis)used.
The main problem is (as it is everywhere else) lack of data awareness, and fear (even disdain) of technology itself. Luddites that may pride themselves on their 'simple' life have NO idea how vulnerable they are, every time they encounter technology that gets and/or dispenses private data.
You are SAFE if and only if:
1. You do not have an SS number
2. You do not exist
3. You are a wandering saint
4. You have NOTHING to lose - not even your identity
So, before you chuck that computer of yours for a tax write-off, download a good disk-cleaning software, and scrub as much as possible. Remember - deleting files or moving them to the Recycle Bin or emptying the RB has no effect. The data is simply marked to be overwritten but the data itself is still there - invisible, but there, and can be very easily read by someone sophisticated enough to know how to run the right tool.
Whitewashing a disk usually consists of writing garbage over and over again to the disk (or writing 0s) until there is nothing left to read.
Next time you donate a computer, whitewash the heck out of it. And when you buy a used computer, clean it the same way and then install a fresh OS on it. You don't want to see/read/hear someone else's secrets just as you don't want yours to be exposed.
Be safe!
When you donate your old, pathetic, and mostly useless computer, keep one thing in mind: the disk. Forget everything else - just go after the data. Whitewash as much as possible. Many good software can accomplish the task painlessly, and they're worth the investment.
You simply do NOT want someone to have access to private data (SS numbers, medical records, employment details, financial data) etc. If they're a nice person as the one in the story above, you won't lose anything. However, if an ID thief buys up your computer from the local donation center, who knows what he can turn up? And imagine what he could do with it - a virtual goldmine of data begging to be (mis)used.
The main problem is (as it is everywhere else) lack of data awareness, and fear (even disdain) of technology itself. Luddites that may pride themselves on their 'simple' life have NO idea how vulnerable they are, every time they encounter technology that gets and/or dispenses private data.
You are SAFE if and only if:
1. You do not have an SS number
2. You do not exist
3. You are a wandering saint
4. You have NOTHING to lose - not even your identity
So, before you chuck that computer of yours for a tax write-off, download a good disk-cleaning software, and scrub as much as possible. Remember - deleting files or moving them to the Recycle Bin or emptying the RB has no effect. The data is simply marked to be overwritten but the data itself is still there - invisible, but there, and can be very easily read by someone sophisticated enough to know how to run the right tool.
Whitewashing a disk usually consists of writing garbage over and over again to the disk (or writing 0s) until there is nothing left to read.
Next time you donate a computer, whitewash the heck out of it. And when you buy a used computer, clean it the same way and then install a fresh OS on it. You don't want to see/read/hear someone else's secrets just as you don't want yours to be exposed.
Be safe!
Subscribe to:
Posts (Atom)
