|
|
|
Date Submitted:
11/18/07
Hits: 113 Rating:  based on 0 votes
Information Security as a ProcessAdded by Papergrl
By Mitchell Rowton Information security is a maturing field that doesn't have many of the processes that other areas of IT take for granted. In this article we will explore one of the obvious processes that should be in place in any security department and then use this example to illustrate how Policy, Procedure, and Standards, can support this. Discussing how these three elements work together in the grand scheme of information security can provide you with information that will make more efficient use of your time and resources. The basic need of a process is simple, to keep the amount of spur of the moment decisions to a minimum. This can only happen when there is a system of documented and repeatable steps in place to help guide security engineers through common tasks that normally require decisions to be made. Let's go over one process that requires security decisions to be made on a regular basis - firewalls. When someone, possibly in your organization, or maybe in another organization requests a change to your firewall, what do you do? Obviously you look at the request, determine whether or not it is a good idea, and then either make the change or tell the person that it would not be secure. This is the general practice in any maturing security department but this ad-hoc process doesn't address many essential issues. Is your firewall administrator really the one who should be deciding who has access to what data? Could the data owner possibly contribute some input in this process? Exactly what information is taken when the decision is made? Do you make sure that for recording purposes you get phone numbers, e-mail addresses, reasons for the change, descriptions of what will be using the change, etc? Do you keep track of these changes and occasionally check to see if the access is still needed. If you look at the firewall rule set and find an "allow" or "permit" statement that looks a bit vague, can you associate this with a document explaining who requested it, why its there, and who approved it? At first glance the change process seemed simple, but when asking these questions, many other important considerations are brought up. The process of information security contains three basic levels; Policy, Procedure, and Standards. These make up a kind of security organization chart with Policy being at the top, followed by Procedures, and finally with Standards. Many people confuse these terms, especially Policy and Procedure. I cant count the number of times I've heard someone refer to a "Departmental Policy". The words departmental and Policy, when used together - is an oxymoron. Policy is company wide, Departments have an opinion, but they don't represent the organizational views of the Policy. Information Security Policy A Policy in its simplest definition is the formal view of the organization. It serves other purposes such as assigning responsibility, defining punishment, and serving as the "laws of the organization". A Policy gains its authority from senior levels of management and must be followed by "everyone" in the organization. Most organizations of medium to large sizes require many different security Policies but there should usually be one overall Information Security Policy that outlines basic functions of security. This Policy should be signed by the CEO, Commander, President, or other equivalent bigwig in the organization. Keep in mind that this individual doesn't have to (in fact should never) write the Policy, he or she only has to express concurrence in the form of their signature. This Policy may state that the company takes information security seriously, assign different department(s) certain responsibilities for information security, and state the authority of all the individual security Policies... Notice the last statement - state the authority of all individual security Policies. Individual Security Policy (Specific Policy) Now we have an umbrella Information Security Policy that assigns roles and responsibilities, expresses the company's commitment to security, states that there are more detailed Policies, and tells who can draft these detailed Policies. These detailed Policies may be signed off by the CIO, Lieutenant, VP or similar semi-bigwig (who has been given this authority in the umbrella Policy). Depending on the organization this may include a Remote Access Policy, Extranet Policy, Firewall Policy, Logging and Monitoring Policy, etc� Earlier we decided that we need a more formal process for making changes to firewalls so will explore (you guessed it) a firewall Policy. Only this firewall Policy isn't going to be called a firewall policy. Firewalls serve one basic role, restricting access across the network. Other devices may also me used for this role: router ACL's, proxy servers, NAT devices, and who knows what equipment that isn't necessarily called a firewall. Some organizations have begun to call this Perimeter Defense in an effort to include these non-firewall devices. The problem with perimeter defense is that it only protects the perimeter! The perimeter of a network is a vague term that should never be used. Of course the connection to your ISP is a perimeter but what about Wireless Access Points, extranet connections with partners, dial in access from employees at home, DMZs. All of these could or could not be considered a network perimeter depending upon who you ask. This "judgment call" is exactly what we are trying to get away from in our Policy creation process. A better way is to embrace Defense in Depth. How does that candy firewall joke go again? Hard on the outside, soft and squishy on the inside. The decision of protecting to, through, among, from, and above the network (not just the perimeter) should be one of the primary functions of the specific Policy. Enclave Boundary Defense Policy Sounds catchy, eh? Formal, commanding, everything a good policy name requires. The best part of this is that it doesn't restrict you to just firewalls or just protecting the network perimeter. Let's pause to define the term enclave. For the purpose of this article (and a suggestion to you) an enclave is any device or system that requires different access controls than its surrounding devices or systems. An obvious example of this would be a DMZ, it's more secure than the internet but less secure than the inside - it's an enclave. An extranet connection would require different access than a user subnet on the 16th floor - another enclave. In your Policy define the word enclave; define who is responsible for enforcing these access requirements, define basic access control mechanisms such as principle of least access, separation of duties, and most importantly this Policy needs to require the creation of departmental Procedures for installing, managing, tracking, changing, any of the access control devices used in this Policy. Firewall Change Request Procedure We are finally getting back to our original example of making changes to firewalls. We have an Information Security Policy that says security is important and so are these specific policies. We have the Enclave Boundary Defense Policy which says access controls are important and so are departmental Procedures. We have a departmental Procedure that says this is how we make changes to firewalls� It may seem like a very roundabout way of getting to the end goal, but the formal Policies which make up the backbone of authority are essential to establishing repeatable processes. The specifics of a Firewall Change Request Procedure will vary per organization, and may be drafted by the management of the division responsible for maintaining firewalls (as outlined in the Enclave Boundary Defense Policy). But at the very least it should identify who can approve the changes, it should record information about the changes, and it should provide an audit trail to verify the changes in the future. You may have a separate Procedure for all of the above goals, or you could split the Procedure into an internal firewall administrator Procedure and external customer request Procedure. Take some time in developing this Procedure, you may want to talk to data owners about who should approve changes, legal department for what kind of due process needs to be maintained, privacy office for what kind of information you should record, and a host of other departments who may request firewall changes on a regular basis. Acceptable Port Standard Any document that may need to be updated more than twice a year should be separated from the procedures that you develop. The Firewall Change Request Procedure may say that firewall engineers can approve change request for services allowed in the Acceptable Port Standard document, but all services not in this Standard must be approved by management. This may be a good idea because it can create a permanent waiver for some changes that can be made without management approval. This list of Standard ports will need to be edited fairly often as new viruses, worms, or script kiddies start to abuse certain ports and services. But it can save time and ensure that decisions about firewall changes are uniform and independent of the person making the change. There is always going to be a need for an intelligent security professional who can analyze a request with all the nuances that weren't discussed in this article, discover the possible risks associated with these and decide, using their best judgment whether or not it is safe. This repeatable process will not replace an intelligent security analyst, but it will make him or her more efficient at their job.
You don't have permission to post replies. Please login or register. |
