Another day, another report.
**EDIT from Moderators: Latest updates from Medibank regarding the data breach and cyber security are available here: Cyber event updates and support | Medibank
Medibank are investigating a potential breach. This was send out to policy holders in the last 24 hours:
Dear Policy Holder,
You may have heard that Medibank has detected unusual activity on our IT network. Iām sorry this has occurred.
We are working around the clock to resolve this incident and will continue to provide updates as we learn more. Hereās what we know.
At this stage, there is no evidence that any customer data has been accessed. We donāt have all the answers yet, but our highest priority is protecting Medibank Group customers and our people.
What we are doing
While we conduct our investigation, we have temporarily taken some of our customer-facing systems offline. At this stage, these changes to our systems are not impacting Medibank customers.
Weāve engaged external cybersecurity experts to help us with our investigation and are in contact with the relevant government agencies.
How we will communicate
We will keep you up to date as the situation evolves.
As always, Medibank will never contact you requesting your passwords or other sensitive information.
Although there is nothing that customers need to do, we have established an information page on our website where we will provide the latest updates.
Regards,
David Koczkar
Chief Executive Officer, Medibank
1 Like
Update from Medibank:
Dear Policy Holder,
I wanted to update you on the progress weāve made since we detected unusual activity on our IT network last week.
Our ongoing investigation continues to show no evidence that any customer data has been removed from our IT environment. I want to reassure you we take the protection of your information very seriously, and this remains our key priority.
We have now resumed normal activity for all customers.
What we are doing
Our cyber security protection systems had detected activity that was consistent with a possible ransomware threat. I want to assure you that our systems were not encrypted by ransomware during this incident.
As a further precaution, weāve deployed additional security measures across our network. We continue to work with external cybersecurity experts and the Australian Governmentās lead cyber agency as our forensic investigation progresses.
We remain vigilant and will continue to take the necessary steps to protect your data.
How we will communicate
We will continue to keep you up to date with regular posts to the information page on our website.
As always, Medibank will never contact you requesting your passwords or other sensitive information.
We appreciate your patience, and once again, Iām sorry this has occurred.
Regards,
David Koczkar
Chief Executive Officer, Medibank
2 Likes
Medibank Update. There now appears to be information āstolenā from Medibank systems:
Media reports indicate that it is now believed that data from Medibank Privateās āahm and international student systemsā is some of the data that has been āstolenā.
In a statement, the company said the criminal group allegedly responsible had claimed that 200 gigabytes of data had been stolen and that it would be reaching out to affected customers to let them know and what to do next.
Medibank has also indicated that it expects the number of affected customer to grow as their investigations continue.
If one has a credit/debit card registered with Medibank Private, until you hear directly from Medibank in relation to whether your information is that which has been āstolenā, it might be worth keeping a eye on your credit/debit card account for unauthorised transactions. It may also be worth contacting your credit/debit card issuer to ask if they can increase monitoring of your card for unusual transactions.
Edit: Some more information is here:
And the $64k governmenty question would be ā¦ only current customers or also past customers? In other words, how long does Medibank retain the data on ex-customers? and what data?
2 Likes
One has to wonder how such a large volume of data could have been transferred to one or more sources without the system noticing a change in the internal network traffic or data requests? Do the hackers know more about a systems defences than the providers of the data management services providers?
In jest, itās hard to believe anyone could move so much data in a very short period of time, at least if they were connecting through the NBN. 
I wonder what their RSP is thinking?
1 Like
Yes, there needs to be a review of what data is stored - short sunset clauses when a customer no longer has a relationship with a business/organisation.
Keeping data for no real purpose is only potential gold to hackers.
The ABC also covered this as well in:
There was also comment of cryptographic identifying tools used in Estonia (and Belgium) which I raised elsewhere. Australia needs to lift its game and not be a data hoarder.
It isnāt a lot of data in todayās business world. It can be transferred easily and if a business does regular data backups or has multiple sites, 200GB is unlikely to noticed amongst transfers.
2 Likes
200 GB? Thatās the amount of information that could be on 4 Blu-ray disks.
How would that be?
What is backed up and when?
Is it an internal process or a request from an external source?
One might expect that a secure system backup is continual and transactional as well as routine. The load on the system in respect of data requests per time and on key external links has a daily norm.
Itās supposition that the amount of data extracted would be noticeable.
Itās supposition that the system administrators would be monitoring for changes in the level of activity, by direct monitoring or through system tools.
It needs a better explanation.
It would seem the failure to notice the activity is consistent with the failure to secure the data in the first place. It says much about the competence or lack there of for those responsible for the systems if it is so easy to avoid detection in progress.
If you have multiple business sites, very large amounts of data are regularly transferred between sites. Iāll use an example of an engineering firm I am familiar with, but the same applies to many other businesses. Data on their servers are transferred to other sites regularly as a backup and to ensure other sites have the up-to-date data to work on. Engineering drawings can be very large and 300GB insignificant in the volume of movements. If a business uses a secure second or third party remote backup, terabytes of data can be transferred regularly.
If staff work from home or client workplaces, data on the businesses servers are accessed remotely. Being an engineering firm with complex drawings, 300GB isnāt overly significant for projects. The same applies for business which use data intensive files - many do.
If you take a business like Medibank with large member base, if each member lodged one receipt for claiming as a compressed pdf document, the 300GB could be exceeded. If it was an image file, then it could easily run into terabytes. Add multiple receipts and all other datasets, the 300GB becomes insignificant. Unless Medibank has extremely poor business practices, they will be backing up their data regularly and transferring large volume of data across their network.
This is how many modern businesses work. Flagging based on volume of data transfer over or off a network wonāt be effective, unless a business never transfers near that volume. Then 300GB may be seen as unusual. Such could apply to a small business, but not large businesses like those where data has recently been compromised.
But Medicare and the others are not a large Engineering firm moving drawings etc. Not every customer transacts daily or even weekly. These days claims are digital records, mostly direct from the provider and very compact even if a pdf image.
The question remains as to if and how the Business systems services used are effectively monitoring the external connections to their systems. How these connections are configured is open for others to comment on. For large organisations the movement of large volumes of data occur in a very different environment to that of the internet consumers are familiar with.
Preventing inappropriate access is one level of control. Limiting what data is collected, or at least separating and more securely restricting access to more critical data another.
Is monitoring what is happening across the internal network especially with authorisations and activity at different levels also a key role of Systems Management? There are others in the community with far greater first hand knowledge than I to respond to that.
A business offer in response to any failures āit is an experience we will learn fromā, is far from acceptable. For consumers itās asking acceptance breeches are now inevitable. Business wins yet again IMO with the victims left to wonder why? I hope those seeking legal remedy more directly have great success.
Medibank has a large number of employees located around Australia in branches and in their head office. They would have enormous traffic on their network for queries to their datasets - with a enormous amount of data moved.
Add in customers assessing and lodging claims, new customers signing up and other customer queries, the data volumes become large.
The 300GB would not have been one file, but as many files which could be downloaded in the time until being noticed. It could have been over number of minutes, hours, days or months.
Using volume transferred as a trigger is fraught with danger. If we say a limit is set to 10GB for a suspicious transfer at one time, 9.9GB of the most sensitive data could be transferred without meeting the trigger. So what would the trigger volume beā¦possibly the smallest file size of data which a business deems is sensitive. This could mean very small file sizes of KBs could be the trigger rendering the screening process useless as almost every file would be flagged as being suspicious bogging done the process. Flagging based on suspicious activity often used, as as reported by Medibank, would be a better option as it flags unusual activity on their network rather than the size of files being moved.
One of my previous employers provided different access to different datasets based on delegations within the organisation. IPs accessing data could be used to check data being access has been authorised and matches the delegations. Using IPs isnāt foolproof, as many employees work from home and could have changing IP addresses - along with customers who can access their own information associated with the accounts. Blocking foreign IP is possible but would only work for a short time until routing through Australia is used. Maybe using cryptographic identifying tools (like those outlined above) across the board might be the best currently available solution.
I also donāt know why, assuming it has been developed, that all data on business servers are encrypted. Decryption and encryption for data extracted from the servers occurs at the user end using portal software installed and maintained by IT personnel. There are reports with encryption is that it is as only as good as the security of the key/ If the key is managed by select IT personnel, then this reduces the risk of the key be available by all staff and potentially leaked.
This is the same reason why the $10,000.00 limit for financial transaction reporting is of little use in stopping financial crimes. A criminal knows about the limit, and transfers multiple amounts of $9,900.00 over a period of time.
A data thief - if they have any sense - will seek to transfer data out using multiple small files rather than one big file. What the internal defence should be looking for is network traffic that does not match normal business, and its alerts will include but not be limited to file size.
3 Likes
The other thing is relying on a data volume trigger means you are getting a trigger to investigate something after a breach or data movement has occurred. Computer says data has goneā¦a bit of a late response.
The appropriate approach is install systems to ensure security of data (viz. stop unauthorised access) and if this fails, ensure and data stolen is in a form of little value (viz encryption). The other key is only store data key to the ongoing function of the business - rather than the current collect and keep as much for as long as possible.
1 Like
Many valid points have been made about the Medibank breach. I would just like to add:
- Security is all about ādefence in depthā - no single approach is good enough in its own right - so yes 1) donāt collect / donāt retain is the safest of all but it will fail or be inappropriate, so 2) control access to data (this is the biggest subject area) but that too is likely to fail eventually, so 3) detect exfiltration.
- If you are moving data between sites (e.g. for backup) then that should be handled as internal traffic (even if going via VPN over the internet) and so your network appliances should be able to ignore that for the purposes of exfiltration detection. I realise it was also discussed above that you might be doing backup to an external provider, in which case your exfiltration detection will have to take that into account - and you better be really really confident with the encryption of your backups.
- Encrypting sensitive data fields at rest is appropriate but it is important to understand at what level in the application stack decryption occurs and at what level the hack occurs.
- As far as I recall, we donāt know when unauthorised access was first achieved. If it was months ago or even more than a year ago then it becomes harder for exfiltration detection to do its job. The hacker could have been dribbling the 200 GB out for so long that the traffic will have flown under the radar. (This contrasts with the Optus breach, I believe, where we know that a specific user stuff-up on a fairly well known date i.e. well known to Optus, was what exposed the data.)
Thereās a slight difference though because the criminal knows the limit is $10k - it is written in law - whereas the hacker will not be sure what the exfiltration detection limits are or how they work unless the hacker has inside knowledge (which certainly can be the case but wonāt be the case in general). The hacker therefore has to err on the side of caution and even then accept the risk of detection.
I have even worked on systems where parameters are deliberately randomly fuzzed e.g. the actual value to be used is randomly in the range +/- 10% of the value that the parameter is set to. (In theory a bank could do that with the AUSTRAC limit, at least on the negative side.)
2 Likes
Meanwhile, the details of the actual hack are getting worse: All Medibank customers' personal data was compromised in the cyber attack. Who is at risk and what should customers do? - ABC News
1 Like
I had ambulance cover with Medibank a few years ago, but it appears they have kept my data, according to their latest email.
In part-
We understand youāve left Medibank, but we are writing to former customers to alert them to this incident because customer data ā both current and former ā is our highest priority.
Unfortunately, it is now clear that the criminal has taken data that belongs to Medibank customers, in addition to that of ahm and international student customers.
Whatās happened
We have received a series of additional files from the criminal. We have been able to determine that this includes:
A copy of the file received last week containing 100 ahm policy records ā including personal and health claims data
A file of a further 1,000 ahm policy records ā including personal and health claims data
Files which contain some Medibank and additional ahm and international student customer data
Given the complexity of what we have received, it is too soon to determine the full extent of the customer data that has been stolen. We will continue to analyse what we have received to understand the total number of customers impacted, and specifically which information has been stolen.
As we continue to investigate the scale of this cybercrime, we expect the number of affected customers to grow as this unfolds.
If we find your data has been stolen, we will notify you, by email, as soon as we can. Until this verification process is complete, unfortunately our contact centre and retail teams will not have access to further information on whether your data has been stolen.
3 Likes
It would be good if Medibank fessed up to what their Data Retention period is.
I used to be with Medibank but that was more than a few years ago. I donāt even remember exactly when it was.
For some people, not receiving email is simply going to be an indication that the customer has changed email address in the meantime i.e. Medibank is alerting you to the fact that your data was āretainedā but sending the alert to an out-of-date email address that no longer works. Once you cease doing business with a company, you really have no obligation to keep them updated with your current email address.
3 Likes
It would be good to know what data/records they have kept on each current and past members.
I suspect that many of their members may have had cover over their lifetime and the records for their members may change over time. It could be that each member has different records to the next.
Maybe in the future, such information could be presented as a listing when one logs in on any business website. Like
At XYZ, as part of our business operations, we have stored the following records on you:
ā Credit Card Details
ā Home Address
ā Home phone number
ā Mobile number
ā Employer
ā Drivers Licence details
ā Passport details
ā Medicare Card details
ā etc etc
Then at least if a business is hacked/data breach occurs, one has a starting point to work from. I personally wouldnāt know what data/records any of the main businesses I deal with have.
5 Likes
I seriously donāt know how any business can fully protect themselves against misuse of administrator level userids. And it seems that one of those was used to do the deeds.
In the case of Medibank, it was business data read, and there would be a multitude of applications all day, every day, reading that data for reports, transactions, backups, statements, etc.
You can put some serious controls on alteration of data, but read access is pretty much open for normal business data.
