As I mentioned in previous post, I began a series of security talks at my primary client site this past week. Since I have my mind on security, architecture, and unit testing lately, I was thinking about how each of these can be combined.
As we should know by now, security should be of utmost importance in developing robust software. It should permeate all thoughts as we write each method, each class, each web page, each stored procedure, and any other code we write day in/day out. Remember the old sayings: “Don't trust user input”, “Build security in depth”. They all apply here.
A few months ago, Martin Fowler remarked on how surprised he was that some people found it odd that security and architecture/design would be combined in a talk he gave with David LeBlanc (co-author of Writing Secure Code, 2nd Edition). Here are his comments:
One thing that interested me was that several people found the combination odd - implying that few people would be interesting in two such diverse topics. I think this is at the heart of problems about security in the industry. Security is seen as some separate topic area which sits in its silo. Yet security isn't something you can just add to an application by putting in a few encapsulated classes here and there. Security thinking should pervade a whole team - particularly on applications that are available on the internet or a large corporate intranet.
To be fair there's room for people to focus on security issues. There's a lot of stuff to know about on security. But everyone should have a reasonable knowledge about it. As David points out: many eyeballs don't lead to secure code - you need many educated eyeballs. One of the things I like about David's attitude is that educating developers is a key part of the picture, with less emphasis on review steps with security groups.
So, again, security and architecture/design DO go together. They have to be married together. There can be no afterthought for security.
Following these lines of thought, I am wondering about my use of unit testing. Most of my unit testing has to do with testing functionality, correctness, error handling, and other expectations of a method I write. What about security? It seems to me that I should also be writing unit tests to test the security implications of my method. Am I testing for input that could compromise my method, my database, or some other entity that exists after my method?
Typically, I think we rely on other layers to protect our middle-tier layers from the security threats, but if I follow the “security in depth” idea, I still need to take into consideration unit tests for the “possibility” of security holes in my all application layers. I need to think about how a hacker would compromise my middle-layer tiers after moving through the user interface tiers. I need to think about how a hacker would compromise my data tiers after moving through the middle-layer tiers.
What would those unit tests look like? I think the developer would write typical tests for buffer overruns, cross-site scripting, SQL injection, file name issues, and other security coding threats. What other tests could be created?
I am interested in the ideas of others on this topic.
