ASD Essential Eight – Application Patching, an essential security process
Organisations struggling with cyber security and where to start can seek general guidance from the Australian Signals Directorate (ASD): specifically, a prioritised list of security controls known as the ASD Essential Eight. ASD claims that when implemented effectively, the Essential Eight mitigates 85% of targeted cyber-attacks. Application Patching sits within the preventative category of controls, yet organisations still struggle to implement a comprehensive patching regime. Let’s take a look at the complications of running an IT system that often lead to making bad patching decisions and explore a few ideas of how you can make improvements inside your own business.
Application Patching: Adversaries target vulnerabilities
Adversaries will continue to exploit vulnerabilities within our systems and applications, and there is one very good reason why: we let them. If this continues, attackers will continue to be successful in their criminal endeavours. The ASD places the utmost importance on patching these vulnerabilities since they report countless examples of adversaries using these entry points to access extra sensitive data, and to persist their remote access activities within their targets. The 2017 Verizon Data Breach Investigations Report suggests that once a security incident has progressed to a confirmed breach, personal information and credentials are most often harvested via web applications.
The Wannacry Lesson
WannaCry educated many on the importance of patch management and although it was an operating system vulnerability and relied on the appropriate patch not being installed, it demonstrated a shift in the timeframes we are used to. The amount of time between the patch’s release to address this known vulnerability and WannaCry’s release was significantly compressed. Microsoft released their patch in March and WannaCry hit the news in May. That’s just two months, which should now be considered the new norm.
This means that if application patches are not applied quickly, there is sufficient evidence to show that systems are at risk. Furthermore, the time available to complete your patching exercise is now under pressure, so security and infrastructure teams need to act fast.
The importance of risk assessment
One caveat that needs to be stated is that you need to complete a risk assessment before rushing out to patch everything. If, for example, the system in question is a medical allergies database, recording where patients have a lethal anaphylactic shock reaction when exposed to certain irritants, patching that at the wrong time could put patients at risk. This is an extreme example, but one to illustrate the severity of loss of some services, so prioritising this one over others in terms of patching is recommended.
Application Patching: What is it?
Application patching is the systematic implementation of security updates and fixes to the applications within your environment. These include commercial applications, such as Adobe Acrobat Reader, or custom in-house applications developed for a specific business purpose.
Tailor your patching to suit the environment
Your approach to patching can vary, depending on the nature of the application. Broadly speaking, applications with one or more of the following attributes prove difficult to continually update, so need careful planning and testing:
- Large geographical deployment;
- Heavily specialised application;
- Critical up-time requirements;
- Incredibly sensitive information.
The deployment window needs to be agreed by all stakeholders, and any outages need to be firmly approved before users lose functionality. Oftentimes, technical staff are asked to be available to support the patching team, should something go wrong, so scheduling needs to consider all people aspects too.
Even a small investment in planning will pay dividends when implementing and maturing your patch management process, so start with the plan and most issues will be eradicated.
Application Patching: Kickstart your regimen
The allergy database example has one or more of the attributes that complicate the patching process. Surgeons use this application to confirm whether someone has an allergy to anaesthetic drugs prior to surgery. If the service goes down at the wrong time, or if information is accidently altered through corruption, the impact could be disastrous. For this reason, the business often takes the ‘risk free’ option of not patching at all. However, security teams should state their case that the impact of a compromise could be much, much worse.
How to manage outliers
It is the outliers, the business-critical applications that must never go offline, that skew the business’s approach to patching. Success depends on the ability to leverage your business relationships and influence appropriate outcomes. The following steps assist in overcoming the blockers you’ll face when proposing a more mature application patching regime:
- Identify and categorise applications – the first step is to understand the nature of the applications within your environment. The Standard Operating Environment (SOE) team is often your best source of the truth when it comes to expertise in managing applications. Alternatively, check your Configuration Management Database (CMDB) as it should have all the supporting information you need to help you understand the application’s criticality. Lastly, you can talk to users and procurement teams to understand the importance of the service the application provides.
- Identify application owners – These are the key stakeholders within the process, who you should develop trust and build relationships with as you seek approval. However, if the outcome of the previous step is an unwieldy list, be mindful that approvals will eventually be required, so it may be necessary to organise delegated authority to a handful of key decision makers. Always seek to develop trust and build relationships.
- Consensus – Educate stakeholders and engender a universal understanding between application owners, risk managers, functional managers and users of the process, demonstrating that patching is not optional.
- Formally agree the patching window – The inability to negotiate an appropriate deployment window is often the primary reason why applications don’t get patched. It may be necessary to hold a workshop to reach an agreement. Avoid using standard change windows for this activity, as it increases the opportunity for objections due to other business imperatives.
- Socialise the outcomes – Once agreed, create a schedule of patching windows across a rolling monthly and yearly basis. This garners support across the business and provides the ability for other technical teams to plan around this activity.
- Baseline the applications – Utilising the list of applications from step 1, understand the versions of everything installed and what the target version is. This determines the extent of the work required to complete the upgrade.
- Raise changes with service management – Effective planning saves time. Raise the change with your service desk, giving enough notice to plan communications and draw attention to your schedules.
- Pilot deployment – Test patch deployment in a development (dev) environment prior to rolling out to production systems. If you don’t have a dev environment, roll the patches out to a small pilot group before you attempt general release.
- User Acceptance Testing (UAT) – Work with application owners and assign someone to do regression testing. Ensure tests are documented for predictable and repeatable outcomes.
- Detail and socialise the process and seek feedback – This step ensures stakeholders understand the process. It builds strong bonds and limits the opportunities for reprisal if something goes wrong.
- Improve and automate – If the patching process can be demonstrated as low risk, then make it less bureaucratic. Understand what tools can perform these activities and seek funding.
Application Patching: Practice makes perfect
If applications aren’t patched, organisations remain vulnerable. However, patching applications with undue care can have catastrophic consequences. While the latter is bad, organisations remain paralysed by the rigour required to assess a patch’s impact, and unfortunately go without because it’s easier. The reality of the situation is that there may be challenges to mature your application patching process, yet the more the process is practiced the easier it becomes. These 11 steps provide a framework for navigating the challenges of application patching, helping you comply with another of ASD’s Essential Eight. Taking the easy option won’t protect you when the next version of WannaCry infects your business, so get your patching regime off the ground and keep your users and business safe.