Australia - Where Compliance and Regulation Obligations are Unlawful

The Australian Government's controversial encryption bill passed the Senate last month and will undoubtedly be law soon.

The bill proposes three key powers;

A technical assistance request (TAR): Police ask a company to "voluntarily" help, such as give technical details about the development of a new online service

A technical assistance notice (TAN): A company is required to give assistance. For example, if they can decrypt a specific communication, they must or face fines

A technical capability notice (TCN): The company must build a new function to help police get at a suspect's data, or face fines

Sound familiar?

The Clipper Chip

The Clipper Chip is a cryptographic device purportedly intended to protect private communications while at the same time permitting government agents to obtain the "keys" upon presentation of what has been vaguely characterized as "legal authorization."

In 1994, Matt Blaze published the paper Protocol Failure in the Escrowed Encryption Standard which explained that any back door to encryption is as good as a closed unlocked home front door.

We know this was impossible in 1994!
in 1994..

For many business entities in Australia there aren't too many Compliance and Regulation Obligations that must be met that are considered under law, the Privacy Act is the best example of obligations under law. However that said, there are certainly a lot of other Compliance and Regulation Obligations for you to consider if you want to avoid fines or other unpleasant outcomes in Australia.

Australian specific Compliance and Regulation Obligations

The following list is the obligations I personally encounter for my day job, it may be missing something that you're aware of, and is specifically in the lens of the Australian Government so excludes many other obligations that may apply to Australian business entities which are more broadly accepted outside of the Australian borders.

• The Australian Prudential Regulation Authority (APRA) CPG-234 Management of Security Risk in Information and Information Technology
• ACSC Publication Cloud Computing Security for Tenants
• Protective Security Policy Framework (PSPF)
• IRAP (Information Security Registered Assessors Program ) Assessment (document 5) version 0.04
• ACSC Australian Government Information Security Manual (ISM)
• Australasian Information Security Evaluation Program (AISEP)
• OAIC guidance

What a list

So let's go through each and why we should care.

APRA

In general terms this is the body that regulates banks, insurers, and companies that take fiat currency deposits, so as to protect consumers as the main goal. I emphasise consumers because we are mostly going to be looking at obligations where the concerned party is not the consumer, and APRA is a special case for this topic.

OAIC

The entity that is responsible for Privacy Act related matters and enforcements, notably the mandatory notifiable data breach law introduced (before GDPR) that makes it unlawful for organisations to keep data breaches to themselves in Australia.

ACSC

The ACSC is interesting in that there isn't anything in law specifically that it enforces, but rather it is responsible for many initiatives that help Agency organisation become more secure. The Agency reference carries with it special meaning in Australia, and to explain it properly would take up more then this whole post. In terms of secure we are making a distinction that we are not referring to privacy of Australians, or any concerns of the public at all, Agency security is in context of government interests alone.

IRAP

While not an obligation required by law, it is however a requirement for any business to interact technologically with the government, any of it's agencies, or in some cases if you operate in areas of public interest where some other regulatory body like APRA has not been established. For example the consultancy I currently work with are not considered to be in any of the above categories however we often work with our clients to achieve IRAP certification where we are the MSP, so we are in the scope of IRAP also.

Failing to meet IRAP requirements can make or break a business

ISM / PSPF / AISEP

Similar to IRAP these are not obligation required under law for the public sector, however an Agency is expected to meet the obligations for each. As described with ACSC, Agency security is in context of government interests alone.
The public sector is encouraged to align their business to the obligations set out for Agencies if they do not implement their own.

Baseline Security Posture is Encryption

With the mandatory notifiable data breach law, the expectation for all Australian businesses is to have a fairly high standard of Information Security, through the implementation of controls set out in many of the above as a preventative strategy.

Rendering data unreadable through cryptographic or hashing means in case of a data breach is by law the baseline, so why then is it also enforcible by law that an organisation must produce in plain text private or sensitive data via TAN or TCN from law enforcement?

The Requirements and Controls

IRAP

While controls are not uniquely IRAP, they are PSPF or ISM, some are Core Security Requirements (CSRs) that are interesting to note here;

• The SRMP must protect the personal and sensitive information of subscribers, authentication credentials including transaction histories,
  backed up and archived information. This wording contradicts all 3 enforcements of the new bill.
• The Applicant must immediately revoke digital certificates and associated keys that have been compromised. Are these enforcements a compromise to an individuals privacy or security?
• The Applicant should immediately suspend digital certificates and associated keys that are suspected by being compromised. Will the new data custodians respect an individuals privacy or security?

An official example of critical Non Compliance states;

The inappropriate storage of cryptographic keys, digital certificates, or
passphrases will be classified as a critical Non Compliance.

Though not prescriptive it does detail that any control that states must will result in critical Non Compliance if not met, meaning in practice an organisation cannot achieve IRAP certification unless they adhere to the controls around encryption stated above, in the PSPF and ISM below.

PSPF

Where encryption is defined in the PSPF a citation for information on cryptography, you're directed to the ISM. Some PSPF specific controls;

• PSPF43: use the encryption standards identified in the ISM for information transmitted over public network infrastructure. The encryption will sufficiently protect the information to allow it to be transmitted on an unclassified network. Basically apply the encryption standards identified in the ISM to protect information on their network infrastructure in unsecured areas.
• PSPF33: Do not allow information to be accessed merely because it would be convenient for personnel to know or because of their status, position, rank or level of authorised access. This is comically appropriate for the new bill, i literally couldn't make up a better control to conflict with the new bill.
• PSPF01: Ensure that personnel who access Australian Government resources are eligible to have access,have had their identity established, are suitable to have access, and agree to comply with the Government’s policies, standards, protocols and guidelines that safeguard resources from harm. This control ties directly with my recommendations for if/when you encounter a possible enforcement under the new bill.

ISM

The ISM has a section on Guidelines for using cryptography where it states;

An Australian Signals Directorate (ASD) Cryptographic Evaluation (ACE) requirements supplement this document and where conflicts occur take precedence.

Simply put, if you're subject to achieving ACE do so first then fulfill any outstanding requirements in the ISM.

Key ISM take aways;

• FIPS 140-x is the standard only when concerned with cryptographic modules (HACE) compliance to the ISM.
• Security Control: 0455; Revision: 2; You Must provide the means to derive the plaintext recovery of data from the ciphertext without the use of the data encryption key used.
• Security Control: 1162; Revision: 3; Must Use encryption in-transit when sensitive data is exchanged over untrusted networks
• ASD Approved Cryptographic Algorithms, apart from the expected DH / ECDH / RSA / AES / 3DES etc, include SHA-2 hashing! Security Control: 1054; Revision: 4;
• ASD Approved Cryptographic Protocols, apart from the expected WPA2 / TLS / SSH / IPsec, it also approves OpenPGP specifically as well as S/MIME (which when used on its own is a shock). Security Control: 0490; Revision: 3;
• Security Control: 0142; Revision: 2, Control: 0143; Revision: 7, and Control: 1091; Revision: 4; All discuss compromised keys and what you must do, but are keys considered compromised after being subject to a TAN or TCN?
• Security Control 0571; Where users send email from outside their network, an authenticated and encrypted channel must be configured to allow email to be sent via the centralised email gateway.
• Security Control 0486; Applicants that allow passphrase authentication must use techniques to block brute force attempts against the passphrase.

ASD ACE / AISEP

An ASD Cryptographic Evaluation test may include packet sniffing, black box testing, source code review, key management analysis, and Random Number Generation (RNG) evaluation.

Cryptographic evaluations conducted in other nations such as CAPS, FIPS-140, and CMVP are not a replacement for an ASD Cryptographic Evaluation for Australian government agencies.

Key take aways;

• ASD-approved cryptographic algorithms and ASD-approved cryptographic protocols defined in the ISM.
• Some products on the EPL do not have a consumer guide. They're not recommended for the use of cryptographic security or products that do not contain cryptographic security.
• An ASD-approved Protection Profile covers the necessary security functionality expected of the evaluated product and known security threats
• FPT_KST_EXT.2.1 from Protection Profile for Mobile Device. The TOE Security Functionality (TSF) shall not transmit any plaintext key material outside the security boundary of the target of evaluation (TOE). A TAN or TCN conflicts with this fundamentally.- FCS_CKM_EXT.4 Cryptographic Key Zeroization from Protection Profile for IPsec clients; requirements to ensure plaintext sensitive data such as key material and the plaintext secrets being protected have no known way to be recovered. This is of particular relevance in the context of TAN and TCN as it is in undisputed conflict.

APRA

Remember, APRA exists to protect the consumer.

Here are some interesting take aways from the CPG-234;

• APRA envisages that a regulated institution would select algorithms from the population of well established and proven international standards that have been subjected to rigorous public scrutiny and verification of effectiveness (e.g. Triple DES38, AES39 etc.). The length of a cryptographic key would typically be selected to render a brute force attacks impractical (i.e. would require an extremely long period of time to breach using current computing capabilities).
• segregation of duties, with no single individual having knowledge of the entire cryptographic key (i.e. two-person controls) or having access to all the components making up these keys.
• A regulated institution would typically utilise tamper resistant devices to store and generate cryptographic keys, generate PINs and perform encryption and decryption. In most cases this would involve the use of Hardware Security Modules (HSMs) or similarly secured devices. These devices would be appropriately secured both physically and logically.

Basically if any APRA regulated entity received a TCN it must find a deliberately insecure HSM, one that the rest of the world would never use and might only exist in fantasy, and don't forget that the TCN would essentially make the APRA regulated entity lose it's license for no other reason then it's inability to meet CPG-234 F.7.

ACSC

Honorable mention.
The ACSC release guidance in certain area where clarity is needed, a great example most organisations will be falimiar with is the Cloud Computing Security for Tenants guidance. This and most others will reference back to the ASD-approved cryptographic controls or ISM with few exceptions.
In the case of this CSP guidance the exception is control 12;

Perform up-to-date encrypted backups in a format avoiding CSP lock-in, stored offline at the tenants premises or at a second CSP requiring multi-factor authentication to modify/delete data. Annually test the recovery process.

While not so different from the ISM, there is specific reference to multi-factor authentication which hasn't been all that common until late 2018.

OAIC

Several investigations and case studies provide us with a clear understanding of how encryption is considered in the context of a data breach and any legal proceedings that may follow.

1. Case study: Cupid Media Pty Ltd

my investigation found that, at the time of the incident, Cupid did not have password encryption processes in place. Password encryption is a basic security strategy that may prevent unauthorised access to user accounts. Cupid insecurely stored passwords in plain text, and I found that to be a failure to take reasonable security steps, as required under the Privacy Act.

Statement of common situations

The loss of portable devices containing personal information. Laptops, external hard drives of USB sticks are often left in taxis, on trains, or misplaced in the office. This is a known risk, however often these devices are not encrypted

Again encryption is the recommendation.

The result;

Password encryption strategies such as hashing and salting are basic security steps that were available to Cupid at the time of the data breach that may have prevented unauthorised access to user accounts. The Commissioner therefore found Cupid’s storage of passwords in plain text to be a failure to take reasonable security steps for the purpose of NPP 4.1.

2. Another example; Adobe

While Adobe generally took a sophisticated and layered approach to information security and the protection of its IT systems, it failed to implement consistently strong security measures across its various internal systems. In particular, a backup server stored a database of unencrypted credential information (email addresses and password hints) of over 1.7 million Australian users, directly linked to the encrypted password for each user. The type of encryption used (block cipher), together with plaintext password hints, allowed security experts with to the database

The verdict;

The Commissioner found that Adobe breached NPP 4 by failing to take reasonable steps to protect the personal information it held from misuse and loss and from unauthorised access, modification or disclosure

What is the OAIC view on the new bill?

The OAIC acknowledges that the power to issue TANs and TCNs is subject to certain limitations, including that a TAN or TCN must not have the effect of requiring a systemic weakness or vulnerability to be built into a form of electronic protection. However, it will be necessary to ensure that the measures proposed in Schedule 1 do not, in practice, introduce unintended exploitable weaknesses into a telecommunications environment that fundamentally relies on strong and robust security settings. While the OAIC acknowledges that the Bill and explanatory memorandum before the Committee addresses some of the recommendations in the OAIC’s earlier submission, privacy risks remain.

Basically, that opportunity to make a submission to the Department of Home Affairs lasted single digit weeks. What a ruse. The Senate passed the bill in contempt of any submissions made and bypassing any conclusions the committee might have made thereafter. So the OAIC statement above is essentially meaningless.

The OAIC themselves made a submission to the committee with 10 recommendations that were not addressed by the bill passed through Senate, but the public is assured that maybe one of the recommendations define the terms ‘systemic weakness’ and ‘systemic vulnerability’ in s 317ZG might be addressed in typical post-truth politics. I digress.

Basically, so long as the 13 legally binding APPs are far from prescriptive, subject to the discretion of the privacy commissioner, the new bill will inevitably supersede privacy, so as to not make the government appear contradictory or any more contemptuous to the public then it is already perceived.

Final thoughts

Basically if your privacy or security is compromised from an APRA regulated company and data was decrypted, it is fair to state there were certainly more than 1 key custodian responsible for the breach and one might assume the act of disclosure was not an accident.

The decision-making criteria that apply to TAN and TCN, and the matters to be consider when applying those criteria, should also be extended to TAR (not part of the bill). A compliance to a TAR should include legitimate expectations relating to privacy and cybersecurity, such as reasonableness, proportionality, practicability, and technical feasibility. The subject of the TAR will more likely comply out of fear of legal proceedings and make mistakes that compromise individuals privacy and security from a lack of knowledge and lack of formal process or decision-making, which is far more damaging then the current state and not in the intent of the bill.

In terms of the AISEP you'll fail the ASD ACE by complying with a TAN or TCN, looking at 2 of dozens of protection profiles, one for mobile device communications and the other for IPSec. Simply doing a quick search I identified a fundamental conflict in both, further analysis must yield a few more. Did the people writing the anti-encryption bill even consider their own existing rules? They mustn't be aware of the ASD, or are intentionally ignorant knowing full-well the conflict in an attempt to avoid the inevitable analysis that would make them look like fools.

Finally; Considering the Notifiable Data Breaches scheme under Part IIIC of the Privacy Act. The fact that personal information is encrypted may reduce the likelihood of serious harm in the event of a data breach and therefore avoid the requirement to notify the OAIC or affected individuals entirely. Did the committee or Senate consider this new NDB Law or the older Privacy Act? Obviously not, or the payoffs were high enough they simply don't care.

And the best part, the PSPF33 control spells out that data shouldn't be accessed just because the person wanting access can get that access. This is in context stating that a warrant should be provided or how can a business possibly know if an external individual or entity should get access to what they are asking for and not just asking because they can ask (which violates PSPF33).

What to do if you get an enforcement

At a minimum, do the following:

• Identity verification, If they identify as law enforcement call the appropriate law enforcement office to make sure it is not a bad actor.
• Criminal record check. This is probably not possible, but if the individual is not identified as law enforcement and you have the means to conduct a Criminal record check i suggest you do so immediately with their consent.
• Eligibility checks, consult with your legal advisor, make sure the requested data and circumstances are all legal at the time of the enforcement. You are in your legal right to check if your own actions are legally appropriate.
• Do not perform any proposed actions outside normal business operations without first consulting your legal advisor specifically about the action.

Speaking from the point of view of a penetration tester i can see the use of these enforcement letters being a fantastic tool to test my target, not posing as law enforcement of course but a convincing TAR might just trick most organisations.