Patching isn't as common or easy as many wish to think. It is one of the biggest reasons why we see an increase of successful cyber-attacks today. Without patching, many of the assets within the organization are prone to vulnerabilities that can be exploited by a perpetrator either internally or externally and lead to a data breach or severe impact the availability of the systems impacted, those leading to possible data loss and financial implications. Making this one of the most important steps for addressing and limiting cyber-attacks across the organization. This blog provides an overview of the key processes that must take place within the organization to successfully limit cyber attack vectors.

Importance of Configuration Management (CM) and Control Change Board (CCB)

Before patching takes place, an organization must have a clear Configuration Management Plan in place clearly delineating all of the components associated with a system that require patching and the steps to be taken by all parties involved in the review and approval process. Once the Configuration Management Process is in place, the organization should establish a Control Change Board (CCB) team that encompasses all parties involved with the application to review all recommended patches, the risk introduce or to be mitigated (if any), the security impact (if any), and whether or not the recommended patch is approved for deployment in a PRODUCTION environment after being approved by all members of the CCB. Once approve, the process should track the outcome of the patch to ensure it worked as intended and that it was applied within the approved date and time in accordance with the configuration management process.

It is essential to understand that before patching takes places, the patch in question must be first tested, examined for possible security impacts, and be approved as part of the organization's Configuration Management Plan (CMP). The problem we see today is that, not all organizations have a process, and not all OSI layer components are addressed accordingly, mainly because updating of such technologies falls under different Information Technology groups. In this article, we will examine the importance of Patching and its associated processes.

There's many reasons why CM and CCB are essential, but the following are key:

• Risk Impact Mitigation and Prioritization;
• Security Impact Implications Discovery and Mitigation Steps and/or Alternative Countermeasures in place limiting impact;
• Monitoring of System Changes to address Accountability and ensure changes were tested, reviewed, and approved; and
• Accurate Representation Reports for Approved Changes to help Incident Response Teams narrow down unapproved changes

Defense In-Depth Patching

Defense in-depth denotes the importance of patching all layers of the OSI accordingly. This means understanding the individuals responsible for each individual layer. The table below provides a general breakdown of the layers, the responsible parties, and the key areas that must be monitored for security related updates. When patches are applied across all layers in a timely manner, the impact of a cyber attack against those layers is slim.

Layer	Description
Application	The patching process differs per application type (i.e., Commercial Off-the-shelf (COTS), In-house Developed, Government Off-the-shelf (GOTS). Caution must be exercise before applying patches on this layer within the Production environment. All patches impacting the application layer MUST be coordinated with the Network Team. As best practice, developers and/or application engineers should be restricted from patching PROD environments unless the patch requires special expertise. This will ensure that the Network Team is fully aware of the change and can take the necessary steps to recover the systems to it's last known state IF the patch impacts the functionality of the application and/or environment. Responsible Parties- ISSO, Application Development Team, Software Engineering Teams COTS/GOTS Software -Security patches and/or version updates can be tracked through the vendor's website and/or repository, and in some instances automatically downloaded. Middleware Software- This is the underlying software (i.e., JAVA, Apache, IIS, etc.) that lies between the OS and the application required for the application to function properly. Security updates and/or version updates can be tracked via the providers website if not automatically discovered. In-House Developed Software- The development team is responsible for developing the appropriate patches in accordance with the organization's Software Engineering practices and it's associated System Development Lifecycle (SDLC) process.
Operating System	The Operating Systems can be set to automatically update itself and key applications attached to the OS; however, in some cases, updates must be performed manually. There's many ways to approach security patches at the OS layer. Automated updates are typically applied on the User's Workstations but restrained at the Server Level until they have been tested and validated, as they can impact the applications being run by the servers and have a major disruption on the organizations network. Responsible Parties- ISSO, Defense In-depth Team, Network Administrators/ Engineers Defense In-Depth Team Task(s):The Defense in-depth team is responsible for initiating an in-depth analysis of the Operating System to identify vulnerabilities and/or licensing and end-of life issues that can introduce risks into the organization. Network, Perimeter, and Application Administrators/Engineers They must work closely with the ISSO to test all patches required in order to identify security impact and initiate the Configuration Management Plan (CMP) process prior to implementation. Once patches are approved, they are responsible for implementing such within the timeframe agreed upon. ISSO- Must ensure patches are applied and tracked in accordance with the organizations POA&M process and validate the security impact with the teams impacted. Must represent the teams during the Configuration Control Board (CCB) meetings to ensure it moves forward IF no major security concerns are identified.
Network Devices	The identification of patches required at this level fall under the ISSO, Network and Defense In-depth teams as part of Continuous Monitoring. The Defense In-depth team should perform testing on the organization's firewalls, virtual or physical, to identify vulnerabilities and the Network team should monitor the vendors website for security patches, firmware updates, and/or end of life support dates impacting the component.
Role-Based Servers	The identification of patches required at this level fall under the ISSO, Network and Defense In-depth teams as part of Continuous Monitoring. Patching of the underlying Roles found within the servers, which can be considered middleware as they are required for the application to function properly, must be maintained. Server roles that tend to fall under this category are Web Servers (i.e., Apache, ISS), Email Servers (i.e., SMTP), Account Management Servers (i.e., LDAP, AD [Kerberos]) , to mention a few.
Databases	The identification of patches required at this level fall under the ISSO, Database Administrators and Defense In-depth teams as part of Continuous Monitoring. The Defense In-depth team should scan the DBs for security vulnerabilities and provide a report to the ISSO. The ISSO and the Database Administrators should keep track of the vendor's security patches and updates on a continuous basis to address concerns in a timely manner. Failures to patch this layer can lead to data leakage.

Importance of Components tracking

One important task for ensuring that defense in-depth patching is applied across the organization correctly is to keep a list of all of the components linked to the system and the associated vendor/supplier links listing the security updates and/or patches of the system. One step that should take place biweekly for systems deemed MOD or HIGH and weekly for systems deemed MISSION CRITICAL. This components can be tracked as an appendix to the Information's Systems Configuration Management Plan, which should be a sub-component of an Enterprise Level Configuration Plan.

How can CyberAdeptness help?

There's two components to Configuration Management, and both are key. However, each component falls under a different role. The roles are:

• Information Systems Security Officer (ISSO) The development of an Information Level Contingency Plan is part of the duties assigned to the ISSO as part of the Security Documentation required to successfully complete the Accreditation of the System.
• Chief Technology Officer (CTO) The development of an Enterprise Level Contingency Plan falls under the CTO. The rational for this is that it's meant to be a unified process across the organization those streamlining the process at the Information System Level to only the essential items impacting the system itself.

Interested on learning more? Contact US via our site form at https://www.cyberadeptness.com 

NOTE: Due to security concerns, we limit our web content to bare bones. Please note that you will receive a response within forty-eight (48) hours or less.