Achieving the Australian Essential 8 Using Nucleus

The Essential 8 model uses a slightly different method of prioritization than traditional prioritization based on vulnerability severity. It also calls for an aggressive approach to scanning and regular patching on frequent intervals. Nucleus is purpose-built for this level of rigor at scale. 

Scanning 

The ASD Essential 8 calls for scanning at approximately two times the rate of your patching interval. This means scanning your external systems daily and scanning your internal systems every two weeks. Scanning twice as frequently as you update allows you to capture a before and after state while measuring progress in between. 

Nucleus supports the aggressive scanning requirements defined by the ASD Essential 8.

Scan health and frequency: the Nucleus asset management module includes a thermometer across the top of the user interface showing scan health status as red, yellow, or green. 

• Red: systems that Nucleus has discovered in your asset inventory either through system scans or other evidence in your network, but Nucleus has not ever ingested scan data for that system. Should be investigated and confirmed as active or removed. 

• Yellow: systems that were scanned and active in Nucleus 90+ day ago but have not been seen in the past 90 days. Should be verified to confirm they are still live or removed. 
• Green; systems seen regularly in Nucleus. 

Scan Fail notifications: Nucleus has a facility to notify users when scan imports fail. Nucleus can import scans on a set schedule, and scans failing to import both serve as a useful check that scans are indeed occurring on a regular basis, and alert users when a scan fails. 

Asset removal automation based on metadata

Using asset processing rules, Nucleus can remove assets automatically as you decommission them. If your inventory system has a flag in its metadata stating whether a system is live, Nucleus can trigger off that metadata element.  

Asset removal rules run automatically after each scan completes.  

If your asset management tool does not have such a facility, Nucleus can remove assets based on your criteria, such as the length of time or duration an asset is absent from scans, or the number of scans where the asset is missed or not seen. 

• Asset removal vs archival: Nucleus gives you the option of completely removing the asset or archiving it, which preserves the systems’ full history so that in the future you can re-activitate the system with its full history intact. 

Implementing policies with processing and ticketing rules 

With your scanning integrations in Nucleus, you can set up rules to define due dates. Nucleus automation rules run in top to bottom order( like firewall rules), so you will want to create your rules in the same order as your due dates, with your most aggressive due dates at the top, and a catch-all rule at the end. Processing rules run after every scan import. 

Patching applications, operating systems, and Internet facing services 

Rather than using traditional severity, the ASD Essential 8 sets due dates based on exposure and types of software. This approach requires a software inventory which Nucleus produces from your scan data. The Nucleus software inventory is in the asset management module, under the link installed software. 

• From your software inventory, you can produce a list of keywords to use to define rules to set due dates and open tickets. 
• You can view the software list directly in the UI, and you can also export it in CSV or Microsoft Excel format.  
• The export is useful for building lists that you can use in the rules that set due dates, since they will be based on keywords specific to your software inventory. 

• Using that inventory, VM professionals can then build lists for each software category to use in automation rules for setting due dates.  

Patching internet-facing services 

Nucleus automatically sets an attribute on every system based on its IP address. Anything with an IP address outside the RFC 1918 ranges get an attribute set called public facing. Every Nucleus processing rule and ticketing rule can take a set of asset-related and finding-related attributes. If the asset is public facing and the finding title matches a regular expression containing keywords describing your Internet facing services—think Apache, Nginx, IIS, PHP, Exchange —you can set a due date of 48 hours from the discovery date if an exploit exists, or 14 days if no exploit exists. 

Your scanner may or may not pass exploitability data. However, Nucleus enriches every finding with two different flags that could be used for setting exploitability:  

• Nucleus provides threat intelligence from Mandiant that includes information on a vulnerability’s exploitability.  

• Nucleus also sets an attribute stating whether the vulnerability is on the CISA KEV, a list of known exploitable vulnerabilities maintained by CISA, a division of the United States Department of Homeland Security. Your rule can key off the exploitability field, the CISA BOD (KEV) field, or the Mandiant Exploit in Wild field. 
• You can accomplish this with as few as four rules, although the number of ticketing rules you need will depend on how many potential assignees you have. Nucleus integrates with several leading ticketing systems, including JIRA and ServiceNow, and if you have more than one ticketing system, that’s not a problem. When you create each ticketing rule, simply choose the appropriate ticketing system for the appropriate team. 
• Tracking due dates in Nucleus is easy. The project dashboard contains a chart called SLA Metrics that stacks findings based on due date. Findings in the red bar are past due, findings in the green bar are not yet due, and any findings with no due date assigned show up in a gray bar. 

Patching common applications 

Patching applications on user workstations uses a similar methodology. In this instance, you set the public facing attribute to false, pass a set of keywords for applications like office suites, web browsers, and PDF tools, and set the due date appropriate for your target level of maturity: 

• For Level 1, use a due date of 30 days.  
• For level 2, use a due date of 14 days. 
• For Level 3, use a due date of two days if the vulnerability is exploitable, and 14 days otherwise. 

Patching operating systems 

The question of “what is an application?” and “what is part of an operating system?” can be difficult, but ordering the operating system after applications makes handling the question a bit easier. You can always come back and adjust the rules if something slips through.  

After running applications through, you can use keywords like Microsoft Windows to catch Windows updates and RHSA to catch updates for Red Hat Enterprise Linux, for example. Set a due date that is appropriate for your target level of maturity: 

• For Level 1, use a due date of 30 days.  
• For level 2, use a due date of 14 days.  
• For Level 3, use a due date of two days if the vulnerability is exploitable, and 14 days otherwise. 

The rules for setting due dates are pretty easy. The ticket assignments may be more difficult, depending on whether you have one team updating everything, or if applications go to one team and the operating system goes to a different team. You can build regular expressions containing keywords to filter out applications in your ticketing rules if that is the case. The key with the ticketing rule is setting the due date and the assignee. 

A catch-all rule 

After you set your other rules, set a catch all rule to set a due date on anything that slipped through the cracks. 

Just like a firewall, your initial set of rules probably won’t be perfect. But it will probably catch more than 90%, and then you can make adjustments to close the gap between 90 and 100%. Expecting perfection on your first go-round isn’t realistic, but 12 months of iterative improvement will show a dramatic increase in productivity and maturity growth against any maturity model, ASD or otherwise.  

If you don’t have much nuance in regards to patching responsibilities, you can probably begin with a small number of rules, 1-2 finding processing rules, and a ticketing rule to handle each of the following: 

• External, Internet-facing services 

• Common applications 
• All other applications and the operating system 

Removal of end-of-life software and operating systems 

The ASD mandates removing software and operating systems that breached end-of-life and are no longer receiving security updates. Many vulnerability scanners have findings related to software going end-of-life. In Nucleus, you can quickly find these searching your vulnerabilities for either the phrase “end of life” or EOL.  

• The scanner vendor usually recommends installing or upgrading to a supported version. You can pull up a vulnerability and edit the recommendation to make it company-specific.  

• You can click the pencil icon and replace the recommendation with information about the software’s approved replacement, making the data much more actionable for your remediation teams. Any edits you make to the recommendations persist and will not be overwritten by subsequent scans. 

Nucleus makes it easier 

The ASD approach takes a bit more work to implement than traditional approaches based on severity. However, traditional approaches don’t exactly have a good track record across the industry.  

• Implementing the ASD Essential 8 policy in Nucleus rules is no harder than categorizing from raw scan results, and the bulk of the work takes place up front.  
• You set up your rules once, and then fine tune them over the course of time, making iterative improvements. This approach accommodates both changes to your environment or the odd miscategorization. Anytime you adjust a due date, Nucleus will keep your adjustment in place and will not overwrite it. 

Although this is an aggressive timeline, it is entirely possible to get Nucleus integrated with your vulnerability scanner and your ticketing solution, plus write the rules that you need to build a remediation policy around the ASD Essential 8, in 30 to 45 days.  

We’ve helped our industry-leading customers prioritize, assign, and remediate over 3.5 billion vulnerabilities across their varied global organizations, as we are built for scale. Watch our demo to see how we can help you get started on your ASD Essential 8 journey.