4.7. Security

Sam asked me to stop by for a cup of coffee. He sat with a perplexed look on his face. I inquired about the idea that he was mulling over.

He said, "I watched a TV show last night about a guy who broke into a computer system and stole information worth millions of dollars. What happens if someone breaks into my system?"

"Well, how much is the information in your system worth?" I asked.

"OK, not millions, but maybe in the tens of thousands," he replied.

"We should perform a risk analysis, before we get too involved in the detailed design of the system," I responded.

Security encompasses a broad range of issues including access protection, attack prevention, data backup, and data security . You can find a detailed discussion of security issues in Security Engineering: A Guide to Building Dependable Distributed Systems by Ross J. Anderson and Ross Anderson (Wiley, 2001). You should consider security from the start of the design. You should perform a risk analysis to determine the risks, the probability of their occurrence, and the cost if the risks materialize. Once you've identified the risks, you can employ appropriate measures, including structuring the design to meet those risks.

Many books explain how to write secure code. Two are Building Secure Software: How to Avoid Security Problems the Right Way by John Viega and Gary McGraw (Addison-Wesley Professional, 2001) and Secure Coding: Principles and Practices by Mark G. Graff and Kenneth R. Van Wyk (O'Reilly, 2003). Determine how much effort you should spend on making code secure based on the vulnerabilities you find in the risk analysis.

Here is a portion of the risk analysis conversation I had with Sam. We were discussing the risks involved for the first two use cases.

"What's the worst thing you can think of that might happen?" I asked Sam.

"I could lose track of which customer rented which CD," he answered .

"That sounds pretty serious, but how serious is it?" I asked. "You would have to worry about dishonest customers who didn't return their CDs if they learned that this had happened . I don't think that would be a very high percentage.

"You're going to be doing daily backups , right?" I continued .

"Yes," Sam replied.

"So we should worry about the rentals and returns for a single day," I stated. "To spend a lot of money at this time worrying about dishonest people is probably not worth the cost. If you do have a disk crash, you can always enter the data again from the paper copies of the rental agreements."

"What we might worry about instead," I suggested, "is whether a customer could check in a CDDisc by himself and then just remove it from the store. We need to prevent this from occurring via physical security on the check-in computer, or software protection such as user passwords, or both."

If we decide to implement passwords, the login and logout processes ought to be added as either additional use cases or alterations of existing ones. The use case changes will affect the design by assigning additional responsibility to classes or by creating new ones.

IF YOU FORGET SECURITY, YOU'RE NOT SECURE

Security should not be an afterthought. Consider it during all phases of development.