1. introduction

The State of Arizona’s Enterprise Architecture (EA) describes a comprehensive framework for information technology (IT)[1] and business that supports the Arizona State government strategic plan. EA facilitates the application of information technology to business initiatives and objectives and subsequent change in an orderly, efficient manner by describing a direction for current and future activities, supported by underlying principles, standards, and best practices.

EA effectively supports and enhances the business of government and improves the ability to deliver responsive, cost-effective government functions and services. Effective utilization of technology to achieve business functions and services, increasing citizen access to those services, sharing information and resources at all levels of government, and maximizing IT resources investment are major motivating factors for the development and implementation of EA. The implementation of EA presents opportunities for State agencies to interoperate together to deliver a higher level of courteous, efficient, responsive, and cost-effective service to the citizen owners and employees of State government. Individually, each State agency can independently implement EA components that are interoperable, however, e-government initiatives, economies of scale, consolidation, and cross-agency savings may best be realized not just through interoperability, but also by working together in partnership and sharing.

EA includes important business, governance, and technical components. The technical components, collectively referred to as Enterprise Wide Technical Architecture (EWTA), provide technical guidance to State agencies. That guidance is supported by principles correlated to agency business functions, recommended standards, applicable recommended best practices, and technology trends[2]. Each component, or domain, of the EWTA is a separate, but interrelated, architectural discipline. EA is the glue that integrates each of these technical disciplines into a cohesive framework with the potential to transform government by improving service delivery, reducing costs, simplifying and streamlining requirements and services, and increasing efficiency and effectiveness.

EA applies to all agencies. The agency director, working in conjunction with the agency CIO, is responsible for ensuring the implementation of EA within the agency’s “sphere of influence,” as designated by statute or rule. The EA Target Domain Architecture documents define an overall strategy and technical framework; however, by design, the capital planning, process approach and timeframes for transition, project management, and investment control for the implementation of the target architectures are the responsibility of the agency[3]. Implementing EA requires significant capital investments. Arizona, like most states, does not have unlimited capital to invest in implementing EA, therefore, migrating to EA within available budgets is the only viable method.

2. Security Architecture Vision

Within the overall context of Homeland Security, the State of Arizona’s Security Architecture substantiates the fundamental significance of IT security to the State by delineating a set of processes, recommended standards, and best practices that will securely and economically protect the State’s IT business functions, including public access to appropriate information and resources, while maintaining compliance with the legal requirements established by existing Federal and State statutes pertaining to confidentiality, privacy, accessibility, availability, and integrity. Security Architecture provides a risk-based, cost-effective framework, and foundation to enable secure communication, protect agency business processes and information resources, and ensure that new methods for delivering service are secure.

3. Security Architecture Definition

Security Architecture defines common, industry-wide, open-standards-based technologies and applicable industry best practices as the cornerstone elements required to enable secure and efficient transaction of business, delivery of services, and communications among its citizens, federal government, cities, counties, and local governments, as well as the private business sector. Security Architecture must enable the State and individual agencies to quickly respond to technology, business, and information requirements changes without compromising the security, integrity, and performance of the enterprise and its information resources.

4. target Security architecture

Target Security Architecture addresses all relevant criteria on a broad scale, rather than as an individual agency or part of the deployment of an individual application The Target Security Architecture addresses security requirements and statutory mandates from a risk-based, cost-effective approach to establish a recommended minimum baseline for Security Architecture. State agencies have differing levels of security requirements and statutory mandates. Agencies that require higher levels of security based on more stringent mandates will extend or add to the baseline Target Security Architecture, Statewide Policy P800, IT Security and applicable Statewide security standards, and will document additions accordingly in individual agency policies, standards, and procedures.

The Target Security Architecture must identify the basic services needed to address security in both the current electronic environment and in future, anticipated electronic environments. Agencies are working to preserve the integrity, reliability, availability, and confidentiality of important information while maintaining their information systems. The most effective way to protect information and systems is to incorporate security into each domain of EA. This approach ensures that security supports agency business operations, thus facilitating those operations, and that plans to fund and manage security are built into life-cycle budgets for IT.

Target Security Architecture

Target Security Architecture provides the strategies and framework necessary to protect individual agency and the State’s information infrastructure, while transacting business in a changing electronic world. Security Architecture ensures that the systems that make State information and programs more accessible to the people of Arizona protect the State’s information and resources, and the rights of the people of Arizona.

These security issues are augmented by a recognition that the security of systems and data needs to include the recognition and protection of electronic documents. In addition to concerns about the security of data and the systems the data resides on, is a concern for the context and structure of signed (and unsigned) electronic government records (documents). This leads to a policy and practices collaboration with the Secretary of State and Library, Archives and Public Records in matters of signed and unsigned electronic government records. Part of the security issue is the assurance of the integrity and authentication of such records within current and future Electronic Records Management Systems.

Arizona’s Target Security Architecture is supported by principles correlated to agency business functions, recommended standards, applicable recommended best practices, and technology trends. The principles and recommended standards contained in this document are codified in Statewide Policy P800, IT Security, and statewide IT security standards. Policies and standards generated as part of EA are subject to the review, approval, refresh renewal procedures outlined in Statewide Policy P105, Policies, Standards, and Procedures (PSP) Policy.

Rather than present individual target domain tables that potentially could overlap or become outdated as other domains and associated statewide policies and standards are reviewed and updated, the technical components of the Target Security Architecture are summarily presented relative to the OSI 7498-1 Network Reference Model and 7498-2 Security Service Model in a composite, integrated domain table, consolidated from the individual EWTA domains, referred to as the Target Technology Table and available at: http://www.azgita.gov/enterprise_architecture/.

The development of the Target Security Architecture is a collaborative process to allow all agencies to participate so that their current investment in certain products and services can be maximized while also developing a transition plan[4] to allow obsolete or non-conforming elements to be phased out. Maximizing the investment and transitioning these elements should not be seen as mutually exclusive activities, since both are in the best interest of agencies and the State enterprise.

The development of the Target Security Architecture is also a continuous process[5], which is critically important in an environment where funding to implement may not be immediately available. The ongoing process provides the opportunity to continually refine the Target Security Architecture to keep it aligned with Homeland Security Initiatives, business strategies and requirements, emerging standards, and changing technology.

Security components that are not included in this Target Security Architecture document are:

Ø Operating System and Network Operating System security which are addressed in the Platform Domain.

Ø Application and database software security, which are addressed in the Software Domain.

Ø Classification of data, which is addressed in the Data/Information Domain.

5. Security Architecture Standards

Security Architecture Standards are established to coordinate agency implementation of security infrastructure that ensures the incorporation of applicable security requirements and mandates. Security Architecture recommended standards identify criteria and techniques associated with protecting and securely providing access to the State’s information resources.

The State of Arizona is continually moving towards electronic government in its methods of providing benefits and services to the public as well as in conducting business with the Federal government, local governments, and the private sector. As a result of transitioning from face-to-face to online interactions, security must change to ensure identities, authenticity, confidentiality, and reliability of digital information.

Security Architecture Standards have been developed using The National Institute of Standards and Technology (NIST) SP800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems, and NIST SP800-26, Security Self-Assessment Guide for Information technology Systems, and are categorized in the Target Technology Table according to the OSI 7498-1 Network Reference Model and 7498-2 Security Service Model. The goal is to employ only open security products and services based on common, proven, and pervasive industry-wide, approved, open standards; however, a full complement of open standards does not yet exist for all aspects of Security Architecture. Therefore, combinations of open standards, de facto industry standards, mutually agreed upon product standards, and best practices are currently required to protect the State's distributed information and resources.

The Recommended Security Architecture Standards contained in previous revisions of this document have been codified in statewide IT security standards. All Statewide Policies, Standards, and Procedures referenced in this document are available at http://www.azgita.gov/policies_standards.

Budget unit compliance with approved, published Statewide Security required shall be in accordance with Statewide Policy P800, IT Security, and Statewide Policy P700, Enterprise Architecture.

Security Architecture standards contained in statewide IT security standards are reviewed, updated, and approved in accordance with Statewide Policy P105, Policies, Standards, and Procedures (PSP) Policy.

6. Security Architecture Purpose

The purpose of security is to protect and secure the State's information resources in order to provide an environment in which the State's e-government business can be safely transacted. Protecting the information and systems that the State depends on is important as agencies increasingly rely on new technology.

The term “information security” means protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide – (A) integrity, which means guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity; (B) confidentiality, which means preserving authorized restrictions from access and disclosure, including means for protecting personal privacy and proprietary information; and (C) availability, which means ensuring timely and reliable access to and use of information.[6]

Security Architecture, categorized in conjunction with the FISMA definition above for information security and expanded by information derived from NIST SP800-33, Technical Model for Information Technology Security, provides for:

1. Availability of systems and data through:

· Identification, which is the process of distinguishing one user from all others. Identification techniques provide a means of gaining entry to the state's resources such as workstations, networks, and applications.

· Authentication, which is the process of verifying the identity of the user. Authentication answers the question: "Are you who you say you are?" e-Government transactions require strict identification and authentication of the sender or recipient of electronic information.

· Authorization and access control, which are the means of establishing and enforcing rights and privileges allowed to users. Authorization answers the question: "Are you allowed to do what you are asking or trying to do?" Authorization is the permission to use a technology resource. Access is the ability to do something with a technology resource. Access controls are the technical means to enforce permissions. They allow control over what information a user can use, the applications they can run, and the modifications they can make.

2. Integrity of data, which includes the processes and functions necessary to prevent the unauthorized modification of data while in storage, during processing, or while in transit. Integrity of systems, which requires that a system or application perform its intended function in an unimpaired manner, free from unauthorized manipulation.

3. Confidentiality of data and system information. Confidentiality is the requirement that private or confidential information not be disclosed to unauthorized individuals, while in storage, during processing, or while in transit.

4. Accountability, which includes:

· Requirements that actions of an entity can be traced to that entity.

· Non-repudiation, deterrence, fault isolation, and intrusion detection/prevention.

· Audit, which is the process of reviewing system activities that enable the reconstruction and examination of events to determine if proper procedures have been followed. Security architecture must provide the capability to track and monitor successful and unsuccessful interactions with the information infrastructure. The architecture should enable audit of all significant security events including authentication, accessing of services, and security administration.

5. Assurance, which includes the administrative functions necessary to establish, manage, and maintain security. Policies, procedures, practices, and programs that establish preventive methods to safeguard against security related issues and maintain critical public services should be addressed as part of assurance.

Security Architecture provides guidance to ensure that security requirements and associated risks are adequately evaluated when preparing to support adaptability, availability, access, data capture and data sharing needs of the State and its agencies.

7. Security Architecture Principles

Security Architecture Principles guide the planning, design, and selection of security products and services to enable the secure and efficient transaction of business, delivery of services, and communications among its citizens, federal government, cities, counties and local governments, as well as the private sector. The principles contained in this document and codified in Statewide Policy P800, IT Security, are derived from NIST SP800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems, and NIST SP800-27, Engineering Principles for Information Technology Security, as well as lessons learned, best practices, and technical considerations from other states’ enterprise architectures.

Principle 1

Security Architecture must enable the State and its agencies to perform business processes electronically and deliver secure e-government services to the public.

Rationale:

Ø E-government business processes and transactions will continue to increase across the State.

Ø The State and its agencies must be able to conduct business processes that provide access to information and resources electronically, while maintaining confidentiality and integrity.

Ø A standard set of security services allows State agencies to focus on business goals rather than on the development and implementation of independent security services.

Ø The implementation of Security Architecture:

o Protects State agency’s critical assets of resources and information.

o Provides a framework and foundation for secure interoperability and flexibility in conducting electronic business across the State.

Principle 2

Security levels applied to systems and resources must, at a minimum, be commensurate with their value to the State and its agencies, and sufficient to contain risk to an acceptable level.

Rationale:

Ø Security is an e-government and business process requirement with associated costs. Security costs should be rationalized to the intended benefits of the services that are delivered, and appropriate to the level of security required.

Ø The requirements for security will vary depending on Federal and State mandates, individual privacy rights, the application system, connection to other application systems, sensitivity of data, and probability of harm.

Ø Implementation of the appropriate level of security will safeguard against security costs that potentially increase beyond mandated requirements and the value of the assets protected. Security must be managed to compliment, not unnecessarily impede the State’s or agency business operations.

Ø Agencies, both individually and participating in “communities of interest,” have the flexibility to initially implement higher security practices to more easily move processes to higher security levels in anticipation of more stringent security mandates.

Principle 3

Security Architecture must be based on industry-wide, open standards.

Rationale:

Ø Security Architecture that utilizes open standards at all modular levels ensures portability and integration across platforms.

Ø Open standards-based solutions facilitate inter-agency communications and data exchange.

Ø Open, industry standards allow adaptability to migrate to emerging security technologies.

Ø Security Architecture services are infrastructure-level services; therefore, to take advantage of security services, application-level security should be designed for open standards.

Ø Security services already exist for many common applications; however, products from vendors may be implemented in ways that make it difficult to integrate these products into an overall security architecture. Existing application, system, or platform security mechanisms should be used whenever they match Security Architecture target standards. Application-specific security mechanisms should only be developed where necessary.

Principle 4

Security is a critical component of individual agency and State systems interoperability.

Rationale:

Ø Open, industry-wide standards-based security solutions support interoperability needs between application systems and agencies and position the State and agencies for future interoperability opportunities.

Ø Agencies should use encryption technologies when sharing sensitive data.

Ø Web-enabled transactions that require user authentication for transfer of sensitive data or funds should use encryption technologies.

Principle 5

Security architecture should accommodate varying security needs.

Rationale:

Ø Agency requirements for security vary depending upon the nature of communications, the sensitivity of the information, and the risks to the agency.

Ø Security needs will change as business requirements and applications change.

Ø Security services should be granular enough to accommodate the different levels of assurance required, and extensible enough to meet future requirements.

Ø Resetting security assurance levels should not require modification of the Security Architecture.

Ø Security Architecture must be flexible to support the introduction and/or integration of new technologies, while maintaining appropriate security protection and meeting statutory requirements.

Ø Whenever security is required, the location in a communications protocol will have an impact on performance, reliance on an underlying network protocol, and on developers. Choosing the appropriate layer in a communications protocol for security will maximize usability and minimize future changes. The performance impact can be minimized when security services are located in the lower layers of the communications protocol. Services provided at the transport layer have less impact on application programmers than services that run above that layer.

Ø Security services can increase reliance on a network protocol. Recommended Target Network Architecture Standards should be used, unless specific communication requirements of the business system dictate a proprietary solution.

1. Security Architecture recommended Best Practices

Best Practices are approaches that have consistently been demonstrated by diverse organizations to achieve similar results, which in the case of architecture, is demonstrating the principles.

Recommended Best Practices assist agency staff in the planning, design, implementation, and administration of systems and solutions that securely and economically protect agency and State business functions, information, and resources.

The Target Security Architecture recommends a series of standards, principles, and best practices addressing people, technology, and operational aspects of IT to address IT Security requirements. Statewide Policy P800, IT Security, and associated Statewide IT security standards are designed to ensure that the failure or breach of any individual security element will not leave agencies, or the State’s resources and information unprotected. The approved, published statewide IT security standards are available at http://www.azgita.gov/policies_standards/.

[1] Terminology used throughout this document is defined in the GITA Policies, Standards, and Procedures (PSP) and Enterprise Architecture (EA) Glossary of Terms available at: http://www.azgita.gov/policies_standards/glossary.htm.

[2] Trends, economic, governmental, and technical, that impact and influence EA are available at http://www.azgita.gov/enterprise_architecture/NEW/Architecure_Strategies_Framework/.

[4] Transition plans and the implementation of Target Network Architecture are addressed in Statewide Policy P700, Enterprise Architecture.

[5] The Enterprise Architecture lifecycle process is defined in Framework and Strategies and Statewide Policy P700, Enterprise Architecture.

[6] Federal Information Security Management Act (FISMA), Title III, E-Government Act.

Revision	Effective Date	Summary of Changes
NC	04/30/2002	Initial release
1.0	05/06/2003	Revision 1.0 release
2.0	04/05/2004	Revision 2.0 release 1. Introduction. Revised text to be consistent with newer domain documents. Added a graphic, references to applicable policies and standards, and footnote containing link to Enterprise Architecture Trends document. Expanded EWTA domains graphic to be consistent with the EA website. 4. Target Security Architecture. Inserted a graphical representation of Security Architecture. Updated the recommended implementation approach to clarify that the implementation of Target Security Architecture is the responsibility of each agency and, when undertaken, shall be in accordance with Statewide Policy P700, Enterprise Architecture, and Statewide Policy P340, Project Investment Justification (PIJ). Removed implementation information relative to the roles and responsibilities for incorporation of the recommended principles, standards, and best practices into Statewide IT contracts. The alignment strategy of EWTA standards and best practices with Statewide and agency IT contracts is presented in the Framework and Strategies document and Statewide Policy P700, Enterprise Architecture, to consistently address all EWTA domains. Replaced Security Architecture Table with Target Technology Table encompassing all EWTA domains, available at http://www.azgita.gov/enterprise_architecture/AZ_EA_Target_Technology_Table.htm. 5. Security Architecture Standards. Incorporated all Recommended Standards into the applicable, current, published versions of Statewide IT Security Standards, available at http://www.azgita.gov/policies_standards. 6. Security Architecture Purpose. Removed the description of Enterprise Architecture Strategic Alignment with FY2002-03 State IT Plan. It is available at: http://www.azgita.gov/enterprise_architecture/NEW/Architecture_Strategies_Framework/. 8. Security Architecture Recommended Best Practices. Updated section to reflect the incorporation of the majority of Best Practices into the applicable, current, published versions of Statewide IT security standards. 9. Security Architecture Technology Trends. Removed entire section since reference to the location of the document it referenced has been added to the footnote in Section 1, Introduction. Appendix A. OSI Reference Model. Removed. Content has been replaced by the Target Technology Table, available at http://www.azgita.gov/enterprise_architecture/AZ_EA_Target_Technology_Table.htm. Appendix B. Agency Security Architecture “As-Is.” Removed. Agency IT Security is reported and maintained in accordance with Statewide Standard P800-S805, IT Risk Management. Appendix C. Threats to e-Government Business. Removed. Incorporated information into IT Security Assessment, of Statewide Standard P800-S805, IT Risk Management.