What goes into a Security Policy? - Security Series #0.2.2

Previously we discussed whether or not a security policy is needed. I had some good discussion on the topic with Steve Bryant and promised that there would be more coming.

Whether or not you need a security policy is up to you and the stakeholders of the application, but it is my opinion that if your application actually does something (is more than just a static site) then a policy should be used, even if it is just a single page list of best practices that you will follow. If nothing else it demonstrates that you tried to provide a secure application and that your stakeholders agreed to the measures that you took.

So the next obvious question is, what goes into a security policy?

Again, this is up to you and your stakeholders, but here are some suggestion/guidelines of things that would be appropriate. As usual, if you can think of anything else, please comment below.


As with any complicated subject, some things need to be defined so that there is no confusion. Imagine the following conversation:

Boss: I thought I told you to make sure all the files were protected. Someone just downloaded all of our earnings statements.

Administrator: Well I thought you meant I just needed to ensure that the source code was safe. How was I supposed to know what you meant?

So here are some ideas of what should be defined in a security policy.

  • What are the assets that are being protected?
    • Files (Source code, images, system, config)
    • Data (database, settings from config, flat data files)
    • Hardware (Web, middleware, and DB servers, etc.)
    • Anything else that is deemed worthy of protection
  • Responsible parties - Who is responsible for what? Who tests the application for security? Who is responsible for securing the DB? The operating system? It may all be the same person, but then who audits what that person has done?
  • Risks - What are the risks if the application is compromised? Will there be business costs associated with notifying users? Legal costs? Loss of reputation?
  • What are the consequences of failing to comply with the security policy? If developers, administrators, or others involved fail to comply with the security policy, what happens? Are they reprimanded? Terminated? I certainly do not believe in zero-tolerance policies, so I think some description of what should happen in this situation is warranted.


Don't get this section confused with business requirements for an application. Business requirements are important, but we are talking about security. This section is about security requirements like:

  • Access Requirements - Who should have access to what? This is more than likely going to be a macro-level view. For example, developers will have access to read and write from the database, but only DB administrators will have GRANT and REVOKE access.
  • Change Management Requirements - If the application needs to change, how do we ensure that the changes fall within the security policy?
  • External requirements - Is the application required to meet certain external standards, like PCI or HIPAA compliance?
  • Misc Protection requirements - Virus scanner on the servers? Hardware or software firewall? Web Application Firewall?
  • Back up requirements - How often are backups done? What kind of backups? Do they need to be encrypted? Where are they stored? Are the storage locations secure?
  • Disaster recovery requirements - Who is responsible for what in the case of a disaster? If it is a hacking, does forensic evidence need to be maintained? Do you need a hot site backup? Does the backup site comply with the security policy? What are the response time requirements in a disaster?

Rules and Regulations

My daughter knows that rules are important, and she is 6 (she'll be 7 on Saturday), but she also knows that sometimes rules suck and are hard to follow and even, sometimes, hard to remember. That is why it is important to write down the rules that the people on the project are expected to follow. Again, these are rules related to security.
  • Validation Validation Validation - Did I mention validation yet? What are the rules for user input validation? What's allowed? Are some users allowed to enter HTML? Is there a set of allowed tags? Go with wiki style markup instead?
  • Encryption - When, where and how. What need to be encrypted? There are a LOT of places encryption can be used, in transit, in the DB, the file system, etc etc.
  • File upload rules - Is it allowed at all? Where do uploaded files go? What file types are allowed? Are they scanned or verified?
  • Approval workflow - This may also be part of the business rules, but a workflow approval can ensure that sensitive data does not get released by an ignorant user so it can be a security rule too.
  • Error handling - The error handling rules should be defined so they can be handled consistently across the application
  • Access control rules - how will access be controlled?
  • APIs - If the application has an API, how is access to that being controlled? Is it over SSL?
  • Session management - How is it being handled? How are cookies to be handled? Session timeout length?


We expect the rules to be followed and we have all of these requirements, but what are the procedures for accomplishing these things? Not everything needs to be mapped out step-by-step, but somethings may need to be.
  • Data Backup procedures - Where are they stored? Delivery schedule? Recovery test schedule? Off-site backups or off-entity backups? Addresses of backup locations?
  • Disaster recovery procedures - we discussed what the requirements are for disaster recovery, but what are the procedures? Who calls whom? Who calls the police if needed? Who talks to the media? Who notifies the client? In what cases is preserving evidence more important than coming back online?
  • Common countermeasures - If there are established countermeasures in place for dealing with certain security requirements, then they should be documented for the developers so they know which to use in what cases.


Whew, that's a lot of stuff. Surely I do not expect you to do ALL of that for every application. Of course I don't. Some of it only needs to be created once and can possibly be applied to every application you build, others may not be needed for your next project. Like I've said, it is up to you and your stakeholders to determine what you need to put into the security policy. For some applications, it may be all of this and more.

Steve Bryant's Gravatar Jason,

This is really interesting stuff. On my projects, I usually have a selection of programs any combination of which I might load onto a new site. It sounds from this, like each one should probably have its own security policy. Then probably another one for the site as a whole?

I really like the idea of defining the degree to which an application is secure.
# Posted By Steve Bryant | 11/17/09 7:58 AM
rishav raj's Gravatar All bing users can now get help for deleting their browsing history in easy way just by the guideline http://deletebinghistory.com and follow the instruction given in this guideline.
# Posted By rishav raj | 7/3/18 2:18 AM
rishav raj's Gravatar All bing users can now get help for deleting their browsing history in easy way just by the guideline http://deletebinghistory.com and follow the instruction given in this guideline.
# Posted By rishav raj | 7/3/18 2:19 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner