<Previous                     Next>   

Q3: Can you profile the key lessons from your book from each of the topics below?

• Understand the classic Orange Book approach to security, and its limitations
• Use operating system security tools and structures - with examples from Windows, Linux, BSD, and Solaris
• Learn how networking, the Web, and wireless technologies affect security
• Identify software security defects, from buffer overflows to development process flaws
• Understand cryptographic primitives and their use in secure systems
• Use best practice techniques for authenticating people and computer systems in diverse settings
• Use validation, standards, and testing to enhance confidence in a system's security
• Discover the security, privacy, and trust issues arising from desktop productivity tools
• Understand digital rights management, watermarking, information hiding, and policy expression
• Learn principles of human-computer interaction (HCI) design for improved security
• Understand the potential of emerging work in hardware-based security and trusted computing

A: That's quite a list! 

• The Orange Book: smart people spent a long time thinking about how to construct operating systems that meet some specific security goals, with high assurance. There's a lot a modern architect can learn from this material, even if goals and technology have changed. Of course, there's a negative lesson too: as a public policy tool, it failed to produce the desired response in the marketplace.
• Computer systems have become too complex to think clearly about. As a consequence, it's easy to get them wrong - and what's worse, it's hard to even specify exactly what the "right" behavior was supposed to be. These problems lead to many security holes in software. It's like thinking up puns or putting things together the wrong way: the adversary provides input that complies with the basic rules of sense, so it is accepted by the system, but also has completely subversive and unexpected semantics, so it tricks the system into entering a dangerous state, unexpected by the designers.
• Cryptography makes it possible to do all sorts of magic, such as hiding information from an adversary who doesn't know a secret, or convincing a remote party you know a secret without revealing what the secret is. Consequently, it's central to security in modern, networked computing environments - so one needs to understand both its foundations and its practical aspects, if one is to understand security.
• For many of us, computers permeate every part of our daily lives. (Case in point: you sent these questions as a Word document, with macros!) As a result, security issues can affect our daily lives. For non-specialists, discussion of these topics can seem too abstract to be relevant - which is why it's fun (and enlightening) to discuss them instead with explicit examples and war stories from everyday office tools.
• Computation doesn't make much sense without humans; even an embedded system out in a remote power substation requires a human to configure it, design it, and remember it exists! Thinking about how humans interact with computers, and how this interaction can complicate or simplify the security problem, is a promising area.
• Since computation happens on computers, it only stands to reason that changes to the computer hardware affect properties of the computation - including how hard or how easy it is to secure. Researchers have speculated about this for a long time; however, in recent years, we're seeing vendors roll out a lot of new ideas here.
• OS tools - The line that separates the OS from applications is constantly blurring (just ask the US Dept. of Justice or Microsoft). The more that distinction goes away, the easier it is for security problems in applications to cause real security trouble for modern OS.
• Networking, Web, wireless - Funny things happen when you let computers talk to each other. For years, the network has been the battlefield on which the security war has been waged: remote exploits, firewalls, intrusion detection systems, etc. As some new networking technologies become more prevalent, we expect to see new types of attacks and defenses.
• Auth - Authentication typically serves as the foundation for a security system. Complicating matters is the fact that trying to build a good authentication system is hard. We hope that by examining what's out there, those trying to build such systems will learn what has worked and what hasn't and apply that to their own designs. (A pet peeve of mine is that too often, authentication techniques seems to be designed to meet the requirements of the technology, not the human system it's supposed to serve. But that's a topic for research.)
• Validation - Let's say you've built some sort of secure system and you're ready to market it, give it away, or whatever. How do you know it's really "secure"? Testing and the validation process is a good way to systematically check for security trouble and communicate the results to others.
• DRM - The more that computers are used to translate data into something we like to read, watch, listen to, or use, it seems the more that the creators of that data would like to control how and when the data is used. The field of Digital Rights Management, etc. theoretically gives content producers a way to protect their data from "inappropriate use" by content consumers. Some of these schemes technically work, but don't socially work, and vice versa.

Q4: What are five little known but essential tips that can be found in your book?

A: A few that come to mind:

• Formal methods tools, such as model checkers, can go a long way to slaying the dragon of software complexity, and the security bugs that come from this complexity. And we're on the cusp of seeing them ready for prime-time.
• In practice, public-key cryptography almost never relies solely on the public-key algorithms - and the security trouble usually lies in this other stuff.
• Side-channel attacks are a wonderland.
• [John]: Modern software is usually built by smart people trying to do the right thing. So, why does it often go so horribly wrong? At least part of the answer lies in the toolkit and processes that the industry uses to get software to the market.
• [John]: Much security trouble stems from the fact that systems are often difficult to use and encourage users to make honest mistakes that put the system in a bad state.

<Previous                     Next>