Computerworld — 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.

Continue Reading