Government  

When the North American Free Trade Agreement (NAFTA) was originally negotiated, cybersecurity was not a central focus. NAFTA came into force – removing obstacles to commercial trade activity between the US, Canada, and Mexico – in 1994, well before most digital services existed. Today, cybersecurity is a major economic force – itself a large industry and important source of jobs, as well as an enabler of broader economic health by reducing risk and uncertainty for businesses. Going forward, cybersecurity should be an established component of modernized trade agreements and global trade policy. The Trump Administration is now modernizing NAFTA, with the first renegotiation round concluding recently. There are several key ways the US, Mexican, and Canadian governments can use this opportunity to advance cybersecurity. In this blog post, we briefly describe two of them: 1) Aligning cybersecurity frameworks, and 2) protecting strong encryption. For more about Rapid7's recommendations on cybersecurity and trade, check out our comments on NAFTA to the US Trade Representative (USTR), or check out my upcoming presentation on this very subject at Rapid7's UNITED conference! Align cybersecurity frameworks Trade agreements should broadly align approaches to cybersecurity planning by requiring the parties to encourage voluntary use of a comprehensive, standards-based cybersecurity risk management framework. The National Institute of Standards and Technology's (NIST) Cybersecurity Framework for Critical Infrastructure ("NIST Cybersecurity Framework") is a model of this type of framework, and is already experiencing strong adoption in the U.S. and elsewhere. In addition to our individual comments to USTR, Rapid7 joined comments from the Coalition for Cybersecurity Policy and Law, and also organized a joint letter with ten other cybersecurity companies, urging USTR to incorporate this recommendation into NAFTA. International alignment of risk management frameworks would promote trade and cybersecurity by Streamlining trade of cybersecurity products and services. To oversimplify, think of a cybersecurity framework like a list of goals and activities – it is easier to find the right products and services if everyone is referencing a similar list. Alignment on a comprehensive framework would enable cybersecurity companies to map their products and services to the framework more consistently. Alignment can also help less mature markets know what specific cybersecurity goals to work toward, which will clarify the types of products they need to achieve these goals, leading to more informed investment decisions that hold service providers to consistent benchmarks. Enabling many business sectors by strengthening cybersecurity. Manufacturing, agriculture, healthcare, and virtually all other industries are going digital, making computer security crucial for their daily operations and future success. Broader use of a comprehensive risk management framework can raise the baseline cybersecurity level of trading partners in all sectors, mitigating cyber threats that hinder commercial activity, fostering greater trust in services that depend upon secure infrastructure, and strengthening the system of international trade. Helping address trade barriers and market access issues. Country-specific approaches to cyber regulation – such as data localization or requiring use of specific technologies – can raise market access issues or force ICT companies to make multiple versions of the same product. International alignment on interoperable, standards-based cybersecurity principles and processes would reduce unnecessary variation in regulatory approaches and help provide clear alternatives to cybersecurity policies that inhibit free trade. To keep pace with innovation and evolving threats, prevent standards from reducing market access, and incorporate the input of private sector experts, the risk management framework should be voluntary, flexible, and developed in an industry-led and transparent process. For example, the NIST Cybersecurity Framework is voluntary and was developed through an open process in which anyone can participate. The final trade agreement text need not dictate the framework content beyond basic principles, but should instead encourage the development, alignment, and use of functionally similar cybersecurity frameworks. Prohibit requirements to weaken encryption Critical infrastructure, commerce, and individuals depend on encryption as a fundamental means of protecting data from unauthorized access and use. Market access rules requiring weakened encryption would create technical barriers to trade and put products with weakened encryption at a competitive advantage with uncompromised products. Requirements to weaken encryption can impose significant security risks on companies by creating diverse new attack surfaces for bad actors, including cybercriminals and unfriendly international governments – ultimately undermining the security of the end-users, businesses, and governments. NAFTA should include provisions forbidding parties from conditioning market access for cryptography used for commercial applications on the transfer of private keys, algorithm specification, or other design details. The final draft text of the Trans-Pacific Partnership (TPP) contained a similar provision – though Congress never ratified TPP, so it never came into force. Although this provision would be helpful to protect strong encryption, it would only apply to commercial activities. The current version of NAFTA contains exceptions for regulations undertaken for national security (as did TPP, in addition to clarifications that a nation's law enforcement agencies could still demand information pursuant to their legal processes). This may limit the overall protectiveness of the provision, but should also moderate concerns a nation might have about including encryption protection in the trade agreement. This is beginning The NAFTA parties have set an aggressive pace for negotiations, with the goal of agreeing on a final draft by the end of the year. However, the original agreement took years to finalize, and NAFTA covers many subjects that can attract political controversy. So NAFTA's timeline, and openness to incorporating new cybersecurity provisions, are not entirely clear. Nonetheless, the Trump Administration has indicated that both international trade and cybersecurity are priorities. Even as the NAFTA negotiations roll on, the Administration has begun examining the Korea-US trade agreement, and both new agreements and modernization of previous agreements are likely future opportunities. Trade agreements can last decades, so considering how best to embed cybersecurity priorities should not be taken lightly. Rapid7 will continue to work with private and public sector partners to strengthen cybersecurity and industry growth through trade agreements.

On Jun. 22, the US Copyright Office released its long-awaited study on Sec. 1201 of the Digital Millennium Copyright Act (DMCA), and it has important implications for independent cybersecurity researchers. Mostly the news is very positive. Rapid7 advocated extensively for researcher protections to be built into this report, submitting two sets of detailed comments—see here and here—to the Copyright Office with Bugcrowd, HackerOne, and Luta Security, as well as participating in official roundtable discussions. Here we break down why this matters for researchers, what the Copyright Office's study concluded, and how it matches up to Rapid7's recommendations. What is DMCA Sec. 1201 and why does it matter to researchers? Sec. 1201 of the DMCA prohibits circumventing technological protection measures (TPMs, like encryption, authentication requirements, region coding, user agents) to access copyrighted works, including software, without permission of the owner. That creates criminal penalties and civil liability for independent security research that does not obtain authorization for each TPM circumvention from the copyright holders of software. This hampers researchers' independence and flexibility. While the Computer Fraud and Abuse Act (CFAA) is more famous and feared by researchers, liability for DMCA Sec. 1201 is arguably broader because it applies to accessing software on devices you may own yourself while CFAA generally applies to accessing computers owned by other people. To temper this broad legal restraint on unlocking copyrighted works, Congress built in two types of exemptions to Sec. 1201: permanent exemptions for specific activities, and temporary exemptions that the Copyright Office can grant every three years in its "triennial rulemaking" process. The permanent exception to the prohibition on circumventing TPMs for security testing is quite limited – in part because researchers are still required to get prior permission from the software owner. The temporary exemptions go beyond the permanent exemptions. In Oct. 2015 the Copyright Office granted a very helpful exemption to Sec. 1201 for good faith security testing that circumvents TPMs without permission. However, this temporary exemption will expire at the end of the three-year exemption window. In the past, once a temporary exemption expires, advocates must start from scratch in re-applying for another temporary exemption. The temporary exemption is set to expire Oct. 2018, and the renewal process will ramp up in the fall of this year. Copyright Office study and Rapid7's recommendations The Copyright Office announced a public study of Sec. 1201 in Dec. 2015. The Copyright Office undertook this public study to weigh legislative and procedural reforms to Sec. 1201, including the permanent exemptions and the three-year rulemaking process. The Copyright Office solicited two sets of public comments and held a roundtable discussion to obtain feedback and recommendations for the study. At each stage, Rapid7 provided recommendations on reforms to empower good faith security researchers while preserving copyright protection against infringement – though, it should be noted, there were several commenters opposed to reforms for researchers on IP protection grounds. Broadly speaking, the conclusions reached in the Copyright Office's study are quite positive for researchers and largely tracked the recommendations of Rapid7 and other proponents of security research. Here are four key highlights: Authorization requirement: As noted above, the permanent exemption for security testing under Sec. 1201(j) is limited because it still requires researchers to obtain authorization to circumvent TPMs. Rapid7's recommendation is to remove this requirement entirely because good faith security research does not infringe copyright, yet an authorization requirement compromises independence and speed of research. The Copyright Office's study recommended [at pg. 76] that Congress make this requirement more flexible or remove it entirely. This is arguably the study's most important recommendation for researchers. Multi-factor test: The permanent exemption for security testing under Sec. 1201(j) also partially conditions liability protection on researchers when the results are used "solely" to promote the security of the computer owner, and when the results are not used in a manner that violates copyright or any other law. Rapid7's recommendations are to remove "solely" (since research can be performed for the security of users or the public at large, not just the computer owner), and not to penalize researchers if their research results are used by unaffiliated third parties to infringe copyright or violate laws. The Copyright Office's study recommended [at pg. 79] that Congress remove the "solely" language, and either clarify or remove the provision penalizing researchers when research results are used by third parties to violate laws or infringe copyright. Compliance with all other laws: The permanent exemption for security testing only applies if the research does not violate any other law. Rapid7's recommendation is to remove this caveat, since research may implicate obscure or wholly unrelated federal/state/local regulations, those other laws have their own enforcement mechanisms to pursue violators, and removing liability protection under Sec. 1201 would only have the effect of compounding the penalties. Unfortunately, the Copyright Office took a different approach, tersely noting [at pg. 80] that it is unclear whether the requirement to comply with all other laws impedes legitimate security research. The Copyright Office stated they welcome further discussion during the next triennial rulemaking, and Rapid7 may revisit this issue then. Streamlined renewal for temporary exemptions: As noted above, temporary exemptions expire after three years. In the past, proponents must start from scratch to renew the temporary exemption – a process that involves structured petitions, multiple rounds of comments to the Copyright Office, and countering the arguments of opponents to the exemption. For researchers that want to renew the temporary security testing exemption, but that lack resources and regulatory expertise, this is a burdensome process. Rapid7's recommendation is for the Copyright Office to presume renewal of previously granted temporary exemptions unless there is a material change in circumstances that no longer justifies granting the exemption. In its study, the Copyright Office committed [at pg. 143] to streamlining the paperwork required to renew already granted temporary exemptions. Specifically, the Copyright Office will ask parties requesting renewal to submit a short declaration of the continuing need for an exemption, and whether there has been any material change in circumstances voiding the need for the exemption, and then the Copyright Office will consider renewal based on the evidentiary record and comments from the rulemaking in which the temporary exemption was originally granted. Opponents of renewing exemptions, however, must start from scratch in submitting evidence that a temporary exemption harms the exercise of copyright. Conclusion—what's next? In the world of policy, change typically occurs over time in small (often hard-won) increments before becoming enshrined in law. The Copyright Office's study is one such increment. For the most part, the study is making recommendations to Congress, and it will ultimately be up to Congress (which has its own politics, processes, and advocacy opportunities) to adopt or decline these recommendations. The Copyright Office's study comes at a time that House Judiciary Committee is broadly reviewing copyright law with an eye towards possible updates. However, copyright is a complex and far-reaching field, and it is unclear when Congress will actually take action. Nonetheless, the Copyright Office's opinion on these issues will carry significant weight in Congress' deliberations, so it would have been a heavy blow if the Copyright Office's study had instead called for tighter restrictions on security research. Importantly, the Copyright Office's new, streamlined process for renewing already granted temporary exemptions will take effect without Congress' intervention. The streamlined process will be in place for the next "triennial rulemaking," which begins in late 2017 and concludes in 2018, and which will consider whether to renew the temporary exemption for security research. This is a positive, concrete development that will reduce the administrative burden of applying for renewal and increase the likelihood of continued protections for researchers. The Copyright Office's study noted that "Independent security test[ing] appears to be an important component of current cybersecurity practices". This recognition and subsequent policy shifts on the part of the Copyright Office are very encouraging. Rapid7 believes that removing legal barriers to good faith independent research will ultimately strengthen cybersecurity and innovation, and we hope to soon see legislative reforms that better balance copyright protection with legitimate security testing.

Senator Ed Markey (D-MA) is poised to introduce legislation to develop a voluntary cybersecurity standards program for the Internet of Things (IoT). The legislation, called the Cyber Shield Act, would enable IoT products that comply with the standards to display a label indicating a strong level of security to consumers – like an Energy Star rating for IoT. Rapid7 supports this legislation and believes greater transparency in the marketplace will enhance cybersecurity and protect consumers.The burgeoning IoT marketplace holds a great deal of promise for consumers. But as the Mirai botnet made starkly clear, many IoT devices – especially at the inexpensive range of the market – are as secure as leaky boats. Rapid7's Deral Heiland and Tod Beardsley, among many others, have written extensively about IoT's security problems from a technical perspective.Policymakers have recognized the issue as well and are taking action. Numerous federal agencies (such as FDA and NHTSA) have set forth guidance on IoT security as it relates to their area of authority, and others (such as NIST) have long pushed for consistent company adoption of baseline security frameworks. In addition to these important efforts, we are encouraged that Congress is also actively exploring market-based means to bring information about the security of IoT products to the attention of consumers.Sen. Markey's Cyber Shield Act would require the Dept. of Commerce to convene public and private sector experts to establish security benchmarks for select connected products. The working group would be encouraged to incorporate existing standards rather than create new ones, and the benchmark would change over time to keep pace with evolving threats and expectations. The process, like that which produced the NIST Cybersecurity Framework, would be open for public review and comment. Manufacturers may voluntarily display "Cyber Shield" labels to IoT products that meet the security benchmarks (as certified by an accredited testing entity).Rapid7 supports voluntary initiatives to raise awareness to consumers about product security, like that proposed in the Cyber Shield Act. Consumers are often not able to easily determine the level of security in products they purchase, so an accessible and reliable system is needed to help inform purchase decisions. As consumers evaluate and value IoT security more, competing manufacturers will respond by prioritizing secure design, risk management practices, and security processes. Consumers and the IoT industry can both benefit from this approach.The legislation is not without its challenges, of course. To be effective, the security benchmarks envisioned by the bill must be clear and focused, rather than generally applicable to all connected devices. The program would need buy-in from security experts and responsible manufacturers, and consumers would need to learn how to spot and interpret Cyber Shield labels. But overall, Rapid7 believes Sen. Markey's Cyber Shield legislation could encourage greater transparency and security for IoT. Strengthening the IoT ecosystem will require a multi-pronged approach from policymakers, and we think lawmakers should consider incorporating this concept as part of the plan.

In April 2017, President Trump issued an executive order directing a review of all trade agreements. This process is now underway: The United States Trade Representative (USTR) – the nation's lead trade agreement negotiator – formally requested public input on objectives for the renegotiation of the North American Free Trade Agreement (NAFTA). NAFTA is a trade agreement between the US, Canada, and Mexico, that covers a huge range of topics, from agriculture to healthcare. Rapid7 submitted comments in response, focusing on 1) preventing data localization, 2) alignment of cybersecurity risk management frameworks, 3) protecting strong encryption, and 4) protecting independent security research. Rapid7's full comments on the renegotiation of NAFTA are available here. 1) Preserving global free flow of information – preventing data localization Digital goods and services are increasingly critical to the US economy. By leveraging cloud computing, digital commerce offers significant opportunities to scale globally for individuals and companies of all sizes – not just large companies or tech companies, but for any transnational company that stores customer data. However, regulations abroad that disrupt the free flow of information, such as "data localization" (requirements that data be stored in a particular jurisdiction), impede both trade and innovation. Data localization erodes the capabilities and cost savings that cloud computing can provide, while adding the significant costs and technical burdens of segregating data collected from particular countries, maintaining servers locally in those countries, and navigating complex geography-based laws. The resulting fragmentation also undermines the fundamental concept of a unified and open global internet. Rapid7's comments [pages 2-3] recommended that NAFTA should 1) Prevent compulsory localization of data, and 2) Include an express presumption that governments would minimize disruptions to the flow of commercial data across borders. 2) Promote international alignment of cybersecurity risk management frameworks When NAFTA was originally negotiated, cybersecurity was not the central concern that it is today. Cybersecurity is presently a global affair, and the consequences of malicious cyberattack or accidental breach are not constrained by national borders. Flexible, comprehensive security standards are important for organizations seeking to protect their systems and data. International interoperability and alignment of cybersecurity practices would benefit companies by enabling them to better assess global risks, make more informed decisions about security, hold international partners and service providers to a consistent standard, and ultimately better protect global customers and constituents. Stronger security abroad will also help limit the spread of malware contagion to the US. We support the approach taken by the National Institute of Standards and Technology (NIST) in developing the Cybersecurity Framework for Critical Infrastructure. The process was open, transparent, and carefully considered the input of experts from the public and private sector. The NIST Cybersecurity Framework is now seeing impressive adoption among a wide range of organizations, companies, and government agencies – including some critical infrastructure operators in Canada and Mexico. Rapid's comments [pages 3-4] recommended that NAFTA should 1) recognize the importance of international alignment of cybersecurity standards, and 2) require the Parties to develop a flexible, comprehensive cybersecurity risk management framework through a transparent and open process. 3) Protect strong encryption Reducing opportunities for attackers and identifying security vulnerabilities are core to cybersecurity. The use of encryption and security testing are key practices in accomplishing these tasks. International regulations that require weakening of encryption or prevent independent security testing ultimately undermine cybersecurity. Encryption is a fundamental means of protecting data from unauthorized access or use, and Rapid7 believes companies and innovators should be able to use the encryption protocols that best protect their customers and fit their service model – whether that protocol is end-to-end encryption or some other system. Market access rules requiring weakened encryption would create technical barriers to trade and put products with weakened encryption at a competitive disadvantage with uncompromised products. Requirements to weaken encryption would impose significant security risks on US companies by creating diverse new attack surfaces for bad actors, including cybercriminals and unfriendly international governments. Rapid7's comments [page 5] recommended that NAFTA forbid Parties from conditioning market access for cryptography in commercial applications on the transfer of decryption keys or alteration of the encryption design specifications. 4) Protect independent security research Good faith security researchers access software and computers to identify and assess security vulnerabilities. To perform security testing effectively, researchers often need to circumvent technological protection measures (TPMs) – such as encryption, login requirements, region coding, user agents, etc. – controlling access to software (a copyrighted work). However, this activity can be chilled by Sec. 1201 of the Digital Millennium Copyright Act (DMCA) of 1998, which forbids circumvention of TPMs without the authorization of the copyright holder. Good faith security researchers do not seek to infringe copyright, or to interfere with a rightsholder's normal exploitation of protected works. The US Copyright Office recently affirmed that security research is fair use and granted this activity, through its triennial rulemaking process, a temporary exemption from the DMCA's requirement to obtain authorization from the rightsholder before circumventing a TPM to safely conduct security testing on lawfully acquired (i.e., not stolen or "borrowed") consumer products. Some previous trade agreements have closely mirrored the Digital Millennium Copyright Act's (DMCA) prohibitions on unauthorized circumvention of TPMs in copyrighted works. This approach replicates internationally the overbroad restrictions on independent security testing that the US is now scaling back. Newly negotiated trade agreements should aim to strike a more modern and evenhanded balance between copyright protection and good faith cybersecurity research. Rapid7's comments [page 6] recommended that any anti-circumvention provisions of NAFTA should be accompanied by provisions exempting security testing of lawfully acquired copyrighted works. Better trade agreements for the Digital Age? Data storage and cybersecurity have undergone considerable evolution since NAFTA was negotiated more than a quarter century ago. To the extent that renegotiation may better address trade issues related to digital goods and services, we view the modernization of NAFTA and other agreements as potentially positive. The comments Rapid7 submitted regarding NAFTA will likely apply to other international trade agreements as they come up for renegotiation. We hope the renegotiations result in a broadly equitable and beneficial trade regime that reflects the new realities of the digital economy.

Yesterday President Trump issued an Executive Order on cybersecurity: “Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure.” The Executive Order (EO) appears broadly positive and well thought out, though it is just the beginning of a long process and not a sea change in itself. The EO directs agencies to come up with plans for securing and modernizing their networks; develop international cyber norms; work out a deterrence strategy against hacking; and reduce the threat of botnets – all constructive, overdue goals. Below are an overview, a highlight reel, and some additional takeaway thoughts. Cybersecurity Executive Order Overview Executive orders are issued only by the President, direct the conduct of executive branch agencies (not the private sector, legislature, or judiciary), and have the force of law. All public (not classified) EOs are published here. This cyber EO is the first major move the Trump White House (as distinct from other federal agencies) has made publicly on cybersecurity. The cyber Executive Order takes action on three fronts: Federal network security. Directs agencies to take a risk management approach, adopt the NIST Framework, and favor shared services and consolidated network architectures (including for cloud and cybersecurity services). Protecting critical infrastructure. Directs agencies to work with the private sector to protect critical infrastructure, incentivize more transparency on critical infrastructure cybersecurity, improve resiliency of communication infrastructure, and reduce the threat of botnets. National preparedness and workforce development. Directs agencies to assess strategic options for deterring and defending against adversaries. Directs agencies to report their international cybersecurity priorities, and to promote international norms on cybersecurity. Cybersecurity Executive Order Highlights Federal network cybersecurity: The US will now manage cyber risks as an executive branch enterprise. The President is holding cabinet and agency heads accountable for implementing risk management measures commensurate with risks and magnitude of harm. [Sec. 1(c)(i)] Agencies are directed to immediately use the NIST Framework for Improving Critical Infrastructure Cybersecurity (NIST Framework) to manage their cyber risk. [Sec. 1(c)(ii)] DHS and OMB must report to the President, within 120 days, a plan to secure federal networks, address budgetary needs for cybersecurity, and reconcile all policies and standards with the NIST Framework. [Sec. 1(c)(iv)] Agencies must now show preference for shared IT services (including cloud and cybersecurity services) in IT procurement. [Sec. 1(c)(vi)(A)] This effort will be coordinated by the American Technology Council. [Sec. 1(c)(vi)(B)] The White House, in coordination with DHS and other agencies, must submit a report to the President, within 60 days, on modernizing federal IT, including transitioning all agencies to consolidated network architectures and shared IT services – with specific mention of cybersecurity services. [Sec. 1(c)(vi)(B)-(C)] Defense and intel agencies must submit a similar report for national security systems within 150 days. [Sec. 1(c)(vii)] Critical infrastructure cybersecurity: Critical infrastructure includes power plants, oil and gas, financial system, other systems that would risk national security if damaged. The EO states that it is the government's policy to use its authorities and capabilities to support the cybersecurity risk management of critical infrastructure. [Sec. 2(a)] The EO directs DHS, DoD, and other agencies to assess authorities and opportunities to coordinate with the private sector to defend critical infrastructure. [Sec. 2(b)] DHS and DoC must submit a report to the President, within 90 days, on promoting market transparency of cyber risk management practices by critical infrastructure operators, especially those that are publicly traded. [Sec. 2(c)] DoC and DHS shall work with industry to promote voluntary actions to improve the resiliency of internet and communications infrastructure and “dramatically" reduce the threat of botnet attacks. [Sec. 2(d)] Agencies shall assess cybersecurity risks and mitigation capabilities related to the electrical sector and the defense industrial base (including supply chain). [Sec. 2(e)-(f)] National preparedness and workforce: The EO reiterates the US government's commitment to an open, secure Internet that fosters innovation and communication while respecting privacy and guarding against disruption. [Sec. 3(a)] Cabinet members must submit a report to the President, within 90 days, on options for deterring adversaries and protecting Americans from cyber threats. [Sec. 3(b)] Cabinet members must report to the President, within 45 days, on international cybersecurity priorities, including investigation, attribution, threat info sharing, response, etc. The agencies must report to the President, within 90 days, on a strategy for international cooperation in cybersecurity. [Sec. 3(c)] Agencies must report to the President, within 120 days, how to grow and sustain a workforce skilled in cybersecurity and related fields. [Sec. 3(d)(i)] The Director of National Intelligence must report to the President, within 60 days, on workforce development practices of foreign peers to compare long-term competitiveness in cybersecurity. [Sec. 3(d)(ii)] Agencies must report to the President, within 150 days, on US efforts to maintain advantage in national-security-related cyber capabilities. [Sec. 3(d)(iii)] The Executive Order is just the start As you can see, the EO initially requires a lot of multi-agency reports, which we can expect to surface in coming months, and which can then be used to craft official policy. There are opportunities for the private sector to provide input to the agencies as they develop those reports, though the 2-4 month timelines are pretty tight for such complex topics. But the reports are just the beginning of long processes to accomplish the goals set forth in the EO - it will take a lot longer than 60 days, for example, to fully flesh out and implement a plan to modernize federal IT. The long haul is beginning, and we won't know how transformative or effective this process will be for some time.

Rapid7 has long been a champion of coordinated vulnerability disclosure and handling processes as they play a critical role in both strengthening risk management practices and protecting security researchers. We not only use coordinated disclosure processes in our own vulnerability disclosure and receiving activities, but also advocate for broader adoption in industry and in government policies.Building on this, we recently joined forces with other members of the security community to urge NIST and NTIA (both part of the U.S. Dept. of Commerce) to promote adoption of coordinated vulnerability disclosure processes. In each of these two most recent filings, Rapid7 was joined by a coalition of approximately two dozen (!!) like-minded cybersecurity firms, civil society organizations, and individual researchers.Joint comments to the National Institute of Standards and Technology (NIST) Cybersecurity Framework, available here.Joint comments to the National Telecommunications and Information Administration's (NTIA) "Green Paper" on the Internet of Things, available here.The goal of the comments is for these agencies to incorporate coordinated vulnerability disclosure and handling processes into official policy positions on IoT security (in the case of NTIA) and cybersecurity guidance to other organizations (in the case of NIST). We hope this ultimately translates to broader adoption of these processes by both companies and government agencies.What are "vuln disclosure processes" and why are they important?Okay, first off, I really hope infosec vernacular evolves to come up with a better term than "coordinated vulnerability disclosure and handling processes" because boy that's a mouthful. But it appears to be the generally agreed-upon term.A coordinated vulnerability disclosure and handling process is basically an organization's plan for dealing with security vulnerabilities disclosed from outside the organization. They are formal internal mechanisms for receiving, assessing, and mitigating security vulnerabilities submitted by external sources, such as independent researchers, and communicating the outcome to the vulnerability reporter and affected parties. These processes are easy to establish (relative to many other security measures) and may be tailored for an organizations' unique needs and resources. Coordinated vulnerability disclosure and handling processes are not necessarily "bug bounty programs" and may or may not offer incentives, or a guarantee of protection against liability, to vulnerability reporters.Why are these processes important? The quantity, diversity, and complexity of vulnerabilities will prevent many organizations from detecting all vulnerabilities without independent expertise or manpower. When companies are contacted about vulnerabilities in their products or IT from unsolicited third parties, having a plan in place to get the information to the right people will lead to a quicker resolution. Security researchers disclosing vulnerabilities are also better protected when companies clarify a process for receiving, analyzing, and responding to the disclosures – being prepared helps avoid misunderstandings or fear that can lead to legal threats or conflicts.To catch vulnerabilities they might otherwise overlook, businesses and government agencies are increasingly implementing vulnerability disclosure and handling processes, but widespread adoption is not yet the norm. NIST Framework commentsThe NIST Framework is a voluntary guidance document for organizations for managing cybersecurity risks. The Framework has seen growing adoption and recognition, and is an increasingly important resource that helps shape cybersecurity implementation in the public and private sectors. NIST proposed revisions to the Framework and solicited comments to the revisions. In our joint comments, the coalition urged NIST to expressly incorporate vulnerability disclosure processes into the Framework. The Framework already included "external participation" components and metrics (likely directed at formal cyber threat intel sharing arrangements), but they are unclear and don't explicitly refer to vulnerability disclosure processes. Specifically, our comments recommended that the Framework Core include a new subcategory dedicated to vulnerability disclosure processes, and to build the processes into existing subcategories on risk assessment and third party awareness. Our comments also recommended revising the "external participation" metric of the Framework Tiers to lay out a basic maturity model for vulnerability disclosure processes.NTIA Internet of Things "Green Paper" commentsNTIA issued a “Green Paper” in late 2016 to detail its overall policies with regard to the Internet of Things, and then they solicited feedback and comments on that draft. Although the Dept. of Commerce has demonstrated its support for vulnerability disclosure and handling processes, there was little discussion about this issue in the Green Paper. The Green Paper is important because it will set the general policy agenda and priorities for the Dept. of Commerce on the Internet of Things (IoT).In our joint comments, the coalition urged NTIA to include more comprehensive discussion vulnerability disclosure and handling processes for IoT. This will help clarify and emphasize the role of vulnerability disclosure in the Dept. of Commerce's policies on IoT security going forward.The comments also urged NTIA to commit to actively encouraging IoT vendors to adopt vulnerability disclosure and handling processes. The Green Paper mentioned NTIA's ongoing "multistakeholder process" on vulnerability disclosure guidelines, which Rapid7 participates in, but the Green Paper did not discuss any upcoming plans for promoting adoption of vulnerability disclosure and handling processes. Our comments recommended that NTIA promote adoption among companies and government agencies in IoT-related sectors, as well as work to incorporate the processes into security guidance documents.More comingRapid7 is dedicated to strengthening cybersecurity for organizations, protecting consumers, and empowering the independent security research community to safely disclose vulnerabilities they've discovered. All these goals come together on the issue of coordinated vulnerability disclosure processes. As we increasingly depend on complex and flawed software and systems, we must pave the way for greater community participation in security. Facilitating communication between technology providers and operators and independent researchers is an important step toward greater collaboration aimed at keeping users safe.Rapid7 is thrilled to be working with so many companies, groups, and individuals to advance vulnerability disclosure and handling processes. As government agencies consider how cybersecurity fits into their missions, and how to advise the public and private sectors on what to do to best protect themselves, we expect more opportunities to come.You can learn more about our policy engagement efforts on Rapid7's public policy page.

What follows are some first impressions on the contents of the WikiLeaks Vault7 dump. I won't be addressing the legal or ethical concerns about posting classified data that can endanger the missions and goals of American intelligence organizations. I also won't be talking about whether or not the CIA should be involved in developing cyber capabilities in the first place as we have previously written about our views on this topic. But, I will talk about the technical content of the documents posted today, which all appear to come from a shared, cross-team internal Confluence wiki used by several CIA branches, groups, and teams.After spending the last few hours poring over the newly released material from WikiLeaks, Vault7, I'm left with the impression that the activities at the CIA with regards to developing cyber capabilities are... pretty normal.The material is primarily focused on the capabilities of "implants" -- applications that are installed on systems after they've been compromised -- and how they're used to exfiltrate data and maintain persistence after an initial compromise of a variety of devices from Samsung smart TVs to Apple iPhones to SOHO routers, and everything in between.The material also covers the command and control infrastructure that the CIA maintains to remotely use these implants; primarily, the details are concerned with building and testing the various components that makes up this network.Finally, there are the projects that are focused on exploits. The exploits described are either developed in-house, or acquired from external partners. Most of the internally developed exploits are designed to escalate privileges once access is secured, while most of the remote capabilities were acquired from other intelligence organizations and contractors. The CIA does appear to prefer to develop and use exploits that have a local, physical access component.While there is still a lot left to look at in detail, the overwhelming impression that I get from reading the material is that working on offensive tech at the CIA is pretty similar to working on any software project at any tech company. More to the point, the CIA activities detailed here are eerily similar to working on Metasploit at Rapid7. Take, for example, this post about the Meterpreter Mettle project from 2015 (which was written about the same time as these documents). Tell me that Mettle doesn't read like any one of the technical overviews in Vault7. As we spend more time digging through the Vault7 material, and if more material is released over time, I expect we'll be less and less surprised. So far, these documents show that the CIA branches and subgroups named in the documents are behaving pretty much exactly as one might expect of any software development shop. Yes, they happen to be developing exploit code. But, as we all know, that particular capability, in and of itself, isn't novel, illegal, or evil. Rapid7, along with many other security research organizations, both public and private, do it every day for normal and legitimate security purposes.Until I see something that's strikingly unusual, I'm having a hard time staying worked up over Vault7.

Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year, we're highlighting some of the “gifts” we want to give back to the community. And while these gifts may not come wrapped with a bow, we hope you enjoy them. On the seventh day of Haxmas, the Cyber gave to me: a list of seven Rapid7 comments to government policy proposals! Oh, tis a magical season. It was an active 2016 for Rapid7's policy team. When government agencies and commissions proposed rules or guidelines affecting security, we often submitted formal "comments" advocating for sound cybersecurity policies and greater protection of security researchers. These comments are typically a cross-team effort, reflecting the input of our policy, technical, industry experts, and submitted with the goal of helping government better protect users and researchers and advance a strong cybersecurity ecosystem. Below is an overview of the comments we submitted over the past year. This list does not encompass the entirety of our engagement with government bodies, only the formal written comments we issued in 2016. Without further ado: 1. Comments to the National Institute for Standards and Technology (NIST), Feb. 23: NIST asked for public feedback on its Cybersecurity Framework for Improving Critical Infrastructure Cybersecurity. The Framework is a great starting point for developing risk-based cybersecurity programs, and Rapid7's comments expressed support for the Framework. Our comments also urged updates to better account for user-based attacks and ransomware, to include vulnerability disclosure and handling policies, and to expand the Framework beyond critical infrastructure. We also urged NIST to encourage greater use of multi-factor authrntication and more productive information sharing. Our comments are available here [PDF]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-comments-to-nist-fr amework-022316.pdf 2. Comments to the Copyright Office, Mar. 3: The Copyright Office asked for input on its (forthcoming) study of Section 1201 of the DMCA. Teaming up with Bugcrowd and HackerOne, Rapid7 submitted comments that detailed how Section 1201 creates liability for good faith security researchers without protecting copyright, and suggested specific reforms to improve the Copyright Office's process of creating exemptions to Section 1201. Our comments are available here [PDF]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-bugcrowd--hackerone -joint-comments-to-us-copyright-office-s… 3. Comments to the Food and Drug Administration (FDA), Apr. 25: The FDA requested comments for its postmarket guidance for cybersecurity of medical devices. Rapid7 submitted comments praising the FDA's holistic view of the cybersecurity lifecycle, use of the NIST Framework, and recommendation that companies adopt vulnerability disclosure policies. Rapid7's comments urged FDA guidance to include more objective risk assessment and more robust security update guidelines. Our comments are available here [PDF]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-comments-to-fda-dra ft-guidance-for-postmarket-management-of… 4. Comments to the Dept. of Commerce's National Telecommunications and Information Administration (NTIA), Jun. 1: NTIA asked for public comments for its (forthcoming) "green paper" examining a wide range of policy issues related to the Internet of Things. Rapid7's comprehensive comments detailed – among other things – specific technical and policy challenges for IoT security, including insufficient update practices, unclear device ownership, opaque supply chains, the need for security researchers, and the role of strong encryption. Our comments are available here [PDF]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-comments-to-ntia-in ternet-of-things-rfc-060116.pdf 5. Comments to the President's Commission on Enhancing National Security (CENC), Sep. 9: The CENC solicited comments as it drafted its comprehensive report on steps the government can take to improve cybersecurity in the next few years. Rapid7's comments urged the government to focus on known vulnerabilities in critical infrastructure, protect strong encryption from mandates to weaken it, leverage independent security researchers as a workforce, encourage adoption of vulnerability disclosure and handling policies, promote multi-factor authentication, and support formal rules for government disclosure of vulnerabilities. Our comments are available here [PDF]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-comments-to-cenc-rf i-090916.pdf 6. Comments to the Copyright Office, Oct. 28: The Copyright Office asked for additional comments on its (forthcoming) study of Section 1201 reforms. This round of comments focused on recommending specific statutory changes to the DMCA to better protect researchers from liability for good faith security research that does not infringe on copyright. Rapid7 submitted these comments jointly with Bugcrowd, HackerOne, and Luta Security. The comments are available here [PDF]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-bugcrowd-hackerone- luta-security-joint-comments-to-copyrigh… 7. Comments to the National Highway Traffic Safety Administration (NHTSA), Nov. 30: NHTSA asked for comments on its voluntary best practices for vehicle cybersecurity. Rapid7's comments recommended that the best practices prioritize security updating, encourage automakers to be transparent about cybersecurity features, and tie vulnerability disclosure and reporting policies to standards that facilitate positive interaction between researchers and vendors. Our comments are available here [PDF]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-comments-to-nhtsa-c ybersecurity-best-practices-for-modern-v… 2017 is shaping up to be an exciting year for cybersecurity policy. The past year made cybersecurity issues even more mainstream, and comments on proposed rules laid a lot of intellectual groundwork for helpful changes that can bolster security and safety. We are looking forward to keeping up the drumbeat for the security community next year. Happy Holidays, and best wishes for a good 2017 to you!

Security professionals today face great challenges protecting their assets from breaches by hackers and malware. A good vulnerability management solution could help mitigate these challenges, but vulnerability management solutions often produce huge volumes of data from scanning and require lots of time spent in differentiating between information and noise.Rapid7 Nexpose helps professionals identify the most critical assets that can be exploited. With this information the security professional can take necessary steps to mitigate the risk.A vulnerability has a risk score of 0 – 1000, calculated using Rapid7's security intelligence. An asset's risk score is calculated by adding the risk score of all its vulnerabilities. Essentially, a higher risk score on an asset implies that the asset is more vulnerable to attack. Unlike a CVSS score which does not consider the whole context of the identified vulnerability, the Real Risk Score, as we call it, adjusts a CVSS value by analyzing each risk element separately incorporating temporal and governance parameters.Temporal parameters look at the age of a vulnerability, as well as how many exploits and/or malware kits use the vulnerability. Temporal score increases over time, increasing risk score.Governance parameters follow asset tagging in Nexpose which lets you tag assets as more critical or less critical than others, raising or lowering risk scores accordingly.The integration of ePO with Nexpose allows the security professionals to leverage Rapid7 Security Intelligence to identify and mitigate real risks that have a higher potential negative impact on the environment and take the right steps to mitigate those risks.Setting Up Risk Score IntegrationTo integrate ePO with Nexpose a site must be configured in Nexpose to hold all of the assets that are imported from ePO during the integration process.The following steps show how to set up an ePO integration with Nexpose and how to push risk scores from Nexpose into ePO:1. Go to the Administration page on Nexpose2. Click on Create Discovery Connection3. From the Connection Type, choose Intel Security ePolicy Orchestrator4. Enter all the information needed to connect to ePO server.5. Check the option “Consume assets” and select a site in which all the existing assets in ePO will go.6. Check “Push risk scores” to have Nexpose risk scores pushed to ePO.7. Click the Test Credentials button to ensure all the entered information is correct, if all the details are valid the following message will appear.8. Click on Save to save the connection and start the integration process between ePO and Nexpose.Shortly after clicking save, the site selected in the configuration will start importing assets from ePO.After the assets have been imported, trigger a scan on the site with any scan template other than the discovery scan template. Once the scan is completed, risk scores identified by Nexpose will now be present in ePO.There is a convenient built-in dashboard present in ePO that shows the top 10 riskiest assets in ePO as identified by Nexpose. The following screenshot shows the dashboard:Now Rapid7 Nexpose has provided the risk exposure information to all ePO partners to see the real risk associated with these assets. With this critical information the respective administrators can work together on the next steps to mitigate the risk identified. Some common operations include quarantining systems, pushing updates to assets and setting up compliance policies.Already a McAfee customer? Be sure to download a trial license of Nexpose and try the integration today!

October was my favorite month even before I learned it is also National Cybersecurity Awareness Month (NCSAM) in the US and EU. So much the better – it is more difficult to be aware of cybersecurity in the dead of winter or the blaze of summer. But the seasonal competition with Pumpkin Spice Awareness is fierce. To do our part each National Cybersecurity Awareness Month, Rapid7 publishes content that aims to inform readers about a particular theme, such as the role of executive leadership, and primers to protect users against common threats. This year, Rapid7 will use NCSAM to celebrate security research – launching blog posts and video content showcasing research and raising issues important to researchers. Rapid7 strongly supports independent research to identify and assess security vulnerabilities with the goal of correcting flaws. Such research strengthens cybersecurity and helps protect consumers by calling attention to flaws that software vendors may have ignored or missed. There are just too many vulnerabilities in complex code to expect vendors' internal security teams to catch everything. Independent researchers are antibodies in our immune system.This NCSAM is an extra special one for security researchers for a couple reasons. First, new legal protections for security research kick in under the DMCA later this month. Second, October 2016 is the 30th anniversary of a problematic law that chills beneficial security research – the CFAA. DMCA exception – copyright gets out of the way (for a while)This October 29th, a new legal protection for researchers will activate: an exemption from liability under Section 1201 of the Digital Millennium Copyright Act (DMCA). The result of a long regulatory battle, this helpful exemption will only last two years, after which we can apply for renewal.Sec. 1201 of the DMCA prohibits circumventing a technological protection measure (TPM) to copyrighted works (including software). [17 USC 1201(a)(1)(A)] The TPMs can be anything that controls access to the software, such as weak encryption. Violators can incur civil and criminal penalties. Sec. 1201 can hinder security research by forbidding researchers from unlocking licensed software to probe for vulnerabilities. This problem prompted security researchers – including Rapid7 – to push the Copyright Office to create a shield for research from liability under Sec. 1201. The Copyright Office ultimately did so last October, issuing a rule that limits liability for circumventing TPMs on lawfully acquired (not stolen) consumer devices, medical devices, or land vehicles solely for the purpose of good faith security testing. The Copyright Office delayed activation of the exception for a year, so it takes effect this month. Rapid7 analyzed the exception in more detail here, and is pushing the Copyright Office for greater researcher protections beyond the exception.The exception is a positive step for researchers, and another signal that policymakers are becoming more aware of the value that independent research can drive for cybersecurity and consumers. However, there are other laws – without clear exceptions – that create legal problems for good faith researchers. Happy 30th, CFAA – time to grow upThe Computer Fraud and Abuse Act (CFAA) was enacted on October 16th, 1986 – 30 years ago. The internet was in its infancy in 1986, and platforms like social networking or the Internet of Things simply did not exist. Today, the CFAA is out of step with how technology is used. The CFAA's wide-ranging crimes can sweep in both ordinary internet activity and beneficial research. For example, as written, the CFAA threatens criminal and civil penalties for violations of the website's terms of service, a licensing agreement, or a workplace computer use agreement. [18 USC 1030(a)(2)(C)] People violate these agreements all the time – if they lie about their name on a social network, or they run unapproved programs on their work computer, or they violate terms of service while conducting security research to test whether a service has accidentally made sensitive information available on the open internet.Another example: the CFAA threatens criminal and civil penalties for causing any impairment to a computer or information. [18 USC 1030(a)(5)] No harm is required. Any unauthorized change to data, no matter how innocuous, is prohibited. Even slowing down a website by scanning it with commercially available vulnerability scanning tools can violate this law. Since 1986, virtually no legislation has been introduced to meaningfully address the CFAA's overbreadth – with Aaron's Law, sponsored by Rep. Lofgren and Sen. Wyden, being the only notable exception. Even courts are sharply split on how broad the CFAA should be, creating uncertainty for prosecutors, businesses, researchers, and the public. So for the CFAA's 30th anniversary, Rapid7 renews our call for sensible reform. Although we recognize the real need for computer crime laws to deter and prosecute malicious acts, Rapid7 believes balancing greater flexibility for researchers and innovators with law enforcement needs is increasingly important. As the world becomes more digital, computer users, innovators, and researchers will need greater freedom to use computers in creative or unexpected ways.More coming for NCSAMRapid7 hopes National Cybersecurity Awareness Month will be used to enhance understanding of what independent security research is, how it benefits the digital ecosystem, and the challenges researchers face. To celebrate research over the coming weeks, Rapid7 will – among other things – make new vulnerability disclosures, publish blog posts showcasing some of the best research of the year, and release videos that detail policy problems affecting research. Stay tuned, and a cheery NCSAM to you.

Yesterday, the Michigan Senate Judiciary Committee passed a bill – S.B. 0927 – that forbids some forms of vehicle hacking, but includes specific protections for cybersecurity researchers. Rapid7 supports these protections. The bill is not law yet – it has only cleared a Committee in the Senate, but it looks poised to keep advancing in the state legislature. Our background and analysis of the bill is below.In summary:The amended bill offers legal protections for independent research and repair of vehicle computers. These protections do not exist in current Michigan state law.The amended bill bans some forms of vehicle hacking that damage property or people, but we believe this was already largely prohibited under current Michigan state law.The bill attempts to make penalties for hacking more proportional, but this may not be effective.BackgroundEarlier this year, Michigan state Senator Mike Kowall introduced S.B. 0927 to prohibit accessing a motor vehicle's electronic system without authorization. The bill would have punished violations with a potential life sentence. As noted by press reports at the time, the bill's broad language made no distinction between malicious actors, researchers, or harmless access. The original bill is available here.After S.B. 0927 was introduced, Rapid7 worked with a coalition of cybersecurity researchers and companies to detail concerns that the bill would chill legitimate research. We argued that motorists are safer as a result of independent research efforts that are not necessarily authorized by vehicle manufacturers. For example, in Jul. 2015, researchers found serious security flaws in Jeep software, prompting a recall of 1.4 million vehicles. Blocking independent research to uncover vehicle software flaws would undermine cybersecurity and put motorists at greater risk.Over a four-month period, Rapid7 worked rather extensively with Sen. Kowall's office and Michigan state executive agencies to minimize the bill's damage to cybersecurity research. We applaud their willingness to consider our concerns and suggestions. The amended bill passed by the Michigan Senate Judiciary Committee, we believe, will help provide researchers with greater legal certainty to independently evaluate and improve vehicle cybersecurity in Michigan.The Researcher ProtectionsFirst, let's examine the bill's protections for researchers – Sec. 5(2)(B); pg. 6, lines 16-21. Explicit protection for cybersecurity researchers does not currently exist in Michigan state law, so we view this provision as a significant step forward.This provision says researchers do not violate the bill's ban on vehicle hacking if the purpose is to test, refine, or improve the vehicle – and not to damage critical infrastructure, other property, or injure other people. The research must also be performed under safe and controlled conditions. A court would need to interpret what qualifies as "safe and controlled" conditions – hacking a moving vehicle on a highway probably would not qualify, but we would argue that working in one's own garage likely sufficiently limits the risks to other people and property.The researcher protections do not depend on authorization from the vehicle manufacturer, dealer, or owner. However, because of the inherent safety risks of vehicles, Rapid7 would support a well-crafted requirement that research beyond passive signals monitoring must obtain authorization from the vehicle owner (as distinct from the manufacturer).The bill offers similar protections for licensed manufacturers, dealers, and mechanics [Sec. 5(2)(A); pg. 6, lines 10-15]. However, both current state law and the bill would not explicitly give vehicle owners (who are not mechanics, or are not conducting research) the right to access their own vehicle computers without manufacturer authorization. However, since Michigan state law does not clearly give owners this ability, the bill is not a step back here. Nonetheless, we would prefer the legislation make clear that it is not a crime for owners to independently access their own vehicle and device software.The Vehicle Hacking BanThe amended bill would explicitly prohibit unauthorized access to motor vehicle electronic systems to alter or use vehicle computers, but only if the purpose was to damage the vehicle, injure persons, or damage other property [Sec. 5(1)(c)-(d); pgs. 5-6, lines 23-8]. That is an important limit that should exclude, for example, passive observation of public vehicle signals or attempts to fix (as opposed to damage) a vehicle.Although the amended bill would introduce a new ban on certain types of vehicle hacking, our take is that this was already illegal under existing Michigan state law. Current Michigan law – at MCL 752.795 – prohibits unauthorized access to "a computer program, computer, computer system, or computer network." The current state definition of "computer" – at MCL 752.792 – is already sweeping enough to encompass vehicle computers and communications systems. Since the law already prohibits unauthorized hacking of vehicle computers, it's difficult to see why this legislation is actually necessary. Although the bill's definition of "motor vehicle electronic system" is too broad [Sec. 2(11); pgs. 3-4, lines 25-3], its redundancy with current state law makes this legislation less of an expansion than if there were no overlap.Penalty ChangesThe amended bill attempts to create some balance to sentencing under Michigan state computer crime law [Sec. 7(2)(A); pg. 8, line 11]. This provision essentially makes harmless violations of Sec. 5 (which includes the general ban on hacking, including vehicles) a misdemeanor, as opposed to a felony. Current state law – at MCL 752.797(2) – makes all Sec. 5 violations felonies, which is potentially harsh for innocuous offenses. We believe that penalties for unauthorized hacking should be proportionate to the crime, so building additional balance in the law is welcome.However, this provision is limited and contradictory. The Sec. 7 provision applies only to those who "did not, and did not intend to," acquire/alter/use a computer or data, and if the violation can be "cured without injury or damage." But to violate Sec. 5, the person must have intentionally accessed a computer to acquire/alter/use a computer or data. So the person did not violate Sec. 5 in the first place if the person did not do those things or did not do them intentionally. It's unclear under what scenario Sec. 7 would kick in and provide a more proportionate sentence – but at least this provision does not appear to cause any harm. We hope this provision can be strengthened and clarified as the bill moves through the Michigan state legislature.ConclusionOn balance, we think the amended bill is a major improvement on the original, though not perfect. The most important improvements we'd like to see are Clarifying the penalty limitation in Sec. 7;  Narrowing the definition of "motor vehicle electrical system" in Sec. 2; andLimiting criminal liability for owners that access software on vehicle computers they own.However, the clear protections for independent researchers are quite helpful, and Rapid7 supports them. To us, the researcher protections further demonstrate that lawmakers are recognizing the benefits of independent research to advance safety, security, and innovation. The attempt at creating proportional sentences is also sorely needed and welcome, if inelegantly executed.The amended bill is at a relatively early stage in the legislative process. It must still pass through the Michigan Senate and House. Nonetheless, it starts off on much more positive footing than it did originally. We intend to track the bill as it moves through the Michigan legislature and hope to see it improve further. In the meantime, we'd welcome feedback from the community.

Today, we're less than fifty days from the next U.S. presidential election, and over the next couple months, I fully expect to see a lot of speculation over the likelihood of someone "hacking the election." But what does that even mean? The U.S. election system is a massively complex tangle of technology, and, at first, second, and third glance, it appears to embody the absolute worst practices when it comes to information security. There are cleartext, Internet-based entry points to the voting system. There is an aging installed base of voting machines running proprietary, closed-source code, produced by many vendors. And there is a bizarrely distributed model of authority over the election, where no one actually has the power to enforce a common set of security standards. Sure, it seems bad. Nightmarish, really. But what are the actual risks here? If an adversary wanted to "hack" the "election," what could that adversary actually accomplish? Online Voting in the U.S. According to this PDF report from EPIC, the Verified Voting Foundation, and Common Cause, 32 states have some form of Internet-enabled voting. However, those systems are not the kind of easy, point-and-click kind of interface that most people think of when you say "Internet-enabled." They tend to be systems for distributing ballots that the voter needs to print out on paper (ugh), sign (often with a witness's countersignature), and then email or fax back to the state authority for counting. Systems like these throw up privacy concerns. On a purely technical level, email and fax do not offer any sort of encryption. Ballots cast this way are being passed around the public internet "in the clear," and if an attacker is able to compromise any point along the path of transmission, that attacker can intercept these completed ballots. So, not only does this system do away with any notion of a secret ballot, it does it in such a way that it ignores any modern understanding of cryptographic security. Clearly, this is a bummer for security professionals. We'd much rather see online voting systems with encryption built in. Web sites use HTTPS, an encrypted protocol, to avoid leaking important things like credit card numbers and passwords over public networks, so we'd like we see at least this level of security for something as critical as a voter's ballot. That said, actually attacking this system doesn't scale very well for an adversary. First, they would need to target remote, online voters for snooping and interception. These voters are a minority, since most voting in every state happens either in person, or with paper ballots sent in the regular postal mail. Once the vulnerable population is identified, the adversary would then need to either wait for the voters to cast their ballots in order to change those ballots in transit, or vote on behalf of the legitimate voter before she gets a chance to. Active cleartext attacks like this work pretty well against one person or one location, but they are difficult to pull off at the kind of scale needed to tip an election. Alternatively, the adversary could invent a population of phantom voters, register them to vote remotely, and stuff the ballot box with fake votes. Again, this isn't impossible, but it's also fairly high effort, since voter registration is already somewhat difficult for legitimate voters; automating it at scale just isn't possible in most counties in the U.S.. This leaves the servers that are responsible for collecting online ballots. The easiest thing to do here would be to kick them offline with a standard Denial-of-Service (DoS) attack, so all those emailed ballots would be dropped. This sort of attack would be pretty noticeable by the system maintainers, though, and I would expect people would switch back to paper mail pretty quickly. Remember, these systems aren't intended to be used on election day -- they merely collect absentee ballots, so there is going to be plenty of time to switch to the paper-based backup A total compromise of the ballot collection servers could enable attackers to alter or destroy votes in a much sneakier way, and an attack like this could potentially avoid detection until after the election is called. On the bright side, this kind of attack appears possible for only five of the Internet-enabled voting states. Only Alabama, Alaska, Arizona, North Dakota, and Missouri have an "Internet portal." None of these states appear to be battleground states according to FiveThirtyEight's latest projections. So, regardless of their security posture (which isn't known), attacking these portals isn't likely to net a lot of gain for attackers wishing to influence the Presidential election one way or the other. If Florida or Pennsylvania had one of these portals, I'd be a lot more worried. Hacking Voting Machines Another common theme of "election hacking" stories involves attacking the voting machine directly, in order to alter the votes cast on site. Now, on the one hand, no electronic voting machine is cyber-bulletproof. I have every expectation that these voting computers have some bugs, and some of those bugs weaken the security of the system. I'd love to see open source, auditable voting machine code. Voting is important, and the machines we trust to tabulate results should be trustworthy. On the other hand, if the adversary needs to physically visit voting machines in order to fiddle with results, then he'd need a whole lot of bodies in a whole lot of polling places in order to make a real dent in the results of an election. Don't get me wrong, wireless networking is getting ubiquitous, and high-gain antennae are a thing. But even with ideal placement and transmission power, the attacker is going to need to be within sight of a polling place in order to conduct practical attacks on a WiFi-enabled voting machine. So, while such an attack is remote, it's not sitting-in-another-country remote. More like parked-outside-the-polling-place remote. WiFi voting machines are a terrible idea, but they don't appear to be an existential threat to democracy. Ancillary Attacks: Voter Information So, rather than attacking ballot-issuing and ballot-counting systems directly, attackers have much more attractive targets available connected to the election. Voter records, for example, are tempting to cyber criminals, since they contain enough personally identifiable information (PII) to kick off identity theft and identity fraud attacks at scale. Unfortunately, those particular cats are already out of the bag. 191 million voter records were accidentally leaked late in 2015, and the FBI warned in August that some state voter databases have suffered breaches. Altering voter registration records is a big deal, for sure, since such attacks can help an adversary actually affect voter turnout for targeted voting blocs. While that's not what's being reported today, such an attack could not only nudge election results one way or another, but possibly bring into question the integrity of the democratic process itself. After all, "voter fraud," despite being practically non-existent in any recent election in the U.S., is a hot-button political topic. If an attack were detected that involved altering voter records, it would almost certainly be seen as a smoking gun that implies systematic voter fraud, therefore undermining confidence in the election for a huge chunk of the electorate. For more on likely voter data attacks, and what voter registration officials can do to safeguard that information, take a look at ST-16001, Securing Voter Registration Data from US-CERT. Perception Matters Of course, "hacking elections" may not involve actually compromising the balloting or vote counting processes at all. Imagine that someone decided to take down a couple voter information websites. Would this technically interfere with the election process? Maybe, if some people were trying to find out where their polling place is. The obvious effect, though, would be to create the impression that the election is under cyber-attack... and never mind the fact that voter registration and polling place information websites routinely crash under load on election day, despite the best efforts of the people running those sites. So What Can We Do To Secure Elections? Election infrastructure is complex, and there are certain to be bugs in any complex system. While elections, just like nearly everything else, are made safer, more convenient, and more efficient with technology, that same technology is going to introduce new risks that we've never had to deal with before and haven't anticipated. Naturally, there's cause for concern there, even if it doesn't rise to the level of Total Democolypse. If you're in charge of voting technology in your area, we strongly urge you to test your systems now, ahead of the election. You should be attacking the system to see what's possible, and what mitigations are needed to ensure the election will not be affected by any kinks in the system. If you're not sure where to start, feel free to contact community@rapid7.com - we're happy to connect you with security expertise (either our own or someone else from the security community) that will have a chat with you for free. We all have a vested interest in ensuring voting technology is not compromised, so we want to do what we can to help. If you're a U.S. voter concerned about the integrity of the election process in your district, feel free to get in touch with your local office of elections and ask them what they've done to ensure that the election experience is resilient against cyber threats. If you're a real go-getter, I encourage you to volunteer with your county as a poll worker, and see what's going on behind the scenes, up close. Every county always needs help around election day, and I can attest that my own experience as an election judge was a fun and rewarding way to protect democracy without being particularly partisan. NOTE: A version of this essay first appeared in CSM Passcode. You can read that version here: Opinion: Think hackers will tip the vote? Read this first - CSMonitor.com .

Maybe I'm being cynical, but I feel like that may well be the thought that a lot of people have when they hear about two surveys posted online this week to investigate perspectives on vulnerability disclosure and handling. Yet despite my natural cynicism, I believe these surveys are a valuable and important step towards understanding the real status quo around vulnerability disclosure and handling so the actions taken to drive adoption of best practices will be more likely to have impact.Hopefully this blog will explain why I feel this way. Before we get into it, here are the surveys:One for technology providers and operators: https://www.surveymonkey.com/r/techproviderOne for security researchers: https://www.surveymonkey.com/r/securityresearcherA little bit of background…In March 2015, the National Telecommunications and Information Administration (NTIA) issued a request for comment to “identify substantive cybersecurity issues that affect the digital ecosystem and digital economic growth where broad consensus, coordinated action, and the development of best practices could substantially improve security for organizations and consumers.” Based on the responses they received, they then announced that they were convening a “multistakeholder process concerning collaboration between security researchers and software and system developers and owners to address security vulnerability disclosure.”This announcement was met by the deafening sound of groaning from the security community, many of whom have already participated in countless multistakeholder processes on this topic. The debate around vulnerability disclosure and handling is not new, and it has a tendency to veer towards the religious, with security researchers on one side, and technology providers on the other. Despite this, there have been a number of good faith efforts to develop best practices so researchers and technology providers can work more productively together, reducing the risk on both sides, as well as for end-users. This work has even resulted in two ISO standards (ISO 29147 & ISO 30111) providing vulnerability disclosure and handling best practices for technology providers and operators. So why did the NTIA receive comments proposing this topic?  And of all the things proposed, why did they pick this as their first topic?In my opinion, it's for two main, connected reasons. Firstly, despite all the phenomenal work that has gone into developing best practices for vulnerability disclosure and handling, adoption of these practices is still very limited. Rapid7 conducts quite a lot of vulnerability disclosures, either for our own researchers, or on occasion for researchers in the Metasploit community that don't want to deal with the hassle.  Anecdotally, we reckon we receive a response to these disclosures maybe 20% of the time. The rest of the time, it's crickets. In fact, at the first meeting of the NTIA process in Berkeley, Art Manion of the CERT Coordination Center commented that they've taken to sending registered snail mail as it's the only way they can be sure a disclosure has been received.  It was hard to tell if that's a joke or true facts.So adoption still seems to be a challenge, and maybe some people (like me) hope this process can help. Of course, the efforts that went before tried to drive adoption, so why should this one be any different? This brings me to the second of my reasons for this project, namely that the times have changed, and with them the context. In the past five years, we've seen a staggering number of breaches reported in the news; we've seen high-profile branded vulnerability disclosures dominate headlines and put security on the executive team's radar. We've seen bug bounties starting to be adopted by the more security-minded companies. And importantly, we've seen the Government start to pay attention to security research – we've seen that in the DMCA exemption recently approved, the FDA post-market guidance being proposed, the FTC's presence at DEF CON, the Department of Defense's bug bounty, and of course, in the very fact that the NTIA picked this topic. None of these factors alone creates a turn of the tide, but combined, they just might provide an opportunity for us to take a step forward.And that's what we're talking about here – steps. It's important to remember that complex problems are almost never solved overnight. The work done in this NTIA process builds on work conducted before: for example the development of best practices; the disclosure of vulnerability research; efforts to address or fix those bugs; the adoption of bug bounties. All of these pieces make up a picture that reveals a gradual shift in the culture around vulnerability disclosure and handling. Our efforts, should they yield results, will also not be a panacea, but we hope they will pave the way for other steps forward in the future.OK, but why do we need surveys?As I said above, discussions around this tend to become a little heated, and there's not always a lot of empathy between the two sides, which doesn't make for great potential for finding resolution. A lot of this dialogue is fueled by assumptions.My experience and resulting perspective on this topic stems from having worked on both sides of the fence – first as a reputation manager for tech companies (where my reaction to a vulnerability disclosure would have been to try to kill it with fire); and then more recently I have partnered with researchers to get the word out about vulnerabilities, or have coordinated Rapid7's efforts to respond to major disclosures in the community. At different points I have responded with indignation on behalf of my tech company client, who I saw as being threatened by those Shady Researcher Types, and then later on behalf of my researcher friends, who I have seen threatened by those Evil Corporation Types. I say that somewhat tongue-in-cheek, but I do often hear that kind of dialogue coming from the different groups involved, and much worse besides. There are a lot of stereotypes and assumptions in this discussion, and I find they are rarely all that true.I thought my experience gave me a pretty good handle on the debate and the various points of view I would encounter. I thought I knew the reality behind the hyperbolic discourse, yet I find I am still surprised by the things I hear.For example, it turns out a lot of technology providers (both big and small) don't think of themselves as such and so they are in the “don't know what they don't know” bucket. It also turns out a lot of technology operators are terrified of being extorted by researchers. I've been told that a few times, but had initially dismissed it as hyperbole, until an incredibly stressed security professional working at a non-profit and trying to figure out how to interpret an inbound from a researcher contacted me asking for help. When I looked at the communication from the researcher, I could absolutely understand his concern.On the researcher side, I've been saddened by the number of people that tell me they don't want to disclose findings because they're afraid of legal threats from the vendor. Yet more have told me they see no point in disclosing to vendors because they never respond.  As I said above, we can relate to that point of view! At the same time, we recently disclosed a vulnerability to Xfinity, and missed disclosing through their preferred reporting route (we disclosed to Xfinity addresses, and their recommendation is to use abuse@comcast.net).  When we went public, they pointed this out, and were actually very responsive and engaged regarding the disclosure. We realized that we've become so used to a lack of response from vendors that we stopped pushing ourselves to do everything we can to get one. If we care about reaching the right outcome to improve security – and we do – we can't allow ourselves to become defeatist.My point here is that assumptions may be based on past experience, but that doesn't mean they are always correct, or even still correct in the current context. Assumptions, particularly erroneous ones, undermine our ability to understand the heart of the problem, which reduces our chances of proposing solutions that will work. Assumptions and stereotypes are also clear signs of a lack of empathy. How will we ever achieve any kind of productive collaboration, compromise, or cultural evolution if we aren't able or willing to empathize with each other?  I rarely find that anyone is motivated by purely nefarious motives, and understanding what actually does motivate them and why is the key to informing and influencing behavior to effect positive change.  Even if in some instances it means that it's your own behavior that might change JSo, about those surveys…The group that developed the surveys – the Awareness and Adoption Group participating in the NTIA process (not NTIA itself) – is comprised of a mixture of security researchers, technology providers, civil liberties advocates, policy makers, and vulnerability disclosure veterans and participants. It's a pretty mixed group and it's unlikely we all have the same goals or priorities in participating, but I've been very impressed and grateful that everyone has made a real effort to listen to each other and understand each other's points of view. Our goal with the surveys is to do that on a far bigger scale so we can really understand a lot more about how people think about this topic. Ideally we will see responses from technology providers and operators, and security researchers that would not normally participate in something like the NTIA process as they are the vast majority and we want to understand their (your?!) perspectives. We're hoping you can help us defeat any assumptions we may have - the only hypothesis we hope to prove out here is that we don't know everything and can still learn.So please do take the survey that relates to you, and please do share them and encourage others to do likewise:Survey for technology providers and operators: https://www.surveymonkey.com/r/techproviderSurvey for security researchers: https://www.surveymonkey.com/r/securityresearcherThank you! @infosecjen

A major area of focus in the current cybersecurity policy discussion is how growing adoption of encryption impacts law enforcement and national security, and whether new policies should be developed in response. This post briefly evaluates several potential outcomes of the debate, and provides Rapid7's current position on each. Background Rapid7 has great respect for the work of our law enforcement and intelligence agencies. As a cybersecurity company that constantly strives to protect our clients from cybercrime and industrial espionage, we appreciate law enforcement's role in deterring and prosecuting wrongdoers. We also recognize the critical need for effective technical tools to counter the serious and growing threats to our networks and personal devices. Encryption is one such tool. Encryption is a fundamental means of protecting data from unauthorized access or use. Commerce, government, and individual internet users depend on strong security for our communications. For example, encryption helps prevent unauthorized parties from reading sensitive communications – like banking or health information – traveling over the internet. Another example: encryption underpins certificates that demonstrate authenticity (am I who I say I am?), so that we can have high confidence that a digital communication – such as a computer software security update – is coming from the right source and not a man-in-the-middle attacker. The growing adoption of encryption for features like these has made users much more safe than we would be without it. Rapid7 believes companies and technology innovators should be able to use the encryption protocols that best protect their customers and fit their service model – whether that protocol is end-to-end encryption or some other system. However, we also recognize this increased data security creates a security trade-off. Law enforcement will at times encounter encryption that it cannot break by brute force and for which only the user – not the software vendor – has the key, and this will hinder lawful searches. The FBI's recently concluded efforts to access the cell phone belonging to deceased terrorist Syed Farook of San Bernardino, California, was a case study in this very issue. Although the prevalence of systems currently secured with end-to-end encryption with no other means of access should not be overstated, law enforcement search attempts may be thwarted more often as communications evolve to use unbreakable encryption with greater frequency. This prospect has tempted government agencies to seek novel ways around encryption. While we do not find fault with law enforcement agencies attempting to execute valid search or surveillance orders, several of the options under debate for circumventing encryption pose broad negative implications for cybersecurity. Weakening encryption One option under discussion is a legal requirement that companies weaken encryption by creating a means of "exceptional access" to software and communications services that government agencies can use to unlock encrypted data. This option could take two forms – one in which the government agencies hold the decryption keys (unmediated access), and one in which the software creator or another third party holds the decryption keys (mediated access). Both models would impose significant security risks for the underlying software or service by creating attack surfaces for bad actors, including cybercriminals and unfriendly international governments. For this reason, Rapid7 does not support a legal requirement for companies or developers to undermine encryption for facilitating government access to encrypted data. The huge diversity of modern communications platforms and software architecture makes it impossible to implement a one-size-fits-all backdoor into encryption. Instead, to comply with a hypothetical mandate to weaken encryption, different companies are likely to build different types of exceptional access. Some encryption backdoors will be inherently more or less secure than others due to technical considerations, the availability of company resources to defend the backdoor against insider and external threats, the attractiveness of client data to bad actors, and other factors. The resulting environment would most likely be highly complex, vulnerable to misuse, and burdensome to businesses and innovators. Rapid7 also shares concerns that requiring US companies to provide exceptional access to encrypted communications for US government agencies would lead to sustained pressure from many jurisdictions – both local and worldwide – for similar access. Companies or oversight bodies may face significant challenges in accurately tracking when, by whom, and under what circumstances client data is accessed – especially if governments have unmediated access to decryption keys. If US products are designed to be inherently insecure and "surveillance-ready," then US companies will face a considerable competitive disadvantage in international markets where more secure products are available. Legal mandates to weaken encryption are unlikely to keep unbreakable encryption out of the hands of well-resourced criminals and terrorists. Open source software is commonly "forked," and it should be expected that developers will modify open source software to remove an encryption backdoor. Jurisdictions without an exceptional access requirement could still distribute closed source software with unbreakable encryption. As a result, the cybersecurity risks of weakened encryption are especially likely to fall on users who are not already security-conscious enough to seek out these workarounds. Intentionally weakening encryption or other technical protections ultimately undermines the security of the end users, businesses, and governments. That said, if companies or software creators voluntarily choose to build exceptional access mechanisms into their encryption, Rapid7 believes it is their right to do so. However, we would not recommend doing so, and we believe companies and creators should be as transparent as possible with their users about any such feature. "Technical assistance" – compelled malware Another option under debate is whether the government can force developers to build custom software that removes security features of the developers' products. This prospect arose in connection with the FBI's now-concluded bid to unlock Farook's encrypted iPhone to retrieve evidence for its terrorism investigation. In that case, a magistrate judge ordered Apple to develop and sign a custom build of iOS that would disable several security features preventing the FBI from using electronic means to quickly crack the phone's passcode via brute force. This custom version of iOS would have been deployed like a firmware update only to the deceased terrorist's iPhone, and Apple would have maintained control of both the iPhone and the custom iOS. However, the FBI ultimately cracked the iPhone without Apple's assistance – with help, according to some reports, from a third party company – and asked the court to vacate its order against Apple. Still, it's possible that law enforcement agencies could again attempt to legally compel companies to hack their own products in the future. In the Farook case, the government had good reason to examine the contents of the iPhone, and clearly took steps to help prevent the custom software from escaping into the wild. This was not a backdoor or exceptional access to encryption as traditionally conceived, and not entirely dissimilar to cooperation Apple has offered law enforcement in the past for unencrypted older versions of iOS. Nonetheless, the legal precedent that would be set if a court compels a company or developer to create malware to weaken its own software could have broad implications that are harmful to cybersecurity. FBI Director James Comey confirmed in testimony before Congress that if the government succeeded in court against Apple, law enforcement agencies would likely use the precedent as justification to demand companies create custom software in the future. It's possible the precedent could be applied to a prolonged wiretap of users of an encrypted messaging service like WhatsApp, or a range of other circumstances. Establishing the limits of this authority would be quite important. If the government consistently compelled companies to create custom software to undermine the security of their own products, the effect could be proliferation of company-created malware. Companies would need to defend their malware from misuse by both insiders and external threats while potentially deploying the malware to comply with many government demands worldwide, which – like defending an encryption backdoor – would be considerably burdensome on companies. This outcome could reduce user trust in the security of vendor-issued software updates, even though it is generally critical for cybersecurity for users to keep their software as up to date as possible. Companies may also design their products to be less secure from the outset, in anticipation of future legal orders to circumvent their own security. These scenarios raise difficult questions for cybersecurity researchers and firms like Rapid7. Government search and surveillance demands are frequently paired with gag orders that forbid the recipient (such as the individual user or a third party service provider) from discussing the demands. Could this practice impact public disclosure or company acknowledgment of a vulnerability when researchers discover a security flaw or threat signature originating from software a company is compelled to create for law enforcement? When would a company be free to fix its government-ordered vulnerability? Would cybersecurity firms be able to wholeheartedly recommend clients accept vendor software updates? Rapid7 does not support legal requirements – whether via legislation or court order – compelling companies to create custom software to degrade security. Creating secure software is very difficult under the best of circumstances, and forcing companies to actively undermine their own security features would undo decades of security learnings and practice. If the government were to compel companies to provide access to its products, Rapid7 believes it would be preferable to use tools already available to the companies (such as that which Apple offered prior to iOS 8) in limited circumstances that do not put non-targeted users at risk. If a company has no means to crack its products already available, the government should not compel a company to create custom software to undermine their products' security features. Software developers should also be free to develop patches or introduce more secure versions of their products to fix vulnerabilities at any time. Government hacking and forensics Finally, there is the option of government deploying its own tools to hack products and services to obtain information. End-to-end encryption provides limited protection when one of the endpoints is compromised. If government agencies do not compel companies to weaken their own products, they could exploit existing vulnerabilities themselves. As noted above, the government's exploitation of existing vulnerabilities was the outcome of the FBI's effort to compel Apple to provide access to Farook's iPhone. Government has also turned to hacking or implanting malware in other contexts well before the Farook case. In many ways, this activity is to be expected. It is not an irrational priority for law enforcement agencies to modernize their computer penetration capabilities to be commensurate with savvy adversaries. A higher level of hacking and digital forensic expertise for law enforcement agencies should improve their ability to combat cybercriminals more generally. However, this approach raises its own set of important questions related to transparency and due process. Upgrading the technological expertise of law enforcement agencies will take time, education, and resources. It will also require thoughtful policy discussions on what the appropriate rules for government hacking should be – there are few clear and publicly available standards for government use of malware. One potentially negative outcome would be government stockpiling of zero day vulnerabilities for use in investigations, without disclosing the vulnerabilities to vendors or the public. The picture is clouded further when the government partners with third party organizations to hack on the government's behalf, as may have occurred in the case of Farook's iPhone – if the third party owns a software exploit, could IP or licensing agreements prevent the government from disclosing the vulnerability to the vendor? White House Cybersecurity Coordinator Michael Daniel noted there were "few hard and fast rules" for disclosing vulnerabilities, but pointed out that zero day stockpiles put Internet users at risk and would not be in the interests of national security. We agree and appreciate the default of vulnerability disclosure, but clearer rules on transparency and due process in the context of government hacking are quickly becoming increasingly important. No easy answers We view the complex issue of encryption and law enforcement access as security versus security. To us, the best path forward is that which would provide the best security for the most number of individuals. To that end, Rapid7 believes that we should embrace the use of strong encryption without compelling companies to create software that undermines their product security features. We want the government to help prevent crime by working with the private sector to make communications services, commercial products, and critical infrastructure trustworthy and resilient. The foundation of greater cybersecurity will benefit us all in the future. Harley Geiger Director of Public Policy, Rapid7

Currently one of the most successful methods for compromising an organization is via password-guessing attacks. To gain access to an organization using brute force attack methods, there are a minimum of three things a malicious actor needs: A username, a password, and a target. Often the targets are easy to discover, and typically turn out to be email systems such as Outlook Web Access (OWA) or VPN solutions that are exposed to the Internet. Once a malicious actor has a target, they next need a list of usernames fitting the context of the attack. In this case, we can often turn to the Internet and search Google or similar search engines for email addresses related to the organization. A commonly utilized alternative is to make use of business-centric social media (such as LinkedIn) to discover names, which can be converted into usernames. Besides gathering usernames from the Internet, a malicious actor also needs to identify the username syntax in use. The most common syntax encountered for usernames is first initial lastname—for example, the user John Doe's username would be jdoe. Using resources such as Google and Linkedin for gathering usernames to target is a very simple process, but inevitably the amount of names gathered this way can often come up short and represents a significant effort on the part of the malicious actor. Of course, there are several other attack methods, which can be used to enumerate valid accounts, for example RCPT TO requests against an exposed SMTP service or the OWA timing attack by Nate Power can also be used to great effect. Although if those attack vectors have been mitigated, what next? Well, personally I like turn to the United States Census Bureau for help. It turns out the US Census Bureau published a very valuable piece of information for genealogy researchers—and of course this data lends itself well to be leveraged to conduct brute force password attacks. So how is this data useful you ask? Well, let us explore it and see how to effectively leverage this data. The data I am referring to is available at the US Census Bureau and consists of surnames, which have an occurrence greater then 100 from the 2000 census. This data is in descending order from most common to least common as shown in Figure 1: Due to the ordering of the data it is possible to increase the odds of guessing a users lastname with reasonably high probability of success by selecting the top most common surnames from the list.  As previously stated, first Initial last name is the most common username syntax encountered, so to build a list of valid usernames using this data we first need to figure out what initials to use. Of course we could use the full alphabet of 26 characters and combine that with the full list of names from the 2000 census, but if we do that we end up with 3,943,472 possibilities. Firing that against an Internet facing service to brute force accounts is not practical unless you have a lot of time on your hands. The solution is to figure out what first initials and surnames to use that will have the highest probability of resulting in an active account within the targeted service. To determine the most effective list of first initials we can turn to the 1990 census data, which contains a list of the most common first names from the 1990 census. In my case I took the first initial from top 100 female name and top 100 male names, which gave me the following 20 initials: ABCDEFGHIJKLMNPRSTVW. Next, I took the top 1000 surnames and combined these with the initials. You may be asking, why not top 2000 or 3000 surnames? Well, using this data I conducted a number of real world tests using various combinations of this data and determined that using the top 20 initials combined with top 1000 surnames successfully matched between 25-35% of an organizations employee usernames. I also determined that using more initials and surnames had diminishing returns as we increase the count and greatly increased the time to conduct the brute force attacks. So now we have a list of 20,000 potential usernames we need to figure out what passwords to use. Password guessing is another interesting subject on its own, and I would suggest taking a look at The Attacker's Dictionary, which is an outstanding piece of work on the subject. If I was only going to pick a single password to try, I would have to admit my favorite password for brute force attacks is constructed of season combined with year, and has the first initial capitalized such as “Winter16”. It seems this form of password has a very high success rate. I remember one summer while conducting external penetration tests I compromised 10 organizations in a row using this method. The most common reason for this is that it meets Windows password complexity requirements (Figure 2). Furthermore, password policies are often configured requiring users to change their password every 90 days. Guess what else changes every 90 days: Seasons. And this style of password is very easy for an employee to remember (Winter16, Spring16, Summer16, Fall2016). So if we combine all of these together—a username of first initial lastname, Windows password complexity enabled in addition to a 90-day password rotation—it can lead to the perfect storm, which can allow a malicious actor to potentially gain access to your critical exposed system over the Internet. Finally, what steps can be taken to mitigate these issues? I like to recommend the following items, which I have found to seriously impact my ability to compromise an organization through brute force attacks when correctly implemented. Email address and username account should not match. Example: if email address is jdoe@acme.com username should not be jdoe Employee awareness training about the risk of using seasons (Summer, Winter, Fall, Spring) in the password. This should also include company names and any dictionary word related to your industry. Also regular password audits should be conducted to ensure employees are following these rules. Two factor authentication of employee-based services exposed to the internet (OWA, VPN, Extranet)