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 environment.
Hardening 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 actions:
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.
Standard Builds 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 builds.
Through the use of standard builds, an institution simplifies
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.
Patch Management 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 Environment 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 following:
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.