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 PoliciesSecurity 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:
Architecture DocumentationFollowing 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.
Change DocumentationAll 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:
After the change has occurred, the following should be added to the documentation:
After the change has been requested , documented, and approved, you should then send out notification. Notification is discussed a little bit later. Logs and InventoriesThe 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. ClassificationThe 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:
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. NotificationChange 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 DisposalLog 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. |