Understanding Security Documentation

Vulnerability assessments, change-management procedures, incident-response guidelines, security procedures, logs, and many other security- related factors may require extensive documentation. In addition, you should plan for the proper storage and disposal of these documents to prevent accidental exposure of sensitive information. Because security audit documentation provides focused information detailing vulnerabilities and risks, these documents should always be kept in a sealed, limited-access location.

Security Policies

Security policy documentation is often the most extensive in terms of variety, rapidity of change, and requirements for retention and disposal. Possible security policies include the following:

  • Acceptable use policy Specifies the acceptable use of equipment and resources as well as the expected security measures users should follow. This may include a more detailed email use policy.

  • Antivirus policy Specifies requirements for antivirus software, definitions update procedures, and computer use expectations involving potential avenues for viral incursion.

  • Audit policy Specifies details to authorize, conduct, and investigate audits , security risk assessments, and user compliance. This may also include authorization for incident response and reporting, along with limitations on what data may be logged and how long it may be stored during client monitoring.

  • Nondisclosure agreement Documents the user's agreement to avoid disclosing sensitive information. This may include specific details regarding the level of access granted to a particular user and should be maintained in a secured, limited-access, fireproof location.

  • Password policy Specifies password requirements, including length, strength, history, and required rate of change. This may include details on regular security reviews of password settings.

  • Remote access policy Specifies access requirements and methods used during the remote access of an organization's resources, such as dial-up or VPN connections.

  • Server security policy Specifies the minimum security required of servers operating within an organization's protected network. This may include additional details specific to DMZ or bastion servers.

  • Wireless network policy Specifies the standards, WEP keys, and other configuration settings used in WLAN solutions.

Architecture Documentation

Following the discovery and profiling phases of your asset-identification and risk assessments, you need to produce detailed documentation on the system's architecture. This documentation includes hardware and software inventories, as well as specifications on logical replication paths and protocols in use. Security architectural documentation should include remote access, VPN, firewall, and IDS systems. Obviously, these documents should be carefully protected to avoid accidental exposure.

Because the network architecture will continue to evolve , it is critical to plan for change management. Change-management policies should include specifications for change authorization, documentation, and notification, along with inventory-control procedures and retirement procedures to be used when hardware, software, or storage media is replaced or discarded.

graphics/tip_icon.gif

An organization's information sensitivity policy will define requirements for the classification and security of data and hardware resources based on their relative level of sensitivity. Some resources, such as hard drives , might require very extensive preparations before they may be discarded.


Change Documentation

All changes should be documented. Many companies are lacking in this area. We are often in a hurry to make changes and say we will do the documentation latermost of the time, that doesn't happen. You should realize that documentation is critical. It eliminates misunderstandings and serves as a trail if something goes awry down the road. Change documentation should include the following:

  • Specific details, such as the files being replaced, the configuration being changed, the machines or operating systems affected, and so on

  • The name of the authority who approved the changes

  • A list of the departments that will be involved in performing the changes and the names of their supervisors

  • What the immediate effect of the change will be

  • What the long- term effect of the change will be

  • The date and time the change will occur

After the change has occurred, the following should be added to the documentation:

  • Specific problems and issues that occurred during the process

  • Any known workarounds if issues have occurred

  • Recommendations and notes on the event

After the change has been requested , documented, and approved, you should then send out notification. Notification is discussed a little bit later.

Logs and Inventories

The log files themselves are documentation, but how do you set up a log properly? Standards should be developed for each platform, application, and server type to make this a checklist or monitoring function. When choosing what to audit, be sure you choose carefully. Audit logs take up space and use system resources. They also have to be read, and if you audit too much, the system will bog down and it will take a long time to weed through the log files to determine what is important. A common storage location for all logs should be mandated , and documentation should state proper methods for archiving and reviewing logs.

Classification

The last area of documentation we'll discuss is the classification of data. You should set standards for how information is evaluated and classified . The standards for data classification can be taken directly from standards published by the U.S. government, or you can come up with your own model. After that is accomplished, you can then document how to store the data. There should also be a policy in place for the destruction of data. Many criminals have found valuable data by "dumpster diving," and many companies have been embarrassed by the media, conducting their own investigations, using information these companies do not destroy properly.

Retention and storage documentation should outline the standards for storing each classification level of data. Take, for example, the military levels of data classification. Their documentation would include directions on handling and storing the following types of data:

  • Unclassified

  • Sensitive

  • Confidential

  • Secret

  • Top secret

Documentation for data should include how to classify, handle, store, and destroy it. The important thing to remember here is to document your security objectives. Then change and adjust that documentation when and as needed (with emphasis on when and as needed ). There may be a reason to make new classifications as business goals change, but make sure this gets into your documentation. This is an ongoing, ever-changing process.

Notification

Change notification should be distributed to those possibly affected by the change. The notification process should include a feedback option in the event that someone finds a step or detail that was overlooked in the original submission. Before you actually deploy the change, an impact assessment should be conducted .

An impact assessment or test phase should be conducted on nonproduction equipment in a test lab and evaluated without affecting user productivity. The most effective way is to create a mockup of the production environment and deploy changes there first. Deployment on lab equipment may uncover immediate problems and allow you time to adjust the process to overcome the issues. A good example would be a software patch. Many vendors release security patches for their software. By testing the patch in a lab environment, you may help avert a disaster later on, when the patch adversely affects another security issue. Impact testing should be well documented and should involve simulated end-user activity on the system. You never know the true impact of a change until you take the final step and upgrade your production systems. So what happens if disaster strikes? How do you remove the changes?

A rollback strategy should be part of every change operation. You need to remember that you are making changes that may impact productivity and the ability of the company to conduct business. Something as simple as upgrading a video driver can turn into a nightmare if you can't find a copy of the old driver when the new one fails. You need to protect yourself from such scenarios. Make sure you have a rollback plan in place before any changes are made.

Retention and Disposal

Log files, physical records, security evaluations, and other operational documentation should be managed within an organization's retention and disposal policies. These should include specifications for access authorization, term of retention, and requirements for disposal. Depending on the relative level of data sensitivity, retention and disposal requirements may become extensive and detailed.



Security+ Exam Cram 2 (Exam SYO-101)
Security+ Certification Exam Cram 2 (Exam Cram SYO-101)
ISBN: 0789729105
EAN: 2147483647
Year: 2005
Pages: 162

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net