Out of the Box – Into A Data Breach?

There are a number of things that are great “out of the box” – new shoes, small kitchen appliances and power tools to name a few. What is not good “out of the box” – your operating systems, applications and network devices. Vendors deliver their products to the masses, so naturally, the standard configuration of their products is oriented toward ease of installation, deployment and operation. Their goal is to get you up and running on their product as fast as possible, not to meet the needs of the security conscious. Secure configurations for your operating systems, applications and network devices are your concern, not theirs. Just like the hours you spend on Christmas Eve putting together that thousand-piece toy kitchen set, you’re going to need to invest some time determining the secure configurations for your operating systems, applications and network devices. The following are some things to keep in mind as you start your journey toward a secure computing environment:

Remove/disable default accounts and change default passwords. You can find the default username and passwords for almost any device or software platform on the Internet. If you don’t remove or disable these accounts or change the default passwords, you’re asking for a breach. According to the 2016 Verizon Data Breach Investigations Report (DBIR), 63% of confirmed data breaches involved weak, default or stolen passwords. Failing to make this simple change is like leaving your car running with the door open in the parking lot at the mall. You can download the 2016 DBIR here: http://www.verizonenterprise.com/verizon-insights-lab/dbir/2016/

Use secure configuration benchmarks to harden your operating systems, applications and network devices. There is no lack of guidance on how to harden operating systems, applications and network devices. A great place to start, and a source I’ve consistently consulted, is the Center for Internet Security (CIS) benchmarks. You can download the latest benchmark documents here: https://benchmarks.cisecurity.org/downloads/latest/.

During my many years supporting the U.S. Government, we used the Security Technical Implementation Guides, or STIGs, as the guidance for hardening operating systems, applications and network devices. The list of STIGs produced by the Defense Information Systems Agency (DISA) is quite extensive; you can access the latest versions of the STIGs here: http://iase.disa.mil/stigs/Pages/a-z.aspx.

In my experience, no operating system, application or network device was ever configured to meet all secure configurations outlined in the CIS Benchmarks or the STIGs. Implement as much of the hardening guidance as you can and document the rationale of why you cannot meet the other hardening guidelines. This becomes your organization’s secure baseline which should be managed within a configuration management platform. Any changes to the secure baseline need to go through a change control process and receive the proper approvals prior to implementation. Afterwards, make sure you update the secure baseline with any approved changes.

Beware of the “temporary.” It is not unusual for someone in the organization to request a “temporary” change to the hardened OS configuration or to the firewall ruleset to support a business need. The danger with this is that the “temporary” often becomes permanent. In these instances, have a defined date when the temporary configuration is removed and replaced with the baselined configuration.

For operating systems, start small. For *nix systems, start with the minimum number of packages and build up from there. Through this method, you’ll be able to identify what packages/services are required for your system to work – with no extras. This method is much cleaner and efficient than the converse which is to start with the full install and try and remove packages/services that you don’t need. Using this approach, you will almost always have more than what is needed.

Use automated tools to verify and maintain your secure configuration. Determining and implementing secure configurations across your operating systems, applications and network devices takes valuable time and effort, so you want to make sure that your secure configurations stay in place. To do this, you’ll need to leverage automated tools. There are automated tools you can use (e.g. the CIS Configuration Assessment Tool (CAT)) that will report on the compliance of your system against the CIS benchmarks. An open source option is OpenSCAP. The output of these tools will direct you where systems are out of compliance with the secure configuration baseline. You’ll then need to take steps to get the secure configuration re-enabled on the system.

Another option is to use a configuration management tool like Puppet or Chef to apply the secure configuration to your systems at specified intervals. Using this method, if a change to the secure configuration was made, it is detected and overwritten when the secure configuration is re-applied to your systems. Most importantly, you need to know on a continual basis if your systems are out of compliance, so steps (automated or manual) can be taken to re-gain a compliant configuration.