Okta Worforce Identity Cloud has all three identity functions – identity access management, identity governance, and privilege access management – under the hood.

Identity is at the cornerstone of everything people do online – and is one of the biggest security challenges. In a bid to help organizations streamline how they manage logins and identity, Okta introduced the Okta Workforce Identity Cloud at its annual Oktane22 conference this week.

Organizations have to ensure that the right levels of access is given only to those authorized to have them. The fact that people are now more mobile than ever – they can be on any number of devices, in various geographic locations, and connecting to different networks – complicates the task even further. Organizations are also juggling identity and access requirements from customers, employees, contractors, and partners.

Workforce Identity Cloud unifies identity governance and administration, identity access management, and privilege access management. For many organizations, these three functions are often handled by three distinct tools, forcing security teams to cobble together integrations and handoffs that check users are who they say they are and to give them the right level of access for the task they are trying to accomplish.

The resulting effort tends to be cumbersome, brittle, and difficult to scale. It's also harder to identify the security gaps. Identity and access management providers are increasingly addressing the fact that IAM has to go hand-in-hand with identity governance and privileged access.

Workforce Identity Cloud brings together Okta's core identity and access management tools; Okta Identity Governance, which simplifies the process of requesting and granting access to resources; and Okta Privileged Access, which secures highly-privileged credentials for administrator and root accounts, as well as to monitor and record privileged access. There is also an orchestration layer for automation.

The platform provides identity validation services for consumers as well as for enterprise customers, according to Okta. Phishing-resistant measures include a WebAuthn allow list to restrict WebAuthn enrollment to specific hardware keys. IT can also manage passkeys and apply enhanced security checks for unmanaged devices. Most capabilities are available today, and more features (such as support for "highly regulated identity" management) will be added by the end of next year's second quarter, according to Okta.

"Workforce Identity Cloud unifies the identity market’s previously siloed legacy solutions into a cohesive and holistic offering that makes identity a growth driver for enterprises," Sagnik Nandy, President and Chief Development Officer, Workforce Identity at Okta, said in a statement.

Okta Launches New Workforce Identity Cloud

The line between criminal and political aims has become blurred, but motivations matter less than the effects of a breach.

Cybersecurity professionals have long discussed the notion that future conflicts will no longer be fought just on a physical battlefield, but in the digital space as well. Although recent conflicts show that the physical battlefield isn't going anywhere soon, we are also seeing more state-backed cyberattacks than ever before. It is therefore vital that businesses, individuals, and governments ensure they are prepared for an attack. In the digital battleground it isn't just soldiers being targeted — everyone is in the line of fire.

Broadly speaking, an act of cyberwar is any state-backed malicious online activity that targets foreign networks. However, as with most geopolitical phenomena, real-world examples of cyberwarfare are far more complex. In the murky world of state-backed cybercrime, it isn't always government intelligence agencies directly carrying out attacks. Instead, it's far more common to see attacks from organized cybercriminal organizations that have ties to a nation-state. These organizations are known as advanced persistent threat (APT) groups. The infamous APT-28, also known as Fancy Bear, that hacked the Democratic National Committee in 2016 is a great example of this type of espionage.

The loose ties between APT groups and state intelligence agencies mean the lines between international espionage and more traditional cybercrime are blurred. This makes defining whether a particular attack is an "act of cyberwarfare" difficult. As such, security analysts are often only able to hypothesize whether an attack was state backed by percentages and degrees of certainty. This, in a way, is the perfect cover for malicious state agencies that wish to target and disrupt critical infrastructure while lowering the potential for generating a geopolitical crisis or armed conflict.

**If the Enemy Is in Range, So Are You**

Regardless of whether a cyberattack is directly linked to a foreign state agency, attacks on critical infrastructure can have devastating consequences. Critical infrastructure does not just refer to state-owned and operated infrastructure such as power grids and government organizations; banks, large corporations, and ISPs all fall under the umbrella of critical infrastructure targets.

For example, a targeted "hack, pump, and dump" scheme, where multiple personal online trading portfolios are compromised in order to manipulate share prices, could be undertaken by a state-backed group to damage savings and retirement funds in another nation, with potentially catastrophic consequences for the economy.

As governments and private organizations continue to adopt smart and connected IT networks, the risks and potential consequences will continue to grow. Recent research by the University of Michigan found significant security flaws in local traffic light systems. From a single access point, the research team was able to take control of over 100 traffic signals. Although the flaw in this system has subsequently been patched, this highlights the importance of robust, up-to-date inbuilt security systems to protect infrastructure from cyberattacks.

**Defend Now or Be Conquered Later**

With larger and more complex networks, the chance that vulnerabilities can be exploited increases exponentially. If organizations are to stand any chance against a sophisticated state-backed attack, every single endpoint on the network must be continually monitored and secured.

Some have already learned this lesson the hard way. In 2017, US food giant Mondelez was denied a $100 million insurance pay-out after suffering a Russian ATP cyberattack because the attack was deemed to be "an act of war" and not covered under the firm's cybersecurity insurance policy. (The conglomerate and Zurich Insurance recently settled their dispute on undisclosed terms.)

Endpoint security has never been more critical than today. The use of personal mobile devices as a work tool has become pervasive across almost every single industry. Scarily, this rise in bring-your-own-devices policy has in part been driven by the false assumption that mobile devices are inherently more secure than desktops.

However, several governments and ATP groups with well-established cyber capabilities have adapted to and exploited the mobile threat landscape for over 10 years with dangerously low detection rates. Attacks on government and civilian mobile networks have the potential to take down large portions of a workforce, grinding productivity to a halt and disrupting everything from government decision-making to the economy.

In today's threat landscape, cyberattacks aren't just a potential risk but are to be expected. Thankfully, the solution to minimize the damage is relatively straightforward: Trust no-one and secure everything.

IT and security managers may not be able to prevent a cyberattack or a cyberwar; however, they can defend themselves against the worst outcomes. If a device is connected to the infrastructure, whether physically or virtually, it is a potential back door for threat actors to access data and disrupt operations. So, if organizations want to avoid being caught in the crossfire of cyberwarfare, endpoint security must be the first priority in all operations, from mobile to desktop.

Cyberwar and Cybercrime Go Hand in Hand

PIN-locked SIM card? No problem. It's easy for an attacker to bypass the Google Pixel lock screen on unpatched devices.

The November 2022 Android update includes a remediation for a bug that could allow an attacker to bypass the Google Pixel lock screen.

The researcher behind the discovery, David Schütz, reported the Google Pixel security flaw back in June after a series of errors led him to finding the vulnerability. He had forgotten his PIN after his device ran out of battery and died. After reboot, Schütz entered an incorrect PIN number three times, triggering the SIM card to lock itself. 

Luckily, he explained in a blog post this week, he had the original SIM packaging with the factory personal unlocking key (PUK) code to open the SIM card. From there he was able to gain access to the device without ever entering the correct PIN.

"After I calmed down a little bit, I realized that indeed, this is a got d\*mn full lock screen bypass, on the fully patched Pixel 6. I got my old Pixel 5 and tried to reproduce the bug there as well. It worked too," he wrote. 

The Google Pixel lock screen bypass vulnerability is tracked under CVE-2022-20465. Here are the bypass steps, according to Schütz: 

1.  Enter the wrong PIN three times.
2.  Hot-swap the device SIM for an attacker-controlled SIM with known PIN code.
3.  Enter the new SIM's eight-digit PUK code. 
4.  Enter the new device PIN.
5.  Presto! The device unlocks.

For his efforts, Schütz said he was awarded a $70,000 bug bounty, along with bragging rights. 

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

5 Easy Steps to Bypass Google Pixel Lock Screens

We commend vets in cyber, with this slideshow look at how the training and experience of former military personnel can be a big, differentiating asset in cybersecurity environments.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Veterans Day Salute: 6 Reasons Why You Want Vets in Your Cyber Platoon

Lea Kissner was one of three senior executives to quit this week, leaving many to wonder if the social media giant is ripe for a breach and FTC action.

Twitter CISO Lea Kissner has become the latest high-ranking executive to leave the company following Elon Musk's controversial $44 billion acquisition of the social media giant last month.

In a tweet Thursday, Kissner said they had resigned from Twitter but did not offer any reason for the decision. "I've made the hard decision to leave Twitter," Kissner wrote. "I've had the opportunity to work with amazing people and I'm so proud of the privacy, security, and IT teams and the work we've done."

It's unclear who is now in charge of security at the tech behemoth, or how much manpower is devoted to it. In the less than two weeks since he took charge, Musk has laid off some 3,700 Twitter employees so far, or roughly half of its workforce.

**Executive Exodus?**

Kissner's resignation follows the reported resignations of two other high-ranking Twitter executives this week: chief compliance officer Marianne Fogarty and chief privacy officer Damien Kieran. Casey Newton, founder and editor of Platformer, on Wednesday reported the exits of Fogarty and Kieran based on messages shared in Twitter Slack, which he claimed to have seen.

Twitter did not immediately respond to a Dark Reading request seeking confirmation of the reported resignations of Fogarty and Kieran.

Alex Stamos, former CSO at Facebook, described the exits of Kissner, Fogarty, and Kieran as a big deal for Twitter. 

"Twitter made huge strides towards a more rational internal security model and backsliding will put them in trouble with the FTC, SEC, 27 EU DPAs and a variety of other regulators," he said — ironically, in a tweet. "There is a serious risk of a breach with drastically reduced staff."

Many others also view the cuts and the exodus of senior executives — both voluntarily and involuntarily — as severely crippling the social media giant's capabilities, especially in critical areas such as security, privacy, spam, fake accounts, and content moderation.

"These are huge losses to Twitter," says Richard Stiennon, chief research analyst at IT-Harvest. "Finding qualified replacements will be extremely expensive."

Kissner's exit is sure to add to what many view as a deepening crisis at Twitter following Musk's takeover. Among those that have been axed previously are CEO Parag Agarwal, chief financial officer Ned Segal, legal chief Vijaya Gadde, and general counsel Sean Edgett. Teams affected by Musk's layoffs reportedly include engineering, product teams, and those responsible for content creation, machine learning ethics, and human rights.

For his part, Musk has described the cuts as being necessitated by a catastrophic drop in ad revenue because major companies are suspending their ad spending on the platform following his takeover.

**Potentially Severe FTC Impact**

Twitter's most immediate concern might be on the compliance front. In response to a Dark Reading inquiry, a Federal Trade Commission (FTC) spokeswoman said the agency is taking note of what's going on at Twitter.

“We are tracking recent developments at Twitter with deep concern," the spokeswoman said in an emailed statement. "No CEO or company is above the law, and companies must follow our consent decrees. Our revised consent order gives us new tools to ensure compliance, and we are prepared to use them.”

Twitter is currently already under heavy FTC scrutiny. In May, the agency slapped Twitter with a $150 million fine for violating the terms of a previous 2011 consent decree involving the use of deceptively collected data — such as email and phone numbers — for ad targeting.

In announcing the fine, the FTC also imposed fresh restrictions on the company's ability to use account security data to sell targeted ads. The FTC consent decree, among other things, prohibits Twitter's use of phone numbers and email addresses to serve ads. The decree requires Twitter to provide users with multifactor authentication options that do not involve phone numbers and requires the company to notify users about any improper use of phone numbers and emails and explain how they can turn off personalized ads. 

The FTC has also asked Twitter to strengthen its privacy program, implement a beefed-up information security program, and submit to security audits by an independent third party.

The company's ability to live up to these commitments is sure to remain a focus at the commission following the recent layoffs and executive exodus at the company. 

And indeed, Newton — the reporter who saw Twitter's Slack feed — quoted an employee as saying that for the moment, at least, it is up to Twitter engineers to “self-certify compliance with FTC requirements and other laws."

Stiennon says it would not be surprising if the three executives who resigned this week left because the new regime does not value what they do and treats their functions as secondary to the business goals.

"The teams have been cut to the quick," Stiennon says, "and the leaders are resigning because they cannot fulfill their responsibilities when they are understaffed and under resourced."

Twitter's CISO Takes Off, Leaving Security an Open Question

A dual Russian-Canadian citizen is being extradited to the US to face charges related to LockBit ransomware activities.

One of LockBit's alleged ringleaders has been arrested in Ontario, Canada and is on his way to the US to face charges related to ransomware attacks against at least a thousand victims, according to the Department of Justice.

Dual Russian-Canadian citizen Mikhail Vasiliev is accused of being behind LockBit ransomware, which first emerged in January 2020 and has grown into one of the most widely used variants in the world. According to the DOJ, members of the ransomware group have demanded at least $100 million in ransoms collectively, ultimately successfully extorting tens of millions from their victims.

Deputy Attorney General Lisa O. Monaco said in a statement about the charges that the DOJ hopes the arrest sends a clear message to other cybercriminals.

"This arrest is the result of over two-and-a-half-years of investigation into the LockBit ransomware group, which has harmed victims in the United States and around the world," Monaco said. "Let this be yet another warning to ransomware actors: working with partners around the world, the Department of Justice will continue to disrupt cyber threats and hold perpetrators to account. With our partners, we will use every available tool to disrupt, deter, and punish cybercriminals."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

LockBit Bigwig Arrested for Ransomware Crimes

Five practical steps to up-level attack surface management programs and gain greater visibility and risk mitigation around the extended ecosystem.

Modern IT environments are purposefully designed to be dynamic, evolving organically through things such as cloud computing, Internet of Things (IoT) devices, and, for many organizations, through mergers and acquisitions and supply chain business relationships. While enabling greater business efficiency and effectiveness, often infrastructure and data are added ad hoc without looping in the IT team or adhering to organizational security policies. The result is unmanaged or unknown infrastructure within the technology ecosystem, which introduces hidden risk.

Most security teams will acknowledge a lack of visibility in this dynamic environment. Whether it's credentialed access or missing agents, it's common to have a gap in visibility. However, unknown unknowns present an even more significant visibility challenge in most organizations.

**What Is an Unknown-Unknown Asset?**

Let's start by defining what we mean by unknown unknowns, or assets of which the security and IT teams have no awareness. Unknown unknowns can be introduced in a multitude of ways. For example, well-meaning developers with the ability to provision cloud resources on a personal credit card can spin up new database instances.

Consider capable contractors who can spin up their own infrastructure but forget to limit access to the code on GitHub. Or the business partners (third- and Nth-party suppliers) that are not accounted for in the extended enterprise ecosystem. Mergers are another common way that "unknown unknowns" are introduced — when the often outdated list of IT infrastructure doesn't meet the current reality of the infrastructure state.

With supply chain compromise on the rise and increasing organizational sprawl, how can organizations manage and mitigate risk from unknown unknowns?

**Closing Attack Surface Visibility Gaps**

To solve for unknown unknowns, security teams need to establish mechanisms and processes to maintain an up-to-date inventory of all _known_ assets associated with their organization and the vulnerabilities that can be used by threat actors as entry points into the network. The more known about the organization, the more information to perform active and continuous search for unknowns, and even fewer unknown unknowns.

Below are five practical steps to closing visibility gaps:

1.  **Enumerate and continuously monitor the asset inventory:** Create a process and workflow for continuous asset discovery that delivers a comprehensive inventory. Assets include internal and external resources, cloud resources, employees, and the supply chain. Externally accessible assets are often targeted by threat actors for initial access (MITRE T1190) by exploiting known vulnerabilities. In situations where a zero-day is disclosed, the security team can leverage the inventory to answer these questions: "Do we have that technology in our ecosystem and, if so, where?" and "Are we running the vulnerable version of the technology?"
2.  **Determine ownership of assets:** Attribution plays a big role in providing relevant information to the security team. Receiving a list of assets that may or may not be owned by your organization will slow down the team as they triage false positives (out-of-scope assets). At the onset of asset discovery efforts, the inventory should be audited to determine what is directly managed vs. shared security model (where the management of the asset is outsourced to a provider – such as a cloud service or SaaS provider). Management becomes easier over time as a security team establishes the baseline understanding of asset ownership.
3.  **Enrich assets with intelligence to identify and prioritize critical and high-severity issues**: The faster vulnerabilities are identified, the faster the security team can respond. Indicators of compromise (IoCs) and Dark Web monitoring can inform a security team of malicious activity involving the brand or an asset. Analysis based on incident response and adversary research can help defenders respond and prioritize appropriately based on how a vulnerability is being leveraged and the impact of exploitation. Recommended sources include NIST National Vulnerability Database (NVD), CISA's Known Exploited Vulnerability catalog, and intelligence feeds from the private sector.
4.  **Remediate and harden at scale****:** Prioritizing remediation and hardening efforts on the entry points that present the most risk to the organization is crucial to mitigation strategies. Critical and high-severity security findings should be investigated and remediated immediately. Over the medium and long term, the security team needs to be aware of and monitor for lower severity vulnerabilities that are often overlooked but can be used in tandem with easier-to-exploit vulnerabilities. Assign responsibility to the lower-priority items and set expectations for quarterly reporting on progress.
5.  **Regularly review assets for unknown unknowns — and integrate your findings into steps 1–4**: Information is only valuable if it's used. As more data is collected about an organization's attack surface, the information needs to be distributed to the appropriate teams within the organization and incorporated into the operational workflows across the security operations center (SOC) or intelligence organization. For example, the SOC team can leverage the latest information about potentially compromised devices to take specific threat-hunting actions and then implement mitigation strategies.

Managing and mitigating risk from known threats is challenging enough for already over-stretched security teams. By following the steps above, organizations can uplevel their attack surface management programs and gain greater visibility into potential risk within their extended ecosystem as well.

**About the Author**

    

Jonathan Cran is head of engineering, Mandiant Advantage Attack Surface Management, at Mandiant and was the founder and CEO of Intrigue prior to its acquisition by Mandiant in 2021. An experienced entrepreneur and builder, he's passionate about delivering high-quality outcomes and data-driven solutions, particularly when they require significant technical leadership. He is constantly striving to understand customers' challenges and deliver elegant solutions. His background includes hands-on experience as a security practitioner and leadership roles at companies such as Kenna Security, Bugcrowd, and Rapid7.

Managing and Mitigating Risk From Unknown Unknowns

KmsdBot takes advantage of SSH connections with weak login credentials to mine currency and deplete network resources, as it gains a foothold on enterprise systems.

A just-discovered evasive malware takes advantage of a key Internet-facing protocol to gain entry onto enterprise systems to mine cryptocurrency, launch distributed denial-of-service (DDoS) attacks, and gain a foothold on corporate networks, researchers have found.  

Dubbed KmsdBot by researchers at Akamai Security Research, the botnet infects systems via a Secure Shell Protocol (SSH) connection with weak login credentials, according to a report published Thursday. SSH is a remote administration protocol that allows users to access, control, and modify their remote servers over the Internet.

The botnet poses the most risk for enterprises that have deployed cloud infrastructure, or corporate networks that are exposed to the Internet, says Larry Cashdollar, principal security intelligence response engineer at Akamai.

“Once this malware is running on your system, it essentially has a toehold into your network," he tells Dark Reading. "It has functionality to update and spread itself, so it's possible it can burrow itself deeper into your network and surrounding systems.”

The researchers observed KmsdBot — which is written in Golang as an evasive measure — targeting an "erratic" range of victims, including gaming and technology companies as well as luxury car manufacturers, Cashdollar wrote in a Nov. 10 report. Golang is a programming language that's attractive to threat actors because it's difficult for researchers to reverse engineer.

Moreover, once it infects a system, the botnet does not maintain persistence, allowing it further to evade detection. "It’s not often we see these types of botnets actively attacking and spreading, especially ones written in Golang," Cashdollar wrote.

**Attack on Gaming Company**

The researchers detected KmsdBot when it dangled an unusually open honeypot in the hopes of luring attackers. The first victim of the new malware they observed was an Akamai client — a gaming company called FiveM that allows people to host custom private servers for Grand Theft Auto online, they said.

In the attack, threat actors opened a user datagram protocol (UDP) socket and built a packet using a FiveM session token. UDP is a communication protocol used across the Internet for time-sensitive transmissions, such as video playback or DNS look-ups.

"This will cause the server to believe a user is starting a new session and waste additional resources besides network bandwidth," Cashdollar wrote.

The researchers also observed a range of other attacks by the bot that were less specifically targeted, they said. They included generic Layer 4 TCP/UDP packets with random data as a payload, or Layer 7 HTTP consisting of GET and POST requests to either the root path or a specified path set in the attack command, he said.

And while the bot does have cryptomining capability, researchers did not observe this particular aspect of its functionality — only the DDoS activity, Cashdollar added.

In general, KmsdBot has a wide attack surface, supporting multiple architectures including Winx86, Arm64, mips64, and x86\_64, researchers said. It uses TCP to communicate with its command-and-control infrastructure.

**Avoiding and Mitigating Bot Attacks**

Despite the danger it poses to enterprises, they can avoid falling victim to the botnet by using common network security best practices that they really should be implementing anyway, Cashdollar says.

"The best way to prevent getting infected is to either use key-based authentication and disable password logins, or make sure you're using strong passwords," he tells Dark Reading.

Indeed, password compromise — whether it's by using stolen credentials or cracking a company's weak protections — remains one of the top ways threat actors access enterprise systems.

Beyond strong passwords, security experts recommend multifactor authentication, as well as more advanced solutions to solve this persistent issue. However, it's advice that remains unheeded by users in many corporate settings, leaving networks exposed to threats such as KmsdBot. 

Other easy steps organizations can take to protect themselves, according to Cashdollar, include keeping deployed applications up to date with the latest security patches, as well as checking in on them from time to time to ensure they remain secure.

Evasive KmsdBot Cryptominer/DDoS Bot Targets Gaming, Enterprises

Cloud storage databases, often deployed as "rogue servers" without the blessing of the IT department, continue to put companies and their sensitive data at risk.

A string of household names lately have been responsible for misconfigured cloud storage buckets overflowing with wide-open data — once again shining a light on a cybersecurity problem for which there seemingly is no plug.   

Just last week, security researcher Anurag Sen revealed that an Amazon server had exposed data on the viewing habits of Amazon Prime members. During the same period, news and media conglomerate Thomson Reuters acknowledged that three misconfigured servers had exposed 3TB of data through public-facing ElasticSearch databases, according to Cybernews, which revealed the issues. 

And In mid-October, Microsoft acknowledged that it left a misconfigured cloud endpoint open that could expose customer data, such as names, email addresses, email content, and phone numbers.   

"The issue was caused by an unintentional misconfiguration on an endpoint that is not in use across the Microsoft ecosystem and was not the result of a security vulnerability," Microsoft said in its statement on the misconfigured server. "We are working to improve our processes to further prevent this type of misconfiguration and performing additional due diligence to investigate and ensure the security of all Microsoft endpoints."

And indeed, the leaks are caused by a variety of misconfigurations rather than any bugs — ranging from insecure read-and-write permissions to improper access lists and misconfigured policies — all of which could allow threat actors to access, copy, and possibly alter sensitive data from accessible data stores.

"The main concern with this kind of leak is the high impact, and that is why the threat actors go after misconfigured storage \[servers\] and buckets," says Ensar Şeker, CISO at SOCRadar, the cybersecurity firm that discovered the Microsoft issue. "Once they discover \[the accessible data\], the bucket might ... contain huge amounts of sensitive data for one tenant \[or\] numerous tenants."

The security impact of misconfigured storage is not a new issue. The problem regularly ranks in the top 10 security issues included in the popular Open Web Applications Security Project (OWASP) Top 10 security list. In 2021, Security Misconfiguration took the No. 5 spot, up from No. 6 in 2017. The annual "Data Breach Investigations Report," published by Verizon Business, also notes the outsized impact of misconfigured cloud storage: Human errors accounted for 13% of all breaches in 2021, with report noting that misconfiguration "heavily influenced" the result  

**Rogue Servers: A Stealth Cloud Security Problem**

Overall, 81% of organizations have experienced a security incident related to their cloud services over the past 12 months, with almost half (45%) suffering at least four incidents, according to Venafi. The increase in complexity of cloud-based and hybrid infrastructure, along with a lack of visibility into that infrastructure, has caused the increase in incidents, says Sitaram Iyer, senior director of cloud-native solutions at Venafi.

"Yes, misconfigured cloud storage is one of the primary reasons for data leaks — I do believe that this is a trend," he says. "The increase in this trend is most often due to misconfiguration related to access controls: While only authorized users need to be allowed access to cloud storage, a simple mistake in configuration often enables \[any\] authenticated users to gain access."

Yet, often misconfiguration is not the original sin — instead, a worker or developer will deploy a "shadow" server, a container or storage bucket not known to the information-technology department and, thus, not managed by the company. "Shadow" data — stored in cloned databases test environments, unmanaged backups, and data analysis pipelines — is the main threat, says Amit Shaked, CEO and co-founder of Laminar, a cloud data security platform.

"Because it is unknown, it is at extra risk for exposure, which makes it a popular target for adversaries," he says  

**Better DevOps Automation Could Help**

Companies should regularly monitor their cloud assets to detect when a datastore or storage bucket may have been exposed to the public internet. In addition, when deploying cloud storage, using infrastructure-as-code (IaC) configuration files not only automates deployments but helps eliminate errors, according to data from Snyk, a maker of security services for the software supply chain.

Adopting IaC reduces cloud misconfigurations by 70%, according to the firm.

"When IaC isn’t being used, or when runtime misconfigurations can’t be tied back to the IaC templates that were used to create and manage an environment, it’s common for the same vulnerability to appear over and over again after remediation," Manoj Nair, chief product officer at Snyk, said in a statement sent to Dark Reading.

Part of the issue continues to be the division of responsibilities between cloud providers and the business customers. While the responsibility for configuring cloud assets belong to the customer, the cloud service should make properly configuring a cloud asset as easy as possible, Venafi's Iyer says.

"Principle of least privilege must be adopted for every aspect of the data," he says. "Access to data must be provided as needed, with proper controls and authorization policies that tie it to a specific user or service account, and proper logging of access and notifications must be implemented."

Amazon, Microsoft Cloud Leaks Highlight Lingering Misconfiguration Issues

StackRox bridges network security and other gaps and makes applying and managing network isolation and access controls easier while extending Kubernetes' automation and scalability benefit.

To reap the full benefits of Kubernetes and microservices-based application architectures, organizations must transform how they implement security. This transformation often reveals gaps and silos across the development and operations teams and processes. Case in point: the gap between developers and the network security team.

Based on survey results from more than 300 DevOps, engineering, and security professionals, the "2022 State of Kubernetes Security Report" (PDF) shows that security is one the biggest concerns about container and Kubernetes adoption, with respondents noting that security issues have caused delays in deploying applications into production.

Almost all respondents to the survey, 93%, said they had experienced at least one security incident in their Kubernetes environment in the last 12 months, with 31% reporting a revenue or customer loss due to a security incident.

Most of these incidents come down to human error, with more than half (53%) of respondents saying they had detected a misconfiguration in Kubernetes in the last 12 months. There are many best practices for avoiding Kubernetes misconfigurations, but the reality is that Kubernetes is large and has a certain amount of complexity to it. Gaps among roles, responsibilities, and skill sets — common, especially for companies refactoring legacy applications — leave the door open to vulnerabilities.

For example, developers and the network security team may be working, if not at cross purposes, then in silos. Developers historically haven't been the ones to implement network security — they would just throw apps over the wall and rely on the security team to take care of network configuration.

In a Kubernetes world, however, the onus for security is on DevOps — or, at least, that's the perception. And, it makes sense that people would think like that: The whole notion of "shift left" is that security is addressed as early in the development cycle as possible.

Indeed, according to the survey, DevOps is the role most often cited as responsible for securing containers and Kubernetes: 15% of respondents consider developers as the primary owners of Kubernetes security, with only 18% identifying security teams as being most responsible.

But shifting left is not enough, especially when zero-day exploits are a relatively common occurrence. Only tight collaboration across development, IT operations, and network and other security teams can reasonably secure applications against attackers— especially those who are looking for points of entry from which they can move as far along the kill chain as possible.

Organizations likely understand all of this in theory, but in reality, there's a bit of a no-man's land when it comes to network security and Kubernetes: Who manages and understands and reviews network configuration within the cluster? Who is identifying and remediating misconfigurations ?

The gap between developers and the network security team can grow wider as companies move toward a zero trust model. With zero trust, of course, nothing is trusted. But businesses can't run that way. At some point, someone has to provide permissions to specific applications and services to communicate with each other.

**Kubernetes' NetSec Conundrum**

By default, Kubernetes deployments don't apply network policy to Kubernetes pods. Without network policies, any pod can talk to any other pod or network endpoint — the equivalent of a computer without a firewall. Someone must go in and define ingress and egress network policies that limit pod communication to defined assets.

In the past, developers indicated what communications paths needed to be made available, and network administrators made those paths available via traditional firewall configurations.

The problem is that network security engineers do not speak the Kubernetes language. In a Kube world, everything you do around network security needs to be written in YAML, a data serialization language, but network security engineers think in terms of IP addresses and IP tables. The NetSec team doesn't really understand the language that policies are written in, and the tools aren't familiar to them.

One tool that bridges network security and other gaps is StackRox, a cloud-native open source project that provides organizations with tools, training, and a community of shared experiences with building Kubernetes security implemented as security policies that can be used to monitor Kubernetes clusters and the workloads running on those clusters.

When it comes to network configuration, StackRox enables developers and security teams to visualize existing versus allowed network traffic. Using Kubernetes-native controls, NetSec teams can then more effectively enforce network policies and tighter segmentation. StackRox recently added a new feature to help developers define network policies prior to deploying their application to Kubernetes. This was developed in partnership with the developers of the np-guard project. StackRox roxctl now has the option to call np-guard to generate network policies by analyzing resource YAMLs.

With the StackRox project, organizations can address all significant security use cases across the entire application life cycle. Apropos of what I mentioned above, StackRox eases the process of applying and managing network isolation and access controls for applications. Other use cases include:

**Vulnerability management:** StackRox helps organizations protect against known vulnerabilities by identifying vulnerabilities in images and running containers.

**Security configuration management:** Organizations can leverage StackRox to ensure that Kubernetes is configured according to security best practices.

**Risk profiling:** StackRox provides the context needed to prioritize security issues throughout Kubernetes clusters by analyzing a variety of data about deployments.

**Compliance:** Organizations can leverage StackRox's compliance policies to meet contractual and regulatory requirements.

**Detection and response:** StackRox provides incident response capabilities, enabling organizations to address active threats in their environments.

In general, using Kubernetes-native controls such as StackRox — in other words, using the same infrastructure and its controls for application development and security — enables companies to go from shifting security left to shifting it to a 360-degree cycle, all while extending Kubernetes' automation and scalability benefits.

You can download StackRox from GitHub here. There you will also find related projects such as KubeLinter, a static analysis tool that enables developers to easily check Kubernetes YAML files, and Helm charts to identify misconfigurations and enforce security best practices.

Source

DARKReading