1. Strawman operating environment proposal Presented to P2600 Meeting #16, Las Vegas NV January 16-17, 2006 Brian Smithson

2. Problem: NIAP doesn’t like our definitions  “I am confused with the "high security" name being used. All environments have a need for high assurance (security) functionality.”  “If you are equating "High Security" with government why not call it Government Environment. High security at EAL2 is confusing. Like I indicated, all environments, including government, need high, medium and basic robustness protections.”  “I am not sure why you need a High Asset Value Environment, every environment ("Enterprise", "Public" and "Small Office - Home Office") have high value assets. Even in my home office I have high value assets (at least I consider them high value). An example may be my financial data, when I get on the Internet to pay my bills I do not want a hacker to get access to my checking account data. All the example you provided can be considered "Enterprise" environments. The only deference may be the threat to their high value assets and how much protection they need for those assets.”  [my emphasis]

3. Our environmental dimensions  Based on security level Concept is too subjective. Does anyone want “low security”?  Based on asset value Concept is too relative. Everyone highly values their assets. High - High security - Enterprise - Public - SOHO Low High - High security - Enterprise - Public - SOHO Low

4. Proposed new dimension: Accountability  Auditable environments: For handling information which is regulated by laws or conventions for handling information. Concerned with who did what and when, even if it is an authorized operation. Requires more audit data, and more separation of administration roles.  Enterprise environments: Still requires individual identification and authentication, but not so much auditability. Exceptions and unsuccessful operations would be logged, for security purposes.  Public environments: No identification, only temporary authorization Usage logging for accounting/payment only  SOHO environments: Don’t require authentication or logging. Still requires some security protections. High Accountability - Auditable environment - Enterprise environment - Public environment - SOHO environment Low Accountability Individual I&A, complete logging, separate auditor role Individual I&A, exception logging No identification, temp authorization, only usage logging No authorization, no logging, basic security protection

5. Impact?  I think these will still be concentric sets of objectives.  There would be some changes, but not many.  We’re reviewing and potentially changing some threats, assumptions, policies, and objectives anyway.  From a marketing point of view, there maybe some advantage in selling Common Criteria evaluated products for environments that are more closely identified with markets.  I still think we should consider the usefulness of a SOHO PP and perhaps do an EAL1 / Low Assurance Level PP.  Also consider if the Auditable Environment should be a “medium robustness” environment.