Облачно наблюдение на сигурността

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

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

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

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

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

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

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

Жизнен цикъл на наблюдение на сигурността в облака

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

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

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

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

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

Вградени облачни услуги

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

Като цяло, по начина, по който доставчикът на облак описва проблемите със сигурността на информацията на своя уебсайт и в своята документация, можете да разберете колко сериозно той приема този проблем. Например, ако прочетете ръководствата за продуктите „Моят офис“, изобщо няма дума за сигурност, но в документацията за отделния продукт „Моят офис. KS3”, предназначен за защита срещу неоторизиран достъп, има обичаен списък с точки от 17-ти ред на FSTEC, които „My Office.KS3” прилага, но не е описано как го прилага и най-важното как да интегрирайте тези механизми с корпоративната информационна сигурност. Може би такава документация съществува, но не я намерих в публичното пространство на уебсайта „Моят офис“. Въпреки че може би просто нямам достъп до тази секретна информация?..

За Bitrix ситуацията е много по-добра. Документацията описва форматите на регистрационните файлове на събитията и, което е интересно, логът за проникване, който съдържа събития, свързани с потенциални заплахи за облачната платформа. Оттам можете да извадите IP, име на потребител или гост, източник на събитие, време, потребителски агент, тип събитие и т.н. Вярно е, че можете да работите с тези събития или от контролния панел на самия облак, или да качвате данни във формат MS Excel. Сега е трудно да се автоматизира работата с регистрационните файлове на Bitrix и ще трябва да извършите част от работата ръчно (качване на отчета и зареждането му във вашия SIEM). Но ако си спомним, че до сравнително скоро такава възможност не съществуваше, то това е голям напредък. В същото време бих искал да отбележа, че много чуждестранни доставчици на облак предлагат подобна функционалност „за начинаещи“ - или погледнете регистрационните файлове с очите си през контролния панел, или качете данните в себе си (обаче повечето качват данни в . csv формат, а не Excel).

Без да обмислят опцията без регистрация, облачните доставчици обикновено ви предлагат три опции за наблюдение на събитията по сигурността – табла за управление, качване на данни и достъп до API. Първото изглежда решава много проблеми за вас, но това не е съвсем вярно - ако имате няколко списания, трябва да превключвате между екраните, които ги показват, губейки цялостната картина. Освен това е малко вероятно доставчикът на облака да ви предостави възможността да свързвате събитията за сигурност и като цяло да ги анализирате от гледна точка на сигурността (обикновено имате работа със сурови данни, които трябва да разберете сами). Има изключения и ще говорим за тях по-нататък. И накрая, струва си да попитате какви събития се записват от вашия доставчик на облак, в какъв формат и как те съответстват на вашия процес на наблюдение на информационната сигурност? Например идентификация и удостоверяване на потребители и гости. Същият Bitrix ви позволява, въз основа на тези събития, да записвате датата и часа на събитието, името на потребителя или госта (ако имате модула „Уеб анализи“), обекта, до който имате достъп и други елементи, характерни за уебсайт . Но услугите за корпоративна информационна сигурност може да се нуждаят от информация дали потребителят е имал достъп до облака от надеждно устройство (например в корпоративна мрежа тази задача се изпълнява от 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 не е най-добрият пример поради факта, че това е американска услуга и може да бъде блокирана като част от борбата срещу екстремизма и разпространението на информация, забранена в Русия. Но в тази публикация просто бих искал да покажа как различните облачни платформи се различават по своите възможности за наблюдение на информационната сигурност и на какво трябва да обърнете внимание, когато прехвърляте ключовите си процеси в облаците от гледна точка на сигурността. Е, ако някои от руските разработчици на облачни решения научат нещо полезно за себе си, тогава това ще бъде страхотно.

Първото нещо, което трябва да кажем е, че Амазонка не е непробиваема крепост. На клиентите му редовно се случват различни инциденти. Например имената, адресите, датите на раждане и телефонните номера на 198 милиона избиратели бяха откраднати от Deep Root Analytics. Израелската компания 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 инжектиране) чрез изблици на „500 грешки“.
• Известни инструменти за атака са sqlmap, nikto, w3af, nmap и др. чрез анализ на полето User Agent.

Amazon Web Services разработи и други услуги за целите на киберсигурността, които ви позволяват да решавате много други проблеми. Например AWS има вградена услуга за одит на политики и конфигурации - AWS Config. Тази услуга осигурява непрекъснат одит на вашите AWS ресурси и техните конфигурации. Да вземем един прост пример: Да кажем, че искате да сте сигурни, че потребителските пароли са деактивирани на всичките ви сървъри и че достъпът е възможен само въз основа на сертификати. AWS Config улеснява проверката на това за всички ваши сървъри. Има други политики, които могат да бъдат приложени към вашите облачни сървъри: „Нито един сървър не може да използва порт 22“, „Само администраторите могат да променят правилата на защитната стена“ или „Само потребител Ивашко може да създава нови потребителски акаунти и той може да го прави. Това е само във вторник. " През лятото на 2016 г. услугата AWS Config беше разширена, за да автоматизира откриването на нарушения на разработените политики. Правилата за конфигурация на AWS са по същество непрекъснати заявки за конфигурация за услугите на 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 и потребителски действия
• Доверен съветник - проверка на сигурността спрямо най-добрите практики
• Config - инвентаризация и конфигурация на акаунти и настройки на услугите
• VPC Flow Logs - връзки към виртуални интерфейси
• IAM - услуга за идентификация и автентикация
• Регистрационни файлове за достъп до ELB - Балансиране на натоварването
• Инспектор - уязвимости на приложението
• 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 няма този проблем - неговият механизъм за регистър на активността проследява цялата дейност в цялата организация без ограничения. Същото важи и за AWS Security Hub, който наскоро беше разработен от Amazon, за да консолидира много функции за сигурност в рамките на един център за сигурност, но само в рамките на своя регион, който обаче не е от значение за Русия. Azure разполага със собствен център за сигурност, който не е обвързан с регионални ограничения, осигуряващ достъп до всички функции за сигурност на облачната платформа. Освен това, за различни местни екипи той може да предостави свой собствен набор от защитни възможности, включително събития за сигурност, управлявани от тях. AWS Security Hub все още е на път да стане подобен на Azure Security Center. Но си струва да добавите муха в мехлема - можете да изтръгнете от Azure много от описаното по-рано в AWS, но това се прави най-удобно само за 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. В допълнение, използвайки API за събиране на данни, услугата Azure Monitor може да събира данни от всеки REST източник, за да изгради свои собствени сценарии за наблюдение.

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

• Дневници на активността - този журнал отговаря на класическите въпроси „кой“, „какво“ и „кога“ по отношение на всяка операция за запис (PUT, POST, DELETE) в облачни ресурси. Събитията, свързани с достъпа за четене (GET), не са включени в този дневник, както редица други.
• Диагностични регистрационни файлове - съдържа данни за операциите с определен ресурс, включен във вашия абонамент.
• Отчитане на Azure AD - съдържа както потребителска дейност, така и системна дейност, свързана с управлението на групи и потребители.
• Windows Event Log и Linux Syslog - съдържа събития от виртуални машини, хоствани в облака.
• Метрики - съдържа телеметрия за производителността и здравословното състояние на вашите облачни услуги и ресурси. Измерва се всяка минута и се съхранява. в рамките на 30 дни.
• Журнали на потока на групата за мрежова сигурност - съдържа данни за събития за мрежова сигурност, събрани с помощта на услугата Network Watcher и мониторинг на ресурсите на мрежово ниво.
• Регистри за съхранение - съдържа събития, свързани с достъпа до съоръженията за съхранение.

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

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

Разширенията на 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 онлайн, 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, така и с помощта на специални разширения, които в момента са официално достъпни само за следните SIEMs - Splunk (Add-On за монитор на Azure за Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight и ELK. Доскоро имаше повече такива SIEM, но от 1 юни 2019 г. Microsoft спря да поддържа Azure Log Integration Tool (AzLog), който в зората на съществуването на Azure и при липса на нормална стандартизация на работата с регистрационни файлове (Azure Монитор дори все още не съществуваше) направи лесно интегрирането на външни SIEM с облака на Microsoft. Сега ситуацията се промени и Microsoft препоръчва платформата Azure Event Hub като основен инструмент за интеграция за други SIEM. Много вече са внедрили такава интеграция, но бъдете внимателни - те може да не уловят всички регистрационни файлове на Azure, а само някои (погледнете в документацията за вашия SIEM).

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

Пример: Мониторинг на информационната сигурност в 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 дни.
• Достъп до данни - съдържа всички събития, свързани с работа с данни от облачните потребители (създаване, промяна, четене и др.). По подразбиране този дневник не се записва, тъй като обемът му набъбва много бързо. Поради тази причина срокът му на годност е само 30 дни. Освен това не всичко се пише в това списание. Например събития, свързани с ресурси, които са публично достъпни за всички потребители или които са достъпни без влизане в GCP, не се записват в него.
• Системно събитие - съдържа системни събития, които не са свързани с потребители или действия на администратор, който променя конфигурацията на облачните ресурси. Винаги се записва и съхранява 400 дни.
• Access Transparency е уникален пример за регистрационен файл, който улавя всички действия на служители на Google (но все още не за всички GCP услуги), които имат достъп до вашата инфраструктура като част от служебните си задължения. Този дневник се съхранява 400 дни и не е достъпен за всеки GCP клиент, но само ако са изпълнени редица условия (или поддръжка на ниво Gold или Platinum, или наличие на 4 роли от определен тип като част от корпоративната поддръжка). Подобна функция също е налична, например, в Office 365 - Lockbox.

Пример за регистрационен файл: Прозрачност на достъпа

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: 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.com%2Faccess_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, която ви позволява да наблюдавате ключови показатели (производителност, MTBF, цялостно състояние и т.н.) на облачни услуги и приложения. Обработените и визуализирани данни могат да улеснят намирането на проблеми във вашата облачна инфраструктура, включително в контекста на сигурността. Но трябва да се отбележи, че тази функционалност няма да бъде много богата в контекста на информационната сигурност, тъй като днес 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 или нещо друго). Те могат да включват сървъри и потребители, както и типове ресурси, специфични за вашата облачна среда, като групи за сигурност и групи за автоматично мащабиране. Тези модели използват структурирани потоци от данни, предоставени от облачни услуги като вход. Например за 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 (включително потребителско име, дата и час, наред с други подробности ). което предизвика промяната в правилото на ITU. След това тази информация може да бъде изпратена до 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 сървъри и т.н. Всички тези данни ще бъдат обогатени с информация за Threat Intelligence, събрана от Cisco Talos, най-голямата в света неправителствена група от изследователи на заплахи за киберсигурността.

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

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

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