Quite interesting, the recent concerns over how Google mines data and how it might use it when combined with its recent acquisition, DoubleClick. Plus, now you have street-level, 360-degree, detailed snapshot views of actual happenings on streets that Google has covered.
Somewhat creepy, a little scary, but mostly harmless. For now.
How Google addresses privacy concerns raised by both small privacy groups and organizations like ACLU, EPIC etc is to be seen, but it's quite likely that G, whose main edict is 'Don't be evil' may be forced more and more to live up to its grand statements. Only, you don't want it going the way of 'We don't do finance'...
What is the Security concern here? Plenty, plenty, plenty. Imagine this fantastic goldmine of data that tells you all you want to know about someone's secrets and the makeup of their psyche - right from search terms to visited sites to how long they surfed those sites to your most private communication (email). Imagine this fantastic data in the hands of a hacker. There. You know what I'm saying.
So, G, which employs the most brilliant minds it can afford to buy on the strength of its balance sheet as well as brand name, needs to REALLY tighten up its environment. You do NOT want embarrassments like when someone stole G's own blog and it had to do some red-faced explaining. We don't have to teach G about security and how to protect its data, but we do have a RIGHT to expect that what G knows, only G knows and nobody else. Plus, you also hope (wish, pray, beseech, request, beg, fight) that G also has a bad memory (think data retention policies).
Anyway, the coming few months are going to be very intense as the search, advertising, and portal markets heat up with existing giants waking up and new, disruptive technologies start chipping away at the heels of the Big Ones.
Be safe!
Showing posts with label internet safety. Show all posts
Showing posts with label internet safety. Show all posts
Tuesday, June 12, 2007
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!
Subscribe to:
Posts (Atom)
