ASD Essential Eight Explained – Part 6: Using Application Hardening

The Essential Eight

The Australian Signals Directorate (ASD) Essential Eight has received considerable attention since it included an additional four strategies to the previously defined ‘Top 4 Strategies to Mitigate Cybersecurity Incidents’. Logan Daley continues the ASD Essential Eight Explained series below.

Using Application Hardening

What is it?

Think of it kind of like spring cleaning on top of a minimalist lifestyle where you keep only what you absolutely need after taking stock of what you have. Many applications are installed with defaults (you know the Next-Next-Next-Next-OK approach) and as a result, many options, services, and capabilities enabled. We’re all guilty of installing applications this way, being more interested in using the program than securing it. Default usernames and passwords, insecure services, default SNMP communities, anonymous access, and the list goes on. Hardening these applications renders them more secure and less likely to be used against us. We all have applications on our infrastructures that could have a negative impact is used incorrectly or maliciously, so reducing that possibility only makes sense. Controlling who can access an application, what the application can do, and periodically revisiting this on a regular basis or after significant changes is a good approach.

Where do I start?

If you have undertaken an Application Whitelisting exercise or similar that required a full inventory of your applications, you have a big head-start. Otherwise, it’s time to make that list. It goes without saying that if you don’t need it, get rid of it and you’ll probably start finding applications you never knew you had. List in hand, you can check with the vendors to see what their hardening recommendations are or even use the industry best practices to better secure your environment.

Something else that should go without saying (but I’m going to say it anyway) is to change default usernames (if possible) and passwords if the application uses them. You’d be surprised how often this gets overlooked.  If the application uses a service that is not essential, consider disabling it or – if possible – uninstalling that component completely, which can often be done through the installation wizard (if the app uses one). Use non-default program folders to fool exploits that go looking for default installation locations. Close network ports unless required and for applications that use random ports, try to statically define these ports and adjust your firewall and security policies accordingly.

Another good tip is to engage in vulnerability scanning using any of a number of commercial (or even open source) tools like Nessus, Nexpose, OpenVAS, SAINT, and so on. These will often locate vulnerable services that can be considered.

There is also patching your applications and enabling logging and auditing, but I’ll cover these separately.

Any pitfalls?

Many, because unless you harden your applications correctly, you may be effectively committing a denial-of-service attack against yourself. Some applications may just need “insecure” services or settings which will have to be accepted, but can be guarded using a defence-in-depth strategy. Ensure that your approach allows for functionality as well as security because the most amazing applications are pointless if we can’t use them due to security settings. Asking the right questions to the right people, testing, and change management is crucial.

The ghost in the machine?

Shadow IT seems to creep into our systems using grey applications, which are neither explicitly approved or denied for their use in the infrastructure. These “unauthorised” programs can provide a quick and dirty workaround but unless secured, can present a bigger risk to your environment. Shadow IT exists often when users feel the tools they are given are inadequate or unduly restricted among many other reasons.

How do I make it work?

Once you have an inventory of applications, find out how to secure them using either vendor or industry best practices. Test these changes to understand what you can and cannot do and then run them through change management bearing in mind the benefits and any potential negative impacts. Office politics will always be present when dealing with issues of control, so management support and enforcement is a good idea. Once the logistics have been looked after, set about implementing the changes. Unless you can control the changes through large scale distribution (such as AD Group Policy) it can be a bit cumbersome. Putting all required hardening into a base image helps, followed by implementing the hardened applications through distributed software points, so the hardening is already embedded.

Am I missing anything?

It doesn’t hurt to look at network appliances that may be running default services that are not used or may be insecure. Network printers & multi-function devices, UPS systems, routers, switches, and more may be considered if one is undertaking a hardening exercise. FTP, SNMP, HTTP, TELNET and more are often running on these devices and may present a risk

Don’t overlook patching your applications and enabling relevant logging and auditing.

How do I start?

As with most things, begin with a current state inventory to understand what you have. Understand how best to secure these applications (and other devices if you wish) and create a plan to address these issues. Perform proper testing and QA and ensure that proper change control is followed. Management support is important so it is seen as not just an IT approach, but a business approach. Work your way methodically through the systems with a goal of allowing secure functionality of your applications. Regular reviews, such as after major upgrades or staffing changes, are also recommended.

Like a good spring cleaning, get rid of anything you don’t absolutely need!

Read more from the ASD Essential Eight Explained series.

Go to: Part 1: Application Whitelisting | Part 2: Patching Applications | Part 3: Restricting Administrative Privileges | Part 4: Patching Operating Systems | Part 5: Disabling Untrusted Microsoft Office Macros