UP L04 Introduction to 3 rd Party Patching Using the 4A Model Hands-On Lab

(1)

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.

(2)

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

(4)

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”

(5)

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.

(6)

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

(7)

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”

(8)

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”

(9)

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”

(10)

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: Any

Operating System: Any Distribution Status: All

12) On the upper right side of the report menu bar select the “Group by:” drop down and choose “Custom Severity”

(11)

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.

(12)

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

(13)

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 >”

(14)

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}”

(15)

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

(16)

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

(17)

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

(18)

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

(19)

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

(20)

7) The report will filter the results and show us the MS13-022 update. Note that its “Installed” status is “True”

(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.

UP L04 Introduction to 3 rd Party Patching Using the 4A Model Hands-On Lab