INFOSEC: information security news from the University System of Georgia, July 2009 (Vol. 1, No. 3)

Information Security News from the University System of Georgia
V0l. 01 No. 03 July 2009

INFOSEC WWW.USG.EDU/INFOSEC

Whenever an institution starts throwing around terms like "policies" and "standards," those who may be faced with incorporating these requirements into their operational realities often begin to shudder reflexively. That need not be the case.

Since it was established in August 2008, the University System of Georgia's (USG) Office of Information Security goal was to help our System to achieve dramatic improvements in public service and value for the citizens of Georgia by providing leadership and direction for information and information systems policy. The security and privacy of information and information systems in the USG through common policies will ensure accountability and alignment of System business objectives and information technology with USG strategies, and ensure that we leverage policies, technology and awareness to support that transformation.

According to Stanton S. Gatewood, Chief of Information Security: "Management support, policies, technology, and awareness are a powerful cocktail."

THE WHEN & HOWs

There are any number of reasons for a policy to be generated, but the majority of them are created to serve an institutional need such as a security concern.

These concerns can be internal (as in the case of the arrival of new technology...) or external (such as copyright enforcement from either a commercial or

governmental agency...). Also there are legal requirements and specific federal programs such as FERPA and HIPAA that will be the jumping off point for a

policy initiative. Be certain, that when you enter the planning stage of your policy development that the policy can be easily implemented into the targeted

workflow and that it can be effectively enforced. Policies should always strive to meet operating standards and relevant business practices. Some policies

are simple and straightforward, while others are more complex. But policies

on a whole should be appropriate to the needs that brought them about.

"NO POLICY...NO ACCOUNTABILITY"

Remember...no one wants to find himself/herself in a situation where they have expended $800,000 worth of effort to protect an $80 hammer.

- Stanton S. Gatewood Chief, Information Security University System of Georgia

If you are new to the world of policy development, don't feel like you have to re-invent the wheel. There are many resources online that can help provide the seed work for a new policy. For instance, the National Institute
>> cont., PG 2

of Standards and Technology (NIST) and Educause (www.educause.org) are good places to start.
You should always attempt to make new policies as consistent with existing policies as possible. If you are in the process of building your first policies, you may want to strive to make them as consistent as possible with USG policies.
WHAT'S INSIDE...
A strong principle to adhere to when creating policies is that they remain as flexible as possible and leave the specifics to their attendant standards. Policies should indicate a need but not a methodology. That falls to the roll of standards and guidelines. A policy is simply a position or stance on an issue that has been adopted by an institution. You may need to someday create a policy surrounding network traffic, but you wouldn't want to appear before a faculty senate asking for permission to close specific ports.
Standards (see glossary at right...) can change more frequently than policies. For instance a policy may exist as to the need to classify data based on sensitivity, but then the standard can go into the specifics of how. There may be a need for a policy dictating that strong passwords be used throughout an organization, but the standard will manage the particulars. For instance, you wouldn't want to create such a policy and insist that all systems use passwords that have a minimum of eight characters comprised of letters, numbers, and special characters only to discover that a legacy system affected by the policy was set up to only handle six characters.
WHO'S ONBOARD?
A key part of moving a policy forward is to involve the right stakeholders. You always want to secure buy-in from those individuals who will make your policy a living document. Surveying and/or convening representatives whose groups will be affected by or placed in the position of enforcing a policy is crucial. Knowing your constituencies can always facitliate the process of rolling out a new policy.
Also, remember to be thorough in your research when creating a policy initiative. Being proactive and seeking out subject matter experts is a way to ensure that alignment with other business rules and policies is maintained. The earlier both of these aspects of the development process are brought into play, the healthier the prospects are for a policy's development and resiliency.
>> cont., PG 3

GLOSSARY
POLICY: Generalized requirements that must be written down and communicated to certain groups of people inside, and in some cases outside, the organization. are mandatory and can be thought of as the equivalent of organization-specific law. STANDARD: Provisions for specific technical requirements such as implementation steps, systems design concepts, software interface specifications, software algorithms, and other specifics. GUIDELINES: Identify best practices to facilitate compliance while providing additional background or other relevant information. Similar to policies, but optional.
RECOMMENDATIONS
Formulation of a security policy is essential for any organization that has security concern Policy design requires a thorough understanding of the potential risks Unless your organization has an appropriate security policy you may be legally restricted in what activities you can monitor and what steps you can take The words used to compose policies must convey both certainty and indispensability Standards will need to be changed considerably more often than policies because the manual procedures, organizational structures, business processes, and information systems technologies mentioned in standards change so rapidly

USG POLICIES

POLICY

STATUS

USG Password Authentication Policy Approved

USG Appropriate Use Policy (AUP) BOR Approved

Risk Management Policy (RM)

BOR Approved

USG Continuity of Operations Plan BOR Approved Policy (C.O.O.P.)

USG Data Handling and Storage Policy Approved and Standard

Draft USG Computer Security Incident Developed under

Management Policy (IR)

review/vetting

USG Use of Encryption Policy

Developed under review/vetting

APPROVAL DATE
Dec 2008 Jan 2009 Feb 2009 May 2009
May 2009
March 2009
June 2009

POLICY TYPES
Program policies: address overall IT security goals and typically apply to all IT resources within an institution.
System-specific: address the IT security issues and goals of a particular system
Issue-specific: address particular IT security issues such as Internet access, and installation of unauthorized software or equipment, and sending/receiving e-mail attachments.

POLICY POLISH
Once a policy has reached the draft stage, it is probably best to allow for a healthy cycle of review and refinement. This ensures that the development of the policy is still on track and that support for the document remains in place with stakeholders as it comes closer to being finalized. While input should be solicited, changes and additions to new policies should be made carefully. Final policy directives are approved by the Board of Regents IT Committee before being presented to the BOR body for final approval.
This may also be a good time to develop a communications strategy that will best serve the policy's dessmination and compliance. Web postings, e-mails, and targeted training sessions can all be used to spread the word about emerging policy initiatives. The release of the final policy includes a management memorandum from the CISO to the system office and the institution heads.
The last part of the process is putting the policy into practice. Included in this step is any necessary post-publication training required to educate those that fall under the governance of a new policy. It also bears mentioning that the USG System Office must model the compliance behavior it expects from the institutions. Depending on the scope of the policy, a program of compliance monitoring may be undertaken. An additional aspect of implementation is the regular evaluation of the policy for continued usefulness.
RESOURCES
Throughout the policy development process it is important to remember that there are a wealth of resources available to help guide CISOs through all the necessary considerations that must be made during the cycle. The following online resources are good jumping-off points that can be explored and revisited as necessary:

http://www.usg.edu/infosec/policy_management

http://www.sans.org http://www.educause.edu

NETCASTS

http://csrc.nist.gov/

To listen to a new USG Infosec netcast on "Polices" and many other topics, go to:
http://itunes.usg.edu/

MORE INFORMATION...
USG Office of Information Security

Stan S. Gatewood, Chief of Information Security 706-583-2001 or 888-875-3697 www.usg.edu/infosec