SHARE

Борисов казал, че младежът, обвинен за изтичането на данните на НАП, бил вълшебник и държавната администрация трябвало да наема бели хакери на работа (К.Б., бял хакер, наричан Кристиян Белия).

Това ме мотивира да напиша този, надявам се, не прекалено страшен и дълъг коментар.

Първо – предупреждение. В дългата си (вече 30+ години) ИТ кариера съм се занимавал и се занимавал с какво ли не, с различна степен на успех, но винаги внимателно съм заобикалял темата за сигурността.

ИТ сигурността си е собствен микросвят, с изключителна динамика, където познанието, каквото и да имаш, остарява с дни и аз винаги съм смятал за прекалено голямо и неблагодарно усилие граденето на кариера в тази област.
Въпреки това, макар и неспециалист, съм видял това-онова, правил съм или съм разследвал това-онова, тук-там ми се е налагало да правя или дори професионално да оценявам чужди дизайни на тема сигурност.

В този смисъл искам да отбележа, че изказването на Борисов е популистко, радост и надежда за публиката, но дразнещо специалистите и дори аматьорите като мен.
Прочетете следващото, с известна критичност, но се надявам да успеете да разберете какво всъщност се опитвам да кажа и къде според мен стои истинският проблем.
Проблемът с изказването на Борисов е това, че то подсказва тотално неразбиране на това, как точно се реализира ИТ сигурността, и всъщност подсказва, че администрацията може да продължи да си прави каквото си е свикнала да си прави, а отговорността за проблемите със сигурността ще се прехвърли на нови хора – хакерите.

„Черните хакери“ ще са отговорни за зловредните ефекти, „белите хакери“ за това, че не са ни защитили.
Основен фундамент на проблемното разбиране за това как се реализира ИТ сигурност е мисленето, че сигурността е продукт или услуга, които можеш да закупиш.
Не, закупуването на firewall не гарантира това, че системата ви ще бъде сигурна.

Закупуването на penetration testing от бели хакери, било то наети като служители или външни фирми, не гарантира, че системата ви ще бъде сигурна.
Това ГДБОП да прегледа дизайна на системата ви или да проверява това или онова не гарантира, че системата ви ще бъде сигурна.

Държавна агенция (ДАЕУ, ДКСИ, ГДБОП или ИО), участваща в дизайна и изискваща прилагането на добри практики при изпълняването на системите или програмирането, не гарантира, че системата ви ще бъде сигурна.
Дори спирането на публичния достъп до електронни услуги пак не гарантира, че затворените регистри и мрежи ще бъдат сигурни.

Това са аматьорски виждания. Толкова аматьорски, че могат да бъдат оценени като аматьорски от аматьори като мен.
Първото нещо, което е важно да бъде проумяно от всички радетели за ИТ сигурност, е, че сигурността е организация и процес(и).

Ако разгледаме хипотетично създаването и въвеждането на една нова ИТ система, то какви са стъпките, необходими, за да я превърнат в сигурна?

Вероятно добър дизайн (например разделение на типовете данни, криптография, недопускане на една подсистема и интерфейси в системата да има достъп до всички данни едновременно, анализ на рисковете от компрометиране на всяка комуникация, всяка връзка, всяка подсистема и т.н. всеки компонент, машина, хайпървайзър, физически достъп, административен достъп, т.н. Изолация между подсистемите и мрежите и подобни).

Използване на подходящи хардуерни или виртуални подсистеми, така че да отговарят на нуждите на дизайна и от гледна точка на сигурността.
Това достатъчно ли е? Не.

Всеки компонент, дори самата система може да бъде компрометирана. Може да изскочи експлойт, публичен или не. Хакер, вътрешен пробив, изтичане на данни, подкуп, чистачката да събори сървъра, да откачи кабела. Как да се предпазим?

Може би трябва да проверяваме за експлойти? Когато възникне информация, да тестваме (penetration testing) и ако ни засягат, да вземем мерки (vulnerability management, patch management). Системите със затворен код не можем да оправим сами, но вероятно можем да вземем мерки да изолираме проблема (подходящ дизайн на комуникационните потоци, който да позволява това, е необходим). Но въпреки това, когато се натрупват изолации, става колода от карти, така че трябва да разчитаме на производителите на хардуер и софтуер да поправят активно дефектите си и ние активно да патчваме подсистемите с тях. Обаче какво става, ако подсистемите (да речем Windows 7) вече не са в поддръжка? Ако се ползва софтуер, който е опън сорс/безплатен, но няма кой да извърши поддръжката, в състояние ли сме да наемем/подсигурим външен платен ресурс, който да извърши софтуерният патч, или да използваме вътрешен ресурс, който да го патчне?

А ако дадени подсистеми изискват ъпгрейд поради промяна на интерфейси (примерно Oracle спира поддръжката на стара база с данни и вие трябва не просто да инсталирате нова версия, но и да промените драйверите и дори самия код, който комуникира с базата), в състояние ли сте да го направите? Фирмата, от която е закупена системата под ключ в състояние ли да извърши това. А ако фирмата фалира, преди да изтече времеживота на вашата ИТ система? А, ако трябва да я смените?

Ако се замислите над тези въпроси, виждате, че съществуването на една ИТ система е процес и организация, които започват още отпреди проявата й, още отпреди създаването на дизайн.

Трябва още когато проектирате заданието, да имате адресирани куп рискове, като например какво правите, ако се наложи да промените изцяло дизайн, изпълнител, поддръжка и т.н. на системата. Как юридически, логически, логистично и физически и като споразумение с подизпълнителите осигурявате това?

Как ще изградим организацията по съществуването и поддръжката и подобряването и усъвършенстването на системата? Ако това не е планирано, рискувате да имате на всеки 2 г. проблеми, както има Търговският регистър.
Ами парите за тази поддръжка? OPEX-а не е само заплати. Ако нямате това планирано или пък го изтънявате систематично, рискувате отново да имате проблеми като Търговския регистър.

[Всъщност у нас има фундаментално некоректно изчисляване на OPEX-а, свързан с реалната поддръжка (например MTBF) – пример, ако сте Търговски регистър и имате 50 диска, всеки с MTBF от 10 години, то значи на 10-ата година вече ще сте загубили поне 25 диска, или средно по 2.5 на година (по-малко в началото, но след 5-ата година поне 2-3 пъти повече) – линейните изчисления на тези разходи са фундаментално грешни, линейното предположение за необходими spares и количество човешки труд – също. Първите години подвеждат, че поддръжката е с по-малка цена, и създават грешното усещане за възможност за съкращаване на разходите и даване на по-големи бонуси на мениджмънта. Превантивна поддръжка – например предварителна подмяна на дисковете, когато остареят, преди да са гръмнали, за да се намалява рискът да гърмят едновременно и да намажат RAID-а е направо нечувана по нашите земи.]

Ами работа с външни подизпълнители? Ами работа с нови под изпълнители, при условие че старият изпълнител не е добронамерен (не съдейства или дори злонамерено вреди на системите)? Ще се изненадат колко често се случва това (всъщност е правило, така че при приемането на ИТ системата от подизпълнител вие трябва да сте подсигурили максималния риск, че може да се наложи да работите в злонамерена среда и с други хора – тоест трябва ви всичко необходимо за такъв преход изначално – код, документация, права, собственост, лицензи и т.н.). А дали подизпълнителите са ви дали система с достатъчно качествен дизайн и са ви предали документация, сорс, права, лицензи и компоненти, които да ви позволят да се оправите самостоятелно, ако се наложи да решавате най лошите проблеми и рискове? Как оценявате това?

Впоследствие как проверявате, че системата работи коректно. Как преценявате, че не е хакната (и това има много слоеве, например дали системата изпълнява всичките си функции точно както се предполага, но и дали не е хакната или модифицирана злоумишлено, или пък е компрометируема)? Тук може би можете за част от тези дейности (penetration testing) да ползвате услугите на бели хакери, но те не могат да решат другите въпроси и проблеми. Всъщност те дори не могат да ви дадат основата на сигурността. Те само могат да ви отговорят дали системата ви е несигурна. Но не могат да ви кажат, че е сигурна, нито да ви посъветват как да я направите такава генерално, а не на парче.

А ако трябва да патчнете системата за дефекти? Или да я промените, защото компонент излиза от поддръжка на производителя или възникне прекомерен проблем?
А ако пък ви хакнат, как разбирате? Ако разберете, как проследявате и откривате как са ви хакнали? Ако хакерите са изтрили всичките ви данни, вие как ги възстановявате (процедури за бакъп, bootstrap, преинсталация, възстановяване)? Как проверявате за компрометираност на самите бакъпи? Дали хакерите са имали достъп и до бакъпите и са си вкарали хака вътре, та всеки път като възстановите системата си всъщност сами я хаквате (и може да са изтрили и некомпрометираните бакъпи)?

А как откривате кога са възникнали проблемите, за да разследвате събитията (логове)? Обратно, как подсигурявате, ако хакерите достъпят логове, да не научат прекомерно много информация за вас (например пароли, които се логват в логовете)?

Как се защитавате, ако недоволен админ просто дъмпне базата с данни и я даде на приятел?
А как се защитавате от DoS и DDoS (и въобще DDoS хакване ли е)?

А криптографията? Как подсигурявате, че я има и е изпълнена коректно, така че да не издава информация (без да се налага декриптиране) или да се счупва прекалено лесно?
А какво става, когато решите най-накрая да извадите системата от употреба (може би е заменена с нова)? Дали не трябва да я изтриете много внимателно (за да не би хакер хакнал тая система, която вече не следите и не поддържате, но е оставена по дисковете, да извади любимите и вечно не сменяеми пароли на много потребителя или пък личните им данни)?

По тези теми мога да коментирам много.

Но се надявам с критичните въпроси, да съм ви създал усещането, че най-важното е, че ИТ сигурността е организация и процес. Тя започва отпреди създаването на ИТ системата и завърша доста след прекратяване на съществуването й.
Хакерите, консултантите, фирмите доставчици, продуктите, това са компоненти в ИТ сигурността. Но те не я създават, нито я оркестрират.

Тя се създава организационно от възложителя и той е единственият отговорен и заинтересован, тази организация, създаваща сигурността, да съществува и оперира коректно през целия необходим период.

И у нас това не е дори въпрос на законодателство. Ратифицирани директиви, наредби и дори правила от държавната агенция за електронно управление, предполагат, предлагат и допускат въвеждането и прилагането на добри практики. Но както виждаме, това не е самодостатъчно, наредбите да го допускат. Някой трябва и да ги следва.
Трябва възложителите и собствениците на ИТ системите, които са критични за държавата и обществото, да се постараят да приведат организацията си в ред, и да допускат и позволяват външен одит и анализ, както от определени за целта агенции (например ДКСИ, ДАЕУ, ГДБОП), така и от гражданското общество.

Организацията и процесите, трябва да позволяват възникването на проблем да е повод за подобрение и оптимизация, а не повод за теории на конспирациите и обвинения.

У нас заради начина на бюджетиране на държавните дружества още от времето на социализма всеки годишен разход се третира като проект, в който има основно CAPEX и приключва след закупуването. Единственият OPEX идва за/по пера заплати и много трудно се приема и признава какъвто и да е друг такъв. В резултат организации, риск, сигурност, остават недофинансирани.

Европейското финансиране също не помага в промяната на мисленето.

Европейските пари финансират само CAPEX, защото се предполага, че тяхната цел е да помогнат да придобиете нещо, за което не ви стигат парите. Но не финансират OPEX, защото се предполага, че това си е ваше задължение, след като сте получили това нещо, за да си го имате, понеже сте го поискали, защото наистина ви е необходимо.
Но ние искаме неща, защото ни се искат, не защото наистина ни трябват. А, и за да извъртим едни пари. Никой не мисли за поддръжката и използването им.

Дали ще са магистрали, финансирани от ЕС, които след 2 години се развалят и не сме измислили откъде да вземем пари, за да си ги поправим, или говорим за Търговския регистър, финансиран с пари от ЕС и като му свърши пространството или остареят дисковите под системи, не са останали пари да ги подменим, понеже е били по-важно мениджмънтът да си раздаде бонуси, проблемът е един и същ – че не се мисли изначално за ползването на системата, организацията, поддръжката, рисковете и ИТ сигурността.
Има добри практики. Те не гарантират сигурност, но предполагат и целят да ви напомнят за важни компоненти в създаването на нов ИТ продукт, система или услуга, напомнящи ви да обърнете внимание на организация, сигурност, поддръжка, физически, логически компоненти, подизпълнители, комуникации и трети страни.
Хубаво е всяка система, която е критична държавна инфраструктура (НАП, ТР, съдебни системи, МВР, военни) да премине (а защо не и да се сертифицира и периодично одитира) през някоя от тези добри практики.
Цитирам някои практики – ISO 27000 + Common Criteria (не влиза в много детайли, и допуска доста празни петна, ако сами не се сетите да ги адресирате), BSI IT Grundschutz (базирана и разширяваща ISO 27000, но по-детайлна), BIS (за банковите и финансови институции, доста детайлна и фокусирана по тази тема надстройка на ISO 27000), CIS за комуникациите, британската CAPS (британският BSI), EU Security сертификацията (включ. за ИТ системи) за държавните институции и критичната инфраструктура (изисква ISO 27000 като минимум), NIA за NATO и военните (и полицейски) ИТ системи.

Етичното хакерство, както споменах, се фокусира върху прекомерно тесен фокус на осигуряването на ИТ сигурност, то е полезно и вероятно необходимо, но далеч не достатъчно условие за създаването на сигурност и гарантирането на защита.

За сметка на това може да се използва като лесно оправдание (виж Борисов) – черните хакери са ни виновни, че ни хакват. Белите хакери са ни виновни, че не са ни предпазили. Така държавната ни организация си остава чиста и безотговорна, каквото и да стане, въпреки че тя като възложител е единствената отговорна и единствено в състояние да реализира необходимото.

Препубликувано от Фейсбук. Заглавието е на „Терминал 3“ 

SHARE
Делян Делчев е телекомуникационен инженер. Експерт по информационни технологии, програмиране и телекомуникации в последните 30 години. Един от пионерите на интернет и пакетните телекомуникации в България. Участвал е в изграждането на повечето основни телекомуникационни инфраструктури у нас в последните 20 години като е работил и консултирал почти всички оператори в страната, както и много в чужбина. Прави го до днес. Радетел за Електронно управление, Електронно гласуване, Open Source, Open Data, Open API, Open Government, граждански права и равна интерпретация на гражданските права електронно и физически.