SCAP – standaryzacja formatów wymiany danych w zakresie bezpieczeństwa IT
•Download as PPTX, PDF•
0 likes•578 views
konferencja SCS 2016, https://www.securitycasestudy.pl/
SCAP – standaryzacja formatów wymiany danych w zakresie bezpieczeństwa IT
- 1. SCAP – standaryzacja formatów wymiany danych w zakresie bezpieczeństwa IT Przemysław Frasunek Security Case Study, 14 września 2016 r.
- 2. Problematyka i potrzeby standaryzacji • Różnorodność narzędzi do badania podatności i egzekwowania polityk bezpieczeństwa • Bazy danych podatności opracowywane przez wielu dostawców • Problemy z nomenklaturą i taksonomią (np. klasyfikacja podatności) • Problemy z jednoznacznym identyfikowaniem podatności • Problemy z oceną ryzyka • Problemy z opisem incydentów i zautomatyzowaną wymianą danych pomiędzy zespołamiCERT 2
- 3. Standardy z rodziny SCAP (1) • Zbiór specyfikacji początkowo rozwijanych przez niezależne organizacje, później pod patronatem NIST (USA) • Formaty danych oraz nomenklatura wykorzystywane do sformalizowanego opisu różnych aspektów bezpieczeństwa TI • OVAL (OpenVulnerability and Assessment Language) – opisywanie podatności oraz testów ich wystąpienia • XCCDF (Extensible Configuration Checklist Description Format) – wymagania dotyczące systemu (np. polityka bezpieczeństwa) oraz automatyczne testy zgodności • OCIL (Open Checklist Interactive Language) - kwestionariusze, służące do manualnego weryfikowania poziomu bezpieczeństwa 3
- 4. Standardy z rodziny SCAP (2) • IODEF (Incident Object Description Exchange Format) – opisywanie incydentów bezpieczeństwa • CVSS (CommonVulnerability Scoring System) - zasady punktowej oceny ważności zagrożeń wynikających z podatności sprzętu i oprogramowania • CVE (CommonVulnerabilities and Exposures) - słownik identyfikatorów podatności związanych z wykorzystaniem konkretnych słabości oprogramowania • CPE (Common Platform Enumeration) – słownik oprogramowania, systemów, pakietów • CWE (Common Weaknesses Enumeration) – taksonomia podatności 4
- 5. Źródła danych SCAP • NVD (NationalVulnerability Database) – baza podatności – zawiera metadane i testy OVAL • NCP (National Checklist Program) – baza wymagań dla systemów używanych w administracji publicznej USA – Zestawy polityk bezpieczeństwa dla typowych konfiguracji (np. Windows 7 i MS Office) • Obydwa źródła dostępne nieodpłatnie, na otwartej licencji 5
- 6. OVAL – przykład metadanych <definition id="oval:org.mitre.oval:def:15422" version="1" class="vulnerability"> <metadata> <title>Vulnerability in the PDF functionality in Google Chrome before 19.0.1084.46 via an out-of-bounds write error in the implementation of sampled functions.</title> <affected family="windows"> <platform>Microsoft Windows 2000</platform> <platform>Microsoft Windows 7</platform> <platform>Microsoft Windows Server 2003</platform> <platform>Microsoft Windows Server 2008</platform> <platform>Microsoft Windows Server 2008 R2</platform> <platform>Microsoft Windows Vista</platform> <platform>Microsoft Windows XP</platform> <product>Google Chrome</product> </affected> <reference source="CVE" ref_id="CVE-2011-3097" ref_url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3097"/> <description>The PDF functionality in Google Chrome before 19.0.1084.46 allows remote attackers to cause a denial of service or possibly have unspecified other impact by leveraging an out-of-bounds write error in the implementation of sampled functions.</description> <oval_repository> <dates> <submitted date="2012-05-16T08:35:52.000-04:00"> <contributor organization="G2, Inc.">Shane Shaffer</contributor> </submitted> <status_change date="2012-05-16T12:22:38.177-04:00">DRAFT</status_change> </dates> <status>DRAFT</status> </oval_repository> </metadata> <criteria> <extend_definition comment="Google Chrome is installed" definition_ref="oval:org.mitre.oval:def:11914"/> <criterion comment="Check if the version of Google Chrome is less than 19.0.1084.46" test_ref="oval:org.mitre.oval:tst:79966"/> </criteria> </definition> 6
- 7. OVAL – przykład testu (1) • Referencja na badany obiekt oraz oczekiwany stan obiektu <registry_test id="oval:org.mitre.oval:tst:79966" version="1" comment="Check if the version of Google Chrome is less than 19.0.1084.46" check_existence="at_least_one_exists" check="at least one" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows"> <object object_ref="oval:org.mitre.oval:obj:15888"/> <state state_ref="oval:org.mitre.oval:ste:19568"/> </registry_test> 7
- 8. OVAL – przykład testu (2) • Definicja obiektów <registry_object id="oval:org.mitre.oval:obj:15888" version="4" comment="The registry key holding the version of Google Chrome" xmlns="http://oval.mitre.org/XMLSchema/oval- definitions-5#windows"> <set xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5"> <object_reference>oval:org.mitre.oval:obj:15257</object_reference> <object_reference>oval:org.mitre.oval:obj:16406</object_reference> <filter action="include">oval:org.mitre.oval:ste:18296</filter> </set> </registry_object> <registry_object id="oval:org.mitre.oval:obj:16406" version="1" comment="The registry key holding the version of Google Chrome (admin install for all users)" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows"> <hive>HKEY_LOCAL_MACHINE</hive> <key>SOFTWAREMicrosoftWindowsCurrentVersionUninstallGoogle Chrome</key> <name>Version</name> </registry_object> 8
- 9. OVAL – przykład testu (3) • Definicja obiektu i zmiennej <registry_object id="oval:org.mitre.oval:obj:15257" version="3" comment="The registry key holding the version of Google Chrome (individual users install)" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows"> <hive>HKEY_USERS</hive> <key var_ref="oval:org.mitre.oval:var:1249"/> <name>Version</name> </registry_object> <local_variable id="oval:org.mitre.oval:var:1249" version="1" comment="Full key path of Google Chrome uninstall registry key under HKEY_USERS" datatype="string"> <concat> <object_component item_field="key" object_ref="oval:org.mitre.oval:obj:23331"/> <literal_component>SoftwareMicrosoftWindowsCurrentVersionUninstallGoogle Chrome</literal_component> </concat> </local_variable> 9
- 10. OVAL – przykład testu (4) • Definicja stanu oczekiwanego <registry_state id="oval:org.mitre.oval:ste:19568" version="1" comment="Version is less than 19.0.1084.46" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows"> <value datatype="version" operation="less than">19.0.1084.46</value> </registry_state> 10
- 11. Historia projektu BZURA (1) • Studium wykonalności realizowane w latach 2005-2007 • Realizacja projektu dofinansowana ze środków NCBiR (program bezpieczeństwo i obronność 1) – umowa z dnia 28 grudnia 2011 r. • Temat: System zarządzania bezpieczeństwem teleinformatycznym jednostek administracji publicznej oraz resortu obrony narodowej, wraz z narzędziami wspomagającymi zwalczanie cyberterroryzmu i ochronę teleinformatycznej infrastruktury krytycznej 11
- 12. Historia projektu BZURA (2) • Gestor: Ministerstwo Obrony Narodowej • Wykonawca: Atende S.A. (Atende Software sp. z o.o. jako podwykonawca) • Zakończenie realizacji projektu: marzec 2014 r. • Osiągnięto IX poziom gotowości technologii • Obecnie w trakcie opracowywania planu zagospodarowania produktu 12
- 13. Założenia funkcjonalne – SZBI SK (1) • Ewidencjonowanie systemów IT • Zarządzanie cyklem życia systemów IT (workflow) – projektowanie (wizualny edytor) – wdrażanie w eksploatację – eksploatacja (nadzór, obsługa incydentów) – wycofywanie z eksploatacji 13
- 14. Założenia funkcjonalne – SZBI SK (2) • Utrzymywanie bazy polityk bezpieczeństwa dla systemów i sieci • Zarządzanie bazą podatności i zagrożeń w oprogramowaniu • Zautomatyzowane testy na wystąpienie podatności lub niezgodności z polityką bezpieczeństwa 14
- 15. Założenia funkcjonalne – SZBI SK (3) • Akwizycja i korelacja logów (SYSLOG) • Zarządzanie przepływem pracy przy obsłudze incydentów komputerowych • Wymiana informacji o incydentach komputerowych z zespołamiCERT i platformą N6 (NASK) • Obsługa standardów z rodziny SCAP (Security Content Automation Protocol) 15
- 17. System Zarządzania Procesami Bezpieczeństwa (1) • Aplikacja stworzona w technologii Java EE • Autorski silnik procesów biznesowych (własna notacja, parser oparty o ANTLR) • Wielopoziomowa kontrola dostępu (kilkaset ról – systemowych i dziedzinowych) • Rozliczalność użytkownika • Integracja z Active Directory • Translacja danych SCAP na potrzeby AgentaTestów OVAL (wykorzystanie języka Lua) • Interfejs WWW (HTML5/AJAX) 17
- 18. System Zarządzania Procesami Bezpieczeństwa (2) 18
- 19. Edytor bezpieczeństwa (1) • Aplikacja stworzona w technologii .NET • Interfejs użytkownika wzorowany naVisio • Wybór elementów z Bazy Rozwiązań Certyfikowanych • Możliwość przypisywania własnych atrybutów do elementów (np. adres IP, adres MAC) • Walidacja atrybutów na podstawie reguł pobieranych z SZPB • Wykrywanie typowych błędów (np. połączenie kontenerów o różnej klauzuli) 19
- 21. Agent testów OVAL • Usługa dla systemów operacyjnych z rodzinyWindows i Linux • Stworzony w C++, wykorzystuje interpreter języka Lua • KomunikacjaTLS z SZPB • Akwizycja danych o systemie (np. lista procesów, pakietów, interfejsów sieciowych) • Testy bezpieczeństwa - API Lua symetryczne z OVAL i XCCDF 21
- 22. Wnioski • Ze środków publicznych opracowane zostało oprogramowanie, które odpowiada potrzebom określonym w założeniach do strategii cyberbezpieczeństwa RP • SZBI adresuje potrzeby jednostek administracji publicznej i operatorów systemów krytycznych w zakresie koordynacji działań i wymiany informacji • Wdrożenie SZBI w dowolnym podmiocie wymaga jedynie dostosowania przebiegu procesów biznesowych i opracowania polityk bezpieczeństwa 22
- 23. Dziękuję za uwagę i zapraszam do zadawania pytań.