Home ยป Securing Microsoft Terminal Services First Web Edition

Chapter 4: Enterprise Architecture

Posted April 30th, 2008 by roddyr

Chapter 4: Enterprise Architecture

  
Chapter Overview:
This chapter beginswith a high level overview of Enterprise Architecture (EA) and concludes with an introduction to the Enterprise Architecture’s policy infrastructure. Because Enterprise Architecture is a field unto itself, a detailed review of its principles, processes, and approach is beyond the scope of this book. The goal of this chapter is to explain how Terminal Server fits within an Enterprise Architecture.
 
The purpose of Enterprise Architecture is to establish an Enterprise wide blueprint used to achieve business objectives while maximizing the business value of information technology. An Enterprise Architecture is a “blueprint” that describes an organization’s strategic direction, security and regulatory requirements, information technology portfolio and their inter-dependencies, baseline and target architectures, and the processes to implement new technologies. In business terms, Enterprise Architecture is accomplished by efficiently achieving an organization’s mission with minimal investment in information technology; and in technical terms, by optimizing business operations, effective information technology planning, information technology budgeting, information technology acquisition, human resource utilization, and the implementation of security controls.
 
After the goals and stakeholders of an Enterprise Architecture project have been identified, a framework is selected to help implement and support the Enterprise Architecture through its entire life cycle. Frameworks provide methodologies, standards, guidelines, and formats that can be used as is or adapted to meet specific requirements. Because organizations have different missions and business objectives, no single framework will be right for each situation. Organizations typically select a framework or a mixture of frameworks to meet their requirements. There are a number of feasible frameworks, such as Cobit, ISO/IEC 17799, ITIL, and others that represents a variety of methodologies and toolsets to fulfill the requirements of any size or type of organization.
 
Enterprise Architecture has well defined principles and processes, along withan approach that generates a comprehensive layered policy infrastructure used to communicate management’s goals, principles, instructions, appropriate procedures, and response to laws and regulatory mandates. A policy infrastructure consists of tier 1, tier 2 and tier 3 policies that encompass people, systems, data, and information. A policy infrastructure consists of policies, standards, procedures, baselines, and guidelines.
 
Tier 1 policies sit at the top of the policy infrastructure and address broad organizational issues, vision and direction. Most organizations will develop and support up to a dozen tier 1 policies. An example tier 1 policy is an Employee Practices Policy or a Conflict of Interest Policy. Global in scope, Tier 1 policies are high level documents that define vision and direction. Tier 2 policies are topic specific, and tier 3 policies are application or system specific. Standards are tier 2 policies that describe system design concepts, implementation steps, and detailed configurations. Procedures are tier 2 & 3 policies that provide step by step compulsory measures, communicating best practices in using information systems and organizational data/information. Baselines are tier 3 policies that are application or system specific and describe step by step instructions to implement technologies. Guidelines are tier 3 documents, offering application, system, or procedural specific best practices. Guidelines are recommendations unlike policies, standards, procedures, and baselines, which are compulsory.
 
Figure 4.1 shows the organization of Enterprise Architecture’s layered policy infrastructure.
 
Figure 4.1
 
 
Figure 4.1 represents Enterprise Architecture’s layered policy infrastructure, starting with tier 1 policies which address broad organizational issues, vision, and direction. The next layer, General Organizational Policy, consists of tier 1 policies in which management makes security statements, explains roles and responsibilities, and defines which assets are considered valuable. The following layer, Practical Implementation Policies, contains tier 2 and 3 policies which are topic, application, and system specific and are used to enforce upper layer policies. The lower layer consists of tier 2 and 3 policies which are topic and technology specific and are used to enforce higher layer policies.
 
Figure 4.2 shows the work flow of a policy infrastructure.
 
Figure 4.2
 
 
 
A policy infrastructure contains confidential information relating to running a business and the publication, distribution and storage of that information should be strictly monitored. Many organizations leverage the human resource department and web-based intranet solutions to distribute and control access to policies.
 
An Enterprise Architecture groups infrastructure components within topic specific domains. An example of Enterprise Architecture domains are infrastructure, applications, network, and security. After an organization has defined its Enterprise Architecture domains, all infrastructure components are grouped within their corresponding domain and reviewed individually and as a single cohesive unit. Layered policies are developed for each domain and individual technology within a domain.
 
Table 4.1 shows the Enterprise Architecture domain structure that will be used throughout this book. The example encompasses five domains split between two high level domains of infrastructure and applications. The domains are platform, network, software, data / information, and security.
 
Table 4.1

Enterprise Architecture Scope
Infrastructure
Applications
Platform
Software
Network
Data/Information
Security

 
An organization’s mission and business objectives drive its Enterprise Architecture domain structure. As we have all learned, there is no ‘one size fits all’ with information technology, and Enterprise Architecture is no exception. Enterprise Architecture is flexible and can be molded to suit any organization’s mission and business objectives.
 
Table 4.2 shows a variation of the above Enterprise Architecture domain structure.
 
Table 4.2

Enterprise Architecture Scope
Platform
Network
Software
Data/Information
Security 
Access Domain
Integration Domain
Privacy Domain
Project Management Domain
Systems Management Domain

 
Each of the domains within an Enterprise Architecture will have its corresponding layered policy infrastructure, with tier 1 & 2 policies, tier 2 & 3 standards, procedures, baselines, and guidelines. Many of the layered policies within an Enterprise Architecture govern a Terminal Server environment because they dictate user access methods, network infrastructure parameters, and applications and security controls that work within a Terminal Server environment.
 
To gain a broader understanding of how Terminal Server fits within an Enterprise Architecture, the next sections will review tier 2 & 3 policies from the platform, network, software, data/information, and security domains.
 
 
The platform architecture domain defines the roles, policies, standards, and decision-making criteria for the acquisition and deployment of all computing and data storage hardware and operating systems for servers, desktops, and handheld devices. The platform architecture domain policies start with a definition of high level platform architecture requirements and cascade down to hardware standards and operating system installation and configuration. High level policies from the platform architecture domain include the Platform Architecture Policy and Platform Infrastructure Standard, which establish the foundation for lower layer policies.
 
List 4.1 shows a partial list of the layered policies within the platform architecture domain.
  • Platform Architecture Policy
  • Platform Infrastructure Standard
  • Server Standards
  • Windows Terminal Server Standards
  • Windows Server Security Policy
  • Hardware Virtualization Standards
 
Note: An organization’s policy infrastructure directly reflects its unique mission and business objectives. The above list is for educational purposes only.
 
At the top of the platform architecture domain policy infrastructure sits the Platform Architecture Policy. The Platform Architecture Policy is a big picture tier 2, non vendor specific document, which establishes high level platform architecture requirements that define the acquisition and deployment of servers, end-user devices, and storage technologies. Lower level tier 3 policies define vendor specific technologies, outlining system-specific or procedural-specific standards and requirements.
 
Many of the lower level tier 3 policies define the controls that govern the acquisition and deployment of the hardware and operating system upon which Terminal Server will run. They also define data storage and personal computing devices requirements. During the development and periodic review of platform architecture policies, Terminal Server and supporting technologies must be carefully considered to ensure interoperability, integration, and security.
 
The next example is a platform architecture policy. The goal with this example is to illustrate the relationship between a high level tier 2 platform architecture policy and Terminal Server. This policy is intended for informational purposes only.
 
 
Purpose and Scope
The purpose of this policy is to establish platform architecture requirements which control the acquisition, use, and management of server, personal computing devices, and storage technologies. This policy provides controls that ensure Enterprise issues are considered along with business objectives when making computing platform related decisions. The scope of the platforms in this policy includes servers, personal computing devices and storage systems.
 
Platform Architecture policies, standards and guidelines will be used to acquire, design and implement servers, personal computing devices, and storage systems.
 
Responsibilities
The CEO and CIO ensure that policies are followed in order to establish contracts, review procurement requests and to develop and manage services.
 
Platform Architecture Goals
The goals to employ computing platform controls are to:
  • Ensure that platform devices support industry-wide open-standards and seamlessly interoperate with other platform devices, operating systems, storage technologies and embedded security.
  • Meet business objectives through greater efficiencies in the acquisition and use of computing platforms.
  • Ensure the availability of tools in order to meet business objectives, security, management and productivity requirements.
 
Platform Architecture Categories
Platform Architecture categories address servers, personal computing devices and storage technologies, including their hardware and operating systems. Platform Architecture categories include Servers, Personal Computing Devices, and Storage.
 
Servers
A server is a computer that provides services for other computers. Types of servers include:
  • Mainframe servers
  • High-end servers
  • Mid-range to small servers
 
Personal Computing Devices
Personal computing devices are desktop computers, thin clients, laptops and handheld devices, including the operating systems and their hardware. Types of personal computing devices include:
  • Desktop personal computers
  • Thin Clients
  • Handheld devices
 
Storage
Storage technologies address short term, long term and permanent storage of information and data. Types of storage technologies include:
  • Direct Attached Storage
  • Network Attached Storage
  • Storage Area Network
 
Assumptions and Expectations
Platform Architecture evaluates platform technologies in terms of flexibility, scalability, and interoperability with other platform technologies and operating systems. Each platform architecture category should have the following characteristics: Servers, Personal Computing Devices and Storage.
 
Servers
  • Have embedded security
  • Support industry-wide open-standards
  • Support centralized management
  • Support common management tools
  • Interoperate with other platform technologies
 
Personal Computing Devices
  • Have embedded security
  • Support industry-wide open-standards
  • Support centralized management
  • Support common management tools
  • Interoperate with other platform technologies
 
Storage
  • Have security
  • Support industry-wide open-standards
  • Support centralized storage
  • Support common management tools
  • Interoperate with other platform technologies
 
Compliance
All information technology investments will comply withexisting policies to ensure the integrity and interoperability of computing platforms.
 
Related Policies
Platform Infrastructure Standard
 
The example Platform Architecture Policy illustrates how a policy is used to define high level computing platform requirements, roles and responsibilities. The policy defines servers, personal computing devices and data storage computing platform requirements. Each individual computing platform must have seamless interoperability and integration with Terminal Server. During the development or review of platform architecture policy, Terminal Server and other computing platforms must be carefully considered to ensure interoperability, integration and security.
Summary
The platform architecture domain defines the roles, policies, standards and decision-making criteria for the acquisition and deployment of all computing and data storage hardware and operating systems for servers, desktops and handheld devices.
 
Network Architecture Domain
The network architecture domain defines the network infrastructure and explains how data flows between systems, computers and devices on a network. It defines the technologies used to enable reliable, secure communication on LAN, WAN and wireless networks. Architects that develop or review network architecture policies must understand Terminal Server architecture and end-user access requirements in order to ensure reliable and available network access to resources via Terminal Server.
 
List 4.2 shows a partial list of the layered policies within the network architecture domain.
  • Network Architecture Policy
  • Network Infrastructure Standard
  • Router and Switch Technology Standards
  • Network Security Standards
 
Note: The policy infrastructure of an organization directly reflects the unique mission and business objectives of the organization. The above list is for educational purposes only.
 
Network infrastructure enables reliable and secure communication between information systems and all related computing platforms. The network architecture domain with its layered policies takes into consideration Terminal Server architectural and supporting computing platforms to ensure reliable and secure communications over a wide variety of networks.
 
The next example is an abbreviated network architecture policy. The goal with this example is to illustrate the relationship between a high level network architecture policy and Terminal Server. This policy is intended for informational purposes only.
 
Network Architecture Policy
 
Purpose and Scope
The purpose of this policy is to establish network architecture requirements that describe how information processing resources are interconnected to topology standards, transport media, and protocols used to deliver converged services, including traditional data, voice, and video services. This policy provides controls that ensure Enterprise issues are considered along with business objectives when making network architecture related decisions. The scope of the architecture in this policy includes a network infrastructure to enable converged services, such as traditional data, voice and video services.
 
Responsibilities
The CEO and CIO ensure that policies are followed in order to establish contracts and procurement requests and to develop and manage services.
 
Network Architecture Goals
The goals to employ network architecture controls are:
  • Networks should be operational, reliable and available 24x7x365 to support mission-critical business operations and processes.
  • Networks should be designed for security, growth and adaptability.
  • Network architecture shall use proven open industry standards.
  • Network architecture will support converged services while accommodating traditional data, voice and video services.
 
Network Architecture Topology
Network architecture topology consists of the following:
  • Local Area Network (LAN): A local area network is a communications system that covers a small local area, like an office or building.
  • Wide Area Network (WAN): A wide area network is a communications system that spans a large geographical area.
 
Network architecture transport media include:
  • Wired (i.e. copper, fiber)
  • Wireless (i.e. 802.x, all EVDO)
 
Network Architecture protocols provide the rules that support network access and communication.
 
Assumptions and Expectations
Network Architecture evaluates network technologies in terms of flexibility, scalability, and interoperability with other technologies.
 
Compliance
All information technology investments shall conform to existing policies in order to ensure the integrity and interoperability of computing platforms.
 
Related Policies
Network Architecture Standard
Network Architecture Guideline
 
The example network architecture policy illustrates how a policy is used to define network architecture requirements and to describe how information processing resources are interconnected.
 
 
Unlike the platform architecture domain policies that govern Terminal Server, the network architecture domain establishes the foundation to plan, build, run and monitor the network infrastructure. Architects that oversee the development or review of network architecture policy must understand Terminal Server architecture and end-user access requirements to ensure reliable and available network access to resources via Terminal Server.
 
The next section will review the data and information architecture domain. We will also review a data classification and categorization standard which is used to define the classification and categorization of data/information and information systems such as Terminal Server.
 
Data/ Information Architecture Domain
 
The data/information architecture domain provides the layered policy infrastructure that describes business processes, data requirements of business systems and user data, and the classification and categorization of data/information and information systems. High level policies, such as the Data Architecture Policy, describe the requirements used to develop, acquire and implement technologies that collect, modify, store and report data/information. Other high level policies within the data and information architecture domain are the Data Modeling Standards, used to develop flow charts to understand business processes and data flow, and the Data/Information Classification and Categorization Standards, which are used as a framework to define data/information’s criticality and sensitivity levels, custodian responsibilities and accessibility.
 
List 4.3 shows a partial list of the layered policies within the data/information architecture domain.
  • Data Architecture Policy
  • Data Modeling Standards
  • Data/Information Classification and Categorization Standards
  • Database Systems Standards
  • Data Modeling Standards
  • Enterprise Document Management System Standards
 
Note: The policy infrastructure of an organization directly reflects the unique mission and business objectives of the organization. The above list is for educational purposes only.
 
Policies from the data and information architecture domain lay the foundation for information security by explaining business processes and how information flows between systems. The data and information architecture domain will also provide guidance for personnel on how to classify and maintain data. Data classification and maintenance policies allow organizations to implement the appropriate security controls based on the sensitivity and criticality of data/information.
 
Terminal Server is often used as the primary interface to applications, data and information. From a data/information security perspective, security controls will be implemented at multiple layers (defense in depth), starting with compartmentalization of data and systems along with administrative and technical security controls.
 
The next example is an abbreviated Data/Information Classification and Categorization Standard. This example shows how a standard allows an organization to define data/information classifications and security levels for both data/information and information systems. This standard is intended for informational purposes only.
 
Data/Information Classification and Categorization Standard
 
Purpose and Scope
The purpose of this standard is to identify classifications and security levels for all forms of data/information and information systems across the Enterprise. It is intended to establish a “need to know” data/information classification methodology in order to protect <Company Name> data and information against unauthorized discloser, loss or misuse. This standard provides controls that ensure Enterprise issues are considered along with business objectives when making data/information classification decisions. The scope of the standard covers all forms of <Company Name> data/information throughout its entire life cycle, from its origination to its destruction.
 
Data Classification Standards Goals
The goals of this standard is to establish how data/information is classified according to its criticality and sensitivity and to ensure that <Company Name> data/information preserves its security classification as it traverses information systems or non-electronic boundaries.
 
Data Classifications
All <Company Name> information will be categorized into three main classifications:
  • Public
  • Internal
  • Confidential
Table 1 provides examples of each classification and required security measure.
 
Table 1

Security
Objective
Data Classification
 
Public
Internal
Confidential
Criteria 
 
Unauthorized disclosure would not considerably impact organization.
Unauthorized disclosure would result in considerable adverse impact, embarrassment or legal actions.
Examples
Examples include public web site, press releases, marketing brochures, annual reports, and public financial filings.
Examples include inter-office memoranda, internal correspond-dence, employee newsletters, internal directories, and internal policies. 
Examples include employee records, department financial data, purchasing information, new product designs, strategic plans, marketing studies, vendor and customer contracts, confidential information of organizations customers, partners, and suppliers.
Accessibility
Available to the general public, can be distributed outside the organization.
Available for internal use. May be shared outside the organization to meet business objectives only when approved by a manager.
Access is limited to a “need to know” basis within the organization.
Document Label
None
“Internal”
“Confidential”

 
Data and information, regardless of its medium, will be:
  • Classified as either public, internal, or confidential.
  • Used in a manner equivalent with its classification.
  • Segregated by accessibility, file structure, or presentation.
  • Secured in accordance with applicable standards.
  • Disposed of in accordance with applicable standards.
 
Data and Information Custodians Responsibilities
Data/information custodians are responsible for the classification and execution of security controls of data they own, create or have become a delegate of. Data and information custodians retain their responsibility of data classification and execution of security controls for data and information within the organization, or for data/information that isshared with other organizations.
 
Security Categories for Data/Information and Information Systems
Source: FIPS PUB 199-final, Categorization of Information and Information Systems.
This section establishes security categories for both data/information and information systems. The security categories are based on the potential impact on an organization should certain events occur that jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions and protect individuals. Security categories are to be used in conjunction with vulnerability and threat information in assessing the risk to an organization.
 
Categorization of data/information and software application systems includes risk levels of confidentiality, integrity, and availability. Table 2 summarizes the security objectives and their risk levels.
 
Table 2

POTENTIAL IMPACT
Security Objective
LOW
MODERATE
HIGH
Confidentiality
Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
[44 U.S.C., SEC. 3542]
The unauthorized disclosure of information could be expected to have a limited adverse effect on organizational operations, organizational assets or individuals.
The unauthorized disclosure of information could be expected to have a serious adverse effect on organizational operations, organizational assets or individuals.
The unauthorized disclosure of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets or individuals.
Integrity
Guarding against improper
information modification or destruction; includes ensuring information non-repudiation and authenticity.
[44 U.S.C., SEC. 3542]
The unauthorized modification or destruction of information could be expected to have a limited adverse effect on organizational operations, organizational assets or individuals.
The unauthorized modification or destruction of information could be expected to have a serious adverse effect on organizational operations, organizational assets or individuals.
The unauthorized modification or destruction of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets or individuals.
Availability
Ensuring timely and reliable access to and use of information.
[44 U.S.C., SEC. 3542]
The disruption of access to or use of information or an information system could be expected to have a limited adverse effect on organizational operations, organizational assets or individuals.
The disruption of access to or use of information or an information system could be expected to have a serious adverse effect on organizational operations, organizational assets or individuals.
The disruption of access to or use of information or an information system could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets or individuals.

 
The potential impact is LOW if the loss of confidentiality, integrity or availability could be expected to have a limited adverse effect on organizational operations, organizational assets or individuals.
 
The potential impact is MODERATE if the loss of confidentiality, integrity or availability could be expected to have a serious adverse effect on organizational operations, organizational assets or individuals.
 
The potential impact is HIGH if the loss of confidentiality, integrity or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets or individuals.
 
Compliance
All classification and security levels for data/information and information systems will conform to existing policies. Any employee found to have violated this standard may be subject to disciplinary action, up to and including termination of employment.
 
Related Policies
Data Architecture Policy
Data Modeling Standards
Data Security Policy
 
Reference
FIPS PUB 199-final
 
The example illustrates how a standard defines classifications and security levels for all forms of data/information and information systems across the Enterprise. The classification of data/information and information systems sets the stage for information security, allowing organizations to employ the appropriate security control based on the sensitivity or criticality of data and information systems.
 
The data and information architecture domain directly influences the design, support and auditing of a Terminal Server environment. Organizations implement administrative and technical controls to ensure the confidentiality, integrity and availability of sensitive data. From a design perspective, Terminal Server silos can be leveraged to support access to different data security levels. One Terminal Server silo with one set of security controls can be leveraged to access internal data, while other silos with different security controls such as encryption and application access restrictions are used to access confidential data. Terminal Server silos allow the appropriate security controls such as auditing and encryption to be implemented based on the sensitivity of the data or application accessed from a given Terminal Server silo.
 
The software architecture domain defines the methodologies, tools and best practices to develop, acquire, deploy and retire software that automates and maintains business processes. It provides a framework to ensure the integrity, interoperability and integration of software and computing platforms. The software architecture domain policy infrastructure provides the framework to support the entire lifecycle of software, including desktop applications and management software installed and managed on Terminal Servers. Software architecture can consist of the following components:
 
  1. Applications
    • Software designed to automate specific business processes, such as customer resource management, employee services, accounts payable, payroll, etc.
  2. Programming Software
    • Enabling technologies used to develop software.
  3. Database Software
    • Database management systems that enable organizations to store, modify and extract information from a database.
  4. Productivity Software
    • Office productivity and collaborative software.
  5. Management Software
    • Software used to maintain, monitor and audit network infrastructure and computing platforms.
An example of high level tier 2 policy in the software architecture domain is the Software Architecture Policy, which describes high level requirements to design, develop or acquire software. Another example high level policy is a tier 2 Applications and Software Standard that is used to describe high level application and software standards. Lower level tier 2 & 3 policies describe individual applications or application groups. An example would be the Productivity Application Standards, which isa tier 2 policy describing Enterprise-wide productivity application standards. Lower level tier 3 policies describe application A, B or C’s configuration and use.
 
List 4.4 shows a partial list of the layered policies within the software architecture domain.
  • Software Architecture Policy
  • Application and Software Standards
  • Productivity Application Standards
  • Application Development Standards
  • Load and Performance Testing Software Standards
  • Software Licensing Policy
 
Note: The policy infrastructure of an organization directly reflects the unique mission and business objectives of the organization. The above list is for educational purposes only.
 
The next example is a tier 3 Terminal Server Application Software Policy. This example illustrates the relationship between the software architecture domain, layered policy infrastructure and Terminal Server. This policy is intended for informational purposes only.
 
Terminal Server Application Software Policy
 
Purpose and Scope
The purpose of this policy is to define Terminal Server application software requirements that control the acquisition, use, management and retirement of software applications. This policy provides controls that ensure that Enterprise issues are considered along with business objectives when making Terminal Server application software related decisions.
 
The scope of this policy includes all standard desktop suites and application software intended for use on Terminal Servers.
 
Responsibilities
The CEO and CIO ensure that policies are followed to establish contracts, review procurement requests and to develop and manage services.
 
Policy Identifies and Defines
  • Define <Company Name’s> Terminal Server desktop and list all supported application software.
  • Define a standard model for deployment, installation and updates of Terminal Server application software.
  • Define eachapplication software’s life cycle, classification and management requirements.
Standard Desktop and Sanctioned Application Software
The standard desktop is available exclusively from <Company Name> Terminal Servers. The standard desktop will contain approved desktop suites and application software as a business service for the purpose of supporting <Company Name> business activities and occasional personal use as defined in the Acceptable Use Policy.
 
The standard Terminal Server desktop application portfolio will consist of the following categories:
a. Office Productivity
  • Word processor
  • Spreadsheet
  • Presentational software
  • Customer Relations Management software
  • Project management software
  • Email client with group calendaring and address book facility
  • Web browser with essential plug-ins
  • Media player
  • PDF reader
  • File compression/archiving tool
  • File browser
  • Calculator
b. Management Software
  • Anti-virus and malware software
  • Log Analyzer
  • Network sensor
c. Optional Software
  • “in-house” software
  • Graphics editing
  • Web authoring
  • PDF writer
  • Terminal emulation client
  • X-Windows client
 
This list contains application software that is specifically prohibited:
  • Games
  • Peer to peer file sharing software
  • FTP software
  • Instant messaging clients
 
The names and versions of software in the above categories are found in the Application Software Standards document.
 
Application Software Deployment
  • <Company Name> IT staff will provide an automated standard deployment solution for application software. This model will be used to deploy and update all software on the standard desktop.
  • All application software intended for deployment on the standard desktop will first require “packaging”. <Company Name> IT staff will provide a packaging solution for this purpose. When it is not technically possible to package an application, an alternative will be presented to management for approval before the application is put into production.
 
Application Software Life Cycle Classification and Management Requirements
The application software life cycle classifications are: current, contained, retired and research/emerging. The classifications are defined in the Application Software Standards policy.
 
Application software life cycle management follows NIST Special Publication 800-64 and is defined in the Systems Life Cycle Management Policy.
 
Assumptions and Expectations
Terminal Server Application Software will be evaluated in terms of cost, flexibility, scalability and interoperability with Terminal Server and other platform technologies. Each Terminal Server Application Software category should have the following characteristics:
  • Embedded security and logging capabilities
  • Support for industry-wide open-standards
  • Support for centralized management
  • Interoperation with other platform technologies and authentication systems
 
Application Software Approval Process
Before any application software is put into production, it will go through an approval process. Before any application software is approved for production, an Application Assessment Profile (Appendix A) is submitted for approval.
 
Appendix A

Survey Site:
 
Date:
 
Surveyor:
 
Application:
 
Version:
 
Type:
 
Install directory:
 
Install date:
 
User(s):
 
Describe the application function:
 
Application manufacturer:
 
Manufacturer contact(s):
 
Manufacturer Web:
 
Manufacturer phone:
 
Questions:
Answer:
Comments:
ISV or custom-built application?
 
 
If custom-built, is the source code available?
 
 
Is the vendor still in business?
 
 
How often is this application used?
 
 
How many users use this application?
 
 
Does the application require a DOS device driver?
 
 
Does the application require any input devices besides a keyboard and mouse? Please describe how the devices are attached.
 
 
Does the application use .ini files? If so, please provide details.
 
 
How much memory does the application require?
 
 
Does the application depend on DCOM?
 
 
Does the application require IPX?
 
 
Will the application work with IP?
 
 
Does the application require a unique IP address to work?
 
 
Does the application have a dependency on a server component? If so, is there a set of api that it uses?
 
 
Is there a database dependency? What database/version?
 
 
Is there a host connectivity dependency? If so, what kind (appc, nfs)?
 
 
What is the data flow for the application?
 
 
Would you consider this a graphic-intensive application?
 
 
Describe other application dependencies.
 
 
Is the version of the software the latest version available?
 
 
Is this a custom Windows NT graphical identification and authentication (GINA) DLL?
 
 

 
Compliance
All Terminal Server Application Software shall conform to existing policies. Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
 
Related Policies
Acceptable Use Policy
Application Software Standards
Systems Life Cycle Management Policy
 
Reference
NIST Special Publication 800-64
 
The example illustrates how a policy defines the application software life cycle for a Terminal Server environment. This policy provides the foundation for lower level policies that are used to design, develop, implement and maintain application software on Terminal Servers.
 
 
The software architecture domain defines the methodologies, tools and best practices in order to develop, acquire, deploy and retire application software. It provides a framework to ensure the integrity, interoperability and integration of application software and computing platforms across the Enterprise. The software architecture domain policy infrastructure provides the framework to support the entire lifecycle of application software. Architects that oversee the development or review of software architecture policy must understand Terminal Server application software requirements to ensure the integrity, interoperability and integration of application software in a Terminal Server environment.
 
Security Architecture Domain
 
The security architecture domain defines the roles, policies and process reviews to implement and monitor security across an Enterprise. The security architecture domain encompasses people, physical security and the technologies used for security management, such as surveillance, firewalls, intrusion detection, cryptography, public key infrastructure (PKI), authentication, authorization, remote access, virus detection, and so forth. It enables organizations to look at their entire technology portfolio as a single cohesive unit and apply the appropriate security controls in order to achieve business objectives without compromising user productivity.
 
An example of a high level policy in the security architecture domain is the Security Architecture Policy, which defines security and regulatory requirements used to establish a recommended minimum security architecture baseline. Another example of high level policy is the IT Risk Management Standard that defines a Risk Management process.
 
List 4.5 shows a partial list of the layered policies within the security architecture domain.
  • IT Risk Management Standard
  • Change Management Policy
  • Incident Response Policy
  • Encryption Standard
  • IT Disaster Recovery Planning Policy
  • IT Physical Security Standard
 
Note: The policy infrastructure of an organization directly reflects the unique mission and business objectives of the organization. The above list is for educational purposes only.
 
There are many policies within the security architecture domain that govern a Terminal Server environment. Security controls, such as physical and environmental policies, encryption standards, authentication, authorization, Anti-Virus Guidelines, server hardening, and so forth, are applied to Terminal Servers via the security architecture domain policy infrastructure.
 
The next two examples introduce a tier 3 Terminal Server Anti-Virus Software Guideline, followed by a tier 2 Change Management Policy. These examples illustrate the relationship between the security architecture domain’s layered policy infrastructure and Terminal Server.
 
Even with the most state of the art content filtering system, firewall, and proxy server rules, viruses find their way into the environment. Anti-virus software is a necessity in contemporary computing environments in order to protect hosts from malware and to meet legal and regulatory mandates.
 
Anti-virus software scans active processes in memory and files while comparing them against a database of known signatures. Most anti-virus solutions protect against all three types of malware - spyware, spam and viruses. Unfortunately, the protection is only as good as the signature database which must be kept up to date to detect the latest types of malware.
 
This guideline is intended for informational purposes only.
 
Terminal Server Anti-virus Software Guidelines
The following list introduces guidelines to acquire, implement and configure anti-virus software on Terminal Server:
  • Select an anti-virus solution that enables updated signatures to be pulled from an internal source. This provides an opportunity to validate new signatures in a lab before deploying them into production.