DRaaS Portal, Security Announcements, vSphere 6.7

Hi everyone!

Based on the input I received from my last letter, I thought I would make these updates more regular. Look for mid-week updates, if I have anything to say.

Improved DRaaS Architecture

VMsources has implemented a Web Portal for all DRaaS customers (in addition to the existing Veeam Console) that will allow you to view and manage backups and Failover from any location that can facilitate https access. Please contact VMsources to schedule a meeting and we’ll go over IP addresses and credentials for access to your portal.

What the HTTPS portal does What the HTTPS portal does not do
  • Allow authorized users to initiate restore
  • Allow authorized users to initiate failover
  • Allow authorized users to view jobs
  • Allow authorized users to generate reports
  • Allow restores to be directed outside protected channels
  • Allow failover to be initiated to any other than established DR Sites

VMware vSphere 6.7

VMware vSphere 6.7 is ready for Prime Time, but the question is: are you ready for vSphere 6.7?

vSphere 6.7 has significant improvements, especially regarding resources consumed by the VCSA (vCenter) itself. The upgrade process is smooth and painless (as long as you have supported hardware) and we have documented that process on a new YouTube video and SBS LAB for your convenience.

You should upgrade to VMware vSPhere 6.7 if:

  • You have already upgraded to vSphere 6.5. Current users of vSphere 6.5 have nothing to loose and much to gain by upgrading to 6.7
  • You stand to benefit significantly by some of the new features in vSphere 6.7

You SHOULD NOT upgrade to vSphere 6.5 or 6.7 if:

At this point, we are recommending users stay on vSphere 6.0 for at least another year unless they have a specific reason for upgrading. There is no reason to upgrade to vSphere 6.5 at this point, as it was a much more unstable release than 6.7 has proven to be. GO ahead and upgrade to vSphere 6.7 if it has features you can use AND your hardware is capable of running ESXi 6.7.

VMsources is available to upgrade or patch your VMware vSphere environments, please call 866-644-7764 or email for availability

New ESXi Security Patch CVE-2018-6974

VMware announced the release of a new patch for ESXi on Tuesday: VMSA-2018-0026 There are patches available for ESXi 6.0, 6.5 and 6.7. VMware describes these patches as CRITICAL in nature, but we (VMsources) only began validating them on Tuesday 10/16/2018, when the announcement was made.

You must decide for yourself how important these patches are as they are security related, however, past experience has proven that VMware can release patches that make systems unstable. I will advise about our testing and validation, as well as community reports of any side-effects of these patches in my next letter.

VMsources is available to install these patches, please call 866-644-7764 or email for availability.

Password recommendations is by NIST

For years, many of us have acknowledged the ultimate stupidity and counter-productive nature of requiring users to periodically update their passwords. The obvious and unavoidable result is that, after the second or third mandatory change, passwords will be written on post-it notes and stored in desk drawers and keyboards!

The good news is that about a year ago, the NIST issued Special Publication 800-63B, debunking many of the counterproductive policies foisted upon us by auditors and executives concerned more with the “letter-of-the-law” that actual security.

The DOs and DONTs:

The NIST uses the unambiguous terminology of “SHALL” and “SHALL NOT” in Special Publication 800-63B. I have distilled NIST recommendations to those points which apply directly to Kerberos based user directories such as Active Directory. Many of the recommendations below are directly contradictory to current policies and should be updated immediately.

Don’t forget, if you are running vCenter, you have a separate Kerberos directory known as SSO. Your SSO Directory contains at least one user, and those policies should be updated concurrently with AD to meet NIST guidelines.

  • DO allow use of passphrases
  • NIST Says (5.1.1.2): “Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets.”
  • DO allow the use of cut & paste for passwords
  • NIST Says (5.1.1.2): “Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret.”
  • DO favor users, not administrators
  • NIST Says (6.1.3): “password policies should be user friendly and put the burden on the verifier”
  • DO enforce password length
  • NIST Says (5.1.1.1) “Memorized secrets SHALL be at least 8 characters in length”
  • DO create a banned-list and compare passwords to known-bad passwords
  • NIST Says (5.1.1.2): “compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised”
  • DO enforce timeout for inactivity
  • NIST Says (4.3.4): “Reauthentication of the subscriber SHALL be repeated following any period of inactivity lasting 15 minutes or longer”
  • DO allow users to see their passwords in plain text
  • NIST Says (5.1.1.2): “offer an option to display the secret — rather than a series of dots or asterisks — until it is entered”
  • DO NOT require numbers, special characters or enforce composition rules
  • NIST Says (5.1.1.2): “Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.”
  • DO NOT use hints or questions
  • NIST Says (5.1.1.2): “Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”)
  • DO NOT enforce password aging
  • NIST Says (5.1.1.2): “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”

No Comments Yet.

Leave a comment