Security Policy - Security Series #0.2

Something I have been reading up on a lot lately and I am really excited about is security policy. I know, I know, you are thinking excited about security policy? Is this guy cracked out of his mind?. If you are thinking that, you're partially right ;)

One of the coolest parts of a security policy is that it let's you define what it means for your application to be secure. That's right, YOU get to define what "secure" means.


Well, to be clear, you and the stakeholders who are affected by your application are responsible for deciding what "secure" means for the context of your application.

Every application is different and every application will contain different levels of sensitive data that need to be protected from different threats. I think sometimes we get into a thinking rut when it comes to application security. I think that we see it as an all-or-nothing effort where it seems that if you do not implement countermeasures x, y and z, that your application cannot be considered secure. But when we stop to think about it, does that make sense?

Does it make sense that a software application for personal blogs needs to have the same level of security as a firewalled, intranet human resources application needs to have? Probably not. The human resources applicaiton probably has 10s of thousands, maybe even 100's of thousands of dollars invested in security alone. Do all of your projects have those kinds of resources? It would be nice, but probably not.

Also, are the risks the same between the blogging software and the HR software? At a 10,000 foot view, it may seem so. They could both be hacked, and we don't want that. But if we look even a little deeper, we see that the risks very different.

The worst thing that will to the blogging application if it gets hacked is that it may get vandalized or maybe have some data loss. The risks are low. No one gets hurt, only inconvenienced.

However, if the HR application gets hacked, and names, addresses, phone numbers, SSNs, etc. get compromised, that is a SERIOUS breach that could cost millions to rectify. It could also cost the reputation of the organization resulting in unrecoverable loss.

So as developers or project managers, we need to meet with project stakeholders to find the delicate balance between confidentiality, integrity, availability and resources.

Once we, and our stakeholders, find that balance, we have our definition of what "secure" means for the application. Once we have established that by keeping the data within the CIA model that protects the data to the level that we feel is adequate and within resources, then we know what we need to do to secure our application. Hence, once we achieve that level, our application is "secure"

This may sound unusual, but when you think it through, this type of thing is done all the time in other areas. An apartment building simply needs a controlled entry system to be considered a "secure" building. Even though most of us could "hack" past that secure entry. And what kind of training does it take to become a "security" guard, versus that of a city police officer? Each provides a level of security that meets the needs of what they are protecting as defined within the security plan that they are a part of.

This is certainly not to say that our applications should only be defended as well as an apartment building. Nor am I saying that they should not be putting resources into application defense. I am saying that we, including all of the application's stakeholder, are responsible for deciding what "secure" is for our application. We cannot ensure that our application IS secure, until we understand what "secure" is in the context of the application.

External Forces

No doubt some of you are thinking to yourselves that it is not ALWAYS just up to the developers and stakeholders to decide what secure is. Sometimes there are external forces. You would be correct if you think that.

Depending on what type of data you are dealing with, there may be external forces that will directly influence your security plan. The Payment Card Industry (PCI) will tell you specifically what you need to do to be able to call your application PCI complaint. The same goes for the Health Insurance Portability and Accountability Act (HIPAA) when dealing with patient medical records. Many times you will need to be aware of these or other external forces that affect your security policy, but they are not enough to fully define your policy, they only address specific concerns about the data they are targeted to protect.

Until Part 2

In part 2 of Security Policy, we will discuss what types of things go into a security policy. If you'd like to learn more before I get to part two, sometime next week, you should check out my presentation at CFinNC this coming weekend. I will be discussing more about security policy and other basics of application security.

Joe Williamson's Gravatar Thoroughly enjoyed the presentation in CFinNC! Thanks and looking forward to digging into your other material.
# Posted By Joe Williamson | 10/19/09 10:29 AM
Jason Dean's Gravatar @Joe, Thanks. I hope you get a lot out of the posts. Let me know if you have questions.
# Posted By Jason Dean | 10/19/09 11:47 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner