UP L04 Introduction to 3 rd Party Patching Using the 4A Model Hands-On Lab Description The objective of this course is to introduce students to the various concepts of 3rd party patching. Students will model several use cases whereby various non-microsoft applications. Students will report on which installed applications require updates and then follow through by patching each of the applications. The instructor will relate this process to the standardized "4A Model" or a best practice approach. At the end of this lab, you should be able to Understand Patch Management configuration options Report vulnerabilities on all computers with the software update agent installed Report on individual computers update needs Understand how to use the 4A model to create best practices Review common patch problems Deploy updates Create policies Notes **Note This lab is not about configuring Patch Management Solution. A significant amount of basic configuration has been completed prior to the lab. A brief presentation will introduce this lab session and discuss key concepts. The lab will be directed and provide you with step-by-step walkthroughs of key features. Be sure to ask your instructor any questions you may have. Thank you for coming to our lab session.
Table of Contents UP L04 Introduction to 3 rd Party Patching Using the 4A Model Hands-On Lab... 1 Introduction to the 4A Model... 3 Assessment Phase... 3 Step 1 Identify New Updates... 3 Step 2 Review the Nature of the Vulnerability... 5 Step 3 Devices Affected... 5 Step 4 Define Custom Security Levels... 7 Step 5 Assign Custom Severity Levels... 8 Analysis Phase... 11 Application Phase... 12 Step 1 Creating the Update Policies... 12 Step 2 Processing the Policy... 14 Step 3 Reporting on Status... 19 Advancement Phase... 21 2 of 21
Introduction to the 4A Model Given the challenges involved, many organizations have found it advantageous to manage the software update process by following a best practice approach based on predictable, orderly, and repeatable processes that can be sized based on their needs and the resources available to them. One such approach is the 4A model, which seeks to strike the optimal balance between risk on one hand and the cost and impact involved in mitigating that risk on the other hand. The 4A model includes four phases: the Assessment phase, the Analysis phase, the Application phase, and the Advancement phase. Because the names of each phase begin with the letter A, this approach is known as the 4A Model. Assessment Phase The first phase of the software update process is the Assessment phase. The Assessment phase is the phase where the security team is most actively involved. The goals of the Assessment phase are to become aware of new updates, evaluate them, and prioritize them. This requires the security team to review security advisories/bulletins describing vulnerabilities, threat management alerts/feeds describing known exploits of those vulnerabilities, and information about the potential impact of the vulnerabilities on their environment. The security team uses this information to create a Risk Assessment, which prioritizes each of the updates. Step 1 Identify New Updates 1) Switch to the NS75 virtual machine and open the Symantec Management Console by double clicking on the desktop icon 2) Navigate to Home-> Patch Management-> 3) On the left side of the screen click on the link for Bulletins and Updates Note: This is typically the default screen for the Patch Management home page 4) After the report screen finishes loading, locate the column labeled Released and click it until you are sorted by descending This sorts all of the updates by most recent date top to bottom 3 of 21
5) From here we need to look at just the Adobe updates that have been released. From the Vendor drop down select Adobe 6) Press the Refresh button located on the menu bar (not the browser refresh button) 7) Now we need to organize the report by criticality. On the upper right side of the report menu bar locate the Group by drop down and select Severity This will create a tree view of all the Adobe updates 4 of 21
Step 2 Review the Nature of the Vulnerability After identifying the new updates that have been released since your prior rollout, the next step in the Assessment Phase is to understand the nature of the issues being addressed by those updates. This can only be done by reviewing the vendor security bulletins, security advisories and KB articles associated with the updates. 1) Since there is no unified mechanism for review details about any particular update (each process is vender specific) we have included a URL to show an example of what one would look like: http://www.oracle.com/technetwork/java/javase/7u17-relnotes-1915289.html It is a best practice to research all potential updates before they are deployed to the population. This is not always feasible in every situation but it can eliminate a large number of problems up front. Step 3 Devices Affected Once the nature of the issues addressed by the new updates is determined, the next step in the Assessment Phase is to develop an understanding of the number of devices in your environment that may be affected. 1) In the Symantec Management Console navigate to Reports-> All Reports 2) Expand Software-> Patch Management-> Compliance-> 3) Click on the Windows Compliance by Bulletin report to run it 4) Now that the report has been generated you have the ability to manipulate several of the sorting parameters as well as the date ranges. Sort the report defensing by compliance. 5) Filter out everything except for Windows 7 Professional by selecting it from the Operating System: drop down. 5 of 21
6) We are only concerned about updates that have been released in 2013. Use the Release Date From: parameter to filter the date 7) Press the button to reload the report with the new set of parameters 8) Locate the MS13-022 bulletin, right click on it and select View Not Installed Computers by Bulletin Note: This will open a new tab with a custom report showing which computers need this specific update. Additional custom reports can be created to tailor the solution to fit any current internal process you may have at your company 9) Close the custom report tab 6 of 21
Step 4 Define Custom Security Levels After becoming aware of new updates that are available and gathering information regarding devices in the environment that require those updates, the security team can then prepare a Risk Assessment prioritizing distribution of the updates. One way that this can be done is by using the Custom Severity functionality in the Patch Management Solution. Application vendors assign their own severity rating to security bulletins. However, those ratings do not account for factors unique to each organization s environment. For example, Microsoft may rate a security bulletin related to vulnerability in Internet Explorer to be Critical. While the vulnerability may be considered critical to those who use Internet Explorer, its potential impact on your organization may be much less severe if your organization s standard calls for employees to use another browser such as Chrome or Firefox. The Altiris Patch Management Solution allows users to assign custom severity ratings to software bulletins. The Core Services page of the Patch Management Solution, which you see here, allows you to define the values for the Custom Severity data element. In this example, three different Custom Severity values will be defined: Severity 1 for updates involving a vulnerability or issue that could have a significant impact on the organization Severity 2 for updates involving a vulnerability or issue that could have a moderate impact on the organization Severity 3 for updates involving issues that are likely to have a minimal impact on the organization 1) Navigate to Settings-> All Settings-> 2) Expand Software-> Patch Management-> 3) Select Core Services 4) On the right side of the screen click on the Custom Security tab 5) Enter: Severity 1 into the Security Level box and press Add 6) Repeat this process for Severity 2 and Severity 3 7) Finally, enter: Known Issue into the Security Level box. Your screen should now look like this: 7 of 21
8) Press Save Changes Note: This process edits the right click menu in the Patch Management reports windows. It allows you to set custom severities on individual and/or groups of updates. This process may be repeated or updated as needed as many times as your organization needs Step 5 Assign Custom Severity Levels After defining the values for the Custom Severity data element, the security team can assign a custom severity rating to each bulletin to assist the IT operations team in prioritizing the distribution of updates. Most organizations consider updates that do not have security implications to be of the lowest priority. Updates that address issues that have security implications but which are not likely to have an immediate and significant impact on an organization are usually considered to be of the second highest priority. Many organizations consider out of band releases from vendors that are assigned a severity rating of Critical by the vendor to be of the highest priority. In many cases, organizations rate security bulletins released as part of a vendor s normal release cycle as being of the second highest priority. Those updates which are not security related are often given the lowest priority. Because such updates tend to be less critical, organizations typically distribute them less frequently (e.g. quarterly or bi-annually). 1) While still in the Symantec Management Console navigate to Home-> Patch Management 2) Select the Compliance by Computer report on the left side of the screen 3) Locate and highlight the WIN7 computer 4) Right click and select View Not Installed Updates Note: This will open a new custom report window 8 of 21
5) Locate and highlight MS13-022 and APSB13-09 Note: Use ctrl + left click to highlight multiple items 6) With the two updates highlighted, right click on one of them and choose Custom Severity-> 01 Severity 1 7) Locate and highlight MS13-021, JAVA6-43 and MS13-A01. Set their custom severity level to Severity 2 using the method from the previous exercise 8) Finally, locate and highlight AQ12-002 and MS12-046. Set their custom severity level to Severity 3 9) Close the custom report window/tab 9 of 21
10) Review the custom severity settings by clicking on the Compliance by Bulletin link on the left side of the screen 11) Set the following parameters: Vendor: Operating System: Distribution Status: Any Any All 12) On the upper right side of the report menu bar select the Group by: drop down and choose Custom Severity 13) Refresh the report by pressing the button. Your report should now look like this: 10 of 21
14) Expand each of the custom severity tress (leave the Not Set tree collapsed). You should see the seven updates that were manipulated in previous exercises *** Do not close this page Analysis Phase The second phase of the software update process is the Analysis phase. Think of the Analysis phase as change management applied to the software update process. The Analysis phase involves defining the full scope of a rollout, understanding the potential impact of the rollout, and developing a plan to mitigate risk if something goes wrong with the rollout. The starting point for the Analysis phase is the Risk Assessment produced the Security Team as part of the Assessment phase, which prioritizes the various updates. The primary deliverable coming out of the Analysis phase is the Remediation Strategy, which identifies the updates to be distributed, endpoints to be included or excluded, and the roll back plan to be used in case things go astray. Because this particular topic is very abstract it is difficult to demonstrate in a lab environment. The deliverables, digital or otherwise, will very much depend on the available resources, maturity and scale required to create a recovery plan. Symantec has many solutions that assist with various aspects of this process. For the purposes of this lab we will leave this topic to Q&A. Regardless of the resources at your disposal it is highly recommended that everyone that could potentially be affected by failed patch deployment be made aware of the situation, even if ultimately you are unable to implement a proper and useful disaster recovery plan at this time. Disastery recovery (or lack there of) plans can and should have a significant impact on how and when updates are applied to various systems in the environment. 11 of 21
Application Phase The third phase in the software update process is the Application phase. The Application phase is the phase that many in this room may be most familiar with. It is the phase in which the IT operations team is most actively involved, rolling out updates based on the Remediation Strategy created during the Analysis phase. The overall goal of the Application phase is to ensure that updates are rolled out on a timely basis, while appropriately mitigating risk and minimizing disruption to the business. The primary deliverable of the Application phase is a Compliance Report, verifying that the updates were successfully rolled out. Step 1 Creating the Update Policies The first step involved in Phased rollouts is to create a Software Update Plug-in Policy for each group of computers one for the Test Group, one for the Pilot Group, and one for each of the groups of computers in the production environment. The Software Update Plug-in Policy not only defines the default installation schedule for the computers that it targets and includes Start and End Dates. The Start Date can be updated at the start of each rollout cycle to ensure that new updates don t get rolled out to a particular group of computers until it is time to do so. 1) While still on Group by Custom Severity report page (created in the last exercise) highlight the updates in the Severity 1 group (MS13-022 & APSB13-09) Use crtl + left click to highlight multiple lines 2) Right click the highlighted updates and select Distribute Packages from the menu The Software Update wizard loads 3) Change the name of the policy to Critical Updates Deployment 12 of 21
4) Expand the Package Options and check the boxes for Allow immediate restart if required & Run (As soon as possible ) 5) In the Apply to computers section, highlight the Windows Computers with Software Update Plug-in Installed Target line item and press the button 6) Press the button and select Computers from the list The Filter wizard loads 7) Press the Add rule button and create your filter with the following parameters: exclude computers not in Computer list WIN7 8) Press the Update results button. You should now see the WIN7 computer in the filter list 9) Press OK. Your Policy should now look like this: 10) Press Next > 11) Enable the policy by press the red orb button ( ) and choosing ON ( ) 13 of 21
12) Press the Distribute software updates button to deploy the updates In a production environment rather than selecting an individual computer to deploy the first round of updates to we would use a test group that would have been created prior to creating the policy. Assuming there aren t any problems in the test group, the policy would then be cloned and applied to additional groups as necessary until the rollout is complete. Step 2 Processing the Policy It is important to note that this step will happen naturally, without manual intervention, based on the agent policies in your environment. We are simply forcing the process for the sake of time. 1) On the NS75 virtual machine locate and click the shortcut for the Windows Task Scheduler on the Start Bar 2) After the Task Scheduler loads, select the Task Scheduler Library on the left side of the screen Note: Many of the schedules that the Symantec Management Platform utilizes are located on this screen. It is import that you take extreme caution when modifying the scheduling settings. Even something as simple as changing an interval from 60 minutes to 30 minutes may have a dramatic effect in your environment. Always consult Symantec documentation or a certified partner for advice 3) Sort the Name column ascending (Z-A) by clicking on the name column once If performed correctly, the first line item should be NS.Windows Patch Remediation Settings. {GUID} 4) Highlight it, right click and press Run 14 of 21
5) This process can take anywhere from 60 seconds to 15 minutes to complete. In our lab it should take approximately 2 minutes. Press the Refresh button in the Actions pane to the right periodically to view status. Once your status changes from to you may proceed to the next step Note: As previously mentioned this process will happen naturally on a scheduled basis. It essentially associates the newly created Patch Policies with the appropriate targeted resources 6) Switch to the WIN7 virtual machine 7) Double click the Symantec Management Agent Icon in the system tray 8) Press the button to bring up the agent settings screen 9) Locate and press the Update button to force the agent to check in with the management server If performed correctly, you will see the Changed time stamp closely match the Requested time stamp 15 of 21
10) Back on the Symantec Management Agent screen, select the Software Updates tab 11) Once the agent receives the policy and processes it, you should begin to see the updates listed on the screen: 12) Again, this next set of steps would happen automatically but in order to speed it along, locate the Start Software Update Cycle link on the bottom right of the Agent page and press it Note: You may have to wait a few minutes for any current processes to finish (the agent may be in the middle of an Inventory, etc) 16 of 21
13) After a brief period, you will see a notification screen like this: Feel free to wait or press Install now to begin the update process Note: The notification itself as well as the amount of time given to the user can be configured based on your companies requirements The updates will now go through a series of steps while they are process, installed and verified. You will typically see a set of assigned updates in this status when they are ready to be installed, but waiting for a specific time to execute (in our case we are waiting on the Patch engine to make sure the updates are still applicable to this specific computer): 17 of 21
14) Press the Start Software Update Cycle link again to force the update process to proceed After a few moments you should see that status change to Installation in progress and then to Verification. The Verification step runs another Assessment Scan to make sure the updates were installed correctly Once the installation has completed successfully, the status will change to reflect the success: 18 of 21
Step 3 Reporting on Status After the updates have been installed you can report on the state of each of the computers that were part of the patch cycle. Since the patch process is in constant communication with the management server, this data is readily available 1) Switch to the NS75 virtual machine 2) Open the Symantec Management Console and navigate to Home-> Patch Management Note: There are several ways to report on update status. You can view the resource to see if the update is missing/needs to be installed. You can see all of the applicable updates and their installation status as well as look at the individual logs for each policy deployment. For the purposes of this lab we are going to focus on the more global approach by looking at all applicable updates 3) Select the Compliance by Computer report on the left side of the screen 4) Locate and highlight the WIN7 computer 5) Right click and select View Applicable Updates This dynamic report will show us all of the updates that apply to this resource and their installation status 6) From here we can search for the specific updates that were installed via the policy created in the previous steps. Locate the Search bar in the upper right and enter: MS13-022 19 of 21
7) The report will filter the results and show us the MS13-022 update. Note that its Installed status is True As previously mentioned there are numerous methods for presenting patch status data and an almost unlimited combination of data may be displayed via custom reporting. In production these reports would be tailored to meet the specific needs of the individuals who are responsible for reviewing the data 20 of 21
Advancement Phase The fourth and final phase of the software update process is the Advancement phase. Think of the Advancement phase as the continuous improvement part of the process. This part of the process often utilizes a lessons learned type of approach and usually involves all of those who play an active role in the process. The primary goal of the Advancement phase is to fine-tune and optimize the process. It is important to understand that the patch management process is constantly evolving. There are many individual roles and specific responsibilities that are often performed by a single individual and should probably have several teams involved. Whether it is resource constraints or something else the most important thing that can be done is to modularize the process and collect data along the way. Collecting data from each step allows for a post mortem analysis of the process and modularizing the process allows you to quickly fine tune at a granular level without having to rewrite the entire process itself. This concludes the hands on portion of the lab. 21 of 21