STE WILLIAMS

Researchers have disclosed a huge leak of government data stemming from the Oklahoma Securities Commission. As discovered by UpGuard researcher Greg Pollock, 3 TB of data was exposed, including millions of files, many of which pertained to FBI investigations.

The data was exposed on a server sans password protection, meaning anyone with an Internet connection may have had access. Chris Vickery, head of research for UpGuard, reported to Forbes the FBI data had seven years’ worth of archive enforcement actions. Files included FBI interviews, emails among people involved with investigations, and letters from witnesses. They named companies involved with investigations, such as ATT and Goldman Sachs.

Vickery, who calls the incident “massively noteworthy,” says the commission had a poor response. Nobody looked into what was done with the trove of data downloaded by the researchers, he says. A spokesperson said the issue was being investigated; when the commission was alerted to the incident in December, it took the server off the public Internet.

Further, when Vickery and Pollock shared the breach, they told the agency it had exposed an rsync server, which holds large data stores and must be password-protected. This was one of several poor security practices the commission showed, in addition to weak passwords on government machines.

Read more details here.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/endpoint/oklahoma-data-leak-compromises-years-of-fbi-data/d/d-id/1333669?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

S4x19 — Miami — Researchers who discovered multiple vulnerabilities in building automation system (BAS) equipment have also constructed proof-of-concept malware to exploit some of those security weaknesses.

Security researcher Elisa Costante and her team at ForeScout last summer created the test malware, a modular design that includes a worm that spreads itself among BAS devices, using intelligence they gathered over the past three years while testing popular BAS systems such as protocol gateways and PLCs for HVACS and access control, for vulnerabilities. During that period, they uncovered ten security flaws, half of which were cross-site scripting (XSS) bugs in their associated Web application interfaces, as well as privilege escalation and buffer overflow vulnerabilities.

Costante shared the team’s research here at S4x19 this week.

While the affected BAS vendors – which ForeScout declined to reveal – since have patched the vulnerabilities, more than 11,000 of the affected devices today remain exposed on the public Internet to the buffer overflow flaw, mostly in schools and hospitals, due to poor patching processes or none at all, Costante says. Some had already quietly fixed the flaws in new versions of the devices.

“You still have a lot of [BAS] devices running on old firmware,” Costante said in an interview with Dark Reading. BAS devices and equipment don’t get updated or replaced regularly: some 60% of BAS products in place today are around 20 years old, she says.

Building systems are the oft-forgotten and increasingly network-connected piece of the security puzzle. They fall into a category of their own, and rarely are updated or vetted for security. BAS control systems manage and run physical operations of a building such as HVAC, elevators, physical access control, and video surveillance.

“A lot of times, building automation systems sit on the enterprise but IT has no access to them,” said Dale Peterson, CEO of Digital Bond and the head of the S4 ICS SCADA conference. “They’re not behind the firewall or [part of] ICS … and they’re not run by IT. It’s a little group doing their own thing.”

BAS SCADA systems often are older, and not typically considered part of the overall IT infrastructure, noted Eddie Habibi, CEO of ICS security vendor PAS. “Protecting them could be a lot easier” than an OT network, he said, but most BAS managers don’t even consider the cybersecurity of those systems. “It’s okay to do a ten-minute shutdown” for patching a BAS, he said. “You’re not running a refinery.”

Building Hacks

BAS hacking already is starting to become a thing: in a report published today on its BA system security findings and malware, ForeScout cited a 2016 ransomware attack on a hotel in Austria that targeted room locks, and a DDoS attack that hit heating systems in two apartment buildings in Finland. And among some of the juicier BAS targets are data centers, for example, where temperature fluctuations via a hacked HVAC could wreak havoc and ruin computers, ForeScout said.

Costante says her team’s goal was to create complex malware that couldn’t be traced by forensics. They decided to first target in the malware an Internet-facing IP camera, which then spread to a workstation that ultimately got them to their target, the PLC that controls the building automation process. “From the Windows workstation, we use the core part of the malware, the exploitation of the buffer overflow” vulnerability, she said.

The malware could be used to open a restricted phyisical access area to an attacker, such as a restricted area in an airport, she said.

ForeScout spent a total of $12,000 on the malware and equipment for the project, which Costante says demonstrates that BAS hacking doesn’t require heavily resourced nation-state backing, for example. And part of the goal of the research was to test what the vulnerability of BAS and possible attack scenarios.

“There was a lack of awareness on what you can do with buildings and how easy and exposed they are,” Costante said.

Meanwhile, some building management operations are starting to find cybersecurity religion. David Weinstein, vice president of threat research at Claroty, says his company is seeing major real estate firms inquiring about securing their properties’ building automation systems. “More CISOs are taking responsibility for OT and IoT,” he said, and that also brings BAS into the security equation.

Related Content:

• Hijacking a PLC Using its Own Network Features
• Triton/Trisis Attack Was More Widespread Than Publicly Known
• 7 Privacy Mistakes That Keep Security Pros on Their Toes
• 2019 Attacker Playbook

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/malware-built-to-hack-building-automation-systems/d/d-id/1333671?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

S4x19 — Miami — New details have emerged about the 2017 Triton/Trisis cyberattack on a Middle East plant’s safety instrumentation system — including a missed opportunity to quash it two months earlier than its ultimate discovery, according to an ICS security expert who assisted in the incident response.

New information also shows that the attackers infected six engineering systems, not just two as investigators had reported, said Julian Gutmanis, who was working out of a major oil and gas organization in Saudi Arabia at the time of the attacks, in a presentation here at S4. The publicly revealed attack on Aug. 7, 2017, was not the first incident suffered by the victim at the hands of the Triton/Trisis attackers, he said. In June 2017, an emergency plant-process shutdown system was knocked offline by the attackers. He also confirmed that the Middle East organization victim of the Triton/Trisis attack was a petrochemical plant in Saudi Arabia – a detail that initially had been speculated but not publicly verified.

The June incident wasn’t accurately identified as a cyberattack by the petrochemical firm’s vendor, Schneider Electric, he said, nor did Schneider ultimately take the proper remediation steps to clean up and remediate the attack. As a result, he said, the Triton/Trisis attackers remained unnoticed in the plant network; it wasn’t until the August attack that it became obvious hackers were inside of it.

While early reports by Schneider and investigators into the attack said that a single Schneider Triconex Emergency Shut Down (ESD) system was targeted and knocked offline by the Triton/Trisis attack, it turns out there were actually six infected Triconex Emergency Shut Down (ESD) systems machines, all of which suffered a rare shutdown. These so-called safety instrumentation systems provide emergency shutdown for plant processes to prevent physical threats when a plant process reaches an unsafe level. These systems are not typically under the domain of security teams but, rather, engineering teams; Triton/Trisis was the first known incident to affect the OT engineering department.

“The June investigation was insufficient,” with Schneider attributing the attack to a mechanical failure of the ESD system rather than a cyberattack, said Gutmanis, who will be joining Dragos. “They should have investigated what occurred in the plant,” he said. “So the attackers got another two months [in the network] unimpeded. They ran executables multiple times between June and July before the August incident.”

Red Flags
According to Gutmanis, the June Triconex system outage occurred on a Saturday evening, a time when most engineers aren’t typically in the plant. The petrochemical firm called in Schneider to assist in troubleshooting the Triconex system failure; the vendor pulled logs and diagnostics from the machine, checked the machine’s mechanics, and, after later studying the data in its own lab, addressed what it thought was a mechanical issue. “The ESD was determined to be fully functional again and the operations restored,” Gutmanis said. “But there were a number of big red flags going on here.”

He said the vendor recommended moving the system to a secure reference architecture. “That’s good for a new plant but not advisable in the midst of an incident because it could expose admin credentials and other assets in the domain to the … [still-] compromised system,” Gutmanis said.

The now-infamous August shutdown of the Saudi Arabian firm’s Triconex ESD system, leading to the discovery of the Triton/Trisis malware, actually involved six of the controllers, he said. These safety systems handled sensitive operations, including a burner management system. “The worst case was the potential release of toxic hydrogen sulfide gases,” he said.

The attackers likely didn’t mean to trigger shutdowns in the Triconex safety systems, but those were the only red flags until Gutmanis’ team and others, including Schneider, dug deeper into the incident and found the sophisticated malware targeting those engineering systems. Gutmanis’ team was called in for a rapid-response engagement.

There were other clues of a spreading attack uncovered, he said, including Remote Desktop Protocol (RDP) sessions to the plant’s engineering workstations from within the IT network. “The plant on paper had a secure architecture. But we identified a poorly configured DMZ infrastructure that allowed the attackers to compromise the DMZ [between the IT and OT networks] and pivot to the control network,” he said. “The DMZ firewall configuration was insecure,” and the organization’s perimeter VPN had been compromised and infiltrated.

“We saw a lot of traffic across the DMZ … there were beacons we could see from the control network,” he said. There was Mimikatz Windows-hacking traffic spotted, which had been flagged by the victim organization’s antivirus software, for example.

“The entire organization was compromised,” he said, and it became an all-hands-on-deck cleanup with various IT and OT vendors on-site doing cleanup and reboots of their systems.

Gutmanis said while his firm shared its findings with Schneider throughout the investigation, it was a “one-way” collaboration because Schneider didn’t reciprocate. The first his firm heard about Schneider’s findings was when the company was onstage at S4 in 2017 giving its presentation of the Triton/Trisis malware.

Schneider’s public sharing of its attack findings was unprecedented for an ICS/SCADA vendor. The firm gave details of a vulnerability in its Triconex Tricon firmware that allowed the attackers to grab control of the emergency shutdown system at the plant, using a remote access Trojan as well in the attack. 

In a response to Gutmanis’ presentation, Schneider pointed to the August incident in a statement but did not mention the initial June incident investigation criticized by Gutmanis.

“We deployed a support engineer to the site within four hours of the end user’s request. Thereafter, our on-site experts conducted a comprehensive analysis. Once they determined the incident to be cybersecurity-related, they turned the investigation over to the end-user, who hired FireEye for attack eviction and site remediation,” the company said in its statement. “FireEye worked directly with the end user, and at the end-user’s request, Schneider Electric communicated only with FireEye. At every step, we have cooperated fully with the end user, FireEye and the U.S. Department of Homeland Security, with coordination from the U.S. Federal Bureau of Investigation.

“We continue to be open and transparent about the incident to learn from Triton and help the broader goal of worldwide cyberattack prevention.”  

‘Lucky’
Gutmanis, meanwhile, pointed out that the petrochemical firm “got lucky” in the end, despite expensive and multiple outages for at least one full week per affected plant within the site. “The intent of the attacker was to manipulate the integrity of the ESD controllers,” but no catastrophic physical disaster occurred, he noted.

The Triton/Trisis attackers had been inside the victim firm’s network since 2014, said Rob Lee, CEO and founder of Dragos. The way attackers targeted the six sites could have caused a loss of human life as well, he says.

OT managers need to have a well-rehearsed incident response plan and be able to detect lateral movement in their networks, he said. “And recognize that your vendors’ [approach to response] may be outdated.”

In an interview with Dark Reading, Gutmanis said he believes Triton/Trisis could have been a “testing ground” for other such attacks in OT. He recommended that OT operators have monitoring in place, perform auditing, and be prepared for an incident to occur, such as knowing who to call and how to get them onsite rapidly.

Gutmanis’ new details on the attacks came as a surprise to many security experts at S4.

“It’s a big deal that the attackers realized they hadn’t been caught and had the opportunity to continue what they were doing without consequences,” said Michael Toecker, owner and engineer at Context Industrial Security. “There was an original missed opportunity to catch the attackers when they were on the DCS [distributed control system].”

Phil Neray, vice president of industrial cybersecurity at CyberX, says the key lesson from the Triton/Trisis attack is the organizational breakdown between the organization’s IT and OT network operators. “There were no clear definitions of which team was responsible for ensuring that security controls had been properly implemented and were actually effective,” he said.

Related Content:

• Industrial Safety Systems in the Bullseye
• TRITON Attacker Disrupts ICS Operations, While Botching Attempt to Cause Physical Damage
• First Malware Designed Solely for Electric Grids Caused 2016 Ukraine Outage
• Lessons From The Ukraine Electric Grid Hack

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise … View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/triton-trisis-attack-was-more-widespread-than-publicly-known/d/d-id/1333661?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Why are we so good at identifying attacks but so bad at preventing them? Every day, we hear of new organizations getting hacked or old targets getting tagged again. Clearly, our defenses are not getting the job done. However, forensics experts have been able to quickly retrace each attack sequence, identify details about which systems were compromised, and determine how much information leaked. That is only possible if the necessary clues were collected during the attack.

Obviously, we are solving the challenge of identifying important details and retaining that information. We are becoming adept at mining that information once we know what to look for. The failure comes in connecting dots in real time as hackers (excluding those spreading ransomware) hide within our networks for hundreds of days before detection. As a result, they have time to conduct reconnaissance, escalate privilege, and exfiltrate information with increasing regularity and severity.

Why are hackers able to hide for so long? Imperva reports that 27% of security professionals receive over 1 million alerts per day and most receive over 10,000. Those are overwhelming numbers. No team can effectively respond to that many incidents. Most alerts are false positives that suck up resources to investigate and make it impossible to automate responses — the impact would be more damaging than the attacks.

On the other hand, we already see the impact of not responding. No defenses will survive well-trained, determined attackers free inside the organization for an extended period. If unable to achieve their goals initially, the attackers collect credentials, expand footprint, and catalog defenses. When a new exploit is available, the hackers have a list of potential targets. Each exploit creates a race to see if the hackers can exploit vulnerabilities in their catalog of devices before the ops team can patch systems. Given enough time and exploits, the hackers will win a race and penetrate defenses. Attacking becomes a numbers game that is clearly in favor of the hackers.

How can an IT team survive continuous assault? Social engineering attacks allow hackers to bypass firewalls with some regularity. Detecting intruders quickly and completely removing them is key. As described above, most organizations already have systems in place that are detecting attacks and logging evidence. This information needs to be processed in real time and without the false positives.

The cyber kill chain (CKC) is a great framework to start organizing network and application defenses. I like this version of the framework because it provides a little more detail on containing an attack than most others. (Most models seem to portray containment as dealing with lateral movement.) The framework makes it easy to catalog types of attacks and develop strategies to intercept them.

Using the CKC, make sure you have tools in place to at least “Detect,” “Deny,” and “Contain” attacks. Just detecting hackers is insufficient because that only helps identify what information has been stolen. You want to block or at least stall them long enough to give security team time after detection to remediate the issue.

Next, identify which alerts are actionable and map those alerts to boxes in the CKC. These are the alerts that quickly resolve issues. They must contain detailed information about the attack such as source, target and any confirming information. For example, an attempt to log in to a honeypot should result in an alert indicating which machine is being attacked, where is the attacker coming from, and whose credentials are they using. Actionable alarms represent the best bang for the buck for the support team. Other alerts might be helpful for an attack postmortem, but don’t provide real protection. Make sure your SIEM escalates actionable alerts for immediate resolution. Secondarily, escalate the most informative alerts for each block in the matrix. Hopefully, taking care of priority issues will eliminate enough symptoms to enable some investigation into secondary warnings.

Reassess the effectiveness of your defenses using the CKC framework but only include reliable, actionable indicators. This provides a true picture of information security posture. For remaining boxes, check with existing tool vendors to see if they have plans to make their systems more actionable and less noisy. Find solutions to cover remaining gaps.

Review the operational value of each tool. If a tool is not providing enough useful information, or is generating too much noise, replace or eliminate it. With all the low-commitment software-as-a-service solutions available, it is easier than ever to swap tools. The goal is to build a CKC filled with actionable, effective tools that can:

Ben Haley, SVP of Engineering of HOPZERO Security, has extensive experience monitoring application performance and identifying security vulnerabilities. He was the initial software engineering director at NetQoS where he led the development of the first scalable NetFlow … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/are-you-listening-to-your-kill-chain/a/d-id/1333620?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Gamers beware: a vulnerability in Epic Games’ online platform could have threatened data belonging to players of the massively popular video game Fortnite, Check Point researchers disclosed today. Epic Games was made aware of the problem, which has since been addressed.

Fortnite, created by Epic Games, has more than 80 million players and is responsible for nearly half of the video game developer’s estimated value of $5 billion to $8 billion. Newly discovered flaws in its system could let attackers take over players’ accounts, view personal account data, buy V-bucks (digital in-game currency), and record in-game chats and background home conversations.

It’s not the first time Fortnite has been targeted. Previous scams tricked players into accessing fake websites that promised to generate V-bucks, which are typically only acquired in the official Fortnite store or earned through the game. These phishing sites prompted players to enter game login credentials and personal data: name, address, and credit card information.

Fortnite players, many of whom are minors, were being scammed as a result of their involvement with the game, but nobody could tell how. It may just be a game, but with millions of players, it also presents a huge opportunity for cybercriminals to take advantage of players.

“When we started to research, we immediately understood that Fortnite is not a game – it’s an infrastructure,” says Oded Vanunu, head of product vulnerability research at Check Point. It gives players the ability to connect, talk with people around the world, and sell and buy weapons. The business logic is deeply sophisticated and bring a lot of potential vulnerabilities.

New data indicates a more sophisticated attack method, which doesn’t require users to enter any of their login details. A vulnerability in some of Epic Games’ subdomains enabled a cross-site scripting (XSS) attack with a user only needing to click a link sent by the attacker. When they clicked, the adversary could instantly capture their username and password with no interaction at all.

A Risky Login Page

From the start of their research, a member of the Check Point team had a strong feeling about Epic Games’ single sign-on (SSO) mechanism, analysts explain in a blog post on the discovery. They took a closer look and found that Epic Games had written a generic SSO implementation to support several login providers, so they investigated further and found the flaw.

Researchers found when a player logged into their account by clicking the “Sign In” button, the platform generated a URL with a “redirectedUrl” parameter. The redirect URL could be manipulated to send the player to any site within the domain “.epicgames.com.” With this parameter under their control, attackers could send victims to a site with the XSS payload. The payload could make a request to any SSO provider—and Fortnite uses many, they point out.

Players accessing Fortnite will see Epic Games uses multiple SSO providers: PlayStationNetwork, Xbox Live, Nintendo, Facebook, and Google+. Researchers decided to use Facebook as the SSO provider for their proof-of-concept to show how players could be redirected to a vulnerable webpage where the XSS payload is executed and steals authentication code.

“Once [we’ve] exploited this sub-domain, we chain this specific vulnerability into an account takeover vulnerability by manipulating a parameter which is part of the main logic of the authentication process of Epic Games,” Vanunu explains. Because the flaw is linked to Epic Games, he calls it a “very sophisticated method” to silently steal Fortnite users’ tokens.

When they have access to a player’s account, attackers can buy access or weapons, shift it to their own account, and sell it. “Lots of gamers’ accounts are worth a lot of money,” says Vanunu. “As long as you play on this platform, every day you’re getting more seniority.”

Intruders can also use their point within a user’s account to chat with other Fortnite players and send them malicious content, he continues.

Epic Games has responded to the report, thanking Check Point for bringing the problem to its attention. “As always, we encourage players to protect their accounts by not re-using passwords and using strong passwords, and not sharing account information with others,” a company spokesperson says.

Related Content:

• 6 Ways to Beat Back BEC Attacks
• Online Fraud: Now a Major Application Layer Security Problem
• Former IBM Security Execs Launch Cloud Data Security Startup
• Cryptomining Continues to Be Top Malware Threat

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance Technology, where she covered financial … View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/fortnite-players-compromised-via-epic-games-vulnerability/d/d-id/1333662?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Attackers are ramping up efforts to try and scam HR employees at many businesses into diverting the payrolls of CEOs and other highly compensated executives to fraudulent accounts.

Security vendor Agari says it has observed a recent and considerable increase in such payroll diversion attempts via social engineering. The criminal gangs behind these scams appear to have invested considerable resources into understanding organizational hierarchies and knowing exactly whom to target, Agari said in a report this week.

“Payroll diversion has become an emerging threat during the past year,” says Crane Hassold, senior director of threat research at Agari. The attacks began ramping up in Q4 2018 and are the latest evolution in business email compromise (BEC) scams, he says.

“Unlike traditional BEC attacks, which are starting to raise red flags with financial institutions, payroll diversion attacks eliminate the interaction with banks because it is a direct deposit instead of a wire transfer,” he says.

The typical modus operandi in these scams is for the attacker to assume the identity of the CEO by setting up an email account in the name of the executive. The adversary then sends an email to a previously identified individual within the HR or finance function requesting a change in the existing direct deposit account details and inquiring about what’s needed to process the change. The threat actors often are not fazed when asked to provide a voided check displaying the new account’s details, and often can provide it. If the scam is successful, the payroll of the executive that was impersonated gets diverted to the attacker-held account.

The payroll diversion approach eliminates the need for attackers to deal with a third-party system, thereby allowing for greater control over the whole process, Agari researchers said. “We’ve observed this type of attack targeting a variety of employees, but the majority target C-suite individuals because the monetary payoff is much greater,” says Hassold.

The attacks are scalable in the sense that adversaries can conduct them against a large number of targets at different companies. But the likelihood that the attackers would select multiple targets at the same company is low because of the red flags that it would raise, he said.

BEC attacks have been around for several years and continue to be a potent threat for most organizations. Originally, BEC involved attacks in which an adversary either tricked an individual with signing authority at a company into wire-transferring funds to an attacker-held account, or hijacked an account to achieve the same objective.

As organizations have become savvier about such BEC scams, adversaries have kept introducing new twists as well. In December for instance, security researchers observed a new trend in which threat actors impersonating CEOs tried to get office managers and others with similar authority to purchase gift cards for employees. Though losses from gift card BEC attacks have been relatively small so far in the US—at around $1 million—the scam illustrates how criminal groups have kept trying different ruses to try and defraud businesses.

According to the FBI, the reported global loss from BEC attacks between October 2013 and May 2018 was some $12 billion. The scam has been reported in 150 countries and continues to grow and evolve, the FBI has noted. The agency has described BEC as a threat that impacts organizations of all sizes.

BEC shows how cyber attacks are increasingly leveraging social engineering instead of technical exploits, Hassold notes. “BEC has become a staple in cyberattacks for scammers because they are very easy to deploy [and] require very little technical expertise or knowledge,” he says.

Importantly, the success rate does not need to be very high for BEC to be profitable. “If even one percent of 1,000 attacks is successful, it could generate hundreds of thousands of dollars,” for the criminals, Hassold says.

Related Content:

• Who’s At Greatest Risk for BEC Attacks? Not the CEO
• Attackers Employ Social Engineering to Distribute New Banking Trojan
• ‘London Blue’ BEC Cybercrime Gang Unmasked
• 6 Ways to Beat Back BEC Attacks

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

Article source: https://www.darkreading.com/attacks-breaches/bec-groups-ramp-up-payroll-diversion-attacks-/d/d-id/1333665?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Where do you stand in the debate over whether governments should stockpile vulnerabilities? Some believe that regardless of its utility, the practice of keeping software vulnerabilities secret affects all users and they should be disclosed no matter the circumstances. On the other side of the argument are those who believe zero-days are a matter of national security and that if a vulnerability gives us an edge in warfare or intelligence gathering, it should be kept secret.

And then there’s a third group, to which I belong. This crowd understands both the benefits and consequences that can occur when governments find and conceal vulnerabilities. Ultimately, this group believes we need to take an approach that’s less binary and more circumstantial, factoring in both the pros and cons of the practice and how they change based on the situation and conditions at hand.

Did you know the US government has a process in place to do exactly that? It’s called the Vulnerabilities Equity Process (VEP), defined as “a process used by the U.S. federal government to determine on a case-by-case basis how it should treat zero-day computer security vulnerabilities, whether to disclose them to the public to help improve general computer security, or to keep them secret for offensive use against the government’s adversaries.” The VEP was developed in the late 2000s in response to a public outcry against the stockpiling of zero-day vulnerabilities. It was initially kept secret until the Electronic Frontier Foundation received redacted documentation through a Freedom of Information Act (FOIA) request in 2016. After the disclosure of the ShadowBrokers in mid-2017, the White House released an updated version of the VEP to the public in an attempt to improve transparency around the process. Let’s explore how it works.

Today’s VEP Process
The process is run with the authority of the White House and is led by both a representative from the National Security Agency (NSA), under the direction of the secretary of defense, as the executive secretariat, and the president’s cybersecurity coordinator as the director. Other participants include representatives from 10 government agencies that comprise the Equities Review Board.

The process dictates an exchange between organizations that discover these vulnerabilities, the secretariat and the members of the Equities Review Board. During this exchange, vulnerabilities are disclosed to the group so each member can claim equity (for example, explaining “Here’s how this vulnerability affects me”). This claim kicks off a round of discussion between the reporter and equity claimants to determine whether or not to recommend disclosing or restricting the vulnerability. The final decision to accept the recommendation or come up with alternatives is made by consensus of the Equities Review Board. Once a disclosure decision is made, the dissemination happens within seven days. Once you add up the time frames, the entire end-to-end process from discovery to dissemination can take anywhere from a week to one month, which is fast for a US government process.

The VEP also requires an annual report that includes statistical data on the process and its outcomes throughout the year. The report requires an unclassified executive summary at a minimum. The first reporting period closed on September 30, 2018, so we should expect an annual report soon.

Gaps and Exceptions
This process is by no means perfect. Between accommodations for the timetable, varying nondisclosure action options, and the complex back-and-forth between organizations, there is potential for our government to simply maintain the old status quo and fall short of the level of transparency for which the VEP was intended to deliver. A recent report outlined a solid list of issues associated with the process (you can read the original article here), which includes the following factors:

1. NDAs and other agreements. The VEP is subject to legal restrictions against disclosing things such as nondisclosure agreements, memoranda of understanding, and other agreements between foreign or private sector partners. This opens up the possibility for both partners to hide behind these agreements in order to prevent disclosure.
2. Lack of Risk Rating. The industry rates vulnerabilities by severity based on many factors. The VEP does not mandate any such rating. The absence of this kind of categorization or ranking process could result in false statistics at the end of the year. For example, the VEP could publicly state that it disclosed 100 vulnerabilities this year, but without context those could all be low-risk threats that have very little impact to the private sector.
3. NSA Leadership. Considering the fact that the NSA is likely the greatest equity holder, as well as the most experienced in dealing with vulnerabilities, it comes as no surprise that a representative from the NSA was chosen as the secretariat. This position allows the largest equity holder the most power in this process.
4. Alternative to Disclosure. While public disclosure is the default, other options include: disclosing mitigation information but not the vulnerability itself, limited use by our government, disclosing to US allies at a classified level, and indirect disclosure to the vendor. Many of these options keep the vulnerability a secret, negating the benefit that disclosure would bring.

Lack of Transparency
In addition to this list, there doesn’t seem to be any private sector oversight built into the process. One of the issues I always find when arguing about zero-days is trust. The individual who believes vulnerabilities should always be disclosed for the betterment of security will rarely accept the response of an insider stating: “We can’t because it’s worth keeping secret.” With the 10 agencies in the Equities Review Board including both the Department of Commerce and Department of Homeland Security, one could assume it is their responsibility to keep the private sector in mind. This does little to ease the mind of the security advocate, as these are positions appointed by the executive branch.

I believe the government should include a private sector review board of select industry representatives and cybersecurity experts who can hold a security clearance. These board members could review the outcomes of the VEP process on a monthly or quarterly basis. I believe that security advocates would be more willing to accept the response “We can’t because it’s worth keeping secret” if they hear it from a widely accepted industry expert as well as from the government.

Related Content:

• 2019 Attacker Playbook
• Bug Bounty Awards Climb as Software Security Improves
• Ex-NSA Contractor Was a Suspect In Shadow Brokers Leak

Ricardo Arroyo, senior technical product manager and ThreatSync guru|], is responsible for guiding the design and implementation of threat detection and response at WatchGuard Technologies.  Following a 15-year career at the NSA, where he worked as an analyst and cyber … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/how-the-us-chooses-which-zero-day-vulnerabilities-to-stockpile-/a/d-id/1333652?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple