Category: Cyber Security

To assist stakeholders in their migration from PA-DSS to the Software Security Framework, PCI Security Standards Council (PCI SSC) is publishing a series of blog posts to guide payment software vendors and assessors through the key differences between PA-DSS and the SSF. In Part One of our multi-part blog series, PCI SSC’s Sr. Manager, Public Relations Alicia Malone sits down with PCI SSC’s Sr. Manager, Emerging Standards Jake Marcinko to discuss some of the conceptual differences between PA-DSS and the Software Security Framework that stakeholders should be aware of as they work to transition between programs.

What is the PCI Software Security Framework?

Jake Marcinko: The PCI Software Security Framework (SSF) is a collection of security standards and associated validation and listing programs for promoting software security in the payments industry. The SSF is comprised of the Secure Software Standard and the Secure Software Lifecycle (Secure SLC) Standard.

The Secure Software Standard defines the security features and attributes that payment software must possess, and the Secure SLC Standard defines the security processes and capabilities that a software vendor must have in place to ensure its software is developed securely.

The SSF replaces the PCI Payment Application Data Security Standard (PA-DSS) which is being retired in October 2022.

Why was the Software Security Framework created and why is PA-DSS being retired?

Jake Marcinko: PA-DSS was one of the first standards and programs of its kind. It laid the groundwork for software security in the payments industry, and it has served the payment industry’s needs for over 10 years. Those needs, however, have evolved to the point that it no longer made sense to make incremental changes to an aging standard and program. A new approach was needed to support modern payment software architectures and software development methodologies, and to protect payment software from increasingly complex software attacks.

What benefits does the Software Security Framework provide over PA-DSS?

Jake Marcinko: The SSF builds on many of the concepts introduced in PA-DSS but is designed to provide both software vendors and assessors a more dynamic, faster-to-market approach to security validation for a broader array of software types compared to PA-DSS.

In PA-DSS, the scope of software eligible for validation and listing was limited to software that facilitates payment authorization. Under the SSF, the eligibility criteria for software validation has been expanded to include software providing additional functions such as fraud monitoring or cardholder authentication. Additionally, by separating software requirements and vendor requirements into different standards, vendors who produce software that is ineligible for validation to the Secure Software Standard are able to demonstrate good software security hygiene through independent Secure SLC validation.

PCI SSC recommends that software vendors with eligible payment software products have both their software development lifecycle (SDLC) practices and payment software validated to the respective SSF standards. Validating to both standards not only demonstrates that a vendor’s payment software is secure upon validation, but also demonstrates greater assurance that the software will remain secure throughout its lifetime. To encourage validation to both standards and to support faster time-to-market strategies, the SSF provides a more streamlined listing management process to Secure SLC qualified software vendors with validated payment software. This process enables qualified software vendors to manage and publish updates to their validated payment software listings more quickly than previously supported under PA-DSS.

More information on these and other benefits can be found in the respective Program Guides under the Software Security section of the PCI SSC Document Library.

What are ‘objective-based’ requirements in the Software Security Framework and how are they different from PA-DSS requirements?

Jake Marcinko: PA-DSS requirements specify the practices and security controls that must be implemented to meet a particular security objective. The SSF supports a newer approach among PCI security standards, including the PCI 3-D Secure (3DS) security standards and the Customized Approach in PCI DSS version 4.0, where security requirements are expressed as security objectives that provide greater flexibility in how requirements are met. This approach is referred to as ‘objective-based’ and recognizes that there are often many different ways to satisfy a particular security objective.

How does the objective-based approach provide software vendors more flexibility?

Jake Marcinko: The objective-based approach enables software vendors to choose the practices and methods that best meet the security objectives given the entity’s unique business requirements and capabilities, rather than having to implement the specific practices and methods stipulated in more prescriptive security standards such as PA-DSS.

For example, where PA-DSS requires the use of specific password complexity parameters such as minimum length and composition, the corresponding control objective in the Secure Software Standard requires that authentication methods be ‘sufficiently strong and robust to protect authentication credentials from being forged, spoofed, leaked, guessed, or circumvented’ in accordance with industry-accepted methods. This enables software vendors to choose which industry-accepted authentication methods to implement to meet the control objective rather than having to implement the password complexity parameters stipulated in PA-DSS.

How does the objective-based approach benefit security assessors?

Jake Marcinko: The testing procedures in PA-DSS specify the verification methods that assessors are required to use to validate security requirements, with limited flexibility. The SSF permits assessors to deviate somewhat from the methods stated in the test requirements where necessary. This is referred to as ‘alternative testing’ and it permits assessors to use alternative verification methods if the stated methods aren’t sufficient to properly validate the control objectives.

For example, many SSF test requirements require examination of software vendor documentation and evidence to validate control objectives. In certain circumstances, it may be more appropriate to validate a control objective using interviews or other assessor-provided tools. Under the SSF, assessors are permitted to use such verification methods even if those verification methods aren’t explicitly stated in the test requirement. This provides assessors greater flexibility in determining how best to confirm control objectives have been met. The use of alternative testing does not allow assessors or software vendors to change what the test requirement is verifying, or to reduce the thoroughness of the testing.

How does the Software Security Framework’s support for PCI DSS differ from PA-DSS?

Jake Marcinko: PA-DSS was developed explicitly to facilitate PCI DSS compliance for entities implementing payment applications in a cardholder data environment. The SSF was developed with broader applicability in mind and covers a broader range of security topics and data assets than PA-DSS and PCI DSS. The SSF is also intended to apply to payment software and software vendors regardless of whether PCI DSS applies to the environment in which the payment software is deployed.

For these reasons, the security requirements in the SSF standards do not map directly to PCI DSS requirements like the PA-DSS requirements do. With that said, the SSF security standards still support an entity’s PCI DSS compliance by enabling entities who use qualified software vendors and/or validated payment software to potentially meet some PCI DSS requirements without the need for additional detailed testing.

For example, bespoke or custom software provided by a Secure SLC qualified software vendor is confirmed to have been developed in accordance with a rigorous set of secure software development best practices. The use of such software by a merchant or service provider (who may also be the Secure SLC qualified software vendor) may satisfy a number of sub-requirements under PCI DSS Requirement 6 without the need to have those sub-requirements retested by a QSA.

Similarly, payment software that has been validated to the Secure Software Standard is confirmed to possess robust sensitive data protection mechanisms. Use of such software by a merchant or service provider may satisfy corresponding requirements in PCI DSS for the protection of cardholder data and authentication credentials during storage and transmission.

Entities anticipating the publication of PCI DSS v4.0 should expect even greater alignment between PCI DSS and the SSF standards with the introduction of the Customized Approach. Please refer to the PCI SSC website for more information on PCI DSS v4.0.

How will the differences between PA-DSS and the Software Security Framework impact vendors of currently validated PA-DSS applications?

Jake Marcinko: It is possible that some vendors with PA-DSS validated applications may need to upgrade their software or software development practices to meet applicable SSF requirements. This isn’t intended to undermine the value that PA-DSS validation has provided over the years. Given the increasing complexity of modern software and the sophistication of modern software attacks, the SSF standards contain additional requirements that weren’t included in PA-DSS.

PCI SSC recognizes that there are a number of important differences between PA-DSS and the SSF, and a lot of information about the Secure Software and Secure SLC standards and programs that stakeholders must absorb. To assist with the transition between PA-DSS and SSF, PCI SSC is offering informational training classes for software vendors; details can be found in the Training and Qualification section of the PCI SSC website. Software vendors with validated PA-DSS applications are also encouraged to start working with a qualified SSF assessor company to help understand the differences and to begin the transition to SSF before PA-DSS is retired in October 2022.

Coming Soon: In Part Two of this blog series, we will discuss some of the key technical differences between PA-DSS and the SSF, including what critical assets are and why they are important; how cryptography and data storage requirements are different; and how the concept of the PA-DSS Implementation Guide has evolved. If you have any questions or topics related to the PA-DSS to SSF transition that you would like us to clarify in guidance, please forward those to software@pcisecuritystandards.org. 

Read more about the Software Security Framework.

New research has been published that points the finger at the Chinese government for being behind hacks of major telecommunications companies around Southeast Asia, all for the purpose of spying on high-profile individuals. 

Published by Cybereason, the report said that it found evidence of three different clusters of attacks going back to at least 2017, all perpetrated by groups or individuals connected in some way to advanced persistent threat (APT) groups Soft Cell, Naikon and Group-3390, which have each operated for the Chinese government in the past. 

SEE: Security incident response policy (TechRepublic Premium)

Cybereason said it believes the goal of the attacks was to established continuous access to telecom provider records “and to facilitate cyber espionage by collecting sensitive information, compromising high-profile business assets such as the billing servers that contain Call Detail Record (CDR) data, as well as key network components such as the Domain Controllers, Web Servers and Microsoft Exchange servers.”

Those up-to-date on the latest cybersecurity news will probably have heard of the exploit the attackers used to establish access. It’s the same one Chinese-based hacking group Hafnium used, and it’s the same one that allowed attackers to infiltrate SolarWinds and Kaseya: A set of four recently disclosed Microsoft Exchange Server vulnerabilities.

Target selection follows suit with SolarWinds, Kaseya and Hafnium attacks as well: APTs in those instances compromised third parties with the intent to surveil high-value customers of the affected organizations, like political figures, government officials law enforcement, political dissidents and others. 

Cybereason said its team started looking into Exchange vulnerabilities immediately after the Hafnium attacks “During the investigation, three clusters of activity were identified and showed significant connections to known threat actors, all suspected to be operating on behalf of Chinese state interests,” the report said. 

Overlap between the three clusters has occurred, Cybereason said, but it can’t figure out why: “There is not enough information to determine with certainty the nature of this overlap — namely, whether these clusters represent the work of three different threat actors working independently, or whether these clusters represent the work of three different teams operating on behalf of a single threat actor,” the report said.

Regardless of origin, the attacks have been very adaptive and actively maintain the backdoors they have into telecom networks. The report found that “attackers worked diligently to obscure their activity and maintain persistence on the infected systems, dynamically responding to mitigation attempts,” which it said indicates that the targets are highly valuable to the attackers.

SEE: How to manage passwords: Best practices and security tips (free PDF) (TechRepublic)

“These attacks compromised telcos primarily in ASEAN countries, but the attacks could be replicated against telcos in other regions,” the report concluded. As is often the case with widely publicized exploits used by APTs and cybercriminals, patches are available that close the gaps, and it’s in the best interest of companies using Microsoft Exchange both in-house and through Outlook Web Access (targeted by one of the clusters).

For more information on the report, be sure to attend Cybereason’s Aug. 5 seminar, where it will discuss its findings. 

Cybersecurity Insider Newsletter

Strengthen your organization’s IT security defenses by keeping abreast of the latest cybersecurity news, solutions, and best practices.
Delivered Tuesdays and Thursdays

Sign up today

Also see

Following a string of major cyberattacks and proposed initiatives by the U.S. government to better thwart them, cybersecurity has never been so uppermost on the minds of organizations and individuals around the world. That’s why this week’s Black Hat and DEF CON conferences promise to run hot and heavy with a host of topics in the world of security. But what discussions should we expect at this year’s events? Here are some thoughts from a variety of analysts.

First, how might Black Hat USA 2021 (held July 31 – Aug. 5) and DEF CON 29 (held Aug. 5 – 8) differ in their topics and slants? Both are joined at the hip because of their back-to-back schedules and slight distinctions, but there are some nuanced differences between the security conferences, according to 451 Research senior research analyst Daniel Kennedy. The events focus on information security, but Black Hat tends to adopt a more corporate slant.

SEE: Security incident response policy (TechRepublic Premium)

Looking at the lineup at DEF CON, Kennedy points to an expected slate of talks, such as ones on exploiting vulnerabilities in Windows and macOS/iOS, DNS issues, cryptography weaknesses and the compromising of security tools.

“But even a conference that focuses on the practical implementation of security compromises is not immune from macro issues discussed in information security,” Kennedy said. “And so not surprisingly there are topics on the evolution of ransomware to the scale of threat it has posed in the last twenty four months, concerns around security in healthcare specifically, and the role and scope of critical infrastructure protection and nation-state or equivalent capable threats.”

The government’s renewed attention on cybersecurity also seems reflected in the conference topics, Kennedy noted. The announcement of Secretary of Homeland Security Alejandro Mayorkas as a keynote speaker generated some controversy, though he had attended in 2015.

Supply chain attacks are likely to be a key topic on the agenda, according to senior security researcher Boris Larin. These types of attacks don’t just target one specific party; rather, they try to target an entire string of dependent companies. Recent supply chain attacks such as the SolarWinds breach, the Microsoft Exchange hack and the Kaseya ransomware incident show how a single security vulnerability can be exploited to affect multiple organizations and users.

Supply chain attacks are hard to detect and may infect hundreds, thousands or even millions of computers, Larin said. As such, these types of attacks are effective for cybercriminals who aim at a single supplier but gain access to the networks of all the customers and vendors who use its products.

“Suppliers might also be weaker from a security point of view; it is just simpler to infect a supplier than the end target,” Larin added. “The result of such attacks could be very devastating if instead of performing espionage operations, attackers would launch a wiper or ransomware. The effectiveness and impact of supply chain attacks leads us to expect that more APT groups and cybercriminals will try to perform such attacks in the future.”

The conferences are likely to pay attention to Exchange vulnerabilities, nation-state attacks, critical infrastructure and IoT and even jailbreaks of IOS 14, according to security researcher Victor Chebyshev.

With nation-state attackers perhaps the most important theme, Chebyshev said he believes there will be a lot of discussion about Pegasus and the NSO Group. But the starting point for this topic will be such Black Hat presentations as “The Kitten that Charmed Me: The 9 Lives of a Nation State Attacker about ITG18” by IBM X-Force about the infamous Charming Kitten threat group.

SEE: Checklist: Securing digital information (TechRepublic Premium)

Another topic expected by Chebyshev will focus on ways that attackers may bypass certain security tools. Specifically, Endpoint Detection and Response (EDR) and Managed Detection and Response (MDR) are two promising security methods designed to find and deal with cyberthreats. The Black Hat presentation “Rope: Bypassing Behavioral Detection of Malware with Distributed ROP-Driven Execution” will cover the topic of bypassing these detection mechanisms based on behavior.

Further, Chebyshev advises Black Hat attendees to check out “20+ Ways to Bypass Your macOS Privacy Mechanisms” and “Come to the Dark Side, We Have Apples: Turning macOS Management Evil” for details about attacks that target Macs.

“What I see lacking is the reports on attacks on Apple’s macOS ecosystem,” Chebyshev said. “Yes, there are a few reports on the topic, but not that many, especially given the relevance of the platform.”

Chris Steffen, research director at Enterprise Management Associates, expects a range of topics at Black Hat. 2020 was supposed to be the year people started to focus on IoT security, but the pandemic changed that; however, IoT security still needs to be a priority, and organizations want IoT security vendors to provide direction in this area.

IT management tools is another topic that should garner attention.

“With the recent ransomware attacks, there is a need to understand how these tools are being secured, evaluated, and reevaluated,” Steffen said. “It is something that the security industry has known for years, but it has taken high visibility attacks to finally get people (vendors, users, regulators) to pay attention to it.”

Chris Clements, vice president of solutions architecture for Cerberus Sentinel, sees three topics that promise to pop up at the conferences: 1) The continuing ubiquity of ransomware; 2) Potential targets and defenses for supply chain attacks; and 3) Microsoft’s recent security struggles.

For ransomware, Clements said he believes there will be a focus on new attack techniques as well as prevention and detection methods. In the realm of supply chain attacks, SolarWinds and Kaseya have shown us how many vendors have deep access into different networks. And as for Microsoft: “The recent ugly vulnerabilities in legacy Windows components like the print spooler have exposed that while the upcoming Windows 11 release may look slick and modern, Windows is a gigantic amalgamation of components with some code that’s old enough to drink in the US,” Clements said.

Cybersecurity Insider Newsletter

Strengthen your organization’s IT security defenses by keeping abreast of the latest cybersecurity news, solutions, and best practices.
Delivered Tuesdays and Thursdays

Sign up today

Also see

Cybersecurity researchers disclosed multiple flaws, dubbed PwnedPiper, that left a widely-used pneumatic tube system (PTS) vulnerable to attacks.

Researchers from cybersecurity Armis disclosed a set of nine vulnerabilities collectively tracked as PwnedPiper that could be exploited to carry out multiple attacks against a widely-used pneumatic tube system (PTS).

The Swisslog PTS system are used in the hospitals to automate logistics and the transport of materials throughout the building via a network of pneumatic tubes. 

The flaw affects the Translogic PTS system manufactured by Swisslog Healthcare, which is installed in about 80% of all major hospitals in North America and thousands of hospitals worldwide.

An attacker could exploit the PwnedPiper vulnerabilities to completely take over the Translogic Nexus Control Panel, which powers current models of Translogic PTS stations.

The flaws could be exploited by attackers to conduct a broad range of malicious activities, such as carrying out a man-in-the-middle (MitM) attack to change or deploying ransomware

“These vulnerabilities can enable an unauthenticated attacker to take over Translogic PTS stations and essentially gain complete control over the PTS network of a target hospital,” reads the post published by Armis. “This type of control could enable sophisticated and worrisome ransomware attacks, as well as allow attackers to leak sensitive hospital information.”

The flaws include privilege escalation, memory corruption, remote-code execution, and denial-of-service issues. An attacker could also push an insecure firmware upgrade to fully compromise the devices.

These are the nine vulnerabilities discovered by the researchers:

• CVE-2021-37161 – Underflow in udpRXThread
• CVE-2021-37162 – Overflow in sccProcessMsg
• CVE-2021-37163 – Two hardcoded passwords accessible through the Telnet server
• CVE-2021-37164 – Off-by-three stack overflow in tcpTxThread
• CVE-2021-37165 – Overflow in hmiProcessMsg
• CVE-2021-37166 – GUI socket Denial Of Service
• CVE-2021-37167 – User script run by root can be used for PE
• CVE-2021-37160 – Unauthenticated, unencrypted, unsigned firmware upgrade

Swisslog has released Nexus Control Panel version 7.2.5.7 that addresses most of the above vulnerabilities. The CVE-2021-37160 has yet to be addressed.

“This research sheds light on systems that are hidden in plain sight but are nevertheless a crucial building block to modern-day healthcare. Understanding that patient care depends not only on medical devices, but also on the operational infrastructure of a hospital is an important milestone to securing healthcare environments.” concludes the report.

Swisslog has also published security advisories for these vulnerabilities.

Follow me on Twitter: @securityaffairs and Facebook