Editor's Note
Can I See Some Identification?
Howard Dierking
Recently my wife and I went to see a movie, and I had to purchase our tickets from a ticket agent who, as a result of an intercom system designed to transmit through half-inch-thick glass, sounded like a synthesized voice run through a distorted amp. And imagine my surprise when I was asked for my ID because the movie was rated R.
For anyone unfamiliar with the movie rating scale in the U.S., an R means individuals younger than 17 are not allowed to attend unless accompanied by an adult. Now, I realize that I probably look a bit younger than I am. But under 17? I showed my ID and purchased my movie tickets, but the incident caused me to think about some broader issues related to security requirements and context.
One realization has to do with the thick sheet of glass separating me from the agent. I suspect that the actual reason for it is based in history, when most moviegoers used to purchase tickets using cash. And while the rise of credit cards may make it less common today, those folks behind the window still have to manage a lot of cash. Based on where most ticket counters are located relative to the rest of the theater, without that window (and the distorted intercom), the ticket agent would be extremely vulnerable to anyone with a broken moral compass and a desire for the cash.
Another case where different contexts yield different security requirements is in age validation. If I'm buying tickets at the counter, I'm a captive audience—the agent can check my ID and verify my age with minimal effort or impact to the process of selling a ticket.
But if I'm buying tickets online, while the business process remains consistent, the change in context shifts the security focus from protecting the assets of the movie theater (cash) to protecting the assets of the purchaser (credit card number). In a context where the ticket purchaser is essentially anonymous, deeper validation steps like ascertaining the purchaser's age may seem superficial.
As I've said many times, the number of technologies that must be integrated into our apps and enterprises is enormous, and it keeps growing. Additionally, each change in technology causes a change in the security context, potentially altering the security requirements. I have seen many projects start out with the simple goal of moving an existing app to the Web, only to later require a great deal of additional effort (or stall out completely) because the impact of the context change was not planned for up front.
From the technology perspective, there's no simple solution here. Security measures must be designed and implemented based on a proven understanding of the system, the users, and the context in which the system will be run. Given that, I firmly believe building secure systems has more to do with people and processes.
We focus a lot of attention on the security development lifecycle (SDL). This is meant to underscore the idea that security is contextual and must be a standing discipline along with other major phases of a development lifecycle. As you will see in this issue, the SDL has also undergone some changes to remain achievable even in high-change environments where agile development methodologies are most effective. In fact, I guess you could say that the SDL is changing in response to a change in context.
Visit us at msdn.microsoft.com/magazine. Questions, comments, or suggestions for MSDN Magazine? Send them to the editor: mmeditor@microsoft.com.
Thanks to the following Microsoft technical experts for their help with this issue: Paul Andrew, Jonathan Aneja, Bob Brumfield, Jeff Cao, Kiran Dowluru, Ryan Duguid, Mike Flasko, Matt Gibbs, Kevin Gjerstad, Christian Kleinerman, Bertrand Le Roy, Varsha Mahadevan, Duane Need, Wayne Norton, Eugene Osovetsky, Dave Reed, Michael Rys, Gerhard Schneider, and Michael Wang.
It is with great sorrow that we note the passing of Paul DiLascia, a long-time contributor to MSJ and MSDN Magazine and a friend to many of the staff here at the magazine. He shall be missed.