Welcome » IT Booklets » Information Security » Security Controls Implementation » Systems Development, Acquisition, and Maintenance » Systems Maintenance
Financial institutions that introduce trustworthy systems into
their environment should ensure that the systems retain that
trustworthiness over time.
Essential control elements are the development of appropriately
hardened systems, usage of standard builds, the appropriate
updating of builds and deployed systems through patch management,
and the controlled introduction of changes into the institution's
Financial institutions use commercial off-the-shelf (COTS) software
for operating systems and applications. COTS systems
generally provide more functions than are required for the specific
purposes for which they are employed. For example, a default
installation of a server operating system may install mail, Web,
and file-sharing services on a system whose sole function is a DNS
server. Unnecessary software and services represent a
potential security weakness. Their presence increases the
potential number of discovered and undiscovered vulnerabilities
present in the system. Additionally, system administrators
may not install patches or monitor the unused software and services
to the same degree as operational software and services.
Protection against those risks begins when the systems are
constructed and software installed through a process that is
referred to as hardening a system.
When deploying off-the-shelf software, management should harden
the resulting system. Hardening includes the following
After deployment, COTS systems may need updating with current
security patches. Additionally, the systems should be
periodically audited to ensure that the software present on the
systems is authorized and properly configured.
Consistency in system configuration makes security easier to
implement and maintain. Standard builds allow one documented
configuration to be applied to multiple computers in a controlled
manner. One financial institution may have many standard
Through the use of standard builds, an institution
An institution may not be able to meet all of its requirements
from its standard builds. The use of a non-standard build is
typically documented and approved, with appropriate changes made to
patch management and disaster recovery plans.
Software support should incorporate a process to update
and patch operating system and application software for new
vulnerabilities. Frequently, security vulnerabilities are
discovered in operating systems and other software after
deployment. Vendors often issue software patches to correct
those vulnerabilities. Financial institutions should have an
effective monitoring process to identify new vulnerabilities in
their hardware and software. Monitoring involves such actions
as the receipt and analysis of vendor and governmental alerts and
security mailing lists. Once identified, secure installation
of those patches requires a process for obtaining, testing, and
installing the patch.
All patches are not equally important. Financial
institutions should have a process to evaluate the patches against
the threat and network environment and to prioritize patch
application across classes of computers. Should the
institution decide not to apply an otherwise important patch to any
particular computer, the decision should be documented with
appropriate conforming changes made to inventory records and
disaster recovery plans.
Patches make direct changes to the software and configuration of
each system to which they are applied. They may degrade
system performance, introduce new vulnerabilities, or reintroduce
old vulnerabilities. The following actions can help ensure
patches do not compromise the security of systems:
Controlled Changes to the
Financial institutions should have an effective process to
introduce application and system changes into their
environments. The process should encompass developing,
implementing, and testing changes to both internally developed
software and acquired software. Weak procedures can corrupt
applications and introduce new security vulnerabilities.
Control considerations relating to security include the
Changes to operating systems may degrade the efficiency and
effectiveness of applications that rely on the operating system for
interfaces to the network, other applications, or data.
Generally, management should implement an operating system change
control process similar to the change control process used for
application changes. In addition, management should review
application systems following operating system changes to protect
against a potential compromise of security or operational
integrity. Isolated software libraries should be used for the
creation and maintenance of software. Typically, separate
libraries exist for development, test, and production.