Scope Material

for

Software Facts

Nothing can satisfy everybody's needs. To do anything meaningful, we must choose our audiences, classes of products or services, and goals. This page lists some possibilities.

Audiences

• Naive home users - know nothing about computers or security; the machine is a box that should just work, like a toaster
• Careful home users - know little, but want to take reasonable precautions
• Knowledgeable home users - administer their own machine with upgrades and settings, can put some effort in
• Small businesses - up to a dozen employees; like a dentist office, plumber, dry cleaner, or local diner
• Large businesses - with dedicated IT professionals
• High security - banks, military, medical records
• Federal government (are they different?)
• Integrators - incoming software is only one piece that goes into embedded devices; software is in the product

The following three audiences were selected at the DHS Software Assurance working group meeting, Arlington, VA, July 2008.

• Naive home users
• Small businesses
• Integrators

Product Classes

• web (on-line) services
• operating system
• device drivers & apps
• games
• email programs
• chat and instant messaging programs
• checking and banking
• anti-virus, firewall, anti-malware, etc.
• desktop tools
• security products vs. products not having a security aim

Goals

• Present relevant information to empower consumers to make the right decisions
1. Buy product A vs. product B
2. Buy vs. no buy
3. Buy vs. build
• Lead to better (e.g. more secure) software through market forces, re: Akerlof "The Market for Lemons:Quality Uncertainty and the Market Mechanism"
• Be a market differentiator
• Convey what settings are (more) secure
• Convey expected noteworthy behavior (for instance, disk space used, Internet use: once for registration or every time it starts, screen or key logging)
• Serve as input to risk or other assessments
• Convey information that user needs to establish trust and confidence in the product
• Convey measures that enable better risk management decisions
• Identify "hot spots" for risk analysis
• Be able to determine that this will not weaken current security position, in order words, it won't make your desktop worse

• replace RFP/RFI or other due diligence
• (completely) substitute for incoming audits or review

Means, or, Criteria

• First, do no harm
• Voluntary (not legislated)
• Standardized - normalized across different implementations
• Different for different audiences or needs. A dependent criterion might be
  • Content should be normalized across different scopes.
• Low impact (cost) for those doing "the right thing"
• Absolutely simple for vendors to produce or extract. This suggests these criteria
  • Facts generated automatically, e.g., lines of code
  • Tools to generate or find the facts are available to everyone
  This criteria is repeated below. Conceivably each fact might be simple to produce while the ensemble is hard or vice versa.
• Visibility: location? in clear view? accessible (via web)? doesn't come up after install?
• tiers or hierarchy, for instance, from self-certification to Common Criteria EAL7
• Summarize data in a format suitable for non-technical users

The following criteria were considered, but almost unanimously rejected (DHS SwA working group meeting, Arlington, VA, July 2008).

• Have a standard format for other (developer's) claims. That is, have some format for the maker to record other claims.
• Have a machine-readable version, for example, an XML version that one could get from the software or web site that (a) conveys the same information and (b) can be input to some an assurance case or SCAP.
• Limit to label size. Should we have some target, for instance, the facts shouldn't be more than 2 pages in length?

The Process of Software Facts

A software developer might obtain a set of software facts many different ways.

• What body oversees these facts, their definition, permitted use, etc.?
• Does a body determine a standard set of facts? Or do developers choose the claims, like CESG Claims Tested Mark?
• How does a software developer get these facts? Self-certification? Self- then verified by a third-party? Who pays for it?
• Does a set of software facts apply to a different version? Different release? Different build?
• Can software facts be easily, cheaply, and/or quickly updated for a different version or release or patch?
• Who "rescinds" an approved set of facts? Under what circumstances? Is this needed?
• Is there a central repository of software with approved facts?

Terminology

We want to convey the correct perception of this work, or at least minimize (undue) negative reactions. The DHS Software Assurance working group (Arlington, VA, July 2008) overwhelming and generally approved simply "software facts" as a name for this effort. Here are other terms brought up.

• metadata
• transparency
• software assurance
• black marks (a partly humorous reference to Paul Black who led the discussion)
• label (2 votes)
• seal (5 votes)
• attestation
• product characteristics
• claims
• badge
• code traits
• pedigree
• provenance

All the facts together need a collective name. "Label" has many negative connotations, as the above vote shows. Other possible terms are "set", "collection", and "digest".

Up to the software facts main page

Created Mon Aug 4 12:37:25 2008

Updated Thu Feb 28 15:29:55 2013

Information Technology Laboratory, Software and Systems Division
PRIVACY/SECURITY ISSUES • FOIA • Disclaimer • USA.gov
NIST is an agency of the U.S. Commerce Department

This page's URL is http://hissa.nist.gov/~black/SoftwareFacts/possibleScope.html