• Choose a category
• All
• Classic-Fiction

A security baseline is a subjective thing between one organization and another. Baseline parameters need to be defined as part of your security policy. The baseline can be a written policy document, it can be implemented via a configuration tool, or it can be imposed via an installation/deployment system (such as image clones of a secured original).

Your best effort for establishing or defining a baseline lies in a full understanding of your operating system, business goals, and the vulnerabilities, threats, and risks of your environment. To get started on creating a security baseline, seek out existing public baseline recommendations. Use these as a seed to generate your own customized version. Every OS vendor provides “how to secure this OS” documents, numerous security product vendors provide them, and many third-party security watch groups (grassroots, commercial, and governmental) provide them as well. A few Internet searches should produce more than sufficient results. Some great keywords to search with include the name of your selected OS along with security policy, system hardening, how to secure, security baselines, and security recommendations.

The SANS policy site is a good first stop for information on using security baselines (http://www.sans.org/resources/policies).

As previously mentioned, no one operating system is significantly better or worse than any other. So pick the one you are most familiar with and have the most knowledge and experience with. The more you already know about an OS, the less you have to learn. As all of the lockdown or hardening guides will tell you, keeping the system updated and imposing the principle of least privilege are your two best efforts.

After a security baseline is established, you will need to regularly reassess the security state of every system. Time and change can result in the lowering of security. To prevent such a diminishment, you need to be proactive in testing the security of each and every system on a periodic basis. Any system failing to meet baseline requirements should be taken offline, corrected, and verified before being returned to the operating environment.

It should also be a point of procedure that after every security incident, no matter how minor, every system involved should be reassessed. If any system cannot be given a clean bill of health (i.e. returned to baseline security levels or better), it should be reconstituted. Any system that has experienced a full-blown intrusion, rootkit deposit, Trojan horse attack, or malware infection should be reconstituted.

Reconstitution is the act of completely purging hardware of all software elements and then reinstalling the entire system from original media or from trusted backups. The purpose of reconstitution is to reestablish the trustworthiness of a compromised system. If a serious compromise occurs, there is no way to fully verify that all aspects of the compromise are removed or thwarted. Thus, reconstitution removes all traces of possible corruption and rebuilds a new trustable system.

Certificate Management

Certificates are currently the top-shelf method of proving identity. However, it is important to stress that identity proof (such as authentication) is the only purpose of certificates. Certificates in no way provide proof of reliability, rustworthiness, compatibility, or benevolence of an entity. The only proof provided by a certificate is the identity of that entity. It is a separate and distinct choice to trust in an entity once you know who they are. Certificates are used as the primary means of identity proof on the Internet for e-commerce and resource download sites. However, too many people associate having a certificate with some type of proof of goodness. This is an absolutely incorrect assumption.

A simple understanding of what a certificate is and how they are created can easily dispel this misguided notion. Certificates are issued by CAs after they prove the identity of the requesting subject. The identity is