Say you’ve taken the wise decision to have your corporate cloud data be backed up by the Keepit cloud solution: you’ve selected one of our many data centers, configured relevant connectors, and are now seeing how snapshots are blissfully parading into eternal archive as you log in to the Keepit web user interface. But perhaps you want a bit more assurance and perhaps you are not keen on logging into a separate web application several times a day to get that assurance.

Many of our customers have their own monitoring solutions and communication systems that they wish to enrich with information from their Keepit account. Luckily, we have a very elaborate API (Application Programming Interface) to allow for all sorts of queries on the state and history of your backups; while we do publish the full API documentation, some might find a small appetizer easier to comprehend.

If you’re already a Keepit customer and if you have an account and working connectors, then this blog post will guide you through creating a PowerShell API agent that prints the timestamp of the last completed backup on your screen. It is very simple: it will not integrate into any monitoring or alerting system, it will not print fancy messages in any messaging platforms, nor will it draw graphs on its own – but it is a small building block that you can extend and transform into whatever you might need.

Getting Access to the API

In order to make calls to the API, your script needs to have the proper credentials and those are obtained through the web user interface. So, log in with a user that has at least ‘Job Monitor’ privileges and create an API token by doing: Users -> Your user – Edit User (the grey cog wheel) -> Security -> Add API token. Give the token a name and decide when it should expire; the API token cannot outlive the user it is associated with. Click ‘Create’ – confirm your password and you will get an API token username and password. Those you need to store in a secure place.

You are now ready to make API calls. For this example, we will be using PowerShell, and the first API call to be made is the call to obtain your account GUID. Now, the account GUID is also available in the web user interface, but obtaining this via the API is a nice, small exercise to verify that the API token and your script is working. 

Launch your favorite text editor – it can be Notepad, Notepad++, VSCode, Vim, or whatever you fancy the most, create the file accountguid.ps1 and paste this code into it:

try {
        $username = '<API Token username>'
        $password = '<API Token password>'
        $basicauth = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes('${username}:${password}'))
        $headers = @{
            'User-Agent' = 'PowerShell-Keepit-API-Agent-1.0/jakob-dalsgaard'
            'Authorization' = 'Basic $basicauth'
        }
        
        $response = Invoke-WebRequest -UseBasicParsing `
          -Uri 'https://de-fr.keepit.com/users' `
          -Method:Get -Headers $headers -ErrorAction:Stop -TimeoutSec 10 
        
        $userlist = [xml]$response.Content
        $id = $userlist.user.id
        
        Write-Host $id
}
catch {
        $line = $_.InvocationInfo.ScriptLineNumber
        Write-Host 'Cannot query Keepit API due to: $_'
        Write-Host 'at line $line'
}

Make sure to get the backticks and single and double quotes correct – computers can be very pedantic. In this file, you need to put in the API Token username and API Token password where specified. On line 11, this example reads ‘de-fr.keepit.com’ – thus valid for a Keepit account on our German data center – please change this hostname to the hostname of the data center for your account (i.e., ‘dk-co’, ‘uk-ld’, ‘us-dc’, ‘ca-tr’ or ‘au-sy’). Then, in a command terminal, you execute the script by typing:

Powershell .\accountguid.ps1

Depending on your security setup, you might need to confirm that you really want to execute a script, but please do – and you should see the script print out your 20-character account GUID. This GUID can then be used, along with the API Token, to obtain the list of connectors available in your account.

Save the following code block as devices.ps1:

try {
        $username = '<API Token username>'
        $password = '<API Token password>'
        $userguid = '<Account GUID>'
        $basicauth = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes('${username}:${password}'))
        $headers = @{
            'User-Agent' = 'PowerShell-Keepit-API-Agent-1.0/jakob-dalsgaard'
            'Authorization' = 'Basic $basicauth'
        }
        
        $response = Invoke-WebRequest -UseBasicParsing `
          -Uri 'https://de-fr.keepit.com/users/${userguid}/devices' `
          -Method:Get -Headers $headers -ErrorAction:Stop -TimeoutSec 10 
        
        $devicelist = [xml]$response.Content
        foreach ($system in $devicelist.devices.cloud) {
                $name = $system.name
                $guid = $system.guid
                Write-Host 'Name: $name'
                Write-Host 'Guid: $guid'
                Write-Host
        }
}
catch {
        $line = $_.InvocationInfo.ScriptLineNumber
        Write-Host 'Cannot query Keepit API due to: $_'
        Write-Host 'at line $line'
}

Again, put in API Token username and password, the Account GUID, and correct the hostname. Then execute as:

Powershell .\devices.ps1

Your terminal will then be filled with a list of connector names and GUIDs, and among those you will have to select one that can be used in the final script that will be called latest.ps1– this script will print out the timestamp of the latest backup performed by one specific connector:

try {
        $username = '<API Token username>'
        $password = '<API Token password>'
        $userguid = '<Account GUID>'
        $connectorguid = '<Connector GUID>'
        $basicauth = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes('${username}:${password}'))
        $headers = @{
            'User-Agent' = 'PowerShell-Keepit-API-Agent-1.0/jakob-dalsgaard'
            'Authorization' = 'Basic $basicauth'
        }
        
        $response = Invoke-WebRequest -UseBasicParsing `
          -Uri 'https://de-fr2.keepit.com/users/${userguid}/devices/${connectorguid}/history/latest' `
          -Method:Get -Headers $headers -ErrorAction:Stop -TimeoutSec 10 
        
        $history = [xml]$response.Content
        $tstamp = $history.history.backup.tstamp
        if ($tstamp) {
            Write-Host $tstamp
        }
        else {
                Write-Host 'Backup not completed yet'
        }
        exit 0
}
catch {
        $line = $_.InvocationInfo.ScriptLineNumber
        Write-Host 'Cannot query Keepit API due to: $_'
        Write-Host 'at line $line'
        exit 1
}

Again, put in API Token username and password, account GUID, connector GUID, correct hostname, and then execute as:

Powershell .\latest.ps1

If your selected connector has completed a backup, you should now, in your terminal, see the timestamp of completion of the latest backup for this connector. It might look something like: 

2022-12-24T18:30:00Z

This would say that the latest backup completed on Dec 24, 2022, at 18:30 UTC. The timestamp is given in the ISO8601 format with the Z designator for UTC.

Further Integration

While such a neat PowerShell script is nice to have on the command line, it will bring much more value as part of a monitoring platform or other reoccurring automatic execution. For your business, it might make sense to execute this script once per hour and alert if no backup has been completed for 24 hours. You might want to explore our public API for more information and status.

It’s easy to get a false sense of security and assume that your Microsoft 365 data is safe and secure because M365 automatically backs up your SaaS data for simple recovery, right?

Well, not so fast.

While M365 and most other SaaS platforms offer some sort of data protection and recovery features, it’s bare bones at best. For healthcare organizations, this opens Pandora’s box for compliance and continuity issues that can end up costing hundreds of thousands of dollars in fines. And on top of that, add the inability to serve patients and conduct daily business.

It’s critical to have timely and secure access to patients’ highly sensitive personally identifiable information (PII), protected health information (PHI), financial information, intellectual property, and credentials. However, given how this information has grown exponentially, data loss prevention has never been more necessary to ensure business continuity.

It’s crucial to understand that retention requirements far exceed what SaaS applications typically deliver natively, making it vital to close the gap with a reliable backup and recovery tool.

For healthcare organizations, compliance and continuity are the two main factors driving the need for third-party SaaS backup.

Regulatory Compliance
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) makes healthcare delivery organizations legally obligated to preserve certain types of information for periods that exceed a SaaS service’s built-in capabilities.

As the HIPAA Journal explains, each state has its own laws governing the retention of patients’ medical records. To complicate things further, those retention periods can vary considerably. 50 states with 50 retention requirements: Is this something your healthcare organization wants to (or can afford to) manage?

Individual U.S. state laws govern the retention of patients’ medical records, while HIPAA imposes requirements on how long HIPAA-related documents must be retained.

According to the HIPAA Journal, “In Florida, physicians must maintain medical records for five years after the last patient contact, whereas hospitals must retain them for seven years. In North Carolina, hospitals must maintain patients’ records for 11 years from the date of discharge, and records relating to minors must be retained until the patient has reached 30 years of age.”

The hard truth is that SaaS services do not deliver the level of backup and recovery required for healthcare organizations, and what they do provide isn’t seamless.

Business Continuity
Imagine the worst-case scenario where your mission-critical data is suddenly gone—it’s not hard to imagine since it happens to companies every day. Healthcare organizations rely on the information stored in SaaS systems to maintain their business continuity. If the information suddenly becomes unavailable, then significant disruption results.

Continuity Considerations
Things can (and do) go wrong with SaaS data: a simple misconfiguration can cause primary data sources to become unavailable, making accidental deletion a real risk, which may not be discovered until it’s too late to recover from the SaaS app – and may be unrecoverable even if you do find it quickly.

In fact, according to ESG Research, the most common reasons for data loss are service outages and accidental deletion, as seen here:

2 Reasons Why: M365 Data Backup for Healthcare Organizations
Compliance 26.10.22 9 Minutes
It’s easy to get a false sense of security and assume that your Microsoft 365 data is safe and secure because M365 automatically backs up your SaaS data for simple recovery, right?

Well, not so fast.

While M365 and most other SaaS platforms offer some sort of data protection and recovery features, it’s bare bones at best. For healthcare organizations, this opens Pandora’s box for compliance and continuity issues that can end up costing hundreds of thousands of dollars in fines. And on top of that, add the inability to serve patients and conduct daily business.

It’s critical to have timely and secure access to patients’ highly sensitive personally identifiable information (PII), protected health information (PHI), financial information, intellectual property, and credentials. However, given how this information has grown exponentially, data loss prevention has never been more necessary to ensure business continuity.

It’s crucial to understand that retention requirements far exceed what SaaS applications typically deliver natively, making it vital to close the gap with a reliable backup and recovery tool.

For healthcare organizations, compliance and continuity are the two main factors driving the need for third-party SaaS backup.

Regulatory Compliance
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) makes healthcare delivery organizations legally obligated to preserve certain types of information for periods that exceed a SaaS service’s built-in capabilities.

As the HIPAA Journal explains, each state has its own laws governing the retention of patients’ medical records. To complicate things further, those retention periods can vary considerably. 50 states with 50 retention requirements: Is this something your healthcare organization wants to (or can afford to) manage?

Individual U.S. state laws govern the retention of patients’ medical records, while HIPAA imposes requirements on how long HIPAA-related documents must be retained.

According to the HIPAA Journal, “In Florida, physicians must maintain medical records for five years after the last patient contact, whereas hospitals must retain them for seven years. In North Carolina, hospitals must maintain patients’ records for 11 years from the date of discharge, and records relating to minors must be retained until the patient has reached 30 years of age.”

The hard truth is that SaaS services do not deliver the level of backup and recovery required for healthcare organizations, and what they do provide isn’t seamless.

Business Continuity
Imagine the worst-case scenario where your mission-critical data is suddenly gone—it’s not hard to imagine since it happens to companies every day. Healthcare organizations rely on the information stored in SaaS systems to maintain their business continuity. If the information suddenly becomes unavailable, then significant disruption results.

Continuity Considerations
Things can (and do) go wrong with SaaS data: a simple misconfiguration can cause primary data sources to become unavailable, making accidental deletion a real risk, which may not be discovered until it’s too late to recover from the SaaS app – and may be unrecoverable even if you do find it quickly.

In fact, according to ESG Research, the most common reasons for data loss are service outages and accidental deletion, as seen here:

Still, accidents, misconfigurations, and other ‘innocent’ causes aren’t the only ways to lose data.

In recent years, ransomware gangs have set their sights on the healthcare sector and, unfortunately, have been successful in their efforts to disrupt and demand payment for the data’s return.

Fulfilling Regulatory Obligations
Few people like being told what to do, but it turns out that governments do have the authority to compel action.

In the U.S., federal and state laws impose strict requirements around data retention for different healthcare records and information types. Additionally, regulations are subject to change, adding more pressure to comply to avoid a regulatory audit and heavy fines. Failure to comply can lead to significant financial and legal exposure, such as lawsuits, fines, settlements, and certification losses, further increasing the risk of data breaches.

For Healthcare delivery organizations (HDOs) committed to minimizing or avoiding these risks, having a proper backup and recovery practice in place is key to compliance.

Third-party backup and recovery services help you stay compliant by ensuring your data remains immutable and tamperproof. Immutable data and metadata make it possible for you to document and recover not just all data but all data processing, ensuring that auditors have complete visibility of everything that has impacted the data.

If complying with laws (and avoiding potentially hefty fines) isn’t enough to secure the budget, there are other reasons to invest in SaaS backup, such as mitigating downtime and costs.

Protecting Business Continuity
In a presentation titled “Conti Ransomware and the Healthcare Sector,” the United States Department of Health and Human Services (HHS) relayed that:

the average length of a general ransomware incident is 19 days.
Cybersecurity provider Sophos reported that 25% of healthcare organizations disrupted by ransomware took up to a month to restore operations. Sophos’ research also suggests that:

the average remediation cost for healthcare organizations soared to USD 1.85M in 2021 (up from USD 1.27M in 2020).
Keeping services operational is essential for maintaining the revenue that sustains an organization. That’s why having reliable backups that can quickly and easily be restored is paramount.

Unfortunately, the reality is that data outages are a matter of when, not if, making your ability to recover key data (and fast!) a necessary part of business continuity planning. Additionally, the shorter the outage, the lower the recovery and remediation costs, making loss avoidance a compelling part of the value proposition.

Recovery processes and costs can also include Digital Forensics and Incident Response (DFIR) activities, whether mandated by cyber insurance coverage, necessary for root cause analysis, driven by a motivation to prosecute, or some other reason.

Third-party backups assist DFIR activities by providing trustworthy information that extends further back in time than what can be pulled from SaaS applications.

But being able to restore services quickly from a dedicated SaaS backup doesn’t just protect revenue and minimize recovery costs, it also means you avoid paying the ransom and lower your cyber insurance fees.

Protect Your SaaS Data Today
If you can recognize some of the data backup and recovery vulnerabilities discussed here within your own healthcare organization, the good news is that it’s easy and cost effective to address those challenges and help secure your organization’s data.

Unintentional and malicious data losses don’t offer the convenience of a “heads up,” so it’s a wise business decision to have a proper backup and recovery solution in place before you need it – and as such, it should be an integral part of your cybersecurity approach. Only backup allows you to go back in time and recover to before bad things happened!

If you’d like to learn more about compliance and continuity for healthcare organizations, access the