Вътрешен риск: намалете възможностите и подобрете реакцията

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

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

Идентифицирайте пътищата с голямо въздействие

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

Питайте какво може човек да прочете, промени, експортира, изтрие или одобри – а не просто дали има акаунт.

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

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

Премахнете ненужните правомощия, преди да добавите наблюдение

Най-малките привилегии означават правата да съответстват на текущата работа. Започнете с действителните права, включително вложените групи, специфичните за приложенията роли, делегирания достъп, служебните акаунти, API токените и споделените идентификационни данни. Подреден списък с роли в директорията може да прикрива прекомерни права в отделните приложения.

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

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

Вградете промените в достъпа в процесите за персонала и доставчиците:

• Постъпване: предоставяйте определена роля, вместо да копирате натрупаните права на колега.
• Преместване: премахвайте остарелия достъп, а не само добавяйте нови отговорности.
• Напускане: координирайте деактивирането на акаунта, прекратяването на сесиите, отнемането на токените, обработката на устройствата и премахването на достъпа на доставчиците.
• Временна работа: определяйте собственик и срок на валидност за повишения или специфичен за проекта достъп.

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

Защитете данните и пътя навън

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

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

Криптирането в покой и при пренос защитава определени пътища на експозиция, но оправомощен потребител все пак може да извлече некриптиран текст. Комбинирайте криптирането с граници на достъпа, ограничения на експорта и контролирано споделяне. Защитавайте и резервните копия и администрирането на възстановяването: от разрушителна злоупотреба е по-трудно да се възстановите, когато една и съща идентичност може да променя производствената среда и да изтрива резервните ѝ копия.

Направете откриването пропорционално и обяснимо

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

Използвайте одитните журнали на приложенията заедно със събитията от идентичностите, крайните устройства и облака. Система за управление на информацията и събитията по сигурността (SIEM) може да корелира тези източници; анализът на поведението на потребители и обекти може да помогне за откриване на отклонения от базова линия. Нито едното не установява намерение. Миграция, одобрено реагиране при инцидент или променена длъжност могат да обяснят необичайна активност.

За всяко правило за откриване посочете:

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

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

Първо установете предпазни мерки за наблюдението

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

Когато се прилага ОРЗД, неговите членове 5, 6, 13–14 и 32 уреждат принципите, законосъобразното обработване, прозрачността и сигурността. Член 35 изисква оценка на въздействието върху защитата на данните, когато има вероятност обработването да породи висок риск. Целите на сигурността не премахват тези изисквания.

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

Помогнете на хората да докладват грешките рано

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

Направете обучението специфично за работата. Финансовите екипи се нуждаят от сценарии за проверка на промени в плащанията; разработчиците се нуждаят от примери за работа с хранилища на код и тайни; служителите по поддръжката се нуждаят от насоки за експорти на данни за клиенти и опити за представяне под чужда самоличност. Включете изпълнителите и привилегированите администратори.

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

Реагирайте на факти, а не на етикети

Сигналът е повод за разследване, а не доказателство за нарушение. Установете контекста и защитете поверителността на всички замесени. Привидно валидно действие с акаунт може да отразява грешка, автоматизация, открадната сесия или умишлена злоупотреба; нуждите от ограничаване може да се припокриват, докато последиците за трудовото правоотношение се различават.

Използваемият наръчник за реагиране трябва да обхваща пет решения:

1. Първоначална оценка: потвърдете събитието, засегнатите активи, чувствителността, оторизацията и дали вредата продължава. Проверете одобрените промени и се свържете със собственика на процеса чрез доверен канал.
2. Запазване: запазете релевантните журнали, събитията от идентичностите, записите за споделяне и оригиналните файлове, когато е уместно. Документирайте времето на събиране, източника, разследващия и обработката. Ограничете достъпа до материалите по случая.
3. Ограничаване: изберете пропорционални мерки като анулиране на сесии, ограничаване на експорти, изключване на споделянето или премахване на повишените права. Вземете предвид зависимостите на услугите, преди да деактивирате акаунт, без да забавяте спешната защита.
4. Координиране: включете сигурността, собственика на системата, поверителността, правния отдел и човешките ресурси според фактите. Мерките по трудовото правоотношение и сигналите до правоохранителните органи изискват подходящи правомощия, а не автоматичен праг на сигнал.
5. Възстановяване: възстановете одобрения достъп и конфигурации, сменете засегнатите идентификационни данни, валидирайте цялостността на данните и наблюдавайте за повторна поява.

Определете кой може да разреши спешно ограничаване и алтернативен контакт, ако е замесен привилегирован администратор или обичайното лице, вземащо решенията.

Оценявайте задълженията за уведомяване отделно. Съгласно членове 33 и 34 от ОРЗД администраторите оценяват уведомяването на надзорния орган без ненужно забавяне и когато е осъществимо – не по-късно от 72 часа след узнаването, освен ако няма вероятност нарушението да породи риск за правата и свободите на физическите лица. Обработващите уведомяват администраторите без ненужно забавяне. Високият риск може да изисква съобщаване на засегнатите лица, при спазване на изключенията по член 34. Документирайте мотивите за неуведомяване и проверете другите приложими договорни или законови задължения.

Практически пример: необичаен експорт на данни за клиенти

Илюстративни допускания: приложение за поддръжка съдържа данни за контакт на клиенти; супервайзорите могат да експортират ограничени записи за одобрени случаи; отделна идентичност за интеграция изпълнява планирано отчитане.

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

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

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

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

Пазете доказателства, които показват, че контролите работят

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

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

Secani свързва рисковете, внедряването на контролите и доказателствата в управляван контекст. За един път за достъп екипите могат да моделират релевантните системи, да прикачат експорти от прегледи и записи от тестове, да възлагат задачи за отстраняване на пропуските и да запазват решенията от човешкия преглед. Документацията за права и API достъп описва ролята за OSCAL API, ограничена само до валидиране – конкретен пример за предоставяне на идентификационни данни с възможности, ограничени до предназначената им задача. Внасяйте експортите от прегледите на достъпа, констатациите от наблюдението и одобрените решения за реагиране в този свързан запис за контролите.

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