Cloud

5/29/2018
11:10 AM
Jai Vijayan
Jai Vijayan
Slideshows
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

6 Ways Third Parties Can Trip Up Your Security

Poor access control, inadequate patch management, and non-existent DR practices are just some of the ways a third party can cause problems
Previous
1 of 7
Next

Image Source: arka38 via Shutterstock

Image Source: arka38 via Shutterstock

The security risks posed by third parties connecting to enterprise networks are well understood.

In recent years, countless organizations have suffered data breaches as the result of a security failure at a vendor, supplier, partner or other third-party with access to their network.

Fifty-six percent of organizations in a 2017 Ponemon Institute survey say they had experienced a data breach stemming from a third-party security failure. More than 4-in-10 (42%) of the respondents say that attacks on their third parties resulted in a misuse of their organization's sensitive and confidential data and 75% believe that risks from third parties is increasing.

One big issue that survey respondents identify is the lack of visibility into the security status of third-party networks and systems. Although third parties have access to an increasing amount of enterprise data, more than half of the respondents in the survey have no inventory of all the external people accessing their networks and data.

The issue is a problematic one for enterprises, especially with regulations such as the EU's General Data Protection Regulation, which went into effect recently. Organizations increasingly are being held directly responsible for breaches stemming from third-party failures and are therefore under the gun to do more about ensuring their vendors and others follow security best practices.

"Third-party vendor risk is the unseen threat for enterprises dealing with cyber-risk," says Dan O'Sullivan, an analyst with UpGuard.  "Like a rip in the back of a jacket, the fact that risks taken on by third-party vendors are not visible does not mean they do not expose you to the world," he notes.

Here in no specific order are some of the most typical ways your third-party can trip up your security:

 

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio

Previous
1 of 7
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Microsoft Fixes 11 Critical, 39 Important Vulns
Kelly Sheridan, Staff Editor, Dark Reading,  6/12/2018
Why CISOs Need a Security Reality Check
Joel Fulton, Chief Information Security Officer for Splunk,  6/13/2018
Cisco Talos Summit: Network Defenders Not Serious Enough About Attacks
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/13/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12580
PUBLISHED: 2018-06-19
library/DBTech/Security/Action/Sessions.php in DragonByte vBSecurity 3.x through 3.3.0 for vBulletin 3 and vBulletin 4 allows self-XSS via $session['user_agent'] in the "Login Sessions" feature.
CVE-2018-12578
PUBLISHED: 2018-06-19
There is a heap-based buffer overflow in bmp_compress1_row in appliers.cpp in sam2p 0.49.4 that leads to a denial of service or possibly unspecified other impact.
CVE-2018-1061
PUBLISHED: 2018-06-19
python before versions 2.7.15, 3.4.9, 3.5.6 and 3.7.0 is vulnerable to catastrophic backtracking in the difflib.IS_LINE_JUNK method. An attacker could use this flaw to cause denial of service.
CVE-2018-1073
PUBLISHED: 2018-06-19
The web console login form in ovirt-engine before version 4.2.3 returned different errors for non-existent users and invalid passwords, allowing an attacker to discover the names of valid user accounts.
CVE-2018-12557
PUBLISHED: 2018-06-19
An issue was discovered in Zuul 3.x before 3.1.0. If nodes become offline during the build, the no_log attribute of a task is ignored. If the unreachable error occurred in a task used with a loop variable (e.g., with_items), the contents of the loop items would be printed in the console. This could ...