Seems the state of Texas unwittingly published – for a whole year – personal info about 3.5 million citizens:
When private corporations do this kind of thing, they pay big fines. What sort of penalty applies to governments?
Hmm. I know! Nothing! 
Just read this, about an ex-admin at Gucci who retained both VPN and admin access and caused some harm after being let go:
The sad thing is that – statistically – this sort of thing is all too predictable. The failures here are pretty simple, if numerous:
* The organization allowed this guy to create a user profile for a fake employee. Can you say broken controls? I know you can…
* The help desk subsequently authenticated this fake employee and enabled his VPN one time password device. What happened to the approvals process? Shouldn’t this bogus employee’s manager have had a say about VPN access?
* It sounds like admin accounts had shared, static passwords. Once on the VPN, this ex-employee was able to use his old passwords to cause damage. Why didn’t Gucci implement a privileged access management system to eliminate static and shared passwords?
Organizations can’t continue to assume that all employees will behave professionally and ethically all the time. While that’s going to be true 99.9% of the time, the 0.1% of the time when it’s not is a problem.
So to abuse a term from the cold war: “Trust, but verify!”
Obviously identity and access management systems, implementing sound processes, would have locked this user out of the network. Just as clearly, privileged access management systems would have blocked this user, even if he got back on the network, from gaining admin rights.
Last month, a major certificate authority was compromised, leading to the issue of a number of fraudulent SSL certificates for major sites such as Google.com and Skype.com. You can read more about it at CNet.com.
When we think about authentication, we are normally talking about verifying that a (human) user is, in fact, who he or she claims to be.
This incident raises questions about a whole other type of authentication — how does your web browser authenticate the secure (HTTPS) server it’s communicating with? Technically, this is done using a signed SSL certificate — a certificate authority (CA) signs the public key of the site you are visiting. Your browser comes with a list of about 300 “trusted” CAs and will silently accept SSL web site certificates if they are signed by any of them.
The trouble with this model is: should you really trust this arbitrary list of CAs? Some of them may not operate very securely, which means that a compromise of their systems could lead to bogus site certificates being issued, which your browser would then treat as valid sites. Another question is should you trust these organizations? Some of them are government agencies, in countries with dubious track records regarding human rights or due process. Would you trust the US government to vouch for the security of a web site? No? What about a government-owned telephone company in the United Arab Emirates? Odds are pretty good that your web browser already trusts the latter…
But if you don’t trust the CAs, then who do you trust? If you do trust them, when do you stop trusting them? How do you train your browser to stop trusting one of these sites? This is a sticky question, because anything that’s complicated will be rejected by end users.
One idea is for the browser to display the chain of trust to the end user whenever a “secure” site is visited. This means that a user would see a message like “You are about to visit yourbank.com/ – a secure site vouched for by Verisign of Mountainview, California, USA.” The idea here is that a user might be startled if one day he sees a message like this, instead: “You are about to visit gmail.com – a secure site vouched for by TURKTRUST Bilgi Iletisim ve Bilisim Guvenligi Hizmetleri A.S.” (Nothing against Turktrust here – this is just an example of a strange combination.)
Another idea is for your browser to frequently download a refreshed list of CAs, with ones that are known to have been compromised deleted. Some browsers already do this, but the process that leads a key to be removed is a big question mark. If a CA is used by a government to lawfully monitor its own citizens, should a company such as Microsoft (that makes IE) or a foundation such as Mozilla (that makes Firefox) revoke that government’s CA in their respective web browsers? What constitutes a serious enough incident to revoke a CA?
One more idea might be to setup a peer-to-peer relationship between CAs. To be accepted by a browser, perhaps the CA’s own key should be signed by a few other CAs, and vice versa. This way, a “rotten apple” CA would be quickly removed by their peers. Once again, the devil is in the details – CAs would be incented to create a tightly knit oligarchy and block new competitors from entering the market. That’s not the intent at all!
Regardless of how the question is addressed, something really needs to be done to secure the server authentication process — too much hangs in the balance!
– Idan
