"Securable" by Design

"Secure by Design" suggests that one can design an airplane that cannot run out of fuel or collide with terrain or another aircraft.  Rather, the goals should be "Securable by Design" and "Safe Out of the Box."  Such a design should begin with a  statement of ranked requirements in which security requirements are included with all others.  For example, things that the product must not do should be ranked  with things that it must do.  Failure modes must be explicitly identified along with the indicators of failure and the indicated corrective action.  Engineers have been doing this with hardware for millennia.

Complete requirements describe:

• The environment in which the system must operate (including natural and artificial hazards and threats)

• The market or market conditions

• The results that the system must produce (e.g., move passengers and freight, computing application, user programming)

• Performance (e.g., passenger load, range, speed, users, standard operations per unit time)

• How it must function

• Required/forbidden controls (e.g., over-ride of automated controls)

• The granularity of the controls (maximum rate of climb, number of named users or resources; controls must be sufficiently granular that one can implement the rule of least privilege.)

• Things that it must not do (e.g., stall near cruise speed, leak information between users or compartments)

• Specific threats that it must resist (e.g., lightning, easily anticipated abuse and misuse, hostile use of controls) • Cost for overcoming resistance (e.g., cost of attack)

• Impermissible failure modes and their alternatives (e.g., halt before leaking)

• Reliability

• The availability of the system (mean-time before failure, mean-time to recovery)

• Efficiency

• Maintainability (“Function may not trump maintainability and reliability.”)

• Compatibility

• How it is to be demonstrated (e.g., testing, third-party evaluation)

• Other

Complete Specification

By habit and culture, engineers use a complete specification for a system. By contrast, IT developers often work from a specification that is less than complete. A complete specification includes an expression or description:

• Of how the system is to achieve the requirements

• What functions it will perform

• What it will look like

• What materials it will be built from

• What controls and interfaces it will present

• How it will fail (failure modes)

• Indications or evidence of failure

• A model or prototype

• Users or operators manual

• Assembly processes

• Testing or demonstration procedures

• Other