System Misconfigurations Can Put Your Data at Risk

While many organizations focus on their vulnerability management programs to find critical vulnerabilities like the highly-publicized Shellshock, Poodle and Ghost, it’s equally important to validate system build and configuration change management processes, as these activities can also leave your systems and data at risk. Kelly Prevett and I addressed this topic last week in a Tenable webcast where we shared some interesting misconfiguration examples, discussed how to coordinate people, processes and technology to avoid misconfigurations, and explained how Nessus configuration audits can help.

How can system misconfigurations leave you vulnerable?

A good example is last year's data breach at MBIA. MBIA is the largest bond insurer in the USA, with reported assets of more than $16 billion in 2014. Last year, MBIA was in the news because of a data breach reportedly caused by a misconfigured Oracle Reports database server. This database server, part of mbiaweb.com was misconfigured so that instead of only sending data to authorized administrators, data was made public, picked up by the search engine crawlers and made available to anyone with a web browser. Account information like account numbers and balances was exposed. As soon as they were notified, MBIA shut down the server and notified their customers, but because of a misconfiguration, sensitive data was exposed for some time. Brian Krebs did a nice write up if you want to read more.

It’s not just misconfigurations that can leave you vulnerable. Not changing the default configuration can be equally risky.

It’s not just misconfigurations that can leave you vulnerable. Not changing the default configuration can be equally risky. Earlier this year, Swiss Security Firm BinaryEdge did a study where they scanned the Internet on various ports looking for servers running Redis, MongoDB, Memcache and ElasticSearch. They picked these applications because if you read the documentation, it’s clear these applications are not intended to be secure with default settings only. For example, the Redis website clearly states:

Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.

So, despite clear warning, it is obvious from the BinaryEdge study that not everyone reads the documentation. BinaryEdge received responses from hundreds of thousands of servers, delivering more than a terabyte of data. Misconfigurations can come in many forms.

Avoiding misconfigurations

Kelly walked through five steps to help ensure your systems and applications are configured appropriately, so you don’t end up in a situation like the above examples.

1. First, define the technical standard your organization will follow. Your organization might choose to follow a well-known industry benchmark like CIS or another best practice, or develop your own best practice. Involve more than just the security team in this decision (especially systems administrators) and don’t expect that all your systems will meet the standard on day one. It’s better to pick a future date and work towards compliance with that standard by that date.
2. Next, define roles and responsibilities. Ideally, there’s an executive champion responsible for getting a technical standard to sponsor the program and stakeholders from teams throughout the organization.
3. Document at what frequency assessments must be performed. Depending on the standard you choose, that standard might have a minimum designated interval for doing assessments. More frequent assessments will give you better visibility into whether systems are compliant with your standard or not.
4. Cite exception procedure for systems that do not comply with the technical standard. There will be systems that you may not be able to configure per your standard for a variety of reasons.
5. Finally, cite the scope (production, pre-production, certain business functions, vendors, etc.).

Kelly also shared good advice on the importance of continually measuring how this process is working for your organizations. Set realistic milestones and know that it may take your organization some period of time to meet them.

Configuration auditing in Nessus

Configuration auditing in Nessus, while perhaps not as well-known as its vulnerability scanning capability, is a core tenet of the Nessus solution.

While people and process play a big part in a configuration management program, technology can help too. Configuration auditing in Nessus®, while perhaps not as well-known as its vulnerability scanning capability, is a core tenet of the Nessus solution. Today there are more than 450 different configuration audit policies available for Nessus, ranging from CIS and DISA STIG audits for assets like applications, systems and databases, configuration audits to address standards like CERT and HIPAA, and even audit policies that look for sensitive content within Windows and Unix/Linux systems.

More frequent audits can result in greater visibility into configurations in your IT environment.

In the webcast, we talked about how to do configuration audits with Nessus; that you can either set up a configuration audit scan to run agent-less (ad hoc or scheduled) or use Nessus Agents. One of several benefits we discussed about using agents is that, since agents use local resources on the host where they’re installed, they can be a better way to more frequently run configuration audits without placing an undue performance load on your network. More frequent audits can result in greater visibility into configurations in your IT environment.

Resources

To learn more about configuration auditing in Nessus, check out these resources:

• Watch the recording of our Systems Misconfigurations Leave your Data at Risk webcast
• Sign up for our October 22, 2015 Nessus Agents Online Demo
• See Configuration Audit examples
• Follow the blog articles by our Director of Compliance Research, Mehul Revankar, who writes frequently about new configuration audit policies