All of the recent chatter about enhanced security guidance in the banking industry has made for a rather scary computing environment. It's a wonder that e-commerce and the financial network function as well as they do, considering the prevalence of spam, viruses, keystroke loggers and a whole phylum of vulnerabilities beginning with the letters "ph."
Because of this, I'm guessing that one of your New Year's resolutions -- in addition to dieting, exercising and restocking the canned food in your underground bunker -- is to learn how to defend yourself and your computer network against attack. But, since it's highly unlikely that your cohabitants divined what you really wanted to find under the holiday tree -- that is, a library of technical books about cryptography, security and privacy -- here are a couple of recommendations for the technically minded bank executive.
Privacy Protection and Computer Forensics, 2nd ed., by Michael A. Caloyannides (Artech House, 2004)
Yes, this book contains step-by-step instructions for securing the typical Windows workstation. But don't get put off by the technical title -- the most compelling reading in the book is its reasoned defense of security consciousness and discussions of the philosophical underpinnings of privacy protection. In a society without privacy, the potential for abuse of power is very real and very dangerous. One need not look hard to find governments that pursue dissidents with excessive zeal, thus elevating the humble art of data protection to being a valid defense against tyranny.
The book also offers several "recommended best practices" for privacy. For example, to protect yourself against digital eavesdroppers, make sure to disable your built-in microphone by connecting a plug into the microphone jack. Similarly, put black electrical tape over the lens of any built-in cameras when not in use. "Heroic measures" include purchasing your own cables so that you can be sure that they were not tampered with, and carrying your hard drive with you at all times.
Cryptography in the Database: The Last Line of Defense, by Kevin Kenan (Symantec Press, 2006)
Here's another book in which the technical content shouldn't scare away the business user. While the final one-third of the book contains code samples, the rest contains a fairly nontechnical description of the various parts of a cryptographic architecture, plus an approach for project management of an implementation.
Under the old rules, the banking industry considered security a given. "We're all regulated," the reasoning goes, "so we're all safe." But as security requirements intensify, banks may find strategic advantage by differentiating themselves based on the specific security measures they employ. Doing so will require an understanding of the underlying techniques, and insight into how those techniques may be adapted to particular segments of the marketplace. Which algorithms should be used? How can the industry manage a "key vault"? Which players form a security ecosystem? While Kenan's high-level overview should prompt further reading on the subject, it is reasonably complete for starters.
In the project management section, Kenan describes how security awareness should become part of the entire project life cycle. In the requirements phase, security awareness calls for enumeration of both "functional requirements," such as the use of a given protocol, as well as "defensive requirements," like protecting against a certain type of attack. Then, during design, the analyst has to seek out and eliminate potential weaknesses. With that perspective, the analyst should "keep security in the minds of the developers" during the development phase. But, when it's time for testing, the analyst leaves the scene, so as to let a separate team perform an objective test of the locks.
So what do these books teach us? It's important to remember that computer literacy was, at one time, a luxury in the business world. But now, executives write their own e-mails, put together their own budgets and spreadsheets, and build their own presentations. Likewise, we can't depend upon experts to protect us -- we need to become our own security experts. *