Vývoj softwaru z hlediska bezpečnosti

Bezpečnost softwaru je termín, který všichni považujeme, ať už více, či méně, za protimluv. Selhání softwaru, kte...


Bezpečnost softwaru je termín, který všichni považujeme, ať už více, či méně,
za protimluv. Selhání softwaru, který každodenně používáme, jsou na denním
pořádku a jsou jednou z věcí, na niž už řada z nás sama rezignovala.


Faktem ale je, že kdyby byl software kancelářská budova, vypadala by navenek
honosně, ale uvnitř by výtahy mívaly pravidelně poruchy. Zloději by měli volný
přístup přes otevřenou ventilaci na úrovni ulice. Nájemníci by potřebovali
konzultanty, aby se byli schopní vůbec nastěhovat. Zjistili by, že dveře se
odemykají, kdykoliv si někdo uvaří hrnek kávy. Stavitelé by vám poskytli
opravářskou soupravu a slíbili, že podobné výstřednosti, jako výše uvedené, se
už nebudou vyskytovat u dalšího mrakodrapu, který postaví (a do nějž se pak
mimochodem nájemníci budou nuceni přestěhovat).
Kupodivu by se nájemníci s tím vším smířili. Tolerovali by rostoucí náklady i
zvláštně utěšující rytmus poruch a oprav, který by začal ovládat jejich životy.
Kdyby se někdo zeptal: "Proč jsme se vlastně spokojili s touhle budovou?",
všichni by krčili rameny, lomili rukama a těžce vzdychali. "Tak to prostě je. V
podstatě jdou totiž kancelářské budovy každému na nervy."
Právě absurdita této představy je hlavní pointou. "V dřívějších letech byli
klienti poněkud uvolněnější při výběru dodavatelů a byli naklonění rozhodnout
se pro ta levnější řešení. To na druhou stranu znamenalo, že na trhu rovněž
působilo více výrobců, kteří méně utráceli za seriózní R&D (výzkum a vývoj) a
více dávali na marketing. Takto byl software vyráběn a vypouštěn na trh dokonce
ještě před tím, než byl zcela dokončen," popisuje Abdul Karim Riyaz, technolog
ve společnosti CA.
Na tomto tvrzení je kus pravdy. Software vznikal během doby, kdy šlo pouze o
dvě věci: funkce a časové lhůty. Šlo o to zařídit, aby software uměl něco navíc
a aby to dělal rychleji. Nikdo nevyráběl bezpečný software a nikdo jej ani
nepožadoval. Avšak síťové prostředí a schopnost nabourat se vzdáleně do systémů
jiných lidí tento stav výrazně změnily. A jestliže jsou převažující signály
něčím, o co se dá opřít, postoje k bezpečnosti softwaru se mění k lepšímu s
tím, jak výrobci, tlačeni několika faktory, začínají věnovat pozornost tomu, co
v podobě svých produktů nabízejí trhu.

Měnící se scénář
Riyaz roky 1999-2000 nazývá jako "předělová léta na poli bezpečnosti, kdy se
svět probudil do nebezpečí informační bezpečnosti a viry se z málo známých
staly velmi aktivními". Komplexní množina faktorů se propojila, aby dohromady
vytvořila kulturní posun od poraženecké tolerance ve smyslu "tak to prostě je"
směrem k nové éře.
Klíčovým aspektem mezi nimi je vzrůstající povědomí zákazníků o aplikační
bezpečnosti a tím i rostoucí požadavky na lepší produkty. Dalším důležitým
faktorem je potřeba udržovat si reputaci na celosvětově rostoucím trhu.
"Pro výrobce softwaru představuje nezabezpečený kód především drahý kód. Je
drahý nejen co do nákladů, které organizaci vyplývají z přípravy oprav a ze
ztracených příležitostí, ale má také dopad také na těžce vydobytou reputaci.
Získat nálepku ,nezlomný nebo ,bezpečný pro nás znamená provést mnoho
nákladných bezpečnostních testování avšak stačilo by jen několik chyb, abychom
se stali terčem posměchu," říká Mohamed Al Ojaimi, hlavní produktový manažer v
divizi Server Technologies společnosti Oracle.
Bezpečnost aplikací se pod vlivem těchto okolností postupně mění k lepšímu, a
to zcela fundamentálním a hlubokým způsobem. Během posledních několika let si
výrobci začali velmi důrazně uvědomovat potřebu bezpečnosti softwaru nebo
bezpečnosti, která je součástí samotné tvorby aplikací, a začali sami u sebe
implementovat procesy, díky nimž by měli být schopni zajistit totéž.

Vestavěná bezpečnost
"Jestliže korporace chtějí být důkladně chráněny před útoky, musí být
bezpečnost začleněná přímo do aplikací už během jejich vývoje. Svůj dům byste
také nezabezpečili jen tím, že se budete soustřeďovat na zamykání dveří a
přitom budete nechávat otevřená okna. To je přitom přesně to, co lidé dělají ve
své firemní infrastruktuře tím, že se soustřeďují na zabezpečení sítě, zatímco
zanedbávají aplikace, které se v ní nacházejí," říká Sarah Saltzmanová,
technologická manažerka pro kvalitu aplikačního softwaru ve společnosti
Compuware.
"Když navrhujete software, bezpečnost do něj musí být zahrnuta už na úrovni
architektury. Tak lze redukovat potřebu pozdějších oprav, neboť se tím redukují
zranitelnosti softwaru," vysvětluje Detlef Eckert, ředitel pro oblast EMEA ve
společnosti Microsoft.
Softwarový gigant, jehož operační systém okupuje 95 % světa osobních počítačů,
implementoval procesy pro řízení životního cyklu svých vlastních produktů pod
označením Security Development Lifecycle už v letech 2002-2003. Přitom není
sám. Většina velkých společností včetně takových firem, jako je například
Oracle, IBM či CA, má zavedeny detailní procesy řízení životního cyklu
produktů, s jejichž pomocí monitorují softwarový proces v nepřetržité snaze o
zlepšování produktů, které vycházejí z jejich stájí.
Aby monitorovala a hodnotila svoji práci při vývoji softwaru, většina firem se
drží procesů stanovených modelem Capability Maturity Model (CMM). V jejich
rámci si nicméně každá společnost podle svých vlastních potřeb stanovuje, co by
mělo a co by nemělo být během celého procesu softwarového vývoje prováděno.
Avšak zatímco spletitosti životního cyklu vývoje se od firmy k firmě liší,
základní fáze zůstávají stejné ať už jste výrobce nebo společnost, která si
svůj vlastní software vyvíjí vnitropodnikově a jde o následující:
1. Stanovení požadavků
2. Analýza a modelování hrozeb
3. Design a architektura
4. Pravidelné monitorování a testování během fáze vývoje
5. Konečné testování a zajištění kvality
"Držíme se procesů CMM pro nastavení požadavků. Konkrétní klient je vždy
mnohokrát navštíven obchodníky doprovázenými technickým týmem s cílem, aby se
obě skupiny daly dohromady. Tyto návštěvy a diskuse jsou využívány především
pro to, abychom navrhli podrobné dokumenty, a teprve poté je podepsána
příslušná dohoda. To všechno je navíc monitorováno jak naší skupinou pro
zajištění kvality, tak skupinou zabývající se měřením, což dává ustanoveným
požadavkům další dimenzi," říká Mona Arishiová, manažerka procesů pro zajištění
kvality softwaru v jednom z vývojových center společnosti IBM.
Stanovení požadavků je první fází vývojového životního cyklu, přičemž způsob,
jakým je firma vytváří, může nakonec výrazně ovlivnit, zda bude mít projekt
úspěch, nebo zda selže. Ačkoliv je důležité stanovit požadavky na co
nejdetailnější úroveň, stejně důležité je nechat trošku prostoru pro změnu.
"Teoreticky jsou požadavky nedotknutelné. Avšak realita je taková, že nic není
předem jasně dáno. Klienti se kvůli změnám někdy k vývojářům vracejí, a ty
proto musejí být dovoleny (stejně jako následně kontrolovány). Většina
požadavků na změny je vyhodnocena produktovou laboratoří, dodatečné úsilí je
zaznamenáno do tabulek a s klientem je před tím, než jsou inovované požadavky
realizovány, podepsána dodatečná dohoda," říká Ahmed Tantawy z centra
technologického vývoje ve společnosti IBM. Jakmile jsou požadavky vytvořeny,
následujícím krokem je pochopit, jakým druhům hrozeb bude aplikace nucená čelit.

Modelování hrozeb
"Naše modelování hrozeb je vysoce rozvinutý proces, který se pokouší
identifikovat a ohodnotit hrozby, které se nejpravděpodobněji dotknou systému,
pomocí modelu STRIDE (Spoofing, Tampering, Repudiation, Information disclosure,
Denial of services and Elevation of privileges, tedy spoofing, falšování,
odmítnutí práv, odkrytí informací, odmítnutí služeb a navýšení práv). Kategorie
STRIDE nám pomáhají podívat se na architekturu očima útočníka," říká Eckert ze
společnosti Microsoft.
Proces modelování hrozeb Microsoftu je realizován prostřednictvím několika
fází, a to včetně celkového pohledu na architekturu, dekompozice aplikace,
identifikace hrozeb, dokumentace či hodnocení, a zahrnuje každého od klienta až
po hlavního designéra, architekta, bezpečnostní vedení nebo projektový
management. Jedině po tomto přísném procesu přejde výrobce ke skutečnému
bezpečnému vývoji.
Některé firmy, jako například CA, berou klienta na zřetel dokonce i během fáze
návrhu. Podle Riyaze jeho společnost ve skutečnosti během této fáze zapojuje i
radu Product Advisory Council, která se skládá z expertů z vnějšku, aby tak
získal relativně nezávislý názor na celou problematiku. Vstupy této rady jsou
přijaty a jsou řízeny po celou dobu vývoje příslušným projektovým manažerem.
Ale ani to nestačí. Jakmile je vše, co je výše popsáno, vykonáno a projekt se
posune do fáze skutečného psaní kódu, je nezbytné, aby byl během fáze vývoje
pravidelně prováděn monitoring a testování.
"Když vývojáři píší kód, je nezbytné, aby existovaly body synchronizace mezi
týmem a skupinou pro zajištění jakosti, aby se všechni zúčastnění udrželi na
stejné vlně. Proto jsou úrovně kódu monitorovány a hodnoceny v pravidelných
intervalech v průběhu celého životního cyklu, což zaručuje vyšší bezpečnost při
dodání produktu," říká Tantawy.
Vlastní procesy pro řízení životního cyklu produktů společnosti CA, označované
jako Project 360, kladou velký důraz na interní testování a rovněž na to, aby
softwarové aplikace prošly přes její vlastní "zátěžové laboratoře". Bez ohledu
na to CA ve finální fázi ujišťování provádí betatesty svého softwaru mezi
vybranými klienty, shromažďuje zpětnou vazbu od zákazníků a také změny, pokud
jsou nějaké nutné, implementuje ještě před vypuštěním produktu na trh.
V tomto směru není sama. Oracle je další firmou, která klade důraz na testování
třetími stranami a betatestování u zákazníků před tím, než uvolní jakékoliv
nové verze na trh. Takové iniciativy zajišťují nezaujaté posouzení softwaru a
umožňují jeho lepší vyhodnocení a minimalizaci možnosti, že bude něco nakonec
opomenuto.

Vnitrofiremní vývoj
Pokud jste si mysleli, že jsou tyto procesy aplikovatelné pouze pro velké
výrobce, kteří si mohou dovolit investovat do takové komplikované organizace
relativně vysoké prostředky, zamyslete se znova. Mnohé firmy, které z
jakýchkoliv důvodů vyvíjejí svůj vlastní software, se, aby svůj software
vylepšily, drží téhož náročného postupu.
Vezměme si například divizi e-services v rámci instituce Dubai E-government. Od
prvního dne procesu vývoje softwaru jsou brány v úvahu funkce, jež by nově
vytvářené aplikace vykonávaly, a také dostupná infrastruktura či bezpečnostní
opatření potřebná pro takovou aplikaci. Veškerá tvorba aplikací musí dodržovat
přesně definované procedury a musí být uvnitř organizace "certifikována" na
důkaz toho, že těmto procedurám vyhovuje. Samotné bezpečnostní procesy byly
sestaveny na bázi několika vypozorovaných nejlepších praktik v odvětví.
"Máme své politiky nastaveny už po dobu více než čtyř let, po které existujeme.
Avšak teprve v posledním roce jsme je formalizovali. Politiky rovněž zahrnují
síťovou bezpečnost (jak se data přesouvají v páteři), přičemž se kontroluje,
zda aplikace síťové protokoly správně využívá," vysvětluje Fadi Hindi, výkonný
IT manažer instituce Dubai E-Government.
Všechny tyto politiky jsou důsledně zdokumentovány a implementovány s maximální
precizností. Co je však na této divizi skutečně působivé, je jejich
propracovaný testovací proces. Jak říká Hindi, neustále jen "testují, testují a
testují", dokud si nejsou absolutně jisti bezpečností svého softwaru. Divize
využívá pro své softwarové aplikace speciální prostředí pro zajištění kvality
(Quality Assurance Environment), které je do posledního detailu zrcadlem
skutečného produkčního prostředí. Zde aplikace prochází přes minimálně tři
různé testovací cykly ještě před tím, než je schválena pro produkční část. Mimo
to divize vyzývá externí bezpečnostní experty, aby na jejich aplikacích
provedli penetrační testování, takže je zajištěno, že bude vše bezpečné i
zvnějšku. Tyto testy jsou prováděny na pravidelné bázi a podle Hindiho jeho
divize hodlá učinit penetrační testování v blízké budoucnosti mnohem
sofistikovanějším a "podobné skutečnému hackování".
Dalším dobrým příkladem procesně orientovaného vývoje uvnitř organizace je
skupina Al Ghurair. Před začátkem vývoje skupina provádí dedikovanou analýzu
hrozeb, nemluvě o stanovení požadavků, jak snadno aplikace může a měla by být
záplatovatelná a jak jednoduše mohou být sledovány její verze. Nedávno začala
zavádět aspektově orientované programování (Aspect Oriented Programming), které
skupině dovoluje separovat softwarovou funkcionalitu od bezpečnosti a takto jí
umožnit se na obě stránky mnohem lépe soustředit. "Bezpečnost je pro nás v
životním cyklu aplikace základem. Vedle využívání procesů se rovněž neustále
ujišťujeme o tom, zda jsou plně aktualizovány také naše vývojové nástroje a
knihovny. Stejně tak sledujeme nejnovější exploity, které se objevují, abychom
byli neustále připraveni na různé eventuality," říká Hatem Ali, CIO této
skupiny.

Zadní vrátka
Bezpečnost, která je začleněna do celého vývojového cyklu aplikace, je pro
odvětví relativně novým konceptem. To znamená, že zatímco větší hráči jej už ve
větší či menší míře přijali a během posledních čtyř let zavedli potřebné prvky,
mnozí z menších výrobců a ISV (Independent Software Vendor, nezávislí
softwaroví tvůrci) se k němu teprve snaží propracovat.
"Na ISV je tlak v rámci projektů velmi vysoký, a bezpečnost tak často není
jejich klíčovým elementem. Takže mimo velké výrobce zůstávají bezpečnostní
iniciativy dlouhodobým problémem," říká Eckert. Většina velkých výrobců, kteří
spolupracují s ISV, se pokouší zajistit, aby bezpečnost byla klíčovým prvkem
jejich vývojových procesů ještě před tím, než začnou uvažovat o integraci
jejich produktů do svých rozsáhlých softwarových sad.
Například Oracle vytvořil portál Oracle Technology Network (OTN), aby ISV
pomohl adoptovat nejnovější technologie a nejlepší praktiky. Oracle Security
Technology Centre, což je součást sítě OTN, pokrývá bezpečnostní problémy a
pomáhá ISV vypořádat se se všemi oblastmi bezpečnosti. Centrum pro všechny ISV
nabízí například bezpečnostní zdroje, nejlepší praktiky, kódy, školení a
technická upozornění.
Další velikán, společnost CA, má zase partnerský proces označovaný jako CA
Smart Member, jenž specifikuje ideální vývojový proces pro partnery, kteří
chtějí buďto použít nějakou komponentu CA, nebo chtějí, aby byla jejich
technologie integrována s produkty od CA.
Firma Cisco Systems naopak vyžaduje, aby partneři, s nimiž se spojuje za účelem
integrace produktů, prošli přes důkladný certifikační proces a aby byl jejich
software pečlivě otestován a akreditován na poli bezpečnosti.
Takto velcí výrobci prostřednictvím vynucování zavedení svých procesů u ISV
současně napomáhají tomu, aby celé odvětví rychleji dospělo a vyhovělo potřebě
brát ohled na bezpečnost při vývoji aplikací. Jsou také další výrobci, jako
třeba poskytovatel zákaznických softwarových řešení AlliedSoft, kteří
bezpečnost začlení do vývoje, pokud si to klient specificky vyžádá a je
připraven za to zaplatit. Ale stále je tu mnoho malých výrobců, kteří pro to,
aby kladli na bezpečnost větší důraz, postrádají dostatek prostředků na
investice, čas nebo výzkumné a vývojové zázemí. Celé toto odvětví se přitom
shoduje na tom, že bude ještě nějakou dobu trvat, než ISV budou schopni se
zmíněného trendu chytit.
Dalšími zadními vrátky v bezpečnostních iniciativách, jež výrobci zavádějí, je
nedostatek příslušného vzdělávání mezi vývojáři ve firmách. Takové vzdělávání a
školení je už zcela nezbytné a jak podotýká Tantawy, v kurzech softwarového
inženýringu toho stále hodně chybí. Například vývojové centrum IBM pro své
vývojáře nabízí komplexní školicí program, jenž jim pomáhá pochopit, jakým
způsobem má jejich práce zapadnout do příslušných procesů, a neustále jim
vštěpuje důležitost potřeby bezpečnosti.
Microsoft zase během nástupu Windows Serveru 2003 na místo Windows Serveru 2000
utratil téměř 200 milionů dolarů za změny ve svém vývoji, a to včetně školení
vývojářů a pomoci začlenit bezpečnostní prvky do softwarového designu a vývoje.
Ačkoliv se lze v odvětví setkat s opatřeními, jako jsou výše zmíněná, jež mají
za cíl vzdělávat bojovníky na poli tvorby kódu o bezpečnosti aplikací,
dlouhodobé vštěpování takových konceptů bude muset přicházet už z akademické
půdy na to bude muset odvětví ale trošku zatlačit.

Želízko na konci
Dokonce i když se výrobci pokoušejí prosadit standardy týkající se toho, jak má
být vytvářen bezpečný software, je zde ještě další důležitý element celého
procesu, jenž by neměl být opomenut zákazník. Těmi důvody, proč výrobci
zamýšlejí zvýšit úroveň bezpečnosti svého softwaru, jsou z velké části rostoucí
povědomí mezi klienty a nárůst počtu takzvaných chytřejších zákazníků. Nicméně
obecné povědomí o potřebě bezpečnosti aplikací má před sebou v porovnání se
síťovou bezpečností ještě dlouhou cestu, a to obzvláště mezi menšími firmami,
které se teprve probouzejí a začínají uvažovat o výhodách, jež může IT přinést
do jejich organizace.
Většina zákazníků požaduje spoustu funkcí, ale neexistuje pro ně způsob, jak je
opravdu stručně zaznamenat. Uchylují se k tomu, že přicházejí s prohlášeními
jako ,chceme, aby byl systém bezpečný, ale je pro ně obtížné to dále
specifikovat. Je tedy potřeba vzdělávat také zákazníky, aby se posunuli dále v
evolučním procesu a byli schopni lépe vyjádřit, co od IT vlastně chtějí,"
uzavírá Tantawy.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.