Audyt Wewnetrzny W Zakresie Bezpieczenstwa
0 likes2,351 views
Prezentacja dla studentów Podyplomowych Studiów Zarządzania Bezpieczeństwem Informacji w Szkole Głównej Handlowej (SGH), kwiecień 2010.
Audyt Wewnetrzny W Zakresie Bezpieczenstwa
- 1. Audyt wewnętrzny w zakresie bezpieczeństwa Paweł Krawczyk
- 2. Kontakt z autorem: [email protected] Tel. +48-602-776959 Prezentacja udostępniona na licencji Creative Commons BY-NC-SA („uznanie autorstwa“, „użycie niekomercyjne“, „na tych samych warunkach“) http://creativecommons.org/licenses/by-nc-sa/3.0/pl/
- 3. Konspekt ● Standardy i normy ● Pomiary bezpieczeństwa ● Audyty, testy penetracyjne ● Modele budowy bezpiecznych systemów
- 4. Standardy i normy Bezpieczeństwa teleinformatycznego
- 5. Terminologia ● ISMS – Information Security Management System ● SZBI – System Zarządzania Bezpieczeństwem Informacji ● Polityki, standardy, procedury, zasoby, delegacje odpowiedzialności i struktura organizacyjna służąca zarządzaniu bezpieczeństwem informacji ● Otoczenie prawne i normatywne związane z ISMS
- 6. ISO 27001 ● ISO 27* (27001,27002 i inne) ● Model PDCA (Plan-Do-Check-Act) ● Rekomendacje w zakresie podnoszenia poziomu bezpieczeństwa informacji ● Wytyczne dla analizy ryzyka, oceny bezpieczeństwa ● Kontrolna lista audytowa (ISO 27001)
- 7. ISO 27001 ● British Standards Institute (BSI) ● BS 7799-2:1999 ● BS 7799-2:2002 ● Przyjęte przez ISO ● ISO/IEC 27001:2005 ● Certyfikacja ISO 27001 ● Szereg wersji krajowych ● Np. PN ISO/IEC 27001 ● Problem aktualności wersji krajowych
- 9. ISO 27002 ● BS 7799-1:1999 (uwaga! BS 7799-2 to ISO 27001) ● Przyjęte przez ISO jako ISO/IEC 17799:2000 ● ISO/IEC 17799:2000 ● Nowa wersja ISO/IEC 17799:2005 ● ISO/IEC 17799:2005 ● Zmiana numeracji na ISO/IEC 27002:2007 ● ISO/IEC 27002:2007 ● Większość aktualnych publikacji posługuje się nazwą ISO 27002 ● W Polsce 17799:2007 na bazie ISO 17799:2005
- 10. Historia ISO 27001 i 27002 BS 7799-1:1999 BS 7799-2:1999 ISO 17799:2000 BS 7799-2:2002 ISO 27001:2005 ISO 17799:2005 ISO 27002:2007
- 11. ISO 27001 i 27002 ● ISO 27001 ● ISO 27002 ● Jak nadzorować i ● Jak budować ISMS? monitorować ISMS? ● Annex A ● Annex A – Lista kontrolna – Lista kontrolna zabezpieczeń zabezpieczeń – Jak to zrobić? – Co powinno być – Rekomendacje zrobione? – Numeracja odpowiada – Lista audytowa 27001 – Numeracja odpowiada 27002
- 12. ISO 27001 jako standard audytowy ● ISMS zarządzany na podstawie 27002 ● Poprawność działania weryfikowana z 27001 ● Audyt wewnętrzny ● Cykliczna weryfikacja poprawności ISMS ● Audyt zewnętrzny ● Na żądanie klienta, regulatora ● W celu uzyskania certyfikatu
- 13. Certyfikacja ISO 27001 ● Certyfikat na podstawie audytu ● Np. A.10.10.6: „System clocks on all systems should be synchronized based on a common time source” ● Proces certyfikacji ● Prowadzony przez niezależną organizację ● Audytowany jest określony zakres (scope) ● Zakres definiowany przez podmiot występujący o certyfikację
- 18. Inne standardy
- 19. COBIT ● COBIT (Control Objectives for Information and related Technology ) ● Standardowe miary, wskaźniki, procesy i rekomendacje, kontrolna lista audytowa ● Maksymalizacja efektywności systemów IT ● Część DS5 – Ensure Systems Security ● Kompatybilny z ISO 27002 ● Organizacja: ISACA – Wsparcie "Big 4"
- 20. ITIL ● ITIL (Information Technology Infrastructure Libary) ● Model PDCA ● Procesy i zalecenia dla maksymalizacji efektywności usług IT i zarządzania infrastrukturą IT ● Kompatybilny z ISO 27002 ● Organizacja: Central Computers and Communications Agency (CCTA, UK)
- 21. NIST ● National Institutes of Standards and Technology (NIST) ● FIPS – Federal Information Processing Standards – Normy (wiążące dla amerykańskiej administracji) ● SP – Special Publications – Rekomendacje, najlepsze praktyki ● Godne uwagi ● Bardzo szeroki zakres ● Częste aktualizacje ● Także niskopoziomowe i techniczne
- 22. NIST SP ● SP 800-39 „Managing Risk from Information Systems. Organizational Perspective” ● SP 800-60 „Guide for Mapping Types of Information and Information Systems to Security Categories” ● SP 800-53 „Recommended Security Controls for Federal Information Systems” ● SP 800-70 „National Checklist Program for IT Products-- Guidelines for Checklist Users and Developers” ● SP 800-53A „Guide for Assessing the Security Controls in Federal Information Systems” ● SP 800-37 „Guide for Security Authorization of Federal Information Systems: A Security Lifecycle Approach”
- 23. ISF SOGP ● ISF (Information Security Forum) ● Standard of Good Practice for Information Security ● Integracja z innymi standardami ● ISO 27002, COBIT, SOX, PCI DSS, BASEL II, Dyrektywa EU o ochronie danych osobowych
- 24. Inne ● SAS70 (Statement of Auditing Standards) ● AICPA (American Institute of Certified Public Accountants) ● PCI (Payment Card Industry) ● DSS (Data Security Standard) ● SOX (Sarbanes-Oxley) ● PCAOB ● Europejska dyrektywa o ochronie danych osobowych ● Ustawa o ochronie danych osobowych (uodo) ● GIODO
- 25. ISO 27003 Information security management system implementation guidance Guidance on using PDCA method 1. Introduction 2. Scope 3. Terms & Definitions 4. CSFs (Critical success factors) 5. Guidance on process approach 6. Guidance on using PDCA 7. Guidance on Plan Processes 8. Guidance on Do Processes 9. Guidance on Check Processes 10. Guidance on Act Processes 11. Inter-Organization Co-operation
- 26. ISO 27004 Information security management -- Measurement The standard is intended to help organizations measure and report the effectiveness of their information security management systems, covering both the security management processes (defined in ISO/IEC 27001) and the security controls (ISO/IEC 27002).
- 27. ISO/IEC 27005 Information security risk management ISO/IEC 27005:2008 provides guidelines for information security risk management. It supports the general concepts specified in ISO/IEC 27001 and is designed to assist the satisfactory implementation of information security based on a risk management approach. ● Por. ISO 31000 ● Risk management -- Principles and guidelines on implementation ● Por. NIST SP 800-30
- 28. ISO 27007 Guidelines for information security management systems auditing This standard will provide guidance for accredited certification bodies, internal auditors, external/third party auditors and others auditing Information Security Management Systems against ISO/IEC 27001 (i.e. auditing the management system for compliance with the standard) but may also offer advice to those auditing or reviewing ISMSs against ISO/IEC 27002 (i.e. auditing the organization’s controls for their suitability in managing information security risks) although this may be covered instead by ISO/IEC TR 27008.
- 29. Narzędzia ● ISO27k Toolkit ● MS Excel ● EBIOS (Francja, DSSI) ● Java ● SOMAP ● Open Information Security Risk Assessment Guide ● SOBF (Security Officer’s Best Friend) – Java ● Duży rynek narzędzi komercyjnych
- 31. Miary bezpieczeństwa ● Na potrzeby analizy ryzyka (risk analysis) ● Jakościowa (qualitative) – Low/Medium/High ● Ilościowa (quantitative) – SLE, ALE ($) ● Na potrzeby zarządzania podatnościami (vulnerability management) ● Standardyzacja podatności – CVE, CCE, CPE, CWE – BID, QID, Microsoft, Secunia... ● Standardyzacja stopnia zagrożenia (impact) – Umowna klasyfikacja katalogowa (severity) – CVSS (Common Vulnerability Scoring System)
- 32. Standardyzacja podatności ● NIST NVD (National Vulnerability Database) ● CVE (Common Vulnerability Enumeration – „Microsoft Windows Server Service Could Allow Remote Code Execution” (CVE-2008-4250) ● CWE (Common Weakness Enumeration) – "Cross Site Request Forgery" (CWE-352) ● CCE (Common Misconfigurations Enumeration) – W trakcie opracowywania... ● CPE (Common Platform Enumeration) – cpe:/a:apache:apache-ssl:1.37
- 33. Standardyzacja podatności ● Inne katalogi podatności ● SecurityFocus (BID), Secunia (SA), Qualys (QID), VUPEN, OSVDB... ● Klasyfikacja producentów oprogramowania ● Microsoft, Sun, Cisco...
- 34. Standardyzacja stopnia zagrożenia ● Umowna producentów (severity) ● Opisowa (Low/Medium/High/Urgent/Critical...) ● Liczbowa (1-5) ● NIST CVSS (Common Vulnerability Scoring System) ● Obiektywizacja kryteriów ● Umożliwia wycenę podatności w dużej skali ● Wycena ułatwia przydział zasobów
- 35. CVSS ● Base CVSS ● Odzwierciedla stałą charakterystykę podatności – Zdalna/lokalna? Trudna/łatwa? Uwierzytelnienie? ● Temporal CVSS ● Charakterystyka zmienna w czasie – Potwierdzona/niepotwierdzona? Exploit? Poprawki? ● Environmental CVSS ● Zagrożenie w konkrentym środowisku lokalnym – E-CVSS danego serwera versus CVSS podatności
- 36. Przykład CVSS ● Podatności w Microsoft RPC DCOM ● CVE-2003-0352 (Blaster) – Nie daje uprawnień administratora – CVSS=7,5 ● CVE-2003-0715 – Daje uprawnienia administratora – CVSS=10 (max) ● Poza tym Base CVSS wysokie – Dostępna przez sieć – Łatwość ataku – Bez uwierzytelnienia
- 37. Metody pomiaru bezpieczeństwa ● Audyt ● Systematyczny, powtarzalny, obiektywny, ograniczony zakres oceny, globalnie rozpoznawany ● Test penetracyjny ● Szerszy zakres , ocena całościowego stanu bezpieczeństwa, aktualny stan wiedzy, częściowo systematyczny, uzależniony od kompetencji zespołu ● Ocena bezpieczeństwa ● Zastosowanie wiedzy i doświadczenia eksperta, aktualny stan wiedzy
- 38. Metody pomiaru bezpieczeństwa ● Pomiary powtarzalne ● Statystyki operacyjne z procesów biznesowych – Liczba eskalacji? Liczba opóźnień? Liczba fraudów? ● Narzędzia do oceny podatności (vulnerability assessment) – Skanery działające w trybie ciągłym (tydzień, miesiąc) – Cykliczne testy penetracyjne ● Analiza zdarzeń – Firewalle, systemy IDS/IPS – Logi systemowe (system alerts)
- 40. Audyt bezpieczeństwa systemu "Dokonanie niezależnego przeglądu i oceny działania systemu w celu przetestowania adekwatności środków nadzoru systemu, upewnienia się, czy system działa zgodnie z ustaloną polityką bezpieczeństwa i z procedurami operacyjnymi oraz w celu wykrycia przełamań bezpieczeństwa i zalecenia wskazanych zmian w środkach nadzorowania, polityce bezpieczeństwa oraz w procedurach" Źródło: PN-I-02000:2002, pkt 3.1.007 "usystematyzowany, niezależny i udokumentowany proces uzyskania dowodu z auditu i obiektywnej oceny w celu określenia w jakim stopniu spełniono uzgodnione kryteria auditu" Źródło: PN-EN ISO 9000:2001, pkt 3.9.1
- 41. Cele audytów ● Obiektywizacja kryteriów ● Niewspółmierna rola systemów IT ● Minimalny standard jakości (baseline) ● Różne poziomy dojrzałości uczestników rynku (maturity levels) ● Podstawa do przyjęcia zobowiązań ● Łańcuch dostaw, podwykonawcy ● SLA (Service Level Agreement)
- 42. Cele audytu wewnętrznego ● Ocena zgodności procesów z celami organizacji ● Optymalizacja procesów ● Przywrócenie odpowiednich priorytetów zadań ● Ograniczenie zjawiska "przesunięcia celów" ● Psychologiczne bariery audytu - zapobieganie ● Audyt nie służy "zwalczaniu" kogokolwiek ● Audyt to nie kontrola ● Audyt ma pomóc, nie przeszkadzać
- 43. Cele audytu zewnętrznego ● Zlecany przez organizację ● Cele jak w audycie wewnętrznym ● Zlecany przez trzecią stronę ● Zgodność z regulacjami (legal compliance) ● Zgodność z deklaracjami organizacji ● Ocena przed transakcja (due dilligence)
- 44. Audyt niezależny ● Nie wykonuje go ● Projektant, dostawca, wykonawca, integrator ● Audyt wewnętrzny (pierwszej strony) ● Niezależność w hierarchii służbowej ● Audyt zewnętrzny (drugiej, trzeciej strony) ● Niezależność organizacyjna
- 45. Audyt systematyczny ● Powtarzalność ● Plan audytu, metodyka, minimalne wymagania ● Obiektywność ● Brak uznaniowości w interpretacji faktów – Co jest "wystarczająco bezpieczne" a co nie ● Ściśle określone kryteria zgodności
- 46. Audyt systematyczny ● Ustalona lista kontrolna (checklist) – Zamknięta, kompletna – Punkt odniesienia do protokołu rozbieżności (gap analysis) – Na podstawie standardów lub przepisów – Polityki, standardy, procedury organizacji ● Czy można prowadzić audyt bez punktu odniesienia? ● Wady listy kontrolnej ● Wysokopoziomowa, statyczna
- 47. Audyt udokumentowany ● Dowód (evidence) jako krytyczna część audytu ● Na pytania z listy kontrolnej odpowiada audytor – Nie audytowany ● Odpowiedzi na podstawie dowodów ● Źródła informacji audytowych ● Ankiety, wywiady (próba statystyczna) ● Wizja lokalna ● Dokumentacja strategiczna i operacyjna ● Analizy, testy i badania
- 48. Warunki obiektywności ● Audytor ocenia dowody ● Nie opinie audytowanego ● Audytor ocenia zgodność z założeniami ● Ocenę rozbieżności prowadzi adresat audytu ● Audytor wybiera próbki audytowe ● Ocena losowych próbek z dużych ilości obiektów ● Czy próbka jest losowa? ● Czy próbka jest reprezentatywna? ● Dlaczego wybrano te, a nie inne obiekty?
- 49. Istotne cechy audytu ● Ograniczony do zdefiniowanego zakresu ● Brak oceny obiektu, który nie jest przedmiotem audytu ● Ograniczony do punktu odniesienia ● Brak oceny obiektu wg kryteriów nie ujętych w liście kontrolnej ● Brak gwarancji "ogólnego bezpieczeństwa" ● Produkt lub proces pozytywnie zaudytowany nadal może mieć istotne podatności
- 50. Metodyka audytu ● LP-A (Liderman-Patkowski, WAT) ● Oparty o ISO 27001 ● Skład zespołu audytowego ● 2 audytorów, 3 specjalistów audytowych ● Personel pomocniczy (ankieterzy itd) ● Eksperci z poszczególnych dziedzin ● Narzędzia audytowe (skanery)
- 51. Proces audytu #1 ● Przygotowanie audytu ● Udzielenie uprawnień, osoby kontaktowe, zasady komunikacji, harmonogram, szkolenie zarządu organizacji audytowanej ● Ścieżka formalna ● Badanie jakości zarządzania ISMS – dokumentacja oficjalna, dokumenty operacyjne, ankiety
- 52. Proces audytu #2 ● Ścieżka techniczna ● Analiza architektury systemów IT, analiza stanu faktycznego infrastruktury ● Przegląd i ocena zabezpieczeń ● Prezentacja wyników audytu ● Protokół rozbieżności ● Zalecenia pokontrolne
- 54. Rola audytu i testu penetracyjnego ● Ograniczenia audytu ● Szybkie zmiany w technologii – Czas życia standardów audytowych – lata – Czas życia typowych podatności w systemach – dni ● Zakres oceny audytowej – Może nie obejmować wszystkich aspektów i scenariuszy ● Rola testu penetracyjnego ● Ocena praktycznego, chwilowego stanu bezpieczeństwa, ● Konkretny, działający system ● Próba uzyskania dowodu nieskuteczności
- 55. Cechy testów penetracyjnych ● Szeroki zakres ● Testy od wysoko- do niskopoziomowych ● Wszystkie komponenty systemu ● Cel – dowolny scenariusz prowadzący do przełamania zabezpieczeń ● Utrudniona powtarzalność ● Zależny od kompetencji zespołu ● Zależny od aktualnego stanu wiedzy ● Zależny od dostępu do informacji
- 56. Próby standardyzacji ● Algorytm testu penetracyjnego ● 1) Sprawdź wersję serwera WWW, 2) sprawdź w bazie znane podatności, 3) ... ● Nadal ograniczone kompetencjami zespołu ● Zbyt duża liczba scenariuszy ● Główna zaleta testu penetracyjnego ● Możliwość odkrycia nowych ataków dzięki kreatywności zespołu ● Możliwość wskazania niestandardowych scenariuszy ataku
- 57. Co należy standardyzować? ● Kroki, które muszą być wykonane ● Minimalne wymagania ● Zakres informacji dokumentowanej ● Zakres informacji raportowanej ● Zasady komunikacji ● Zakres testu ● Np. daty i godziny wykonywania testów ● Wymagania formalne ● Np. upoważnienie do testu
- 58. Kwestie prawne ● Kodeks karny ● Przestępstwa przeciwko ochronie informacji – Art. 265-269b kk – "Oprogramowanie hakerskie" (art. 269b) ● Obowiązki zespołu testującego ● Pisemne upoważnienie właściciela systemu ● Precyzyjnie opisany zakres upoważnienia ● Dokumentacja działań testowych ● Dokumentacja kontaktów z klientem
- 59. Kiedy test ma sens? ● Przed udostępnieniem aplikacji w sieci ● Później może być za późno ● Prowadzony na produkcyjnej wersji systemu ● Takiej, jaka będzie dostępna dla klientów ● Zakończone prace rozwojowe ● Testy funkcjonalne, poprawki, zmiany ● Czas testu uwzględniony w harmonogramie ● Jeśli wyniki mają być miarodajne
- 60. Test penetracyjny a włamanie ● Test penetracyjny trudniejszy niż włamanie ● Konieczność sprawdzenia wszystkich scenariuszy – Włamanie – najkrótszą drogą do celu ● Konieczność dokumentacji działań – Włamanie – nie ma takiej potrzeby ● Wymaganie wobec zespołu testującego – Kwestie etyczne, systematyczność, rzetelność
- 61. Metody testowania ● "Black box" ● Ograniczona wiedza zespołu testującego ● Zalety – brak uprzedzeń, kwestie psychologiczne ● Wady – brak widoczności niektórych trywialnych zagrożeń ● "Crystal box" ● Pełny dostęp zespołu do "środka" systemu ● Zalety – lepsza widoczność nietypowych scenariuszy ● Wady – możliwość przyjęcia błędnych założeń
- 62. Istniejące metodyki ● OSSTMM (Open Source Security Testing Methodology Manual) ● NIST SP800-42 „Guideline on Network Security Testing „ ● NIST SP800-115 „Technical Guide to Information Security Testing" ● OISSG „ISSAF Penetration Testing Framework” ● P-PEN (Patkowski, WAT) ● MindCert Certified Ethical Hacker mind-map series ● OWASP (Open Web Application Security Project) ● Penetration Testing Framework (Kevin Orrey)
- 63. Typowy scenariusz testu ● Enumeracja i inwentaryzacja zasobów ● Skan podsieci IP ● Enumeracja usług ● Skan portów, protokołów ● Enumeracja aplikacji ● Skan odpowiedzi na portach, nagłówki, wersje... ● Wartość dodana ● O czym klient nie wiedział wcześniej?
- 64. Mapowanie podatności ● Zasoby, usługi, aplikacje ● Jakie znane podatności? – Np. wykryta wersja serwera Apache/1.3.18 ● Jakie znane podatności? – Czy są praktyczne? – Cel – stwierdzenie podatności ● Testowanie (exploit) tylko za zgodą klienta ● Brak podatności, wersja – wartościowa informacja – Załączyć do raportu, ocena przydatności przez klienta
- 65. Aspekt skali ● Różne zakresy testów ● Jeden serwer? Sto serwerów? 10 tys. stacji roboczych? ● Testy zautomatyzowane ● Testy losowej próbki ● Dobre wyniki w jednorodnej grupie ● Konieczność inwentaryzacji całości i agregacji podobnych grup
- 66. Skanery automatyczne ● Ogólnego przeznaczenia ● Nessus, OpenVAS, QualysGuard, IBM Internet Scanner... ● Wykrywanie sygnaturowe ● Zalety ● Masowe, cykliczne skany podobnych zasobów ● Wady ● Możliwość pominięcia nietypowych zasobów ● Niska skuteczność wobec aplikacji webowych
- 67. Skanery automatyczne ● Aplikacje webowe ● IBM Rational AppScan (WatchFire), HP WebInspect, Acunetix ● Wykrywanie sygnaturowe plus uniwersalne techniki ataków ● Zalety ● Przewaga w testach rozbudowanych aplikacji ● Wady ● Możliwość pominięcia oczywistych, choć nietypowych podatności ● Niska skuteczność w testowaniu logiki biznesowej
- 68. Jakość testów penetracyjnych ● Metodyki testów penetracyjnych ● Raczej "lista zadań" niż "lista kontrolna" ● Próby standardyzacji dokładności testu ● OWASP ASVS (Application Security Verification Standard) – Level 1 – Automated verification – Level 2 – Manual verification – Level 3 – Design verification – Level 4 – Internal verification
- 69. Statyczna analiza kodu ● Ograniczenia badania behawioralnego ● Nietypowe scenariusze ● Moduły nieujawnione w interfejsie ● Błędy w logice biznesowej ● Statyczna analiza kodu (SCA – Static Code Analysis) ● Ręczna ● Automatyczna – Veracode, Fortify, Checkmarx, Ounce Labs...
- 70. Kontakt z autorem: [email protected] Tel. +48-602-776959 Prezentacja udostępniona na licencji Creative Commons BY-NC-SA („uznanie autorstwa“, „użycie niekomercyjne“, „na tych samych warunkach“) http://creativecommons.org/licenses/by-nc-sa/3.0/pl/
- 71. Audyt wewnętrzny w zakresie bezpieczeństwa Paweł Krawczyk 1
- 72. Kontakt z autorem: [email protected] Tel. +48-602-776959 Prezentacja udostępniona na licencji Creative Commons BY-NC-SA („uznanie autorstwa“, „użycie niekomercyjne“, „na tych samych warunkach“) http://creativecommons.org/licenses/by-nc-sa/3.0/pl/ 2 Literatura: http://ipsec.pl/ http://securitystandard.pl/ Andrew Jaquith, "Security metrics"
- 73. Konspekt ● Standardy i normy ● Pomiary bezpieczeństwa ● Audyty, testy penetracyjne ● Modele budowy bezpiecznych systemów 3
- 74. Standardy i normy Bezpieczeństwa teleinformatycznego 4
- 75. Terminologia ● ISMS – Information Security Management System ● SZBI – System Zarządzania Bezpieczeństwem Informacji ● Polityki, standardy, procedury, zasoby, delegacje odpowiedzialności i struktura organizacyjna służąca zarządzaniu bezpieczeństwem informacji ● Otoczenie prawne i normatywne związane z ISMS 5
- 76. ISO 27001 ● ISO 27* (27001,27002 i inne) ● Model PDCA (Plan-Do-Check-Act) ● Rekomendacje w zakresie podnoszenia poziomu bezpieczeństwa informacji ● Wytyczne dla analizy ryzyka, oceny bezpieczeństwa ● Kontrolna lista audytowa (ISO 27001) 6
- 77. ISO 27001 ● British Standards Institute (BSI) ● BS 7799-2:1999 ● BS 7799-2:2002 ● Przyjęte przez ISO ● ISO/IEC 27001:2005 ● Certyfikacja ISO 27001 ● Szereg wersji krajowych ● Np. PN ISO/IEC 27001 ● Problem aktualności wersji krajowych 7
- 78. 8
- 79. ISO 27002 ● BS 7799-1:1999 (uwaga! BS 7799-2 to ISO 27001) ● Przyjęte przez ISO jako ISO/IEC 17799:2000 ● ISO/IEC 17799:2000 ● Nowa wersja ISO/IEC 17799:2005 ● ISO/IEC 17799:2005 ● Zmiana numeracji na ISO/IEC 27002:2007 ● ISO/IEC 27002:2007 ● Większość aktualnych publikacji posługuje się nazwą ISO 27002 ● W Polsce 17799:2007 na bazie ISO 17799:2005 9
- 80. Historia ISO 27001 i 27002 BS 7799-1:1999 BS 7799-2:1999 ISO 17799:2000 BS 7799-2:2002 ISO 27001:2005 ISO 17799:2005 ISO 27002:2007 10
- 81. ISO 27001 i 27002 ● ISO 27001 ● ISO 27002 ● Jak nadzorować i ● Jak budować ISMS? monitorować ISMS? ● Annex A ● Annex A – Lista kontrolna – Lista kontrolna zabezpieczeń zabezpieczeń – Jak to zrobić? – Co powinno być – Rekomendacje zrobione? – Numeracja odpowiada – Lista audytowa 27001 – Numeracja odpowiada 27002 11
- 82. ISO 27001 jako standard audytowy ● ISMS zarządzany na podstawie 27002 ● Poprawność działania weryfikowana z 27001 ● Audyt wewnętrzny ● Cykliczna weryfikacja poprawności ISMS ● Audyt zewnętrzny ● Na żądanie klienta, regulatora ● W celu uzyskania certyfikatu 12
- 83. Certyfikacja ISO 27001 ● Certyfikat na podstawie audytu ● Np. A.10.10.6: „System clocks on all systems should be synchronized based on a common time source” ● Proces certyfikacji ● Prowadzony przez niezależną organizację ● Audytowany jest określony zakres (scope) ● Zakres definiowany przez podmiot występujący o certyfikację 13
- 84. 14
- 85. 15
- 86. 16
- 87. 17 Źródła wykresów: Certification News, 2008 PBSG, www.iso27000.pl, 2010
- 88. Inne standardy 18
- 89. COBIT ● COBIT (Control Objectives for Information and related Technology ) ● Standardowe miary, wskaźniki, procesy i rekomendacje, kontrolna lista audytowa ● Maksymalizacja efektywności systemów IT ● Część DS5 – Ensure Systems Security ● Kompatybilny z ISO 27002 ● Organizacja: ISACA – Wsparcie "Big 4" 19
- 90. ITIL ● ITIL (Information Technology Infrastructure Libary) ● Model PDCA ● Procesy i zalecenia dla maksymalizacji efektywności usług IT i zarządzania infrastrukturą IT ● Kompatybilny z ISO 27002 ● Organizacja: Central Computers and Communications Agency (CCTA, UK) 20
- 91. NIST ● National Institutes of Standards and Technology (NIST) ● FIPS – Federal Information Processing Standards – Normy (wiążące dla amerykańskiej administracji) ● SP – Special Publications – Rekomendacje, najlepsze praktyki ● Godne uwagi ● Bardzo szeroki zakres ● Częste aktualizacje ● Także niskopoziomowe i techniczne 21
- 92. NIST SP ● SP 800-39 „Managing Risk from Information Systems. Organizational Perspective” ● SP 800-60 „Guide for Mapping Types of Information and Information Systems to Security Categories” ● SP 800-53 „Recommended Security Controls for Federal Information Systems” ● SP 800-70 „National Checklist Program for IT Products-- Guidelines for Checklist Users and Developers” ● SP 800-53A „Guide for Assessing the Security Controls in Federal Information Systems” ● SP 800-37 „Guide for Security Authorization of Federal Information Systems: A Security Lifecycle Approach” 22
- 93. ISF SOGP ● ISF (Information Security Forum) ● Standard of Good Practice for Information Security ● Integracja z innymi standardami ● ISO 27002, COBIT, SOX, PCI DSS, BASEL II, Dyrektywa EU o ochronie danych osobowych 23
- 94. Inne ● SAS70 (Statement of Auditing Standards) ● AICPA (American Institute of Certified Public Accountants) ● PCI (Payment Card Industry) ● DSS (Data Security Standard) ● SOX (Sarbanes-Oxley) ● PCAOB ● Europejska dyrektywa o ochronie danych osobowych ● Ustawa o ochronie danych osobowych (uodo) ● GIODO 24
- 95. ISO 27003 Information security management system implementation guidance Guidance on using PDCA method 1. Introduction 2. Scope 3. Terms & Definitions 4. CSFs (Critical success factors) 5. Guidance on process approach 6. Guidance on using PDCA 7. Guidance on Plan Processes 8. Guidance on Do Processes 9. Guidance on Check Processes 10. Guidance on Act Processes 11. Inter-Organization Co-operation 25
- 96. ISO 27004 Information security management -- Measurement The standard is intended to help organizations measure and report the effectiveness of their information security management systems, covering both the security management processes (defined in ISO/IEC 27001) and the security controls (ISO/IEC 27002). 26
- 97. ISO/IEC 27005 Information security risk management ISO/IEC 27005:2008 provides guidelines for information security risk management. It supports the general concepts specified in ISO/IEC 27001 and is designed to assist the satisfactory implementation of information security based on a risk management approach. ● Por. ISO 31000 ● Risk management -- Principles and guidelines on implementation ● Por. NIST SP 800-30 27
- 98. ISO 27007 Guidelines for information security management systems auditing This standard will provide guidance for accredited certification bodies, internal auditors, external/third party auditors and others auditing Information Security Management Systems against ISO/IEC 27001 (i.e. auditing the management system for compliance with the standard) but may also offer advice to those auditing or reviewing ISMSs against ISO/IEC 27002 (i.e. auditing the organization’s controls for their suitability in managing information security risks) although this may be covered instead by ISO/IEC TR 27008. 28
- 99. Narzędzia ● ISO27k Toolkit ● MS Excel ● EBIOS (Francja, DSSI) ● Java ● SOMAP ● Open Information Security Risk Assessment Guide ● SOBF (Security Officer’s Best Friend) – Java ● Duży rynek narzędzi komercyjnych 29
- 100. Pomiary bezpieczeństwa 30
- 101. Miary bezpieczeństwa ● Na potrzeby analizy ryzyka (risk analysis) ● Jakościowa (qualitative) – Low/Medium/High ● Ilościowa (quantitative) – SLE, ALE ($) ● Na potrzeby zarządzania podatnościami (vulnerability management) ● Standardyzacja podatności – CVE, CCE, CPE, CWE – BID, QID, Microsoft, Secunia... ● Standardyzacja stopnia zagrożenia (impact) – Umowna klasyfikacja katalogowa (severity) 31 – CVSS (Common Vulnerability Scoring System)
- 102. Standardyzacja podatności ● NIST NVD (National Vulnerability Database) ● CVE (Common Vulnerability Enumeration – „Microsoft Windows Server Service Could Allow Remote Code Execution” (CVE-2008-4250) ● CWE (Common Weakness Enumeration) – "Cross Site Request Forgery" (CWE-352) ● CCE (Common Misconfigurations Enumeration) – W trakcie opracowywania... ● CPE (Common Platform Enumeration) – cpe:/a:apache:apache-ssl:1.37 32
- 103. Standardyzacja podatności ● Inne katalogi podatności ● SecurityFocus (BID), Secunia (SA), Qualys (QID), VUPEN, OSVDB... ● Klasyfikacja producentów oprogramowania ● Microsoft, Sun, Cisco... 33 Example: „Microsoft Windows Server Service Could Allow Remote Code Execution” - CVE-2008-4250 – QID (Qualys Guard) – 90464 – BID – 31874 – Microsoft – MS08-067 – Secunia – SA32326 - VUPEN/ADV-2008-2902 - OSVDB 49253
- 104. Standardyzacja stopnia zagrożenia ● Umowna producentów (severity) ● Opisowa (Low/Medium/High/Urgent/Critical...) ● Liczbowa (1-5) ● NIST CVSS (Common Vulnerability Scoring System) ● Obiektywizacja kryteriów ● Umożliwia wycenę podatności w dużej skali ● Wycena ułatwia przydział zasobów 34
- 105. CVSS ● Base CVSS ● Odzwierciedla stałą charakterystykę podatności – Zdalna/lokalna? Trudna/łatwa? Uwierzytelnienie? ● Temporal CVSS ● Charakterystyka zmienna w czasie – Potwierdzona/niepotwierdzona? Exploit? Poprawki? ● Environmental CVSS ● Zagrożenie w konkrentym środowisku lokalnym – E-CVSS danego serwera versus CVSS podatności 35
- 106. Przykład CVSS ● Podatności w Microsoft RPC DCOM ● CVE-2003-0352 (Blaster) – Nie daje uprawnień administratora – CVSS=7,5 ● CVE-2003-0715 – Daje uprawnienia administratora – CVSS=10 (max) ● Poza tym Base CVSS wysokie – Dostępna przez sieć – Łatwość ataku – Bez uwierzytelnienia 36
- 107. Metody pomiaru bezpieczeństwa ● Audyt ● Systematyczny, powtarzalny, obiektywny, ograniczony zakres oceny, globalnie rozpoznawany ● Test penetracyjny ● Szerszy zakres , ocena całościowego stanu bezpieczeństwa, aktualny stan wiedzy, częściowo systematyczny, uzależniony od kompetencji zespołu ● Ocena bezpieczeństwa ● Zastosowanie wiedzy i doświadczenia eksperta, aktualny stan wiedzy 37
- 108. Metody pomiaru bezpieczeństwa ● Pomiary powtarzalne ● Statystyki operacyjne z procesów biznesowych – Liczba eskalacji? Liczba opóźnień? Liczba fraudów? ● Narzędzia do oceny podatności (vulnerability assessment) – Skanery działające w trybie ciągłym (tydzień, miesiąc) – Cykliczne testy penetracyjne ● Analiza zdarzeń – Firewalle, systemy IDS/IPS – Logi systemowe (system alerts) 38
- 110. Audyt bezpieczeństwa systemu "Dokonanie niezależnego przeglądu i oceny działania systemu w celu przetestowania adekwatności środków nadzoru systemu, upewnienia się, czy system działa zgodnie z ustaloną polityką bezpieczeństwa i z procedurami operacyjnymi oraz w celu wykrycia przełamań bezpieczeństwa i zalecenia wskazanych zmian w środkach nadzorowania, polityce bezpieczeństwa oraz w procedurach" Źródło: PN-I-02000:2002, pkt 3.1.007 "usystematyzowany, niezależny i udokumentowany proces uzyskania dowodu z auditu i obiektywnej oceny w celu określenia w jakim stopniu spełniono uzgodnione kryteria auditu" Źródło: PN-EN ISO 9000:2001, pkt 3.9.1 40
- 111. Cele audytów ● Obiektywizacja kryteriów ● Niewspółmierna rola systemów IT ● Minimalny standard jakości (baseline) ● Różne poziomy dojrzałości uczestników rynku (maturity levels) ● Podstawa do przyjęcia zobowiązań ● Łańcuch dostaw, podwykonawcy ● SLA (Service Level Agreement) 41
- 112. Cele audytu wewnętrznego ● Ocena zgodności procesów z celami organizacji ● Optymalizacja procesów ● Przywrócenie odpowiednich priorytetów zadań ● Ograniczenie zjawiska "przesunięcia celów" ● Psychologiczne bariery audytu - zapobieganie ● Audyt nie służy "zwalczaniu" kogokolwiek ● Audyt to nie kontrola ● Audyt ma pomóc, nie przeszkadzać 42
- 113. Cele audytu zewnętrznego ● Zlecany przez organizację ● Cele jak w audycie wewnętrznym ● Zlecany przez trzecią stronę ● Zgodność z regulacjami (legal compliance) ● Zgodność z deklaracjami organizacji ● Ocena przed transakcja (due dilligence) 43
- 114. Audyt niezależny ● Nie wykonuje go ● Projektant, dostawca, wykonawca, integrator ● Audyt wewnętrzny (pierwszej strony) ● Niezależność w hierarchii służbowej ● Audyt zewnętrzny (drugiej, trzeciej strony) ● Niezależność organizacyjna 44
- 115. Audyt systematyczny ● Powtarzalność ● Plan audytu, metodyka, minimalne wymagania ● Obiektywność ● Brak uznaniowości w interpretacji faktów – Co jest "wystarczająco bezpieczne" a co nie ● Ściśle określone kryteria zgodności 45
- 116. Audyt systematyczny ● Ustalona lista kontrolna (checklist) – Zamknięta, kompletna – Punkt odniesienia do protokołu rozbieżności (gap analysis) – Na podstawie standardów lub przepisów – Polityki, standardy, procedury organizacji ● Czy można prowadzić audyt bez punktu odniesienia? ● Wady listy kontrolnej ● Wysokopoziomowa, statyczna 46
- 117. Audyt udokumentowany ● Dowód (evidence) jako krytyczna część audytu ● Na pytania z listy kontrolnej odpowiada audytor – Nie audytowany ● Odpowiedzi na podstawie dowodów ● Źródła informacji audytowych ● Ankiety, wywiady (próba statystyczna) ● Wizja lokalna ● Dokumentacja strategiczna i operacyjna ● Analizy, testy i badania 47
- 118. Warunki obiektywności ● Audytor ocenia dowody ● Nie opinie audytowanego ● Audytor ocenia zgodność z założeniami ● Ocenę rozbieżności prowadzi adresat audytu ● Audytor wybiera próbki audytowe ● Ocena losowych próbek z dużych ilości obiektów ● Czy próbka jest losowa? ● Czy próbka jest reprezentatywna? ● Dlaczego wybrano te, a nie inne obiekty? 48 Przykład: Na prośbę o dostarczenie próby 5% transakcji właściciel procesu biznesowego dostarcza 100 przypadków, które nie wykazują większych odchyleń od określonych wartości brzegowych. Czy taki audyt można określić mianem obiektywnego?
- 119. Istotne cechy audytu ● Ograniczony do zdefiniowanego zakresu ● Brak oceny obiektu, który nie jest przedmiotem audytu ● Ograniczony do punktu odniesienia ● Brak oceny obiektu wg kryteriów nie ujętych w liście kontrolnej ● Brak gwarancji "ogólnego bezpieczeństwa" ● Produkt lub proces pozytywnie zaudytowany nadal może mieć istotne podatności 49
- 120. Metodyka audytu ● LP-A (Liderman-Patkowski, WAT) ● Oparty o ISO 27001 ● Skład zespołu audytowego ● 2 audytorów, 3 specjalistów audytowych ● Personel pomocniczy (ankieterzy itd) ● Eksperci z poszczególnych dziedzin ● Narzędzia audytowe (skanery) 50
- 121. Proces audytu #1 ● Przygotowanie audytu ● Udzielenie uprawnień, osoby kontaktowe, zasady komunikacji, harmonogram, szkolenie zarządu organizacji audytowanej ● Ścieżka formalna ● Badanie jakości zarządzania ISMS – dokumentacja oficjalna, dokumenty operacyjne, ankiety 51
- 122. Proces audytu #2 ● Ścieżka techniczna ● Analiza architektury systemów IT, analiza stanu faktycznego infrastruktury ● Przegląd i ocena zabezpieczeń ● Prezentacja wyników audytu ● Protokół rozbieżności ● Zalecenia pokontrolne 52
- 123. Testy penetracyjne 53
- 124. Rola audytu i testu penetracyjnego ● Ograniczenia audytu ● Szybkie zmiany w technologii – Czas życia standardów audytowych – lata – Czas życia typowych podatności w systemach – dni ● Zakres oceny audytowej – Może nie obejmować wszystkich aspektów i scenariuszy ● Rola testu penetracyjnego ● Ocena praktycznego, chwilowego stanu bezpieczeństwa, ● Konkretny, działający system 54 ● Próba uzyskania dowodu nieskuteczności
- 125. Cechy testów penetracyjnych ● Szeroki zakres ● Testy od wysoko- do niskopoziomowych ● Wszystkie komponenty systemu ● Cel – dowolny scenariusz prowadzący do przełamania zabezpieczeń ● Utrudniona powtarzalność ● Zależny od kompetencji zespołu ● Zależny od aktualnego stanu wiedzy ● Zależny od dostępu do informacji 55
- 126. Próby standardyzacji ● Algorytm testu penetracyjnego ● 1) Sprawdź wersję serwera WWW, 2) sprawdź w bazie znane podatności, 3) ... ● Nadal ograniczone kompetencjami zespołu ● Zbyt duża liczba scenariuszy ● Główna zaleta testu penetracyjnego ● Możliwość odkrycia nowych ataków dzięki kreatywności zespołu ● Możliwość wskazania niestandardowych scenariuszy ataku 56
- 127. Co należy standardyzować? ● Kroki, które muszą być wykonane ● Minimalne wymagania ● Zakres informacji dokumentowanej ● Zakres informacji raportowanej ● Zasady komunikacji ● Zakres testu ● Np. daty i godziny wykonywania testów ● Wymagania formalne ● Np. upoważnienie do testu 57
- 128. Kwestie prawne ● Kodeks karny ● Przestępstwa przeciwko ochronie informacji – Art. 265-269b kk – "Oprogramowanie hakerskie" (art. 269b) ● Obowiązki zespołu testującego ● Pisemne upoważnienie właściciela systemu ● Precyzyjnie opisany zakres upoważnienia ● Dokumentacja działań testowych ● Dokumentacja kontaktów z klientem 58
- 129. Kiedy test ma sens? ● Przed udostępnieniem aplikacji w sieci ● Później może być za późno ● Prowadzony na produkcyjnej wersji systemu ● Takiej, jaka będzie dostępna dla klientów ● Zakończone prace rozwojowe ● Testy funkcjonalne, poprawki, zmiany ● Czas testu uwzględniony w harmonogramie ● Jeśli wyniki mają być miarodajne 59
- 130. Test penetracyjny a włamanie ● Test penetracyjny trudniejszy niż włamanie ● Konieczność sprawdzenia wszystkich scenariuszy – Włamanie – najkrótszą drogą do celu ● Konieczność dokumentacji działań – Włamanie – nie ma takiej potrzeby ● Wymaganie wobec zespołu testującego – Kwestie etyczne, systematyczność, rzetelność 60
- 131. Metody testowania ● "Black box" ● Ograniczona wiedza zespołu testującego ● Zalety – brak uprzedzeń, kwestie psychologiczne ● Wady – brak widoczności niektórych trywialnych zagrożeń ● "Crystal box" ● Pełny dostęp zespołu do "środka" systemu ● Zalety – lepsza widoczność nietypowych scenariuszy ● Wady – możliwość przyjęcia błędnych założeń 61
- 132. Istniejące metodyki ● OSSTMM (Open Source Security Testing Methodology Manual) ● NIST SP800-42 „Guideline on Network Security Testing „ ● NIST SP800-115 „Technical Guide to Information Security Testing" ● OISSG „ISSAF Penetration Testing Framework” ● P-PEN (Patkowski, WAT) ● MindCert Certified Ethical Hacker mind-map series ● OWASP (Open Web Application Security Project) ● Penetration Testing Framework (Kevin Orrey) 62
- 133. Typowy scenariusz testu ● Enumeracja i inwentaryzacja zasobów ● Skan podsieci IP ● Enumeracja usług ● Skan portów, protokołów ● Enumeracja aplikacji ● Skan odpowiedzi na portach, nagłówki, wersje... ● Wartość dodana ● O czym klient nie wiedział wcześniej? 63
- 134. Mapowanie podatności ● Zasoby, usługi, aplikacje ● Jakie znane podatności? – Np. wykryta wersja serwera Apache/1.3.18 ● Jakie znane podatności? – Czy są praktyczne? – Cel – stwierdzenie podatności ● Testowanie (exploit) tylko za zgodą klienta ● Brak podatności, wersja – wartościowa informacja – Załączyć do raportu, ocena przydatności przez klienta 64 Podatności: Securityfocus.com NVD (NIST) OSVDB Secunia.com Exploity: Packetstormsecurity.org Metasploit.org
- 135. Aspekt skali ● Różne zakresy testów ● Jeden serwer? Sto serwerów? 10 tys. stacji roboczych? ● Testy zautomatyzowane ● Testy losowej próbki ● Dobre wyniki w jednorodnej grupie ● Konieczność inwentaryzacji całości i agregacji podobnych grup 65
- 136. Skanery automatyczne ● Ogólnego przeznaczenia ● Nessus, OpenVAS, QualysGuard, IBM Internet Scanner... ● Wykrywanie sygnaturowe ● Zalety ● Masowe, cykliczne skany podobnych zasobów ● Wady ● Możliwość pominięcia nietypowych zasobów ● Niska skuteczność wobec aplikacji webowych 66
- 137. Skanery automatyczne ● Aplikacje webowe ● IBM Rational AppScan (WatchFire), HP WebInspect, Acunetix ● Wykrywanie sygnaturowe plus uniwersalne techniki ataków ● Zalety ● Przewaga w testach rozbudowanych aplikacji ● Wady ● Możliwość pominięcia oczywistych, choć nietypowych podatności 67 ● Niska skuteczność w testowaniu logiki biznesowej W3af – many modules (Python, command-line, GUI) Sqlmap – many variants of SQL Injection (Python, command-line) Nikto – „hidden” file and directory finder (Perl, command-line) Wikto – „hidden” file and directory finder, supports Nikto (.NET, GUI) JAD – Java decompiler (open-source) PMD – static source code checker for Java (open- source) Disassembly – IDA Pro Debuggers – OllyDbg (open-source)
- 138. Jakość testów penetracyjnych ● Metodyki testów penetracyjnych ● Raczej "lista zadań" niż "lista kontrolna" ● Próby standardyzacji dokładności testu ● OWASP ASVS (Application Security Verification Standard) – Level 1 – Automated verification – Level 2 – Manual verification – Level 3 – Design verification – Level 4 – Internal verification 68
- 139. Statyczna analiza kodu ● Ograniczenia badania behawioralnego ● Nietypowe scenariusze ● Moduły nieujawnione w interfejsie ● Błędy w logice biznesowej ● Statyczna analiza kodu (SCA – Static Code Analysis) ● Ręczna ● Automatyczna – Veracode, Fortify, Checkmarx, Ounce Labs... 69
- 140. Kontakt z autorem: [email protected] Tel. +48-602-776959 Prezentacja udostępniona na licencji Creative Commons BY-NC-SA („uznanie autorstwa“, „użycie niekomercyjne“, „na tych samych warunkach“) http://creativecommons.org/licenses/by-nc-sa/3.0/pl/ 70 Literatura: http://ipsec.pl/ http://securitystandard.pl/ Andrew Jaquith, "Security metrics"