ISSS Keynote 03.05.2007 IT-Security Monitoring Worauf es wirklich ankommt! ISSS Keynote Monitoring 2007 3. May, 2007
Table of Contents t277325 [printed: April 17, 2007 9:28 AM] [saved: April 20, 2007 3:13 PM] P:\My Documents\ISSS_Keynote_2007\ISSS_Keynote_2007d_final.ppt SECTION 1 IT Security Monitoring: Anforderungen & "Treiber" 2 SECTION 2 IT Security Monitoring Framework & Architektur 7 SECTION 3 Definition der IT Security Monitoring Anforderungen 12 SECTION 4 IT Security Monitoring - Auf was es wirklich ankommt..summary 15 SECTION 5 Fragen/Diskussion 18 1
SECTION 1 IT Security Monitoring: Anforderungen & "Treiber"
IT Security Monitoring Anforderungen & "Treiber" Legal SOX Control EBK Company Other Frameworks Policies External (CobIT,, ISO27001, ISF, etc..) Requirements Anforderungen bzgl. IT Security Monitoring Ist-Zustand im Unternehmen...Betrieb...Services Verfügbarkeit.. 3
IT Security Monitoring Anforderungen & "Treiber" Was? Wie? Wieviel? Maturity Dimensions HOW (capability) IT Mission and Goals IT Mission and Goals 100 % Cost Efficiency & ROI HOW MUCH (coverage) WHAT (control) 4
IT Security Monitoring Anforderungen & "Treiber" Externe Anforderungen SOX (Public Company Accounting Reform and Investor Protection Act of 2002) Basel II (Basel II bezeichnet die Gesamtheit der Eigenkapitalvorschriften vom Basler Ausschuss für Bankenaufsicht; Regeln müssen gemäss EU-Richtline 2006/49/EG seit 1.1.2007 in der EU umgesetzt werden; USA vorr. ab 1.1.2009) GLBA (Gramm-Leach-Bliley Act; Nov 12,1999) Compliance verbindlich; Privacy, Schutz der Kundendaten, Personenprofile, Kundenrechte..etc. COSO project: Entwickelt Richtlinien bzgl. der Monitoring Komponenten des COSO Internal Control-Integrated Framework. Ein Schwerpunkt ist eine effizientere Ueberprüfung der "Internal Controls". SEC (US Securities and Exchange Commission): Dec 2006 SEC und PCAOB (Public Company Accounting Oversight Board) schlagen neue Guidelines bzgl. Management Assessment von internen Controls vor: Top-down risk-based approach Kosteneffizientere Prinzipien zur Erreichung der notwendigen Compliance PCAOB: Dezember 2006: Neuer Internal Control Audit Standard, welcher auch Audits der IT System Controls vorsieht. HIPAA (US Department of Health & Human Services) Andere 5
IT Security Monitoring Anforderungen & "Treiber" "Treiber" GRC (Governance Risk and Compliance): SAP hat seit neuestem eine GRC Business Unit ISO/IEC: ISO 2700x Standard Familie COBIT: (Control Objectives for Information and Related Technology) International anerkanntes Framework zur IT-Governance ITGI/ISACA: Val IT & COBIT (s.o) Andere 6
SECTION 2 IT Security Monitoring Framework & Architektur
IT Security Monitoring Framework & Architektur Bedeutung aus Risikosicht IT Security Monitoring als Risiko-kompensiernde Massnahme Basierend auf einem Kontroll-Framework, z.b.: ISO/IEC 27001 COBIT 4.0 Etc. Funktion: Kontrolle/Ueberwachung von Risiken, welche nicht über "technische Massnahmen" in Griff zu bekommen sind Messen: Messgrössen bzgl. Effizienz und Qualität von Prozessen und System- bzw. Konfigurationszuständen (Metrik, Messwerte) 8
IT Security Monitoring Framework & Architektur Error Human Risk Management Framework ISO 27001 based (example) Natural disaster or external accident Malfunction Unforeseen effects of change Internal misuse / abuse Service interruption threats Theft, Other Threats BCP Access Controls - external Access Controls - internal Information security Incident Management Information System acquisition, development and maintenance Communications and operations management Human Resources Security Physical and environmental security Compliance, Security Policy and Organization of information security Middleware, Databases & Applications W-XP, WSP, DELL, MS- SQL,.NET, etc. SUN, OLU, ORACLE etc. DB2, AS400, etc. z/os, DB2 etc. Proxies, etc. Firm-ware, etc. Cisco etc. Windows UNIX Midrange Mainframe Network High Risk e.g. DMZ, CA's etc. Controls Business Technology Stacks 9
IT Security Monitoring Framework & Architektur Logfile Architektur Contract Audit Trail - Contract Data Business Application Business Audit Trail - Business Data Security Subsystems Security Audit trail 10 years User Activity Log Systems Mgmt. Tools, Middleware Operating Systems Exception Log Trace Log 90 days 200 days Log Sources 15 days Log Types 10
IT Security Monitoring Framework & Architektur Technische Monitoring Architektur (Beispiel) Log Source Integrated Recorder IDS, UNIX etc..) Log Source Log Source Interceptor Log Type A Log Type B Converter Log Log Type A Dispatcher Dispatcher Receiver Management Reports (in periodic time intervals) Log Archiv Logfile Manager Log Repository IT-Security Event Monitoring (Event Filter; Log-Viewer; Log- Processor; e.g. SEM/SIM- Tool, z/os: e.g. Vanguard) IT-Security Incident Management (realtime) 11
SECTION 3 Definition der IT Security Monitoring Anforderungen
Definition der IT Security Monitoring Anforderungen Generischer Ablauf am Beispiel von z/os Input: z/os Baseline Security & z/os-audit Plan Schwachstellenanalyse Risikobewertung: Low/Medium/High Definieren der Monitoring Anforderung Definition der Event/Incident-Prozesse Reporting Input Technical Compliance Checks 13
Definition der IT Security Monitoring Anforderungen Beispiel für z/os Internal Reference (in this document) MON1 Monitoring Issue Collecting Monitoring data System Management Facility (SMF) Objective: System Management Facility (SMF) is critical to the audit ability of MVS and its subsystems. SMF is used for the collection of system activity as well as ESM security events in SMF record types 80,81 or 230. When an external security manager (RACF, CA-ACF2 or CA-Top Secret) is used, the corresponding SMF records must be enabled. Risk: Incorrect settings of SMF parameters can cause records not to be logged. SMF exits can also selectively or completely suppress SMF logging. Failure to log record types required by the UBS may result in lack of information for performance measurement, accounting, (security) event tracking and an incomplete audit trail. Implementation at UBS: Company specific settings and actions 14
SECTION 4 IT Security Monitoring - Auf was es wirklich ankommt..summary
IT Security Monitoring - Auf was es wirklich ankommt.. Monitoring Anforderungen Definition der Anforderungen sollte Risiko-basiert erfolgen (z.b. mit Hilfe eines "Generischen z/os Audit- Programms; siehe z.b. www.isaca.org ) Definition der Anforderungen pro Platform: z/os, UNIX, Windows, ORACLE etc Definition von Logfile-Typen und Aufbewahrungszeiten Definition einer generischen Technischen IT Security Monitoring Architektur Definition von Event und Incident-Prozessen pro Platform und Umgebung Implementierung Umsetzung der definierten Event- und Incident-Prozesse Unterscheidung von 7x24 Monitoring und periodischen "Technical Compliance Checks" (Risikoabhängig) Periodische "Technical Compliance Checks" gehen fliessend über in das Technical Vulnerability- Management Konfiguration der Korrelations-Engine: Was ist nun wirklich ein Event/Incident? Betrieb Resourcen: Ausreichend Resourcen zur Bearbeitung der Events und Incidents Einfach und übersichtlich Dokumentierte Event/Incident-Prozesse: Wer muss wen, wann und wie benachrichtigen, wie muss reagiert werden 16
IT Security Monitoring Auf was es wirklich ankommt.. Betrieb Stufengerechtes Reporting: Das Management sollte nicht über die technischen Details eines Events/Incidents informiert werden, sondern über die Event/Incident-Kategorie, das damit verbundene Risiko und die getroffenen Massnahmen Zeitplan, bis wann was im Griff ist. Nachbearbeitung des Events/Incidents; Wichtig: Behebung der Ursache, sich nicht auf die Symptombekämpfung beschränken!! Vorbeugende Massnahmen: Regelmässige Vulnerability Scans sollten die Zahl der Events/Incidents reduzieren helfen. Bsp.: ORACLE: Default Passwörter sollten dadurch generell nicht mehr vorkommen. 17
SECTION 5 Fragen/Diskussion
Discussion t277325 [printed: April 17, 2007 9:28 AM] [saved: April 20, 2007 3:13 PM] P:\My Documents\ISSS_Keynote_2007\ISSS_Keynote_2007d_final.ppt Danke! Fragen? 19