One Thought on State Department Incidents
I have absolutely no special knowledge of this event. All I know I've learned from stories like this. The following caught my eye:
The department also temporarily disabled a technology known as secure sockets layer, used to transmit encrypted information over the Internet.
Hackers can exploit weaknesses in this technology to break into computers, and they can use the same technology to transmit stolen information covertly off a victim's network.
Many diplomats were unable to access their online bank accounts using government computers because most financial institutions require the security technology to be turned on. Cooper said the department has since fixed that problem.
So DoS (heh, pun intended) disabled outbound HTTPS? It sounds to me like the intruders used a HTTPS covert channel (not so covert, actually) to communicate with their victims. I think we are getting to the point where encrypted outbound HTTP will have to terminate on a proxy server that permits inspection or at least logging of the HTTP action. The proxy will then establish its own connection with the remote HTTPS server.
Yes, (1) this breaks end-to-end HTTPS; (2) users will probably have to accept an unexpected SSL certificate; (3) this will undermine any training they may have received to avoid connecting to the uber hacker at https://www.paypa1.com. However, to have any shot at identifying these connections in a timely manner, inspection of clear text at the network perimeter is a must. (What perimeter? It's the line between what you own/control and what you don't.) Not being able to do this probably hurt the DoS.
The department also temporarily disabled a technology known as secure sockets layer, used to transmit encrypted information over the Internet.
Hackers can exploit weaknesses in this technology to break into computers, and they can use the same technology to transmit stolen information covertly off a victim's network.
Many diplomats were unable to access their online bank accounts using government computers because most financial institutions require the security technology to be turned on. Cooper said the department has since fixed that problem.
So DoS (heh, pun intended) disabled outbound HTTPS? It sounds to me like the intruders used a HTTPS covert channel (not so covert, actually) to communicate with their victims. I think we are getting to the point where encrypted outbound HTTP will have to terminate on a proxy server that permits inspection or at least logging of the HTTP action. The proxy will then establish its own connection with the remote HTTPS server.
Yes, (1) this breaks end-to-end HTTPS; (2) users will probably have to accept an unexpected SSL certificate; (3) this will undermine any training they may have received to avoid connecting to the uber hacker at https://www.paypa1.com. However, to have any shot at identifying these connections in a timely manner, inspection of clear text at the network perimeter is a must. (What perimeter? It's the line between what you own/control and what you don't.) Not being able to do this probably hurt the DoS.
Comments
I think your intentional pun raises an issue which doesn't seem to be talked much about in the security community. It seems that the organization itself (and more specifically the IT department) is a security threat and should be treated as such. While we may not wish to question their motives, from the users perspective their actions are sometimes indistinguishable from a DoS attack.
So there's always going to be a trade-off between a secure system and a usable/useful system. Those in the trenches attempting to secure networks may not always see the optimal tradeoffs. It's a hard job.
That is a good comment. On a related note, I've seen some security shops that are very quick to shut down switch ports at the slightest suspicion of compromise. Usually the "up-at-all-costs" crowd dominates and potentially compromised systems are kept on line despite evidence to the contrary.
People were laughing at me, but here is the proof in the puddin. If only people would listen to the billster.
Just so everyone knows, I am ready and ready for some high payin consulting for the "DEPARTMENt!" to help them clean up their mess they went and got them selfs into. I fixed things up licky-splits at the bank, and I can do it here too!
My favorite fixer uper for this is to get everyones crdedit card numbers from them then use them for them and not trust end users to do it themselfs beucase they are not to be trusted and can only be trusted to do the wrong thing/ Then I have them so I can use them, and the more you get, the better you did it!
With regard to my previous post, the following howto looks pretty good: http://www.unixwiz.net/techtips/deploy-webcert-gp.html Disclaimer: I have not tried this, just an idea. :)
Josh