MUZIKANT, P. Využití databází při analýze malwaru reprezentovaného grafem chování [online]. Brno: Vysoké učení technické v Brně. Fakulta elektrotechniky a komunikačních technologií. 2020.
Práce studenta Petra Muzikanta je rozsáhlejšího charakteru a pohybuje se u horní hranice počtu normostran. Toto je dáno převážně rozsáhlostí zadaného tématu, které sestávalo jak z instalace a měření kandidátních databázových řešení, implementace nástroje pro zpracování a import dat do vybraného DB řešení a návrh jednoduchého filtru pro výběr podgrafů, které budou v DB uloženy, tak i výkonnostní optimalizace nástroje. Všechny tyto dílčí kroky student v práci detailně popisuje a vysvětluje včetně analýzy a řešení problémů, se kterými se v průběhu implementace setkal. Velice pozitivně hodnotím prezentační úroveň a formální úpravu technické zprávy. Všechna naměřená data jsou prezentována jak formou tabulky hodnot, tak pomocí přehledných grafů. Oceňuji taktéž použití vývojového diagramu / obrázků při popisu složitějších algoritmů. Kladně hodnotím i práci s literaturou, kterou musel student ve značném množství nastudovat a kterou korektně cituje v textu technické zprávy. Výstupy práce shledávám jako velice přínosné, na jejichž základech se bude dále budovat a rozvíjet systém automatického zpracování a ukládání grafových dat pro potřeby detekce škodlivého software. Student během semestru vykazoval aktivní přístup k řešení práce, pravidelně navštěvoval kanceláře firmy a konzultoval technické otázky jak s vedoucími, tak i s vývojáři jednotlivých DB řešení pomocí online komunikačních kanálů.
Cílem práce bylo vyvinout software pro vyhledávání podgrafů v datech, jejich klasifikace pomocí interních systémů firmy Avast a jejich následný import do zvoleného databázového systému. Práce je psaná česky poměrně srozumitelnou formou, z typografického hlediska je práce lehce nad standardem FEKT VUT. Vytkl bych zde předložky na koncích řádků (např. Str. 21 – „a“), jiný font textových popisků v obrázcích než v textu (např. Obr. 6.1.), a ne zcela přehledné výpisy zdrojových kódů (doporučil bych zde např. LaTeX balíček „minted“). V prvních čtyřech kapitolách student představuje řešený problém a úvádí čtenáře do teoretických základů nezbytných k řešení problému. V rámci této teoretické rešerše bych vytkl určité nepřesnosti či nepodložené informace: - V Kapitole 2. je napsáno, že bude popsána základní struktura a indexace dvou nejrozšířenějších modelů databázových systémů. Trošku zde uniká, o které dva modely vlastně má jít? Jsou tím myšlenky relační a grafové databáze? Pokud ano, jak si může čtenář být jistý, že zrovna grafové databáze patří k nejrozšířenějším NoSQL databázím? Opravdu jsou rozšířenější než například NoSQL databáze klíč-hodnota, které se často používají pro cachování? - V Sekci 2.1. je napsáno, že společnost Oracle přišla na trh s první komerční databází v roce 1970, což samozřejmě není pravda, protože v roce 1970 teprve vyšel první článek s návrhem relačního modelu. Společnost Oracle představila trhu svůj databázový systém v roce 1979. - V sekci 2.1.1 – je napsáno o primárním klíči, že má pro sebe vyhrazený pouze jeden sloupce v tabulce, to samozřejmě není vždy pravda, protože existuje také složený primární klíč (composed primary key), který je složen z více sloupců tabulky - V sekci 2.1.3. je napsáno, že B+ stromy představují jakýsi extrém rozdělení na podskupiny, zde je slovo extrém poměrně zavádějící, vzhledem k tomu, že B+ stromy jsou velmi častou implementací indexů. Vzhledem k tomu, že databázové indexy jsou podstatnou součástí návrhu databázového schématu, včetně rozmyšlení typů indexů pro různé databázové záznamy, mi zde chybí detailnější rozbor volby databázových indexů (B+ stromy, hash, ...) pro různé typy dotazování. - V sekci 2.2.1 mi chybí zmínka o dalším často využívaném systému v NoSQL databázích, čímž je BASE. Rovněž bych si zde představoval detailnější rozbor důsledků, které tyto principy přinášejí. - Kapitola 3 obsahuje informace, které pokládám za firemní „know-how“ a předpokládám tedy jejich význam v rámci interní integrace poskytnutého řešení. Mate mě zde pouze v sekci 3.3.2 Executable uzel, který obsahuje atribut RegistryContext, který značí změny v registrech Windows, který daný uzel provedl. Nicméně mi zde uniká zda je tato struktura poté použitelná i pro jiné operační systémy? Nebo jde o systém čistě pro operační systém Windows. - V kapitole 4 chybí citace na představená tvrzení. Například tvrzení, že vícevláknové aplikace jsou méně náročné na RAM, protože „sdílí prostředky“ je dosti zavádějící a troufám si říct, že v mnoha případech nepravdivé. Následující kapitoly práce již pojednávají o praktickém výstupu studenta, je zde představeno testovací prostředí, konkrétní databázové instance, na kterých byly provedeny simulace a také diskuze na výsledky, kterých bylo dosaženo. Zde se mi zdá kapitola 5 poměrně dobře zpracovaná, pouze bych zde uvedl parametry prostředí, v kterém se prováděla měření do přehledné tabulky, aby nezanikala v textu, vzhledem k jejich významnosti na prezentované výsledky. V kapitole 6 si lze všimnou drobných překlepů jako (sekce 6.1.2 „Microsfot”). V sekci 6.5 je dále specifikováno, že softwarové řešení má být schopno zpracovat 200 000 XML souborů za 1 den, nicméně jsem se v textu nedopatrál informace, jak velké tyto soubory jsou, což degraduje přínos této informace. Při měřeních v sekci 6.5.2 chybí odůvodnění proč se měření provádělo právě 12krát, proč ne víckrát? Trošku podezřele na mě působí informace ohledně porovnání switch a if-else, kde vychází if-else výkoněji, což v obecných poučeních v C# ani v jiných jazycích (jako je například Java) nebývá obvykle pravda vzhledem ke kompilaci, v některých případech, switch výrazů do „jump tables“. Další kapitolu 7 velmi oceňuji a je to velmi dobrý zdroj informací pro členy týmu navazující na tuto práci. V samotné implementaci bych vytkl nadužívání proměnných „static“, které bych vhodně nahradil pomocí „dependency injection“ (kupříkladu třída RestClient a další). Dále bych nahradil při čtení souborů klasický try-catch block pomocí „using“ (případně doplnil Finally blok a v žádném případě nevracel z metod null, kupříkladu třída „XmlFilesHelper“). Kódu by dále prospěla robustnější dokumentace a oprava dalších chyb, které jistě budou v produkční verzi kódu opraveny. Otázky k obhajobě: - Ve Vaší práci řešíte poměrně podrobně optimalizaci a výkonnost aplikace, nicméně Vaše vybraná grafová databáze Neo4J je interně implementována v Javě a poskytuje nativní Java API pro operace nad touto databází. Přinesla by náhrada Vašeho řešení v jazyce C# za řešení v jazyce Java nějaké výkonnostní benefity pro Vaši aplikaci? - Jak bude vypadat proces nasazení Vašeho řešení do stávající softwarové architektury firmy Avast? Celkově se domnívám, že odevzdaná práce splňuje zadání a její úroveň zpracování odpovídá nárokům kladeným na velmi kvalitní závěrečnou práci. Domnívám se, že rozsahem a náročností práce by mohlo jít i o poměrně kvalitní diplomovou práci. S ohledem na výše uvedené skutečnosti doporučuji práci k obhajobě s hodnocením A (95 bodů).
eVSKP id 125904