I definitely second this. Vulnerability maps give a todo list of what need to be secured, and tells you where to look for trouble. Mining the logs ensures that you don't overlook trouble when it actually happens.

Read about LANGSEC. The only real solution is software that has strong protocol specifications, and strong guarantees that it behaves as specified. In the real world however, organizations have little say in the quality of the software they use. So everything gets proxied in some fashion; whether it's at the network level (NIDS), or in the network stack (HIDS) or other system calls (virus detect). I work at a firewall company after being bought from an IDS company. These things help as much as possible, given the hideous state of the software we all use.

But that's the problem PKI (public key cryptography) is not being used for encryption or decryption at all. The keypair that the server owns is so that you can identify the server. The certificate is a digitally signed statement that the server is what it claims to be. Having the private key to its cert, it is the only thing that can respond correctly to a challenge to prove its identity.

The point is that he is actually correct. It's not "impossible" to undo encryption. It's inefficient. Not only that, for the trapdoor schemes we use, it's not even proven that it's inefficient. We hope that nobody figures out prime factorization any time soon.

This idea extends to hashes. A hash is a function for which the .inv operation is inefficient, and there is no secret key to help to make it efficient. Symmetric key encryption is where the .inv key is efficient. ie: Msg * SymmetricKey = CipherText. CipherText * SymmetricKey == Msg. Because X * X.inv == 1.

In Rubiks cube notation, the Reverse operation and Commutator operation are the same. To invert an operation, apply not only the inverse functions but apply them in reverse order. ie: (L * F * U).inv == (U.inv * F.inv * L.inv). The difference with asymmetric encryption is that the .inv operation is designed to be so inefficient that you can't do it without the help of a secret key.

Actually, you can! The problem is going forward and going backward are not something you can do at the same efficiency. We rely on working backwards being out of reach in terms of time to do it.

In addition to not showing it to the user, remember also to try/catch anything sensitive to make sure that a stack trace cannot escape out to the logging system.

Sure, in terms of (srcip,dstip:dstport) tuples, the firewall rules do read like an ACL. But it's a pretty ineffective one in the sense that srcip doesn't quite identify users, and dstip:dstport doesn't quite identify a resource. Particularly in the face of tunnels and NATs, you really need application layer support to lock down a resource to a particular user in a particular context.

If you updated on Friday, it took the ability to just add the immediate code after the function definition. If you updated again, it takes away the ability to do this as well (good!): x='() { echo foo; }' bash -c foo