Bezpečnosť vo vývoji softvéru a DevSecOps

Informatec Digital » Zdroje » Bezpečnosť vo vývoji softvéru a DevSecOps

Zabezpečenie softvéru už nie je voliteľným doplnkom pridaným na konci projektu, ale kľúčovou súčasťou už od prvého náčrtu aplikácie. Vo svete, kde sa kód nasadzuje niekoľkokrát denne a kde sú kybernetické útoky čoraz sofistikovanejšie, je neustále spoliehanie sa na manuálne kontroly na poslednú chvíľu receptom na katastrofu.

Integrácia bezpečnosti počas celého životného cyklu vývoja (od počiatočného konceptu až po údržbu produkcie) je základom prístupov, ako sú DevSecOps, bezpečnosť zameraná na vývojárov a bezpečné modely SDLC z rámcov ako OWASP SAMM alebo NIST SSDF. Cieľ je jednoducho formulovateľný, ale zložitý na dosiahnutie: vytvoriť bezpečný softvér už od návrhu bez toho, aby sa obmedzila obchodná agilita a zabránilo sa tomu, aby sa bezpečnosť stala úzkym hrdlom.

Čo je bezpečnosť pri vývoji softvéru a prečo je dôležitá?

Keď hovoríme o bezpečnosti vývoja softvéru, máme na mysli všetky postupy, nástroje a procesy používané na zabezpečenie odolnosti aplikácie voči útokom, zachovania integrity údajov a dostupnosti služieb počas celého jej životného cyklu. Nejde len o „inštaláciu firewallu“ alebo používanie šifrovania, ale o navrhovanie a programovanie softvéru spôsobom, ktorý znižuje pravdepodobnosť bezpečnostných zraniteľností.

Útoky škodlivého softvéru a zraniteľnosti softvéru môžu ohroziť autentifikáciu, autorizáciu, integritu a dôvernosť. Ak sa tieto hrozby riešia počas fázy návrhu, mnohé z nich je možné zmierniť skôr, ako sa stanú problémom v produkcii, čím sa zabráni núdzovým záplatám a únikom údajov.

Ústrednou myšlienkou je, že každý softvér by mal prejsť bezpečnostným testovaním predtým, ako sa dostane k používateľovi, a že tieto testy by nemali byť izolovaným „filtrom“, ale skôr rutinnou súčasťou každej verzie. Výsledkom je odolnejší softvér, ktorý nemusí hromadiť vrstvu za vrstvou dodatočného zabezpečenia, keď sa objavia zraniteľnosti.

Konečným cieľom je dosiahnuť aplikácie zabezpečené už od návrhu , s kontrolnými mechanizmami zabudovanými do ich architektúry, častým automatizovaným testovaním a kultúrou, v ktorej vývojári, bezpečnostné oddelenie a prevádzka spolupracujú. To si vyžaduje vedomé úsilie celého technického tímu, nielen malej skupiny špecialistov na kybernetickú bezpečnosť.

DevSecOps a zabezpečenie zamerané na vývojárov

Termín DevSecOps sa objavil na riešenie veľmi špecifického problému: tradičné modely, v ktorých sa bezpečnostný tím pripájal až na konci vývojového cyklu, už nezodpovedali častým vydávaniam, agilným metodikám a CI/CD pipeline. Predtým aktualizácia aplikácie raz alebo dvakrát ročne umožňovala dôkladnú kontrolu; teraz, s kontinuálnym nasadzovaním, sa tento prístup stal neprijateľnou prekážkou.

DevSecOps podporuje bezproblémovú integráciu bezpečnosti do agilných metód a DevOps , takže bezpečnosť aplikácií a infraštruktúry je riešená od začiatku a priebežne. Cieľom je odhaliť a opraviť zraniteľnosti hneď, ako sa objavia, keď je ich náprava ešte lacná, a nie ich objaviť krátko pred nasadením.

DevSecOps navyše propaguje bezpečnosť ako spoločnú zodpovednosť : vývoj, prevádzka a bezpečnosť úzko spolupracujú, a nie pracujú izolovane, ktoré komunikujú až na konci. Motto tohto prístupu sa často zhrňuje ako „softvér, bezpečnejší, rýchlejší“: dodávanie rýchlejšieho a bezpečnejšieho softvéru automatizáciou kontrol a znižovaním trenia v životnom cykle vývoja.

Kľúčovým pilierom tejto filozofie je bezpečnosť zameraná na vývojárov . Namiesto toho, aby bezpečnostný tím na konci procesu pôsobil ako „polícia“, sú bezpečnostné nástroje priblížené k vlastnému pracovnému prostrediu vývojárov, napríklad integráciou skenerov do IDE alebo systému správy verzií. Týmto spôsobom sa časť analýzy, testovania a opravy vykonávajú priamo z klávesnice vývojára.

Tento prístup „priblíženia bezpečnosti ku kódu“ umožňuje odhaliť a opraviť zraniteľnosti takmer hneď po ich napísaní, bez čakania na pravidelné audity alebo rozsiahle penetračné testovanie. Výsledkom je, že vývojové tímy prestávajú vnímať bezpečnosť ako nepríjemnosť, ktorá spomaľuje ich prácu, a namiesto toho ju prijímajú ako základné kritérium kvality.

Bezpečnosť je zabudovaná do každej fázy SDLC.

Aby bola bezpečnosť skutočne účinná, musí byť integrovaná do všetkých fáz životného cyklu vývoja (SDLC) a nesmie sa s ňou zaobchádzať ako s konečnou „kontrolou kvality“. Zaobchádzanie so bezpečnosťou iba ako s problémom pri ukončení projektu vytvára pre bezpečnostný tím úzke hrdlo, najmä preto, že nemôžu byť expertmi na všetky technológie a cloudové prostredia používané dnes.

Moderný prístup navrhuje bezpečnosť, ktorá je „pretkaná“ celým SDLC: od definovania požiadaviek, cez plánovanie a návrh, až po implementáciu, testovanie, nasadenie a údržbu. Celá organizácia si uvedomuje, že bezpečnosť je základnou súčasťou úspechu produktu , nie samostatným problémom, ktorý možno odložiť.

Predtým boli bezpečnostné kontroly primárne manuálne testovanie a izolované nástroje pre každú aplikáciu alebo službu, kombinujúce bodové skenery s penetračným testovaním. Dnes sú nástroje navrhnuté s ohľadom na integráciu a automatizáciu: pripájajú sa k kanálom CI/CD, systémom sledovania incidentov a úložiskám kódu, čo umožňuje oveľa plynulejší pracovný postup.

Skenery zraniteľností sú integrované do procesu nepretržitej integrácie, takže každá zmena kódu sa automaticky analyzuje pred prechodom do ďalšej fázy. Zároveň sa zistenia zaznamenávajú ako bežné úlohy, viditeľné pre celý tím, čo uľahčuje stanovovanie priorít, sledovanie a meranie časov riešenia.

To všetko znamená, že bezpečnosť už nie je dodatočnou myšlienkou, ale stáva sa štrukturálnou súčasťou SDLC . Namiesto jednoduchého „prejdenia bezpečnostnou kontrolou“ tesne pred nasadením organizácia predpokladá, že každý commit, každé zlúčenie a každé doručenie je súčasťou nepretržitého reťazca bezpečnostných kontrol.

Bežné postupy zabezpečenia softvéru

V rámci tohto spôsobu práce existuje množstvo iniciatív v oblasti softvérovej bezpečnosti , ktoré mnohé organizácie už implementujú alebo začínajú prijímať. Nie je to vyčerpávajúci zoznam, ale pomáha pochopiť, aké druhy aktivít by sme mali integrovať do SDLC na posilnenie bezpečnosti.

Kľúčovým prvým krokom je statická analýza kódu (SAST). Zahŕňa analýzu zdrojového kódu (vrátane infraštruktúry ako kódu) s cieľom odhaliť nebezpečné programovacie vzory alebo známe zraniteľnosti. Zvyčajne ide o automatizovaný proces, ktorý je možné spustiť pri každom commite alebo push, čím vývojárom poskytuje spätnú väzbu takmer v reálnom čase.

Na druhej strane, dynamická bezpečnostná analýza (DAST a podobné prístupy) hodnotí celú aplikáciu a jej základnú infraštruktúru počas jej behu. Patria sem napríklad skenovania portov, testy cross-site scriptingu, kontroly konfigurácie kontajnerov a analýza služieb pripojených na internet s cieľom identifikovať zraniteľnosti, ktoré sú viditeľné iba vtedy, keď je systém v prevádzke.

Popri automatizovaných nástrojoch zostávajú manuálne kontroly kódu nevyhnutné. Zatiaľ čo mnohé funkcie sú už kontrolované na logické chyby, začlenenie bezpečnostného hľadiska do týchto kontrol kódu umožňuje odhaliť menej zjavné zraniteľnosti, ktoré by skener mohol prehliadnuť. To si však vyžaduje, aby tím mal určité školenie v oblasti vzorcov útokov a osvedčených postupov.

Penetračné testovanie ide ešte o krok ďalej: najímajú sa experti, ktorí konajú ako útočníci a pokúšajú sa kompromitovať infraštruktúru alebo aplikácie. Môžu použiť čokoľvek od automatizovanej analýzy až po skutočné zneužitia a výsledkom je zvyčajne správa s podrobnosťami o zraniteľnostiach, ktoré štandardné testy prehliadli, s konkrétnymi odporúčaniami na ich zmiernenie.

Súvisiacim, ale odlišným prístupom sú programy Bug Bounty . Tento model vyzýva výskumníkov a pokročilých používateľov, aby nahlásili zraniteľnosti výmenou za finančnú odmenu alebo uznanie. Je to efektívny spôsob, ako sprostredkovať zistenia tretích strán a premeniť potenciálnych útočníkov na spolupracovníkov.

Napokon nesmieme zabúdať na bezpečnostné školenia pre technický personál . Situácia s hrozbami sa rýchlo mení: to, čo dávalo zmysel pred desiatimi rokmi, môže byť dnes zlým postupom. Informovanie vývojárov o aktuálnych informáciách o OWASP Top 10, nových útokoch a bezpečných návrhových vzoroch výrazne znižuje riziko ľudskej chyby, ktorá zostáva príčinou významnej časti narušení bezpečnosti.

Životný cyklus bezpečného vývoja softvéru (Secure SDLC)

Integrácia bezpečnosti do SDLC nespočíva v pridaní „ďalšej fázy“ na konci, ale skôr v prepojení postupov a kontrol do existujúcich fáz. Vytvára sa tak udržateľný proces, ktorý prináša skutočnú hodnotu bez narušenia dynamiky tímu. Bezpečný SDLC zvyčajne zahŕňa nasledujúce fázy:

Fáza požiadaviek jasne definuje problém, ktorý sa má vyriešiť, a potrebnú úroveň zabezpečenia. Toto je čas na transformáciu incidentov, požiadaviek na nové funkcie a známych zraniteľností do konkrétnych projektov a posúdenie ich vplyvu na celkové riziko. Zapojenie bezpečnostného tímu v tejto fáze pomáha efektívne stanoviť priority a pochopiť dôsledky každej zmeny.

Nasleduje fáza plánovania , v ktorej sa rozhoduje o tom, čo sa bude stavať a ako sa k tomu bude pristupovať. Je dôležité, aby sa do tejto fázy zapojila aj bezpečnosť, ktorá overí, či plánované riešenie nezavádza nové vektory útoku a či sú obchodné ciele v súlade s požiadavkami na ochranu údajov, dodržiavanie predpisov a odolnosť.

Fáza návrhu riešenia sa zameriava na architektúru: ktoré systémy interagujú, aké služby sa vytvárajú, ako spolu súvisia a aké toky údajov sa vytvárajú. Diagramy by sa mali skontrolovať s bezpečnostným tímom, aby sa identifikovali potenciálne zraniteľnosti v hraniciach dôveryhodnosti, vstupných bodoch, mechanizmoch autentifikácie, šifrovaní atď. Plynulá komunikácia v týchto raných fázach zabraňuje odhaleniu vážnych problémov, keď je už všetko naprogramované.

Nasleduje implementácia , moment preloženia návrhu do kódu. Tu sa stávajú kľúčovými postupy, ako je statická analýza pri každom commite, integrácia bezpečnostných pravidiel do CI pipeline a vykonávanie kontrol kódu so zameraním na bezpečnosť. Čím skôr sa chyba v kóde zistí, tým nižšie sú náklady na jej opravu.

Keď je kód hotový, prechádza do fázy testovania a implementácie . Okrem funkčných testov je vhodné zahrnúť aj komplexnejšie bezpečnostné analýzy: DAST skenovanie, manuálne bezpečnostné testovanie kritických funkcií a, ak to zdroje dovolia, penetračné testovanie zamerané na hlavné zmeny. Zistenia v tejto fáze by sa mali použiť na úpravu automatizovaných nástrojov, aby sa predišlo regresiám.

Po nasadení sa začína preventívna údržba . Aj keď je softvér vydaný do produkcie „bez známych zraniteľností“, prostredie a hrozby sa menia: objavujú sa nové CVE, zisťujú sa chyby závislostí, menia sa právne požiadavky atď. Fáza údržby zahŕňa monitorovanie nových zraniteľností, aktualizáciu komponentov, kontrolu bezpečnostných protokolov a reakciu na incidenty.

Celý proces je kruhový: každá nová objavená chyba, vylepšenie alebo zraniteľnosť sa vracia späť do fázy požiadaviek . Bezpečný SDLC je preto cyklus neustáleho zlepšovania, nie lineárna cesta. Toto zmýšľanie pomáha tímom zdokonaľovať svoje ovládacie prvky a nástroje s každou iteráciou, namiesto toho, aby si mysleli, že po nasadení je „všetko hotové“.

Referenčné rámce: OWASP SAMM a NIST SSDF

Pre organizácie, ktoré chcú ísť o krok ďalej, je veľmi užitočné spoliehať sa na zavedené modely zrelosti a rámce pre bezpečný vývoj . Dva z najrelevantnejších sú model OWASP SAMM a rámec NIST SSDF, ktoré ponúkajú praktické rady pre integráciu bezpečnosti do vývojových procesov.

Model zrelosti softvérového zabezpečenia (SAMM) spoločnosti OWASP je vývojom bývalého modelu CLASP od spoločnosti OWASP. Navrhuje súbor bezpečnostných postupov usporiadaných podľa domén (ako je riadenie, budovanie, overovanie a nasadenie) s rôznymi úrovňami zrelosti. Myšlienkou je, že každá organizácia prispôsobí tieto postupy svojmu vlastnému rizikovému profilu, a nie aby sa snažila uplatňovať rigidný zoznam kontrol.

Rámec pre vývoj bezpečného softvéru (SSDF) NIST načrtáva základné postupy bezpečného vývoja na základe odporúčaní viacerých expertných organizácií. Rozdeľuje bezpečný SDLC do štyroch hlavných častí: príprava organizácie, zabezpečenie softvéru, tvorba bezpečného softvéru a reakcia na zraniteľnosti. Každá časť obsahuje špecifické činnosti, ktoré je možné implementovať postupne.

„Príprava organizácie“ znamená pripraviť ľudí, procesy a technológie tak, aby bezpečný vývoj bol prierezovou praxou, a to na úrovni spoločnosti aj v rámci každého tímu. „Ochrana softvéru“ zahŕňa opatrenia na zabránenie neoprávnenej manipulácii s kódom, artefaktmi zostavovania a dodávateľským reťazcom.

Blok „tvorba bezpečného softvéru“ sa zameriava na minimalizáciu zraniteľností v každej verzii , integráciu statickej analýzy, kontroly závislostí, skenovania kontajnerov a podobných kontrol do každodennej prevádzky. Nakoniec, „reakcia na zraniteľnosti“ sa vzťahuje na identifikáciu prehliadnutých chýb, ich rýchlu opravu a úpravu procesu tak, aby sa zabránilo ich opakovaniu.

Školenie, modelovanie hrozieb a kultúra bezpečnosti

Aby toto všetko fungovalo, nestačí len nainštalovať nástroje; vyžaduje si to vybudovanie spoločnej bezpečnostnej kultúry v rámci tímu. To znamená, že vývojári musia pochopiť, že ochrana aplikácií je súčasťou ich práce a že bezpečnostné tímy musia byť integrované do každodennej prevádzky, nielen keď dôjde k incidentu.

Špecifické školenie je dobrým východiskovým bodom. Posilnenie vývojárov pri identifikácii zraniteľností a písaní bezpečnejšieho kódu drasticky znižuje výskyt základných chýb. Zdroje ako OWASP Top 10 pomáhajú identifikovať najčastejšie slabiny vo webových aplikáciách a pochopiť, ako útočníci uvažujú.

Ďalšou metódou s vysokým dopadom je modelovanie hrozieb . Zahŕňa analýzu aplikácie (alebo novej funkcie) z pohľadu útočníka: ktoré aktíva potrebujú ochranu, aké vstupy existujú, aké toky údajov sú kritické a aké zraniteľnosti by sa dali zneužiť. Na základe tejto analýzy sa navrhujú opatrenia na zmiernenie rizík a začleňujú sa do samotného technického návrhu.

Ak sa modelovanie hrozieb vykonáva počas fázy návrhu, ovplyvňuje architektúru od samého začiatku a zabraňuje nezabezpečeným riešeniam, ktoré by neskôr vyžadovali prepísanie. Na štruktúrovanie analýzy sa zvyčajne používajú diagramy toku údajov a známe vzory útokov, do ktorých sú zapojené vývojové aj bezpečnostné tímy.

Súčasne je dôležité povzbudzovať vývojové tímy, aby sa naučili myslieť ako útočník . To neznamená, že každý musí byť expertom na penetračné testovanie, ale skôr to znamená, že musia pochopiť, ako sa malé zraniteľnosti spájajú a vytvárajú väčší útok, ako sa kradnú prihlasovacie údaje alebo ako sa zneužívajú slabé cloudové konfigurácie.

Obmedzenia tradičného penetračného testovania

Tradičné penetračné testovanie zostáva cenným nástrojom, ale má obmedzenia pri použití v prostrediach s nepretržitým nasadením. Podľa definície penetračné testovanie poskytuje prehľad o bezpečnosti v konkrétnom časovom bode: hodnotí stav aplikácie a infraštruktúry v danom dni.

Hneď ako tím nasadí nové verzie alebo zmení konfigurácie, niektoré zistenia sa môžu stať zastaranými . Ak sú vydania časté, udržiavanie úplných penetračných testov po každej zmene sa stáva nepraktickým z hľadiska času a nákladov.

Okrem toho, keď sa penetračný test vykonáva vo veľmi pokročilých fázach životného cyklu vývoja, oprava zistených zraniteľností je zvyčajne nákladná a často si vyžaduje aplikáciu zložitých bezpečnostných aktualizácií . Niekedy to znamená úpravu kľúčových komponentov alebo prepísanie celých častí aplikácie, čo má vplyv na plánovanie, rozpočet a morálku tímu.

A v organizáciách s mnohými službami a aplikáciami je ťažké škálovať manuálne penetračné testovanie na celý katalóg. Existuje tendencia uprednostňovať iba najkritickejšie systémy, čím sa nechávajú medzery v iných oblastiach, ktoré môžu útočníci tiež zneužiť.

Nepretržité testovanie bezpečnosti potrubí CI/CD

Aby sa prispôsobili tomuto tempu zmien, objavujú sa modely ako nepretržité testovanie bezpečnosti v rámci CI/CD, ktoré kombinujú automatizované skenovania 24 hodín denne, 7 dní v týždni s cielenými, jednorazovými manuálnymi testami. Cieľom je prejsť od ad hoc auditov k neustálemu toku detekcie a nápravy zraniteľností.

Tento prístup kombinuje automatizované skenery, ktoré kontrolujú aplikácie, webové zdroje, API a exponované povrchy, so zásahom expertov na penetračné testovanie, ktorí skúmajú najzložitejšie zistenia a hľadajú logické zraniteľnosti, ktoré nástroje nedokážu samy odhaliť.

Hlavnou výhodou je, že tímy dostávajú rýchle a podrobné informácie o bezpečnostných problémoch, a to aj v prípade, že CI/CD kanál je veľmi rýchly. To skracuje časové okno odhalenia, pretože zraniteľnosti sú identifikované a opravené skôr, ako sa postihnutý kód dostane do produkcie (alebo v nej zostane dlhší čas).

Ďalšou výhodou je, že neustále testovanie uľahčuje prepojenie medzi správou zraniteľností a bezpečnosťou aplikácií . Časté správy s jasnými zoznamami zraniteľností a ich vývojom v priebehu času pomáhajú pri rozhodovaní o rizikách, stanovovaní priorít opráv a odôvodňovaní investícií do vylepšení zabezpečenia.

Niektoré služby dokonca ponúkajú bezplatné opätovné testovanie po použití opráv, čo vám umožňuje overiť, či riešenia skutočne fungujú a či neboli zavedené žiadne regresie. Toto všetko dokonale zapadá do étosu neustáleho zlepšovania v DevSecOps.

Typické komponenty a nástroje DevSecOps

V praxi sa prostredie DevSecOps spolieha na niekoľko kľúčových technologických komponentov . Kontinuálna integrácia (CI) zjednocuje prácu všetkých vývojárov a automaticky spúšťa jednotkové, integračné a bezpečnostné testy pri každej integrácii nového kódu.

Kontinuálne dodávanie (CD) zabezpečuje, že softvér je vždy pripravený na nasadenie postupným overovaním a schvaľovaním softvéru (vrátane bezpečnostných kontrol) v každej fáze. Do prostredí vyššej úrovne sa povýšia iba verzie, ktoré prechádzajú všetkými definovanými kontrolami.

Automatizácia zabezpečenia sa dosahuje pomocou nástrojov SAST a DAST, skenerov závislostí, analýzy infraštruktúry ako kódu a kontroly kontajnerov. Tieto nástroje sú integrované do kanála CI/CD v systémoch ako Jenkins, GitLab CI alebo podobných, takže bežia bez manuálneho zásahu.

Riešenia na správu zraniteľností sa tiež bežne používajú na centralizáciu zistení, stanovenie priorít rizík a sledovanie ich riešenia. Popri tom nástroje na správu tajomstiev (ako napríklad Vault) zabraňujú zverejneniu prihlasovacích údajov a kľúčov v kóde alebo konfiguráciách nasadenia.

Nakoniec, nepretržité monitorovanie a audit sa spoliehajú na platformy pozorovateľnosti a SIEM (ako napríklad ELK alebo Splunk), ktoré zhromažďujú protokoly, detekujú anomálne správanie a uľahčujú audity súladu s predpismi. Táto vrstva uzatvára slučku a umožňuje detekciu produkčných incidentov a včasnú reakciu.

Aplikácia DevSecOps na vývoj mobilných aplikácií

Keď hovoríme o mobilných aplikáciách , prístup DevSecOps musí byť prispôsobený ich špecifickým charakteristikám. Fáza plánovania a návrhu musí zohľadniť špecifické riziká: správu povolení zariadení, bezpečné ukladanie poverení, šifrovanie komunikácie a súlad s nariadeniami, ako je GDPR.

Počas vývoja sa používajú SAST skenery prispôsobené jazykom ako Kotlin, Swift a Java a externé závislosti a SDK sa starostlivo kontrolujú. Mnohé zraniteľnosti v mobilných aplikáciách vznikajú práve zo zle udržiavaných knižníc tretích strán alebo z tých s nadmernými oprávneniami.

Vo fáze testovania sa skenovanie DAST kombinuje s testami špecifickými pre mobilné zariadenia : simuláciou útoku typu „man-in-the-middle“ (MITM), overením integrity binárnych súborov, analýzou lokálneho úložiska a kontrolou interakcie s rozhraním API na strane servera. To pomáha identifikovať chyby v aplikácii aj v službách, ktoré využíva.

Integrácia do CI/CD pipeline znamená, že každý commit prechádza automatickými bezpečnostnými kontrolami , čím sa zabezpečí, že sa do obchodov s aplikáciami nedostane žiadna verzia so závažnými chybami. Okrem toho je monitorovací systém po nasadení nakonfigurovaný tak, aby detekoval nezvyčajné správanie, nárasty chýb alebo vzory, ktoré by mohli naznačovať útok.

Nakoniec je definovaný jasný proces reakcie na incidenty , ktorý umožňuje rýchle vydanie urgentných záplat, ak sa v produkčnom prostredí objaví kritická zraniteľnosť. Schopnosť rýchlo reagovať a aktualizovať aplikáciu je kľúčom k udržaniu dôvery používateľov.

Všetky tieto postupy, rámce a nástroje spolu umožňujú, aby bezpečnosť prestala byť prekážkou a stala sa spojencom agilného vývoja. Zapojením vývojárov od samého začiatku, automatizáciou testovania pri každej zmene a využitím štandardov, ako sú OWASP SAMM alebo NIST SSDF, môžu organizácie vytvárať robustnejší softvér, znižovať náklady na opravy chýb a byť oveľa lepšie pripravené na neustále sa meniacu situáciu s hrozbami.