|
|
AMG Task - Define a Strategy for a Secure Network EnvironmentAppendix BStrategy for a Secure Network Environment, Including IntranetsReport and RecommendationsApril 16, 1997
Prepared byAMG - Secure Network Environment Working Group
Prepared by: AMG, Secure Network Environment Working Group
April 16, 1997
The Internet is a rapidly developing technology whereby information is delivered to the desktop via internet applications. Internet technology allows the user to browse documents, files, and databases on web servers located here at NIH, across the United States, or throughout the world. Many ICDs are developing an internal or private internet, called an "intranet". An intranet is defined as "an environment of network and computing tools based on those used in the global Internet that is isolated from or connected in a controlled way to the global network, and is generally not accessible from the Internet at large."
Proliferation of intranets across the NIH raises a concern for the security of information, integrity of data, and the protection of systems. The purpose of this Sub-committee is to define a strategy for a secure network environment, including intranets.
Key recommendations:
2. Establish a central authentication service. 3. Establish a central registry for web servers and other types of network servers. 4. Designate a group to develop a public key certificate policy for NIH and a means to coordinate public key certificate authorities, NOS security registries, and directory services. 5. Establish central intranet services at DCRT as part of the infrastructure. Minimum intranet security standards will apply to central Intranet as well as all ICD intranet services.
I. Overview
Today, network security at NIH is inadequate, at best. Responsibility for network services at the NIH is decentralized. The DCRT provides network services to the routers in each building and maintains the NIHnet, which provides connectivity to the Internet, computer facilities at DCRT, and other NIH systems. The individual ICDs provide the network services from the routers to the desktop. Network services have evolved with little NIH-wide planning, guidance, and oversight. Many network services have no security, and many are secured are done so in an ad-hoc, independent, and non-interoperable fashion.
This can be inconvenient for users, who are required to register for and know up to a dozen separate login IDs and passwords in order to access various systems: ICD and DCRT network services, e-mail, Grateful Med, IMPAC2, IMPACT, and so on. This encourages poor security practices such as choosing easy to remember, but weak, passwords, writing down passwords, using the same password on multiple accounts, never changing passwords, and sharing accounts with other users.
Network service providers at NIH must often establish, administer, and protect their own user registries, and operate the business process needed to handle requests to create, delete, and update accounts, reset forgotten passwords, and detect and respond to security incidents. With today's shortage of skilled computer personnel, such work is often done poorly, or not at all.
However, the explosive growth of the Internet and the World Wide Web has recently spawned the concept of an internal Internet, or Intranet, which is the structured use of Internet technologies to conduct the business of an enterprise such as NIH. It is an environment of network and computing tools based on those used in the global Internet that is isolated from or connected in a controlled way to the global network, and is generally not accessible from the Internet at large. Since the development and use of intranets at NIH is in its infancy, and since internets are based on open standards, we have an opportunity to greatly improve the interoperability and security of the NIH network environment by developing and implementing a suitable strategy.
To capitalize on this opportunity, the AMG Working Group on Defining a Secure Network Environment Strategy recommends:
* Building upon the work-in-progress described in Section II * Adopting the Intranet Security strategy presented in Section III
The result will be a network environment that alleviates the problems described above, and that is capable of providing the appropriate level of security needed by the wide range of applications and information services it must support, for example:
* Members of the general public will be able to retrieve non-sensitive information from NIH with the assurance that it actually came from NIH and not an impostor, and that it was not altered in transit.
* NIH's extramural business partners, such as grant applicants and scientific collaborators, will be permitted authorized access to sensitive databases and results, with privacy and without excessive inconvenience.
* NIH's most sensitive information, such as patient data, can be used by only those NIH researchers that "need to know", with minimal risk of disclosure, loss, or tampering.
II. Other Security Work in Progress
A joint committee of the AMG and Telecommunications Committee is developing an NIH Security Plan which will:
* Assign Responsibility for Security * Develop a system security plan based on risk assessment, which addresses General Support Systems (i.e. the NIH network backbone and ICD LANS), including Rules of Behavior and Technical Security. * Review system security controls * Identification of the authorization process whereby a manager is responsible for adequately protecting systems or applications
This NIH Security Plan, which complements the recommendations presented here, will be presented in draft to the Telecommunications Committee at their September 1997 meeting. AMG and other approvals will be obtained. A final approved NIH Security Plan is planned for December 1997.
Another AMG working group is identifying a strategy for an NIH-wide directory service. This work must be coordinated with the intranet security strategy as described in Sections III-5 through III-9.
III. Intranet Security Strategy
The committee recommends the following strategy: 1. Develop an NIH web policy addressing purpose, appropriate use, and security standards. 2. Implement the NIH Security Plan, due December 1997. 3. Continue ongoing NIH education on computer security awareness and standards (OIRM). 4. Review and assess general support systems security on a recurring basis (ICD/OIRM). 5. Implement intranet security using a combination of public key security standards (see Appendix A), native NOS security mechanisms, and firewalls (see Appendix B). * To secure the information stored in NIH files and databases, all methods of accessing this information via network communications must be secured. In NIH's heterogeneous, multi-purpose computing environment, this requires the coordinated use of several security technologies. Public key security based on standards such as SSL and X.509 is particularly well-suited to provide mutual authentication, digital signatures, and privacy for Web applications. The native security mechanisms of Network Operating Systems (NOSs), particularly those based on shared-secret key standards such as Kerberos, are a proven means to secure non-Web based applications and Web server network access to file and database servers. Firewalls block network access via methods not protected by public key or native NOS security. 6. Establish a central authentication service. * Investigate and implement a central authentication service using public key and/or shared-secret key security standards. The central authentication service will provide electronic credentials for every NIH employee (contractor, IRDAs, etc.) to use NIH computing resources. These credentials will uniquely and reliably identify NIH employees and provide a convenient, consistent, and secure means for the ICDs that provide intranet services to control exactly who may access servers, files, databases, and so forth. The authentication service should be easy to use and reduce the administrative burden of ICD service providers, yet ensure a minimum level of security for the NIH network environment. 7. Establish a central registry for web and other types of network servers. Registration will include submission of a security plan approved by an ISSO and a plan for monitoring and auditing security. * Web servers, file servers, and database servers also require credentials, so that the users of these services can trust them and ensure data privacy and integrity. 8. Designate a group to develop a public key certificate policy for NIH and a means to coordinate public key certificate authorities, NOS security registries, and directory services. * In order to achieve strong security, certificates and/or credentials must be issued and maintained strictly according to an NIH certificate policy. The NIH certificate policy should keep in mind the future development of a Federal Government-wide Public Key Infrastructure (PKI) and interoperability with external PKIs for possible cross-certification. * The credentials issued by the central NIH authentication service will carry a unique personal identifier assigned to each NIH employee. To enable these credentials to grant access to computing services, the unique personal identifiers will need to be associated with and used consistently across various subsidiary certificate authorities, NOS security registries, and directory services. * Servers and applications must be able to access certificates through the use of AMG-approved standards including X.500 and LDAP. 9. Establish central intranet services at DCRT as part of the infrastructure. Minimum intranet security standards will apply to central Intranet as well as all ICD intranet services. * Secure central intranet services will enable those ICDs who do not wish to maintain an intranet environment that meets minimum NIH standards to develop secure intranet applications to distribute ICD-specific information to their staff. 10. NIH ISSO may allow exceptions to published NIH intranet security standards upon acceptable justification.
Keith Gorlen (DCRT) Jaren Doherty (OD/OIRM) Daniel Sands (NCI) Ralph Van Wey (NHLBI) Wes Russell (NLM) Pamela Rabbit (NLM)
Charles Tate (NIEHS)
Web Security
There are a number of challenges to providing an intranet which fosters collaboration and information sharing within a defined group. Desirable characteristics include:
* Secure access and privacy of data * Data integrity and freedom from corruption or tampering * Cross platform client support * Cross platform server support * Multi-vendor software and hardware support * Open standards-based * Scaleable * Support single login to greatest degree possible * User transparency and ease of use * Support remote access conveniently * Reasonable access control administration
The use of cryptography in the form of the secure sockets layer (SSL) protocol and the public-key digital certificate is one method to address these challenges. It is a standardized mechanism that provides privacy, authentication, integrity, and controlled access to an institution's intranet resources.
Basically, the protocol allows the browser and server in a web session to authenticate one another and secure information which subsequently flows between them. Through the use of cryptographic encryption and digital signature, these techniques:
* Allow Web browsers and servers to authenticate each other * Permit Web site owners to control access to particular servers, directories, files or services * Allow sensitive information to be shared between browser and server, yet remain inaccessible to third parties * Ensure that data exchanged between browser and server cannot be corrupted without detection.
A key component in the establishment of secure Web sessions via SSL protocol is the public key certificate. Public key-based techniques were invented by Whitfield Diffie and Martin Hellman of Stanford University. Under the Diffie-Hellman public key system, each user is assigned two unique digital keys: a public key and a private key. The public key is published, while the private key is kept secret, accessible only to the owner.
Encryption is the conversion of a message into an unreadable form. Decryption is the reverse: an encrypted message is made readable. The keys control both encryption and decryption. If either key - public or private - encrypts a message or file, only the other key can decrypt it. If someone encrypts a message or file with an individuals public key, only that individuals private key can decrypt this message. This assures message privacy.
Two additional components of information security are integrity and authenticity. How can a recipient know that the message has not been tampered with or changed and is actually from the purported party? If we communicate electronically with those we do not know, we must have a way to address these concerns. Digital signatures provide this.
A digital signature is a portion of a message encrypted with a user's private key. Anyone who knows this user's public key could now decrypt this digital signature and the message it signs. By doing so, the recipient would know that this message and its digital signature could have come only from the owner of the private key corresponding to the public key used to decrypt. Only the corresponding private key could have originally encrypted the message. Digital signatures not only ensure that the received message is exactly the one sent, but also verify that the alleged sender actually sent it.
In a public key system, the private key is never transferred or distributed. Consequently, the risk of an outsider obtaining this critical item is very small. However, we still need to know, without doubt, that the owner of a public key is who he claims to be. This involves the intervention of a disinterested, trusted third party that binds a public key to an individual or entity that it has positively identified. This binding mechanism is know as a digital certificate. A digital certificate can be considered analogous to a passport, in that it proves your identity. Similarly, a digital certificate is a non-forgeable, tamper-proof electronic document that attests to the binding of an individual's identity with his or her public key.
The digital certificate is authorized by a trusted third party known as a Certification Authority (CA). In the passport analogy, the CA is similar to the Passport Office, which verifies your identification, creates a recognized and trusted document which certifies who you are, and issues the document to you. A Certification Authority is a trusted authority responsible for issuing certificates used to identify a community of individuals, systems or other entities which make use of a computer network. By digitally signing the certificates it issues, the CA binds the identity of the certificate owner to the public key within the certificate, and thereby vouches for the trustworthiness of the certificate. The CA plays a crucial role in Web security, since the CA makes a third-party trust relationship possible. Two parties with certificates issued and signed by different Certificate Authorities will be able to mutually authenticate each other by relying on the signature of a trusted third party: A trusts B, A trusts C, so B trusts C.
One advantage to this approach is the wide vendor and government development effort associated with it. Even in it's early stages there are a number of existing vendor Certificate Authorities and plans to create accessible public authorities (U.S. Postal Service and others). This offers certain advantages in the form of development of third-parties trust relationships.
Digital signatures, like handwritten signature, can be used as proof of agreement with or ownership of the contents of a document. The identifying information in the certificate can be trusted because the digital signature is cryptographically strong. The signature contained in a digital certificate meets the following criteria:
* It must be unforgeable. The signature proves that the signer deliberately signed the document. * It must be authentic. The signature convinces the document's recipient that the signer deliberately signed the document. * It must not be reusable. The signature is part of the document, and an unscrupulous person cannot move the signature to a different document. * It must make the signed document unalterable. In the case of digital signatures, after a document is signed, it cannot be altered without detection. * It cannot be repudiated. The signature and the document, although intangible, are physical entities. The signer cannot claim later that he or she did not sign it.
Today, several web server and browser packages are "certificate-aware", meaning that they are capable of interpreting and using certificates and SSL. Examples include Netscape's Navigator and Enterprise Server; Microsoft's Internet Explorer and IIS; and IBM's Internet Connection Server. In the future, all browser and servers will likely require certificate-awareness to ensure Web session security. This highlights a final advantage to this approach: To be truly effective, our intranet security solutions must be integrated into the existing X.509 information security frame and be aggressively supported by vendors, both with usable products now and active development for the future.
Daniel Sands NCI Appendix B
Firewalls and an NIH Intranet
What is a firewall?
A firewall is a system or group of systems that enforces an access control policy between two networks, usually an internal network and the Internet. The actual means by which this is accomplished varies widely, but in general, a firewall examines every network packet going between the two networks and then either passes it or blocks it based on a preprogrammed set of rules. Some firewalls place a greater emphasis on blocking traffic, while others emphasize permitting traffic. A firewall can provide a high level of granularity with regard to security and auditing. Firewalls are required when, for whatever reason, the level of server security is inadequate--they provide a second line of defense to augment the security controls of the server. The relationship between the need for a firewall and the level of server security is an inverse one--as the security level of the server decreases, the need for a firewall increases, and vice versa. Probably the most important thing to recognize about a firewall is that it implements an access control policy--you must have such a policy before you can implement a firewall, and it must be a part of a consistent overall organizational security architecture.
What can a firewall protect against?
Generally, firewalls are configured to protect against unauthorized interactive logins from the "outside" world in order to prevent vandals from logging into machines on your network. More elaborate firewalls block traffic from the outside to the inside based on specified access rules, but permit users on the inside to communicate (more or less) freely with the outside. Access rules can be set up to block or permit any service, e.g., http, telnet, ftp, rlogin, or block traffic from any specified location. Firewalls are also important since they can provide a single "choke point" where security and auditing can be imposed. In addition to security measures, firewalls can provide summaries to the administrator about what kinds and amount of traffic passed through it, how many attempts there were to break into it, etc.
What can't a firewall protect against?
Firewalls can't protect against attacks that don't go through the firewall. If there are backdoor access points to the network or intranet, the firewall protection can be subverted. A firewall can't protect you against authorized users attempting to perform unauthorized actions inside your network. A firewall provides protection against outside attacks for the network and/or server--data protection and user authorization are usually handled not by the firewall but by the Web server software.
Firewalls and Intranets:
A firewall provides an additional security barrier between an intranet and the Internet. Without a firewall, an intranet server would be directly connected to the Internet and have only the security features of that server to protect it. This "single line of defense" strategy is generally viewed as inadequate for a secure intranet, since all servers and Web software have security holes, both known and yet to be discovered, that hackers may be able to exploit.
Recommendation:
It is absolutely necessary that the system on which an NIH intranet is implemented have the capabilities of a firewall, e.g.:
* the ability to block or permit specific TCP/IP and Web services * the ability to block or permit all traffic from specific Internet addresses * the ability to notify an administrator when an attack is in progress * the ability to support advanced authentication methods such as smart cards
Whether or not a separate firewall system is necessary to achieve these requirements depends on the platform on which an NIH Intranet is implemented. If it is implemented on a standard UNIX or NT system, a separate firewall would be necessary to insure an adequate level of security. If it was decided to use a central facility such as the MVS SILK or an ALW DCE implementation, a separate firewall would not be necessary since the standard high level of host security on those systems would be adequate.
Kevin Haney March 18, 1997
Report on Interoperability at the NIH |