konferencja SCS 2016, https://www.securitycasestudy.pl/

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

16. Schemat logiczny
16

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

20. Edytor bezpieczeństwa (2)
20

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ń.