2. Windows 2000 - Security Martin Höppner Dr. Horst Walther Krickenbeck, April 03 rd, 2001 Goals, results & lessons learned SiG

3. 2 Agenda Mission of the W2K-Security Team Project Structure Overview W2K Project Team Dependencies W2K Project Timeline Project data Security - Where to apply? Work breakdown Structure Positioning our Deliverables in the Security Pyramid WP1: Security Policy WP2: Security Requirements - Methodology WP2: Security Requirements - Example

4. SiG 3 Agenda (continued) WP 3: "Security Guidelines for W2K„- Timeline WP 3: "Security Guidelines for W2K„- Example WP 4: Security Operations - Example WP 5: “W2K-Security Helpfile” - Topics WP 5: “W2K-Security Helpfile”- Example WP 8: “GPO settings (Level 4)” - Timeline WP 8: “GPO settings (Level 4)” - Example Open points – lessons learned

5. SiG Mission of the W2K-Security Team Provide the platform-independent security requirements, Deliver security guidelines for Win2K specific solutions, Deliver rule sets and requirements for processes within W2K Security Operations, Deliver Test-Design for proposed security solutions, Deliver Training-Design for proposed security solutions. Not Mission: Implementation of security measures or actual processes. Performing the tests.

6. SiG 5 Project Structure Overview...

7. SiG 6 W2K Project Team Dependencies Infrastructure design and security are foundation for all design. The W2K-Sec-Team communicates with the other teams through Liason Partners. The bilateral interfaces still have to be defined. Infrastructure Basic Servers Workstations Applications Security Operational Model Operational Model Migration Planning Migration Planning Pilot Tests Pilot Tests Advanced Servers Project Office

8. SiG 7 W2K Project Timeline Infrastructure Design and Implementation Infrastructure Design and Implementation Server Design Desktop Design 30.06.0031.03.0030.09.0031.12.0031.03.01 Migration Planning and Test Pilots Migration Planning and Test Pilots Global Apps Testing and Test Standards Test Lab Setup Security & Quality Circle Review – Establish Standards and Review Design Team Deliverables Security & Quality Circle Review – Establish Standards and Review Design Team Deliverables Project Planning/Staffing Note: These items are required for full rollout, but not for infrastructure implementation. Security (short term focus) Establish Standards and Review Design Team Deliverables Security (short term focus) Establish Standards and Review Design Team Deliverables Security (long term focus) Establish Standards and Review Design Team Deliverables Security (long term focus) Establish Standards and Review Design Team Deliverables

9. SiG Project data Start date: 15.06.2000, : 31.03.2001 Duration: ~ 9.5 months Effort:  ~ 325 days (FTE)  ~ 300 days Team  ~ 25 days Reviewers Budget: 440.000,- Euro separate cost-allocation for IT- and Bank-Staff

10. SiG 9 Security - Where to apply? plan designpilot W2K-Sec-Team Requirements Consulting, QA forecasts tests

11. SiG 10 Work breakdown Structure Deliverables 1. WP 1: “Security Policy” 2. WP 2: “Security Requirements“ 3. WP 3: “Security Guidelines for W2K” 4. WP 4: “Security Process Requirements“ 5. WP 5: “W2K-Security Helpfile” 6. WP 8: “GPO settings (Level 4)” 7. WP 9: “Security Testing” Services and Management 1. WP 6: “QA of W2K design-team-results“ (project office) 2. WP 7 : „Project Management“ 3. WP 10: „EFS-Taskforce“ (I-Team)

12. SiG 11 W2K-Sec Timeline

13. SiG 12 Times reported - figures 1. Phase 2. Phase Total times consumed

14. SiG 13 Times reported - weekly 0,0000 5,0000 10,0000 15,0000 days worked 6. Okt 13. Okt20. Okt27. Okt 3. Nov 10. Nov17. Nov24. Nov 1. Dez8. Dez 15. Dez22. Dez29. Dez 5. Jan 12. Jan19. Jan26. Jan 2. Feb9. Feb 16. Feb23. Feb 2. Mrz9. Mrz 16. Mrz23. Mrz30. Mrz 6. Apr Mean week effort Jack Aldus, IT-Systems Dr. Horst Walther, SiG Martin Höppner, BankOne Steve Fiverocks, Globalsec Michael Tharrson, IT-Systems Jon Redford Head, LON-IT-SEC

15. SiG 14 Times reported - monthly

16. SiG 15 Positioning our Deliverables in the Security Pyramid Existing Information Sources...  Security-Manual, Chapter 8.2.4 1. Manual 130, Chapter 3 2. Network-Requirements - abstract form 3. London Requirements 4. SIZ-Standard IT-Sec 5. SIZ NT-Security 6. [SIZ Security Architecture] 7. [DoD Orange book] 8. [BSI GSHB]  Network -Requirements – NT solution  NT Admin Manual  Discussion by IT Security Policy (WP1) Security Requirements (WP2) Level 1 (static) Level 2 (rel. static) Level 3 (dynamic) Security Guidelines & Operations W2K Security Guidelines (WP3) W2K Security Operations (WP4) just reference Technical solutions by I-Team (WP8) (e.g. Parameter Settings, …), Process solutions by Operations WD SF JC Results  Security Policy (high level)  Requirements  Organizational, technical, non product specific  Security Guidelines & Operations  Product specific Solutions and Processes Level 4 (dynamic) Communication Basis

17. SiG 16 WP1: Security Policy Security Policy (1. mile stone)  Referencing Manual 101, Chapter 8.2.4 Security Policy (2. mile stone)  Recommendation of additional statements resulting from new technologies, new insights etc.

18. SiG 17 WP2: Security Requirements - Methodology System A DATA Data Integrity Data Authenticity Data Confidentialtiy Data Access Control User Identity and Authentication System Access Control Logging and Auditing System B Communication (Data Transport) Data Integrity Data Authenticity Data Confidentialtiy

19. SiG 18 WP2: Security Requirements - Example 1.1Access Control 1.1.1System Access 10.3.1.1.Requirement 1: Automatic account locking The user account should be automatically locked after a specified number of failed logon attempts. Please refer to Requirement 23 Applicability Table: Source: BankOne, Network-Requirement 1.7 10.3.1.2. Requirement 2: Accountability for each system interaction Every user interaction should identify the user who performed it. Applicability Table: Source: BankOne, Network-Requirement 1.8 System classification Level of applicability Level 3 Level 2 Level 1 Level 0 Recommended Desirable Nice to have System classification Level of applicability Level 3 Level 2 Level 1 Level 0 Obligatory

20. SiG 19 Timeline - WP 3: "Security Guidelines for W2K"

21. SiG 20 WP 3: "Security Guidelines for W2K„- Example

22. SiG 21 WP4: Security Operations - Example

23. SiG 22 WP 5: “W2K-Security Helpfile” – Topics (German) Security Policy Login Vorgang Passwort Helpdesk Virenschutz Antragswesen Internet Schutz Notes Sicherheit Gruppenrichtlinien NTFS Rechte EFS Systempflege Datenschutz

24. SiG 23 WP 5: “W2K-Security Helpfile”- Example (german) Das Passwort  Das persönliche Passwort wird verwendet, um sich im Windows - Netzwerk anzumelden.  Hierbei muss...  erst die Benutzerkennung eingetragen werden,  anschließend das Passwort  und - zu guter letzt - die domain, an der sich der User anmelden möchte. z.B. MDBankOne oder GSA.  Das Passwort dient zur persönlichen Identifikation des Users.  Das Passwort muss unbedingt geheim gehalten werden.  Das bedeutet, es sollte nicht auf einem Zettel notiert werden und dann unter der Tastatur verschwinden.  Es sollte auch nicht der Name oder Geburtstag einer Person aus der eigenen Familie sein, oder der Name des Hundes, sondern etwas alltägliches, dass keine Rückschlüsse zulässt.  Hierbei sollten Sie Buchstaben, Zahlen und Sonderzeichen verwenden. Psst! Wer bin ich?

25. SiG 24 Windows 2000 Security - Review Plan

26. SiG 25 WP 6: QA to other W2K design-teams

27. SiG 26 WP 8: “GPO settings (Level 4)”

28. SiG 27 WP 8: “GPO settings (Level 4)” - Example Security Team requirement and commentsPossible Security Threat Description Restricted Groups System Services Registry File System Account Policies Password Policy Enforce password history A password history is neccessary to prevent the user from using the same password. Together with the minimum password age, this results in the minimum cycle of passwords of 6 days. User uses same password when changing the password. Maximum password age The user should change the password at least once a month. User does not change the password. Minimum password age To prevent, that the user can change the password immediatly after a change. The password cannot be changed for 1 day. Note: if a new password is presumed compromised the user needs to contact the administrator who can change the password instantly. User changes password immediatly "history"-times after another to choose the old pasword. Denil-of- service is also possible. Minimum password length Longer passwords are more secure than shorter passwords. The password should be at least 8 characters. Note: To conform to the SIZ security standard a minimum length of 6 characters is sufficient, but we consider 8 characters as more secure because computer power has increased dramatically during the last years. Short passwords are easy to break in brute force attacks. Passwords must meet complexity requirements of the installed password filter The password complexity mechanism enforces more secure passwords, which prevents the user from choosing weak passwords. User chooses weak password. Store password using reversible encyrption for all users in the domain Storing passwords in reversible encryption is a security hole and must be avoided. Applications that need to compare the password of a user to the stored password in clear should not be approved. Passwords can be decypted by attackers. User must log on to change the password Users should be authenticated before they can change their password. Enforces that users have to contact the adminstrator when the password has expired A temporary user can gain access to the account again after the password expired. Desktop default Windows 2000 Policy SecTeam 0.1

29. SiG 28 Open points – lessons learned Initial goals, which have not bee tackled until now …  vulnerability assessment tools,  Application related security settings  Test for compliance with requirements and guidelines  Security of patches and updates (part of the SW-update concept) Lessons we had to learn...  The effort of W2K-deployment projects is widely underestimated.  We did it too.  Global projects need a strict formal project management  There’s still “room for improvement”  Deployment of AD means organizing Administration  Resulting in time consuming “political” discussions  Organizing means formal documentation of design concepts  “Organically” grown NT 4.0 environments often lack this doc’s

30. SiG 29 S top, A ppendix From here on the back-up-slides follow...

31. SiG 30 WP 7 : „Project Management“ - Principles of QA Full coverage Each result will be checked for quality and formally singed off The expert principle - Project results are assessed by experts...  Following a formal process  colleagues, internal or external experts  Reviews including meetings or in documents-flow based way.  Comments und sign off decision are documented by review minutes.... But signed off by a third party. Reliability by transparency :  Results become visible in the Intranet for a defined public. Indivisibility - A result is considered to be done by 0% or by 100%. Documentation - In the Intranet – so that we can learn from our faults. The minimum principle:  documented regulations as concise as possible – visible in the Intranet.

32. SiG 31  WP 7 : „Project Management“ - Q-Check & Sign off Mile Stone II Start DateEnd DateDeliverables... Mile Stone completed  All Results are signed off Mile Stone completed  All Results are signed off  Results are completed by 0 % (not signed off) or by 100 % (signed off).  Results are signed off after successfully passing a formal Q-Check process.  ? ? ? ? Deliverables...  ?      Deliverables... Q Miles Stone not completed  Not all Results are signed off Miles Stone not completed  Not all Results are signed off Miles Stone not completed  There are no results Miles Stone not completed  There are no results Phase Mile Stone I Phase  Defined per Phase...  Participants  Tasks  Results Defined per Phase...  Participants  Tasks  Results Phase Mile Stone III Phase

33. SiG 32 WP 7 : „Project Management“ - QA-Tasks The Result of a Phase is either...  Signed off  Signed off by condition or  rejected The QA-check follows a formal Procedure... procedures / checklists QA-Plan Report Quality Management-Handbook Phase Result Plan Prepare produce Check   Moderator Reviewer 1..n Author Recorder Example: Participants of a Review-Meeting

34. SiG 33 WP 7 : „Project Management“ Steps of a Reviewmeeting The Author signals a ready for review result to QM. QM names a Moderator and calls experts for participating the Review. The Reviewer deliver their expertise prior to the Meeting. They mark flaws in a precise way  Minor flaws lead to conditions  Major flaws lead to rejection A Review is not a interrogation but a service for the Author The Recorder writes Review-Report QM signs the result off, rejects it or imposes conditions (while signing off). Tue.., 02.11.99 Tue., 09.11.99 Scheduling QA-Check Minutes 1 week Review time 1 week Planning time Tue., 16.11.99 Reworking  Tue., 23.11.99 Reworking time Organizing

35. SiG 34 WP 7 : „Project Management“ - Reporting Work reports – Team members report via time sheets to the PL. Period is weekly (each Friday by noon) There will be BankOne-Forms available The PL consolidates the weekly work reports and sets up a monthly Status report.

36. SiG 35 WP 7 : „Project management“ Project meetings Jour fixe - Each Tuesday, 10:00 to 16:00 Participants – All actually active Team members (and optionally guests). Location - Frankfurt, Empirestreet 59. Minutes – Decisions, results and Todos will be documented in minutes, sent to the participants and stored in a project folder.

37. SiG 36 WP 7 : „Project Management“ - Standards to apply Policies & guidelines - We will follow the rules and regulations of „procedures of project management “ Exchange format - We will publish the results in Office 97 format und additionally as PDF-documents as ZIP-files. Project folder - We will use a Lotus Domino DB to store the project results and other relevant documentation. Communication – We will make use of Internet-Mail or Lotus NOTES (Text, RTF, HTML)

38. SiG 37 Planned time of Non-availability 23.430.4 absence