This case study looks at the experiences of a Georgia Army National Guard. When it comes to distributed patch management the GaARNG has similar issues of those facing other National Guard Units, as well as many businesses. The development of today's distributed patch management systems has created a progressive structure for managing organizational computer systems. This is also known as updating computers from known vulnerabilities (on both servers and workstations), which supports maintaining a secure computing system. Patches are composed of several different computer "fixes" that help maintain, secure and control the computer systems for an GaARNG. In this case study I will take a closer look policies, procedures of how distributed patch management is handle in the GaARNG.
In the GaARNG patch management compliance is the responsibility of the Information Assurance Manager (IAM). The IAM develops and establishes policy and guidance for all Information Assurance Systems Officers (IASO) throughout the state. The department that actually performs patch management is known as Information Technology Division or simply ITD. ITD has a Systems Administrator or (Sys Admin) who is responsible for planning, coordinating, modifying, implementing distributed patch management for computer related systems on the Georgia domain. The Sys Admin administers the distributed patch management system, software applications.
What is Patch Management? Patch management is one of the most important processes to repair vulnerabilities of operating systems and software. Since an institute or a company has distributed hierarchical structure and the structure consists of many heterogeneous Patch, it is not easy to update patches timely. Patch management framework with patch profiling mechanism and patch dependency solving mechanism. There it's no secret that identifying and correcting network security holes is critical to protecting any business from harmful attacks, the process of vulnerability assessment and remediation often gets overlooked as a critical component of sound security practices. Because it is an ongoing process, many companies avoid proper vulnerability auditing until disaster strikes and they are forced to react. Some businesses fail to learn the lesson of proactive vulnerability assessment and remediation. Despite all the attention that firewalls, anti-virus applications and Intrusion Detection System (IDS) receive, security vulnerabilities still plague organizations. The implementation of these tools often leads administrators into believing that their networks are safe from intruders. There is a complex threat environment of malware, spyware, disgruntled employees and aggressive international hackers, developing and enforcing a strict and regular network security policy that incorporates on-going vulnerability assessment is critical to maintaining business continuity. Firewalls and IDS are independent layers of security. Firewalls merely examine network packets to determine whether or not to forward them on to their end destination. Firewalls screen data based on domain names or IP addresses and can screen for low-level attacks. They are not designed to protect networks from vulnerabilities and improper system configurations. Nor can they protect from malicious internal activity or rogue assets inside the firewall. Similarly, an IDS inspects all inbound and outbound network activity and identifies suspicious patterns. IDS can be either passive or reactive in design, but either way they rely on signature files of known attacks to prevent intrusion. Most sophisticated attacks can easily trick IDS and penetrate networks. Likewise, IDS will not protect against vulnerabilities that may be exploited by remotely executed code. A vulnerability assessment system, on the other hand, will look at the network and pinpoint the weaknesses that need to be patched; before they ever get breached. With new vulnerabilities announced each week, a company's network is only as secure as its latest vulnerability assessment. An ongoing vulnerability assessment process, in combination with proper remediation, will help ensure that the network is fortified to withstand the latest attacks.
In the GaARNG there is an established Configuration Control Board or CCB. The Configuration Control Board tracks changes to controlled automations systems in order to maintain tested, recoverable configurations that may also be "rolled-back" as necessary. This will be accomplished through a process of testing, documentation, authorization, and planned execution of changes on GaARNG automation systems with CCB oversight.The CCB managements any network infrastructure changes, patches and updates. If any changes are requested they must to be approved by the CCB. The CCB board members are comprised of key personnel from ITD and Data Processing Installation or DPI. CCB is important to distributed Patch Management process. If a change is needed, a request is submitted through to the CCB. Risk mitigation is a major responsibility of the CCB. The CCB will forecast a plan of action and milestones for the network infrastructure changes. The board will evaluate the change request documents. The requestor or representative will present a brief summary of their planned change, and answer any question from the attending board members. The board will approve, disapprove, or defer the change request. Approvals will include an assigned implementation window. Upon approval, implementer will execute the change request and report the results to the CCB for final update of the change log. Here are several changes that require CCB approval:
Minor Upgrades / Maintenance: Changes having either no outage, or up to a two hour maintenance window, require CCB notification, and sign off by the branch chief.
Major Upgrades / Maintenance: CCB approval is required for any change that has a maintenance window greater than two hours, or may cause loss of a mission essential function (MEF) for longer than 15 minutes.
New Installations: New installations require CCB approval.
Emergency: Emergency changes affect a mission essential function that requires an immediate fix. They will be completed with the concurrence of another analyst, or approval of an immediate manager. Afterwards, they will be documented by the branch, and approved by the CCB at the next opportunity for audit purposes per the change type guidelines.
Without a Configuration Control Board, arbitrary, unapproved, and undocumented changes and updates to information system baselines have the potential to negatively impact system integrity and availability. A chartered Configuration Control Board provides a setting process for technical review and formal approval of network changes to help prevent rogue system modifications. Each component shall formally charter a CCB for the purpose of monitoring and controlling configuration changes within all information systems under its purview. CCB members shall be appointed in writing for a specified period of time and their duties outlined by title, position, and system. All decisions made by the CCB, including any changes to the system baseline, shall be documented and maintained in the appropriate configuration management system. An effective configuration management plan should address managing and monitoring the personnel allowed making code changes with a review accomplished every 3 months. The Configuration Control Board (CCB), consisting of, at minimum, a Program Manager, Information Assurance Manager, or the Information Assurance Officer shall identify the patches and files/data sets that contain production code or production data and then authorize and document who is allowed to make changes to the production code or data.
Most information systems throughout an organization are unique. Patches, upgrades, and new applications can behave quite differently when applied across disparate systems. It is paramount that steps be taken to maintain the stability of the production IS. Proper compliance testing provides a reasonable level of assurance that system changes will achieve expected results. Each component shall implement a comprehensive set of test procedures that verify modifications to fielded systems will not be negatively impacted by the introduction of patches, upgrades, or modification. Identify need for upgrade by monitoring appropriate channels such as vendor sites, mailing lists, third party sources, vulnerability scans or other means of detection. Patches shall come from an approved trusted source and be tested and deployed in a timely manner.
National Guard Bureau (NGB) domain software products introduce an element of uncertainty to DoD information systems due to their public and unsupported nature. Organizations should not use public domain software products unless required for a mission critical purpose and as approved by the CCB. Components shall establish local policy governing freeware or shareware. The CCB shall ensure freeware or shareware applications are distributed and used as directed. If such software products are determined to be warranted, the organization shall limit the distribution of software to those that have a legitimate business need. Periodic audits shall be conducted to ensure such software is being used for its intended business purpose.
Vulnerability management is another section of distributed patch management. Vulnerability management will focus on the immediate risk to the GaARNG network infrastructure and furnishs Computer Network Defense (CND) alerts to potential compromises. Vulnerability management takes a leading role in monitoring the network and develops countermeasures to reduce vulnerabilities that are active, while providing assistance with reducing risk and vulnerability remediation. During an information emergency, intrusion, or exploitation, personnel report the occurrence to their commander and the next highest Information Assurance (IA) level. IA personnel are responsible for timely reporting. They are also responsible for ensuring that CND alerts, advisories, and that corrective measures are taken.
Once a patch was deployed, many computers were not often or never updated. Most software patches are known as installing software or operating system fixes. I associate a patch with a band-aid. The band-aid covers up the scratch or wound but does not heal the skin, an update patch is the same way, and it covers up the opening but doesn't repair the entire system. This perception is accurate, and as soon as the patch is release it should be tested and installed.
The increase of quickly circulating malicious code and worms targeting recognized vulnerabilities on systems that are not kept up to date, and the downtime along with the expense to bring a system back up are prominent causes for the GaARNG to focus on patch management. These malware threats and increasing interest on regulatory compliance (IE: HIPAA) has evaluated the GaARNG to improve control over the Information Technology assets that have Personal Identifiable Information (PII). The increase in Virtual Private Network (VPN), which gives the mobile user the ability to remote back into the network, is forcing patch management to become a major priority. Patches are normally used to install software fixes and to add new functionality. Others provide operational enhancements of legacy systems through driver optimization. Additionally, patching will provide more options to current network management tools. On an enterprise level these improvements on software service packs and firmware upgrades will also enhanced functionality on certain computers. Normally firmware is often responsible for the behavior of a system when it is first switched on and maintained in Read Only Memory (ROM) or Programmable Read Only Memory (PROM). Attempting to alter any of the ROM files could hinder the overall operations of the system. Units are not authorized to change or manipulate any of the firmware or systems.
The amount of information in audit logs can be very large and extremely difficult to analyze manually; important security related events could be overlooked. Audit review tools are available that can query the audit records by user ID, date/time, or some other set of parameters to run reports of selected information. Operating systems and applications shall have the capability to review audit records and generate reports from the audit records. Most operating systems and applications have built-in auditing capabilities, but if they don't, a DOD approved auditing utility shall be acquired. Selection of the individual approved software should be determined by auditing capabilities, ease of use, administrative overhead, and system overhead, as well as enterprise or organizational policy on auditing requirements. Operating systems typically provide at least the minimum tools and utilities to review audit records and generate reports. Microsoft Windows event viewer tracks all security events and can selectively review audit records, and the Solaris operating system uses the 'praudit' utility for audit reviews.
The computer hardware and software systems used within the DOD have varying amounts of risks. Security configuration or implementation guides are created to minimize the security risks associated with the hardware or software products. IA and IA-enabled applications deployed within the enclave (C&A boundary) shall be configured or implemented according to the information within applicable security guides (e.g., STIGs, SNAC Guides). If security guides are not available for deployed IA products, waivers shall be obtained and commercial best practices shall be applied. All IA and IA-enabled IT products deployed within the system are not periodically reviewed for compliance with governing security implementation guidance documents. The list is extensive. In essence, the network, enclave, Cisco and other devices, including routers and switches are not configured in accordance with current STIGs. Most errors are caused by using default settings and not addressing STIG requirements.
The integrity of computer systems is at risk if software development change controls are not established and implemented. A Configuration Management (CM) plan and an access control policy greatly reduces the risk of unauthorized program modification.
Implementation Guidance
A CCB plan shall be established and implemented, and the CCB plan shall include how software change requests are prepared, submitted, processed, and tracked.
The IAM and the site's lead developer/programmer shall authorize and document the roles, responsibilities, and privileges for all personnel allowed making software development changes.
Systems shall include technical features that implement a role- based access scheme to assure program modifications are made by authorized personnel.
The software developer's user accounts shall be limited to the minimum number of permissions needed to perform their assigned duties.
The Georgia Army National Guard decided on Patchlink UPDATE which provides both client-side and server-side patch management and limited software distribution.
Patchlink is based on PatchLink's automated the GaARNG patch detection and deployment, enabling the management and distribution of critical patches and software packages that resolve known security vulnerabilities. The replication service is a component on the Patchlink server which that retrieves the latest critical updates from the private PATCHLINK UPDATE Master Archive. As new updates become available to the Patchlink Update Master Archive, the Meta data is downloaded and if patches are critical, they are downloaded and set for rapid installation. Information is sent in one direction only; from the Master Archive to the user's PATCHLINK UPDATE Server. When new patches are released, the PATCHLINK UPDATE Server downloads the proper fingerprint from the PATCHLINK UPDATE Master Archive and then checks to see if there are any computers that meet the profile by sending the fingerprints to the workstations to be scanned. The administrator is then notified of the new patch and its impact to the work environment. The report matrix quickly informs the administrator which computers or groups need the patch and which do not. The administrator simply selects an individual computer or a group and then deploys. The administrator can set the time of the deployment and decide whether or not to reboot after the patch installation.
In a managed data center, the administrator creates a group for each cluster of servers. This will help the administrator manage large numbers of servers easily. Administrators can test all critical updates published from the PATCHLINK UPDATE Master Archive service before they are deployed to client computers on the network. After the testing has been successful, the administrator can then deploy the patch to all or just a group of servers. The use of agent policies will help the administrator to setup the hours of operation for each group of servers.
The prioritized restoration plan shall be periodically reviewed and updated. Mission and business-essential functions are identified for priority restoration planning along with all assets supporting mission or business-essential functions (e.g., computer-based services, data and applications, communications, physical infrastructure).
Without implementing transaction roll-back and journaling, unauthorized or unintentional modification or destruction of data stored in the database would cause the loss of critical data. This implementation guide is aimed to help database administrators ensure the recovery of database data that was modified or deleted unintentionally or by unauthorized users. The database administrator shall identify and determine if the database systems (e.g., Oracle, Microsoft SQL Server) implemented into the system provide transaction capabilities (e.g., transaction roll back and transaction journaling). If the database systems do not provide the transaction roll back and journaling or technical equivalent, the database administrator shall: Identify a DoD approved 3rd party product that provides transaction roll back and journaling or technical equivalent · Configure the product and test it in a lab environment to ensure it functions properly. Install the product on the database system in the operational environment
Without regular conformance testing being performed, system vulnerabilities could not be identified and fixed in a timely manner. This implementation guide is aimed to help patch management schedule and perform regular conformance testing to identify threats to and vulnerabilities of the system and implement countermeasures to mitigate or eliminate potential risks.
The patch management shall develop a conformance testing plan that includes the following information:
Type of conformance testing (e.g., vulnerability assessment, security test and evaluation [ST&E], internal and/or external penetration testing)
Schedule of the testing either periodic (e.g., quarterly) or unannounced · Resources required to perform individual testing
Tools to be used for conformance testing (e.g., Internet Security Systems (ISS) Vulnerability Scanner, FSO Gold Disk, nmap, nessus, Retina).
Current Information Assurance Vulnerability Alerts (IAVA), IAV Bulletins (IAVB), and IAV Technical Advisories (IAV-TA).
Other vulnerability and patch information from vendors, Common Vulnerabilities& Exposures (CVE), etc.
The patch management shall determine if the conformance testing will be performed using in-house resources or outsourced.
The patch management shall establish a conformance test team (e.g., Test Engineer, Test Reviewer).
For penetration testing, the patch management shall ensure to establish a "White Cell" to coordinate the penetration testing.
The test team shall install required testing resources on the workstations/laptops to be used for the testing and configure them properly.
The test teams shall perform the testing based on the approved rules (e.g., ST&E Plan, Rules of Engagement) and document the test results.
The patch management shall review the results of the conformance testing and countermeasures to mitigate the identified potential risks.
The patch management shall develop a Plan of Actions and Milestones (POAM).
The patch management shall implement the recommended countermeasures based on the POAM to ensure that the system's IA capabilities provide adequate assurance against constantly evolving threats and vulnerabilities.
In summary, today's network environments are dynamic, requiring a multitude of defense measures to effectively prevent attacks and efficiently mitigate vulnerabilities across the entire enterprise. GaARNG used Windows Update Server (WUS) and System Management Server (SMS) for distributed patch management to maintain 1,000 Windows XP clients, 1, 500 Windows Vista, 90 Windows 2003 Servers, 1 Linux and HP server. But with no appropriate Microsoft Office updates are displayed when you use Microsoft Update or Windows Server Update Service. Office updates would not successfully install because the path of the local installation source kept changing. By installing Patchlink the GaARNG was able to keep up with the sheer numbers of patches for multiple nodes. Additionally, PATCHLINK UPDATE provides the support for all common operating systems like anti-virus, firewalls and database servers from many different vendors. PATCHLINK UPDATE provides the GaARNG with the most complete distributed patch management solution.
