Category: supply chain attack

The emphasis on securing supply chains against sophisticated cyberattacks has never been more pressing. The supply chain represents a vital artery for diverse industries, from healthcare to manufacturing, yet remains a prime vector for cyber infiltration. 

In an era of increasingly interconnected business ecosystems, third-party vendors often hold the keys to sensitive systems and data without the security infrastructure that larger enterprises rely on. This imbalance reveals a significant vulnerability, with 56% of organizations reporting third-party data breaches, according to a survey conducted by Ponemon. In the majority of cases, excessive or unmanaged privileged access granted to third parties was the root cause. 

With the rise of advanced threats like ransomware, supply chain poisoning, and AI-enhanced social engineering, it’s clear that organizations must adopt a more forward-looking, proactive defense strategy. The question isn’t whether a supply chain will be attacked; it’s how effectively it can be defended. 

New era, new threats 

Modern attackers aren’t merely opportunistic—they’re strategic. Supply chain vulnerabilities offer attackers a less fortified entry point into larger, well-defended organizations. Cybercriminals know that breaching a smaller vendor with inadequate security measures can provide the access needed to disrupt an entire network of businesses; they also increasingly view third-party vendors as the weakest link in a security chain, exploiting their connections to enterprises for significant, often devastating breaches.

One prominent and growing threat is supply chain poisoning—a method where malicious actors compromise components or code during a product or service’s development or distribution phases. Once the poisoned asset enters the ecosystem, the impact multiplies, affecting numerous organizations reliant on the compromised software or hardware. This form of attack underscores the vulnerability in operational security and the software development lifecycle, where vetting and oversight can be inconsistent.

Modern cyber attacks are complex. Your defenses should be too. 

The convergence of AI-driven social engineering and traditional tactics has created a new breed of cyber threats. Today’s attackers can employ AI to conduct advanced phishing campaigns, utilizing deep fake technology to convincingly impersonate high-ranking executives or trusted third-party vendors. These AI-enhanced attacks bypass many human-level heuristics traditionally relied upon to detect fraud.

In a recent incident, we heard from a client that cybercriminals leveraged AI to synthesize a convincing replica of a senior executive’s voice. By mimicking tone, cadence, and speech patterns, they were able to deceive an organization’s help desk into nearly resetting multi-factor authentication (MFA) credentials—effectively granting the attackers full access to critical systems. This near-breach was only averted because of a stringent, albeit somewhat outdated, internal policy requiring in-person verification for such requests.

This incident illustrates the growing sophistication of AI-enhanced social engineering attacks, where even advanced security measures can be circumvented by well-crafted, highly personalized exploits. As AI continues to evolve, organizations must anticipate these more subtle, harder-to-detect threats, reinforcing their authentication protocols and building resilience against AI-generated deception.

In parallel, ransomware has evolved from a blunt-force tool into a more targeted and surgical weapon. Attackers now look for critical vulnerabilities in supply chains, recognizing that disrupting a single supplier can have far-reaching consequences for an entire ecosystem. The goal is no longer to extract a ransom from a singular entity but to leverage disruption across multiple organizations, compounding the financial and operational damage.

To stay ahead, organizations must recognize that AI isn’t only a tool for attackers—it’s also a powerful ally in defense. By leveraging AI and automation, companies can enhance their own security systems, building layers of protection that match the sophistication of today’s threats.

If organizations are serious about safeguarding their supply chains, they must also commit to upgrading status quo defenses. The complexity of modern cyber threats demands a strategic pivot toward leveraging AI and automation to bolster security at multiple levels. AI’s ability to ingest, process, and analyze vast quantities of data at speeds far beyond human capability makes it a natural fit for automating risk assessments and monitoring for anomalies within supply chain networks.

AI-enabled systems can continuously analyze data traffic and behavior patterns, identifying subtle deviations that might otherwise go unnoticed. They can also automate real-time threat detection and response, reducing dwell time and minimizing the window of opportunity for attackers.

And while AI and automation offer powerful tools for enhancing supply chain security, they’re not a silver bullet. Even the most sophisticated systems cannot fully compensate for the risk introduced by human error. 

A stringent security posture is key

Beyond AI, strong third-party access management tools play a critical role in keeping intrusions at bay. Solutions like Vendor Privileged Access Management (VPAM) offer precise control over who can access sensitive information and for how long, making sure that only verified, authorized users get through. With tools that monitor, limit, and secure vendor access, organizations gain a vital layer of protection that addresses the unique risks posed by third-party interactions.

Employee education and awareness also remain critical components of any robust security strategy. After all, phishing attacks — many designed to compromise third-party vendors — still rely on human oversight failures to gain traction. 

Employees, particularly those who interact with external vendors, must be trained to recognize the tactics used in social engineering schemes, understand the protocols for granting access to sensitive systems, and exercise skepticism in the face of unexpected or unusual requests.It’s essential to cultivate a security-first culture across the organization. Employees should understand that third-party vendors are not employees and, therefore, not held to the same security standards. Interactions with third-party vendors require heightened scrutiny. 

Leadership must champion this mindset, demonstrating an unwavering commitment to security by integrating these practices into everyday operations. Clear communication, ongoing training, and a well-defined protocol for managing third-party access can reduce the likelihood of human errors, which often act as the entry points for more significant breaches.

As we consider the future, the role of AI-resistant security frameworks will become increasingly important. The very technologies that allow organizations to defend their supply chains can also be co-opted by attackers to enhance their methods. To mitigate this risk, companies must focus on strengthening identity verification and authentication processes. 

Multi-factor authentication (MFA) and advanced AI algorithms can serve as a robust defense against AI-generated impersonation attempts. Biometric authentication (fingerprint scanning or facial recognition, for instance) adds a layer of security that is difficult to falsify using current AI techniques, safeguarding against deepfakes and other fraudulent activities.

What does the future of cybersecurity look like? 

Moving forward, we will likely see the evolution of self-managing systems that not only detect vulnerabilities and abnormalities but can automatically patch them without the need for human intervention. This kind of proactive cybersecurity, driven by continuous machine learning, will be critical in maintaining an edge over attackers who are constantly refining their methods. These innovations will allow for real-time adjustments in security postures, ensuring that the weakest link in a supply chain does not become the entry point for catastrophic breaches.

As cyber security threats become more and more sophisticated, organizations must reexamine their defenses, and the spotlight on supply chain security must remain bright. The interdependencies that define modern business make supply chains a critical asset and a significant risk. By integrating AI and automation with a strong culture of human vigilance, organizations can build a resilient supply chain that withstands today’s attacks and anticipates tomorrow’s threats.

The future of cybersecurity lies not in reacting to threats but in preventing them from ever taking hold, turning vulnerability into strength through intelligent, resilient and adaptable security.

 

The post How to protect against supply chain cyber risk with automation appeared first on Cybersecurity Insiders.

Four years on from the SolarWinds hack, supply chains should still be top of mind for businesses. Warnings from the NCSC have reinforced this message, but in the UK just 13% of business decision-makers describe supply chain security as a top priority.

Perhaps they don’t realise how fragile and vulnerable software supply chains can be? A report from ReversingLabs found almost 11,200 unique malicious packages across major free and open-source software (FOSS) platforms in 2023, thirteen times as many as 2020. With FOSS a common part of many commercial software products, organisations need to better understand this threat, and the strategies they can use to mitigate it. 

Understanding FOSS in supply chains

According to Synopsis, around 97% of commercial codebases use FOSS to some degree. Why, if it’s so vulnerable? The answer is that the benefits of FOSS can far outweigh the risks: it reduces the cost of ownership, maintenance, upgrades, and support fees, and reduces the problem of vendor lock-in. Many businesses not only use FOSS, they contribute too, part of the give-and-take that makes open-source so useful.

It’s unlikely that organisations will stop using open-source software, given they would need to rewrite many core components of their product. In order to protect against attacks, security professionals need to “know their enemy”. The most common tactics used to compromise FOSS include: 

  • Code injection—The threat actor inserts a backdoor into software updates. In most cases, malicious code is injected into a piece of software that is then distributed, allowing the attacker access to multiple organisations.

  • Code substitution—Attackers replace code with malicious code, either by compromising the source code repository or by tampering with the software distribution channel.

  • Code compromise—Exploitation of a vulnerability or a misconfiguration in the software development or delivery process, compromising the code. To illustrate, the NotPetya attack involved hackers exploiting a vulnerability in the M.E.Doc accounting software to deliver ransomware to Ukrainian organisations.

Creating a strategy for protection

Once they fully grasp the risks, security teams will need to do a lot of work to get a handle on the situation. However, it’s not an impossible task and in all likelihood, they’re not going to be starting from scratch—many will already have policies and tools in place that can be improved and built on. 

SBOMs: Software Bills of Materials (SBOMs) play an increasingly important role in enhancing supply chain security. SBOMs list the components and dependencies of a software product, such as open-source libraries, third-party software, and licences. It helps to identify and manage security risks in the software supply chain, such as vulnerabilities, malware, or outdated versions. It’s also necessary from a compliance perspective as the UK begins to enforce its cybersecurity strategy. 

Create a culture of security: It’s also necessary to establish a security-first culture and educate staff on risks and best practices. At a high level, this means understanding the risk an organisation faces, and a better appreciation for security. From a technical perspective, this includes how to use and deploy code safely, and how organisations can use authoritative sources and repositories to download or update open-source software to ensure security.

Patch, patch, patch: IT teams also need to be strict on their cyber hygiene, mainly in regards to patching. Everyone knows that patching is important but it’s also the bare minimum. To remain secure, organisations should work more proactively and regularly scan software components and dependencies for malicious code.

Limit access: A key component of Zero Trust is to never trust anyone and always verify. Dev teams can take this a step further and apply the “principle of least privilege” to software components and users, limiting their access to the minimum necessary resources and permissions. This can include implementing strong encryption and digital signatures to protect the confidentiality and integrity of software components and data is also imperative.

Stricter rules for vendors and suppliers: As an end user, third-party software audits should be a critical component of a strategy for protection. This includes performing due diligence on third-party vendors and suppliers and verifying their security policies and practices. It’s critical to establish clear contracts and service level agreements (SLAs) with third-party suppliers and define the roles and responsibilities in the supply chain.

 

It’s important to keep in mind that this is all reactive, a minimum of what should be done to keep organisations safe. Building on this with a more proactive approach will offer even better protection. This means continually monitoring and auditing the software supply chain for any suspicious activity. Only then can security teams be confident that they are doing enough to stay safe from supply chain attacks.

The post Mitigating the biggest threats in supply chain security appeared first on Cybersecurity Insiders.

[By Ross Bryant, Chief of Research at Phylum]

If there is one safe prediction that I can make in 2024, it is that software supply chain attacks will continue to grow at an alarming rate. My team’s job is to track bad actors across the open-source software ecosystem, and there was a lot to see in 2023. Our Q4 2023 research report revealed that the software supply chain is one of the easier and more popular attack vectors. This vector is an easy target since open source is used in 97% of projects and included in more than 70% of code bases.  The research discovered a significant increase in targeted organizations and attack sophistication, especially within financial and cryptocurrency organizations, with monetary gain as a top motivator. 

As 2024 evolves, popular attack methods such as production system credential theft and financial resources (e.g., personally identifiable information (PII), cryptocurrency, etc.) will remain top threats. Attackers will also continue to execute ransomware-style campaigns – leveraging access to customer data and assets and using the threat of stolen information to coerce organizations to pay the ransom. 

A Surprise in the Numbers

This quarterly research report showed a slight decrease in published packages compared to the previous quarter. However, the number of targeted organizations increased substantially—262.63% more targeted attacks compared to Q3 2023, which had risen 47% from Q2 2023. This showed a clear trend across 2023 of increased direct, targeted attacks.

While the number of published packages was lower than in previous reports, a larger portion focused on specific organizations and indicated specific methods associated with software supply chain threats. 

Mistaken identity 

One such attack method, dependency confusion, is a software supply chain attack that exploits a state of confusion in package managers – checking for named packages within a public registry first before searching in a private registry. An attacker can register an identically named, malicious package on the public registry, intending for the package manager to inadvertently download it, mistaking it for the legitimate package.

Another method that exploits public registries is brandsquatting. In this method, threat actors use popular brand names to mask their malicious code and lure, mislead, and trick the developer into downloading the malicious package.

Attacker Subtly = Greater Gains

In this recent research, two common approaches emerged for targeting the software supply chain: production system credential theft and stealing financial resources (e.g., bank account information, cryptocurrency, etc.). 

In one attack, a threat actor targeted a select group of widely used cloud provider SDKs. A review of the code revealed that the attacker was specifically interested in sensitive credentials to cloud infrastructure.

Exploiting developers’ trust in these packages, the attacker slightly modified a vital part of the code responsible for managing and handling credentials. This triggered a stealthy HTTP POST request for the users’ access and secret keys to a remote URL under the attacker’s control. By making subtle changes and republishing these altered packages on PyPI with similar names, the attacker blended in to remain undetected while maintaining the packages’ expected functionality.

This method, used in at least five packages, involved a simple and effective technique to obscure the remote URL, demonstrating a calculated approach to infiltrating trusted software components on developer workstations and production infrastructure.

Some Organizations Take Proactive Security Steps 

In Dec 2023, an article was published outlining the discovery of an additional set of oddly sophisticated packages. Unlike some of the other campaigns, this one was highly targeted.

These packages contained an encrypted component that could only be unlocked with data from the environment of a local machine in a specific network, where the decryption key was the hostname of a particular organization. Once decrypted, the payload was executed, and user credentials were moved laterally inside the network to a Microsoft Teams Webhook. This left few options: a threat actor had gained a deep foothold in the network, this was a security audit, or this was the work of an insider threat.

Realizing these packages’ specific focus, the targeted organization was contacted to warn and mitigate an attack. If this were an external threat actor, the organization needed to be notified of it before the attacker could do considerable damage.

The analysis continued to explore a very advanced and sophisticated attack comparable with other APT (Advanced Persistent Threat) campaigns.

However, once contact was established with the targeted company, it was discovered that this was part of a broad internal security assessment aimed at mimicking pressing real-world threats. The mimicked attack looked to replicate behaviors the organization was seeing from attackers leveraging the software supply chain as a conduit into their network.

Why Organizations Should Prioritize Software Supply Chain Security

In 2024, attackers will become even more sophisticated, finding new ways to access an organization’s valuable customer and corporate data by exploiting the software supply chain. Methods such as dependency confusion and brandsquatting are the beginning, easily fooling package managers and developers alike. 

Heightened focus on the software supply chain should be a critical component of an organization’s security portfolio, especially those in the financial and cryptocurrency arenas.

The post Software supply chain attacks are escalating at an alarming rate appeared first on Cybersecurity Insiders.

In a concerning development for financial security, American Express has announced that its customers’ credit card information has been compromised in a data breach. The breach occurred through a third-party service provider, marking another significant event in a series of financial data security breaches affecting major companies.

The Breach: A Closer Look

The Amex breach was disclosed in a notification filed with the state of Massachusetts, revealing that American Express’s own systems were not directly compromised. Instead, the vulnerability stemmed from a service provider used by the company’s travel services division, American Express Travel Related Services Company. Information at risk includes American Express card account numbers, names, and expiration dates. Customers with more than one American Express credit card exposed in the breach (and wondering “Did my credit card data get leaked?”) have been advised to expect follow-up contact from the company.

Response and Recommendations

American Express has urged affected customers to vigilantly monitor their accounts for fraudulent activity over the next 12 to 24 months and to enable notifications in the American Express Mobile app for real-time account activity updates. The company assured its customers that they would not be held liable for any fraudulent charges detected on their accounts.

Industry-Wide Concerns About Leaks

This data breach comes on the heels of a similar incident at Bank of America, where a ransomware attack on third-party provider Infosys McCamish Systems affected at least 57,028 customers. These breaches underscore the growing concerns around third-party vendor security within the financial sector.

The Underlying Issues

The lack of details regarding the Amex breach’s detection and the scale of compromise has been a point of criticism. Industry professionals highlight the need for better logging and monitoring capabilities among third-party providers to identify and respond to data compromises effectively. This incident highlights the broader issue of “nth party” risk, where the security vulnerabilities of one vendor can affect multiple parties down the supply chain.

Moving Forward

Experts argue for a multi-faceted approach to mitigate third-party risk, including rigorous vetting during onboarding, specifying breach response responsibilities in contracts, and adopting best practices like data masking. The aim is to minimize access risk and ensure that third-party partners adhere to high standards of data security.

Roger Grimes, Data-Driven Defense Evangelist at KnowBe4, commented: “The problem of service providers, who get successfully hacked, that then end up causing a much larger data breach compromise is quite common. Really anyone who has access to a system becomes an ingress point for hackers. That’s why all services must routinely take inventory of who has what type of access and ensure that they are following recommended security guidelines. It also can’t hurt to have data monitoring so that when a large amount of data begins to move in an unusual way it can be reviewed, and if unauthorized, stopped soon as possible.”

Conclusion

The American Express data breach is a stark reminder of the vulnerabilities present in the complex supply chains of financial institutions. As cyber threats continue to evolve, it becomes increasingly important for organizations to invest in advanced data security capabilities, enforce robust access controls, and proactively reduce their data risk. The financial industry must prioritize these efforts to safeguard sensitive customer information against unauthorized access and ensure the integrity of their operations in the digital age.

The post American Express Customer Data Compromised in Third-Party Service Provider Breach appeared first on Cybersecurity Insiders.

In the complex field of application security, the challenges surrounding open source software security require innovative solutions. In a recent interview with Varun Badhwar, Founder and CEO of Endor Labs, he provided detailed insights into these specific issues and how Endor Labs is positioning itself to tackle them head-on.

The Broken State of Application Security

Software developers currently spend more than half their time investigating an overwhelming number of security alerts and maintaining tools in CI/CD pipelines. Badhwar characterizes the problem:

“Application security is fundamentally broken today – engineering teams are constantly being asked to deploy numerous AppSec tools in the CI/CD pipeline, which creates substantial work for developers, slows down feature delivery, and adds friction.”

Endor Labs aims to mitigate this productivity tax by focusing on OSS security, with a goal to reduce 80% of vulnerability noise.

Open Source Security and Endor Labs’ Innovative Approach

Open source software (OSS) makes up a significant portion of modern application code, sometimes exceeding 90%. While fostering efficiency and collaboration, it also introduces vulnerabilities if not managed correctly.

Challenges in Open Source Security:

  1. Proliferation of OSS Components: With 80-90% of application code being borrowed from open source repositories, it’s essential to know what components are being used and how.
  2. False Positives: Traditional security tools generate an overwhelming number of false positives, creating a massive burden on developers.
  3. Incompleteness and Inaccuracy: Existing tools often lack insight into how open source code is being used, resulting in both noisy and incomplete risk assessments.
  4. Transitive Dependencies and Reputation Risks: Hidden vulnerabilities and dependencies are often overlooked, posing a latent threat to security.

Endor Labs’ Approach to Open Source Security

Endor Labs’ pioneering approach focuses on actual risks and utilization patterns within OSS. This empowers DevSecOps teams to prioritize risks, secure CI/CD pipelines, and meet compliance objectives like SBOMs. Their methodology includes:

  1. Intelligent Analysis: By understanding exactly how developers are using open source code, Endor Labs pinpoints the actual risks. 90% of code in modern applications is open source software, yet only 12% of that code is actually used within applications. Endor Labs replaces the existing breed of Software Composition Analysis (SCA) solutions that lack context on what parts of the code developers are actually using.
  2. Evidence-Driven Insights: Endor Labs employs an evidence-driven approach that assesses the true impact and risk of vulnerabilities based on how code is being used, rather than blanket evaluations.
  3. Eliminating Noise: By focusing on what matters, Endor Labs eliminates up to 80% of the noise associated with traditional tools, saving developers’ time.
  4. Tackling Hidden Risks: The solution addresses hidden dangers like vulnerabilities present in transitive dependencies, uncovering risks that might otherwise be missed. Endor Labs research reveals that 95% of vulnerabilities live in transitive dependencies, yet most organizations have no visibility into them.
  5. Holistic View of Risk: Endor Labs provides a comprehensive view of risk by evaluating not just the code but also the reputation and potential hazards associated with using specific open source components.
  6. Regulatory Compliance: With open source being labeled a national security issue, Endor Labs ensures that their approach aligns with regulatory requirements, including initiatives like Software Bill of Materials.

Endor Labs’ approach to open source and application security is not only revolutionary but necessary in today’s interconnected development lifecycle. By focusing on actual risks, reducing noise, and providing a comprehensive and intelligent analysis, they are shaping the future of how organizations manage and secure their applications and open source components.

Advice to Organizations and Developers

For organizations and developers, the future lies in consolidating the DevSecOps toolchain, simplifying tool deployments, and prioritizing the risks that matter. In the interview, Varun provided actionable guidance to both developers and organizations:

  1. Embrace Open Source While Ensuring Security: Utilize the benefits of open source software, but with a focus on security and compliance. Implement intelligent tools that understand how code is being used, thereby reducing noise and pinpointing real threats.
  2. Streamline Development Pipelines: Avoid overcomplication and duplication by consolidating the DevSecOps toolchain. Choose tools that simplify deployments, enforce consistent security policies, and enable building software that is “secure by default.”
  3. Foster Collaboration Between Teams: Work towards aligning engineering and security teams, viewing them as internal partners. Focus on real issues that matter most, creating a synergy that enhances overall productivity and security.
  4. Adhere to Regulatory Requirements: Stay abreast of regulatory standards such as Software Bill of Materials (SBOMs), recognizing the importance of transparency and compliance, especially as open source security continues to be a national concern.
  5. Adopt a ‘Trust but Verify’ Approach: Balance the use of open source with vigilant verification of its security. Encourage a development model that leverages OSS benefits without slowing down the development process, promoting a secure and innovative environment.

Endor Labs is at the forefront of reshaping how we approach application security. With a new $70 million round of funding and a clear mission to enable developers to be more productive without compromising on security, they are leading the way toward a more secure and efficient future in software development.

For more information on Endor Labs, visit https://www.endorlabs.com

The post Reducing the Productivity Tax in Open Source Software Security – A Deep Dive with Varun Badhwar of Endor Labs appeared first on Cybersecurity Insiders.

By Tomislav Pericin, Chief Software Architect at ReversingLabs

Looked at from one angle, the recent attack on JumpCloud, a cloud-based identity and access management provider, was unsurprising. The incident, which JumpCloud disclosed in early July, involved a North Korean state-sponsored actor known as Lazarus Group, hacking into accounts associated with JumpCloud customers in the cryptocurrency business. That’s a long-established pattern for Lazarus Group, and North Korean hacking groups generally. CISA warned in 2022 about North Korean forays into cryptocurrency and block chain companies and infrastructure. The JumpCloud hack was also just the latest, sophisticated supply chain attack to target the customers of cloud infrastructure providers – with potentially devastating consequences for private sector firms, government agencies and more.

As JumpCloud and its customers pick up the pieces from the compromise, however, it is worth asking why attacks on third-party providers such as JumpCloud, CircleCI and 3CX manage to trip up even sophisticated firms and what it would take to put supply chain hackers like Lazarus Group on the back foot. In this blog post, I’ll review what we know about the recent JumpCloud incident and talk about the bigger implications of the attack on firms as they assess the risk posed by supply chain compromises of third-party software providers they rely on.

JumpCloud: part of a pattern

The attack on JumpCloud, which dates to June, 2023, forced the company to rotate API keys for many of its estimated 180,000 customers to prevent further attacker access to customer accounts and data. That recalled the follow-up to the attack on CircleCI, a popular application development platform in January 2023 that resulted in that company calling on its customers to rotate API tokens and other environmental variables. There were also echoes in the attack of other recent supply chain incidents: the compromise of Voice over IP provider 3CX, the breach of Solar Winds, CodeCov and more. It’s all part of a trend of attacks on software suppliers. In fact, the European Union Agency for Cybersecurity (ENISA) predicted that supply chain compromises targeting software dependencies will be the biggest emerging threat by 2030.

Tool talk: supply chain hacks escape notice

The increasing frequency of successful attacks underscores the challenges that even sophisticated firms face in managing cyber risks from their software supply chains. Partially, that is due to a gap in the tooling and processes needed to manage software supply chain threats. Established application security technologies like static- and dynamic application security testing (S/DAST) and software composition analysis (SCA) are well suited to identifying flaws in raw application code, or vulnerable software dependencies. But they fall short when presented with challenges like software tampering or the inadvertent use of malicious open source- and proprietary software modules as part of the application design process. SAST, for example, requires access to raw, uncompiled application code for analysis. That makes it of little use to downstream consumers, who are unlikely to be given access to the code. Similarly, SCA products are useful for spotting out-of-date or vulnerable open-source software libraries, but have little visibility into the vast population of proprietary, closed source third party libraries and software components.

Software makers get it. We sponsored a survey of more than 300 IT professionals that found 74% of IT and security professionals working for development organizations considered tools such as SAST, DAST, and SCA inadequate to fully protect their organizations from software supply chain threats. In that same survey, more than half of technology professionals (55 percent) cited secrets leaked through source code as a serious business risk. 52 percent labeled malicious code as a serious risk and 46 percent did so for “suspicious code.”

I’m from the government, and I’m here to help!

Given the growing awareness of the risks posed by vulnerable software supply chains, what is needed now is a way to break down the barriers within organizations to implementing effective software supply chain risk management policies, tools and practices.

Some of that is already happening. Platform providers like Google, Amazon as well as Microsoft (owner of GitHub and npm) are implementing features that raise the bar for would-be supply chain hackers, while streamlining basic security functions like monitoring code for vulnerabilities or leaked development secrets.

Government and industry regulators are also taking up the mantle of software supply chain security. The Biden Administration, for example, issued an Executive Order (#14028) in 2021 calling on companies that sell software and services to the federal government to attest to the security of their software and the components contained in them. The Administration recently issued a memo (PDF) to the heads of Executive Branch agencies on how to comply with those attestation requirements, while CISA and the NSA have issued guidance on securing CI/CD pipelines.

In the meantime, the federal PATCH Act, passed in late 2022, requires makers of medical devices to present to the Food and Drug Administration a wide range of security measures prior to getting FDA approval. Those include “plans to monitor, identify, and address…cybersecurity vulnerabilities and exploits;” secure device design, development and maintenance processes;” as well as a software bill of materials (SBOM) documenting commercial, open source and off the shelf software components used in the device.

Regulations like these are raising the bar for application security, even as they shift the ground under software development organizations. Over time, however, they promise to raise the level of application security, while giving customers (or one customer, anyway: Uncle Sam) assurances and actionable information to address threats spilling out of extensive software development supply chains.

Wanted: a final exam for developed code

In the meantime, both development organizations and their customers have to navigate increasingly treacherous terrain, with the risk of damaging supply chain compromises growing. To do that, application security teams need to increase their scrutiny of the entire development pipeline. That requires organizations to stay on top of traditional risks such as insecure developer and administrator accounts, not to mention exploitable software vulnerabilities and balky open source libraries.

Beyond those basic measures, organizations need to embrace new processes and methods. The deployment of software bills of materials (SBOMs), for example, requires more than just generating an ingredients list for compiled applications. Development organizations and downstream customers also need a way to monitor and act on the information contained in SBOMs to limit exposure to newly discovered exploits (Log4Shell, for example).

And both application security teams and customers need tools that can assess the security of developed code both before it is shipped and after it has been received to spot evidence of more sophisticated attacks – like SUNBURST style code tampering – that may slip past traditional application security technologies.

A great approach is to present developed and compiled code with something like a “final exam” that must be passed before binaries are released to customers. It presumes that development teams follow all of the best practices but adds an integrity check of the compiled (post-compilation, pre-deployment) software package to look for characteristics or behaviors that are known to be malicious or suspicious. Those might include red flags like unexplained communications with external infrastructure, or suspicious dependencies that aren’t explained by the design and function of the application.

The goal is to detect the kinds of compromises that bedeviled SolarWinds and 3CX, which were clearly observable after the fact, but escaped notice by application security teams within those organizations looking for the ‘usual suspects.’

The objective is for software makers to have a reliable means of manufacturing reproducible software builds that give both them and their customers confidence that malicious code or functionality is not lurking in application code and updates shipped to end users. That’s a goal we should all be able to get behind.

The post Supply chain attacks demand a 3rd party risk re-think appeared first on Cybersecurity Insiders.

By Marc Gaffan, CEO of IONIX

The digital supply chain is in the attackers crosshairs, and CISA is worried. In mid-June, they issued a Binding Operational Directive, “a compulsory order to the federal, executive branch, departments, and agencies to safeguard federal information and information systems.” CISA is especially concerned about devices that connect to the internet. The order covers routers, switches, firewalls, VPN, load balancers, and out-of-band server management interfaces. It also covers remote management tools, like SolarWinds.

The fragility of the digital supply chain came into focus in 2020 with the SolarWinds hack. Russian attackers compromised a software update impacting 18,000 organizations, including the US Departments of Health, Treasury, and State.

A threat actor set on penetrating your organization doesn’t care whether they’re attacking your internet-facing asset directly or exploiting a vulnerability from a third-party digital service that provides a toehold into your environment (e.g., a takeover of a dangling Azure blob called by an app referenced in a script on your website).

CISA’s directive recognizes that the increasingly interwoven nature of the digital supply chain demands a radically different approach to threat protection. It must identify the sprawling network of dependencies on the same level as an organization’s other assets – and separate signal from noise.

Perhaps proving CISA’s point, another cybersecurity story has dominated the month of June. Progress Software’s popular managed file transfer solution MOVEit has suffered three separate SQL injection vulnerabilities in less than a month.

Enterprises increasingly rely on third-party web services, vendors, and platforms to accelerate growth, scale operations, and increase efficiencies. What they are also doing is expanding their attack surface. A partner’s security problems quickly become yours in a connected digital supply chain. MOVEit is just the latest example of how one impacted organization can lead to problems for hundreds of others. In less than a month, the third SQL injection vulnerability shows how these services are frequently targeted and often fragile.

Attack Surface Discovery

Digital connections, like data, grow and change daily. These connections include IP addresses, cloud infrastructure, SaaS applications, and managed platforms (like MOVEit).

According to a recent ESG survey, manual processes for attack surface discovery can take over 80 hours to complete, making them impractical and inefficient in the face of the scale and dynamism of modern digital landscapes. Leveraging automation is the only way to get a handle on an organization’s attack surface.

The tasks that are automated run the gamut, from incredibly dynamic to mundane. Of course, AI and ML are a big part of it. Advanced AI algorithms and machine learning models can uncover all domains, subdomains, and IP addresses related to a network or system. Their reach extends to indexing the internet and public cloud platforms to identify and attribute all domains, IP blocks, and cloud infrastructure. They overlay continuous mapping across Web, Domain Name System (DNS), Cloud, Software-as-a-Service (SaaS), and On-Premises. They even help monitor domain registrars and global certificates.

Risk assessment

Automation is at the heart of assessment as well as discovery. Discovered assets are evaluated against specific categories, including Cloud, PKI, Web, DNS – automated at scale across the entire environment.

By evaluating assets and connections automatically, security teams can identify risky connection vulnerabilities – external risks due to being connected to 3rd party web services, external dependencies that impact security posture, and DNS chains.

Alert fatigue is a real problem. An assessment of risk has to provide context and focus on the most critical, impactful threats. Any vulnerabilities discovered within the supply chain must account for in calculating the risks they pose to the first-party assets that connect to them. Any attack surface solution should derive from these vulnerability assessments a prioritized risk score for the organization and each asset, with clear steps to remediate the vulnerabilities and eliminate the risks.

A risk assessment should dynamically prioritize threats based on the potential damage to the business. These factors include sensitive data access, business context, brand reputation, and dependencies’ operational impact.

Mitigation

As is always the case, a strategy for securing the attack surface requires a combination of technology and human processes. The technology will be used primarily for collecting and synthesizing information, while the processes will focus on enabling humans to be preemptive or remediate action.

No enterprise trusts its cybersecurity vendor to automate threat mitigation fully. What matters at this point in the process is having the context and clarity required to make decisions and act. You can’t ask or expect a SOC team to adopt your processes and procedures; you must integrate them into theirs. Intelligent workflows align remediation tasks with the way security operations work, so they spend less time routing tickets and more time resolving critical risks.

Conclusion

Cybersecurity teams are under intense pressure to get control over their digital supply chain. The challenge is enormous. Teams are being asked to identify and secure assets they have no control over. These assets belong to partners, and their partners. Before teams can develop and enforce policies and practices around their digital supply chain they need to find the right tools to support them.

The post CISA’s binding directive shows attackers still feasting on digital supply chain appeared first on Cybersecurity Insiders.

By Javed Hasan, Co-Founder and CEO at Lineaje

Software supply chain compromises have been top-of-mind for CISOs and their security teams for the past few years — and rightfully so. The total cost of a software supply chain attack was $4.46 million last year.

In order to meet product development deadlines, most teams utilize third-party resources such as pre-built libraries and open-source components to accelerate the construction process and lower production expenses rather than creating software from scratch. This approach enables engineers to introduce products to the market more quickly, but not without risk.

According to a recent IBM report, one in five breaches occurred from a software supply chain compromise in 2022. On average, it takes 26 more days to detect and control a supply chain attack than any other method.

The sheer number of software supply chain compromises, coupled with increasing federal regulations such as the U.S. Executive Order 14028, should have software producers and consumers putting software supply chain security at the top of their priority list.

In this article, I break down the Who, What, When, Why, and Where of the software supply chain, so cybersecurity professionals can understand the full scope of software supply chain security to help avoid costly mistakes, and uphold brand reputation.

What is software supply chain security and the increasing importance of it?

The software supply chain refers to either the entire process by which software is acquired, developed, and delivered to end users or anything that has a role in its development throughout the software development life cycle. It consists of everything and everyone involved in developing code in the software development lifecycle (SDLC), from sourcing, application development, packaging and delivery through his CI/CD pipeline to delivery.

So, when done properly, software supply chain security is used to protect against a wide range of threats including malicious software, unauthorized access, tampering, and misuse, which can lead to surmounting financial costs and irreversible brand damage as seen with the 3CX, SolarWinds, and Okta incidents.

Why does securing your software supply chain matter?

Adversaries are always going to use the method of least resistance. Most threat actors gain initial access to the software supply chain by compromising up stream components in Open-Source.  In doing so, threat actors gain access an organization’s network simply through tampers in the supply chain and exploiting unknown vulnerabilities in the software and then moving laterally throughout the network and to third-party organizations. Throughout the journey, adversaries are stealing sensitive data and disrupting business processes often without the knowledge of security teams. Left undetected, adversaries have the ability to cause significant interruptions to business, leaving even the biggest of household names victim to brand reputation damages.

In addition, many regulations and industry standards, such as the SLSA, FedRAMP rev 5, and NIST 800-53  require organizations to implement secure software supply chain practices to protect sensitive data. In particular, the upcoming U.S. Executive Order 14028 revolves around “enhancing the security of the software supply chain to deliver a secure government experience.”

Securing your software supply chain can protect against cyberattacks, safeguard intellectual property (IP), ensure compliance, and maintain brand reputation, business continuity, and risk management. It allows organizations to be proactive in identifying potential vulnerabilities and mitigating risks, and ultimately provides a higher level of security and peace of mind for the organization and its partners and end users.

Who should care about software supply chain security?

Software supply chain security is a concern for a wide range of stakeholders within an organization, each with its own responsibilities and areas of focus. It is important for all stakeholders to understand the risks and take appropriate actions to protect the organization’s software supply chain.

These include:

CISOs: CISOs are responsible for the overall information security of an organization and have a critical role in protecting the organization’s networks, systems, and data from cyber threats. Software supply chain security is an essential part of this, and CISOs need to ensure that appropriate policies, procedures, and technologies are in place to protect the organization’s software.

Procurement teams: Procurement teams need to ensure that the software they acquire is from reputable vendors and has been independently verified for security. Oftentimes, procurement teams work hand in hand with security to qualify security solutions and ensure software meets company standards.

IT teams: IT teams must maintain regular updates to software, patch any known vulnerabilities, and implement appropriate security controls to protect against cyber threats.

Developers: Developers need to use secure development practices, such as code signing and testing for vulnerabilities, to ensure that the software they develop is safe, speedy, and efficient to end users.

Defenders: Defenders include Security Operations Center (SOC) analysts responsible for detecting and responding to cyber threats and attacks.  Software supply chain tampers and attacks require specialized analysis of the software during run-time.

When should organizations think about securing their software supply chain?

With the fallout of several high-scale software supply chain attacks, the federal government has made securing the software supply chain a top priority. The Biden Administration highlighted the importance of securing the software supply chain in its recent White House National Cybersecurity Strategy, and allocated significant budget toward it in the rollout of its FY24 Budget. It’s more than likely that private sector organizations will follow the lead of federal companies, and begin to align with the Biden Administration’s software supply chain security standards, especially with time to comply with Executive Order 14028 growing shorter.

The due date for software suppliers to US government agencies to provide attestations and SBOMs is coming up on June 11th, but the Cybersecurity & Infrastructure Security Agency (CISA) is still taking feedback on the forms, and there is a sense that the deadline might move to July.

Regardless, the time is now for securing the software supply chain. Doing so will enable key company stakeholders to be ahead of any current legislative deadlines and any to come.

Where should security professionals focus on?

A lot of the focus on acting on software supply chain security begins with a software bill of materials (SBOM), which is a list of all the open-source and third-party components present in a codebase. An SBOM typically includes the name, version number, and licensing information for each software component used in the application. This information is important for ensuring software security, compliance, and managing vulnerabilities.

Both software consumers and producers need to make sure they can thoroughly search their SBOMs of all deployed software quickly and efficiently to find newly discovered vulnerabilities. They will need to centrally manage their entire software supply chain, which consists of applications they build or buy, thereby allowing them to govern SBOMs at an enterprise-wide level.

Organizations must look at software supply chain solutions that can automatically provide visibility into a company’s entire software supply chain, create SBOMs for a company’s portfolio of products, assess them, ensure their integrity and continuously improve their security profile. To know what’s in your software, it’s important to find a supply chain manager that can do a full transitive decomposition of  any software to discover all deep dependencies including open source, private and third party code.

So What Next?

Now that organizations and individuals are aware of the 5 W’s of the software supply chain and the importance of software supply chain security, where do they go from here? The answer lies in a new approach – a focus on better software. Only software that is built securely, can run securely. Consumers of software are failing to make software secure at deployment – as is evident by continuous breaches and attacks even as the world becomes more digital every day. We are currently in a time when every security professional needs to feel confident and know “What’s in their software?” in order to stay compliant and ahead of today’s top threats.

The post The 5Ws of the Software Supply Chain — How Security Teams Can Prevent Costly Mistakes appeared first on Cybersecurity Insiders.

Ransomware attacks have emerged as a pervasive and relentless threat, wreaking havoc on organizations of all sizes. The number of ransomware victims announced in March 2023 was nearly double that of April 2022. These malicious acts not only compromise sensitive data but also disrupt business operations, causing significant financial and reputational damage. As organizations grapple with the escalating ransomware challenge, it becomes imperative to adopt robust defense strategies that can effectively combat these evolving threats.

To gain insights into the dynamics of ransomware attacks and the vulnerabilities they exploit, we turn to Ben Smith, the Field CTO of NetWitness, a trusted provider of threat detection and response technology.

Unraveling the Ransomware Attack Sequence

According to Ben Smith, ransomware attacks involve a series of calculated steps that bypass or exploit technologies used in an organization’s daily operations. This presents a significant challenge due to the multitude of technologies organizations rely on, each representing a potential weak spot in the attack surface. One notable example is the compromise of organizations through an exploit targeting MOVEIt, a commercial file transfer platform. The vulnerability, which was disclosed in May 2023, allows cyber criminals to gain unauthorized access to the environment and steal customer data.

To tackle this challenge, organizations must carefully consider the tools they employ to support their business or mission. Comprehensive visibility throughout the environment is critical, starting with real-time network traffic monitoring. Organizations equipped with network-level visibility have a better chance of detecting and responding to unexpected behavior within their operating network, thwarting ransomware attacks before irreparable damage occurs.

Solutions to Combat Ransomware Attacks

Understanding the ransomware landscape requires a multi-pronged approach that encompasses prevention, detection, and response. To combat these threats effectively, organizations must adopt solutions that address the specific vulnerabilities exploited by ransomware attacks. Ben Smith suggests a range of capabilities designed to bolster cybersecurity and counter the ransomware menace:

1 – Network Detection and Response (NDR)

NDR solutions provide real-time monitoring and analysis of network traffic. Leveraging advanced machine learning algorithms, behavioral analytics, and threat intelligence, NDRs can detect suspicious activities and anomalous behaviors indicative of ransomware attacks. With deep visibility into network traffic, organizations can swiftly identify compromised systems and take proactive measures to contain the threat.

2 – Endpoint Detection and Response (EDR)

EDR solutions offer comprehensive visibility and monitoring at the endpoint level. By continuously monitoring endpoint activities, EDRs can identify malicious behaviors, unauthorized processes, and file modifications associated with ransomware. Rapid detection and containment of ransomware outbreaks become possible, enabling security teams to quarantine affected endpoints and initiate timely remediation procedures.

3 – Security Information and Event Management (SIEM)

SIEM solutions combine log management, event correlation, and threat intelligence to provide a comprehensive view of an organization’s security posture. By aggregating and correlating security events and logs from various sources, SIEM empowers security teams to proactively hunt for ransomware-related indicators. Actionable intelligence allows organizations to respond swiftly to ransomware incidents and mitigate their impact.

The Evolving Landscape of Ransomware Attacks

During the interview, Ben Smith sheds light on the changing tactics employed by ransomware operators. In addition to traditional extortion methods, cybercriminals are adopting a more strategic approach. Criminals have transformed ransomware attacks into PR opportunities by publicly announcing breaches and threatening to expose sensitive data if their demands are not met. This evolution indicates that attackers are running sophisticated businesses with a clear understanding of the value they can extract from their victims.

The Importance of Collaboration and Threat Intelligence

In the fight against ransomware, collaboration and access to timely threat intelligence are vital. NetWitness recognizes the significance of building relationships with other organizations, sharing information, and fostering a collective defense approach. By actively participating in industry-specific information sharing platforms like FS-ISAC (Financial Services Information Sharing and Analysis Center), organizations can stay ahead of emerging threats and proactively protect their assets.

The Holistic NetWitness Approach

NetWitness’s comprehensive portfolio of solutions is specifically designed to address the ransomware challenge. Their network detection and response capabilities, combined with endpoint detection and response and SIEM solutions, provide organizations with unparalleled visibility into their network and endpoints. By leveraging advanced analytics and machine learning, NetWitness enables proactive threat hunting and early detection of ransomware activities.

Moreover, NetWitness’s security orchestration, automation, and response (SOAR) platform, known as NetWitness Orchestrator, streamlines incident response procedures. It offers predefined runbooks and automated workflows, empowering security analysts to respond swiftly and effectively to ransomware incidents. Integration with threat intelligence ensures that the decision-making process is backed by up-to-date information, enhancing the organization’s ability to mitigate attacks.

Conclusion

Ransomware attacks pose a significant threat to organizations worldwide, with devastating consequences for those who fall victim. The evolving tactics of ransomware operators demand a proactive and multi-faceted defense strategy. By leveraging threat intelligence, fostering collaboration, and implementing comprehensive security measures, organizations can enhance their resilience against these malicious campaigns.

The post Defending Against Ransomware Attacks appeared first on Cybersecurity Insiders.

Aaron Bray, Co-Founder and CEO of Phylum

A few weeks ago, PyPI announced that it temporarily disabled the ability for users to sign up and upload new packages due to “The volume of malicious users and malicious projects being created on the index in the past week.” Although PyPI stated that the move was a bit overblown, it made headlines because it comes at a time when attackers are evolving their techniques in the open-source ecosystem in an effort to poison the software supply chain and compromise developer environments. And it is working.

Prior to the shutdown, there was a persistent attack that would overwhelm any package manager trying to do the right thing: A bad actor on GitHub laced his repositories with malware written in Python and hosted on PyPI. Minutes after his malware gets taken down from PyPI, the same malware respawns on PyPI under a slightly different name. It’s a vicious cycle made easy for attackers as they embrace automation to avert best efforts by humans.

The situation highlights a few key challenges that businesses are just now coming to terms with:

  1. It underscores the risks organizations face from their blind trust in free and open-source software published by strangers on the internet. This is certainly not meant to disparage package registries as they created tremendous amounts of value for all of their downstream users and beneficiaries, but it highlights their susceptibility to being coopted as an attack vector.
  2. It proves just how prevalent bad actors in the open-source ecosystem have become. When my team first started monitoring the open-source ecosystem about a year and a half ago, we would frequently see spikes of malicious packages in the hundreds per month. Now, in just the first quarter of 2023, we saw nearly 900,000 packages that were objectively bad – either overtly malicious or spam.
  3. The tools and processes most companies have in place are not equipped to defend against the tactics attackers are deploying in the open-source ecosystem. Most initiatives either focus on scanning inventory, complying with regulatory or industry initiatives such as the creation and management of a Software Bill of Materials (SBOMs) or the SLSA framework, or on attestation that centers around ensuring assets aren’t tampered with during the development process. This leaves a blind spot around the inputs, efforts, and individuals involved in creating their software components, and whether or not they will behave as expected.

This new reality has company’s asking themselves: How can we trust the open-source packages we rely upon to build our applications? And how can we secure our software supply chain without impeding the speed of innovation to which we are accustomed?

Fundamentally, from a business risk perspective, organizations have backed themselves into a corner. The use of open source components has skyrocketed in recent years, with industry studies putting the average project’s composition at somewhere between 70-90% open source, with a scant 10-30% proprietary code, across a broad spectrum of verticals. To make matters worse, threat actors are more active than ever before in these ecosystems, and software supply chain attacks have continued to become both more prevalent and more targeted. Rather than being a “black swan event,” these problems have escalated to the point where developers now have difficulty ensuring that a package they pick is legitimate or malicious, and security teams are entirely in the dark as to what things are event being installed during the software development process.

The trend line of open-source utilization and reliance is only set to increase as time goes on. In fact even the CIO of the DoD, which operates under extremely stringent guidelines, has mandated more reliance on open-source software. With this in mind, it is important to remember just how difficult monitoring is for the service providers in this equation. The governance and curation of packages in PyPI, which is the major center of gravity for the Python ecosystem, is almost entirely managed by a few volunteer individuals. Most package registries are similarly understaffed, especially when considering the sheer volume of package publications that need to be managed. We see an average of 50,000 packages published every day across the ecosystems we support.

As attackers continue to target these ecosystems, and new artificial intelligence and automation innovations emerge, how can we expect package registries to manage this burden alone?

At the end of the day, organizations need to bear more responsibility for protecting their developers and the applications that are at the core of their livelihoods. It’s time for businesses to start questioning everything they thought they knew about securing code and protecting their software supply chains. The next time a package registry shuts down, it could be for good. What then?

Author

Aaron Bray, Co-Founder and CEO of Phylum

Aaron has 14 years of experience working in software engineering and information security. Aaron’s past research has focused on program synthesis, malware diversity, software anomaly detection, and the application of natural language processing techniques to binary analysis.

https://www.phylum.io/aaron-bray

The post Who’s responsible for securing the open-source software organizations used to build all applications? appeared first on Cybersecurity Insiders.