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 

Tags: ACSC Essential Eight, Application Hardening, Cybersecurity, Network Security



Information protection in an age of information theft

Managing and safeguarding data across various apps, clouds, and endpoints is an uphill battle. It’s led to organisations relying on…

Customer Story: Knight Frank

Cloud Transition an Azure Success Story for Knight Frank Download Customer Story Contact a Specialist Objective…

3CX Desktop App Critical Vulnerability Alert

The Australian Cyber Security Centre has issued a warning about a new supply chain attack that has targeted a…

Managed Services eBook
Your guide to Data#3 Managed Services

Digital disruption is causing significant changes in the workplace, leading to higher expectations for access, security, and support regardless of…

JuiceIT Guest Blog | How XDR can help when time is of the essence

The only thing worse than cyber threats is an inability to detect those threats in time. Organisations need the…

JuiceIT Guest Blog | Veeam Platform: Reliable and Fast Recovery from Ransomware in a Hybrid World.

Ransomware attacks have become a growing concern for organisations of all sizes in Australia and New Zealand, resulting in significant…

Customer Story: Pernod Ricard Winemakers

Azure Migration gives Pernod Ricard Greater Flexibility and Improved Performance Download Customer Story Contact a Specialist…

Why would you deploy SASE?
If Secure Access Software Edge (SASE) with Cisco Meraki is the destination, what does the journey to get there look like?

Firstly, let’s set the scene. The term SASE was first mentioned by Gartner Analysts in July 2019 and Gartner continues…