Sysdig is pleased to support AWS today in their GA launch of Bottlerocket, a special-purpose operating system designed for hosting Linux containers. Orchestrated container environments run potentially hundreds of compute nodes. Operating general-purpose Linux on container hosts introduces complexity for IT teams who must patch and update packages across their clusters. Worse, features and packages that are not necessary for running containers, introduce unnecessary security exposure.

Attackers were quick to exploit the COVID-19 pandemic, with coronavirus-themed phishing campaigns, Trojans delivering ransomware and backdoors, and other scams. Netskope Threat Labs have been keeping a close eye on the threat landscape and tracking COVID-related campaigns throughout this unprecedented time.

According to its own website, FedRAMP serves three different of partners: federal agencies, Cloud Service Providers (CSP) and third-party assessment organizations. This article will focus on CSPs and how a good CSP can provide services that provide monetary savings for your agency.

Imagine you’ve protected your production Google Cloud environment from compromised credentials, using MFA and a hardware security key. However, you find that your GCP environment has been breached through the hijacking of OAuth session tokens cached by gcloud access. Tokens were exfiltrated and used to invoke API calls from another host. The tokens were refreshed by the attacker and did not require MFA. Detecting the breach via Stackdriver was confusing, slowing incident response.

Cloud storage has become mainstream. It is one of the fastest-growing segments of IT spending and an indispensable tool for many modern businesses. However, not enough is being done to secure data residing in the cloud. According to Gartner, 90% of organizations that fail to control public cloud use will share information inadvertently or inappropriately through 2025. Almost all cloud security failures will be due to the cloud customer, not the service provider.

Recently I participated in a webinar with Toks Oladuti (Netskope customer, and senior IT security manager at the international law firm Herbert Smith Freehills), and my colleague Neil Thacker (Netskope’s CISO EMEA). The conversation was hosted by Janet Day, a long-time technology consultant to the legal industry. During the webinar, we touched on a lot of topics and I was particularly interested to hear Toks’ stories of HSF’s journey to the cloud.

“Ev, do you have time later today to discuss the new web GUI for the command line terminal?” said the Slack message. It came from Alex, our user experience chief and the product in question is the SSH client. Part of me was worried. The command line environment had a sanctuary where I found peace and happiness away from the world of browser-based tools.

As many organizations have migrated their infrastructure, applications, and data to cloud offerings, adversaries have extended their operational capabilities in cloud environments to achieve their mission — whether that means stealing intellectual property, disrupting business operations, or holding an organization’s data for ransom.

Did you know that the default “copy link” option in O365 personal accounts generates a public shared link with edit permissions? In this edition, we will cover how link sharing in O365 can lead to the accidental internal and public exposure of sensitive data.

“Send it to the cloud” has been the increasingly common response over the years for dealing with the issue of how to handle massive amounts of data. On one side, I understand it. Another infrastructure owned by a third party who has teams dedicated to implementing security by design, continuous testing and validation – this all sounds attractive.

There’s no doubt that the adoption of public cloud deployments has accelerated for most organizations recently. In fact, according to metrics released by Oracle recently, nearly half (49%) of all respondents to the Oracle and KPMG Cloud Threat Report expect to store most of their data in a public cloud by the end of 2020. Effectively managing the security and compliance of public cloud deployments can be tricky for many organizations.

Cloud computing provides undeniable benefits for storing and accessing electronic health records. Files stored in the cloud are accessible anytime and anywhere from any device, which makes it easy to share critical medical information between healthcare workers. But is cloud storage secure enough to store, access and transfer sensitive personal and medical information?

Threat actors are leveraging top tier cloud apps to host phishing baits. Netskope Threat Labs has identified an ongoing O365 phishing campaign hosted in Google App Engine with the credential harvester mostly hosted in Azure App Service. This phishing campaign typically targets O365 users via phishing emails with a direct link or attachment.

Cloud misconfigurations are no laughing matter. In its “2020 Cloud Misconfigurations Report,” DivvyCloud revealed that 196 separate data breaches involving cloud misconfigurations had cost companies a combined total of approximately $5 trillion between January 1, 2018 and December 31, 2019. The problem is that those costs could be even higher; as reported by ZDNet, 99% of IaaS issues go unreported.

A phishing campaign abused both the Google App Engine and the Azure App Service to steal victims’ Microsoft Outlook credentials. Netskope observed that the attack campaign started with a shortened link distributed by a phishing email. This link redirected a recipient of the email to a Google App Engine domain.

Amazon Web Services provides its users with the ability to create temporary credentials via the use of AWS Security Token Service (AWS STS). These temporary credentials work pretty much in the same manner like permanent credentials created from AWS IAM Service. There are however two differences.

Netskope, CrowdStrike, Okta, and Proofpoint are joining together to help better safeguard organizations by delivering an integrated, Zero Trust security strategy that is designed to protect today’s dynamic and remote working environments at scale.

Did you know that in the United States, the Social Security Number was never intended to become the defacto method for physical identification? On its surface, this may come as a shock given how ubiquitously SSNs are used for this exact reason, but looking beneath the surface, we find that SSNs are terrible forms of identification. Ignoring the security concerns of a nine digit numeric code, an SSN is not for universal identification.

When it comes to modern software development, collaboration is the name of the game; to this end, development teams have more than ample selection of tools at their disposal these days.