Information System Security Assurance Architecture Working Group (P1700)
MINUTES November 30, 2004 Johns Hopkins University Applied Physics Laboratory, Laurel, Maryland USA

Presiding & Author of Minutes: Jack Cole

Meeting was called to order at 9:30 am ET . Participants introduced themselves, and attendance taken.

The agenda was accepted as proposed, and the IEEE Patent Policy was reviewed using the authorized slide set.

MAIN BUSINESS
This meeting was intended to:

1. Come to closure on the discussion about the term “System Under Review (SUR)”; to
2. Receive a presentation from NIST on their draft security control assessment document; to
3. Identify elements of the ISSAA policies and procedures (P&P) draft to be modified; and to
4. Gather members’ thoughts about making teleconferencing available to those unable to attend

TOPICS DISCUSSED

1. System under review
2. Security Control Assessment

RESULTS OF DISCUSSION

System under review (“SUR”)
It was concluded that an analytical definition of a SUR is not possible because of the infinite ways in which a SUR may be constituted. So a sentence or two will be written to introduce the term, and that will be followed by examples of possible SUR definitions, elements. Ultimately the user of this standard will have to convincingly define a SUR to establish a trust relationship with another enterprise.

The complexity of a SUR was discussed, and these points were considered:

1. There is a great deal of subjectivity in the security world, and a combination of legal and safety elements are used building an assurance argument for a SUR that considers the general concepts of due care, due diligence.
2. A SUR may consist of a number of other systems (systems of systems), network access, human and environmental elements, and distributed architectures in which the user of this standard owns an application running on a host owned by another.

3. The boundary of a SUR is set where control (which may be contractual control) ends.

Security Control Assessment
Participants from NIST presented a Security Control Assessment draft that was later released to those in attendance. A wide-ranging discussion resulted, and some bulleted points of that discussion are included here:

1. Do low/med/hi compare with NSA basic/moderate/hi? No.
2. EAL levels outdated
3. Each control has a functional and an assurance component, like Common Criteria (CC)
4. Like CC, supplemental components are additive
5. Contingency Planning – Low end: no training
6. “Assurance” is an assurance argument, not detailed implementation requirements
7. Think through control development, then records to make assessment easier (Auditing)
8. Gray Box testing (not black box ;-)) For high impact systems go down a little, White Box Testing all the way down to the code (did not do this)
9. Completely avoided formal specification
10. Good requirements are testable, can be validated
11. Always a lot of subjectivity
12. Combination of legal arguments and safety
13. Building an assurance argument
14. Standard for Due Care, Due Diligence
15. Prioritize of Controls? Can’t do that. Every link in chain important
16. Balance is the key
17. FISMA suite all works together
18. DoD versus Lo/Med/Hi

                                                    i.     Robustness levels come down between EALs

                                                  ii.     Evaluation: Vulnerability Assessment

                                                iii.     Common Criteria will always have a place

                                                iv.     Mistake: Product evaluation and security of system mapped one-to-one, serves integration and interoperability, but leaves the system as an afterthought

                                                  v.     Mistake: Stretch paradigm of eal4 to high, etc

                                                vi.     CC has extensibility

19. Military drove Security Until CIP in 1997 Recognized real World
20. FISMA as an issue for outsourcing so many other countries
21. CC does heavy lifting for evaluation auditing nodes
22. CC and security controls in general: how do they relate? In U.S. , product evaluations
23. Demand for evaluated products will rise if answer this relationship question
24. Effectiveness of CC and NIAP: customers are integrators
25. Value of third party testing: Consider attitude of some countries -> Who would want to test products? We build correct first time.
26. Make management comfortable that you put the right things in
27. Must be able to provide enough information to your partner to make them comfortable.

P&P
The IEEE model P&P was presented and the interest in modifying elements of this was discussed. Also discussed were different schemes to determine membership, voting status basing membership on contributions.

Teleconferencing
Generally the group favors opening part of the meeting to those attending telephonically, but the issue of cost remains.

ACTION

1. Write a simple sentence or two (Jack) description of SUR to be coupled with a couple of paragraphs containing example elements and boundaries of a SUR (all).
2. (ALL) Help Stu in writing the functionality section of the P1700 draft by picking a component in framework chart, sending your thoughts on the inputs/outputs to Stu.
3. (ALL) Read current draft of P1700, provide comment to Stu.
4. Submit draft P&P to group (Jack)

Next Meeting:

January 25, 2005, 9:30am-3:30pm at the Johns Hopkins Applied Physics Laboratory, Laurel, MD
(Basement of Gibson Library, Room L-1, see http://issaa.org/meetings/announce_20050125.html)

Adjournment at 3:30pm ET

updated Tuesday, January 4, 2005

This site and all contents (unless otherwise noted) are Copyright © 2005
Institute of Electrical and Electronics Engineers, Inc.
All rights reserved.