Last week I went to training on information security. I had thought at the get go that it was about “secure coding”, but to my surprise it was more about designing secure systems. I really am not interested all that much in information security, but certain projects at my job have required me to learn more about this topic than I ever wanted to.
We talked about cryptography, authentication, authorization, threat modelling, and a slew of other topics.
The overview of cryptography helped as I now understand what things like initialization vectors, block cipher modes, and using a salt on a hash. The most important thing I took away from this is that there are considerations outside of what algorithm you use when it comes to effectively using cryptography. If, for example, you use AES-256, but use ECB block cipher mode (http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation) you may introduce patterns that would allow you to guess the encrypted value. Furthermore, hashing without a SALT value is less secure because of the possibility of using rainbow tables to lookup the password.
As far as authentication goes, I can’t remember much without looking at the slides provided, but one cool thing we went over was Kerberos http://www.duke.edu/~rob/kerberos/kerbdetails.html and a common notation used for encryption (as seen in the link).
We talked about different attacks that a system can be hit with, SQL injection, XSS, CSRF, response splitting, XPATH injection, DoS attacks, vertical and horizontal privilege escalation, and so on as well as techniques to prevent them. The trick in most of these is to encode/decode and validate data at every point entering a “trust boundary”. A “trust boundary” where nodes within the boundary trust data going between them, but all data coming in and out of the trust boundary must be checked on all nodes.
Off the top of my head I couldn’t recall any other major details from the class. If I had the time I would review the slides and share some of these things. One of the best parts of the class was being allowed to hack some of their example websites. This gave good insight into how an attacker thinks and the methods they use to “get in”. It was so tempting after that to go out and try to hack some amateur websites, but as an ethical software engineer (in the making) I have no option but to refrain from doing so. However, I may install some old websites of mine on a local web server and attempt to hack them (which probably wouldn’t be too hard given when I wrote these I had no knowledge of web vulnerabilities).
Anyways, there is my little summary of my information security training. I am sure in the future I will have more to say on the topic, but I now have 28 days and counting to finish up my first 2 assignments and my first exam in my SE course (plus I have to get started on my application into the actual program). I will probably do some additional work on state diagrams this week, and so I’ll share what I come up with on that.