Модульный подход к эксплуатационной документации

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

Детализация описания конфигурации

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

Сразу оговорюсь, что я здесь не буду цитировать какие-то ГОСТ-ы, ISO и т.п., а покажу минимальный набор документов, полезный с практической точки зрения и попытаюсь объяснить свое мнение. Касательно контента документов и их детализации, понятно, что все здесь примерно, возможны перекрытия и углубления в детали, однако я пишу о минимальных потребностях, чтобы вся эта история с проектами вообще работала, понятно, что если где-то будет больше конкретики, чем необходимо - это, скорее, не повредит, и ничего страшного, если будут повторы (хотя копи-пейста, из документа в документ, конечно же, надо избегать!)

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

Пришел Подрядчик, и уже в рамках проекта на основании потребности, изложенной в ФТТ, он разрабатывает Техническое задание (ТЗ). В целом, под ТЗ нормально понимать детализированное ФТТ, поэтому особенности следующие:
- более технический документ;
- определяет уже из чего будет делаться целевая Система (исходные материалы);
- скорее всего (так и надо делать - это правильная практика!), было проведено какое-то обследование (~понимание среды/условий, уточнение требований из ФТТ), поэтому помимо требований к результату указываются требования к проектированию, причем уже с учетом выбранных исходных материалов;
- степень детализации - максимально возможная - результат и важные моменты в рамках проектирования должны быть учтены до мельчайших потребностей.
Важно: Поскольку ТЗ полностью определяет что должно получиться в результате, а, при грамотном подходе (со стороны Подрядчика), может определить и ключевые моменты проектирования, чтобы не иметь проблем с возможными изменениями потребностей Заказчика по ходу проекта (ведущим к изменению объема) - проектирование следует начинать только после полного согласования ТЗ.


ТЗ является исходным материалом для процесса проектирования, в рамках которого разрабатывается Технический проект (ТПр). ТПр:
- полностью технический документ;
- определяет КАК мы будем делать нашу Систему из выбранных исходных материалов;
- степень детализации ТПр должна быть достаточной для того, чтобы превратить исходные материалы в Систему, полностью соответствующую ТЗ и ФТТ; Фактически под ТПр можно понимать детальный план такого приведения - действительно сначала дешевле поупражняться "на бумаге", а уже потом, все 7 раз отмерив, пойти работать ручищами "на железе".
Будучи результатом раздумий "на бумаге" ТПр - это то, "что хотели" получить. Еще важно, что ТПр - во всех подробностях описывает процесс перевода исходных материалов в желаемую Систему.

Закончив проектирование и написав максимально подробный ТПр можно переходить к разворачиванию\внедрению\настройке Системы, т.е. превращению исходных материалов в нашу Систему, соответствующую ТЗ и ФТТ уже в полях.

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

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

Как правило, в эксплуатационной документации полезно иметь следующие документы:
- Технический паспорт (ТПс);
- Инструкция пользователя (ИП);
- Инструкция администратора (ИА) - если администраторов несколько может быть несколько ИА для всех возможных групп сопровождения, можно и совместить все эти инструкции в одном документе - тут как удобнее организовать использование этих документов;
- Регламент обеспечения непрерывности бизнеса (РОНБ или BCP-DRP).

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

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

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

РОНБ должен содержать подробненькое описание процедур восстановления из резервных копий и всяческих других применяемых механизмов обеспечения непрерывности. Из РОНБ должно быть однозначно понятно к каким типам несчастья мы (вся группа эксплуатации) готовы и что в этих случаях мы делаем применительно к нашей системы.
На заметку: при приемка подобного документа полезно проводить упражнение по полной симуляции наиболее страшного несчастья - "... а ну-ка давайте грохнем файлы данных БД из-под СУБД и попросим наших админов восстановиться по вашей эксплуатационной документации в заявленные вами 3 часа..." - всегда лучше поупражняться сейчас, почти еще в проекте, чем потом, когда беда придет "на боевом дежурстве".
Еще: если сервис супер-критечен и его падение смерти подобно, то полезно не только заниматься тренировкой админов, но и пользователей (вообще, конечно, BCP-DRP тема обширная и даже не отдельного поста, а целой книги (!), тем более не рассказать ее в абзаце). Например, если у вас есть трейдеры которые должны постоянно торговать вашими продуктами на всяких биржах через Интернет, можно подумать о том, что на период недоступности нужной им ИТ-инфраструктуры их можно отправить домой с ноутом и быстрым мобильным Интернетом или посадить в автобус с теми же ноутами и хорошим wi-fi-ем в салоне и прочими минимальными ИТ-сервисами, и увезти туда, где пока еще спокойно и откуда можно продолжать крутить колеса корпорации (причем, куда везти также должно быть хорошо продумано заранее, чтобы минимизировать необходимость придумывания решения по ходу).
Да, еще момент, можно, в принципе, размазывать РОНБ по инструкциям администраторов и пользователей, но, я вас уверяю, лучше, чтобы в час Х все было под рукой, в одном месте, причем, наличие единого Плана придумали задолго до этого поста (возьмите любой гайд для подготовки, например, к CISSP).

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

И последнее - простой пример.
ФТТ: Бизнес: "Нужна деревянная кукла!"
ТЗ: мы должны получить Буратино из сосны, он должен передвигаться, издавать звуки, "думать", в меру возможности.
ТПр: идем в лес, находим говорящую сосну, вырубаем из нее полено, несем в столяную мастерскую, обрабатываем топором, рубанком, наждаком.... рисуем лицо и все остальное... одеваем на "голову" носок.... отдаем в школу....
ТПс: Буратино, сделан из говорящей сосны, полные ТТХ и т.п.
ИП: играть на шарманке, подпевать....
ИА: царапины зачищать наждаком, глубокие - рубанком, сколы красить, подрисовывать лицо по мере истирания, кормить луком раз в месяц....
РОНБ: утерянные конечности восстанавливаются так-то с использованием остатков говорящей сосны, в случае тяжелых потерь - есть 17 братьев-близнецов, полностью обученных и упакованных аналогичным образом, приводимых в рабочее состояние так-то...

Пентесты на рынке

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

Как я отмечал 4 года назад у пентеста и аудита соответствия разные цели, соответственно, разумно их применять для решения разных задач. Во-первых, я вижу мало смысла в пентесте коммерческого продукта: зачем мне финансировать исследования безопасности, скажем, Microsoft, - достаточно того, что я честно купил их продукты и исправно плачу за поддержку!
Во-вторых, между обнаружением уязвимости и ее успешной эксплуатацией - огромная разница, стоящая подчас колоссальных ресурсов. Отчасти, именно для того, чтобы хоть как-то адресовать эти ресурсы, товарищи из Microsoft придумали свой индекс эксплуатируемости.
В-третьих, я склонен считать пентесты продуктом, выходящим за рамки умения пользоваться готовыми инструментами, так как для последних есть специальное название, да и я сам так умею :). Я в понятие "пентест" вкладываю понятие "исследование". Именно это мне дает надежду считать, что когда я наразрабатываю кучу софта, понастрою систем, где заказчиком, архитектором и исполнителем работ буду я сам, найдутся реальные исследователи, способные обнаружить уязвимости в моем творении, исследовать вопрос их эксплуатируемости и довести эту эксплуатацию, возможно, с моей помощью, до реального бизнес-влияния, которое докажет не только мне самому, но моему топ-менедженту необходимость как-то адресовать проблемы с безопасностью. Этот абзац очень важен, поэтому я скомпилирую его в дайджест: есть 3 уровня результата аудита: 1-ый - только обнаружить уязвимость; 2-ой - исследовать ее эксплуатируемость, проэксплуатировать; 3-ий - сделать из этой эксплуатации бизнес-кейс, поднять эксплуатацию до реального профита для атакующего\ущерба для бизнеса. Так вот, для заказчика важен результат именно третьего уровня.

В своих последних постах на эту тему коллеги пишут, что пентест - стандартная работа, типа приходят парни со скриптами, за полчаса находят непатченную рабочую станцию, получают на ней локального админа, ждут пока там появится админ домена, перехватывают его пароль/хеш, делают учетку в Enterprise Admins и рапортуют об успехе. Я немного огорчился, увидев как в твиттере ребята, специализирующиеся именно на пентестах, подхватили, что пентест - стандартная работа. Не, мне не нужна стандартная работа, - работу по сценарию может делать и автоматический сканер (собственно, сценарий :) ), а где нужно немножко подумать - запускающий его человек, мне нужно именно исследование, мне нужна эксплуатация не Micosoft Windows, а АИС "Моя АБС", - за ее безопасность никто не отвечает, кроме меня, и я хочу серьезно подойти к этой своей ответственности. 
Возможно, сторонники commodity-услуги правы в том, что с точки зрения аудитора подход все равно будет одинаков: пентестит он Active Directory или АИС "Моя АБС", по крайней мере начало, - есть понятный набор практик и подходов, определенный набор инструментов, как умею, так и работаю :), да и моя супер-пупер-уникальная система все равно может быть представлена как совокупность стандартных компонетов: стандартной ОС, стандартной СУБД, стандартного сервера приложений и т.п. Но неправильно провоцировать людей думать, что раз услуга стандартна, то стандартно и предложение на рынке, откуда делается неправильный вывод, что любой игрок, предлагающий такую стандартную услугу, окажет ее со стандартным уровнем качества, регулируемым все тем же рынком. Нет, не так. Именно потому что здесь велика доля ресерча, качество результата далеко нестандартно и инструменты типа Критерия минимальной цены здесь отработают неэффективно.

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

Категории инцидентов

Все, кто  пытается отстроить сервисы мониторинга   событий безопасности рано или поздно приходят к вопросу необходимости классификации инцидентов. Здесь, как и в случае с отчетностью следует использовать подход "по цели", а уже понимание целей позволит определить критерии классификации. 
1. По критичности/важности/приоритету/потенциальному ущербу, иногда сюда же замешивают "влияние". Цель здесь - приоритезация усилий по реагированию: наиболее приоритетные - в первую очередь, наименее - можно отложить. Обычно в этом случае для определения критичности используется какая-то матрица в виде (Количество затронутых пользователей) х (Критичность подразделений для предприятия, либо грейд/позиция этих людей).
2. По типу инцидента/сути инцидента. Здесь цель - организовать правильную маршрутизацию, чтобы информация об инциденте с минимальным количеством хопов попала сразу в правильную группу реагирования. Обычно здесь используются типы, как-то коррелирующие с имеющимися группам эксплуатации. Например, DOS-атаки надо как-то совместно решать сетевикам с ISP, проблему спама могут адресовать почтовые админы и админы антиспам-фильтров (если это другие люди), проблемы на Интернет-сайте предприятия разумно направить сразу админам сайта, вирусы на рабочих станциях пользователя - в поддержку рабочих мест, чтобы они вытащили сэмпл, передали админу антивируса, который направит его в поддержку, получит экстру и всех сразу вылечит. Если кто-то сливает данные на флешки/в Интернет - разумно аккуратно переговорить с его линейным руководителем, чтобы уточнить возможную бизнес-потребность такого поведения. Если кто-то сканирует сеть, надо выяснить кто это: если админ - уточнить что он делает, если пользователь - исследовать удаленно насколько это возможно, если не все понятно - направить туда поддержку рабочих мест. Полезно в ходе расследования уточнять является атака специализированной "под вас" или "просто залетело" - это также следует учитывать в классификации. .... подобные "если, то" можно продолжать бесконечно, ибо мы одарены безграничной фантазией, поэтому надо смотреть по месту.
3. По вектору атаки. Может переплетаться с "По типу инцидента" (если погуглить, то большинство из того, что выпадет в результат будет содержать слитые эти типы категорий вместе - это тоже нормально и тоже определяется вашей целью). Достигаемая здесь цель - контроль эффективности используемых систем безопасности. Если, например, у меня большинство подтвержденных взломов прошло через Интернет-прокси - надо что-то в нем менять; если большинство прилетело по почте, то надо поднастроить почтовый шлюз. Может, при просмотре статистики инцидентов будет установлено, что почти все занесли со съемных носителей, то надо поставить какую-нибудь контролировалку флешек, а может, даже и запретить копировать с них исполняемые файлы; ну а если стало известно что все наши проблемы из-за того, что пользователи не задумываясь о последствиях сливают важную информацию направо и налево, то имеет смысл заняться повышением осведомленности.
4. По источнику обнаружения. Возможно, предыдущий тип классификации вам не нужен, но есть потребность оценивать эффективность используемых систем обнаружения (имеется в виду не только IDS), тогда полезно в инциденте указывать каким образом он был обнаружен. Это позволит понимать во-первых насколько существующие системы здорово выполняют свою работу (может, их надо заменить на другие или получше подконфигурировать), во-вторых, понять в какие места еще что было бы полезно поставить, чтобы обнаруживать инциденты быстрее/дешевле.
5. ....

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

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

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

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

Бесплатное обучение

Залетел мне "спам" о предлагаемых онлайновых курсах. Как любитель MOOC сразу пошел изучать, и с разочарованием заметил, что курсы платные :(

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

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

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

IDM - это непросто!

Сегодня выступал на CISO Forum-е с 40-минутным практикумом, презентацию выкладываю:

IDM - это непросто! from Sergey Soldatov

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

Комплексная услуга

Читая книжку Practical malware analysis (кстати, обалденная книжка) пытаюсь найти применение этим знаниям для CISO и прихожу к выводу, что держать в штате заказчика таких ребят не надо, - разумнее это аутсорсить. Очевидно, что аутсорсить надо у того, кто это здорово делает и у кого объемы этой работы таковы, что ее себестоимость низкая. Кто же это такие :) ? Антивирусные вендоры!
Может, я, конечно, отстал от жизни и на рынке есть подобные предложения, но я не могу понять почему антивирусные вендоры не продают вместе со своими продуктами сервис по анализу и противодействию таргетированным атакам, против которых их продукты, очевидно, бессильны. Это позволило бы представить на рынке комплексную услугу.

Заказчику такая услуга интересна в том плане, что она комплексная и, очевидно, более эффективная чем всякие лозунги про эффективность автоматов и типовых подходов против APT. Автомат не способен адаптироваться, поступать нестандартно, здесь нужна работа человека... Да и вообще, пускай с профессионалами сражаются профессионалы!
Мое мнение, что в перспективе нас ожидают исключительно таргетированные атаки, поскольку мы почти все электрифицировали и разместили в Интернете, что позволят получать не виданный ранее профит, измеряемый миллионами рублей, а, вместе с тем, заказная разработка софта - 100 т.р. + способность поставить правильно задачу (написать техтребования).
Я это все говорю к тому, что автоматическая борьба с зловредами уже неэффективна и в недалеком будущем вообще превратится в профанацию, поэтому антивирусным вендорам надо задуматься об адаптации к ситуации и выводить на рынок более эффективные продукты\сервисы...

Прежде, чем описывать почему этот сервис будет выгоде антивирусному вендору. Попробую пофантазировать как этот сервис мог бы выглядеть.
1. Заказчик как-то узнал, что его поимели, да хоть даже из новостей... ну если не узнал никак, то он вряд ли будет заказчиком этого сервиса :) - вообще, сейчас мир таков, что есть только два типа заказчиков: которых имеют и они об этом знают и которых имеют и они об этом не знают, поэтому, если вы ничего не видите - это очень плохой знак!. Обращается на сервисную линию, ему выделяется телефонный эксперт, который помогает ему собрать необходимый эвиденс. Тут вендор может вложиться в курсы для своих заказчиков по компьютерной криминалистике, и этот шаг в большинстве случае будет пропущен - заказчик будет в состоянии собрать все что нужно, и как это нужно. Ну, или можно предоставлять автоматизированные инструменты для сбора.
2. Вендор, получив все это анализирует:
- выпускает экстру которая сразу позволит как-то "вылечить" проблему,
- помогает найти ответы на вопросы "что за негодяй", "какой мотив" и т.п. с чем можно пойти в милицию,
- помогает с "Lessons learned": что за уязвимость, как ее закрыть\снизить риск и т.п.
3. Все

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

По-моему обалденная перспектива для всех. Надо брать и внедрять!