Профессионализм vs. Новые идеи

Собирая новую команду мы стремимся найти себе как можно более профессиональных коллег, обладающих многолетним опытом, и сильно переживаем, когда желанных гуру найти не удается. Будучи оптимистом, надо всегда стремиться находить положительное зерно в любой, на первый взгляд, очевидно негативной ситуации. Так и здесь, опыт далеко не однократного набора команд, показал объективные преимущества молодежи перед подразделениями, полностью укомплектованными звездами. А в ситуации, когда вы стартуете что-то абсолютно новое, что ранее никто не делал, напротив, чрезмерный профессионализм может быть даже вреден.

К величайшему сожалению (и даже тех, кто об этом задумывается и понимает), в большинстве случаев наше самомнение в значительной степени обгоняет наш профессионализм. Поэтому вместе с расширением и углублением знаний в какой-либо области, мы теряем способность слышать и воспринимать альтернативное мнение. Я люблю приводить аналогии и верю в повсеместную применимость законов сохранения, - и этот случай не исключение: как чем глубже автомобиль залез в колею, тем труднее из нее выехать, так и чем более профессионален сотрудник, тем сложнее его заставить смотреть на вещи иначе, стимулировать его решать задачи не так, как он привык это делать.

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

Молодые, не обремененные глубоким профессионализмом, мешающим им видеть альтернативы и не бояться изобретать велосипеды, напротив, открыты к новым идеям, способны их слышать и понимать, быстро адаптироваться к новым условиям, а это как раз то, что нужно, если вы делаете что-то новое, идете по ранее нехоженой тропе, и ваш план достижения цели динамично изменяется в процессе движения.

В этом последнем моем посте в уходящем году, я хотел бы нам всем пожелать:

• всегда видеть положительные моменты в любой ситуации;
• становиться как можно более широкими и глубокими профессионалами и, вместе с тем, не обрастать инертностью мышления;
• новых идей;
• отсутствия страха, а напротив, повышения интереса и увлеченности, при виде трудностей;
• удачи и Божьей благодати.

Полечить нельзя форенсить

Наверно, многим читателям этот пост покажется очевидным баяном, однако, к сожалению, мой опыт общения с разными людьми не позволяет утверждать это с уверенностью, поэтому вынужден в очередной раз прибегнуть к созданию поста, который в дальнейшем можно будет давать ссылкой и не тратить много времени на объяснения.

Заметна некоторая путаница в терминах: APT, целевые атаки, вредоносное ПО и т.п., поэтому сразу договоримся: атака - это то, что делается людьми; целевая атака - характеризуется наличием конкретной цели (жертвы), кастомизирована под жертву; APT - крутой маркетинговый термин для целевая атака. Атака всегда выполняется с помощью каких-либо инструментов, которые могут быть как легитимными (их изначальный функционал не предполагает вредоносных, нарушающих КЦД, действий, так и, собственно, ВПО.

ВПО может быть "обычное", "случайно залетевшее", не связанное с целевой атакой - это означает, что за успехом данного ВПО атакующий не следит, т.е. в случае его неуспеха, атака не будет повторяться до тех пока, пока компрометация не будет произведена. Назовет сценарий такого инцидента "Обычная малвара".

Но бывает и иной сценарий - ВПО является кастомизированным инструментом проведения атаки. Тут миллион различных вариантов, но принципиально, что в этом случае за атакой стоит целеустремленный человек, который в случае неуспеха будет пробиваться до последнего, пока цель не будет достигнута. Здесь хорошим сравнением может служить команда пентестеров, которая рано или поздно совершит успешный взлом через тот или иной вектор. Вот это и есть "Целевая атака".

При расследовании инцидентов ИБ принципиально отличать "Обычную малвару" от "Целевой атаки", поскольку принципиально различная реакция требуется.

Обычную малвару можно просто продетектить антивирусом и на этом атака будет исчерпана. Ну конечно, если у вас бесконечные ресурсы форенсеров, вы можете расследовать каждый такой инцидент, а по результатам чинить свою периметровую защиту, чтобы впредь такое не повторялось - будет прямо как по книжкам. Однако, любой кто видел лог антивируса в большом интерпрайзе поймет, что такое количество детектов более чем неразумно подробно расследовать. Компромиссное решение - смотреть статистику за период, выявлять наиболее частые вектора и сценарии, адресовать их в планах развития своей ИБ.

А вот с целевой атакой все наоборот, - обнаружив какой ее компонент просто детектить ее нельзя. Помним, что за ней стоят конкретные люди, которые превосходят в технических познаниях и возможностях нас с вами, бумажных интерпрайзных безопасников, голова которых забита космосом про СУИБ, governance и пр., безусловно, важными вещами, но, как правило, далекими от практической стороны вопроса, - заметив, что мы их стали детектить - они сменят тактику\инструменты\процедуры и мы снова будем вынуждены их искать, или надежно уничтожат свои следы и мы не сможем их исследовать, или обидятся и что-нибудь нам поломают - мы же пока еще не знаем как глубоко они в нас попали и какие у них есть возможности по управлению нашими системами, как они закрепились и т.п. В случае целевой атаки надо проводить полноценное расследование, получить ответы, как минимум, на следующие вопросы:
- как они получают к нам доступ, как осуществляется контроль со стороны атакующего, как устроена С&C, как передаются данные;
- как они к нам попали (вектор проникновения);
- все стадии атаки (для затруднения расследования, уничтожения следов, а также множества других плюсов с т.з. разработки атаки, применяются многоступенчатые комбинации, когда одно [В]ПО запускает другое [В]ПО, которое надежно удаляет первое, которое запускает третье и т.п.);
- какие инструменты они используют, и как все эти компоненты работают совместно, управляются;
- как и где они закрепились, как реализовано обеспечение высокой доступности инфраструктуры атаки (плохие ребята, безусловно, готовы к тому, что их когда-то начнут детектить, поэтому у них есть миллион вариантов, как обеспечить живучесть своей атаки - многократное закрепление с использованием различных техник, взаимный контроль закрепления - сервисы которые поднимают друг друга и перепрописывают правильные слова в конфигах и реестре в т.ч. и по сети и т.п.)

Собрав ответы на все эти вопросы можно спланировать эффективную реакцию, основная цель которой - обрубить все щупальце сразу, чтобы атакующий не смог быстро восстановить свой доступ и был вынужден вернуться на первые стадии килчейна - разведка снаружи или первоначальный пробив. Понятно, что без "dd hdd" на все эти вопросы не ответить, поэтому здесь понадобятся полноценные форенсика, чтобы собрать куски инструментария, информацию о закреплении в системах, какие вектора проникновения выполнены и т.п. (что можно вытащить из форенсики достойно отдельного поста, а может и не одного) и анализ образцов ВПО, чтобы найти другие связанные компоненты, понять где С&С и как передаются данные, понять функциональное назначение каждого компонента и т.п. (также тема очень обширная). Закончив с форенсикой и анализом ВПО можно спланировать реагирование на инцидент, чтобы максимально быстро всех накрыть и атака не успела мутировать. 

Я люблю для пояснения использовать аналогии - здесь подходит аналогия с захватом ОПГ. Чтобы затем не гоняться за ее участниками, каждый из которых может собрать по такой же ОПГ, что явно прибавит работы и увеличит ущерб, лучше придумать как накрыть всех сразу.

"Все здорово", - скажете вы, - "но как же отличить "целевую атаку" от "обычной малвары"? Наверно, и в этом случае отвечать пришлось бы очень долго, однако накидаю первые пришедшие на мысли:
- анализ найденного ВПО - в случае целевой атаки процесс будет превышать одну итерацию: нашел подозрительный образец, отреверсили, достали из него IoC-и (какие-то связанные компоненты, какие-то конфиги, ветки реестра, адреса С&С - да что угодно, по чему можно поискать и быть уверенным, что найденное будет относиться к нашему кейсу), поискали данные IoC-и по всей нашей сети, нашли еще файлы, компьютеры - их тоже отреверсили\отфоренсили, вытащили новые IoC-и - поискали уже по ним и т.п.;
- установленный функционал - что файлик делает, понятно ли вообще на текущем этапе его назначение;
- популярность - видели ли это где-нибудь когда-нибудь у кого-либо раньше;
- пересечения по имеющемуся Threat intelligence - может, что-то совпадает по C&C, по хешам компонент, по поведенческим сигнатурам, по любым другим IoC-ам и атрибутам атаки.

Буквально пару слов про атаки без применения ВПО (возможно, об этом надо отдельно написать поподробнее). Такие атаки находятся исключительно по поведению в тесной коммуникации с владельцем инфраструктуры, ибо здесь без "situational awareness" не обойтись - отличить легитимное использование psexec, teamviewer или powershell-скрипта, запускаемого из Word-а от нелигитимного, к сожалению, можно только спросив. В большинстве случаев нелегальных действий без применения ВПО мы будем иметь дело с целевой атакой.

В заключение, приведу простую последовательность действий (эдакий дайджест из всего, что я выше написал):
1. Если вы что-то обнаружили - начинаем строить цепочку расследования: (то, что обнаружили) -> IoC1 -> (то, что нашли по IoC1) -> IoC2 -> (то, что нашли по IoC2) -> ... .
2. Если цепочка закончилась на том, что обнаружили (нет связных компонентов, функционал понятен и т.п.) - можно просто продетектить\пролечить, как  yet another malware и закрыть инцидент.
3. Если цепочка длинная, то надо пройти ее до конца, вытащив всю информацию об атаке, достаточную для того, чтобы накрыть всех сразу.
4. Придумать как накрыть всех сразу и сделать это.
5. Придумать как защититься в будущем.

Attack Kill Chain

Очевидна необходимость анализа компьютерных атак с позиции Cyber Kill Chain. Как минимум, полезно самим увидеть на каких этапах происходит детектирование - отсюда можно сделать выводы об эффективности тех или иных типов средств защиты информации (превентивных, детективных и т.п.), об эффективности конкретных систем безопасности.
Сама идея - превосходна и стадии, в общем-то правильные, однако, с точки зрения корпоративного мониторинга, как правило, действующего без поддержки всеобъемлющего Threat intelligence-а (в совокупности с телепатией), позволяющего узнавать об атаке практически сразу как о ней подумал атакующий (действительно, едва ли я смогу задетектить атаку на этапе Weapoization, а этап Delivery настолько краткосрочен, что его можно совместить с Exploitaion без ущерба для идеи; а  с другой стороны упущена необходимость атакующему "осмотреться внутри, куда он попал", "повысить свои привилегии" - когда для достижения целей надо быть админом, а проэксплуатировав периметр удалось стать лишь рядовым сотрудником Бухгалтерии). К сожалению, в подавляющем большинстве случаев, об атаке мы узнаем когда нас уже начали атаковывать, или, хотя бы, активно инвентаризировать.
Поэтому, вынужден позволить себе переписать стадии Kill Chain на более, на мой взгляд, приближенные к практике обнаружения атак.

Recon - первоначальная рекогносцировка. Здесь имеется в виду, что меня пассивно (можно заметить только Threat Intelligence-ом) или активно (можно увидеть, например, сканирования) исследуют, чтобы найти потенциально удачные для атаки уязвимые места.
Initial compromise - атакующий эксплуатирует обнаруженную на этапе Recon уязвимость. Это может быть эксплоит, эксплуатирующий техническую уязвимость в применяемом у меня ПО, или социальная инженерия, эксплуатирующие уязвимости в моей программе повышения осведомленности.
Persistence establishment - успешно проэксплуатировав уязвимость, атакующему надо закрепиться в моей инфраструктуре. Здесь можно обнаруживать записи в autoruns, планировщики задач, исталляцию сервисов и пр. техники. 
Privileges escalation - повышение привилегий - также неотъемлемый этап атаки, в рамках которого можно обнаруживать попытки неавторизованного доступа, применение инструментов, атакующих аутентификационные данные и т.п. Этап будет выполняться атакующим, например, для обеспечения lateral movement или обеспечения дополнительных возможностей для достижения конечных целей атаки.
Internal recon - получив возможность перемещения по сети, атакующий ищет свою конечную цель. Здесь можно наблюдать внутренние сканирования, выполняемые уже закрепившимся и получившим необходимый доступ атакующим.
Post-exploitation - когда все сложности преодолены и атакующему остается только реализовывать свою конечную цель атаки. Здесь можно наблюдать уже какие-то сливы данных, исполнение команд, полученных с C&C, а может, и участие в DDOS или майнинг Bitcoin-ов, и т.п.

Как реализовать требования ИБ и не потерять внутреннюю свободу @ZN2016

Вместе с Наташей рассказывали как, оставаясь человеком, контролировать исполнение требований ИБ.
По ходу прощупывали почву для следующих докладов на тему мониторинга инфраструктуры.
Постарались рассказать, что в условиях, когда требования бизнеса первичны, безопасность может существовать и не мешать бежать, но помогать сохранять.

Сам себе Threat hunter @ZN2016

Как обещал на BIS Summit-е на ZN рассказали техническую составляющую тематики Threat Hunting-а, с позиции как это можно сделать самому, при остром нежелании (или отсутствии возможности) приобретения полноценного коммерческого сервиса.
В докладе были затронуты сначала теоретико-процессная сторона вопроса, затем подробно рассказано о собранном лабораторном стенде и, в заключении, продемонстрирован наглядный пример расследования целевой спам-рассылки с последующей эксплуатацией.
Презентация:

Все конфиги: https://github.com/votadlos/ZN2016

Традиционный раздел благодарностей хочется полностью посвятить моему коллеге по выступдению - Теймуру, подготовившему превосходный стенд, на котором демонстрировался презентуемый подход.

IoNA: ADS офисных приложений

Полезно следить за ADS.

Подозрительные с первого взгляда ADS вида "c:\programdata\temp:58a5270d", создаваемые офисными приложениями powerpnt.exe, winword.exe, excel.exe - нормальная активность, если имеет место использование ПО Office Tab.

Охота на угрозы @BIS SUMMIT

23.09 на конференции за 20 минут знакомил аудиторию с проблематикой Threat hunting-а. Тема обширная, говорить о ней можно значительно дольше, поэтому в отведенный тайм-слот имел цель донести почему это нужно и важно. 
Основная мысль презентации выражается примерно в следующем. 
Для того, чтобы сделать сигнатуру защиты от угрозы, необходимо эту угрозу сначала найти и проанализировать. Традиционно компании, занимающиеся исследования в области ИБ и предоставляющие своим клиентам защиту от угроз, вынуждены искать их in the wild. В случае APT поиск ITW зачастую невозможен (ну, как минимум, не очень эффективен), так как ВПО и прочие TTP, используемые в APT-кампаниях отличаются высокой кастомизацией. Именно поэтому для защиты корпорации от кастомизированных атак, необходимо уметь искать угрозы (== Threat hunting) не ITW, а непосредственно в корпоративной инфраструктуре. ТН не является простой задачей, поскольку для этого нужны специализированные инструменты, процессы, опытный персонал. Понятно, что компания, занимающаяся поиском угроз ITW и обеспечивающая для своих продуктов удовлетворительное качество обнаружения/зашиты, сконцентрировав всю мощь своего ТН на конкретной инфраструктуре конкретного предприятия, покажет еще больший Detect rate, ибо законы сохранения работают и здесь: с уменьшением объема анализа, уровень выявления повышается.
К сожалению, природа Человека такова, что ему сложно верить в то, что он понимает плохо, поэтому в презентацию были добавлены несколько тяжелых слайдов о том, как работает ТН изнутри в надежде на то, что эта вершина айсберга будет иметь положительный эффект: усилит веру в ТН и, в то же время, не загрузит окончательно, создав противоположный эффект в виде отвращения.
В завершение были приведены пара обфусцированных случаев из практики - как они были обнаружены и расследованы, несмотря на то, что в одном вовсе не применялось ВПО, а в другом использовались образцы, не обнаруживаемые на момент проведения расследования.
Я искренне надеюсь, что мне удалось просто рассказать о сложном - еще со времен института я считаю эту способность наивысшей добродетелью преподавателя, так как именно это способствует разжиганию того самого интереса аудитории, на котором впоследствии можно добиться небывалых результатов в понимании предметной области. 

Update 31.03.2017
1. Выкладываю презентацию

Охота на угрозы на BIS summit 2016 from Sergey Soldatov

2. Про то же самое еще есть статья в журнале БДИ.

Классификация инцидентов

Вот сколько бы мне не приходилось читать классификаций инцидентов, все мне не нравится и, придумав за долгое время работы далеко не одну классификацию, я снова взялся за старое... - изобретение велосипедов(!), поскольку помимо красоты отчетности с приоритетами, хочется еще извлекать из них пользу, делать выводы, строить прогнозы.

С операционной точки зрения пользой может быть тот самый "triage", необходимый для приоритезации усилий, а при постфактумном анализе, скажем, за квартал, - поможет понять сколько инцидентов какой Критичности, или, если хотите, Приоритета, у меня было за период, чтобы планировать ресурсы на мой Incident Response в будущие периоды более осмысленно, чем ППП.

Проблема всех попадающихся в Google классификаций в том, что они нередко дают противоречивые результаты, что позволяет одному аналитику получить уровень High, другому - Low, и при этом каждому быть правым. Вот давайте попробуем по этому классифицировать это. Если это просто малварь, тогда - Low-Medium, если же это APT, то надо считать High. Причем, все еще интереснее, так как пока это не было исследовано - это было APT, а когда это разобрали и добавили детекты - это уже обычное ВПО :), но не будем этим загружаться.

Следующие характеристики хочется учесть при определении Критичности: тип атаки (что-то совсем непонятное и ранее невиданное ~ APT или целевая работа людей, обычная малвара или просто "нежелательное ПО", админ ошибся или пользователь нарушил что-то и т.п.), факт успешности (если был какой-то инструмент или ВПО - были ли они запущены на жертве или не успели), ну и, насколько это возможно, ущерб (хотя бы в терминах "фактический" - есть подтверждения, что увели деньги, унесли данные и имиджевые потери, ну а если фактов ущерба нет - хотя бы в терминах "большой"\"небольшой".

И вот что получилось.

			Ущерб
			Фактический	Потенциально большой	Потенциально небольшой
Тип инцидента	APT		CRITICAL	HIGH
	Сетевая атака		HIGH	MEDIUM	LOW
	Malware: Trojan, Criptor, etc	Запущено /активно		MEDIUM
		Не запущено /неактивно		MEDIUM	LOW
	Scan, Misuse, Configuration error
	Adware, Riskware, Potentially unwanted program

Если у вас что-то серьезное (APT или по вам шарятся какие-то неэтичные ребята), то это -  HIGH, если предполагается наличие CRITICAL, то должен быть подтвержденный ущерб.
Если у вас просто новая недектируемая (т.к. детектируемую просто убьет антивирус) малвара - MEDIUM, но если она успела натворить Ущерб - надо повышать до HIGH.
Если ошибки пользователей или админов имеют потенциально большой ущерб - это MEDIUM, сюда же можно отнести какие-нибудь рекогносцировки неэтичных ребят, так как они еще не успели начать работать. Если же ущерб небольшой - это LOW. Я не стал рисовать, Misuse с фактическим ущербом, который надо бы классифицировать как HIGH, ибо склонен считать, что админы и пользователи у нас с вами достаточно профессиональны.
Если вы нашли ПО, которое не имеет вредоносного функционала, а просто нежелательно - это LOW.

Сигнатурные и Контекстные ложные срабатывания

Все в этом мире относительно. Именно поэтому для результативности безопасности нам важен контекст, поскольку технологические сигнатуры (не важно на что: на конкретный файл или на последовательность действий) производителем СЗИ выпускаются на среднестатистическую ситуацию, которая может быть сильно различна от инфраструктуры к инфраструктуре. В качестве иллюстрации можно привести сигнатуры на отстуки по C2 ботнетов - это безусловно нехороший знак для рабочих станций рядовых сотрудников HR или бухгалтерии, однако, это вполне может быть ОК для сотрудников подразделений RnD, исследующих ботсети, и для них фиксируемые алерты в контексте конкретной ситуации вполне могут быть ложными срабатываниями. Важным моментом здесь является то, что технологически сигнатура отработала корректно и мячик находится уже на стороне адаптации решения к конкретной среде. Перевод СЗИ из дефолтной конфигурации в адаптированную для конкретной инфраструктуры - очевидная вещь о которой много написано, и сегодня не про это (хотя, в моей практике были комичные случаи, когда я так и не смог убедить в необходимости конфигурирования СЗИ из коробки :) - поэтому, если в необходимости адаптации под свою сеть есть сомнения - этому можно посветить отдельный пост).

Ложные срабатывания косвенно характеризуют качество СЗИ. Поэтому разумно желание отличать ложные срабатывания по причине того, что сигнатура СЗИ работает неправильно - сигнатурные ложные срабатывания от ложных срабатываний ввиду особенностей контекста инфраструктуры - контекстных/инфраструктурных ложных срабатываний. Несомненно, можно придумать еще более ветвистую классификацию, однако, не надо забывать о практическом смысле, дополнительных трудозатрат по учету, поэтому, думаю, на первое время этих двух ложных срабатываний вполне достаточно.

Таким образом получаем, что сигнатурные ложные срабатывания позволяют судить о качестве инструмента, т.е. характеризует работу производителя, а контекстные ложные срабатывания - характеризуют работу подразделений ИБ по интеграции инструмента в конкретную инфраструктуру и степень оперативности учета ее изменений в конфигурации СЗИ. Последовательность действий, направленная на снижение этих двух видов ложных срабатываний, различна, а, следовательно, имеет смысл их отличать.

IoNA: Сетевой трафик winlogon

Рассуждая о безопасности мы часто упоминаем индикаторы компрометации - все те же сигнатуры, все то же перечисление зла. Однако, для понимания происходящего, тем более для хантинга, надо не просто находить по индикаторам, а отличать "нормальное" от "подозрительного"/"не нормального" - для чего надо неплохо разбираться в том, что может быть нормальным. Имея знания о "нормальности" подход будет примитивным и, вместе с тем, вполне себе эффективным: из общего количества активностей убрали все, что "нормальны"/известны, а с оставшимися - явно ненормальными или неизвестными - разбираемся. По результатам разбора можно пополнить свой багаж знаний о "нормальности" поведения - т.е. копить не только IoC-и, но и IoNA - индикаторы нормальной активности :)

Оказывается, процесс winlogon тоже генерит сетевой трафик. Причем эта его активность не вызвана никакими инъекция зловредов в него - это его нормальная активность в случае, если у пользователя смонтированы папки WebDAV. Более того, если у вас используется WPAD, то winlogon пойдет сначала на сервер wpad, получит настройки прокси, а затем с ними устремится подключать шары. Если посмотреть dll-ки, подгруженные в winlogon, демонстрирующий такое поведение, то там можно будет обнаружить компоненты Internet Explorer: %SYSTEMROOT%\system32\urlmon.dll, %SYSTEMROOT%\system32\iertutil.dll, %SYSTEMROOT%\system32\WININET.dll, %SYSTEMROOT%\system32\jsproxy.dll. Сетевой трафик от winlogon можно наблюдать в момент входа пользователя в Windows (== момент подключения сетевых папок WebDAV).

Таким образом, наш IoNA выглядит так:
1. Сетевой трафик (WPAD - если есть, HTTP - на сервер с папкой WebDAV) от легитимного процесса winlogon.exe.
2. Подгруженные в winlogon библиотеки IE.
3. У пользователя подключена сетевая папка WebDAV.

В заключение хочется отметить, что это нормальное поведение может являться неплохим вектором атаки на winlogon, - уже как на клиента Интернет... - время покажет.

Два сценария мониторинга

Несомненно, заслуживает уважения стремление Человечества все автоматизировать. Однако, концептуально непреодолимая проблема в том, что машина не может догадываться (некоторая продвинутость в вопросах машинного обучения заставляет в этом сомневаться , но на практике я не видел полностью автоматических систем безопасности, полагаю, сначала появятся пентестеры-автоматы, и это будет предвестником безопасников-автоматов :) ), а рейтинговые системы порой дают результаты, оспаривающие здравый смысл, что может служить почвой для анекдотов и прочего народного творчества. Поэтому, приходится нехотя соглашаться, что автоматикой мы способны задетектить то, с чем аналитик когда-то разбирался и придумал некоторый алгоритм, как это обнаруживать. Но, очевидная правда в том, что безопасность - бесконечная игра в кошки-мышки, где защищающие постоянно отстают от нападающих и вынуждены уже постфактумно, получив какие-либо артефакты, разгадывать неведанные, тайные и запутанные замыслы атакующих. Поскольку от детских проблем прекрасно спасает автоматика, а кибератака - эффективный инструмент влияния, получающий всю большую популярность одновременно с повышением своей эффективности, мы имеем, что для обеспечения этого эффективного влияния атакующий должен использовать недетские TTP, способные обходить автоматические средства защиты, бить в те места, где автоматика бессильна, обнажая пробельные места в защите.
Вот, как раз, эти-то пробельные места и компенсируются трудом аналитика, проводящего расследования компьютерных атак (== инцидентов ИБ). Широко смотря на проблему разделение задач такое: робот - детектит все то, что известно, а все что не известно - детектит аналитик и учит этому робота, создавая корреляционные правила/сигнатуры и т.п.. Так обеспечивается замкнутый цикл мониторинга, реализованный через симбиоз человека и робота - основа построения комплексной услуги и системного подхода.

На практике это выглядит как два сценария мониторинга. Первый назовем "Alerting" (или "Alerts"). Его суть заключается в том, что под известные TTP, выраженные в цепочках событий\нотификаций систем безопасности (да и любых других систем, способных генерить логи вообще) создаются алерты, свидетельствующие о том, что данная цепочка была обнаружена, а следовательно - обнаружена соответствующая ей атака. Достоверность (% ложных срабатываний) такого алерта будет полностью зависеть от качества цепочки (корреляционного правила, сигнатуры). Здесь задача службы мониторинга - а) понять что алерт - не фолса, б) инициировать процесс реагирования на инцидент и отработки последствий. Этот случай - классический, все, кого я спрашивал о том, что он думает о мониторинге и SOC, - отвечали примерно это.
Второй сценарий, назовем его "Hunting", менее очевидный, но все понимают его необходимость при попытке ответить на вопрос: "Откуда берутся корреляционные правила". Да, сценарий, когда аналитик почитал новости и сделал новую детектирующую цепочку все равно относится к Первому сценарию, поскольку аналитик автоматизировал уже известную атаку. А вот если хочется защищаться от неизвестных атак, обеспечивая комплексную услугу, - аналитику надо самому находить атаки, анализируя неочевидные индикаторы и признаки, совокупность которых создаст подозрения, расследование которых приведет к выявлению новых, ранее не встречаемых ITW атак. Вот это - Второй сценарий, позволяющий создавать эти корреляционные правила, и далее - учить автомат самостоятельно, насколько это возможно, это детектировать и обезвреживать.

Указанные два подхода к мониторингу принципиально отличаются и, вместе с тем, прекрасно дополняют друг друга до единого целого, необходимого, в конечном счете, потребителю. Для Первого можно придумать SLA со временем реакции и временем решения, для второго - нет. Для первого важна реалтаймовая корреляция, что обычно возникает в сознании при слове "SIEM", для второго - важна возможность разнопланового анализа, структурирование в момент поиска, позволяющее одни и те же события в разное время увидеть и интерпретировать по-разному. Первый сценарий - больше operations, оперативная готовность, тогда как Второй - research, планирование и развитие. Оба сценария важны, невозможно добиться желаемого результата реализовать лишь какой-то из них, однако, Второй, как любые исследования, достаточно дорог (нужны люди, инструменты, время), а поэтому может эффективно выполняться, скорее, специализированным компаниям, уже проводящим такие исследования в рамках своей основной деятельности, и поэтому - обречен на аутсорсинг, что, на мой взгляд, - нормально.
Очевидно, что Hunting, применяемый к угрозам ITW, а полученные сигнатуры - к угрозам на данном конкретном предприятии, дает значительно меньший эффект, чем сценарий, когда весь исследовательский потенциал специализированного аутсорсера направлен на Hunting в рамках данной конкретной инфраструктуры, в результате которого созданные корреляционные правила/сигнатуры для данной конкретной инфраструктуры, - именно поэтому он интересен для понимающего заказчика. Hunting атак ITW, сопряженный с Alerting-ом в конкретном предприятии можно сравнить со стрельбой вслепую - если везет, то по направлению предполагаемого противника, тогда как Hunting по данной конкретной инфраструктуре в совокупности с Alerting-ом по ней же, аналогичен прицельному снайперскому огню, эффективность которого, безусловно, выше.

Новые методы эксплуатации инъекций в ORM

27.05 мне в очередной раз посчастливилось выступать на HITB@AMS. Даю ссылку на нашу презу. Также она доступна на сайте конференции. Этот доклад - продолжение темы, подсвеченной на ZN, но более расширенное и углубленное. Заниматься этим подстегивало весьма незначительное количество публикаций по теме, надеемся, нам удастся, хотя бы частично, заполнить этот информационный вакуум.

New methods for exploiting ORM injections in Java applications from Mikhail Egorov

Как обычно, в нашем докладе были демки, которые традиционно доступны на YouTube у Миши, ссылки на видео есть на слайдах презентации, дублирую здесь:
Exploiting JPQL injection against EclipseLink ORM
Exploiting HQL injection against Hibernate ORM with Unicode method
Exploiting HQL injection against Hibernate ORM with Java Constants method

После доклада был вопрос, на котором стоит также остановиться: "Как находить такие инъекции?" Они находятся также как и обычные SQLi, однако, в отличии от них они эксплуатируются несколько иначе. Собственно, доклад как раз о том, как такие инъекции эксплуатировать - предложены методы, которыми можно пользоваться в зависимости от комбинации СУБД-ORM - см таблицу на слайде 81.

Хонипоты в интерпрайзе

В презентации, рассказывая про атаки, я упомянул (этого нет в слайдах, но, по-моему, это было сказано), что с подавляющим большинством атак достаточно эффективно сражаются стандартные средства защиты, типа IPS, антивирусов и пр., и лишь небольшой процент (я слышал цифру ~1%) можно отнести к сложным целевым атакам (aka "APT"), с которыми надо работать как-то по-другому - используя другие инструменты с более глубоким вовлечением именно аналитика. 

Я много игрался с хонипотами, но потребность в них по-прежнему не очевидна. Просматриваются две основные идеи их применения. Во-первых, это может замедлить потенциальную атаку, о чем с некоторой подменой смысла повествовалось в статье уважаемого института. Однако, беря во внимание первый абзац этого поста, если мы имеем дело с "типовой" атакой, мои "стандартные" средства защиты прекрасно с этим справятся и без хонипота. Если же мы имеем дело с профессиональной атакой, то такой злоумышлениик раскусит наш хонипот за время, едва ли имеющее важное значение в общем таймлайне атаки. В этом случае, эффективность хонипота сводится к эффективности стандартной IDS - просто обнаружить то, с чем далее надо разбираться. Следует признаться, что когда в Амстердаме мы показывали видео про то, как ловить "хакеров" с помощью kippo, народ в зале отметил, что демонстрируемое поведение позволяет судить о далеко не высоком профессионализме атакующего. Если же мы будем разворачивать более хорошую эмуляцию (high-interaction honeypots), то это - полноценная новая система, которая, по Закону сохранения, утянет ресурсы, которые было бы куда более разумно потратить на обеспечение безопасности реальных информационных активов. Итого, от сложных неизвестных атак мы этим не защитимся, от известных - поможет "антивирус" (далее буду использовать как собирательный образ типовых привентивных технических средств обеспечения безопасности).

Второй задачей, решаемой хонипотом, обычно называют возможность исследования атаки: пока злоумышленник понимает, что он атакует хонипот, мы собираем эвиденс, который позволяет нам расследовать что происходит. Понятно, что едва ли нужно расследовать типовые атаки, где "антивирус" все заблокирует... Однако, хонипот не нужен и для сложных атак, поскольку, а) как было отмечено выше, его быстро раскусят, б) в случае необходимости расследования сложной целевой атаки у нас есть неотъемлемый "хонипот" - вся наша инфраструктура и приложения. Поэтому не надо сразу кидаться все вычищать, надо сначала понаблюдать и разобраться - это позволит избежать потенциальных проблем и радикально повысить эффективность вашего респонса. Об этом пишут все умные книжки про Incident response и об этом же говорил коллега в презентации (шикарная, на мой взгляд преза, полезно ознакомиться) - прежде чем кидаться в бой, надо максимально изучить противника (ну, безусловно, надо смотреть по обстоятельствам, не надо злоупотреблять "созерцанием и ничего не деланием", никогда не надо перегибать палку, красота - посередине). Итого, для исследования сложных атак в интерпрайзе хонипот тоже не нужен, так как все самое нужное и актуальное можно собраться собственно с защищаемой сети. А для "типовых" атак - достаточно, что хонипоты или любые другие подобные эмуляторы есть у производителей систем "антивирусов", которые я использую, и они регулярно и своевременно поставляют мне сигнатуры, защищающие меня от ~99% зла. 

Мониторинг своими руками

Выкладываю презентацию с CISO Forum 2016.

Мониторинг своими руками from Sergey Soldatov

Соответствие Спроса и Предложения

Так сложилось, что сегодня, общаясь с приятелями, я в разном контексте и абсолютно от разных людей услышал, по сути, один вопрос - почему, несмотря на то, что мы все тут CISO встречаемся и, вроде как, друг друга понимаем, читаем одни и те же книжки, однако, как правило, на предприятии все наоборот: культивируем перегибы, охотимся на ведьм, осваиваем бюджеты, вместо решения конкретных задач... - в общем, делаем типовые действия по инерции, ошибочность которых вполне очевидна. Я не раз утверждал, что Умный учится на своих ошибках, и поэтому не отвергаю необходимость хождения по граблям, однако, сколько же можно делать одно и то же!? А ответ прост - столько, сколько соответствует нашему пониманию. К сожалению, единственный инструмент дифференциации "правильно" от "неправильно" - это наше понимание действительности, этакая наша собственная Модель зрелости. Говоря максимально предметно: чтобы понимать, что "правильно" - это  на самом деле правильно ("правильно" - то, что лучше адаптировано к фактической действительности), нужно иметь определенную Модель зрелости, наша Модель зрелости - характеризует нашу способность выбирать из возможных вариантов развития наиболее правильный. В целом, это то же, что опыт и профессионализм, однако мысль поста - другая, а именно - для осознания действительной необходимости того  или иного продукта (не важно, будь то коробка или сервис) нужно иметь определенную Модель зрелости. Не достигнув определенной модели зрелости мы не будем в состоянии выбрать правильный продукт, а если даже выберем, мы не сможем его использовать эффективно. Как не странно на первый взгляд, второй исход для производителя еще более неудачен - его продукт будет неэффективен и никто не будет разбираться в причинно-следственной связи о том, что его не умеют использовать, или используют неправильно, или не использую вовсе. Тень неудачи продукта в конкретном случае упадет на производителя и мы получим эффект отсутствующей плитки.

В то время, когда я поступал в институт, на вступительных экзаменах по математике к разряду сложных относилась задача на минимизацию чего-либо: дана какая-то геометрическая фигура, в ней проведены какие-то замысловатые линии, которые соединены каким-то отрезком, задача - определить минимальный этот отрезок. В целом, в математике есть неплохой инструмент для эффективного решения таких задач - производная. В основной программе школы в то время (сейчас не знаю) не было производной, поэтому абитуриент был не обязан это знать, и вынужден был решать задачу геометрически... такое решение, безусловно, можно было бы найти, однако это более чем неэффективно и по трудозатратам и по "красоте", но можно, хотя и больше напоминало бы историю о необходимости спалить лес для приготовления яичницы. Я был "продвинутым" и в 11-м классе я знал что  такое производная и как этим пользоваться, поэтому задача для меня свелась к построению функции и ее исследованию через производную.

Ровно также и в жизни: чтобы приобретать эффективные продукты (сервисы и\или технологии) надо, как минимум, понимать что они есть и в чем их эффективность перед другими, возможно, имеющими даже аналогичную классификацию, а дополнительно - надо уметь ими правильно пользоваться, чтобы продукт раскрывался на все 100% своего функционала, показывая максимальную эффективность и результативность. 
К сожалению, как невозможно первокласснику объяснить все преимущества производной, так и безопаснику на определенном уровне своей Модели зрелости невозможно объяснить необходимость того или иного продукта. Очень важно понимать, что это и не хорошо и не плохо. Очевидно, почему это плохо, - потому что действительно качественные решения остаются аутсайдерами, поскольку способность понимания этого качества предъявляет определенные требования к потребителю, который действительно должен быть профессионалом. Но это и не плохо, поскольку, как я отмечал выше, профессиональный инструмент в неумелых руках, как минимум, не приносит ожидаемого эффекта (что плохо для производителя!!), а, как максимум, может сотворить беду, поэтому пускай лучше автоматом пользуется тот, кто умеет из него стрелять, а мартышка никогда не примеряет очки.
Еще один важный момент для понимания, что, как правило, руководитель имеет команду, соответствующую ему по пониманию действительности. Относительно этого поста это означает, что, как правило, и руководитель и подчиненный имеют одну Модель зрелости. Различие в Модели зрелости приведет к тому, что либо подчиненный сам уволится, потеряв надежду выровнить с собой руководство, либо руководство уволит невыравниваемого с собой подчиненного. Работающие долго команды, как правило, имеют одну Модель зрелости. Это не стоит понимать буквально, что набор предметных знаний руководителя и подчиненного одинаков, но он эквивалентен с учетом уровня позиции. Поясню проще: CEO подбирает CISO эквивалентного своей Модели зрелости в области безопасности на уровне CEO, т.е. если для CEO безопасность - это антивирус, на позицию CISO будет взят человек с таким же концептуальным пониманием, но, может быть, с более глубокими техническими знаниями, например, тот, кто был админом антивируса в бэкграунде. CISO, который будет "на другой волне" не пройдет по квалификационным требованиям, даже если он будет говорить правильные вещи, очевидные с точки зрения более высокого уровня Модели зрелости (понятно, что под уровнем Модели зрелости здесь следует понимать степень приближенности к фактической действительности). Здесь этот несчастный, своеобразная белая ворона, может быть сравним с Гигантами прошлого, чьи изобретения и произведения искусства опережали свое время и не были по достоинству оценены при жизни авторов.
В общем, идея понятна, теперь давайте разберемся что же можно сделать творцам шедевров, чтобы потребителям, находящимся на уровне ВАЗ2106 уметь предоставлять BMW5.
1. Если вопрос себестоимости просто не стоит (понятно, что делать BMW дороже чем Жигули), то можно про BMW говорить категориями, применимыми к Жигулям. Т.е. свой высокотехнологический продукт продавать в "обертке", понятной потребителю (~махорка американская). Понятно, что для разного потребителя "обертка" будет разная. Причем здесь нет никакой лжи - это аналогично изложению на понятном языке.
2. Если вопрос себестоимости стоит, то здесь надо бить на компоненты и группировать их в пакеты, соответствующие разным Моделям зрелости. При переходе на новую Модель - предлагать новые фичи. Да, да, комплектации продуктов надо компановать не только на основе каких-то сценариев использования, но и на основе потребностей (способностей понимания, Модели зрелости) потенциального клиента. Не надо предлагать сигары тому, кто курит махорку и т.п.
3. Ну и, конечно, надо бороться с невежеством. В понятной доступной форме объяснять проблематику и рассказывать о том, как эти проблемы могут быть решены - так будет повышаться Модель зрелости потребителя, и это позволит нам всем в целом повысить среднюю Модель зрелости в отрасли и тем самым сделать Мир лучше!

Аутсорсинг мониторинга и реагирования на инциденты

Вчера общался с коллегами на тему SOC.
Наиболее любопытной мне показалась все еще актуальная проблема распространенности категоричного взгляда на вещи. Да, мы все постоянно твердим, что Мир не черный или белый, а серый, причем весьма неравномерно. Однако, эта простая аналогия, почему-то, не способствует вытеснению безапелляционных мнений о невозможности аутсорсинга безопасности, или ИТ, или их части.

Известно мнение о принципиальной разнице подхода Великих и Обычных. Обычный - находит в себе слабые стороны и пытается их развить до среднего уровня. Великий - пытается найти в себе сильные стороны и развить их до максимально возможного совершенства. Нетрудно догадаться, что стратегия Великих дает больший результат с несравненно меньшими усилиями. Однако, почему-то, классическая литература и классическое образование культивирует в нас мнение, что надо идти путем Обычных: находить в себе слабости и пытаться с ними бороться.... Далее не хочется эту развивать на масштабы истории и будущего Человечества, - может, как-нибудь позже я об этом порассуждаю, сделав очередной общественно-значимый пост, возможно, и без очевидной связи с ИБ.

Из этой, т.н. "Стратегии Великих", важно понять, что принцип использования и развития сильных сторон актуален и применительно к аутсорсингу. Не надо заниматься тем, что не есть ваша сильная сторона, и сокрушаться по этому поводу. Особенно неразумно этим заниматься, если есть кто-то доступный, кто делает это много лучше. Но правильно заниматься тем, что является вашей сильной стороной или тем, что никто кроме вас не сделает. Последнее (на всякий случай сделал его курсивом) должно стать принципом вашего планирования развития.

Не надо заниматься анализом малвари самому, когда есть антималварные вендоры, которые делают это много лучше. Не надо бороться с проблемами мировой кибер-безопасности, но займитесь своими внутренними делами. С профессионалами должны иметь дело профессионалы. С вас достаточно умения поставить задачу и принять результат. Да, это предполагает определенные знания, но, я вас уверяю, их недостаточно, чтобы это делать самому на профессиональном уровне.

Итак, что же получается. 
Сильные стороны интерпрайзной ИБ: 
- она знает чего боится - понимая свои корпоративные бизнес-процессы она понимает что критично, может правильно расставить приоритеты и сформулировать цели;
- она знает свою инфраструктуру и приложения, что позволяет понять потенциальное "поле боя";
- она знает своих работников - вопросы кадровой безопасности, лояльности сотрудников очень важны и это обязательно следует анализировать (немного этой темы я коснулся здесь);
Очевидно, что все эти сильный стороны корпоративной ИБ - слабые стороны аутсорсера, но, с другой стороны, профессиональный сервис:
- видит глубже и шире проблему, поскольку у него больше опыта, он от большего количества клиентов имеет данные, поэтому "новая" для вас атака, может быть известной для профессионального сервиса, а вместе с тем известным станет и контекст атаки - цели атакующего, инструменты, TTP; да и вообще, понимание того видите ли вы атаку или легальную активность для профессионального сервиса много четче;
- профессионален в специальных областях: пентест, реверс, форенсика, анализ малвари и т.п., поскольку эти ребята изо дня в день это делают, и это - их основная работа.

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

О сборе логов

В условиях современной действительности приходится констатировать, что все интерпрайзы можно поделать на два типа: те, которые знают, что их скомпрометировали, и те, кто об этом пока не догадывается. Связано это с некоторой нестыковкой "классических" подходов к обеспечению безопасности с текущей реальностью. "Классический" подход рекомендует нам иметь алерты реального времени на все возможное зло, на основании которых мы будем предпринимать, также, почти в реальном времени, определенное реагирование. Еще одной характеристикой "классики" является приоритет превентивных мер - рубить канаты как можно скорее: прервать неправильную деятельность как можно раньше. Данный подход прекрасно работает, когда определено что такое "зло" т.е. точно детерминирован алерт, а также, рубя канаты, есть уверенность что именно ты прерываешь и какая под этим мотивация. Ужасными последствиями такого "классического" подхода являются: 
а) непродолжительное хранение логов в системе мониторинга, поскольку данных нужно не более, чем достаточно для генерации алерта, который, напомню, генерится в реальном времени (тут следует отметить, что предположение о том, что логи можно оставлять на самой системе для дальнейшего анализа с точки зрения любого подхода, и классического, и не очень, является полным бредом - логи всегда надо уносить, чтобы, потеряв систему, не потерять историю ее болезни и кончины), 
б) нехранение "сырых" логов, а только "мета-событий", сформированных из них "на лету" на основании некой логики, известной на момент настройки алерта, несущий в себе фиксированное понимание вредоносной активности и мотивации злоумышленника (поскольку только в этом случае можно придумать эффективное реагирование, а само наличие алерта предполагает, что должно быть и реагирование).

Появление целенаправленных сложных атак дало нам понимание, что 
а) скорее всего мы не увидим эксплуатацию, поэтому приоритезировать усилия разумнее на как можно более раннее обнаружение постэксплуатации, 
б) скорее всего не стоит сразу "рубить концы", но потратить время на исследование\расследование атаки, что позволит понять мотивацию и выработать более эффективные защитные мероприятия (ну конечно типовые вещи должны сразу идти на типовой маршрут отработки, речь - о нестандартных ситуация, которые пока еще не исследованы и не переведены в разряд "типовых"),
в) обязательно надо иметь возможность разностороннего ретроспективного анализа логов, так как на момент обнаружения нет понимания что это мы наблюдаем и зачем это делается, поэтому не понятно где и в каком виде это может проявиться.

Адаптируя свой лог-менеджмент к этой новой парадигме получается примерно следующее:
а) собирать логи надо все и обрабатывать централизованно (т.е. искать по всем сразу), поскольку едва ли удастся угадать где что полезного можно будет обнаружить в рамках расследования,
б) хранить именно сырые логи и иметь возможность в будущем их по-разному анализировать, - технологии атак меняются, меняются и подходы их обнаружения и расследования, а раз так, то надо иметь возможность делать различные выборки, по-разному отображая одни и те же данные; иными словами, по мере расследования я буду получать все новую информацию, которая позволит мне строить более точные запросы к данным и доставать все новые детали,
в) хранить логи надо долго, так как, обнаружив сейчас постэксплуатацию, надо уметь ее "отмотать" на неопределенно долгий срок назад, с целью понять "как это было" и "с чего все началось", чтобы, в конце концов, имея целостную картину, выработать эффективное противостояние.

Получается, что в таких условиях задача службы мониторинга уже не просто "как можно раньше прокукарекать и заткнуть все, что получится", а именно расследовать с целью выработки более эффективных мер. Тут хорошая аналогия вспоминается из практики: в логах антивируса фиксировалось постоянно заражение и успешное лечение одной и той же рабочей станции. В целом, можно было бы забить - заражение завершалось успешным лечением, однако несложное исследование показало, что дроппер не обнаруживался этим антивирусом, причем сидел уже настолько хорошо, что самые свежие сигнатуры были ни по чем, а то, что успешно лечилось - это уже его "полезные нагрузки" и вопрос был только в некотором временном лаге, когда-таки прилетел бы "правильно запакованный\пересобранный" малварь, приведший уже к последствиям, совпадающим с мотивами злоумышленника. Этот банальный пример показывает, что здесь мы видим именно постэксплуатацию, ибо прошляпили как залетел и как закрепился дроппер. Анализ проводился на большом периоде, поскольку попытки закачать "полезную нагрузку" не были чаще чем раз в день, причем разброс по времени был случаен. Но уже потом, вытащив дроппер, было интересно поискать его следы в логах Web-прокси, почтовой системы, пошариться SCCM-ом и антивирусом по всем десктопам в интерпрайзе, поискать его в логах системы контроля доступа к периферийным устройствам и вообще везде, от чего у нас есть логи (очевидно желание все это сделать одним поиском). Причем, с учетом того, что "грамотный" дроппер, закрепившись, не стал бы палиться сразу, ретроспективный анализ следов его залета к нам необходимо проводить на неопределенной глубине данных.

Конечно, Истина где-то посередине, поэтому из этого поста совсем не должно делать вывод о полной бесполезности оперативной готовности, совсем нет, просто неправильно полагаться исключительно на нее. В одном из проектов построения системы мониторинга, некие архитекторы делали глубину хранения логов 1 месяц, типа "...нам нужна глубина не более, чем необходимо для формирования алерта на основании которого админ далее полезет на "проблемную" систему и будет там что-то чинить..." - вот так не надо рассуждать.
 

Сканеры уязвимостей@Enterprise

Следуя правильной причинно-следственной логике, прежде чем выбирать инструмент решения, следует понять задачу. Очевидно, сканер уязвимостей нужен для поиска уязвимостей, чтобы их потом латать и так, постепенно, улучшать свои ИТ-системы в предположении, что минимизация уязвимостей == повышение безопасности, наверно, это так и есть. 
Ранее, мы разбирались с уязвимостями (кому лень читать, можно послушать), в совокупности с предположением, что в компании не разрабатывается ПО, с необходимостью сканера не все понятно. 
Вообще, аудит мне подтверждает две вещи: что я делаю правильные вещи, и что я делаю эти вещи правильно. Второе - это аудит соответствия. Первое - пентест, этакая Зарница,  в идеале, может, даже и без оповещения, что мы в состоянии игры. Как я не раз отмечал, в большом интерпрайзе управляемость - один из важнейших моментов, а следовательно, обычно, есть централизованные системы управления элементами ИТ-комплекса, типа SCCM, выполняющих любые виды инвентаризации. Чем вам такая инвентаризация не аудит соответствия? Сейчас уже у любого производителя есть руководство по безопасной настройке, так называемые hardening-гайды, - аудит соответствия такому гайду легко автоматизировать, да и многие производители имеют автоматизированные инструменты, которые проверят соответствие (некоторые потом даже предложат и исправить) - совсем нетрудно дергать такие проверялки при инвентаризации. В общем, очевидно, уязвимости конфигурации средствами инвентаризации легко закрываются. 
Но закрываются и ошибки разработчиков, поскольку уязвимости коммерческого ПО решаются для интерпрайза единственным образом - установкой патчей. Если я имею дело с 0-day, то такие риски компенсируются другими "эшелонами" моей безопасности: сегментацией, "навесными" средствами с разными модными технологиями, типа "virtual patch", контролем доступа, постоянным мониторингом и пр. К тому же, если производитель нормальный (я рекомендую, и от души желаю, работать только с нормальными производителями), скорее всего он выпустит какие-нибудь рекомендации, что нам всем делать, пока он не выпустил патч. Производитель, в софте которого вы нашли уязвимость, а затем безрезультатно закидываете его enhancements request-ами с требованиями исправить проблему, - не достоин называться "нормальным", поэтому неразумно держать сканер исключительно для таких случаев.
Перейдем к пентестам. Здесь мы пытаемся удостоверитья, что мы делаем правильные вещи. Безусловно, здесь уже нужна автоматизация... Но, в случае уязвимости конфигурации - эксплуатация тривиальна, как правило, можно и не пробовать, а в случае уязвимости ПО - вопрос эксплуатируемости, обычно, исследован вендором, и этому исследованию можно и нужно верить, а проверять экплуатируемость сканером - ну разве что только из спортивного интереса - насколько хорошо производитель сканера реализовал эксплоит. Более того, исследовать вопрос насколько правильные вещи я делаю, мне едва ли нужно часто. А раз так, то, наврено, эффективнее нанять профессиональную команду, где натренированные практики будут использовать десятки инструментов, чем я-любитель буду в автоматизированном режиме использовать один, имеющейся у меня сканер.
Прниципиальная вещь: сканер не находит неизвестные уязвимости и вряд ли найдет больше, чем известно "нормальному" производителю исследуемого ПО.

Любопытно, что даже если я разрабатываю ПО, мне тоже едва ли подходит off-the-shelf сканер, - значительно эффективнее будет работать моя продуктовая безопасность, которая знает мои продукты лучше производителя сканера и имеет специализованные инструменты, адаптированные под мою продукцию, понимает, что дейстительно критично и поэтому может правильно расставлять приоритеты.

Подводя итог всему написанному, хочется все-таки понять, когда же мне нужен сканер:
0. У меня огромный разнородный ИТ-комплекс, поэтому мне невозможно детально разбираться с каждым, используемым у меня производителем (заниматься харденинком его решений), мне проще запустить комбайн, который на приемлемом уровне решит проблему (ну или хотя бы сделает что-то, что лучше, чем ничего).
1. Я не знаю свою инфраструктуру. Отсканировал - получил какое-то представление (почти п.0, но с условием необходимости быстрых результатов при отсутствии времени).
2. У меня нет систем управления ИТ-инфраструктурой, поэтому я это компенсирую сканером, реализовав следующий процесс управления ИТ-инфраструктурой: отсканировал --> нашел узявимости --> устранил --> отсканировал --> ...
2,5. У меня плохие отношения с ИТ, поэтому я не могу использовать их системы управления ИТ-инфраструкурой и должен обязательно иметь свою штуку.
3. У меня стандартные системы, чтобы в сканере под них были сигнаруты\профили.
4. Я не хочу разбираться с безопасной настройкой каждой из используемых у меня систем, мне удобнее иметь комбайн, который все мои ошибки конфигурации (в целом, отсутствующий патч тоже можно считать уязвимостью конфигурации) найдет мне в виде уязвимостей (тоже почти п.0, но при отсутствии объективной невозможности разобраться с рекомендациями производителей, я просто лентяй).
5. Меня вынудил комплайнс, требующий от меня наличия сканера, или инструмента управления уязвимостями, или еще чего подобного.
6. У меня есть желание поразвлечься - посмотреть эксплуатируемость стандартных уязвимостей (== доступных в сигнатурах\проверках сканера)
7. Я хочу\должен кому-то что-то продемонстрировать или доказать, сделать вау-эффект, или эффективность моей работы характеризуется количетсвом найденных уязвимостей.
8. Сканер - это мой инструмент situational awareness (что-то около п.1) - фундаментальное требование для эффективной работы SOC.

На практике мы, конечно же, имеем комбинацию перечисленного + что-то уникальное, до чего я даже не догадываюсь.
 

Сертификация аутентификации

...при сертификации не ищутся уязвимости - она всего лишь подтверждает функционал продукта и его соответствие требованиям регулятора.

Алексей Лукацкий

Отличный пост Алексея: все подробнейшим образом рассказано, объяснено, даны ссылки на руководящие документы, ... - методически и систематически все на высшем уровне.

Но почему-то остается ощущение какого-то чеквалапства: создана целая система, потребляющая немало инвестиций, однако выхлоп - небольшой. Попробую разобраться.

Есть, например, такое требование: "МЭ должен обеспечивать идентификацию и аутентификацию администратора МЭ при его локальных запросах на доступ". Аутентификация, с точки зрения их же, регуляторов, терминов: "Проверка принадлежности субъекту доступа предъявленного им идентификатора; подтверждение подлинности". Можно предположить, что принадлежащим субъекту идентификатором в контексте данного определения считается пароль, который пользователь сам себе назначил (==известен только ему). Из чего, несложно понять простую логику: если пользователь проходит проверку принадлежности ему идентификатора, предъявляя системе идентификатор (пароль), ему не принадлежащий, то такое поведение системы нельзя считать обеспечением аутентификации. Говоря совсем просто: аутентификация, работающая с ошибкой, приводящей к НСД, не может называться аутентификацией, ибо сама по себе нужна лишь для того, чтобы НСД не было. Итого: в устройстве нет аутентификации, подтверждение ее наличия сертификатом - ошибка, из которой надо извлечь соответствующие уроки...

Конкретно в этом случае все было еще хуже, приведу цитату: "The argument to the strcmp call is <<< %s(un='%s') = %u, which is the backdoor password, and was presumably chosen so that it would be mistaken for one of the many other debug format strings in the code. This password allows an attacker to bypass authentication through SSH and Telnet. If you want to test this issue by hand, telnet or ssh to a Netscreen device, specify any username, and the backdoor password. If the device is vulnerable, you should receive an interactive shell with the highest privileges", так как я во-первых, предъявляя не свой пароль успешно аутентифицируюсь, а во-вторых, после этого я еще и авторизуюсь максимальным админом, ну, как минимум, не с полномочиями, указанного при аутентификации аккаунта.

... но вернемся к извлеченным урокам....
Вообще, внедряя процесс и инвестируя в него, необходимо всегда помнить цель, не надо инвестировать в тот процесс, который не приводит к цели, или степень приближения к цели не оправдывает инвестиций. Цель сертификации - подтверждение качества товара, защита потребителя. Если какой-то из видов сертификации этой цели не достигает, или достигает не нужной не той цели, в ней нет смысла => ее надо или изменить, или отменить. Если любая из заявленных функций может быть скомпрометирована наличием НДВ, так давайте оставим только сертификацию на НДВ. Отзыв сертификатов, при этом, - тоже нормальное решение ("не пойманный - не вор" - неподходящий в этом случае принцип), если практика показала, что в сертифицированном на НДВ продукте все-таки нашлись НДВ, логичны два последствия: а) отзыв сертификата, б) lessons learned для процесса сертификации - это нормально, так как ничего не стоит на месте и подходы к сертификации подтверждению качества продукта также должны эволюционировать.

ЗЫ: вот и Фортинет порадовал. Я когда-то в шею гнал разработчиков, хардкодящих пароли, а вот, оказывается, это общая практика....