Tag: Ransomware

  • US DoJ Makes PyPI Give Up User Data ¦ Tape Storage: Not Dead

    US DoJ Makes PyPI Give Up User Data ¦ Tape Storage: Not Dead

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: PyPI complies with a “string of subpoenas,” and LTO continues to grow, despite predictions of its demise. (more…)

  • How DevOps Teams Can Defend Against API Attacks

    How DevOps Teams Can Defend Against API Attacks

    Remember when ransomware was the main security threat that DevOps teams needed to worry about?

    Those days are over. Ransomware attacks are certainly still happening, but API security breaches—which increased by a whopping 600% in 2021—are now poised to become the top attack vector for threat actors, according to Gartner.

    That’s the bad news. The good news is that, in many respects, the security practices that DevOps teams already have in place to defend against ransomware can be repurposed to deliver API security, too—with a few tweaks.

    Keep reading for a look at the state of API security today, along with tips on expanding upon DevOps’ existing ransomware defense techniques to protect your APIs.

    The Preponderance of APIs

    Although it may seem surprising that APIs have suddenly become an attacker’s best friend, it’s actually not when you step back and think about how deeply dependent we’ve become on APIs over the past half-decade.

    APIs have been around for a long time. But until relatively recently, APIs were used mostly for specific types of applications, B2B or infrastructure integrations. It wasn’t until the pivot toward microservices and distributed architectures that internal (or east-west) APIs became the glue that holds application environments together and carries information (which is sometimes sensitive) between the components and micro-components of an application.

    As for external APIs, publishing public APIs has become a basic expectation for virtually any business with a software product—to the extent that there are now something like 22,000 public APIs out there as well as several orders of magnitude more internal APIs.

    The result is a world where APIs create potential attack vectors against virtually every application or service. It only makes sense, then, that the bad guys are increasingly focusing on exploiting APIs as a means of obtaining access to things you don’t want them to have.

    From Ransomware Protection to API Protection

    You might think that securing APIs requires fundamentally new security tools and practices. In reality, though, there are extensive parallels between mitigating ransomware risks and mitigating API security risks. And DevOps teams are a major line of defense against these.

    Here’s how to extend an anti-ransomware strategy to an anti-API-exploit strategy.

    Prevent Lateral Movement

    Like ransomware, which propagates from endpoint to endpoint laterally by exploiting flaws and vulnerabilities, API exploits also typically spread laterally across an environment.

    This means that even if you can’t prevent all API (or ransomware) attacks from breaching your perimeter, you can take steps to make it hard for breaches to expand. By detecting malicious activity inside your environment early on, you can stop lateral propagation of the threat before it leads to a largescale compromise.

    Focus on Data Security

    Ransomware attacks and API attacks are both focused on compromising the same crown jewel: Your data. Ransomware attackers want to hold that data for ransom. API attackers—such as those who stole sensitive information from compromised Peloton accounts, or others who breached LinkedIn’s API to scrape data about 700 million users—typically want to exfiltrate it, possibly to resell it or maybe just to harm your business’s reputation.

    Mitigating both ransomware risks and API security risks, therefore, boils down to securing your data. By enforcing strong access controls and segmentation over what both internal and public APIs can do, you mitigate the risk of data exfiltration due to API security breaches.

    Use Behavioral Security Models

    Investing all of your signature-based security controls in attack prevention doesn’t work well for either ransomware or API attacks, especially when they are zero-day or unknown attacks. While you certainly should do what you can to harden your environment, it’s impossible to guarantee that a breach won’t slip past your defenses.

    That’s why deploying behavior-based security models is key to protecting against both ransomware and API attacks. Behavioral security models detect anomalous activity inside an environment, such as unusual types of requests or strange request patterns. By modeling and baselining behaviors and detecting anomalies based on your model, you can prevent attacks from spreading once they are underway.

    Don’t Rely on Perimeter-Based Defenses

    Along similar lines, trying to protect the perimeter of your environment is not a surefire defense against either ransomware or API attacks. Instead, you need to distribute protections across all of your endpoints, applications, services and so on.

    Again, nothing will guarantee that attackers won’t get in. The success of your defense hinges, in large part, on your ability to make it hard for them to escalate their attack from a small-scale breach into one that impacts a wide array of resources.

    Look Beyond the Surface

    Ransomware and API attacks are similar in that both often involve attack methodologies designed to elude common security monitoring tools.

    For example, attackers might try to leverage ports 80 or 443 (the default HTTP/HTTPS ports), which will almost always be open on firewalls. It’s therefore imperative to avoid relying just on standard ports or on encryption to protect API traffic. Instead, you must look deep into the payload, then parse and understand the protocols. It is also important to monitor and collect data from multiple sources, then correlate and analyze them to a get a deeper understanding of what is actually going on within the environment.

    Conclusion

    To be sure, ransomware attacks and API security attacks are fundamentally different in some respects. They involve the exploitation of different protocols and the goals of attackers are usually a bit different.

    But in terms of how attackers operate, what they want to steal (your data) and the limitations of perimeter-based defenses, ransomware attacks and API attacks are actually pretty similar.

    That’s why developers and DevOps teams don’t need to rethink their entire security strategy to cope with the surge in API attacks. Instead, do what you’re already doing to protect against ransomware and use those techniques to help secure your APIs, too.

  • That Other Continuous: Data Protection

    That Other Continuous: Data Protection

    Looking around at things to add to our current project’s toolchain (that is one of the reasons we do these side projects; to check out all sorts of new ideas/tools/etc), and researching the company where a former coworker is the CMO, I was drawn into the resurgent world of continuous data protection (CDP). It is interesting that we could end up adding CDP to the list of ‘continuous’ activities, like CI/CD/… CDP, even though CDP was named long before any of our DevOps or Agile terms were born.

    The whole idea of CDP is that it is always backed up, so you are continuously protected. It largely failed when first introduced because it massively increased both the cost and complexity of your storage environment. Essentially, it required a hot copy of all of your storage. Not something most enterprises were willing to invest in. I mean, it was friggin’ expensive. And it used virtualized storage, which no one wanted to mess with. Long story short, at the time, virtualized storage introduced issues no one wanted to deal with.

    But several things have changed over the years, and it is interesting to see where CDP concepts have cropped up. You see, today it is being used to protect companies from ransomware. It’s still a bit of complexity, but we’ve become experts at hiding complexity. It still requires a lot of storage (I would argue that the current versions I’m seeing require more storage than the original CDP solutions did), but when your environment is taken over by ransomware, a clean machine can be used to restore data to a point before the ransomware took over. From a “continuous protection” standpoint—giving it a modern meaning along the lines of “continuous testing”—that is an astounding feat.

    The way it works—at least the way that the current implementations I’ve looked at work—is pretty simple at heart, though as my former coworker likes to say, “Easy in concept, difficult in implementation.” It keeps every write ever made to storage, with time and currency markers. So it knows what the disk currently looks like, but it can also get to what the disk looked like at 12:33 am yesterday. Or January first, or a year ago… You get the idea.

    It uses a ton of space because there is an implied truth here—nothing is destroyed. In traditional storage, if you change a document and hit save, the document is written over. In the new iteration of CDP, if you change a document and hit save, the changes are recorded, but the original is not altered. Call it “non-destructive writes,” if you will.

    It is worth checking out. The concepts are huge, and offer protection that is otherwise in short supply. If you have a dedicated DevSecOps team, they’re the ones I’d point at it, since the big reason for using this is a security reason at heart (though there are other uses; I’m currently gushing about security because this is a big deal).

    I’ll get back on track and report back about things directly in the toolchain for our newest DevOps project next week. I thought this was worth writing about, since most of you all could use the concept, even if only for peace of mind. You’re rocking it! Protecting your work against the newest range of attackers is just common sense. It’s worth seeing if the modern iteration of CDP is for you.

  • Make GitHub Backups Part of Your Development Process

    Make GitHub Backups Part of Your Development Process

    GitHub’s platform is the largest host of source code in the world, hosting over 190 Million repositories. So much of the code we rely on every day is hosted there. You are, in all likelihood, using it. But what would you do if, one day, all of the project code GitHub stored for you disappeared?

    Just like all other cloud services, GitHub follows a cloud computing principle called “shared responsibility” for data protection and security. It essentially means that users of a cloud platform and providers of said platform split the responsibility for safeguarding data. In other words, users are just as responsible for mitigating risks on their side of the equation as GitHub is on theirs. It’s all laid out in GitHub’s terms and conditions:

    Taking this into account, there are a handful of things that can impact your ability to access to data in GitHub. Here are a few:

    Account Compromises

    In July of 2019, Ubuntu Security reported that the credentials for a company-owned GitHub account were compromised. These compromised credentials were used to create repositories, issues and more.

    In this case, critical infrastructure was decoupled from GitHub, and the breach wasn’t allowed to spread. However, Ubuntu had to restore various repositories and issue trackers to their previous state. When rolling back from an account compromise like this, backups are infinitely helpful, as they give you a previously good state to compare with the current state.

    Additionally, attackers often leave backdoors in compromised codebases. This can allow them to gain deeper access once the initial discovery and remediation process is completed. If you only have your infected codebase, it can be challenging to uncover all the infected files or identify possible vectors for future attacks. Restoring to a previous version of your code eliminates that threat.

    Ransomware Attacks

    Ransomware is the act of taking control of data and encrypting it so that only the attacker can unlock it. The attacker will usually ask for a ransom to unlock the files; otherwise, they may delete the data.

    In May 2019, ZDNet reported on a ransomware attack in which a hacker held various repositories hostage for a fee. The hackers modified the git histories to the point where the repositories were unusable, and they demanded payment within 10 days to reverse the changes.

    These attacks can create a severe disruption in operations. Developers will be unable to commit code, creating a complete stoppage in new feature development. Bug fixes and even support tickets (if managed through GitHub) could also be affected. However, restoring from a backup would allow a business to continue working.

    Service Downtime

    Depending on a third party always carries some risk, and GitHub is no exception. No service can deliver 100 percent uptime, but when your entire business (or codebase) depends on GitHub’s availability, you might want to mitigate that risk by having your own backups.

    For example, in June 2020, GitHub experienced a major, hours-long outage before stability returned. So, if all your work was stored in GitHub, you would have had to wait for access to be restored. This downtime can be devastating if it occurs during a crucial launch window.

    These are just three examples, and they happen more often than you think. A recent report by Oracle and KPMG found that 49 percent of IT professionals could attribute recent data loss to their failure to safeguard data. That’s essentially the same odds as a coin flip. Having continual access to all your work shouldn’t be left to chance. That’s why you need a backup strategy.

    Strategies for Backing Up Data in GitHub

    1. Managing Your Own Backups: This means you are responsible for all the infrastructure, business processes and ongoing repair costs to create the backups. You might think this will be a more cost-effective option, but the ongoing labor and maintenance expenses tend to add up quickly. It also means your team may use up cycles on something that is not part of the core business. What you make up for in control, you lose in time and spent resources.
    2. Using a Third Party to Manage Your Backups: Sometimes referred to as Backup-as-a-Service (BaaS), this involves outsourcing backup management responsibilities to a separate company. It removes the responsibility from your business, but it might seem more expensive upfront. In most cases, there is nothing to do after choosing a provider. They manage the entire process, from cradle to grave. This includes any API updates (which can happen often), implementation and ongoing maintenance. The drawback is that you lose control. Terms of service can change, or the data that’s backed up could change. And, not all BaaS solutions are transparent in what they do and how they access data.

    So, What’s the “Right” Choice?

    For most businesses, the sheer amount of work required to build and maintain backup software is a non-starter. Development cycles are too valuable to tie up with work not directly supporting the business’s product roadmap. You may get to a size where you think adding this competence makes sense; however, even some massive multinational corporations use some form of BaaS.

    Just make sure you do your research. Read reviews, speak to their sales or development team and confirm that they know what they are talking about. You need to determine if they have built a credible product. For many PaaS and SaaS tools, third-party backup applications are built by faceless companies with no track record. Considering the level of access they will have to your data, you want to ensure they are reputable with a proven history of successfully building backup software.

    Regardless of the method you choose, having a backup strategy in place is vital. Due to the nature of how GitHub works and how important your code repositories are to your business, the sooner you get something in place, the better.

  • Ransomware will Double in 2017. Are you Prepared?

    Ransomware will Double in 2017. Are you Prepared?

    A recent report found that ransomware attacks quadrupled in 2016, and are likely to double in 2017. Not surprisingly, a research survey showed that 48 percent of organizations had been hit by ransomware in the past year. And as we highlighted in a recent blog post, next generation cloud applications and databases are quickly becoming an attractive target for criminals.

    Attackers are targeting critical data or operations now, not just files. A few examples from the past two weeks highlight this trend:

    Attackers are getting much more clever and picking valuable targets within a business. It’s only a matter of time before ransomware hits cloud-based applications that run on these platforms. What can you do? Be prepared.

    A layered “onion strategy” means using a set of security tools to spot and isolate malware and ransomware, but that alone isn’t enough. The Department of Homeland Security issued an alert last year highlighting the key role backup plays in defending against ransomware:

    Employ a data backup and recovery plan for all critical information. Perform and test regular backups to limit the impact of data or system loss and to expedite the recovery process. Note that network-connected backups can also be affected by ransomware; critical backups should be isolated from the network for optimum protection.

    As the Texas police department example shows, recovering from a backup won’t work if the backup itself gets infected. A versioned backup of business data and files is essential to recovery. That’s where most backup solutions fall short, especially for next-generation applications and databases that cannot be quiesced to make a consistent backup copy across the database cluster due to their distributed nature. More importantly, given the large amount of data that is processed by these applications, it is critical that there is no bottleneck to data movement in and out of the cluster for an application consistent backup.

    — Jeannie Liou

  • Elasticsearch Ransomware Attacks Highlight Need for Better Security

    Elasticsearch Ransomware Attacks Highlight Need for Better Security

    Recently, reports surfaced that a large number of Elasticsearch servers fell victim to potential ransomware attacks. Ransomware is the type of malware a company doesn’t want on its systems or network. It takes systems hostage, most commonly by encrypting or stealing data, and exposes the owners to blackmail attempts. According to a report by the Herjavec Group, the cost of damages from ransomware was projected to reach $1 billion by the end of 2016.

    A new wave of ransom attacks observed over the last several weeks targets unsecured MongoDB databases. Security researchers Victor Gevers and Niall Merrigan call these attacks a “ransack,” and Merrigan estimates that more than 40,000 databases were impacted in the first two weeks alone.

    Now research shows that Elasticsearch servers, which are configured to be insecure so they can be accessed over the public internet, are being subjected to similar ransom attacks. Victor Gevers tweeted that within the first three days, 2,515 Elasticsearch servers were eradicated and ransomed and 34,298 vulnerable Elasticsearch instances are still open. In the following days, the number of affected servers has risen to more than 5,000. John Matherly, founder of Shodan, tweeted that the vast majority of vulnerable Elasticsearch servers are open on Amazon Web Services (AWS).

    If an Elasticsearch server is hacked, users will find data indices gone and a message that reads: “SEND 0.2 BTC TO THIS WALLET: 1DAsGY4Kt1a4LCTPMH5vm5PqX32eZmot4r IF YOU WANT RECOVER YOUR DATABASE! SEND TO THIS EMAIL YOUR SERVER IP AFTER SENDING THE BITCOINS…”

    The FBI stresses that victims should refuse to pay Bitcoin ransoms, so users might or might not get their data back depending on the security processes they had in place in case of an attack. At this point, it is unclear who is behind the attacks.

    Ironically, what makes these attacks possible is not that Elasticsearch in itself is insecure, because it isn’t. Ransom attacks are possible because these instances have been configured in a way that makes them vulnerable. It’s like leaving the front door open.

    Technology journalist Steven Vaughan-Nichols of ZDNet gave an excellent summary, explaining that, when used by amateurs without any security skills, Elasticsearch is simple to crack. The people deploying instances on AWS clouds are under the impression that AWS is protecting them, but that’s not the case. While AWS tells users how to protect their AWS Elasticsearch instances, users still need to do the work themselves.

    He notes: “The worst thing about this? Just like the MongoDB attacks, none of this would have happened if its programmers had protected its instances with basic, well-known security measures.”

    Elasticsearch is often used in log management, typically as part of the Elastic Stack or ELK, which stands for its main open-source ingredients of Elasticsearch, Lucene and Kibana. Since it’s free, open-source software, ELK is an easy first choice for many. It’s a great, powerful piece of software. These open-source projects are highly active, with thousands of code contributions every month and a growing combined code base of about 2.5 million lines of code.

    Users need expertise to deploy and run it efficiently and safely, though, and that means needing people in an organization with the skills and time to maintain ELK clusters. If these people leave, companies need to have a backup. If they aren’t willing or able to invest in these resources, they are likely to get into trouble, like this latest ransom attack situation illustrates.

    ELK is free software, but keep in mind what Richard Stallman, founder of the Free Software Foundation and the GNU Project, has to say about free: “’Free software’ is a matter of liberty, not price. To understand the concept, you should think of ‘free’ as in ‘free speech,’ not as in ‘free beer.’”

    Whether a company pays for a log management service or runs ELK, one approach isn’t necessarily better than the other. For some companies, it makes a lot of sense to run an in-house-built log management solution based on ELK, or even one built from scratch. For others, a delivered solution may be best.

    Regardless, companies and teams need to carefully evaluate if open source makes business sense and if they are realistically able to properly support the deployment without imposing risks. If these factors aren’t weighed or completed correctly, the number of Elasticsearch ransomware attacks will continue to grow and be a profitable endeavor for hackers.

    About the Author / Sven Dummer

    Sven Dummer is the senior director of product marketing at Loggly. Previously, Sven worked with Yahoo, Wind River (acquired by Intel), SUSE, and Microsoft in product development and management. At Intel, Sven also helped launch (and named) the collaborative Yocto Project, an open-source initiative that enables users to create custom Linux-based systems for embedded products regardless of the hardware architecture. Connect with him on LinkedIn and Twitter.

  • Murphy’s DevOps: The Internet Apocalypse

    Murphy’s DevOps: The Internet Apocalypse

    I’ve been immersed in cybersecurity for a good stretch, since it was known as just “infosec” and “security.” Over time, I’ve had opportunities to work with some brilliant minds and young-gun “hackers” (I’m not a name dropper, so I’ll refrain from using them as SEO-bait). I’ve watched attackers transition from being basement-dwelling teenagers to organized intruders to APTs. At one point or another, I’ve met all of Five Horsemen of the Internet Apocalypse: Scam, Extortion, Embarrassment, Theft and Death.

    The biggest cybersecurity news story of all time is still Edward Snowden. Fancying himself a “whistleblower,” champion of the Constitution and privacy rights expert, this fugitive data thief accused of espionage by the United States government has done more to force businesses and individuals to think about digital security and privacy than anyone or incident before him.

    Snowden aside, there are thousands of other stories about just how fragile our online lives and businesses are. If you were at the devopsy.kinsta.cloud Rugged DevOps event at RSA 2015 and caught the presentation by Wired cybersecurity and privacy writer Kim Zetter, “2015 — The Year in Hacks,” then you had a chance to get a great overview of some of 2015’s biggest digital crimes. You might have even noticed the Internet Apocalypse Horsemen riding through.

    With an ear to the ground on everything the NSA and APT-using hackers are guilty of, @KimZetter never fails to intrigue readers and live audiences. Whenever you read her stories or listen to her speak, you always walk away reassured that when all the smoke and headlines have cleared, the great deep-down reality is that everything we digitize is subject to the whim of Scam, Extortion, Embarrassment, Theft and Death. If you didn’t have a chance to attend, please enjoy some of the highlights listed below.

    China vs. U.S., Spy vs. Spy

    Internet Apocalypse

    She kicked off with the biggest hack of 2015: the one that penetrated the U.S. Office of Personnel Management (OPM). The full extent of the damage done and who the actual attackers were may never be fully realized. Were they Chinese spies, rogue hackers or a combination of both? What we do know is that it exposed millions of identities tied to covert U.S. operatives and their family members listed on security clearance forms. It may have even exposed personal information on everyone who has ever applied for a job with the federal government. One for-sure lesson is that even after several decades of security product development (with more than 800 available for review at RSA), the world is still in need of innovation in the space.

    Men Behaving Badly …

    Internet Apocalypse

    Some might argue that Embarrassment made a special appearance at Ashley Madison, but the fact that suicide was part of that hack leaves me to think that Death was the lead actor there. @KimZetter pegged the data theft as the most brazen hack of 2015. With 30+GB of account information stolen and dumped, login credentials for 32 million accounts purloined, credit card transaction information accessed and even several suicides tied to the incident, the hack again reminded the world that the great deep-down reality is that everything we digitize can be used by attackers to scam, extort, embarrass, steal and even kill us.

    From the Keyboards of Babes …

    Anyone at the presentation must agree that Embarrassment really stole the show in the hack of CIA Director John Brennan’s AOL email account. Allegedly perpetrated by a teenager, Zetter describes the incident more deeply in her October story: Teen Who Hacked CIA Director’s Email Tells How He Did It

    Internet Apocalypse

    Keep Calm and Internet On

    Anyone reading this may be walking away with a rather pessimistic view of our chances of remaining secure online. The truth, however, is that the existence of determined hackers should do no more to stop individuals or businesses from going online than road rage should to prevent anyone from getting behind the wheel of a car.

    If any lesson can be learned from news articles pumped out by @KimZetter and her peers, it’s that the world should continue to take full advantage of the Internet but to also take the time needed to apply effective security. Quite simply, we all should keep calm and Internet on …