P2600 Hardcopy Device and System Security June 2004 Working Group Meeting

1. P2600Hardcopy Device and System SecurityJune 2004 Working Group Meeting Don Wright Director, Alliances & Standards Lexmark International don@lexmark.com

2. Agenda • Wednesday, June 2nd8:30 Continental Breakfast9:00 Opening, Intros, etc.9:15    IEEE Patent Policy9:30      Report on PP Activity with DAPS/DOD10:00     System Security - Jon Williams, Software Imaging10:45     Break11:00     Non-US Legislative Landscape – Sharp11:30 DOD Policies, Canadian Policies - Canon12:00     Lunch1:30       Document Development Plan     5:30       Wrap-up • Thursday, June 3rd8:30      Continental Breakfast9:00      Opening, Intros, etc.9:15       Document Development Plan12:00     Lunch1:30       Environment Definition2:30       Review future meeting plans3:00       Wrap-up

3. Instructions for the WG Chair • At Each Meeting, the Working Group Chair shall: • Show slides #1 and #2 of this presentation • Advise the WG membership that: • The IEEE’s Patent Policy is consistent with the ANSI patent policy and is described in Clause 6 of the IEEE SA Standards Board Bylaws; • Early disclosure of patents which may be essential for the use of standards under development is encouraged; • Disclosures made of such patents may not be exhaustive of all patents that may be essential for the use of standards under development, and that neither the IEEE, the WG nor the WG Chairman ensure the accuracy or completeness of any disclosure or whether any disclosure is of a patent that in fact may be essential for the use of standards under development. • Instruct the WG Secretary to record in the minutes of the relevant WG meeting: • that the foregoing advice was provided and the two slides were shown; • that an opportunity was provided for WG members to identify or disclose patents that the WG member believes may be essential for the use of that standard; • any responses that were given, specifically the patents and patent applications that were identified (if any) and by whom. Approved by IEEE-SA Standards Board – March 2003 (Revised Feb 2004) (Not necessary to be shown)

4. IEEE-SA Standards Board Bylaws on Patents in Standards 6. Patents IEEE standards may include the known use of essential patents and patent applications provided the IEEE receives assurance from the patent holder or applicant with respect to patents whose infringement is, or in the case of patent applications, potential future infringement the applicant asserts will be, unavoidable in a compliant implementation of either mandatory or optional portions of the standard [essential patents]. This assurance shall be provided without coercion and prior to approval of the standard (or reaffirmation when a patent or patent application becomes known after initial approval of the standard). This assurance shall be a letter that is in the form of either: a) A general disclaimer to the effect that the patentee will not enforce any of its present or future patent(s) whose use would be required to implement either mandatory or optional potions of the proposed IEEE standard against any person or entity complying with the standard; or b) A statement that a license for such implementation will be made available without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination. This assurance shall apply, at a minimum, from the date of the standard's approval to the date of the standard's withdrawal and is irrevocable during that period. Slide #1 Approved by IEEE-SA Standards Board – March 2003 (Revised February 2004)

5. Inappropriate Topics for IEEE WG Meetings • Don’t discuss licensing terms or conditions • Don’t discuss product pricing, territorial restrictions or market share • Don’t discuss ongoing litigation or threatened litigation • Don’t be silent if inappropriate topics are discussed… do formally object. If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at patcom@ieee.org or visit http://standards.ieee.org/board/pat/index.html Slide #2 Approved by IEEE-SA Standards Board – March 2003 (Revised February 2004)

6. Officers • Chair: Don Wright, Lexmark • Vice Chair: Lee Farrell, Canon • Secretary: Steffan Deschrijver, Print4Sight • Editors: • Brian Volkoff • Jerry Thrasher • Ron Bergman • Stefaan DeSchrijver

7. Document Editor(s) • Create drafts • Publish on web site • Respond to comments • Maintain change history • Volunteers: • Brian V. • Jerry T. • Ron Bergman • Stefaan DeSchrijver

8. Mailing List and Web Site • Web Site: http://grouper.ieee.org/groups/2600 • Mailing list: • Listserv run by the IEEE • An archive is available on the web site • Subscribe via a note to: listserv@listserv.ieee.orgcontaining the line:subscribe stds-2600 • Only subscribers may send e-mail to the mailing list.

9. DAPS/DOD Protection Profile • Meeting held at DAPS in Harrisburg PA May 12-13 • Lexmark, Sharp, HP, Ricoh, Xerox attended • Pre-meeting proposed PP available at:http://grouper.ieee.org/groups/2600/drafts/DAPS-PP-1.doc • Post-meeting PP (incomplete) available at:http://grouper.ieee.org/groups/2600/drafts/DAPS-PP-2.doc • Subsequent meetings and processes are TBD. • DAPS contact is Daniel Mory (Daniel.Mory@dla.mil)

10. Presentation/Proposal Hardcopy System Security • John Williams • Software Imaging

11. System Security • How are system security issues specified? • How much is a part of the PP? • How much is simply text within the document? • Is there a dependency on a certified Operating System? • How do the legislative requirements affect a “system” versus a device?

12. Presentation/Proposal Non-US Legislative Landscape • Peter Cybuck / Ron Nevo • Sharp

13. Presentation/Proposal US DOD / Canadian Policies • Wanda Nuckolls • Canon

14. Day 2 • Thursday, June 3rd8:30      Continental Breakfast9:00      Opening, Intros, etc.9:15       Document Section Reports - Intro Material - Vulnerabilities - Best Practices - Protection Profiles10:15 Break10:30 Document Work - Definition of the environments - Brainstorming on “Bag of Tricks”12:00     Lunch1:30       Document Work2:30       Review future meeting plans3:00       Wrap-up

15. Content of Standard • Introductory Material • Vulnerabilities/Threats/Exploits • “Meat on the bones” of the Vulnerability Charts • Directives / Best Practices on • Physical Security • Encryption • System Consideration • Auditing • Device Protection Profiles / Security Target Templates • “AAA” • “AA” • “General” • “Public”

16. Group Goals • Description of the section. • What’s to be done to create the section? • What other material is needed? • What process is to be used (one person? Team?) • How long will it take? • If possible, identify an editor to own the section.

17. Environments / Settings Brainstorm1 – 4 (1 = lowest impact from security breach) • Real Estate Broker, small office, no substantial physical security, minimal firewall, e-mail, web access, contracts, may have accounting considerations (C) • Financial Broker, physical security, escorts required, no internet connection, e-mail through a secure server, individual’s information is subject to legislative privacy requirements, foreign devices not allowed on the network, WAN connection among remote offices (B) • Stock Broker, physical security, escorts required, internet access (monitored and thru proxy), SMTP e-mail, individual’s information is subject to legislative privacy requirements, interconnection offices via WAN or VPN (B) • Engineering Office, no substantial physical security, no private information, internet access, e-mail, cost estimates, schedules, plans and drawings, supplier and contractor contact information, customer lists, confidential business information (C)

18. Environments / Settings Brainstorm1 – 4 (1 = lowest impact from security breach) • Public Library – no physical security, internet access, e-mail, not liable for disclosure of copied/scanned/printed content. Accurate charge-back/payment information. No credit card information. (D) • Commercial operation (ala Kinkos, etc.), internet access, some physical security, credit card information on the network but not through the HC device. Internal network is firewalled from Internet (D) • Public access devices driven by utilities like “PrintMe” and “PrinterOn” which are effectively on the Internet. Physical security varies, content could be personal information. (?) • Local District Attorney’s office. Some physical security, content of printed material is usually confidential. Internet access and e-mail. (B)

19. Environments / Settings Brainstorm1 – 4 (1 = lowest impact from security breach) • Pharmaceutical research lab – internet access (firewalls, proxies), e-mail, high dollar value data, potentially segregated networks, high physical security, high potential for industrial espionage (A) • Top Secret Military research lab – like above except on MIL network, high potential for military or industrial espionage, personnel have clearances (A) • MFP at home – minimal physical security, content could be confidential, internet access, e-mail, no legislative mandates apply to my own information, wireless network common and often not protected with WEP, etc. (none -> D)

20. Security Environment Matrix A B C D -- -- -- -- Value of Asset H+ H M L Physical Security H M L L Network Protection H M L L Legislated Mandates 0 H M 0 Personnel Clearances H M L L Sophistication of Attacker H M M L

21. Bag of Tricks Brainstorming • Turn off any physical port • Turn off any protocol (implicitly that port #) • User authentication • Be able to map any protocol to any port • Support use of proxies • Encryption • Access control • Physical security • Enable audit trail • Expire passwords • Lock out users after so many login errors • Minimum password length, reuse requirements • Disk wiping techniques • Device authentication (certificate? IP address? Mac address?...) • Disable arbitrary services within device • Restrict connections from remote devices to those on a managed list • Integrate access control with existing operating environment

22. Bag of Tricks Brainstorming • Be able to limited core OS functions to only those actually needed. • Validate integrity and source of uploaded firmware and applets. • Isolate core OS functions from network ports. (e.g. network code runs on separate processor based NIC card.) • Prevent never ending jobs via a watchdog • Lock down mgmt functionality “out of box” • Op panel passwords • Avoid back doors to network functions • No default passwords preloaded into MFD (e.g. “public” for SNMP) • Customer settable key sequence or password to service/maintenance mode • Resilience / Resistance to DOS attacks • Resilience / Resistance to replay / man-in-the-middle attacks • Shielding to reduce emissions • Maintain log and require mutual authentication of transactions to provide nonrepudiation • Enable removal of hard disk for overnight protection • Job accounting • FAX timeout on perpetual negotiations • General use of connectivity and service timeouts

23. Bag of Tricks Brainstorming • Ability to lock down services from access by Java, Chai, MEAP, etc. • Provide locking input and output bins • Prevent removal of “bolt on” accessories • Hold and release print job • Locking access panels • Restrict access to certain times of day, days of week, etc. • Restrict size of jobs (pages? megabytes?) • Protect stored fonts, signatures, watermarks, etc. • Encrypt data as it is written to hard disk

24. Content of Standard - PPs CSPP - Guidance for COTS Security Protection Profiles (http://csrc.nist.gov/publications/nistir/ir6462.pdf) • Introduction – D.W. • TOE Description – J.T. • Security Environment (Multiple environments) – P.C. • Security Assumptions • Organizational Policies • Role/Vulnerabilities/Exploitations – S.D. • Security Objectives – B.V. • Functional Security Requirements • Assurance Requirements • Appendix • TOE Functional Requirements Details • TOE Assurance Requirements Details • IT Environment Functional Requirements

25. Action Items for August Meeting • Section 1 – Deliver a draft at least 1 week before the August 2004 meeting. (Including defining the security environments (A/B/C/D)) • Section 2 – Deliver a draft at least 1 week before the August 2004 meeting. • Section 3 – More detailed outline and clean-up of the brainstorming work prior to the August meeting. • Section 4 – TOE Description and TOE Security Environment for “A” environment prior to August meeting. • Everyone: Begin identifying terms, definitions and acronyms which need to be included in Section 1. • Everyone: Think about 2005 meeting schedule and if you can host.

26. Schedule • The PAR included estimates of the end-points of the schedule: • Sponsor Ballot: June 2005 • Submission to RevCom: Feb 2006 • Future Meetings • August 19-20, with PWG in Montreal • Details coming soon • October 6-7, with PWG, in Lexington KY • At Lexmark • November 18-19, with PWG, San Antonio