🥇Следење на безбедноста во облак

Преместувањето податоци и апликации во облакот претставува нов предизвик за корпоративните SOC, кои не се секогаш подготвени да следат туѓа инфраструктура. Според Netoskope, просечното претпријатие (очигледно во САД) користи 1246 различни облак услуги, што е за 22% повеќе од пред една година. 1246 облак услуги!!! Од нив 175 се однесуваат на услуги за човечки ресурси, 170 се однесуваат на маркетинг, 110 се од областа на комуникациите и 76 се за финансии и CRM. Cisco користи „само“ 700 надворешни облак услуги. Па малку сум збунет од бројкиве. Но, во секој случај, проблемот не е во нив, туку во фактот што облакот почнува да се користи доста активно од се поголем број компании кои би сакале да ги имаат истите можности за следење на облак инфраструктурата како во сопствената мрежа. И овој тренд расте - според според Американската сметководствена комора До 2023 година, 1200 центри за податоци ќе бидат затворени во Соединетите држави (6250 веќе се затворени). Но, преминот кон облакот не е само „да ги префрлиме нашите сервери на надворешен провајдер“. Нова ИТ архитектура, нов софтвер, нови процеси, нови ограничувања... Сето тоа носи значителни промени во работата не само на ИТ, туку и на информациската безбедност. И ако провајдерите научија некако да се справат со обезбедувањето на безбедноста на самиот облак (за среќа има многу препораки), тогаш со следењето на безбедноста на информациите во облакот, особено на платформите SaaS, има значителни тешкотии, за кои ќе зборуваме.

Да речеме дека вашата компанија преселила дел од својата инфраструктура во облакот... Стоп. Не на овој начин. Ако инфраструктурата е префрлена, а вие дури сега размислувате како ќе ја следите, тогаш веќе сте изгубиле. Освен ако не се Амазон, Гугл или Мајкрософт (а потоа со резервации), веројатно нема да имате голема способност да ги следите вашите податоци и апликации. Добро е ако ви се даде можност да работите со дневници. Понекогаш податоците за безбедносните настани ќе бидат достапни, но вие нема да имате пристап до нив. На пример, Office 365. Ако ја имате најевтината лиценца E1, тогаш безбедносните настани воопшто не ви се достапни. Ако имате лиценца Е3, вашите податоци се чуваат само 90 дена, а само ако имате лиценца Е5, времетраењето на дневниците е достапно една година (сепак, ова има и свои нијанси поврзани со потребата за одделно побарајте голем број функции за работа со дневници од поддршката на Microsoft). Патем, лиценцата E3 е многу послаба во однос на функциите за следење од корпоративната Exchange. За да го постигнете истото ниво, потребна ви е лиценца E5 или дополнителна лиценца за напредна усогласеност, за што може да бидат потребни дополнителни пари што не биле вклучени во вашиот финансиски модел за преместување во облак инфраструктура. И ова е само еден пример за потценување на прашањата поврзани со следењето на безбедноста на информациите во облакот. Во оваа статија, без да се преправам дека сум комплетен, сакам да привлечам внимание на некои нијанси што треба да се земат предвид при изборот на провајдер на облак од безбедносна гледна точка. И на крајот од статијата, ќе биде даден список за проверка што вреди да се пополни пред да се разгледа дека е решено прашањето за следење на безбедноста на информациите во облакот.

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

Безбедносните дневници не постојат. Ова е прилично честа ситуација, особено кај почетниците играчи на пазарот на облак решенија. Но, не треба веднаш да се откажете од нив. Малите играчи, особено домашните, се почувствителни на барањата на клиентите и можат брзо да имплементираат некои потребни функции со промена на одобрениот патоказ за нивните производи. Да, ова нема да биде аналог на GuardDuty од Amazon или модулот „Proactive Protection“ од 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“, но не е опишано како го спроведува и, што е најважно, како да интегрирајте ги овие механизми со корпоративната информациска безбедност. Можеби таква документација постои, но не ја најдов во јавен домен, на веб-страницата „Моја канцеларија“. Иако можеби едноставно немам пристап до овие тајни информации? ..

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

Без да се земе предвид опцијата без логови, провајдерите на облак обично ви нудат три опции за следење на безбедносните настани - контролни табли, поставување податоци и пристап до API. Се чини дека првото ви решава многу проблеми, но тоа не е сосема точно - ако имате неколку списанија, мора да се префрлате помеѓу екраните што ги прикажуваат, губејќи ја целокупната слика. Дополнително, тешко дека давателот на облакот ќе ви обезбеди можност да ги поврзувате безбедносните настани и генерално да ги анализирате од безбедносна гледна точка (обично имате работа со необработени податоци, кои треба сами да ги разберете). Има исклучоци и за нив ќе зборуваме понатаму. Конечно, вреди да се праша кои настани се снимени од вашиот облак провајдер, во кој формат и како тие одговараат на вашиот процес на следење на безбедноста на информациите? На пример, идентификација и автентикација на корисници и гости. Истиот Bitrix ви овозможува, врз основа на овие настани, да го снимите датумот и времето на настанот, името на корисникот или гостинот (ако го имате модулот „Веб аналитика“, објектот до кој се пристапува и други елементи типични за веб-локација . Но, корпоративните служби за безбедност на информации може да имаат потреба од информации за тоа дали корисникот пристапил до облакот од доверлив уред (на пример, во корпоративна мрежа оваа задача е имплементирана од Cisco ISE). Што е со толку едноставна задача како што е функцијата geo-IP, која ќе помогне да се утврди дали корисничката сметка на услугата облак е украдена? И дури и ако провајдерот на облак ви го обезбеди тоа, ова не е доволно. Истиот Cisco CloudLock не ја анализира само геолокацијата, туку користи машинско учење за ова и анализира историски податоци за секој корисник и следи различни аномалии во обидите за идентификација и автентикација. Само MS Azure има слична функционалност (ако имате соодветна претплата).

Постои уште една тешкотија - бидејќи за многу провајдери на облак следењето на безбедноста на информациите е нова тема со која штотуку почнуваат да се занимаваат, тие постојано менуваат нешто во нивните решенија. Денес имаат една верзија на API, утре друга, задутре трета. Исто така, треба да бидете подготвени за ова. Истото важи и за функционалноста, која може да се промени, што мора да се земе предвид во вашиот систем за следење на безбедноста на информациите. На пример, Амазон првично имаше посебни услуги за следење на настани во облак - AWS CloudTrail и AWS CloudWatch. Потоа се појави посебна услуга за следење на настани за безбедност на информации - AWS GuardDuty. По некое време, Амазон лансираше нов систем за управување, Amazon Security Hub, кој вклучува анализа на податоците добиени од GuardDuty, Amazon Inspector, Amazon Macie и неколку други. Друг пример е алатката за интеграција на дневникот Azure со SIEM - AzLog. Активно го користеа многу продавачи на SIEM, сè додека во 2018 година Мајкрософт објави прекин на неговиот развој и поддршка, со што многу клиенти кои ја користеа оваа алатка се соочија со проблем (ќе зборуваме за тоа како се реши подоцна).

Затоа, внимателно следете ги сите функции за следење што ви ги нуди вашиот облак провајдер. Или потпирајте се на надворешни даватели на решенија кои ќе дејствуваат како посредници помеѓу вашиот SOC и облакот што сакате да го следите. Да, ќе биде поскапо (иако не секогаш), но целата одговорност ќе ја префрлите на туѓи раменици. Или не сето тоа?.. Да се потсетиме на концептот на споделена безбедност и да разбереме дека не можеме ништо да префрлиме - ќе мораме самостојно да разбереме како различни провајдери на облак обезбедуваат следење на безбедноста на информациите на вашите податоци, апликации, виртуелни машини и други ресурси хостиран во облакот. И ќе започнеме со она што го нуди Amazon во овој дел.

Пример: Следење на безбедноста на информациите во IaaS врз основа на AWS

Да, да, разбирам дека Амазон не е најдобар пример поради фактот што ова е американска услуга и може да биде блокирана како дел од борбата против екстремизмот и ширењето на информации забранети во Русија. Но, во оваа публикација би сакал само да покажам колку различни платформи за облак се разликуваат во нивните можности за следење на безбедноста на информациите и на што треба да обрнете внимание кога ги пренесувате вашите клучни процеси на облаците од безбедносна гледна точка. Па, ако некои од руските развивачи на решенија за облак научат нешто корисно за себе, тогаш тоа ќе биде одлично.

Првото нешто што треба да се каже е дека Амазон не е непробојна тврдина. На неговите клиенти редовно им се случуваат разни инциденти. На пример, имињата, адресите, датумите на раѓање и телефонските броеви на 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 итн. преку анализа на полето Кориснички агент.

Амазон веб сервиси исто така разви и други услуги за сајбер-безбедност кои ви дозволуваат да решите многу други проблеми. На пример, AWS има вградена услуга за ревизија на политики и конфигурации - AWS Config. Оваа услуга обезбедува континуирана ревизија на вашите AWS ресурси и нивните конфигурации. Да земеме едноставен пример: да речеме дека сакате да бидете сигурни дека корисничките лозинки се оневозможени на сите ваши сервери и дека пристапот е возможен само врз основа на сертификати. AWS Config го олеснува проверувањето на ова за сите ваши сервери. Постојат и други правила што може да се применат на вашите облак сервери: „Ниту еден сервер не може да ја користи портата 22“, „Само администраторите можат да ги менуваат правилата за заштитен ѕид“ или „Само корисникот Ивашко може да креира нови кориснички сметки, а тој може да го прави тоа е само во вторник. " Во летото 2016 година, услугата AWS Config беше проширена за да го автоматизира откривањето на прекршувањата на развиените политики. Правилата за конфигурација AWS се во суштина континуирани барања за конфигурација за услугите на Amazon што ги користите, кои генерираат настани доколку се прекршат соодветните политики. На пример, наместо периодично да се извршуваат барањата за AWS Config за да се потврди дека сите дискови на виртуелен сервер се шифрирани, Правилата за конфигурација на AWS може да се користат за континуирана проверка на дисковите на серверот за да се осигура дека овој услов е исполнет. И, што е најважно, во контекст на оваа публикација, секое прекршување генерира настани што може да ги анализира вашата служба за безбедност на информации.

AWS, исто така, има свој еквивалент на традиционалните корпоративни решенија за безбедност на информации, кои исто така генерираат безбедносни настани што можете и треба да ги анализирате:

Откривање на упад - AWS GuardDuty
Контрола на истекување информации - AWS Macie
EDR (иако зборува за крајните точки во облакот малку чудно) - AWS Cloudwatch + osquery со отворен код или решенија GRR
Анализа на Netflow - AWS Cloudwatch + AWS VPC Flow
DNS анализа - AWS Cloudwatch + AWS Route53
АД - Услуга за директориуми AWS
Управување со сметки - AWS IAM
ДЗС - AWS ДЗС
безбедносна анализа - AWS инспектор
управување со конфигурации - AWS Config
WAF - AWS WAF.

Нема да ги опишам детално сите услуги на Амазон кои можат да бидат корисни во контекст на безбедноста на информациите. Главната работа е да разбереме дека сите тие можат да генерираат настани што можеме и треба да ги анализираме во контекст на безбедноста на информациите, користејќи ги за таа цел и вградените способности на самиот Amazon и надворешните решенија, на пример, SIEM, кои можат однесете безбедносни настани во вашиот центар за следење и анализирајте ги таму заедно со настани од други облак услуги или од внатрешна инфраструктура, периметар или мобилни уреди.

Во секој случај, сè започнува со изворите на податоци кои ви обезбедуваат настани за безбедноста на информациите. Овие извори вклучуваат, но не се ограничени на:

CloudTrail - Употреба на API и кориснички дејства
Доверлив советник - безбедносна проверка против најдобрите практики
Конфигурација - инвентар и конфигурација на сметки и поставки за услуги
Дневници на проток на VPC - врски со виртуелни интерфејси
IAM - услуга за идентификација и автентикација
ELB Access Logs - Load Balancer
Инспектор - пропусти на апликацијата
S3 - складирање на датотеки
CloudWatch - Активност на апликацијата
SNS е услуга за известување.

Амазон, иако нуди таков опсег на извори на настани и алатки за нивната генерација, е многу ограничен во својата способност да ги анализира собраните податоци во контекст на безбедноста на информациите. Ќе мора самостојно да ги проучувате достапните дневници, барајќи релевантни индикатори за компромис во нив. AWS Security Hub, кој Amazon неодамна го лансираше, има за цел да го реши овој проблем со тоа што ќе стане облак SIEM за AWS. Но, досега е само на почетокот на своето патување и е ограничен и од бројот на извори со кои работи и од другите ограничувања утврдени со архитектурата и претплатите на самиот Амазон.

Пример: Следење на безбедноста на информациите во IaaS базирано на Azure

Не сакам да навлегувам во долга дебата за тоа кој од трите даватели на облак (Амазон, Мајкрософт или Гугл) е подобар (особено затоа што секој од нив сè уште има свои специфични специфики и е погоден за решавање на сопствените проблеми); Да се фокусираме на способностите за следење на безбедноста на информациите што ги обезбедуваат овие играчи. Мора да се признае дека Amazon AWS беше еден од првите во овој сегмент и затоа напредуваше најдалеку во однос на функциите за безбедност на информациите (иако многумина признаваат дека се тешки за користење). Но, тоа не значи дека ќе ги игнорираме можностите што ни ги даваат Microsoft и Google.

Производите на Мајкрософт отсекогаш се одликувале по својата „отвореност“, а во 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):

Дневници на активности - овој дневник одговара на класичните прашања „кој“, „што“ и „кога“ во врска со која било операција за пишување (СТАВИ, ПОСТАВЕ, ИЗБРИШИ) на ресурсите на облакот. Настаните поврзани со пристапот за читање (GET) не се вклучени во овој дневник, како и голем број други.
Дијагностички дневници - содржи податоци за операции со одреден ресурс вклучен во вашата претплата.
Известување за Azure AD - содржи и корисничка активност и системска активност поврзана со управување со групи и корисници.
Windows Event Log и Linux Syslog - содржи настани од виртуелни машини хостирани во облакот.
Метрика - содржи телеметрија за перформансите и здравствената состојба на вашите облак услуги и ресурси. Се мери секоја минута и се складира. во рок од 30 дена.
Дневници на проток на група за безбедност на мрежата - содржи податоци за настани за безбедност на мрежата собрани со помош на услугата Network Watcher и следење на ресурсите на ниво на мрежа.
Дневници за складирање - содржи настани поврзани со пристап до капацитети за складирање.

За следење, можете да користите надворешни SIEM или вградениот Azure Monitor и неговите екстензии. Подоцна ќе зборуваме за системи за управување со настани за безбедност на информации, но засега да видиме што ни нуди самиот Azure за анализа на податоци во контекст на безбедноста. Главниот екран за сè што е поврзано со безбедноста во Azure Monitor е таблата за безбедност и ревизија на Log Analytics (бесплатната верзија поддржува ограничена количина на складирање на настани за само една недела). Оваа контролна табла е поделена на 5 главни области кои визуелизираат збирна статистика за она што се случува во околината на облак што ја користите:

Безбедносни домени - клучни квантитативни индикатори поврзани со безбедноста на информациите - број на инциденти, број на компромитирани јазли, незакрпени јазли, настани за безбедност на мрежата итн.
Забележителни прашања - го прикажува бројот и важноста на активните прашања за безбедноста на информациите
Откривања - прикажува шеми на напади што се користат против вас
Интелигенција за закани - прикажува географски информации на надворешни јазли што ве напаѓаат
Вообичаени безбедносни прашања - типични прашања кои ќе ви помогнат подобро да ја следите безбедноста на информациите.

Наставките на Azure Monitor вклучуваат Azure Key Vault (заштита на криптографски клучеви во облакот), Проценка на малициозен софтвер (анализа на заштита од злонамерен код на виртуелни машини), Azure Application Gateway Analytics (анализа на, меѓу другото, дневници на заштитниот ѕид на облакот) итн. . Овие алатки, збогатени со одредени правила за обработка на настани, ви дозволуваат да визуелизирате различни аспекти на активноста на облак услугите, вклучително и безбедноста, и да идентификувате одредени отстапувања од работата. Но, како што често се случува, секоја дополнителна функционалност бара соодветна платена претплата, која ќе бара соодветни финансиски инвестиции од вас, кои треба однапред да ги планирате.

Azure има голем број вградени способности за следење закани кои се интегрирани во Azure AD, Azure Monitor и Azure Security Center. Меѓу нив, на пример, откривање на интеракција на виртуелни машини со познати малициозни IP-адреси (поради присуството на интеграција со услугите Threat Intelligence од 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 and Security Center би можеле да се наречат SOC за облакот Azure и би можеле да бидат ограничени на нив (со одредени резервации) доколку веќе немате никаква инфраструктура и ги префрливте сите ваши компјутерски ресурси во облакот и тоа би бил Microsoft cloud Azure.

Но, бидејќи вградените способности на Azure (дури и ако имате претплата на Sentinel) честопати не се доволни за целите на следење на безбедноста на информациите и интегрирање на овој процес со други извори на безбедносни настани (и облак и внатрешни), постои треба да се извезат собраните податоци во надворешни системи, во кои може да биде вклучен и SIEM. Ова се прави и со користење на API и со користење на специјални екстензии, кои во моментов се официјално достапни само за следните SIEM - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight и ELK. До неодамна имаше повеќе такви SIEM, но од 1 јуни 2019 година, Мајкрософт престана да ја поддржува алатката за интеграција на Azure Log (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, секоја организација, проект или папка има четири дневници:

Активност на администраторот - ги содржи сите настани поврзани со административен пристап, на пример, создавање виртуелна машина, менување на правата за пристап итн. Овој дневник е секогаш напишан, без оглед на вашата желба, и ги складира неговите податоци 400 дена.
Пристап до податоци - ги содржи сите настани поврзани со работа со податоци од корисниците на облакот (создавање, измена, читање итн.). Стандардно, овој дневник не е напишан, бидејќи неговиот волумен отекува многу брзо. Поради оваа причина, неговиот рок на траење е само 30 дена. Покрај тоа, не е сè напишано во ова списание. На пример, настаните поврзани со ресурси кои се јавно достапни за сите корисници или кои се достапни без да се најавите на GCP не се напишани на него.
Системски настан - содржи системски настани кои не се поврзани со корисници, или дејства на администратор кој ја менува конфигурацијата на ресурсите на облакот. Секогаш се пишува и се чува 400 дена.
Транспарентноста на пристапот е уникатен пример за дневник кој ги прикажува сите дејства на вработените на Google (но сè уште не за сите услуги на GCP) кои пристапуваат до вашата инфраструктура како дел од нивните работни должности. Овој дневник се чува 400 дена и не е достапен за секој клиент на GCP, но само ако се исполнети голем број услови (или поддршка на ниво на злато или платина или присуство на 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 или преку страницата Активност на вашиот проект за кој сте се заинтересирани за настани. На ист начин, тие можат да се извезат во надворешни решенија за дополнителна анализа. Последново се прави со извоз на логови во BigQuery или Cloud Pub/Sub складирање.

Покрај Stackdriver Logging, платформата GCP нуди и функционалност за следење на Stackdriver, која ви овозможува да ги следите клучните метрики (перформанси, MTBF, целокупното здравје, итн.) на услугите и апликациите во облак. Обработените и визуелизираните податоци може да го олеснат наоѓањето проблеми во вашата облак инфраструктура, вклучително и во контекст на безбедноста. Но, треба да се забележи дека оваа функционалност нема да биде многу богата во контекст на безбедноста на информациите, бидејќи денес GCP нема аналог на истиот AWS GuardDuty и не може да ги идентификува лошите меѓу сите регистрирани настани (Google разви Откривање закани за настани, но сè уште е во развој во бета верзија и прерано е да се зборува за неговата корисност). 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 - заштита на криптографски клучеви.
Услуга за управување со клучеви во облак - управување со криптографски клучеви во GCP.
VPC Service Control - Создадете безбеден периметар околу вашите GCP ресурси за да ги заштитите од протекување.
Безбедносен клуч Titan - заштита од фишинг.

Многу од овие модули генерираат безбедносни настани што може да се испратат до складиштето 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

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, според политиката, никогаш нема да биде оддалечена дестинација за најавување. Ајде понатаму да претпоставиме дека овој компјутер доживеа далечинско најавување поради погрешна промена во политиката на правилата за заштитен ѕид. Функцијата Entity Modeling ќе ја открие и пријави оваа активност („Невообичаен далечински пристап“) во скоро реално време и ќе укаже на специфичниот AWS CloudTrail, Azure Monitor или GCP Stackdriver Logging API повик (вклучувајќи корисничко име, датум и време, меѓу другите детали што ја поттикна промената на правилото на 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 сервери и така натаму. Сите овие податоци ќе бидат збогатени со информации за разузнавањето за закани собрани од Cisco Talos, најголемата светска невладина група истражувачи на закани за сајбер безбедноста.

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

Со ова ќе го заокружиме првиот дел од статијата, во која ги разгледав вградените и надворешните алатки за следење на информациската безбедност на IaaS/PaaS платформите, кои ни овозможуваат брзо откривање и реагирање на инциденти кои се случуваат во облачните средини кои нашето претпријатие избра. Во вториот дел, ќе ја продолжиме темата и ќе ги разгледаме опциите за следење на SaaS платформите користејќи го примерот на Salesforce и Dropbox, а исто така ќе се обидеме да сумираме и составиме сè заедно со создавање на унифициран систем за следење на безбедноста на информациите за различни даватели на облак.

Извор: www.habr.com