Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[2600] FW: Questions from IEEE P2600 working group about the CIM and CC version 3



P2600 group:
 
I didn't get answers in time for our December meeting, but I spoke with Audrey Dale after that meeting and just received this response to my question about assumptions, threats, and policies that the new CIM is likely to recommend. See below. I suggest that we discuss this at the January meeting before trying to implement anything.
 
Regards,
--
Brian Smithson
Project Manager
PMP, SSCP, CISSP, CISA
Advanced Imaging and Network Technologies
Ricoh Corporation
(408)346-4435


From: Cohen, Howard H. [mailto:hhcohen@missi.ncsc.mil]
Sent: Wednesday, January 04, 2006 7:46 AM
To: Brian Smithson
Cc: Bottomly, Ronald J.; Cohen, Howard H.
Subject: RE: Questions from IEEE P2600 working group about the CIM and CC version 3

The CIMs are still in the conversion process but here are some of the item that we are considering.  Your assumptions, threats, and policies may and probably will be different.
 
Howard

*******************************************************************
(U) This email and any files transmitted with it are intended
solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify
the sender.
******************************************************************

Howard H. Cohen
Senior Information Assurance Engineer
NSA/BAH Contractor
410-854-4458
hhcohen@missi.ncsc.mil
cohen_howard@bah.com

******************************************************************

 

Assumption

Description of Assumption

A.NO_GENERAL_PURPOSE[1]

 

The administrator ensures there are no general-purpose computing or storage repository capabilities (e.g., compilers, editors, or user applications) available on the TOE.

A.PHYSICAL

It is assumed that the IT environment provides the TOE with appropriate physical security, commensurate with the value of the IT assets protected by the TOE.

A.TRAINED_ADMINISTRATORS

Authorized administrators are appropriately trained and follow all administrator guidance

A.ROBUST_ENVIRONMENT

It is assumed that the IT environment is at least as robust as the TOE.

A.SECURE_COMMS

It is assumed that the IT environment will provide a secure line of communications between the remote user and the TOE.

A.MANAGE

There will be one or more competent individuals assigned to manage the TOE and the security of the information it contains.

A.TRUSTED_INDIVIDUAL

If an individual is allowed to perform procedures upon which the security of the TOE may depend, it is assumed that the individual is trusted with assurance commensurate with the value of the IT assets.

A.NO_CORRUPTED_ IMPLEMENTATION

It is assumed that no unintentional or intentional errors in implementation of the TOE design occur, leading to flaws that may be exploited by a malicious user or program.



[1] This assumption should be used only on “server”-type TOEs that should have no general-purpose functionality available to untrusted users.  It makes sense, for example, for a firewall or a router, but does not make sense for an operating system or someone’s desktop computer.

 
Threat
Description of Threat
T.AUDIT_ COMPROMISE
A malicious user or process may view audit records, cause audit records to be lost or modified, or prevent future audit records from being recorded, thus masking a user’s action.
T.CORRUPTED_ IMPLEMENTATION
Unintentional or intentional errors in implementation of the TOE design may occur, leading to flaws that may be exploited by a malicious user or program.
 T.CRYPTO_ COMPROMISE
If cryptography is used, a malicious user or process may cause key, data or executable code associated with the cryptographic functionality to be inappropriately accessed (viewed, modified, or deleted), thus compromise the cryptographic mechanisms and the data protected by those mechanisms.
T.FLAWED_DESIGN
Unintentional or intentional errors in requirements specification or design of the TOE may occur, leading to flaws that may be exploited by a malicious user or program.
T.MALICIOUS_TSF_ COMPROMISE
A malicious user or process may cause TSF data or executable code to be inappropriately accessed (viewed, modified, or deleted).
T.MASQUERADE
A user or process may masquerade as another entity in order to gain unauthorized access to data or TOE resources.
T.POOR_TEST
Lack of or insufficient tests to demonstrate that all TOE security functions operate correctly (including in a fielded TOE) may result in incorrect TOE behavior being discovered thereby causing potential security vulnerabilities.
T.REPLAY
A user may gain inappropriate access to the TOE by replaying authentication information.
T.RESIDUAL_DATA
A user or process may gain unauthorized access to data through reallocation of TOE resources from one user or process to another.
T.RESOURCE_ EXHAUSTION
A malicious process or user may block others from system resources (e.g., CPU time) via a resource exhaustion denial of service attack.
T.SPOOFING
An entity may misrepresent itself as the TOE to obtain authentication data.
T.UNATTENDED_ SESSION
A user may gain unauthorized access to an unattended session.
T.UNAUTHORIZED_ACCESS
A user may gain access to user data for which they are not authorized according to the TOE security policy.
T.UNIDENTIFIED_ ACTIONS
The administrator may fail to notice potential security violations, thus limiting the administrator’s ability to identify and take action against a possible security breach.
T.UNKNOWN_ STATE
When the TOE is initially started or restarted after a failure, the security state of the TOE may be unknown.
 
 

   

Policy

Policy Description

Formal Organizational Policy Reference

P.ACCESS_BANNER

 

 

The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which administrators consent by accessing the system.

DODI 8500.2 Enclosure 4, Attachment 4 ECWM-1 and ECAN-1

P.ACCOUNTABILITY

 

 

The authorized users of the TOE shall be held accountable for their actions within the TOE.

DODI 8500.2 Paragraph 5.12, Enclosure 4, Attachment 1,2,3, and 4, ECAT-2, ECRG-1, ECTP-1, ECAR-3, ECLC, etc.

P.ROLES

 

 

The TOE shall provide an authorized administrator role for secure administration of the TOE.  This role shall be separate and distinct from other authorized users.

DODI 8500.2 Enclosure 4, Attachment 2 ECPA-1

P.ADMIN_ACCESS

 

 

Administrators shall be able to administer the TOE both locally and remotely through protected communications channels.

DODI 8500.2 Enclosure 4, Attachment 4 EBRP-1

P.I_AND_A

 

 

All users must be identified and authenticated prior to accessing any controlled resources with the exception of public objects.

DODI 8500.2 Enclosure 3, Paragraph E3.2.4.3.3.

P.SYSTEM_INTEGRITY

 

 

The TOE shall provide the ability to periodically validate its correct operation and, with the help of administrators, it must be able to recover from any errors that are detected.

DODI 8500.2 Enclosure 4, Attachment 3 DCPR-1

P.CRYPTOGRAPHY_ VALIDATED

 

 

 

 

Where the TOE requires FIPS-approved security functions, only NIST FIPS validated cryptography (methods and implementations) are acceptable for key management (i.e.; generation, access, distribution, destruction, handling, and storage of keys) and cryptographic services (i.e.; encryption, decryption, signature, hashing, key distribution, and random number generation services).

DODI 8500.2 Enclosure 3, Paragraph E3.2.4.3.3.

P.CRYPTOGRAPHIC_ FUNCTIONS

 

 

If cryptography is required, the TOE shall provide cryptographic functions for its own use, including encryption/decryption and digital signature operations.

DODI 8500.2 Enclosure 4, Attachment 1 DCNR-1

P.NONREPUDIATION

 

 

 

 

The TOE must provide non-repudiation services for transmitted and received repository data.  The non-repudiation services include both the generation and verification of evidence for non-repudiation, including a timestamp, and notification that evidence of receipt the TOE is waiting for is overdue. 

DODI 8500.2 Enclosure 4, Attachment 1 DCNR-1

P.VULNERABILITY_ ANALYSIS_TEST

 

 

The TOE must undergo appropriate independent vulnerability analysis and penetration testing to demonstrate that the TOE is resistant to an attacker possessing a medium attack potential.

DODI 8500.2 Enclosure 4, Attachment 5 ECMT-1

P.TRUSTED_RECOVERY

 

 

Procedures and/or mechanisms shall be provided to assure that, after a TOE failure or other discontinuity, recovery without a protection compromise is obtained.

DODI 8500.2 Enclosure 4, Attachment 1 COTR-1

-----Original Message-----
From: Brian.Smithson@ricoh-usa.com [mailto:Brian.Smithson@ricoh-usa.com]
Sent: Wednesday, November 23, 2005 1:32 PM
To: Bottomly, Ronald J.; Cohen, Howard H.
Subject: Fw: Questions from IEEE P2600 working group about the CIM and CC version 3


Hello,

Thank you again for the answers you provided in last month's email (below). I am still wondering about the future of CIM instruction #7. Do you have any kind of draft of the new version which includes the assumptions, threats, and policies that you will be expecting a PP author to address? Any kind of input on this issue will help, even if it's very preliminary. The IEEE P2600 working group is meeting in mid December and I would like to be able to report about this and direct our efforts so that they are as consistent as possible with NIAP instructions.
 
Thank you, and happy holidays!
--
Brian Smithson
Project Manager
PMP, SSCP, CISSP, CISA
Advanced Imaging and Network Technologies
Ricoh Corporation
(408)346-4435

----- Forwarded by Brian Smithson/SJ/CA/RCUS on 11/23/2005 10:20 AM -----

This mail template has been enhanced with PGPNotes.
Brian Smithson

10/14/2005 10:33 AM


        To:        "Bottomly, Ronald J." <RJBotto@missi.ncsc.mil>
        cc:        "Cohen, Howard H." <hhcohen@missi.ncsc.mil>
        Subject:        RE: Questions from IEEE P2600 working group about the CIM and CC version 3Link


Thank you very much for the detailed answers to my questions. This really helps and gives us a lot to work with for now. However, there is one item which is fundamental to our current stage of PP development, and I am hoping that you can provide addition details, even if it is still quite preliminary. Regarding instruction 7, you said that

The list of assumptions will change. In addition, this section will also provide a list of threats, and policies that the PP author will have to address and if the author does not include them, rationalize why they are not included.

Can you give us the new list of assumptions, threats, and policies? Some of them may already be addressed in our PP, but under a different name or slightly different definition. Others may be new for us. The list of threats, in particular, have a significant effect on our work in the IEEE P2600 working group because we deal with them not only in the PPs, but also in the rest of the P2600 standard.

Any additional guidance on this instruction would be greatly appreciated.

Thank you and best regards,
--
Brian Smithson
Project Manager
PMP, SSCP, CISSP, CISA
Advanced Imaging and Network Technologies
Ricoh Corporation
(408)346-4435