Kenneth Van Wyk: Your 2012 security action plan

This is my end-of-the-year column, but I'm not much for predicting (my stock portfolio can attest to that). Instead, I thought I'd give you some ideas on what to put onto your action lists for 2012.

Rather than a comprehensive list of everything an IT security organization should plan on doing in the new year, these are some of the things that many probably haven't even considered.

Know your developers.

All too often, I find that the IT security folks and the software developers in an organization don't even know who each other are. Change that. Whether your organization's developers are in-house or outsourced, get to know them. Seek them out and engage them in conversation. What should you discuss, you ask? Start with something you have in common: application logs.

After all, when security incidents occur, you'll need to use those logs to try to figure out what's going on, from a business perspective. Try talking to the developers about what sorts of things should be logged. Explain that when it comes to functionality, the business owner is their customer, but when it comes to security logging, the IT security team is the end consumer of the information. Work out scenarios of common application attacks and what sorts of business-relevant information you'll need to do your investigative work. Chances are the developers never adequately considered that use case.

Know your technologies.

Do you find yourself treating your application platforms as "black boxes," without truly knowing their inner workings? Change that. Whether you're deploying mobile apps, Web apps or whatever, dive into the technology platforms and learn them inside out. Install them. Configure them. Load (and even write) apps on them. Examine the security logs. Examine the security settings that are possible. Virtual machines can work great for this sort of thing. Seek tutorials on the technologies and take and pass them.

No, you don't have to be expert at everything all the time, but time spent learning the platforms you're supporting is time well spent. When things go bump in the night, that knowledge may well end up making all the difference in how you're able to respond to the incident.

Build coding guidelines.

Software developers tend to be exceptionally good at building things that comply with their functional specifications. But when it comes to security topics, they often make seemingly trivial mistakes. One of the most valuable things that can be done is to build a library of common security mechanisms for them to use in their code.

There are many building blocks that need to be repeated on different applications, such as authenticators, database connectors, input validators, output encoders and so on.

Work with your software developers to ensure that they all have that cookbook of common security mechanisms. The IT security team probably won't build that cookbook, but they can drive the effort and ensure that all the necessary common building blocks are there.

And make sure the library is well annotated and easy to understand. It's not enough to prescribe, for example, "Use Prepared Statement or some other immutable API for SQL connections." While that's useful, you should also be using that opportunity to explain why it's important to use an immutable SQL API - to prevent SQL injection attacks.

Think outside the black-box testing.

Penetration testing is positively the worst possible way of testing the security of an application. It's still essential, but there's a whole world of other forms of security testing that should be done to ensure that an application is truly ready to put your business on it.

I'm a big fan of dynamic validation testing, for example. Start with a checklist of security assumptions, such as "Session credentials must be encrypted at all times when in transit over a network." From there, set up some instrumentation around the application in a test bed, and dynamically observe that no session credentials are ever hemorrhaged from the application. That'll help ensure that it can stand up to being run on an open network, such as an unsecured Wi-Fi.

The point here is to expand your security testing beyond just doing penetration tests. Go out and read up on other security testing methodologies, and give some of them a try.

Give threat modeling a try.

Reviewing the design of your applications before they're built is one of the most effective things you can do to ensure that they're built to withstand the sorts of threats you can reasonably anticipate. Yet design reviews aren't anywhere near as common as they ought to be. Work with your software developers to do some critical reviews of software designs as early as possible. Threat modeling can be an effective way of doing that, and can be done without an enormous amount of time and effort. A collaborative approach between IT security and software development tends to work well here.

These are just a few things to consider, but it's been my experience that these things aren't often done very well -- or at all in many cases.

Rather than waiting to see what 2012 holds for us, why not take an active role in shaping that outcome a bit? Carpe annum!

With more than 20 years in the information security field, Kenneth van Wyk has worked at Carnegie Mellon University's CERT/CC, the U.S. Department of Defense, Para-Protect and others. He has published two books on information security and is working on a third. He is the president and principal consultant at KRvW Associates LLC in Alexandria, Va.