Jul 12 2023

Shared Responsibilities: The Core Tenet Of Third-Party Risk Management

Category: Vendor Assessmentdisc7 @ 11:04 am

Third parties (vendors of products or services) are responsible for a significant portion of cybersecurity incidents or data breaches at customer organizations.

Amid all the focus on third parties, what is often not discussed is that customers themselves might be in a position to possibly detect or contain the damage from certain security incidents on their own, regardless of the third party’s association with the cause of the incident.

The concept or principle of shared responsibilities between customers and their third parties was originally conceived and popularized in the context of public cloud service providers and their customers.

I don’t think the shared responsibilities principle should be limited to public cloud services. It could apply just as well as a core tenet to the security of any product or service that customers source from their third parties. This discipline of information security—of customers managing security risks in the product or services sourced from third parties—is commonly referred to as third-party risk management (TPRM). Terms such as “vendor risk management” or “supply chain risk management” are also used synonymously.

The shared responsibilities tenet of TPRM is illustrated well in the MOVEit breach that has been in the news over the past month.

It is clear from the vendor’s own account that the breach resulted from security vulnerabilities in the vendor’s product, MOVEit Transfer. What might be missed on the vendor’s page, however, is that the vendor did not detect the vulnerability on their own.

It appears they might have learned about the vulnerability from the calls they received from their customers indicating suspicious activity on May 28, 2023. This was likely within a day of when the adversary started exploiting the vulnerability, as reported by Mandiant.

The customers who detected the adversary’s activity had likely done a diligent job of implementing the vendor-suggested security best practices, especially the practice related to reviewing audit logs for anomalous behavior.

By having such effective detection mechanisms in place, as well as implementing the other security best practices suggested by the vendor, it wouldn’t be far-fetched to say that these customers might have been in a position to act in a timely manner and prevent significant impact from the adversary’s actions.

On the other hand, there are likely many other customers who may not have undertaken the due diligence to implement the vendor-suggested best practices and operate those practices effectively. Such customers may not have discovered the exploit in time, which could have resulted in sensitive data being stolen by the adversary.

In my view and experience, the shared responsibilities tenet often does not get due recognition or necessary focus at customer organizations. TPRM programs at the organizations are usually focused on assessing risks posed by vendors (i.e., the vendor portion of the shared responsibilities). They may not “close the loop” by evaluating how well their own organizations have implemented their part of the shared responsibilities.

I believe the ecosystem of customers and third parties could implement and operationalize shared responsibilities in their TPRM programs through several means, including but not limited to:

• Contracts: Emphasize each party’s portion of the shared responsibilities in contract documents.

• Transparency And Communication: Vendors should provide necessary and actionable details regarding customers’ part of the shared responsibilities in their self-assessment reports, as well as communicate the responsibilities to customers in a proactive manner, especially when new features require updates to shared responsibilities.

• Program Charters: Customer TPRM programs should update their program charters and governance to emphasize that the program’s objective is not limited to assessing risks posed by the vendor, but that it should also assess and mitigate risks associated with how their own organizations use the goods or services provided by the vendors.

• Governance And Ownership: Customer TPRM programs should clarify the roles and responsibilities of internal sponsors and other stakeholder teams that use vendor services.

Cybersecurity and Third-Party Risk: Third Party Threat Hunting

Cybersecurity Risk Management

CISSP training course

InfoSec tools | InfoSec services | InfoSec books

Tags: Third Party Risks, TPRM

Jun 26 2023

What is TPRM?

Category: Vendor AssessmentDISC @ 10:45 am


Tags: TPRM

May 29 2023

CISO-approved strategies for software supply chain security

Category: CISO,vCISO,Vendor AssessmentDISC @ 12:40 pm
CISO approved strategies for software supply chain security video

Integrating proprietary and open-source code, APIs, user interfaces, application behavior, and deployment workflows creates an intricate composition in modern applications. Any vulnerabilities within this software supply chain can jeopardize your and your customers’ safety. In this Help Net Security video, Tim Mackey, Head of Software Supply Chain Risk Strategy at Synopsys, discusses supply chain security practices and approaches.

Software Transparency: Supply Chain Security in an Era of a Software-Driven Society

InfoSec tools | InfoSec services | InfoSec books

Tags: software supply chain security

Mar 13 2023

Vendor Security Checklist

Category: Information Security,Vendor AssessmentDISC @ 12:36 pm

Vendor Security Checklist – by Ministry of Security

Third Party Risk Management

Previous posts on Vendor Assessment

DISC performs Vendor assessment, we’d love to hear from you! If you have any questions, comments, or feedback, please don’t hesitate to contact us. Our team is here to help and we’re always looking for ways to improve our services. You can reach us by email (info@deurainfosec.com), or through our website’s contact form

InfoSec Threats | InfoSec books | InfoSec tools | InfoSec services

Tags: Third Party Risk Management

Feb 08 2023

Researcher Hacked Toyota’s Global Supplier Portal

Category: Hacking,Vendor AssessmentDISC @ 12:43 pm

The Global Supplier Preparation Information Management System, or GSPIMS, of Toyota, was breached by a security researcher using a backdoor. After 90 days, the hacker dutifully alerted the company about the breach.

The firm’s web platform, known as GSPIMS, enables employees and suppliers to remotely log in and manage the company’s extensive supply chain. It is an Angular single-page application. Based on a license key embedded in the app for AG Grid, it was created by SHI International Corp – USA on behalf of Toyota.

“I discovered what was essentially a backdoor login mechanism in the Toyota GSPIMS website/application that allowed me to log in as any corporate Toyota user or supplier just by knowing their email”, a security specialist who blogs under the pseudonym EatonWorks.

He eventually found the email address of the system administrator and was able to access their account. He says “I had full control over the entire global system”.

Also, he had complete access to all internal Toyota projects, data, and user accounts, including those of Toyota’s partners and suppliers from outside the company.

On November 3, 2022, Toyota was properly informed of the issues, and by November 23, 2022, the firm had verified they had been resolved.

Specifics of the Toyota’s Breach

The researcher made the decision to investigate any potential threats concealed behind the login screen.

He had to modify the JavaScript code to get beyond the login screen. Here, developers may control who has access to particular pages by utilizing the Angular framework, which will return true or false.

Patching the Angular functions
Patching the Angular functions

Researcher explains that patching the JavaScript was all that was needed to achieve full access since their API was improperly secured. 

In GSPIMS’ case, no data would load from the API. All the endpoints would return HTTP status 401 – Unauthorized responses due to the missing login cookie.

“Toyota/SHI had seemingly secured their API correctly, and at this point, I was about to write this site off as “probably secure”. I don’t bother reporting single-page-application bypasses unless it also exposes a leaky/improperly secured API”, says the researcher.

Further, the analyst rapidly realized that the service was creating a JSON Web Token (JWT) based on the user’s email address for password-less login. Therefore, someone may create a valid JWT if they were able to guess a genuine email address of a Toyota employee.

“I had discovered a way to generate a valid JWT for any Toyota employee or supplier registered in GSPIMS, completely bypassing the various corporate login flows, which probably also enforce two-factor authentication options”, the researcher.

Acquiring a valid JWT
Acquiring a valid JWT

Then the researcher was trying to locate a user who had the System Admin position and came across another API endpoint called findByEmail that only required a valid email to return data on a user’s account. Conveniently, this also identifies the managers of the user.

This gave him access to the User Administration section. He poked around more and found users with even higher access, such as Supplier Admin, Global Admin, and finally, System Admin.

A GSPIMS system administrator has access to private data, including 14,000 user profiles, project schedules, supplier rankings, and classified documents.

Internal Toyota documents
Internal Toyota documents

Researcher said Toyota prevented what may have been a disastrous leak of information about both their partners’ and suppliers’ employees as well. It was possible to make embarrassing internal remarks and supplier rankings public. 

Because cyberattacks on Toyota and its suppliers have previously occurred, another one was quite likely.

Modern cars: A growing bundle of security vulnerabilities

InfoSec Threats
 | InfoSec books | InfoSec tools | InfoSec services

Tags: Hacked Toyota

Nov 17 2022

6 Tips for Understanding 3rd-Party Risk in the Cloud

Category: Information Security,Vendor AssessmentDISC @ 10:21 am

If you’re like most modern organizations, you rely on third-parties to help you run and grow your business. Yet the vendors, partners and suppliers that make up your supply chain are also a significant component of your cloud environment attack surface. While you can’t (and shouldn’t) cut third-parties off completely, you can (and should) enforce the principle of least privilege when providing them with permissions into your single and multicloud environment. Read on to learn how to implement this essential modern security practice and tips for getting started.

Why are Third Parties So Risky for Your Cloud Environment?

Third parties, including suppliers, contractors, vendors, partners and even your cloud provider are a fundamental part of your organization’s business ecosystem. They help with any and all aspects of business growth, from engineering and IT to marketing and business development, and legal and strategy. Many of these third parties have other third parties they work with to help run their own businesses, and so on. This natural business reality creates a supply chain of companies and networks interlinked in various ways.

But all this help has a dark side: third parties and supply chains create considerable vulnerabilities in your cloud environment. According to IBM’s 2022 Cost of a Data Breach Report, 19% of breaches were caused by a supply chain compromise. The average total cost of a third-party breach was $4.46M, which is 2.5% higher than the average cost of a breach. In addition, identifying and containing third-party breaches took an average of 26 days longer compared to the global average for other kinds of breaches.

The vulnerability of third parties arises from the different security hygiene practices and controls each business in your ecosystem employs. In many cases, their standards are less stringent than your own, creating inconsistency and an increase in their relative security vulnerability.

In May 2021, U.S. President Biden dedicated an entire section in his monumental CyberSecurity Executive Order to the hardening of the supply chain and mitigation of risks of vendor attacks. The order states that “the development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors.” In short, the order notes that since it is easier for an attacker to breach, third-party software is more susceptible to exploitation.

Third-party vulnerabilities are not just software-related. Security practices that are different, mismatched and/or below your organization’s standard also create vulnerabilities. For example, some third parties may not practice password hygiene. In other cases, they may be reusing credentials or accidentally misconfiguring their environments.

Once they gain access to your supplier, attackers may find it easier to access your environments as well. Unlike malicious attackers, for which organizations are on the alert, organizations tend to treat third-parties as trusted entities. As such, third-parties are granted access and control over sensitive resources. Sometimes, this access is required for them to perform their work. Too often, though, permissions are intentionally or unintentionally over-privileged – due to manual errors, oversight or not knowing better. As a result, attackers that access your vendors can exploit this trust and breach your environments as well. Overprivileged permissions put your critical systems and data at risk, and can disrupt your compliance with regulations.

Third Parties in the Cloud: Why the Risk is Different from On-Premises

In the cloud, excessive trust of third parties and supply chain actors is riskier than on-premises environments – not just because one’s guard is down but due to the nature of cloud architecture and how it differs from on-premises.

On-premises, local servers and components enabled delineating network borders and implementing security controls to protect those borders, like firewalls. But in the cloud, infrastructure is distributed and resides on public infrastructure, making surrounding it with security controls impossible. This means that previously used security tactics and solutions, like third-party PAMs, are no longer helpful.

In addition, the distributed nature of the cloud, alongside the workforce’s reliance on cloud-based resources for their work (e.g, on SaaS apps), has changed connectivity needs. Businesses going through cloudification now rely on identities and credentials as the main means for providing access to company resources, making identity the new security perimeter.

It’s not only human users that require identities for access. The cloud has transformed many architectures from monoliths to microservices to support more development agility. These cloud services now also need digital identities as their main means for resource access. In some cases even your cloud provider can be a third party with access, often authorized, to your environment. Still, maintaining a list of CSP-managed accounts can be a difficult task.

Identities: A Complicated Security Affair

In the cloud, IT, DevOps, Security and DevSecOps are now managing thousands of new digital organizational identities, each with a complex sub-set of permissions that determines which resources they can access and the actions they can take on those resources. In the recent 2022 Trends in Security Digital Identities survey, by the independent group Identity Defined Security Alliance (IDSA), 52% of identity and security professionals identified cloud adoption as the driver of the growth of organizational identities.

Managing and monitoring these identities and their permissions is extremely complicated. The combination of the high volumes of identities and the intricacies of their permissions makes it almost impossible to avoid oversights and manual errors.

This extreme difficulty in avoiding permissions error has dangerous security implications. Verizon’s 2022 Data Breach Investigations Report (DBIR) finds that credentials are the number one organizational security weakness. When it comes to third-parties, the same research finds that the use of stolen credentials and ransomware are the top two “action varieties” leading to incidents. Per Ermetic research, ransomware potential is the cause of misconfigured identities, publicly exposed machines, risky third-party identities and risky access keys. In other words, third-party credentials are a focus point of violation for attacking companies and breaching their data. Protecting third-party credentials needs to be part of everyone’s security strategy.

Third-Parties: A Global Necessity and Pain

Businesses operating in a legacy-security mindset tend to block any risk or threat. But modern security strategies require security teams to act as business enablers. This means security needs to be maintained without slowing down business productivity and performance. Overcoming the third-party business vs. security dilemma is challenging, since while the supply chain is an inherent risk, it is also essential to a business’s success. Shutting down third-party operations is equivalent to shutting down business operations.

But the risk speaks for itself: third-party access in the cloud requires a dedicated security approach to permissions management. Fortunately, the principle of least-privilege is the modern security practice that can answer identity-management complexity – including that of third parties – in the cloud. By minimizing user and service permissions to only those deemed necessary for business operations, organizations can reduce their blast radius and attack surface in case of an attack. When it comes to third parties, the principle of least privilege – including its implementation via tools like Just in Time access – enables providing third parties only with the necessary access for the business while minimizing the risk these entities pose.

Implementing the Principle of Least Privilege for Third Parties in the Cloud

Let’s look into the various options for managing the risk of third-party permissions with least privilege.

Solution #1: Manual Maintenance

To secure third-party access to resources, IT and security need to find a way to keep track of all identities and their permissions. Some businesses rely on manual tracking in spreadsheets or other similar means. This quickly turns into long lists of identity names, the resources they have access to and their permissions.

However, manual maintenance in spreadsheets or by other means cannot capture the complexity of permissions management requirements. Many identities have access to a large number of resources, each with different authorization requirements. These all need to be meticulously tracked – spreadsheets are not equipped for presenting this information in a consumable fashion.

In addition, permissions can be inherited. This means that if service A has permissions to control service B, and service B has permissions for service C, service A will have permissions for service C. This creates a complex chain of permissions that is hard to create and visualize manually.

Excessive permissions derive from a complex chain of permissions that is hard to determine, visually present and keep up with manually
Excessive permissions derive from a complex chain of permissions that is hard to determine, visually present and keep up with manually

Finally, permissions need to be continuously monitored. Creating a one-time picture of permissions does not reflect the mercurial nature of the cloud or legitimate needs that come up requiring elevated or expanded permissions be granted for a certain amount of time.

Scanning and reviewing all these permissions takes time and concentration, which many IT and security teams don’t have. In addition, understanding the complexity, depth and how permissions are intertwined requires cloud security expertise, which not all security and IT teams have or have had time to develop. Even if they did, is this the best use of their time?

Here’s an example of one JSON permissions doc. Imagine having to comb through thousands of these and identifying any errors or issues:

Typical JSON permissions document - where lie the risky permissions?
Typical JSON permissions document – where lie the risky permissions?

Solution #2: Automation and Least Privilege to Reduce Third-Party Risk

Constantly updating manual spreadsheets while also being able to pinpoint any excessive or toxic permissions requires painstaking tracking, which resembles the type of analysis a machine would perform, not a human. The required level of detail, the scope of data and the speed of decision-making required when managing and monitoring the principle of least privilege screams “automation.” Doing so in a multicloud, let alone single cloud, environment is daunting.
Here are six tips for ensuring your automated mechanism can protect you from third-party risk with least privilege:

Tip #1: Monitor for Excessive Third-Party Permissions

As we’ve established, permissions in the cloud are convoluted by nature. An automated, multicloud monitoring mechanism will check third-party credentials for excessive permissions or toxic combinations and identify if these permissions violate the principle of least privilege by providing them with the unnecessary ability to access sensitive data and modify infrastructure. This information will be visualized by its risk severity, and any attacker reconnaissance capabilities will be highlighted. The evaluation of severity will take into account any risk offsetting covered by other policy definitions, including network related, along the permissions chain.

Tip #2: Monitor with Care and Context

Modern security strategies are business enablers and growth enthusiasts. Therefore, security controls need to be applied in a contextual manner. Rather than blocking any potentially vulnerable activity, actions need to be implemented intelligently. With permissions, it is essential to provide context of permissions scope. Not all third-party capabilities are dangerous for the business. Excessive permissions, i.e., those that exceed the principle of least-privilege, are the ones that should be mitigated. Automated security controls provide mechanisms for marking accounts and services as trusted, reducing false alerts.

Tip #3: Auto-Remediate Third-Party Vulnerabilities

Engineering, IT and security teams are busy and have alert fatigue. A helpful automated solution does not just highlight the problem but also helps solve it. Instead of adding more tasks to the teams’ full plate, take care to choose a solution that can provide a recommended substitute policy and auto-remediate into your organization’s workflows, and even shift left with optimized policies through infrastructure as code, while leaving more advanced issues to human judgment.

Tip #4: Set Permissions Guardrails

Guardrails limit the actions an identity can perform. This helps minimize the blast radius by capping the potential of what a user or principal can do. Determining automated guardrails are especially important with third-parties, since it is often easier for IT teams to provide them with excessive access or accepting the cloud vendor’s default configurations rather than having to go into the weeds and figuring out how to limit their permissions to the resources they actually need.

Tip #5: Ensure Ease of Use

Automation should support you, not make your daily flow more difficult. A helpful automated solution will integrate with the security and engineering teams’ workflows. This can be done through easy to understand dashboards, clear instructions, integrations into the CI/CD cycle and integrations with tools like Slack or PagerDuty.

Tip #6: Deliver JIT Access

JIT (Just-in-Time) access is a security principle that provides access to users for a limited period of time and then revokes it. JIT is useful for when users need permissive entitlements to complete a certain task, such as when developers need to fix a bug in production.

A secure automated solution will support JIT access for third-parties as well. That way, if your vendor needs to access a sensitive environment for an important work-related issue, you can provide them with such access without leaving attackers with a permanent window of opportunity for reconnaissance.


From a business perspective, third parties are as much a part of your business as any internal department. But from a security perspective, these entities need to be approached intentionally and with strategic caution. Third parties carry huge risks since their security practices are beyond your control.

The answer to managing these vulnerabilities is through an automated security solution that enforces least privilege and JIT access. Automated permissions management and monitoring reduces access risk by assigning third-parties, including developers, with only the access they need. This is the best way to balance and ensure business continuity and security in your cloud.

The post 6 Tips for Understanding 3rd-Party Risk in the Cloud appeared first on Ermetic.

Tags: 3rd-Party Risk

Nov 09 2022

Information Security Risks That You Need to be Careful With Vendors

Category: Information Security,Vendor AssessmentDISC @ 12:46 pm

nformation Security Risks assisted Business models for banking & financial services(BFS) institutions have evolved from being a monolithic banking entity to multi-tiered service entity.

What this means to BFS companies is that they need to be more updated and relevant with regards to technology & the quality of all services provided to their clients. The most opted methodology to do that today is by means of outsourcing services to vendors & 3rd parties.

Though outsourcing is cost beneficial to companies, this approach comes with its own set of drawbacks. It is judicious to say that every outsourcing enterprise should be aware of the risks that vendors bring to the table.

Though vendors bring in a lot of operational Information Security Risks depending on the business engagement, a methodology to manage only the 3rd party Information Security Risks are discussed here.

Just to provide a sense of the impact that vendor Information Security Risks brings to organizations, below are some of the facts from surveys conducted by Big 4 consulting companies like PwC & Deloitte.

“The Number of data breaches attributed to 3rd party vendors has increased by 22% since 2015”- Source PwC

According to Deloitte “94.3% of executives have low to moderate confidence in their third-party risks management tools & technology, and 88.6% have low to moderate confidence in the quality of the underlying Information Security Risks management process” .

We know the problem now, how do you begin resolving it??

A perfect place to begin is with the sourcing team and /or procurement team depending on how your organization is set up. In an ideal world, these teams are expected to have an inventory of all vendors, 3rd parties & Partners of your organization.

Once we have this inventory in place, the IT vendor risk management (IT- VRM) team needs to segregate the IT vendors from the non-IT ones. This is a onetime activity. For future needs, it is recommended to have the sourcing team segregate vendors basis on their business engagement (IT vs Non-IT).

Understanding your Vendors & the Information Security Risks they carry:

One of the simplest & efficient way to understand your vendors is by having a scoping checklist, that details the vendor business with your organization, kind of data touchpoints & exchanges, kind of Information Security Risks that your organization is exposed by this outsourced business.

This information is usually available with the vendor manager representing your organization in the vendor relationships.

Below is the list of Information Security Risks pointers (not limited to) that you might want to consider asking your vendor manager.

  • Regulatory risk – Does this relationship affect your regulatory posture? What is the penalty associated with such regulatory non-compliance?
  • Reputational risk– Does this service impact your clients & the reputation you hold with them?
  • Financial risk– Any financial Information Security Risks associated with business engagement?
  • Information security risks – what data are shared as part of the business engagement with the vendor? how secure is the vendor with regards to protecting your organization data?
  • Resiliency risks – Does the vendor introduce any single point of failures to your business practices?

For understanding the level of assessment to be performed with the vendor, you will need to understand the vendor’s business operating model.

Below is an indicative list of themes that you might want to discuss with vendor manager to understand the scope of the vendor assessment.

  • Data attributes shared & received with the vendor, volume of data & frequency
  • Mode of communication/interfaces with a vendor – Mail, remote connection to vendor network, the remote connection from vendor to your internal network, data upload only, data download only, vendors are brought on-site & connect from your offices to provide services
  • Services provided – Data center services, Application provider, Cloud service provider, Data processing services, & many others.

Information Security Risks Rating, Assessment recurrence & Assessment type:

Cybersecurity and Third-Party Risk: Third Party Threat Hunting

Tags: 3rd party risks, Vendors security risks

Oct 02 2022

White House Releases Software Supply Chain Security Guidance

Category: Vendor AssessmentDISC @ 1:39 pm

The White House published a memo requiring agencies to comply with guidance from the Office of Management and Budget (OMB) which aims to improve software supply chain integrity and security. 

Signed by OMB Director Shalanda Young, the memo builds on Executive Order (EO) 14028, Improving the Nation’s Cybersecurity from May 2021, which is focused on the security and integrity of the software supply chain.

That EO emphasized the importance of secure software development environments and directed the National Institute of Standards and Technology (NIST) to issue guidance identifying practices that enhance the security of the software supply chain.

The recent memo, published on September 14, requires each federal agency to comply with the NIST guidance when using third-party software on the agency’s information systems or otherwise affecting the agency’s information.

Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center, said it is heartening to see the memo establish a desire for consistency in the process by which they obtain self-attestations from suppliers.

“Such consistency and any eventually-centralized repository should help minimize the burden suppliers have in complying with the requirements of this memo,” he explained. “This is the first point where we have a directive for agencies to comply with guidance emerging from EO 14028.”

Software Supply Chain Security: A Challenging Space

Mackey said the single most important thing to realize is that software security is a problem space and that there is no silver bullet.

“No single action will prevent the next ransomware attack and the execution of tools doesn’t inherently fix vulnerabilities,” he said. “This is a highly technical space that is rather complex and nuanced. Well-intentioned humans will always make some mistakes and perfection isn’t attainable.”

That means the IT security industry needs to accept that software will always have weaknesses that can be exploited in certain circumstances.

“The moment you combine software into a supply chain, the potential for weaknesses increases and the potential for the authors of components within the supply chain to know the circumstances of how their software is used goes down,” Mackey said. 

Rick Holland, CISO and vice president of strategy at Digital Shadows, a provider of digital risk protection solutions, said from his perspective, the White House’s EO on improving the nation’s cybersecurity was a step in the right direction.

He said the OMB guidance is another good step; however, he added that this is a very long journey that will be measured not in months, but in years and, possibly, decades.

“The guidance focuses on vendor self-attestations and not independent validation,” he pointed out. “A government software supplier could claim to comply with NIST standards, but without third-party confirmation, the agency won’t know for sure. Zero-trust principles should apply here, too; don’t trust that a supplier is compliant—confirm it.”

He argued that the biggest threat to supply chain security is the complexity in defending against supply chain threats.

“Point-in-time security questionnaires are a legal requirement, not a preventive control. The number of third-party providers can be staggering, with security teams having to assess hundreds of providers,” he said.

Holland pointed out that security teams often don’t know the sensitive data their suppliers can access or the attack paths coming from their partners.

“Adversaries often do a better job of data discovery than defenders,” he added. 

A Plan For Moving Forward

Mike Parkin, senior technical engineer at Vulcan Cyber, a provider of SaaS for enterprise cybersecurity risk remediation, said the idea behind the government’s plan is good and the NIST guidelines are solid.

“What remains to be seen is how vendors will implement the guidance and whether it is enough to deal with a very dynamic threat space,” he added. 

He said while zero-day vulnerabilities still get the biggest headlines, the fact remains that users represent the broadest threat surface.

“Phishing, social engineering and other attacks against personnel remain consistent threat vectors and will almost certainly remain so,” he explained. “Having the most secure application code and supply chain won’t help when users are still giving up their passwords.”

Parkin said by requiring third-party vendors to adhere to the NIST standards, they can encourage them to develop software that is more secure and more robust—but that only really applies to vendors that want to work in the government space.

“They can’t necessarily push those standards on the public sector,” he noted. “And without a robust testing scheme to assure that when a vendor says ‘We comply’, that they actually do, some risks will remain.”

Mackey said mitigating software supply chain threats requires an understanding of the risk such threats pose to both the production of software and its associated operation and communicating the nature of those risks from producers to operators.

Properly managing software supply risk requires teams to move from a paradigm where tools are run and teams “do security” to one where the impact of findings from tools are understood and mitigations are made based on the context of how the given application runs.

“Solving this problem requires teams to think in terms of risk analysis first and then identify which tooling is best positioned to provide data supporting the analysis,” he explained.

Parkin added that threat actors have always adapted to the defenses put in place to stop them, and it’s difficult to say what technique they’ll shift to next.

“They will continue to look for vulnerabilities in the software, and they will continue to go after the users using whatever technique they find works,” he warned.

white house supply chain

Tags: Software Supply Chain Security Guidance

Sep 21 2022

Vendor Security Assessment

Category: Information Security,Vendor AssessmentDISC @ 10:14 pm

Assessing the security of network equipment.

decorative image

This document provides guidance on how operators should assess the security of vendor’s security processes and vendor equipment and is referenced in the Telecom Security Act Code of Practice.

The purpose of the guidance is to allow operators to objectively assess the cyber risk due to use of the vendor’s equipment. This is performed by gathering objective, repeatable evidence on the security of the vendor’s processes and network equipment.


Tags: Third-party risk management, vendor assessment

Sep 07 2022

Government guide for supply chain security: The good, the bad and the ugly

Category: Information Security,Vendor AssessmentDISC @ 8:11 am

ust as developers and security teams were getting ready to take a breather and fire up the BBQ for the holiday weekend, the U.S.’s most prestigious security agencies (NSA, CISA, and ODNI) dropped a 60+ page recommended practice guide, Securing the Software Supply Chain for Developers.

My first reaction was that it’s great to see these agencies adding to the public discourse in these still heady days where we’re all sorting out software supply chain security best practices. This is an important voice in shaking out the still many requirements, frameworks, and best practices, and kudos to them for sharing some of their hard-fought lessons learned.

But I think it’s also important for developers at large to weigh what makes sense in the most extraordinarily sensitive national security environments, versus what makes sense for the average enterprise developer and security team.

Here’s what stuck out to me as the good, bad, and ugly implications of the report.

The good

There are some excellent, prescriptive recommendations in the report where these agencies are advocating specific frameworks like Supply chain Levels for Software Artifacts (SLSA, pronounced “salsa”) and Secure Software Development Framework (SSDF). The report mentions these frameworks 14 and 38 times, respectively, and for developers and security teams that realize they have a software supply chain security problem but don’t know where to start, now they have a clear path to take their first steps.

The upshot of these frameworks is they give developers clear guidance on (1) how to develop secure code, from design issues to organizational structure issues for more secure software; (2) build system integrity (making sure malicious code isn’t being injected in our build systems); and (3) what happens after software is built and how to operate systems security (vulnerability remediation, monitoring, those types of aspects).

I also think the report does an excellent job of emphasizing what software signing buys developers in terms of artifact security, and how by making the investment in signing and verifying at the start of the software development lifecycle, you can save yourself a lot of toil not having to worry about the security of the package managers further down the line.

The bad

The guide suggests that “all development systems must be restricted to development operations only” … and goes on to say “no other activity such as email should be conducted for business nor personal use.”

I can’t see a future where developers are told they can’t do Slack, email and web browsing on their dev machines, and here’s an example where what’s mandatory in air-gapped environments like the NSA don’t really map out to mainstream developer scenarios.

I also find that the SBOM guidance has great points, but also misses concrete threats and mitigation examples. Overall the industry continues to tell everyone to use SBOMs, but doesn’t really explain what to do with them or what the real benefits are. And while I like the guidance to compare SBOMs with software composition analysis (SCA) results, the reality is that today’s vulnerability scanners actually miss a lot of the transitive dependencies that make software supply chains an attractive threat surface in the first place.

The ugly

While open source is mentioned 31 times in the guide, it’s mostly superficial references, with no new recommendations. We all know most source code being used today is open source, and it has unique aspects for security – the report doesn’t pay any care to how to choose which open source projects to use, what to look for when deciding on a new dependency, approaches to scoring systems, or how to tell the security health of an OSS project.

There’s quite a bit of information overload. Half of the document explains what its contents are, and the other half presents a couple of frameworks and the intersections of those frameworks. I think what we’re going to see next is a tidal wave of security vendor product whitewashing, claiming to have the first capabilities conforming to these guidelines – but it’s important to remember that there is no accreditation process, and most of this will simply be marketing bluster.

What’s next

Software supply chain security is pretty unique – you’ve got a whole lot of different types of attacks that can target a lot of different points in the software lifecycle. You can’t just take one piece of security software, turn it on, and get protected from everything.

Guides and recommendations like this that come down from the most sophisticated organizations that have gone through the early paces give a lot of great clues for developers at large, and I hope the NSA/CSA/ODNI will continue to disclose this type of insight … even if it may require some decoding for what applies to more mainstream developer scenarios outside of the Pentagon.

Cyber Security and Supply Chain Management: Risks, Challenges, and Solutions

Tags: supply chain, Vendor Security Assessment

Aug 28 2022

Why You Need a Third-Party Risk Management (TPRM) Program

Category: Vendor AssessmentDISC @ 9:56 am

What entity, or sector doesn’t engage with a third party in some way, shape or form? Not many. The reality is that outsourcing, contracting and subcontracting happen all the time and is the norm as businesses continue to embrace the core/context mindset and division of labor. The more you outsource, the more you need to have a robust third-party risk management process (TPRM), also known as vendor risk management, plan in place.

Risk management is not new, but the current iteration of TPRM logic typically focuses on three parts:

  • Risk assessment and analysis
  • Risk evaluation and
  • Risk treatment.

I had the pleasure of chatting with David Medrano, director of third-party risk management at Morgan Franklin, who shared his insight on the importance of TPRM and vendor oversight. Medrano explained that many enterprise entities may have over 1,000 separate third-party engagements and, therefore, must have a methodology to measure the risk each of those presents.

Medrano said that while many entities know their contractors, they may lack visibility into the contractor’s contractor; thus, a daisy chain of outsourced work may be taking place which places data at an unknown level of risk as the third party shares it with a fourth party and so on. The most important thing an organization can do, in this case, is to categorize vendors in the planning/strategy phase. Suggested risk buckets may include critical vendors, physical vendors and technology vendors.

“Bucket them according to how and what they do and how their third-party actions present a risk to you,” Medrano said. The risk from the coffee vendor, for instance, is not the same as the risk provided by an MSSP. He advised caution with regard to allowing more risk to be accepted than the vendor’s worth or value to the enterprise.

Medrano also advised keeping the methodology used uniform, as that can help manage risk while also showing customers, regulators and compliance entities that the company has a methodology in place to measure and address risk and explains the company’s thought processes with regard to its actions.

TPRM Tools

Ironically, there are a plethora of vendors (yes, third parties) who are prepared to provide you with tools to create your TPRM program, there are also standardized methodologies available from the U.S. government. For example, the National Institute of Standards and Technology (NIST) has created a TPRM framework to help companies create a consistent and uniform TPRM plan which is adaptable to their unique needs. The NIST framework can help you:

  • Prepare – Essential activities to prepare the organization to manage security and privacy risks
  • Categorize – Categorize the system and information processed, stored and transmitted based on an impact analysis
  • Select – Select the set of NIST SP 800-53 controls to protect the system based on risk assessment(s)
  • Implement – Implement the controls and document how controls are deployed
  • Assess – Determine if the controls are in place, operating as intended and producing the desired results
  • Authorize – Senior official makes a risk-based decision to authorize the system (to operate)
  • Monitor – Continuously monitor control implementation and risks to the system

In sum, every business unit should be using a TPRM system, regardless of if their engagement with third-party vendors is centralized or decentralized. Additionally, uniformity in the assessment is of paramount importance, Medrano said.

Third-Party Risk Management: Driving Enterprise Value

Cybersecurity and Third-Party Risk: Third Party Threat Hunting

IT Vendor RISK Management Toolkit

Tags: Third Party Risk, Third Party Threat Hunting, Third-party risk management, TPRM, Vendor Security Assessment

Aug 25 2022

Twilio Hackers Scarf 10K Okta Credentials in Sprawling Supply Chain Attack

The “0ktapus” cyberattackers set up a well-planned spear-phishing effort that affected at least 130 orgs beyond Twilio and Cloudflare, including Digital Ocean and Mailchimp.

Okta logo on a mobile phone screen

The hackers who breached Twilio and Cloudflare earlier in August also infiltrated more than 130 other organizations in the same campaign, vacuuming up nearly 10,000 sets of Okta and two-factor authentication (2FA) credentials.

That’s according to an investigation from Group-IB, which found that several well-known organizations were among those targeted in a massive phishing campaign that it calls 0ktapus. The lures were simple, such as fake notifications that users needed to reset their passwords. They were sent via texts with links to static phishing sites mirroring the Okta authentication page of each specific organization.

“Despite using low-skill methods, [the group] was able to compromise a large number of well-known organizations,” researchers said in a blog post today. “Furthermore, once the attackers compromised an organization, they were quickly able to pivot and launch subsequent supply chain attacks, indicating that the attack was planned carefully in advance.”

Such was the case with the Twilio breach that occurred Aug. 4. The attackers were able to social-engineer several employees into handing over their Okta credentials used for single sign-on across the organization, allowing them to gain access to internal systems, applications, and customer data. The breach affected about 25 downstream organizations that use Twilio’s phone verification and other services — including Signal, which issued a statement confirming that about 1,900 users could have had their phone numbers hijacked in the incident.

The majority of the 130 companies targeted were SaaS and software companies in the US — unsurprising, given the supply chain nature of the attack.

For instance, additional victims in the campaign include email marketing firms Klaviyo and Mailchimp. In both cases, the crooks made off with names, addresses, emails, and phone numbers of their cryptocurrency-related customers, including for Mailchimp customer DigitalOcean (which subsequently dropped the provider).

In Cloudflare’s case, some employees fell for the ruse, but the attack was thwarted thanks to the physical security keys issued to every employee that are required to access all internal applications.

Lior Yaari, CEO and co-founder of Grip Security, notes that the extent and cause of the breach beyond Group IB’s findings are still unknown, so additional victims could come to light.

“Identifying all the users of a SaaS app is not always easy for a security team, especially those where users use their own logins and passwords,” he warns. “Shadow SaaS discovery is not a simple problem, but there are solutions out there that can discover and reset user passwords for shadow SaaS.”

Time to Rethink IAM?

On the whole, the success of the campaign illustrates the trouble with relying on humans to detect social engineering, and the gaps in existing identity and access management (IAM) approaches.

“The attack demonstrates how fragile IAM is today and why the industry should think about removing the burden of logins and passwords from employees who are susceptible to social engineering and sophisticated phishing attack,” Yaari says. “The best proactive remediation effort companies can make is to have users reset all their passwords, especially Okta.”

The incident also points out that enterprises increasingly rely on their employees’ access to mobile endpoints to be productive in the modern distributed workforce, creating a rich, new phishing ground for attackers like the 0ktapus actors, according to Richard Melick, director of threat reporting at Zimperium.

“From phishing to network threats, malicious applications to compromised devices, it’s critical for enterprises to acknowledge that the mobile attack surface is the largest unprotected vector to their data and access,” he wrote in an emailed statement.


#InfoSecTools and #InfoSectraining



Follow DISC #InfoSec blog

Ask DISC an InfoSec & compliance related question

Tags: authentication, authorization, Identity and Access Management

Aug 15 2022

Patch Madness: Vendor Bug Advisories Are Broken, So Broken

Category: Bug Bounty,Information Security,Vendor AssessmentDISC @ 12:56 pm

Dustin Childs and Brian Gorenc of ZDI take the opportunity at Black Hat USA to break down the many vulnerability disclosure issues making patch prioritization a nightmare scenario for many orgs.

Image of a bug spewing out code

BLACK HAT USA – Las Vegas – Keeping up with security-vulnerability patching is challenging at best, but prioritizing which bugs to focus on has become more difficult than ever before, thanks to context-lacking CVSS scores, muddy vendor advisories, and incomplete fixes that leave admins with a false sense of security.

That’s the argument that Brian Gorenc and Dustin Childs, both with Trend Micro’s Zero Day Initiative (ZDI), made from the stage of Black Hat USA during their session, “Calculating Risk in the Era of Obscurity: Reading Between the Lines of Security Advisories.”

ZDI has disclosed more than 10,000 vulnerabilities to vendors across the industry since 2005. Over the course of that time, ZDI communications manager Childs said that he’s noticed a disturbing trend, which is a decrease in patch quality and reduction of communications surrounding security updates.

“The real problem arises when vendors release faulty patches, or inaccurate and incomplete information about those patches that can cause enterprises to miscalculate their risk,” he noted. “Faulty patches can also be a boon to exploit writers, as ‘n-days’ are much easier to use than zero-days.”

The Trouble With CVSS Scores & Patching Priority

Tags: Vendor Bug Advisories

Jul 14 2022

Vendor Security Assessment

Category: Information Security,Vendor AssessmentDISC @ 8:43 am

Assessing the security of network equipment.

decorative image

This document provides guidance on how operators should assess the security of vendor’s security processes and vendor equipment and is referenced in the Telecom Security Act Code of Practice.

The purpose of the guidance is to allow operators to objectively assess the cyber risk due to use of the vendor’s equipment. This is performed by gathering objective, repeatable evidence on the security of the vendor’s processes and network equipment.


Cybersecurity and Third-Party Risk: Third Party Threat Hunting

DISC InfoSec

#InfoSecTools and #InfoSectraining



Ask DISC an InfoSec & compliance related question

Tags: supply chain, Third-party risk management, third-party vendor program, Vendor Security Assessment

May 29 2022

How to Identify and Reduce the Risks of 3rd Party Vendors

Category: Vendor AssessmentDISC @ 12:45 pm

How to Identify and Reduce the Risks of 3rd Party Vendors

In a landscape filled with new threats and regulations managing the risks of 3rd party vendors is vitally important. Most financial institutions have tens of thousands of supplier relationships, and many data breaches originate through IT Vendors within the supply chain. Compounding this dilemma, regulators including OIG, OCC, FFIEC and others are increasing their focus on potential 3rd party risks. They want to see organizations proactively identifying potential risks, verifying that business partners providers and their employees are compliant, monitoring for changes that might create new risks or compliance gaps, and managing the investigation and remediation of incidents.

During this webcast our panel will specifically address the practical ‘how to’s’ around identifying and reducing the risks of 3rd party vendors, and we will focus on:

  • Typical risks resulting from third party relationships
  • Common deficiencies of vendor management practices used during the on-boarding process, and the life of the relationship
  • Moving from a reactive to a proactive (preventative) vendor management process
  • Real world examples will be used to illustrate the key points and recommendations

In a landscape filled with new threats and regulations managing the risks of 3rd party vendors is vitally important. Most financial institutions have tens of thousands of supplier relationships, and many data breaches originate through IT Vendors within the supply chain. Compounding this dilemma, regulators including OIG, OCC, FFIEC and others are increasing their focus on potential 3rd party risks. They want to see organizations proactively identifying potential risks, verifying that business partners providers and their employees are compliant, monitoring for changes that might create new risks or compliance gaps, and managing the investigation and remediation of incidents.

During this webcast our panel will specifically address the practical ‘how to’s’ around identifying and reducing the risks of 3rd party vendors, and we will focus on:

– Typical risks resulting from third party relationships
– Common deficiencies of vendor management practices used during the on-boarding process, and the life of the relationship
– Moving from a reactive to a proactive (preventative) vendor management process
– Real world examples will be used to illustrate the key points and recommendations

Source: https://


Tags: Cybersecurity and Third-Party Risk, Risks of 3rd Party Vendors

Mar 31 2022

How to read a SOC 2 Report

how to read a SOC 2 report

The following conversation about reviewing a SOC 2 report is one to avoid. 

Potential Customer: “Hi Vendor Co., do you have a SOC 2?”

Vendor Co. Sales Rep: “Yes!”

Potential Customer: “Great! We can’t wait to start using your service.” 

The output of a SOC 2 audit isn’t just a stamp of approval (or disapproval). Even companies that have amazing cybersecurity and compliance programs have a full SOC 2 report written about them by their auditor that details their cybersecurity program. SOC 2 reports facilitate vendor management by creating one deliverable that can be given to customers (and potential customers) to review and incorporate into their own vendor management programs.

Vendor security management is an important part of a company’s cybersecurity program. Most mature organizations’ process of vendor selection includes a vendor security review – a key part of which includes the review of a SOC 2 report.

SOC 2 reports can vary greatly in length but even the most basic SOC 2 report is dense with information that can be difficult to digest, especially if you aren’t used to reading them. This article will teach you how to read a SOC 2 report by providing a breakdown of the report’s content, with emphasis on how to pull out the important parts to look at from a vendor security review perspective.

Please note that you should not use this as a guide to hunt and peck your way through a SOC 2 report. It is important to read through the entire report to gain a full understanding of the system itself. However, this should help draw attention to the particular points of interest you should be looking out for when reading a report. 

Many different auditing firms perform SOC 2 audits, some reports may look a little different from the others but the overall content is generally the same.

How to read a SOC 2 report: the Cover Page

Even the cover page of a SOC 2 report has a lot of useful information. It will have the type of SOC 2 report, date(s) covered, the relevant trust services criteria (TSC) categories, and the auditing firm that conducted the audit. 

What Type of SOC 2 Report?

There are two types of SOC 2 reports that can be issued: A SOC 2 Type I and a SOC 2 Type II. The type of report will be denoted on the cover page. The key difference is the timeframe of the report:

A SOC 2 Type I is an attestation that the company complied with the SOC 2 criteria at a specific point in time. 

A SOC 2 Type II is an attestation that the company complied with the SOC 2 criteria over a period of time, most commonly a 6 or 12 month period. 

SOC 2 Type II reports are more valuable because they demonstrate a long-term commitment to a security program – and any issues over the time frame will be revealed. It’s possible for a company to get a SOC 2 Type I report then fail to adhere to their controls. 

Key takeaway: If a company only has a SOC 2 Type I, ask if and when they are working on achieving a SOC 2 Type II. If they say they are not getting a Type II, this is indicative of a lower commitment to security. 

Trust Services Criteria

Cybersecurity for Executives in the Age of Cloud 

Tags: SOC 2 report, SOC2

Mar 24 2022

Strengthening third-party vendor programs in times of crisis and beyond

Category: Vendor AssessmentDISC @ 10:05 pm

The ongoing global turmoil has tested the supply chain across industries in a myriad of ways – from strained resources and remote workflows to security concerns and more. Sustaining a resilient supply chain is one area where many organizations have seen disruptions and business risk, mostly related to managing third-party vendors.

Recent reports have found that 85% of companies are losing money to third-party integration issues related to their supply chains – some losing over $1 million per year. Much of this is contributed by outdated integration systems – those that are not cloud-based – as well as a lack of end-to-end business process visibility. In addition, 35% of businesses have stated their compliance teams have no way of knowing if third-party partners are compliant. Not only is this a big problem financially, but it indicates that most aren’t aware of what is happening across business transactions, which could contribute to even greater future risk and loss.

To overcome these challenges, businesses must implement an agile risk management program that prioritizes third-party risk management. Building a formalized third-party risk management program that strengthens end-to-end process visibility is a three-step process.

Step one: Define and build the program

Defining the current state of an IT and third-party risk management program is the first step in understanding what is working, and most critically, what is not working. This includes a complete audit of existing vendors and the potential risks they pose; this gives leaders visibility into current risks, identifies addressable risk, and unnecessary future risks that can be preemptively mitigated. This process also enables organizations to create new standards and goals for an improved third-party vendor program. For example, organizations need to understand communication processes between IT and third-party risk management teams to unearth potential issues caused by manual processes, inadequate reporting and/or inaccessibility to relevant data.

Top-down sponsorship and bottom-up execution is also key when developing a third-party compliance program. Organization-wide alignment shifts third-party vendor processes from a “check box” compliance exercise to a consistent, thorough process that underscores the significance of having a risk management program in place. For example, many organizations have a vendor onboarding checklist that includes tasks like reviewing their product/service track record, financial stability and if they’ve run afoul of the law. However, a consistent, thorough process would also encompass activities like ongoing due diligence that regularly checks a vendor’s risk profile for financial, regulatory, and reputational risk.

To break down silos and make adoption more seamless, organizations should consider automating these processes, and integrating with systems of record across the business. This will grow program efficacy, create greater efficiency in operations and most importantly, will support a risk management program that can evolve alongside future compliance needs, workflows, and processes.

Step two: Establish resources, priorities, and foundational assets

A primary reason executive sponsorship is critical is because organizations need to determine what resources are available to actualize plans.

Key stakeholders across IT, HR and risk and compliance will be instrumental in not just the rollout of an improved third-party vendor program, but also in defining the scope. Allocating resources can be anything from identifying internal subject matter experts, formalizing committees, or determining if and how new hires need to be evaluated.

Because you can’t boil the ocean, it is important to understand which vendors have the greatest potential impact to the business. With this data in hand – which is accessed by foundational assets like robust risk management tools and solutions – project stakeholders can prioritize risks by level of importance and formulate an actionable plan.

Lastly, establishing and enforcing a library of controls within these solutions can improve processes and decrease the level of risk. By doing so, the organization can manage enforcement for internal as well as regulatorily enforced best practices, while also ensuring that any third parties with access to these systems follow the same requirements, thereby creating uniformity of process and reducing risk.

Step three: Implement program methodology

In addition to assessing third parties, a key step in building a healthy risk management program is defining metrics. The program methodology should include established reporting standards and target metrics, allowing success to be measured over time. With benchmarks from step one in place, teams can measure how cloud integrations led to overall improvements, or how quickly potential risks were rectified, for example.

Employee training plays a big role here as everyone within an organization needs to be able to navigate third-party risk management solutions with ease. Training should include the entire risk management function and provide repeatable introductions into the change management challenges that are associated with any new program, process, or system.

While a robust solution with automated workflows will certainly resolve integration issues and streamline processes, organizational buy-in for third-party risk management programs is what defines resilient vendor relationships and a healthy compliance program. Using this methodology to create a risk-based strategy will not only help a business establish and maintain a strong vendor supply chain but can help identify future risks enabling teams to mitigate them before they become a business-impacting issue, which is what businesses resilience is all about.

Cybersecurity and Third-Party Risk: Third Party Threat Hunting 

Tags: third-party vendor program

Nov 04 2021

Supply Chain at Risk: Brokers Sell Access to Shipping, Logistics Companies

Category: Risk Assessment,Vendor AssessmentDISC @ 8:54 am

As if disruption to the global supply chain post-pandemic isn’t bad enough, cybercriminals are selling access, sometimes in the form of credentials, to shipping and logistics companies in underground markets.

That’s a worrisome, if not unexpected, development; a cybersecurity incident at a company that operates air, ground and maritime cargo transport on multiple continents and moves billions of dollars worth of goods could prove devastating to the global economy.

“At the moment, the global supply chain is extremely fragile. This makes the industry a top target from cybercriminals who will look to take advantage of today’s current situation,” said Joseph Carson, chief security scientist and advisory CISO at ThycoticCentrify. “The global chip shortage is resulting in major delays, with some stock unavailable or backlogged for more than six months, making it a prime attraction for cybercriminals to attempt to expose and monetize this via various scams. This includes redirecting shipments by changing logistic details or causing disruptions via ransomware.”

The actors, ranging from newcomers to prolific network access brokers, are selling credentials they obtained by leveraging known vulnerabilities in remote desktop protocol (RDP), VPN, Citrix and SonicWall and other remote access solutions, according to the Intel 471 researchers tracking them.

“No business or IT security team would willingly allow bad actors to exploit known vulnerabilities in remote access technologies, but this is exactly what is happening,” said Yaniv Bar-Dayan, CEO and co-founder of Vulcan Cyber, who believes much of the problem is a result of poor cybersecurity hygiene.

In one instance last August, an actor that has worked with groups deploying Conti ransomware said they had accessed “corporate networks belonging to a U.S.-based transportation management and trucking software supplier and a U.S.-based commodity transportation services company,” the researchers wrote in a blog post. “The actor gave the group access to an undisclosed botnet powered by malware that included a virtual network computing (VNC) function.” The group then used the botnet “to download and execute a Cobalt Strike beacon on infected machines, so group members in charge of breaching computer networks received access directly via a Cobalt Strike beacon session,” they said.

supply chain IoT edge trucking

Supply Chain Risk Management

Supply Chain Risk Management

Tags: Supply Chain at Risk

Apr 08 2021

4 things you can do to minimize cyberattacks on supply and value chains

Category: Vendor AssessmentDISC @ 11:06 am

The SolarWinds hack was a classic supply chain attack, compromising downstream organizations in order to traverse the victim’s extended enterprise of customers, suppliers, vendors and other third parties to gain unauthorized access to their on-premises and cloud systems.

The hack was unprecedented, transforming a core security product into a malware delivery system that provided unauthorized access to sensitive data for a minimum of nine months by escalating privileges, forging access tokens, and other alterations that went undetected.

Minimize supply chain cyberattacks

How can your organization protect itself from data breach by affected third parties in your supply or value chain? Apart from “basics” such as enforcing least privilege for third-party users and forcing administrative password resets on initial use (to avoid “username:admin, password:admin” scenarios), below are four unique and effective ways your organization can mitigate access-related third-party risk.

4 things you can do to minimize cyberattacks on supply and value chains

Tags: cyberattacks on supply and value chains

Apr 06 2021

What is Third-Party Risk?

Category: Vendor AssessmentDISC @ 10:09 pm

Next Page »