Notice2023-27948
Request for Information on “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software”
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
December 20, 2023
Issuing agencies
Homeland Security Department
Abstract
CISA requests input from all interested parties on the white paper "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software."
Full Text
<html>
<head>
<title>Federal Register, Volume 88 Issue 243 (Wednesday, December 20, 2023)</title>
</head>
<body><pre>
[Federal Register Volume 88, Number 243 (Wednesday, December 20, 2023)]
[Notices]
[Pages 88104-88107]
From the Federal Register Online via the Government Publishing Office [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2023-27948]
-----------------------------------------------------------------------
DEPARTMENT OF HOMELAND SECURITY
[Docket No. CISA-2023-0027]
Request for Information on ``Shifting the Balance of
Cybersecurity Risk: Principles and Approaches for Secure by Design
Software''
AGENCY: Cybersecurity and Infrastructure Security Agency (CISA),
Department of Homeland Security (DHS).
ACTION: Notice; request for information.
-----------------------------------------------------------------------
SUMMARY: CISA requests input from all interested parties on the white
paper ``Shifting the Balance of Cybersecurity Risk: Principles and
Approaches for Secure by Design Software.''
DATES: Written comments are requested on or before February 20, 2024.
Submissions received after the deadline for receiving comments may not
be considered.
ADDRESSES: You may send comments, identified by docket number CISA-
2023-0027, by following the instructions below for submitting comments
via the Federal eRulemaking Portal at <a href="http://www.regulations.gov">http://www.regulations.gov</a>.
Instructions: All comments received will be posted to <a href="https://www.regulations.gov">https://www.regulations.gov</a>, including any personal information provided. If
you cannot submit your comment using <a href="https://www.regulations.gov">https://www.regulations.gov</a>,
contact the person in the FOR FURTHER INFORMATION CONTACT section of
this notice for alternate instructions. For detailed instructions on
sending comments and additional information on the types of comments
that are of particular interest to CISA, see the ``Public
Participation'' heading of the SUPPLEMENTARY INFORMATION section of
this document.
Documents: The draft white paper titled ``Shifting the Balance of
Cybersecurity Risk: Principles and Approaches for Secure by Design
Software'' is available at <a href="https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf">https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf</a>.
Docket: For access to the docket and to read comments received, go
to <a href="https://www.regulations.gov">https://www.regulations.gov</a>.
FOR FURTHER INFORMATION CONTACT: Megan Doscher, 202-975-4911,
<a href="/cdn-cgi/l/email-protection#90c3f5f3e5e2f5d2e9d4f5e3f9f7fed0f3f9e3f1bef4f8e3bef7ffe6"><span class="__cf_email__" data-cfemail="7c2f191f090e193e0538190f151b123c1f150f1d5218140f521b130a">[email protected]</span></a>.
SUPPLEMENTARY INFORMATION:
I. Public Participation
Response to this RFI is voluntary. Interested persons are invited
to comment on this notice by submitting written data, views, or
arguments using the method identified in the ADDRESSES section above.
All members of the public including, but not limited to, specialists in
the field, academic experts, members of industry, public interest
groups, and those with relevant economic expertise are invited to
comment. The draft white paper titled ``Shifting the Balance of
Cybersecurity Risk: Principles and Approaches for Secure by Design
Software'' is available at <a href="https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf">https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf</a>.
Instructions: All submissions must include the agency name and
Docket number for this notice. Comments may be submitted electronically
via the Federal e-Rulemaking Portal. To submit comments electronically:
1. Go to <a href="http://www.regulations.gov">www.regulations.gov</a> and CISA-2023-0027 into the search
field.
2. Click on the ``Comment Now!'' icon.
3. Complete the required fields.
4. Enter or attach your comments.
All submissions, including attachments and other supporting
materials, will become part of the public record and may be subject to
public disclosure. CISA reserves the right to publicly publish relevant
and unedited comments in their entirety. Do not include personal
information such as account numbers, Social Security numbers, or the
names of other individuals. Do not submit confidential business
information or otherwise sensitive or protected information. All
[[Page 88105]]
comments received shall be posted to <a href="http://www.regulations.gov">http://www.regulations.gov</a>.
Commenters are encouraged to identify the number of specific topic(s)
they are addressing.
II. Background
Products that are secure by design are those where the security of
the customers is a core business goal, not a technical feature. Secure
by design products start with that goal before development begins.
Secure by default products are secure and ready to use ``out of the
box'' with little to no necessary configuration changes; moreover, the
security features are available without any additional costs. Together,
these two concepts move much of the burden of staying secure to the
manufacturers and reduce the chance that the customer will fall victim
to security incidents resulting from misconfigurations, insufficiently
fast patching, or other common issues.
Consequently, it is crucial for software manufacturers to make
secure by design and secure by default the focal points of product
design and development processes. The white paper strongly encourages
every software manufacturer to build products in a way that reduces the
burden of cybersecurity on customers. To achieve this outcome, software
manufacturers are urged to evolve their design and development programs
to permit only secure by design and secure by default products to be
shipped to customers.
The white paper identifies three core principles to guide software
manufacturers in building software security into their design processes
prior to developing, configuring, and shipping their products to
customers:
1. Take Ownership of Customer Security Outcomes: Software
manufacturers should take ownership of their customers' security
outcomes and evolve their products accordingly. Software manufacturers
should invest in product security efforts that include application
hardening, application security features, and application default
settings.
2. Embrace Radical Transparency and Accountability: Software
manufacturers should pride themselves in delivering safe and secure
products. Transparency will help convey what ``good'' looks like, and
that information will benefit the defenders more than our adversaries.
3. Lead From the Top: Build organizational structure and leadership
to achieve these goals. Senior leaders must make security a business
priority and not just a technical matter. Internal incentives and
culture must support security as a design requirement. While technical
subject matter expertise is critical to product security, senior
leaders are the primary decision makers for implementing change in an
organization.
CISA acknowledges that security by design is not easy. For example,
implementing a secure software development lifecycle (SDLC) is a
difficult task and takes time; smaller software manufacturers may
struggle to implement many of these suggestions. As more organizations
focus their attention on secure software development, there is room for
innovations that will narrow the gap between the larger and smaller
software manufacturers. Furthermore, engineering teams will be able to
establish a new, steady-state rhythm in which security is built into
the design and takes less effort to maintain.
The ``Shifting the Balance of Cybersecurity Risk: Principles and
Approaches for Secure by Design Software'' white paper identifies a
path forward for implementing security by design and security by
default into the SDLC, placing the burden of cybersecurity on
manufacturers instead of customers. The white paper explores the
benefits and challenges of applying the three secure by design
principles. In doing so, the white paper outlines the requirements and
activities necessary for software manufacturers to adopt a secure by
design philosophy. An updated version of the white paper was published
on October 16, 2023.\1\
---------------------------------------------------------------------------
\1\ The updated white paper ``Shifting the Balance of
Cybersecurity Risk: Principles and Approaches for Secure by Design
Software'' can be found at <a href="https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf">https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf</a>.
---------------------------------------------------------------------------
III. Additional Topics for Commenters
This white paper is part of a broader campaign across CISA and the
federal government to encourage technology manufacturers to prioritize
security in their development processes. For future iterations of
guidance, CISA also seeks additional information on the economics of
secure development, particularly as compared with the cost of incident
response. Additionally, for use in future guidance, CISA seeks
information from the public describing how security could be more fully
integrated into computer science and software development courses of
study.
In addition to comments on the white paper, CISA seeks comments and
information on the following related topics:
1. Incorporating security into the SDLC.
a. Among the many tactics for weaving security into the SDLC, which
tactics are the most effective? How is that impact measured?
b. What actions in the white paper are respondents taking, and what
measured results are they seeing? Have respondents publicly documented
these actions and their results and, if so, where?
c. Smaller software manufacturers report that they struggle to
implement the tools and practices that larger manufacturers can
implement. What are some examples of smaller software companies that
have implemented well-lit paths to reduce product vulnerabilities?
d. What are some best practices that smaller software companies can
adopt?
e. What improvements are needed to allow most small software
manufacturers to build and maintain software that is secure by design?
f. What are some examples of companies that invest in continuous
security education for software developers? How much do these programs
cost, and what are the results?
2. Education. University-based computer science degree programs
must manage many priorities, including research, student demand,
faculty and tenure requirements, and curriculum design. Security is
often relegated to an elective, rather than a core component of the
program. Online education programs, which offer a viable and convenient
pathway toward a degree or a specialized skill set in computer science
or software development, have similar outcomes, though perhaps for
different reasons.
a. What are some examples of commercial entities signaling their
demands to universities for knowledge of security and secure coding in
graduates of computer science programs? Is knowledge of security
evaluated during the hiring stage, or are employees reskilled after
being hired?
b. What are some examples of higher education incorporating
foundational security knowledge into their computer science curricula?
How did the universities incorporate the knowledge and what were some
results? Did students demand additional security training, or were they
resistant? Were students able to differentiate their skillsets based on
this knowledge and experience?
c. How can current or prospective students for online computer
science or coding education programs signal their demands for security?
What are some actions that online programs can take to incentivize
companies to develop content with integrated security
[[Page 88106]]
principles that are hosted on their platforms?
3. Hardening/loosening guides. Hardening guides are supplements to
installation guides that help customers configure and deploy a product
with a stronger security posture than the product's defaults would
create.
a. What are some best practices for hardening guides? What are some
good examples?
b. How do software manufacturers decide on their products' default
configurations, and how do those decisions affect the length and
complexity of the hardening guide?
c. What are some examples of products that have something closer to
a ``loosening guide?''
d. How do companies decide which staff members author the
hardening/loosening guides, and how much cybersecurity experience do
those members have? What are some best practices that more companies
should adopt?
e. Are there examples of products that offer automated hardening
mechanisms, such as in installation scripts or in real-time when
configuring settings, rather than in a supplemental document?
f. What are customers' experiences with multiple hardening guides
across a large tech stack?
4. Economics of implementing secure by design practices. Just as
cars with crumple zones and air bags may cost their manufacturers more
to build than cars without such safety mechanisms, developing secure by
design products is likely to cost the software manufacturer more than
if the manufacturer did not emphasize product and customer security.
CISA requests additional information about the magnitude and sources of
these costs.
a. What types of costs do software manufacturers incur as they
implement and mature their secure by design programs? Examples might
include developer training, security analysis tools, migrating to
memory safe languages (MSL), and vetting the security of open-source
libraries.
b. How much are these costs, typically; to what extent are they
absorbed by manufacturers; and to what extent are they passed along to
consumers through price increases?
c. Which secure by design practices are the most effective, and
what voluntary guidance should CISA consider issuing to encourage those
practices?
5. Economics of software vulnerabilities. Software vulnerabilities
cost software manufacturers and their customers time, effort, and
money. CISA seeks additional information about how software
manufacturers measure these costs and how manufacturers respond as
costs fluctuate.
a. Impact of vulnerabilities on software manufacturers.
i. How do software manufacturers measure their costs for each
vulnerability?
ii. Do software manufacturers measure the financial impact of
vulnerabilities over time? If so, what are some examples of common
patterns that emerge?
iii. What are the differences in the remediation costs associated
with vulnerabilities discovered in-house compared to the costs
associated with vulnerabilities found after customers have deployed the
product?
iv. How do software manufacturers determine how to remediate
vulnerabilities, e.g., whether to patch specific instances of a
vulnerability versus making other changes to remove the class of
vulnerabilities? Does the size of the company (small versus large) make
a difference for these choices? Are there particular cost structures
that warrant investments in removing the class of vulnerabilities
rather than patching vulnerabilities upon subsequent discovery? What
factors or considerations do software manufacturers use to determine
the financial decision points?
v. Where in the software manufacturer's organization are tradeoffs
made based on this financial data? Are these tradeoffs handled as
technical matters or as business matters addressed by senior business
leaders?
b. Impact of vulnerabilities on customers.
i. Do software manufactures calculate costs for consumers? If so,
how do software manufacturers determine the average cost for customers
to deploy software updates to mitigate a software vulnerability?
ii. How do software manufacturers determine the aggregate cost
across all customers for patching?
6. Economics of customer demand. Software manufacturers generally
implement the features customers ask for the most. There is a
perception that customers are not asking for security in the products
they buy.
a. In what ways do customers ask software manufacturers to make
products more secure?
b. In what ways do customers ask for specific security features
rather than asking for products that are secure by design?
c. How can customers measure the security of a product? Can they
take that measurement and translate it into long-term costs to decision
makers in a business?
d. What are the inhibitors to customers creating a strong demand
signal that software should be secure by design?
7. Field studies. Field studies can illuminate how customers
configure and use products in ways that may differ from the developer's
expectations. For example, a field study might determine that a
significant percentage of customers use unsafe settings when safer ones
exist, thus putting them at risk, possibly without their knowledge.
a. Do software manufacturers carry out such field studies? If so,
what are some examples of software manufacturers that have implemented
formal field studies, and how did those studies affect the design of
future versions of that software? How did those studies affect the user
experience of the security settings in line with how the software is
supposed to function in different sectors (such as healthcare, K-12,
etc.)?
b. What are some best practices for conducting field studies and
incorporating the results into the SDLC? Are field studies on the user
experience of security settings and software function conducted and, if
so, what are some best practices?
c. What costs and benefits do field studies have for software
manufacturers? For their customers?
8. Recurring vulnerabilities. In the news, we frequently see
examples of software vulnerabilities for which effective mitigations
have been available for years, or even decades. Examples include hard-
coded credentials, SQL injection vulnerabilities, and directory path
traversal vulnerabilities.
a. What are the barriers to eliminating recurring classes of
vulnerability?
b. How can potential customers determine which software
manufacturers have been diligent in removing classes of vulnerability
rather than patching individual instances of that class of
vulnerability?
c. What changes to the Common Vulnerabilities and Exposures (CVE)
and Common Weakness Enumeration (CWE) programs might lead to more
companies identifying recurring vulnerability types and investing to
eliminate them?
9. Customer upgrade reluctance. When software manufacturers improve
a product, perhaps by implementing a new security feature or network
protocol, customers may need to act to take advantage of those
improvements. However, customers do not always adopt those security
improvements,
[[Page 88107]]
particularly if the improvements cost them time or money.
a. What are the primary barriers to customers investing in upgrades
that should reduce their risk?
b. What are some examples of security improvements where customer
adoption was swift despite those barriers? What factors made customer
upgrades more likely? How much did the software manufacturer need to
invest in dollars or customer outreach to achieve broad adoption?
10. Threat modeling. Threat modeling is a technique used to
identify assets and threats and to design, implement, and validate
mitigations.
a. What are some examples of threat models that software
manufacturers have made public?
b. What are some best practices for publishing a high-level threat
model that will demonstrate to customers that the software manufacturer
has adopted a robust threat-modeling program as part of its SDLC?
11. Charging for security features. Companies often charge more for
security features. Companies may choose to include security features
only in higher-product tiers, or they may charge for it as a separate
line item. For example, some software companies charge customers more
when they want to use a single sign-on (SSO) service or if the customer
wants access to all security related audit logs. CISA seeks additional
information about how software manufacturers might decide to charge for
a feature or to include it in the base price.
a. How do software manufacturers decide which pricing model is
appropriate?
b. What considerations do they factor into their decision?
12. Artificial Intelligence (AI). AI is software and therefore
should adhere to the three secure by design principles.
a. What additional security considerations are necessary for the
development of secure AI?
13. Operational Technology (OT). OT systems can differ
significantly from information technology (IT) systems. OT systems
operate in different environments in which availability is the main
priority. Unlike some IT systems that are refreshed or replaced every
few years, some OT systems may operate in the field for a decade or
more.
a. Which OT products or companies have implemented some of the core
tenants of secure by design engineering?
b. What priority levels do customers place on security features and
product attributes? What incentives would likely lead customers to
increase their demand for security features, even if it costs more?
c. Where could targeted investments be made to raise and scale
security levels across OT?
This notice is issued under the authority of 6 U.S.C. 652 and 659.
Eric Goldstein,
Executive Assistant Director for Cybersecurity, Cybersecurity and
Infrastructure Security Agency, Department of Homeland Security.
[FR Doc. 2023-27948 Filed 12-19-23; 8:45 am]
BILLING CODE 9110-9P-P
</pre><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script></body>
</html>Indexed from Federal Register on December 20, 2023.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.