Do I Need a Security Policy? - Security Series #0.2.1

Last week we discussed the basics of a security policy. Today I want to go a little more in depth and discuss the need for a security policy.

Do I need a security policy?

Of course you know what my answer is going to be. Now you might respond with: But we are a small business, not an enterprise... or, But I am just a one-person shop... or Well you are in state government, Jason, I just make web sites for Mom & Pop... Too any of those responses I will direct you to my short list of reasons that a security policy is important for all.

  • In a large business, federal or state government, or any other "enterprisey" environment, a security policy of some sort is probably going to be expected. Whether for legal reason, accountability reasons, or because bureaucrats like paperwork, you are probably going to need to do it. But this should be seen as a positive, because security is good. Consider the following reasons as well.
  • In any size web development shop a security policy can ensure that everyone is on the same page. It can help maintain consistency across the entire application to ensure that the same levels of quality and control exist for each part of the application.
  • Even in the smallest of web development shops having a security policy can help ensure that security is part of the application's life-cycle from the very begin instead of making security an afterthought (which probably happens too often, right?)
  • If nothing else, having a security policy will help demonstrate due diligence in planning for the security of the application should the application ever be hacked and the client decides to take action. Whether is in a court of law, or internally within the company, by having a security policy you may be able to demonstrate that the hack happened outside of the scope of the agreed upon policy and that it was beyond your control with the given resources.

    This is not to say that it is a "get-out-of-jail-free card" for a stupid mistake, but if a hack occurs that really could not have been prevented without additional resources that were decided (in prior planning) were not reasonable, then you have that documented and it could save your job or your bacon.

So those are my reasons for the need for a security policy. If you have more, I'd love to hear about them in the comments.

Steve Bryant's Gravatar In a recent article on Evolution, Richard Dawkins said "A good theory is one that is vulnerable to disproof, yet is not disproved.".

When getting advise of the kind "Always do X", I would love to see am example of what X should not be done. Even if the situation is nearly (or completely) impossible. Otherwise, it takes on the feel of blind dogma.

For example, perhaps a security policy wouldn't be needed for sites that have no secure data, dynamic programming, or expected longevity.

That being said, you really have my interest with your series on security policies. I am excited to learn more and to begin to implement that knowledge.
# Posted By Steve Bryant | 10/26/09 7:42 PM
Jason Dean's Gravatar @Steve,

Far be it for me to argue with Richard Dawkins ;)

You're right, "Always do X" is not the message I am trying to convey. And that is actually the subject of a post I have coming up. I hope I don;t come across that way.

I would aruge that if your site is an "Application" then it probably needs a security policy. If it has no secure data (which in most cases is unlikely, because even an email address you be considered secure data) and it is not dynamic, then I would not really consider it an application.

As for expected longevity, in my experience, that is rarely accurate. Applications almost ALWAYS survive longer than expected, and many times it is those same old apps that are full of security holes.

I see what you are saying, but just as we can;t say "Always do X", we also can't say that in these cases "no need for X". Just like everything in web development, it depends :)
# Posted By Jason Dean | 10/26/09 8:35 PM
Steve Bryant's Gravatar Jason,

My point wasn't the specifics of the example that I gave. My point is, it depends on what? I'm fine with hearing "It depends", but without some examples of something on which it might depend, that isn't very useful.

I hope I'm not coming off as argumentative or anything, I just prefer to see advice with guidelines that allow for a scenario where you would not take a certain course of action (even if it is a virtually impossible scenario).
# Posted By Steve Bryant | 10/27/09 9:23 AM
Jason Dean's Gravatar In my future posts I plans to discuss what types of things go into a security policy. Possibly you will find the answers you seek there. I am trying not to have posts that are exceedingly long, but instead to cover these things over several shorter posts. Perhaps you are getting ahead of me.

I would say that if your application actually "does anything" that you should have at least something that resembles a security policy. It may only be a one page document that covers a few boilerplate concerns, but it would cover at least the basics. I am not saying that ever application needs a huge document that requires countless meetings to prepare.
# Posted By Jason Dean | 10/27/09 10:14 AM
Steve Bryant's Gravatar Jason,

Sounds good. I am really excited to learn more about security policies. I hope to start using them soon.
# Posted By Steve Bryant | 10/27/09 10:26 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner