[Senate Hearing 117-519]
[From the U.S. Government Publishing Office]




                                                        S. Hrg. 117-519

      RESPONDING TO AND LEARNING FROM THE LOG4SHELL VULNERABILITY

=======================================================================

                                HEARING

                               before the

                              COMMITTEE ON
               HOMELAND SECURITY AND GOVERNMENTAL AFFAIRS
                          UNITED STATES SENATE

                    ONE HUNDRED SEVENTEENTH CONGRESS


                             SECOND SESSION

                               __________

                            FEBRUARY 8, 2022

                               __________

        Available via the World Wide Web: http://www.govinfo.gov

                       Printed for the use of the
        Committee on Homeland Security and Governmental Affairs





                [GRAPHIC NOT AVAILABLE IN TIFF FORMAT]





                               ______
                                 

                 U.S. GOVERNMENT PUBLISHING OFFICE

49-901 PDF                WASHINGTON : 2023









        COMMITTEE ON HOMELAND SECURITY AND GOVERNMENTAL AFFAIRS

                   GARY C. PETERS, Michigan, Chairman

THOMAS R. CARPER, Delaware           ROB PORTMAN, Ohio
MAGGIE HASSAN, New Hampshire         RON JOHNSON, Wisconsin
KYRSTEN SINEMA, Arizona              RAND PAUL, Kentucky
JACKY ROSEN, Nevada                  JAMES LANKFORD, Oklahoma
ALEX PADILLA, California             MITT ROMNEY, Utah
JON OSSOFF, Georgia                  RICK SCOTT, Florida
                                     JOSH HAWLEY, Missouri

                   David M. Weinberg, Staff Director
                    Zachary I. Schram, Chief Counsel
         Christopher J. Mulkins, Director of Homeland Security
         Jeffrey D. Rothblum, Senior Professional Staff Member
                Pamela Thiessen, Minority Staff Director
       Cara G. Mumford, Minority Director of Governmental Affairs
           William H.W. McKenna, Minority Chief Investigator
           Patrick T. Warren, Minority Investigative Counsel
                     Laura W. Kilbride, Chief Clerk
                     Thomas J. Spino, Hearing Clerk









                            C O N T E N T S

                                 ------                                
Opening statements:
                                                                   Page
    Senator Peters...............................................     1
    Senator Portman..............................................     3
    Senator Padilla..............................................    12
    Senator Hassan...............................................    19
    Senator Lankford.............................................    21
    Senator Hawley...............................................    24
Prepared statements:
    Senator Peters...............................................    31
    Senator Portman..............................................    33

                               WITNESSES

                       Tuesday, February 8, 2022

David Nalley, President, Apache Software Foundation..............     5
Brad Arkin, Senior Vice President and Chief Security and Trust 
  Officer, Cisco Systems, Inc....................................     7
Jen Miller-Osborn, Deputy Director of Intelligence, Unit 42, Palo 
  Alto Networks..................................................     8
Trey Herr, Ph.D., Director, Cyber Statecraft Initiative, 
  Scowcroft Center for Strategy and Security, The Atlantic 
  Council........................................................    10

                     Alphabetical List of Witnesses

Arkin, Brad:
    Testimony....................................................     7
    Prepared statement...........................................    37
Herr, Trey, Ph.D.:
    Testimony....................................................    10
    Prepared statement...........................................    54
Miller-Osborn, Jen:
    Testimony....................................................     8
    Prepared statement...........................................    48
Nalley, David:
    Testimony....................................................     5
    Prepared statement...........................................    35

                                APPENDIX

Miller-Osborn Palo Alto Cyber Threat Landscape Report............    65









 
      RESPONDING TO AND LEARNING FROM THE LOG4SHELL VULNERABILITY

                              ----------                              


                       TUESDAY, FEBRUARY 8, 2022

                                     U.S. Senate,  
                           Committee on Homeland Security  
                                  and Governmental Affairs,
                                                    Washington, DC.
    The Committee met, pursuant to notice, at 10 a.m., via 
Webex and in room SD-342, Dirksen Senate Office Building, Hon. 
Gary Peters, Chairman of the Committee, presiding.
    Present: Senators Peters, Hassan, Sinema, Rosen, Padilla, 
Ossoff, Portman, Lankford, Romney, Scott, and Hawley.

            OPENING STATEMENT OF CHAIRMAN PETERS\1\

    Chairman Peters. The Committee will come to order. I 
certainly would like to thank our witnesses for joining us to 
examine the vulnerability in Log4j, which our government's top 
cybersecurity experts have called one of the most severe and 
widespread cybersecurity risks ever seen.
---------------------------------------------------------------------------
    \1\ The prepared statement of Senator Peters appears in the 
Appendix on page 31.
---------------------------------------------------------------------------
    This bug, which can be exploited by only typing in 12 
characters, can allow cybercriminals and foreign adversaries to 
remotely access critical American networks. Reportedly, the 
Russian Federation has already taken advantage of this 
vulnerability to perpetrate cyberattacks against Ukraine. While 
I hope that situation deescalates, we must be prepared to 
protect our systems from similar attacks from the Russian 
government and the criminal organizations that they harbor, who 
could exploit this or other vulnerabilities to compromise 
American networks in retaliation for our nation's support of 
Ukraine.
    The weakness in Log4j is one example of how widespread 
software vulnerabilities, including those found in open source 
code, or code that is freely available and developed by 
individuals, can present a serious threat to our national and 
economic security.
    In terms of the amount of online services, sites, and 
devices exposed, the potential impact of this software 
vulnerability is immeasurable, and it leaves everything from 
our critical infrastructure, such as banks and power grids, to 
government agencies, open to network breaches.
    We have already seen how cyberattacks on these critical 
entities can have catastrophic impacts on the lives and 
livelihoods of Americans. That is why I am grateful to our 
private sector partners, the open source community, and the 
Federal Government who have swiftly mobilized to respond to 
this threat.
    While I am grateful to the Administration for their quick 
action and transparency with Congress, I remain concerned that 
we may never know the full scope and impacts of this 
vulnerability or the risks posed to our networks that the 
American people rely on each and every day.
    That is why I will continue to monitor and track this 
latest cybersecurity threat, and work with my colleagues to 
help ensure the government is receiving timely information 
about cybersecurity threats, so we can formulate a 
comprehensive strategy to fight back against hackers and hold 
foreign adversaries accountable for targeting our networks.
    That includes urging the Senate to pass landmark 
legislation that Ranking Member Portman and I authored and 
passed out of this Committee, to require critical 
infrastructure companies and civilian Federal agencies to 
report to the Cybersecurity and Infrastructure Security Agency 
(CISA) when they are hit by a substantial cyberattack. Our 
efforts will also ensure that critical infrastructure owners 
and operators are reporting ransomware payments. Our 
government's top cybersecurity experts would analyze this 
information and use it help private sector organizations that 
provide essential services to the American people, protect 
their networks.
    This legislation will help our lead cybersecurity agency 
better understand the scope of attacks, including from 
vulnerabilities like Log4j, to warn others of the threat, 
prepare for potential impacts, and help affected entities 
respond and recover.
    By modernizing the government's cybersecurity posture by 
passing Federal Information Security Modernization Act (FISMA) 
reforms, we can help prevent online assaults against Federal 
agencies, from foreign and domestic actors who seek to degrade 
our national and economic security.
    I am pleased that yesterday Ranking Member Portman and I 
introduced a bipartisan package that combines these critical 
efforts into one bill, along with our bill to modernize Federal 
Risk and Authorization Management Program (FedRAMP), that we 
hope to move forward soon.
    Today I am honored to welcome a panel of experts who can 
discuss this vulnerability in greater detail, how it has been 
exploited, how they have worked to mitigate its impacts, and 
broadly discuss how we can work to secure modern software that 
commonly contains open source coding. I look forward to hearing 
their thoughts on how to improve our government's overall 
ability to respond to open source vulnerabilities like Log4j, 
and ensure we have comprehensive plans and procedures in place 
to prevent a cybersecurity crisis of this magnitude.
    Ranking Member Portman, you are recognized for your opening 
comments.

            OPENING STATEMENT OF SENATOR PORTMAN\1\

    Senator Portman. Thank you, Mr. Chairman, and thanks for 
the witnesses here before us today. This is an opportunity for 
us to hear from organizations who have distinct perspectives on 
Log4shell, a pervasive cybersecurity vulnerability in a Java 
software library called Log4j.
---------------------------------------------------------------------------
    \1\ The prepared statement of Senator Portman appears in the 
Appendix on page 33.
---------------------------------------------------------------------------
    Log4j is open source software, meaning unlike proprietary 
software it is available for anyone to use and access free of 
charge. Open source software like Log4j has unique advantages 
in that sense but also disadvantages relative to proprietary 
software, that we will discuss at today's hearing.
    Open source software is ubiquitous in the software 
industry. It underpins much of our economy and numerous other 
software products. Companies benefit from not having to 
reinvent the wheel, and that is a good thing, when they are 
developing their products. As a result of these dependencies, a 
vulnerability, though, in open source software can affect many 
other software products that rely on it.
    The Log4shell vulnerability is a particularly severe 
vulnerability because the code is in so many places, the 
vulnerability is easy to exploit requiring less than a 
sentence, and because it provides a high level of access. To 
put this in perspective, we had CISA Director Jen Easterly 
described it as, ``the most serious vulnerability'' she has 
seen in her decades-long service and area of cybersecurity.
    This is not the first severe vulnerability in open source 
software, by the way. In 2014, there was another open source 
vulnerability, called ``Heartbleed'' that allowed normally 
protected information to be stolen. Similar to Log4j, the open 
source product with the Heartbleed vulnerability was widely 
used, making the response challenging.
    Then, in 2017, of course we had the Equifax massive breach, 
due to a vulnerability in an open source Apache Software 
Foundation (ASF) product called Apache Struts. Log4j is also 
maintained by Apache, who is here today. When I chaired the 
Permanent Subcommittee on Investigations (PSI), we released a 
bipartisan report, and Senator Carper and I did so together, on 
Equifax's failure to remediate the vulnerability, compromising 
the personal information of roughly 147 million Americans. I am 
concerned that without prompt remediation of the Log4shell 
vulnerability we run the risk of experiencing one or even more 
incidents of the same magnitude as the Equifax breach.
    It is clear that issues involving the security of open 
source software have been around for a long time. I am looking 
forward to hearing from our witnesses today, who have a wide 
variety of perspectives on how to address these challenges.
    This does, by the way, build on a previous hearing we had 
on Log4j just about a month ago, where we heard from National 
Cyber Director, Chris Inglis, and CISA Director, Jen Easterly. 
In that briefing we learned several things. First, we learned 
this vulnerability is widespread. Hundreds of millions of 
devices have the vulnerability. David Nalley, the President of 
the Apache Software Foundation is here, and I look forward to a 
conversation about the disclosure and subsequent remediation of 
this vulnerability.
    Second, we learned that fixing this vulnerability is not as 
easy as Apache putting out a one-size-fits-all patch. Vendors 
who used this vulnerable code, not knowing it was vulnerable, 
will have to issue their own patches for their own products. 
This makes the response even more complicated and time 
consuming. I am glad Brad Arkin, a Senior Vice President and 
the Chief Security and Trust Officer of Cisco is here to 
provide some perspective from a company that had this 
vulnerability and has remediated it.
    Finally, we learned that because this response will be 
drawn out, attackers are going to have time to exploit the 
vulnerability and launch attacks. Just because a vulnerability 
exists, does not mean that it is actively being used to attack 
an entity. But the concerning reality today is that our nation 
does not know how widespread attacks leveraging this 
vulnerability are and when they are going to occur. It is one 
reason it is more important than ever to pass my Cyber Incident 
Reporting Act, that Senator Peters just talked about. That 
legislation will ensure that our nation has visibility into 
attacks exploiting the Log4shell vulnerability against critical 
infrastructure.
    I am looking forward to hearing from Jen Miller-Osborn from 
Palo Alto about her work tracking and analyzing the threats 
stemming from this vulnerability.
    Open source software is inextricably woven into every bit 
of software we use every day. The answer to this problem is not 
to stop using it, but it is important that we use this hearing 
to understand how we can address security risks in open source 
products, working within existing processes and strategically 
investing time and money to support the open source community 
so it can be more secure.
    I am also going to be asking some of our cybersecurity 
threat experts here today about the ongoing targeting of 
Ukraine by Russia in cyberspace. I am hopeful that we will 
leave this hearing with a better understanding of the risks and 
benefits of open source software and also what the role of the 
Federal Government should have in supporting these efforts to 
increase open source security.
    Thanks very much for convening this hearing, Mr. Chairman. 
I look forward to hearing from the witnesses.
    Chairman Peters. Thank you, Ranking Member Portman.
    It is the practice of the Homeland Security and Government 
Affairs Committee (HSGAC) to swear in witnesses, so if each of 
you will please stand, including those joining us by video, if 
you could stand and raise your right hand, please.
    Do you swear that the testimony that you will give before 
this Committee will be the truth, the whole truth, and nothing 
but the truth, so help you, God?
    Mr. Nalley. I do.
    Mr. Arkin. I do.
    Ms. Miller-Osborn. I do.
    Mr. Herr. I do.
    Chairman Peters. Everybody has answered in the affirmative. 
You may be seated.
    Our first witness is David Nalley. Mr. Nalley is President 
of the Apache Software Foundation. It is a not-for-profit 
organization and the world's largest open source foundation 
that serves as a steward for hundreds of open source projects. 
David has extensive experience as a Systems Administrator and 
decades of experience working on open source projects.
    Previously he served as a member of the Apache Software 
Foundation's board of directors, as Executive Vice President 
and Vice President of Infrastructure.
    Mr. Nalley, welcome to our Committee. You may now proceed 
with your opening comments.

   TESTIMONY OF DAVID NALLEY,\1\ PRESIDENT, APACHE SOFTWARE 
                           FOUNDATION

    Mr. Nalley. Chairman Peters, Ranking Member Portman, 
distinguished Members of the Committee, thank you for the 
invitation to appear this morning. My name is David Nalley, and 
I am the President of the Apache Software Foundation. The ASF 
is a nonprofit, public-benefit charity established in 1999, to 
facilitate the development of open source software. Thanks to 
the ingenuity and collaboration of our community of 
programmers, the ASF has grown into one of the largest open 
source organizations in the world. Today more than 650,000 
contributors have contributed to more than 350 ongoing open 
source projects, comprising more than 237 million lines of 
code.
---------------------------------------------------------------------------
    \1\ The prepared statement of Mr. Nalley appears in the Appendix on 
page 35.
---------------------------------------------------------------------------
    Open source is not simply a large component of the software 
industry. It is one of the foundations of the modern global 
economy. Whether they realize it or not, most businesses, 
individuals, nonprofits, and government agencies depend on open 
source; it is an indispensable part of America's digital 
infrastructure.
    Projects developed from open source, like Log4j, tend to 
resolve problems that many people have, essentially serving as 
reusable building blocks for solving those problems. This 
enables faster innovation because it eliminates the need for 
every company or every developer to reimplement software for 
problems that have already been solved. This efficiency allows 
programmers to stand on the shoulders of giants. The ASF 
provides a vendor-neutral environment to enable interested 
programmers, sometimes direct competitors to each other, to do 
this common work together in transparent, open-handed 
cooperation.
    This is the essence of open-source software: brilliant 
individuals contributing their time and expertise to do the 
unglamorous work solving problems, many with the intent of 
incorporating the results into the results of their employer's 
products. It is why I have dedicated my professional life to 
open source.
    Log4j, which was first released by Apache in 2001, is the 
product of just this kind of collaboration. It performs a 
particular set of functions, like recording a computer's 
operating events, and does it so well that it has been used in 
products as diverse as storage management software, software 
development tools, virtualization software and, perhaps most 
famously, the Minecraft video game. As Log4j's footprint grew 
over the years, so did its feature list. It was a 2013 addition 
to Log4j, along with a part of the Java programming 
environment, that combined in such a way to expose this 
security flaw.
    This vulnerability was reported to Apache's Log4j team late 
in November 2021, after having been latent for many years. The 
Apache Logging project and Apache's security team immediately 
got to work addressing the vulnerability. The full solution was 
released approximately two weeks later. Given the near ubiquity 
of Log4j's use, it may be months or even years before all the 
deployed instances of this vulnerability are eliminated.
    As a software professional myself, I am proud of how the 
Logging project, the ASF's security team, and many others 
across the Apache Software Foundation responded and remediated 
this threat. We acted quickly and in accordance with practices 
we have adopted over many years of supporting a diverse set of 
open source projects, and we will continue to develop our 
projects in responding to and preventing security 
vulnerabilities.
    Moreover, every stakeholder in the software industry, 
including its largest customers, especially like the Federal 
Government, should be investing in software supply chain 
security. While ideas like the software bills of materials 
(SBOM) will not prevent vulnerabilities, they can mitigate the 
impact by accelerating the identification of potentially 
vulnerable software. However, the ability to quickly update to 
the most secure and up-to-date versions remains a significant 
hurdle for the software industry.
    The reality is that humans write software, and as a result 
there will continue to be bugs, and despite best efforts some 
of those will include security vulnerabilities. As we continue 
to become ever more connected and digital, the number of 
vulnerabilities and potential consequences are likely to grow. 
There is no easy software security solution. It requires 
defense in depth, incorporating upstream development in open 
source projects, vendors that incorporate these projects, 
developers that make use of the software in custom 
applications, and even down to the organizations that deploy 
these applications to provide services important to their 
users.
    Rather than shying away from this risk, I submit that 
software developers, open source communities, and Federal 
policymakers should face it head-on together, with the 
determination and the vigilance that it demands.
    Thank you again, and I look forward to answering any 
questions you may have for me.
    Chairman Peters. Thank you, Mr. Nalley.
    Our next witness is Brad Arkin, Senior Vice President and 
Chief Security and Trust Officer of Cisco Systems. In his role, 
he is responsible of ensuring Cisco meets its security and 
privacy obligations. Prior to joining Cisco he was Adobe's 
first Chief Security Officer and developed a security function 
from a few employees to over 600 globally. He also was formerly 
a board member of Safeco, a global nonprofit that brings 
business leaders and technical experts together to exchange new 
ideas.
    Mr. Arkin, welcome to our Committee. You may proceed with 
your opening remarks.

  TESTIMONY OF BRAD ARKIN,\1\ SENIOR VICE PRESIDENT AND CHIEF 
        SECURITY AND TRUST OFFICER, CISCO SYSTEMS, INC.

    Mr. Arkin. Thank you, Chairman Peters, Ranking Member 
Portman, and Members of this Committee for the invitation to 
speak with you today and for your leadership on this important 
issue we are discussing, our collective response to and 
learnings from the Log4j vulnerability.
---------------------------------------------------------------------------
    \1\ The prepared statement of Mr. Arkin appears in the Appendix on 
page 37.
---------------------------------------------------------------------------
    My name is Brad Arkin, and I am the Chief Security and 
Trust officer for Cisco. I am responsible for the security of 
our products, our company, and our services. Today I am going 
to discuss our experience with Log4j, how Cisco responded to 
help protect our enterprise and our customers, how government 
can play an important role, and the critical lessons we have 
learned together.
    Cisco is a global company of nearly 80,000 full-time 
employees worldwide. While well-known as a networking hardware 
company, Cisco is now one of the leading software companies in 
the world, with $15 billion in software revenue last year. We 
own and operate a large and complex information technology (IT) 
environment to run our business and support our customers. 
Protecting our company, our customers, and their data from 
cyberattacks is critical to our business.
    On December 9, 2021, a critical vulnerability was revealed 
in the Apache Foundation's Log4j library, used in almost every 
job application on the internet. This forced organizations 
around the world to figure out how they were using Log4j, the 
potential exposure that needed to be addressed, and how they 
could best manage the associated risks.
    For Cisco, the scope and diversity of our technology 
business includes protecting not only our internal enterprise 
systems but also our on-premise hardware products and our 
cloud-delivered services too. We needed to quickly identify the 
presence of the vulnerability and to apply necessary fixes 
using risk assessments to prioritize our efforts. With Log4j, 
software patches were available for vulnerable on-premise 
products within the first two weeks.
    In 2014, our industry faced a similar, widespread zero-day 
vulnerability called ``Heartbleed.'' At that time, it took 
Cisco 50 days to identify the full list of software that 
required updates and several additional weeks to publish the 
necessary software patches. This significant improvement in 
response times was driven by lessons learned in the past, 
Cisco's ongoing automation and security investments, which 
allowed us to assess and mitigate very quickly.
    Partnership in the collaborative efforts with industry 
peers and government can also provide valuable context, threat 
indicators, and help to create consistent technical guidance 
and understanding across public and private sectors during 
incidents like Log4j. The Joint Cyber Defense Collaborative 
(JCDC), recently stood up by the Department of Homeland 
Security's (DHS) Cybersecurity and Infrastructure Agency is a 
promising example.
    We are proud of advances in the speed and efficiency of our 
incident response and our threat information-sharing efforts, 
but we know there is always room for improvement. The world of 
cloud-delivered services demands faster response times and more 
resilient computing environments.
    Cisco is among the world's largest users of, and 
contributors to commercial, open source software. We do 
recognize that there are shared risks from shared development 
infrastructure and that is why Cisco makes ongoing investments 
of money and time to help improve the security of widely used 
open source projects, including through our work with the 
Apache Foundation.
    It is, however, incorrect to assume that open source 
software is uniquely a source of risk. All software has the 
potential to contain vulnerabilities. All software used in 
enterprise and commercial products and services requires 
lifecycle management. These ongoing investments help minimize 
repetition of past mistakes. They allow us to find and fix 
problems faster and to bolster our resiliency when we are 
vulnerable, in the time after a problem has been disclosed and 
before software patches can be applied.
    The secure software development and zero-trust networking 
requirements in Executive Order (EO) 14028 are also important 
steps forward, regardless of whether they would have prevented 
this particular vulnerability. We will continue our efforts to 
help shape these requirements in partnership with key Federal 
agencies, including CISA, and to drive adoption within Cisco 
and by our industry peers.
    In conclusion, I want to thank you for the opportunity to 
testify today and provide Cisco's views on these important 
topics. Together we need to further improve baselines for 
software security including open source software. We 
collectively need to improve our speed and efficiency at 
finding and fixing problems when they arise, and together we 
need to boost our resilience against attacks, particularly as 
we work to develop, distribute, and apply software patches and 
mitigations.
    Chairman Peters. Thank you, Mr. Arkin.
    Our next witness is Jen Miller-Osborn. She currently serves 
as the Deputy Director of Threat Intelligence of Unit 42, Palo 
Alto Networks, the research arm of the cybersecurity company 
that works to solve some of the world's most challenging 
problems. In her role, she manages a team tasked with 
detecting, identifying, and differentiating between cyber 
espionage and cybercrime actors.
    Ms. Miller-Osborn has almost two decades of experience in 
cyber threat intelligence and regularly briefs all levels of 
government and the private sector, and has influenced national 
cybersecurity policies. She is also a veteran of the United 
States Air Force (USAF).
    Welcome, Ms. Miller-Osborn. You may proceed with your 
opening comments.

 TESTIMONY OF JEN MILLER-OSBORN,\1\ DEPUTY DIRECTOR OF THREAT 
           INTELLIGENCE, UNIT 42, PALO ALTO NETWORKS

    Ms. Miller-Osborn. Thank you, Chairman Peters.
---------------------------------------------------------------------------
    \1\ The prepared statment of Ms. Miller-Osborn appears in the 
Appendix on page 48.
---------------------------------------------------------------------------
    Chairman Peters, Ranking Member Portman, and distinguished 
Members of this Committee, I am honored to appear before you 
today to discuss the impact and scope of the Log4j 
vulnerability. My name is Jen Miller-Osborn, and I am 
privileged to be a senior leader on the Unit 42 threat 
intelligence team at Palo Alto Networks.
    For those not familiar with Palo Alto Networks, we were 
founded in 2005, and have since become the global cybersecurity 
leader. We serve more than 85,000 enterprise and government 
organizations, protecting billions of people, in more than 150 
countries. Practically speaking, this means that we have a deep 
and broad visibility into the cyber threat landscape. We are 
committed to using this visibility to be good cyber citizens 
and integrated homeland security partners with the Federal 
Government.
    I am happy to dive into technical details during the 
questioning period, but first I wanted to take a step back for 
a second and think about why we are here.
    If it feels like Log4shell is just the latest in a strong 
of vulnerabilities that the cyber community must rally in 
response to, you are right. That is why it is important to look 
at Log4shell both as a standalone vulnerability that demands 
discrete analysis but also in the broader context of a rapidly 
evolving cyber threat landscape. Log4shell is not the first 
national-level vulnerability, and it certainly will not be the 
last.
    I cannot stress enough the foundational importance for 
every organization to accurately understand the size of their 
internet-exposed attack surfaces. If you do not see the 
totality of your digital footprint through the eyes of the 
adversary, then your security baseline is inherently 
incomplete. Since you cannot secure what you cannot see, your 
ability to respond to any vulnerability, whether it has a 
sophistication of Log4shell or is more elementary, it is 
limited if you do not already establish this common operating 
picture.
    I expect a robust conversation today about operational 
collaboration, what CISA Director Jen Easterly has described as 
turning information sharing into information enabling. Coming 
from a military background myself, I am hardwired to serve a 
common goal. Our company shares this spirit, and I have found 
this to be the norm across the cybersecurity community. We are 
all truly in this together.
    The Joint Cyber Defense Collaborative sparked by 
congressional leadership from many of you in this room, is a 
promising collaboration body of which we are proud to be a 
founding alliance member. Its structure provided a body to 
scramble a snap call on Saturday afternoon, after Log4shell 
emerged, to allow industry competitors to act as partners with 
the government to share raw situational awareness, and we must 
continue building upon this partnership.
    I am also proud that one of my colleagues, Wendy Whitmore, 
was selected just last week to serve on DHS's Cyber Safety 
Review Board, whose first tasking will be Log4shell focused. 
Log4shell has sparked a necessary conversation about open 
source software security. While others on this panel are closer 
to that community than I am, I think it is worth pointing out 
that the cyber Executive Order from last May teed up a series 
of workstreams tackling parts of this issue, so these 
conversations are thankfully not starting from scratch.
    As we have these conversations, we cannot lose sight of key 
security pillars that we know reduce risk. These include 
accurately understanding your attack surface through the eyes 
of the adversary, as I mentioned earlier; promoting common 
visibility across cloud, endpoint, and on-premises systems, so 
not having data silos; driving industry adoption of development 
security operations, or DevSecOps best practices; automating 
security orchestration wherever possible, particularly as it 
relates to vulnerability management, incident response, and 
compliance; and yes, also the well-trodden cyber hygiene basics 
that we know work. We know the consequences. As a society, we 
have to stop driving around without our seat belts on in 
cyberspace.
    A quick glance at cybersecurity headlines provides 
reinforcement why all of this matters. Between geopolitical 
tension, the ongoing ransomware threat, and the steady drumbeat 
of cybercrime, the threat landscape that I spend every day 
analyzing demands maximum vigilance.
    Palo Alto Networks appreciate this Committee's sustained 
bipartisan interest in cybersecurity policy. I look forward to 
your questions as we explore these topics further. Thank you.
    Chairman Peters. Thank you, Ms. Miller-Osborn.
    Our final witness is Dr. Trey Herr. Dr. Herr is the 
Director of the Cyber Statecraft Initiative under the Scowcroft 
Center for Strategy and Security at the Atlantic Council, where 
his team works on cybersecurity and geopolitics.
    His work centers on a broad span of topics ranging from 
cloud computing and supply chain policy to the security of the 
internet and cyber effects on the battlefield. He is also 
working to build a more capable cybersecurity policy workforce.
    Prior to his work at the Atlantic Council, Dr. Herr was a 
senior security strategist with Microsoft as well as a fellow 
with Belfer Cybersecurity Project at Harvard Kennedy School.
    Welcome, Dr. Herr. You may proceed with your opening 
remarks.

 TESTIMONY OF TREY HERR, PH.D.,\1\ DIRECTOR, CYBER STATECRAFT 
  INITIATIVE, SCOWCROFT CENTER FOR STRATEGY AND SECURITY, THE 
                        ATLANTIC COUNCIL

    Mr. Herr. Let me join the other witnesses in expressing my 
appreciation to this Committee for the invitation and share my 
particular thanks to you, Chairman Peters, and to you, Ranking 
Member Portman, along with your staff for making this topic a 
priority.
---------------------------------------------------------------------------
    \1\ The prepared statement of Mr. Herr appears in the Appendix on 
page 54.
---------------------------------------------------------------------------
    The security of software, including open source, is one of 
great importance for this country's national security and 
economic vitality, but it poses challenges to you as 
policymakers. The open source ecosystem, the long-essential 
pillar of software use and development, is still a relatively 
nascent domain of policymaking, and its core values of 
decentralization and open cooperation can make traditional, 
more centralized models of security very difficult to implement 
successfully.
    Our understanding of harm in cyberspace also understates 
the influence of a vulnerability like that found in Log4j. 
Rather than a flaw leading a compromise of a handful of 
targets, this was effectively a crack in the foundation of our 
software infrastructure. The Log4j incident is notable less for 
enabling some novel harm and more for the difficulty of finding 
and patching this flaw across tens of thousands of 
organizations and different pieces of software.
    But even Log4j is not exception. Software supply chains, 
both open source and proprietary, have been victim to and 
remain vulnerable to widely exploited flaws.
    My name is Trey Herr. I run the Cyber Statecraft Initiative 
at the Atlantic Council, a nonpartisan think tank founded here 
in Washington, DC, in 1961. For the past two and a half years, 
my team and I have studied the security of software supply 
chains, cataloging more than 160 attacks and vulnerability 
disclosures going back 11 years. In that time there have been 
41 separate attacks or vulnerability disclosures against open 
source code.
    The most disconcerting trend in this data is the 
consistency with which these attacks occur against sensitive 
portions of our supply chains. This is not a new problem. A 
2010 report from Carnegie Mellon University's Software 
Engineering Institute profiled the Defense Department's (DOD) 
concern about vulnerabilities buried deep in software and 
exploited by malicious partners, and indeed we live that 
reality today.
    The track record of software is one of insecurity, no 
different for open source and proprietary code. Our discussion 
should today look beyond the intricacies of a single incident. 
Open source is used by nearly every organization on the planet, 
and even the vast majority of proprietary or paid-for software 
integrates open source in some way. Yet the way we plan for the 
security of this code does not match the depth or diversity of 
use across society.
    I would suggest to this Committee that while the bulk of 
our discussion may involve the intricacies of technology and 
cybersecurity, our ultimate topic is innovation and the shared 
infrastructure which makes it possible. Our task should be to 
ensure the long-term viability and security of open source as 
it enables important and widely used technologies.
    In working to support this infrastructure and improve its 
long-term health, our goal should not be to ``fix'' open 
source, for open source is not broken. Rather, our task should 
be to organize the U.S. Government as a better partner for open 
source communities and to invest in their shared 
infrastructure.
    Trust in software is not built in isolation. It would be a 
mistake to equate software supply chain attacks to a novel 
weapon system in some opponent's arsenal. They are 
manifestations of opportunity, attacking secure targets by 
compromising weaknesses in their connected neighbors, and their 
vendors, and in the software they depend on.
    Our challenge is to grow the awareness of the importance of 
this infrastructure inside of a maturing Federal cyber policy 
architecture, to enable risk assessment of software supply 
chains that respond to these national and international 
priorities and to support the long-term health of the open 
source ecosystem, recognizing it as the infrastructure that it 
is.
    There is little in this task that can be done alone. There 
are members of the software technology industry and advocates 
across civil society hard at work better securing open source 
software and pursuing efforts to make structural improvements 
to the way we govern the security of these code bases.
    Software, especially open source, is not developed by one 
country. It is developed and consumed globally. We need look no 
further than the headlines covering Ukraine to recognize the 
need for not only the United States but our allies to have 
secure, reliable, and resilient technologies. The United States 
has natural partners around the globe in this effort.
    The key for this body and a watchword for policy efforts 
then is to improve the security of open source. It is to fund 
the mundane, provide resources where industry might not or 
where public attention fades, and drive structural improvements 
in the security of open source software.
    Thank you again for the opportunity to speak with you 
today. I look forward to your questions and the discussions 
with this group.
    Chairman Peters. Thank you, Dr. Herr.
    We will now go to questions. I will actually defer my 
opening questions to Senator Padilla, who I know has to preside 
before the full Senate.
    Senator Padilla, you may proceed with your questions with 
my time slot.

              OPENING STATEMENT OF SENATOR PADILLA

    Senator Padilla. Thank you, Mr. Chair. I appreciate the 
flexibility in accommodating the schedule, because this is a 
very important topic before us today, I think the variety of 
questions today will spotlight.
    I approach this with some relatively recent experience and 
conversations about the role of open source technologies in the 
election space. Many people who want to really digest the 
integrity of our elections broadly are focused on the integrity 
of voting systems and underlying technologies which are 
primarily closed source, a movement to advance open source 
voting systems for purposes of transparency and public 
confidence in that unique sector.
    But I appreciate the opportunity to weigh in in this 
hearing. At the end of the day, one of the fundamental 
questions that we can ask is what can Congress and the Federal 
Government do to help address any underlying vulnerabilities 
that exist within the open source ecosystem. But beyond what 
government can do, I think it is also important to ask what is 
industry doing and what more can industry do.
    As you all know, much of our software ecosystem is built on 
the use of open source code. Large companies, including but not 
limited to Cisco and others, are able to grow themselves and 
their proprietary products because of the work done through 
open source collaboration. One concern with this type of model 
is that it can potentially lead to a free-rider problem. What 
does that mean? That means that companies can reap massive 
benefits from open source software that collaboration makes 
possible without necessarily any obligation to contribute to 
its development or maintenance, or in situations like we are 
discussing today, remediation.
    I understand that that is not every company and that many 
companies actually do make sizable contributions to collectives 
like Apache and Linux and others that help maintain some open 
source software products. But it is not every company that does 
so.
    I would like to ask each of you, actually, in your opinion 
is private industry doing enough to help develop, maintain, 
and, when necessary, remediate the open source ecosystem, and 
what more should we expect our private companies to be doing to 
ensure that open source can remain a collaborative, 
decentralized system?
    Mr. Nalley. Thank you, Senator Padilla. It is an 
interesting question and one that has been discussed for a 
number of years in the open source community, specifically that 
free-rider problem. The Apache Software Foundation takes the 
point of view that we do not require, and we do not ship out 
software with any obligation to contribute back, and our 
mission is to distribute software free of charge for the public 
to use. we consider it accomplishing our mission when it is 
broadly used.
    We believe that enlightened self-interest will inform 
industry to begin contributing, and indeed in response to this 
we are seeing greatly increased contributions around security 
auditing and code validation in the Log4j and a number of other 
open source projects.
    I do think that incidents like this will continue to 
enlighten the industry, that they have their own self-interest 
to protect. by doing so that the easiest way to do that is to 
contribute to open source.
    Mr. Arkin. I echo what David was saying. I think one of the 
things that really encourages good behavior here is that if you 
had a free-rider situation where a company is getting a lot of 
benefit from a project and not contributing back in an optimal 
manner, another company can come in and start making those 
contributions to better steer the project in a direction more 
suited to their interests. Then it tends to create competitive 
pressures that encourages everybody to participate and 
contribute in a way that is going to lead to an optimal outcome 
for what they are trying to drive.
    The dynamics within the open source projects and the 
ability for anyone to show up and contribute, and when it is in 
their own interest to do so, to step up their contributions and 
allocate resources to best steer the project in a way that is 
going to match their desired outcomes.
    Senator Padilla. You think there are also sufficient 
incentives for that contribution?
    Mr. Arkin. I think these incentives exist today, and it 
tends to drive resource allocation decisions by companies that 
are participating with these open source project.
    Senator Padilla. OK. Thank you.
    Ms. Miller-Osborn. I have a slightly different viewpoint of 
that. I think Log4j for this is really serving to highlight 
that this is a problem that is not going to go away. This is 
not an open source problem. This is inherently that software 
will have vulnerabilities regardless of whether or not it is 
proprietary open source, and there will also be the potential 
for those to be found and exploited by attackers. It serves to 
highlight the need to do a shift-left in security posture, to 
move to more of a zero-trust architecture, where we are 
acknowledging that these things could happen at any given time. 
We need to have more robust protections in place where we 
assume compromise at a base level and then work to be able to 
quickly isolate those systems and remediate them and work on 
them when situations like this arise.
    I think this past year, year and a half we have seen with 
Log4j and SolarWinds and the Microsoft Exchange 
vulnerabilities, we have seen that the cyberthreat landscape, 
as a whole, is shifting to this being a more commonplace event, 
and that means from a security posture we need to shift as well 
to be able to address that.
    Senator Padilla. Thank you. Mr. Herr, if you are still with 
us?
    Mr. Herr. I would concur with David in saying that software 
in the open source space is offered as is, without an 
expectation of payment. I think that should remain so. Industry 
has already recognized it is in their self-interest to invest 
in the security and the health of this infrastructure in the 
long term.
    There is more that industry can do, but as it stands at the 
moment industry efforts already vastly outstrip Federal support 
for this infrastructure. I think that calling for action on 
both sides is admirable.
    Senator Padilla. Thank you to each of you, and thank you, 
Mr. Chair. Thank you again for the courtesy.
    Chairman Peters. Thank you, Senator Padilla.
    Ranking Member Portman, you are recognized for your 
questions.
    Senator Portman. Great. Thanks, Mr. Chairman. I appreciate 
the great testimony we have had today, and all the experts 
being here. We need your help badly.
    I noticed, Ms. Miller-Osborn, you said you appreciate the 
fact that this Committee has worked in a bipartisan way to both 
identify the problem, and you said showed interest and to 
actually pass legislation. That is our goal. This is not a 
partisan issue. This is one that is a threat to all of us, if 
we do not figure out a better way to deal with it, and we have 
this immediate issue of Log4j. But it is not new, as we have 
said repeatedly, and we need to, among other things, use best 
practices.
    You mentioned the Joint Cyber Defense Collaborative. That 
stemmed from an authority that we here in Congress gave CISA, 
and I am glad to see you think it is working. So do we. We 
think it has brought the private sector in, in ways that are 
appropriate to provide those best practices.
    In terms of best practices, Mr. Arkin, I want to talk to 
you for a second about what Cisco did and how it applies to 
some of your customers. First of all, does your company have a 
sense of how many and which of your customers have applied the 
patch to Cisco products that they own?
    Mr. Arkin. When it comes to the question of patch update 
adoption, when it comes to our on-premise products, the big 
focus for us is to make sure that we are communicating 
transparently about the status of each of the products that we 
have and is it vulnerable or not, and then regarding patch 
availability, how to get that patch and apply it.
    We were able to ship all of the updates relevant for this 
Log4j vulnerability for the on-premise products that we ship to 
our customers within about two weeks of when the vulnerability 
was first publicly announced. Once we get that information out 
to our customers, for the on-premise products it is up to our 
customers to then take that and apply it within the patch 
maintenance windows that they have, according to their risk 
profile of how the technology is deployed in their environment. 
That is not something that we track. It is something that we 
make available to the customers and then it is up to them to 
then take it and apply that where it makes sense within their 
risk management framework.
    Senator Portman. Yes. That is one of the challenges here is 
that my understanding is companies have to develop their own 
patches for their own products. Correct? So there is not 
necessarily a one-size-fits-all approach here. My hope is that 
Cisco will continue not just to provide those products but to 
encourage people to use them and help them through that 
process.
    How long did it take for you to identify potentially 
vulnerable products?
    Mr. Arkin. When the information was first released we 
worked with our internal insights into our source code and the 
products that we are responsible for maintaining, and we 
developed an understanding of where we have Log4j within the 
code base of the different products that we ship.
    In some cases, the instance of Log4j was bundled into a 
larger component which was upstream from us, with some supplier 
in between. In each of these cases we need to understand where 
does Log4j exist, is it in part of the active code path or is 
it in a dormant, dead section of the code, and then where it is 
relevant, where do we need to make those fixes.
    We got the information about Log4j Thursday night, which I 
think is December 9th, and then by the weekend, Saturday/
Sunday, we had a good picture of where we thought Log4j was 
relevant within the code base, and we maintained a webpage, 
publicly facing, where we were providing updated information 
for our customers so they could see what was confirmed as not 
affected, confirmed vulnerable, and if it was vulnerable, what 
the patch schedule was, and if the patch has been released, 
where to go to download it.
    I would say within about 72 hours we had a good sense of 
where we needed to make change within the code.
    Senator Portman. Were you already patching within 72 hours?
    Mr. Arkin. Some products, yes. Some products were patched 
within 48 hours. And within 72 hours I think we understood 
where all of our patch requirements would be, and then it took 
us another 10 days or so to get those patches published for our 
customers.
    Senator Portman. Your experience needs to be applied 
elsewhere, and that is remarkable and fast, and my hope is, 
again, your customers are getting your assistance to do it 
quickly as well.
    With regard to cyberthreat coming from Russia, Ms. Miller-
Osborn, Russian cyberattacks against Ukraine are a threat right 
now. We also have threats here in the homeland. We have seen 
this over time with regard to Russian-based cyberattacks.
    Actually I was in Ukraine recently, just a few weeks ago. I 
was briefed by members of the Ukrainian government about some 
of these attacks and their need to bolster their cyber defenses 
and resiliency.
    Let me ask you this. You just put a report out on the 
cyberthreat landscape between Russia and Ukraine. Can you give 
us a very brief summary of what that report said and also 
provide that report to the Committee?
    Ms. Miller-Osborn. Yes. We can totally provide the report 
to the Committee.\1\ The summary would be that due to the 
ongoing situation we decided to take a look at what is 
historically one of the more active groups attributed to 
Russia, which is Gameredon, and what we found were active 
campaigns targeting entities in the Ukraine over the past 90 
days, trying to compromise them and get malware into the 
systems for the likely purpose of espionage.
---------------------------------------------------------------------------
    \1\ The Cyber Threat Landscape Report appears in the Appendix on 
page 65.
---------------------------------------------------------------------------
    Because we found this recent activity we worked very 
closely, both with our JCDC and other government counterpoints 
within the intelligence community (IC) to make sure they were 
aware of the same thing that we were seeing, and we also worked 
closely with the Cyber Threat Alliance (CTA), which we are a 
founding member of. It is essentially a group of competitors 
that have recognized that sharing threat intelligence between 
organizations is critical to really get an understanding of 
what the adversaries are doing on a global scale.
    In advance of publication we shared it with everyone that 
we have partnerships with so they could take action and already 
have protections in place and be working on it, and then we 
went ahead and released it to the public so that everyone, or 
anyone that might be in this kind of position, could make 
educated decisions on what they needed to do to be safe. We 
provided actionable Indicators of Compromise (IOCs) and data 
from attacks happening over the last 90 days for them to use 
for hunting in their own environments.
    Senator Portman. Well that is very helpful, I am sure. That 
is concerning, what you are saying about these attacks, and let 
us just be clear. You are talking about critical infrastructure 
in Ukraine--is that accurate?---as well as governmental 
entities are under attack, cyberattack, right now?
    Ms. Miller-Osborn. Yes. Governmental organizations and 
other critical infrastructure.
    Senator Portman. Yes. One serious concern we have, of 
course, is the possibility of more cyberattacks against the 
United States in response to the United States doing things 
like applying sanctions, which many of us believe are 
necessary, particularly should Russia make a big mistake and 
invade Ukraine.
    What can we do more here to be sure that those potential 
cyberattacks on critical infrastructure find a coordinated both 
defense and offense on our side?
    Ms. Miller-Osborn. From my perspective, as a threat 
researcher, what we are doing with the JCDC and the 
partnerships there is really critical to make sure all of the 
stakeholders who come to the table, to be able to do exactly 
what we did for Log4shell, where we were able to convene 
quickly with all of the people that needed to be at the table 
and share actionable data for these sorts of things as it moves 
forward.
    For anything else past that, sanctions and things like 
that, that is totally not my area of expertise. I leave that to 
the lawmakers. I am very focused on being able to make sure 
that we can share actionable intel with the organizations who 
need it to be safe.
    Senator Portman. My time has expired, but I want to thank 
you for what you are doing every day in your organization. My 
sense is that we need to be much better prepared, not just 
because of these existing issues we are talking about today, 
with regard to open source software, but with regard to the 
reality that we are going to be subject to more and more 
cyberattacks, and perhaps an intense effort at doing that from 
Russia, that we need to be ready for.
    Thank you for working with the governmental sector and also 
with the private sector, and with this Joint Cyber Defense 
Collaborative to ensure we have that capability.
    Thank you, Mr. Chairman.
    Chairman Peters. Thank you, Ranking Member.
    It is clear this vulnerability has exposed potentially 
thousands of organizations to cyber criminals and foreign 
adversaries, some of whom I think we have already been taking 
advantage of this, including reports that the Russian 
Federation has exploited Log4shell to attack Ukrainian systems.
    The intelligence community has warned that the Russian 
government may perform similar attacks against the United 
States in response to our support for Ukraine, and certainly I 
am concerned that there is no way to fully understand who has 
been victimized by Log4shell because there is no comprehensive 
reporting in place, unfortunately.
    Ms. Miller-Osborn, my question is for you. We moved 
legislation earlier this year out of Committee and are now 
putting it forward to be considered by the full Senate, that 
would require critical infrastructure to report substantial 
cyber incidents to CISA, who would be required to properly 
scrub and share such information back with the public. My 
question is how would this legislation, if enacted, help 
improve threat intelligence and help companies protect 
themselves?
    Ms. Miller-Osborn. From a threat intelligence perspective 
there is real policy benefit from sharing cyber incident 
information, especially if CISA is able to then provide 
bidirectional benefit. The legislation, of course, would need 
to be carefully crafted to avoid unintended consequences, but 
we appreciate the Committee's bipartisan support and commitment 
to listening to that feedback and working to ensure that the 
legislation is as accurate and useful as it can be for everyone 
involved.
    Chairman Peters. Thank you. Dr. Herr, from your perspective 
could you discuss the benefits of incident reporting and the 
subsequent analysis and warning provided by CISA to other 
companies that would occur as a result of it?
    Mr. Herr. Senator, I think the incident reporting 
requirements, as have been discussed and proposed, would add to 
CISA's ability to understand not just long-term trends in 
cybersecurity threats but potentially threats across industry 
sectors, where there might be silos in reporting at the moment.
    In addition to the incident reporting, though, there is 
opportunity for an entity to be created to really take the 
long-term analytic task of understanding what those incidents 
and trends in incidents tell us over time. I was encouraged by 
the amount of discussion and debate given in this body to the 
Bureau of Cyber Statistics (BCS) last year, and hope to see 
that incident reporting is discussed in the framework of an 
additional analytic capacity in the future.
    Chairman Peters. Ms. Miller-Osborn, recent reporting 
suggests Russia used the Log4shell vulnerability against 
Ukrainian government where they saw over 70 government websites 
manipulated with threatening propaganda messaging. In your 
testimony, you mentioned that you have identified cyber 
criminals using this vulnerability to illegally assess victim 
computers for ransomware attacks.
    Who is exploiting this vulnerability and to what end, if 
you could tell the Committee, please?
    Ms. Miller-Osborn. From the visibility that I have, the 
primary exploitation that we have seen are coin mining, which 
is where someone installs a malicious piece of software on a 
system to mine cryptocurrency. That typically flies under the 
radar, because, it does not really take over a system. It does 
not crash a system, so often it is something that people do not 
pay a lot of attention to. We have also seen ransomware attacks 
using this.
    What I want to note is a lot of times people discount coin 
mining because it does not do anything big. It does not take a 
network down. It does not necessarily impact computing power. 
But it is a security problem in the sense that this is still 
malicious software that has now been installed on a system 
without your knowledge and without your approval. That means 
that if it can be exploited for a coin miner it can just as 
easily be exploited for other purposes. It serves to highlight 
why it needs to be patched, even if, we are not necessarily, at 
least from our visibility, currently seeing a ton of nation-
state attempted exploitation.
    Chairman Peters. Would you follow up? Could you discuss why 
we have not seen a major attack yet, in your estimation, or is 
it simply we just do not know about it yet?
    Ms. Miller-Osborn. From my perspective, based on the 
visibility that I have, we were able to react and move very 
quickly to protect our customers when it came to this 
vulnerability. The only real visibility my time has into this 
is the scanning that is taking place where entities of all 
sorts of motivations are trying to exploit this vulnerability.
    The difficulty becomes, because protections are in place so 
quickly, we are not seeing that follow-on exploitation where 
that is when you could figure out who is behind it. That is 
when either a ransomware payload would be dropped or some other 
sort of nation-state, espionage-related malware, and that is 
where you could tease out that is who that was.
    Right now, from our visibility, all I am seeing is mass 
scanning all over the internet for this, but that makes a lot 
of sense when you consider the number of people trying to 
exploit it and the fact that this has been incorporated into 
internet-of-things (IoT) botnets, which just randomly scan the 
internet for this constantly, so the volume is very high. But 
the fact that it has been adopted by botnets as well serves to 
highlight that this vulnerability is never going to die. It is 
going to be scanned for years on the internet, with people 
attempting to exploit it if they can find vulnerable systems. 
It really points to why this is so critical to be taken care 
of.
    Chairman Peters. It is clear that in the immediate days and 
weeks after the disclosure of the Log4shell, the cybersecurity 
ecosystem certainly went into high gear to identify the scope 
of this risk and to quickly remediate it.
    Part of this effort was extensive sharing of cyber threat 
intelligence and part through CISA's Joint Cyber Defense 
Collaborative. I know a similar question was asked of Ms. 
Miller-Osborn, but I would like to ask this of you, Mr. Arkin. 
As a participant of JCDC trying to address this vulnerability 
for yourself and for your clients, how do you believe CISA did 
in this case? What was your assessment of their actions? What 
more do you believe Congress needs to do to support these 
efforts?
    Mr. Arkin. Yes. The information-sharing that happened 
through JCDC definitely added value to our efforts. The key 
thing for us, when there is an infinite number of things you 
could be working on, how do you prioritize your efforts to 
where the bad guys are actually exercising and preparing to do 
bad things to your environment?
    The information that we got through JCDC helped us to 
understand the techniques and attacks that were being observed 
in the real world so that we could then marshal our resources 
in defense of that.
    The thing, I think, that is most important when I think 
about threat information-sharing, in partnership with 
government, is keeping the classification level as low as 
possible. If I go into a briefing that is at a very high 
classification level, if I cannot share that information out to 
the rest of my company I am not going to be able to put it to 
its full effect. Keeping things at the unclassified or for-
official-use-only level is going to allow us to most rapidly 
push the information out to the people who can put it to work 
in a defensive manner in our environment.
    Chairman Peters. Right, and thank you, Mr. Arkin.
    I need to step away briefly to ask a question at the Senate 
Armed Services Committee (SASC). I will be turning the gavel 
over to Senator Hassan.

              OPENING STATEMENT OF SENATOR HASSAN

    Senator Hassan [Presiding.] Thank you all very much.
    I will start by thanking Chair Peters and our Ranking 
Member Portman for this hearing and to all of you for 
participating in it. I am very grateful for your expertise.
    I want to start with a question to Ms. Miller-Osborn and 
Mr. Arkin. In your testimony, you each commented on how helpful 
the Joint Cyber Defense Collaborative, which brings together 
Federal and private sector cybersecurity stakeholders was in 
accelerating responses to the Log4j vulnerability. However, as 
I asked Director Easterly at a hearing last September, I am 
also interested in how the Joint Cyber Defense Collaborative 
could help strengthen the cybersecurity of entities that tend 
to have fewer cybersecurity resources, such as hospitals, 
schools, and small businesses.
    Can you both comment on if and how the Joint Cyber Defense 
Collaborative was able to help under-resourced entities with 
the Log4j vulnerability and how you see the collaborative 
evolving to better support under-resourced entities, moving 
forward?
    we will start with you, Ms. Miller-Osborn.
    Ms. Miller-Osborn. Sure. Thank you. I see the JCDC as a 
convening body to serve as a bit of a clearinghouse for giving 
effective guidance geared toward, these mid-to lower-sized 
businesses good advice on the things that they need to 
prioritize from a protections perspective, because that can 
vary quite a bit when you have a much smaller organization and 
a much smaller budget.
    I see JCDC as a good way to develop these guidelines and 
then be able to share them back out with industry, because they 
will be coming from not only the government background for it 
but also the vendor perspective for it, so that we can really 
have these best practices that we develop cohesively to help 
give formal, strong guidance to these organizations so they can 
understand what they need to do. Because that often is a big 
component too. They are not necessarily resourced to have an 
expert come in and help them and evaluate it.
    I see them as a body to be able to put together that sort 
of guidance to help those organizations understand what they 
need to do in a prioritized manner.
    Senator Hassan. Thank you. Mr. Arkin.
    Mr. Arkin. Yes. From my role as a defender, nothing is more 
tragic than inefficiency and misdirected resources. I think the 
work that CISA is doing to make it clear, if you are going to 
do one thing you should patch these particular vulnerabilities 
that are being actively exploited, and that prioritization, in 
order to help defenders understand where to focus their 
efforts. There are an infinite number of bugs out there, but 
focus on this short list. Then if you have time to do 
defensive, proactive improvements and investments, things like 
multifactor authentications, zero-trust network architecture, 
these are other pieces of advice that CISA is offering, which I 
think really sharpens the focus for organizations onto things 
that will be most impactful.
    Senator Hassan. Thank you. I have another question for you, 
Ms. Miller-Osborn. In your testimony, you emphasized the 
importance of network visibility, that is knowing what is on 
your network so you know what you are defending. I strongly 
agree, which is why I supported the Federal Continuous 
Diagnostics and Mitigation Program (CDM), so that the Federal 
Government can know everything that exists on its networks.
    Do you think it would be helpful if CDM included a pilot 
program to assist State and local entities working to improve 
visibility on their networks to help identify vulnerabilities 
like Log4j?
    Ms. Miller-Osborn. I think anything that we could do to 
provide that level of guidance, especially at a cohesive level, 
would be good and helpful, especially as the cyber threat 
landscape can change so quickly, even, guidance that was 
potentially given two, three years ago now really needs to be 
updated. I do think there would be a good resource for that.
    Senator Hassan. Thank you. I think one of the challenges 
small businesses and small government entities have is a dearth 
of expertise or staff on board to really enact this kind of 
visibility or, provide the programs to let them see their whole 
network and what is on it. Thank you for that response.
    Mr. Nalley, larger, better-resourced software companies are 
generally able to detect and remediate the Log4j vulnerability 
in software applications that they develop. However, smaller 
developers are less likely to do so because many do not 
regularly check to see if the software they used in developing 
their own applications has security issues, which may leave the 
software applications that they produce vulnerable. This 
underscores the importance of notifying anyone using a piece of 
open source software of a severe vulnerability.
    Mr. Nalley, moving forward what is the Apache Software 
Foundation doing to better notify smaller developers that use 
Apache's open source software of security vulnerabilities?
    Mr. Nalley. Thank you, Senator. There are a number of 
methods that we use today to communicate around updates and 
security vulnerabilities. Those include the National 
Vulnerability Database that is run by National Institute of 
Standards and Technology (NIST) and using formats developed out 
of MITRE, the Common Vulnerabilities and Exploits message, to 
make that machine readable and easily parsable to automation.
    Our hope is that especially with initiatives like software 
bill of materials, where developers can gain a better 
understanding of what open source packages and components they 
have consumed in their applications, that they will have a 
better understanding both of their threat landscape and have 
easier access to remediation information as part of that.
    Senator Hassan. Thank you. Do any of the other witnesses 
want to comment on how we can proactively notify users of open 
source software about their vulnerabilities?
    Mr. Arkin. Something that I can echo is the potential for 
the software bill of materials and other automation tools in 
order to make it easier and lower the friction for people to 
have insights into their code base and what is happening 
upstream for the components that they rely on. This tooling, I 
think, has the potential to take what today requires a lot of 
human elbow grease and then make it an automated process, which 
has the chance to lower the costs for all involved.
    Senator Hassan. Thank you. Anyone else? I see you nodding, 
Ms. Miller-Osborn.
    Ms. Miller-Osborn. I agree. I do not have anything else to 
add, but I totally agree.
    Senator Hassan. OK. Our virtual guest, Mr. Herr, anything 
to add?
    Mr. Herr. No. I concur.
    Senator Hassan. OK. Thank you.
    Senator Lankford, are you ready to proceed? OK. With that I 
will turn it to Senator Lankford.

             OPENING STATEMENT OF SENATOR LANKFORD

    Senator Lankford. Senator Hassan, thank you very much. To 
the witnesses, thanks for being here and for the dialog.
    I have a question that is going to be your favorite 
question that no one can really answer, but we do need to have 
some serious conversation about it. It is my understanding that 
this particular vulnerability, the Log4j, it has been around 
since 2013. It was discovered just months ago, and it was 
discovered in China, and that the entity was then reprimanded 
by China on that.
    Here is my unanswerable question. What are the chances that 
this has actually been exploited since 2013 or 2014, and how do 
we go backwards to be able to determine how long this has 
really been exploited, and by who? What are the forensics of 
that and how do we determine how long this has been exploited 
before it was actually revealed, since it has been around for 
nine years?
    Ready, set, go. Who wants to take that first.
    Mr. Nalley. I will take it first, Senator. Thank you for at 
least acknowledging that it is an unanswerable question.
    Senator Lankford. Yes, it is.
    Mr. Nalley. I will say that we have observed no indication 
that this was exploited before it was disclosed to us. That is 
obviously not great evidence. The absence of evidence is not 
perfect. But we have seen no indication from our side that this 
was exploited prior to disclosure.
    Senator Lankford. OK. Other comments on that?
    Mr. Arkin. Whenever there is a new attack technique or a 
new exploit that is developed, once you get a sample and you 
see how it is used in the real world there is the potential to 
roll back in the logs and look for examples of where it might 
have been used previously. This is something where something 
becomes well known and understood and then you can go back in 
time and look to see. Basically as long as you have logs that 
go back then you can go and try to understand what is 
happening.
    Pulling out forensics images and things that might have 
been laying around from a while ago, it is just a question of 
do you have the automation to do that in a cheap way or is it 
something that you have to go back and review.
    From our telemetry, I think there were some indications of 
exploit prior to December 9th, but only a week earlier, back to 
December 2nd, and there was no indication that we have of any 
exploits that went earlier than that. That is something where 
you can go back from when you first learn of something and then 
ask the question, have we actually seen this before and it is 
sitting around on a log somewhere?
    Senator Lankford. When you talk about exploits you would 
say large scale, where you actually saw the result. This would 
not be necessarily that it was exploited on that device, 
malware was then implanted, and the malware has not been used 
yet?
    Mr. Arkin. The examples of exploit that our team at Cisco 
saw were not large scale, but I guess I would say small scale. 
And so things that show up in the logs, and I do not have the 
details about what they were used to achieve or which targets 
they were after. That is something I can work with my team and 
get back to the Committee on.
    Senator Lankford. I appreciate that, because again, we are 
trying to be able to determine long-term how long this has been 
around, other ways that it could have been used in the past, 
and places that it could be sitting where there is an exploit 
sitting there but it has just not been activated.
    Do you want to make any comments on this?
    Ms. Miller-Osborn. Yes. I think Log4shell serves to 
highlight why there are kind of standard vulnerability 
disclosures processes that exist, and highlights why we need to 
continue to ensure the integrity of those programs, just to 
make sure, it is very clear when they are logged and how the 
entire process is going before they are released to the public.
    Senator Lankford. OK. I am going to shift this a little 
bit, just in our conversations dealing with open source versus 
proprietary code. Obviously there are lots of challenges there 
and lots of benefits. Open source, lots of opportunity to be 
able, to continue to be able to build on it, to be able to use 
it in other ways. So that is a very good system.
    The challenge becomes if someone has nefarious plans to be 
able to build something in, to be able to put something that 
then could be exploited. What is the process for them just 
being able to evaluate that, because there is a lot of peer 
review on that, before it actually goes into an open source? So 
walk me through a little bit what that process is like.
    Mr. Nalley. In general, contributors to open source start 
by submitting either their idea or the actual code modification 
that they are trying to have included. That tends to be 
reviewed by the folks who are responsible for the project 
itself, and it is not uncommon for that to take weeks or months 
before inclusion, and it is inversely proportionate to the 
size. Smaller, easy fixes tend to be reviewed pretty quickly, 
and tend to be included quickly, because they are easy to 
review, frankly. The larger or the more esoteric of the change, 
the more heavily that is going to be scrutinized, the more time 
people are going to take, and it is not uncommon for that to 
spin up into months.
    It is a long-term evaluation. Because the code and the 
review are all happening in public, there is plenty of 
opportunity for additional outside inspection to happen, and it 
is not uncommon for someone who tends to be lurking around 
silently most of the time to say, ``Hey, have you thought about 
what the impact of this change is going to be?'' And so there 
is quite a heavy burden there.
    I will call out that there has been some academic study on 
this. There was a university who tried to inject malicious code 
into an open source project. It was not one housed at the 
Apache Software Foundation but it was another large, open 
source project. That was quickly spotted, and the entire 
university was essentially banned from ever participating in 
the project again.
    Senator Lankford. Do we know the process and how that 
worked for Log4j before and how the peer review happened at 
that point, to be able to look at it?
    Mr. Nalley. It was requested by a long-term, well-
experienced software developer who was known at Apache, in 
terms of wanting to enable to feature. The feature was reviewed 
by a core member of the project management committee and then 
implemented into the code.
    Senator Lankford. All right. I would assume there has been 
a conversation on lessons learned at this point of how we 
evaluate this, because a feature like this, that we then later 
learn, it also could be used for, is always the challenge of 
what else could be done with this that leaves us exposed to it.
    I guess when I go back to the lessons learned, how do we 
get creative and actually having an opportunity, as individuals 
peer-review this, to be able to determine yes, it does this, 
that is very helpful, it grabs the date, it grabs all those 
things, that is very helpful, but it also could grab something 
else in the days ahead?
    Mr. Nalley. It is important for context that some of these 
systems that we are talking about making use of in this 
particular feature were actually developed in the 1990s, which 
was a very different place, cybersecurity landscape. I do think 
that there were some unintended consequences.
    We have gone back and looked to see whether automated tools 
could have detected this vulnerability, and we have come to the 
conclusion that none of the automated tools on the market today 
would have done so, had they been looking either then or even 
very recently.
    It comes down to complex interoperation of multiple 
systems, because this required three different systems to be in 
place to achieve this vulnerability. I am not sure how we get 
around that without good understanding of those systems and 
good thinking of potential malicious uses.
    Senator Lankford. Yes. This will be an ongoing dialog for 
us for a long time, and trying to be able to figure out the 
``what else'' with this. I appreciate all your input. I really 
do. I am grateful for folks that are continuing to be able to 
think through the what-ifs of this and also to be able to look 
backwards and to be able to see, have we been exploited already 
and are just not aware of it yet.
    Thank you.
    Chairman Peters [Presiding.] Thank you, Senator Lankford.
    Senator Hawley, you are recognized for your questions.

              OPENING STATEMENT OF SENATOR HAWLEY

    Senator Hawley. Thank you very much, Mr. Chairman. Thanks 
to the witnesses for being here.
    Mr. Nalley, if I could start with you. I want to make sure 
I am right on the facts here. Am I right that the vulnerability 
was discovered by a Chinese researcher at Alibaba, who then 
reported it to your organization, that is?
    Mr. Nalley. Yes, Senator.
    Senator Hawley. Under Chinese law I understand the Chinese 
researcher, that is required to report the vulnerability to the 
Chinese government. Is that right? Is that your understanding?
    Mr. Nalley. That is the reporting that has occurred. I am 
not familiar on the specifics of Chinese law.
    Senator Hawley. Understood. Do you believe that the 
researchers reported it to Apache first and not the Chinese 
government first? Do we have any idea what the sequence was?
    Mr. Nalley. Based upon the reporting that has been in the 
tech press, my understanding is they reported it to us first, 
and then were subsequently sanctioned by the Chinese 
government.
    Senator Hawley. Do we know what the basis is for that 
belief? In other words, here is what I am asking you. Other 
than what you read in the press you do not have any idea, any 
basis for knowing one way or another.
    Mr. Nalley. Right.
    Senator Hawley. Is that right?
    Mr. Nalley. That is right.
    Senator Hawley. That is concerning, for obviously reasons. 
I mean, just looking at China's recent cyberattacks, The New 
York Times now reporting that China is this prime cyber threat 
to the United States. Of course, in 2020, a Federal grand jury 
charged four members of China's PLA for their role in the 2017 
Equifax hack, which the Federal Bureau of Investigations (FBI) 
called one of the largest thefts of personally identifiable 
information (PII) ever recorded. It was 145 million Americans 
affected there.
    Last summer, of course, China hacked Microsoft. In 
December, Chinese hackers breached four U.S. defense and 
technology firms, and last month a Chinese hacking group 
breached several German pharma and tech firms in an effort to 
steal intellectual property. Obviously, the Chinese government 
and affiliated groups are getting very active in this space.
    What do we know about any efforts by China to exploit the 
Log4j vulnerability? I noticed that the CISA director said that 
this vulnerability is one of the most serious seen ``in my 
entire career''--that is a quote--``if not the most serious.'' 
So do we know, do you know, Mr. Nalley, anything about the 
extent of China's attempts to exploit the vulnerability?
    Mr. Nalley. I do not.
    Senator Hawley. Does anybody else on the panel know about 
China's attempts to exploit the vulnerability?
    [No response.]
    Mr. Nalley, how many products use the Log4j code? Do you 
have any idea?
    Mr. Nalley. I have no insight into that. Unfortunately, our 
users are not required to enter into any contract to provide us 
with any contact information or tell us how or where or to what 
scale they are using them. It is unknowable by me.
    Senator Hawley. Do we have any estimates about the number 
of products that use Log4j, or how many have tried to download 
the patch, for instance?
    Mr. Nalley. My understanding is that CISA has maintained a 
database of affected software and affected hardware devices as 
well. The last time I looked at that list it was hundreds or 
maybe even thousand-plus entries into that database.
    In terms of patch adoption, I do not have a good sense of 
what that looks like across the ecosystem. I can tell you that 
talking to the folks who run Maven Central, which is where most 
of the Java developer ecosystem gets their open source 
components, they were still seeing, as of mid-January, they 
were still seeing roughly 30 percent of downloads being for a 
vulnerable version of Log4j. That is roughly, if I recall 
correctly, around 10,000 downloads per hour.
    Senator Hawley. Ten thousand per hour, 30 percent of which 
were vulnerable. Do we know what the latest number of attacks 
detected?
    Mr. Nalley. Ten thousand downloads per hour was of the 
vulnerable versions.
    Senator Hawley. I got you. Do we have any sense what the 
latest number of attacks detected is, do you know?
    Mr. Nalley. I have no insight into that, unfortunately.
    Senator Hawley. What about remedial action here? Obviously 
businesses can engage in best practices. What measures are you 
and others taking to scan for incidents of exploitation, rather 
than vulnerability?
    Mr. Nalley. The Apache Software Foundation is not taking 
any action to scan or try and detect exploitation.
    Senator Hawley. Is there any role that you think that 
Congress should be taking to help address this issue?
    Mr. Nalley. I do not claim to be an expert on what Congress 
should do. In general, I think the most urgent thing is that 
folks need to be urged to upgrade to a secure version of Log4j, 
and understanding the threat environment, being able to quickly 
determine if you are vulnerable is important, so software bill 
of materials might aid in that particular objective.
    Then the ability to quickly update. I said that we ought to 
encourage people to update the version of Log4j, but in general 
the software industry struggles with maintaining version 
currency. To the degree that we can build in faster remediation 
to all of our infrastructure, I think that will lead us to more 
secure outcomes.
    Senator Hawley. Mr. Arkin, let me come to you and in my few 
remaining moments here, in your written testimony you mentioned 
that this was hardly the first time that Cisco has had to 
respond to the identification of a new cyber vulnerability. In 
2014, the industry had a zero-day vulnerability called 
Heartbleed, I understand, which Cisco took 50 days to identify 
the full list of software that required remedial updates.
    With Log4j you were able to do that in 10 days, if I have 
my facts correct. Do you think that your 10-day response 
timeline is representative of typical of other companies, or 
only large companies? Give me some sense of what you think the 
industry picture is.
    Mr. Arkin. We have made a lot of investments to squeeze the 
timeframes down, where it took weeks before, and get it down to 
the 10 or 14 days that we did for this time around. Every time 
something like this happens is an opportunity to study the 
situation and see what we can do in order to squeeze that 
further. We are always looking for how we can optimize that.
    I think when you look across other parts of industry, there 
are plenty of organizations that can get in in a single-digit 
number of days, and then there are lots of other organizations 
that, for the things they know about, they might be able to 
patch relatively quickly, within weeks. But then that inventory 
management challenge of making sure you understand the full 
scope of what you are responsible for, that can be a real hard 
problem for a lot of organizations.
    Senator Hawley. I appreciate your testimony today. I have a 
few additional questions but I will give them to you for the 
record. Thank you for being here.
    Thank you, Mr. Chairman.
    Chairman Peters. Thank you, Senator Hawley.
    Senator Rosen, you are recognized for your questions.
    Senator Rosen. Thank you, Chairman Peters. Thank you for 
holding this hearing. I am really excited to hear everybody 
talking about software bill of materials. I appreciate all your 
answers because I think that this is a critical component to 
ensuring our future safety because as a former computer 
programmer my mind is just spinning here with all the questions 
I could ask.
    But I know from experience that software systems do involve 
complex and sometimes obscure supply chains. As the Log4shell 
vulnerability demonstrates, supply chains can provide just that 
point of entry for malicious cyber actors to exploit, and they 
are going to range from the cyber criminals to nation-state 
actors.
    To bring transparency to our supply chain and get ahead of 
the next vulnerability, President Biden's Executive Order on 
improving the nation's cybersecurity is pushing our Federal 
agencies to adopt the software bill of materials.
    I want to explain for everyone what an SBOM is. It contains 
the details on the supply chain relationships, but basically we 
have that in our lives every day. Look on the backs of any box 
of food in your pantry and you will see a list of ingredients. 
We look on any sweater you are wearing, or jacket that has a 
list of materials in your clothes, that is what a software bill 
of materials is, and we can go forward with that, and that can 
help us react more quickly to new vulnerabilities.
    I want turn, Dr. Herr, to Federal procurement. Should 
contractors with the Federal Government be required to submit 
an SBOM, because we want to require the software developers to 
contract with the government. We want to disclose the software 
packages that went into their final products. What do you think 
about that, Dr. Herr?
    Mr. Herr. Yes, Senator. Absolutely it should be a basic 
condition of doing business.
    Senator Rosen. Thank you. I appreciate that. I want to move 
on a little bit to talking about how we secure the open source 
software, because obviously, if you are a bad actor, if I leave 
my window open people are going to come in that way versus they 
are not going to break down my door. This open source software 
can really be a big point of vulnerability. There is rapid 
growth in open source software, and it really brings 
considerable advantages for companies. I know that reduced 
costs, faster adoption of software in Log4shell just 
demonstrates how this can pose unique challenges.
    To improve network security, I believe we have to have 
developers adopt a never-trust, always-verify approach where 
developers are actively thinking about what assets need to be 
protected, who needs access, under what conditions, and how the 
software they are developing can best operate in a zero-trust 
environment.
    To Ms. Miller-Osborn and Mr. Nalley, how can we help the 
open source community apply the zero-trust model in an 
effective way to try to close that open window, if you will? We 
will start with Ms. Miller-Osborn and then Mr. Nalley, please.
    Ms. Miller-Osborn. Thank you. It is a two-pronged question. 
What we are really looking at from this is more of the need for 
a shift-left approach and a shift to the zero-trust kind of 
architecture that you were talking about, because recognizing 
that this is not solely an open source security problem, this 
is going to be a software security problem, and no software 
package, no matter how well designed, is ever going to 
necessarily be perfect.
    We need to shift more to the assuming that at any given 
time a device on a network could be compromised, and then have 
good deterrence in place with multiple layers of protect so 
that when and if that does happen it does not have effect on 
the rest of your network. Because as we have seen, over the 
past year, year and a half, it seems to be a constant onslaught 
of new zero days across a range of software, not just things 
that were open source that we are having to respond to.
    It is less of a, in my opinion, the software components. It 
is more of a need for the security posture to understand that 
this is the cyber threat landscape that we live in now.
    Senator Rosen. Thank you. Mr. Nalley, do you have anything 
to add?
    Mr. Nalley. Thank you, Senator. I do think that it is a 
nuanced question. Specifically, a number of these components, 
these open source components, are building blocks, and they are 
written to serve a very specific purpose, but often the people 
who are writing that software do not have insight into how it 
will be used or where it will be used. I think that there are 
some missing pieces of context that might better inform the 
authors of the software if they understood it.
    Having users of the software come participate in open 
source communities would certainly add to that context and 
perhaps better inform our security posture.
    Senator Rosen. Yes, and I would add how we use open source 
software, whether we are calling it dynamically or statically, 
probably changes the threat landscape as it goes on to the 
ability to do future patches and maintenance, as it were.
    But we are going to need a lot of people to do these jobs, 
a lot of people to do these tech jobs. Our workforce, we know 
our cyber workforce is not where we need it to be. There are 
hundreds of thousands of open jobs across the country, about 
600,000 now, about 3,500 at least in Nevada alone, according to 
Cyberseek. That is a Federal Government job security jobs map.
    Last week I introduced the bipartisan Cyber Ready Workforce 
Act with Senator Blackburn. It is going to instruct the 
Department of Labor (DOL) to award grants to workforce 
intermediaries to develop apprenticeship programs, programs all 
across the board, to try to really buildup this workforce we 
are going to need to really address the threat landscape that 
we are facing.
    Again, Ms. Miller-Osborn, in the few seconds I have left, 
how do you think we can best expand our apprenticeship 
programs, our certificate, two-year programs, to fill and 
address these long-term cyber issues we are having and get 
people to work as quickly as possible?
    Ms. Miller-Osborn. Thank you for that question. I think 
those initiatives are key to this as well as a number of others 
that currently exist. I was absolutely honored and privileged 
to be a part of the program that we sponsored with the Girl 
Scouts to design the cybersecurity badges that will be one of 
the most proud things I have ever worked on, to get this 
started, when girls are young, when children are younger, so 
they feel comfortable growing up in this field. They are 
interested in it. This is something they want to do. We have 
classes more at younger ages. There are a lot of other 
organizations out there that we participate with that you can 
partner with. There is Women in Cybersecurity, Black Girls 
Code.
    There are a lot of organizations that look at doing 
networking and training and mentorship, to start bringing in 
people from the field, whether, it is at the girls in 
elementary school level all the way up through college, or it 
is people that are potentially looking for a second career and 
they want to get into cybersecurity, and they come into these 
organizations so they can start getting training and start 
getting mentorship and start learning the skills that they need 
to be brought into the field.
    I think diversity that is being created by taking these 
approaches is also critical, because that diversity is really 
what makes sure, informs that we are doing effective analysis. 
Everyone in the room cannot have the same background or you are 
not going to actually be able to understand the kind of threats 
you are facing, from a threat intel perspective.
    I think all of these things combined are really what we 
need to bring more people into the field.
    Senator Rosen. Thank you. I love hearing that. I just 
formed a Women in Science, technology, engineering, and 
mathematics (STEM) Caucus, to try to promote the very things 
you are talking about. I think it is really important. It was a 
great career for me. We have passed some bills, Building Blocks 
of STEM, and have quite a few others that we have done and are 
working on.
    Thank you for what you are doing, and, Mr. Chairman, I 
yield back.
    Chairman Peters. Thank you, Senator Rosen.
    Dr. Herr, as you are well aware, open source code is 
developed internationally and used internationally, and this 
vulnerability not only impacts American companies but it 
impacts critical infrastructure for our allies and partners all 
around the world.
    My question for you, sir, is do you have any 
recommendations for how the government, DHS, or CISA, 
specifically, should be working with foreign partners when 
widespread vulnerabilities such as the one we are discussing 
here today are discovered?
    Mr. Herr. Senator, thank you for the question. I could not 
underline more the importance that the United States' 
relationship with its partners and allies have to this issue. 
Two suggestions to you and to this Committee.
    The first is to empower CISA with a purpose-built open 
source security organization. This is something that we have 
advocated for as a point of contact with the open source 
community, which as Mr. Nalley and others have pointed out is 
globally distributed. I think it is something that would 
provide benefit both directly to the United States government 
but also to communities abroad.
    The second is to encourage that efforts to fund open 
source, these infrastructure investments we talk about, be 
driven forward in partnership with key U.S. allies in the 
European Union (EU) and in the Indo-Pacific.
    I think the underlying point for this discussion is that 
the consumption of open source, not only an issue for the 
United States, not only an issue for its close allies, but for 
the security relationships that we maintain abroad, the 
cyberattack surface that we are going to be forced to defend 
against adversaries is being shaped as we speak by these sorts 
of vulnerabilities. These kinds of long-term investments are 
not simply a protection for ourselves at home but actually an 
attempt to make the management problem, the security challenge 
that we face abroad, significantly easier as well.
    Chairman Peters. Thank you, and I certainly would like to 
thank each of our witnesses here today for joining us to 
discuss what is an incredibly important matter, and we look 
forward to continuing this discussion with you in perhaps other 
forms or in other ways as we work to address these 
vulnerabilities.
    Over the past year we have experienced cybersecurity 
attacks that pose a direct threat to our nation's critical 
infrastructure and the American way of life, and I believe that 
all of my colleagues on this Committee can agree that we must 
continue to be diligent and proactive to improve cybersecurity 
of our critical infrastructure, the government, and other 
private sector entities as well.
    Incidents like SolarWinds and the Colonial Pipeline attack 
continue to illustrate the need for us to secure our supply 
chains and improve software security. The impacts of widespread 
vulnerabilities need to be better understood, and we need to 
pass incident reporting legislation to ensure that we actually 
have a full picture of the threat that we are facing in this 
country.
    While I applaud the work of the Administration and the 
private sector companies working to address the vulnerability 
in Log4j, it is going to continue. It will require our 
continued diligence, and we will need to be aware that it could 
be exploited in the future.
    Our adversaries continue to look for cybersecurity 
vulnerabilities, and we must be diligent in our defense. Open 
source software has led to significant advances in modern 
software and technology development, but we need to continue to 
improve the security of this and all other software. I 
appreciate the panel's discussion today on this topic and look 
forward to continuing this discussion in the future.
    The record for this hearing will remain open for 15 days, 
until February 23rd at 5 p.m. for submission of statements and 
questions for the record.
    This hearing is now adjourned.
    [Whereupon, at 11:31 a.m., the hearing was adjourned.]

                            A P P E N D I X

                              ----------                              

              [GRAPHIC(S) NOT AVAILABLE IN TIFF FORMAT]



                              [all]