Základom bezpečnej aplikácie je dobrá analýza - Bart Digital Products Základom bezpečnej aplikácie je dobrá analýza - Bart Digital Products

Základom bezpečnej aplikácie je dobrá analýza

Nápad či požiadavky zákazníka na appku máš na papieri. Vieš zhruba, čo má robiť, ako má vyzerať a vybral si si aj technológie. Teraz je na rade analýza. Čím začať, ako postupovať a na čo myslieť? Okrem iného aj na zraniteľnosti a hrozby. Ak si takúto analýzu urobíš hneď na začiatku, počas programovania môžeš priebežne ošetrovať všetko, čo treba, a na konci ťa neprekvapí žiadna nezabezpečená diera.

Základom bezpečnej aplikácie je dobrá analýza - Bart Digital Products
Analysis, photo via Unsplash

Proces identifikácie možných problémov a určenie si bezpečnostných priorít projektu sa nazýva modelovanie hrozieb. Existuje množstvo možných prístupov, ako sa na nieto potenciálne diery v projekte pozerať a každá z nich má svoje výhody i nevýhody. Spája ich však cieľ – zabezpečiť, aby bol tvoj projekt chránený. Ako to vyzerá v praxi?

Hrozby modeluješ aj cestou do obchodu

Ľudia používajú modelovanie hrozieb vo svojom každodennom živote bez toho, aby si to uvedomili. Určite aj ty cestou do práce či školy zvažuješ, čo sa môže po ceste zvrtnúť a ako sa tomu vyhnúť. Ak ideš bicyklom, hoc aj mimo mesta, dáš si prilbu, lebo veď vieme, akí sú naši vodiči. Ak cestuješ autom v špičke, snažíš sa nájsť trasu, kde nie je zápcha a teda tu nehrozí veľké zdržanie ani ťukes s iným autom v rade za tebou. Vo svojej podstate je teda modelovanie hrozieb identifikáciou a klasifikáciou hrozieb, ktoré pravdepodobne ovyplyvnia naše prostredie.

Tieto modelovania sú obzvlášť užitočné pre kyberfyzikálne systémy vrátane internetu vecí (Internet of Things – IoT). Takéto systémy integrujú softvérové technológie do fyzických infraštruktúr (napríklad inteligentné autá) a sú často zraniteľnejšie voči hrozbám, ako tradičná fyzická infraštruktúra (auto s minimom elektroniky asi nikto hackovať nebude :). Modelovanie hrozieb teda môže pomôcť identifikovať hrozby ešte v procese vývoja a v konečnom dôsledku ušetriť manažmentu balík peňazí.

Zdroj: https://www.softwaretestingnews.co.uk/threat-modelling-for-connected-cars/

Historické okienko

Prvé metodológie modelovania hrozieb sa objavili už v roku 1977 a boli založené na koncepte architektonických vzorov, ktoré predstavil Christopher Alexander vo svojej knihe “A Pattern Language”. Za otca modelovania hrozieb však môžeme považovať Edwarda Amorosa, ktorý popísal koncept “stromu hrozieb” vo svojej knihe „Fundamentals of Computer Security Technology“ z roku 1994. Na jej základoch postavil v 1998 Bruce Schneier štúdiu “Toward a Secure System Engineering Methodology”. Stromová metodológia, dokonca s rovnakým názvom, ako jej dal Amoros, je používaná dodnes.

Historicky druhú metodológiu vyvinuli v roku 1999 odborníci na kybernetickú bezpečnosť z Microsoftu Loren Kohnfelder a Praerit Garg. Išlo o model špecifický pre vývojové prostredie Microsoft Windows s názvom STRIDE. Opäť ide o metodológiu, ktorá je stále využívaná a teší sa všeobecnej popularite. V rovnakom roku zaviedol Inštitút softvérového inžinierstva na Carnegie Mellon University metódu na vyhodnotenie prevádzkovo kritických hrozieb, aktív a zraniteľností – OCTAVE6.

Prvú kniha s názvom Modelovanie hrozieb vydali v roku 2004 Frank Swiderski a Window Snyder. Tá rozvinula myšlienku využitia modelovania hrozieb na proaktívne písanie bezpečných aplikácií. V tom istom roku spoločnosť Microsoft predstavila dodnes používaný nástroj Threat Analysis & Modeling (TAM), ktorý využíva diagramy toku údajov (Data-flow diagram – DFD) a stromy hrozieb v štýle Schneierovej štúdie. Tie pomáhajú vývojovým tímom premýšľať nad potenciálnymi útokmi a zodpovedajúcimi bezpečnostnými opatreniami, ktoré sa majú proaktívne implementovať.

Analysis, photo via Unsplash

4 základné kroky

Výber konkrétneho modelu hrozieb závisí od cieľov a prostredia tvojej aplikácie. Modelovanie ako také však zvyčajne zahŕňa stále rovnaké kroky:

  1. Identifikuj všetky zraniteľné miesta svojho projektu. Máš tam textový vstup pre používateľa? To je zraniteľnosť. Prihlasovanie? Takisto áno.
  2. Na základe zraniteľností vytvor zoznam hrozieb. Textový vstup od používateľa predstavuje riziko nasadenia cudzieho kódu do štruktúry appky, prihlasovanie zase hrozbu ukradnutia identity. Ak si to chceš trochu uľahčiť, odporúčame zoznamy hrozieb od OWASP.
  3. Pre každú hrozbu si načrtni kroky, ako jej zabrániť. Stačia ti body – implementovať recaptchu, same-origin policy, content security policy…
  4. Urči si priority. Ktoré zraniteľné miesto bude pravdepodobne najbombardovanejšie? Aký problém mi môže urobiť najväčšie škody? Takto budeš vedieť, že týmto hrozbám treba pri vývoji venovať extra pozornosť.

Konkrétne metodológie sú o čosi zložitejšie, niektoré sa sústreďujú na riziká, iné priradia hrozbám dokonca konkrétne čísla podľa ich kritickosti. Na tie najznámejšie a najstaršie, ako STRIDE alebo Stromy hrozieb, sa pozrieme v ďalšom blogu zo série Bezpečnosť na internete už o týždeň.

Zdroje:

  • https://reciprocity.com/blog/top-threat-modeling-methodologies/
  • https://threatmodeler.com/evolution-of-threat-modeling/
  • https://www.techtarget.com/searchstorage/definition/business-impact-analysis
  • https://threatmodeler.com/threat-modeling-methodologies-overview-for-your-business/
  • https://threatmodeler.com/threat-modeling-methodologies-vast/

Opatrnosti nie je nikdy dosť. Prečítaj si viac na tému bezpečnosť!