Security Domain-Technology Reference Model Version 2.0

1.1 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.

Text Box:

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.

Principle 1: Information is an Interior 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. 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.

Principle 2: Data and Information Stewardship
	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. There must be support for adhering to federal laws, executive direction, guidelines and the generally accepted principles and practices of IT security. Stewardship includes responsibility for managing data’s consistency, timeliness, accuracy completeness, and the necessary security training and awareness. 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). Metadata will need to include a security classification or identification. Criteria used for classifying information/data needs to be flexible to accommodate changes in the threat environment (e.g., Homeland security). A clear process to assign and document stewardship responsibility on a application/system basis needs to be established and published.

Principle 3: Integration/ Interoperability
	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. Will need common security standards & consistent processes across Interior. Increased integration/ interoperability will increase risk & security complexity. When integrating systems, the highest security level of the source systems should be used. System security design will migrate to more widely used standards.

Principle 4: Reuse before you buy and buy before you 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.

Principle 5: Ensure Security, Confidentiality 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. Need for education on issues of privacy, security, and confidentiality to become routine part of normal business processes. Need to make the security, confidentiality and privacy requirements clear to designers, developers, users, system owners and operations personnel. Security has to be integral part of systems life cycle management (e.g., “baked in, not painted on”). System security certification and accreditation must be done prior to placing the system into operation and re-certified/ re-accredited periodically. Security must be included in the IT planning and budgeting processes. 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).

Principle 6: Continuity of Operations 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).

Principle 7: Enterprise Network 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: Need to identify the perimeter of the network. Requires effective and coordinated perimeter security. Requires elimination of all “back-door” access to networks Requires secure, remote access gateways, both in and out Intra-bureau networks will have to develop “trust mechanisms.” Need to continue developing our VPN capabilities to allow secure remote access Requires higher speed and higher bandwidth networks. Need to implement a robust, interoperable directory services capability. Will need the interconnection of distributed Local Area Networks (LANs). Need to create secure connections between legacy systems, client/server and Internet applications. Need to define guidelines around “who pays”, “who uses”, “who gets”, and “who coordinates” these interoperable networks. 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). Need to accommodate remote locations with secure communication options.

Principle 8: Information 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. By isolating information, public access to information will be easier and more timely. Effective security may increase the complexity of internal access Data access will be limited to those who “need to know”.

Principle 9: Total Cost of Ownership
	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.

Principle 10: Product Standards
	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.”

Principle 11: Personnel 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. Position descriptions and performance standards will need to be revised. Contracts for non-feds will need to include security responsibilities. Need periodic training and a mechanism (e.g., records management system) to track that it has been done. Need to have an enforcement mechanism. Contracts/ negotiations with unions will need to be modified (e.g., change in working conditions). Need to acquire/develop forensic capabilities (e.g., chain of custody, evidence collection). Need to have a damage assessment capability (e.g., “how big was information hole created by backhoe?”). Appropriate use/acceptable use needs to be clearly defined and regularly communicated. Accountability and personal liability must be clearly communicated. Need to develop guidelines for actions to take when someone violates security policy.

Principle 12: Computer Security Incident Response Capability (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. Need to develop a “trusted” information sharing system for CSIRC among bureaus, to which only certain trusted people will have access. Need to develop knowledge base repository. Need to develop criteria for incident response procedures. Need for staffing with knowledgeable people. Need 24 x 7 capability for security (e.g., alert notifications). Need to acquire supporting tools and training. Need IT security communication system tied into incident response capability. 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

Principle 13: Individual Security Responsibility
	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. Accountability and personal liability must be clearly communicated. 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. All management levels must ensure that adequate resources are provided for security and its appropriate priority.

1.3 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 Meaning

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

1.3.7 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

1.3.8 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

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 Name

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

Chapter 1. Information Security Architecture

Principle 2: Data and Information Stewardship

Principle 3: Integration/ Interoperability

Principle 7: Enterprise Network as a secure “Virtual” Network