Secure OS deployment

Question

I want to deploy operating system images on quite a lot of clients. I know that the images must contain the latest security patches, as well as hotfixes (assuming they are tested and approved for the target environment). They also have to be configured to receive regular updates from a certain distribution point. Moreover, I know (see this Q&A) that the PXE installation must be performed in a contained environment, so that an attacker cannot install rogue devices and services.

Are there other security precautions and/or best practices to follow when preparing and deploying OS images?

PS: Here's some additional information, just in case: The client OS is Microsoft Windows 7 x64. I'm deciding to use tools such as Windows Automated Installation Kit, Microsoft Deployment Toolkit, Windows Deployment Services, and System Center Configuration Manager to prepare, deploy, and manage the OS on the clients.

Answer 1

I accomplished this using WDS and MDT. The biggest problem as you gave mentioned is that the boxes aren't secure whilst the latest few rounds of updates are being installed.

Keeping the windows firewall enabled and restricting exactly who and from what computers these sensitive machines can be accessed can easily be accomplished by the ipsec rules and restricted group membership deployed via group policy. We have a whole separate firewall policy for our new build OUs.

To minimize the danger from a rogue dhcp / tftp server I prefer to keep the server on the same subnet, not forward broadcasts and only apply the vlan to the ports associated with my bench.

I use solar wind's patch manager which uses wsus under the hood. This is set up using https to verify any later patches are securely transmitted. We also sign all patches we assemble in house.

Answer 2

Strictly from an organization point of view. An organization that takes O/S hardening very seriously they would do something similar to this. High-levels steps would include:-

1. Classify the system before installation (critical, sensitive, public). These sensitivity levels are organization specifics and related to organization data classification schemes. Like NIST have profiled their system based upon their use; Their levels are divided in

   • Specialized Security-Limited Functionality

   The High Security, or Specialized Security – Limited Functionality, level is designed specifically for very hostile environments under significant risk of attack. This level guards information of the highest possible value, such as information that is required by some government systems.

   • Enterprise client

     More about this can be read from the link

   Remember that these are hardline details or procedures,and are expected for a certain O/S to meet the requirements of the profile mentioned above. In your case; these sensitivity can vary from some web-server you keep on DMZ to an internal server use ERP server, both would have different profiles and hardening requirements.

   Also a choice of general purpose server can be influenced by some international certification and accreditation. Like O/S Windows 2003 Server is a C2-level Secure Operating System, this is why you would see this O/S running on systems of DoD. C-2 is based upon orange standard made by DoD to meet required security requirements. More about this can be read from Details of Janus Group Security System

2. When done through automated compliance check scripts (unix or windows) that is run by system security administrators to ensure organization hardening / configuration management policy requirements are kept in order. Administrators in case of NIST levels (already mentioned) can deploy pre-defined templates to bring their system profile on desired level of security.

   Based upon The National Checklist Program (NCP) * defined by the NIST SP 800-70 Rev. 2, is the U.S. government repository of publicly available security checklists (or benchmarks) that provide detailed low level guidance on setting the security configuration of operating systems and applications*. If you are interested in Checklist Details for CIS Windows Server 2008 Benchmark v1.1.0. The link i provide gives you the option to select checklist as per need (e.g from non-automated tests to automated using scap(Security Content Automation Protocol)).

From practical standpoint of view these above 2 points means the difference of having an o/s run on iptables and use of tcp-wrapper , to a web-server running open development environment like joomala to have third party joomala firewall running (e.g RSFirewall), or having mod-security configured to harden the server.

The purpose of any secure O/S deployment exercise should be limit the attack surface while not limiting or breaking the intended application or use. Usually after o/s deployment, system administrators follows a checklist of list of services or programs that needs to kept on the server. That list comes down from business or process owners. This crucial step not only lessens the load of configuration management but also makes change management easy and practical.