Data Privacy Day rolls around year after year, and data privacy breaches likewise. Two-thirds of data breaches result in data exposure.

There are continued breaches of data privacy, and according to Omdia's Security Breaches Tracker, approximately two-thirds of security breaches involve data exposure, many of these of personally identifiable information (PII). Data Privacy Day serves to highlight the inadequacies of data protection and to support the confidentiality of information.

Omdia's Cybersecurity Decision Maker survey, conducted in the second quarter of 2022, found that 32% of organizations are "extremely confident" in their organization's security controls, and a further 58% describe themselves as "reasonably confident." However, this confidence is likely misplaced. The same survey found that 77% of organizations have suffered numerous security incidents and breaches, some with a severe impact on the organization. Realistically, strong security controls should be preventing some of these incidents and breaches.

Some of these security breaches are included in Omdia's Security Breaches Tracker. This data looks at the leading outcome of security breaches, and in the breaches reported during the first nine months of 2022, for 66% of breaches tracked this was data exposure. Looking back at the historical data to 2019, we see that approximately two-thirds of breaches have consistently resulted in data exposure: 68% in 2021, 67% in 2020, and 64% in 2019. Thus, it is not a stretch to say that organizations will continue to fail customers' data privacy expectations.

**Not a One-and-Done Task**

Better cyber hygiene would result in few breaches of data privacy; however, cyber hygiene is not a one-and-done task. Cyber hygiene can be defined as the good practice that all organizations can follow to minimize the opportunity for cybersecurity incidents to materialize. Examples include timely patching, password management, backups, and much more.

Cyber hygiene requires constant review and updating, because malicious actors are also constantly reviewing and updating their offensive capabilities. Attacks range from ransomware-as-a-service (RaaS) to highly sophisticated nation-state and organized criminal group attacks — a significant threat landscape.

Other factors challenging good cyber hygiene include: the omnipresent security workforce shortage, that organizational data is frequently spread far and wide with no proper handle on all the locations, gray areas of responsibility when it comes to actions such as patching, the complexity of cybersecurity, and more.

Failures in cyber hygiene can lead to opportunities for breaches of data privacy. Not only does this erode customer trust in the organization, it also opens the organization to potential regulatory breaches and fines.

Data privacy legislation has been enacted around the world, and there are plenty of examples of breaches of data privacy legislation. A significant fine of €390 million was issued to Meta (which owns Facebook) for breaking EU data laws on using personal data to deliver targeted advertisements. The ruling rejected Meta's argument that when people engage with social media platforms, such as accepting terms and conditions, they are actually agreeing to receive personalized ads. The ruling was made this month (January 2023), and Meta plans to appeal the decision.

Some consumers are becoming more savvy about their data and how it should be kept private. However, apathy and lack of knowledge are also evident among customers when it comes to data privacy: Many are not always aware of what they are signing up for or don't care about what they are signing for because they get something for free.

In many parts of the world, if a company discovers a breach of data privacy regulations, it must inform its customers and support them. There are, however, many organizations that take their time to report breaches, and especially if they have not created a playbook for such a situation, they may struggle to follow the right and appropriate rules, handle any press inquiries, deal with ransomware demands, and so on.

**Take It Personally**

It is incumbent upon those responsible for data privacy at an organization to look after their customers' data in the same way that they would expect other organizations to look after personal data about them. There is no doubt that maintaining data privacy is a challenge, but it must be tackled head on as a component of winning and maintaining customer trust. Data Privacy Day serves to remind everyone that data is precious and must be looked after.

In no small part, data security focuses on maintaining data privacy. Data security is essential to the fundamental ideas of information ownership, which are dependent on a comprehensive strategy and are made up of three primary elements.

The first of these elements is data discovery, needed to successfully locate information assets that may require protection. The second element is data governance, necessary to ensure that data is managed properly while internal policies are adhered to and external compliance requirements are met. Finally, data protection is essential to prevent information from being accessed or potentially compromised by unauthorized parties.

Ultimately, organizations must focus on data security to have a hope of maintaining the confidentiality of the information they are responsible for, thus adhering to data privacy regulations and expectations.

On Data Privacy Day, Organizations Fail Data Privacy Expectations

In Apache::Session::LDAP before 0.5, validity of the X.509 certificate is not checked by default when connecting to remote LDAP backends, because the default configuration of the Net::LDAPS module for Perl is used. NOTE: this can, for example, be fixed in conjunction with the CVE-2020-16093 fix.

@@ -119,22 +119,32 @@ sub ldap { push @servers, $server; }  
# Compatibility my $caFile = $self\->{args}\->{ldapCAFile} || $self\->{args}\->{caFile}; my $caPath = $self\->{args}\->{ldapCAPath} || $self\->{args}\->{caPath};  
# Connect my $ldap = Net::LDAP\->new( \\@servers, onerror \=> undef, verify \=> $self\->{args}\->{ldapVerify} || "require", ( $caFile ? ( cafile \=> $caFile ) : () ), ( $caPath ? ( capath \=> $caPath ) : () ),  
( $self\->{args}\->{ldapPort} ? ( port \=> $self\->{args}\->{ldapPort} ) : () ), ) or die( 'Unable to connect to ' . join( ' ', @servers ) ); ) or die( 'Unable to connect to ' . join( ' ', @servers ) . ': ' . $@ );  
# Start TLS if needed  
if ($useTls) { my %h = split( /\[&=\]/, $tlsParam ); $h{cafile} = $self\->{args}\->{caFile} if ( $self\->{args}\->{caFile} ); $h{capath} = $self\->{args}\->{caPath} if ( $self\->{args}\->{caPath} ); $h{verify} ||= ( $self\->{args}\->{ldapVerify} || "require" ); $h{cafile} ||= $caFile if ($caFile); $h{capath} ||= $caPath if ($caPath); my $start\_tls = $ldap\->start\_tls(%h); if ( $start\_tls\->code ) { $self\->logError($start\_tls);

CVE-2020-36658: Add ldapVerify option for SSL cert validation · LemonLDAPNG/Apache-Session-LDAP@490722b

In Apache::Session::Browseable before 1.3.6, validity of the X.509 certificate is not checked by default when connecting to remote LDAP backends, because the default configuration of the Net::LDAPS module for Perl is used. NOTE: this can, for example, be fixed in conjunction with the CVE-2020-16093 fix.

@@ -154,10 +154,18 @@ sub ldap { push @servers, $server; }  
# Compatibility my $caFile = $self\->{args}\->{ldapCAFile} || $self\->{args}\->{caFile}; my $caPath = $self\->{args}\->{ldapCAPath} || $self\->{args}\->{caPath};  
# Connect my $ldap = Net::LDAP\->new( \\@servers, onerror \=> undef, verify \=> $self\->{args}\->{ldapVerify} || "require", ( $caFile ? ( cafile \=> $caFile ) : () ), ( $caPath ? ( capath \=> $caPath ) : () ),  
( $self\->{args}\->{ldapRaw} ? ( raw \=> $self\->{args}\->{ldapRaw} ) : () @@ -169,10 +177,12 @@ sub ldap { ) or die( 'Unable to connect to ' . join( ' ', @servers ) );  
# Start TLS if needed  
if ($useTls) { my %h = split( /\[&=\]/, $tlsParam ); $h{cafile} = $self\->{args}\->{caFile} if ( $self\->{args}\->{caFile} ); $h{capath} = $self\->{args}\->{caPath} if ( $self\->{args}\->{caPath} ); $h{verify} = $self\->{args}\->{ldapVerify} || "require"; $h{cafile} = $caFile if ( $caFile ); $h{capath} = $caPath if ( $caPath ); my $start\_tls = $ldap\->start\_tls(%h); if ( $start\_tls\->code ) { $self\->logError($start\_tls);

CVE-2020-36659: Add ldapVerify option for SSL cert validation · LemonLDAPNG/Apache-Session-Browseable@fdf3932

Improper input validation in driver adgnetworkwfpdrv.sys in Adguard For Windows x86 up to version 7.11 allows attacker to gain local privileges escalation.

CVE-2022-45770: Versions history | AdGuard

Jenkins OpenID Plugin 2.4 and earlier improperly determines that a redirect URL after login is legitimately pointing to Jenkins.

**Open redirect vulnerability in Jenkins OpenID Plugin**

Moderate severity GitHub Reviewed Published Jan 26, 2023 to the GitHub Advisory Database • Updated Jan 27, 2023

GHSA-mj62-m63x-mh84: Open redirect vulnerability in Jenkins OpenID Plugin 

A missing permission check in Jenkins GitHub Pull Request Builder Plugin 1.42.2 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

CVE-2023-24435: Jenkins Security Advisory 2023-01-24

Missing permission checks in Jenkins Orka by MacStadium Plugin 1.31 and earlier allow attackers with Overall/Read permission to connect to an attacker-specified HTTP server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

CVE-2023-24433: Jenkins Security Advisory 2023-01-24

A cross-site request forgery (CSRF) vulnerability in Jenkins Gerrit Trigger Plugin 2.38.0 and earlier allows attackers to rebuild previous builds triggered by Gerrit.

CVE-2023-24423: Jenkins Security Advisory 2023-01-24

A missing permission check in Jenkins Orka by MacStadium Plugin 1.31 and earlier allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins.

CVE-2023-24431: Jenkins Security Advisory 2023-01-24

A cross-site request forgery (CSRF) vulnerability in Jenkins Keycloak Authentication Plugin 2.3.0 and earlier allows attackers to trick users into logging in to the attacker's account.

Tag

#perl