Time Will Tell if the New Vulnerabilities Equities Process Is a Step Forward for Transparency
Drudge Bot last edited by
The White House has released a new and apparently improved Vulnerabilities Equities Process (VEP), showing signs that there will be more transparency into the government’s knowledge and use of zero day vulnerabilities. In recent years, the U.S. intelligence community has faced questions about whether it “stockpiles” vulnerabilities rather than disclosing them to affected companies or organizations, and this scrutiny has only ramped up after groups like the Shadow Brokers have leaked powerful government exploits. According to White House Cybersecurity Coordinator Rob Joyce, the form of yesterday’s release and the revised policy itself are intended to highlight the government’s commitment to transparency because it’s “the right thing to do.”
EFF agrees that more transparency is a prerequisite to any debate about government use of vulnerabilities, so it’s gratifying to see the government take these affirmative steps. We also appreciate that the new VEP explicitly prioritizes the government’s mission of protecting “core Internet infrastructure, information systems, critical infrastructure systems, and the U.S. economy” and recognizes that exploiting vulnerabilities can have significant implications for privacy and security. Nevertheless, we still have concerns over potential loopholes in the policy, especially how they may play into disputes about vulnerabilities used in criminal cases.
The Vulnerabilities Equities Process has a checkered history. It originated in 2010 as an attempt to balance conflicting government priorities. On one hand, disclosing vulnerabilities to vendors and others outside the government makes patching and other mitigation possible. On the other, these vulnerabilities may be secretly exploited for intelligence and law enforcement purposes. The original VEP document described an internal process for weighing these priorities and reaching a decision on whether to disclose, but it was classified, and few outside of the government knew much about it. That changed in 2014, when the NSA was accused of long-term exploitation of the Heartbleed vulnerability. In denying those accusations and seeking to reassure the public, the government described the VEP as prioritizing defensive measures and disclosure over offensive exploitation.
The VEP document itself remained secret, however, and EFF waged a battle to make it public using a Freedom of Information Act lawsuit. The government retreated from its initial position that it could not release a single word, but our lawsuit concluded with a number of redactions remaining in the document.
The 2017 VEP follows a similar structure as the previous process: government agencies that discover previously unknown vulnerabilities must submit them to an interagency group which weighs the “equities” involved and reaches a determination of whether to disclose. The process is facilitated by the National Security Council and the Cybersecurity Coordinator, who can settle appeals and disputes.
Tellingly, the new document publicly lists information that the government previously claimed would damage national security if released in our FOIA lawsuit. The government’s absurd overclassification and withholdings extended to such information as the identities of the agencies that regularly participate in the decision-making process, the timeline, and the specific considerations used to reach a decision. That’s all public now, without any claim that it will harm national security.
Many of the changes to the VEP do seem intended to facilitate transparency and to give more weight to policies that were previously not reflected in the official document. For example, Annex B to the new VEP lists “equity considerations” that the interagency group will apply to a vulnerability. Previously, the government had argued that a similar, less-detailed list of considerations published in a 2014 White House blog post was merely a loose guideline that would not be applied in all cases. We don’t know how this more rigorous set of considerations will play out in practice, but the new policy appears to be better designed to account for complexities such as the difficulty of patching certain kinds of systems. The new policy also appears to recognize the need for swift action when vulnerabilities the government has previously retained are exploited as part of “ongoing malicious cyber activity,” a concern we’ve raised in the Shadow Brokers case.
The new policy also mandates yearly reports about the VEP’s operation, including an unclassified summary. Again, it remains to be seen how much insight these reports will provide, and whether they will prompt further oversight from Congress or other bodies, but this sort of reporting is a necessary step.
In spite of these positive signs, we remain concerned about exceptions to the VEP. As written, agencies need not introduce certain vulnerabilities to the process at all if they are “subject to restrictions by partner agreements and sensitive operations.” Even vulnerabilities which are part of the process can be explicitly restricted by non-disclosure agreements. The FBI avoided VEP review of the Apple iPhone vulnerability in the San Bernardino case due to an NDA with an outside contractor, and such agreements are apparently extremely common in the vulnerabilities market. And exempting vulnerabilities involved in “sensitive operations” seems like an exceptionally wide loophole, since essentially all offensive uses of vulnerabilities are sensitive. Unchecked, these exceptions could undercut the process entirely, defeating its goal of balancing secrecy and disclosure.
Finally, we’ve seen the government rely on NDAs, classification, and similar restrictions to improperly and illegally withhold material from defendants in criminal cases. As the FBI and other law enforcement agencies increasingly use exploits to hack into unknown computers, the government should not be able to hide behind these secrecy claims to shield its methods from court scrutiny. We hope the VEP doesn’t add fuel to these arguments.
Related Cases: EFF v. NSA, ODNI - Vulnerabilities FOIA
Make ISO from DVD
In this case I had an OS install disk which was required to be on a virtual node with no optical drive, so I needed to transfer an image to the server to create a VM
Find out which device the DVD is:lsblk
Output:NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465.8G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 464.8G 0 part ├─centos-root 253:0 0 50G 0 lvm / ├─centos-swap 253:1 0 11.8G 0 lvm [SWAP] └─centos-home 253:2 0 403G 0 lvm /home sdb 8:16 1 14.5G 0 disk /mnt sr0 11:0 1 4.1G 0 rom /run/media/rick/CCSA_X64FRE_EN-US_DV5
Therefore /dev/sr0 is the location , or disk to be made into an ISO
I prefer simplicity, and sometimes deal with the fallout after the fact, however Ive repeated this countless times with success.dd if=/dev/sr0 of=win10.iso
Where if=Input file and of=output file
I chill out and do something else while the image is being copied/created, and the final output:8555456+0 records in 8555456+0 records out 4380393472 bytes (4.4 GB) copied, 331.937 s, 13.2 MB/s
Recreate postrgresql database template encode to ASCIIUPDATE pg_database SET datistemplate = FALSE WHERE datname = 'template1';
Now we can drop it:DROP DATABASE template1;
Create database from template0, with a new default encoding:CREATE DATABASE template1 WITH TEMPLATE = template0 ENCODING = 'UNICODE'; UPDATE pg_database SET datistemplate = TRUE WHERE datname = 'template1'; \c template1 VACUUM FREEZE;