Този сайт използва бисквитки (cookies). Ако желаете можете да научите повече тук. Разбрах

Новини ИТ сигурност
бр. 3, 2018

Формализмът - риск при въвеждане на GDPR

от , 28 март 2018 0 548 прочитания,

доц. Велиян Димитров

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

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

Формализмът - риск при въвеждане на GDPR

Практиката е най-добрият съветник

За разлика от останалите финансовият сектор по-лесно ще въведе изискванията на GDPR, тъй като при него са налице необходимите технически и организационни предпоставки, а именно дълъг опит със сигурността на КИТ и акумулирана корпоративна култура за опазване на цифровите активи. За да се разбере проблемът, представям два случая, от които ясно си личи, че изискванията на GDPR засягат далеч повече технически аспекти на сигурността на ИКТ, отколкото изглежда на пръв поглед (член 39).

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

Според GDPR взаимното изискване към контрагентите за покриване на изискванията за защита на личните данни важи, в случай че една организация изпраща лични данни към друга. Тук изниква следният интересен момент. След като най-големите пробиви с изтичане данни (не само лични) станаха точно по веригите за доставки - красноречив пример е случилото се с ритейлъра Target - се оказва, че има смисъл да се изисква от контрагента ниво на сигурност на ИКТ системата му.

Лошите практики също са полезни

Всеки може да открие в интернет и да разгледа сайтовете, които онлайн представят актуална информация за инциденти с изтичане на данни. Доклади с такива данни и статистически анализи ежегодно и за по малки периоди издават много от големите компании, които се занимават с темата. Пропускам имената на домейните и брандовете (в духа на GDPR) и обръщам внимание на един факт. От тези сайтове и доклади лесно се вижда, че доста от пострадалите са големи корпорации, които до инцидента са покрили изискванията на много стандарти и режими за сигурност, минали са много одити на информационната сигурност, провеждали са обучение на персонала. Мерките, които са били налице, далеч надхвърлят изискванията за сигурност, които на пръв поглед налага прочитът (колкото и да е внимателен) на GDPR.

Нивото на сигурност на конкретна система от ИКТ е относително във времето, поддържането му е подобно на стрелба по движеща се мишена. Например никой не знае в момента колко уязвимости от типа 0-day, които засягат наличните активи от ИКТ на дадена организация, се търгуват в подземния интернeт. Оттук следва, че сроковете за съхраняване на личните данни, които независимо дали са в покой, в движение или предадени към контрагенти, имат още един смисъл, а именно намаляват риска от експониране и засягане на правата на субектите на данни.

Следващият сценарий се отнася до ситуации, които директно нанасят вреди на компаниите поради невъзможност да отговорят на субектите на данни при определени искания и да спазят правата им. Да допуснем, че системата от ИКТ на дадена компания, която е администратор на лични данни, е компрометирана, което вече, надявам се, стана ясно, че е напълно възможно. Данните не са изтекли, но са криптирани от злосторници, които искат откуп. Класически - за съжаление - вече инцидент с ransomware. Нападателите си чакат откупа в срок. През този период организацията може да получи искания за преместване на данните, информиране за обработването им или реализиране на някое от останалите права на субекта на лични данни, както диктува GDPR. Допускам, че част от исканията за откуп ще имат период по-малък от 72 часа. През този период правата на субектите на данни са нарушени, вижда се например от Съображение 59, че в подобна ситуация данните на субекта трудно може да се коригират или, да речем, изтрият при негово искане в качеството му на субект на данните. Тук само припомням, че в няколко добре изследвани и описани инциденти с ransomware декриптирането на данните не се състоя по различни причини, анализът на които излиза извън рамките на тази статия.

Технологията doxing пък се отличава с отвличане на чувствителни данни извън средата на организацията, да речем, чрез невидимо присъствие (Advanced Persistent Thread), техники за невидимо източване на данни (например stegware), с последващо искане на откуп срещу заплаха да бъдат публикувани. Ondrej Vlcek предрече още за 2017, че този подход ще се разпространи.

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

доц. Велиян Димитров

Поуки от реалността

Осъществяването на формалните мерки за съответствие с GDPR, които се свеждат до наличие на документация, козметични промени в интерфейсите на софтуерните артефакти, които осигуряват информационните системи, и повърхностното обучение, се налага по много причини, които са известни в професионалните среди, а ЕС издава достатъчно разпоредби по темата. Делегираните документи, които са издадени от този комитет въз основа на или във връзка с Директива 95/46/EО, която се отменя с GDPR, са общо 1069, от които 111 становища на Европейския надзорен орган за защита на данните, ЕНОЗД. Твърдя, че броят на делегираните документи, които ще произтекат от GDPR, ще надхвърли тези стойности много скоро.

Съответствието с GDPR ще се изисква взаимно от всички участници по веригите за доставки, а реалните взаимни одити се очертават като неизбежен елемент от договорните отношения между изпълнители и заявители. Тази практика и сега съществува в контекста на познати утвърдени стандарти наред с формалното признаване на сертифицирани системи по определени стандарти. Големите производители, звената за разфасоване, брандиране и опаковане заедно с търговските вериги и сега провеждат непрекъснат взаимен контрол поради изискванията на различни стандарти. Това твърдение по аналогия важи и за изпълнителите на софтуерни продукти.

Последствията от нарушения с лични данни ще се отразят върху целостта на веригата за доставки, а организациите, които са компрометирани, ще останат извън нея.

Разпоредбите за сигурност на GDPR предполагат коренна промяна не само за активите на системите от ИКТ, а и за процесите при замисляне и реализиране на информационни системи, интеграцията им, оперативната съвместимост, както и инкорпорирането на киберсигурност.

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

Кога ще си проличат формализмът и неглижирането на системния подход към управлението на сигурността на системите от ИКТ при нарушенията с лични данни? Има много такива възможни сценарии. Един от тях е разследването на инцидент с изтичане на лични данни. В този случай интерес представляват записите, които водят до откриване на технологията за проникване и компрометиране, както и източване на данните, които са различни от указаните в Съображение 82 и член 30. Въпросните интересни записи (включително системните журнали, syslog) са предмет на конструирането на системата за сигурност на ИКТ. Последната от своя страна включва организационни и технически мерки, излизащи далеч извън рамките на изискванията на GDPR.

Формализмът - риск при въвеждане на GDPR

Формализмът е опасен

Тук му е мястото да спомена многото изследвания за „успиването“, измамното чувство за надценяване на наличната сигурност на системите от ИКТ, което е установено от няколко анкетни проучвания. Очаквам подобен ефект да се прояви в някои организации и след въвеждането на изискванията на GDPR, особено когато това стане само със съставяне на документация, дори да е само оценката на въздействието на сигурността на личните данни.

GDPR въвежда доверителни вериги, участниците в които трябва да притежават документални доказателства, че са положили необходимите грижи за опазването на личните данни и могат да приемат и изпращат помежду си такива за обработване. Административните проверки са редки, с ясно указани правила и се ограничават в общия случай до документацията, докато хакерите действат непрекъснато, с неординарни способи и са фокусирани върху системата за сигурност. Действията на хакерите може да доведат до изтичане на данни, което от своя страна освен административни проверки да предизвика каскада от разследвания по най-различни поводи…

Организациите, работещи като подизпълнители, трябва да получат гаранции и документални доказателства, че освен за себе си контрагентите им са положили необходимата грижа да проверят всеки от своите доставчици, тъй като, ако някой от тях претърпи нарушение на данните, може да бъдат засегнати всички по веригата. Техническите аспекти на това твърдение отиват твърде далеч: те касаят инкорпориране на сигурност освен чрез регулярния процес за проактивна защита по веригата за доставки на облачни услуги инструментите за писане и тестване на програмен код, програмните библиотеки, SDK, API, интегрирането на двуслойни и трислойни и разпределени програмни обкръжения, договорни съглашения за гаранционна поддръжка с ъпдейти по сигурността, наблюдение и реакция на новоизлезли технически нормали (методики, указания) по сигурността от ЕС.

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

В контекста на финансовите институции трябва да се отбележи, че PSD2 съдържа свой собствен набор от правила за достъп до лични данни на клиентите, които се отнасят за доставчиците на платежни услуги, като PISP и AISPs (член 64 от PSD2). Текстовете допълват, вместо да заменят законите за защита на данните. PSD2 укрепва изискванията за изрично съгласие, изискването за минимален набор от други лични данни освен тези, необходими за предоставяне на услугата, ограничението за използване или съхраняване на лични данни за други цели.

Тези правила не са напълно съвместими с изискванията за защита на данните на GDPR и биха могли да доведат до объркване. Например от доставчиците на услуги се очаква да не съхраняват "чувствителни данни за плащанията". Това е съвсем различна категория от информацията, класифицирана като "чувствителни лични данни" в GDPR, която включва информация за расов или етнически произход, политически възгледи, генетични данни и т.н. Следователно, въпреки че PISPs и AISPs ще трябва да следват правилата PSD2, те ще трябва да доказват постоянно, че са в съответствие с по-широките правила за защита на данните съгласно GDPR.

От гледна точка на целта на настоящата статия бих казал, че в благодарение на PSD2 екосистемата на бизнеса с финансови услуги се намесват играчи, които досега са били в съвсем други сфери. Според някои тълкувания иновационният потенциал на PSD2 ще даде възможност на организации от други браншове да посредничат във веригата за платежни операции.

Тук откривам аналогията с проблемите, които се очертаха в областта на сигурността при размиването на границите на IoT и сливането на обхвата на индустриалните контролни системи (ICS), облачния компютинг и мобилните технологии. Досегашното статукво на сигурността на ИКТ във финансовия сектор се отличава с много по-високи изисквания от този на останалите браншове. Очертава се синергия на технологичните схеми на организациите от финансовия сектор и други. Последните тепърва ще трябва да усвояват стандартите за сигурност на финансовия сектор. По тази тема засякох публикации, в които за посредници при обработване на финансови транзакции се спрягат включително и компаниите, собственици на големите социални мрежи, и търсещи машини. Регламентирано е да става чрез API към банките, което пък ми припомни няколко интересни разработки на мой студент с тревожни изследвания на сигурността на много от сега действащите в интеренет приложни програмни интерфейси (API).

В тази област се открива широко поле за изследователите… Накрая бих препоръчал на заинтригуваните да имат предвид, че бегло сечение в CVE показа над 1000 слабости в разпространени API за последните пет години, без да се отчита тежестта им, но всяка от тези слабости е експонирана отново в десетки хиляди приложни инстанции.

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

КОМЕНТАРИ ОТ  

Полезни страници
    За нас | Аудитория | Реклама | Контакти | Общи условия |
    Действителни собственици на настоящото издание са Иво Георгиев Прокопиев и Теодор Иванов Захов