With the National Cybersecurity Strategy planning to add real teeth into enforcement actions, software vendors have extra incentive to reduce applications' security debt.

We're in the midst of a transformational shift in software security. Companies will soon bear responsibility for insecure software and can no longer play the victim card.

Recently, President Biden's administration released its long-awaited National Cybersecurity Strategy, created with the hope to "secure the full benefits of a safe and secure digital ecosystem." As expected, it focuses to a large extent on software security and who should be liable for its vulnerabilities. Stating that "markets impose inadequate costs on — and often reward — entities that introduce vulnerable products or services," the strategy calls for making organizations more liable for shipping insecure software.

Putting aside the debate about regulation versus market forces, it's hard to argue with the strategy's implicit assertion that insecure software code is endemic. As security professionals, it's our job to examine why insecure software is so prevalent and understand how to address it. Furthermore, with this plan, software security would no longer be a nice-to-have: Companies will be liable for the security of their products. Therefore, now is the time to bring rigor to software security.

**The Root of Vulnerabilities**

Insecure software often starts at the beginning, where flaws are introduced. But before diving in, it's important to be clear about the terminology.

A "flaw" is an implementation defect introduced when code is written that can lead to a "vulnerability" — an exploitable condition within software code that opens the door to an attack. Flaws accumulate over time resulting in "security debt" — the flaws you don't fix over the lifetime of an application. Security debt has been an important driver in the rise of DevSecOps, which integrates security throughout the software development life cycle.

Veracode's most recent "State of Software Security" research report took a fine-grained look at the factors contributing to flaw introduction, using data drawn from static analysis of more than 750,000 applications.

It found that no matter the size, applications grow steadily at about 40% a year through the first five years. But the rate of new flaw introduction follows a different pattern. When a new application is onboarded, the number of flaws undergoes a precipitous drop, most likely as an initial scan discovers accumulated flaws. The app then enters the "honeymoon phase" through the first year and a half, during which nearly 80% of applications introduce no new flaws. When the honeymoon ends, however, the introduction of flaws grows steadily until plateauing around year five.

The most common flaws discovered vary widely depending on the type of scan conducted, as static, dynamic, and software composition analyses involve different techniques and can detect different issues. There was some overlap among the top flaws found — information leakage showed up in all three — but there were enough differences to underscore the importance of using multiple scan types.

Scan frequency also has an impact. We found a marked reduction in both the probability of new flaws and the actual number of them when scans were performed the previous month. Using application programming interfaces (APIs) to automate the scanning process was also beneficial in reducing the probability and number of flaws.

**Stepping Toward More Secure Applications**

Preventing all flaws from being introduced in the first place would be ideal, but it's just not practical. Our research uncovered three recommendations for making applications more secure.

Our first piece of guidance is to remediate security flaws as early and quickly as possible. By the time an application is two years old, we see applications increasingly accumulating flaws. It's clear that something happens to the application or to the groups developing them. Whether increasing application complexity from years of steady growth or diminishing focus on production applications over time, this familiar pattern of an upwards slant, shown in our research, is clear.

Our next piece of guidance is to prioritize automation and developer training. Awareness of the most common flaws and how they are introduced makes a notable difference in reducing their numbers. We saw this in results from organizations whose developers had completed 10 hands-on security training courses. Our research found that completion of 10 training courses correlates to a 12% reduction in the number of flaws introduced.

Lastly, companies need to establish application life-cycle management. Establishing who owns an application will help keep it secure, but don't try to make a comprehensive list upfront, because you'll never finish it. It would be better to start with the necessary information for a few applications and build the list iteratively from there.

Maintaining an application isn't just a matter of deciding whether it's needed, but also how long it should be in production. This is important given the growth of flaws that occur over time and the amount of attention that will be paid to it in later years.

**Rigor Is a Requirement**

In today's security climate, software security is paramount. With the National Cybersecurity Strategy planning to add real teeth into enforcement actions, software vendors have extra incentive to reduce the security debt of their applications.

Understanding how flaws are created and how best to remediate them can help ensure both the security and viability of software products.

Rigor in software security means being thorough at every stage of the modern software development life cycle as the shift of responsibility turns to you.

3 Strategies for Bringing Rigor to Software Security

New LLM-based projects typically become successful in a short period of time, but the security posture of these generative AI projects are very low, making them extremely unsafe to use.

There is a lot of interest in integrating generative AI and other artificial intelligence applications into existing software products and platforms. However, from a security standpoint these AI projects are fairly new and immature, exposing organizations using these applications to various security risks, according to recent analysis by software supply chain security company Rezilion.

Since ChatGPT’s debut earlier this year, more than 30,000 open source projects now use GPT 3.5 on GitHub, which highlights a serious software supply chain concern: How secure are these projects that are being integrated left and right?

Rezilion’s team of researchers attempted to answer that question by analyzing the 50 most popular Large Language Model (LLM)-based projects on GitHub – where popularity was determined by how many stars the project has. The project's security posture was measured by the OpenSSF Scorecard score. The Scorecard tool, from the Open Source Security Foundation, assesses the project repository on various factors, such as the number of vulnerabilities it has, how frequently the code is being maintained, its dependencies, and the presence of binary files, to calculate the score. The higher the number, the more secure the code.

The researchers mapped the project’s popularity (size of the bubble, y-axis) and security posture (x-axis). None of the projects analyzed scored higher than 6.1 – the average score was 4.6 out of 10 – indicating a high level of security risk associated with these projects, Rezilion said. In fact, Auto-GPT, the most popular project (with almost 140,000 stars), is less than 3 months old and has the third-lowest score of 3.7, making it an extremely risky project from a security perspective.

When organizations are considering which open source projects to integrate into their codebases or which ones to work with, they consider factors such as whether the project is stable, currently supported, actively maintained, and the number of people actively working on the project. Organizations have to consider several types of risks, such as trust boundary risks, data management risks, and inherent model risks.

"When a project is new, there are more risks around the stability of the project, and it’s too soon to tell whether the project will keep evolving and remain maintained,” the researchers wrote in their analysis. “Most projects experience strong growth in their early years before hitting a peak in community activity as the project reaches full maturity, then the level of engagement tends to stabilize and remain consistent.”

The age of the project was relevant, Rezilion researchers said, noting that most of the projects in the analysis were between 2 and 6 months old. When the researchers looked at both the age of the project and Scorecard score, the age-score combination that was the most common was projects that are 2 months old and have a Scorecard score of 4.5 to 5.

"Newly-established LLM projects achieve rapid success and witness exponential growth in terms of popularity,” the researchers said. “However, their Scorecard scores remain relatively low.”

Development and security teams need to understand the risks associated with adopting any new technologies and make a practice of evaluating them prior to use.

Open Source LLM Projects Likely Insecure, Risky to Use

Cl0p ransomware group uses its Dark Web leak site to identify five new victims of MOVEit cyberattacks.

Schneider Electric; Siemens Energy; the University of California at Los Angeles (UCLA); Werum, a pharmaceutical technology provider; and AbbVie, a biopharmaceutical company, are the five latest organizations identified on the Cl0p ransomware group's Dark Web data leak site as victims of MOVEit cyberattacks.

Threat actor directory organization Falcon Feeds monitors the Cl0p ransomware leak site and released the latest list to Twitter today.

For its part, UCLA uses MOVEit Transfer to transfer files across the campus and to other entities. In a statement to Dark Reading, the university noted that it discovered the attack on May 28, after which it "immediately activated its incident response procedures, fixed the vulnerability using the security patch issued by Progress Software, and enhanced monitoring of the system."

The statement continues, "the university notified the FBI and worked with external cybersecurity experts to investigate the matter and determine what happened, what data was impacted and to whom the data belongs. Those who have been impacted have been notified. This is not a ransomware incident. There is no evidence of any impact to any other campus systems."

Last Saturday, the New York City Department of Education (DoE) revealed it was also the victim of a MOVEit cyberattack, resulting the in unauthorized access of around 19,000 documents affecting 45,000 students.

"The FBI is investigating the broader breach that has impacted hundreds of entities; we are currently cooperating with both the NYPD and FBI as they investigate," the DoE announcement of the breach said. "Given that review and investigation are ongoing, we are limited in terms of additional details at this point."  

**MOVEit File Flaw**

Progress Software's MOVEit file transfer software zero-day vulnerability was discovered May 31 and traced back to the Russian ransomware group Cl0p. But before the zero-day bug could be patched, Cl0p already had its foothold in target systems.

The ransomware group reportedly sat on the MOVEit file transfer vulnerability for two years before it started to actively target victims including the BBC, British Airways, and the government of Nova Scotia.

Subsequent MOVEit victims emerged later, including Gen Digital, parent company of Avast and Norton.

UCLA, Siemens Among Latest Victims of Relentless MOVEit Attacks

The free tool aims to help organizations meet the requirements of the new version of the payment standard, which takes effect next March.

Jscrambler has released a free tool to help companies check the JavaScript code running on their e-commerce sites and bring them into compliance with the latest PCI DSS (Payment Card Industry Data Security Standards) version 4.0.

PCI Security Standards Council released PCI DSS v4.0 in March 2022 and began a two-year phaseout of the previous versions before beginning enforcement. By March 31, 2025, all retailers and e-commerce sites – anyone who handles payment cards online, really – will need to be in compliance with these requirements. Jscrambler's PCI DSS JavaScript Compliance Tool helps organizations assess whether the JavaScript on their e-commerce sites meet to two v4.0 requirements: protection against (6.4.3) and detection (11.6.1) of skimming attacks on all scripts from a merchant or its third- and fourth-party contractors.

Section 6.4.3 requires that companies confirm that each script is authorized, ensure the integrity of the scripts, and maintain a complete inventory that explains why each script is necessary. Section 11.6.1 applies to merchants that include a third party's iframe payment form on their websites; it compels an evaluation of the HTTP header and payment page periodically (usually every seven days) that looks for and notifies the merchant about any changes to the page.

The anti-skimming requirements are necessary because attackers are launching Web skimming campaigns by injecting malicious code into Magento, WooCommerce, Shopify, and WordPress sites. Magecart skimmers have been found on 2 million websites, including those of Ticketmaster and British Airways.

The Jscrambler tool searches for and collates all scripts on a merchant's site, performing script verification and authorization, and then logging the results, including compliance status. It visualizes each script, highlighting actions that are considered suspicious, analyzes scripts for function and generates justifications for using each. Alerts are triggered if scripts are tampered with, the contents of the payment page are changed without authorization, and the HTTP header is altered. All of these functions reduce manual compliance efforts and assist in generating audit-ready reports, the company said.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Jscrambler Launches JavaScript Scanner for PCI DSS 4.0 Compliance

One ransomware attack can be devastating for a small or midsize business. Here are four solid survival tips to ensure it doesn't turn into a disaster.

If your organization is hit with a ransomware attack, it's going to cost you. According to Verizon's "2023 Data Breach Investigations Report"(DBIR), released earlier this month, the median loss to a ransomware attack has risen to $26,000 and can go as high as $2.25 million.

"\[T\]he overall costs of recovering from a ransomware incident are increasing, even as the ransom amounts are lower. This fact could be suggesting that the overall company size of ransomware victims is trending down," the DBIR team wrote.

Much of the expense comes from the loss of business and recovery time. The average ransomware attack has a life cycle of more than 300 days. That's nearly a full year in which the organization is tied up with discovery and remediation — and almost two months longer than other types of cyber incidents. And then there are other costs to factor, such as long-term damage to the corporate brand and reputation, as well as loss of institutional knowledge when the employees who are held responsible for the attack are let go.

The costs surrounding a ransomware attack could cripple small and midsize businesses (SMBs) and even cause one to shut down. But it doesn’t have to be that way. Even for SMBs with tight IT/security budgets and limited security expertise, ransomware protection and recovery boils down to planning ahead.

The best way to avoid the high costs of a ransomware attack is to avoid being a victim, but protection and detection tools also come with hefty price tags. How much a company will need to pay depends on the number of employees and devices it needs to protect, but even a company with as few as 50 people can spend five figures on ransomware protection. Cyber insurance to protect the business in case of an attack could add at least $1,500 per $1 million in coverage, depending on the deductible.

Note that getting cyber insurance for ransomware is not easy; many insurance agencies are limiting coverage because of the high payout costs.

Organizations also need to think about the cybersecurity approach they want to take. How cybersecurity teams approach ransomware defense has changed over the years, says PJ Kirner, CTO and co-founder of Illumio. Cybersecurity has shifted from perimeter defense (setting up a secure perimeter to keep the bad guys out), to rapid detection (detecting and stopping as quickly as possible), to containment (limiting the amount of damage the attackers can cause once they break in).

Which approach an SMB decides to take determines the type of tools and protective actions it will need. A company deciding to contain malware would make investments to beef up authentication and privilege management in order to validate all users and devices before granting access to any transaction. A company focused on perimeter defense would have very different investments, requiring firewalls and other methods to keep attackers out of the network.

While an organization can adopt any number of security systems and tools, SMBs should consider the following actions, regardless of their overall security approach.

**1\. Decrease the Attack Surface**

Applying the concept of least-privilege access can close the door against ransomware attacks. The fewer people with access to applications and databases, the lower the chances for cybercriminals to also gain access and get in. Audit your users' roles to make sure they have access only to the software and services they need, especially if the software processes sensitive data.

For example, explains Kirner, Remote Desktop Protocol (RDP) is a popular access point for threat actors to get into a Windows system and launch ransomware. But RDP is most often used for IT help desks and troubleshooting. Most employees across the business have no need to have RDP accounts, yet they might have RDP enabled on their machines. Kirner advises revoking access if employees have no reason to have those accounts.

"Remove all that attack surface from your environment," Kirner says. "This is something you can do proactively and reduce the impact of ransomware."

Also worth disabling — especially in a Windows environment — is PowerShell. Attackers are increasingly using PowerShell in malware-less attacks. The average user is never going to use it, so it's better to disable it when setting up the user machine. Similarly, keep track of what accounts have been created on the network or for cloud applications and services. If the employee no longer needs it or has left the company, remove that account entirely. Cloud access security broker software can help manage and monitor employees’ cloud activity and enforce security policies.

**2\. Shift the Costs to the Attackers**

Another way to make your organization less attractive to bad actors is to make launching an attack more costly for the cybercriminal. Something as simple as restricting access to unnecessary applications shifts the burden to the attacker. If the attacker can’t do much with the application despite having user credentials — maybe they can only view reports but can’t extract data — the attacker has a choice of moving on to easier victims or working harder. Similarly, requiring multifactor authentication adds another roadblock for threat actors because just stealing credentials is no longer enough. Many types of MFA can fit an SMB's budget and security expertise, including biometrics, hardware tokens, and even the employee’s phone.

Attackers are economic actors, just like any other business, Kirner points out. "When they run out of time, they'll go to an environment with less security controls," he says.

**3\. Improve Your Security Hygiene**

Good security hygiene is important, regardless of company size.

The first step is to build an internal security culture around cybersecurity awareness and guidance, explains Dave Gerry, CEO at Bugcrowd. That doesn’t just mean watching security videos and calling it a day. Encourage open communications and give employees the confidence to report anything that seems suspicious.

Explain which external services and resources are allowed and why there are restrictions. Make it easy for employees to go through an approval process for getting access to tools so that they aren’t just going off and creating their own accounts.

Use modern training materials. Security companies are now producing training videos that are episodic, like sitcoms, or use techniques from reality shows that entertain as well as educate.

Gamification, such as setting up contests or offering rewards when designated milestones are met, also creates an environment where employees want to improve their security practices. Human error is a top cause of cyberattacks. When employees are encouraged to take an active role in cybersecurity and understand the consequences when they don't, you add another cybersecurity tool at little cost.

**4\. Don't Fail to Plan**

Prevention is important, but every organization should have a plan in place to mitigate an attack when it happens. The company should know who will be involved in mitigation and recovery, as well as how to handle the negotiations.

For example, because of the possibility that a ransomware attack can lead to permanently shutting down an SMB, many plan to pay the ransom. That requires setting a budget on how much to pay. If the organization does not already have a cryptocurrency wallet or access to cryptocurrency, that will make payment a bit difficult. SMBs are already working with managed service providers, consultants, and contractors. It may be worth lining up a ransomware negotiator ahead of time, who can spring into action when needed. The same goes for a computer forensics team to help figure out what is happening on the network and how to remove the ransomware.

Priority No. 1 has to be a strategy, says Joseph Carson, chief security scientist at Delinea. A ransomware attack isn't a typical incident, he points out. It will make you unavailable to your customers and, in worst-case scenarios, put lives at risk. No matter how small your budget, it is essential to think about what ransomware defense should look like but to also plan out what is needed for a successful recovery.

Protecting Small Businesses From Ransomware on a Budget

Cequence's latest updates to its Unified API Protection platform help organizations reduce the time needed to create API security testing plans.

API security company Cequence Security has updated its API protection platform with generative AI and no-code security automation to help organizations with security testing and reporting, the company said.

IDC estimates that up to 50% of enterprises’ revenues are enabled over application programming interfaces (APIs), making API security a top priority for CISOs, stated Cequence Security in a blog post about the new capabilities. With generative AI, security teams working with Cequence’s Unified API Protection (UAP) platform can generate API Security Test Plans using plain English, the company said. UAP's Intelligent Mode automatically associates the appropriate APIs with the right test cases, given the functionality of that API.

Cequence gave an example in its blog: Security analysts can say, “Generate a test plan for my Payments API to ensure PCI data compliance,” and the platform will automatically inspect the Payment API endpoints and the payload characteristics to associate the appropriate test cases that would verify that the endpoints are performing as expected.

This functionality reduces the time needed to create a test plan to minutes, rather than months, according to the company.

Security analysts can also use low-code/no-code tools within Cequence to link together multiple third-party connections to implement the equivalent of an API security orchestration and response workflow, the company said. It provided an example of how analysts can create a workflow to log a JIRA ticket when sensitive data exposure is detected from a shadow API, automatically geofence access to the API to internal applications only, and then send an email to the relevant developer or business owner alerting them to the issue.

Other updates to the platform include adding new test cases for the latest OWASP API Top 10 2023 to the test catalog and the ability to run API tests outside of CI/CD pipelines and test directly against staging and production servers.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Cequence Security Adds Generative AI to API Security

By leveraging misconfigured DLLs instead of EDR-monitored APIs, this new technique injects malicious code into running processes, completely evading endpoint security.

Endpoint detection and response (EDR) systems have become increasingly efficient at detecting typical process injection attempts that invoke a combination of application programming interfaces to insert code into the memory space of a running process.

So researchers at Israeli-based Security Joes set out to find another way to due process injection without relying on EDR-monitored APIs. The result is Mockingjay, a novel method for process injection that leverages dynamic link libraries (DLLs) with default read, write, and execute (RWX) permissions to push code into the address space of a running process.

**The Mockingjay Approach**

The approach reduces the likelihood of an endpoint security mechanism detecting a malicious process injection effort and requires a smaller number of steps to achieve, Security Joes said in a report this week. "Our research aimed to discover alternative methods to dynamically execute code within the memory space of Windows processes, without relying on the monitored Windows APIs," the security firm said.

"Our unique approach, which involves leveraging a vulnerable DLL and copying code to the appropriate section, allowed us to inject code without memory allocation, permission setting, or even starting a thread in the targeted process."

Process injection is a technique for manipulating the memory of a process to either add new functionality or modify its behavior. Attackers commonly use the method to hide malicious code and evade detection on compromised systems. Common process injection methods include self-injection where a process that receives the injected payload also executes it; DLL injection where a malicious DLL is loaded into the memory space of a process; and PE injection where a portable executable file is mapped into the memory of a running process.

"Each of these injection techniques requires a set of specific Windows APIs, which generate characteristic patterns that can be leveraged by defenders and security software for detection and mitigation purposes," Security Joes said in its report. For instance, the APIs required for self-injection are VirtualAlloc, LocalAlloc, GlobalAlloc, and Virtual Protect, the company said. Similarly, the APIs used in PE injection are VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread. Most EDR systems are tuned to monitor commonly used APIs in process injection attacks and can effectively identify malicious activity associated with their use.

**Abusing Vulnerable DLLs**

The strategy Security Joes used in developing Mockingjay was to systematically search for DLLs within the Windows OS that contained a default RWX section. Researchers at the company developed a tool that explored the entire Windows file system to identify DLLs that could serve as potential vehicles for code injection without triggering an EDR alert. The exploration resulted in Security Joes finding a DLL (msys-2.0.dll) with 16KB of RWX space in Visual Studio 2022 Community that they could use for injecting and executing their own code.

"After identifying the vulnerable DLL that contains a default Read-Write-Execute (RWX) section on disk, we conducted several tests to explore two different methods that could leverage this misconfiguration to execute code in memory," Security Joes said.

One method was to directly load the vulnerable DLL into the memory space of a custom application called nightmare.exe that Security Joes developed. Doing that allowed researchers to inject and execute their own shellcode into the memory space of the application without leveraging any Windows APIs. Among other things, the shellcode also removed all EDR hooks without triggering any alerts. "This complete removal of dependency on Windows APIs not only reduces the likelihood of detection but also enhances the effectiveness of the technique," the company said.

Security Joes' second tactic for abusing the RWX section in the DLL was to do process injection in a remote process. To achieve this, they first identified binaries that used mysys-2.0.dll for their operations. Many of these were associated with GNU utilities and other applications that require POSIX emulation. For the proof-of-concept, researchers chose the ssh.exe process in Visual Studio 2022 Community as the target for injecting their code. "It is important to note that in this injection method, there is no need to explicitly create a thread within the target process, as the process automatically executes the injected code," the company explained.

According to Security Joes, the DLL that its researchers used to developed Mockingjay is just one of potentially many others that can similarly be abused for code injection purposes. Addressing the threat requires endpoint security tools that don't just monitor specific APIs and DLLs but also use behavioral analysis and machine learning techniques to identify process injection.

Mockingjay Slips By EDR Tools With Process Injection Technique

In a move to embarrass the city, hacking group known as SiegedSec accessed thousands of files with administrator logins, but it's making no ransom demands.

In a security breach first discovered on June 23, Fort Worth, a north Texas city that has more than 935,000 residents, announced that hacktivist threat actors gained unauthorized access to its data.

The group claiming responsibility for the cyberattack, SiegedSec, said it was carried out for political reasons. Specifically, what it deemed to be recent anti-transgender legislation in the state of Texas, stating, "Texas happens to be one of the largest states banning gender affirming care, and for that, we have made Texas our target."

The hacking group publicly claimed in a post that it had accessed around a half-million files containing materials such as police reports, employee/contractor emails, internal documents, work orders, employee lists, and a great deal more. SiegedSec allegedly did so by stealing administrator credentials in order to access city data, the stolen amount of which totals around 180GB.

With a list of links, the post went on to say, "We have uploaded this leak in 10 different links, each containing 20GB of government files (except the last one). If any links go down, we assure we'll have it up again very soon\[.\]"

In a press conference on the same day of the hack, city CTO Kevin Gunn confirmed the attack.

"The City of Fort Worth has confirmed that the posted information did originate from our computer systems," he said. "However, that data came from a website that our workers use to manage their maintenance activities and not from the city's public-facing intranet website. It appears the hackers downloaded file attachments to work orders within the system and those attachments include things like photographs, spreadsheets, invoices for work performed, emails between staff, PDF documents and other related materials for work orders."

Though it is unknown how the group managed to steal login information, Gunn claims that there was no indication that sensitive information was released and there was no ransom demand made, but rather that the group's intent was to make a political statement.

Trans-Rights Hacktivists Steal City of Ft. Worth's Data

The attack exposed personal information from pilot applicants, prompting both airlines to ditch their third-party provider and move services internally.

Hackers breached a database maintained by Pilot Credentials, a recruiting company based in Austin, Texas, resulting in the theft of personal information from more than 8,000 pilot applicants for American Airlines and Southwest Airlines.

The compromised data includes names, birth dates, Social Security and passport numbers, as well as driver- and pilot-license numbers of pilot and cadet job applicants.

According to the breach notifications filed by both airlines, 5,745 American Airlines applicants were affected, while the breach exposed information from 3,009 Southwest applicants. 

The airlines became aware of the breach on May 3, after it occurred on April 30. 

American Airlines reported no evidence of fraudulent activity or identity theft but is offering affected applicants two years of identity theft protection.

Both airlines said they have shifted their recruitment processes to internal websites and are cooperating with law enforcement investigations.

"We are no longer utilizing the vendor, and, moving forward, pilot applicants are being directed to an internal portal managed by Southwest," Southwest Airlines said.

Erfan Shadabi, cybersecurity expert with comforte AG, says this type of data is a goldmine for cybercriminals, who can exploit it for various malicious purposes, including identity theft, financial fraud, and targeted phishing attacks.

"The recent data breach involving American Airlines and Southwest Airlines highlights the profound damage that such incidents can inflict on organizations," Shadabi says. 

Erich Kron, security awareness advocate at KnowBe4, agrees that this kind of breach illustrates the dangers of relying on third parties to manage sensitive information.

"Unfortunately, supply chains have been increasingly targeted, causing users of their services a considerable amount of grief," he adds. "In many cases it is more economically feasible to enlist vendors to handle services such as managing resumes, job requests, and many other functions." 

The problem there, Kron explains, is that when things go wrong, it often reflects more poorly on the customer organization than on the service provider. 

**Airlines Must Improve Third-Party Security**

Nick Tausek, lead security automation architect at Swimlane, says to significantly reduce the risk of data breaches, airlines must collaborate closely with third-party vendors to prioritize the implementation of robust security measures.

This includes practices such as multifactor authentication and regular password updates, and evaluating whether their current security strategy is leaving room for delays in threat detection and incident response.

"The reality is that manual security processes are often time consuming and prone to errors, leaving organizations vulnerable to attacks," he says. "Security automation tools, especially those of the low-code variety, can accelerate security teams' capabilities to keep pace with the evolving threat landscape."

Sally Vincent, senior threat research engineer at LogRhythm, says in addition to the challenges of managing and detecting threats within an enterprise's IT infrastructure, assessing third-party risk is also a critical aspect.

"For airlines, it is essential to have strong communication and notification tools, as well as a deep understanding of how to effectively configure their complex IT environment," she says.

This allows them to gain a comprehensive view of anomalous and malicious activities across all fronts, enabling a prompt and thorough response.

"By implementing a well configured security monitoring solution that provides complete visibility, including for third-party vendors, it would have been more likely to detect indicators of compromise and mitigate the threat in a timely manner," Vincent notes. 

Kron adds when an organization is going to use a third-party service to process or gather information, especially anything of a sensitive nature, special care needs to be taken with respect to security and should be part of the contract with the vendor.

From his perspective, how the data is handled, who has access, how it's secured, and how long it's retained are some of the key concerns that should be handled within the contracts.

"The security of any third parties who are handling your sensitive information should be vetted to ensure that their security standards meet or exceed those of the organization that is hiring them," he says. 

**Airlines, Travel Industry Under Continued Attack**

Last year American Airlines was victim to a successful phishing attack against employees that compromised email accounts containing a raft of customer data. 

In the wake of these attacks and continued targeting of the travel sector by cybercriminals, the Transportation Security Administration (TSA) announced a new set of cybersecurity requirements for airport and aircraft operators.

This obligation follows previous TSA requirements for operators to report significant cyber breaches to the Cybersecurity and Infrastructure Security Agency (CISA). 

Ransomware attacks have impacted airlines worldwide, including low-cost carrier Indian SpiceJet, where an attack caused flight delays and rendered unavailable online booking systems and customer service portals.

Pilot Applicant Information for American, Southwest Hacked

Organizations are largely deluded about their own security postures, according to an analysis, with the average SIEM failing to detect a whopping 76% of attacker TTPs.

Despite enterprises' best efforts to shore up their security information and event management (SIEM) postures, most platform implementations have massive gaps in coverage, including missing more than three-quarters of the common techniques that threat actors use to use to deploy ransomware, steal sensitive data, and execute other cyberattacks.

Researchers from CardinalOps analyzed data from production SIEM platforms from companies such as Splunk, Microsoft Sentinel, IBM QRadar, and Sumo Logic, and found that they have detections for just 24% of all MITRE ATT&CK techniques. That means that adversaries can execute about 150 different techniques that can bypass SIEM detection, while only about 50 techniques are spotted, the researchers said.

This is despite the fact that current SIEM systems actually do take in sufficient data to cover potentially 94% of all these techniques, CardinalOps revealed as part of the company's "Third Annual Report on the State of SIEM Detection Risk," released today.

Moreover, organizations are largely deluded about their own security postures and "are often unaware of the gap between the theoretical security they assume they have and the actual security they have in practice," the researchers wrote in the report. This creates "a false impression of their detection posture."

MITRE ATT&CK is a global knowledge base of adversary tactics and techniques based on real-world observations that's aimed at helping organizations detect and mitigate cyberattacks. The report's data is the result of analysis of more than 4,000 detection rules, nearly 1 million log sources and hundreds of unique log source types used in SIEM across a range of diverse industry verticals — including banking and financial services, insurance, manufacturing, energy, and media and telecommunications.

**A Lack of SIEM Fine-Tuning to Blame for Detection Fails**

The key issue contributing to the current state of SIEM efficacy (or lack thereof) seems to be that even though resources exist for organizations to use knowledge, automation, and other processes to detect adversaries and potential attacks on their environments, they still largely rely on manual and other "error-prone" processes for developing new detections, the researchers noted. This makes it difficult to reduce their backlogs and act quickly to fill gaps in detection.

Indeed, SIEMs themselves "are not magic" and rely on the organizations deploying them to do so correctly and efficiently, notes Mike Parkin, senior technical engineer at Vulcan Cyber, a security-as-a-service provider of enterprise cyber-risk remediation.

"Like most tools, they require fine-tuning to deliver the best results for the environment they’re deployed in," he says. "These report results imply that many organizations have gotten the basics working but haven’t done the fine-tuning necessary to take their detection, response, and risk management strategies to the next level."

In addition to the need to scale detection-engineering processes to develop more detections faster, one key issue that seems to be tripping up detection in enterprise SIEM deployments is that on average, they have 12% of rules that are broken, which means they will never file an alert when something is amiss, according to the report.

"This commonly occurs due to ongoing changes in the IT infrastructure, vendor log format changes, and logical or accidental errors in writing a rule," the researchers noted in the report. "Adversaries can exploit gaps created by broken detections to successfully breach organizations."

**Why MITRE ATT&CK Matters**

MITRE ATT&CK, created in 2013, has now "become the standard framework for understanding adversary playbooks and behavior," the researchers noted. And as threat intelligence has advanced, so has the wealth of knowledge the framework provides, currently describing more than 500 techniques and sub-techniques used by threat groups such as APT28, the Lazarus Group, FIN7, and Lapsus$.

"The biggest innovation introduced by MITRE ATT&CK is that it extends the traditional intrusion kill chain model to go beyond static indicators of compromise (like IP addresses, which attackers can change constantly) to catalog all known adversary playbooks and behaviors (TTPs)," the CardinalOps researchers wrote.

Organizations clearly see the value in using MITRE ATT&CK to help them in their security efforts, with 89% currently using the knowledge base to reduce risk for security-operations use cases — such as determining priorities for detection engineering, applying threat intelligence to alert triage, and gaining a better understanding of adversary TTPs, the researchers noted, citing Enterprise Strategy Group (ESG) research.

However, using the framework to support SIEM efforts and using it well appear to be two very different scenarios, the report found.

**Closing the SIEM Gap**

There are steps that organizations can take to help close the gap between what a SIEM is capable of in terms of cyberattack detection, and how they currently are using it, researchers and security experts said.

One key strategy would be to scale SIEM detection-engineering processes to develop more detections faster using automation, something that companies already use widely to great effect in "multiple areas of the SOC, such as anomaly detection and incident response," but not so much in detection, they noted in the report.

"The detection-engineering function remains stubbornly manual and typically dependent on 'ninjas' with specialized expertise," the researchers wrote.

Indeed, having a focus on automation is critical to achieving goals with limited human and financial resources, agrees one security expert.

"This includes expanding automated detection to include Internet of things (IoT) and operational technology (OT) attack vectors, as well as having plans already in place for automated threat remediation," says John Gallagher, vice president of Viakoo Labs at Viakoo.

One key challenge that organizations continue to face is that the current attack surface — which now includes large numbers of vulnerable network-connected devices as well as the typical enterprise network — has grown well past what the IT organization is currently capable of supporting or managing, Gallagher says.

"To defend and maintain the integrity of those assets requires IT working closely with other parts of the organization to ensure those assets are visible, operational, and secure," he says.

Indeed, Parkin observes, until organizations can get a clear picture of their threat surfaces, manage their risk, and prioritize events to focus on what matters most, there will be problems.

"We have the tools to make it happen," he says. "But it can be a challenge to get them deployed and configured for best effect."

Source

DARKReading