Over the past few weeks it has become apparent that there are many questions in today's society about what exactly an Information Assurance group is supposed to do. Are they there to be technical experts in every single platform and application that is brought into a company as to secure it in the best means possible? Are they there to maintain controls and non-repudiation logging to the utmost so as fall back on that when something bad happens.
The problem is as a business with what do you place your focus. Should you security staff be focused on security and only security or should there be more of a focus to protect from legal matters. Are the security staffers there to protect the data of the customers/clients or are they there to protect the company.
I can't imagine that in ChoicePoints case the customers were protected in any matter, and that being said neither was the company as they lost much more in soft costs and clients than they did in the courts.
I think the focus should be on protecting the data that keeps the company afloat and directly protecting the company from SOX, GLB, and such. If we cork to protect the data to the utmost extent, don't we inherently protect the company as well?
Wednesday, February 01, 2006
Monday, January 30, 2006
How much is your identity worth?
In CNN's article:
http://money.cnn.com/2006/01/26/news/companies/
choicepoint.reut/index.htm?cnn=yes
ChoicePoint is settling for $15 million after losing 163,000 customers data. $10 million of it will go to fines and the other $5 will go to those affected. This means that each person identity is only worth a measly $30.67.
Granted CP lost much more money in the process through stocks and other fines but in the end the big loser is the clients whose information was lost. What about those 500 so cases of known identity theft from this loss? I am going to wager that they lost more than $30.
I think companies secure their systems and networks to prevent those fines from the government, but really the fines should go to pay those whose data was lost. If I was one of those 163,000 people I would have turned around and got new credit cards, new Social Security number and heck who knows even a new name. There is something wrong with this picture.
What do you think?
http://money.cnn.com/2006/01/26/news/companies/
choicepoint.reut/index.htm?cnn=yes
ChoicePoint is settling for $15 million after losing 163,000 customers data. $10 million of it will go to fines and the other $5 will go to those affected. This means that each person identity is only worth a measly $30.67.
Granted CP lost much more money in the process through stocks and other fines but in the end the big loser is the clients whose information was lost. What about those 500 so cases of known identity theft from this loss? I am going to wager that they lost more than $30.
I think companies secure their systems and networks to prevent those fines from the government, but really the fines should go to pay those whose data was lost. If I was one of those 163,000 people I would have turned around and got new credit cards, new Social Security number and heck who knows even a new name. There is something wrong with this picture.
What do you think?
Secure Single Sign On
How to perform Single Sign On from website to website in a secure manner?
There have been many requests recently for reviews of different methods of Single Sign on approaches from website 1 to website 2. The approaches have all been different and don't usually end up in the original form of the request but I wanted some thoughts on other options to solve the SSO problem. (website 1 and website 2 are completely separate companies and have no ties financially)
1. Have a hidden form in website 1 that can be posted to website 2. The hidden form includes an encrypted string (using DES cipher) that is a userid and timestamp (which is good for 5 minutes).
I don't like a lot of things about this method. First and foremost, use a cipher that cannot be broken in a couple hours. I recommended atleast RC4 but I would prefer AES. Hidden fields are the security by obscurity of the middle ages. A hidden field is not hidden and can be modified very easily by the end user. Then the end user could perform brute force attack against the encrypted string and never be locked out on the other end.
I think a better approach is to use a server side redirect over a dedicated VPN. Both sides could verify it is coming and going to the correct systems. The end user never has a chance to modify the encrypted string and an external attacker could not perform a brute force attack against website 2 without first authenticating to website 1.
I would like thoughts on this and other methods that people have used.
There have been many requests recently for reviews of different methods of Single Sign on approaches from website 1 to website 2. The approaches have all been different and don't usually end up in the original form of the request but I wanted some thoughts on other options to solve the SSO problem. (website 1 and website 2 are completely separate companies and have no ties financially)
1. Have a hidden form in website 1 that can be posted to website 2. The hidden form includes an encrypted string (using DES cipher) that is a userid and timestamp (which is good for 5 minutes).
I don't like a lot of things about this method. First and foremost, use a cipher that cannot be broken in a couple hours. I recommended atleast RC4 but I would prefer AES. Hidden fields are the security by obscurity of the middle ages. A hidden field is not hidden and can be modified very easily by the end user. Then the end user could perform brute force attack against the encrypted string and never be locked out on the other end.
I think a better approach is to use a server side redirect over a dedicated VPN. Both sides could verify it is coming and going to the correct systems. The end user never has a chance to modify the encrypted string and an external attacker could not perform a brute force attack against website 2 without first authenticating to website 1.
I would like thoughts on this and other methods that people have used.
Subscribe to:
Posts (Atom)
