Trusted Facility Manual - v2.3.3

TRUSTED FACILITY MANUAL v2.
3
EFTPS – December, 2009
Signature Approvals
NOTE: Signatures verify the activation of policy and procedures outlined within this document.
Division President, Government, Education and Healthcare (John DATE

Reynolds)
VP and General Manager, LINK2GOV (Holly Huggins) DATE
Tax Program Manager, LINK2GOV (Helen Justice) DATE

Document History
As specified in IRS Required Documentation, all LINK2GOV audit documents contain the
information listed below:
Management Commitment
Signature Approvals on the preceding page indicate that Management has reviewed and
endorsed—and will fully support—the content expressed within this document.
Document Changes
At a minimum, this document is updated annually, although interim changes in policy or

procedure may require more frequent updates.
DATE + VERSION PAGE(S) CHANGE DESCRIPTION EDITOR(S)

December 8, 2009 61-62 Changed procedures for reinstating a user’s Dan Bachrach,
logon permission Michael Meinolf,
V2.3
Jennifer Wendell
November 25, 25, 55, Changed Media Handling Guidelines to Media Dan Bachrach,
2009 69, 70, Handling Procedures to better reflect Michael Meinolf,
74 LINK2GOV processes, updated environmental Jennifer Wendell
V2.2
controls, added session lock procedures,
removed reference to OS documentation.
November 13, 14, 15, Added detail about location of Information Dan Bachrach,
2009 25, 24, System components, supply chain protection, Michael Meinolf,
71 media/ hardware components disposal, Jennifer Wendell
V2.1
removed reference to PE-016 evidence folder,
added media marking guidelines, details of
physical access controls, maintenance call
details, numerous additional procedures.
August 21, 2009 12, 13, Added reference to proof of tamper-evident Dan Bachrach,
14, 30- packaging for software, PCI accreditation, ISAs Jennifer Leonard,
V2.0
31, 34, 81 and MOUs, spam-filtering software, substitute Jennifer Wendell
IS components, vulnerability scanning,
additional appendixes
March 16,2009 36-40; Inserted procedures for authentication Gary Eeds
42-44; management, including user accounts and
V1.9
48-50 passwords. Inserted procedures for configuring
machines with policy for identifying and
authenticating devices. Inserted procedures for
configuring new VoIP machines (phones and
IVR applications).
March 9, 2009 16 Clarified IVR equipment located in main Gary Eeds
processing facility
V1.8
February 23, 2009 66 Added cryptographic key management Steve Ross,
EFTPS – LINK2GOV CONFIDENTIAL December 8, 2009 Page 2 of 96

DATE + VERSION PAGE(S) CHANGE DESCRIPTION EDITOR(S)
V1.7 procedures. Jennifer Wendell
January 30, 2009 28, 41, Added several detailed procedures Steve Ross,
42, Jennifer Wendell
V1.6
January 14, 2009 53 Added section 5.2.5 to address Cardholder Steve Ross
Information Retention procedures.
V1.5
December 30, 56-62 Added detail to System Integrity Checking Steve Ross
2008 section to include steps for setting monitors for
integrity checking.
V1.4
December 19, 11-14, Additional changes made per SAIC review. Steve Ross,
2008 21, 22- Jennifer Wendell
23, 29,
V1.3
55
December 9, 2008 ALL Additional changes made per SAIC review (see Steve Ross,
POA&M in APPENDIXES folder) Jennifer Wendell
V1.2
September 18, ALL Changes made per IRS review. Steve Ross,
2008 Jennifer Wendell
V1.1
August 22, 2008 ALL Format revised to follow NIST guidelines, Jennifer Wendell
improve readability, and visually distinguish
V1.0
from previous versions.
Distribution
Once any updates have been approved, an electronic version of this document are distributed
via e-mail to the following persons:
DEPARTMENT TITLE NAME E-MAIL ADDRESS

MANAGEMENT Division President John Reynolds john.reynolds@metavante.com
VP & General Manager Holly Huggins hhuggins@LINK2GOV.com
CUSTOMER Tax Program Manager Helen Justice hjustice@LINK2GOV.com

SUPPORT
IRS Business Analyst John Chesnut jchesnut@LINK2GOV.com
DATABASE Database Team David dbuckingham@LINK2GOV.com

SERVICES Manager Buckingham
DEVELOPMENT Manager of Tax Dustin Jones djones@LINK2GOV.com
Solutions
INFRASTRUCTURE Manager, Infrastructure Mike Meinolf michael.meinolf@metavante.com
SERVICES QA
This document is additionally stored in an IT DOCUMENTATION LIBRARY on LINK2GOV’s

Intranet SharePoint site (@ http://LINK2GOVsp/sites/LINK2GOVPolicy ), which can be readily

accessed—given the appropriate permissions—by LINK2GOV management from all site
locations.
Should this online location not be available, backup copies are stored in a locked file cabinet at
LINK2GOV Corporate Headquarters in Nashville, TN, and are available by request.
References
All supporting government documentation is located within LINK2GOV’s APPENDIXES folder. If

government regulatory documents are published online, links are also provided to those Web
sites (see Government Sources).
This document additionally follows guidelines provided by:
The Office of Management and Budget (OMB) Circular No. A-130, Appendix III: Security of
Federal Automated Information Resources
National Computer Security Center (NCSC) TG-015, Guide to Understanding Trusted Facility
Management, June 1989
National Computer Security Center (NCSC) TG-016, Guidelines for Writing Trusted Facility
Manuals, October 1992.
NOTE: LINK2GOV’s’s Trusted Facility Manual follows the outline of this document—in
particular Section 7.2, Requirements and Recommendations for Security Class C2.
National Computer Security Center (NCSC) NCSC-TG-013-89, Rating Maintenance Phase

Program, 23 June, 1989.

CONTENT
REFERENCES ................................................................................................................... 4
1.0 INTRODUCTION ............................................................................................. 12
1.1 PURPOSE ........................................................................................................ 12
1.2 SCOPE AND CONTENTS ...................................................................................... 13
1.3 CONTROL OBJECTIVES ....................................................................................... 13

1.3.1 System Protection Controls .............................................................................. 13
1.3.2 Communication Protection Controls ................................................................. 16
1.4 TFM INTRODUCTION .......................................................................................... 17

1.4.1 Scope.............................................................................................................. 17
1.4.2 Recommended Use of the Manual .................................................................... 20
1.4.3 TFM Contents.................................................................................................. 22
1.4.4 User-Based Collaboration and Information Sharing........................................... 22
2.0 SYSTEM SECURITY OVERVIEW ...................................................................... 23
SYSTEM DESCRIPTION..................................................................................................... 23
PHYSICAL ACCESS CONTROLS .......................................................................................... 24
ENVIRONMENTAL CONTROLS........................................................................................... 25
CHANGE MANAGEMENT .................................................................................................. 26
2.1 THREATS TO SYSTEM SECURITY .......................................................................... 26
2.2 SECURITY COUNTERMEASURES............................................................................27

2.2.1 Functional Security Coordinator ....................................................................... 30
2.2.2 SQL Security Settings...................................................................................... 30
2.2.3 Audit Mechanisms ........................................................................................... 31
2.2.4 Application Software Maintenance Controls ..................................................... 32
2.2.5 Mobile Code Restrictions.................................................................................. 32
2.2.6 Personnel Security Clearances ......................................................................... 33
2.2.7 Off-Premises Storage of Electronic Media ......................................................... 33
2.2.8 System Backup Procedures .............................................................................. 33

2.2.9 Virus Countermeasures .................................................................................... 33
2.2.10 Incident Reporting ......................................................................................... 34
2.2.11 Vulnerability Scanning ................................................................................... 34
2.2.12 Honey Pots ................................................................................................... 35
2.3 EXPLICIT PHYSICAL SECURITY ASSUMPTIONS .........................................................35

2.3.1 System Designer Assumptions......................................................................... 36
2.4 PROTECTION MECHANISMS AVAILABLE TO ADMINISTRATIVE USERS ......................... 36

2.4.1 Processing Information .................................................................................... 36
2.4.2 Storing Information......................................................................................... 36
2.4.3 Transmitting Information ................................................................................ 37
2.4.4 User Authentication/Access Control ................................................................. 37
2.4.5 Handling Output ............................................................................................ 40
2.5 SECURITY VULNERABILITIES AND WARNINGS ........................................................ 41
2.6 SEPARATION OF ADMINISTRATIVE ROLES ............................................................. 42
3.0 SECURITY POLICY .......................................................................................... 44
3.1 DISCRETIONARY ACCESS CONTROL ..................................................................... 44

3.1.1 Initialize DAC Privileges and Defaults ............................................................... 44
3.1.2 Distribute, Review and Revoke User Privileges................................................... 44
3.1.3 Group Membership Definition and Impact ......................................................... 45
3.1.4 Change, Restoration, and Destruction Process .................................................. 45
3.1.5 Concurrent Login Control ................................................................................. 45
3.2 MANDATORY ACCESS CONTROL ......................................................................... 45
3.3 MANAGEMENT OF USER ACCOUNTS .................................................................... 45

3.3.1 Establishing Accounts ...................................................................................... 49
3.3.2 Activating Accounts......................................................................................... 49
3.3.3 Modifying Accounts ......................................................................................... 49
3.3.4 Reviewing Accounts ......................................................................................... 49
3.3.5 Disabling Accounts .......................................................................................... 49
3.3.6 Removing/Deleting Accounts ........................................................................... 50
3.4 COMMAND, SYSTEM CALL AND FUNCTION DEFINITIONS ......................................... 50

3.4.1 Effects and Exceptions .................................................................................... 50
3.4.2 Parameter and Default Settings ...................................................................... 50
3.4.3 Examples of Command Use and Potential Misuse ............................................. 50
3.4.4 Domain Name Resolution ................................................................................ 50
3.5 SPECIFIC VULNERABILITIES ..................................................................................51

3.5.1 DoS Attacks ................................................................................................... 51
3.5.2 VoIP Attacks ................................................................................................... 51
3.5.3 Network Interconnection Policy ........................................................................ 53
4.0 ACCOUNTABILITY ........................................................................................... 54
4.1 IDENTIFICATION AND AUTHENTICATION................................................................ 54

4.1.1 TCB Commands and Interfaces........................................................................ 54
4.1.2 Password Management .................................................................................. 54
4.1.3 Account Restrictions ....................................................................................... 54
4.1.4 Choice of User or Group Identifiers ................................................................... 57
4.1.5 Maximum Levels of Trust for Users and Groups ................................................. 57
4.1.6 Level of Trust Requirements ............................................................................ 59
4.1.7 Device Authorization ....................................................................................... 59
4.1.8 System Output Naming Conventions ............................................................... 61
4.1.9 Information Labeling ....................................................................................... 61
4.1.10 Remote Access Management ......................................................................... 61
4.1.11 Wireless Technologies .................................................................................... 62
4.1.12 Mobile and/or Portable Devices ...................................................................... 62
4.2 DEFINITION AND CHANGE OF SYSTEM PARAMETERS OF THE LOGON MECHANISM....... 62

4.2.1 Time-out Intervals .......................................................................................... 62
4.2.2 Multiple Logon Attributes ............................................................................... 63
4.2.3 Maximum Logon Time .................................................................................... 63
4.2.4 Limits on Unsuccessful Logons ........................................................................ 63
4.2.5 Use of Special Trusted Path Mechanisms for Administrative Users ..................... 63
4.2.6 Dormant Accounts .......................................................................................... 64
4.2.7 Account Correlation Review ............................................................................ 64
4.3 AUDIT MECHANISMS ......................................................................................... 64

4.3.1 Audit-Event Selection Mechanisms .................................................................. 64
4.3.2 Management/Review of Audit Logs ................................................................. 64
4.3.4 Functions for Formatting, Compressing, and Post-Processing of Audit Files ........ 65
4.3.5 Interfaces for Setting of Covert Channel Delays and Randomization of Variables65
4.3.5 Description of Audit Log and Event Formats ..................................................... 65
4.4 COMMANDS, SYSTEM CALLS, AND FUNCTION DEFINITION ...................................... 66
4.5 SPECIFIC VULNERABILITIES ................................................................................. 67
5.0 ROUTINE OPERATIONS.................................................................................. 68
MAINTENANCE PROCEDURES ........................................................................................... 68

Analyzing System Logs after Crashes ........................................................................... 68
Conducting Crash-Recovery and Restart Actions ........................................................... 68
Changing System Configuration Parameters................................................................. 68
Anticipating Predictable Component Failures ................................................................ 68
Changing Hardware Components ................................................................................. 69
Running Periodic System Integrity Checks .................................................................... 69
Maintenance/Repair of Damaged Volumes ................................................................... 71
5.1 SECURITY-RELEVANT PROCEDURES AND OPERATIONS ............................................ 71

5.1.1 Running of System Diagnostics ....................................................................... 71
5.1.2 System Boot and Shutdown ............................................................................ 71
5.1.3 Setting of System Clocks ................................................................................. 72
5.1.4 Identification of Damaged User Files and Volumes ........................................... 76
5.1.5 Routine Backup of TCB Files ............................................................................. 76
5.1.6 Online Device Testing ..................................................................................... 77
5.1.7 Response to User Requests to Mount/Un-Mount Tapes ..................................... 77
5.1.8 Handling of Peripheral Devices, Removable Storage, and Output....................... 77
5.2 SECURITY-IRRELEVANT PROCEDURES AND OPERATIONS ........................................ 80

5.2.1 Backup of User Volumes .................................................................................. 80
5.2.2 System Metering ............................................................................................ 80
5.2.3 Response to User Requests .............................................................................. 80
5.2.4 User Account Administration .......................................................................... 81
5.2.5 Cardholder Information Retention.................................................................... 81

5.3 COMMANDS, SYSTEM CALLS AND FUNCTION DEFINITIONS ..................................... 81
5.3.1 Effects and Exceptions of Commands Used for Routine Operations ................... 81
5.3.2 Parameter and Default Settings ...................................................................... 82
5.3.3 Examples of Use and Potential Misuse ............................................................. 83
5.4 WARNING OF SPECIFIC SECURITY VULNERABILITIES OF ROUTINE OPERATIONS ........... 83
6.0 SECURITY OF THE TCB (TRUSTED COMPUTING BASELINE) ......................... 84
6.1 GENERATION OF THE TCB SOURCE CODE............................................................. 84

6.1.1 TCB Code Modules, Module Interface and Data ................................................. 84
6.1.2 Approved Tools for TCB Generation .................................................................. 84
6.1.3 Procedures for TCB Generation ........................................................................ 84
6.1.4 Vulnerabilities ................................................................................................. 84
6.2 CONFIGURATION MANAGEMENT POLICY .............................................................. 84
6.3 RATINGS MAINTENANCE PLAN ........................................................................... 84
6.4 TCB INSTALLATION PROCEDURE ........................................................................ 84

6.4.1 TCB Generation from Source Code ................................................................... 84
6.4.2 TCB Hardware Installation .............................................................................. 84
6.4.3 TCB Data Structure Initialization...................................................................... 85
6.4.4 TCB Loading ................................................................................................... 85
6.4.5 Setting of TCB File Protection .......................................................................... 85
6.4.6 Approved Tools ............................................................................................... 85
6.5 TCB MAINTENANCE PROCEDURES ...................................................................... 85

6.5.1 Analysis of System Dumps ............................................................................... 85
6.5.2 Crash Recovery and Restart ............................................................................. 85
6.5.3 Changes of Configuration Parameters .............................................................. 85
6.5.4 Repair of Damaged TCB Data Structures .......................................................... 85
6.5.5 Consistency-Checking Procedures .................................................................... 86
6.5.6 Running of Periodic System Information Integrity Checking ............................... 86
6.5.7 Setting up System Information Integrity Checking ............................................. 86
6.6 TRUSTED DISTRIBUTION OF THE TCB ................................................................... 90

6.6.1 Policies and Procedures ................................................................................... 90

6.6.2 Correspondence between Master Copy and Installed Copy ................................ 90
6.7 COMMANDS, SYSTEM CALLS, AND FUNCTION DEFINITIONS .................................... 90

6.7.1 Effects and Exceptions ..................................................................................... 91
6.7.2 Parameter and Default Settings ....................................................................... 91
6.7.3 Examples of Use and Potential Misuse .............................................................. 91
6.8 WARNINGS OF SPECIFIC SECURITY VULNERABILITIES .............................................. 91
7.0 SATISFYING TCSEC REQUIREMENTS ............................................................. 92
7.1 CLASS C1 APPLICATION ..................................................................................... 92
7.2 CLASS C2 APPLICATION..................................................................................... 92

7.2.1 TFM Introduction ............................................................................................. 92
7.2.2 System Security Overview ............................................................................... 92
7.2.3 Security Policy ................................................................................................. 92
7.2.4 Audit .............................................................................................................. 92
7.2.5 Routine Operations.......................................................................................... 92
7.2.6 Security of the TCB .......................................................................................... 92
8.0 TELECOMMUNICATIONS................................................................................... 93
8.1 NETWORK PROTOCOLS..................................................................................... 93
8.2 NETWORK PORTS ............................................................................................ 93
8.3 NETWORK ADDRESSES ...................................................................................... 93
9.0 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................. 95
TO RENEW A CERTIFICATE: ............................................................................................... 95
APPENDIXES ............................................................................................................... 96
EQUIPMENT AND SPECIFICATIONS ...................................................................................... 96
GLOSSARY..................................................................................................................... 96
GOVERNMENT SOURCES .................................................................................................. 96
NETCORDIA EVENT SUMMARY ........................................................................................... 96

NEW HIRE ACCESS REQUEST ............................................................................................. 96
PCI ACCEPTANCE LETTER ................................................................................................. 96
RETINA VULNERABILITY SCANS (3) ..................................................................................... 96
RISK ASSESSMENT REPORT............................................................................................... 96
SECURITY ACTIVITIES CHECKLIST ........................................................................................ 96
SECURITY TRAINING – COMPLIANCE ................................................................................... 96
TRUSTKEEPER COMPLIANCE REPORT .................................................................................. 96
USING REMEDY .............................................................................................................. 96
POLICIES .................................................................................................................... 96
Access Control............................................................................................................. 96
Change Advisory Board ............................................................................................... 96
Corporate Office Access ............................................................................................... 96
Cryptographic Key Management .................................................................................. 96
Identification and Authentication ................................................................................. 96
Information Sensitivity and Retention .......................................................................... 96
Mobile Communications .............................................................................................. 96
Network Interconnection ............................................................................................. 96
Physical and Environmental Protection ........................................................................ 96
Public Key Infrastructure (PKI) (4) ................................................................................. 96
Remote Access ............................................................................................................ 96
Wireless Communication ............................................................................................. 96

1.0 Introduction
The Office of Management and Budget (OMB) Circular No. A-130, Appendix III: Security of
Federal Automated Information Resources requires agencies to secure their systems
commensurate with the risk and magnitude of loss or harm that could result from loss, misuse,
or unauthorized access to information contained in those systems. This includes assuring that
systems and applications used by the service operate effectively and provide appropriate
confidentiality, integrity, and availability controls.
LINK2GOV’s IRS Electronic Filer Tax Payment System (EFTPS) is a Class C2 database
application that adheres to the controls outlined in the reference cited above (see Section 13 of
LINK2GOV’s System Security Plan). The system was placed in production in January 2003 and is a
proven product. The IRS uses the EFTPS to accept electronic tax payments (both individual and
small business tax returns) and deliver the results to the Bank of America.
Guiding principles for the EFTPS are to:

Minimize taxpayer burden as data is collected.
Ensure that the collected data meets business objectives and is used as a corporate asset.
1.1 Purpose
LINK2GOV’s Trusted Facility Manual (TFM) supplements vendor-supplied, commercial off-the-

shelf (COTS) documentation and provides specific information that enables EFTPS System
Administrators (SAs) and Database Administrators (DBAs) to:
1. Configure and install the EFTPS.
2. Operate the EFTPS in a secure manner.
3. Make effective use of system privileges and protection mechanisms to control access to
administrative functions and databases.
4. Avoid risks and improper use of administrative functions that would compromise the
Trusted Computing Base (TCB) and user security.
Additionally, this manual provides guidance for:

Configuration of EFTPS servers (see also LINK2GOV’s Configuration Management Plan).
Consequences of the misuse of administrative functions, procedures, privileges, and

databases.

1.2 Scope and Contents
As stated in the NCSC’s Guidelines for Writing Trusted Facility Manuals, LINK2GOV’s Trusted
Facility Manual (TFM) gives specific guidance to administrative users on how to configure, install,
and operate a secure computer system, and illustrates the intended use of all security features,
citing actual system commands and procedures.
LINK2GOV’s SSA and DBAs have experience using MS SQL 2000, 2005 setup parameters,
registry settings, network configurations, domain configurations, user account/rights policy
configurations, environmental group profile settings, and service pack/hot fix implementation
procedures (as applicable).
LINK2GOV’s administrative personnel are also familiar with the concept of trusted systems,
and the critical importance of system confidentiality, integrity, and availability.
This manual is not intended to replace a coordinated training and security awareness plan. Such
a plan has been developed and is maintained as a separate document (see LINK2GOV’s Security
Features Users Guide).
1.3 Control Objectives
1.3.1 System Protection Controls
The following system protection controls are adhered to by LINK2GOV:

Configure and install a specific secure system -
1. Research all possible configuration options and submit recommendations to

LINK2GOV’s Change Advisory Board before initiating a purchase:
a. Download and evaluate all best practice guides available on the Internet (NIST,
manufacturer’s guidelines, CERT.org. SANS.org).
b. Research and analyze any known issues of compatibility for desired
configuration.
c. Open a Remedy Ticket outlining findings and requesting purchase approval
(see Using Remedy in LINK2GOV’s IT DOCUMENTATION LIBRARY on internal
SharePoint site @ http://l2gsp/sites/L2GPolicy/default.aspx).
2. Order only from trusted and accredited, government- and corporate-approved
vendors.*
a. Contact vendors for showcases or demos.

b. Request quotes to determine best value for configuration solution.
c. Evaluate and implement security standards for all software and hardware
deliverables (such as use of tamper-evident packaging for all software, per

NIST security requirement SI-007)
* NOTE: Per executive order, all companies doing work for the US government and government
organizations must comply with FIPS-140-2. All of LINK2GOV’s purchases comply with this
directive.
3. Per NIST requirement PE-018, install the information system in a location adhering to
industry standards (e.g. restricted access and cooling requirements) and the procedures
specified.
a. Use ‘best practice’ guides (see Step 1.a above).
4. Provide substitute Information System components when needed, and a mechanism to

exchange active and standby roles of the components, for example firewalls with high-
availability, IPSs, primary and secondary databases, Web farms, NetScalers, Cisco ASA
firewalls, MSCS-based SQL Servers, HBA’s with dual paths, teamed NIC’s in failover
mode, RAID-based storage with automatic hot spares.
5. By policy, LINK2GOV does not utilize centralized computing/”thin nodes”. To mitigate

for this policy, LINK2GOV employs firewalls at all ingress/egress points leading to the
Internet, as well as IPS/IDS. These components are further backed-up by the use of both
anti-virus and HIPS on all machines located on the network.
Operate the system in a secure manner -
1. To support the control of information flow to and from external information systems,
utilize the following control mechanisms:
a. VLANs (for segregating system subnets)
b. Access control lists (for controlling user and computer authorization)
c. Firewalls (for supporting ‘least functionality’ of information flow)
d. Intrusion Prevention Systems (IPS) devices (for identifying and mitigating potential
threats and/or attacks—LINK2GOV utilizes Proventia for this purpose).
For further detail, see LINK2GOV’s Network Interconnection policy in LINK2GOV’s IT

DOCUMENTATION LIBRARY on internal SharePoint site @
http://l2gsp/sites/L2GPolicy/default.aspx).
2. Do not allow the use of peripheral devices without management and SSA approval.
3. Conduct continuous audit logging.
4. Utilize NetMRI for centralized log consolidation and reporting.
6. All changes must go through the Change Advisory Board (see Change Advisory Board
policy in LINK2GOV’s IT DOCUMENTATION LIBRARY on internal SharePoint site @

7. Conduct risk assessments on an annual basis (see the Risk Assessment Plan in
LINK2GOV’s IT DOCUMENTATION LIBRARY on internal SharePoint site @
8. To ensure compliance with industry standards:
a. Maintain certification and accreditation by recognized institutional authorities (PCI-

SSC, e.g.— see PCI Acceptance Letter in the APPENDIXES folder).
b. Conduct monthly external vulnerability scans utilizing TrustKeeper.net to support

compliance and credibility.
Practice supply chain protection measures –
In accordance with NIST requirement SA-012, Supply Chain Protection, LINK2GOV
Employs anonymous acquisition processes.
Purchases all anticipated information system components and spares in the initial
acquisition.
Conducts a due diligence review of suppliers prior to entering into contractual

agreements to acquire information system hardware, software, firmware, or services.
Uses trusted shipping and warehousing for information systems, information system
components, and information technology products.
Employs a diverse set of suppliers for information systems, information system

components, information technology products, and information system services.
Employs standard configurations for information systems, information system

components, and information technology products.
Minimizes the time between purchase decisions and delivery of information systems,
information system components, and information technology products.
Employs independent analysis and penetration testing against delivered information

systems, information system components, and information technology products.
Avoid pitfalls and improper use of administrative functions that would compromise system
and user security -
1. Allow only documented authorized users to access the system.
a. Utilize Active Directory as the standard control mechanism.
b. Utilize the following control mechanisms:

i. VLANs (for segregating system subnets)
ii. Access control lists (for controlling user and computer authorization)
iii. Firewalls (for supporting ‘least functionality’ of information flow)
iv. Intrusion Prevention Systems (IPS) devices (for identifying and mitigating
potential threats and/or attacks)
v. CISCO Security Agent on all networks (for host-based intrusion

prevention).
vi. For further detail, see LINK2GOV’s Network Interconnection policy in

LINK2GOV’s DOCUMENTATION LIBRARY on internal SharePoint site @
2. Maintain separation of duties by functional area:
a. Evaluate and analyze risk positions on an annual basis (see LINK2GOV’s Position
Risk Assessment policy in LINK2GOV’s IT DOCUMENTATION LIBRARY @
3. Do not allow the use of mobile code unless specifically approved by the Systems
Security Administrator and installed by the Systems Administrator:
a. See LINK2GOV’s Mobile Code policy in the IT DOCUMENTATION LIBRARY on

LINK2GOV’s internal SharePoint site @ http://l2gsp/sites/L2GPolicy/default.aspx).
1.3.2 Communication Protection Controls
LINK2GOV has formalized its support of communications protection via the company’s Media
Handling Guidelines (see section 5.1.8, p. 75), as well as Information Sensitivity and Retention and
Network Interconnection policy and procedures (see LINK2GOV’s IT DOCUMENTATION LIBRARY
on the company’s internal SharePoint site @ http://l2gsp/sites/L2GPolicy/default.aspx).
As specified by NIST security control requirement CA-003 and Special Publication 800-47,
Security Guide for Interconnecting Information Security Systems, beginning in 2009 LINK2GOV will also
require any affiliated third parties to read and comply with an Interconnection Security Agreement
(ISA) and Memorandum of Understanding (MOU).
Per NIST requirement SI-008, LINK2GOV employs MxLogic spam filtering software together
with Exchange (central email server) to detect and take action on unsolicited messages
transported by electronic mail, electronic mail attachments, web accesses, or other common
means, and updates spam protection mechanisms (including signature definitions) when new
releases are available..

1.4 TFM Introduction
1.4.1 Scope
LINK2GOV’s Trusted Facility Manual provides a guide to EFTPS configuration, operation,

privileges and protection mechanisms, and warnings about possible misuse of administrative
authority, as follows:
SYSTEM CONFIGURATION
Hardware items for the EFTPS are standard Commercial Off-The-Shelf (COTS)-based
components and work in a standard operational office environment. There are no special cooling
or electrical requirements. No extraordinary security requirements are utilized for controlling
access to these components.
The EFTPS is configured as illustrated below:

SYSTEM OPERATION
The EFTPS operating environment consists of the following components:
Applications/Systems
The EFTPS application is a suite of Visual Dot Net program(s) Web applications running on IIS 6.0
on MS Windows Server 2003. IVR applications are hosted on the Interactive Intelligence (I3)
platform running on two IVR servers located in the primary EFTPS facility. The application
interfaces with MS Sql 2000 and MS SQL 2005 as application DB servers. The hardware is HP
Proliant servers operating in a 1Gb Ethernet-switched environment. All systems are protected by
redundant Cisco Pix Firewalls, IDS and Cisco Security Agent (CSA) intrusion preventions system.
Equipment Required for Processing
For the Atlanta alternate site, the minimal equipment required for processing includes 1 Web
Server, 1 MS SQL Db Server, 1 Ethernet Switch, 1 Cisco Pix Firewall and 1 Cisco 2600 Series
Router. No particular brand of hardware is required. The hardware must be able to support the
MS Windows 2000 or 2003 operating systems.
For the Brown Deer alternate site, the minimal equipment required for processing includes 2
Telephony Gateway Servers , 1 SIP Proxy Server, 1 IVR Server, 1 MS SQL Db Server, 1 Domain
Controller, 1 Ethernet Switch, 1 Cisco Pix Firewall and 1 Cisco 2600 series router. No particular
brand of hardware is required. The hardware must be able to support the MS Windows 2000 or
2003 operating systems.
Further detail is provided in LINK2GOV’s Configuration Management Plan.

.Net Components and Web Services
LINK2GOV’s IVR application leverages Web services to communicate tax payer data from its
interface to the tax payment processor component. LINK2GOV’s Web interface communicates
with the tax payment processor component directly. The tax payment processor component
interfaces with the payment component to process tax payments for the EFTPS application. In
addition, .Net components are utilized for the file processing system.
Development Tools
Microsoft Visual Studio.Net, Microsoft SQL Server 2000 and SQL 2005, and IIS.
Hardware and Facilities Information
See LINK2GOV’s Disaster Recovery Plan, as well as Equipment and Specifications in the
APPENDIXES folder.
SYSTEM PRIVILEGES AND PROTECTION MECHANISMS
Primary system privileges and protection mechanisms are provided for the EFTPS through
Microsoft’s Active Directory. LINK2GOV’s network provides additional limited mechanisms.
Baseline security protection within the system is set to include User IDentification (USERID),
password, and audit trails. The EFTPS’ host platform provides for resource isolation, object
reuse, and full system backups.
LINK2GOV’s System Security Administrator (SSA) defines access for all users on a user-by-user
basis, and can additionally define when users may log on (i.e., by date, time, physical location,
and authentication mechanism). Password complexity and expiration is set via group policy (see
LINK2GOV’s Security Features Users Guide).
In addition to password protection, the system does not allow users to access all menu
commands. Access is only permitted based on the employee’s delegated responsibilities (in
accordance with LINK2GOV’s ‘separation of duties’ policy (see also New Hire Access Request
form in the APPENDIXES folder). User accounts are deleted from the system when users no
longer require access to the EFTPS.
Warning screens are displayed at initial logon to inform users that the system belongs to the
LINK2GOV, is for authorized users only, and that unauthorized access is punishable by law.
All LINK2GOV maintenance procedures are directed and implemented by LINK2GOV’s affected
functional area.
MISUSE OF ADMINISTRATIVE AUTHORITY
Failure to implement protection mechanisms and procedures may result in a loss of controlled

access to sensitive information and systems. This loss of control could lead to unauthorized
access or modification of sensitive data or software, which in turn could lead to:
Denial of service due to unauthorized modifications or deletions of system software,
controls, accounts, or profiles;
Introduction of unauthorized, incompatible, or malicious software; and
Unauthorized disclosure or modification of information from unauthorized direct or indirect

access to system and user objects.
A potential for misuse of authority exists due to access levels and permissions granted to
administrative users. Because this group of users has the ability to bypass system security
mechanisms, it is necessary for them to conscientiously follow all applicable guidelines in
performance of their duties.
LINK2GOV’s SSA, DBAs, and developers are assigned administrative privileges on the Operating
System, and have the authority to:
Update and execute security parameters
Monitor signed-on users
Update and delete user records
Create and modify system procedures, schedules, and exceptions
Perform database backups
Reset hardware resources
Record system announcements
Print activity logs
View maintenance records
View database tables
All of the above administrative and security-level access functions are audited and reviewed on a
regular basis. This allows activities to be monitored for compliance and to detect any trends
indicating misuse, so that corrective actions can immediately be taken to prevent any negative
impact.
1.4.2 Recommended Use of the Manual
LINK2GOV’s Trusted Facility Manual is intended for the use of EFTPS administrative personnel,
including the System Security Administrator (SSA) and DBAs.

SKILLS AND SYSTEMS BACKGROUND OF ADMINISTRATIVE PERSONNEL
All LINK2GOV administrative personnel are familiar with the concept of trusted systems as it
pertains to confidentiality, integrity, and availability. LINK2GOV’s SSA is trained in security
compliance best practices and techniques; DBAs are trained in SQL 2000 and 2005 database
administration, as well as security compliance best practices and techniques.
LINK2GOV employees are encouraged to establish and maintain contact with special interest
groups, specialized forums, professional associations, news groups, and/or peer groups of
security professionals in similar organizations to stay up to date with the latest recommended
security practices, techniques and technologies, and to share the latest security-related
information including threats, vulnerabilities, and incidents.
In support of this form of continuing education, LINK2GOV will reimburse its employees for the
cost of professional association memberships or training, if those memberships are deemed
relevant to the employee’s job function.
To request any type of professional group membership or training, LINK2GOV administrators

should first consult with their functional manager. The manager will in turn:
Evaluate the benefits of membership or relevance of requested training (group vs.
individual, for example)
Determine if budget allows for cost of membership dues or training
If approved, process request through the appropriate channels (Concur, LINK2GOV’s

expense report tool, or via issuing a Purchase Order).
ADDITIONAL SUPPORT DOCUMENTATION
Other system manuals that may be consulted by the administrative staff for guidance on how to
operate the system in a secure manner include:
LINK2GOV’s Configuration Management Plan for system configuration.
LINK2GOV’s Security Features Users Guide for security-related policy and procedures.
LINK2GOV’s System Development Life Cycle for development security components and
administrative roles and responsibilities.
LINK2GOV’s System Security Plan for security-related controls.
For troubleshooting database issues, administrative personnel may additionally consult:
Inside Microsoft® SQL Server™ 2000
Microsoft ® SQL Server ™ Administrators Companion
Microsoft® SQL Server™ 2000 Reference Library

Security-related topics addressed by the National Institute for Standards and Technology (NIST)
may also be reviewed. For further detail, see the References section at the beginning of this
document, plus Government Sources in the APPENDIXES folder.
LIMITATIONS
The security features described in this document pertain primarily to the EFTPS host Operating
System. Other LINK2GOV applications or operating platforms are not collectively addressed by
this document.
1.4.3 TFM Contents
Following the outline of the NCSC’s Guidelines for Writing Trusted Facility Manuals, the contents
of LINK2GOV’s TFM include sections that address a System Security Overview (Section 2),
Security Policy (Section 3), Accountability (Section 4), Routine Operations (Section 5), Security of
the TCB (Section 6), and finally, one addressing Satisfying the TCSEC Requirements (Section 7).
1.4.4 User-Based Collaboration and Information Sharing
This document is available—along with many others pertinent to LINK2GOV operations—on the
company’s Intranet SharePoint site @ http://l2gsp/sites/L2GPolicy/default.aspx .

2.0 System Security Overview
The purpose of this section of the Trusted Facility Manual (TFM) is to define the security and
accountability policies and mechanisms of the system that are designed to counter a set of
perceived threats. The focus of this section is on the administrative-user functions available to
counter threats, the privileges and protection mechanisms available to administrative users, and
the general vulnerabilities associated with actions of administrative users. This section should
also include a list of dependencies on other security measures, such as those for the
maintenance of physical security, which, although not required by the TCSEC, are taken into
account by system installation management and by system accreditation.
In keeping with NIST security control specification RA-005, LINK2GOV:
Attempts to discern what information about the EFTPS is discoverable by adversaries.
Performs security testing to determine the level of difficulty in circumventing the security
controls of the system.
Employs automated mechanisms to compare the results of vulnerability scans over time to
determine trends in system vulnerabilities.
Testing methods include penetration testing, malicious user testing, and independent
verification and validation (IV&V). Testing methods are approved by authorizing officials in
coordination with the organization’s Risk Executive function.
System Description
The EFTPS is an Information System developed by LINK2GOV incorporating COTS products.

Microsoft Windows Server 2003 and SQL 2000, 2005, and physical security controls in place at all
LINK2GOV facilities provide access control for the system.
LINK2GOV’s EFTPS-dedicated server supports user identification and passwords. The use of
proper OS settings allows for operation at the C2 level. The EFTPS has no attachment to the IRS’
internal network configuration and therefore has no effect on IRS security.
LINK2GOV’s system security structure consists of several layers of safeguards:

OS access controls and auditing features incorporating:
Object Reuse
Identification and Authentication (I&A)
Discretionary Access Control (DAC)
Audit (User, File, Printer)

Microsoft’s Active Directory domain logon with password and option permissions
(includes components that control object access, the selection of audited events, and
memory reuse).
Microsoft’s Active Directory drives user identification, password verification, access control,
volume restrictions and user rights. Parameters can be set for identification of a user attempting
to access unauthorized resources.
Audit logs also provide the capability to audit information when changes, deletions, and
additions occur. Windows 2003 auditing is enabled via Group Policy on the Domain Controller.
LINK2GOV’s System Security Administrator (SSA) creates a standard set of access profiles
depending on each user’s level of authorized access, which the employee is assigned before
accessing the EFTPS.
EFTPS user community categories are:

System Administrator
DBA
Development personnel
Data protection objectives for user authorization requirements and constraints are to:
Protect data from unauthorized access.
Protect data from unauthorized, unanticipated, or unintentional modification.
Ensure data availability on a timely basis.
EFTPS documentation and controls are used to describe the hardware, software, policies,
standards, and procedures related to EFTPS security. These procedures include users at all levels.
Physical Access Controls
LINK2GOV’s physical security infrastructure includes:

Video surveillance and an armed alarm system to protect against unauthorized access to
any LINK2GOV facility, 24/7 (for an alarm notification sample, see PE-006 folder).
Equipment delivery and removal controls (see Destroyed/Disposed Log Sample in the
APPENDIXES folder).
Physical access logs are reviewed on a weekly basis by the SSA.
LINK2GOV’s co-location facility provides controlled access to buildings in accordance with IRS
standards. Building access is restricted to authorized personnel utilizing a variety of security
controls (badges, sign-in sheet, and locked server cabinets).

With regard to corporate employee access:
1. Per NIST security requirement PE-003, LINK2GOV requires card readers and badges to
be used for employees’ physical access to all facilities (corporate office and data
centers, plus alternate work sites), 24/7. Physical access overall is monitored by video
cameras.
2. LINK2GOV maintains an alarm system that is triggered and notifies the appropriate authorities in
the event of unauthorized access attempts.
3. Annual inventories for physical access devices (keys, locks, combinations, card readers)
are required.
To allow visitor access to the Corporate Office:
1. Visitors must sign the Visitor Log in the front reception area and call the LINK2GOV
employee whom they wish to visit.
2. The employee must obtain a visitor badge before allowing the visitor physical access to
the corporate office (see LINK2GOV’s Corporate Office Access policy in the APPENDIXES
folder).
3. Once the visit is completed, the LINK2GOV employee must retrieve the visitor’s badge
and return it to the Office Manager or SSA.
The following provide day-to-day procedures and mechanisms to protect the EFTPS:
Production and Input/Output (I/O) controls provide the proper handling, processing,
storage, and disposal of I/O data and media, including system hardware components (see
Destroyed/Disposed Log Sample in the APPENDIXES folder).
Emergency, Backup, and Contingency Planning are covered in LINK2GOV’s Disaster

Recovery Plan.
Audit logs allow management to conduct independent review of records and activities.
Currently these logs are generated on the LINK2GOV Operating System, part of which are
specifically implemented for the EFTPS.
Environmental Controls
Environmental controls at LIN2GOV’s Production and IVR facilities are managed by Service Level
Agreements with those vendors, and at the corporate location per LINK2GOV’s Physical and
Environmental Protection policy.
To change any environmental condition at the corporate office, a request must first be entered
via Remedy and approved by the appropriate authority.

Standard environmental controls should be adhered to as follows:
Ambient relative humidity levels maintained between 45% and 55%
Ambient temperature levels maintained at a range of 68° to 75°F (20° to 24°C) for
optimum system reliability.
Change Management
LINK2GOV has instituted a Change Advisory Board (CAB) to monitor the installation of software
updates to ensure that the EFTPS functions as expected, and that a historical change record is
maintained (see POLICY – Change Advisory Board in the APPENDIXES folder). The CAB also
ensures that only authorized software is allowed on the system, and requires managerial
approval for all modifications to the system.
The following steps are required before the CAB can review and authorize any of these updates:
1. Deploy update in a controlled [sandbox] environment:
a. Depending on scale of the update, initially deploy update into a virtual environment.
b. Updates of a smaller scale can be deployed to the QA environment.
2. Verify no negative impact to controlled environment:
a. Document change implemented and any effects within a Word document.
b. Distribute document to team describing results of the update.
3. Submit Request For Change (RFC) to CAB outlining:
a. Software updates to be applied.
b. Rollback procedures.
c. Expected results.
4. After CAB approval, roll out update to Production environment.
a. If an emergency update is required, changes must be applied during approved off-peak

hours.
b. If the update is not an emergency, updates will be applied during a normal patch cycle.
2.1 Threats to System Security
Threats to the security of the EFTPS include any unauthorized disclosure or modification of
information from unauthorized access (direct or indirect) to system and user objects. This can
happen via system failures, subversion, tampering, or the use of covert channels. All users are

aware of possible modes of trespass, including all users’ responsibilities to reduce access to the
system.
LINK2GOV’s Risk Assessment Plan and subsequent Risk Assessment Report (in the APPENDIXES
folder) provide a comprehensive analysis of potential threats to the EFTPS; the following section
addresses LINK2GOV countermeasures to anticipated threat sources, and is updated as often as
new sources are discovered.
2.2 Security Countermeasures
A Trusted Computing Base (TCB) is defined as “the totality of protection mechanisms within a
computer system—including hardware, firmware, and software—the combination of which is
responsible for enforcing a security policy. A TCB consists of one or more components that
together enforce a unified security policy over a product or system. The ability of a TCB to
enforce a security policy correctly depends solely on the mechanisms within the TCB, and on the
correct input by system administrative personnel of parameters (e.g., a user's clearance) related
to the security policy.”
With regard to security countermeasures based on accountability policies and procedures,

opportunities for unauthorized access to the EFTPS are minimal. Recommended security
settings (via Discretionary Access Controls, deviation from default settings, continuous
monitoring, and firewalls to control input/output filtering) prevent most known unauthorized
access opportunities. The administrative user community is centrally located and relatively
small. Physical access is restricted, and administration activities are normally conducted
remotely from a secure central monitoring location (LINK2GOV’s Corporate Offices).
Most anticipated threats to the EFTPS can be countered by LINK2GOV policy or implemented
security controls (see Access Control, Identification and Authentication, Network Interconnection,
and Physical and Environmental Protection policies in the APPENDIXES folder). In addition to the
implementation of Discretionary Access Controls (DAC), LINK2GOV utilizes anti-virus software
(Symantec) to detect and prevent malicious code and viruses from compromising the system.
LINK2GOV’s overall security policy plays a comprehensive role in how the EFTPS was developed
from inception and is currently managed (see LINK2GOV’s System Development Life Cycle and
System Security Plan). The dependency of system security mechanisms on administrative-user
actions is emphasized throughout LINK2GOV documentation.
Specific countermeasures used by LINK2GOV’s System Administrator to mitigate potential

threats include McAfee and EEYE Retina software, as follows:
McAfee Corporate Anti-Virus (log onto server to manage, see screenshot below):

EEYE Retina Vulnerability Scanning—for internal vulnerability scanning (see procedures
below):
To generate an internal scan:
1. Remote desktop into one of the three servers (one server located at each of the sites)
10.10.161.4 at SunGard, 10.10.177.4 at Atlanta or 10.10.153.4 at corporate
2. Double-click the Retina Network Security Scanner icon in the upper left corner of the
screen:
3. Select the Report tab at the top of the page:
4. Select a report from the list and click Generate on the left:

5. The report will be generated in the bottom area of the screen:
6. Print or forward the report as desired.

TrustKeeper Vulnerability Scanning—for external vulnerability scanning (see section 5 for
details on generating a report).
MS WSUS—for patch management (log onto server to manage, see screenshot below):

Based on all of the above considerations, LINK2GOV believes that the EFTPS operates as a
Trusted Computing Base, and is confident that as such, the system cannot be circumvented and
is tamper-proof. All countermeasures supported in the system require the interaction of both
access control and accountability mechanisms, and these mechanisms are employed by both
ordinary and administrative users.
Addressing the NIST security control specification SC-030, which states that “The organization
employs abstraction techniques to present information system components as other types of
components, or components with differing configurations,” LINK2GOV does not utilize this
approach—for example representing an IIS (Internet Information Server) as an Apache web
server—because of uncertainties as to whether the technology exists, plus concerns that such a
masking approach would cause more harm than good..
2.2.1 Functional Security Coordinator
The IRS requires the assignment of a Functional Security Coordinator (FSC), which for
LINK2GOV is the Systems Security Administrator (SSA). LINK2GOV’s SSA assumes
responsibility for EFTPS audit logs and validates various security components of the system.
2.2.2 SQL Security Settings
SQL 2000 and 2005 settings have been determined to be the appropriate Trusted Computer
System Evaluation Criteria (TCSEC) C2-level security settings (see below).
C - RATING DISCRETIONARY PROTECTION

C1 Discretionary Security Protection
Separation of users and data
Discretionary Access Control (DAC) capable of enforcing access limitations on
an individual basis
C2 Controlled Access Protection
More finely grained DAC
Individual accountability through login procedures

C - RATING DISCRETIONARY PROTECTION
Audit trails
Resource isolation
Required system documentation and user manuals.
2.2.3 Audit Mechanisms
System controls for the EFTPS create, maintain and protect audit trails. System controls allow
for identification of auditable events and management of audit trails (logs) in a secure
environment. These are available from the Operating System and NetMRI SysLog server, and
allow management to conduct independent reviews of records and activities to test the
adequacy of controls, to detect and react to departures from established policies, rules, and
procedures.
AUDIT PROCEDURES
Following the control enhancements specified in NIST SP 800-53:
1. The information system provides the capability to compile audit records from multiple
components throughout the system into a system-wide (logical or physical), time-correlated
audit trail:
LINK2GOV utilizes NetMRI for centralized SysLog capturing and event correlation for
networking components (firewalls, routers, switches—see Netcordia Event Summary in
the APPENDIXES folder).
To use NetMRI:
Using RSA token, log onto the Web interface of NetMRI.
Click the Reports tab.
In the Event Summary Report Parameters section, select Period (Daily, 7-day, 30-
day), Date, and Device Group (Servers, Routers, Switches).
Click Run Report.
2. The information system provides the capability to manage the selection of events to be
audited by individual components of the system:
See the Event Summary Report Parameters outlined above.
3. The organization periodically reviews and updates the list of organization-defined auditable
events.
LINK2GOV reviews and updates these events as mandated by policy (see Audit and
Accountability policy in LINK2GOV’s IT DOCUMENTATION LIBRARY in the internal
SharePoint site:@ http://l2gsp/sites/L2GPolicy/default.aspx ):

Account logon successes and failures:
Account management successes and failures.
Directory service access successes and failures.
Logon event successes and failures.
Object access failures.
Policy change successes and failures..
2.2.4 Application Software Maintenance Controls
Application software maintenance controls monitor the installation of and updates to

application software, to ensure that the software functions as expected and that an historical
application change record is maintained. Software maintenance controls also ensure that only
authorized software is allowed on the system. These controls include a Change Advisory Board
(CAB) that grants approval to modifications and documents those changes (see POLICY_Change
Advisory Board).
System configuration control policy is covered in the LINK2GOV’s Configuration Management

Plan; emergency, backup, and contingency planning are covered in LINK2GOV’s Disaster
Recovery Plan.
2.2.5 Mobile Code Restrictions
LINK2GOV has a strict policy on mobile code use in the secure environment—defined as
computer programs or parts of programs that are transmitted across a network and executed by
a remote computer.
Mobile code restrictions for the EFTPS apply to Java, JavaScript, Active X, Flash, macros,
Shockwave, PostScript, VBScript and new technologies as they arrive. As general practice,
LINK2GOV:
Keeps systems current with the latest software upgrades and patches that address security
vulnerabilities in desktop applications, such as Web browsers, readers and electronic mail,
and other critical software to prevent vulnerabilities.
Obtains all software through approved distribution channels.
Has evaluated and installed virus scanners, firewalls, active content filters, and dynamic
behavior monitors according to enterprise security requirements.
Stays informed of latest security advisories from the Federal Computer Incident Response
Center (FedCIRC) and the Computer Emergency Response Team (US-CERT) Coordination
Center, and subscribes to multiple security mailing lists.
LINK2GOV periodically crosschecks products against published lists of known vulnerabilities,

such as the National Vulnerability Database, which provides pointers to solution resources and
patch information.
LINK2GOV regularly audits systems and networks, quickly remedying any deficits noted.
2.2.6 Personnel Security Clearances
LINK2GOV policy requires personnel who access, design, develop, install, modify, service, or
maintain Sensitive But Unclassified (SBU) systems to receive a favorable Background
Investigation (BI) before being granted access to the system.
All LINK2GOV personnel are required to undergo an initial BI. In situations where access to
sensitive information is necessary, contractors are subject to the same background requirements
as regular LINK2GOV employees.
Individuals granted access to the EFTPS are appropriately trained in how to fulfill their security
responsibilities (see LINK2GOV’s Security Training - Compliance presentation in the APPENDIXES
folder). Employees who do not observe any of the security procedures outlined in LINK2GOV’s
Security Features Users Guide are subject to disciplinary actions, up to and including termination
of employment from LINK2GOV.
LINK2GOV maintains an authorized personnel list of employees and contractors, which are
reviewed monthly to ensure accuracy (see 3 Access Lists in the APPENDIXES folder).
2.2.7 Off-Premises Storage of Electronic Media
In accordance with IRS requirements, off-premises storage standards are used to provide
application and system backup requirements. EFTPS backup procedures and frequency of
backups have been established. Copies of EFTPS backups are rotated to an off-premises storage
facility on a daily basis.
2.2.8 System Backup Procedures
LINK2GOV SAs perform regular backups of the EFTPS and associated databases. Backup data is
stored at LINK2GOV’s Corporate offices and EFTPS production facility in Nashville, TN, and at
the Verizon co-location facility in Atlanta, GA.
2.2.9 Virus Countermeasures
Norton AV Corporate edition runs on all servers at all LINK2GOV sites; Norton AV for exchange
runs on all e-mail servers, as well as MX Logic services for spam filtering.
LINK2GOV servers also receive updated virus definitions at least weekly over the Internet from
the Symantec Norton site; in turn, Symantec Norton’s Corporate AV management tool pushes
updates out to each workstation on no less than a weekly basis.

2.2.10 Incident Reporting
All employees of LINK2GOV are trained to immediately notify a member of IT Security whenever
a security breach is discovered (e.g. unknown visitors in LINK2GOV facilities, evidence
suggesting compromised files, and/or observed failure to adhere to any LINK2GOV security
policy). IT Security will then report the problem to the Systems Security Administrator (SSA),
who will research the vulnerability to determine a remediation plan.
If the incident relates to unauthorized physical access:
The unknown visitor will first be questioned (asked for identification and/or company
affiliation)
Management will be consulted to see if the visitor should be escorted off the premises or
appropriate authorities be notified.
Incident will be noted in LINK2GOV’s security incident log.
If the incident relates to access to an information system:
Any compromised systems are taken offline and evaluated for evidence.
Any compromised system will be reimaged before being placed back into service.
Metavante’s Computer Incident Response Team (MCIRT) is notified to determine if there is

reason for any legal response. If so, Metavante’s Legal Department will handle any legal matters
dealing with a vulnerability or compromise of any LINK2GOV system.
Additionally, it is Metavante policy to engage the local FBI office when needed, as the company
has a favorable working relationship with them. Jim Brown of the MCIRT has been on the Board
of Directors for the Milwaukee FBI InfraGard chapter since its inception in 1998 and is the
organization’s current President.
2.2.11 Vulnerability Scanning
Vulnerability scanning is automatically performed monthly (at a minimum) by Trustwave on all

systems related to the EFTPS. This process maintains an up-to-date status of required security
patches to address any perceived software deficiencies.
Vulnerability scans are conducted as follows:

Eeye’s Retina software prompts a vulnerability scan of all internal systems at the beginning
of every month; TrustKeeper prompts a vulnerability scan of LINK2GOV’s external IP subnet
(see TrustKeeper Compliance Report in the APPENDIXES folder)
After the scan is completed, a report is generated and emailed to the Network Engineers
Group (Dan Bachrach and Robert Valentine—see the three Retina Vulnerability Scans in the
APPENDIXES folder);

Network Engineers Group reviews report, schedules vulnerability remediation as needed.
Penetration testing is additionally performed once a month by Metavante Corp. on all

LINK2GOV systems.
2.2.12 Honey Pots
Per federal directive (NIST requirement SC-026), honey pots are established and monitored in
the following manner:
1. They are placed on the DMZ with and NOT permitted to transition the firewall
internally for any reason by the use of access control lists on the firewall
2. They are monitored on a routine basis for the first sign of compromise
3. Once a honey pot is deemed to have been compromised, its logs are pulled to analyze
the data for the following information
Who
How
When
4. The honey pot is returned to the DMZ with as little outage or down time as possible to
prevent the possibility of the attacker knowing that they have found a non-critical
system
5. Once the logs are analyzed and it is understood how the honey pot was compromised
steps are then taken to apply fixes/patches to production machines to keep the same
attack from being utilized against them.
6. Firewall rules will be put in place to prevent the IP of the attacker from reaching
production boxes.
NOTE: Honey Pots DO NOT replace any IPS/IDS, and data gathered from the Honey Pot is only
used for understanding how machines are compromised, NOT for protecting them directly.
2.3 Explicit Physical Security Assumptions
This Trusted Facility Manual is written with the assumption that all systems are housed in a
protected data center, and that access to both the facility and equipment is controlled by data
center personnel and established security controls (see LINK2GOV’s System Security Plan).
Systems allowing legitimate users to access EFTPS components are used only in environments
where both administrative and ordinary users are trusted to access all data in the system, and
not to misuse physical access permissions. Wherever users are not allowed access to system

components, security controls are in place (e.g. via data center access permissions) such that
access is not possible.
Actual physical security for the EFTPS is specified by vendor SLAs (currently Verizon and
SunGard), which are reviewed by LINK2GOV on an annual basis.
2.3.1 System Designer Assumptions
Explicit physical security assumptions made by system designers include:

Physical access is limited and controlled by an access list, badge identification requirements,
and password.
All systems are monitored continuously via CCTV.
In the event of system compromise, all components are redundant and subject to isolation.
2.4 Protection Mechanisms Available to Administrative Users
LINK2GOV’s System Administrators are responsible for protecting server administrative

components from ordinary users (e.g. via user setup parameters, registry settings, network
configurations, domain configurations, user account/rights policy configurations, environmental
group profile settings, and backup/restore procedures).
Controls that support system availability for access accounts are managed by utilizing groups via
Active Directory and Group Policy. Protection mechanisms are also in place to manage invalid or
expired passwords. Other protection measures are supported as follows:
2.4.1 Processing Information
To ensure that EFTPS information is protected during processing, the system is designed to
provide:
SSL encryption to the Web sites during the entire session.
Layer-3 VLANs providing access restrictions between networking devices.
VPN tunnels between third-party vendors.
These functions are supported by cryptographic key management procedures (see Section 9 of
this manual, plus LINK2GOV’s Cryptographic Key Management policy in the APPENDIXES folder.
2.4.2 Storing Information
LINK2GOV systems store information in Server Query Language (SQL) databases, such that
data cannot be accessed by unauthorized users, who are defined by access control lists.

2.4.3 Transmitting Information
LINK2GOV’s use of special trusted-path mechanisms are based on physically protected, hard-
wired consoles (no wireless access is permitted), therefore the invocation of command processors
is available only to administrative users.
TO PROHIBIT WIRELESS ACCESS TO THE EFTPS
Wireless network cards are not installed on any system.
Laptops with wireless cards cannot connect to the system because no wireless access points are
installed on the system.
The use of audit mechanisms to detect potential misuse of the system is also a protection
mechanism specific to administrative users (see Section 2.2).
2.4.4 User Authentication/Access Control
LINK2GOV requires all access and privileges to be requested by the assignee’s manager before being
granted. Access control is typically requested via Remedy.
LINK2GOV utilizes information system authenticators such as:
Roles assigned a risk factor (see LINK2GOV’s Personnel Risk Assessment policy in
LINK2GOV’s IT DOCUMENTATION LIBRARY @ http://l2gsp/sites/L2GPolicy/default.aspx).
RSA tokens for VPN authentication (see procedures on the following page).
Two-factor (unique userID and password) authentication via Active Directory to internally
control user login and object access.
Key cards for physical access to the corporate facility.
For password-based authentication, the information system:
Protects passwords from unauthorized disclosure and modification when stored and
transmitted;
Prohibits passwords from being displayed when entered;
Enforces password minimum and maximum lifetime restrictions;
Prohibits password reuse for a specified number of generations;
Automatically locks out a user after 3 unsuccessful logon attempts (if the attempts fall
within a 15-minute time period).
Requires additional security clearances for remote access.*
* As stated in NIST SP-53, a remote session is initiated whenever an information system is

accessed by a user (or an information system) communicating through an external, non-
organization-controlled network (e.g., the Internet). For this reason, remote access is strictly
controlled by LINK2GOV, as follows:
TO GRANT REMOTE ACCESS TO THE SYSTEM
1. The SSA must have received a valid request for remote access submitted by the intended user’s
manager (submitted via Remedy)—also stating that the assigned equipment will be for business use
only.
2. The user must be assigned a specific and restricted ‘remote access’ role.
3. The system must be accessed using a portable computer provided by LINK2GOV (for security
considerations/threat mitigation, no personal computers will be allowed by the SSA to access the
system).
4. The portable computer must be tracked with a unique identifier via LINK2GOV’s component inventory
system.
Multi-factor authentication (via the assignment and use of RSA token, see RSA Token Setup and
Assignment below) is also required from the user before remote access is granted. See also
LINK2GOV’s Remote Access policy (in APPENDIXES folder).
In compliance with NIST security control IA-005, LINK2GOV’s System Security Administrator
(SSA) manages information system authenticators by defining initial authenticator content;
establishing administrative procedures for initial authenticator distribution, for
lost/compromised, or damaged authenticators, and for revoking authenticators; changing
default authenticators upon information system installation; and changing/refreshing
authenticators periodically (every 3-4 years).
RSA TOKEN SETUP AND ASSIGNMENT
1. An unused RSA token is retrieved from the safe in LINK2GOV’s Network Operations Center (NOC).
2. A network engineer logs into l2gacsdc1 and opens the RSA Host Mode icon
3. Select the token from the list via the Serial Number list

4. Select the Enabled checkbox, then click on Resynchronize Token to sync up the rotating keys:
5. Click Assign Token, then on the resulting Select User dialog box (Last name checkbox will be checked
by default), enter the users Last name, then click OK:
6. Click on the ‘Set PIN to Next Tokencode’ button and enter the code displaying on the token

The user will use their LINK2GOV account name for a user ID, and for a password, the PIN
assigned during this process plus the code showing on the token to log into the VPN system.
This places the remote system/laptop on the internal network and then allows them to remote
to whatever system they need access to do their work, check their mail etc.
When an employee leaves the company, the token is unassigned and disabled by simply
reversing the process shown in Step 4.
Users take reasonable measures to safeguard authenticators including maintaining possession

of their individual authenticators, not loaning or sharing authenticators with others, and
immediately reporting lost or compromised authenticators. Lost/compromised or damaged
authenticators must be immediately reported to the Infrastructure team, who will then disable
the authenticator and mark it as lost. The user will then be re-issued a new token and pin
number.
2.4.5 Handling Output
LINK2GOV uses SQL Server as its database tool, along with its built-in functions for security
purposes. SQL Server secures and stores data as follows:
SQL Server has built-in encryption to protect various types of sensitive data. In some cases, this
encryption is completely transparent; things are encrypted when they're stored and decrypted
automatically when they're used. In other cases, you can choose whether data should be
encrypted or not. SQL Server can encrypt the following components:
Passwords
Definitions of stored procedures, views, triggers, user-defined functions, defaults, and rules
Data sent between the server and the client
SQL Server encryption keys include a combination of public, private, and symmetric keys that
are used to protect sensitive data. The symmetric key is created during SQL Server initialization
when you first start the SQL Server instance. The key is used by SQL Server to encrypt sensitive

data that is stored in SQL Server. Public and private keys are created by the operating system
and they are used to protect the symmetric key. A public and private key pair is created for each
SQL Server instance that stores sensitive data in a database.
To manage symmetric keys, the tools included in SQL Server may be used to do the following:
Back up a copy of the server and database keys so that you can use them to recover a server
installation, or as part of a planned migration.
Restore a previously saved key to a database. This enables a new server instance to access
existing data that it did not originally encrypt.
Delete the encrypted data in a database in the unlikely event that you can no longer access
encrypted data.
Re-create keys and re-encrypt data in the unlikely event that the key is compromised. As a
security best practice, you should re-create the keys periodically (for example, every few
months) to protect the server from attacks that try to decipher the keys.
Add or remove a server instance from a server scale-out deployment where multiple servers
share both a single database and the key that provides reversible encryption for that
database.
NOTE: Accessing objects secured by the service master key requires either the SQL Server
Service account that was used to create the key or the computer (machine) account. That is, the
computer is tied to the system where the key was created. You can change the SQL Server
Service account or the computer account without losing access to the key. However, if you
change both, you will lose access to the service master key. If you lose access to the service
master key without one of these two elements, you be unable to decrypt data and objects
encrypted by using the original key.
2.5 Security Vulnerabilities and Warnings
Per SAIC requirement CM-007, whenever the system is updated (see Security Activities Checklist
in the APPENDIXES folder for schedules), LINK2GOV proactively takes all anticipated security
vulnerabilities and warnings into consideration, as follows:
Review design and implementation assumptions to ensure that any new component
introduced into the system is compatible with the current architecture and operating
requirements,
Ensure that procedures are in place to ensure a smooth transition, and that the system is
continuously monitored (via automatic scanning and reviewing audit logs) post-
implementation to ensure operational stability.
Test the functionality of any update or patch to the system and apply change control

procedures as needed.
2.6 Separation of Administrative Roles
LINK2GOV meets the requirements stated in SAIC criteria AC-005, as follows:
(i) Mission functions and distinct information system support functions are divided among
different individuals/role:
Network Services – Systems Engineer & IT Infrastructure Team Lead.
Database Management – DBA Team Lead.
Development (Tax) – Manager of Tax Solutions.
Development (Gateway) – Manager of Gateway Development & Support.
(ii) Different individuals perform information system support functions:
System Management - Systems Administrator.
Systems Programming – Development Group.
Quality Assurance/Testing – Director of Product Development & QA.
Configuration Management – Change Advisory Board (consisting of

representatives from all LINK2GOV functional areas).
Network Security – Systems Security Administrator.
(iii) Security personnel who administer access control functions do not administer audit
functions.
Although LINK2GOV’s System Security Administrator also manages system audits,

these audits are in part conducted via automated software, and test cases are
delegated to Network Services personnel. Additionally, any discovered system
anomalies are brought before LINK2GOV’s Change Advisory Board for mitigation,
which consists of roles from all of LINK2GOV’s functional areas.
TO SUBMIT A CHANGE REQUEST:
1. Test and evaluate proposed change for ‘Proof of Concept’ in a controlled environment.
2. Once tested, open formal change request ticket in Remedy (see Using Remedy in the
APPENDIXES folder).
3. The request is thereby submitted to the Change Advisory Board.

4. RFC is reviewed and approved by committee.
5. Once approved, change is scheduled for Production.
6. Once implemented, monitor and document change effects on the system

(positive/negative).

3.0 Security Policy
LINK2GOV’s Trusted Computing Baseline (TCB—defined as the set of all computer components
critical to its security) is supported via Microsoft’s Active Directory. TCB commands are
restricted utilizing Active Directory’s ability to delegate control to specific systems, files and
folders, and any other resource within the EFTPS domain; interfaces are managed by Access
Control Lists (ACLs) on routers and switches, as well as delegated permissions granted to Active
Directory. Individual aspects of LINK2GOV’s security policy are discussed below.
3.1 Discretionary Access Control
Access control features of Microsoft Server 2003 and SQL Server 2000, 2005 are used to grant
access to EFTPS data and functionality on a need-to-know basis. Within Windows 2003,
developers are granted the permissions necessary to modify the EFTPS application programs
and access the EFTPS database. They are restricted to accessing only those administrative tools,
utilities, and directories that are essential. Limited privilege accounts are established for
transferring files from various interfacing systems/applications. The SQL Server DAC
mechanisms are used to define and distinguish access permissions for users and groups within
LINK2GOV and the EFTPS domain.
3.1.1 Initialize DAC Privileges and Defaults
ACTION EFFECTS EXCEPTIONS PARAMETERS

Command
dsa.msc Opens Active Directory Does not affect networking
Console devices, local computer
compmgmt.msc Opens local computer Does not affect networking
management console devices, Active Directory
Function
Right-click on Displays Security / Only SAs have access to
object > General etc. tabs the AD on Domain
Properties Controllers
3.1.2 Distribute, Review and Revoke User Privileges
LINK2GOV utilizes Group membership within Active Directory to distribute and revoke user
privileges; audit logs are used to review user privilege use and object access.

Command Opens Active Directory Does not affect networking
Console devices, local computer
System Call

Function Displays General / Only SAs have access to
Account / Member of the AD on Domain
etc. tabs Controllers
3.1.3 Group Membership Definition and Impact
Defined by the user’s role with respect to the EFTPS.

Command Opens Active Directory Does not affect networking
Console devices
System Call
Function Displays the groups the Does not affect networking Only SAs have access to
individual is a part of and devices. the AD on Domain
allows SA to add to Controllers
different groups
3.1.4 Change, Restoration, and Destruction Process
Changing object ownership is determined on a “need to know” basis; restoring privileges deleted
accidentally is managed by a backup of Active Directory’s system state; destroying errant
processes is managed by reviewing audit logs and submitting requests for change (RFCs) to
LINK2GOV’s Change Advisory Board (CAB); running consistency checks on system and user
security profiles is managed by Active Directory replication; managing user accounts is discussed
in Section 3.3 below.
3.1.5 Concurrent Login Control
Users (other than a system administrator) are not permitted more than 2 concurrent/multiple access
sessions at a time, per domain.
3.2 Mandatory Access Control
Only Discretionary Access Controls (DAC) determine EFTPS access and access levels, therefore
Mandatory Access Controls (MAC) are not applicable.
3.3 Management of User Accounts
As specified in NIST SP 800-53, account management includes the identification of account

types (i.e., individual, group, and system), establishment of conditions for group membership,
and assignment of associated authorizations. The organization identifies authorized users of the
information system and specifies access rights/privileges. The organization grants access to the
information system based on: (i) a valid need-to-know/need-to-share that is determined by
assigned official duties and satisfying all personnel security criteria; and (ii) intended system

usage. The organization requires proper identification for requests to establish information
system accounts and approves all such requests. The organization specifically authorizes and
monitors the use of guest/anonymous accounts and removes, disables, or otherwise secures
unnecessary accounts.
Account managers are notified when information system users are terminated or transferred
and associated accounts are removed, disabled, or otherwise secured.
Account managers are also notified when users’ information system usage or need-to-
know/need-to-share changes.
With regard to the EFTPS, LINK2GOV manages user accounts utilizing Microsoft’s Active
Directory, which assigns users to specific user groups. Individual user groups have access to the
EFTPS based on assigned responsibilities—which follow NIST guidelines for separation of duties.
The guidelines and procedures that are used in the management of user accounts are outlined
below, and provide the network administrator with the necessary information to create and
manage user accounts and passwords:
Systems will uniquely identify and authenticate users and processes acting on behalf of
users using either single or multifactor authentication as deemed necessary.
Systems will obscure feedback of authentication information (e.g., display asterisks when a
user types a password).
The Microsoft Windows 2000, Microsoft Windows XP, and Microsoft Windows 2003 Security
Accounts Management (SAM) database stores hashed copies of user passwords. This
database is encrypted with a locally stored system key. To keep the SAM database secure,
Windows requires that the password hashes are encrypted. Windows prevents the use of
stored, unencrypted password hashes.
Systems will enforce password specifications:
Passwords automatically expire after 45 days.
Users cannot reuse passwords that were in effect for the previous180-day time period.
Passwords must be at least 8 characters long.
Passwords must include, at a minimum, two types of either letters, numbers, and
special characters (e.g., #, !, %, etc.).
To grant a user access to any LINK2GOV system (new or transferred):
Before a user can access the system, the system administrator must ensure the following:
The user will pass a background check and comply with all standard hiring policies in
place by Metavante. The process of creating a user account will not begin until the
individual has been hired as an employee of Metavante.
Upon receiving authorization through the REMEDY system requesting the new user be

configured on the network, the System and/or IT Administrator will set up the user
profile based on privileges needed for the user’s job requirements. To do this, the IT
administrator will create an Active Directory account for the new user from a template
that relates to the position they are being hired for. The Active Directory path is
L2GDC01.LINK2GOV.com\LINK2GOV.com, and the templates can be accessed using
\Acct Templates (screenshot below).
A unique user identifier will be issued to the user, which is comprised of the first letter of
the user’s first name and the complete last name of the user. For example, John Smith
is “jsmith”. The new user is created by right clicking anywhere in the active directory,
and choosing “New User.”
A temporary password will be created for the user. A random password is created by
the administrator and assigned to the employee. In the active directory, the
administrator will configure the user account to require a password change upon first
login. This will be done in the new user screen shown below.
The temporary password will be securely communicated in person by the network

administrator to the new user.
New user identifiers will be maintained in the active directory. These are initially entered
into the system during the new user account setup described above and can be accessed in
the Active Directory path listed above. This directory can only be accessed by the system
administrator, who can create, edit, remove, and backup the users.
An initial temporary password or a reissued temporary password will be changed the first
time a user accesses the system. This process is setup during the new user process

described above, and the user will be forced to change their password during the first login.
If a user forgets his/her password or believes it may have been compromised, he/she must
immediately report it to the Infrastructure team by submitting a REMEDY request.
Upon notification from the REMEDY request that a user needs a new password, the System
and/or IT Administrator will:
Revoke the current password by selecting the appropriate user account in active
directory and enabling the “reset password” option. Once the password is reset, the
administrator will be prompted to set up a temporary password, and the administrator
will do so and configure the password to be reset upon first login as described above.
Securely provide the new temporary password to the user and provide instruction that
the user will be required to change the password on the next login.
The network administrator can disable user accounts in the active directory by right clicking
on the user and choosing “disable”, or using the action menu and choosing “disable”. This
will remove all network access and permissions that were originally assigned to the user, but
the permissions will be saved in the active directory in the event that the user will need to be
re-enabled. .
The network administrator can completely delete user accounts in the active directory by
right clicking on the user and choosing “delete”, or using the action menu and choosing
“delete”. This will completely remove the user from the active directory, including all access
and permissions that were assigned to the user. If the user needs to be re-instated in the
future, the user account will be completely recreated.
User identifiers will be disabled immediately at the conclusion of employment. Standard

procedure is to disable the users from the system immediately, and a review is conducted
weekly to evaluate any outstanding inactive users. All inactive users will be deleted from the
active directory no later than 45 days after the last account activity. The queries used during
the weekly review are run from the active directory using the screen shown below. Any
inactive users that need to be removed from the system will be deleted using the process
described above.

All default identifiers and authenticators will be changed. This is a standard setup
configuration whereby any default “administrator” account is renamed by accessing the
user in the active directory and renaming it to an appropriate name.
3.3.1 Establishing Accounts
To access the EFTPS, a user must first submit a ticketed request within the REMEDY system for
approval and authorization. Upon authorization, the user is assigned a unique personal USERID
and password.
3.3.2 Activating Accounts
Once an account has been established, users may logon to the network and are required at that
time to change their initial password to a new one based on established complexity rules, as
follows:
At least one alpha numeric character.
At least one special character.
At least one upper-case letter.
At least one lower-case letter.
Password is comprised of eight or more characters.
3.3.3 Modifying Accounts
Individuals who forget their passwords or want to change them must submit a Remedy ticket to
request the change.
3.3.4 Reviewing Accounts
Accounts are reviewed every quarter by LINK2GOV’s System Security Administrator (SSA).
3.3.5 Disabling Accounts
When an employee or contractor leaves the company for whatever reason (permanent or
temporary)—or at the request of the users manager to disable an account—the following steps
are performed:
1. Access the Active Directory User computer.
2. Right-click on appropriate domain name and select Find.
3. Enter users name.
4. Once users name is identified, click on the name and select Disable Account.

3.3.6 Removing/Deleting Accounts
At the end of every month, disabled accounts are deleted using the following steps:
1. Access the Active Directory User computer.
2. Right-click on appropriate domain name and select Find.
3. Enter user’s name.
4. Once users name is identified, click on the name and select Delete Account.
3.4 Command, System Call and Function Definitions
3.4.1 Effects and Exceptions
LINK2GOV maintains an exception database which stores any errors or exceptions thrown by
the applications. This data is retained for approximately six months to allow LINK2GOV to
research potential issues or trends.
3.4.2 Parameter and Default Settings
If any parameter or default settings are required to be changed, the changes are first tested and
approved in a controlled environment before introducing them to the EFTPS.
3.4.3 Examples of Command Use and Potential Misuse
LINK2GOV does not retain specific data identifying individual or business personal information
within the EFTPS logging system. The logging system records application and server-specific
errors tied to a date time stamp to allow further research into any given issue.
3.4.4 Domain Name Resolution
LINK2GOV installs Domain Name Services (DNS) on all domain controllers, of which there are
two for each domain.
To install DNS on a server:
1. Initiate Build process.
2. Upon server prompt or server roll, configure DNS as part of Active Directory build on
Windows server, designated as a domain controller
TO CREATE OR DELETE DNS RECORDS
1. Open a Help Desk ticket in Remedy outlining post name and IP address to be added, and
specific DNS zone to be added to.

2. Once ticket has been submitted and assigned to a Systems Administrator (SA), the
appropriate DNS record will be added and documented to the system.
3.5 Specific Vulnerabilities
Specific vulnerabilities of administrative procedures and activities are addressed in LINK2GOV’s

Security Features Users Guide.
3.5.1 DoS Attacks
These types of threats are filtered by multiple hardware devices such as Cisco PIX firewalls and
Proventia Intrusion Prevention devices. LINK2GOV also employs Cisco Security Agent, a software-
based intrusion detection/prevention solution.
3.5.2 VoIP Attacks
Although most of these types of attacks are already mitigated by LINK2GOV’s hardened
infrastructure, LINK2GOV has developed a Voice over Internet Protocol (VoIP) policy, along with
procedures to counter these potential types of attacks.
The procedures listed below are used by the network administrator to securely configure and
distribute VoIP machines (in this case, Cisco phones), to employees:
When a new employee is hired and has successfully been subject to and passed all security
checks and processes, the network administrator will receive a request from the hiring
manager, via a REMEDY ticket, to set up a new phone for the employee. The phone
systems currently used by L2G are Cisco VoIP phones.
The network administrator retrieves a phone from the onsite inventory and works with the
hiring manager to log an EMAC (employee change control) ticket to the corporate location
in Milwaukee using the REMEDY system to configure the phone. This ticket requires the
following information: employee’s phone extension, business reason for the request, and
the 16 digit registration code located on the phone.
Once the EMAC ticket is approved and the request is successfully configured by Metavante,
the network administrator and hiring manager are notified via REMEDY that the phone is
ready to be used by the employee. The completed ticket includes the phone number and
extension that will be displayed on the phone.
The network administrator delivers the phone to the employee’s workstation and connects
it to the secure network port located in the workstation. The phone is then tested to ensure
that it is working properly—consisting of verifying that the proper number and extension are
displayed on the phone, and placing and receiving calls from the phone to ensure it is
functioning properly. The administrator will also verify that the employee’s information is

displayed in the corporate phone directory by looking up the employee name.
The procedures listed below are used by the Development team to securely create and configure
IVR applications:
Once a new IVR application has been approved by the product team, a request is made via
REMEDY and reviewed through the existing Change Advisory Board (CAB) process. Once
approved, the application is configured in Production using the steps outlined below.
A new IVR phone number is created and applied to the appropriate IVR server by a
Development team member (an employee of L2G who has successfully passed all security
checks during the hiring process). The configuration is performed using the Interaction
Attendant tool stored on the IVR server (see screenshot below), accessed by securely
logging in to the server. The configuration consists of naming the new IVR profile, marking
it as “active”, and entering the correct phone number to be used for the application.
The new IVR phone number is registered with the carrier (currently Verizon), by calling 800-
444-1111 and using the existing L2G account.
MONITORING VOIP
A security code is provided by Verizon for each IVR number, and this code is required for any
future configuration to the IVR number. The security code consists of 6 numbers. The IVR
number is then verified by the development team to ensure the application is properly
linked to the IVR number. This is verified using the Interaction Supervisor tool located on
the server, which can be accessed by securely logging in to the IVR server. The member of
the development team will verify that the phone number is associated with the correct
profile (see screenshot below).

3.5.3 Network Interconnection Policy
See LINK2GOV’s Network Interconnection policy for LINK2GOV’s approach to preventing

vulnerabilities via third-party connections, remote facilities, and site-to-site VPNs.

4.0 ACCOUNTABILITY
4.1 Identification and Authentication
EFTPS controls require users to identify themselves by USERID and have their identification
authenticated by password before being granted access to the system. Controls enforce
individual accountability by linking a specific individual to all auditable actions taken by that
user. Authentication data is protected from unauthorized access.
EFTPS System Administrators (SAs) define when users can logon by date, time, physical
location, and authentication mechanism. Password composition and quality are protected by
pre-set rules. Time limits on passwords are established. Individual or group profiles are also
established.
4.1.1 TCB Commands and Interfaces
Trusted Computing Base (TCB) commands, interfaces and procedures are utilized to perform the
setup of user/group security profiles, authentication, and authorization parameters of the logon
mechanism.
4.1.2 Password Management
LINK2GOV utilizes complex passwords which protect the EFTPS from unauthorized access. SAs
provide initial USERID and password access to users. Job assignment and management
determine user approval and access level. At no time are passwords distributed via email, Instant
Messenger (IM), or any type of office stationery.
4.1.3 Account Restrictions
Account policies and restrictions determine how password and logon policies are enforced.
Passwords expire every 45 days
Passwords contain a minimum of eight characters
Passwords must be upper/lower case and consist of a mix of alpha-numeric characters
Password history retains the last 5 passwords updated by the user, and prevents the same
password from being used again (within the last 5 updates)
An Account Lockout option is utilized to prevent unauthorized users from attempting to access
the system by password guessing, as follows:
Lockout is set after three failed login attempts
Lockout duration is set to 99,999, to force a System Administrator to unlock the account.
User must login to change password

User will NOT be allowed to access any LINK2GOV system without a user ID and password.

STANDARD WARNING MESSAGE
A standard warning message is automatically displayed whenever a user logs onto the server
hosting the EFTPS. The message below displays until the user clicks OK to complete the logon
process.
SESSION LOCK/SCREENSAVER
A session lock is automatically initiated (forced through Group Policy) to prevent further access
to the system after 5 minutes of inactivity or upon receiving a request from a user. The session
lock is retained until a user reestablishes access by using established identification and
authentication procedures.
To initiate a session lock:
1. Log into the domain controller.
2. Open the Group policy editor snap-in.
3. Go to “The Real Domain Policy”
4. Go to “User Configuration”
5. Go to “Administrative Templates”
6. Go to “Control Panel/Display”
7. Enable settings to desired settings.
To reinstate a user’s session:
1. User must move their mouse to reactivate the screen.
2. User must reenter their password to regain access to their session.

AUTOMATIC LOGON REMOVAL
EFTPS user accounts are disabled when the user no longer requires access to the system.
When a user no longer requires access to a LINK2GOV system, the SSA:
Immediately disables the user account in Active Directory for each domain where the
employee had an account
o Log onto the Domain Controller
o Select start, then Administrative Tools
o Click on Active Directory Users and Computers
o Click on Actions then Find in the menu bar at top
o Search for the users name
o In the section titled Options check the Disable Users Account box
o Click on ok
Moves the disabled user account to ‘Disabled Accounts’ (OU)
o Select the users account from above
o Locate the Disable Accounts folder on the left hand side of the screen.
o Drag the users name into that folder and release.
Every quarter, the SSA:
Reviews all user ids in the ‘Disabled Accounts’ OU
Consults with all Departmental managers (via e-mail) to determine which accounts can be
deleted.
Deletes accounts as instructed.
o Log onto the Primary Domain Controller
o Click Start then Select Administrative Tools
o Select Active Directory Computers and Users
o In the left panel find the Disabled Accounts OU and select it
o Manually review the accounts in the folder.
o Notate those accounts that have been disable then send an E-mail to their
managers asking if they can be removed
o If they can be removed, right click on the users account
o Select delete

o If prompted to delete press ok.
4.1.4 Choice of User or Group Identifiers
Microsoft’s Server 2003 and SQL Server 2000, 2005 provide tools for managing user accounts
and groups. The following documentation list is utilized for establishing and managing individual
or group profiles.
Microsoft® SQL Server™ 2000 Administrator's Companion
Microsoft Security Operations Guide for Windows 2000 Server
Microsoft Security Operations Guide for Windows 2003 Server
Microsoft® SQL Server™ 2000 Administrator's Pocket Consultant
Microsoft® SQL Server™ 2000 Reference Library
4.1.5 Maximum Levels of Trust for Users and Groups
STANDARD GLOBAL GROUPS
Global group names are formed using appropriate standard abbreviations for functions and
sites, generally using the following format:
Name Description
Where Name is the group function, and Description is any additional information necessary.
The following are standard domain-wide global groups:
Domain Administrators Personnel with administrator privileges. This may include personnel at other
(Network Services) sites with administrator privileges at that site, and personnel designated to
the role of the EFTPS security coordinators. Users in this group are allowed
to access security information on the servers.
Database Personnel with DBA privileges, including all database servers and database
Administrators backup archives. Users in this group are allowed to access security
information within the database.
Developers Personnel with application development privileges. Users in this group have
access to Web servers, application logs, and back-end processing servers.
Service Accounts Applications that need to access the system and maintain operational
stability without requiring user intervention.
Users All other users requiring the limited access needed to resolve customer
queries.

STANDARD LOCAL GROUPS
When default domain local and global groups cannot meet local needs, local group names are
formed based on standard global groups. Other non-standard or application groups may be
created as needed.
ADMINISTRATOR GROUP AND ACCOUNTS
Administrator Group and Administrator accounts have unlimited rights on the system.
Therefore, membership is carefully evaluated and protected as follows:
The Administrator account is often the target of attacks, therefore Administrator accounts
are renamed.
Select the Administrator account and right click on it
Select the Rename option.
Type in new name then press ok
Failed logons are enabled in the auditing system to detect attempts to logon to any
account.
Membership of the Administrators and the Domain Administrators group is regularly

reviewed to remove any unnecessary users.
The SSA will log into the Active Directory Computers and Users on the Primary
domain controller
The SSA will open the Administrators and the Domain Administrators OUs and
manually review the accounts in each group. Those that shouldn’t be there are
noted and deleted
All Microsoft server parameter changes, user privileges, and registry modifications are
restricted.
All changes for Microsoft servers are coordinated and executed by the System Security
Administrator (SSA).
All database changes are coordinated and executed by the DBA. Remote access is also
available to approved developers for troubleshooting.
The SA’s personal logon is added to the appropriate administrator group for access rights to
perform administrative functions.

GUEST ACCOUNT AND EVERYONE GROUP
Guest accounts and the Everyone group are disabled on all application Web servers.
• Log into the Primary Domain Controller
• Open the Active Directory Users and Computers
• Perform a search for the above listed groups
• Open the group
• In the options section check the Disable Users Account
• Click ok
4.1.6 Level of Trust Requirements
LINK2GOV requires all personnel to obtain a standard ‘Background Investigation’ clearance.
System controls for the EFTPS require users to identify themselves and have their identification
authenticated before being granted access. Authentication data is additionally protected from
unauthorized access.
4.1.7 Device Authorization
As stated in LINK2GOV’s Identification and Authorization policy, no peripheral devices—including

but not limited to USB drives, MP3 devices, external hard drives, digital cameras, mobile phones,
and non-company laptops—may be attached to any LINK2GOV system without prior written
consent from the employee’s manager and the SSA.
To ensure the existing Device Authorization policy is implemented on machines located on the
network, the Network Administrator will use the following procedures (see following page):
1. Apply the group policy to approved OUs using the Group Policy Object Editor.

2. Right-click on the OU and select Link Existing OU, then select Disable USB Drives:
3. Select the Enabled radio button, then click OK (following page):

4.1.8 System Output Naming Conventions
LINK2GOV uses system output naming conventions (e.g., for client reports) that identify the
client, the report type, and the date of the report.
4.1.9 Information Labeling
All LINK2GOV information is labeled as outlined in the Information Sensitivity and Retention
policy (see APPENDIXES folder)
4.1.10 Remote Access Management
Any LINK2GOV employee requiring remote access to a LINK2GOV system must provide the
following:
1. A valid reason for remote access submitted by their manager.
2. The use of an available LINK2GOV portable computer (for security considerations/threat mitigation,
no personal computers will be allowed to access the system).
3. A statement acknowledging that the assigned equipment is for business use only.
Once remote access is granted, multi-factor authentication is also required via the use of an RSA
token before remote access will be granted at logon.
Under no circumstances may a personal computer be used (by an employee, contractor, or

vendor) for LINK2GOV business.
If a LINK2GOV administrator requires remote access to a LINK2GOV system to perform

maintenance, then to ensure an acceptable security level:
1. The remote session must be logged.

2. The audit logs of the remote session must be reviewed.
3. The SSA must first approve the use of any remote diagnostic tools used for remote
maintenance.
4.1.11 Wireless Technologies
LINK2GOV does not deploy wireless access points at any location and denies the right for
anyone to connect wireless data communication devices to their network.
For further detail about LINK2GOV’s policy regarding wireless technologies, see the Wireless
Communications policy in the APPENDIXES folder.
4.1.12 Mobile and/or Portable Devices
LINK2GOV does not allow mobile and/or portable devices to access the system.
For further detail about LINK2GOV’s policy regarding mobile and/or portable devices, see the
Mobile Communications policy in the APPENDIXES folder.
4.2 Definition and Change of System Parameters of the Logon Mechanism
LINK2GOV System Administrators control parameters of the EFTPS logon mechanism. To make
it more difficult for unauthorized users to compromise a password, the following administrative
restrictions are placed on passwords.
A password cannot consist entirely of ascending or descending numbers (e.g., 12345678 or
87654321).
A password cannot consist of one repeated digit (e.g., 88888888)
Passwords must meet the minimum length of eight characters.
A password cannot start with 0.
After a password has been changed, it cannot be changed back to the initial password.
Users are issued their unique network USERID and initial password upon submission and
approval of a written request from their manager to LINK2GOV’s SSA. Upon initial logon, users
are prompted to change their password from the initial password provided. After a successful
password change, users are prompted every 45 days to change their password. Passwords must
be comprised of eight (or more) alphanumeric characters. The sequence should not spell a word
or phrase or be recognizable as a word, phrase, name, or acronym.
Logon parameters are as follows:
4.2.1 Time-out Intervals

The EFTPS Windows Server 2003 domain security model will log off users after 15 minutes of
inactivity. Users are made aware that applications are at risk if left unattended.
4.2.2 Multiple Logon Attributes
The logon screen prompts users for a USERID and password. The EFTPS Windows Server 2003
domain security model permits multiple logons. The user may initiate multiple connections to
the EFTPS Windows Server 2003 domain servers from the same workstation, and the local
LINK2GOV domain allows a user to logon at multiple workstations simultaneously.
4.2.3 Maximum Logon Time
There is no limit to the amount of time a user may be logged on to the EFTPS. However, users
must logoff as soon as their work is finished.
4.2.4 Limits on Unsuccessful Logons
A user can attempt to logon to the EFTPS with an invalid password three times before the
account is locked out.
A user cannot log back on to the EFTPS after the account has been locked. Only the SA can
reinstate a user who has been deactivated by resetting the user’s password.
To reinstate a user’s logon permission:
1. Log into L2GPDC.
2. Click Start and select Administrative Tools.
3. Select Active Directory Users and Computers
4. In the new window click Action then Find
5. Enter user’s initials.
6. Click Find Now.
7. Double-click on user’s name.
8. In new window at top, select the Account tab.
9. Uncheck the box next to Account is locked out.
10. Click OK.
11. Close all open windows.
12. Log off L2GPDC.

4.2.5 Use of Special Trusted Path Mechanisms for Administrative Users
In the event an Administrative User of the EFTPS is working from a remote location, LINK2GOV
mandates the use of a multi-factor Virtual Private Network (VPN) connection in order to access
the system.
4.2.6 Dormant Accounts
Dormant/disabled accounts are audited quarterly too determine if they will ever need to be
utilized at a future date (users out on maternity leave or a military leave of absence, for
example). Should any account situation have changed (employee on maternity leave decides not
to return, for example), the account is deleted during the next quarterly audit.
4.2.7 Account Correlation Review
‘Account Correlation’ (or Cross-Account Correlation) enables a supplier with multiple Web sites
and affiliate programs to accurately track a referral. Additionally, it allows suppliers to receive
credit for all of their referrals, regardless of the path the consumer takes before finally taking a
commissionable action, such as purchasing a product or filling out a form (in the case of the
EFTPS, paying LINK2GOV a commission fee once taxes have been paid by the consumer).
To support the security and privacy of all financial transactions relating to consumer use of the
EFTPS, LINK2GOV utilizes 128-bit Secure Socket Layer (SSL) encryption. To date, LINK2GOV
has experienced no loss of financial data or any associated loss of confidence by EFTPS users.
4.3 Audit Mechanisms
Group policy enforces user accountability and tracks the activities of all EFTPS users. The
resulting system audit log shows when each user logged on to a workstation and logged off,
password changes, creation and deletion, opening and closing of files, program initiations, and
actions by system operators, SAs, and security coordinators.
4.3.1 Audit-Event Selection Mechanisms
SAs are responsible for auditing and performing the following tasks:
Setting up the auditing subsystem parameters.
Selecting event types and other selection criteria for generating auditing information.
Planning file system space consumption for audit data.
4.3.2 Management/Review of Audit Logs
Audit log management protects auditing and security logs from other administrators who might

change or delete them, and grants only the Administrator group the ability to access the logs.
The following guidelines are followed by LINK2GOV to ensure proper log management and to
avoid audit data loss:
Audit logs are reviewed (on a quarterly basis or more often if needed),
Ensure the physical security of systems and disks containing audit logs and log backups (so
that audit logs are not overwritten, e.g.).
Provide disk mirroring and other high availability support for audit log disks.
TO REVIEW AUDIT LOGS
1. Go to LINK2GOV’s Central Login Server and look for any of the following unusual activities:
Late night logons
Logon failures
Failed access to files
Failed attempts to perform security-relevant tasks such as changing file permissions or Access
Control Lists (ACLs).
4. Upon discovering any of the above, LINK2GOV’s SSA should open an incident report in Remedy and
notify the following authorities:
Executive management
Local and/or federal agencies
4.3.4 Functions for Formatting, Compressing, and Post-Processing of Audit Files
LINK2GOV does not retain audit files once they have been reviewed and deemed safe (that is, do
not contain any evidence of a potential threat source).
4.3.5 Interfaces for Setting of Covert Channel Delays and Randomization of Variables
LINK2GOV utilizes encryption mechanisms (PKI) for all EFTPS transactions.
4.3.5 Description of Audit Log and Event Formats
LINK2GOV utilizes the standard audit log and event format set forth set by Windows Server
2003 Operating System, which tracks the following:
Account logon successes and failures.
Account management successes and failures.
Directory service access successes and failures.
Logon event successes and failures.

Object access failures.
Policy change successes and failures.
Privilege use successes and failures.
System events successes and failures.
AUDIT STORAGE CAPACITY
To ensure that LINK2GOV can meet the requirement of retaining audit logs for six years—and
prevent their being overwritten—the SSA will continuously monitor storage capacity using
SiteScope, and will plan for growth when audit storage capacity reaches 75%. At present,
LINK2GOV maintains a minimum storage capacity of 3.0 Terabytes.
Beyond automatic monitoring, the SSA will routinely check storage capacity and stability on a
monthly basis (see Security Activities Checklist in the APPENDIXES folder).
NOTE: LINK2GOV incorporates audit data into its overall database schema; therefore
audit storage capacity is monitored together with overall data storage capacity—which
as a matter of policy should never be less than 25%.
NON-REPUDIATION
LINK2GOV tracks accountability (non-repudiation) by capturing date and time, source, user, and
computer information of any transaction in the system log.
Additionally, LINK2GOV employs the use of digital certificates to mitigate against “man in the
middle” attacks and replay attacks, thus providing non-repudiation to the end user.
RESPONSE TO AUDIT FAILURES
In the event of any type of audit failure:
1. LINK2GOV’s automated event collector (NetMRI) will send an email alert to the System
Security Administrator (SSA) detailing failure type, date, time, object failed, and source of
the failure (to be implemented by Q4 of 2009).
2. SSA will review the failure and address as necessary.
3. Depending on the failure type, SSA will create an Incident Report via Remedy, and discuss
required corrective action(s) to be taken with the appropriate functional area.
4.4 Commands, System Calls, and Function Definition
With respect to the EFTPS, all commands (such as restarting services, querying information, or

tracing network connectivity) are conveyed using DOS command prompts. Certain parameters
and default settings are limited depending on the level of assigned user rights. This approach is
used to mitigate all potential sources of misuse of the system.
4.5 Specific Vulnerabilities
Vulnerabilities of administrative activities and procedures related to identification,

authentication, and audit—that is, anything that would compromise an EFTPS account—is
proactively managed by:
Physically restricting access to LINK2GOV’s Production facility.
Logically restricting access to the EFTPS.
Use of password complexity rules to mitigate ‘brute force’ attacks.
Auditing accounts for misuse and necessary access permissions.
For further detail, see LINK2GOV’s Risk Assessment Plan and Risk Assessment Report (in the
APPENDIXES folder).

5.0 Routine Operations
Routine operations of administrative personnel include both security-relevant and security-

irrelevant operations. Security-relevant operations include: boot and shut down the system, set
system clocks, identify damaged user volumes and files, perform backups and online device
tests, run system integrity tests, respond to user requests to mount/unmount volumes, and
install, activate, and set the current sensitivity level of a printer within the pre-defined range.
Routine security-irrelevant operations include: perform system metering and require operator
response to various user requests.
Maintenance Procedures
Maintenance procedures include the following processes.
NOTE: All maintenance services provided to LINK2GOV must adhere to the restrictions outlined
in LINK2GOV’s Maintenance and Supply Chain Protection policies.
Analyzing System Logs after Crashes
1. Log onto system.
2. Open Event Viewer.
3. Review all warning and error messages during the time in question.
Conducting Crash-Recovery and Restart Actions
1. Restart crashed system.
2. Observe for unusual activity.
3. Verify operational stability before reintroducing to the system.
Changing System Configuration Parameters
1. Submit Request for Change (RFC) to Change Advisory Board (CAB).
2. After analysis and approval by the committee, schedule a change into the next maintenance
cycle.
Anticipating Predictable Component Failures
1. Review Inventory – HARDWARE list on an annual basis to determine which components are due for
failure (i.e. every 40 months, per LINK2GOV policy).

2. Schedule any proactive changes as outlined below.
Changing Hardware Components
In the event of any hardware component failure—or in anticipation of possible failure, per
LINK2GOV policy—LINK2GOV follows the steps outlined below, per service level agreement
(SLA) with CompuCom:
STEP ACTION INFORMATION NEEDED

1 Log Remedy ticket. Retain this number for later use.
2 Contact CompuCom @ Agent will greet caller and request
information.
1-800-366-3888, option 1 (File server issue)
3 Give name and phone number. Required in case call gets disconnected.
4 State severity level SEV1 – System down
SEV2 – System impaired
SEV3 – System operation normal
5 Provide equipment type/model. e.g., Compaq Proliant 6000
6 Describe problem. If scheduling the call for a later e.g., specify break fix services or
date and time, please indicate this to the agent. requesting IMAC services
7 Provide customer account number Client ID# 192067
8 Provide site zip code, site address. Where is equipment located?
9 Provide contact and alternate contact info, if Main number at which to reach you or
applicable. designated representative..
10 Provide equipment serial number e.g., s/n D637BHJ40059
11 CompuCom agent will verify if equipment is under Contract # K090323-10645
the contract.
12 Provide customer reference number Remedy ticket number is required.
13 CompuCom agent will provide work order #. Record CompuCom case number for
reference.
14 CompuCom agent will immediately assign the call Remedy ticket number is required.
to a local engineer, who will contact customer
within two hours to schedule ETA.
15 CompuCom engineer will call within 2 hours and Accompany engineer throughout
arrive on-site within 4 hours, unless rescheduled. service call to ensure no unauthorized
access to any L2G system.
Running Periodic System Integrity Checks

st
On the 1 day of each month, internal and external vulnerability scans are automatically initiated
by EEYE Retina (internal, see three Retina Vulnerability Scans in the APPENDIXES folder) and
TrustKeeper (external—see below).

To generate a scan report (e.g. from TrustKeeper):
1. Log into the TrustKeeper website:
2. From the left menu select View Results:
3. At the top of the screen select the Compliance Report you want to look at (Summary or Detailed).

4. The resulting reports (one from each scan—Eeye Retina and TrustKeeper) are delivered via email to the
System Security Administrator (SSA).
5. The SSA reviews the reports and submits any findings to the CAB.
6. After analysis and approval by the committee, any required changes are scheduled for the next
maintenance cycle.
Maintenance/Repair of Damaged Volumes
1. Damaged hard drive is immediately reported to the vendor for immediate replacement.
2. In keeping with industry standards and federal directives (NIST requirement MA-003),
damaged hard drive is degaussed (see Destroyed/Disposed Sample Log in the APPENDIXES
folder)
3. SSA must authorize the removal of equipment before it is returned to vendor.
NOTE: For further maintenance-related security requirements, see LINK2GOV’s Supply Chain
Protection policy.
5.1 Security-Relevant Procedures and Operations
5.1.1 Running of System Diagnostics
SAs and DBAs diagnose issues with the EFTPS utilizing the following types of logs (generated via
NetMRI Event Analysis):
System
Application
Security
Database
Network
5.1.2 System Boot and Shutdown
EFTPS SAs can initiate an emergency shutdown and subsequent reboot if required. Once the
system has been rebooted, an email is generated to prompt users to diagnose their respective
functional areas to ensure that no data loss or corruption has occurred.
Routine system or application maintenance does not normally require system-wide shutdown.
If required, the EFTPS may be booted and shutdown by the SA or system operations personnel
using standardized procedures.
Should the system fail to restart, the System Administrator will contact the data center for

emergency ‘hands on ‘ or will physically visit the data center to troubleshoot and diagnose the
problem. LINK2GOV’s system is designed with high availability in mind; therefore complete
redundancy is available in the event of any system failure.
5.1.3 Setting of System Clocks
The EFTPS has a system clock that is set by the SAs/DBAs and is synchronized using Microsoft
Network Time Protocol (NTP), using two primary servers that synchronize their time with an
International Atomic clock. The other servers in the EFTPS system synchronize their time with
the two primary servers using Microsoft NTP.
NETWORK TIME PROTOCOL (RFC-1305)
The Network Time Protocol (NTP) is the most commonly used Internet time protocol, and the
one that provides the best performance. Large computers and workstations often include NTP
software with their operating systems. The client software runs continuously as a background
task that periodically gets updates from one or more servers. The client software ignores
responses from servers that appear to be sending the wrong time, and averages the results from
those that appear to be correct.
Many of the available NTP software clients for personal computers don’t do any averaging at all.
Instead, they make a single timing request to a signal server (just like a Daytime or Time client)
and then use this information to set their computer’s clock.
The NIST servers listen for a NTP request on port 123, and respond by sending a UDP/IP data
packet in the NTP format. The data packet includes a 64-bit timestamp containing the time in
UTC seconds since January 1, 1900 with a resolution of 200 ps.
Most of the NIST time servers do not require any authentication when requesting the time in
NTP format, and no keys or passwords are needed to use this service. In addition to this standard
NTP service (which will not be modified), we have begun testing an authenticated version of NTP
using a single time server that implements the symmetric key encryption method defined in the
NTP documentation. In order to use this server, you must apply to NIST for an encryption key,
which will be linked to the network address of your system. This service is being offered on an
experimental basis only, and it may not be continued after the initial testing period.
LINK2GOV’s NTP server is pointed to one of the National Institute of Standards and
Technology’s (NIST.ORG) recommended time servers. These time servers fall under the RFC
1305 standards for time synching for all present day Wintel servers.
NIST.gov’s Internet Time Service (ITS) allows LINK2GOV to synchronize computer clocks via the
Internet. The time information provided by the service is directly traceable to UTC (NIST). The
service responds to time requests from any Internet client in several formats including the

DAYTIME, TIME, and NTP protocols.
Requests in these formats generally do not support authentication, and no keys or passwords
are needed to use these services.
To have all Microsoft Window systems that are located on the LINK2GOV domain(s) and the
Corp, SunGard, Verizon locations to use the ITS common time, common time replication is
essential for systems in synchronizing servers and clients. Currently, each domain Controller
(DC) is independently synching to its clients and servers. This means that each DC is looking at
its own W32time clock thus pushing it’s time down to clients or other servers on the domain.
NETWORK TIME CONFIGURATION
A Cisco appliance, model 6506 is configured as a Network Time Protocol device (NTP). The time
device would be configured with a default value of 900 seconds which is equal to 15 min. This
time needs to be determined if appropriate for LINK2GOV domains. Another option of 3600
seconds may deem more appropriate due to the fact of network conditions, security
requirements, time source NIST traffic and server actions that is always on going daily at one
given time.
The NTP Cisco device is pointed to one of the National Institute of Standards and Technology
(NIST.ORG) recommended time server. These time servers fall under the RFC 1305 standards for
time synching for all present day Wintel servers.
The NIST.org server would be located at: time-a.nist.gov, IP 129.6.15.28, or time-nw.nist.gov.

The device, IP 10.10.140.1, replicates Central time to the LINK2GOV.com, Gateway, and Ingate
domains. The L2Gex NTP device is 10.4.0.3, which is also configured for the Eastern Time zone,
and pulls its time information from the referenced time—a NIST.gov site.

TIME CONFIGURATION STEPS
To configure an internal time server to synchronize with an external time source:
1 Change the server type to NTP. To do this, follow these steps:
a. Click Start, click Run, type regedit, and then click OK.
b Locate and then click the following registry sub key:

.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Tim
e\Parameters\Type
c. In the right pane, right-click Type, and then click Modify.
d In Edit Value, type NTP in the Value data box, and then click OK.
2 Set AnnounceFlags to 5. To do this, follow these steps:
a. Locate and then click the following registry sub key:
e\Config\AnnounceFlags
b In the right pane, right-click AnnounceFlags, and then click Modify.

.
c. In Edit DWORD Value, type 5 in the Value data box, and then click OK.
3 Enable NTPServer. To do this, follow these steps:
a. Locate and then click the following registry sub key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
\TimeProviders\NtpServer
b In the right pane, right-click Enabled, and then click Modify.

.
c. In Edit DWORD Value, type 1 in the Value data box, and then click OK.
4 Specify the time sources. To do this, follow these steps:
a. Locate and then click the following registry subkey:
e\Parameters
b In the right pane, right-click NTPServer, and then click Modify.

.
c. In Edit Value, type Peers in the Value data box, and then click OK.
Note Peers is a placeholder for a space-delimited list of peers from which your
computer obtains time stamps. Each DNS name that is listed must be unique.
You must append ,0x1 to the end of each DNS name. If you do not append
,0x1 to the end of each DNS name, the changes made in step 5 will not take

effect.
5 Select the poll interval. To do this, follow these steps:
\TimeProviders\NtpClient\SpecialPollInterval
b In the right pane, right-click SpecialPollInterval, and then click Modify.

.
c. In Edit DWORD Value, type TimeInSeconds in the Value data box, and then
click OK.
Note TimeInSeconds is a placeholder for the number of seconds that you want
between each poll. A recommended value is 900 Decimal. This value configures
the Time Server to poll every 15 minutes.
6 Configure the time correction settings. To do this, follow these steps:
\Config\MaxPosPhaseCorrection
b. In the right pane, right-click MaxPosPhaseCorrection, and then click Modify.
c. In Edit DWORD Value, click to select Decimal in the Base box.
d. In Edit DWORD Value, type TimeInSeconds in the Value data box, and then
click OK.
Note TimeInSeconds is a placeholder for a reasonable value, such as 1 hour

(3600) or 30 minutes (1800). The value that you select will depend upon the poll
interval, network condition, and external time source.
e. Locate and then click the following registry subkey:

\Config\MaxNegPhaseCorrection
f. In the right pane, right-click MaxNegPhaseCorrection, and then click Modify.
g. In Edit DWORD Value, click to select Decimal in the Base box.
h In Edit DWORD Value, type TimeInSeconds in the Value data box, and then
. click OK.
Note TimeInSeconds is a placeholder for a reasonable value, such as 1 hour

(3600) or 30 minutes (1800). The value that you select will depend upon the poll
interval, network condition, and external time source.
7 Quit Registry Editor.
8 At the command prompt, type the following command to restart the Windows Time
. service, and then press ENTER:
net stop w32time && net start w32time

RECOVERY STEPS CONFIGURATION STEPS:
Backup Registry for fall back procedures on the NTP Server.
FALL BACK PROCEDURES ON NTP SERVER:
In the case of technical issues, perform a restore of the registry on the NTP server.
Any actual issues most likely would not harm the server since the server is clean and only tasked
as a NTP server.
Domain issues (Risks): Low threat. NTP will either synch the LINK2GOV server or not. No issues
should develop and the local servers would hold their current time by falling back to the original
time source.
FALL BACK PROCEDURES ON DOMAIN SERVERS:
Disable NTP from Domain and wait for Domain Controllers to start its synchronization to trickle
down within 15 min.
5.1.4 Identification of Damaged User Files and Volumes
SAs employ the utilities available within Windows Server 2003 OS (i.e., chkdsk, Disk
Management) to monitor and optimize system disks and server volumes. LINK2GOV also utilizes
HP SiteScope to monitor volumes for capacity readiness and stability.
To verify SiteScope functionality, SAs will perform system checks monthly using the following
steps:
1. Remove hard drive from non-critical system.
2. Ensure alert is properly showing in Site scope
3. Verify alert is clear on the following points:
• System name
• System issue.
5.1.5 Routine Backup of TCB Files
A full backup of EFTPS databases is maintained locally and at LINK2GOV’s alternate datacenter
in Atlanta, GA. DBAs perform full EFTPS backups, which are maintained at each facility using
real-time merge replication. Copies of seven days’ worth of full backups are available for
restoration purposes at each LINK2GOV site.
To restore any database from a backup, simply access the system in question and run ‘Restore.’

5.1.6 Online Device Testing
Any device that is scheduled to be connected to the EFTPS is analyzed and certified before
access is permitted to the system.
To certify any device attempting to access a LINK2GOV system:
1 Ensure that device is on approved device type list.
2 Determine device MAC address.
3 Register MAC address in NAC.
4 When device is plugged into the LINK2GOV network, device will either authenticate or not,
in which case it will not be allowed access to the system.
5.1.7 Response to User Requests to Mount/Un-Mount Tapes
Not applicable to the EFTPS since LINK2GOV does not use tapes.
5.1.8 Handling of Peripheral Devices, Removable Storage, and Output
LINK2GOV does not allow nor deploy any peripheral devices (e.g., floppy drives, tapes drives) to
be connected to any EFTPS hardware (see LINK2GOV’s Identification and Authentication policy),
although an exception is sometimes made for an external hard drive (to secure off-site backups,
for example).
For further detail about handling output (media marking, e.g.), see the guidelines in LINK2GOV’s
Information Sensitivity and Retention policy in the APPENDIXES folder.
MEDIA HANDLING PROCEDURES
The procedures on the following pages provide details on how to protect information deemed
‘Confidential’ or ‘Restricted’ at varying sensitivity levels (Minimal, More Sensitive, and Most
Sensitive). See the Disposal/Destruction row for instructions on media sanitizing for each level,
where appropriate.
MINIMAL General corporate, some personnel contact, and minimal technical

SENSITIVITY configuration information.
Marking Guidelines Marking is at the discretion of the owner or custodian of the information. If
desired, the words ‘LINK2GOV CONFIDENTIAL’ or ‘LINK2GOV
PROPRIETARY’ may be written in a conspicuous place on the information in
question. Even if no marking is present, LINK2GOV information is presumed
to be CONFIDENTIAL unless expressly determined to be PUBLIC
information by a LINK2GOV employee with the authority to make that
determination.

MINIMAL General corporate, some personnel contact, and minimal technical
SENSITIVITY configuration information.
Access LINK2GOV employees, contractors, and others with a business-based ‘need
to know’
Distribution within Standard interoffice e-mail, approved instant messaging and electronic file
LINK2GOV transmission methods.
Distribution outside of U.S. mail and other approved public or private carriers, e-mail, and
LINK2GOV electronic file transmission methods
Electronic Distribution No restrictions except that it should only be sent to approved recipients.
(NOTE: instant messaging to and from external sources is blocked.)
Storage Keep from view of unauthorized people, erase whiteboards, do not leave in
view on tabletop. Machines should be administered with security in mind.
Protect from loss; electronic information should have individual access
controls where possible and appropriate.
Disposal / Destruction Deposit outdated paper information in specially marked disposal bins on
LINK2GOV premises; electronic data should be expunged / cleared. Reliably
erase/overwrite data to a minimum of DoD 5220-22.M ‘short’ or standard of
physically destroy the media.
Penalty for Deliberate Up to and including termination, possible civil and/or criminal prosecution to
OR Inadvertent the full extent of the law.
Disclosure
MORE SENSISTIVE Business, financial, technical, and most personnel information.

Marking Guidelines As the sensitivity level of information increases, in addition to or instead of
‘LINK2GOV CONFIDENTIAL’ or ‘LINK2GOV PROPRIETARY’, the
information may also be labeled ‘LINK2GOV INTERNAL USE ONLY’ or
otherwise at the discretion of the business unit or department. However,
marking is discretionary at all times.
Access LINK2GOV employees and non-employees with signed non-disclosure
agreements who have a business-based ‘need to know.’
Distribution within Standard interoffice e-mail, approved instant messenger and electronic file
LINK2GOV transmission methods.
Distribution outside of U.S. mail with receipt confirmation, or approved private carriers with similar
LINK2GOV delivery verification methods.
Electronic Distribution No restrictions to approved recipients within LINK2GOV, but should be
encrypted or sent via private link to approved recipients outside of
LINK2GOV. (NOTE: instant messaging to and from external sources is
blocked.)
Storage Individual access controls are highly recommended for electronic
information. Multi-factor authentication requirements are encouraged.
Unnecessary physical documents and copies are discouraged.
Network storage of this type of data will cover the tenure of the owner or
custodian, will remain available to that employee’s business unit specifically,
and LINK2GOV executives in general, until deemed disposable or a

MORE SENSISTIVE Business, financial, technical, and most personnel information.
maximum period of 7 years to allow for adherence to legal requirements.
Disposal / Destruction After this data is deemed disposable, or has reached its maximum archival
age, hard copies shall be placed in specially marked disposal bins for
shredding on LINK2GOV premises; electronic data should be fully
expunged/cleared. Temp directories are to be deleted and all recycling
services purged. Reliably erase all data to the full DoD 5220-22.M standard,
or physically destroy all media.
Disclosure
Cardholder and sensitive authentication data under PCI/DSS

requirements, trade secrets, administrative passwords, security master
accounts, encryption technologies used for application security,
contractual agreements, personnel, financial, source code, intellectual
property, corporate account numbers, and all other information deemed
MOST SENSISTIVE paramount to the integrity and the success of LINK2GOV.
Marking Guidelines To indicate that RESTRICTED information is very sensitive, label the
information ‘LINK2GOV PCI-DSS RESTRICTED’, ‘LINK2GOV INTERNAL:
Registered and Restricted’, ‘LINK2GOV Internal: Personal & Confidential’,
‘LINK2GOV Eyes Only’, ‘ LINK2GOV Protected’ or similar labels at the
discretion of individual business unit or department. Once again, this type of
restricted information may not be marked, but users should be aware that
this information is very sensitive and protect it as such.
Access Only designated LINK2GOV employees and non-employees with approved
access and signed non-disclosure agreements. Business unit access to this
level of information requires Director or higher approvals. The most
restrictive levels of Adaptive Communication Environments (ACEs) shall be
used on all Access Control Lists (ACLs), both share and NTFS, shall be
applied as standard operating procedure (SOP) for this level of data.
Distribution within Delivered direct - signature required, envelopes stamped confidential,
LINK2GOV digitally signed and/or encrypted email or approved secured electronic file
transmission methods .i.e. HTTPS, SFTP, SSH…etc.
Distribution outside of After appropriate encryption and/or being physically locked and
LINK2GOV documented, this data may be delivered direct; signature required; approved
private carriers with guaranteed deliveries and electronic, real-time
tracking.
Electronic Distribution Only approved recipients within LINK2GOV, and only through strongly
encrypted mechanisms. All external distribution shall be only to recipients
with formal approval, in writing, and only with an encrypted format through
a secured tunnel, i.e. S-MIME across a 3DES VPN. (NOTE: instant messaging
to and from external sources is blocked.)
Storage Network-controlled access controls are mandatory for electronic
information that meets this criterion. Physical security is mandatory for all
machines containing this level of data, and information should be stored in a
physically secured, fully patched server with managed anti-virus that is
audited for failed and successful access attempts.
All databases containing data of this classification will maintain an

Cardholder and sensitive authentication data under PCI/DSS
requirements, trade secrets, administrative passwords, security master
accounts, encryption technologies used for application security,
contractual agreements, personnel, financial, source code, intellectual
property, corporate account numbers, and all other information deemed
MOST SENSISTIVE paramount to the integrity and the success of LINK2GOV.
encrypted format while at rest. All transaction-based data will be
maintained for a minimum period of seven (7) years after the transaction
date, or such time that LINK2GOV executive orders require the disposal of
this data, whichever comes first. Archived data within this class shall also be
encrypted at rest, protected by secure credentials and maintained only in
PCI-DSS certified locations that can exhibit existing, current and reliable
SAS-70 audit reports. All trade secrets, administrative account data and
other mission-critical data shall be kept indefinitely; the disposal/destruction
of this type info will require written authorization from a minimum of two (2)
LINK2GOV executive members.
Disposal / Destruction Physical copy will only be generated for specific use required by law or by
LINK2GOV executive counsel and across a secure transit mechanism. Shred
and dispose across multiple, specially marked disposal bins on LINK2GOV
premises; electronic data should be expunged/cleared fully WITHOUT
decryption or use of temporary file locations. Reliably erase any hard drive
containing media to a minimum standard of DoD 522022.m standard;
however, the Gutmann Wipe (27 random-order passes using specific data,
combined with eight passes using random data) is recommended if possible;
a few random passes should suffice. Otherwise, completely physically
destroy all containing media in a physically secured location.
Disclosure
5.2 Security-Irrelevant Procedures and Operations
5.2.1 Backup of User Volumes
Weekly full backups of EFTPS servers, and system state backups on a daily basis, are both
automatically conducted by Paragon Software Group.
5.2.2 System Metering
System metering and load balancing for the EFTPS is performed continuously using Citrix
NetScaler.
5.2.3 Response to User Requests
User requests are handled automatically through several messaging applications:

Error Messages are data-specific. If the user enters incorrect data the system will respond
with an error message.
Alert Messages are broadcast system-wide to alert the internal user of system conditions

such as the system is busy, down, or unavailable.
Activity Log Messages include ordinary activity, error conditions, and any emergency or
unauthorized access.
5.2.4 User Account Administration
The EFTPS requires minimal user account administration. Once the user account is set up, EFTPS
is self-sustaining unless a user leaves the organization or their account is locked out.
5.2.5 Cardholder Information Retention
To address storing and retention of Cardholder data LINK2GOV’s DBA copy’s the existing
transactional data over to historical tables (without the card number/expiration date) as it occurs
and that will remain untouched. The automated process will remove the old/aged records from
the transactional data per the data retention policy. There will not be any manual intervention.
5.3 Commands, System Calls and Function Definitions
Routine operations of the system consist of EFTPS applications, which the user operates from
their workstation. LINK2GOV’s Security Features Users Guide and vendor documentation provide
additional operational guidance.
5.3.1 Effects and Exceptions of Commands Used for Routine Operations
USER SESSION INITIATION
At logon, EFTPS users are prompted for their unique USERIDs and passwords. Upon correct
entry of this information, the user is allowed access to system resources that have been
approved for the user.
Associated Vulnerability—Social Engineering. LINK2GOV mitigates this potential by security

awareness training.
ACTIVITY LOG CHECK
LINK2GOV’s Operating System maintains system logs that generate exception reports based on
predetermined system parameters (see screenshot below):
AUDIT TRAIL REPORTS
Windows Server 2003 OS audit trail features enforce user accountability and tracks all activities
of SAs and users. It shows exactly when each user logged on to a workstation, or EFTPS domain,

and logged off. It also shows password changes, creations, deletions, opening and closing of
files, program initiations, and all actions by system operators, SAs, and security officers. The
audit trail exception reports include any instances of a user being locked by exceeding the logon
maximum or a workstation being temporarily deactivated, and can be modified to report on a
single user or workstation, or include any event (see screenshot below):
An example of an event log from the Primary Domain Controller is shown below:
NOTE: Corporate level audit reports are typically generated by the MCIRT department at FIS.

If any parameter or default settings are required to be changed, the changes are first tested and
5.3.3 Examples of Use and Potential Misuse
LINK2GOV utilizes account restrictions and audit logs to mitigate potential misuse of the EFTPS
(such as users attempting to access sensitive data, for example). Should any exceptions be
detected, LINK2GOV will immediately take action to correct the potential of any threat
occurring.
5.4 Warning of Specific Security Vulnerabilities of Routine Operations
LINK2GOV relies on Antivirus, firewalls, intrusion prevention/detection systems (IPS/IDS), and

audit logs to provide warnings of specific security vulnerabilities to the EFTPS.

6.0 Security of the TCB (Trusted Computing Baseline)
6.1 Generation of the TCB Source Code
6.1.1 TCB Code Modules, Module Interface and Data
LINK2GOV utilizes Visual SourceSafe to manage code development.
6.1.2 Approved Tools for TCB Generation
LINK2GOV utilizes Windows Server Operating System, Microsoft SQL Server, and Cisco IOS to
generate its system baseline.
6.1.3 Procedures for TCB Generation
LINK2GOV employs System Development Life Cycle (SDLC) methodology to manage a system
throughout its life cycle.
6.1.4 Vulnerabilities
LINK2GOV’s trusted computing base is protected from most conceivable threat source (see
LINK2GOV’s Risk Assessment Plan and Risk Assessment Report).
6.2 Configuration Management Policy
See LINK2GOV’s Configuration Management Plan.
6.3 Ratings Maintenance Plan
Although a formalized Ratings Maintenance Plan (RAMP) has not been established, LINK2GOV
subscribes to the standards and procedures outlined in the National Computer Security Center’s
NCSC-TG-013-89, Rating Maintenance Phase Program.
6.4 TCB Installation Procedure
6.4.1 TCB Generation from Source Code
LINK2GOV uses Visual SourceSafe to manage and secure code development.
6.4.2 TCB Hardware Installation
LINK2GOV tests all hardware employed by the EFTPS in a secure environment before
connecting it to the system.

6.4.3 TCB Data Structure Initialization
LINK2GOV uses Visual SourceSafe to maintain consistent structure of the data.
6.4.4 TCB Loading
Before deploying or loading any code to the EFTPS, LINK2GOV requires all changes to go
through its Change Advisory Board (CAB).
6.4.5 Setting of TCB File Protection
LINK2GOV uses Active Directory and Group Policy to limit access to EFTPS files.
6.4.6 Approved Tools
LINK2GOV uses the following proven system development and support tools:
Windows Server Operating System – Operating Platform
Visual SourceSafe – Source Code Controls
Visual Studio .NET - Development
Microsoft SQL Server - Databases
SiteScope - Monitoring
6.5 TCB Maintenance Procedures
6.5.1 Analysis of System Dumps
LINK2GOV utilizes log files to analyze system dumps.
6.5.2 Crash Recovery and Restart
In keeping with federal directive (NIST requirement SC-024), LINK2GOV’s system is completely
redundant, therefore crash recovery and restart is mitigated via load balancing and clustering.
6.5.3 Changes of Configuration Parameters
See LINK2GOV’s Configuration Management Plan.
6.5.4 Repair of Damaged TCB Data Structures
LINK2GOV’s approach to repairing damaged TCB data structures is to restore the most recent
backup.

6.5.5 Consistency-Checking Procedures
LINK2GOV checks data consistency by monitoring databases, synchronizing Web site structures,
and maintaining consistent operating system patch and service pack level.
6.5.6 Running of Periodic System Information Integrity Checking
LINK2GOV ensures the integrity of its system by using SiteScope (a real-time agent-less
centralized monitoring, alerting and reporting tool) to continuously monitor the following
system components:
Services—deemed critical by specific system/server functions
Hardware—CPU, Memory, Disks
Databases—to verify capacity
Network connectivity—to verify availability
URLs—to verify availability and functionality
LINK2GOV has a SiteScope solution at each site to ensure accuracy and to reduce bandwidth
between site links. Each site’s SiteScope server is configured to monitor each of the other sites
SiteScope servers to ensure there are no issues with other SiteScope servers or connectivity
issues between WAN links.
6.5.7 Setting up System Information Integrity Checking
NOTE: To configure monitors you must first be granted access to the SiteScope server in the
domain you are trying to monitor in.
1. To configure a new monitor you must first add the server to be monitored in the Remote
Windows group by clicking on the Remote Windows link at the home screen.
2. Click the Add link at the bottom of the Remote Windows page to add your server.
3. At the Add Remote Server section you will fill in the outlined areas providing the information
highlighted.
NOTE: See LINK2GOV’s System Security Administrator for Service account information.

4. Once you have completed you can click the Add button at the bottom of the page to
complete this step.
5. To add monitoring for the newly added server you must click on the Monitor link in the Add
to Group section.
6. In the Add Monitor to Group section you have many types of monitors that are available. For
this section we will cover the major components.

7. In the Add Service Monitor in Group page:
Make sure that you have the Server you want to monitor selected in the Server section.
In the Service section, choose the service you wish to monitor from the drop-down
menu.
In the Update every section, choose the frequency for the monitor to run a check.
In the Title section name the monitor accordingly for accurate alerting and reporting.
When you are finished, click the Add button to complete the configuration:
8. Hardware
Make sure that you have the Server you want to monitor selected in the Server section.
When you are finished click the Add button to complete the configuration.

9. Network Connectivity
Add the IP Address of the Server you want to monitor selected in the Host Name
section.
In the Update every section choose the frequency for the monitor to run a check.
10. Database Query
Add the ODBC URL of the server being queried in the Database Connection URL section.
In the Query section copy and paste the query string to be run against the server.
In the Update every section choose the frequency for the monitor to run a check.

11. URL
Add the URL of the web site being queried in the URL section.
In the optional Match Content section, look for specific information on the web page.
In the Title section, name the monitor accordingly for accurate alerting and reporting.
When you are finished, click the Add button to complete the configuration.
6.6 Trusted Distribution of the TCB
6.6.1 Policies and Procedures
Since the EFTPS is not a product offered for sale, this criteria is not applicable.
6.6.2 Correspondence between Master Copy and Installed Copy
LINK2GOV uses Visual SourceSafe to house the master copy of the source code, therefore the
installed copy of the application resides on the EFTPS.
6.7 Commands, System Calls, and Function Definitions
With respect to the EFTPS, all commands (such as restarting services, querying information, or

tracing network connectivity) are conveyed using DOS command prompts. Certain parameters
and default settings are limited depending on the level of assigned user rights. This approach is
used to mitigate all potential sources of misuse of the system.
6.7.1 Effects and Exceptions
Effects and exceptions are detected via continuous monitoring of the system.
If any parameter or default settings are required to be changed, they are first tested and
6.7.3 Examples of Use and Potential Misuse
LINK2GOV utilizes account restrictions and audit logs to mitigate potential misuse of the EFTPS
(such as users attempting to access sensitive data, for example). Should any exceptions be
detected, LINK2GOV will immediately take action to correct the potential of any threat
occurring.
6.8 Warnings of Specific Security Vulnerabilities
LINK2GOV relies on Antivirus, firewalls, intrusion prevention/detection systems (IPS/IDS), and

audit logs to provide warnings of specific security vulnerabilities to the EFTPS.

7.0 Satisfying TCSEC Requirements
7.1 Class C1 Application
All C-1 requirements have been met or exceeded by the EFTPS, as indicated by the table below:
7.2 Class C2 Application
Because the EFTPS is a Class C2 application, some additional documentation is required, as

follows:
7.2.1 TFM Introduction
See Section 1 of this document.
7.2.2 System Security Overview
See LINK2GOV’s System Security Plan and Security Features Users Guide.
7.2.3 Security Policy
See LINK2GOV’s Security Features Users Guide.
7.2.4 Audit
See Section 4.2 of this document.
7.2.5 Routine Operations
7.2.6 Security of the TCB

8.0 Telecommunications
Telecommunications equipment and policy at LINK2GOV includes two distinct sites and two,
separate telecommunications systems. Appropriately, security policy and standards will vary
from site to site as required by information handled, and from system to system depending on
the capabilities of the respective system. All interconnected systems use cryptographic key pairs
in secured VPN tunnels.
For more detailed information on the company’s telecommunications policy, see LINK2GOV’s
Network Interconnection policy in the APPENDIXES folder.
Approved network protocols, ports, and addresses are as follows:
8.1 Network Protocols
LINK2GOV utilizes the TCP/IP protocol suite.
8.2 Network Ports
LINK2GOV utilizes the following ports:

21 – telnet
22 – ssh
25 – smtp
53 – dns
80 – http
443 – ssl
1434/1433 - sql
8.3 Network Addresses
LINK2GOV utilizes the following network addresses:
CORPORATE
10.10.152.0/25
10.0.0.0/16
10.1.0.0/16
10.10.153.0/24
10.10.155.0/24
10.10.156.0/25
10.10.159.32/27
10.210.210.0/24
10.10.138.0/24
10.10.139.0/25
10.10.139.128/25
10.10.140.0/25
10.10.140.128/25
10.10.254.164/30

10.10.156.128/26
10.2.0.0/16
SUNGARD
10.56.0.0/16
10.60.0.0/16
10.61.0.0/16
10.10.160.0/25
10.10.161.0/24
10.10.163.0/24
10.10.166.224/27
10.10.167.0/26
10.63.10.0/24
10.63.20.0/24
10.63.0.0/24
10.63.3.0/24
10.63.30.0/24
10.63.55.0/24
10.63.69.0/24
ATLANTA
10.10.177.0/24
10.10.183.0/29
10.10.184.0/28
10.4.0.0/24
10.4.2.0/24
10.5.0.0/16
10.10.176.0/25

9.0 Cryptographic Key Management
LINK2GOV obtains all cryptographic keys for use in the secure environment from Entrust
Certificate Authorities (CAs).
All keys supplied to LINK2GOV—whether via CAs and/or subscriber RSAs (algorithms), or DSA
(Digital Signature Algorithm) private keys—must be 1024 bits or larger. The CA private key(s)
used to sign certificates and certificate status information shall be generated in cryptographic
modules validated against FIPS 140 Level 2 (or higher).
To renew a certificate:
1. LINK2GOV’s System Security Administrator (SSA) receives a 30-day notification from

Entrust (via email) that a key is up for renewal. The SSA then:
2. Goes to the affected Web server and generates an offline request for the certificate.
3. Logs onto the Entrust Web portal.
4. Selects the certificate to be renewed.
5. Copies and pastes the offline certificate request into the designated field to be processed.
6. Clicks .
For further detail, refer to LINK2GOV’s Renewing a Certificate procedure and Cryptographic Key
Management policy, as well as four Public Key Infrastructure (PKI) policies in the APPENDIXES
folder.

APPENDIXES
Equipment and Specifications
Glossary
Government Sources
Netcordia Event Summary
New Hire Access Request
PCI Acceptance Letter
Retina Vulnerability Scans (3)
Risk Assessment Report
Security Activities Checklist
Security Training – Compliance
TrustKeeper Compliance Report
Using Remedy
POLICIES
Access Control
Change Advisory Board
Corporate Office Access
Cryptographic Key Management
Identification and Authentication
Information Sensitivity and Retention
Mobile Communications
Network Interconnection
Physical and Environmental Protection
Public Key Infrastructure (PKI) (4)
Remote Access
Wireless Communication

Trusted Facility Manual - v2.3.3

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Trusted Facility Manual - v2.3.3

Încărcat de

Drepturi de autor:

Formate disponibile

TRUSTED FACILITY MANUAL v2.

Division President, Government, Education and Healthcare (John DATE

VP and General Manager, LINK2GOV (Holly Huggins) DATE

Tax Program Manager, LINK2GOV (Helen Justice) DATE

At a minimum, this document is updated annually, although interim changes in policy or

DATE + VERSION PAGE(S) CHANGE DESCRIPTION EDITOR(S)

EFTPS – LINK2GOV CONFIDENTIAL December 8, 2009 Page 2 of 96

DEPARTMENT TITLE NAME E-MAIL ADDRESS

VP & General Manager Holly Huggins hhuggins@LINK2GOV.com

CUSTOMER Tax Program Manager Helen Justice hjustice@LINK2GOV.com

DATABASE Database Team David dbuckingham@LINK2GOV.com

This document is additionally stored in an IT DOCUMENTATION LIBRARY on LINK2GOV’s

EFTPS – LINK2GOV CONFIDENTIAL December 8, 2009 Page 3 of 96

All supporting government documentation is located within LINK2GOV’s APPENDIXES folder. If

This document additionally follows guidelines provided by:

National Computer Security Center (NCSC) NCSC-TG-013-89, Rating Maintenance Phase

EFTPS – LINK2GOV CONFIDENTIAL December 8, 2009 Page 4 of 96

1.0 INTRODUCTION ............................................................................................. 12

1.1 PURPOSE ........................................................................................................ 12

1.2 SCOPE AND CONTENTS ...................................................................................... 13

1.3 CONTROL OBJECTIVES ....................................................................................... 13

1.3.2 Communication Protection Controls ................................................................. 16

1.4 TFM INTRODUCTION .......................................................................................... 17

1.4.2 Recommended Use of the Manual .................................................................... 20

1.4.3 TFM Contents.................................................................................................. 22

1.4.4 User-Based Collaboration and Information Sharing........................................... 22

2.0 SYSTEM SECURITY OVERVIEW ...................................................................... 23

PHYSICAL ACCESS CONTROLS .......................................................................................... 24

CHANGE MANAGEMENT .................................................................................................. 26

2.1 THREATS TO SYSTEM SECURITY .......................................................................... 26

2.2 SECURITY COUNTERMEASURES............................................................................27

2.2.2 SQL Security Settings...................................................................................... 30

2.2.3 Audit Mechanisms ........................................................................................... 31

2.2.4 Application Software Maintenance Controls ..................................................... 32

2.2.5 Mobile Code Restrictions.................................................................................. 32

2.2.6 Personnel Security Clearances ......................................................................... 33

2.2.7 Off-Premises Storage of Electronic Media ......................................................... 33

2.2.8 System Backup Procedures .............................................................................. 33

EFTPS – LINK2GOV CONFIDENTIAL December 8, 2009 Page 5 of 96

2.2.10 Incident Reporting ......................................................................................... 34

2.2.11 Vulnerability Scanning ................................................................................... 34

2.2.12 Honey Pots ................................................................................................... 35

2.3 EXPLICIT PHYSICAL SECURITY ASSUMPTIONS .........................................................35

2.4 PROTECTION MECHANISMS AVAILABLE TO ADMINISTRATIVE USERS ......................... 36

2.4.2 Storing Information......................................................................................... 36

2.4.3 Transmitting Information ................................................................................ 37

2.4.4 User Authentication/Access Control ................................................................. 37

2.4.5 Handling Output ............................................................................................ 40

2.5 SECURITY VULNERABILITIES AND WARNINGS ........................................................ 41

2.6 SEPARATION OF ADMINISTRATIVE ROLES ............................................................. 42

3.0 SECURITY POLICY .......................................................................................... 44

3.1 DISCRETIONARY ACCESS CONTROL ..................................................................... 44

3.1.2 Distribute, Review and Revoke User Privileges................................................... 44

3.1.3 Group Membership Definition and Impact ......................................................... 45

3.1.4 Change, Restoration, and Destruction Process .................................................. 45

3.1.5 Concurrent Login Control ................................................................................. 45

3.2 MANDATORY ACCESS CONTROL ......................................................................... 45

3.3 MANAGEMENT OF USER ACCOUNTS .................................................................... 45

3.3.2 Activating Accounts......................................................................................... 49

3.3.3 Modifying Accounts ......................................................................................... 49

3.3.4 Reviewing Accounts ......................................................................................... 49

3.3.5 Disabling Accounts .......................................................................................... 49