Делян Делчев е телекомуникационен инженер. Участвал е в изграждането на

...
Делян Делчев е телекомуникационен инженер. Участвал е в изграждането на
Коментари Харесай

Няма "бели" хакери, няма "черни" хакери, няма вълшебници!

Делян Делчев е телекомуникационен инженер. Участвал е в построяването на множеството съществени телекомуникационни инфраструктури у нас в последните 20 години, като е съветвал съвсем всички оператори в страната, както и доста в чужбина. Текстът е препечатан от " Терминал 3 ".

Борисов споделил, че младежът, упрекнат за приключването на данните на Национална агенция за приходите, бил магьосник и държавната администрация трябвало да наема бели хакери на работа (К.Б., бял хакер, именуван Кристиян Белия). Това ме стимулира да напиша този, уповавам се, не прекомерно заплашителен и дълъг коментар.

Първо – предизвестие. В дългата си (вече 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 и военните (и полицейски) ИТ системи.

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

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

Всичко, което би трябвало да знаете за: Изтичането на персонални данни от Национална агенция за приходите (52)

СПОДЕЛИ СТАТИЯТА


Промоции

КОМЕНТАРИ
НАПИШИ КОМЕНТАР