🥇Мониторинг на сигурността на облаците

Пренасянето на данни и приложения в облака представлява ново предизвикателство за корпоративните SOC, които не винаги са готови да наблюдават чужда инфраструктура. Според данни от Netoskope средното предприятие (очевидно все пак в САЩ) използва 1246 различни облачни услуги, което е с 22% повече, отколкото преди година. 1246 облачни услуги!!! 175 от тях се отнасят до HR услуги, 170 са свързани с маркетинг, 110 — в областта на комуникациите и 76 в финансите и CRM. В Cisco се използват "само" 700 външни облачни услуги. Затова малко ме смущават тези цифри. Но в крайна сметка проблемът не е в тях, а в това, че облаците доста активно започват да се прилагат от все повече компании, които биха искали да имат същите възможности за наблюдение на облачната инфраструктура, както и в собствената мрежа. И тази тенденция нараства — според данни на американската счетоводна палата към 2023 г. в САЩ планират да закрият 1200 Цоопа (6250 вече са закрити). Но преходът към облака не е просто "а да пренесем нашите сървъри при външен доставчик". Нова ИТ архитектура, нов софтуер, нови процеси, нови ограничения… Всичко това внася съществени промени в работата не само на ИТ, но и на ИБ. И ако с осигуряването на безопасността на самото облако доставчиците са успели да се справят (за щастие има достатъчно много насоки), то с облачния мониторинг на ИБ, особено на SaaS платформи, има съществени затруднения, за които ще говорим.

Да предположим, че вашата компания е преместила част от своята инфраструктура в облак... Стоп. Не така. Ако инфраструктурата е преместена, а вие само сега се замисляте как ще я мониторите, то вече сте загубили. Ако не е Amazon, Google или Microsoft (и то с уговорки), вероятно нямате много възможности за мониторинг на вашите данни и приложения. Добре, ако ви позволят да работите с логове. Понякога данни за събития на безопасността ще са достъпни, но вие няма да имате достъп до тях. Например, Office 365. Ако имате най-евтината лицензия E1, то събития на безопасността изобщо не са ви достъпни. При наличие на лицензия E3, данните се съхраняват само за 90 дни и само при наличие на E5 — продължителността на логовете е достъпна за една година (впрочем, тук също има свои нюанси, свързани с необходимостта да искате отделни функции за работа с логове от поддръжката на Microsoft). Между другото, лицензия E3 е много по-слаба в частта на функциите за мониторинг, отколкото корпоративен Exchange. За да постигнете същото ниво, ви е нужна лицензия E5 или допълнителна лицензия Advanced Compliance, която може да изисква допълнителни средства, които не са били отчетени във вашата финансова модел за преход към облачна инфраструктура. И това е само един пример за подценяване на въпросите, свързани с мониторинга на ИБ в облаците. В тази статия, без да претендирам за пълнота на изложението, искам да обърна внимание на някои нюанси, които трябва да се вземат под внимание при избора на облачен доставчик от гледна точка на безопасността. А в края на статията ще бъде предоставен контролен списък, който трябва да изпълните, преди да смятате, че въпросът с мониторинга на облачната ИБ е решен.

Можете да откроите няколко типични проблема, водещи до инциденти в облачните среди, на които службите ИБ не успяват да реагират или изобщо не ги виждат:

Логовете за безопасност не съществуват. Това е доста разпространена ситуация, особено при начинаещите играчи на пазара на облачни решения. Но и не трябва да се отказвате от тях веднага. Малките играчи, особено местните, са по-чувствителни към изискванията на клиентите и могат бързо да реализират някои търсени функции, променяйки одобрената пътна карта на своите продукти. Да, това няма да бъде аналог на GuardDuty от Amazon или модула „Проактивна защита“ от Битрикс, но поне нещо.
ИБ не знае къде се съхраняват логовете или няма достъп до тях. Тук е необходимо да се преговаря с доставчика на облачни услуги - възможно е той да предостави такава информация, ако счете клиента за важен за себе си. Но по принцип, не е много добре, когато достъпът до логовете се предоставя "по специално решение".
Случва се и така, че логовете при облачния доставчик да съществуват, но те осигуряват ограничен мониторинг и регистрация на събития, недостатъчни за откриване на всички инциденти. Например, могат да ви предоставят само логовете за изменения на сайта или логовете за опити за аутентификация на потребители, но други събития, например, за мрежови трафик, да не предоставят, което да скрие от вас цяло пласт събития, характеризиращи опити за хакване на вашата облачна инфраструктура.
Логовете съществуват, но достъпът до тях е труден за автоматизация, което принуждава мониторинга им да не е непрекъснат, а по график. А ако не можете да изтеглите логовете автоматично, тогава извличането им, например, в формат Excel (както е при редица български доставчици на облачни решения), може напълно да доведе до нежелание за работа с тях от страна на корпоративната служба за ИБ.
Няма мониторинг на логовете. Това, вероятно, е най-неразбираемата причина за възникване на инциденти с ИБ в облачни среди. Изглежда, че логовете съществуват и достъпът до тях може да бъде автоматизиран, а никой не го прави. Защо?

Концепцията за споделена сигурност в облака

Преминаването към облака винаги е търсене на баланс между желанието да запазим контрола над инфраструктурата и предаването ѝ на по-професионални ръце на облачен доставчик, който се специализира в нейното поддържане. И в областта на безопасността на облачните среди, този баланс също трябва да се търси. Особено предвид, че в зависимост от използвания модел на предоставяне на облачни услуги (IaaS, PaaS, SaaS), този баланс ще бъде постоянно различен. Във всеки случай, трябва да помним, че всички облачни доставчици днес следват така наречения модел на споделена отговорност и споделена ИТ безопасност. За нещо отговаря облакът, за нещо отговаря клиентът, който е разположил в облака своите данни, приложения, виртуални машини и други ресурси. Би било необмислено да се очаква, че като преминем в облака, ще прехвърлим цялата отговорност на доставчика. Но също така е неразумно да строим цялата безопасност сами при преминаването към облака. Необходим е баланс, който ще зависи от множество фактори: — стратегия за управление на рисковете, модел на заплахите, налични защитни механизми у облачния доставчик, законодателство и др.

Например, класификация данни, разположени в облака, винаги е отговорност на клиента. Облачният доставчик или външният доставчик на услуги могат само да помогнат с инструменти, които да маркират данните в облака, да открият нарушения, да изтрият данни, нарушаващи законодателството, или да ги маскират по определени методи. От друга страна, физическата сигурност винаги е отговорност на облачния доставчик, която той не може да сподели с клиентите. Всичко, което е между данните и физическата инфраструктура, е именно предмет на обсъждане в тази статия. Например, наличността на облака е отговорност на доставчика, а настройките на правилата КСЕ или активирането на криптиране вече са отговорност на клиента. В тази статия ще опитаме да разгледаме какви механизми за мониторинг на ИБ предлагат днес различни популярни облачни доставчици в Русия, какви са особеностите на тяхното приложение и кога е разумно да се обърнете към външни решения (например, Cisco E-mail Security), които разширяват възможностите на вашето облако в частта за киберсигурност. В редица случаи, особено при следване на мултиоблачна стратегия, няма да имате избор, освен да използвате външни решения за мониторинг на ИБ в няколко облачни среди (например, Cisco CloudLock или Cisco Stealthwatch Cloud). В някои случаи ще разберете, че избраният (или наложен) от вас облачен доставчик изобщо не предлага възможности за мониторинг на ИБ. Това е неприятно, но също така е важно, тъй като позволява адекватно оценяване на нивото на риска, свързано с работата с това облако.

Цикъл на мониторинг на сигурността на облака

За да наблюдавате сигурността на използваните от вас облаци, имате само три възможности:

да разчитате на инструмента, предоставен от вашия облачен доставчик,
да се възползвате от решения на трети страни, които ще наблюдават използваните от вас IaaS, PaaS или SaaS платформи,
да изградите собствена инфраструктура за мониторинг на облачни среди ( само за IaaS/PaaS платформи).

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

Подготовка на инфраструктурата. Определяне на необходимите приложения и инфраструктура за събиране на важни за информационната сигурност събития в хранилището.
Събиране. На този етап събитията за сигурност се агрегат от различни източници за последваща обработка, съхранение и анализ.
Обработка. На този етап данните се преобразуват и обогатяват с цел улесняване на последващия им анализ.
Съхранение. Този компонент отговаря за краткосрочното и дългосрочно съхранение на събраните обработени и „сурови“ данни.
Анализ. На този етап имате възможност да откривате инциденти и да реагирате на тях автоматично или ръчно.
Отчетност. Този етап помага за формиране на ключови показатели за заинтересованите страни (управление, одитори, облачни доставчици, клиенти и т.н.), които да ни помагат да вземем решения, например смяна на доставчика или засилване на информационната сигурност.

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

Вградени възможности на облачните услуги

Вече писах, че много облачни услуги в момента не предлагат никакви възможности за мониторинг на ИБ. Всъщност, те не отделят много внимание на темата за ИБ. Например, един от популярните руски услуги за изпращане на отчетност до държавни органи през интернет (специално няма да споменавам името му). Целият раздел за сигурността на тази услуга е съсредоточен около използването на сертифицирани СКЗИ. Разделът за ИБ на друга отечествена облачна услуга за електронен документооборот е значително по-обемен. В него се споменава за сертификати за открити ключове, сертифицирана криптография, отстраняване на уеб уязвимости, защита от DDoS атаки, употреба на МСЕ, резервно копиране и дори редовно провеждане на одити на ИБ. Но за мониторинг няма и дума, нито за възможностите за достъп до събитията на ИБ, които може да представляват интерес за клиентите на този доставчик на услуги.

Всъщност, от начина, по който облачният доставчик описва въпросите на ИБ на сайта си и в документацията, може да се разбере колко сериозно подхожда към този въпрос. Например, ако прочетете ръководствата за продуктите “Моят офис”, там изобщо няма дума за сигурността, а в документацията на отделен продукт “Моят офис. КС3”, предназначен за защита от неоторизиран достъп, има обичайно изброяване на точките от 17-ия указ на ФСТЕК, които изпълнява “Моят офис. КС3”, но не е описано как се изпълняват и, най-важното, как да се интегрират тези механизми с корпоративната ИБ. Възможно е такава документация да съществува, но в публичния достъп на сайта на “Моят офис” не я намерих. Възможно е просто да нямам достъп до тази секретна информация?

При същия Битрикс ситуацията е на много по-добро ниво. В документацията са описани формати за дневниците на събития и, което е интересно, дневника на нахлуванията, който съдържа събития, свързани с потенциални заплахи за облачната платформа. Оттам можете да извлечете IP адрес, име на потребител или гост, източник на събитието, време, User Agent, тип събитие и т.н. Вярно е, че можете да работите с тези събития или от контролния панел на самото облако, или да експортирате данните в формат MS Excel. Автоматизацията на работата с дневниците на Битрикс в момента е затруднена и ще трябва част от работата да извършвате ръчно (експортиране на отчет и зареждане в вашия SIEM). Но ако си спомним, че съвсем наскоро такава възможност нямаше, то това е значителен напредък. В същото време искам да отбележа, че много чуждестранни облачни доставчици предлагат подобна функционалност "за начинаещи" — или преглеждате дневниците с очите си през контролния панел, или експортирате данните при вас (въпреки че повечето експортират данни в формат .csv, а не Excel).

Ако не разглеждаме опцията за отсъствие на логове, облачните доставчици обикновено предлагат три варианта за мониторинг на събитията за сигурност — табла за управление, експортиране на данни и достъп до тях чрез API. Първото изглежда решава много проблеми вместо вас, но не е съвсем така; при наличие на няколко журнали е необходимо да превключвате между екрани, които ги показват, което води до загуба на цялостна картина. Освен това, малко вероятно е облачният доставчик да ви предостави възможността за корелация на събитията за сигурност и изобщо да ги анализирате от гледна точка на сигурността (обикновено се сблъсквате с сурови данни, с които трябва да се справяте сами). Има изключения и за тях ще говорим по-късно. Накрая, добре е да се запитате какви събития записва вашият облачен доставчик, в какъв формат и колко отговарят на вашия процес на мониторинг на ИБ? Например, идентификация и аутентификация на потребители и гости. Системата Битрикс ви позволява да записвате данни за събития, включително дата и час на събитията, име на потребителя или госта (при наличието на модула „Уеб-аналитика“), обект, до който е осъществен достъп, и други типични елементи за уебсайтове. Но корпоративните служби по ИБ може да се нуждаят от информация за това дали потребителят е влизал в облака от доверено устройство (например, в корпоративната мрежа такава задача реализира Cisco ISE). А каква е простата задача, която предлага функцията за гео-IP, която може да помогне да се определи дали профилът на потребителя на облачната услуга е бил откраднат? И дори ако облачният доставчик ви я предостави, това ще е недостатъчно. Cisco CloudLock не само анализира геолокация, а използва машинно обучение и анализира историческите данни за всеки потребител, следейки различни аномалии в опитите за идентификация и аутентификация. Подобен функционал има само MS Azure (при наличието на съответния абонамент).

Има и още една трудност - тъй като мониторингът на информационната безопасност за много облачни доставчици е нова тема, с която едва започват да се занимават, те постоянно променят своите решения. Днес имат една версия на API, утре друга, а вдругиден трета. И за това също трябва да бъдете подготвени. Същото важи и за функционалността, която може да се променя и която трябва да се вземе предвид във вашата система за мониторинг на ИБ. Например, Amazon първоначално имаше отделни услуги за мониторинг на събития в облака - AWS CloudTrail и AWS CloudWatch. След това се появи отделна услуга за мониторинг на събития именно в ИБ - AWS GuardDuty. След известно време Amazon стартира нова система за управление Amazon Security Hub, която включва анализ на данни, получени от GuardDuty, Amazon Inspector, Amazon Macie и редица други. Друг пример е инструментът за интеграция на логове Azure с SIEM - AzLog. Много вендори SIEM активно го използваха, докато през 2018 г. Microsoft не обяви за прекратяване на неговото развитие и поддръжка, което постави много клиенти, които са използвали този инструмент, пред проблем (как решението беше намерено, ще обсъдим по-късно).

Затова внимателно следете всички функции за мониторинг, които ви предлага вашият облачен доставчик. Или се доверете на външни доставчици на решения, които ще действат като посредници между вашия SOC и облака, който искате да наблюдавате. Да, това ще бъде по-скъпо (макар и не винаги), но ще прехвърлите цялата отговорност на чужди рамена. Или не всичко? Вспомнете за концепцията за споделена безопасност и разберете, че нищо не можем да прехвърлим - ще трябва сами да се запознаем с това как различните облачни доставчици осигуряват мониторинг на ИБ за вашите данни, приложения, виртуални машини и други ресурси, разположени в облака. И ще започнем от това, което предлага Amazon в тази част.

Пример: Мониторинг на ИБ в IaaS на база AWS

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

Започваме с това, че Amazon не е недостъпна крепост. С клиентите му редовно се случват различни инциденти. Например, на Deep Root Analytics са откраднати имената, адресите, датите на раждане и телефоните на 198 милиона избиратели. На израелската компания Nice Systems са откраднати 14 милиона записи за абонати на Verizon. Въпреки това вградените възможности на AWS ви позволяват да откривате широк спектър от инциденти. Например:

влияние върху инфраструктурата (DDoS)
компрометиране на възел (инжектиране на команди)
компрометиране на акаунт и неоторизиран достъп
неправилна конфигурация и уязвимости
незащитени интерфейси и API.

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

За откриване на инциденти може да се използва широк спектър от различни мониторингови услуги, разработени от Amazon (въпреки че те често са допълнени с външни инструменти, като osquery). Така в AWS се проследяват всички действия на потребителите, независимо от начина, по който се извършват - през конзолата за управление, командния ред, SDK или други AWS услуги. Всички записи за действията на всяка AWS акаунт (включително името на потребителя, действието, услугата, параметрите на активността и нейния резултат) и използването на API са достъпни чрез услугата AWS CloudTrail. Можете да преглеждате тези събития (като влизане в конзолата AWS IAM) от конзолата CloudTrail, да ги анализирате с помощта на Amazon Athena или да ги предадете на външни решения, като Splunk, AlienVault и т.н. Самите логове на AWS CloudTrail се поставят в вашето хранилище AWS S3.

Два други AWS услуги предлагат още редица важни възможности за мониторинг. На първо място, Amazon CloudWatch е услуги за мониторинг на ресурсите и приложенията на AWS, който позволява сред много други да открива и различни аномалии в вашето облако. Всички вградени услуги на AWS, като Amazon Elastic Compute Cloud (сървъри), Amazon Relational Database Service (бази данни), Amazon Elastic MapReduce (анализ на данни) и още 30 други услуги на Amazon, използват Amazon CloudWatch за съхранение на своите логове. Разработчиците могат да използват отворения API на Amazon CloudWatch, за да добавят функция за мониторинг на логовете в потребителските приложения и услуги, което позволява разширяване на спектъра на анализираните събития в контекста на ИБ.

На второ място, услугата VPC Flow Logs позволява анализ на мрежовия трафик, изпратен или получен от вашите AWS сървъри (отвън или отвътре), а също така между микросервизи. Когато някой от вашите ресурси AWS VPC взаимодейства с мрежата, услугата VPC Flow Logs записва информация за мрежовия трафик, включително мрежовия интерфейс на източника и целта, както и IP адресите, портовете, протокола, броя на байтовете и броя на пакетите, които сте наблюдавали. Тези, които имат опит с локалната мрежова безопасност, ще признаят това за аналог на потоките. NetFlow, които могат да се създават от комутатори, маршрутизатори и защитни стени на корпоративно ниво. Тези журнали са важни за мониторинг на ИБ, защото за разлика от събитията за действия на потребители и приложения, не позволяват да пропуснете и мрежовото взаимодействие в виртуалната частна облачна среда AWS.

Така че тези три услуги на AWS — AWS CloudTrail, Amazon CloudWatch и VPC Flow Logs — заедно осигуряват достатъчно ефективно представление за използването на вашия акаунт, поведението на потребителите, управлението на инфраструктурата, активността на приложенията и услугите, както и мрежовата активност. Например, с тях можете да откриете следните аномалии:

Опити за сканиране на сайта, търсене на бекдора, търсене на уязвимости чрез изблици на “грешки 404”.
Инжекционни атаки (например, SQL injection) чрез изблици на “грешки 500”.
Известни инструменти за атаки sqlmap, nikto, w3af, nmap и т.н. чрез анализ на полето User Agent.

Amazon Web Services разработи и други услуги за киберсигурност, които позволяват решаване на много допълнителни задачи. Например, в AWS има вградено средство за одит на политики и конфигурации — AWS Config. Тази услуга осигурява непрекъснат одит на вашите AWS ресурси и техните конфигурации. Нека разгледаме прост пример: предположете, че искате да се уверите, че паролите на потребителите са деактивирани на всички ваши сървъри и достъпът е възможен само на база сертификати. AWS Config позволява лесна проверка за всичките ви сървъри. Има и други политики, които могат да бъдат приложени към вашите облачни сървъри: „Никой сървър не може да използва порт 22“, „Само администраторите могат да променят правилата на защитната стена“ или „Само потребителят Ивашко може да създава нови потребителски акаунти, и той може да го прави само в вторниците“. През лятото на 2016 година услугата AWS Config беше разширена, за да автоматизира откритията на нарушения на разработените политики. AWS Config Rules представляват непрекъснати заявки за конфигурация на използваните от вас услуги на Amazon, които генерират събития при нарушения на съответните политики. Например, вместо да извършвате периодични заявки чрез AWS Config, за да проверите дали всички дискове на виртуалния сървър са криптирани, можете да използвате AWS Config Rules за постоянно наблюдение на дисковете на сървъра, за да осигурите изпълнението на това условие. И, което е най-важно в контекста на тази публикация, всяко нарушение генерира събития, които могат да бъдат анализирани от вашето ИБ звено.

AWS предлага и свои еквиваленти на традиционните корпоративни решения за ИБ, които също генерират събития за сигурност, които можете и трябва да анализирате:

детекция на прониквания — AWS GuardDuty
контрол на изтичането на информация — AWS Macie
EDR (въпреки че е малко странно да говорим за крайни устройства в облака) — AWS Cloudwatch + решения с отворен код osquery или GRR
анализ на Netflow — AWS Cloudwatch + AWS VPC Flow
анализ на DNS — AWS Cloudwatch + AWS Route53
AD — AWS Directory Service
управление на акаунти — AWS IAM
SSO — AWS SSO
анализ на сигурността — AWS Inspector
управление на конфигурации — AWS Config
WAF — AWS WAF.

Няма да описвам подробно всички услуги на Amazon, които могат да бъдат полезни в контекста на информационната безопасност. Най-важното е да се разбере, че всички те могат да генерират събития, които можем и трябва да анализираме в контекста на ИБ, използвайки както вградените възможности на само Amazon, така и външни решения, например SIEM, които могат да събират събития за сигурност в вашия мониторингов център и да ги анализират там наравно с события от други облачни услуги или от вътрешната инфраструктура, периметъра или мобилни устройства.

Във всеки случай всичко започва от източниците на данни, които ви предоставят събития за ИБ. Към тези източници могат да се отнесат, наред с другите:

CloudTrail — използване на API и действия на потребителите
Trusted Advisor — проверка на сигурността за съответствие с добри практики
Config — инвентаризация и конфигурация на сметки и настройки на услуги
VPC Flow Logs — свързвания с виртуални интерфейси
IAM — услуга за идентификация и аутентификация
ELB Access Logs — логове за натоварване
Inspector — уязвимости в приложенията
S3 — файлово хранилище
CloudWatch — активност на приложенията
SNS — услуга за известия.

Amazon, предлагаща такъв спектър от източници на събития и инструменти за тяхното генериране, е силно ограничена в възможностите си за анализ на събраните данни в контекста на ИБ. Ще трябва сами да проучвате наличните логове, търсейки в тях съответните индикатори за компрометиране. AWS Security Hub, който Amazon наскоро стартира, е предназначен да реши този проблем, като функционира като облачно SIEM за AWS. Но засега той е само в началото на пътя си и е ограничен както от броя на източниците, с които работи, така и от други ограничения, наложени от архитектурата и абонаментите на самия Amazon.

Пример: Мониторинг на ИБ в IaaS на база Azure

Не желая вступать в долгую полемику о том, какой из трех облачных провайдеров (Amazon, Microsoft или Google) лучше (особенно поскольку каждый из них имеет свою специфику и подходит для решения определенных задач), давайте сосредоточимся на возможностях мониторинга информационной безопасности, которые предоставляют эти компании. Нужно признать, что Amazon AWS был одним из первых в этом сегменте и поэтому добился наибольшего прогресса в области функций информационной безопасности (хоть многие и считают, что их использование довольно сложно). Однако это не означает, что мы проигнорируем возможности, которые предоставляют нам Microsoft и Google.

Продукция Microsoft всегда отличалась своей «открытостью», и в Azure ситуация аналогичная. Например, если AWS и GCP всегда исходят из концепции «всё, что не разрешено, запрещено», то у Azure подход прямо противоположный. Создавая виртуальную сеть в облаке и виртуальную машину в ней, все порты и протоколы по умолчанию открыты и разрешены. Поэтому вам придется потратить немного больше усилий на первоначальную настройку системы разграничения доступа в облаке от Microsoft. Это также накладывает более строгие требования к мониторингу активности в облаке Azure.

AWS има особеност, свързана с това, че когато следите своите виртуални ресурси, ако те са в различни региони, възникват трудности при обединяването на всички събития и тяхния единен анализ. За да разрешите това, трябва да прибегнете до различни трикове, като например създаване на собствен код за AWS Lambda, който ще прехвърля събития между регионите. В Azure такъв проблем няма — неговият механизъм Activity Log проследява цялата активност в рамките на цялата организация без ограничения. Същото важи и за AWS Security Hub, който беше наскоро разработен от Amazon за консолидация на много функции за сигурност в единен център за сигурност, но само в рамките на своя регион, което, обаче, за Русия не е актуално. В Azure има собствен Security Center, който не е свързан с регионални ограничения, предоставяйки достъп до всички функции за сигурност на облачната платформа. Освен това, за различни локални екипи, той може да предостави свой набор от защитни възможности, включително и управлявани от тях събития за сигурност. AWS Security Hub все още цели да стане подобен на Azure Security Center. Но трябва да добавим и лъжичка катран — можете да извлечете много от функциите, описани по-рано в AWS през Azure, но най-удобно това се прави само за Azure AD, Azure Monitor и Azure Security Center. Всички останали защитни механизми на Azure, включително анализа на събития за сигурност, все още не се управляват по най-удобния начин. Отчасти проблемът се решава с API, който прониза всички услуги на Microsoft Azure, но това ще изисква от вас допълнителни усилия за интеграция на вашето облако с вашия SOC и наличието на квалифицирани специалисти (както и с всяка друга SIEM, работеща с облачни API). Някои SIEM, за които ще става въпрос по-нататък, вече поддържат Azure и могат да автоматизират задачата за неговото наблюдение, но и с тях има свои трудности — не всички могат да вземат всички логове, които има в Azure.

Събирането на събития и тяхното наблюдение в Azure се осъществява чрез услугата Azure Monitor, която е основният инструмент за събиране, съхранение и анализ на данни в облака на Microsoft и неговите ресурси — Git хранилища, контейнери, виртуални машини, приложения и др. Всички данни, събирани от Azure Monitor, се делят на две категории — метрики, събирани в реално време и описващи ключовите показатели за работа на облака Azure, и регистрационни журнали, съдържащи данни, организирани в записи, които характеризират различни аспекти на дейността на ресурсите и услугите в Azure. Освен това, с помощта на Data Collector API, услугата Azure Monitor може да събира данни от всяко REST източник за изграждане на собствени сценарии за мониторинг.

Ето няколко източника на събития за сигурност, които Azure предлага и до които можете да получите достъп чрез Azure Portal, CLI, PowerShell или REST API (а някои само чрез Azure Monitor / Insight API):

Activity Logs — този журнал отговаря на класическите въпроси “кой”, “какво” и “кога” относно всяка операция на запис (PUT, POST, DELETE) върху облачни ресурси. Събития, свързани с достъп до четене (GET), не попадат в този журнал, както и редица други.
Diagnostic Logs — съдържа данни по операциите с даден ресурс, включен в абонамента ви.
Azure AD reporting — съдържа както активността на потребителите, така и системната активност, свързана с управлението на групи и потребители.
Windows Event Log и Linux Syslog — съдържа събития от виртуални машини, хоствани в облака.
Metrics — съдържа телеметрия относно състоянието на производителността и “здравето” на вашите облачни услуги и ресурси. Измерват се всяка минута и се съхраняват в продължение на 30 дни.
Network Security Group Flow Logs — съдържа данни за мрежовите събития за сигурност, събирани чрез услугата Network Watcher и мониторинга на ресурсите на мрежово ниво.
Storage Logs — съдържа събития, свързани с достъпа до хранилищата.

За мониторинг можете да използвате външни SIEM решения или вградения Azure Monitor и неговите разширения. Ще поговорим по-подробно за системите за управление на ИТ инциденти, а сега нека видим какво предлага самият Azure за анализ на данни в контекста на сигурността. Основният екран за всичко, свързано със сигурността в Azure Monitor, е Log Analytics Security and Audit Dashboard (безплатната версия поддържа съхранение на ограничено количество събития само за една седмица). Тази панел е разделена на 5 основни области, визуализиращи обобщена статистика относно това, което се случва в облачната ви среда:

Security Domains — ключови количествени показатели, свързани със сигурността на ИТ — брой инциденти, брой компрометирани възли, непатчнати възли, събития за мрежова сигурност и т.н.
Notable Issues — показва броя и важността на активните проблеми със сигурността на ИТ
Detections — показва шаблони на атаките, използвани срещу вас
Threat Intelligence — показва географската информация за външни възли, които нападат вас
Common security queries — типични запитвания, които ще ви помогнат по-добре да наблюдавате вашата ИТ сигурност.

Като разширения на Azure Monitor можем да споменем Azure Key Vault (защита на криптографските ключове в облака), Malware Assessment (анализ на защитата от злонамерен софтуер на виртуални машини), Azure Application Gateway Analytics (анализ, между другото, на логовете на облачния междинен защитник) и т.н. Тези инструменти, обогатени с определени правила за обработка на събития, позволяват визуализиране на различни аспекти на дейността на облачните услуги, включително и сигурността, и откриване на отклонения от работата. Но, както често се случва, всяка допълнителна функционалност изисква съответна платена абонаментна услуга, което изисква от вас да планирате съответстващи финансови инвестиции предварително.

Azure предлага множество вградени функции за мониторинг на заплахи, които са интегрирани в Azure AD, Azure Monitor и Azure Security Center. Сред тях се включват например откритие на взаимодействия на виртуални машини с известни злонамерени IP адреси (чрез интеграция със службите за анализ на заплахи на Microsoft), откритие на злонамерен софтуер в облачната инфраструктура чрез получаване на сигнали за тревога от виртуални машини, разположени в облака, атаки тип "подбор на парола" на виртуални машини, уязвимости в конфигурацията на системата за идентификация на потребителите, вход от анонимизатори или заразени възли, изтичане на акаунти и вход от необичайни местоположения и т.н. Azure днес е един от малкото облачни доставчици, които предлагат вградени възможности за анализ на заплахи за обогатяване на събраните събития за информационна безопасност.

Както бе споменато по-горе, защитната функционалност и съответно генерираните от нея събития за сигурност не са достъпни за всички потребители в равна степен и изискват наличието на определена абонаментна услуга, която включва необходимата функционалност, генерираща съответните събития за мониторинг на информационната безопасност. Например, част от описаните в предишния абзац функции за мониторинг на аномалии в акаунтите са достъпни само с премиум лиценза P2 за услугата Azure AD. Без него, както и в случая с AWS, ще е необходимо да анализирате събраните събития за сигурност "ръчно". И, също така, в зависимост от типа лиценз на Azure AD, не всички събития ще бъдат налични за анализ.

На портала Azure можете да управлявате както търсенията към интересуващите ви регистърни журнални записи, така и да конфигурирате табла за визуализация на ключовите показатели за безопасност. Освен това, там можете да избирате разширения за Azure Monitor, които ще ви позволят да разширите функционалността на логовете на Azure Monitor и да получите по-дълбок анализ на събитията от гледна точка на сигурността.

Ако ви е необходима не само възможност за работа с логове, но и цялостен център за сигурност на вашата облачна платформа Azure, включително управление на политики за информационна безопасност, тогава можете да говорите за необходимостта от работа с Azure Security Center, повечето полезни функции на което са достъпни за отделна такса, например, откриване на заплахи, мониторинг извън Azure, оценка на съответствието и т.н. (в безплатната версия имате достъп само до оценка на безопасността и препоръки за отстраняване на идентифицирани проблеми). Той консолидира всички въпроси на сигурността на едно място. По същество може да се каже, че предоставя по-високо ниво на информационна безопасност, отколкото Azure Monitor, тъй като в този случай събраните данни от цялата ви облачна платформа се обогатяват с множество източници, като Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) и Microsoft Security Response Center (MSRC), върху които се налагат различни сложни алгоритми за машинно обучение и поведенческа аналитика, което в крайна сметка трябва да повиши ефективността на откриването на заплахи и реакцията на тях.

Azure има и свой SIEM — той се появи в началото на 2019 година. Това е Azure Sentinel, който се основава на данни от Azure Monitor и може също да интегрира външни решения за сигурност (например, NGFW или WAF), списъкът на които постоянно се допълва. Освен това, чрез интеграцията на Microsoft Graph Security API имате възможност да свържете свои собствени потоци за Threat Intelligence към Sentinel, което обогатява възможностите за анализ на инциденти във вашето облако Azure. Може да се твърди, че Azure Sentinel е първият „роден“ SIEM, който се появи при облачните доставчици (същите Splunk или ELK, които могат да бъдат разположени в облака, например, AWS, всъщност са разработени не от доставчици на традиционни облачни услуги). Azure Sentinel и Security Center могат да бъдат наречени SOC за облака Azure и може да се ограничи до тях (с определени уговорки), ако нямате друга инфраструктура и всичките си изчислителни ресурси сте преместили в облака, а това е облак Microsoft Azure.

Но тъй като вградените възможности на Azure (дори при наличието на абонамент за Sentinel) често не са достатъчни за мониторинг на информационната сигурност и интегриране на този процес с други източници на събития за сигурност (както облачни, така и вътрешни), възниква необходимостта от експортиране на събраните данни във външни системи, сред които може да бъде и SIEM. Това може да стане както чрез API, така и с помощта на специални разширения, които в момента официално са налични само при следните SIEM — Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight и ELK. Още преди, имаше повече такива SIEM, но от 1 юни 2019 година Microsoft спря поддръжката на Azure Log Integration Tool (AzLog), който в началото на съществуването на Azure и при отсъствието на нормализиране на работата с логовете (Azure Monitor дори все още не съществуваше) позволи лесна интеграция на външни SIEM с облака на Microsoft. Сега ситуацията се е променила и Microsoft препоръчва платформата Azure Event Hub, като основен инструмент за интеграция за останалите SIEM. Много вече са осъществили такава интеграция, но внимавайте — те може да не улавят всички логове на Azure, а само някои (проверете документацията на вашето SIEM).

Завършвайки краткия преглед на Azure, искам да дам обща препоръка относно този облачен сервис – преди да твърдите нещо относно функциите за мониторинг на ИБ в Azure, е важно да ги настройте много внимателно и да тествате дали работят според документацията и как ви бяха описани от консултантите на Microsoft (които може да имат различни мнения относно функционирането на функциите на Azure). При наличието на финансови възможности, Azure може да предостави много полезна информация относно мониторинга на ИБ. Ако ресурсите ви са ограничени, както в случая с AWS, ще трябва да разчитате само на собствените си способности и на суровите данни, които Azure Monitor предоставя. Не забравяйте, че много от функциите за мониторинг са платени и е по-добре да се запознаете с ценовата политика предварително. Например, безплатно можете да съхранявате данни за 31 дни с обем не повече от 5 Гб на клиент — превишаването на тези стойности ще изисква допълнителни разходи (около 2+ долара за съхранение на всеки допълнителен Гб за клиента и 0.1 долара за съхранение на 1 Гб всеки допълнителен месец). Работата с телеметрия на приложения и метрики също може да изисква допълнителни финансови средства, както и работата с аларми и уведомления (безплатно е наличен определен лимит, който може да не е достатъчен за вашите нужди).

Пример: Мониторинг на ИБ в IaaS на базата на Google Cloud Platform

Google Cloud Platform на фона на AWS и Azure изглежда съвсем млад, но това отчасти е добре. За разлика от AWS, който постепенно увеличаваше своите възможности, включително и защитните, с проблеми с централизацията; GCP, подобно на Azure, е много по-добре централизирано управляван, което намалява броя на грешките и времето за внедряване в предприятието. От гледна точка на сигурността, GCP е, странно, между AWS и Azure. Той също така разполага с единна регистрация на събития за цялата организация, но тя не е пълна. Някои функции все още са в бета-режим, но постепенно този недостатък трябва да бъде отстранен, и GCP ще стане по-зряла платформа от гледна точка на мониторинга на ИБ.

Основният инструмент за регистриране на събития в GCP е Stackdriver Logging (аналога на Azure Monitor), който ви позволява да събирате събития от цялата ваша облачна инфраструктура (включително от AWS). От гледна точка на сигурността в GCP всяка организация, проект или папка притежава четири регистрационни дневника:

Admin Activity — съдържа всички събития, свързани с административен достъп, например създаване на виртуална машина, промяна на права за достъп и др. Този дневник се записва винаги, независимо от желанието ви, и съхранява данните си в продължение на 400 дни.
Data Access — съдържа всички събития, свързани с работата с данни от облачни потребители (създаване, промяна, четене и др.). По подразбиране този дневник не се записва, тъй като обемът му бързо нараства. Поради тази причина срокът на съхранение е само 30 дни. Освен това, в този дневник не се записват събития, свързани с публично достъпни ресурси за всички потребители или такива, които са налични без вход в GCP.
System Event — съдържа системни събития, които не са свързани с потребители, или дейности на администратор, който променя конфигурации на облачни ресурси. Записва се винаги и се съхранява в продължение на 400 дни.
Access Transparency — това е уникален пример на регистрационен дневник, който записва всички действия на служители на Google (но все още не за всички услуги на GCP), които имат достъп до вашата инфраструктура в процеса на изпълнение на служебните си задължения. Този дневник се съхранява 400 дни и не е достъпен за всеки клиент на GCP, а само при изпълнение на определени условия (или поддръжка на ниво Gold или Platinum, или наличие на 4 роли от определен тип в рамките на корпоративната поддръжка). Подобна функция има и в Office 365 — Lockbox.

Пример за дневник: Access Transparency

{
 insertId: "abcdefg12345"
 jsonPayload: {
 @type: "type.googleapis.com/google.cloud.audit.TransparencyLog"
 location: {
 principalOfficeCountry: "САЩ"
 principalEmployingEntity: "Google LLC"
 principalPhysicalLocationCountry: "Канада"
 }
 product: [
 0: "Cloud Storage"
 ]
 reason: [
 detail: "Номер на случая: bar123"
 type: "CUSTOMER_INITIATED_SUPPORT"
 ]
 accesses: [
 0: {
 methodName: "GoogleInternal.Read"
 resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
 }
 ]
 }
 logName: "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.comaccess_transparency"
 operation: {
 id: "12345xyz"
 }
 receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
 resource: {
 labels: {
 project_id: "1234567890"
 }
 type: "project"
 }
 severity: "NOTICE"
 timestamp: "2017-12-18T16:06:24.660001Z"
}

Достъпът до посочените логове може да се осъществи по различни начини (приблизително както и при споменатите Azure и AWS) — чрез интерфейса Log Viewer, чрез API, чрез Google Cloud SDK или чрез страницата Activity на проекта ви, който ви интересува. По същия начин те могат да се експортират в външни решения за допълнителен анализ. Последното става чрез експортиране на логовете в хранилището BigQuery или Cloud Pub/Sub.

Освен Stackdriver Logging, платформата GCP предлага и функционалността Stackdriver Monitoring, която позволява проследяване на ключови метрики (производителност, време до отказ, общо състояние и др.) на облачните услуги и приложения. Данните, обработени по специален начин и визуализирани, могат да улеснят търсенето на проблеми в облачната ви инфраструктура, включително в контекста на сигурността. Но трябва да се отбележи, че тази функционалност ще бъде ограничена именно в контекста на информационната безопасност, тъй като в момента GCP няма аналог на AWS GuardDuty и не може да идентифицира сред всички регистрирани събития точно лошите (Google разработи Event Threat Detection, но той все още е в бета версия и е твърде рано да се говори за полезността му). Stackdriver Monitoring би могло да се използва като система за откриване на аномалии, които след това ще се разследват за установяване на причините за тяхното възникване. Но при условия на недостиг на квалифициран персонал в областта на информационната безопасност на GCP, тази задача в момента изглежда сложна.

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

Cloud Security Command Center — аналог на AWS Security Hub и Azure Security Center.
Cloud DLP — автоматично откриване и редактиране (напр. маскиране) на данни, разположени в облака, спрямо повече от 90 предварително зададени политики за класификация.
Cloud Scanner — скенер за известни уязвимости (XSS, Flash Injection, непатчирани библиотеки и т.н.) в App Engine, Compute Engine и Google Kubernetes.
Cloud IAM — управление на достъпа до всички ресурси на GCP.
Cloud Identity — управление на профилите на потребителите, устройствата и приложенията на GCP от единство конзола.
Cloud HSM — защита на криптографските ключове.
Cloud Key Management Service — управление на криптографските ключове в GCP.
VPC Service Control — създаване на защитена зона около вашите ресурси на GCP за защита от изтичания.
Titan Security Key — защита от фишинг.

Много от тези модули генерират събития за сигурност, които могат да бъдат изпратени в хранилище BigQuery за анализ или износ в други системи, включително SIEM. Както вече беше споменато, GCP — активно развиваща се платформа и в момента Google разработва редица нови модули за ИБ за своята платформа. Сред тях е Event Threat Detection (в момента наличен в бета версия), който сканира логовете на Stackdriver за следи от несанкционирана активност (аналог на GuardDuty в AWS), или Policy Intelligence (наличен в алфа версия), който ще позволи разработването на интелигентни политики за достъп до ресурсите на GCP.

Направих малък преглед на вградените възможности за мониторинг в популярните облачни платформи. Но имате ли специалисти, способни да работят с 'суровите' логове на IaaS доставчика (не всички са готови да купуват разширени функции на AWS, Azure или Google)? Освен това, много хора знаят пословицата “доверявай, но проверявай”, която в областта на сигурността е актуална както никога. Колко доверие имате в вградените функции на облачния доставчик, които ви предоставят събития за ИБ? Насколько те изобщо се фокусират на ИБ?

Понякога е добре да се обърнете към наложени решения за мониторинг на облачни инфраструктури, които могат да допълнят вградената сигурност на облака; понякога такива решения са единственият вариант да получите данни за сигурността на вашите данни и приложения, хоствани в облака. Освен това, те са просто по-удобни, тъй като поемат всички задачи по анализиране на необходимите логове, генерирани от различни облачни услуги на различни облачни доставчици. Като пример за такова наложено решение можем да приведем Cisco Stealthwatch Cloud, който е съсредоточен върху единствената задача – мониторинг на аномалии в информационната сигурност в облачни среди, сред които не само Amazon AWS, Microsoft Azure и Google Cloud Platform, но и частни облаци.

Пример: Мониторинг на информационната сигурност с помощта на Stealthwatch Cloud

AWS предоставя гъвкава платформа за изчисления, но тази гъвкавост води до факта, че компаниите често допускат грешки, които водят до проблеми със сигурността. И споделеният модел на информационната сигурност само допринася за това. Пускането на облака на софтуер с неизвестни уязвимости (с известни може да се бори, например, AWS Inspector или GCP Cloud Scanner), слаби пароли, некоректни конфигурации, инсайдери и т.н. И всичко това се отразява на поведението на облачните ресурси, които Cisco Stealthwatch Cloud може да наблюдава, представлявайки система за мониторинг на информационната сигурност и откриване на атаки в публични и частни облаци.

Една от основните характеристики на Cisco Stealthwatch Cloud е възможността за моделиране на обекти. С негова помощ можете да създадете софтуерна модел (тоест симулация почти в реално време) на всеки от вашите облачни ресурси (независимо дали става дума за AWS, Azure, GCP или нещо друго). Те могат да включват сървъри и потребители, както и ресурси, специфични за вашата облачна среда, като групи за сигурност и групи за автоматично мащабиране на услуги (auto-scale). Тези модели използват като входни данни структурирани потоци от данни, предоставени от облачните услуги. Например, за AWS това ще бъдат VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda и AWS IAM. Моделирането на обекти автоматично открива роля и поведение на всеки от вашите ресурси (може да се говори за профилиране на цялата облачна активност). Сред тези роли са мобилно устройство Android или Apple, сървър Citrix PVS, RDP-сървър, пощенски шлюз, VoIP клиент, терминален сървър, контролер на домейни и т.н. След това той непрекъснато следи тяхното поведение, за да определи кога настъпва рисковано или заплашително поведение за сигурността. Можете да идентифицирате подбране на пароли, DDoS атаки, изтичане на данни, незаконен отдалечен достъп, действия на зловреден софтуер, сканиране на уязвимости и други заплахи. Например, ето как изглежда откритие на опит за отдалечен достъп от нетипична за вашата организация страна (Южна Корея) към Kubernetes клъстер по SSH:

А ето как изглежда предполагаемото изтичане на информация от базата данни Postgress в страна, с която взаимодействието преди не е било срещано:

Накрая, ето как изглежда твърде голямо количество неуспешни опити за достъп по SSH от Китай и Индонезия от външно отдалечено устройство:

Или, да предположим, че инстанция на сървъра в VPC, според политиката, никога не трябва да бъде цел за дистанционен достъп до системата. Предположим още, че на този компютър е проведен дистанционен достъп в резултат на грешно изменение на политиката на правилата на защитната стена. Функцията за моделиране на обекти ще открива и съобщава за тази активност ("Необичаен дистанционен достъп") в почти реално време и ще посочва конкретен API извикване от AWS CloudTrail, Azure Monitor или GCP Stackdriver Logging (включително потребителско име, дата и час, сред други детайли), които са предизвикали изменения в правилата на МСЕ. И след това тази информация може да бъде предоставена на SIEM за анализ.

Подобни възможности се реализират за всяка облачна среда, поддържана от Cisco Stealthwatch Cloud:

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

Някой е открил бекдор в софтуера, който използваме?
Има ли какъвто и да е софтуер или устройство от трета страна в нашето облако?
Злоупотребява ли упълномощен потребител с привилегиите си?
Била ли е допусната грешка в конфигурацията, която позволява дистанционен достъп или друго непреднамерено използване на ресурсите?
Има ли изтичане на данни от нашите сървъри?
Опитвал ли се е някой да се свърже с нас от нетипично географско място?
Не е ли нашето облако заразено с вредоносен код?

Обнаруженото събитие ИБ може да бъде предадено под формата на съответния тикет в Slack, Cisco Spark, системата за управление на инциденти PagerDuty, както и предоставено на различни SIEM, сред които Splunk или ELK. В обобщение, ако вашата компания използва стратегия за многооблачност и не се ограничава до един облачен доставчик, възможностите за мониторинг на ИБ, описани по-горе, показват, че използването на Cisco Stealthwatch Cloud е добро решение за получаване на унифициран набор от възможности за мониторинг на водещите облачни играчи — Amazon, Microsoft и Google. Най-интересното е, че ако сравните цените на Stealthwatch Cloud с разширените лицензи за мониторинг на ИБ в AWS, Azure или GCP, може да се окаже, че решението на Cisco е дори по-евтино от вградените възможности на решенията на Amazon, Microsoft и Google. Парадоксално, но е вярно. И колкото повече облаци и техни възможности използвате, толкова по-очевидно ще бъде предимството на консолидираното решение.

Освен това, Stealthwatch Cloud може да мониторира и частни облаци, внедрени във вашата организация, например базирани на контейнери Kubernetes или чрез мониторинг на потоците Netflow или мрежовия трафик, получен чрез набиране в мрежовото оборудване (дори с местно производство), данни от AD или DNS-сервери и т.н. Всички тези данни ще бъдат обогатени с информация за заплахи, събирана от подразделението Cisco Talos, което е най-голямата в света неправителствена група изследователи на заплахи ИБ.

Това ви позволява да реализирате единна система за мониторинг както на публични, така и на хибридни облаци, които вашата компания може да използва. Събраната информация може след това да бъде анализирана с вградените възможности на Stealthwatch Cloud или изпратена в вашия SIEM (по подразбиране се поддържат Splunk, ELK, SumoLogic и редица други).

С това завършваме първата част от статията, в която разгледах вградени и външни средства за мониторинг на ИТ сигурността на IaaS/PaaS платформи, които ни позволяват бързо да откриваме и реагираме на инциденти, настъпващи в облачни среди, избрани от нашето предприятие. Във втората част ще продължим темата и ще разгледаме възможностите за мониторинг на SaaS платформи, използвайки примери от Salesforce и Dropbox, а също така ще се опитаме да обобщим и обединим всичко, създавайки единна система за мониторинг на ИТ сигурността на различни облачни доставчици.

Източник: habr.com