Кой е там зад лога?
Обвързването на управлението на логовете с управлението на идентичността скъсява времето за реакция при инциденти. Стивън Норткът
Реакцията при инцидент е труден проблем, когато трябва да се стигне до основите на това, което се е случило. Повечето организации, които забележат или заподозрат проникване, се нуждаят от часове работа, за да съберат достатъчно данни за регистрациите (логовете) и разберат какво точно е станало. Причината е проста – повечето устройства и приложения за сигурност предоставят отчети какво се случва, но не и за това кой стои зад дадено действие или за историята на въпросната система или за други подобни събития.
Днес обаче изискванията за нормативно съответствие са изградени върху необходимостта сигурността да предоставя основа за свързване на самоличността с действието. Всъщност нормативното съответствие е това, което принуждава организациите да внедряват управление на логовете и да заделят бюджети за обвързване на идентичността с действието. Законът Sarbanes-Oxley (SOX) например изисква стриктни проверки на достъпа до финансовитезаписи, което означава, че е от критично значение всяко неоторизирано човешко действие да бъде забелязано.
Организациите, които извършват анализ на логовете, продължават само да реагират на събития в мрежата, въпреки че се опитват да бъдат проактивни. Когато регистрациите са свързани със самоличността на потребителите, може бързо да се определи лицето зад събитието. Идентичността на служителите е важен елемент от информацията, който скъсява цикъла анализ - решение, спомага да се елиминират несъществените проблеми и предоставя увереност относно събитията, които се маркират като приоритетни за вземане на мерки. Например вие може да не знаете колко неуспешни опити за регистриране са признак за проучване с цел проникване, но ако можете да получавате диаграми на неуспешните опити на всеки потребител, ще можете да откриете модели, за които не сте и предполагали, че трябва да следите приоритетно.
Да се знае „кой“, както и „какво“ е повече отблагоприятно при разследване на инциденти е много съществен елемент от програмата за сигурност и съответствие на всяка организация. Кой е проникнал без право в базата данни с клиенти? Кой се е опитал да получи базови привилегии за домейн сървъра? Кой е подправил финансовите записи?
Класически случай на нормативно несъответствие по отношение свързването на действието със самоличността са медицинските записи. Някои от тези случаи, като този с Бритни Спиърс и медицинския център UCLA, получиха широка популярност и стана известно, че 13 служители без пълномощни са гледали нейните записи през март 2008 г. Запознати с тези неща твърдят обаче, че това не е изключение, а доста често срещано явление. Откраднатата информация може да бъде продадена не само на сензационните таблоиди, както в случаите с Бритни Спиърс, Мария Шайфър и Джордж Клуни, но и на застрахователните компании.
Едва ли е нужно да се казва, че има потенциален риск за медицинските институции както от съдебни дела за нарушаване на личната информация и емоционално разстройство, така и за нарушаване на съответствието със закона Health Insurance Portability and Accountability Act, HIPAA в САЩ. (В България здравната информация е под защита на Закона за здравето и Закона за защита на личните данни.)
Да се обвърже самоличността с действията на един потребител не е лесна задача, но вече се появяват инструменти и разработени методи, които проследяват обратно събитията до непреднамерения или злонамерения злосторник.
Проследяване на събития с хора
Защо е толкова трудно да се обвърже идентичността с действието? В сърцевината на проблема е оскъдният отчет за събитията. Един компютър, сървър или устройство за сигурност изпращат доклад до сислога (syslog) с информацията, която имат. Те не могат да събират друга информация за събития, състояния, лица, които се регистрират, и т.н. Резултатите, които обикновено се получават от логовете, са:
• Времето и датата на събитието
• IP адресът или ако е възможно имената на въвлечените в събитието хостове
• Програмата, докладваща за събитието
• Тежестта на събитието, като обичайните стойности са „фатално“, „тежко“, „предупредително“, „информационно“, „премахване на дефекти“, което се решава от приложението и може да бъде точно и полезно, но може и да не бъде
• Какво се е случило според гледната точкана докладващата програма
Нека видим един пример от Suhosin, една усилена версия на Hypertext Preprocessor (PHP):
Февруари 24 09:56:43 [31321] ТРЕВОГА – опит за регистриране на забранена променлива ‘GLOBALS’ чрез променливата GET (нападател ‘41.204.211.204’, файл ‘/srv/www/ live/sans/public_html/newsletters/risk/index. php’)
Всяко от тези полета е полезно, необходимо, но не и достатъчно. Какво липсва? За да се направи пълен анализ, обикновено са нужни „дебели“ данни – допълнителна информация, която може да не е достъпна за докладващaта програма. Допълнителните полета, които обикновено са необходими, за да се получи информация, с която да се определи как да се действа по даденото събитие, включват:
• Кога се е случило събитието: Февруари 24 09:56:43 според времевата зона на източното крайбрежие на САЩ.
• Кой е инициирал действието: 41.204.211.204, според програмата nslookup е присвоен на webhost3.shadowrain.co.za по това време.
• Това стимул ли е или реакция: В този случай е стимул, понеже webhost3 е инициирал връзките с www.sans.org.
• Ако събитието, което сме записали, е реакция, идентифицирали ли сме стимула или, както е в случая, ако е стимул, реагирали ли сме?
• Кои хора и програми са въвлечени. О, има преграда – ние знаем IP адреса, името на машината, но нямаме и най-малка идея кой в Южна Африка стои зад това действие.
• Било ли е или не е било успешно всяко събитие във веригата? Това регистрирано влизане е едно от цяла серия; webhost3 вероятно е пуснал скенер на www.sans.org; за щастие всички опити са неуспешни.
• Това приключило ли е или продължава? Този опит има стартово време и крайно време, така че събитието е приключило. Това можем само да предположим, като разглеждаме всички логове от IP адреса.
От много години събирането на данните на едно място е отговорност на аналитика по сигурността. Поставяме сигнален флаг на дадено събитие в сислога, понеже то съдържа ключова дума, за която знаем, че показва подозрително действие, например „rejected“, „dropped“ или „denied.“ След това вземаме информацията от постъпилите в сислога съобщения и започваме да проследяваме нещата напред и назад, за да открием други събития, свързани с регистрираното. Може би имаме IP адрес и трябва да се консултираме с таблицата на Dynamic HostConfiguration Protocol DHCP, за да определим името на хоста и MAC адреса.
След това може би трябва да отидем към логовете на събитията в системния или домейн контролера, за да видим кой се e регистрирал. Дали те са се регистрирали от първия път или е имало многократни опити? Откъде са се регистрирали? Локално или отдалечено е било логването? Такъв тип аналитично разследване на мрежата е възможен, но отнема много време и изисква съвършени познания за това откъде може да се получи информация.
Всяко събитие може да отнеме между 30 минути и няколко часа, за да се „разкопае“ до дъното, а работата е досадно еднообразна, особено ако трябва да се работи с данни от различни времеви зони. Високата цена на ръчното изграждане на взаимозависимости означава, че много потенциални инциденти никога не са разследвани, което пък означава, че не сме успели да открием събития, които могат да доведат понякога до опустошителни последици. Такива бяха грандиозните измами в Barings Bank и Societe General.
От друга страна, ако можем да използваме софтуер, който да събира тази информация и да я показва по смислен начин, аналитикът може да вземе за секунди доста добро решение за тежестта на събитието в логовете, с което значително да се подобри способността ни да откриваме и отговаряме на потенциално опасни събития.
Ключът за решаване на проблемите ще бъде в способностите на аналитиците да следят за промени в поведението на потребител, да докладват за разпределение на задълженията, двойни контроли и нарушения на достъпа и да следят дейността му и да я докладват.
Инструменти следят потребителите
Тъй като залогът е висок и нуждата да се обвърже самоличността с действието – голяма, доставчиците започнаха да предлагат решения, които могат да помогнат. Например Sourcefire Real-time User Awareness (RUA) може да бъде конфигуриран така, че да изпрати сигнал за тревога всеки път, когато се открие идентичност на нов потребител, и тази идентичност може да бъде проверена за съответствие със специфични стойности.
Да вземем моя пример със „Zippy“. (Това се случи наистина. Макар че банките страдат най-често от пробиви на акаунти, повечето професионалисти по сигурност с над двегодишен опит могат да разкажат някоя история с нов или променен акаунт.) Компанията бе лаборатория, в която потребителските имена се образуваха от първата буква на първото име и първитешест букви от фамилията. Регистрирането на нов акаунт „zippy“ (популярен герой от детско шоу – бел.прев.) веднага привлича вниманието ни. Въпросът бе дали имаме служител, чието име е Zeke Ippy, или имаме проблем.
Ако имахме списък на всички потребители, можехме да проучим zippy, за да видим дали имаме потребител, чието първо име започва с „Z“, а фамилията му с „Ippy“. Това може да бъде направено с любителски скрипт, като се използват обикновени изрази, но с времето виждаме доставчици да предлагат повече възможности, с които може инструментите да се конфигурират за поддръжка на бизнес логика.
Архитектите на сигурността сега могат да разчитат на една или повече категории на индустрията за логове и анализ, предлагащи инструменти, които могат да доставят „дебели“ данни и да обвържат потребителската идентификация и друга информация, свързана с нея, с логовете на събитията. Тези инструменти включват:
• Мениджъри на информация за събития в сигурността (Security information event managers, SIEM)
• Устройства за управление на логовете, които основно събират лог файловете
• Централна конзола за продуктите на дадена компания по сигурност, която предлага много допълнителни възможности, а не само логове и анализи. Например и Tenable, и Sourcefire имат по няколко продукта за сигурност, които докладват в централна конзола и се стремят да доставят „дебели“ данни.
Тези продукти приемат слаби събития и създават „дебели“ данни за анализи. Доставчиците продължават да прибавят функционалности и тези продуктови категории започват да се припокриват и е по-трудно да се дефинират, отколкото беше преди няколко години. Например SIEM сега наблягат на своите възможности за управление на логовете, за да извлекат приходи от пазара, образуван вследствие необходимостта от нормативно съответствие. А някои продукти за управление на логовете сега развиват възможности като на SIEM.
Потокът върви по следния начин. Случва се събитие, създава се малък лог файл, който го описва, и се изпраща в колектор (събирач). (В една организация или поделение може да има един или повече колектори.) Колекторът може да съхрани файла като сурово, непроменено събитие. Лог събитието може да бъде съхранено и със съответстващ криптографски хеш, за да се докаже, че с него не е боравено.
Ако съответната организация иска да направи повече от простото съхранение на лога, копие от лог събитието се изпраща до машина за анализи. Лог събитието може да бъде оценено според правила, които са проектирани така, чеили да потвърждават и записват нормалните събития, или да откриват необичайните или лошите събития.
Правилата могат да бъдат базирани на технология с обикновени изрази, за да се направи разбор на суровите събития, но по-сложните продукти нормализират логовете. Нормализирането разлага суровите данни на компоненти в стандартизирани полета, съхранени в база данни, така че да може да се търсят зависимости с друга информация. Примери за типа полета, които могат да се видят в база от данни на събития, включват ден от седмицата, час на деня, идентификационен номер, координираното универсално време - UTC, местното време, времевата зона, идентификация на програмата, име на операционната система, версия на операционната система, версия на приложението,име на хоста, IP на хоста, име на домейна на хоста, MAC адрес, причина за приложението, тип тежест.
След като данните се нормализират и вкарат в базата данни, нашите инструменти създават „дебело“ събитие, като добавят други референтни данни, като история за IP адреса, MAC адреса, името на системата, както и информация от сканиране за сродни уязвимости, история на подобни събития и логвания, данни за идентичност или достъп. Това ниво на информация ще помогне на аналитика да вземе информирано решение много по-бързо. Едно предупреждение – информацията не винаги е това, което изглежда, че е, така че не скачайте в очевидното заключение, което като че ли ви подсказват данните.
Тъй като справочните данни са важни, организациите, които вземат на сериозно лог анализите, ще искат всички данни, които е възможно да получат. Едно полезно средство е т.нар. пасивен „съгледвач“. Тези инструменти обикновено се слагат в събирателни точки като защитни стени и „подслушват“ и анализират преминаващия трафик. Те могат да определят каква операционна система е асоциирана към определени адреси. Могат също да определят версията на софтуера, който се изпълнява. Това е огромна крачка напред от базовото регистриране на порта на защитната стена и IP адреса. В допълнение те могат да определят точно съществуването на уязвимости. Тъй като създават справочните си таблици, като подслушват трафика, те дават по-текуща информация от мрежовите инвентарни таблици, които се осъвременяват ръчно. Съществуват примери на P0f (Passive OS Fingerprinting) на отворен код, а Sourcefire и Tenable Security имат търговски продукти, съответно Sourcefire Real-time Network Awareness (RNA) и Tenable Passive Vulnerability Scanner. И двете компании предлагат централна конзола, някакъв сорт мини- SIEM, който да събира и управлява данните за събитията, които техните продукти създават. Идентифицирането на събитие в сислога и „разпитването“ на тези конзоли все още е ръчен процес, но е огромна крачка напред от това всичко да се прави на ръка.
Със сложните SIEM става възможно да се обвържат слаби събития към самоличността по много ползотворен начин. По-рано това беше трудно да се прави, тъй като средният потребител има много акаунти – имейли, прозорци, VPN, интранет, идентификации според приложението, IM и т.н. Въпреки че даден SIEM може да събира действията от всички акаунти, ако искаме данните да водят до конкретни действия, трябва всички акаунти да се асоциират с едно-единствено лице. Като използва например ArcSight ESM, аналитикът избира един идентификатор на акаунт като уникален за потребителя. След това е възможно да асоциира всички други акаунти на потребителя към този уникален идентификатор. SIEM системи като ESM използват няколко метода, за да свържат действията по регистриране (логване) към самоличността, включително агенти и изпращане на присъщи за операционната система удостоверения.
Единственият начин за откриване на промени в поведението чрез технически контроли е да се обвърже самоличността към действията в продължение на достатъчно дълъг период от време за установяване на изходно ниво. Какво става, ако времетраенето на интернет връзката към социални медии като Twitter и Facebook внезапно се увеличи? Това може да показва, че потребителят си губи времето, вместо да работи. Или голямо увеличаване на времето вLinkedIn подсказва създаване на връзки преди напускане на сегашната организация. Въпреки това няма начин да откриете увеличението, ако не разполагате с изходното ниво.
Може да се очаква, че SIEM, която поддържа асоцииране на самоличността с дейността, ще може да се интегрира с Active Directory или Network Directory. Това означава, че освен за акаунтите можете също да получавате информация за група или роля. Въпреки че организациите не бързат да внедряват контрол на достъпа в мрежата (NAC) на корпоративно ниво, тази способност се вгражда във все повече и повече софтуери и устройства и нещата започват да се случват.
Една вълнуваща възможност за обвързване самоличността към действията е да се използват исторически данни за действията чрез технологията за профилиране на ArcSight, за да се генерират статистически модели и да се създадат нови правила. Например можете да направите преглед на действията на последните 50 души, които са напуснали, за да видите какви неща са извършили, които не се правят от тези, които все още са на работа. След това, ако видите подобна дейност, ще можете автоматично да съставите списък за наблюдение и да се уверите, че лицето, което ще напуска, не си тръгва с данни, файлове и др.
Или при спад на икономиката, каквато е сегашната ситуация, ако трябва да обявите, че вашата организация не може да дава бонуси една година, може да направите профил на действията на потребителите преди обявяването спрямо същите след обявяването, за да видите дали няма разлики. Скорошно проучване на Ponemon института (спонсорирано от Symantec), в което са интервюирани 945 възрастни хора в САЩ, съкратени, уволнени или променили работните си места през последната година, е установило, че повече от половината са взели фирмена информация с тях, когато са напуснали.
Обосновките за вземане на данните са включвали помощ да се получи друга работа или да се започне собствен бизнес, или просто отмъщение. Всички участници в изследването са имали достъп до секретна фирмена информация, включително данни за клиентите, информация за служителите, финансовите отчети, софтуер и конфиденциални бизнес документи. Изследването също така констатира, че само 15% от фирмите проучват хартиените и/или електронните документи, които техните бивши служители са взели с тях при напускането.
Отплатата
Всяка организация се бори с размера на необходимите усилия, за да получава реална полза от анализа на лог файловете. Очевидно еднатаголяма победа е нормативното съответствие. Повечето регулаторни органи или изискват, или силно препоръчват мониторинг на логовете. По-конкретно Consensus Audit Guidelines се отнасят до важността на обвързване на самоличността към действието. Два примера са налагането на контроли към латентните акаунти и непрекъс- нато оценяване на необходимостта да се знае. В двата случая трябва да се знае кой е потребителят и каква трябва да бъде ролята му.
От наблюдението на логовете не следва успехът. Помислете за стойността на аналитик, който отделя време да разнищи подозрително събитие до корен и намира нещо значимо, като например служител, събиращ личната информация на клиентите и изпращащ я на своя hotmail акаунт. Щетите могат да се сведат до минимум чрез бързото откриване и реагиране. Логовете, които обикновено се считат за глупава и скучна работа, стават вълнуващи.
Това е наистина едно от най-големите предимства на обвързването на самоличността с действието. Ударите върху защитната стена,отхвърлените спам съобщения, грешките в програмата, размерът на свободното дисково пространство - всички те са важни, разбира се. Хората обаче правят най-побърканите неща, и когато се добави човешката страна в уравнението на лог събитията, това е една изцяло нова игра. Не би било учудващо, ако в следващите няколко години станем свидетели на много вълнуващи методи за откриване на проблеми в сигурността, като обвързваме самоличността и ставаме по-добри в създаването на “дебели“ събития за преглед от аналитиците.
Стивън Норткът основава GIAC сертифицирането и в момента е президент на SANS Technology Institute, следдипломно ниво на IT Security College. Той е автор/съавтор на Incident Handling Step-by-Step, Intrusion Signatures and Analysis, Inside Network Perimeter Security 2nd Edition, IT Ethics Handbook, SANS Security Essentials, SANS Security Leadership Essentials и Network Intrusion Detection 3-о издание.
Възражение срещу аналитиците на логове
Вашите заключения са дотолкова добри, доколкото са вашите данни
Всеки професионалист по моделиране на данни веднага ще ви предупреди, че справочните данни са полезно и силно средство за анализ и класификация на събитие, само ако тази информация е коректна и поставена в правилни взаимовръзки. Ако си представите, че сте аналитик, който взема решение как да класифицира събитие, тогава ясно можете да видите, че ако този тип полета водят към погрешна следа или са неправилни, лесно можете да достигнете до грешно заключение. Нека вземем един пример на аналитик в университет, който разследва събитие от логовете:
Февруари 25 02:55:19 [16934] ТРЕВОГА – ограничението в дължината на конфигурираното име на заявка на променлива е преминато – отхвърли променливата ‘___df9d5 760ba1af926bed589c89//модули/My_eGallery/ index_php?basepath’ (нападател ‘10.12.82.4’,файл ‘/srv/www/live/college/public_html/new/ CS423/grades/display.php’
Информацията от лога за IP адрес 10.12.82.4 води към име на студент Джон Браун, а историята на събитието показва по-раншно предупреждение за хакерски тип поведение. Човек може веднага да направи заключението, че събитието е свързано с хакерство и Джон Браун отново е замесен.
Ако обаче някоя от тези информации е погрешна или неправилно корелирана, можем да обвиним Джон несправедливо. Ами ако Джон е включил безжичен достъп до мрежовия конектор в спалнята си и друг студент я използва, докато той се опитва да види оценките си? В действителност друго парче информация показва, че Джон дори не е в списъка на класа CS 423. Защо ще хаква сървър с оценки, за да промени своята, за дисциплина, която не е записвал? – Стивън Норткът
Убийци на компании
Злоупотреба със сметки направи това в много банки
Провалите в установяването на наличието и наблюдението на нови акаунти или прекалени привилегии са важен показател за необходимостта от обвързване на дейностите с потребителите и техните роли. Обърнете внимание на следния грандиозен пример.
Един подобен провал доведе през 1995 г. до кончината на уважаваната банка Barings Bank, най-старата търговска банка във Великобритания. Акаунт 88888 бил създаден, за да прикрие грешка, направена от друг член на екипа, която довела до загуба на 20 000 долара. Това било лошо, но станало и по-зле. Ник Лийсон след това използвал този акаунт, за да скрие своите натрупани загуби като вторичен търговец в Сингапур. Когато пушекът се разсеял, Лийсон вече имал 1.3 милиарда долара загуби и в крайна сметка разрушил 233-годишната банка, преживяла войните на Наполеон, както и Първата и Втората световни войни. Всички надзорници на Лийсон подали оставка (под натиск) или били уволнени, когато холандската ING Bank закупува Barings за 1 лира.
Жером Кервиел, търговец във френската банка Сосиете Женерал, имал достъп, който му позволявал далеч да надвишава правата си на търговия на европейския борсов индекс. Той успял да извърши неоторизирани транзакции, които довели до загуба от 4.9 милиарда eвро.
През 2006 г. Кервиел започва серия от фалшиви сделки, примесени с големи истински сделки, някои от които надвишавали капитализацията на банката. Някак си той избягвал нормалните контроли, базирани на времеви периоди, и поддържал баланса на спечелени и загубени сделки така, че да изглежда, че не влияе значително на основите на банката.
Много инструменти за предотвратяване на загубата (изтичането) на данни, както и някои прости скриптове, могат да помогнат да се открива появата на нов акаунт. (Кервиел е пуснат под гаранция и от пролетта на 2008 г. работи като ИТ консултант във френска фирма. – бел. прев.) – Стивън Норткът
Управление на информационната сигурност – що е то
Управлението на информационната сигурност помага да посрещнете предизвикателствата пред нея по отношение на съответствието с нормативните изисквания, управлението на риска, стандартите по информационна сигурност, структурата й, възстановяването на данни при бедствие и др.
Основните моменти, които се отнасят към управлението на информационната сигурност, са:
• Реакция при инциденти или какво да се прави, ако има пробив в сигурността и как да се действа при откраднат лаптоп или при изтичане на данни. Компаниите трябва да разработят план, политика и обучение за реакция при инциденти, както и как да управляват разходите при пробив в сигурността.
• Пазарни тенденции, предвиждания и прогнози, или да сме в течение на тенденциите в индустрията по сигурност, както и с изследванията, прогнозите и анализите на изследователските фирми.
• Управление на доставчиците или как да преговаряме, за да получим продуктите и решенията за сигурност на най-добра цена, как да определяме бюджетите, сливанията и поглъщанията с други фирми.
• Управление на корпоративния риск – измерване и оценка. Какво е необходимо, за да се оцени рискът, да се направи анализ и да се изработи структура на управлението му? Иоще как да се възлагат роли и отговорности, кои са подходящите инструменти, как да се възползваме от стандартите и да автоматизираме процесите, но най-важно е да се реши кое е неприемлив риск.
• Обучение за бдителност към сигурността и вътрешните заплахи или как сигурността на крайните потребители и обученито по бдителност може да предотврати вътрешните заплахи.
• Политики, процедури и наръчници, или как да създадем, управляваме и внедряваме ефективни политики и процедури за информационна сигурност, като приемливо използване, политики за достъп на място и отдалечено и т.н.
• Закони, разследвания и етика – необходима е информация за законите и етичните норми като CAN-SPAM, CALEA, за съдебните практики, за разкриването на уязвимости, за интелектуалната собственост, киберпрестъпността, електронните записи и т.н.
• Планиране на възстановяване след бедствие и непрекъснатост на бизнеса
