Defining a Security Policy

Security Polices are a necessary evil in today’s enterprise networks. Without a Security Policy, you leave yourself open and vulnerable to a lot of political attacks. For instance, you have a web surfer in the company who feels it necessary to visit Porn related sites during working hours. If lets say someone who views this activity finds it offensive, you may have a court case on your hands if your paperwork is not in order. In this article, we will begin to look at all the measures you will need to deploy to successfully define a security policy. Since each policy is customizable to each organization, its important that you know here and now that each will be different in content in some sense, but defining it should follow some kind of model. In this article, you will be shown the fundamentals of defining your own Security Policy.

What is a Security Policy?

So the first inevitable question we need to ask is, “what exactly is a security policy”? Well, a policy would be some form of documentation that is created to enforce specific rules or regulations and keep a structure on procedures. Here, in the context of ‘security’, is simply a policy based around procedures revolving around security. Think of any other kind of policy… a disaster recovery policy is a set of procedures, rules and plans revolving around having a disaster and how to recover from it. Security polices are much the same. Ok, now that you have the general idea now, lets talk about what the security policy will generally provide. Remember… a security policy is the foundation and structure in which you can ensure your comprehensive security program can be developed under. If I can make an analogy, a security policy is like the spine, and the firewalls, IDS systems and other infrastructure is the meat and flesh covering it up. There are a great many things you will need to understand before you can define your own.

Security policies are generally overlooked, not implemented or thought of when it’s already too late. To keep you in the loop on what this means, we can flip flop back to the example I first stated with the Porn Surfer… It doesn’t help ‘after’ the fact when your dealing with a court case, if you had a policy in place to keep people informed about what it is they can or cannot do (like surf the web during business hours hitting sites that are not business related) they may not do it in the first place, and If they do, you have a tool (the policy) to hold them accountable.

So, now that we understand the fundamentals of what a security policy is, lets sum it up in one sentence before we move forward… A security policy is a living document that allows an organization and its management team to draw very clear and understandable objectives, goals, rules and formal procedures that help to define the overall security posture and architecture for said organization. This article will cover the most important facts about how to plan for and define a security policy of your own, and most of all, to get you to think about it – whether you already have one or not.

A security policy must also be created with a lot of thought and process. You can make a security policy too restrictive. If you do, you could cause a lot of strain on your employees, who may be accustomed to one way of doing business, and it may take awhile to grow them into a more restrictive security posture based on your policy. A security policy should contain some important functions and they are as follows.

The security policy must be Understandable! People who read it should be able to easily comply with it. You need to ensure that it’s not full of complete techno-babble that can be argued by an end user.
The security policy must be Realistic! Ok, you need to draw a line in the sand with your policy. If you are too restrictive, than you need to address why complaints could arise, or worse yet, management not backing your policy because it isn’t realistic. Remember, too much security actually impedes business so you have to find a perfect balance. Also, as new hires are brought into the company and perhaps made to sign a policy such as this, they need to feel comfortable with it at some level, so make sure it realistically meets your business, technological and security needs simultaneously.
The security policy must be Consistent! You need to be consistent. Telling people they can only surf business related websites and then overturn that decision to allow full access, to only three weeks later, again reverse your decision. This causes discontent amongst your user community.
The security policy must be enforceable! You can do this with auditing tools, logging and by other means. It must also be ‘clearly’ backed by management and human resources. If you decide that someone is in violation of policy, and management doest back the proposed punishment for breaking policy, then the policy is useless. I have seen this so many time in practice that this should be the number one item you look at when trying to get a policy together… if management doesn’t back it from the onset, then I could assure you, the effort of doing the policy and the enemies you could possibly creating enforcing it solely by yourself is a waste. Make sure you have backing from management!
The security policy must be documented, distributed, and communicated properly! To not do so is harmful to the organization because if you try to enforce a security policy nobody has read, then you are basically alone in your battle to enforce it. I suggest having new hires sign a copy as they join the organization and have the current employees do an intranet web form enforced via their managers or supervisors.
A successful security policy needs to be flexible! In order for a security policy to be a solution you have implemented for a long time to come, the policy needs to be flexible on what it covers, who maintains it and most important of all, who changes is. Your policy WILL experience change, just as your business changes (today’s business change faster than a heartbeat), you need to stay on top of the policy, that’s why it needs to be flexible and changeable.
A successful security policy must be reviewed! To ensure that your policies do not become obsolete, you should implement a regular review process of them. Its very possible that months after you create and implement a security policy that it doesn’t even fit into your organization anymore, depending on how often your company changes it other business relationships, or if it is in merger and acquisition mode. If so, you may find yourself in constant review of your policy. Make sure you are aware of what would instigate a review, and make sure you do a proper review after a certain amount of stagnation occurs, like if you had 6 months of no change in the organization.

Security Policy Structure

The basic structure of a security policy should contain the following components as listed below. Of course, you can add more to this list, but this is a pretty generic list of what it is you will want to structure your policy around.

The roles and responsibilities of those affected by the policy: Ensure that your policy clearly states the roles and responsibilities of all those affected by such policy. Do not leave any guesswork here. In other words, if you have different levels of access to systems like for instance, Internet access, where the user community has limited access, but the marketing department may have more than limited access due to the fact that they have more research they may need to do on the Internet. This being said, just make sure that you don’t start a war out on the floor because you did not clearly state who can do what in your policy. It’s a balancing act, but if done correctly, will, work like a charm and no animosity can really occur, since everyone knows what it is they can or cannot do once they are hired into the organization.
What actions, activities and processes are allowed and which are not? You have to be very clear here. You need to explicitly define what it is that people being held to the policy can and cannot do. The policy needs to be heavily reviewed to make certain that there is no wording in there that someone can use to an advantage point. If you say, do not use the Internet for anything other than business while working, then you pretty much put a blanket statement on what it is that users can do and if read a few times, I could probably say, “well, you said while working, and I surfed shopping network sites on my lunch break.” You left the door open here, and if that is not what you wanted to say, then you are in trouble because that’s what the user may have signed when being hired. Remember, its all a play on words, and you have to make sure you know how to state specific things. Make sure that you explain what actions, activities and processes are allowed and which are not – very clearly.
What are the consequences of non-compliance? This is a very important item to add to the structure. It’s very important that you clearly define what your punishment will be for security policy noncompliance. More importantly, make sure that any punishment that is placed within the policy is carried out without question. Once your user community knows that you are not enforcing your own policies, it’s all over! Make certain that if you state a punishment will occur, it does in fact occur. This is why you need to have simple punishments defined. Here is an example… If you are caught surfing non business related websites during working hours, you will be issued a verbal warning on the first slip up, the second slip will result in a letter of reprimand being placed in your employee folder, and a third slip WILL result in termination. This way, people are able to goof up, once, twice… three times – sorry! Your outta here. This is clear, to the point and it not intolerable.

Roles and Responsibilities

The development of security policies is also based greatly on roles and responsibilities of people, the departments they come from, or the business units they work within. Nothing in information Technology is 100% cookie cutter especially when dealing with real business examples, scenarios and issues. In the security policy framework, it’s critical that all area of responsibility are labeled clearly. Lets look at what areas need to be addressed within the organization. From the list below, you should make sure that when developing your policy, all areas listed below are at least offered to be a part of the team to develop the policy:

Business management: Business Management is the management in your organization – or the business leadership. Business management would contain Marketing, Sales, Customer Service, Engineering, Legal and the list goes on and on. Make sure that you discuss with all departmental level business management the needs of the department within the context of the security policy. The Sales department manager may want 100% Internet access for the employees in the department for research reasons. Maybe you can explain the risks involved and see if you can hit a happy medium. The Customer Service manager may be very strict and not want any Internet access, where its your job to weigh out the risks of an employee not having any Internet access… you have to look at both sides of the fence. Just make certain that you at least work with the business leadership to get their input regardless. Management must also 110% ‘back’ your policy no matter what. If there is a breakdown here, then the policy may be deemed useless if it’s easy to work around it.
Information Technology functions: IT is on a different end of the stick. Since most everything that is done with the Security Policy may come out of the IT department, there are a few items that you should be very aware of when developing your policy. Make certain that you involve all the appropriate parties. Lets say you are the security officer for the company and you are responsible for putting together a secuei9ty policy. Its easy to see security from ‘your’ point of view, but you may not have a well rounded IT view to be able to ‘not miss’ anyone. Just to make sure, you need to consider the following: Make sure that you involved ALL IT related departments, to include network engineering, systems, Applications, IT management, change management, and any other IT function that exists in your organization. Also, make certain that if you have IT help at remote locations or small business units that you involve them and get their needs as well.
Human resources and Legal: It is critical that you get HR and Legal involved with your security policy. You need HR to disperse the policy (hopefully when new hires are brought onboard), or even afterwards. Legal needs to be involved to make sure that everything in your policy is legal and does not infringe on rights that cannot be infringed upon or you could line yourself up for trouble.

Recommended Development Method

The following provides an outline of the tasks used to develop security policies. Again, this is not the defacto list, its just things to think about while deigning a security policy. This article is set up for beginners who are unfamiliar with policies, there are entire books on the subject, so just make sure that if you are building a serious security policy you will need to consider many more things so please do not take the next list as being definitive, but rather, the things you really ‘shouldn’t’ miss when creating a security policy.

Make sure that all responsible organizations and stakeholders are completely identified and their roles, obligations and tasks well detailed.
Make sure that all primary business objectives are outlined. Knowing the primary objectives of your business is important for your security policy.
Make sure that a list of security principles representing management’s security goals is outlined and clearly defined.
Make sure that all applicable data and processing resources are identified and classified.
Make sure that a data flow analysis is performed for the primary data classifications, from generation through deletion.
Make sure that the primary threats that can reasonably be expected in one’s environment are outlined.
Make sure that the primary security services necessary in the environment are identified.
Make sure that a generic policy template is constructed.
Make sure that you proofread your final Security Policy before you deploy it.
Make sure you have managements backing – this is very important!

Well, that’s the top ten listing of items you would not want to forget to think about when constructing your security policy.

Conclusion

In this article, we looked at security policies. Here, we took a very generic look at the very basic fundamentals of a security policy. In future articles, we will look at more detail and then build a security policy from scratch, until then…