And this has what to do what with Vista?
It's an excellent illustration of what can happen to you when you literally bet the life of your company on Microsoft's ability to deliver a secure product. Of all the merits of Visa, Microsoft focusing on security is just plain dumb, to the point of being laughable. They can't even secure their server products.
I guess this mean you consider the new sandboxing feature of WinServer08 and Vista worthless?
I don't care if it's an IBM mainframe, a sandbox is an infrasturcture partition, not an OS or logical one. I realize it'll save smaller companies money, but from a PII perspective, I think it'll cause more problems than it will solve.
How do you think a sandbox would fit into a trusted computing model? especially in an environment where trusted is defined at a circuit level?
Microsoft products don't rate above C1 on the Trusted Computing scale, so perhaps it's the definition of security that is at issue.
In the WinServer08/Vista instance they've extended the concept to a network level.
Can you drop me a link on who is determining the C1 scale? I'd like to read how they are testing and what criteria they're using...you know, the usual BS.
http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteriahttp://en.wikipedia.org/wiki/Common_CriteriaYou could maybe make a case that MS is B1, but it's unlikely. Also, I misspoke, Server is C2 not C1.
Divisions and Classes
The TCSEC defines four divisions: D, C, B and A where division A has the highest security. Each division represents a significant difference in the trust an individual or organization can place on the evaluated system. Additionally divisions C, B and A are broken into a series of hierarchical subdivisions called classes: C1, C2, B1, B2, B3 and A1.
Each division and class expands or modifies as indicated the requirements of the immediately prior division or class.
[edit] D — Minimal Protection
Reserved for those systems that have been evaluated but that fail to meet the requirements for a higher division.
[edit] C — Discretionary Protection
C1 — Discretionary Security Protection
Separation of users and data
Discretionary Access Control (DAC) capable of enforcing access limitations on an individual basis
C2 — Controlled Access Protection
More finely grained DAC
Individual accountability through login procedures
Audit trails
Resource isolation
Required System Documentation and user manuals.
[edit] B — Mandatory Protection
B1 — Labeled Security Protection
Informal statement of the security policy model
Data sensitivity labels
Mandatory Access Control (MAC) over select subjects and objects
Label exportation capabilities
All discovered flaws must be removed or otherwise mitigated
B2 — Structured Protection
Security policy model clearly defined and formally documented
DAC and MAC enforcement extended to all subjects and objects
Covert storage channels are analyzed for occurrence and bandwidth
Carefully structured into protection-critical and non-protection-critical elements
Design and implementation enable more comprehensive testing and review
Authentication mechanisms are strengthened
Trusted facility management is provided with administrator and operator segregation
Strict configuration management controls are imposed
B3 — Security Domains
Satisfies reference monitor requirements
Structured to exclude code not essential to security policy enforcement
Significant system engineering directed toward minimizing complexity
A security administrator is supported
Audit security-relevant events
Automated imminent intrusion detection, notification, and response
Trusted system recovery procedures
Covert timing channels are analyzed for occurrence and bandwidth
An example of such a system is the XTS-300, a precursor to the XTS-400
[edit] A — Verified Protection
A1 — Verified Design
Functionally identical to B3
Formal design and verification techniques including a formal top-level specification
Formal management and distribution procedures
An example of such a system is SCOMP, a precursor to the XTS-400
Beyond A1
System Architecture demonstrates that the requirements of self-protection and completeness for reference monitors have been implemented in the Trusted Computing Base (TCB).
Security Testing automatically generates test-case from the formal top-level specification or formal lower-level specifications.
Formal Specification and Verification is where the TCB is verified down to the source code level, using formal verification methods where feasible.
Trusted Design Environment is where the TCB is designed in a trusted facility with only trusted (cleared) personnel.