Yesterday, CISA Director Jen Easterly announced the second iteration of CISA’s Secure by Design whitepaper, “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software” at the Singapore Cyber Week conference. Since releasing the first version of the whitepaper in April, we received a great deal of constructive and detailed feedback from a wide spectrum of stakeholders, including software manufacturers of all sizes, customers, non-profits, academics, U.S. and international government agencies, and individuals. Ten U.S. and international partners co-sealed the first version of the whitepaper. This version includes an incredible eight additional countries and international organizations. This scale of feedback and partnership underscores that the industry is keen to have this conversation, and that the time to shift the responsibility for security is now. We have been honored by how generous people have been with their time and expertise.
The feedback spanned all sections of the document, including commentary on which software development practices were most helpful in the design and development of secure software. One of the most common themes was centered on the three Secure by Design principles. That is gratifying because the principles were the heart of the document, despite that section not being very long. People were picking up what we were laying down.
In addition to listening to the community’s feedback, we held a few initial secure by design summits. The first summit was an internal CISA summit geared towards educating the CISA workforce we called “Summit Zero” where we spent an entire day hosting both internal and external speakers to explain the many challenges facing the software industry as it seeks to build more secure products. Speakers covered topics ranging from OT security, to economic challenges, to the history of the “quality by design” movement in manufacturing.
We’ve since held two other summits. The first focused on the K-12 education technology (or “EdTech”) market. A number of EdTech companies, ranging from small to large, participated to share their experiences in serving their customers while trying to improve their secure development practices. This goal is a significant challenge for smaller software companies, and one the industry needs to address: How can we democratize the “well-lit paths” that some larger software companies have created to ensure the path of least resistance for their software developers is also the most secure one?
Following the summit, we launched a pledge with top K-12 software manufacturers focused on secure by design practices. The pledge lays out specific actions that EdTech companies are committing to take, including not charging extra for basic security features and publishing a secure by design roadmap. In the coming months, we’re planning on expanding this pledge out to other sectors. In the meantime, K-12 software manufacturers can reach out if interested in joining the pledge.
The second summit focused on university and community college computer science programs. At this event we heard about the challenges facing faculty who are trying to satisfy many goals as they prepare the nation’s software workforce for their careers. Topics ranged from teaching memory safe programming languages, to defensive programming practices, to the incentives that guide universities and their faculty’s programs.
Since April, we’ve worked to incorporate feedback into a new version of the whitepaper. As noted above, we heard from numerous software industry stakeholders, large and small, governmental and private, suppliers and customers. We’ve briefed numerous nonprofit and industry organizations. We attended workshops to learn about company software development processes. We attended the DEF CON conference in Las Vegas in August and held a “red pen” session where we invited DEF CON participants to literally mark up the draft whitepaper with a red pen. Much red ink was spilled that day, my friends.
Based on the prevailing feedback that people wanted more information about the three principles, we expanded that section substantially in two ways. First, we provided more context to help readers understand the intent behind each principle. Second, we introduced the concept of evidence in the form of artifacts. We wanted to know what artifacts a software manufacturer could present to demonstrate that they are investing in a secure by design program. The idea is that no one artifact would convince an outsider, but a collection of artifacts might start to tell a compelling story.
Software companies have asked how they can get more involved. The best way is to demonstrate the three principles. Look at the list of suggested artifacts in the new whitepaper and make public the ones you are currently doing. We need companies that are already engaging in these behaviors to teach others what “good” looks like. If you are a customer, start to ask potential vendors for some of the artifacts listed in the whitepaper. We need buyers to create a significant demand signal that will nudge incentives towards secure by design engineering.
In the coming weeks, we’ll be releasing a Request for Information (RFI) on secure by design engineering. We’re especially interested on any feedback on areas our whitepaper can be improved and what areas CISA should focus its future efforts on.
We heard many ideas that we continue to contemplate, and much like software development, we will work to address them in future versions of the whitepaper. In the meantime, we look forward to reading more about the ways in which companies adopt a secure by design philosophy for their products and their customers. As always, you can get in touch with us at SecureByDesign@cisa.dhs.gov and visit www.cisa.gov/SecureByDesign for more information and related resources.
