The UIA Team will employ numerous existing safeguards to protect both the physical
and logical security of its systems and the data stored on them. While a
high-level discussion of those safeguards is appropriate for this
proposal, specific details are not. The two guiding principles behind the
UIA Team security posture are:
- The more widely a precaution is disclosed, the less useful it is,
and
- A sufficiently committed and resourced individual can circumvent any
precaution.
The UIA Team is, however, prepared to disclose additional details to
ICANN or its agents in a separate forum and under assurances of
confidentiality. Security policies have been developed within the
following general outline:
- Do everything humanly possible. This includes staying abreast of the
latest exploits and the latest technology, as well as implementing all
known state-of-the-practice safeguards.
- Develop contingency plans for events that are out of your control.
- Monitor frequently. Just as in the medical field, the key to the
cure is early detection.
Figure C17.9-1 identifies general areas of concern with regard to
system risks as well as the precautions that the UIA Team will take to
protect the .org registry systems. Interestingly, non-malicious or
accidental incidents present as high risk and are in reality more
prevalent than malicious incidents.
Figure 17.9-1: Security Risks and Precautions
Physical Security
Physical security includes a 7x24 onsite security force and card
readers protecting access to all owned and operated data center
facilities. This discipline is also required for all collocation partner
facilities. Additionally, biometric access controls are employed at data
center facilities. As important as physical security is, however, it pales
in comparison to logical or I/T security risks. In reality, there is no
way to provide 100% protection to a facility. Therefore, although
state-of-the-practice physical security technologies and procedures are
employed, there must be a recognition that physical security for systems
can only be accomplished by reducing or eliminating the dependence on
individual physical facilities. For this reason, the proposed .org
registry systems have been designed and built such that transaction load
is balanced between multiple facilities and functions can be transferred
from one facility to another.
Background Checks
Two levels of background checks on contractors, consultants, and
prospective employee candidates are performed for each member of the
technical staff. The first level is called a Basic Background
Investigation Status (BBIS). Employees will be required to re-qualify for the
BBIS every three years as a condition of employment. Non-employees (e.g.,
contractors and consultants) will be required to re-qualify every three years
in order to be granted badge access to data center facilities. The BBIS
checks for items such as:
- Convictions for violent crimes
- Convictions for crimes involving financial malfeasance
- Convictions for crimes involving controlled substances or illegal
drugs
- Behavioral patterns indicating personal irresponsibility (e.g.,
multiple Driving Under the Influence convictions)
- Embellishing or falsifying a job application
In addition to the BBIS, personnel requiring access to data center
facilities will be required to qualify for an Extended Background
Investigation Status (EBIS). The EBIS includes all elements of the BBIS,
with the addition of a credit check.
Dedicated I/T Security Staff
A dedicated I/T security staff will perform a number of functions in
support of the I/T security posture, including:
- Development of I/T security standards
- Implementation and management of network security devices (e.g.,
firewalls, ACLs, etc.)
- Working with upstream provider's security staff in order to deal
with DOS and DDOS issues
- Working with government and industry entities responsible for
critical infrastructure assurance, such as the National Communications
Center (NCC) and the FBI's National Infrastructure Protection Center (NIPC)
- Participation in government and industry cooperative forums, such as
the NSTAC, the Carnegie Mellon CERT CC, ICANN DNSSAC, the National
Security Council's ISP DNS and BGP Security Working Group, and the IT/ISAC
Hardened System/Network Architectures and Configurations
A number of architectural elements and configuration standards to
provide the maximum protection possible against system intrusions are
currently used and will continue to be used. All hardware and operating
system images go through a rigorous security audit and lockdown prior to
being approved for deployment into production. Nameservers are a good
example of this. Only those elements of the operating system necessary to
perform the nameserver function are deployed. Additionally, certain
functions of BIND that are not necessary to the function of the nameserver
constellation have been stripped out. One reason for this was made very
apparent in 2001 when a root level exploit was identified in the version
of BIND being run by all Internet root server operators. Upon detailed
investigation, it was discovered that the modified version of BIND running
on the current .org nameservers had disabled that portion of the code
susceptible to the exploit. All other root operators implemented a new
version of BIND within 48 hours of receiving the patch, a dangerous
practice to be sure, but there was little choice. Root operators were
forced to choose between a known exploit and deploying an untested version
of BIND. But because the .org servers were not susceptible to the exploit,
it was possible to take a more disciplined approach, extensively testing
the new version of BIND for several weeks, locking down or disabling those
portions not needed and then deploying it in a methodical fashion.
The UIA Team proposes that the three levels of security procedures for
accessing the .org registry currently employed continue. First, all IP
traffic will be filtered, with only traffic from predetermined authorized
registrar subnets being permitted through the routers. Second, a
successful SSL handshake with valid PKI certificates will be required in order
to establish a connection to the .org registry. Finally, after passing
both of those levels, each registrar must enter a valid userid and
password in order to gain access to the .org registry. Security internal
to the .org database prevents one registrar from accessing another's data.
As an added layer of protection, QoS devices are currently and will
continue to be used in order to prevent a few registrars from consuming
all registry resources.
Globally deployed nameservers are managed via a secure VPN connection.
These connections will be encrypted via IPSec and allow only connections from
authorized machines and users. The VPNs will be configured in a high
availability mode.
Detailed Physical and Logical Monitoring
Data center facilities will be monitored 7x24 via surveillance cameras.
These cameras are located both outside and inside the facility. At the
primary data center facility in Lakeside II, each row of equipment
cabinets has a security camera. Additionally, all card access and
biometric access is monitored and logged.
The Registry Command Center (RCC) monitors all aspects of the .org
registry database and global DNS, including system health, system
performance, system load, and attempted system intrusions. Attributes of
the .org database are monitored in 60-second increments. Attributes of the
global constellation of nameservers are monitored in 4-second increments.
Frequent Audits and Tests
Periodic audits of its systems and networks, including third-party
intrusion testing, will be performed. Penetration tests will be performed by an
outside company and include numerous tests for exploits, versions and
patch levels. Various groups such as KPMG regularly perform SAS 70 and BS
7799 audits.
System Survivability and Disaster Recovery Plans
A complete business continuity and disaster recovery strategy have been
developed. Key elements of this strategy include:
- Multiple load-balanced servers and/or hot spare servers to protect
against system hardware failures
- A secondary site (with RRP transactions load-balanced between sites)
to protect against a site failure
- The ability to transfer operations (especially DNS operations)
between global sites
Business continuity and disaster recovery plans are not just for system
failures and natural disasters. They are also designed to be implemented
in the event that a system or site suffers a security compromise.
Cautious Selection of Strategic Vendors and Suppliers
One of the most important elements of any critical infrastructure
operation is the selection of, and ongoing relationship with, vendors and
suppliers. Critical vendors and suppliers provide dedicated onsite
support. These technical representatives will be located at corporate
facilities, work solely with corporate I/T staff and do not split their
time with other companies. They will be onsite during business hours, onsite
along with corporate I/T staff during major deployments, and on-call 7x24,
ensuring a direct line to vendor engineering and operational resources.
Additionally, these critical vendors will advise of potential bugs or exploits
before public announcements are made. Because of the intense processing
performed by the current .org registry database and DNS constellation
(e.g., transaction volumes and speeds), several problems with vendor
products (that had not been previously discovered during the course of
normal vendor product development and testing) have been discovered and
addressed prior to their deployment in the current .org registry.
Strict Policies on Information Release
Strict policies will be maintained regarding the release and disclosure of
information that could generate a security risk. Direct relationships with
the National Communications Center, National Security Council, and
National Infrastructure Protection Center ensure that the UIA Team is now
and will always be "in the know" regarding the latest security
threats.