In the first part of this series titled "Enterprise Web Application Security: Part 1 - The Foundation" I left you with 6 foundational things you should consider before galloping head-long into building a web application security program.  Going forward I'll take as a given that you've defined those 6 items, and you have good definition of all of those components.

 After you've defined the baseline for your security program the next most important thing to do is exercise your patience.  This second stop involves a lot of thinking, writing, and processing time.  You'll be building a policy and framework for the entire program going forward, so don't spare the details.

Building a policy is difficult, let's face it.  You have to have some sense of actual security inside, with a tint of business logic so that you have buy-in from your upper-management, and now you've got to think about how to keep the people who will actually have to read and use it engaged.  I'll address each of the 3 major groups you'll need to impress and give you some pointers on how to do that... so let's get going.

First off, let's discuss the format of your policy document.  Over time, what I've found that works well in organizations large and small is the "Cook Book" approach.  Folks in your organization want to know what they have to do to be in compliance with security - or they'll simply find a way to avoid security altogether.  That being said your responsibility is to lay out a simple cookie-cutter approach to performing common tasks and projects in such a way that minimizes the need for interaction with security while creating a simple approach to building security into the project.  To illustrate the point consider a project where your delivery team will be building out a private customer-centric site to interface with your internal systems.  The project may be repeated dozens or hundreds of times each year and by creating a one-time approved and documented process, procedure and architecture document you'll save yourself and the project teams many cycles and meetings.  They'll thank you for it later.  In order to make this work though, you'll have to make sure you cover as many of the common project types as possible.

The last thing you'll need to remember on the format is to give people as many options (that you've pre-approved) as possible.  There will be no one-size-fits-all approach that will work all of the time - so you need to make sure you cover as many options as possible and provide possibilities for accomplishing the same goal given budgets, resources and time.  Don't forget to factor in budget, resources and time into your documentation or you'll regret it later when your hard work starts to gather dust.

 The first group you'll need to cover are the people who make projects go - the project managers (PMs).  They will need easy to understand cheat-sheet style documentation which can be printed out and stuck into a binder.  Maybe you'll get lucky and your document's simple pages will end up on the head of the project management office... or maybe it'll be required reading during the project manager training process.  At any rate - the policy must be comprehensible by the project manager.  Comprehensible can be broken down into a few simple requirements: simple, short, non-technical, and short.  I mention short twice because PMs have enough to worry about without yet another complicated document.  Your policy should include a very short executive summary (the "why" for your policy), it should contain a logical "if - then" organized section which describes at a high level (at the business level) the causal and effect of the security requirement.  If the business requirement is X, the security requirement will be Y must be laid out in simple to understand, non-technical language.  The Y (the requirement itself) must be broken down into a general solution and a technical directive.  An example of this is as follows:  If the business chooses to store credit card numbers (the business requirement) they must be protected by an approved form of encryption (high-level requirement); this requires utilizing pre-built module A, B, C or code snippets D, E, or F depending on implementation or technical requirements.  This example provides adequate if/then for the PM to grasp the requirement and then provides some light technical guidance on how to solve the problem.

After you've created a section for each of the cookie-cutters you're creating that's designed for the project manager you're going to want to address the development resources.  These technical resources often have no care for the business angle of the requirement only the technical solution which must be included to pass security audit later on.  Quite simply put these are the technical options that security is providing.  You can provide code snippets, pre-reviewed and approved modules or an architectural approach to the issue.  Securing a project can often take on many forms and it's important to include as many options (within reason, and that are technically sound) as possible to ensure that at least one if not more of the approved methods is feasible.  Feasibility is often overlooked when creating a document like this... security professionals simply bark out requirements without looking into whether it's even possible to execute them within the parameters of the project.  I've often heard from project managers that IT Security is trying to force the business to spend a million to protect a thousand.  Make sure you don't run into this type of obstacle - as it will definitely deter adoption.

Lastly, and this group is only last because I'm saving the most important group for last, you need to address management.  Eventually someone from either the PM or the Development groups will challenge your requirements and solutions.  Ensure that upper-management understands and can make sense of your documentation.  Getting this level of understanding will usher a whole new level of cooperation among business and IT and security, I promise.  Covering not only the technical approach, but also the project-management approach is one thing... but to make your policy document readable by someone in upper management who may or may not even understand what IT is doing... that's a whole new level of brilliant.  Upper management has a surprising thirst to "do the right thing"... but often times they're constrained by two major factors - understanding and budget.  You can't always address budget (which is where I tell you, sometimes you just have to let them accept crazy risks), but you can definitely address understanding.  Overcoming that taboo between management and security technology can not only create a very cooperative relationship but it has been known to lead to random acts of proper risk management.  I once shared the elevator with a CIO who, after being asked to read and approve the security policy I had set forth not a week before, let me know that in the last meeting of his direct reports when someone mentioned a new project that they were considering - he was able to throw out the security requirement for that "type" of project.  He smiled in self-approval as he described how silent the room fell... and how everyone could simply not believe the CIO was spouting security requirements.  It was quite an accomplishment.

So there you have it - we've gone through a lot of material - but the policy requires a lot of attention to get it right.  It's like building a good, strong castle.  The foundation is everything... but the cornerstone is the policy.

Next we'll be addressing the first real step you'll be making - taking a baseline - and this time I hope not to have a month in between posts... thanks for reading!