no --- was any invited ?
I'm guessing (actually, I really, really hope) that a few of my co-workers are attending.
Huge field right now, considering the wealth of information collected on nearly everyone, and the ****-poor security most is guarded with.
Looking forward to your AAR!
I am interested in Infosec, working on my CISSP and want to get into Information Security full time, right now I am the Director of Information Systems for a law firm so I have had to educate myself. Any tips for making the the change to going completely into security?
So, man in the middle?The big things weren't any technology, but architecting your network with security in mind (lots of segmentation for one thing), making sure you're following least privilege and least access principles and also that breaches are going to happen, but how quickly you can detect and stop is the main thing. One of the big technologies was SSL decryption. One blind spot is SSL encrypted traffic on your network that you don't know the content of. There are several products that decrypt it, allow you to analyze and then re-encrypt and send out to it's destination. Those are the biggest takeaways I had.
So, man in the middle?
I thought SSL was meant to stop man in the middle attacks* using a CA.
* One man's "allow you to analyze" is another man's attack.
That's my reaction too. But owners of businesses have the right to enforce their policies, which generally include the right to monitor what you are doing on their network and time. The good news is that is it fairly easy to figure out if they are doing this type of SSL breakage.
Least privilege? Isn't that a 40-year old concept now? Sad that it needs to be a major topic and not assumed and mentioned in passing.
That's my reaction too. But owners of businesses have the right to enforce their policies, which generally include the right to monitor what you are doing on their network and time. The good news is that is it fairly easy to figure out if they are doing this type of SSL breakage.
I believe the reaction was the same as mine, not whether a company was allowed to do it but I was under the impression SSL was not able to be decrypted by anyone but the receiver.
Decrypting is really, really hard.I believe the reaction was the same as mine, not whether a company was allowed to do it but I was under the impression SSL was not able to be decrypted by anyone but the receiver.
Decrypting is really, really hard.
My guess is they get you to connect to the man in the middle by pretending to be Amazon, then that middle man connects securely to Amazon and pretends to be you; so there's two SSL connections. But your computer should say, "The computer you're connecting to use using Amazon's certificate, but it's not an Amazon server. This is really sketchy and I don't want you to do this."
You <----- SSL -----> middle man <----- SSL -----> Amazon
This is why there's a Certificate Authority - someone that will vouch for Amazon's server. The mathematics of cryptography is pretty easy (relatively speaking), it's the issues with trust that are harder to deal with. I.e. how can you trust that this computer that you're about to establish an encrypted communication line is really who they say they are?
I read this as the company owned the cert., and was using it to decrypt the traffic on its own network, before allowing it to leave the network encrypted. For example, if you are worried about corporate espionage, you could view the contents of encrypted communication on your own network. Without something like this, you could give a contractor a cert, and they could send any info using it, and you would only see "2 TB of encrypted traffic", and have no idea if it is the source code to your latest product, or cat pictures. With this, you can validate they are indeed cat pics, re-encrypt, and let them go to their destination.One blind spot is SSL encrypted traffic on your network that you don't know the content of. There are several products that decrypt it, allow you to analyze and then re-encrypt and send out to it's destination.