Professional Documents
Culture Documents
3
EFTPS – December, 2009
Signature Approvals
NOTE: Signatures verify the activation of policy and procedures outlined within this document.
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
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:
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
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.
REFERENCES ................................................................................................................... 4
SYSTEM DESCRIPTION..................................................................................................... 23
ENVIRONMENTAL CONTROLS........................................................................................... 25
4.2.5 Use of Special Trusted Path Mechanisms for Administrative Users ..................... 63
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
8.0 TELECOMMUNICATIONS................................................................................... 93
APPENDIXES ............................................................................................................... 96
GLOSSARY..................................................................................................................... 96
POLICIES .................................................................................................................... 96
Access Control............................................................................................................. 96
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.
Ensure that the collected data meets business objectives and is used as a corporate asset.
1.1 Purpose
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.
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).
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.*
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.
1. To support the control of information flow to and from external information systems,
utilize the following control mechanisms:
d. Intrusion Prevention Systems (IPS) devices (for identifying and mitigating potential
threats and/or attacks—LINK2GOV utilizes Proventia for this purpose).
2. Do not allow the use of peripheral devices without management and SSA approval.
3. Conduct continuous audit logging.
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 @
http://l2gsp/sites/L2GPolicy/default.aspx).
Purchases all anticipated information system components and spares in the initial
acquisition.
Uses trusted shipping and warehousing 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.
Avoid pitfalls and improper use of administrative functions that would compromise system
and user security -
ii. Access control lists (for controlling user and computer authorization)
iv. Intrusion Prevention Systems (IPS) devices (for identifying and mitigating
potential threats and/or attacks)
a. Evaluate and analyze risk positions on an annual basis (see LINK2GOV’s Position
Risk Assessment policy in LINK2GOV’s IT DOCUMENTATION LIBRARY @
http://l2gsp/sites/L2GPolicy/default.aspx).
3. Do not allow the use of mobile code unless specifically approved by the Systems
Security Administrator and installed by the Systems Administrator:
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.1 Scope
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.
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.
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.
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.
See LINK2GOV’s Disaster Recovery Plan, as well as Equipment and Specifications in the
APPENDIXES folder.
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.
Failure to implement protection mechanisms and procedures may result in a loss of controlled
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
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.
LINK2GOV’s Trusted Facility Manual is intended for the use of EFTPS administrative personnel,
including the System Security Administrator (SSA) and DBAs.
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.
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.
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.
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).
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 .
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.
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
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.
Object 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.
DBA
Development personnel
Data protection objectives for user authorization requirements and constraints are to:
Protect data from unauthorized access.
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.
Equipment delivery and removal controls (see Destroyed/Disposed Log Sample in the
APPENDIXES folder).
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).
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.
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).
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.
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:
a. Depending on scale of the update, initially deploy update into a virtual environment.
b. Rollback procedures.
c. Expected results.
b. If the update is not an emergency, updates will be applied during a normal patch cycle.
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
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.
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.”
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.
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:
4. Select a report from the list and click Generate on the left:
MS WSUS—for patch management (log onto server to manage, see screenshot below):
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..
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.
SQL 2000 and 2005 settings have been determined to be the appropriate Trusted Computer
System Evaluation Criteria (TCSEC) C2-level security settings (see below).
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
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:
In the Event Summary Report Parameters section, select Period (Daily, 7-day, 30-
day), Date, and Device Group (Servers, Routers, Switches).
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 ):
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.
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 regularly audits systems and networks, quickly remedying any deficits noted.
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).
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.
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.
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.
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.
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.
Any compromised systems are taken offline and evaluated for evidence.
Any compromised system will be reimaged before being placed back into service.
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.
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);
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.
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
Actual physical security for the EFTPS is specified by vendor SLAs (currently Verizon and
SunGard), which are reviewed by LINK2GOV on an annual basis.
In the event of system compromise, all components are redundant and subject to isolation.
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:
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.
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.
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.
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.
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).
LINK2GOV requires all access and privileges to be requested by the assignee’s manager before being
granted. Access control is typically requested via Remedy.
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.
Protects passwords from unauthorized disclosure and modification when stored and
transmitted;
Automatically locks out a user after 3 unsuccessful logon attempts (if the attempts fall
within a 15-minute time period).
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).
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
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
When an employee leaves the company, the token is unassigned and disabled by simply
reversing the process shown in Step 4.
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
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
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.
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
(i) Mission functions and distinct information system support functions are divided among
different individuals/role:
(iii) Security personnel who administer access control functions do not administer audit
functions.
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).
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.
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.
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.
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.
Users (other than a system administrator) are not permitted more than 2 concurrent/multiple access
sessions at a time, per domain.
Only Discretionary Access Controls (DAC) determine EFTPS access and access levels, therefore
Mandatory Access Controls (MAC) are not applicable.
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.
Users cannot reuse passwords that were in effect for the previous180-day time period.
Passwords must include, at a minimum, two types of either letters, numbers, and
special characters (e.g., #, !, %, etc.).
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
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.
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
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.
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.
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:
Individuals who forget their passwords or want to change them must submit a Remedy ticket to
request the change.
Accounts are reviewed every quarter by LINK2GOV’s System Security Administrator (SSA).
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:
4. Once users name is identified, click on the name and select Disable Account.
At the end of every month, disabled accounts are deleted using the following steps:
4. Once users name is identified, click on the name and select Delete Account.
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.
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.
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.
LINK2GOV installs Domain Name Services (DNS) on all domain controllers, of which there are
two for each domain.
2. Upon server prompt or server roll, configure DNS as part of Active Directory build on
Windows server, designated as a domain controller
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.
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.
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
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).
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.
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.
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.
Account policies and restrictions determine how password and logon policies are enforced.
Passwords expire every 45 days
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.
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.
4. Go to “User Configuration”
5. Go to “Administrative Templates”
6. Go to “Control Panel/Display”
EFTPS user accounts are disabled when the user no longer requires access to the system.
Immediately disables the user account in Active Directory for each domain where the
employee had an account
o In the section titled Options check the Disable Users Account box
o Click on ok
o Locate the Disable Accounts folder on the left hand side of the screen.
Consults with all Departmental managers (via e-mail) to determine which accounts can be
deleted.
o Notate those accounts that have been disable then send an E-mail to their
managers asking if they can be removed
o Select delete
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
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.
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.
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 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.
Failed logons are enabled in the auditing system to detect attempts to logon to any
account.
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 accounts and the Everyone group are disabled on all application Web servers.
• Click ok
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.
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.
LINK2GOV uses system output naming conventions (e.g., for client reports) that identify the
client, the report type, and the date of the report.
All LINK2GOV information is labeled as outlined in the Information Sensitivity and Retention
policy (see APPENDIXES folder)
Any LINK2GOV employee requiring remote access to a LINK2GOV system must provide the
following:
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.
3. The SSA must first approve the use of any remote diagnostic tools used for remote
maintenance.
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.
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.
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).
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.
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.
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.
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.
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.
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.
‘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.
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.
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.
Audit log management protects auditing and security logs from other administrators who might
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.
1. Go to LINK2GOV’s Central Login Server and look for any of the following unusual activities:
Logon failures
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
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 the standard audit log and event format set forth set by Windows Server
2003 Operating System, which tracks the following:
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.
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).
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.
With respect to the EFTPS, all commands (such as restarting services, querying information, or
For further detail, see LINK2GOV’s Risk Assessment Plan and Risk Assessment Report (in the
APPENDIXES folder).
Maintenance Procedures
NOTE: All maintenance services provided to LINK2GOV must adhere to the restrictions outlined
in LINK2GOV’s Maintenance and Supply Chain Protection policies.
3. Review all warning and error messages during the time in question.
2. After analysis and approval by the committee, schedule a change into the next maintenance
cycle.
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).
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:
3. At the top of the screen select the Compliance Report you want to look at (Summary or Detailed).
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.
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)
NOTE: For further maintenance-related security requirements, see LINK2GOV’s Supply Chain
Protection policy.
SAs and DBAs diagnose issues with the EFTPS utilizing the following types of logs (generated via
NetMRI Event Analysis):
System
Application
Security
Database
Network
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
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.
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
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.
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.
a. Click Start, click Run, type regedit, and then click OK.
d In Edit Value, type NTP in the Value data box, and then click OK.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Tim
e\Config\AnnounceFlags
c. In Edit DWORD Value, type 5 in the Value data box, and then click OK.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
\TimeProviders\NtpServer
c. In Edit DWORD Value, type 1 in the Value data box, and then click OK.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Tim
e\Parameters
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
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
\TimeProviders\NtpClient\SpecialPollInterval
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.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
\Config\MaxPosPhaseCorrection
d. In Edit DWORD Value, type TimeInSeconds in the Value data box, and then
click OK.
h In Edit DWORD Value, type TimeInSeconds in the Value data box, and then
. click OK.
8 At the command prompt, type the following command to restart the Windows Time
. service, and then press ENTER:
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.
Disable NTP from Domain and wait for Domain Controllers to start its synchronization to trickle
down within 15 min.
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:
• System name
• System issue.
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.’
Any device that is scheduled to be connected to the EFTPS is analyzed and certified before
access is permitted to the system.
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.
Not applicable to the EFTPS since LINK2GOV does not use tapes.
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.
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.
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
Weekly full backups of EFTPS servers, and system state backups on a daily basis, are both
automatically conducted by Paragon Software Group.
System metering and load balancing for the EFTPS is performed continuously using Citrix
NetScaler.
Alert Messages are broadcast system-wide to alert the internal user of system conditions
Activity Log Messages include ordinary activity, error conditions, and any emergency or
unauthorized access.
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.
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.
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.
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.
LINK2GOV’s Operating System maintains system logs that generate exception reports based on
predetermined system parameters (see screenshot below):
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,
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.
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.
LINK2GOV utilizes Windows Server Operating System, Microsoft SQL Server, and Cisco IOS to
generate its system baseline.
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).
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.
LINK2GOV tests all hardware employed by the EFTPS in a secure environment before
connecting it to the system.
Before deploying or loading any code to the EFTPS, LINK2GOV requires all changes to go
through its Change Advisory Board (CAB).
LINK2GOV uses Active Directory and Group Policy to limit access to EFTPS files.
LINK2GOV uses the following proven system development and support tools:
SiteScope - Monitoring
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.
LINK2GOV’s approach to repairing damaged TCB data structures is to restore the most recent
backup.
LINK2GOV checks data consistency by monitoring databases, synchronizing Web site structures,
and maintaining consistent operating system patch and service pack level.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
Since the EFTPS is not a product offered for sale, this criteria is not applicable.
LINK2GOV uses Visual SourceSafe to house the master copy of the source code, therefore the
installed copy of the application resides on the EFTPS.
With respect to the EFTPS, all commands (such as restarting services, querying information, or
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
approved in a controlled environment before introducing them to the EFTPS.
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.
All C-1 requirements have been met or exceeded by the EFTPS, as indicated by the table below:
See LINK2GOV’s System Security Plan and Security Features Users Guide.
7.2.4 Audit
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.
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
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
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:
2. Goes to the affected Web server and generates an offline request for the certificate.
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.
Glossary
Government Sources
Using Remedy
POLICIES
Access Control
Mobile Communications
Network Interconnection
Remote Access
Wireless Communication