Essential info on the “Essential 8”

A few days ago the Australian Signals Directorate released the new version of their document Strategies to Mitigate Cyber Security Incidents. This is the third version of this excellent guide and there are a number of obvious changes from the previous version in 2014. This year (unlike the 2014 release) ASD have chosen not to provide a summary of the key changes, so I did a quick side-by-side comparison. This post summarises the changes.

The obvious changes

There are three significant changes that have been made to this version of the document:

  1. The Top 4 is still around (and mostly the same), but now we also have the Essential 8
  2. The previous “Top 35” list of strategies is now grouped into strategies for: prevention of malware delivery and execution, limiting the extent of cyber security incidents, detecting cyber security incidents, recovering data and system availability, and preventing malicious insiders.
  3. The title has changed. The 2014 release was titled “Strategies to Mitigate Targeted Cyber Intrusions” – the new version is “Strategies to Mitigate Cyber Security Incidents”

My take on these high level changes is that the ASD seems to be aiming for the guidelines to be more widely applicable. Instead of just talking about targeted attacks, the advice is now more relevant to a wider range of cyber security incidents.
With a more cynical hat on, perhaps they are also coming to accept that no amount of guidance is going to be truly effective in preventing a targeted cyber intrusion from a well-resourced adversary.

What’s gone

The following items from the Top 35 list no longer seem to be present:

  • 19 – Web domain whitelisting for all domains
  • 32 – Block attempts to access websites by their IP address
  • 34 – Gateway blacklisting

These seem to be fair exclusions. Web domain whitelisting is a nice idea in theory, but invasive and difficult to maintain. Blocking attempts to access websites by IP address never really seemed like it would make much difference – getting a DNS record for a C&C server is hardly a difficult task.

What’s changed

The following strategies have been significantly changed, updated or merged:

  • The previous guidance / intent of “Workstation inspection of Microsoft Office files” (29) has been transformed into a new (better) strategy for protecting against malicious Office files – “Configure Microsoft Office macro settings”
  • The previous guidance for “Workstation and server configuration management” (21) has been given a more general heading of “Operating system hardening”. This new strategy also incorporates previous guidance for “Restrict access to Server Message Block (SMB) and NetBIOS” (27).
  • “Enforce a strong passphrase policy” (25) is now incorporated into a much broader “Protect authentication credentials”.
  • The verbosely-titled strategies “Centralised and time-synchronised logging of successful and failed computer events” (15) and “Centralised and time-synchronised logging of allowed and blocked network activity” (16) have been rolled up into “Continuous incident detection and response”
  • Elements of “Centralised and time-synchronised logging of successful and failed computer events” (15) have also made their way into the new strategy for “Endpoint detection and response software”.

These updates, changes and merges all seem to make a lot of sense. Personally, I would have taken this even further – I think there are more opportunities to reduce the overall number of strategies by rolling-up similar or related guidance. For example, in the strategies to prevent malware delivery and execution section we have “User application hardening” and “Configure Microsoft Office macro settings” – I would argue that the latter is a subset of the former.

What’s new

Perhaps the most interesting aspect of this year’s version of the document are the new entries to the list:

  • “Hunt to discover incidents” (Mitigation strategies to prevent malware delivery and execution). This is an excellent recommendation, and it is almost baffling that this wasn’t explicitly required in previous years.
  • “Personnel management” (Mitigation strategy specific to preventing malicious insiders)

And the following three new entries under “Mitigation strategies to recover data and system availability”:

  • “Daily backups”
  • “Business continuity and disaster recovery plans”
  • “System recovery capabilities”

These last three really underline ASD’s apparent change in thinking for this year’s release – instead of just being about ‘keeping the bad guys out’, this new guide better aligns to a ‘Prevent – Detect – Respond – Recover’ incident response approach.

Closing thoughts

  1. It is great that ASD produce this guide and make it publicly available. I believe that the guidance is sound and mostly I would agree with the assigned ratings for effectiveness, impact, cost, etc.
  2. I am not a huge fan of the new groupings for the strategies. I think that this may be confusing for casual readers and non-industry types. I am concerned that a customer might work their way down the “prevent” list from top to bottom, while completely ignoring the essential strategies from “limit” and “detect”. It would be nice for ASD to release the recommendations in a format that facilitated sorting by different attributes.
  3. It is good to see the guidance updated in a way that addresses changes to the threat landscape, changes to current attack patterns, changes to defensive technologies (and technology capabilities).

Symantec Endpoint Protection: Setup.exe extruder

What do you do when you need to create around 40 Symantec Endpoint Protection packages?!

I’m way too impatient to do it manually, and after automating the sylink creation (see previous post), I got the idea of automating the setup.exe creation.

Ok, first thing you will need to do is setup your sylink files: instructions here

You will need 7-zip on your SEPM, this allows us to update the contents of the zip archive.

Export a setup msi directory from your SEPM, do not create a single exe file.
Once you have done this, zip up the output into a regular zip file call, this will be your $setup_src

Running the Script:
1) put all of your sylink files into a directory structure like this:


2) create a domains.txt file in the Sylink/ directory:


3) create a groups.txt (or use your previous groups.txt from the sylink creation) and put one in each domain directory (ie: Sylink/domain1/groups.txt). The groups.txt has a list of each group:


4) find the makesfx.exe: it is on the SEPM, in your SEPM install path: /Symantec Endpoint Protection Manager/tomcat/bin, and copy it to a convenient location. You will point the script variable $MakeSFX to it.

5) edit the script variables, make sure the paths point to the right places. Note for $bits and $type, I manually update these depending if im exporting 32 or 64 bit packages and Server or Desktop packages (depending on the SEP features in the package)

$update = @"
C:\"Program Files"\7-Zip\7z.exe u
$delete = @"
C:\"Program Files"\7-Zip\7z.exe d
$MakeSFX = "D:\temp\MakeSFX.exe"
$setup_src = "D:\temp\"
$setup_dst = "D:\Program Files\Symantec\SEP Agents\bulk\"
$sylink_dir = "D:\Program Files\Symantec\SEP Agents\Sylink\"
$domains_txt = $sylink_dir + "domains.txt"
$bits = "_x32"
$type = "_Desktop"

6) run the script and marvel at how much faster you can extrude out (think sausage factory ūüôā ) setup files!

You can pull the scripts from Asterisk Labs Github repository

Im pretty sure I have hit the Win inflection on this chart:
Geeks and repetitive tasks

Actually, this script generated about 40 setup exe’s for me in 20 minutes. If it takes about 5 minutes to export a setup.exe from the SEP console, Im certain I’m in front, even with script setup time, and definately with reduction in Repetitive Click Boredom.

Symantec Endpoint Protection: Sylink.xml hacking to automate SEPM migration

I have completed a couple of projects recently migrating customers from Symantec Endpoint Protection v11.0 to v12.1, including moving to a new SEP Manager. In these projects, the decision was made to do a fresh install of the SEPM, and move the clients into the new manager, without using replication between the old and new SEPM.

The file on the SEP v11 client called Sylink.xml tells the client which server to connect to, what the server certificate is and which group the client should join on the SEPM (among other things).

There is a tool on the SEP media part 2 in Tools\SylinkDrop.exe which can be used to swap the Sylink.xml file on the SEP client.

During these projects I was looking for a way to simplify the creation of the sylink.xml file, the projects both involved a large number of client groups РI didnt really want to manually export the communication settings for over 30 groups!

This lead me on a powershell path of discovery, and the realisation that powershell could load an xml file as a data object, manipulate it, and then write it out! This was exactly what I needed.

The process I used to generate the sylink files was:
– Create the group structure in the SEPM
– Create a groups.txt file: this file had a list of SEP client groups per line
– export a sylink.xml file from the destination SEPM: for example, download the communication settings file from the “My Company” top
level group.
– run the update_sylink.ps1 powershell script
– deploy the sylink files to the SEP agents with SylinkDrop.exe

The groups.txt file contained lines like:

My Company\Desktops
My Company\Desktops\WA
My Company\Desktops\NSW
My Company\Desktops\NT
My Company\Desktops\QLD
My Company\Desktops\SA
My Company\Desktops\TAS
My Company\Desktops\VIC

Note that SEP is case sensitive – the groups.txt file must match the group names in the SEPM.

When you export the sylink.xml, you will end up with a file that looks like:

<?xml version="1.0" encoding="UTF-8"?><ServerSettings DomainId="BC7791940DEADBEEF3A86829"><CommConf><AgentCommunicationSetting AlwaysConnect="1" CommunicationMode="PULL" DisableDownloadProfile="0" Kcs="18F84DEADBEEF2CF46D" PullHeartbeatSeconds="1800" PushHeartbeatSeconds="300" UploadCmdStateHeartbeatSeconds="300" UploadLearnedApp="0" UploadLogHeartbeatSeconds="300" UploadOpStateHeartbeatSeconds="300"/> <LogSetting MaxLogRecords="100" SendingLogAllowed="1" UploadProcessLog="1" UploadRawLog="1" UploadSecurityLog="1" UploadSystemLog="1" UploadTrafficLog="1"/>
<RegisterClient PreferredGroup="My Company\Workstations (location based)" PreferredMode="1"/> <ServerList FreezeSmsList="0" Name="Default Management Server List"> <ServerPriorityBlock Name="List0"> <Server Address="" HttpPort="8014" VerifySignatures="1"/> <Server Address="SEPM"
HttpPort="8014" VerifySignatures="1"/> <Server Address="SEPM" HttpPort="8014" VerifySignatures="1"/> </ServerPriorityBlock> </ServerList> <ServerCertList>

<Certificate Name="SEPM">MIICujCCAiOgAwIBAgIQhjuQQqXvBWWzipD7elI3oTANBgkqhkiG9w0BAQUFADB3MXUwCQYDVQQI&#xd;


vUN+ypsPydoiLKd7uMsNWaFGzP4JKJjiJsrhGi3l1pLlR553GxZz2UZ1zbX7knjjiReVLrniIyYd&#xd; CPFkI/DEADBEEF+fnUbxr259h</Certificate>



The powershell script can actually update any token in the xml file, we are just using it to update the PreferredGroup item:

$xml_orig = New-Object XML

$grps = get-content groups.txt
ForEach ($i in $grps) {
$PreferredGroup = $i.toString()
$xml_new = New-Object XML
$xml_new = $xml_orig

$xml_new.ServerSettings.CommConf.RegisterClient.PreferredGroup = $PreferredGroup

$j = $i.Replace("\", "_")
$filename = $j.Replace(" ", "_")
$xml_new.Save($filename + "_Sylink.xml")
remove-variable xml_new

The script needs the groups.txt and sylink.xml to be in its currect directory.
The sylink files will be output to the currect directory, with the group name preceding, eg: My_Company_Desktops_WA_Sylink.xml.
All that is left is to run SylinkDrop -s “target sylink.xml” on the agents to repoint them to the new SEPM. I have used both Symantec¬†Management Platform (Altiris) to do this, and AD group policy.

You can pull the scripts from Asterisk Labs Github repository

I have used this script to save a lot of time generating sylink files for migrations. This also gave me an idea for automating the creation of a large number of setup.exe files for SEP deployments: Stay tuned for more on that!