The kick-off meeting for the Eugene OWASP Chapter is tomorrow night (Thursday, Feb. 28). My plan is to give everyone a chance to meet each other, talk about the importance of web application security, and introduce OWASP and the free resources that OWASP provides for securing web applications.

I'm excited about it and am looking forward to building a community of folks in the area with web app security expertise. I'm also working with the Lane County Chapter of the Software Association of Oregon and I'm hoping that a development community in Eugene/Springfield with a solid foundation on application security could be turned into a distinguishing characteristic of the area: you want a secure application built in Oregon, go to Eugene/Springfield. We'll see.

In any case, working with others on these sorts of security initiatives is the kind of stuff I love to do, and it is very satisfying. The doors open at 6:00pm and the presentation begins promptly at 6:30. I'll be (or rather, K2 Digital Defense will be) providing pizza and soft drinks.

If you're reading about this for the first time here, and would like to attend, please RSVP by registering for the event at:

Thanks go to the Eugene Water & Electric Board for providing the space for this meeting. EWEB furnishes public meeting rooms as a community service and does not sponsor or endorse activities or groups using EWEB's facilities.

One of the things he stresses is that you must identify the threat the encryption is to protect against. I agree wholeheartedly. In the first chapter of Cryptography in the Database I talk about threat models:

A threat model is one of the most important tools to have when considering a database cryptosystem. The threat model shapes the design of the cryptosystem to ensure that it protects against the threats the organization ranks highly. Without a carefully crafted threat model, a cryptosystem can easily be built or purchased that protects only against a single class of low-priority threats.

Too many organizations are told that they need to encrypt some data, and off they go to encrypt without first deeply understanding the threats they are mitigating. The actual security value of such off-the-cuff encryption solutions is questionable. Always figure out what you want the system to protect against before going too far down the solution path.

Generally, people want encryption to make the data unreadable by folks who don't have a need to read the data. Seems fairly straightforward, but who are these folks? Your threat model should identify the threat agents you are worried about. Here's a list to get you started: system and database administrators, development staff, network intruders, application crackers, legitimate users, offsite backup-storage staff, and thieves.

Your encryption solution can be optimized to protect against different subsets of these threat agents. Protecting against all of them with a high-degree of security is exceedingly difficult and expensive. As you design your encryption strategy, select which of the threats it will address, and then cover the remaining threats with other mechanisms.

Your threat model will primarily influence two components of your cryptosystem: where to store the keys and where to place the encryption engine. The reason for this is straightforward. Encrypting information simply means that now you don't need to worry too much about protecting lots of little pieces of information (say credit card numbers), but instead you need to worry about protecting the encryption key (which, in turn, protects all the little pieces of information). Since the encryption engine is the only component that needs access to the key, you need to protect it and the place where the keys are stored against the relevant threats.

Another topic he mentions is the problem of tying your encryption solution to your access control system. A few vendors have referred to this as "transparent encryption." I talk about it in Chapter 2 (which is available for download--see section 2.7) of my book. As I say there: "The name itself should raise a few questions: what kind of security does transparent encryption provide."

In a transparent encryption solution, the system only decrypts data for authorized users. Depending on where the key is stored, this could be a viable solution if your threat model only consists of people stealing the database server or file (or a backup of the database). But against just about any other type of threat, transparent encryption is pretty much worthless.

Again, your threat model will help you determine the appropriateness of transparent encryption for your environment. I can't stress enough the importance of building a solid threat model to help you make informed security decisions. I'll talk more about threat models in a later post, but you don't need to build extensive attack trees and catalogs of vulnerability minutia. A simple list of the bad things you want to avoid, who might do them, and how they might be done will generally suffice.

Why isn't disaster recovery and business continuity included in the dozen security processes?

Disaster recovery and business continuity (DR/BC) is generally included in the theoretical information security agenda. It is a core domain in the CISSP body of knowledge. For many organizations, though, DR/BC is actually handled outside of the information security department. Typically, the information security team is focused on controlling risk due to malicious adversaries: worms, hackers, etc., and the skill set of a typical information security team reflects this focus.

IT business continuity teams have a different set of skills. They are first and foremost focused on getting the necessary IT infrastructure up and running as quickly as possible after a disaster. Information security has a role to play here, without a doubt, but it is often not a role in the driver's seat. Because of this, I don't include it in the twelve security processes.

Plus, have thirteen security processes seems to be just asking for trouble.

When building your organization's security program, it is helpful to have a starting framework, something that gives you a solid initial structure yet is malleable enough to fit the particulars of your situation. I've found that thinking about security as a collection of processes provides just such a framework.

To keep us all on the same page, I'll offer up my definition of a process. This isn't the most exciting stuff, but, oh well. A process is a set of measurable, controlled activities aimed at achieving a specific goal. Measured means that the activity produces metrics that can be used to help determine if the process goal is being met. Controlled means that the activity's steps are clearly defined, roles and responsibilities have been assigned, and that outputs are reviewed as necessary.

Context: Bruce Schneier recently made a stir when he mentioned that his home wireless access point is open to anyone to use.

No. Secure your home wireless access point using WPA or whatever happens to be current, effective, and available at the time you read this.

Schneier keeps his home network open for one reason: politeness. He feels that providing "internet access to guests is kind of like providing heat and electricity, or a hot cup of tea." I have no argument with this, but it doesn't mean your home network needs to be open. You can provide an open guest network and still keep your home network secured. The rest of this post goes into more detail.

Dedication

My grandfather had a wonderful shop in his basement. To me, it was a place of mystery and fascination, and I would spend hours wandering through it, looking at all the tools and projects in various states of completion. Not being much of a wood worker, I've never had the need for such a shop (not to mention that I lack a basement), but recently it occurs to me that my gear, computers, and software are my shop. This site is for my late grandfather and everyone else who takes personal pride in carefully executed work.