CERT

Back to [13]   [14]    Forwards to [15]



Brainstorming Information Survivability for ISW'98 - Reducing Risk in Critical National IT Operations and Infrastructures [Finance, Transport, Power & Telecommunications]

T.E. (Ted) Elliott
Senior Consultant IT Security Systems
Communications Security Establishment, Government of Canada
Tel. (613) 991-7506; FAX (613) 991-7455; E-Mail: telliott@cse-cst.gc.ca

© Minister of National Defence, on behalf of Communications Security Establishment, Canada 1998

In considering the four focus areas announced for this workshop, I submit the following as my own personal views and conclusions which should not be taken or interpreted as representing those of my employer, the Communications Security Establishment, nor those of the Government of Canada.

Defining Metrics for IS

Risk management methodology is one strong tool that IS professionals use or follow under national direction to gain maximum benefit within approved economic funding options for senior management. This approach includes defining a clear statement of sensitivities, all known threats, threat agents, vulnerabilities and probabilities of negative actions or events which leads to a threat risk assessment report (TRA). This should allow a most effective IS research focus. Should IS use specific TRAs - are these appropriate for each of the operational domains, finance, transport, power & telecommunications, or should they be based upon a core or backbone environment which could be driven by one TRA? Current documentation for TRA efforts has recently been published by CSE.1

Which IS domain(s) should IS professionals "focus" upon?: [timelines, subject/open, organization/priority, resources]
(a) improvements to the existing today snapshot of "highly distributed, networked systems that support critical infrastructures and critical applications"; [Timeline; Retrofit survivability approach]
(b) Term: possible short (1 yr.), medium (4 yr.) and long term10 yr.) future IS systems approaches which may bring revolutionary gains i.e. quality, requirements, characteristics to achieve greater risk reduction; [timelines; Research survivability]
(c) the ad hoc approach, "each professional and organization to their own" area(s) of interest and specialty; [subject/open]
(d) this workshop and future IS focus is upon Finance, Transport, Power & Telecommunications - Are these the only top priority items required for common IS requirements? For example, the Canadian Public Key Infrastructure (PKI) is a current Canadian Federal Government project scope with intended interoperability agreements for internal national and international extension; [subject/open]
(e) Software Engineering approaches to improve the software product and systems proposed for IS priority applications: [subject/open]
  • Operating systems, with appropriate trust, robustness, sustainability etc. as appropriate;
  • IS tailored operational modules of application software as well as any cryptographic software;
  • "install software" including installation specific IS architectural and operational set-up and run data, operator and managerial authorizations and related public key infrastructure(s) and certificates for digital signature and for privacy/confidentiality encryption; and,
  • any other software and IS sensitive data.
(f) Hardware Engineering approaches - computer hardware specifically designed or modified as suitable for running IS systems which may include a complete Operating System Software environment for example a future "Company ABC's IS OS" may well displace ...Windows NT, Windows '95 or real-time operating systems RTOS like QNX, etc. I suspect a RTOS approach may allow much more robustness, but I'm not too familiar with their nature. [subject/open]
(g) National direction (with some possible International collaboration) on specific items and level of project resources toward each of the above. [timelines, subject/open, organization/priority & resources]

Development Processes for IS

"Quality, Requirements and Characteristic Attributes" are the terms from the call for ISW'98 proposals.
I suggest significant elements of some of these attributes are already some criteria as part of the international "Common Criteria for Information Technology Security Evaluation, Version 2.0, May 1998, CCIB-98-026 et seq.2" for trusted computer products and it therefore appears very suitable for an IS start towards survivable systems. More specifically the integrity, assurance and availability (to name only a few) elements of the common criteria ("CC") would seem invaluable. The IS community might begin to focus upon specific criteria within the CC and future drafting a "survivability target profile". This would be one very effective technical direction toward robust IS design and evaluation to achieve survivable systems and products. There are already related drafts of the Common Evaluation Methodology3 to give more evaluation methodology guidance. The CC could be extended with any additional new IS criteria if there are not sufficient criteria on IS there today. Specific IS criteria additions (such as Robustness) not yet within the "CC" and deemed critical for IS could be drafted and, when appropriate, submitted through a sponsoring nation to the Common Criteria Implementation Board (CCIB). When I scanned the ISW'97 proceedings papers I made a short list below4 of some ISW'97 characteristics together with some possible draft CC references (these draft criteria are in bold face type below). This approach could be pursued by an IS-criteria group or workshop; although much more effort is required, isn't this a very worthwhile IS future?
Would some elements of the Systems Security Engineering Capability Maturity Model (SSE-CMM)5 , warrant inclusion in refining IS? This covers essential characteristics of an organization's security engineering process that must exist to ensure good security engineering. The SSE-CMM does not specify a particular process or sequence, but captures most practices generally observed in industry: the entire life cycle, the whole organization, interactions with other disciplines, such as system, software, hardware, human factors, and test engineering, system management, operation, and maintenance; interactions with other organizations, including acquisition, system management, certification, accreditation, and evaluation. This should help to rule out the "basement or midnight coding" approach which unfortunately has and still does plague all too many of our IT systems, critical and otherwise.

Integrity

Hardware Integrity - Once any modules of IS software are finalized, (for all those which are called and used without any modification or update requirement,) they become absolutely unchangeable if they are securely loaded into storage devices capable of then being secured (hardware "locked") in read-only access mode using either CD-ROM or our prototype digital storage device hardware switch6 developed for absolute resistance to hackers and malicious code attacks. The latter provides alert (audio, visual or digital) if any attempt is made to write to the device when the read-only mode is switch selected.7

Software Integrity/Authentication/Validation/Non-repudiation (IAVN): Every module or file of all IS software could be "integrity sealed" with an IS-digital signature from any of:
(a) the developer together with the compatible OS provider;
(b) the purchaser/licensee;
(c) the IS-accredited certification/evaluation authority;
(d) the accreditation authorities (managerial signature to begin operation in an IS application/site.
Such a proposed scenario would allow IS-systems to validate all IS-modules when called and during other times as a possible robust system or application design requires. Even IS-critical "data-modules" can and should be considered for the same "IAVN" benefits, provided they do not require real-time modification of content.

Timestamping and IS-Registry based Mandatory Access Controls In addition to authentication with digital signatures as above, all IS-modules which any specific application/site/OS require for IS-operation could be "entered" in the respective application/site/OS registry and enforced by IS-firewall (or access control) (new) technology driven by the application/site/OS IS-policy rule set. Extra assurance might be obtained if the manufacturer of the IS-modules employed Timestamping together with digital signature for validation and re-validation actions.

Conclusions

     I believe a focus on hardware based integrity supplemented by specific digital signature based integrity will advance IS to a whole level of new protection for IS critical operations. Research toward IS-related "software module validation and re-validation" and IS-domain protection is felt to be most fruitful.
     On the other hand, requirements for high trust OSs to include mandatory access controls over specific control channels and systems, as well as requirements for confidentiality based upon cryptography, are also quite mature and it is believed can already be provided by existing COTS product from existing national cryptographic and IT Security organizations.
     I propose the following towards having future critical systems more survivable:
  1. ISW's should also focus on what constitutes the complete set of quality attributes or IS-criteria necessary for the most economic IS system for these critical national architectures. This would be done using first the existing Common Criteria version 2.0 and the Common Evaluation Methodology.
  2. Do any existing COTS OSs, which may meet (or easily be brought to meet) sufficient minimums from 1. above, allow us to make retrofitting economically and technically feasible?
  3. Isn't this proposed hardware enforced integrity approach, one of the biggest risk reduction items capable of making IS modules and OSs robust and unchangeable?
  4. Is ground up design of IS-system products a viable approach once the "quality attributes" or criteria are drafted and an agreed survivability protection profile established? This is directly related to item 1 above.
  5. A proposed scenario: An IS site establishes an Internet connection with a remote IS site, point-to-point, using an IS-PKI and IS-site software such as Entrust® - this provides robust authentication of each IS site to the other, digital signature based integrity seals for all software modules and as well provides an approved IS-encryption based confidentiality protection to eliminate eavesdropping and intruders. Because both sites' Entrust software and the PKI are sufficiently "robust" to meet the IS-TRA(s)), I submit this moves ahead our protection and lowers risks considerably. Existing non-IS designed PKI projects may be sufficiently robust or perhaps with supplementary IS protection upgrades.
  6. Should an IS-criteria specific workshop be convened, or does the existing IS organization have the ability to address a way ahead using the CC and CEM?



Ted Elliott is a B.Sc. graduate of the University of Waterloo (Ontario) with over 30 years of work experience of which the last 15 involve IT Security as a senior consultant within the Government of Canada. He has a personal research interest in IT hardware integrity as well as tracking parallels between information in the paper based world versus information in all telecommunications, IT, and electronic domains.
1
Threat and Risk Assessment Process for the Government of Canada (DRAFT), May 1998, MG-11(draft for comment); A Guide to Risk Management for Information Technology Systems, January 1996, MG-2; A Guide to Risk Assessment and Safeguard Selection for Information Technology Systems, January 1996, MG-3; and A Guide to Certification and Accreditation for Information Technology Security, January 1996, MG-4 address this whole domain and all but the draft are available from CSE: http://www.cse-cst.gc.ca/cse/english/manu2.htm;
2
Available on the U.S.NIST URL http://csrc.nist.gov/cc/ccv20/ccv2list.htm
3
Common Evaluation Methodology for Information Technology Security Part 1 Introduction and general model, Version 0.6, 97/01/11, 30 p.; Common Methodology for Information Technology Security Evaluation (sic) Part 2: Evaluation Methodology, Version 0.31, CEM-97/052, 97/09/17, 56 p.; available from CSE: http://www.cse-cst.gc.ca/cse/english/cc.html
4
Safety; fault tolerance - FRU_PRS; FPT_FLS; attack incident; failure; survivability - AVA_SOF; absence of security flaws - ADV_FSP; ADV_HLD; ADV_LLD; ADV_IMP; ATE_FUN; AVA_VLA; performance; identify departures from baseline behavioral data - FAU_SAA.2; identify known system invariants; temporal properties; track the system's adherence to these specifications - ADV_IMP; multiple overlapping lines of defense; intrusion; detection; recovery - FPT_RCV; integrity - FDP_SDI; FDT_ITI; permutating the system implementation; dependability - FPT_FLS; continuous redesign; automated recovery procedures for system disruptions - FPT_RCV; recovering loss of data or service resulting from information attack - FPT_RCV.3; data and system recovery; to combine different facets of dependability; to provide relatively new forms of dependability such as security against terrorist attacks; to support extensive functionality on distributed targets; to use in implementations commercial-off-the-shelf (COTS) and legacy systems that were not necessarily designed to support dependability; to evolve yet maintain dependability properties in response to technological and domain changes; withstand external terrorist threats - covered in PP/ST Environment under Assumptions; overcome processes of inadequate software engineering - ADV Class; evolution mediators as the fundamental design paradigm; protection mediators - FPT Class; network mediators that extend mediators to distributed applications; real-time infrastructure (RTIS) in the following areas: real-time scheduling and constraint enforcement, transaction management, scheduler encapsulation, real-time predictability, admission control, overload management, real-time tasks, real-time threads, interthread synchronization, mutual exclusion, interprocess/interthread communication, fault-tolerance and group communication, portability, and security; segregation of data at different security levels, with a high degree of confidence - CC access control policies; deterrence and detection of intrusions that compromise; detect novel attacks through the use of machine learning.; to characterize the normal operating signatures of a target system, developing an internal representation of normal behavior; remove as much code that is incorrect (rather than malicious); intrusion detection on system; network intrusion detection; anomaly detection and self-healing; self-stabilization; and self-stabilizing protocols which guarantee automatic recovery from any transient fault.

5
Published on the CD-ROM version of "Proceedings of the 10th Annual Canadian Information Technology Security Symposium", Communications Security Establishment, Government of Canada, June 1-5, 1998.
6
T.E. Elliott, A Practical hardware Device for System and Data Integrity as well as Malicious Code Protection, Proceedings of the 17th National Computer Security Conference, October 11-14, 1994, Baltimore MD, pp.274 - 282 (Volume 1).
7
U.S. patent 5,559,993, issued September 24, 1996 to T.E. Elliott and R.L. Gonzalez, and assigned to the Minister of National Defence, for the Government of Canada; Canadian patent pending; 4 PCT (France Germany, UK, Netherlands) patents issued ~'96-'97



Back to the Table of Contents
Back to [13]   [14]    Forwards to [15]