Notifiable Data Breach Scheme

What is it?

The Notifiable Data Breach (NDB) Scheme is an amendment to the Privacy Act 1988 that comes into effect from 22 February 2018. The NDB scheme sets out the obligations of organisations to notify individuals after a data breach has disclosed their personal information and that disclosure is likely to cause serious harm to the individual. Notification of the breach must also be provided to the Office of the Australian Information Commissioner (OAIC).

Who does it apply to?

The scheme applies to all entities that are currently subject to the Privacy Act – as a general rule, this includes all Australian government, business or not-for-profit organisations with an annual turnover of $3 million or more.

What needs to be addressed?

To ensure that applicable organisations are able to respond appropriately in the event of a breach, the following needs to be addressed:

• The ability to identify and respond to security incidents in a timely manner;
• Implement processes to assess if a breach is likely to cause serious harm to individuals;
• Develop a communication plan for notifying relevant parties;
• Ensure your notifications meet minimum requirements as defined by the OAIC;
• Implement remediation activities to avoid the incident reoccurring in the future.

How to notify?

When an organisation suspects or has confirmed that a data breach has occurred, it will need to promptly notify individuals that are likely at risk of serious harm. The Commissioner must also be notified as soon as practicable with a statement outlining the data breach.

Notifications must include the following information:

• The identity and contact details of the organisation;
• A description of the data breach;
• What personal information has been breached;
• Steps that individuals should take in response to the data breach.

How to comply?

General guidance is provided by the OAIC and can be found here: https://oaic.gov.au/privacy-law/privacy-act/notifiable-data-breaches-scheme

If you need assistance with meeting your notification obligations, Asterisk can assist with implementing incident detection and response procedures and communications plans to ensure your organisation is ready to take action should a breach occur.*

* If you have not yet sought legal advice on your organisation’s exact eligibility and obligations under the Privacy Act, Asterisk recommends consulting an appropriate legal professional to ensure all legal requirements have been considered.

The End is Nigh?

We are not usually in the business of making bold predictions about future developments in cyber security. But recent internal discussions about WannaCry and Petya/Nyetya have got us all thinking about an entirely plausible and frankly terrifying possibility for where crypto malware could go next.

Here’s the short version:
DeathStar + basic crypto malware variant = complete encryption of the entire AD environment.

DeathStar is an extension to the Empire post-exploitation framework that was released by byt3bl33d3r in May 2017. It builds on previous tools like BloodHound to identify and automate privilege escalation within Active Directory. Basically, “push button, receive domain admin”.

DeathStar (and BloodHound) don’t rely on exploiting any actual vulnerabilities. Rather DeathStar leverages Active Directory configuration and allocation of privilege in order to find and exploit a path of domain joined systems that can be travelled, one hop at a time, in order to eventually obtain DA privileges. The BloodHound github page probably explains this approach most succinctly:
“BloodHound uses graph theory to reveal hidden relationships and attack paths in an Active Directory environment.”

Our predicted scenario plays out something like this:
1. Despite your organisation’s best efforts with security education and awareness, a low privileged user opens a malicious executable email attachment.
2. The attachment first runs DeathStar, which eventually obtains domain admin privileges.
3. Once DA has been obtained, the payload reaches out to every domain-joined Windows system and executes a crypto malware payload, as DA, on every host simultaneously.

Taking this one step further…
Couple this attack with a basic password spraying attack against Remote Desktop Services or Citrix  (or even OWA followed up with Ruler) and you remove the need for any phishing or other user interaction. One minute you’re fine – the next minute every machine on your AD has crypto malware.

So what can be done?

  1. Excellent, frequent, offline and offsite backups. Definitely NOT on local, online, domain-joined backup servers.
  2. Proactively test your Active Directory with tools like Bloodhound and DeathStar. If you can prevent these tools from achieving DA through derivative administrator relationships, chances are good that the predicted malware won’t be able to either.
  3. Use cloud-based / SaaS services where possible.
  4. Follow ‘best practice’ advice like the Top 35 / Essential 8 provided by ASD. Specifically: patch OS and applications, implement application whitelisting, use 2FA for all remote access (including OWA), limit the allocation of administrative rights, and monitor the shit out of your environment.

If this prediction eventuates it could have staggering consequences for individual organisations and possibly for the global economy. We don’t want this to happen, but it just seems like the next logical step in the evolution of crypto malware. Hopefully by highlighting the possibility we can get ahead of the curve before the risk is realised.

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

Bash bug will leave you shell shocked.

A vulnerability has been found in the Bash Unix shell. The vulnerability arises from a bug in the way that Bash processes environment variables. If an attacker is able to pass environment variable content to a network service that calls bash, they may be able to achieve arbitrary remote code execution on the target system.

This has potentially severe implications for any network service that runs bash as an interpreter.

  • CGI scripts on web servers can be leveraged to achieve remote code execution through HTTP requests.
  • Systems running SSH may also be vulnerable. By leveraging AcceptEnv, TERM or SSH_ORIGINAL_COMMAND environment variables, remote code execution may be achieved on affected systems.
  • Other network services may also be impacted (e.g. SMTP servers)

This has widespread severe security implications, as potentially any Linux/Unix system can be compromised remotely.

WHAT CAN YOU DO:

  • Upgrade bash on all Linux/Unix systems immediately
  • Temporarily firewall any Internet-facing SSH servers or web servers running shell-based CGI scripts until the bash patch can be applied.
  • For appliances, software appliances and embedded systems, contact the vendor to seek advice about patching.
  • Cry softly into your pillow
  • Run away from your job
  • Hit the pub.

More to follow…

TrueCrypt Fallout: Early hours

It may appear that 2014 is shaping up as ‘Year of the Crypto Catastrophe’. Closely following Heartbleed we are now monitoring the unfolding and curious events surrounding the sudden shutdown of the TrueCrypt project.

TrueCrypt (or TC) has long been a ‘go to’ open source encryption solution to provide a quick solution for protecting data.

Whilst details are very sketchy, it would appear that the TC binaries have been updated to only allow reading from TC volumes, with a warning that TC is no longer safe.

Asterisk’s recommendations at this point are:

  • Do not download or update TC right now! (version 7.1a seems to be the most recent version released before the current incident)
  • Determine your organisation’s current exposure: assess usage of TC, search for any TC volumes in your fleet (note that TC volumes can be hidden)
  • Take steps to ensure any data secured by TC is backed up in a manner which ensures you can recover the contents
  • Assess your data encryption requirements: why are you using crypto, what are you protecting data from (casual observer, laptop/drive theft, targeted information theft), what platforms & what functionality is required?
  • Assess alternate solutions, and prepare a strategy to move
  • Determine the appropriate trigger and time frame for your organisation to change encryption solution

Until more concrete facts emerge, we have captured some of the timeline of this very intriguing story as it unfolded.

Approximately 5 hours ago (3:30am West Australian Time) this tweet landed:

https://twitter.com/FredericJacobs/status/471735604883890176

thegrugq then provides an archive of the page:

https://twitter.com/thegrugq/status/471741930271809536

Some information about the new binary that is available on the TC website lands:

https://twitter.com/runasand/status/471741572909133824

Speculation about what’s going on starts to happen:

https://twitter.com/matthew_d_green/status/471741836722073600

and investigation around what actually got uploaded starts:

https://twitter.com/cynicalsecurity/status/471742274742013952

The investigation continues:

https://twitter.com/DefuseSec/status/471742363212083200

Another diff:

https://twitter.com/cynicalsecurity/status/471743401361436674

Confirmation that the new binaries were signed by the real PGP key:

https://twitter.com/hdmoore/status/471744014069145600

https://twitter.com/hdmoore/status/471744014069145600

What happens when you try to install the new TC:

truecrypt-9-runasand-2

https://twitter.com/runasand/status/471744625690951681

xabean links to github to better highlight the changes:

https://twitter.com/xabean/status/471746558703448064

Archer has some great advice:

https://twitter.com/ArchrOnSecurity/status/471751244609257472

News articles begin:

http://www.pcworld.com/article/2241300/truecrypt-now-encouraging-users-to-use-microsofts-bitlocker.html

Confirmation on the new functionality:

https://twitter.com/runasand/status/471771828130963456

Luckily, thegrugq already gave us information about TC alternatives:

http://grugq.tumblr.com/post/60464139008/alternative-truecrypt-implementations

https://twitter.com/McGrewSecurity/status/471789973398507522

and now the speculation has started:

https://gist.github.com/ValdikSS/c13a82ca4a2d8b7e87ff

With an interesting  line in the new 7.2 code pointed out by a guy on IRC:

https://github.com/warewolf/truecrypt/compare/master…7.2#diff-889688bf127e7a198f80cbcec61c9571L16

Now, this is still early days, so we’re expecting this news to change as more information starts to surface.

 

UPDATE:

KrebsonSecurity did an interview with Matthew Green (the guy who is heading the audit project for TrueCrypt) and had some additional information.  He still plans to continue the audit.

http://krebsonsecurity.com/2014/05/true-goodbye-using-truecrypt-is-not-secure/

UPDATE 2:

And looks like this is the best explanation we are going to have around the TrueCrypt situation:

https://twitter.com/stevebarnhart/status/472192457145597952

https://twitter.com/matthew_d_green/status/472193658842673152

https://twitter.com/stevebarnhart/status/472193800874758144

https://twitter.com/matthew_d_green/status/472194641136087040

https://twitter.com/stevebarnhart/status/472195239005147136

https://twitter.com/matthew_d_green/status/472198235679764481

https://twitter.com/stevebarnhart/status/472198615579234304

https://twitter.com/matthew_d_green/status/472198897058590721

https://twitter.com/stevebarnhart/status/472200184433483776

https://twitter.com/stevebarnhart/status/472200478345150464