New time series model and enhanced alerting experience make it easy for organizations to address more threats in the cloud while enabling faster investigations.

**SAN JOSE, Calif., Aug. 9, 2022** \-- Lacework, the data-driven cloud security company, today announced new capabilities that enable organizations to uncover more critical threats to their infrastructure and empower teams to collaborate more efficiently in alert investigation and response. Lacework has added fully automated time series modeling to the existing anomaly detection capabilities of the Polygraph Data Platform. Using automated learning and behavioral analytics, the time series model builds a baseline of the volume and frequency of activity within a customer's environment and actively monitors for spikes that deviate from that unique baseline to detect potential threats such as cryptominer attacks and compromised accounts with accuracy. Organizations can also proactively discover increased cloud usage due to misconfigurations — gaining a better understanding of their environment to help control costs. Lacework does this without the need for constant tuning of thresholds, significantly reducing both manual work and false-positive alerts. Lacework has also upgraded its alerting experience with features that empower teams to collaborate more efficiently in alert investigation and response.

The enormous amount of activity in the cloud and adoption of new technology makes it difficult to gain visibility into risks, investigate alerts efficiently, and take action, especially when teams are siloed into different workstreams and tools. Signature and rules-based approaches can't keep pace with this dynamic environment and often overwhelm security teams with thousands of contextless alerts across a range of environments.

Polygraph, the Lacework cloud behavioral analytics engine, uses dozens of models to build a baseline of normal behaviors in the cloud. The time series model introduces a new dimension of analysis by tracking changes in activity frequency and volume over time in a cloud environment. It works with the existing models to uncover more anomalies with fewer alerts.

Lacework also automatically adjusts the severity of alerts based on continuous learning and a fine-grained understanding of how much the observed behaviors deviate from the predicted baseline for improved accuracy. According to Cybersecurity Ventures, the number of unfilled cybersecurity jobs worldwide grew by 350% between 2013 and 2021, with no sign of relief in the next five years. By consolidating alerts into only those that matter and providing security teams with more context about what is happening across their environment, Lacework allows these overburdened teams to uncover more risks and deal with them more efficiently.

"It's critical organizations get transparency as to what is happening across their multicloud environments, but security teams face a massive challenge keeping up with the dynamic nature of cloud environments while threats like cryptomining continue to proliferate," said Frank Dickson, IDC Group Vice President, Security and Trust. "As an industry plagued by a seemingly insurmountable skills shortage, simply layering more alerts on the SOC does not help. Context matters; context quickly forwards SOC investigations from awareness to understanding by enabling correlations across datasets. Alerts are thus replaced with context-rich incidents that are quickly actionable and facilitate outcomes for customers. In the end, secure outcomes are the goal of every SOC."

Lacework has also revamped the alerting experience to help organizations better collaborate with teams to prioritize, investigate, and track the status of all alerts. This includes:

· **Context-rich insights:** Richer insights give the complete picture of what happened, associated events, timelines, and other details, helping organizations understand where to focus and make better decisions.

· **Configurable bi-directional sync:** When teams update an alert on the Lacework user interface or the associated ticket in backend workflow tools like Jira, the alert status is automatically updated on both sides with bi-directional sync for accelerated resolution. Organizations can even give feedback on Lacework alert severity levels, which in turn helps the Polygraph Data Platform learn and optimize modeling to further improve alerting experience.

· **Easy to manage alert life cycle:** Teams can more easily organize alerts, view tags, filter to see a set of specific alerts, change the state of an alert to indicate whether it needs to be investigated or has been resolved, and add comments to classify and better collaborate with teams.

"Lacework relentlessly innovates to deliver features that help customers gain the visibility and controls they need to stay ahead of the evolving threat landscape," said Arash Nikkar, VP of Engineering, Lacework. "The Polygraph Data Platform is the only cloud security solution to combine automated time series analysis with sophisticated cloud behavioral analytics to build baselines that are tailored to a company's unique environment. Combined with our enhanced alerting capabilities, we're making it easier for teams to identify relevant risks and prioritize threats, even as their organization scales, the attack surface grows bigger, and security incidents increase exponentially."

Time series modeling is available now for Lacework customers in AWS environments. Configurable bi-directional sync enhancements to the Lacework alerting experience are available to select customers in beta.

Additional Resources:

· Visit our team at Black Hat USA at booth #2440 on the show floor.

· Check out the Lacework blog to learn more about the new time series model and enhanced alerting experience.

· Become an expert on security fundamentals and learn more from your security and developer peers through Lacework Academy and the Lacework Community.

· Read what Lacework customers have to say about the Lacework Polygraph Data Platform.

**About Lacework**

Lacework is the data-driven security company for the cloud. The Lacework Polygraph® Data Platform automates cloud security at scale so our customers can innovate with speed and safety. Only Lacework can collect, analyze, and accurately correlate data across an organization's AWS, Microsoft Azure, Google Cloud, and Kubernetes environments, and narrow it down to the handful of security events that matter. Customers all over the globe depend on Lacework to drive revenue, bring products to market faster and safer, and consolidate point security solutions into a single platform. Founded in 2015 and headquartered in San Jose, Calif., Lacework is backed by leading investors like Sutter Hill Ventures, Altimeter Capital, D1 Capital Partners, Tiger Global Management, Counterpoint Global (Morgan Stanley), Franklin Templeton, Durable Capital, GV, General Catalyst, XN, Coatue, Dragoneer, Liberty Global Ventures, and Snowflake Ventures, among others. Get started at www.lacework.com.

Lacework Updates Threat Detection To Uncover More Malicious Activity and Speed Investigation at Scale

Given the lack of reporting requirements, the findings are more like assumptions. Here's what organizations can do to minimize exposure.

The most significant finding in the Cyber Safety Review Board's voluminous analysis of the Log4j vulnerability is what it didn't observe.

The board is "not aware of any significant Log4j-based attacks on critical infrastructure systems." Also, "exploitation of Log4j occurred at lower levels than many experts predicted, given the severity of the vulnerability." That's remarkable since Log4j is one of the most severe vulnerabilities of the past decade.

Given how widely the library is used, it's difficult to accept that a vast vulnerability like this — identified as "endemic" — _didn't_ cause any real damage to critical infrastructures. The report saying there weren't any significant incidents is no reason to drop our guard, however. In fact, we need to be more vigilant than ever.

The report acknowledges that unlike, say, government agencies reviewing transportation disasters, there was "no crash site or damaged vehicle to inspect, no stress tests to perform on failed equipment, and no wiring diagrams to review." And since critical infrastructure owners and operators were not yet required to report breaches to the federal government, there's a significant blind spot. The findings in the report are just assumptions, and organizations should not feel comforted by them.

Log4j remains deeply embedded in systems everywhere — it's one of the few pieces of software that popular applications such as Apache Struts, ElasticSearch, Redis, Kafka, and others have in common. We're also told that during the board's review, community stakeholders identified "new compromises, new threat actors, and new learnings."

Some of this represents the democratization of software programming. This is a good thing — but we need to be aware that as long as we have software, we'll have software vulnerabilities.

**Knowing Every Link in the Chain**

Guarding against weak links in the software supply chain requires adequate knowledge of every link in the chain — an elusive goal. Most organizations have terrible asset management practices — and it's impossible to secure technologies in the infrastructure when no one is sure what those technologies are, where they're stored, and how they're used.

There are always new tools and capabilities coming down the pike, and with cloud applications, it's even worse. For homegrown applications in the cloud, developers typically don't see it as their responsibility to track which software components are in the mix. Their focus is on output, not sourcing. And with software-as-a-service (SaaS) applications, there's a near-total dependence on the third-party vendor doing the right thing.

Even without consequences we can point to, Log4j offers further proof that software supply chain security is fundamentally broken.

**What to Do Next**

So what can we do to fix it? The CSRB report serves up recommendations rich with anecdotes. They're well-meaning but too opaque for companies to implement in real-world settings. For example, we're told that "organizations should be prepared to address Log4j vulnerabilities for years to come." But how?

There are steps organizations can take. Again, there are no guarantees — foolproof protection is impossible. But the dangers can be contained and minimized.

First, organizations need greater awareness of all technologies in use; asset management is useless without up-to-date asset inventory. This is an ongoing priority, and it requires developer buy-in. Almost every business uses open source software, so asset inventory must extend down to the dependency level. This isn't sexy, but it may be one of the most essential activities to carry out effectively.

Developers and their software are one thing, yet in every enterprise business users now deploy the apps they believe are best for getting the job done. Employers are understandably concerned about security and compliance, but heavy-handed enforcement (i.e., attempting to block access) represents a losing proposition for everyone. Employee application choice and enterprise security are not mutually exclusive — and with technologies now available, they go hand-in-hand.

In the past we'd call this unsanctioned use of applications shadow IT, but now there's a better term: unmanageable applications. They're very common and easy to spot because they don't support identity and security standards. IT-authorized applications are hard enough to police; unmanageable applications are an even bigger challenge.

Second, we need to move toward zero-trust architecture. This concept is getting a lot of buzz, but there are challenges in deploying zero trust for unmanageable applications. Implementing zero trust requires multiple layers of controls. Trying to apply zero-trust principles to unmanageable applications that don't support industry standards like SAML (for authentication) and SCIM (for adding and removing users) is extremely difficult. Unmanageable applications cannot be added to a zero-trust protected surface since they don't support identity standards. A fundamental zero-trust principle defines who can access a data, application, asset, or service (DAAS) element. Organizations must ensure they include all business apps, including the unmanageable ones, in their zero-trust strategy, not only those that support standards.

We haven't dodged a bullet with Log4j, and there are more zero-days on the way. The CSRB report should serve as a wake-up call for organizations worldwide to dig deeper into their software supply chain for _all_ applications. Physical supply chains have long had this attention; software deserves the same scrutiny.

Don't Take the Cyber Safety Review Board's Log4j Report at Face Value

Machine-learning algorithms alone may miss signs of a successful attack on your organization.

Zero-day attacks that exploit unpatched software vulnerabilities saw exponential growth last year. According to cybersecurity researchers like the Zero-Day Tracking Project, 2021 saw more than 80 zero-day exploits recorded, versus 36 in 2000. There are already 22 such exploits on record for the first half of 2022.

As soon as a vulnerability becomes known, cybercriminals rush to exploit it before the software developer can write, test, and release a patch. That window may be hours, but more likely days or weeks long. So, it's important that you have threat hunters — humans, not machine-learning algorithms — scouring your infrastructure proactively for signs of a successful attack.

The risk of falling victim to a zero-day attack is considerable, and the consequences real. One study from the Ponemon Institute found that 80% of successful data breaches originated with zero-day exploits. The vulnerabilities exploited are found in software common to the enterprise, including Microsoft Windows and Office, Google Chrome, Adobe Reader, Apple iOS, and Linux.

With 2021's Apache Log4j Java-based vulnerability, we can add hundreds of millions of devices and a wide range of websites, consumer and enterprise services, and applications to the list.

Step one in protecting every organization is to practice excellent IT hygiene — keep up to date on patching and updating all software. It's the back-to-basics measure that so many companies love to overlook or postpone. Granted, it can be time and resource consuming to test and deploy software patches, and the process can disrupt business operations. But it's a critical safeguard and far less costly than a data breach.

**The Invisibility of Newness**

A strong perimeter and signature-based edge controls like anti-virus software and intrusion prevention do not provide complete protection. That's because they can only detect known threats. They are blind to the footprints of zero-day attacks, when the cybercriminals are the first to uncover and exploit a software vulnerability. That's why zero-day exploit kits carry very high price tags on the black market, running from tens of thousands of dollars up to millions. They work that well.

Once a cybercriminal has used a zero-day exploit to penetrate a network unseen, they can take their time and deploy their weapon of choice, from viruses and worms to malware and ransomware to remote code execution. They can move laterally in the network, steal identities, and steal data. As long as you don't know they're there, it's like handing over the keys to the crown jewels.

**The Role of Threat Hunting**

It's that invisibility that makes proactive threat hunting an essential component of the layered approach to security. It's made possible in part because we have been smart about using machine learning to free up scarce cybersecurity people resources by reducing the number of alerts needing human intervention by 90%. Some in the industry have taken this success to mean that humans can be phased out of the security equation by algorithms, and that algorithms can do the work for us, including threat hunting.

Machine learning does bring significant advantages to cybersecurity management, but it will never completely replace humans in the security operations center. Machines handle high-volume tasks like eliminating false positives and repetitions extremely well. Machine learning may assist when you are hunting for known threats, including advanced and "low-and-slow" threats, where you know what indicators of compromise (IoCs) to look for.

However, human intelligence, intuition, strategic thinking, and creative problem solving are essential in proactive zero-day threat hunting where the IoCs are unknown and the hunter is looking for the subtle indications that another human is maliciously active in your environment.

This approach is research intensive. The analyst may create a hypothesis and then validate it based on observed patterns or anomalous activity in security data logs and user and entity behavioral analysis (UEBA) logs. According to CISA, these can include failed file modifications, increased CPU activity, inability to access files, unusual network communications, compromised administrator privileges, credentials theft, increases in database read volumes, and irregular geographical access.

Companies can develop threat hunting skills in-house or acquire them as a managed service. Either way, these human defenders and their proactive threat hunting expertise are the new elites in the security industry. Supported by comprehensive log data, threat intelligence, and tools like the MITRE ATT&CK knowledge base, human threat hunters are essential to combatting zero-day attacks, multistage attacks, and devious, low-and-slow hackers.

Human Threat Hunters Are Essential to Thwarting Zero-Day Attacks

The discovery adds to the growing list of recent incidents where threat actors have used public code repositories to distribute malware in software supply chain attacks.

Administrators of the Python Package Index (PyPI) have removed 10 malicious software code packages from the registry after a security vendor informed them about the issue.

The incident is the latest in a rapidly growing list of recent instances where threat actors have placed rogue software on widely used software repositories such as PyPI, Node Package Manager (npm), and Maven Central, with the goal of compromising multiple organizations. Security analysts have described the trend as significantly heightening the need for development teams to exercise due diligence when downloading third-party and open source code from public registries.

Researchers at Check Point's Spectralops.io uncovered this latest set of malicious packages on PyPI, and found them to be droppers for information-stealing malware. The packages were designed to look like legitimate code — and in some cases mimicked other popular packages on PyPI.

**Malicious Code in Installation Scripts**

Check Point researchers discovered that the threat actors who had placed the malware on the registry had embedded malicious code into the package installation script. So, when a developer used the "pip" install command to install any of the rogue packages, the malicious code would run unnoticed on the user's machine and install the malware dropper.

For example, one of the fake packages, called "Ascii2text," contained malicious code in a file (­\_init\_.py) imported by the installation script (setup.py). When a developer attempted to install the package, the code would download and execute a script that searched for local passwords, which it then uploaded to a Discord server. The malicious package was designed to look exactly like a popular art package of the same name and description, according to Check Point.

Three of the 10 rogue packages (Pyg-utils, Pymocks, and PyProto2) appear to have been developed by the same threat actor that recently deployed malware for stealing AWS credentials on PyPI. During the setup.py installation process, Py-Utils for instance connected to the same malicious domain as the one used in the AWS credential-stealing campaign. Though Pymocks and PyProto2 connected to a different malicious domain during the installation process, their code was near identical to Pyg-utils, leading Check Point to believe the same author had created all three packages.

The other packages include a likely malware-downloader called Test-async that purported to be a package for testing code; one called WINRPCexploit for stealing user credentials during the setup.py installation process; and two packages (Free-net-vpn and Free-net-vpn2) for stealing environment variables. 

"It is essential that developers are keeping their actions safe, double-checking every software ingredient in use and especially such that are being downloaded from different repositories," Check Point warns.

The security vendor did not immediately respond when asked how long the malicious packages might have been available on the PyPI registry or how many people might have downloaded them.

**Growing Supply Chain Exposure**

The incident is the latest to highlight the growing dangers of downloading third-party code from public repositories without proper vetting.

Just last week, Sonatype reported discovering three packages containing ransomware that a school-age hacker in Italy had uploaded to PyPI as part of an experiment. More than 250 users downloaded one of the packages, 11 of whom ended up having files on their computer encrypted. In that instance, the victims were able to get the decryption key without having to pay a ransom because the hacker had apparently uploaded the malware without malicious intent. 

However, there have been numerous other instances where attackers have used public code repositories as launching pads for malware distribution.

Earlier this year, Sonatype also discovered a malicious package for downloading the Cobalt Strike attack kit on PyPI. About 300 developers downloaded the malware before it was removed. In July, researchers from Kaspersky discovered four highly obfuscated information stealers lurking on the widely used npm repository for Java programmers.

Attackers have begun increasingly targeting these registries because of their wide reach. PyPI, for instance, has over 613,000 users and code from the site is currently embedded in more than 391,000 projects worldwide. Organizations of all sizes and types — including Fortune 500 firms, software publishers and government agencies — use code from public repositories to build their own software.

10 Malicious Code Packages Slither into PyPI Registry

A rising tide of threats — from API exploits to deepfakes to extortionary ransomware attacks — is threatening to overwhelm IT security teams.

The use of deepfakes to evade security controls and compromise organizations is on the rise among cybercriminals, with researchers seeing a 13% increase in the use of deepfakes compared with last year.  

That's according to VMware's eighth annual "Global Incident Response Threat Report," which says that email is usually the top delivery method.

The study, which surveyed 125 cybersecurity and incident response (IR) professionals from around the world, also reveals an uptick in overall cybersecurity attacks since Russia's invasion of Ukraine; extortionary ransomware attacks including double extortion techniques, data auctions, and blackmail; and attacks on APIs.

"Attackers view IT as the golden ticket into an organization's network, but unfortunately, it is just the start of their campaign," explains Rick McElroy, principal cybersecurity strategist at VMware. "The SolarWinds attack gave threat actors looking to target vendors a step-by-step manual of how to successfully pull off an attack."

He says that keeping this in mind, IT and security teams need to work hand in hand to ensure all access points are secure to prevent an attack like that from harming their own organization.

McElroy explains what he found eye-opening was the increase in lateral movement witnessed by most respondents — i.e., the process by which attackers pivot from a compromised device to burrowing deeper into the corporate network.

He calls lateral movement "the new battleground," appearing in a quarter of all attacks, with attackers leveraging everything from script hosts and file storage (e.g., in the cloud) to PowerShell, business communications platforms, .NET, and numerous other dual-purpose tools to rummage around inside networks.

To account for the threat, organizations must consider solutions that provide visibility into all areas of the network, including the cloud, to ensure they can prevent, detect, and respond to attacks leveraging lateral movement.

"While lateral movement has always been a threat, we have seen an increasing percentage of east-west traffic not moving through the network," McElroy says. "In this situation, most security teams struggle unless their system and organization controls are equipped to see the lateral movement between workloads and containers on the hypervisor."

**Attackers Targeting APIs with Greater Frequency**

The report separately shows that API attacks are being seen by nearly a quarter (23%) of the respondents.

The most common types of API attacks include data exposure (experienced by 42% of respondents), SQL attacks (37%), API injection attacks (34%), and distributed denial-of-service (DDoS) attacks, experienced by a third of respondents.

McElroy says that while it can be difficult to determine a definitive number, if one looks broadly at threat reports from the last three years, API attacks are "definitely increasing."

"Given that APIs underpin technology stacks and ensure things like integrations, automations and orchestrations, the attackers understand the weaknesses in APIs and have been targeting them more frequently as a result," he says.

**Risk of Burnout Still High, but Falling**

Nearly half (47%) of survey respondents have experienced "burnout or extreme stress" in the past 12 months; however, this is down slightly from the 51% reported last year.

However, a higher percentage of those who have experienced burnout say they're more likely to consider leaving their job than those in the same group from the 2021 report.

Although battling something as big as employee burnout may seem daunting, there are practical steps security teams can take to streamline and ease user stress when it comes to security.

The report, for instance, indicates measures such as flexible hours, investment in further education, and days off for well-being were having a positive effect preventing burnout.

McElroy explains that along with smart steps to address employee wellness, dealing with the tsunami of threats is getting a little easier.

"Defenders have also already begun implementing new strategies and methods to stem the tide of incursions," he says.

The report says that 75% of organizations have employed virtual patching as an emergency mechanism, nearly 90% of respondents now say they are able to disrupt an adversary’s activities, and 74% report that IR engagements are resolved in a day or less.

"These are all signs that reflect the growing maturity of security teams," McElroy says.

Deepfakes Grow in Sophistication, Cyberattacks Rise Following Ukraine War

HYAS Confront provides total visibility into your production environment, giving you insight into potential issues like cyber threats before they become problems.

VICTORIA, British Columbia--Leading security technology firm HYAS Infosec — whose proactive solutions ensure that businesses can keep moving full forward in our ever-changing world — today announced the general release of its newest product, HYAS Confront, a cybersecurity solution offering complete visibility into every corner of a production environment. HYAS will be demoing Confront at Black Hat USA in Las Vegas from August 8 to August 11.

> “HYAS Confront’s distinctive ability to detect anomalies within your production environment ensures that even in these cases, you can uncover the problem before it does damage, letting businesses operate confidently and without fear of costly interruptions.”

Production environments are increasingly becoming a target for bad actors, as they want their attacks to cause as much disruption as possible. Afterall, if a company’s production environment is rendered inoperable, its ability to generate income is shut down. HYAS Confront addresses this growing issue by giving DevSecOps teams complete visibility into their production environment. HYAS Confront finally gives them a definitive picture of which devices on their network are communicating with one another, which devices are sending traffic outside the network, and how often and to whom they are sending it. HYAS Confront also automatically identifies communication to known command and control servers as well as other risks and threats.

“We have gotten an excellent response from our first customers, who began using the service during development and testing,” said HYAS CEO David Ratner. “We are extremely proud of the solution we have brought to market and the vital role it fulfills in providing complete network visibility.”

Most cybersecurity solutions on the market today focus on protecting the perimeter of your network, but unfortunately, regardless of the strength of your outward-facing security posture, you will be breached at some point. The numbers bear this out, with 97 percent of companies reporting having experienced a successful cybersecurity breach at some point.

However, even if bad actors sneak past your perimeter security, they can’t hide from the foundational network monitoring provided by HYAS Confront. Once deployed, a process that usually takes less than 30 minutes, it establishes a baseline of normal, healthy network traffic. With this data, HYAS Confront can recognize aberrations from normal traffic patterns that could indicate a problem. When such an anomaly is discovered, Confront alerts administrators so they can take appropriate action.

But the benefits of full production environment visibility doesn’t end with security. HYAS Confront can also reveal issues like misconfigurations, violations of policies or controls, and incomplete removal of malware after an attack. One of the most difficult aspects of incident response is ensuring that the environment is actually clean again, and HYAS Confront’s visibility can play a vital role in that process. It can also be a useful tool for understanding service assurance. This innovative solution integrates seamlessly with other network management and security infrastructure, working alongside them to enhance the value of these pre-existing investments. This improves overall network health, preventing problems down the road and giving businesses the confidence to move forward at full speed.

“Production environments are so critical to a company’s ability to function, and unfortunately, no matter how strong your perimeter is, bad actors _will_ eventually find a way in,” said Ratner. “HYAS Confront’s distinctive ability to detect anomalies within your production environment ensures that even in these cases, you can uncover the problem before it does damage, letting businesses operate confidently and without fear of costly interruptions.”

To request a demo visit

For any questions or to request more info, please email \[email protected\] or call us at 1-888-962-4794.

**About HYAS  
**HYAS is a valued partner and world-leading authority on cyber adversary infrastructure and communication to that infrastructure. We help businesses see more, do more, and understand more about the nature of the threats they face — or don’t even realize they are facing — in real time. HYAS’s foundational cybersecurity solutions and personalized service provide the confidence and enhanced risk mitigation that today’s businesses need to move forward in an ever-changing data environment. For more information: HYAS.com.

HYAS Infosec Announces General Availability of Cybersecurity Solution for Production Environments

Q&A with Jonathan Leitschuh, inaugural HUMAN Dan Kaminsky Fellow, in advance of his upcoming Black Hat USA presentation.

With enterprise software more dependent on open source components than ever before, a big element of modern application security is reliant on how well the open source community can shore up vulnerable code. The Black Hat USA presentation "Scaling the Security Researcher to Eliminate OSS Vulnerabilities Once and For All" will tackle some important tools and strategies that can amp up the progress on this front. 

Jonathan Leitschuh, the inaugural Dan Kaminsky Fellow at HUMAN Security, plans to examine how the security research community can use automated bulk pull request generation to collaborate with open source maintainers in a way that can make it easier to address drastically larger numbers of high-risk flaws.

Leitschuh used his fellowship year to work on refining the tools and methods for scaling open source security vulnerability remediation. Dark Reading caught up with Leitschuh to discuss his upcoming talk and dive deeper into his work. (The interview has been lightly edited for conciseness and clarity.)

**Dark Reading: What do you think the No. 1 takeaway will be for the audience at your Black Hat talk?  
****Leitschuh:** My presentation will examine open source vulnerabilities and how several are more widespread than you’d think. For example, there is one project owned by Perforce, called _zeroturnaround/zt-zip_, that received all three of the security pull request fixes I attempted to fix across open source.

Importantly, the highest impact finding I intend to share is how it is possible to fix widespread and common security vulnerabilities at scale. We have the technology. All we need to do is leverage it.

My goal is to demonstrate that fixing these vulnerabilities is not an interactive problem. We can solve it with math, science, technology, and security. You have to be accessible, flexible, and open-minded if you want your proposed fixes to be accepted.

It’s not that people are asleep at the wheel when it comes to vulnerabilities. They often just aren’t aware of certain problems, and to compound things the Web is insecure by default.

****Dark Reading:** When we first talked at the beginning of the year, you were just getting your feet wet in the fellowship and planning out your year. Can you offer me an update on the progress that you made in utilizing CodeQL, OpenRewrite, and other tools to scale up open source vulnerability mitigation?  
****Leitschuh:** I ended up having to reimplement features, including Data Flow and Control Flow analysis, that were missing or partially implemented in OpenRewrite in order to support the vulnerabilities I intended to fix. The Control Flow feature was particularly tricky but was possible thanks to an excellent collaboration with my intern, Shyam Mehta. He had taken a few classes in college that I had not, in particular, one about compilers that was particularly helpful in our work.  

We generated over 400 pull requests to fix new instances of old vulnerabilities from my previous research and generated over 170 pull requests to fix new vulnerabilities that wouldn’t have been possible without OpenRewrite.

****Dark Reading: Did you run into** any surprises?  
****Leitschuh:** The feedback from maintainers has been, in general, positive, but it’s always interesting to see how careful you need to be around OSS maintainers. It is very important to make sure the automated fix you are making looks like the surrounding code. One of the biggest pushbacks from maintainers I’ve received is about not including unit tests with the pull requests. Unfortunately, their codebase is most often far too complex to automatically generate a unit test in addition to the fix.

****Dark Reading:** What was the most impactful finding/technique/application of tools you discovered over the course of the year?  
****Leitschuh:** To begin with, I had to start from scratch and conduct a data analysis. Using CodeQL was key as I needed to translate my knowledge not only across different programming languages, but also from query language to a procedural one.

Shyam was instrumental in making sure I was correctly building this new feature, which we needed for the final security vulnerability: Zip Slip, which is unzipping a zip file in such a way that one can arbitrarily overwrite file contents, potentially allowing for remote code execution.

As a note, Snyk had already done some work on this, but some of the mitigations their researcher worked with maintainers to craft were found to not have been 100% correct.

****Dark Reading:** Do you have a good example of your techniques in action?  
****Leitschuh:** As I became aware of more existing research, I knew there were more cases of security vulnerabilities waiting to be found.

From a CodeQL query, the GitHub Security Lab team provided me with a list of 900 repositories potentially vulnerable to Zip Slip. Of the 900, we have made 86 Zip Slip fix pull requests to date, which means 86 critical security vulnerabilities that now have possible fixes.

****Dark Reading:** Are there any loose ends that you hope the community can chip in and work on?  
****Leitschuh:** There is still a significant gap where we need the community’s help, especially surrounding the gap between the 900 repositories and 86 fixes.

The list of projects included archived and other unmaintained projects, which means the vulnerabilities may not be fixed any time soon, but at least they are now visible, along with potential fixes.

There’s a wealth of open source vulnerabilities that are just waiting to be fixed with more advanced techniques.

****Dark Reading:** In all practicality, what do you think it will take for practitioners to put your learnings into action?  
****Leitschuh:** Ideally the first step would be to learn CodeQL so that they can express searches for vulnerabilities. Then learning to use something like OpenRewrite in order to generate fixes. Then the best practices around bulk PR submission.

It would also be beneficial for practitioners to have at least a basic understanding of the language in use in a particular project, as this allows them to better understand the vulnerabilities and risks involved.

Curiosity is also an essential component so they can explore and dig into the vulnerability. For example, a practitioner could run a cursory search with GitHub Code Search, compile examples, and then write several unit tests to assess how you can address the vulnerability head on.

****Dark Reading:** How have your views changed over the course of the year on how you think we should work toward solving the biggest problems of software supply chain security today?**  
**Leitschuh:** The software security supply chain is a little different as my work is about the actual vulnerabilities in the project. However, there’s a lot of value in deep dives for security vulnerabilities, but it’s become very clear to me that there’s a lot of security vulnerabilities on the surface.

We know these vulnerabilities are out there. You put the scanners in the hands of a maintainer, they see a lot of noise. They have to filter out what’s good and what’s bad. With a pull request, even if you don’t fix it, it still, hopefully, hardens your software.

I knew this before I came in, but it became very clear to me how picky maintainers can be. There’s reaffirmation that you have to get the code and formatting right; you can’t skimp on messaging and overall reacting accordingly when you’re seeing reactions from maintainers.

People get their ego wrapped up in their software, which I admittedly can be guilty of. You’re challenging them in a certain way – even acting as a threat. As an example, you didn’t just write this wrong, you’ve written it in a way that is a true security vulnerability. It’s bigger than a bug. It’s important to have a healthy respect for the human aspect of open source software.

****Dark Reading:** Why do you think it is important for security practitioners and researchers to bring more respect to the table for maintainers of OSS projects? How can cybersecurity improve as a result?  
****Leitschuh:** I certainly understand the plight of an open source maintainer. It’s tough and demanding, and most are volunteering their time. They are an important line of defense against malicious actors and have to handle broad swathes of open source projects.

You need to be cognizant that the maintainers and owners of the projects are doing this in their spare time, so it is important to actively collaborate with them, as opposed to expecting them to always accept your suggested changes from the start.

We do our best work in cybersecurity when we work collaboratively. Maintainers are part of the process and should be identified and respected as such.

****Dark Reading:** What's next for you and your research as you come out of the fellowship?  
****Leitschuh:** I’m not entirely sure yet. I’d love to see this research taken to the next level. There are certain vulnerabilities like SQL injection that can be deterministically discovered with data flow and taint tracking (because CodeQL already does it).

The complicated bit is turning a detection into a fix. Software developers write code in a lot of different ways, trying to write fixes for all the different ways developers can write code is a difficult task.  

_Leitschuh is co-presenting with Patrick Way of Moderne (one of the open source maintainers for OpenRewrite) and Shyam Mehta, a software engineer studying at the University of Pennsylvania. Way taught Leitschuh "OpenRewrite from the ground up," and Mehta "has been instrumental over the course of the fellowship," Leitschuh says.  
_

_"Whenever I need to solve a problem and can move a little slower, or I need to think something through more as I’m building it, I pair-program with \[Mehta\], where he’s writing the code and I’m providing instructions. He has also helped by conducting a control flow analysis, created the UI for two large Control Flow example graphics used in the talk, and with debugging," Leitschuh says._

We Have the Tech to Scale Up Open Source Vulnerability Fixes — Now It's Time to Leverage It

A new workout leads to five smart lessons about the importance of converging security and fraud into a unified risk function.

Recently, I found inspiration in a set of adjustable dumbbells. I purchased these dumbbells in an effort to get into better shape. When they arrived, I found the four weight-adjusting mechanisms to be very intuitive and easy to use. I was soon on my way to a bit of strength training.

There was only one complication. A few days into using the dumbbells, I found that one of the four mechanisms wasn't quite working properly. In an effort to troubleshoot the issue, I tried a few different things — a trial and error of sorts. It took a few iterations — trying different combinations of placing the adjustable dumbbells in their holders in different orientations, along with swapping the dumbbells.

At last, having visibility into both the dumbbells and their holders, I isolated the issue. A small metal tab on the holder that presses on a piece on the dumbbell that releases the lock was slightly bent. Thus, it was not releasing the lock properly, which prevented me from adjusting the weight on the dumbbell. Once isolated, it was a quick and easy fix — I bent the small tab ever so slightly so that it released the lock properly.

You might be asking yourself what this story has to do with security and fraud. Allow me to share with you the lesson I learned from this: the importance of the convergence of security and fraud.

Just as I could not have troubleshot the dumbbell issue without having visibility into both the dumbbells and their holders, enterprises cannot properly manage risk without having a converged view into both security and fraud. In other words, enterprises must have a unified view of risk, across security and fraud.

**5 Ways Combining Security and Fraud Reduces Risk**

To help illustrate the importance of a converged risk program, let's take a look at five ways in which security and fraud work together to reduce risk across the enterprise:

**1\. Shattering silos:** Effectively managing risk across an enterprise requires teamwork across a variety of groups and functions. Combining security and fraud under a converged risk umbrella sends a signal that everyone is on the same team and working toward the same goals. It also sends the message that silos and the turf wars, politics, and inefficiencies they bring have no place in the enterprise.

**2\. Less biased risk metrics:** Most enterprises maintain a risk register and regularly review, evaluate, and audit both inherent and residual risk. Risks are assigned to different groups within the enterprise, and the management, monitoring, and mitigation of those risks is delegated to those groups. Sounds logical, right? The problem is that there isn't a perfect 1:1 mapping here. As a result, there is overlap — some risks wind up assigned and delegated to multiple groups. Thus begins the double (or multiple) counting of exposure, which translates to inaccurate and biased risk metrics. While combining risk and fraud will not eliminate this problem entirely, it will help reduce the bias of risk metrics.

**3\. Better monitoring:** As you can imagine, visibility into what is happening across the enterprise on the network, within applications, and in cloud environments is critical to proper security and fraud monitoring. There are many other important factors, of course, though visibility is one of several very important ones. When kept separate, security and fraud will naturally develop their own technology stacks. They will have different visibility across the enterprise, different risks they are concerned about, different skill sets developing alerting and eventing content, and different processes and procedures. But what happens when a threat actor jumps from one monitoring silo to another? Chances are that neither group will be able to piece together the bigger picture, and that introduces risk. Combining security and fraud reduces the risk of this happening and facilitates improved monitoring across the enterprise.

**4\. More complete investigation:** When security and fraud are converged, not only is monitoring improved, but so is investigation. In the event that there is a security or fraud incident, analysts (whether their expertise is security, fraud, or both) will need to query and analyze data from a wide variety of sources. When security and fraud are siloed, this is more complex than it needs to be. A converged risk function, on the other hand, should ideally have access to all of the requisite visibility in order to properly and fully investigate the incident.

**5\. More efficient response:** Given that a large amount of fraud happens in digital channels, the line between areas of responsibility for security and fraud is blurred to begin with. And that's all the more so when it comes time to respond to a potential incident. Coordination and collaboration is required across security, fraud, IT, and other areas of the business. Having security and fraud converged at the outset makes the response more efficient and smooth. If multiple responses are going on at the same time, those efficiency gains can really begin to add up.

Strategic thinking, determination, and resources are required to converge security and fraud. It is a worthwhile investment, however, that pays immediate dividends. Converging security and fraud into a unified risk function enables and empowers enterprises to more efficiently and effectively mitigate risk.

What Adjustable Dumbbells Can Teach Us About Risk Management

A worsening threat landscape, increased digitization, and the long-term positive effects of modern security strategies are pushing critical infrastructure operators to do better.

Following the Colonial Pipeline hack — one of the highest-profile attacks against US critical infrastructure to date — in 2021, the Department of Homeland Security's Transportation Security Administration (TSA) released two unprecedented Security Directives, requiring owners and operators of gas and liquid pipelines to implement strict new protections against cyberattacks.

On July 21, the TSA released an update to these directives, doubling down on its efforts to ensure better protection for energy infrastructure nationwide. In particular, it has emphasized the need for access control, credential management, and the use of "compensating controls" to allow pipeline operators to embrace the latest innovations in how they protect critical systems.

While the update represents another step toward better protection for the oil and gas industry, it's important to understand that the guidelines alone aren't the only factors influencing the security postures of critical infrastructure. Pipeline operators have already been acting; in our work with some of the largest TSA-regulated energy companies in North America, we've witnessed a fundamental, positive shift in their approaches to cybersecurity, especially over the past year.

**Three Cybersecurity Motivators**

Three major factors beyond government pressure stand out as being key motivations behind the acceleration of operators' adoption plans.

**1\. Today's threat landscape is progressively worsening.** Regulations don't happen in a vacuum. Today, our threat landscape has grown more dangerous than ever. In the past two years, we've seen countless cyberattacks on critical infrastructure, including hacks on meat processor JBS and the water treatment facility in Oldsmar, Fla. Furthermore, attackers are increasingly targeting the companies that make up the backbone of the United States' supply chain and society at large: oil and gas pipelines, manufacturing plants, food processors, water suppliers, and more.

These threats are only going to grow in severity. This is due in large part to the growth of ransomware-as-a-service (RaaS), heightened collaboration between RaaS and other cybercriminal groups such as access brokers, and a troubling uptick in Russian and other state-sponsored cyber threats targeting US critical infrastructure. Government regulations aside, no operator that we've come across has been able to ignore these growing risks — or wants to try their luck against these hackers without adequate protective measures.

**2\. Digitization is exposing new and dangerous vulnerabilities.** While attacks increase, the digitization of operations is bringing new vulnerabilities to light. On-site equipment such as programmable logic controllers (PLCs), SCADA systems, distributed control systems, and Internet of Things (IoT) devices are increasingly being accessed remotely, creating a porous perimeter that hackers can easily penetrate. This trend was only exacerbated as businesses pivoted to remote work during the pandemic. Now, operators are dealing with a significantly expanded attack surface.

Several components of the TSA's new guidelines reinforce what we already knew to be true: specifically, the importance of recognizing and mitigating these digitization-driven vulnerabilities. The requirements reaffirm the need to control the interconnection of operational technology (OT), IT, and even cloud by securing the digital conduits that connect the different zones and applications. The new TSA guidelines also deepen the requirements for "compensating measures" to protect access to critical systems, many of which have limited built-in security. These protections are so important to prevent an attacker being able to progress from zone to zone, or system to system, in the event of an initial network breach.

**3\. Better security is no longer just defensive; it's also the catalyst for greater digital transformation.** Beyond the necessity of protecting against attacks, operators have begun to realize that an advanced security strategy is capable of catalyzing an accelerated digital transformation — and this has catapulted them into implementing better protective measures.

It's widely understood that a zero-trust security architecture, as defined by the National Institute of Standards in Technology (NIST), is the best approach for protecting operations from threats. The heart of this strategy requires every asset, machine, or data source to have its own identity, with interactions between them being controlled by policy authorizations. Once such a model is achieved, benefits beyond airtight security immediately become clear.

For instance, critical infrastructure cybersecurity leaders reportedly cite, in a study commissioned by Xage (registration required), improved user experience, more efficient operations, and the ability to save time or money as top benefits to adopting zero trust. What's more, with every element of the operation digitized and secured, teams can share sensitive data with one another quickly and easily, and partners can tap into appropriate data sources to better collaborate and drive new types of value across the supply chain. The result is not only defense, but also greater efficiency, collaboration, and business innovation.

**Regulations Are Important, but They're Not a Silver Bullet**

The TSA's original Security Directives, coupled with the recent updates, represent a crucial catalyst in helping operators implement better protective measures; still, they're not the only factors driving progress. A worsening threat landscape, increased digitization, and the long-term positive effects of modern security strategies are all pushing critical infrastructure operators to do better. We're pleased to see the new requirements reaffirm what we know to be best practices for security, and we're confident that critical infrastructure protection will continue moving in the right direction.

Pipeline Operators Are Headed in the Right Direction, With or Without TSA's Updated Security Directives

What issues are cybersecurity professionals concerned about in 2022? You tell us!

As many enterprises shift their operations to cloud, security teams are grappling with multiple security concerns such as visibility, data security, compliance, and data breaches.

Data from Dark Reading's 2021 Strategic Security Survey suggests that security teams are less concerned about deploying security policies, visibility of data stored in the cloud, and the number of exploits targeting cloud service providers than they were in 2020. In contrast, the security professionals in the survey were more concerned in 2021 that cloud service providers would not be able to detect a breach and the fact that there are more cloud breaches being reported than they were in 2020.

What issues are cybersecurity professionals more concerned about in 2022? That's what Dark Reading would like to find out in this year's Strategic Security Survey (click to get to the survey).

Last year's report showed that enterprises are no longer as worried that cloud service providers won't be able to provide service-level guarantees of security. That's a good thing. Fewer people are still thinking that the cloud isn't safe. But the growing number of cloud breaches do have these enterprises concerned about how the service provider will work with them if there is an incident.

Dark Reading's 2022 Strategic Security Survey is still open — we welcome your insights.

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

Source

DARKReading