U.S. Department of the Interior

Interior Enterprise Architecture

Chapter 1

Information Security Architecture

Version 2.0

![](media/image1.jpeg){width="2.6034722222222224in"
height="2.6034722222222224in"}

####### **October 15, 2003**

# 

# Chapter 1. Information Security Architecture

[1.1 Introduction and Background 3](#introduction-and-background)

[1.2 Architectural Principles 5](#architectural-principles)

[Principle 1: Information is an Interior Asset
5](#principle-1-information-is-an-interior-asset)

[Principle 2: Data and Information Stewardship
6](#principle-2-data-and-information-stewardship)

[Principle 3: Integration/ Interoperability
6](#principle-3-integration-interoperability)

[Principle 4: Reuse before you buy and buy before you build
7](#principle-4-reuse-before-you-buy-and-buy-before-you-build)

[Principle 5: Ensure Security, Confidentiality and Privacy
7](#principle-5-ensure-security-confidentiality-and-privacy)

[Principle 6: Continuity of Operations Planning
8](#principle-6-continuity-of-operations-planning)

[Principle 7: Enterprise Network as a secure "Virtual" Network
9](#principle-7-enterprise-network-as-a-secure-virtual-network)

[Principle 8: Information Access 10](#principle-8-information-access)

[Principle 9: Total Cost of Ownership
10](#principle-9-total-cost-of-ownership)

[Principle 10: Product Standards 11](#principle-10-product-standards)

[Principle 11: Personnel security 11](#principle-11-personnel-security)

[Principle 12: Computer Security Incident Response Capability (CSIRC)
12](#principle-12-computer-security-incident-response-capability-csirc)

[Principle 13: Individual Security Responsibility
12](#principle-13-individual-security-responsibility)

[1.3 Technology Components 13](#technology-components)

[1.3.1 Virtual Private Network (VPN) 14](#virtual-private-network-vpn)

[1.3.2 Legislative / Compliance 14](#legislative-compliance)

[1.3.3 Authentication/Single Sign-on 14](#authenticationsingle-sign-on)

[1.3.4 Test Management 15](#test-management)

[1.3.5 Network Devices / Standards 15](#network-devices-standards)

[1.3.6 Utilities 15](#utilities)

[1.3.7 Certificates/Digital Signatures
18](#certificatesdigital-signatures)

[1.3.8 Supporting Security Services 18](#supporting-security-services)

[1.4 Select Best Practices 19](#select-best-practices)

[1.5 Contributors 21](#contributors)

## Introduction and Background

The Department of the Interior is developing closer electronic
partnerships with businesses, other government agencies, employees, and
citizens in general. These various partnerships require varying levels
of security. Regardless of the partnership, the purpose of security
remains the same for all: to protect Interior's information assets and
provide an environment in which Interior's business can be safely
transacted.

In the past, training and resources for security within Interior have
tended to be meager. With the use of shared personnel, part time
resources and the like, maintaining an adequate level of security has
often been difficult. Additionally, the authority to insure compliance
to security policies has not resided within the security area itself
except in times of declared emergencies. A good security practice is to
address compliance issues well in advance of any real emergency.

The focus of the Interior Enterprise Architecture is on providing
guidance for information technology (IT) issues and initiatives that are
Interior-wide or multi-bureau in scope. The following Security
architecture facilitates appropriate and innovative access to
information while ensuring its confidentiality, integrity, availability,
accountability and non-repudiation (CIAACNR). It supports business
processes as well as compliance with all government regulations and
standards related to information security. It also supports the
generally accepted principles and practices of IT security.

If used correctly, the Interior Enterprise Architecture will act as a
catalyst for those looking to capitalize on its contents and better
understand the full meaning of its guidance. This understanding will
permit IT personnel to better engage the non-IT organization in
discussions around tradeoffs and priorities within the proper governance
structure (e.g., Management Initiatives Team (MIT), Information
Technology Management Council (ITMC)). The Interior Enterprise
Architecture is not intended to be the "last word" (e.g., some automated
checklist for product selection). It is intended to be one of the "first
words" to assure that Interior's mission priorities and its IT
priorities remain closely aligned.

Because Interior is incorporating the OMB's Federal Enterprise
Architecture (FEA) models, the technical guidance provided by the
subject area experts within a domain spans both the Service Component
Reference Model (SRM) as well as the Technical Reference Model (TRM).
For the Security domain, the SRM elements are as follows:

**Service Domain(s):** The Support Services Domain defines the set of
cross-functional capabilities that can be leveraged independent of
Service Domain objective and / or mission.

> The Business Management Services Domain defines the set of
> capabilities that support the management of business functions and
> organizational activities that maintain continuity across the business
> and value chain participants. The Business Management Services domain
> represents those capabilities and services that are necessary for
> projects, programs and planning within a business operation to
> successfully be managed.

**Service Type(s):** Security Management -- defines the set of
capabilities that support the protection of an organization\'s
hardware/software and related assets.

Management of Process - defines the set of capabilities that regulate
the activities surrounding the business cycle of an organization.

**Component(s):** Access Control -- defines the set of capabilities that
support the management of permissions for logging onto a computer or
network.

> Identification and Authentication -- defines the set of capabilities
> that support obtaining information about those parties attempting to
> log on to a system or application for security purposes and the
> validation of those users.
>
> Verification -- defines the set of capabilities that support the
> confirmation of authority to enter a computer system, application or
> network.
>
> Role / Privilege Management - defines the set of capabilities that
> support the granting of abilities to users or groups of users of a
> computer, application or network.
>
> Intrusion Detection -- defines the set of capabilities that support
> the detection of illegal entrance into a computer system.
>
> Audit Trail Capture and Analysis -- defines the set of capabilities
> that support the identification and monitoring of activities within an
> application or system.
>
> Encryption -- defines the set of capabilities that support the
> encoding of data for security purposes.
>
> Digital Signature -- defines the set of capabilities that guarantee
> the unaltered state of a file.
>
> Risk Management -- defines the set of capabilities that support the
> identification and probabilities or chances of hazards as they relate
> to a task, decision or long-term goal.

These SRM service elements are likewise supported by Interior's IT
(technical) infrastructure (e.g., servers, networks). Within this
infrastructure are individual TRM components for which this domain team
is providing guidance. The graphic below outlines those TRM elements for
this domain that support the service needs of the SRM.

![](media/image2.wmf){width="6.283333333333333in"
height="3.167361111111111in"}

Although only 9 SRM Service Components and 8 TRM Standards are
explicitly indicated above, it is understood that security is and
integral part of all aspects within the SRM and subsequently the TRM.

Additionally, it's doubtful that a single domain chapter from the TRM
can be used to address a substantive issue. More realistically, a few
architecture domains may need to be reviewed when addressing an
important IT decision. For example, if Interior was considering the
creation of a new Interior-wide Web application that could be used both
by the general public and Interior personnel, then the TRM chapters like
Data Management Technologies, Information Security, Distributed Systems
Management and Application Development might all need to be reviewed.

## 1.2 Architectural Principles

The principles listed below provide guidance for the design and
selection of technology components that will support the security needs
of Interior-wide IT initiatives.

+----------+-----------------------------------------------------------+
| #        |                                                           |
| ## Princ |                                                           |
| iple 1:  |                                                           |
| Informat |                                                           |
| ion is a |                                                           |
| n Interi |                                                           |
| or Asset |                                                           |
+----------+-----------------------------------------------------------+
|          | Information is valued as an Interior asset and must be    |
|          | protected.                                                |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   Unprotected assets lose their value**.**              |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1.  Policies supporting security, privacy,                |
|          |     confidentiality, information sharing, information     |
|          |     integrity must be developed and implemented.          |
|          |                                                           |
|          | 2.  Need to promote secure interoperable information      |
|          |     management that facilitates information availability  |
|          |     for decision-making.                                  |
|          |                                                           |
|          | 3.  Metadata will need to include a security              |
|          |     classification or identification                      |
|          |                                                           |
|          | 4.  Data access will be limited to those who "need to     |
|          |     know".                                                |
|          |                                                           |
|          | 5.  Procedures for regular estimation of the value of the |
|          |     information assets need to be defined and practiced.  |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| #        |                                                           |
| ## Princ |                                                           |
| iple 2:  |                                                           |
| Data and |                                                           |
|  Informa |                                                           |
| tion Ste |                                                           |
| wardship |                                                           |
+----------+-----------------------------------------------------------+
|          | Protection of the data and information must be managed    |
|          | and maintained as a stewardship responsibility to support |
|          | the mission of the department.                            |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   Data needs stewards who are responsible for its       |
|          |     valuation, preservation, integrity, security, access  |
|          |     and utilization across Interior and with the public.  |
|          |                                                           |
|          | -   Data stewards will promote common business rules,     |
|          |     which will facilitate information sharing and improve |
|          |     data integrity.                                       |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1.  Recognition that business area personnel need to be   |
|          |     responsible for stewardship of the data and the       |
|          |     commitment of the resources necessary to provide an   |
|          |     adequate level of protection.                         |
|          |                                                           |
|          | 2.  There must be support for adhering to federal laws,   |
|          |     executive direction, guidelines and the generally     |
|          |     accepted principles and practices of IT security.     |
|          |                                                           |
|          | 3.  Stewardship includes responsibility for managing      |
|          |     data's consistency, timeliness, accuracy              |
|          |     completeness, and the necessary security training and |
|          |     awareness.                                            |
|          |                                                           |
|          | 4.  The scope of stewardship must be very sensitive to    |
|          |     the sources and uses of the information, ensuring     |
|          |     that confidentiality and privacy are protected (e.g., |
|          |     manage & accept risk and accreditation).              |
|          |                                                           |
|          | 5.  Metadata will need to include a security              |
|          |     classification or identification.                     |
|          |                                                           |
|          | 6.  Criteria used for classifying information/data needs  |
|          |     to be flexible to accommodate changes in the threat   |
|          |     environment (e.g., Homeland security).                |
|          |                                                           |
|          | 7.  A clear process to assign and document stewardship    |
|          |     responsibility on a application/system basis needs to |
|          |     be established and published.                         |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| ### Pr   |                                                           |
| inciple  |                                                           |
| 3: Integ |                                                           |
| ration/  |                                                           |
| Interope |                                                           |
| rability |                                                           |
+----------+-----------------------------------------------------------+
|          | Security systems must be designed, acquired, developed,   |
|          | or enhanced so that data and processes can be effectively |
|          | shared, for appropriate purposes, across Interior and     |
|          | with our partners.                                        |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   Increased efficiency will better serve our customers  |
|          |     (e.g., the public, employees).                        |
|          |                                                           |
|          | -   Duplicate systems cause higher support costs.         |
|          |                                                           |
|          | -   Increases access to information.                      |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1.  Every systems analyst needs to consider enterprise    |
|          |     wide security impacts when designing enhancing,       |
|          |     acquiring or extending the scope or use of            |
|          |     applications.                                         |
|          |                                                           |
|          | 2.  Will need common security standards & consistent      |
|          |     processes across Interior.                            |
|          |                                                           |
|          | 3.  Increased integration/ interoperability will increase |
|          |     risk & security complexity.                           |
|          |                                                           |
|          | 4.  When integrating systems, the highest security level  |
|          |     of the source systems should be used.                 |
|          |                                                           |
|          | 5.  System security design will migrate to more widely    |
|          |     used standards.                                       |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| ### Pr   |                                                           |
| inciple  |                                                           |
| 4: Reuse |                                                           |
|  before  |                                                           |
| you buy  |                                                           |
| and buy  |                                                           |
| before y |                                                           |
| ou build |                                                           |
+----------+-----------------------------------------------------------+
|          | In considering system security requirements (e.g., new    |
|          | functionality), we should look to reuse existing          |
|          | components before we buy. If no components exist,         |
|          | purchased solutions (e.g., COTS or GOTS) should be        |
|          | explored before we build.                                 |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   Complies with Office of Management and Budget (OMB)   |
|          |     Circular A-130 "Management of Federal Information     |
|          |     Resources", the Privacy Act of 1974, and the Federal  |
|          |     Information Security Act (FISMA) of 2003.             |
|          |                                                           |
|          | -   The more you're "like" everyone else (e.g., same      |
|          |     standard, same systems), the easier it is to share    |
|          |     with others.                                          |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1.  Need to identify and maintain "reusable" components.  |
|          |                                                           |
|          | 2.  Good system security specifications will be needed    |
|          |     early in the planning cycle to evaluate alternatives. |
|          |                                                           |
|          | 3.  Business processes may need to be \"changed\" but not |
|          |     compromised to ensure compliance with Interior and    |
|          |     Federal security standards, to accommodate reuse or   |
|          |     purchased solutions.                                  |
|          |                                                           |
|          | 4.  In-depth knowledge of security functions may be       |
|          |     outside of the organization, potentially increasing   |
|          |     issues of risk and cost.                              |
|          |                                                           |
|          | 5.  System security design will migrate to more widely    |
|          |     used standards.                                       |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| ### P    |                                                           |
| rinciple |                                                           |
|  5: Ensu |                                                           |
| re Secur |                                                           |
| ity, Con |                                                           |
| fidentia |                                                           |
| lity and |                                                           |
|  Privacy |                                                           |
+----------+-----------------------------------------------------------+
|          | IT systems should be designed and implemented in          |
|          | accordance with security and privacy legislation and      |
|          | policies to assure information confidentiality, integrity |
|          | and availability.                                         |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   Helps safeguard confidential and proprietary          |
|          |     information.                                          |
|          |                                                           |
|          | -   Enhances public trust.                                |
|          |                                                           |
|          | -   Complies with the Federal Information Security        |
|          |     Management Act (FISMA).                               |
|          |                                                           |
|          | -   Enhances the proper stewardship over information.     |
|          |                                                           |
|          | -   Enhances the confidentiality, integrity and           |
|          |     availability of the information.                      |
|          |                                                           |
|          | -   Complies with the Computer Security Act, the Privacy  |
|          |     Act of 1974, and OMB Circular A-130 "Management of    |
|          |     Federal Information Resources" and the generally      |
|          |     accepted principles and practices of IT security.     |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1.  Need to identify, publish and keep the applicable     |
|          |     policies, procedures and attendant interpretations    |
|          |     thereof.                                              |
|          |                                                           |
|          | 2.  Need for education on issues of privacy, security,    |
|          |     and confidentiality to become routine part of normal  |
|          |     business processes.                                   |
|          |                                                           |
|          | 3.  Need to make the security, confidentiality and        |
|          |     privacy requirements clear to designers, developers,  |
|          |     users, system owners and operations personnel.        |
|          |                                                           |
|          | 4.  Security has to be integral part of systems life      |
|          |     cycle management (e.g., "baked in, not painted on").  |
|          |                                                           |
|          | 5.  System security certification and accreditation must  |
|          |     be done prior to placing the system into operation    |
|          |     and re-certified/ re-accredited periodically.         |
|          |                                                           |
|          | 6.  Security must be included in the IT planning and      |
|          |     budgeting processes.                                  |
|          |                                                           |
|          | 7.  Accountability, enforcement, and compliance           |
|          |     mechanisms need to be created/ expanded (e.g.,        |
|          |     after-the-fact audits cannot replace good security    |
|          |     based mechanisms).                                    |
|          |                                                           |
|          | 8.  Criteria used for classifying information/data needs  |
|          |     to be flexible to accommodate changes in the threat   |
|          |     environment (e.g., Homeland security).                |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| ##       |                                                           |
| # Princi |                                                           |
| ple 6: C |                                                           |
| ontinuit |                                                           |
| y of Ope |                                                           |
| rations  |                                                           |
| Planning |                                                           |
+----------+-----------------------------------------------------------+
|          | Appropriate disaster recovery and business continuity     |
|          | planning, design, testing and maintenance must take       |
|          | place. System Contingency plans are an integral part of   |
|          | these planning activities.                                |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   Required by federal laws and regulations              |
|          |                                                           |
|          | -   Customers and partners have heightened awareness of   |
|          |     the need for systems availability.                    |
|          |                                                           |
|          | -   Any significant visible loss of system availability   |
|          |     and stability could negatively impact our mission and |
|          |     legal responsibilities.                               |
|          |                                                           |
|          | -   Application systems and data are valuable             |
|          |     organization assets that must be protected.           |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1.  Operation and systems plans will need to be           |
|          |     categorized according to business recovery needs      |
|          |     (e.g., short term essential and long term essential). |
|          |                                                           |
|          | 2.  Alternate information processing capabilities need to |
|          |     be in place.                                          |
|          |                                                           |
|          | 3.  Systems should be designed with appropriate level of  |
|          |     fault tolerance and recovery in mind.                 |
|          |                                                           |
|          | 4.  Plans for work site recovery will need to be in place |
|          |     (e.g., office space).                                 |
|          |                                                           |
|          | 5.  Life cycle and other costs may increase.              |
|          |                                                           |
|          | 6.  Disaster Recovery Plans (DRPs) and Business Recovery  |
|          |     Plans (BRPs) will require periodic testing and        |
|          |     revision.                                             |
|          |                                                           |
|          | 7.  Plans for records recovery and alternate data capture |
|          |     mechanisms/processes need to be in place.             |
|          |                                                           |
|          | 8.  Business impact analysis needs to be conducted in the |
|          |     first phase of life cycle process (e.g., an           |
|          |     assessment of business continuation and recovery      |
|          |     requirements will be mandatory when acquiring,        |
|          |     developing, enhancing or outsourcing systems).        |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| #        |                                                           |
| ## Princ |                                                           |
| iple 7:  |                                                           |
| Enterpri |                                                           |
| se Netwo |                                                           |
| rk as a  |                                                           |
| secure " |                                                           |
| Virtual" |                                                           |
|  Network |                                                           |
+----------+-----------------------------------------------------------+
|          | We must implement an Interior-wide "interoperable         |
|          | network" performing as if it were a virtual network.      |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   External pressures for developing a secure and        |
|          |     interoperable network                                 |
|          |                                                           |
|          | -   Knowledge workers have an increasing need for secure  |
|          |     transmission and access.                              |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1.  Need to identify the perimeter of the network.        |
|          |                                                           |
|          | 2.  Requires effective and coordinated perimeter          |
|          |     security.                                             |
|          |                                                           |
|          | 3.  Requires elimination of all "back-door" access to     |
|          |     networks                                              |
|          |                                                           |
|          | 4.  Requires secure, remote access gateways, both in and  |
|          |     out                                                   |
|          |                                                           |
|          | 5.  Intra-bureau networks will have to develop "trust     |
|          |     mechanisms."                                          |
|          |                                                           |
|          | 6.  Need to continue developing our VPN capabilities to   |
|          |     allow secure remote access                            |
|          |                                                           |
|          | 7.  Requires higher speed and higher bandwidth networks.  |
|          |                                                           |
|          | 8.  Need to implement a robust, interoperable directory   |
|          |     services capability.                                  |
|          |                                                           |
|          | 9.  Will need the interconnection of distributed Local    |
|          |     Area Networks (LANs).                                 |
|          |                                                           |
|          | 10. Need to create secure connections between legacy      |
|          |     systems, client/server and Internet applications.     |
|          |                                                           |
|          | 11. Need to define guidelines around "who pays", "who     |
|          |     uses", "who gets", and "who coordinates" these        |
|          |     interoperable networks.                               |
|          |                                                           |
|          | 12. Policies and protocols on sharing and exchanging      |
|          |     information with third parties need to be addressed   |
|          |     (e.g., restricted sub-nets will need to be            |
|          |     supported).                                           |
|          |                                                           |
|          | 13. Need to accommodate remote locations with secure      |
|          |     communication options.                                |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| ###      |                                                           |
|  Princip |                                                           |
| le 8: In |                                                           |
| formatio |                                                           |
| n Access |                                                           |
+----------+-----------------------------------------------------------+
|          | Security and privacy must not be compromised in order to  |
|          | accommodate easy and timely access to information.        |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   Required by federal laws and regulations              |
|          |                                                           |
|          | -   The Government Paperwork Elimination Act (GPEA)       |
|          |     requires agencies to incorporate privacy protections  |
|          |     when developing electronic processes.                 |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1.  Publicly accessible services must be logically        |
|          |     isolated from the internal networks to ensure         |
|          |     security.                                             |
|          |                                                           |
|          | 2.  By isolating information, public access to            |
|          |     information will be easier and more timely.           |
|          |                                                           |
|          | 3.  Effective security may increase the complexity of     |
|          |     internal access                                       |
|          |                                                           |
|          | 4.  Data access will be limited to those who "need to     |
|          |     know".                                                |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| ### Prin |                                                           |
| ciple 9: |                                                           |
|  Total C |                                                           |
| ost of O |                                                           |
| wnership |                                                           |
+----------+-----------------------------------------------------------+
|          | Security must be explicitly factored into a Total Cost of |
|          | Ownership (TCO) model for all IT systems.                 |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   Leads to better-informed decisions through an         |
|          |     improved understanding of trade offs that include     |
|          |     security                                              |
|          |                                                           |
|          | -   By including security in the planning process,        |
|          |     management commitment will be strengthened.           |
|          |                                                           |
|          | -   Enables improved planning and budget decision-making. |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1.  Need to develop a total cost of ownership model that  |
|          |     includes security and educate system sponsors and     |
|          |     decision-makers about how to use it.                  |
|          |                                                           |
|          | 2.  Need to identify methods to collect security cost     |
|          |     portion of TCO.                                       |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| ###      |                                                           |
|  Princip |                                                           |
| le 10: P |                                                           |
| roduct S |                                                           |
| tandards |                                                           |
+----------+-----------------------------------------------------------+
|          | Extra value will be given to security products and/or     |
|          | components adhering to federal standards and              |
|          | non-proprietary open architecture.                        |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   Required to support adequate levels of security.      |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1\. Need effective management process to identify and     |
|          | assess federal security standards, guidelines, laws and   |
|          | regulations.                                              |
|          |                                                           |
|          | > 2\. Participation in the development of open standards  |
|          | > is desirable; otherwise, someone else will do it for    |
|          | > you (e.g., litigation.)                                 |
|          | >                                                         |
|          | > 3\. Training and education are required to promote the  |
|          | > use of "open standards."                                |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| ###      |                                                           |
| Principl |                                                           |
| e 11: Pe |                                                           |
| rsonnel  |                                                           |
| security |                                                           |
+----------+-----------------------------------------------------------+
|          | All employees, vendors, business partners, consultants    |
|          | and contractors who require access to business            |
|          | information must be appropriately screened, trained and   |
|          | monitored.                                                |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   Required by federal laws and regulations              |
|          |                                                           |
|          | -   Supports the generally accepted principles and        |
|          |     practices of IT security.                             |
|          |                                                           |
|          | -   Ensures a baseline of security awareness.             |
|          |                                                           |
|          | -   Helps lower the overall risk, since you are only as   |
|          |     secure as your weakest link.                          |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1.  Need to ensure consistency across and among bureaus.  |
|          |                                                           |
|          | 2.  Position descriptions and performance standards will  |
|          |     need to be revised.                                   |
|          |                                                           |
|          | 3.  Contracts for non-feds will need to include security  |
|          |     responsibilities.                                     |
|          |                                                           |
|          | 4.  Need periodic training and a mechanism (e.g., records |
|          |     management system) to track that it has been done.    |
|          |                                                           |
|          | 5.  Need to have an enforcement mechanism.                |
|          |                                                           |
|          | 6.  Contracts/ negotiations with unions will need to be   |
|          |     modified (e.g., change in working conditions).        |
|          |                                                           |
|          | 7.  Need to acquire/develop forensic capabilities (e.g.,  |
|          |     chain of custody, evidence collection).               |
|          |                                                           |
|          | 8.  Need to have a damage assessment capability (e.g.,    |
|          |     "how big was information hole created by backhoe?").  |
|          |                                                           |
|          | 9.  Appropriate use/acceptable use needs to be clearly    |
|          |     defined and regularly communicated.                   |
|          |                                                           |
|          | 10. Accountability and personal liability must be clearly |
|          |     communicated.                                         |
|          |                                                           |
|          | 11. Need to develop guidelines for actions to take when   |
|          |     someone violates security policy.                     |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| ### Prin |                                                           |
| ciple 12 |                                                           |
| : Comput |                                                           |
| er Secur |                                                           |
| ity Inci |                                                           |
| dent Res |                                                           |
| ponse Ca |                                                           |
| pability |                                                           |
|  (CSIRC) |                                                           |
+----------+-----------------------------------------------------------+
|          | Interior will coordinate an incident response capability  |
|          | that will be shared across all bureaus.                   |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   Required by federal laws and regulations.             |
|          |                                                           |
|          | -   Supports the generally accepted principles and        |
|          |     practices of IT security.                             |
|          |                                                           |
|          | -   Establishes the linkages between policy enforcement   |
|          |     and system monitoring.                                |
|          |                                                           |
|          | -   Reduces risk, improves recovery time and/or minimizes |
|          |     damage.                                               |
|          |                                                           |
|          | -   Builds knowledge base, which allows security to be    |
|          |     proactive through information sharing of alerts and   |
|          |     vulnerability notifications.                          |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1.  Need to develop consistent, documented CSIRC          |
|          |     procedures across Interior.                           |
|          |                                                           |
|          | 2.  Need to develop a "trusted" information sharing       |
|          |     system for CSIRC among bureaus, to which only certain |
|          |     trusted people will have access.                      |
|          |                                                           |
|          | 3.  Need to develop knowledge base repository.            |
|          |                                                           |
|          | 4.  Need to develop criteria for incident response        |
|          |     procedures.                                           |
|          |                                                           |
|          | 5.  Need for staffing with knowledgeable people.          |
|          |                                                           |
|          | 6.  Need 24 x 7 capability for security (e.g., alert      |
|          |     notifications).                                       |
|          |                                                           |
|          | 7.  Need to acquire supporting tools and training.        |
|          |                                                           |
|          | 8.  Need IT security communication system tied into       |
|          |     incident response capability.                         |
|          |                                                           |
|          | 9.  Need criteria to determine when incidents come under  |
|          |     "fraud, waste and abuse" that requires further action |
|          |     (e.g., law enforcement).                              |
|          |                                                           |
|          | 10. Need to develop law enforcement linkages              |
+----------+-----------------------------------------------------------+
|          |                                                           |
+----------+-----------------------------------------------------------+
| ###      |                                                           |
| Principl |                                                           |
| e 13: In |                                                           |
| dividual |                                                           |
|  Securit |                                                           |
| y Respon |                                                           |
| sibility |                                                           |
+----------+-----------------------------------------------------------+
|          | All Interior employees, contractors, partners, etc. share |
|          | responsibility for Interior's IT Security.                |
|          |                                                           |
|          | **Rationale:**                                            |
|          |                                                           |
|          | -   Required by federal laws and regulations.             |
|          |                                                           |
|          | -   Supports the generally accepted principles and        |
|          |     practices of IT security.                             |
|          |                                                           |
|          | -   Responsibility for security must be shared because IT |
|          |     cannot do it alone.                                   |
|          |                                                           |
|          | **Implications:**                                         |
|          |                                                           |
|          | 1.  Non-security professionals need to be made aware of   |
|          |     security policies, procedures and their               |
|          |     responsibilities.                                     |
|          |                                                           |
|          | 2.  Accountability and personal liability must be clearly |
|          |     communicated.                                         |
|          |                                                           |
|          | 3.  Systems owners must take a proactive role in securing |
|          |     their systems. They need to work with managers to     |
|          |     ensure that employees working on those systems get    |
|          |     appropriate training and adequate time to perform.    |
|          |                                                           |
|          | 4.  All management levels must ensure that adequate       |
|          |     resources are provided for security and its           |
|          |     appropriate priority.                                 |
+----------+-----------------------------------------------------------+

## 

## Technology Components

The Security components in this domain include:

-   Virtual Private Network (VPN) - A Private Data Network that makes
    use of the public telecommunication infrastructure, maintaining
    privacy through the use of a tunneling protocol and security
    procedures.

-   Legislative / Compliance - Defines the pre-requisites that an
    application, system or service must have mandated by congress or
    governing bodies.

-   Authentication / Single Sign-on (SSO) -- Refers a method that
    provides users with the ability to log-in one time, getting
    authenticated access to all their applications and resources.

-   Test Management -- The consolidation of all testing activities and
    results. Test Management activities include test planning, designing
    (test cases), execution, reporting, code coverage, and heuristic and
    harness development.

-   Network Devices / Standards - A group of stations (computers,
    telephones, or other devices) connected by communications facilities
    for exchanging information.

-   Utilities -- Refers to software tools that address various
    miscellaneous processes for technology applications and users.

-   Certificates / Digital Signature - Software used by a certification
    authority (CA) to issue digital certificates and secure access to
    information.

-   Supporting Security Services - These consist of the different
    protocols and components to be used in addition to certificates and
    digital signatures.

The classifications for any products or standards within this domain
are:

Life Cycle Definition/

[Classifications]{.underline} [Meaning]{.underline}

Preferred Product/standard of choice; support available; recommended.

Contained Develop solutions using these standards or products only if
there are no suitable alternatives categorized as preferred; if a
preferred product is available that will meet the requirements, plans
should be developed to move from contained to preferred as soon as
practical.

Obsolete Being phased out; (e.g., vendor support ending); plans should
be developed to rapidly phase out and replace (often to avoid
substantial risks).

Research Product/standard to be used in conjunction with technology
research efforts only (e.g., testing, pilots).

Rejected Product/standard has been evaluated and found not to meet
technical architecture needs.

### 1.3.1 Virtual Private Network (VPN)

Virtual Private Network (VPN) is a Private Data Network that makes use
of the public telecommunication infrastructure, maintaining privacy
through the use of a tunneling protocol and security procedures.

-   Use of CISCO IPSEC protocol is classified as **Preferred**

-   Use of PPTP and L2TP protocols is classified as **Contained**

## 

### 1.3.2 Legislative / Compliance

Legislative / Compliance defines the pre-requisites that an application,
system or service must have mandated by congress or governing bodies.

-   Use of FISMA Requirements is classified as **Preferred**

-   Use of NIST Guidance is classified as **Preferred**

-   Use of NIST Common Criteria is classified as **Preferred**

### 1.3.3 Authentication/Single Sign-on

Authentication / Single Sign-on (SSO) refers a method that provides
users with the ability to log-in one time, getting authenticated access
to all their applications and resources.

.

**Authentication Standards:**

-   Use of Strong Passwords is classified as **Preferred**

-   Use of Smartcards is classified as **Preferred**

-   Use of 2 Factor Authentication is classified as **Preferred**

-   Use of Kerberos for Authentication is classified as **Preferred**

-   Use of Private / Public Key is classified as **Preferred**

**Single Sign-on Standards:**

-   Use of LDAP is classified as **Preferred**

-   Use of ACS Radius is classified as **Contained**

-   Use of TACACS+ is classified as **Contained**

-   Use of Kerberos for single sign-on is classified as **Contained**

**Authentication and Single Sign-on Products:**

-   Use of Microsoft Active Directory is classified as **Preferred**

-   Use of Novell Directory Services is classified as **Contained**

-   Use of Yellow Pages is classified as **Contained**

### 1.3.4 Test Management

Test Management is the consolidation of all testing activities and
results. Test Management activities include test planning, designing
(test cases), execution, reporting, code coverage, and heuristic and
harness development.

-   Use of Security Test and Evaluation (ST&E) is classified as
    **Preferred**

### 1.3.5 Network Devices / Standards

Network Devices / Standards refer to a group of stations (computers,
telephones, or other devices) connected by communications facilities for
exchanging information.

-   Use of Firewalls is classified as **Preferred**

-   Use of Intrusion Detection is classified as **Preferred**

### 1.3.6 Utilities

Utilities refer to software tools that address various miscellaneous
processes for technology applications and users. Utilities are broken
down into several categories. Due to the nature and increasing frequency
of Information Technology threats, Security Professionals must have the
ability to stay one step ahead of potential hackers and attackers of
Interior systems. Consideration when considering utilities is that,
whenever possible, they should be standards based and the latest
versions must be attained.

**Intrusion Detection Standards:**

-   Use of Anti-Spam is classified as **Preferred**

-   Use of Content Filtering is classified as **Preferred**

**Technical Vulnerability Assessment Standards:**

-   Use of Scanning is classified as **Preferred**

-   Use of Vulnerability Scanning is classified as **Preferred**

**Anti-Virus Products:**

-   Use of Norton Anti-Virus is classified as **Preferred**

-   Use of Mcafee Anti-Virus is classified as **Contained**

**Configuration Management Products:**

-   Use of Microsoft Systems Management Server (SMS) is classified as
    **Preferred**

-   Use of Symantic Enterprise Security Manager is classified as
    **Preferred**

-   Use of Tivoli Tivoli Suite is classified as **Contained**

-   Use of Network Associates ePolicy Orchestrator is classified as
    **Contained**

-   Use of LANDesk Software LAN Desk is classified as **Contained**

-   Use of Cisco, Cisco Works is classified as **Contained**

-   Use of Intuit Track-it is classified as **Contained**

-   Use of BMC Software Company Remedy is classified as **Contained**

**Intrusion Detection Products:**

-   Use of Freeware Snort is classified as **Preferred**

-   Use of Freeware Shadow is classified as **Preferred**

-   Use of Internet Security Systems RealSecure is classified as
    **Preferred**

**Packet Sniffer Products:**

-   Use of UC Berkeley Windump for NT is classified as **Preferred**

-   Use of Freeware Tcpdump for UNIX is classified as **Preferred**

-   Use of Ethereal, Ethereal for NT/UNIX is classified as **Preferred**

**Security & Assessment Products:**

-   Use of Slavlik HFNetChk is classified as **Preferred**

-   Use of Harris Corporation STAT Scanner is classified as
    **Preferred**

-   Use of Foundstone, Foundstone Security Suite is classified as
    **Preferred**

-   Use of Latace is classified as **Preferred**

-   Use of Bindview Corporation Bindview is classified as **Preferred**

-   Use of SystemTools.com Hyena is classified as **Contained**

**Technical Vulnerability Assessment Products:**

-   Use of Security Software Technogies L0PHTcrack is classified as
    **Preferred**

-   Use of John the Ripper is classified as **Preferred**

**Utilities -- Miscellaneous Products:**

-   Use of Norton Ghost is classified as **Preferred**

-   Use of Freeware SysInternals is classified as **Preferred**

-   Use of PowerQuest Driveimage pro is classified as **Preferred**

-   Use of PowerQuest Partition Magic is classified as **Preferred**

-   Use of PGP Corporation PGP (Version \> 7.0) is classified as
    **Preferred**

-   Use of CERT Internet Security Scanner is classified as **Preferred**

-   Use of Spam Assassin is classified as **Preferred**

-   Use of Security Auditor\'s Research Assistant (SARA) is classified
    as **Preferred**

-   Use of Microsoft Baseline Security Analyzer is classified as
    **Preferred**

-   Use of Freeware Nmap is classified as **Preferred**

-   Use of Freeware Nessus is classified as **Preferred**

-   Use of Wihisker.pl is classified as **Preferred**

-   Use of Fport is classified as **Preferred**

-   Use of Tripwire Company, Tripwire is classified as **Preferred**

### Certificates/Digital Signatures

Certificates / Digital Signatures refer to software used by a
certification authority (CA) to issue digital certificates and secure
access to information.

-   Use of FIPS 186-2 is classified as **Preferred**

-   Use of X509 is classified as **Preferred**

-   Use of ANSI X930, 199x part 1 is classified as **Preferred**

-   Use of ISO/IEC JTC1/SC27/WG2 is classified as **Preferred**

### Supporting Security Services

Supporting Security Services - These consist of the different protocols
and components to be used in addition to certificates and digital
signatures.

-   Use of S/Mime is classified as **Preferred**

-   Use of SAML is classified as **Preferred**

-   Use of TLS is classified as **Preferred**

-   Use of WS-Security is classified as **Preferred**

-   Use of 3DES is classified as **Preferred**

-   Use of AES is classified as **Preferred**

-   Use of FIPS 140-2 encryption is classified as **Preferred**

## 1.4 Select Best Practices

The Domain Principles, because they are derived from Interior's business
direction and strategies, provide the primary direction and guidance
around technology decisions within this domain. Additional benefit may
sometimes be obtained by reviewing Select Best Practices. These reflect
the valuable insights from either domain team members' experiences or
other public sector organizations.

**[SRM Focused]{.underline}**

**Select**

**Best Practice 1: Program -** Interior shall have an integrated IT
security program under the direction of the Departmental Office of CIO.
All levels of management are responsible for ensuring the success of the
program. The Office of the CIO (OCIO) and Departmental IT Security
Manager (DITSM) collaborates with the Bureau CIOs and Bureau IT Security
Managers (BITSM) to guide the implementation of IT security throughout
the Department.

**Select**

**Best Practice 2: Policy -** The IT security policy for Interior
provides the foundational requirements on how IT security will be
implemented throughout Interior.

**Select**

**Best Practice 3: Security Awareness, Training and Education --**
Education, training and awareness are a major part of Interior's IT
security program. Security awareness, training, and education will cover
all levels of IT security training and all levels of personnel including
executives, system owners, IT staff, end-users and contractors.

**Select**

**Best Practice 4: Risk Management -** Risk management is an integral
and ongoing element of Interior's IT security program for assessing
risk, and taking steps to reduce and maintain risk at an acceptable
level.

**Select**

**Best Practice 5: IT Contingency Planning -** Contingency planning
directly supports an organization\'s goal of continued operations. This
practice augments Continuity of Operations Planning specifically for IT
assets of Interior.

**Select**

**Best Practice 6: Certification and Accreditation --** All systems will
be certified and accredited in accordance with Interior IT Security
Program Policy.

**Select**

**Best Practice 7: Information Assurance --** Information resources
shall be protected to preserve the confidentiality, availability and
integrity consistent with the information's sensitivity and importance.

**Select**

**Best Practice 8: Computer Security Incident Response -** All computer
security incidents shall be reported to the appropriate authorities and
handled in accordance with established procedures.

**Select**

**Best Practice 9: Lifecycle Management -** IT security shall be an
integral part of IT system lifecycle management (LCM).

**Select**

**Best Practice 10: Personnel Security --** Follow established Interior
procedures (DM441) for determining suitability and grading positions for
access to sensitive information or systems. These procedures apply to
both Federal employees and others using government IT resources and/or
information (e.g., contractors).

**Select**

**Best Practice 11: Identification and Authentication --** Interior will
utilize identification and strong authentication as the basis for
establishing access and accountability associated with the use of IT
resources.

**Select**

**Best Practice 12: Physical and Environmental Security -** Physical and
environmental security controls shall be implemented to protect the
facilities housing IT resources and the IT system resources themselves.

**Select**

**Best Practice 13: Audit Trails -** Audit trails shall be employed to
maintain a record of user, application and/or system activity. Detail
shall be sufficient to reconstruct events, detect intrusion and misuse,
and assist in problem identification.

**Select**

**Best Practice 14: Software Configuration Management --** Test and
apply all security fixes and maintain a comprehensive record of all
configuration changes.

**Select**

**Best Practice 15: Hardware Maintenance --** Follow practices to
guarantee the ongoing availability of systems and IT resources.

**Select**

**Best Practice 16: Review of Security Controls -** Perform assessments
and evaluations at regular intervals to determine if the security
controls of a system are still operating within an acceptable level of
risk.

**Select**

**Best Practice 17: Production, Input/Output Controls -** Procedures for
storing, handling and destroying media shall be part of the support and
operations of IT systems.

**Select**

**Best Practice 18: Logical Access Controls --** Access controls shall
be implemented to enforce access and privileges to information for
authorized users based on the principles of least privilege and
need-to-know or use.

##  1.5 Contributors

The quality of the Interior-wide guidance provided within this TRM
chapter is a reflection of the efforts of the Security Domain team. The
members of the team are:

[Organization]{.underline} [Name]{.underline}

Bureau of Reclamation Lee Matuszczak

Bureau of Land Management David Cavallier

Minerals Management Service Thanh Do

National Business Center Jeanne Tallent

National Park Service Jim Guglielmino

Office of the Secretary Alan Wiser

Office of Hearings and Appeals Robert Elledge

Office of Special Trust Jay Lente

Office of Surface Mining Louis Blasiotti

US Fish and Wildlife Service Tom Snoich

US Geological Survey Lester North