Сигурност

Трансформация на SIEM при мигриране към облачни услуги

CIO Media

Софтуерните инструменти с общо означение SIEM (Security Information and Events Management – управление на събитията по сигурността и информацията, която е свързана с тях) предоставят две основни функции: управление на информацията за сигурността (security information management - SIM) и управление на събитията, които са свързани със сигурността (security event management - SEM).

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

Функционалност на SIEM

Основните функции на SIEM могат да се обобщят в следния списък:

1. Събиране – приемане на журналните записи от отдалечени платформи и записване в локален масив, чрез посредници наречени колектори и конектори.

2. Агрегиране - свързаните събития се агрегират за да се избягнат многократно повтарящи се уведомления за едно и също реално събитие с една причина.

3. Анонимизация за запазване на конфиденциалност - може да се наложи определени събития за се обработят предварително, така че да се запази от разкриване определена информация.

4. Нормализация - текстовете на съобщенията се транслират във унифициран формат.

5. Корелация – основна функция, която се изпълнява от SIEM, открива зависимост между събития, които формират инцидент по сигурността, вследствие на което се активира схема за отговор.

6. Интелигентност и знание с шаблони за откриване на атаки [6].

7. Управление на отговора – функция, която осигурява технически и организационни мерки при отговор на инцидент. Длъжностните лица изспълняват процедури , а техническите средства – скриптове и операции с които спират достъп, изключват системи, изолират мрежови сегменти и др.

8. Плъгини за поддържане на съответствия със стандарти например PCI-DSS или HIPAA.

9. Отчети за състоянието [1],[7], които се формират и генерират ръчно при разследване на инциденти или са планирани за автоматично изпращане.

Споделяне на журналите между наематели на услуги от облака

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

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

Журналните записи могат да се използват за идентифициране на машини, заразени със зловреден софтуер или с неприемливо конфигурирана защита.

Преобладава виждането, че пречките по споделянето на журнални записи имат в основата си технически проблеми, а след това социални нюанси [8].

На фигура 1 е представен олекотен вариант на интересите на клиентите на облачни услуги към информацията, която се генерира и съдържа във файловете с журнални записи. Публикациите по темата засягат проблемите за журнализацията по отношение на съжителството на множество наематели на услугата, но рядко коментират поделянето на журналните файлове между наемателите и доставчиците на облачни услуги (ДОУ).


Анализът на разликите в процеса на управление на журналните записи показва, че при наемане на различни модели услуги от облака е необходимо организациите да познават и диференцират продуктите по отношение на функционалността им, свързана със SIEM. Изводите, до които стигнахме по този повод са систематизирани в таблица 1.

За представените там разграничения ни помогна публикацията на Тери Робъртс и съавтори [Error: Reference source not found], където с една дума е определено отношението на организациите към различните модели облачни услуги, а именно:

  • SaaS – консумира;

  • PaaS – изгражда;

  • IaaS - стопанисва



Трансформация на SIEM при мигриране към облачни услуги

© CIO Media, Cio.bg


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

  • Операции с виртуалните машини – копиране, преместване, спиране на възел от клъстер;

  • Действия на привилегировани потребители в средата на хипервайзора.

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

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

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

Налице е нарастваща необходимост от SIEM системи, които да обхващат множество ИКТ инфраструктури и постигат глобално покритие. За да бъдат ефективни решенията за сигурност в такива сложни, мащабни, с много наематели и разпределени инфраструктури, те трябва да включват автоматични механизми за осигуряване на макро ниво на управление на информационните потоци между основните модули, като например: между слоеве с различна надеждност, от незащитените крайни слоеве до по-защитеното основно ядро; между слоевете от едно ниво с прилагане на механизми за подобряване на устойчивостта [7].

Независимо от това какви модели на услуги (SaaS, PaaS и IaaS) използват организациите архитектурата на ИКТ системите им винаги е комбинирана от локални мрежи и облачен компютинг.

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

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

При SaaS цялата съществуващата SIEM инфраструктура на организацията си остава в нейни ръце. Доставчикът си поддържа собствената SIEM и в най-добрия случай изпраща филтрирани журналните записи на всеки клиент.

Нека организацията има договори за SaaS с N на брой доставчици. Журналните файлове, които я касаят са разпръснати в поне N отдалечени възли, докато не бъде преместено някое от наетите приложения в следващ център за данни. Този процес естествено продължава, което е нормално свойство на облачния компютинг. Вече е трудно да си представим как се променят в случая характерните за SIEM операции:

  • филтриране на файловете със журналните съобщения;

  • откриването на корелирани атаки;

  • откриване на аномалии в поведението на отделни системи;

  • откриване на неправомерни действия;

  • откриване на потенциални за отслабване на сигурността събития – недовършена актуализация на ОС, антивирусна програма и т. н.;

  • реакция при инцидент.

Да допуснем, че имаме една организация потребител на SaaS. Възможни са два сценария на взаимоотношения между клиента и доставчика на облачните услуги:

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

  • При вторият вариант клиентът е лишен от достъп до журналните записи.

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

Кратката чек листа на д-р Антон Чувакин и Лени Зелтцер [9] е предназначена за конвенционални системи от ИКТ. Съпоставяйки всеки раздел от нея с изискванията на С2, виждаме че архитектурата и функциите на конвенционалните SIEM и SIM не съответстват на условията за експлоатация на ИКТ, които включват услуги от облака:

  • журналните записи не са тагвани за разпределяне сред много крайни потребители на С2 услуги;

  • няма механизми за корелиране на времето на събитието и записа в случая когато услугата или виртуалната машина се мести в различни центрове за данни на ДОУ;

  • самите SIEM не са проектирани за разпределяне на събития към много клиенти на базата на гранулирано трасиране на всеки от потребителите от дадена организация клиент;

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

Мениджмънт на събитията по сигурността в облака

Възможна е поява на корелирани събития, които са свързани с VM Escape и VM Introspection. Те обаче в най-добрия случай ще се регистрират от двете страни – доставчик и клиент и ще изглеждат привидно независими. Не открихме изследвания или практически разработки, които да третират корелиране на събития, част от които се прояват от една страна във виртуалните машини и виртуалната мрежа на клиента и друга част – в хипервайзора стопанисван от доставчика.

Изникват следните въпроси:

  • на кого принадлежат всъщност данните за атаките над приложението когато бъде атакувана SaaS услуга. Трябва ли доставчикът да информира клиента при атака и да унищожи данните от журналите, които го касаят след приключване на договорните отношения с клиента си?

  • не могат да се автоматизират реакциите при инцидент, тъй като не може да се спре приложението от страна на потребителя.

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

Препоръки

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

  • SIEM и SIM услуги, които са базирани в облака, но съобразени с особенностите на архитектурата на моделите облачни услуги;

  • Вградени конектори и колектори за журналите на услугите от облака, интерфейси към които да се предлагат на клиентите като опционални части към продукта;

  • Филтриран достъп на клиентите до системата от журнали на ДОУ – онлайн и в архивите;

Развитието на изложената проблематика доведе до предложението към IETF за “Разширение на syslog със структуриране данни за облака” (Syslog extension for cloud using syslog structured data) от S. Johnston G. Golovinsky. При облачния компютинг ситуацията с наличността и надеждността на журналите е различна. Виртуалните машини могат да бъдат активирани и спирани много бързо за къс период, във всеки момент те се поделят не само между различни потребители, но и между различни потребители от различни компании. Въпреки, че виртуалните машини продължават да журнализират активността си, то информацията не може да се отнесе към конкретна физическа среда. Дори да се направи такъв опит не е сигурно, че същата виртуална машина ще работи върху същия хардуер и хипервайзор при следващата си реинкарнация.

В тази ситуация няма ясен начин да се определи колко потребители си поделят хардуера и какви са техните идентичности и роли. Трасиране на промените в обкръжението е практически невъзможно освен ако не е установена схема за регистриране на съответствието между физическите и виртуалните ресурси [3].

Същият документ предлага в журналните записи (Cloud Log) да влязат структурирани данни за:

1. Идентичността на удостоверения пред услугата потребител (RUI - real user identity).

2. Ефективния или деперсонифициран потребител (EUI - effective or impersonated user identity), идентичност на потребителя, от името на който реалния потребител се представя. Например от името на администратора могат да се деперсонифицират акаунти на други потребители, или пък обикновен потребител да ескалира правата си до root.

3. Доставчика – домейн, услуга и др. [3].

В заключение

Съвременното развитие на SIEM системите не е достатъчно за да се опазват данните които идентифицират персонално потребителите. Мета системи като SIEM понастоящем не включват методи за осигуряване на неприкосновеност на личните данните - което води до риск за поверителността включително нарушаване на регламенти на ЕС при трансграничен пренос [4].

Организациите могат да обърнат внимание и на сравнителния анализ на централизираните и разпределените операции по корелиране на събития в [5]. Разпределените решения са подходящи за анализи на събитията в реално време, а затрудненията при конфигурирането им са по-големи.

Източници:

[1] Volume II - SENTINEL USER GUIDE. Novell Inc., 404 Wyman Street, Suite 500, Waltham, MA 02451, U.S.A., 2008.

[2] Terry Roberts Frances Fragos Townsend. Cloud computing: Risks, benefits, and mission enhancement for the intelligence community. Technical report, INSA:Intelligence and National Security Alliance CLOUD COMPUTING TASK FORCE, March 2012.

[3] S. Johnston G. Golovinsky. Syslog extension for cloud using syslog structured data draft-golovinsky-cloud-services-log-format-03. April 2013.

[4] Dr Andrew Hutchison. Privacy implications for next generation siems and other meta-systems. In Workshop on Security and Privacy Services in the Horizon, 19 April 2013, Brussels, April 2013.

[5] Justin Myers. A dynamically configurable log-based distributed security event detection methodology using simple event correlator. AFIT/GCO/ENV/10-J02, DEPARTMENT OF THE AIR FORCE, AIR UNIVERSITY, AIR FORCE INSTITUTE OF TECHNOLOGY Wright-Patterson Air Force Base, Ohio, June 2010.

[6] NetIQ. Novell sentinel advisor. 2008.

[7] Alysson Bessani (FFCUL) Paulo Verissimo (FFCUL) Nuno Neves (FFCUL), Antonio Costa (FFCUL). Management of security information and events in service infrastructures massif fp7-257475 d5.1.1 - preliminary resilient framework architecture. September 2011.

[8] Adam J. Slagell, Yifan Li, Katherine Luo, and I. Introduction. Sharing Network Logs for Computer Forensics: A New Tool for the Anonymization of NetFlow Records. In Proceedings of the Computer Network Forensics Research Workshop, September 2005.

[9] Lenny Zeltser and Anton Chuvakin. Critical Log Review Checklist for Security Incidents.


X