LIST OF TABLES
Table 1.3-1 Software for the Windows NT Server
Essential elements of security for the Continuous Acquisition and Lifecycle Support (CALS) environment are reviewed as they relate to the International CALS Network (ICN), and the general problems of an Integrated Data Environment (IDE), and Electronic Commerce. These elements of security include essential methods for role-based user access and authentication, the use of firewalls, virus-checking software, encryption, and secure servers. These issues are discussed in relation to computer security threats and risks (weak links) posed by sophisticated hackers. Prudent means to maintain security for such a system are reviewed in light of standards and recommendations under consideration as Generally accepted System Security Principles (GSSP) for the Internet, U.S. Defense Information Infrastructure, National Information Infrastructure (NII), and the Global Information Infrastructure (GII), along with consideration of commercially available options and de facto best practices.
The data transmission needs for the CALS ICN and Electronic Commerce/Electronic Data Interchange (EC/EDI) include the following:
Figure 1.21 shows the hardware needed for a CALS ICN demonstration system, including the following:
Software for this system will include the following:
We will attempt to incorporate federal (Tessera) password authentication/digital signature standard software now available. Additional software such as Hot Dog HyperText Markup Language (HTML) Editor, and others will be included for applications development. Further, to permit X-Windows emulation across the network, eXceed and/or Hummingbird software will be used on local client PCs. Router diagnostic software is included in the Router and CSU/DSU units to assure line and delivery system quality.
The distribution of the software among the hardware devices is
summarized in Tables 1.31 through 1.35.
| 1.1 MS Remote Access Server (RAS) | Remote access operating system |
| 1.2 Microsoft (MS) NT 3.51 Server | Operating system for Server Platform |
| 1.3 MS Office Pro Applications | Applications (word processing, spreadsheet, presentation, database) |
| 1.4 Powwow Server | Internet/network one-to-many text and voice file transfer/sharing (groupware) |
| 1.5 HyperText Transfer Protocol (HTTP) Web Server software | Internet Web server |
| 1.6 Netscape Web Browser | Internet Web access |
| 1.7 MS Visual C/C++ Compiler | Software Development tool |
| 1.8 Expersoft X-Shell 3.5 and Iona Orbix 2.0 | Object Request Brokers |
| 1.9 MOREPlus | Multimedia Oriented Repository Environment Management |
| 2.1 Slackware Corp. Linux 3.0 | Shareware UNIX like operating system for Intel platforms |
| 2.2 Majordomo | Mail List Manager server |
| 3.1 PKINet | Rolling code password generation/ authentication |
| 3.2 Checkpoint Software's Firewall-1 | Firewall |
| 3.3 KIF and Cyc Compiler/Server | Smart agent applications/management |
| 3.4 Solaris 2.4 | Operating system |
| 3.5 Oracle 7.0 SQL and ORACLE | Database query language and Relational Database Management System (RDBMS) |
| 3.6 MOREPlus | Multimedia Oriented Repository Environment (front-end to Oracle) for the management of Web collections |
| 3.7 Samba | Internet/network file sharing |
| 3.8 Java | Internet/network object-oriented content executable language |
| 3.9 CUSeeMe Reflector | Videoconferencing software server |
| 3.10 Password One-Time Pad | E-Mail quantum encryption/security |
| 3.11 Pretty Good Privacy (PGP) | Text and voice encryption |
| 4.1 MS-NT Workstation | Operating system and Graphical User Interface |
| 4.2 MS Windows for Workgroups | Operating system and Graphical User Interface |
| 4.3 MS Office Pro | Client Portion applications (text processing, etc.) |
| 4.4 eXceed and Hummingbird | X-windows emulator software |
| 4.5 Client E-Mail (e.g., Lotus cc:Mail) | Electronic Mail |
| 4.6 Netscape Web Browser | Internet Web access and navigation tool |
| 4.7 Hot Dog HTML Editor, others | Web publishing development tools |
| 4.8 Powwow Server | Internet/network collaboration software (oneto-many text and voice file transfer/ sharing) |
| 4.9 CUSeeMe Client | Videoconferencing |
| 4.10 Password One-Time Pad | E-Mail quantum encryption/security |
| 4.11 Pretty Good Privacy (PGP) | Text and voice encryption |
| 5.1 Miscellaneous | Router and DSU diagnostics |
The interrelation of hardware, software, and data storage and transmission security are addressed below, with specifications that allow for migration to systems with multilevel security, while also allowing for the secure evolution of the system over time. In a later section we describe a migration route to an upgraded system, anticipated a year from now.
The ICN is now in the design and development stage, with implementation anticipated in two years. ICN security needs are representative of CALS as a whole. The rapid rate of technological advances means we must consider both how we may secure ICN computer systems now, and where new security technologies are leading, so that the ICN may be optimally secure when fully operational. Current technological advances in collaboration tools, networking, agents, and security will have a strong impact on DoD CALS Network (DCN)/ICN capabilities to real-time exchanges of data, imagery, voice, video, and hypermedia among individuals and groups (E-Mail). These advances will also permit creation and editing of documents and hypermedia by, and exchange among groups of people, and videoconferencing. ICN capabilities are intended to permit such communications internationally. However, while security technologies will continue to evolve, the DCN/ICN needs a stable security baseline to implement acceptable security and privacy policies.
Computer security for the ICN, Internet, National Information
Infrastructure (NII), and Global Information Infrastructure (GII)
for use in EC/EDI are all related topics. Computer security in
this context is jointly determined by a combination of national
and international standards, available technologies, industry
offerings of these technologies, financial community and public
acceptance of security capabilities, and, of course, Government
interests, including security, defense, law enforcement, and social
policy administration issues from tax collection to social security
administration. Security policies and technologies are still
in a state of great flux, so computer security mechanisms relevant
to CALS are not likely to be well-defined in the very near future.
Rather, they are likely to evolve through a life-cycle as implied
in the description of CALS as a continuous "life-cycle"
approach to program development and support.
A large part of the challenge posed by security for an ICN is that it involves security components that serves both military and commercial uses. These components are based on guidance from the Internet community, in the form of guidance by the Internet Engineering Task Force, and those of standards organizations, both national and international, as well as the requirements of the DoD and the International CALS community. International computer security had in preInternet times been overseen largely by guidance from the European Information Technology Security Evaluation Criteria (ITSEC) organized by various European Governments and computer security organizations, including those of France, Germany, England, and the Netherlands (Rihaczek, 1991). The ITSEC advocates standards rather than proscribing standards that might later prove restrictive.
The security needs required by the ITSEC international commercial
computer security recommendations are fundamental, and essentially
mirror those required of DoD and CALS systems as well (Reitenspiess,
1993):
We focus in this document on overall security management, with
emphasis on access control and authentication, which herein include
coverage of the topics of confidentiality, integrity, availability,
and non-repudiation.
Various means of meeting these security goals were attempted through
development of computer security standards by Government and professional
organizations (reviewed in McGillivary, 1994a,b). However,
the rapid development of the Internet, and its even more rapidly
expanding international and multimedia capabilities have placed
security of the global information infrastructure in the hands
of the Internet Engineering Task Force, which issues standards
on security using a comment and response process similar to those
of other organizations. Security measures for the present Internet
are well reviewed in Schiller (1995), and standards may be found
in Coyo (1995). The next generation Internet Protocol, IPng,
contains several advances in the way it handles security that
are noteworthy. The forthcoming IPng security advances are discussed
below in the last section dealing with the ICN Lifecycle
Security Plan, which includes plans for inclusion of these methods
in the ICN as they become available.
The Department of Defense (DoD) Goal Security Architecture and Defense Information System Network (DISN) Security Requirements discuss security in terms of two levels: the Local Subscriber Environment (LSE) and, the Communications Network (CN) level. The LSE includes workstations, servers, mainframes, telephones, radios, relay systems including multiplexers, routers and switches, as well as local LANs and wire lines; CN security involves both public carrier lines and infrastructure, and usercontrolled private lines and switches. We deal here only with computer security for the LSE; CN security issues (reviewed in McGillivary, 1995b) are beyond the scope of this document.
Five principles in planning for computer security are shared by the DoD TAFIM (Technical Architecture Framework for Information Management) Volume 7 on Information Technology Standards Guidance for and Open System Environment (ITSG-OSE), as well as international commercial system security organizations, like ITSEC. The principles are namely 1) having an information security policy, 2) conducting risk analysis, 3) preparing a plan for dealing with risk management, 4) contingency planning in the event of system security compromise, and, 5) developing disaster recovery procedures (DoD, 1994; Elhoff, et al., 1994; Von Solms, Von Solms and Caelli, 1993). We will review these topics in this order.
CALS information security policy must be tailored to the functions required of an ICN, i.e., dependent upon the data types to be handled by this system, as well as to the hardware and software used in the system. The security system must meet needs of both Government and commercial users. This implies specific compliance wherever possible with MILSTD1840C provisions, which call for 1) encrypting of classified headers, 2) "wrapping" of user-encrypted data files, 3) identification of algorithm and key source for the receiver, 4) declaration file digital signature records that allow for certification of the information being transferred, 5) specific data file types for transferring digital signatures, 6) unclassified material to pass unencrypted, but still wrapped via unclassified non-protected header records, and 7) user responsibility for security policy coordination regarding information transfers, including encryption algorithm and key choice, and physical security of premises (Huhn, 1995).
To meet MIL-STD1840C requirements, a CALS security policy
has been suggested that calls for two interacting security mechanisms: 1) universal
labeling, using both DoD security labels and those appropriate
for commercial data, and 2) a protocol for relating data
object security access labels with user access rights (ibid.,
1995). While DoD security labels are clear, there is no universal
agreement on specific commercial data type labels; it is sufficient,
however, to simply permit these other types of labels to be constructed,
beginning with "Proprietary," "Copyrighted,"
and similar concepts that can be added as needed. For the information
that is likely to be exchanged via the CALS network, encryption
security mechanisms discussed below help to minimize the need
to belabor this point further. We will adopt the MILSTD1840C
concept that it is the user's responsibility to select the level
of information security for information exchanged across the ICN.
In the case of CALS and the ICN, this security is principally
achieved by encryption methods readily selectable as ICN GUI options.
The suggested CALS data object access label model is an "Is
Below" (ibid., 1995). This is a type of role-based model
that can be made as specific as necessary while allowing flexibility.
We propose to implement this type of direct, simple, role-based
data access model using object technology methods, which call
for unique universal object labeling under the CORBA 2.0
object technology standard specifications formulated by the Object
Management Group (OMG) in 1994. The "Is Below" model
is not considered to be completely secure on an open system network
because the possibility of spoofing can exist; however, it is
generally considered adequate, and the easiest to organize and
maintain. In part, this is because the relationship of data objects
at different levels of access control can be mathematically defined,
and thus rapidly validated.
The method required by the MIL-STD is thus not incompatible with
current object management methods we propose, with one exception.
The method for digital signature specification called for is
that meeting National Institute for Standards and Technology (NIST)
standards calling for use of the DoD Fortezza card encryption
and hash algorithms, described in greater detail below (and in
McGillivary, 1994a,b, and 1995a,b). It has been argued
that this method is required because of the pseudo random method
encryption keys use to encrypt messages; use of a digital signature
standard provides an additional authentication check on the sender.
If truly random encryption is used, decryption by pseudo random
algorithm spoofing and guessing methods, that have recently developed
as an important and available means to permit loss of computer
communication security (e.g., Goldberg and Wagner, 1996;
Schneier, 1996), become invalid. And the need for a digital signature
may be considered redundant, and indeed, a security risk, as the
digital signature itself is made using what some consider weak
encryption algorithms (discussed further below). However, as
a choice of encryption mechanisms must be provided in the ICN,
and truly random quantum encryption methods are not available
yet for all multimedia data types, methods permitting use of the
U.S. federal Digital Signature Standard will be provided as an
option for use where required or desired.
Beyond this, security policy will involve the points that follow below, as specified in the DoD TAFIM (DoD, 1994), and as proposed for the Generally accepted Computer Security Principles (GSSP) now under development as guidelines for international computer network security (Parker, 1995). The so-called pervasive GSSP principles are included in Table 3.1-1 for reference, and are all addressed in the following ICN security policies. Specifically we follow generally accepted security principles that call for the inclusion in computer security systems of 1) firewalls, 2) password sniffer-checking software, 3) single-use passwords, 4) viruschecking software, 5) intrusion detection and audit control software, 6) information encryption capabilities, 7) encryption of all time stamp data, 8) encryption of router diagnostic software, 9) disabling Internet Protocol (IP) address release in E-Mail functions for inappropriate service requests, 10) disabling of single superuser capabilities, 11) use of CORBA 2 compliant object technology software for centralized database security management, 12) uninterrupted power supply and replicate server backup systems, 13) vulnerability assessment, and 14) periodic security policy reviews.
| 1. Accountability | Information system security accountability and responsibility should be explicit. |
| 2. Awareness | Owners, providers and users of information systems and other parties should be informed about (or readily be able to gain appropriate knowledge of) the existence and general extent of measures, practices, procedures and institutions for the security of information systems. |
| 3. Ethics | Information systems and the security of information systems should be provided and used in accordance with the information security professionals' Code of Ethics. |
| 4. Multi-disciplinary | Measures, practices and procedures for the security of information systems should address all relevant considerations and viewpoints, including technical (e.g., software and system engineering), administrative, organizational, operational, commercial, educational and legal. |
| 5. Proportionality | Security levels, costs, measures, practices, and procedures should be appropriate and proportionate to the value of and degree of reliance on the information systems and to the severity, probability, and extent of the potential for direct and indirect harm. The principle also applies to the level of management support necessary for a successful security program. |
| 6. Integration | Measures, practices, and procedures for the security of information systems should be coordinated and integrated with each other and with other measures, practices, and procedures of the organization so as to create a coherent system of security. |
| 7. Timeliness | Public and private parties, at both national and international levels, should act in a timely coordinated manner to prevent and to respond to breaches of the security of information systems. |
| 8. Reassessment | Security of information systems should be reassessed periodically. |
| 9. Democracy | Security of an information system should be weighed against the rights of users and other individuals affected by the system. |
| 10. Certification and Accreditation | Information systems and information security professionals should be certified to be technically competent, and management should approve them for operations. |
| 11. Internal Control | Information security forms the core of an organization's information internal control system. |
| 12. Adversary | Controls, security strategies, architecture, policies, standards, procedures, and guidelines should be developed and implemented in anticipation of attack from intelligent, rational, and irrational adversaries with harmful intent or harm from negligent or accidental actions. |
| 13. Least Privilege | An individual should be granted enough privilege to accomplish assigned tasks, but no more. |
| 14. Separation of Duty | Responsibilities and privileges should be allocated in such a way to prevent an individual or a small group of collaborating individuals from inappropriately controlling multiple key aspects of a process and causing unacceptable harm or loss. |
| 15. Continuity | Information Systems professionals should identify their organization's needs for continuity of operations and should prepare the organization and its information systems accordingly. |
| 16. Simplicity | Information Systems professionals should favor small and simple safeguards over large and complex safeguards. |
| 17. Policy Centered Security | Policies, standards, and procedures should be established to serve as a basis for management planning, control, and evaluation of information security activities. |
In risk assessment, threats are considered to fall into four principal categories: 1) disruption or denial of service, 2) loss of confidentiality, 3) loss of integrity, and, 4) fraud or financial theft (Phillips, 1995). These threats may result from 1) natural disasters, 2) errors and omissions, 3) mismanagement, 4) system failures, 5) industrial espionage, 6) computer hackers, 7) insiders, and 8) viruses and worms (Craft, 1995). For the ICN, we take design steps to prevent threats due to natural disasters and system failures by use of backup systems, described in the Disaster Recovery Plan section of this document. Security risks associated with mismanagement, errors, and omissions, are minimized by having a simple, clear security policy and line of responsibility, and a commonly accepted, user-friendly security protocol, described further below. Insiders are more of a problem in large organizations than in the ICN, where only a few individuals have access to server systems, but steps can easily be taken to minimize this problem. The main risks to ICN security appear to be viruses/worms, hackers, and industrial espionage, the latter two being potentially the most serious, and having some countermeasures in common.
The basis for risk management for the ICN will focus first on access control and authentication as a first line of defense to ensure hackers and others attempting unauthorized access are thwarted. A description of additional anti-hacker/espionage methods follows, and then methods for addressing threats from viruses, insiders, and system failures/disasters are presented in the following sections.
Security is dependent upon security policy, of which access control is the first step.
Role-based access security has been much debated as a means of maintaining convenient access control, while facilitating operations. Errors in management of role-based security have occurred where access control lists were stored in an insecure manner. They should always be encrypted and listed under an obscure filename as well to eliminate penetration. The use of role-based security has been considered to offer some security problems, but methods for dealing with this problem have evolved to provide adequate, if not perfect, security (Ferraiolo, 1994; Sandhu, 1994b). When combined with object-oriented software, rolebased systems with well-defined roles provide a practical and secure access control policy (Robinson, 1995; Sandhu, 1994a; Symonds, 1994; Thurasingham, 1994; Von Solms and van der Merwe, 1994, for Oracle specifically; and, Jolitz and Jolitz, 1995). The combination of roles specified as part of Personal Computer Manufacturer's Card Industry Association (PCMCIA) card or security token software can provide a means of administering this system without accessing lists of roles, thereby abetting security while enhancing the facility of the access control system.
Within the DoD Multilevel Information Systems Security Initiative (MISSI) program, four tiers of security access occur (ICE, 1995):
| Tier I: | Classified, with multi-level security, and a key escrow method required; this is to be accomplished using "Fortezza++" military crypto cards. |
| Tier II: | Sensitive but unclassified, and having national security impact, requiring key escrow methods and hardware; accomplished via standard Fortezza cards. |
| Tier III: | Sensitive but not of national security impact; to be accomplished by commercial key escrow methods. |
| Tier IV: | Unescrowed information; to be accomplished by DES or RSA-type encryption. |
For the ICN we also envision using four "tiers" of access control roles, outlined below. All ICN users will be required to register with the ICN System Operator by filling out an ICN registration form available from the ICN web page. When the applicant's IP address is verified as belonging to a CALS-associated organization/site, the applicant will then be notified by E-Mail how to proceed to receive an encrypted password. Lists of all users will be kept in files encrypted with the Message Digest (MD5) algorithm freeware (Pope, 1996).
Most ICN users will only want to access information; however,
ICN users wishing to post or update materials composing the ICN
will be provided with a "second-tier" access role that
will allow them to join mail lists or user groups by additionally
registering for these services. Notices or other information
can be posted or exchanged via these ICN forums without an additional
password, although this will be provided as an ICN webmaster option.
If ICN users wish to post material directly to the main ICN web
page, they must forward it to the ICN Webmaster, who constitutes
a "third-tier" access role. The system security officer(s)
is the "fourth-tier" access role. Use of the Fortezza
program technology (described below) has been judged sufficient
to cover up to "Secret" levels of security by DoD officials
(Constance, 1995a), so discussion of "multi-level" security
roles is considered unnecessary as Fortezza security will be provided,
and no information of a higher security level than "Secret"
is anticipated for the ICN.
Initial access control procedures will use temporary passwords. One-time passwords are available over the Internet for UNIX-based users via the S/Key freeware (Internet Request For Comment (RFC) 1760), a de facto standard available at: ftp://thumper.bellcore.com/pub/nmh/skey (Troost, 1995). Later, an encrypted password can be issued with GUI software already developed for the ICN, that makes downloading and decrypting the password the first time simple. The ICN password encryption option screen will allow several choices of password encryption, including Pretty Good Privacy, freely available at ftp: net-dist.mit.edu. PGP uses a combination of strong pseudo random key encryption methods (Noor, 1995; Ubois, 1995).
A second ICN password encryption option will be the Power One-Time
Pad (POTP) Secure Mail software (Elementrix Co., New York, NY)
(Trowbridge, 1995a). Most encryption algorithms, including the
federal Digital Signature Standard (DSS), RSA, and PGP, use pseudo
random number generators for encryption keys (c.f. Plumb,
1994). This poses serious security concerns (c.f. Goldberg
and Wagner, 1996). We prefer POTP Secure Mail software for ICN
access control and encrypted password and data distribution because
it uses truly random one-time symmetric encryption compatible
with all hypermedia data, including video and Virtual Reality
Modeling Language (VRML). Although this method encrypts an entire
message, it may be considered to obviate the need for a separate
digital signature. POTP Secure Mail software costs approximately
$50-100, available for trial from the Elementrix web page, URL:http://draco.centerline.com:8080/~franl/crypto/one-time-pad.html
Two additional password encryption options are available to accommodate
users wishing to make use of the U.S. federal DSS. One ICN password
encryption option will use a commercial product, Crypto SmartDisc
(Fisher International Systems), which uses DES and DSS on a 3.5"
disk with a proprietary-design embedded circuit board. SmartDisc
runs on standard computer drives, and is required on both ends
of a transaction. It costs approximately $100; however, as of
November 1995, the U.S. Post Office will distribute some
cards free to the public for trial use (Sikorovsky, 1995e). Some
of these cards can be made available for ICN registrants. We
offer password encryption using the SmartDisc simply because it
is likely to be a popular commercial method that ICN users may
wish to employ.
Fortezza technology is the U.S. Government's solution to single-use
password access and Digital Signature Standard capabilities for
security up to the "Secret" level (Adams, 1994c; Constance,
1995a). Full Fortezza technology capability will be an option
for password encryption on the ICN web page GUI screen in the
first year. To provide this option, we will access the Fortezza
technology from a PC-card reader accessory, the standard Government
method. Fortezza operability on the ICN user side will be the
users responsibility, as this capability is provided mainly for
DoD or defense-related users who have access to this capability.
The availability of both Netscape and Oracle software with Fortezza
capabilities should make ICN users readily able to use Fortezza
methods if so desired (Sikorovsky, 1995h).
Single-use password technology is behind the rolling code generators in several commercial products (SecurID, Security Dynamics, Cambridge, MA; and InfoKey, LeeMah DataCom Security Corp., Hayward, CA; Keeloq, EXEL Microelectronics, San Jose, CA, Millenium (Yasin, 1995), etc.). Such access control methods do not include message encryption capabilities, and thus are less functional than the access control methods described above. Tokens are among the single-use password access control methods that are less expensive and more popular than PCMCIA security cards. SecureID (Security Dynamics, Cambridge, MA) is a token device employed for access after a computer user initiates a log-on. After the user enters a personal identification number (PIN) into the computer, a code generated by the token must also be entered, and when verified as identical to that generated by an identical synchronized program on the server, access is granted (DiDio, 1994; Davis, 1995a). Tokens from Enigma Logic (Concord, CA) are similar, but after the user enters a PIN number, the host computer issues another number that is then entered onto the token's small calculator-like keypad, which responds by displaying a code used to permit access to the host computer (Zurier, 1994). SecureNet Key (Digital Pathways, Mountain View, CA) operates in this manner, but within a larger proprietary security system (Masud, 1995c). SofKey (MicroFrame, Edison, NJ) is also similar, operating inline between a portable computer and modem; with SofKey, a user enters in a password, and then software in the host verifies user identity before allowing access (Bernstein, 1995).
Other devices are more similar to the PCMCIA card in providing
encryption capabilities as well. The PersonaCard 100 is National
Semiconductors' PCMCIA contribution (Brown, 1994). The AX-400
(Information Resource Engineering, Baltimore, MD) is a secure
PCMCIA modem that has been adopted for use by the Secret Service
(Masud, 1995b), performing both authentication and encryption
using the federally approved algorithms. CryptoCom (Western DataCom,
Cleveland, OH) is a 28.8Kbit/s encrypting "pocket" modem
that is used by the Internal Revenue Service and Department of
Energy (DOE). It uses a small keypad for Personal Identification
Number (PIN) entry and works with callback host security software
(Masud, 1994). CardSecrets PC Card (Mobius Encryption Technologies,
Toronto) is similar in providing U.S. Government-approved encryption,
but also provides a choice of Rivest-Shamir-Adelman (RSA) and
elliptic curve encryption algorithms (Menke, et al.,
1995). This may be useful for the cautious: the elliptic
algorithms are statistically considerably more secure than the
RSA algorithm, of which they are a variant (Demytko, 1993).
In summary, for the ICN access control, the method of choice among
password generation/encryption options depends upon whether there
is a need to include encryption of additional data as part of
the access process. For most situations that CALS users would
face, the Pretty Good Privacy algorithms, available as Internet
freeware, are adequate for password and message encryption. This
both reduces costs and provides considerable security for ICN
users, but is useful only for text and voice messages. For multimedia
data, the Power One-Time Pad Secure Mail option is the preferred
method of generating single use encrypted passwords while also
providing full multimedia message encryption capabilities. This
avoids the need for other password control software (c.f.
Rothke, 1995). To comply with Government regulations, Fortezza
technology is available to provide similar capabilities, with
perhaps weaker encryption. These methods of access control are
important because single-use passwords are perhaps the greatest
single step that can be taken to improve and assure computer security.
A second key part of access controls and overall system security
is the firewall.
Firewalls have become an essential part of standard computer security practice, even to the extent of being used to control access between parts of the same organization. The key points of a firewall are that it 1) serve as a route for all information passing from inside to outside an organization, and vice versa, 2) pass into an organization only information specifically authorized by locally resident security policy software, and 3) that it be immune to penetration (Cheswick and Bellovin, 1994a,b). The excellent book on firewalls by Cheswick and Bellovin (1994a) describes them in detail, explaining their origin based on the premise that security programs should be segregated from the rest of a system and should be as issue specific, and short, as possible.
Firewalls can be as simple as a screened router acting
as a packet filter that refuses packets with specified addresses,
protocols, or ports. Additional security is provided by the fact
that only the router has an IP address, rather than each user
having his own. Ideally, the router should also keep a record
of its actions, perform dynamic packet filtering and routing (i.e., respond
on-the-fly to reconfiguration by other rules), verify packet protocols
by looking at the protocol messages are using, not just at the
ports they are coming from, and finally, authenticate logons,
possible via an independent server (Roberts, 1995; Trowbridge,
1995b). Router-based firewalls have problems screening certain
network protocols: FTP, DNS (Domain Name System), and
X11 (UNIX windowing). Of these, a screened router firewall can
deal with incoming FTP files by accepting only FTP files from
specified ports or passing files to another server with a cut-down
secure version of FTP, while DNS files can be ported in via a
dual-server (public and private) arrangement. Protocols in X11
are usually simply rejected unless specifically unblocked (Bryan, 1995).
A more secure firewall is obtained by putting all security programs
on one device, known as a bastion firewall, optimally a workstation.
The bastion need only have a very limited operating system, with
just the commands needed to pass information and no others. But
it is often useful to include other security software as well.
A bastion firewall can then include additional security software,
not only anti-virus software, but also anti-password-sniffing
software. The evolution of anti-virus software vendors into firewall
vendors is not surprising; a good provider of sophisticated anti-virus
and anti-virus activity scanning software, Norman Data Defense
Systems, now provides much of the U.S. federal firewall software
(Sikorovsky, 1995a). Norman's firewall software includes an additional
security feature as well: it scans all documents it
deals with for specific words and syntax to prevent data passage
- in or out of a network - of materials that are restricted.
This additional security, termed type enforcement, is also provided
by Sidewinder (Secure Computing Co., Roseville, MN), and provides
an additional mechanism for protecting sensitive information,
e.g., anything with the names of executives or products still
under development (ibid., 1995b). Products such as Sidewinder
include user identification and authentication as an essential
part of their firewall activity, and provide real-time intrusion
notification to security managers.
The need for firewalls to protect against spoofing of information
packet IP addresses came to wider attention when it was discovered
this was the method used by Kevin Mitnick to access the San Diego
supercomputer facility (Power, 1995b). Firewalls by vendors such
as Livingston Enterprises (Pleasanton, CA) provide such protection,
which has become an essential feature of most commercial firewall
products. The use of Kerberos protocols for authentication in
a firewall has also been developed (see Cheswick and Bellovin,
1994b; Cobb, 1995). Authentication does not necessarily protect
against tunneling, however. Tunneling is where one protocol is
nested inside another and information is passed from the inside
of an organization to the outside by an insider. To minimize
this type of insider security breach, a third type of firewall,
a circuit-level firewall, can be constructed to specifically monitor
only outgoing packets and can be configured to indicate where
problems of this sort arise (ibid., 1994b).
Encryption is also becoming more popular as a standard part of
a firewall. The LAN Guardian Protector (Uunet Technologies, Falls
Church, VA) provides an encryption chip as part of its firewall
system; files routed there as requested or preconfigured are encrypted
before passage by the firewall, with the chip providing the speed
needed for on-the-fly encryption (Johnson, 1995). To facilitate
security management, a growing trend in firewalls is the inclusion
of flexible GUI management interfaces such as those found in FireWall-1
(CheckPoint Software Technologies, Lexington, MA), a firewall
system selected to work with Sun workstations (Burnette, 1994;
Dawson, 1995). Firewalls are also available for mobile users
(e.g., EagleNomad from Raptor Systems, Waltham, MA: Masud,
1995a), and more are appearing on the market as wireless becomes
more popular.
Useful web pages and Internet forums such as Firewalls and the
Firewalls Digest are readily available for assistance and for
the latest information in setting up a firewall. On the Internet
one can find freeware called "Screend" for packet-layer
firewall construction, and application layer firewall freeware
"Socks," and the Trusted Information Systems "Firewall
Toolkit," all of which are useful (Bryan, 1995). Commercial
firewall software does not come cheap, and freeware is risky unless
expertly configured or highly restricted. Where information security
is critical for applications such as routine FTP transfers from
miscellaneous sites, a commercial firewall may well be necessary.
For most CALS-related users, firewall freeware can be combined
with antipassword sniffing and virus-checking software,
and with the inclusion of authentication and encryption capabilities,
sufficient security should be provided. If funds are available,
FireWall1 (CheckPoint Software Technologies, Lexington, MA)
appears to be the preferred Government and commercial firewall
that could be used for the ICN.
Firewalls are supposed to keep trouble at arms' length, and intrusion detection systems are supposed to identify and notify network system security managers when security is breached. Testing of both these systems is thus related. A number of freeware security testing programs are available which can be applied to determine if firewall and intrusion detection systems are in order. Such programs include COPS (ftp://cert.org in directory /pub/tools/cops), Tripware (ftp://ftp.cs.purdue.edu in directory /pub/spaf/COAST/Tripware), Open Market's Security Watch (http://www.openmarket.com), and the well-known SATAN (System Administration Tool for Analyzing Networks) program (ftp://ftp.win.tue.nl/pub/security/satan_doc.tar.Z). (Commentary on SATAN may be found at: http://ciac.llnl.gov/ciac/notes/Notes07.html).
The DoD Defense Information Systems Agency (DISA) Center for Information
Systems Security (CISS) Countermeasures Department maintains an
Automated Systems Security Incident Support Team (ASSIST) which
has a Vulnerability Assessment Program (VAAP), for security testing
of DoD-related computer networks. We can request ASSIST perform
an ICN VAAP as a firewall/intrusion detection systems check.
To provide an intrusion detection system, we will include the COURTNEY software on the firewall (http://ciac.llnl.gov/ciac.ToolsUnixNetMon.html#Courtney). When installed, COURTNEY alerts a system manager that someone is running SATAN on the system (Sikorovsky, 1995b). Most other intrusion detection software is proprietary and costly if purchased independently of firewall software. However, DoD efforts continue to focus on refining intrusion detection software through the use of artificial intelligence (Brewin, 1995). The Air Force's Distributed Intrusion Detection System (DIDS) continues to evolve in this regard (Constance, 1995b). Likewise, within DISA, the Center for Information Systems Security (CISS) has been given enhanced visibility and funding following a move to the Global Command Center, where its ASSIST personnel provide continuous system intrusion detection and response capabilities (Grimm, 1995). Both these groups have formed closer ties with academic and professional computer security organizations in the past year. From this association, software they are developing should become available for CALS and ICN applications relatively soon. Until readily usable intrusion detection shareware or freeware is available, we recommend using audit tracking software in the FireWall-1 firewall software (CheckPoint Software Technologies, Lexington, MA), if funds permit.
The Fortezza card was intended to provide for secure access control by additionally providing for user authentication through the use of public key encryption technology. After the Fortezza card, originally known as the Tessera card, was introduced, problems with implementation arose. First, there were questions about the algorithms used on the card; and, second, there was considerable debate as to how exactly the escrowed key management system was to be operated. These issues are reviewed in detail elsewhere (McGillivary, 1994a,b, 1995a,b).
The Fortezza card was greatly resented by the public, and its mandatory use eventually withdrawn by the Security Infrastructure Program Management Office (SI-PMO), a joint defense-civilian board that includes representatives from DoD, National Security Agency, National Institute of Standards and Technology, the General Services Administration, Postal Service, as well as Agriculture, Treasury, and Justice Departments. The SI-PMO has determined that algorithm neutral, technology independent solutions should be accommodated in the joint Government-commercial security infrastructure being developed in response to legislative mandates for NII security methods development (Constance, 1995c; Sikorovsky, 1995g).
The next generation Fortezza cards, available in 1996, will thus
have the ability to switch among user-specified algorithms. It
is presently unclear whether they will include the capability
to use a family of encryption algorithms switched off in random
sequence as has been recommended to improve security (Schneier,
1994). And while the change in Government policy regarding the
Fortezza card improves selection among encryption algorithms,
the problem of escrowed key management remains. Within the Government,
a new system is being implemented for secure electronic distribution
of encryption keys. The National Security Agency (NSA) is "Tier
0" in the key management system, as the source of keys which
are distributed by an electronic keyring program, initiated by
GTE, to the successively lower tiers: the DoD hubs,
bases, ships, and "warriors" (Adams, 1995a). This system
is automatically employed by all Fortezza card users.
Federal encryption key management for the public sector was originally designed with the keys to be held by the Justice Department, to be released only under subpoena in accord with existing wiretap laws (Sessions, 1992). But the possibility of misuse of this scheme and uneasiness with Government management have delayed the so-called Public Key Infrastructure (PKI) (Power, 1995a). NIST efforts to mount a PKI program to use Fortezza cards to provide for a DSS collapsed in an era of budget cuts, in part due to the unpopularity of the Clipper and Capstone algorithms NIST proposed (Power, 1995c,d). But the need for a DSS remains, if only for the Federal Electronic Commerce Acquisition Team (FECAT) to use the Government electronic commerce scheme they envision in accord with the Presidential Mandate that electronic commerce be in place by 1997 (ibid., 1994; 1995a). Efforts by the FBI to promote DSS escrow methods (Munro, 1995b) are faltering due to the international nature of the Internet; meanwhile commercial, and public sector "half measures" are being suggested.
There is a federal standard for a secure encryption "module" (Federal Information Processing Standard (FIPS) 140-1) that covers the tamperproof manufacture of encryption in modules such as PCMCIA cards or other devices (Adams, 1994a). AT&T and another company have announced their own PC card-based DSS technology based on implementation of multiple versions of the existing DES now used by banks (Bass, 1995; Power, 1995c). Unfortunately, due to the use of pseudo random keys, this can weaken the security of an encryption algorithm, and at best does little to statistically increase its security (Highland, 1994a; Kaliski and Robshaw, 1996), particularly when compared with use of multiple algorithms (Schneier, 1994). Other commercial DSS efforts are also underway by several companies, including Trusted Information Systems' (Glenwood, MD) proposed Commercial Automated Key Escrow (CAKE) system (Anon., 1995d; Munro, 1995a). A joint commercial-federal DSS has been proposed by the Premenos Corporation that would use the U.S. Postal Service as the "trusted service" to keep the public keys (Semich, 1995). For nonGovernmental users of the Fortezza technology option, authentication will be done through either DoD/DISA or the U.S. Postal Service. For other users, authentication will involve commercial software methods.
Commercial key escrow management schemes would still allow the Government to subpoena keys for law enforcement, but not use the federal DSS, or use it in combination with proprietary software and/or hardware. But before such commercial alternatives become accepted, there must still be 1) clear public policy on privacy, 2) legal liability laws regarding accidental key release, 3) clear laws on key access rights by the Government, and 4) clear legislation on the export of encryption used in such a system (Munro, 1995a). The cost of using DSS technology has somewhat limited its appeal (Sikorovsky, 1995i). However, a bigger problem with the DSS and other authentication algorithms for electronic commerce has been the weakness of the encryption algorithms allowed for international export (Meeks, 1995; Munro, 1995c). This is a problem due to the international nature of the Internet. One electronic cash provider made use of the 40-key encryption algorithm used for electronic commerce by CyberCash (Reston, VA), and VeriSign (Redwood City, CA) which is used by Netscape and Apple for electronic commerce (c.f. Baron, 1995; The, 1995), only to have it soon broken in a fairly unsophisticated effort in France, and then the U.S. (Goldberg and Wagner, 1996).
A second problem deals with access rights by the Government to
authentication information, and the related issue of privacy.
As previously proposed, the Government could know where and when
all access to the escrowed keys occurred even if it did not decrypt
messages. A key escrow scheme for digital signatures that permits
authentication but keeps the identity of the signer secret from
the authentication authority has been suggested that addresses
this problem. This socalled blind signature was proposed
long ago (Chaum, 1983), but has only recently been attempted (Carmenisch,
et al., 1994; Horster, et al., 1994).
Both the initial and subsequent attempts at blind signatures
have, in their turn, been demonstrated as flawed (Harn, 1995),
thus a blind signature method does not yet appear to exist. This
is of particular concern given the possibility of compromise or
collusion of the authenticating authority in reading encrypted
messages (Deutschland, 1995). This is so because message handling
protocols refer to messages by their signatures, so-called signature
nesting, as in service requests, including audit trails.
Storage of data with nested signatures in public key cryptosystems,
including that of the widely used RSA algorithm, permits key spoof
attacks, where a bogus message and a bogus key give the same signature
as the real key and message; signatures may thus be compromised
(Christianson and Low, 1995). The possibility that this might
occur would perhaps seem remote were it not for a spate of cases
in recent years where secrecy of Governmentheld computer
systems and files has been compromised, from agencies as diverse
as the Federal Bureau of Investigation, Central Intelligence Agency,
DoD, and Internal Revenue Service, to name only a few. To counter
this possibility, it is necessary to include only the public key
of the signer within the body of the "nested signature";
this is sufficient to remove the possibility of a key spoofing
attack (ibid., 1995). Previously developed access control
and authentication methods for distributed systems can then be
successfully put in place (c.f. Low and Christianson, 1994).
If the commercial DSS process is carried out as described above,
and if signatures are authenticated by some proposed shared verification
schemes (c.f. Harn, 1995), it has been shown that inclusion
of a digital signature must still accompany more than a single
piece of information used in the shared verification/authentication
process to avoid the possibility of signature forging; i.e., it
must appear with all objects transmitted (Horster, et al.,
1995).
With proper attention to such methodical "fine points,"
shared authentication methods are presumably possible without
the risk of compromise. It is noteworthy that cryptologists are
only now developing formal logic mechanisms which appear at the
present time to be secure - but such proposals are very recent,
and it would be unwise to proceed until at least some further
discussion and consideration of these proposed mechanisms has
been developed. Meanwhile, Government policies on key escrow
and authentication mechanisms remain to be formalized.
Official adoption of the practices described above (or similar
ones) by key escrow agencies can be considered critical if truly
blind digital signatures and secure distributed authentication
are desired. The ability of the Government to perform key spoofing
attacks to decrypt messages by key spoof attacks on nested signatures
is then prevented. This may be considered a liability from the
point of view of law enforcement agencies, which suggests development
and adoption of truly blind signatures may be unlikely to be emphasized
as official U.S. security policy for the National Information
Infrastructure. But as part of the Global Information Infrastructure
(GII), the issue is likely to arise because of the differences
in U.S. and European privacy laws. In Europe, the development
by the European Union of Secure Hyper-G (Flohr, 1995), and of
the Secure Local Area Network Environment (SELANE)/AKI system
proposed by the European Institute for System Security is clear
evidence that the U.S. DSS is internationally unacceptable for
secure authentication.
While we will provide the DSS for authentication, and because
secure Hyper-G and the SELANE/AKI system are not yet in place,
we therefore chose to use the authentication included in the Power
One-Time Password Secure Mail software (Elementrix Co., New York,
NY) that is also used for one-time password generation, as described
above (Trowbridge, 1995c). Because this system uses truly random
encryption, the passwords can be assumed to have the same security
as a digital signature. As an alternative, we will also provide
as an authentication option using the Crypto SmartDisc's 3.5"
disk (Fischer, Co.) with DSS, which employs only the DSS portion
of Fortezza technology. While this is not expensive (approximately
$100), users would be required to possess their own systems
for this method. Commercial browser authentication methods,
such as those attempted without success to date by Netscape and others, despite recent security
"fixes," still appear too great a security risk (c.f. URL http://www.c2.org/remail/by-www.html)
for use by the ICN.
If the proposed ICN is provided with a reasonably strong firewall, makes use of one-time passwords, and has encryption options available for transmission of all sensitive materials, the risk of hackers and espionage by password sniffing and message decryption is minimized, but potential problems are still posed by denial of service, hacker message interception, or access to superuser capabilities, and other possible security breaches (c.f. Bilodeau, 1995). Risk management is important to mitigate the risks posed by hacker and espionage efforts to use the most readily available security shortfalls in a computer system. Described below are six additional steps that we will pursue for the CALS/ICN to minimize hacker and risk espionage:
We will maintain both the SATAN and COURTNEY computer freeware to, respectively, test the ICN for potential security weaknesses and to inform us if other parties are using SATAN to probe for ICN weaknesses. These programs are freely available:
For an amateur or professional hacker, a likely point of attack on the ICN system might be the router. At a router, a hacker can intercept (and potentially replicate and forward) messages, or intercept access to the system as a user (Lang, 1995). Routers connect local networks to lease line providers, and it is at this junction where service availability is most generally disrupted by "normal" network and system failures. To overcome reconnection problems posed by such routine system failures, routers have diagnostic software to tell them what sort of failure may have occurred, and how they may recover (where possible without requiring user intervention). Router diagnostic software is outside typical firewalls, and can thus be easily spoofed as a means of surreptitious access to a network (Tardif, 1995). Connections to the Internet have recently become a much more common use of routers than simply being used for connection among parts of an enterprise. To deal with the problem of spoofing of router diagnostic hardware via Internet connections, security software for routers and servers has recently been provided and/or improved (c.f. Pappalardo, 1995).
Router makers are now including security auditing software as
part of their product, as in the case of the inclusion of "Netstalker"
router security software installed on Network Systems Company's
(Minneapolis, MN) routers (Roberts, 1995). This software
works with the company's "NetSentry" firewall software,
and includes audit trail and real-time alert capabilities, but
at a cost of $5,000. A similar router security product, the Defender
Security Server, a server authentication software package from
Digital Pathways (Mountainview, CA) that works with Novell
NetWare and Microsoft Windows NT, uses a two-challenge response
system to make sure users are who they say they are, and have
not just intercepted access to a line. Cost for this software
is $2,000 and up. A new technology that continually verifies
the user's identify has been patented, but is not yet available
(Lang, 1995). In the absence of reasonably inexpensive router
protection systems, routers are still an easy target for hackers
and espionage. Unsubstantiated claims such as "our router
is hackerproof because only it has an IP address,"
(Anon., 1995c), can only be viewed as marketing hype. We will
investigate reinstalling router diagnostic software in an encrypted
form to minimize router diagnostic spoofing as a means of illicit
access to the ICN. This will be a goal of an improved security
for the ICN by the end of next year.
Denial of service is a principal security threat, considered particularly problematic for web pages with interactive features allowing users to make requests for information or services, as is planned for the ICN. Under these conditions, the requester may turn hacker by simply repeatedly making requests, and thereby overloading the server, resulting in denial of service to other users. The simple solution to this problem is to make use of firewall software that tracks user addresses and requests, and including additional software that limits the number of connects from a given address during a given period of time. This requires merely a simple modification of the use tracking software described elsewhere in this plan.
As stated above, we will attempt to minimize the possibility of misuse of single-user "superuser" capabilities as an additional step to thwart hacker or espionage security breaches. Operationally, when superuser status is required, a log-on screen will pop up requesting access password on the immediate user machine, and request specification of co-superuser access at another (local) site. When co-superuser password authentication is verified at the second location, superuser status is granted to the initial requester. This simple step, of requiring two [authenticated] persons to log in on a different machine at the same physical location to permit access of "superuser" status, can be most useful in minimizing hacker intrusions, while having a minimal effect on ICN operations. A list of four to five persons will be specified to qualify as potential co-superusers (or in effect superuser authenticators) to minimize potential operational difficulties due personnel absence due to travel, vacations, illness, or other activities.
While we cannot reasonably control security shortcomings of existing Internet protocols, we can make use of intrusion detection and audit tracking software as part of a firewall. This is discussed in the section on firewalls, above.
For DoD, security is handled by the Defense Information System Agency (DISA) Center for Information Systems Security (CISS) Countermeasures Department. Within CISS, members of ASSIST (the Automated Systems Security Incident Support Team) will conduct a Vulnerability and Assessment Program (VAAP) on DoD-related user systems on request. When an assessment is complete, they distribute appropriate advisory [correction] bulletins via a .MIL domain customer FTP site. To receive such communications, the ASSIST.MIL FTP site requires anonymous FTP connections from Milnet addresses registered with the Network Information Center (NIC) or Domain Name Server (DNS) offices. (Unregistered systems must provide a Milnet .IP address to ASSIST before access can be granted.) We will request a VAAP prior to operation of the CALS ICN as a step to minimize hacker/espionage risks.
A proliferation of destructive/disruptive viruses continues: the number of both reported virus attacks and known viruses has essentially doubled each year since 1990, with some 4,000 viruses now known (Steinberg, 1995). Where security protocols are lax, viruses, particularly boot sector viruses, can readily gain a foothold (Kendall, 1995). Most anti-virus software looks for known viruses, which can be a limitation in the face of growth in the number of new viruses. Moreover, testing of anti-virus software has reported great variability in the efficacy of commercial products (Anon., 1994b). Newer anti-virus software has been developed with an ability to check for viruses in an encrypted form (as they must be decrypted to run), as well as polymorphic viruses (Dibbell, 1995; McCarthy, 1994). Other anti-virus software has been developed specifically for distributed systems (Anon., 1995e), and on programmable, fieldupgradable chips that are part of Ethernet adapters that check for bootsector viruses (ROMShield, Relia Technologies, Los Gatos, CA).
Sophisticated search engine software can assist in looking for
virus-like code, but virus encryption and high-level computer
viruses can complicate matters (Magruder, 1994). A few simple,
specific steps can be taken to modify virus-checking programs
to improve their effectiveness for detection of Surrogate File
Viruses (SFV) and Corresponding File Viruses (CFV) in firewall
software such as inclusion of a program to abet a file integrity
checker to detect a SFV to see if a corresponding Common Object
Model (COM) file already exists in the current directory (a cause
for suspicion of a CFV) (ibid., 1994). Other types of viruses
are also becoming risks; for example, the capability of encoding
viruses in graphics as unused color bits that could easily escape
detection has been noted (Walton, 1995).
In the recent months, two new types of viruses have been spread
over the Internet. In one case, the virus was an entirely new
type, a macro virus written in Word Basic that infects Microsoft
Word 6.0 documents rather than programs, and can be distributed
in these documents over Internet to both PC and Mac machines;
the second case was a virus that attacked executable directories
and evaded virus-checking software by mutating with every infection
(Alexander, 1995). Other viruses are said to reside in icons,
activated by clicking on a web page somewhere in cyberspace.
The combination of agent technology and the Java executable language
(or "virus implementation language" according to William
Cheswick, in Wallich, 1995) increases the likelihood of security
difficulties of this sort (Dibbell, 1995; Wallich, 1995). Indeed,
the only difference between existing commercial agents written
in Telescript language for General Magic Co., and "wild"
viruses, both of which replicate across networks, is that the
Telescript agents interact only with specific other control agents
that must be resident, and Telescript has encryption-protected
instructions inhibiting them from accidentally subverting control
of a host machine (Dibbell, 1995). As agents become more popular
in the future, security issues they involve will, along with those
posed by Java, be important to monitor.
For now, the best methods are to install anti-virus software as
part of server firewalls, and to use network management security
software that monitors for virus-like activity and has the capacity
to take appropriate actions when this form of intrusion is detected.
It should be noted that realtime detection of virus activity
is still widely considered problematic (c.f. Ladkin
and Thimbleby, 1994). When smart agents are further developed,
it should be possible to use them to monitor Internet sites where
new virus data and anti-virus software updates are available.
The most readily available virus shareware designed specifically
for the detection of viruses potentially spread across the Internet
is McAfee Associates (Santa Clara, CA, Phone 4089883832)
WebScan ($45), which complements its other products, VirusShield
and VirusScan (Leach, 1995). WebScan checks all E-Mail and documents
downloaded over the Internet to assure they are not virus-infected
by connecting to major browsers and intercepting and scanning
the download and alerting the user if a problem is detected before
allowing the download to proceed. It does not itself clean files,
but can interface with other products if this is desired. It
works with Mosaic, Netcom's Netcruiser, and Netscape's Navigator,
and methods are underway to permit it to work with Microsoft's
Internet Explorer. This software is available as on-line shareware,
and will be sufficient for initial implementation. Later, DCN/ICN
implementations will use smart agents to detect and eradicate
new viruses.
But the responsibility for security is also principally held by the ICN systems operators. To minimize insider security risks, we adopt the position of changing all default superuser commands to requiring the action of two individuals, rather than one, a simple but effective protocol change. If root or superuser capability is gained by a hacker, this alone is insufficient to make system-wide changes or to result in system-wide access in the absence of interaction with another existing superuser in real time at the host location. This method of reducing insider risk will be supplemented by intrusion detection software in the second phase of this project, which would also be targeted at indicating anomalous or illicit superuser activity. Such software is now available but proprietary; serviceable shareware in this area is developing and should be available within the near future. We will adopt its use as soon as available at reasonable cost. Available intrusion detection software for the ICN system is discussed in the sections on firewalls and firewall testing sections. A more serious security problem is posed by viruses and worms.
A response to natural and system failure disasters is described below in the disaster recovery plan, which deals with disaster prevention as well. Risk management is reduced by having a clear, simple security management plan, and chain of responsibility. For the ICN, this is simple: the user is responsible for the security of any information placed into the ICN using appropriate security mechanisms provided by the ICN, as described below. These include those recommended by the Internet Engineering Task Force, as well as those required by the U.S. DoD and federal agencies. Additional commercial encryption options are also provided to minimize outside threats to confidentiality and integrity.
A contingency plan is required in the event there is a suspected or known breach of security. There are several parts to the present ICN contingency plan.
As part of the ICN, we will install user documentation software which tracks, and can report on, home page "hits," including the IP addresses of system users and authentication information (Lynnworth, 1995). The first action in the case of a suspected contingency will be to review output from this software. A second, related step will be to review similar user tracking and anomalous behavior/intrusion detection software from the firewall software system. The third step will be to scan all files in and across the system for signs of file alteration or corruption, including comparison with files held in the replicate server.
If these actions produce additional suspicion of a potential system
security breach, we will review contingency procedures outlined
in the "What To Do If Your Site Has Been Compromised"
web page (Savage, 1995), at:
http://www.cis.ohio-state.edu/hypertext/faq/usenet/computer-security/compromise-faq/faq.html.
If compromise seems likely, we will contact appropriate monitoring authorities, listed below.
As a joint DoD/industry collaboration, a number of computer system security authorities exist that are potentially relevant for the CALS ICN network, and might be contacted in the case of a suspected security breach. For DoD, the principal security incident response team is the Defense Information System Agency (DISA) ASSIST team, which is a part of the Center for Information Systems Security (CISS) Countermeasures Department. [The ASSIST team is complemented by an Air Force Computer Emergency Response Team (AFCERT) as well, also listed in Table 3.4.2-1.] In the case of a contingency, the ASSIST team will be the CALS ICN advisor of first resort. As mentioned above, we will ensure that the CALS ICN requests a Vulnerability and Assessment Program (VAAP) assessment prior to operation as a means of both ensuring security, complying with DoD requirements, and ensuring eligibility for ASSIST cooperation in the case of contingency.
An Internet Engineering Task Force (IETF) security working group
was begun in April 1994, and may also be contacted regarding
contingency incident response; it merely provides a standardized
information form for use by incident team responders and vendors.
(See Table 3.4.2-1 for the Internet URL for the IETF's Incident
Reporting form.) We will provide this form to the DISA ASSIST
Team and/or other external advisors in case of a CALS/ICN computer
security contingency.
| ASSIST | The DoD-wide security incidence response team, available at: Phone: 800-357-4231 Com.: 703-607-4700 FAX: 703-607-4735 EMail: assist@assist.mil Internet: http://www.disa.mil/ciss/assist.html |
| FIRST | Forum of Incident Response and Security Teams, a global organization coordinated at NIST that includes CIAC (see below) and some 30 computer security organizations. The list of members is available at: Internet URL: http://www/dfw.net/~aleph1/teams.html and FIRST itself may be contacted via Internet URL: http://csrc.ncsl.nist.gov/first/http://www.first.org/first |
| NCSA | National Computer Security Association, Carlisle, PA, available via CompuServe Forum, at GONSCA, or
EMail: 74774.1326@compuserve, or Phone: 717-258-1816 |
| CERT | Computer Emergency Response Team Coordination Center, Carnegie Mellon University, Pittsburgh, PA, available via Internet URL: http://iss.net/~iss/faq.html or for "Ongoing Network Monitoring Attacks," these are available via FTP: info.cert.org in the /pub/cert_advisories/CA-94:01.network.monitoring, or for "IP Spoofing Attacks and Hijacked Terminal Connections," again FTP: info.cert.org/pub/cert_advisories/CA-95:01.IP spoofing, or EMail: cert@cert.org, or Hotline Phone: 412-268-7090 |
| CIAC | U.S. Dept. of Energy Computer Incident Advisory Capability at the Lawrence Livermore National Lab, Livermore, CA. This organization has several electronic publications dealing with computer security:
The CIAC may be contacted, and their publications accessed via an EMail subscriber request to: EMail: to ciac-listproc@llnl.gov, or FTP: at ciac.llnl.gov [contains all CIAC, CERT/cc, NIST and Defense Data Network (DDN) info], or by IP address: 128.115.19.53 [use Internet address as password] Phone: 510-422-8193 FAX 510-423-8002 |
| AFCERT | Air Force Computer Emergency Response Team (San Antonio, TX) Phone: 210-977-3156, or Phone: 210-977-3214 for the ESET/Recovery/Profiling Team |
| FBI CART | Federal Bureau of Investigation (FBI) National Computer Crime Squad, including or Computer Analysis and Response Team (CART), FBI Crime Lab, Washington, D.C.
Internet: http://www.fbi.gov/compcrim.html Phone: 202-324-9164 E-Mail: nccs@fbi.gov |
| IETF | Internet Society Internet Engineering Task Force (IETF) Working Group on Security and Working Group on Operational Requirements jointly co-chartered "Guidelines and Recommendations for Security Incident Processing (GRIP)" which includes two component drafts, one for Incident Responders, one for Vendors, completed September and June of 1995 respectively, available over the Internet at: Internet: http://www.ietf.cnri.reston.va.us/html.charters/ It is merely a template for incident responders and vendors, a form to use and fill in as they report (or report on) incidents. The Security working group web page also includes information on IP security protocols and web transaction security. |
| ACM | Association of Computer Machines (ACM)
Special Interest Group on Security, Audit, and Control, available at: EMail: info-dir_sigsac@acm.org Phone: (Newsletter editor) 202-767-3490 |
| IEEE | IEEE Technical Committee on Security and Privacy Internet: http://www.ieee.computer.org and http://www.ieee.usab.general |
| Network and Computer Security Reference Index | A general computer security web page with links to many other computer security pages may be found at: Internet URL: http://www.tansu.com.au/Info/security.html |
| USENET Newsgroup | For viruses specifically, one may contact: USENET newsgroup: news:comp.security.misc or news:comp.virus or ftp:oak.oakland.edu/pub/misc/virus or possibly via subscription to: EMail: bugtraq-request@Crimelab.com |
Although the ASSIST team is both the logical and most affordable (free) assistance service, there are other such incident response teams that should possibly be contacted, or may be contacted if not already contacted by the ASSIST team, or which may be considered as alternatives to the ASSIST team. The panoply of possibilities can be assessed by turning to the Forum of Incident Response and Security Teams (FIRST) group's web page, which lists the 40 or so participating security response teams. FIRST has the largest (global) scope of security response groups. FIRST listings include another federal response team, the DOE Computer Incident Advisory Capability (CIAC), run out of Lawrence Livermore Lab, and the FIRST web page includes the CIAC repository, which offers links to several other U.S. computer security groups. CIAC itself has stated it will begin to charge civilian agencies for security assistance, but there are other organizations listed in FIRST that may offer assistance at no cost.
Perhaps the best known of the FIRST teams is the Advanced Research
Projects Agency-funded Computer Emergency Response Team (CERT),
at Carnegie Mellon University. CERT recently announced it was
"swamped" with work, however, and pending additional
funding, wish to be considered a last resort for real emergencies
(Sikorovsky, 1995c). If required, we could follow the CERT
contact procedures in case of a contingency outlined in Fithen
and Fraser (1994). Other no-cost contingency response options
include the Federal Bureau of Investigation's National Computer
Crime Squad, whose Computer Analysis and Response (CART) team
offers assistance if computers are suspected to have been used
to commit a crime (theft, espionage, fraud, etc.).
In addition to these groups, there are nonGovernmental computer
incident, advisory, and response groups that include the National
Computer Security Association (NCSA), ASIS (the American Society
for Industrial Security), and the ACM and IEEE professional society
interest groups on this subject. Additional information on references
to assistance might be sought from the National Computer Security
Center (NCSC) computer system, called DOCKMASTER, which integrates
all federal computer security information, including that for
DoD and other agencies. (NCSC does not itself assist in response
to incidents, however.)
Additional contacts may check vendor web pages for problems/fixes,
the newsgroup news:alt.security.index, or ASIS (the American Society
for Industrial Security).
In the case of natural disaster or system failure other than due to intentional human actions, the main goal is threefold: 1) to ensure the persistence, and 2) to secure all information; and 3) to facilitate restart. In the CALS ICN, accomplishing these goals is achieved by maintaining backup files of all information on a replicate server, located inside the firewall (see Figure 1.21), and also the use of an Uninterruptable Power Supply (UPS). Disastrous failures that result from a power outage longer than the UPS can provide power to the system (15+ minutes for those in use for the CALS ICN) will automatically reboot when the power returns under software in the LAN's Novell Recovery Kit, with retrieval of backup files from a backup tape or other device. A second principal cause of disastrous service interruption is the result of system component failure. The Novell Recovery Kit software will again take care of backup information retrieval; however, in the case of damaged system components, this must be initiated by human operator intervention. A backup reboot may be initiated only by [dual key] superuser authority. The Recovery Kit includes software for information retrieval from damaged hard drives and disks.
If the controversy over the DSS and privacy is not resolved, it is quite possible the present freeware system of security over the Internet may persist and evolve.
E-Mail security could now be obtained by using devices like the Power One-Time Pad (POTP) for Secure FTP and Secure E-Mail to provide one-time only passwords to ensure security of EMail and FTP file transfers (Somers, 1995). These hardware devices have to be present on both ends of the connection however, as would any other token. The DoD has already tested the Fortezza card as part of its secure EMail program (Messmer, 1994). Other federal agencies may await the newly agreed upon RSA-based Secure-Multipurpose Internet Mail Extension (SMIME) that is supported by Microsoft, Lotus, and several other major software vendors. This software-only security may be favored because of its much lower cost than token or PCMCIA card security solutions (Sikorovsky, 1995d). This solution is intended to work with the new Multipurpose Internet Mail Extension (MIME) mail protocols in the next version of the Internet Protocol, which is discussed in detail below.
The Pretty Good Privacy (PGP) program provided by Phil Zimmerman
freely over Internet since 1991 is widely used for secure EMail
of text and voice data (Barrus, 1995). The only problem
is that the NSA has objected to it, arresting Zimmerman, who is
still charged with its export in violation of U.S. national security
laws (Noor, 1995; Winder, 1995). PGP is based on the
wellknown public key RSA algorithm, and two others, MD5,
an algorithm developed by Ronald Rivest in 1992, and IDEA,
the International Data Encryption Algorithm, a fast private key
algorithm with a long (128-bit) key developed by Xue Lai
and James Massey (Barrus, 1995). The E-Mail message
is first encrypted with IDEA using a random session key, then
the session key is RSA encrypted with the public key of the person
the message is being sent to, and finally, MD5 is used to hash
the message, so that if it is altered en route, this will be apparent.
Thus, PGP combines fast private key encryption with convenient
public key encryption.
In one configuration, PGP can be used to encrypt only the signature
of a message, not the message itself, which can be useful. Under
this protocol, the message is still run through a socalled
radix-64 program that converts it to ASCII only characters accepted
exclusively by many EMail systems. Without the key the
message, though unencrypted, will still be illegible (Stallings, 1994).
With earlier versions of PGP, there was a problem of what to
do if the key password is lost, but options in the latest version
ameliorate this problem (Ubois, 1995). Although PGP can
presently handle only text and voice EMail, a version that
will handle all MIME multimedia objects is nearly complete (URL
http://www.c2.org/remail/by-www.html). We will make this method
an option for secure multimedia data transmission as soon as it
is available.
Whereas PGP is based on person-to-person security, another alternative,
Privacy Enhanced Mail (PEM), was configured according to Internet
protocols to provide secure E-Mail authenticated in a hierarchical
manner (Kent, 1993). PGP requires users be "introduced";
software for this is available that was developed by M. Graff
(Iowa State University). The software works with common EMail
software, and there is an MIT version of PGP that works with World
Wide Web server software to store public keys for use when needed
by PGP (Schiller and Atkins, 1995). But how does the user authenticate
that the public key from browser software really belongs to the
person to whom the user wants to send a message? In PGP, this
is done by any trusted third party also signing the message to
build a "web of trust." The problem with this lies
in the lack of specification for assurance of verification by
the third party. This contrasts with PEM where authentication
is strictly hierarchical and specified by the Internet Privacy
and Security Research Group, which uses authentication service
of the Internet Society as a Policy Certificate Authority (PCA).
In order for this to work, however, the mailer (or its company)
must be registered with the PCA (and in the case of a company,
have a system in place for issuing the mailer a key). The latter
requirement has meant that to date this system is not widely in
use, although available.
PEM is a standard that specifies use of tripleDES for message
encryption, DES or RSA for session key encryption, and MD5 for
hashing. Riordan's Internet Privacy Enhanced Mail (RIPEM) is
the actual software implementation of this standard, which is
distributed by the RSA Corporation (Trowbridge, 1995a). Like
PGP, RIPEM is export-restricted. A key difference between RIPEM
and PGP is that in PGP people can sign using another person's
key, whereas RIPEM is more for the business environment, where
authentication of the key comes from a network server, not an
individual. PEM also disallows sending of encrypted messages
that are not signed, which PGP does not (ibid., 1995a). Anyone
can check on a PEM message's authentication, making PEM messages
subject to traffic analysis not possible with PGPencrypted
messages, which do provide anonymous messaging.
Another difference between PEM and PGP is the efficacy of contingency
recovery procedures. If compromised, PEM allows immediate and
universal notification of a public key change. Such universal
notification is not possible with PGP, which permits issuance
of a revocation certificate, but has no way to provide this to
all holders of a users public key (Trowbridge, 1995). On
the other hand, refusal of PGP messages (due perhaps to a dropped
or nonASCII character) can pose a security risk because
it is possible to intercept and fake a refusal. In this case,
however, the address will be incorrect. To address this problem,
PGP software can be made to monitor incoming address consistency,
at an as yet undetermined reduction in implementation speed (Weeks,
Cain and Sanderson, 1995).
RIPEM presently has an advantage in being somewhat more user friendly
than PGP. One important issue is character set compatibility.
PEM as implemented in IPv6 will work with ASCII and nonASCII
characters. Previously available PGP software required ASCIIonly
characters, although this is likely to be corrected in the near
future. Another easeofuse issue is user name. In
PGP, users choose their own; with PEM, the address is for X.500
protocol, is assigned, and may not even be printable, much less
rememberable. Also, with PGP users have to run everything through
the program to get a digital signature, which is inconvenient
and slow; the ability to disable the program is therefore required
as an option which must often be used (Weeks, Cain and Sanderson,
1995).
As an alternative to PEM and PGP, a recent commercial secure EMail
product, TEDSecure (TriTeal Corp.), is user-friendly, GUI-oriented
encryption software compatible with Microsoft Mail, and intended
for the UNIX platforms used by many Government agencies. To facilitate
Government use, TEDSecure uses the same algorithms as the Fortezza
card - and costs about the same ($200) (O'Hara, 1995a). Transmission
of E-Mail secured by PEM/RIPEM will be possible in the ICN for
those wishing to use it for hierarchical E-Mail distribution.
[Recalling that it cannot be considered as secure as PGP because
it uses triple encryption, which as explained earlier, tends to
confer a security risk rather than an advantage (c.f. Kaliski
and Robshaw, 1996).]
Now suppose the user wants to send voice-mail? Zimmerman has just released PGPfone for Macintosh, which works with a SoundBlaster card and 14.4 modem (Ubois, 1995). Another such product, also compatible with a SoundBlaster card and modem, is made by Nautilus (ftp://miyako.dorm.duke.edu/mjp; retrieve text file README_MPJ). Like PGP, it is also exportrestricted. For secure teleconferencing, things get more complicated; secure audio teleconferencing methods have been developed, but not yet implemented (Ayanoglu, 1995).
An additional password encryption system will also be made available for the issuance of ICN user passwords.
The SELANE encryption method, which requires the use of a smart card, was developed at the University of Karlsruhe, Germany, as a European standard more or less the European equivalent of Fortezza technology, but pointedly devoid of potential "backdoors" or "[U.S.] Law Enforcement Access Features (LEAF)" (Beth, 1995). SELANE was developed to promote Internet-based electronic commerce in Europe, and is, by design, easy to overlay on top of Fortezza DSS technology to provide an added level of assurance (ibid., 1995). When SELANE smartcards are available in the U.S., we will make this password encryption development method available on the ICN web page password encryption choice GUI. The SELANE system uses an encryption "key" comprised of three, rather than the usual two, key parts: simply the x,y,z coordinates of a random point in space, where two of the key parts belong to the user and sender, and the third belongs to Secure Key Issuing Authority (SKIA), a certification authority which is also intended to be set up in Europe to supervise use of this method.
If the computer could flawlessly recognize and authenticate that the user was indeed the person at the keyboard, there might be no need for password or other authentication practices. Several types of pattern recognition-based metrics have been developed to provide this solution, using keystroke timing, signature diagnostics, voice recognition, and recognition of fingerprints, the iris of the eye, as well as recognition of facial bone structure and heat flux patterns. The simplest method uses only recognition of timing patterns in keystrokes made by a user, but error rates that occasionally deny valid users access have apparently prevented widespread acceptance of this method. A more sophisticated system, the Handwriter Dynamic Signature Verification Program (Communication Intelligence, Redwood Shores, CA), uses a small "Handwriter for Windows" pad, which the user signs (Anon., 1994a). The pattern recognition software maintains a dynamic database of an individual's signatures that allows for changes over time, but in combination with error possibilities, the additional hardware cost of the pad has apparently limited this method to specialty applications. User authentication by voice pattern recognition was found some years ago to be a difficult problem, and remains so. Even given the recently improved computer power and the new voice recognition and audio compression chips, vocal pattern recognition may be prone to unacceptable error rates, but new voice recognition security products using the improved technologies are appearing (c.f. Anon., 1995a).
Other pattern recognition-based access control/authentication
methods have been proposed that use digital video cameras or other
computer accessories. Such methods include pattern recognition
of fingerprints (using small pads or similarly customized smartcards)
(Dichristina and Kirschner, 1996), or patterns in the iris
of the eye, which are held to differ more among individuals than
fingerprints (Anon., 1994b).
However unlikely in reality, both iris and fingerprint scanning
methods are subject to hitech spoofing methods of the sort
used in Bgrade spy movies the fake contact
lens or fingerprint. For CALS-related applications, such threats
are of little risk, yet these access control methods nonetheless
seem unlikely, as does a DOE-funded access control system based
on the spatial recognition of the 3D shape of a user's entire
hand (DOE/ER-0654, 1995), which remains under development.
By contrast with the methods above, some high tech security solutions
appear to offer broad utility in the future. Much work has been
done to implement facial feature construction and recognition
software (c.f. Javidi, 1995; Mukherjee, 1995;
and, Psaltis and Mok, 1995). Facial recognition constitutes
a major effort in Japan as part of research at the national Electrotechnical
Laboratory (ETL) undertaken by Dr. Kazuyo Tanaka, using
facial models developed by Dr. Hiroshi Harashima (Myers, 1995).
Similar work has been undertaken at the MIT Media Lab by Alexander Pentland,
which has been tested for security applications (Schwartz, 1995).
These methods seem to work well to uniquely determine bone structural
components, independent of whether someone has just had a haircut
or a shave. However, error rates are still somewhat problematical.
Thus, rather than use this method for assuring the identity of
ordinary users, facial recognition has been tested by British
Telecom, the U.S. Army, and the White House as a means of recognizing
exceptional individuals, such as known terrorists and criminals
(e.g., in a crowd). For such uses, error rates are less
troublesome than for access control, but for wider utility the
facial pattern recognition software might be profitably incorporated
with other access control technologies in the future.
To overcome problems with pattern recognition of facial bone structure, while yet making use of the advanced software developed, more recent methods target infrared patterns of heat release from an individual's face. Facial heat flux patterns are held to be highly unique and relatively impossible to spoof, as they are determined by the fractal growth patterns of blood vessels, which differ greatly even between identical twins. Although the problem of errors in this method has not yet been sufficiently addressed, and a small digital video camera is required, the cost of these cameras is little more than most other access control security solutions. This method may, therefore, hold the greatest promise for future access control and authentication methodologies.
Over the lifecycle of the ICN, object-oriented database management and communication methods will become much more prevalent.