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

Chapter 1. Information Security Architecture

1.1 Introduction and Background

1.2 Architectural Principles

Principle 1: Information is an Interior Asset

Principle 2: Data and Information Stewardship

Principle 3: Integration/ Interoperability

Principle 4: Reuse before you buy and buy before you build