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).

Devise Google Authenticator 0.3.3

A couple of weeks back, whilst working on some building some internal management apps, I finally got around to implementing the Devise Google Authenticator gem into a rails app outside of its own testing app. During this process I realised that I hadn’t correctly updated some of the extension’s code to properly work with the Devise 2.0 release, in particular the changes to the migration schema. A few amendments, a push or two and version 0.3.3 was now available.

Looking back over the process I’ve certainly learned a lot about Ruby, Rails and Devise, plus the whole Ruby Gems eco-system. What’s surprising though, is the number of people out there who appear to be using the gem. At a high level the breakdown is as follows:

So far though, we’ve only had a few queries come in. But, to try and capture them in a more appropriate place I’ve started a Google Groups which, if you wish, you can sign up to and post queries. Or, if it’s easier, just hit us up on twitter: @xntrik or @asteriskinfosec.

Cheers!

Integrating Google’s 2nd Factor Authentication with your Rails App

Asterisk is happy to announce the release of their first (beta) Ruby Gem. The “devise_google_authenticator” gem is a Devise Extension that integrates Google’s 2nd Factor Authenticator into Devise’s authentication scheme. It’s not designed to replace the existing password scheme (database_authenticatable), but it’s ideal to provide a second factor authentication mechanism from your smart phone (Android, Blackberry, iOS).

If you are doing any Rails development and have a need for user authentication/authorisation then you should certainly be checking out Devise. From their site:

Devise is a flexible authentication solution for Rails based on Warden. It:

  • Is Rack based;
  • Is a complete MVC solution based on Rails engines;
  • Allows you to have multiple roles (or models/scopes) signed in at the same time;
  • Is based on a modularity concept: use just what you really need.

Lets put together a really simple application.. (I’m assuming you have Ruby 1.9.2, but no other gems available. Also, most of this is following the Rails Guide and the Devise installation process)

Install rails:
$ gem install rails -v 3.2.0 –no-rdoc –no-ri

Create your vanilla app:
$ rails new myapp

Change into your new app:
$ cd myapp

Edit your Gemfile with the following two lines (after gem ‘sqlite3’):
gem ‘devise’, ‘~> 1.5.3’
gem ‘devise_google_authenticator’, ‘0.3.1’

Update your bundle:
$ bundle install

Create some data for your app
$ rails generate scaffold post title body:text

Install Devise:
$ rails generate devise:install

Install Devise Google Authenticator:
$ rails generate devise_google_authenticator:install

Create your user model:
$ rails generate devise User

Add the Devise Google Authenticator scheme:
$ rails generate devise_google_authenticator User

Migrate your database changes:
$ rake db:migrate

Remove the static index page:
$ rm public/index.html

Change the root page (edit your config/routes.rb and add the following below resource :posts):
root :to => ‘posts#index’

Edit your main application controller to require user authentication for all pages (edit app/controllers/application_controller.rb add just after protect_from_forgery) with the following:
before_filter :authenticate_user!

Now start up your app and visit localhost:3000:
$ rails server

After you register your user (after clicking Sign Up), you should be displayed with a QR Code. Simply add this to your Google Authenticator app on your phone, enable the authenticator, close down your browser (to clear your session), revisit the website and after you sign in, you’ll be prompted for your one time password.

Voila!