Введение

Мне посчастливилось трижды поучаствовать в эфире AM Live на тему автоматизации в информационной безопасности. И с тем, как мы раскладывали по полочкам все, что к этому относится – достоинства, недостатки, использование ИИ и примеры из жизни – пришло желание собрать побольше антипримеров автоматизации из опыта работы и как-то это все систематизировать.
За 12 лет в ИБ мне довелось принять участие как в успешных проектах, так и не очень. Хорошо то, что к моменту моего появления в Security Vision три года назад у меня уже сложилось какое-то базовое понимание того, как делать хорошо и не делать плохо. Учитывая ошибки предыдущих лет, используя опыт всех членов нашей команды, сейчас нам все же удается найти баланс и эффективно автоматизировать ИТ и ИБ процессы и сразу понимать, стоит ли вообще эту автоматизацию использовать, но так было не всегда.
Что до антипримеров, они здесь будут как банальные, так и не очень. Все, о чем я расскажу дальше, происходило в течение последних 5-10 лет, и я постараюсь обезличить кейсы из своих примеров на всякий случай. Не важно, какого цвета был заказчик что это был за проект – главное, что любая неудача помогает нам сделать выводы и идти дальше.

Когда автоматизация бесполезна или вредна?

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

Одноразовые задачи

Наверное, если спросить любого человека, даже не причастного к нашей сфере, какая автоматизация будет максимально бесполезной, самый простой и очевидный ответ – это одноразовые задачи.
То есть это те задачи, которые у вас повторяться не будут, и формализовывать процесс для которых вам в принципе не требуется – этого процесса не существует как такового, потому что задачи из разряда «просто бери и делай». Это изначально можно назвать автоматизацией без какой-либо цели, просто чтобы, например, применить какой-то понравившийся фреймворк или поупражняться в написании скриптов, не более.
И в случае, когда это делается, например, для себя, для каких-то пет-проектов, это понять еще можно. Но если это пытаться сделать в энтерпрайзе, когда помимо таких задач хватает и тех, что автоматизации все-таки требуют, история будет печальна. На это уходит время, уходит ресурс ценного сотрудника, а выхлопа от этого будет мало – с таким же успехом и может быть даже в более короткие сроки задачу мог сделать кто-то другой и более к этому вопросу не возвращаться.
То же самое относится и к тем простым задачам, решить которые вручную может быть и сложно – интеллектуально или за один присест – но на самом деле вручную их выполнить гораздо проще и быстрее. Возможно, такая задача может представлять из себя классический monkey job с очевидным дедлайном, или она может быть частично творческой, и тогда автоматизация все равно потребует участия живого человека. Когда вы точно знаете, что эта задача снова не придет, и если вам известно, что в беклоге нет задач, сколько-нибудь на текущую похожих, самый эффективный вариант – такую задачу решить.
Если задача так или иначе разовая, получается так, что тратить силы на то, чтобы ее автоматизировать, просто нет смысла.

Задачи, автоматизация которых требует больше ресурса, чем ручная работа

Причем ресурсом тут могут быть как деньги, так и время.
Об этом как раз второй пример автоматизации задач, реализация которых требует очень много сил или больших денежных вложений или слишком много времени специалиста, который мог бы в это время заняться чем-то еще – например, автоматизировать другие задачи. Всегда при планировании ресурсов на автоматизацию стоит учитывать затраты на выполнение тех же задач вручную. Это тоже прописная истина, о которой все знают и говорят, но все же не всегда учитывают это в работе, когда доходит до дела.
Что до последствий, то, к примеру, был такой заказчик много лет назад, который хотел, чтобы ему настроили интеграцию по передаче тикетов из одной системы в другую. И этот заказчик рассматривал как просто самописный интеграционный скрипт, так и покупку шины данных в уже существующем решении. Что же получилось? Заказчик сел и посчитал, сколько денег будет стоить автоматизация этой задачи и сколько денег он потратит, заплатив специалисту, который будет сидеть и перебивать эти тикеты вручную.
Ввиду того, что тикетов в принципе поступало очень мало и поток был небольшим, получилось так, что при расчете на 5 или даже 10 лет выходило дешевле нанять какого-нибудь стажера или студента.
То же самое актуально в случае, когда для решения задачи потребуется поднять компетенции сотрудников – еще вчера отчеты мог сформировать и отправить любой, даже джун после стажировки – а сегодня ему нужно пройти обучение по работе с новым ПО. Так ли это важно для данной задачи, настолько ли она критична – лучше бы определить это до того, как запускать процесс по ее автоматизации.

Автоматизируемый процесс непонятен или не формализуем

В противовес простым задачам, задачи, конечно же, бывают сложными. Что такое сложная задача в данном контексте? Это или задача, которая требует интеллектуальной деятельности для того, чтобы понять, что там вообще в ней происходит, или она сложная по сравнению с аналогичными простыми. Допустим, в них меньше шагов или эти задачи уже решаются руками, этот путь кем-то был пройден.
Если никто не знает, как выполнить задачу вручную или хотя бы не представляет себе примерный алгоритм действий, возникают проблемы. В целом, любая автоматизация требует процессного подхода – алгоритма для того, чтобы эта история заработала. Неважно, вам требуется написать скрипт или интегрировать опенсорсное решение – все равно вашими первыми шагами будут формализация процесса и формирование итоговой цели.
Были и такие проекты, в которых эти шаги попросту пропускали. Мол, делают же сейчас люди «как-то», нужно просто начать и что-нибудь да получится. Обычно не получалось. Иногда дело было в том, что процесс – например, проведение ежегодного внутреннего тестирования подчиненных – выполнялся по-разному в разных департаментах, начиная от оповещения сотрудников до фиксации результатов; даже артефакты процесса на каждом этапе были разные. Увы, несмотря на то что логичнее было бы сначала договориться внутри, а потом пойти прикручивать автоматизацию, сделано было наоборот.
В итоге получилось очень странное приложение, в котором было много деталей, друг с другом не связанных, ни одной команде было не комфортно работать в таком режиме, и постепенно все вернулись к листочкам и ручному ведению ведомостей.

Сразу автоматизируется сложная задача при наличии нерешенных простых

Продолжим говорить о тех задачах, которые считаются сложными по сравнению с себе подобными. Например, это могут быть задачи на автоматизацию выявления инцидентов, то есть написание правил корреляции. Здесь как раз важно понимать, что без опыта обработки простых случаев, не совсем корректно сразу же браться за сложные.
Что такое вообще сложные правила корреляции, если сформулировать по-простому? Это набор атомарных условий, то есть это те же простые правила, только связанные еще большим количеством условий. Таким образом, если мы возьмемся за выявление сложных правил корреляции, мы можем столкнуться с проблемой, когда мы не знаем, как эти атомарные кусочки найти, как их между собой соединить.
И, соответственно, не отработав что-то на более простых примерах, мы будем получать все больше false positive сработок и все равно будем вынуждены вернуться к более простым примерам для дебага. Здесь автоматизация наоборот не помогает ничего упростить, только забирает ценное время.
Второй пример — это проведение тестирования приложений. Здесь автоматизация может быть бесполезной, если вы беретесь за написание автотестов до того, как напишете тест-кейсы и пройдете хотя бы часть пути вручную, потому что без какого-либо процесса, без формализованного подхода к тестированию начинать делать автотесты – тоже немного бессмысленно. Вы не знаете, как это должно выглядеть в конце, усложняете себе задачу, и когда придёт время заняться тестированием по-настоящему, всю эту работу можно будет выбросить и начать писать тест-кейсы заново.

Автоматизация переусложненных задач с обширным контекстом и вариациями (слишком много исключений)

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

Автоматизация без учета бизнес-процессов и стратегических целей

Представим, что у вас есть некий процесс, который уже эффективно работает. Вы хотите его автоматизировать, чтобы людям не приходилось обрабатывать много информации вручную, но плохо себе представляете, что это за собой может повлечь. К примеру, что, если его автоматизация наоборот усложнит весь процесс?
Если вовремя не задаться вопросом, зачем процесс вообще существует и что он приносит, можно оказаться в такой ситуации, когда сил затрачено много, а эффективнее работать люди от этого не стали.
Например, отдел регулярно вручную тратил два дня в неделю на то, чтобы подробно зафиксировать и актуализировать план-график по задачам, а также затраченные часы. Вести это все в экселе было довольно муторно, к тому же люди часто ошибались, опечатывались, и результат не радовал. Было решено внедрить систему учета трудозатрат. Правда, только после внедрения системы оказалось, что данные по всем проектам и так фиксировались, просто… другой командой. И времени у них на это уходило куда меньше. Получается, что задача уже решалась, процесс был выстроен другой и автоматизации не требовал. Если бы сначала разобрались в нем, то до сложных внедрений просто бы не дошло.
Другой пример – про цели. Вот был и есть у какого-то заказчика свой собственный центр экспертизы, в котором, в том числе, сидят вирусные аналитики. Работа полезная и понятная. И захотелось ему в этом экспертном центре вдруг добавить услугу по формированию пульсов с индикаторами компрометации для своих дочерних организаций и других клиентов. Но понимания, как клиенты должны пользоваться этой информацией, не было.
В итоге, планируется добавить автоматизацию сбора данных об индикаторах и угрозах без четкого понимания, как эти данные помогут улучшить состояние защиты или ускорить расследование инцидентов у каждого из клиентов. Данные собираются, но не анализируются и не применяются на практике, просто хранятся до лучших времен.
Когда процесс улучшается просто чтобы «было эффективнее», а что-то новое появляется «чтобы у нас тоже это было», без определения конечной цели, результат будет соответствовать. Нужно изначально понимать, куда мы идем и зачем, и тогда автоматизация скорее всего принесет только пользу.

Данных для автоматизации недостаточно

Когда мы начинаем автоматизировать какую-то задачу, мы должны в том числе задуматься о том, что с этой автоматизацией будет после.
Один из примеров как раз о том, что может произойти с данными, которые нужны системе автоматизации на вход. Есть такой антипример от заказчика, который захотел себе построить Data Lake, в котором он собирал бы информацию и от IT, от ИБ. И, собственно, целью было как раз объединение этих департаментов и их потоков данных, чтобы одновременно и выявлять аномалии с инцидентами, и как-то проактивно действовать, заниматься защитой инфраструктуры и харденингом.
После завершения проекта ожидалось, что данные будут поступать в озеро из всех доступных систем и СЗИ, и точно так же эти системы смогут делать запросы по всем имеющимся данным, когда это требуется. История в том, что пока проект шел, доступ к каким-то тестовым данным был, и система была успешно разработана, пройдя испытания и проверки.
Основные проблемы начались после внедрения, в виде нехватки данных, потому что два департамента так и не смогли друг с другом подружиться и данными обмениваться не стали. И в итоге в Data Lake шел только какой-то мизерный поток событий, согласованный обеими сторонами. Для того, чтобы даже в этом потоке делать запросы, нужно было разрешение соседнего департамента.
В итоге идея, которая изначально должна была принести пользу, закончилась тем, что формально все было выполнено хорошо – свои задачи система решала. Но на практике существуют как процессные, так и обычные человеческие проблемы, не дающие этой автоматизацией воспользоваться.

Алгоритм некому поддерживать

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

Как оценить, нужна ли задаче автоматизация?

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