Just as we get our hands around one threat to the security of corporate infrastructure, e.g. phishing, it mutates into something new, e.g. spear phishing. Each new mode of attack brings its own challenges, but after 20 years of on-line computer securities problems, have we learned anything at all? Is the situation so complicated and fluid that we are doomed to eventual failure? Probably not, and the fact that, after this much time, we have an expanding interconnected ecosystem suggests that we are actually doing pretty well overall.

After all this time, some basic operating principles have emerged.

Know the Threat

The very first question when designing a security system is what is the risk to my asset? If the answer is, “I don’t know,” it’s likely your security system isn’t doing you much good. One skill that security professionals have excelled at, especially in the last five years, is security risk and threat assessment. A periodic threat assessment can help you keep up your perimeter defenses.

It’s also an essential to map the security to the risk. In the same way that you don’t want a $500 picture tube to blow out to spare a 10 cent fuse, you don’t want to over-commit finite security resources in places that aren’t likely to be attacked, drawing them away from places where you are more vulnerable.

Keep Context in Mind

Periodic threat assessments also help you to become aware when the security context of an application changes. For example, one large US bank had account management software that worked securely for years in the middle office. Used by both tellers and brokers, the system had never been hacked, never been compromised and was considered one of the safest systems in the bank. As the market moved forward, the bank decided to go to an online customer self-service model, allowing clients to view and manage their accounts from home, increasing the satisfaction of the customer experience and saving some money. All well and good. Within a few months however, the “most secure system in the bank” had been compromised, exposing accounts and personal information to the Internet.

What happened? The system hadn’t changed; it was still as secure as ever, when used by tellers and brokers! The security environment was now wholly different when the application was moved to the Internet. A surprising number of vulnerabilities are found only when the application environment changes.

Keep it simple

No major financial institution would rely on “Security through Obscurity” in 2005. Unprotected computers on the Internet have a half-life of approximately six minutes before they are found and compromised. Avoid any security procedures which rely on the end user to adopt new, unfamiliar security procedures. If it’s remotely possible to forget something, most people will, and if your security relies on their not forgetting, your help desk will resemble an airport in a snow storm. Remember, almost anything the user sees in a browser can be faked by a dedicated phisher, so giving users instructions like “Only type in your account number if the box turns green” is functionally equivalent to “Sign a blank check and leave it on the floor of a nearby crackhouse.”

Keep it simple, keep it secure. Assume your end users don’t read a lot of instructions. Assume they are going to lose their passwords. Assume that they are on a 56K dial-up connection in Caribou, Maine.

Monitor and Adapt

The greatest, most widespread and serious threat to financial services security today is the unread security log. Worse than having no security at all, it packs the double whammy of giving you the illusion of security while simultaneously documenting your neglect. More people are fired over unread logs than any other single type of failure.

And rightly so.

Besides, they are such interesting reading. Generally, everything you need to secure your enterprise is right there in the logs. My company, Microsoft, is one of the most hacked sites on the globe and we gain enormous intelligence about the state of our site and of the Internet, simply by reading the security logs.

Take that knowledge and feed it back into your defense planning. If you aren’t monitoring your institution’s firewalls and internal logs, put this article down right now and go do that. We’ll wait.

Assume Failure and Prepare for it

Assume your ideas are going to eventually fail. One of the oldest axioms in cryptography is “everyone can design a cryptographic system they themselves cannot break. This does not make it unbreakable.” This is especially true in security. FSIs should not rely on their systems being completely impenetrable, forever. How your security adapts to failure is at least as important as how it adapts to threats. Is your network segmented or is it one big, flat open system? How will your systems fail-over in case one segment is compromised? What is your action plan should an administrator walk out with the customer database? What cryptographic algorithms are you using and what should happen if one were compromised?

Keep refining your contingency plans as new questions arise. What would you really do if tomorrow morning the Wall Street Journal reported that the Riemann Hypothesis had been solved and public key cryptography had been broken? If you know the answer, you’re in pretty good shape.

Dr. Mark Horvath is Microsoft’s global technical strategist for capital markets.