Thanks for the explanation Shawn.
While I knew there was a vision statement relating to CCRA last year, I wasn't aware that transitional arrangements had effectively come to an end.
With the drop from EAL4 to EAL2, the assurance users could expect to receive would fall mostly on product testing. Much of the evidence of security engineering and process-based assurance would go unevaluated, which I think does go to the security of version vSphere 5.1 (over 5.0) as a maintenance report isn't being used to address it.
Some of the changes between the last two vSphere Security Targets (say, some data protection moving between classes) have indicated potential testing differences, if not differences in security function implementations. The future use of one or more Protection Profiles for vSphere evaluations would likely reduce the importance of closely following STs between releases, however users may wish to make new assumptions about threats and protections after carefully considering the vSphere 5.1 ST until then.
Unfortunately there is a bit more work in securely using vSphere than certified Type 2 hypervisors as those other evaluations may reference a General Purpose Operating System PP. With a software ecosystem as large and detailed as VMware's is becoming, a single PP seems infeasible for vSphere let alone vCloud. That timing resulted in an inconsistent leveling for vCNS and vSphere (and tcServer) is understandable, but this update is still odd for not discussing composition assurance and packaging.
It is understandable that VMware would prioritise persuing evaluations that are most widely recognized and required. The reason for the drop from EAL4+ to EAL2+ is therefore quite clear, although not necessary.
With much of the burden of evidence-based evaluation lifted from VMware for CC certification, one would expect the continuing commitment to security and compliance to conspicuously appear elsewhere.
Do you know if the Flaw Remediation requirements of the Lifecycle Support Class will still form part of the mutual recognition arrangement for non-PP evaluations?
I'd suggest the discovery or introduction of security vulnerabilities - that were not publicly known or present at the time of evaluation - is of great practical importance to users. It would be of reassurance, I think, if your lab were to evaluate evidence of VMware's continued conformance to ALC_FLR.2. Likewise, I think it would be of great reassurance if VMware comitted to timely correction of flaws by submitting its processes to an evaluation of ALC_FLR.3.
- Shanon