Companies must enforce more security on their own third-party providers and retain the ability to conduct independent investigations, experts say.

Identity cloud provider Okta concluded its investigation into a recent breach of its systems by the Lapsus$ extortion group, which gained access to some of company's systems through a third-party contract firm and then revealed the compromise in March.

The breach impacted only two customers, with the hackers maintaining control of a single computer at contract firm Sitel for a 25-minute period, Okta said in the postmortem analysis published on Tuesday. While the identity and access management firm had initially considered as many as 366 customers at risk, the impact ended up being far less, David Bradbury, chief security officer at Okta, stated in the analysis.

The breach caused consternation within the security community because of the lack of notice from Okta and worries that access to the company's systems could undermine much of the security of its single sign-on (SSO) services — an issue of trust that Bradbury acknowledged.

"While the overall impact of the compromise has been determined to be significantly smaller than we initially scoped, we recognize the broad toll this kind of compromise can have on our customers and their trust in Okta," he said, adding: "The conclusions from the final forensic report do not lessen our determination to take corrective actions designed to prevent similar events and improve our ability to respond to security incidents."

To head off attacks in the future, Okta intends to create more stringent security requirements for third-party contractors and have processes in place to confirm compliance. The company has already cut ties with Sitel, according to the postmortem report.

The Okta breach raised the profile of attacks on software supply chains and third-party providers, adding on to lessons from previous compromises such as SolarWinds and Kaseya, says Merritt Maxim, vice president at business intelligence firm Forrester Research. Third-party firms and service providers need to have measures in place to continuously assure customers that their services are secure, he says.

"This is an issue that has to be front and center for security organizations, to push beyond doing just security questionnaires for providers, to doing actual assessments and auditing of third parties," he says. "Simulate breaches and test your incident response plans, and rather than rely on the vendors to do it perfectly, you should be determining what you can do in response to a breach."

**Conduct Your Own Investigation**  
When a breach happens in a third-party provider, such as Okta or its own third-party provider Sitel, companies either are left in the dark or must pursue their own investigation. Whether Okta knew of the breach and failed to notify customers for two months, or the company failed to understand that a contractor's computer had been compromised, businesses need to be ready to verify the details of an incident, members of Cloudflare's security team argued in a March blog post.

Cloudflare has to verify its own systems, since some of the screenshots in leaked by Lapsus$ group appeared to indicate that they may have had access to Cloudflare's instance of Okta. As soon as a provider is breached, companies should have a playbook in place to spell out the steps that need to be taken to assure the integrity of their systems, such as checking all passwords and verifying changes to multifactor authentication with special attention paid to any event initiated by the support group.

To facilitate future investigations, Cloudflare's security team recommended that companies store logs from third-party services on their own premises to have a verifiable copy.

"For years, it has been a struggle to work with different software as a service provider to get all the logs ourselves," says Joe Sullivan, chief security officer at Cloudflare. "Too many times in the past, we have thought there was a risk and we did not have the logs, so we are very proactive."

For its part, Okta maintains that the company did not know about the severity of the issue until March 17, when Sitel sent their summary report, which they then connected with the Lapsus$ screenshots a few days later. "We recognized what appeared to be a connection to the January failed takeover attempt we observed and reported to Sitel," an Okta spokesman said. "We've publicly said we didn't understand the extent of the Sitel compromise in January, and if we had, our actions would have been different."

**Cloud Rife With Single Points of Failure**  
The incident also underscores that while cloud providers typically raise their customers' level of security, the cloud attracts attacks because so much access is concentrated in a small number of providers. Companies should always start by conducting a threat assessment to understand the risks presented by any infrastructure that they move to the cloud, Sullivan says.

"You look at what is the worst that could happen, and how do you mitigate that risk," he says. "If a compromise of a system could lead to a bunch of customer data getting exposed or intellectual property being accessed, then you need to go further."

In the end, while the cloud model asserts that responsibility for security is shared, companies need to understand that that they need to take their fate into their own collective hands, says Forrester Research's Maxim.

"Don't assume that the vendor is going to take care of security and will do it all perfectly," he says. "Have the right playbooks and policies ready to go, so if there is an incident, you can take action whether the vendor is ready or not."

For its own part, Okta plans to directly manage even third-party devices that access its customer-support tools so as to maximize visibility into potential security threats, and it will limit the amount of information that support personnel can view, Bradbury said in the company's postmortem analysis. In addition, as a third-party provider itself, Okta plans to review how to better communicate incidents with its customers.

_Editor's note: This story was updated on April 21 with a quote from an Okta spokesman._

Okta Wraps Up Lapsus$ Investigation, Pledges More Third-Party Controls

Cloud security is constantly evolving and consistently different than defending on-premises assets. Denonia, a recently discovered serverless cryptominer drives home the point.

One of the more important points to get across when addressing cloud security is to make it clear to all involved that cloud security is not only different, but that it keeps evolving. If security professionals needed a reminder of this, they need to look no further than the recent discovery of Denonia, a cryptominer that operates in serverless environments.

Denonia was found by the Cado Security research team, and it released details a few days ago. Denonia is a Go-based cryptominer malware, and it appears to be the first such malware to specifically exploit AWS Lambda, the well-known serverless function execution service. The researchers indicate that Denonia was not widely disseminated and that it executes the XMRig mining software for stealing CPU cycles for mining Morero, while using techniques such as DNS-over-HTTPS (DoH) for evasion. The initial deployment mechanism is unknown but may be a matter of overprivileged environments.

While small in scope, Denonia is notable for its use of the cloud technology stack as intended —it's a Lambda function executing on a Linux environment like any other. This is interesting, as it means similar malware can execute in other serverless function execution environments from other cloud providers as well.

**How the Vulnerabilities Differ**  
To be clear, this is different than some of the vulnerabilities that have been reported across major providers recently, such as ChaosDB (a flaw in Azure's CosmosDB service found by the Wiz security team last year), AWS CloudFormation and AWS Glue issues found by Orca Security, and some of the Google Cloud GKE vulnerabilities raised by the Palo Alto Networks Unit 42 security research team. In those cases, the cloud providers worked directly with the research teams to address those issues.

When discussing cloud security, too often we hear some confusion about security responsibilities. While cloud providers have worked to clarify some of this via their different "shared responsibility models," end-user organizations retain the overall responsibility for securing their cloud estates. Cloud providers are responsible for the structural security of the cloud environment itself, but customers are responsible for the workloads. This includes both ensuring that environments have been properly configured with the adequate mixture of configurations that yield capabilities and privileges — often the realm of cloud security posture management (CSPM) and cloud permissions management (CPM) offerings — and also ongoing monitoring of the multiple events taking place within those cloud estates, which may fall under cloud workload protection platforms (CWPP) or even cloud detection and response (CDR).

The lesson, then, to be learned from the discovery of Denonia is that cloud security keeps evolving: Runtime threats against an organization are not simply the same malware that would execute on a virtual machine but evolve into containers — indeed, exposed container management interfaces or those with poor authentication are often used to launch unauthorized workloads — and now serverless workloads. Organizations looking to address this dynamic need to have the right elements of people, processes, and technology to properly understand the new threat landscape, to look deeply into their cloud stack, and to work together with their cloud engineering and development teams.

Denonia Malware Shows Evolving Cloud Threats

The Russian government is ratcheting up malicious cyberattacks against critical infrastructure in countries supporting Ukraine.

The US, Australia, Canada, New Zealand, and the UK today issued a detailed joint advisory on the increased risk of cyberattacks out of Russia — both nation-state espionage and cybercriminal activity.

The advisory, issued by the Cybersecurity and Infrastructure Security Agency (CISA), warns that Russia's invasion of Ukraine could expose organizations both within and beyond the region to increased malicious cyber activity and that the Russian government is actively trying to use cyberattacks against global organizations as a weapon in its war on Ukraine.

Security teams, including those with critical infrastructure providers in the US and beyond, need to prepare for these threats and shore up their defenses against malware, ransomware, distributed denial-of-service (DDoS) attacks, and cyber espionage. The Russian government is attempting to use cyberattacks in retaliation for sanctions as well as support being provided to the Ukraine defense efforts, according to the advisory.

Cybercrime groups have "threatened to conduct cyber operations against countries and organizations providing materiel support to Ukraine," according to the advisory. "Other cybercrime groups have recently conducted disruptive attacks against Ukrainian websites, likely in support of the Russian military offensive."

In a related development, CISA Director Jen Easterly today also announced the addition of a number of industrial control systems (ICS) companies have now joined the Joint Cyber Defense Collaborative (JCDC), a CISA initiative of government and private industry experts to coordinate on US cyber-defense operation plans for protecting and responding to cyberattacks and threats. Members of the JCDC co-authored the joint advisory CISA published today with its international partners.

The new ICS vendors include Bechtel, Claroty, Dragos, GE, Honeywell, Nozomi Networks, Schneider Electric, Schweitzer Engineering Laboratories, Siemens, and Xylem, among others. 

 "As the destruction or corruption of these control systems could cause grave harm, ensuring their security and resilience must be a collective effort that taps into the innovation, expertise, and ingenuity of the ICS community," Easterly said in her announcement of the JCDC news during the ICS conference S4x22 in Miami. "I’m excited to leverage our evolving JCDC platform to enable us to plan, exercise, and collaborate with industry leaders to drive down risk to the systems and networks we depend on so greatly as a nation.”

CISA, Australia, Canada, New Zealand, & UK Issue Joint Advisory on Russian Cyber Threats

Stuxnet was the first known malware built to attack operational technology environment. Since then, there have been several others.

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

6 Malware Tools Designed to Disrupt Industrial Control Systems (ICS)

Supply chain security attacks have been becoming increasingly common and more sophisticated. Find out how to remain secure throughout the software supply chain.

Software supply chain attacks are becoming more frequent and introducing bigger consequences. This highlights the need for a structured response by policymakers and the security community, which is now in development. But organizations can implement their own software supply chain security strategies as well.

**What Is the Software Supply Chain?  
**The software supply chain consists of code and binaries, and the development teams, tools, and processes involved in building, packaging, and deploying applications. Modern software development has made the supply chain increasingly complex. Reasons for this include:

*   **Product innovation:** Consumers today expect cutting-edge products, which drives software vendors to deliver more innovation.

*   **External services**:**** Organizations now outsource elements that are not core to their business, such as payment, navigation, and translation.

*   **New technology**:**** New operating systems, processors, and graphic chips increase the complexity of software.

*   **Practices**:**** Modern practices like agile development, CI/CD, and DevOps have together accelerated the pace of product delivery.

*   **Code**:**** Code used to build an application contains many ingredients, including custom code, open source dependencies, build and packaging scripts, containers, and infrastructure.

These elements combined create complex software supply chains, which are an attractive attack vector and target for malicious actors.

**Software Supply Chain Attacks  
**Attackers use malicious code in an "upstream" component in the software supply chain with the goal of compromising the target of the attack: the "downstream component." Any link in the software supply chain can be compromised, but current research highlights three main targets: dependencies, pipelines, and the combination of both — pipeline dependencies.

**—Dependencies  
**Application dependencies — open source packages or container images — introduce vulnerability. Attackers insert malicious code into publicly accessible packages, and that code is automatically downloaded by unsuspecting developers.

**—Pipelines  
**Development pipelines used to build and release software can also be compromised. Attackers inject malicious code into the code itself defining the build process — such as CI scripts or build tooling configurations. Then attackers can use the build pipeline to distribute malicious code to downstream consumers.

**—Pipeline Dependencies  
**External dependencies within the build pipeline, such as third party plug-ins, tooling binaries, or the build environment itself, can also be targeted by attackers.

**Best Practices for Software Supply Chain Security  
**These best practices can improve security around your own software supply chain.

**—Use SCA and SAST  
**Software composition analysis (SCA) tools help you integrate security testing early and throughout the software development process to mitigate risk in open source packages being pulled into an application (including transitive dependencies). SCA tools also detect open source software licenses to help organizations ensure compliance with legal requirements.

Static application security testing (SAST) tools check custom code for security issues. Using a SAST tool can inform you of the risks resulting from the combination of supply chain components and your custom code.

**—Secure Your Containers  
**Base images from trusted providers should be free from malicious software, but still often have vulnerabilities in the Linux packages and developer tools they supply. A container security tool can help mitigate risk in a container image, and should also identify application components inside containers, especially in cases where direct access to the source code is not an option.

**—Utilize the SBOM  
**A software bill of materials (SBOM) provides details on all components included within a supplied product: open source dependencies, containers, and build tools. Generate and maintain SBOMs to track your third-party dependencies, tools, and sources. Always require an SBOM from third-party vendors before or during procurement of new software, and routinely scan it for security risks.

**—Manage Source Code Carefully  
**Source code management systems (SCM), like GitHub or Atlassian Bucket, are the central hub for an organization's software development. Modern SCMs provide specialized features and configuration settings, such as access policy controls and branch protection, that can be leveraged to harden security. These mechanisms are not always enabled by default and must be explicitly set.

**—Secrets and Credentials  
**Today's workflows use different types of credentials for access control, including encryption keys, SSH keys, and API tokens. When exposed, these credentials can be used by attackers. To mitigate risk, use a secret management tool to store and encrypt secrets and enforce access controls. Scan source code repositories to ensure secrets are not committed by mistake, automate service account rotation for credentials, and assign restrictive permissions to tokens.

**—Implement DevSecOps Practices  
**DevSecOps integrates security practices into a DevOps model. The key element of DevSecOps is to integrate security as early as possible, and throughout, the life cycle of software development. DevSecOps is a continuous cross-team effort and cannot be achieved without a deep change in organizational culture.

**Keep Your Software Supply Chain Secure  
**Software supply chain attacks will likely increase in both frequency and complexity, affecting more organizations and exacting a growing cost. However, with careful planning and implementation of best practices, organizations can move toward a much more secure software supply chain.

**About the Author**

    

Mic McCully is a Field Strategist at Snyk with a focus on modern application security. In his role as a Field Strategist, Mic spends his time sharing the Snyk vision and strategy while also gathering and collecting insight of security priorities from the market. His background spans over 27 years in the software industry with close to 17 years of that focused on the security space.

The Modern Software Supply Chain: How It's Evolved and What to Prepare For

Module enables apps to establish trust in new devices without adding user friction.

**Palo Alto, CA -- April 20, 2022 --** Mobile authentication pioneer Incognia, today announced the launch of a new location identity fraud detection module to support mobile app security for customers across finserv, crypto, social networks, online gaming and more. Incognia’s latest solution module is Location-based Device Authorization which prevents fraud following device change at login.

Authorization of new devices on mobile is one of the highest friction and highest risk points in the user journey. When new devices attempt a login, the challenge is determining whether this is the legitimate user, or a fraudster using social engineering to get access to the user's credentials. Traditional device fingerprinting solutions are useless in establishing trust in new devices, and as a result most organizations have been forced to employ multi-factor authentication (MFA), which increases user friction and ultimately creates a poor user experience. The Incognia Location-based Device Authorization solution is designed to address the challenges of establishing trust in new devices without adding user friction.

Incognia provides a highly accurate risk signal using anonymized location behavior and device intelligence to detect high risk devices attempting to login before fraud occurs. At login, Incognia delivers a risk assessment based on checking the device integrity and whether the current device location is consistent with the user’s historical location behavior pattern. In an internal study, Incognia identified that 89% of legitimate device authorizations occur at trusted locations, which are places that the user visits most frequently, such as home.

Key benefits and features include:

\- Reduced friction when legitimate good users change their mobile device

\- Reduction in account takeovers due to social engineering

\- Real-time validation of trusted devices with global geographic coverage

“The frequent use of one-time passwords over SMS for new device authorization in mobile apps is causing users unwanted friction and frustration, while also serving as an inadequate security measure to keep fraudsters out,” said André Ferraz, founder and CEO of Incognia. “We’re excited to expand Incognia’s fraud prevention capabilities with our new module, using anonymized location behavior and device intelligence to detect high risk devices attempting login and catch fraud before it happens. Leveraging trusted location behavior allows our customers to enable a frictionless authentication experience.”

Incognia fraud prevention modules are available now. To get started, visit www.incognia.com.

**About Incognia**

Incognia is a privacy-first location identity company that provides frictionless mobile authentication to banks, fintech and mCommerce companies, for increased mobile revenue and lower fraud losses. Incognia’s award-winning technology uses location signals and motion sensors to silently recognize trusted users based on their unique behavior patterns and is a key enabler for zero-factor authentication. Deployed in over 200 million devices, Incognia delivers a highly precise risk signal with extremely low false positive rates.

Incognia is privately held and headquartered in Palo Alto, California with teams in New York and Brazil.

Stay connected and follow Incognia on Twitter and LinkedIn.

Incognia Introduces New Location-Based Device Authorization Solution

Users can scan GitHub repositories and detect misconfigurations, exposed secrets and other security issues.

TEL AVIV, Israel , April 20, 2022 /PRNewswire/ -- Lightspin, the next-generation cloud security platform, today announced an integration with GitHub that will allow organizations to scan their Infrastructure as Code (IaC) files to proactively prevent code with misconfigurations from being deployed. By detecting and fixing security issues before they are deployed to the cloud, Lightspin helps organizations embrace a "shift left" approach to security.

Shifting security left is a growing trend that requires organizations to detect security issues earlier in the software development life cycle. Yet 77% security professionals think developers find too few vulnerabilities too late in the process, according to a 2021 study. Lightspin helps security and DevOps teams to better understand the security posture of their repositories while saving time and more efficiently using technical resources.

"As IaC adoption soars, it's increasingly important for organizations to understand the security risks and complexities that go along with it," said Or Azarzar, chief technology officer and co-founder of Lightspin. "Misconfigured code and over permissive identities introduced into production can prove to be costly for security teams. Scanning IaC files proactively to prevent these issues from ever being deployed gives organizations peace of mind that they have protected their cloud environment."

Lightspin integrates via a GitHub application to scan repositories for security issues, then prioritizes an organization's repositories based on detected security findings. Once complete, a security or DevOps team can easily view the findings of each file, folder, or repository. Additionally, Lightspin provides an impact log to help teams track changes to their repositories, scanning all pull requests and highlighting the changes that had the biggest impact on their security posture. Security teams can review the details of the pull request to better understand the context.

The GitHub integration is available globally to Lightspin customers at no additional cost. To scan IaC files, users simply install the GitHub app on their repositories.

**Follow Lightspin  
**LinkedIn: https://www.linkedin.com/company/lightspin/  
Twitter: @lightspintech  
Blog: https://blog.lightspin.io/

**About Lightspin  
**Lightspin's next-generation cloud security posture management (CSPM) solution secures cloud and Kubernetes environments from build to runtime and simplifies cloud security for Security and DevOps teams. Using advanced graph-based technology, Lightspin empowers cloud and security teams to eliminate risks and reduce effort by proactively and automatically detecting all vulnerabilities, smartly prioritizing the most critical issues, and easily remediating them. For more information, visit https://www.lightspin.io.

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

Lightspin Secures Infrastructure as Code Files with New GitHub Integration

Sanctions imposed by the Biden administration, coupled with Russia's proposed initiative to cut itself off from the global Internet, is causing cybercriminals to ponder their future.

Russian cybercriminals dominate the threat landscape, aided largely by a government that has heretofore turned a blind eye to their illicit dealings — as long as their attacks target organizations and individuals outside of Mother Russia. However, since Russia's invasion of Ukraine on Feb. 24, the Kremlin has made a series of moves that threatens to disrupt the delicate balance that exists between them.

Without an extradition treaty with the United States, most of these cybercriminals operate with impunity or are nabbed when traveling outside of the United States. But in recent months this has not been the case. Several administrators and hosting providers were arrested in Russia in the past year for allegedly breaking the unspoken agreement between the government and cybercriminals. On Jan. 14, the Federal Security Service of the Russian Federation (FSB), in concert with US authorities, arrested members of the REvil ransomware-as-a-service (RaaS) collective that was responsible for the Kaseya attack. About a week later, the FSB detained four members of the Infraud Organization, including the group's founder, Andrey Novak, who was also wanted by the FBI. Though Russia is responsible for detaining these cybercriminals, these arrests and illicit marketplace takedowns have been few and far between and seem to signal more of a public relations ploy than a formal desire to stop cybercrime that affects its Western counterparts; there is no formal cyber alliance between Russia and the United States.

In some ways, Russian cybercrime has always been different, even in the underground. Russian cybercriminals, often young men, have had the autonomy to target foreign victims and establish various Dark Web-based marketplaces, card shops, and forums that attract like-minded threat actors. Wanted posters for these cybercriminals may very well be accompanied by images that showcase their Instagrammable lifestyles — poses that include expensive luxury automobiles, exotic cats, and stacks on stacks of US dollars.

**Connection to Cybercrime  
**There is a demonstrable connection between the Russian government and cybercrime. Public records show that Alyona Eduardovna Benderskaya is the wife of "Evil Corp" ringleader Maxim Yakubets and daughter of FSB agent Eduard Bendersky. The exotic cat-wielding Bogachev has also been associated with Yakubets regarding money laundering for various malware schemes. Former cybercriminal-cum-FSB officer Dmitry Dokuchaev sought the services of Shaltai-Boltai ringleader Vladimir Anikeyev and Yahoo breachers Alexsey Alexseyevich Belan and Karim Baratov. Dokuchaev was also sentenced to six years in prison for treason, so perhaps there is no love lost there. Aleksei Burkov, founder of cybercrime forum "DirectConnection" and co-administrator of "MazaFaka," was recently released from the United States and returned to Russia short of his nine-year sentence. Despite these indictments, all of these Russia cybercriminals remain at large, housed and protected in Russia.

But Russia may unconsciously be eating its own: Russia's war with Ukraine has resulted in a global effort to isolate Putin and, as a result, Russian cybercriminals are feeling the pressure.

For one, Russia has taken an aggressive stance on Internet blocking, which has increased since the start of the war and is affecting the ways in which cybercriminals operate. News and social media websites are actively being censored to create a filter bubble within Russia's borders. Previous reports indicate that Russia has attempted to block Internet protocols such as DNS over HTTPs (DoH) and DNS over TLS (DoT), threatening the security and privacy of Internet communications. Russia is also blocking access to the Tor network, which is having an effect on freedom of speech and the landscape through which cybercriminals can communicate. While dissidents are downloading VPNs in greater numbers, threat actors are actively seeking workarounds that bypass Russia's deep packet inspection (DPI) capability. Threat actor recommendations include "anti-DPI" technology, Tor bridges, and VPN-to-VPN services, though the effectiveness of these countermeasures remains to be seen.

Secondly, Russia previously faltered in implementing its "sovereign Internet," finding difficulty in going from an open global Internet to a closed one. Cybercriminals may be able to gamble on Russia unsuccessfully disconnecting from the Internet. While countries like China have been more successful in closing their borders to disinformation, dissent, and foreign influence, it has come at the cost of vast human, technical, and financial resources. Other examples, such as Iran's walled garden and North Korea's restricted Internet, have demonstrated that cybercrime can persist, though usually it is at the behest of the government.

Thirdly, foreign governments are also making it difficult for Russian cybercriminals to cash out and launder the proceeds of their criminal campaigns. On April 5, German law enforcement, in concert with the US Justice Department, shut down Hydra, Russia's largest cybercrime marketplace. The Treasury Department's Office of Foreign Assets Control (OFAC) followed by sanctioning over 100 cryptocurrency addresses and virtual currency exchange Garantex. The sanctions followed a September 2021 initiative to disrupt ransomware payments by sanctioning Suex, and then Chatex, which have helped facilitate ransomware payments to threat actors. All three were tied to the "Moscow tower," which has been a hub of money laundering and cash-out activity. These sanctions are affecting cybercriminals' ability, in combination with sanctions against Russian financial institutions, to move cryptocurrencies from illicit activities (such as ransomware payouts) into fiat currencies.

**Changing Face of Cybercrime  
**Cybercrime has a way of transforming. When one threat actor group is taken offline, another one takes its spot. There has never been a shortage of victims, and despite increased cybersecurity, there are always loopholes that can be exploited. Russian cybercriminals will have a difficult time overcoming the recent sanctions, although they are not a panacea. Russia has benefited from an overly permissive stance on cybercrime, and cybercriminals have acted with impunity. However, the increased restrictions on protocols, illicit services, and cybercrime marketplaces will make it increasingly difficult to financially benefit from conducting cyberattacks within Russia's borders. The implicit treaty between Russia and cybercriminals has been broken, and it is yet to be seen how they respond.

How Russia Is Isolating Its Own Cybercriminals

When a quantum computer can decipher the asymmetric encryption protecting our vital systems, Q-Day will arrive.

Our current encryption standards protect our bank accounts, financial markets, and most of our infrastructure, not to mention the logistics/supply-chain management system in the US Defense Department. But what happens when quantum computers can decipher the current asymmetric encryption that protects our vital systems? "Quantum-Day," or Q-Day, may happen sooner than scientists predict, and it will act like a "dirty bomb" on information architecture.

For standard encryption, Q-Day will occur when a 4,099 coherent qubit machine can complete the nonpolynomial hard factoring on which today's encryption relies. A quantum computer of this magnitude is not available yet, so the world's encrypted data is relatively safe for now. However, a global race is underway to get there.

Most computing experts agree our world is already in the "Quantum Decade," during which governments, businesses, and entrepreneurs will gain value from quantum advances. The opportunities are dizzying as tech companies race to bring quantum computing to commercial products. In late 2021, IBM trumpeted its plan to complete a 1,000-qubit computer by 2023. Numerous others have made subsequent announcements about even larger quantum processors.

All of these advances push for quantum advantage, meaning the time when a quantum computer exceeds the computing power of today's supercomputers. However, most projects are closer to quantum practicality, as computer scientists acknowledge. Quantum practicality (sometimes called quantum utility) is when a quantum machine is able to outperform traditional computers of comparable power under similar conditions. Regardless of what this Quantum Decade brings, it will force changes to existing systems and break several stable information paradigms that lack resilience.

Because of this, the United States — and indeed, every nation — needs backward-compatible quantum resilience now. The US Defense Department hands out awards to contractors that develop or maintain backward compatibility of system hardware and software interfaces. These contracts bring new capabilities to older systems or remedy known limitations for legacy systems (for example, hardening them for continued use). Any post-quantum communication solution that isn't deeply backward compatible cannot scale in deployment quickly enough and will leave the US vulnerable on Q-Day.

**Legacy Systems Open up Vulnerabilities**  
With this requirement in mind, it's worth asking how we're doing. Is the US ready for Q-Day? Can we get there from here? The easiest answer comes from following the money. Since 1990, each US government executive branch department has been required to produce an annual financial statement. For the Defense Department, the details of its most recent audit point to these new systems and legacy systems being material weaknesses, although the audit does not mention which systems those are. This is mainly because we rush to advocate for innovation, but pay for it slowly and reluctantly.

In both the commercial and government worlds, the financial and time cost of updating old software is significant. For the US Government, each fiscal year these obligated stable (sunk) costs are lagging, according to the audit agency; that means they are inadequately funded and falling further behind the innovation curve. This is a big drawback for warfighters. Of the 28 material weaknesses identified in the "Fiscal Year 2021 DoD Agency Financial Report" (up from 26 in the prior year's report), the top two were legacy systems and configuration management.

We can "get there from here" and must do so for the good financial stewardship and national security standards US citizens expect. Perhaps more important than increasing domestic spending to keep up with innovation, we need to keep in mind our adversaries have a vote. Those seeking to damage the US know that legacy systems are particularly vulnerable. The nine legacy systems the DoD extended beyond their expected retirement and the numerous systems (more than 140) that are out of compliance make for a juicy target. Quantum computing advances only increase threat complexity and limit the time legacy systems are useful without breathing new security protocols into them via backward compatibility.

**Backward Compatibility Is Key**  
The recent Fiscal Year 2022 Omnibus directs funding and policy conditions on most US government agencies' IT infrastructure and cybersecurity practices. Most of these comprehensive provisions will require the modernization of legacy systems. Even if funding does not allow new systems to replace these legacy systems, a newly developed post-quantum communication protocol can limit threat vulnerability in our legacy systems. These new protocols will help protect our security environment after Q-Day.

In every war the United States has fought, we've used legacy systems mixed with newer systems. A natural stepping stone to efficiency is purchasing products proven to be backward compatible. This allows warfighters to develop new tactics, techniques, and procedures by blending new and old systems when countering adversary advances.

However, normal technological development timelines are a bigger hurdle than most admit. This lack of understanding slows innovative products in US government markets, as leaders spend on advanced development without demanding these new products have backward compatibility built in. Backward compatibility is the foundation on which our resilience must be built to survive Q-Day. Buying and training US forces with this truth in mind means we will be ready.

Backward-Compatible Post-Quantum Communications Is a Matter of National Security

This is the shift that companies need to make after a cyberattack.

My team recently received a call from a company in Europe that had received warnings from law enforcement that it might be targeted by hackers. We found evidence through our data forensics that an attacker had entered the company's network, taken credentials, and then left. From what we found, the attacker had just as much access and knowledge as the CISO — maybe even more.

And this was likely not the end of the story; attackers usually spend weeks or months inside networks (known as dwell time) before actually doing anything. There was a good chance the attacker would come back. That should be top of mind for any company that's dealing with the aftermath of an attack or intrusion, and the response requires a holistic, active approach even if an incident appears to be over. Often referred to as the "recovery" period, the hours, days, and weeks after a detected intrusion or attack are anything but passive. This period demands action; in fact, it should be called "post-incident response," not "recovery." Not only is this a crucial period of every cyber incident, but it can also be an important growth opportunity for cybersecurity posture and the company in general.

**Attackers** **Return, So Victims Should Study Their Enemies  
**Often when we see an intrusion like the one at this European company, organizations aren't focused enough or don't spend the required budget to make recommended changes, and the attacker comes back with something worse, such as a ransomware attack that can cause great financial and reputational harm. Many companies also fail to see the unique opportunity that is hidden in the fact that attackers often come back: The post-attack or post-intrusion phase can serve as a valuable time to learn about the enemy — where they came from, how they entered, which assets they spent the most time checking out.

Although much time is spent trying to determine who the enemy could be when preparing for possible attacks, the post-attack period offers actual evidence on who the enemy is. This improved understanding of current and possible future enemies allows for a better allocation of resources in order to protect the assets that not only matter most to business value and continuity but are also most likely to be targeted. Knowing from which geographic area an attacker originates and if there is a chance they're connected to state-backed efforts also allows companies to hire cybersecurity teams that bring the necessary talent to deal with the sorts of threats an organization is facing.

**Stopping an** **Attack Is Only the Beginning  
**Just because an attack path was blocked, or attackers may have left all the data accessible (declining to put ransomware on it, for example), they still could have obtained intellectual property and proprietary or personal data. And this could then be leaked for purposes of sabotaging a business, obtaining intelligence, or for making money on the Dark Web. Attacks with multiple stages or objectives are growing; what may initially manifest as a ransomware attack to extract money from victim organization could turn into a smear campaign when that information is leaked or used to influence public opinion. Just because one organization is able to detect or stop an attack with little obvious damage, the attacker could later target other organizations that are connected, either directly through the software supply chain or through phishing campaigns aimed at email addresses taken from the original, relatively unscathed, target. Even though an incident appears over, it probably isn't; more victims are likely to emerge.

**Deal** **With the Last Mile of an Attack on a Managerial Level  
**After an attack or signs of a security breach, companies must make sure they meet a checklist of demands, including informing the right parties, such as government and regulatory bodies, customers, clients, and business partners. All of these obligations should be an integral part of the post-incident response and involve multiple departments.

But the involvement of multiple departments and the entire C-suite should not end with these obligations. The post-incident period is one of the most important times for a holistic managerial approach; after all, if an attacker decides to leak sensitive corporate information to the public, or sell it on the Dark Web, that is not just the CISO's problem; it is also something that executives across departments must deal with. This includes public relations; in today's world, where everyone, everywhere is vulnerable to cyberattacks, an organization's reaction to an attack and how it handles it is paramount to preserving its brand integrity.

Post-incident activity is, and should be, intense. But it should not — as it unfortunately often is — be left to the CISO. We often see that while an attack or security breach is in progress, most of the company's leadership is involved, including the CEO, COO, and human resources and legal teams. It is essential that these executives and teams continue to lead the post-attack phase.

The entire company should also be involved in reviewing not just what went wrong technically, leading to a cyberattack, but how it was handled, pinpointing lessons for the future, and updating its cybersecurity response plan. Now more than ever, cybersecurity can make or break a company; this reality requires a full-fledged team effort at every stage of an attack, even when some may mistake it for being over.

If done well, a response to an attack will not only close vulnerabilities but protect the brand's reputation, operations, and customers and leave a company better prepared to ward off the next attack.

Source

DARKReading