10 Января, 2017

SANS: От Log and Event Management к Security Analytics (ч.1)

Александр Кузнецов
Анализируя свежий документ от SANS «SANS 2016 Security Analytics Survey», решил сделать пару шагов назад и проанализировать их материалы в ретроспективе.

По факту в 2013 году данный Survey заменил отчет по тематике «Log Management Survey Report», публикуемый с 2005 года:
«As a result of that survey, SANS decided to focus a new survey on the next generation of security tools—ones that process much larger data sets, are capable of deep-dive analytics, and rely more on intelligence than attack signatures».

В связи с этим решил начать с проведения ретроспективного анализа ключевых положений предшествующих документов, посвященных тематике управления log-ами, а именно:
- SANS Sixth Annual Log Management Survey Report (2010 год);
- SANS Seventh Annual Log Management Survey Report (2011 год);
- SANS Eighth Annual 2012 Log and Event Management Survey Results (2012 год);
- Ninth Log Management Survey Report (2014 год).


В результате решил поделиться уже интерпретированной информацией в рамках нескольких заметок, а именно рассмотреть 3 вопроса:
- причины сбора log-ов;
- источники для сбора log-ов (Log sources);

- сложности, с которыми сталкиваются организации (Challenges).

В начале общая статистика о том, какой процент опрощенных организаций осуществлял сбор log-файлов:
a5f327c44e7cb4eca7869b1180ea2f2c.png

Безусловно, базовый вопрос – это «зачем», в данном случае зачем вообще заниматься сбором log-ов? На практике, очень часто возникают ситуации, когда сбор осуществляется ради сбора, по привычке или т.п.


Причем, к сожалению, данные ответы на вопрос «зачем?» абсолютно инварианты к любой области применения, например, в рамках прошедшего SOC Forum-а я отмечал эти же ошибки в отношении вопросов измерений:
8fd8a94891ec26d39da39606e280a430.png

Но вернемся к рассматриваемому в настоящей заметке вопросу.

В рамках сопоставления во времени причин сбора log-ов (Reasons for collecting logs), к сожалению, не все данные удается сравнить «в лоб», т.к. разные отчеты вводили разные шкалы оценок:
- 2010 – пятибалльная шкала без комментариев (для графика выбиралось значение максимальной оценки, упомянутой в тексте документа);
- 2011 – двухбалльная шкала: Critical и Important (для графика выбиралось значение Critical);
- 2012 – трехбалльная шкала: Critical, Important и Not Important (для графика выбиралось значение Critical);
- 2014 – единственный показатель (он же выбирался для графика).

Плюс при ссылках в отчетах между собой так же возникают разночтения по количественным показателям, соответственно там, где это возможно, выбирались значения из первоисточника.
b9e2b253c0ff34901fc1a532b2dd4258.png

В итоге абсолютным лидером стала причина/задача выявления и отслеживания подозрительного поведения – «Detect/track suspicious behavior».

При этом необходимо дать несколько комментариев, отражающих смещение акцентов с течением времени:

1. В отчете 2010 года есть два отдельных пункта:
- «Detect/prevent unauthorized access and insider abuse» – 63%;
- «Track suspicious behavior» – 31%,
далее, в 2011 году, появилась одна объединенная позиция:
- «Detect/track suspicious behavior and prevent incidents» – 64%,
а в 2012 году уже она разделилась на два новых пункта:
- «Detect/track suspicious behavior» – 82%;
- «Prevent incidents» – 58%.

2. В части расследований есть, на мой взгляд, принципиальное уточнение, которое отражает то, что используемая технология – это всего лишь инструмент:
- 2010 – пункт «Forensic analysis and correlation»;
- 2011 – 2012 – уточненный пункт «Support forensic analysis and correlation»;
- 2014 – сокращенный уточненный пункт «Support forensic analysis».

3. Тематика обеспечения IT так же трансформировалась несколько раз:
- 2010 – отдельный пункт «IT troubleshooting and network operations»;
- 2011 – 2012 – отдельный пункт «Support IT/network routine maintenance and operations»;
- 2014 – дополнительно отдельным пунктом появился «Troubleshooting».

4. В отчете 2010 года тематика, связанная с регуляторикой, была разделена на два пункта (для графика выбрано среднее значение – 40,5%):
- «Meet regulatory requirements» – 41%;
- «Ensure regulatory compliance» – 40%,
далее, начиная с 2011 года, она объединилась в одну позицию «Meet/Prove compliance with regulatory requirements».


Таким образом, на базе данных материалов видно, что позиционирование ключевым драйвером для данной тематики только соответствия требованиям не совсем корректно, и реализация аспектов Log and Event Management направлена в первую очередь на практическую (реальную) безопасность.

Успехов при установлении актуальных для вашей организации причин для сбора log‑ов!


Короткий комментарий про словосочетание «Security Analytics», которое может быть знакомо многим по продукту «RSA Security Analytics»: в 2011 году корпорация EMC (для своей компании RSA, The Security Division of EMC) приобрела компанию NetWitness, и их решение по сетевому мониторингу было взято за основу для SIEM-решения RSA Security Analytics.

В этом году произошло обратное переименование: от RSA Security Analytics к RSA NetWitness (подробности здесь ), это было сделано производителем намеренно, чтобы не путать участников рынка, но это тема для другой заметки.

Продолжение следует …
comments powered by Disqus