best practices for end point and patch assesment

Hello all,

What are the best practices for patching on desktop running windows OS. we deploy patches using WSUS currently.

shyam pothiniAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jane UpdegraffSr. Systems AdministratorCommented:
Obviously there is going to be a wide range of opinions on what could be defined a best practices for patching ... but by and large, you establish a test group where you deploy whatever current patches exist for the Windows desktop OS service branch you have chosen .. I recommend sticking with the "Current Branch for Business" or CBB rather than the "CB" which includes less well-tested patches .... deploy to the test group for a few days (make sure it has some actual production workers in it who are reactive enough to actually report problems to you) and once the patch group has been confirmed to not break anything important, you deploy that group across the enterprise using whatever mechanism you like to use. In the case of Windows desktop updates and your existing network, that would be using WSUS. Then rinse and repeat. You use the same general rules for other patching as well, and for updating client versions of whatever enterprise apps you use.

Is that what you are asking or were you looking for something more specific?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
aravind ancheWindows/Vmware Commented:
Step 1: Develop an up-to-date inventory of all production systems, including OS types (and versions), IP addresses, physical location, custodian and function. Commercial tools ranging from general network scanners to automated discovery products can expedite the process (see Resources, below). You should inventory your network periodically.

Step 2: Devise a plan for standardizing production systems to the same version of OS and application software. The smaller the number of versions you have running, the easier your job will be later.

Step 3: Make a list of all the security controls you have in place--routers, firewalls, IDSes, AV, etc.--as well as their configurations. Don't forget to include system hardening or nonstandard configurations in your list of controls. This list will help you decide how to respond to a vulnerability alert (if at all). For example, let's say you learn that OpenSSH has a vulnerability that may allow a buffer-overflow attack, but from your list of controls you know you don't allow the SecSH protocol through your firewall. If nothing else, that knowledge gives you more time to react.

Step 4: Compare reported vulnerabilities against your inventory/control list. There are two key components to this. First, you need a reliable system for collecting vulnerability alerts. And second, you need to separate the vulnerabilities that affect your systems from those that don't. Some companies have staff dedicated to managing this process; others use vulnerability reporting services.

Step 5: Classify the risk. Assess the vulnerability and likelihood of an attack in your environment. Perhaps some of your servers are vulnerable, but none of them is mission-critical. Perhaps your firewall already blocks the service exploited by the vulnerability. In general, to classify and prioritize the risk, consider three factors: the severity of the threat (the likelihood of it impacting your environment, given its global distribution and your inventory/control list); the level of vulnerability (e.g., is the affected system inside or outside perimeter firewalls?); and the cost of mitigation and/or recovery.

Step 6: Apply the patch! OK, so now you have an updated inventory of systems, a list of controls, a system for collecting and analyzing vulnerability alerts and a risk classification system. You've determined which patches you need to install. Now comes the hard part: deploying them without disrupting uptime or production. Fear not, there are several tools that can help you with the actual patch process (see Resources, below). Evaluate these tools in terms of how well they fit your environment and budget. In some cases, manual patch maintenance may be more cost-effective. But in most cases--particularly for multiple servers or server farms distributed across multiple locations--some type of automated patch system will more than pay for itself.
shyam pothiniAuthor Commented:
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Operating Systems

From novice to tech pro — start learning today.