{"id":4516,"date":"2023-11-09T15:07:26","date_gmt":"2023-11-09T15:07:26","guid":{"rendered":"https:\/\/gitprotect.io\/blog\/?p=4516"},"modified":"2024-03-04T14:40:00","modified_gmt":"2024-03-04T14:40:00","slug":"devsecops-mythbuster-nothing-fails-in-the-cloud-saas","status":"publish","type":"post","link":"https:\/\/gitprotect.io\/blog\/devsecops-mythbuster-nothing-fails-in-the-cloud-saas\/","title":{"rendered":"DevSecOps MythBuster : \u201cNothing fails in the cloud \/ SaaS\u2026\u201d"},"content":{"rendered":"\n

Welcome back(up) to the DevSecOps MythBuster series! If somehow you have missed our previous articles, you definitely need to catch up!<\/p>\n\n\n\n

And we’re just getting started! Our DevSecOps Mythubuster’s tentacles reach for another popular myth…<\/p>\n\n\n\n

Myth #4 Nothing fails in the cloud \/ SaaS<\/h1>\n\n\n\n

As the number of organizations using cloud and SaaS apps grows, data loss and cyber threats become a huge concern. It is estimated that a single midsize business uses around 217 SaaS applications. For cybercriminals, it opens at least that many \u201cdoors\u201d to break into company IT systems and steal company data. <\/p>\n\n\n\n

Do you still think your data in the cloud is safe? Let\u2019s start with a few statistics. <\/h2>\n\n\n\n

TechTarget’s Enterprise Strategy Group released a report in February 2023 called “Data Protection for SaaS”. They asked IT professionals about the most common causes of data loss or corruption in SaaS-based applications.<\/p>\n\n\n\n

Top 3 – service outage\/unavailability, malicious deletion from cyber attack, and accidental deletion. <\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

Source: TechTarget<\/a><\/p>\n\n\n\n

And it’s hard for us to disagree with that. When talking to clients about DevOps backup<\/a> software, these reasons, along with the need to ensure security compliance, become the main arguments for choosing our solution.<\/p>\n\n\n\n

In this article, we will focus on DevOps data, kept in GitHub, GitLab, and Atlassian tools as source code, projects, and all related metadata constitute Intellectual Property which is one of the most important resources for every tech-related company.<\/p>\n\n\n\n

Service downtime and outages<\/h2>\n\n\n\n

SaaS\/cloud outages are nothing shocking – they happen to every cloud provider. While many reasons could contribute to such an unavailability, it does not necessarily mean that your data is gone. The question is what to do to keep your business up and running? How to minimize costs? Do you have a fail-over or Disaster Recovery<\/a> plan for your SaaS application data?\u00a0<\/p>\n\n\n\n

Let’s choose the winners of this year’s list of the biggest cloud failures\u2026 A multi-day IT Glue outage in January, an hourslong Microsoft outage in March, or a fire that wreaked havoc for Google Cloud users in Europe. Pick yours.<\/p>\n\n\n\n

Okay, now it’s time for Jira. We bet you heard about the biggest Jira failure of the last year. And if not, you should definitely listen to this story. An all-time Jira outage affected 775 customers and lasted for almost two weeks. And this is how long it took the company to recover all customer data. What was the reason for this massive outage? No surprises this time – human error. <\/p>\n\n\n\n

To make a long story short \u2013 the reason behind it was a maintenance script that accidentally wiped hundreds of customer sites due to communication issues between two Atlassian teams working on deactivating a legacy app. However, instead of being provided the ID required to disable the app, the deactivation team was sent the IDs for the cloud sites where the app was installed. Also, the script was launched using the wrong execution mode (permanent deletion instead of recovery failsafe deletion). <\/p>\n\n\n\n

Want to learn more? Read our article: Was the Jira Outage the Last Atlassian Problem?<\/a> <\/p>\n\n\n\n

In our annual rankings of the loudest threats, we calculated 41 incidents in Bitbucket and 53 incidents in Jira mentioned in Atlassian Status. About 11 hours Atlassian Bitbucket users were out of the service or partially out, while Jira users experienced about a staggering 329 hours of outage. <\/p>\n\n\n\n

Read more: 2022 In A Nutshell: Atlassian Outages And Vulnerabilities<\/a><\/p>\n\n\n\n

When it comes to Github-related \u201cfackups\u201d of 2022<\/a>, we made a pretty long list of serious outages, high-severity vulnerabilities, data breaches, stolen credentials (and source code itself!) from well-known brands, and hacker attacks. Only the best of 133 that happened.<\/p>\n\n\n\n

Once upon a time\u2026 – a true story about some ransomware attack on Git repositories<\/h2>\n\n\n\n

It may surprise you, but more than half of ransomware attacks last year targeted SaaS data<\/a>. Ransomware attacks<\/a> on SaaS tools were the most likely to be successful (52% of them resulted in data encryption).\u00a0<\/p>\n\n\n\n

Data in public infrastructure clouds like AWS, Azure, or Google Cloud was the no. 1 target, while endpoints, such as laptops and mobile devices, and on-premises data came in at no. 2 and no. 3, respectively. <\/p>\n\n\n\n

If you think this won’t happen to your repositories or metadata, let us tell you the story of some attack\u2026<\/p>\n\n\n\n

It was a broader attack against the famous trio of Git hosting services – GitHub, GitLab, and Bitbucket. The bad actor performed command line Git pushes to repositories he accessed, indicating automated methods. These pushes overwrote the repository contents with the ransom note (below) and erased the commit history of the remote repository.<\/p>\n\n\n\n

\u201cTo recover your lost code and avoid leaking it: Send us 0.1 Bitcoin (BTC) to our Bitcoin address 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA and contact us by Email at admin@gitsbackup.com with your Git login and a Proof of Payment. If you are unsure if we have your data, contact us and we will send you a proof. Your code is downloaded and backed up on our servers. If we don\u2019t receive your payment in the next 10 Days, we will make your code public or use them otherwise.\u201d<\/em><\/p>\n\n\n\n

During this attack, a third party accessed repositories by using the correct usernames and passwords for one of the users with permission to access repositories. These credentials may have been leaked through another service. Probably through SourceTree’s free Git client, belonging to Atlassian, as it was found as the common denominator for all hacked accounts.<\/p>\n\n\n\n

The security and support teams of all three companies had taken steps to notify, protect, and help affected users recover from these events. They wrote a joint article on safe practices for Git repositories. They were also working with the affected users to secure and restore their accounts. Unfortunately, there is no confirmation anywhere whether all accounts were successfully restored and how long it took.<\/p>\n\n\n\n

RepoJacking – a threat that even sounds dangerous<\/h2>\n\n\n\n

Dependency repository hijacking (RepoJacking) has already been threatening businesses for years. It can potentially have affected major projects of such companies as Google, Kubernetes, GitHub, NodeJS, and many others. RepoJacking is a supply chain vulnerability with a subdomain takeover-like conceptual underpinning. In more common language, it results in that the attacker may take over retired organizations or users\u2019 names and publish trojanized versions of repos to run some malicious code in it.<\/p>\n\n\n\n

Want to learn more? Read our article: GitHub RepoJacking: Are You Sure Your GitHub Is Safe?<\/a><\/p>\n\n\n\n

Accidental deletions <\/h2>\n\n\n\n

Finally, human errors – the most common reason of all data losses and one of the most favorite attack vectors for criminals. <\/p>\n\n\n\n

Unfortunately, most vendors, including Atlassian do not ensure you with granular, point-in-time restore in case of unintentional deletion and daily operations. Let us remind you – for example, that it is not possible to restore a single issue from Jira if it was accidentally deleted. You probably know how much information a single issue can contain – configuration, all comments, attachments, links, or sub-tasks. All this can disappear forever as a result of one mistaken click by your employee.<\/p>\n\n\n\n

More SaaS providers enable you to restore data after deletion for some given time. For example, in GitHub, a deleted repository can be restored within 90 days unless the repository was part of a fork network that is not currently empty (then it can not be restored at all). Once you discover such deletion 91 days later, you won\u2019t be able to restore this repo anymore. The so-called permanent\/hard deletion occurred.<\/p>\n\n\n\n

Who is guilty? Most users!<\/h2>\n\n\n\n

Unfortunately, there appears to be a lot of confusion about where data loss stems from. Many organizations make dangerous assumptions about who is truly responsible for backing up the data in their SaaS applications.<\/p>\n\n\n\n

In a recent blog post, we referred to this myth, described the main assumptions of Shared Responsibility Models all SaaS vendors rely on, and even quoted some parts of their terms of service. <\/p>\n\n\n\n

\u26a0\ufe0f Know your responsibilities:<\/p>\n\n\n\n