Request for Information on “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software”, 88104-88107 [2023-27948]
Download as PDF
<![CDATA[
88104
Federal Register / Vol. 88, No. 243 / Wednesday, December 20, 2023 / Notices
ddrumheller on DSK120RN23PROD with NOTICES1
Maritime Security Coordinator (FMSC)
in the development, review, update, and
exercising of the Area Maritime Security
Plan (AMSP) for their area of
responsibility. Such matters may
include, but are not limited to, the
following:
(1) Identifying critical port
infrastructure and operations;
Identifying risks (threats,
vulnerabilities, and consequences).
(2) Determining mitigation strategies
and implementation methods.
(3) Developing strategies to facilitate
the recovery of the Maritime
Transportation System after a
Transportation Security Incident.
(4) Developing and describing the
process to continually evaluate overall
port security by considering
consequences and vulnerabilities, how
they may change over time, and what
additional mitigation strategies can be
applied; and
(5) Providing advice to and assisting
the Federal Maritime Security
Coordinator in developing and
maintaining the Area Maritime Security
Plan.
AMSC Membership
Members of the AMSC should have at
least five years of experience related to
maritime or port security operations. We
are seeking to fill one (1) SubCommittee vacancies with this
solicitation, an Executive Board member
to serve as Vice-Chairperson; the
position will serve concurrently as a
member of the Eastern Great Lakes
AMSC when so convened by the FMSC.
Applicants may be required to pass an
appropriate security background check
prior to appointment to the committee.
Applicants must register with and
remain active as a Coast Guard
Homeport user if appointed. Member’s
term of office will be for five years;
however, a member is eligible to serve
additional terms of office. Members will
not receive any salary or other
compensation for their service on an
AMSC. In accordance with 33 CFR 103,
members may be selected from Federal,
Territorial, or Tribal governments; State
government and political subdivisions
of the State; local public safety, crisis
management, and emergency response
agencies; law enforcement and security
organizations; maritime industry,
including labor; other port stakeholders
having a special competence in
maritime security; and port stakeholders
affected by security practices and
policies.
The Department of Homeland
Security does not discriminate in
selection of committee members on the
basis of race, color, religion, sex,
VerDate Sep<11>2014
18:02 Dec 19, 2023
Jkt 262001
national origin, political affiliation,
sexual orientation, gender identity,
marital status, disability, and genetic
information, age, membership in an
employee organization, or any other
non-merit factor. The Department of
Homeland Security strives to achieve a
widely diverse candidate pool for all of
its recruitment actions.
Request for Applications
Those seeking membership are not
required to submit formal applications
to the local Captain of the Port,
however, because we do have an
obligation to ensure that a specific
number of members have the
prerequisite maritime security
experience, we encourage the
submission of resumes highlighting
experience in the maritime and security
industries.
Dated: December 14, 2023.
Mark I. Kuperman,
Captain, U.S. Coast Guard, Captain of the
Port & Federal Maritime Security Coordinator,
Eastern Great Lakes.
[FR Doc. 2023–27944 Filed 12–19–23; 8:45 am]
BILLING CODE 9110–15–P
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’’
Cybersecurity and
Infrastructure Security Agency (CISA),
Department of Homeland Security
(DHS).
ACTION: Notice; request for information.
AGENCY:
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.
SUMMARY:
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 https://www.regulations.gov.
Instructions: All comments received
will be posted to https://
www.regulations.gov, including any
personal information provided. If you
cannot submit your comment using
https://www.regulations.gov, contact the
ADDRESSES:
PO 00000
Frm 00064
Fmt 4703
Sfmt 4703
person in the FOR FURTHER INFORMATION
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 https://
www.cisa.gov/sites/default/files/202310/SecureByDesign_1025_508c.pdf.
Docket: For access to the docket and
to read comments received, go to
https://www.regulations.gov.
FOR FURTHER INFORMATION CONTACT:
Megan Doscher, 202–975–4911,
SecureByDesign@cisa.dhs.gov.
SUPPLEMENTARY INFORMATION:
CONTACT
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 https://www.cisa.gov/sites/default/
files/2023-10/SecureByDesign_1025_
508c.pdf.
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 www.regulations.gov 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
E:\FR\FM\20DEN1.SGM
20DEN1
Federal Register / Vol. 88, No. 243 / Wednesday, December 20, 2023 / Notices
ddrumheller on DSK120RN23PROD with NOTICES1
comments received shall be posted to
https://www.regulations.gov.
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
VerDate Sep<11>2014
18:02 Dec 19, 2023
Jkt 262001
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
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.
1 The updated white paper ‘‘Shifting the Balance
of Cybersecurity Risk: Principles and Approaches
for Secure by Design Software’’ can be found at
https://www.cisa.gov/sites/default/files/2023-10/
SecureByDesign_1025_508c.pdf.
PO 00000
Frm 00065
Fmt 4703
Sfmt 4703
88105
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 welllit 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
E:\FR\FM\20DEN1.SGM
20DEN1
ddrumheller on DSK120RN23PROD with NOTICES1
88106
Federal Register / Vol. 88, No. 243 / Wednesday, December 20, 2023 / Notices
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 realtime 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
VerDate Sep<11>2014
18:02 Dec 19, 2023
Jkt 262001
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-
PO 00000
Frm 00066
Fmt 4703
Sfmt 4703
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,
E:\FR\FM\20DEN1.SGM
20DEN1
ddrumheller on DSK120RN23PROD with NOTICES1
Federal Register / Vol. 88, No. 243 / Wednesday, December 20, 2023 / Notices
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
VerDate Sep<11>2014
18:02 Dec 19, 2023
Jkt 262001
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
DEPARTMENT OF THE INTERIOR
Bureau of Ocean Energy Management
[Docket No. BOEM–2023–0061]
Notice of Intent To Prepare a
Programmatic Environmental Impact
Statement for Future Floating Wind
Energy Development Related to 2023
Leased Areas Offshore California
Bureau of Ocean Energy
Management, Interior.
ACTION: Notice of intent (NOI) to prepare
a programmatic environmental impact
statement (PEIS); request for comments.
AGENCY:
Consistent with the
regulations implementing the National
Environmental Policy Act (NEPA),
BOEM announces its intent to prepare a
PEIS to analyze the potential impacts of
floating offshore wind energy
development on the five leased areas
offshore Humboldt and Morro Bay,
California. The PEIS also will identify
programmatic protective mitigation
measures that if adopted could lessen
those impacts. This NOI announces the
scoping process BOEM will use to
identify significant issues and potential
alternatives for consideration in the
California offshore wind (OSW) PEIS.
DATES: Comments are due to BOEM by
February 20, 2024.
BOEM will hold two virtual public
scoping meetings for the California
OSW PEIS.
Tentative dates:
Tuesday, February 6, 2024; and
Thursday, February 8, 2024.
Please go to https://www.boem.gov/
california for meeting dates, times, and
registration. Meetings are open to the
public and free to attend. Preregistration is not required to attend.
ADDRESSES: Comments can be submitted
in the following ways:
• By mail or delivery service: Send
comments in an envelope labeled,
‘‘CALIFORNIA OSW PEIS’’ and
addressed to Chief, Environmental
SUMMARY:
PO 00000
Frm 00067
Fmt 4703
Sfmt 4703
88107
Assessment Section, Office of
Environment, Bureau of Ocean Energy
Management, 760 Paseo Camarillo,
Suite 102, Camarillo, California 93010;
or
• Through the regulations.gov web
portal: Navigate to https://
www.regulations.gov and search for
Docket No. BOEM–2023–0061. Select
the document in the search results on
which you want to comment, click on
the ‘‘Comment’’ button, and follow the
online instructions for submitting your
comment. A commenter’s checklist is
available on the comment web page.
Enter your information and comment,
then click ‘‘Submit.’’
Detailed information regarding the
California OSW PEIS can be found on
BOEM’s website at: https://
www.boem.gov/california.
For more information about
submitting comments, see ‘‘Comments’’
section under SUPPLEMENTARY
INFORMATION caption.
FOR FURTHER INFORMATION CONTACT: Lisa
Gilbane, BOEM Pacific Region Office of
Environment, 760 Paseo Camarillo,
Suite 102, Camarillo, California 93010,
telephone (805) 384–6387, or email
lisa.gilbane@boem.gov.
SUPPLEMENTARY INFORMATION: In
December 2022, through a competitive
leasing process under 30 CFR 585.211,
BOEM auctioned Renewable Energy
Leases OCS–P 0561, 0562, 0563, 0564,
and 0565 offshore California. These
leases total over 373,000 acres. These
are the first wind energy leases offshore
California and are anticipated to be
commercially developed with floating
foundations in waters from 500 to 1,300
meters deep. Three of the leases are
offshore central California, near Morro
Bay. The other two leases are offshore
northern California, near Humboldt Bay.
All leases grant the lessees the exclusive
right to submit construction and
operation plans (COPs) to BOEM
proposing the construction, operation,
and conceptual decommissioning of
offshore wind energy facilities in the
lease areas. BOEM identified these lease
areas through an extensive datagathering and engagement process that
included the BOEM California
Intergovernmental Renewable Energy
Task Force, comprised of the State of
California, numerous Tribal Nations,
Federal agencies, and local
governments.
The PEIS will analyze the potential
impacts of wind energy development in
the five lease areas offshore California
and consider measures that can be taken
to avoid or reduce those impacts. The
PEIS proposed action is the
identification of programmatic
E:\FR\FM\20DEN1.SGM
20DEN1
]]>Agencies
[Federal Register Volume 88, Number 243 (Wednesday, December 20, 2023)]
[Notices]
[Pages 88104-88107]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[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 https://www.regulations.gov.
Instructions: All comments received will be posted to https://www.regulations.gov, including any personal information provided. If
you cannot submit your comment using https://www.regulations.gov,
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 https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf.
Docket: For access to the docket and to read comments received, go
to https://www.regulations.gov.
FOR FURTHER INFORMATION CONTACT: Megan Doscher, 202-975-4911,
[email protected].
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 https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf.
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 www.regulations.gov 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 https://www.regulations.gov.
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 https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf.
---------------------------------------------------------------------------
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
