Один аналитик SOC, когда его решили перевести на работу из дома, задал сакраментальный вопрос: «Я живу в однушке со своей девушкой и ее кошкой, на которую (кошку, а не девушку) у меня аллергия. При этом у нас всего один стол, за которым мы едим, а во внетрапезное время, моя девушка на нем раскладывает чертежи, она модельер-конструктор одежды. И где мне прикажете разместить 3 монитора, которые мне разрешили временно забрать с работы?» Ну а поскольку это только один из множества вопросов, которые возникают при переводе работников SOC (Security Operations Center) на удаленку, я решил поделиться нашим опытом; особенно учитывая, что именно сейчас для одного из заказчиков мы как раз проектируем центр мониторинга кибербезопасности (SOC) с нуля и он решил на ходу переобуться и попросил учесть в проекте возможность работы его аналитиков и специалистов по расследованию инцидентов из дома.
В условиях пандемии многие компании перевели или обязаны были перевести часть сотрудников на удаленную работу. Не минула чаша сия и специалистов SOC. Однако сразу надо отметить, что отечественные регуляторы своими требованиями запретили специалистам аутсорсинговых SOCов, предоставляющих услуги своим клиентам, работать из дома, так как одним из условий получения лицензии на мониторинг ИБ (а коммерческий SOC — это лицензируемый вид деятельности) являлось не только указание адреса предоставления услуги, но и аттестация его информационной системы, что также делает невозможным экстренный переход на удаленку (да и не экстренный тоже). Правда, в нашем государстве правового ИБ-нигилизма и временного отказа от проведения проверок, на этот нюанс можно внимания и не обращать — требования бизнеса и сохранения жизни и здоровья людей в данном случае гораздо важнее. Особенно учитывая тот факт, что киберпреступники свою активность не снизили. Более того, тему коронавируса они подняли на флаг и стали атаковать пользователей на дому, которые оказались предоставлены сами себе и стали еще более слабым звеном, чем обычно. Поэтому тема SOCа (или мониторинга ИБ) на удаленке становится для многих компаний вполне себе актуальной. Ну а так как Cisco помогла построить и проаудировать немалое количество SOCов, а наш собственный SOC работает по модели «виртуального SOCа» уже больше 10 лет, то у нас накопился ряд советов, которыми бы мы и хотели поделиться.
Но начать мне хотелось бы не с технологических особенностей удаленного мониторинга и расследования инцидентов, о них мы поговорим ниже, а с того, о чем часто забывают. Основная проблема при переводе части или всех аналитиков SOC на дистанционную работу из дома связана с человеческим фактором. Даже если у вас выстроены все процессы, а инструментарий позволяет удаленно подключаться к консоли SIEM или SOAR и также удаленно собирать артефакты с компьютеров удаленных пользователей, то именно люди могут стать самым слабым звеном в SOCе, покинувшем насиженные места.
Согласно исследованиям перевод на домашнюю работу приводит к снижению продуктивности на 15% (времени на выполнение служебных обязанностей человек может быть тратит и больше, но эффективно ли?). Стресс и дискомфорт (если вокруг бегают дети, а за стеной сосед решил вдруг сделать ремонт), а также неумение сосредотачиваться, когда жена варит борщ или подруга в той же комнате занимается йогой, приводят к снижению внимательности. А сон, который так манит? При работе в офисе с ним еще можно как-то бороться, но находясь дома, видя теплую и манящую кровать со спящим там близким человеком, это гораздо сложнее. И это при том, что работоспособность любого человека в ночное время падает просто катастрофически.
Поэтому очень важным становится измерение эффективности специалистов SOC. Удаленная работа расслабляет и не все готовы к ней. Работникам SOC необходимо самим поменять свое поведение при удаленной работе. А их менеджерам необходимо отслеживать показатели работы каждого аналитика и при выходе их за граничные значения своевременно реагировать. Причем речь идет не о банальном «среднем времени взятия инцидента в работу» или «среднем времени реагирования/локализации инцидента», а о измерении каждого этапа или задачи в рамках разработанных playbook. Допустим, у вас есть playbook по анализу подозрительной активности пользователя и среднее время реагирования на нее (от момента получения сигнала в SIEM и до замораживания учетной записи в AD, помещения узла в карантинный VLAN и поиска других узлов и пользователей, которые могли быть связаны с пострадавшим) у вас занимает около 28 минут. Вы смотрите статистику по удаленно отработанным инцидентам и видите, что этот показатель немного скачет в диапазоне от 19 до 37 минут, но в среднем составляет те же 28 минут, что было и до смены режима работы аналитиков. Вроде все ОК.
Но если бы у вас была возможность мониторить все отдельные шаги/задачи playbook, то вы бы увидели, что вместо традиционных 1-3 минут на выявление индикаторов, 1-3 минут их проверки в TI-платформе, 1-2 минут на принятие решения, 3 минут на замораживание учетки и т.п., у вас аналитик сразу после получения сигнала тревоги помещает пользователя и его узел в карантин, а то и вовсе без проверки передает инцидент на следующий уровень, к аналитикам L2. И, примерно, 9-10 минут вообще непонятно, что аналитик делал. То ли он пошел на кухню налить себе кофе, то ли он решил посмотреть новости по ТВ, а может он просто пошел на прогулку, на балкон. Но имеющаяся у вас метрика по конкретному инциденту соблюдена. Поэтому при переходе на удаленную работу надо пересматривать имеющиеся метрики оценки эффективности SOC.
В описанном кейсе, кстати, еще одним решением могло бы стать внедрение средств автоматизации, которые устраняют большинство вручную выполняемых задач и автоматизируют то, что написано в playbook. Но это могло быть сделано и вне зависимости от удаленной работы — платформы SOAR как раз и предназначены для того, чтобы автоматизировать работу аналитиков SOC и не только ускорить процесс расследования и реагирования на инциденты, но и иметь инструмент измерения эффективности работы с ними. Поэтому, кстати, Cisco разработала новую и бесплатную платформу управления ИБ — Cisco SecureX, задача которой как раз автоматизировать управление множеством решений Cisco (и еще сотен разных других производителей), включая и процесс реагирования на инциденты.
SOC — это почти всегда командная работа. В типовом SOC его специалисты работают бок о бок в тесных помещениях и когда они вынуждено переходят на удаленную работу, то сразу возникают сложности, к которым SOC часто не готов. Этому, кстати, способствуют и требования законодательства, которые рассматривают SOC как лицензируемую деятельность в определенном помещении, о чем я уже упоминал выше. Концепция виртуальных или мобильных SOCов в России не очень принята, особенно при оказании услуг по мониторингу ИБ и реагированию на инциденты (для собственных целей вы, конечно, можете строить SOC по любой их доступных архитектур). Удаленная командная работа — это новый челендж, к которому еще надо привыкать. На что обратить внимание в этом аспекте деятельности SOC.
Проанализируйте и, возможно, пересмотрите график посменной работы. Каждый аналитик должен знать не только свою роль и свое расписание работы, но и роль и расписание других членов команды, чтобы иметь возможность обращаться к нужному специалисту или заменить его, если он, по каким-то причинам, «не вышел» на работу (помимо попадания в больницу, можно просто попасть под административный арест на 15 суток за нарушение правил обязательной самоизоляции /классический оксюморон/, когда ты просто пошел выгуливать собаку на рядом находящихся прудах). Кстати, если ваш аналитик работает на даче и у него вдруг вырубили электричество или Интернет, то ему, конечно, не надо записывать виртуальный «прогул», но надо быть готовым заменить его на время восстановления работоспособности его удаленного рабочего места. А ведь помимо названных причин может быть еще куча всего, что стоит учитывать, — затопили соседи, пожар, надо срочно отвезти близкого человека в больницу и т.п. И все это надо учитывать в первую очередь для аналитиков первой и второй линии, для которых постоянное пребывание на рабочем месте является наиболее актуальным.
В условиях достаточно высокой ротации кадров на нижних уровнях иерархии SOC в них распространено менторство более опытных коллег над новичками. Они помогают советом, присматривают, поддерживают. А как это делать на удаленке? Как помочь новичку, предоставленному самому себе? Ответ простой — правильные и постоянные коммуникации!!!
Коммуникации при удаленной работе становятся важнейшим элементов ее эффективности. Причем коммуникации не только в рамках расследования того или иного инцидента, но и «просто так». Пару раз в день собраться на 15 минут и обменяться мнениями, идеями; поддержать друг друга в стрессовой ситуации (а кто бы что не говорил, но текущая ситуация — это именно стресс, который негативно влияет на наши возможности и способности). У наших аналитиков SOC это было всегда, а вот у рядовых сотрудников ввели практику «виртуальных перерывов на кофе» только недавно. Как показывает опыт, многим действительно не хватает общения с коллегами; и даже аналитики-интроверты — не исключение.
Если у вас уже есть план коммуникаций, то стоит его проанализировать и, скорее всего, пересмотреть. Он должен включать в себя, как минимум:
Во время расследования — самый ценный ресурс — это время. Не тратьте его попусту. Специалисты по расследованию, находящиеся на расстоянии, могут дублировать работу друг друга. Они могут повторять одни и те же дискуссии в разных группах и средствах коммуникаций. Мессенджеры, которые часто используются для общения в рамках инцидента, например, Whatsapp, не очень подходят для этой задачи, так как там очень сложно осуществлять поиск и работать с документами и артефактами; особенно когда в одном чате у вас слишком много разных инцидентов и начинается путаница между ними. Создание же отдельных чатов для каждого инцидента могло бы решить проблему, но назвать этот путь удобным я не могу. Все-таки мессенджеры не предназначены для этой задачи. Кроме того, вам будет сложно разделять служебные чаты и личные, а также у вас появится зависимость от внешних серверов управления, работа которых может быть и нарушена, если какой-либогосударственный орган в очередной раз начнет бороться с условным «Telegram», или если производитель мессенджера введет запрет на одновременный постинг в несколько групп/чатов, борясь с фейковыми новостями.
Для эффективной коммуникации в рамках инцидента используемое вами решение должно иметь возможность организации чатов, обмена файлами и удаленного доступа к рабочему столу. Например, используя Webex Teams, в нем можно под каждый инцидент создать отдельное пространство, куда не только собирать все необходимые доказательства, но и общаться со всеми участниками, участвующими в инциденте. А за счет возможности написания чатботов и интеграции Webex Teams со средствами защиты, вы сразу можете проводить проверку и обогащение полученных артефактов.
Если вы не используете Webex Teams, то схожую идею можно реализовать, например, на следующей связке: отдельный канал Slack для специфичного инцидента (и общий канал для общения, который можно использовать как некий индекс по всем инцидентам), комната Zoom для обсуждения (у вас должна быть оплаченная учетная запись для этого и если вас не смущают постоянные проблемы ИБ у этого сервиса) и страница Confluence для сбора заметок. Затем сводная информация по инциденту заносится в IRP, в качестве которой может выступать как привычная многим Jira, так и специализированные решения по управлению инцидентами.
У вас есть в вашем SOC доска для мозговых штурмов? думаю, что есть. При удаленной работе вам может понадобиться Whiteboard — такая функция есть в различных средствах коммуникаций. Вы можете удаленно рисовать и обмениваться идеями с коллегами. А если вы использовали доски канбан для контроля командных задач, то они вам понадобятся и на удаленке — используйте, например, Trello, если у вас нет корпоративного решения. Но пользуясь облачными решениями для командной работы, не забудьте настроить соответствующие права доступа, чтобы посторонние не узнали о том, какие у вас проблемы с безопасностью и не смогли вмешаться в процесс расследования и реагирования.
Вы решили, что что аналитики SOC будут работать удаленно. И вы знаете, как это сделать не только технически, но и психологически и организационно. Но, задавались ли вы вопросом, у вас аналитики SOC имеют собственную квартиру или живут в общаге? Кто ваши аналитики первой линии? Высококлассные специалисты, много лет работающие в SOC, и заработавшие себе на собственный пентхаус на Воробьевых горах? Или это еще недавно студенты, живущие с мамой, папой и с младшими братьями и сестрами? В вашем SOC вы можете предоставить им рабочее место и три монитора для наблюдения «за иголкой в стоге сена». А дома у вашего аналитика есть место для 3-х или хотя бы двух мониторов? А если у него брат режется в метре от него в PlayStation и отвлекает его звуками «горящей резины» или «умирающих зомби»? Если аналитик не может по причине отсутствия места работать из дома, вам понадобится вносить изменения в состав и график работы смен.
А еще важно обеспечить удобство и комфорт работы для аналитиков. В корпоративном SOC вы можете потратить много усилий и ресурсов для выбора правильного освещения, шумоизоляции, реверберации, кондиционирования, удобных кресел и т.п. Но дома часто, увы, мы не обладаем такими роскошествами. И поэтому надо более внимательно следить за тем, насколько изменились показатели работы аналитиков до (если вы, конечно, их собирали) и после ухода на удаленку. И уже после их анализа делать соответствующие выводы. Иначе удаленный SOC превратится в «тыкву» — вроде он и есть, но своей задачи не решает, так как аналитики просто неспособны работать в собственных квартирах.
И не забудьте, что физическая безопасность помещения, в котором циркулирует достаточно чувствительная информация, тоже важна.
В условиях пандемии у вас возрастет объем событий безопасности. Во-первых, вам придется активнее мониторить свой VPN-кластер или кластеры удаленного доступа, через которые пользователи будут подключаться к приложениям и данным внутри корпоративной сети или которые будут «прокидывать» трафик пользователей к внешним облачным сервисам. Во-вторых, вам может понадобиться мониторить облачные среды, если ИТ-служба приняла решение временно или уже постоянно перенести обработку некоторых данных и некоторые приложения в облака. И, наконец, у вас возрастает зоопарк различных систем, находящихся дома у пользователей, которые начнут генерить события безопасности и которые надо будет анализировать. Но это еще не все.
SIEM, IRP/SOAR, ticketing, TI-платформа… Они имеют возможность подключения к ним с удаленной консоли по защищенному соединению (как повезло тем, кто пользуется сейчас облачными SOCами/SIEMами, где это встроенная функция)? Если нет, то надо продумывать вариант с удаленным доступом через RDP/VDI или иные способы подключения, проброшенные через VPN (в этом месте впору задуматься о возможности реализации мобильного или виртуального SOC). В конце концов у вас может быть специальная виртуальная машина, LiveCD или LiveUSB для работы с инструментами SOC; хотя последних вариантов мы почти не встречали — это скорее делается для работы пользователей с их домашних компьютеров, когда надо разделить корпоративные приложения и домашние, с которыми работают ваши близкие.
На наш взгляд VDI (но тоже через VPN) был бы лучшим вариантом с точки зрения контроля доступа и работы с чувствительной информацией, но и прямой доступ при правильной настройке тоже является вполне рабочим вариантом. В обоих случаях необходимо не только использовать многофакторную аутентификацию, но и обязательно проверять подключающийся ПК аналитика на предмет соответствия требованиям по ИБ (установленные патчи, настройки парольной защиты, наличие антивируса или EDR и т.п.). Если у вас на периметре стоит Cisco ASA или внутри сети развернут Cisco ISE, то такую проверку вы можете организовать на них. Мы рекомендуем запретить split tunneling на компьютерах, подключающихся к корпоративному SOC. Это будет гораздо безопаснее; да и для рядовых пользователей на удаленке тоже.
И не забудьте уточнить, требуются ли изменения в ACL пограничного оборудования на стороне компании для доступа к святая святых ИБ? Какова вообще процедура внесения изменений в ACL? Не понадобится ли долгая процедура согласования, да еще и требующая собственноручной подписи на заявке? Сейчас было бы хорошей идеей — пересмотреть все свои политики и инструкции на предмет их работоспособности в условиях невозможности собирать подписи и бегать между начальниками. И даже если у вас электронный документооборот, насколько он приспособлен к оперативному решению вопросов?
Специалисты по расследованию привыкли, что они могут прийти к сотруднику, задействованному в инциденте, и снять с его компьютера все логи/дамп памяти/и иные артефакты. Но как это сделать удаленно? Кто-то использует привычные айтишникам Remote Admin, кто-то RDP, кто-то Skype for Business или иные инструменты. Главное, не забыть правильно настроить защитный функционал у этих инструментов и договориться с сотрудниками о процедуре проверки подлинности сотрудников ИТ/ИБ, подключающихся удаленно (ну и про юридические аспекты не забудьте, о чем будет сказано далее). Кто-то использует бесплатные GRR, osquery, встроенные Sysmon или Autorun Utility или коммерческий EnCase (пользователям Cisco AMP for Endpoints не надо беспокоиться — у них есть такой инструмент как Cisco Orbital, который позволяет проводить удаленное расследование). В ряде случаев можно научить пользователей запускать нужный скрипт, который сам соберет необходимые доказательства и защищенным образом передаст в SOC для анализа. Тут важно для себя решить, эти инструменты должны быть установлены заранее (для корпоративных устройств нет проблемы в их предустановке на корпоративный имидж ОС со всеми приложениями) или их надо устанавливать в случае возникновения каких-либо проблем. В последнем случае, однако, появляется риск, что тем самым мы дадим знать злоумышленнику, что его активность обнаружена и он может «покинуть» свою жертву, попутно затерев и все оставленные собой следы. Это непростой вопрос, который, конечно, лучше решать «на берегу», а не в процессе расследования удаленного инцидента.
Я думаю, что я еще вернусь с отдельным материалом по удаленному расследованию и сбору доказательств, а пока просто упомяну ряд вопросов, на которые надо быть готовым ответить при удаленном расследовании:
Ответы на эти вопросы сильно зависят от имеющейся инфраструктуры, наличия корпоративных стандартов на используемые устройства, системное и прикладное ПО, а также от права сотрудникам использовать личные устройства для работы из дома.
Возможно в условиях пандемии вы решите на время воспользоваться услугами аутсорсингого SOC и MDR-провайдера. Тем более, что с них сейчас можно и скидки выбивать :-) Но гораздо важнее понять, насколько ваш текущий аутсорсинговый контракт или контракты учитывают удаленную работу ваших аналитиков? MSSP/MDR/TIP/CERT/ФинЦЕРТ/ГосСОПКА принимают сообщения от ваших сотрудников, с их личных телефонов или адресов e-mail? Не блокируют ли они доступ не с корпоративных IP-адресов? Можно ли подключаться к дашборду у внешних провайдеров не через корпоративный VPN, с помощью split tunneling?
Про невозможность удаленной работы коммерческого SOC из-за ограничений ФСТЭК я уже выше писал. Но есть и еще ряд тем, о которых надо помнить при удаленной работе SOC. Знаете свежий анекдот? «Мои дети учатся дома. Прошу администрацию школы сдать деньги на новые шторы, покраску стен и ремонт мебели» :-) Так вот в ряде стран появляется практика, когда сотрудники начинают требовать от работодателя компенсацию за использование квартиры и домашнего компьютера в качестве рабочих инструментов. Думаю, что в России нам это пока не грозит, но сам пример достаточно показателен.
Врядли сотрудникам SOC предлагают выполнять свои служебные обязанности с личных компьютеров (хотя....), но вот рядовые сотрудники вполне могут подключаться к корпоративным ресурсам с домашних устройств. И поэтому возникает закономерный вопрос — на каком законном основании работодатель получает доступ к удаленному и личному компьютеру сотрудника при проведении расследований, сборе артефактов и т.п.? У вас в трудовом договоре или допсоглашении к нему есть пункт о праве компании проводить мониторинг работника? А детальный регламент, что можно, а что нельзя делать в рамках такого мониторинга, есть? Если нет, то вы нарушаете действующее законодательство и сотрудник имеет полное право послать вас при попытке доступа к личному устройству. Тоже касается и установки DLP-агентов или средств учета рабочего времени на домашних компьютерах.
И не забывайте, что ваш SOC может попасть в область действия (scope) какого-нибудь международного стандарта управления ИБ (например, в России уже несколько SOCов прошли сертификацию на соответствие ISO 27001). Продумайте, как вы будете проходить аудит с вашим удаленным SOC? Не будете же вы водить аудиторов по квартирам сотрудников. Или будете?..
Вот такие зарисовки о том, с чем нам приходится сталкиваться при проектировании, аудите и разработке планов улучшения центров мониторинга ИБ, в том числе и в России и странах СНГ. Нельзя сказать, что все эти советы невыполнимы или требуют существенных финансовых, временных и людских затрат. Многое из это реализовать достаточно легко. Главное, не спускать эти вопросы на тормозах, так как их игнорирование может привести не только к увеличению времени на проведение расследований инцидентов при удаленной работе, но и даже к их пропуску. Также не стоит думать, что текущая пандемия — это временное явление и скоро все наладится. Если в организации всерьез думаю о непрерывности бизнеса и умеют просчитывать ситуацию на несколько шагов вперед, то мы поймем, что COVID-19 — это всего лишь знак; знак того, что ситуация может повториться уже следующей зимой. Поэтому «сани надо готовить летом». В любом случае, описанные выше советы лишними не будут и в обычной жизни SOC.
ЗЫ. И, кстати, не забудьте дезинфицировать основное помещение SOC перед тем как туда вернутся аналитики.
В условиях пандемии многие компании перевели или обязаны были перевести часть сотрудников на удаленную работу. Не минула чаша сия и специалистов SOC. Однако сразу надо отметить, что отечественные регуляторы своими требованиями запретили специалистам аутсорсинговых SOCов, предоставляющих услуги своим клиентам, работать из дома, так как одним из условий получения лицензии на мониторинг ИБ (а коммерческий SOC — это лицензируемый вид деятельности) являлось не только указание адреса предоставления услуги, но и аттестация его информационной системы, что также делает невозможным экстренный переход на удаленку (да и не экстренный тоже). Правда, в нашем государстве правового ИБ-нигилизма и временного отказа от проведения проверок, на этот нюанс можно внимания и не обращать — требования бизнеса и сохранения жизни и здоровья людей в данном случае гораздо важнее. Особенно учитывая тот факт, что киберпреступники свою активность не снизили. Более того, тему коронавируса они подняли на флаг и стали атаковать пользователей на дому, которые оказались предоставлены сами себе и стали еще более слабым звеном, чем обычно. Поэтому тема SOCа (или мониторинга ИБ) на удаленке становится для многих компаний вполне себе актуальной. Ну а так как Cisco помогла построить и проаудировать немалое количество SOCов, а наш собственный SOC работает по модели «виртуального SOCа» уже больше 10 лет, то у нас накопился ряд советов, которыми бы мы и хотели поделиться.
Но начать мне хотелось бы не с технологических особенностей удаленного мониторинга и расследования инцидентов, о них мы поговорим ниже, а с того, о чем часто забывают. Основная проблема при переводе части или всех аналитиков SOC на дистанционную работу из дома связана с человеческим фактором. Даже если у вас выстроены все процессы, а инструментарий позволяет удаленно подключаться к консоли SIEM или SOAR и также удаленно собирать артефакты с компьютеров удаленных пользователей, то именно люди могут стать самым слабым звеном в SOCе, покинувшем насиженные места.
Внимательность и стресс
Согласно исследованиям перевод на домашнюю работу приводит к снижению продуктивности на 15% (времени на выполнение служебных обязанностей человек может быть тратит и больше, но эффективно ли?). Стресс и дискомфорт (если вокруг бегают дети, а за стеной сосед решил вдруг сделать ремонт), а также неумение сосредотачиваться, когда жена варит борщ или подруга в той же комнате занимается йогой, приводят к снижению внимательности. А сон, который так манит? При работе в офисе с ним еще можно как-то бороться, но находясь дома, видя теплую и манящую кровать со спящим там близким человеком, это гораздо сложнее. И это при том, что работоспособность любого человека в ночное время падает просто катастрофически.
Поэтому очень важным становится измерение эффективности специалистов SOC. Удаленная работа расслабляет и не все готовы к ней. Работникам SOC необходимо самим поменять свое поведение при удаленной работе. А их менеджерам необходимо отслеживать показатели работы каждого аналитика и при выходе их за граничные значения своевременно реагировать. Причем речь идет не о банальном «среднем времени взятия инцидента в работу» или «среднем времени реагирования/локализации инцидента», а о измерении каждого этапа или задачи в рамках разработанных playbook. Допустим, у вас есть playbook по анализу подозрительной активности пользователя и среднее время реагирования на нее (от момента получения сигнала в SIEM и до замораживания учетной записи в AD, помещения узла в карантинный VLAN и поиска других узлов и пользователей, которые могли быть связаны с пострадавшим) у вас занимает около 28 минут. Вы смотрите статистику по удаленно отработанным инцидентам и видите, что этот показатель немного скачет в диапазоне от 19 до 37 минут, но в среднем составляет те же 28 минут, что было и до смены режима работы аналитиков. Вроде все ОК.
Но если бы у вас была возможность мониторить все отдельные шаги/задачи playbook, то вы бы увидели, что вместо традиционных 1-3 минут на выявление индикаторов, 1-3 минут их проверки в TI-платформе, 1-2 минут на принятие решения, 3 минут на замораживание учетки и т.п., у вас аналитик сразу после получения сигнала тревоги помещает пользователя и его узел в карантин, а то и вовсе без проверки передает инцидент на следующий уровень, к аналитикам L2. И, примерно, 9-10 минут вообще непонятно, что аналитик делал. То ли он пошел на кухню налить себе кофе, то ли он решил посмотреть новости по ТВ, а может он просто пошел на прогулку, на балкон. Но имеющаяся у вас метрика по конкретному инциденту соблюдена. Поэтому при переходе на удаленную работу надо пересматривать имеющиеся метрики оценки эффективности SOC.
В описанном кейсе, кстати, еще одним решением могло бы стать внедрение средств автоматизации, которые устраняют большинство вручную выполняемых задач и автоматизируют то, что написано в playbook. Но это могло быть сделано и вне зависимости от удаленной работы — платформы SOAR как раз и предназначены для того, чтобы автоматизировать работу аналитиков SOC и не только ускорить процесс расследования и реагирования на инциденты, но и иметь инструмент измерения эффективности работы с ними. Поэтому, кстати, Cisco разработала новую и бесплатную платформу управления ИБ — Cisco SecureX, задача которой как раз автоматизировать управление множеством решений Cisco (и еще сотен разных других производителей), включая и процесс реагирования на инциденты.
Командная работа
SOC — это почти всегда командная работа. В типовом SOC его специалисты работают бок о бок в тесных помещениях и когда они вынуждено переходят на удаленную работу, то сразу возникают сложности, к которым SOC часто не готов. Этому, кстати, способствуют и требования законодательства, которые рассматривают SOC как лицензируемую деятельность в определенном помещении, о чем я уже упоминал выше. Концепция виртуальных или мобильных SOCов в России не очень принята, особенно при оказании услуг по мониторингу ИБ и реагированию на инциденты (для собственных целей вы, конечно, можете строить SOC по любой их доступных архитектур). Удаленная командная работа — это новый челендж, к которому еще надо привыкать. На что обратить внимание в этом аспекте деятельности SOC.
График работы
Проанализируйте и, возможно, пересмотрите график посменной работы. Каждый аналитик должен знать не только свою роль и свое расписание работы, но и роль и расписание других членов команды, чтобы иметь возможность обращаться к нужному специалисту или заменить его, если он, по каким-то причинам, «не вышел» на работу (помимо попадания в больницу, можно просто попасть под административный арест на 15 суток за нарушение правил обязательной самоизоляции /классический оксюморон/, когда ты просто пошел выгуливать собаку на рядом находящихся прудах). Кстати, если ваш аналитик работает на даче и у него вдруг вырубили электричество или Интернет, то ему, конечно, не надо записывать виртуальный «прогул», но надо быть готовым заменить его на время восстановления работоспособности его удаленного рабочего места. А ведь помимо названных причин может быть еще куча всего, что стоит учитывать, — затопили соседи, пожар, надо срочно отвезти близкого человека в больницу и т.п. И все это надо учитывать в первую очередь для аналитиков первой и второй линии, для которых постоянное пребывание на рабочем месте является наиболее актуальным.
Менторство
В условиях достаточно высокой ротации кадров на нижних уровнях иерархии SOC в них распространено менторство более опытных коллег над новичками. Они помогают советом, присматривают, поддерживают. А как это делать на удаленке? Как помочь новичку, предоставленному самому себе? Ответ простой — правильные и постоянные коммуникации!!!
План коммуникаций
Коммуникации при удаленной работе становятся важнейшим элементов ее эффективности. Причем коммуникации не только в рамках расследования того или иного инцидента, но и «просто так». Пару раз в день собраться на 15 минут и обменяться мнениями, идеями; поддержать друг друга в стрессовой ситуации (а кто бы что не говорил, но текущая ситуация — это именно стресс, который негативно влияет на наши возможности и способности). У наших аналитиков SOC это было всегда, а вот у рядовых сотрудников ввели практику «виртуальных перерывов на кофе» только недавно. Как показывает опыт, многим действительно не хватает общения с коллегами; и даже аналитики-интроверты — не исключение.
Если у вас уже есть план коммуникаций, то стоит его проанализировать и, скорее всего, пересмотреть. Он должен включать в себя, как минимум:
- Список тех, кто находится на домашней работе, включая их контакты — e-mail и телефон, рабочие и домашние. В идеале этот список должен быть вывешен на внутреннем портале/wiki SOCа, чтобы все могли иметь к нему доступ (да и вносит изменения в него можно оперативно).
- Заинтересованным лицам должны быть отправлены соответствующие уведомления. Например, если при переходе на удаленку поменялся способ коммуникации с пользователями, которые могут сообщать об инцидентах, то пользователям неплохо бы сообщить об этом. У вас сотрудники вообще знают куда звонить, если они столкнулись с инцидентом? В условиях удаленки этот телефон будет действовать? Не надо ли оповестить сотрудников о его смене или автоматически переадресовывать все звонки на него на другой номер (или номера, если внедрить IVR), доступный сотрудникам, работающим из дома?
- Пользователям, работающим удаленно, кстати, неплохо бы сообщить о том, как они могут идентифицировать и аутентифицировать звонящих им «сотрудников службы поддержки» или «сотрудников службы ИБ». Объем социального инжиниринга в текущей ситуации только возрастает и надо быть готовым к этому. У нас в Cisco, например, для общения по такого рода вопросам используется Cisco Webex Teams, который не только позволяет аутентифицировать участников коммуникаций, но и защищает их от посторонних. Да и удаленный доступ к рабочему столу тоже обеспечивает, что может понадобиться при разборе того или иного инцидента.
- Если вы используете какие-то иные инструменты для коммуникаций, то проработайте вопрос подтверждения подлинности участников. Это, кстати, нужно будет и для работы распределенных команд SOC, когда не все сотрудники знают друг друга в лицо. Бюджетным вариантом может стать grid card, простой, но эффективный способ взаимной аутентификации пользователей.
- FAQ и мини-матрица RACI с указанием того, кто и с кем может/должен контактировать в том или ином случае/use case.
- В обычной жизни, вы все сидите в одной комнате или в так называемой war room и менеджеры CSIRT и различные начальники видят, что вы при деле. В удаленном режиме это уже работает плохо и поэтому важно регулярно рассылать уведомления по всем заинтересованным сторонам, для чего неплохо бы заранее разработать соответствующие шаблоны, в которые просто будет вставляться необходимая информация, полученная в ходе расследования. В противном случае вас будут отвлекать регулярными звонками или смсками с вопросом «Ну как?», что будет отвлекать от расследования и не даст нормально сосредоточиться на работе. Да и время расследования увеличит.
- Измерение эффективности коммуникаций. Насколько часто ваши аналитики общаются между собой, с командой, поддерживающей ваши платформы SOC, с группой реагирования на инциденты, а также с ИТ-департаментом? Вообще не общаются? А тогда что же они делают? К счастью, переведя всех на удаленную работу и предоставив всем средства коммуникаций, их становится достаточно легко отслеживать и измерять ключевые показатели эффективности — частоту и круг общения.
Корпоративные или личные средства общения?
Во время расследования — самый ценный ресурс — это время. Не тратьте его попусту. Специалисты по расследованию, находящиеся на расстоянии, могут дублировать работу друг друга. Они могут повторять одни и те же дискуссии в разных группах и средствах коммуникаций. Мессенджеры, которые часто используются для общения в рамках инцидента, например, Whatsapp, не очень подходят для этой задачи, так как там очень сложно осуществлять поиск и работать с документами и артефактами; особенно когда в одном чате у вас слишком много разных инцидентов и начинается путаница между ними. Создание же отдельных чатов для каждого инцидента могло бы решить проблему, но назвать этот путь удобным я не могу. Все-таки мессенджеры не предназначены для этой задачи. Кроме того, вам будет сложно разделять служебные чаты и личные, а также у вас появится зависимость от внешних серверов управления, работа которых может быть и нарушена, если какой-либогосударственный орган в очередной раз начнет бороться с условным «Telegram», или если производитель мессенджера введет запрет на одновременный постинг в несколько групп/чатов, борясь с фейковыми новостями.
Для эффективной коммуникации в рамках инцидента используемое вами решение должно иметь возможность организации чатов, обмена файлами и удаленного доступа к рабочему столу. Например, используя Webex Teams, в нем можно под каждый инцидент создать отдельное пространство, куда не только собирать все необходимые доказательства, но и общаться со всеми участниками, участвующими в инциденте. А за счет возможности написания чатботов и интеграции Webex Teams со средствами защиты, вы сразу можете проводить проверку и обогащение полученных артефактов.
Если вы не используете Webex Teams, то схожую идею можно реализовать, например, на следующей связке: отдельный канал Slack для специфичного инцидента (и общий канал для общения, который можно использовать как некий индекс по всем инцидентам), комната Zoom для обсуждения (у вас должна быть оплаченная учетная запись для этого и если вас не смущают постоянные проблемы ИБ у этого сервиса) и страница Confluence для сбора заметок. Затем сводная информация по инциденту заносится в IRP, в качестве которой может выступать как привычная многим Jira, так и специализированные решения по управлению инцидентами.
Whiteboarding для мозгового штурма
У вас есть в вашем SOC доска для мозговых штурмов? думаю, что есть. При удаленной работе вам может понадобиться Whiteboard — такая функция есть в различных средствах коммуникаций. Вы можете удаленно рисовать и обмениваться идеями с коллегами. А если вы использовали доски канбан для контроля командных задач, то они вам понадобятся и на удаленке — используйте, например, Trello, если у вас нет корпоративного решения. Но пользуясь облачными решениями для командной работы, не забудьте настроить соответствующие права доступа, чтобы посторонние не узнали о том, какие у вас проблемы с безопасностью и не смогли вмешаться в процесс расследования и реагирования.
Удаленное помещение
Вы решили, что что аналитики SOC будут работать удаленно. И вы знаете, как это сделать не только технически, но и психологически и организационно. Но, задавались ли вы вопросом, у вас аналитики SOC имеют собственную квартиру или живут в общаге? Кто ваши аналитики первой линии? Высококлассные специалисты, много лет работающие в SOC, и заработавшие себе на собственный пентхаус на Воробьевых горах? Или это еще недавно студенты, живущие с мамой, папой и с младшими братьями и сестрами? В вашем SOC вы можете предоставить им рабочее место и три монитора для наблюдения «за иголкой в стоге сена». А дома у вашего аналитика есть место для 3-х или хотя бы двух мониторов? А если у него брат режется в метре от него в PlayStation и отвлекает его звуками «горящей резины» или «умирающих зомби»? Если аналитик не может по причине отсутствия места работать из дома, вам понадобится вносить изменения в состав и график работы смен.
А еще важно обеспечить удобство и комфорт работы для аналитиков. В корпоративном SOC вы можете потратить много усилий и ресурсов для выбора правильного освещения, шумоизоляции, реверберации, кондиционирования, удобных кресел и т.п. Но дома часто, увы, мы не обладаем такими роскошествами. И поэтому надо более внимательно следить за тем, насколько изменились показатели работы аналитиков до (если вы, конечно, их собирали) и после ухода на удаленку. И уже после их анализа делать соответствующие выводы. Иначе удаленный SOC превратится в «тыкву» — вроде он и есть, но своей задачи не решает, так как аналитики просто неспособны работать в собственных квартирах.
И не забудьте, что физическая безопасность помещения, в котором циркулирует достаточно чувствительная информация, тоже важна.
Архитектура SOC
В условиях пандемии у вас возрастет объем событий безопасности. Во-первых, вам придется активнее мониторить свой VPN-кластер или кластеры удаленного доступа, через которые пользователи будут подключаться к приложениям и данным внутри корпоративной сети или которые будут «прокидывать» трафик пользователей к внешним облачным сервисам. Во-вторых, вам может понадобиться мониторить облачные среды, если ИТ-служба приняла решение временно или уже постоянно перенести обработку некоторых данных и некоторые приложения в облака. И, наконец, у вас возрастает зоопарк различных систем, находящихся дома у пользователей, которые начнут генерить события безопасности и которые надо будет анализировать. Но это еще не все.
Удаленное подключение к SOC
SIEM, IRP/SOAR, ticketing, TI-платформа… Они имеют возможность подключения к ним с удаленной консоли по защищенному соединению (как повезло тем, кто пользуется сейчас облачными SOCами/SIEMами, где это встроенная функция)? Если нет, то надо продумывать вариант с удаленным доступом через RDP/VDI или иные способы подключения, проброшенные через VPN (в этом месте впору задуматься о возможности реализации мобильного или виртуального SOC). В конце концов у вас может быть специальная виртуальная машина, LiveCD или LiveUSB для работы с инструментами SOC; хотя последних вариантов мы почти не встречали — это скорее делается для работы пользователей с их домашних компьютеров, когда надо разделить корпоративные приложения и домашние, с которыми работают ваши близкие.
На наш взгляд VDI (но тоже через VPN) был бы лучшим вариантом с точки зрения контроля доступа и работы с чувствительной информацией, но и прямой доступ при правильной настройке тоже является вполне рабочим вариантом. В обоих случаях необходимо не только использовать многофакторную аутентификацию, но и обязательно проверять подключающийся ПК аналитика на предмет соответствия требованиям по ИБ (установленные патчи, настройки парольной защиты, наличие антивируса или EDR и т.п.). Если у вас на периметре стоит Cisco ASA или внутри сети развернут Cisco ISE, то такую проверку вы можете организовать на них. Мы рекомендуем запретить split tunneling на компьютерах, подключающихся к корпоративному SOC. Это будет гораздо безопаснее; да и для рядовых пользователей на удаленке тоже.
И не забудьте уточнить, требуются ли изменения в ACL пограничного оборудования на стороне компании для доступа к святая святых ИБ? Какова вообще процедура внесения изменений в ACL? Не понадобится ли долгая процедура согласования, да еще и требующая собственноручной подписи на заявке? Сейчас было бы хорошей идеей — пересмотреть все свои политики и инструкции на предмет их работоспособности в условиях невозможности собирать подписи и бегать между начальниками. И даже если у вас электронный документооборот, насколько он приспособлен к оперативному решению вопросов?
Удаленное расследование на удаленных ПК
Специалисты по расследованию привыкли, что они могут прийти к сотруднику, задействованному в инциденте, и снять с его компьютера все логи/дамп памяти/и иные артефакты. Но как это сделать удаленно? Кто-то использует привычные айтишникам Remote Admin, кто-то RDP, кто-то Skype for Business или иные инструменты. Главное, не забыть правильно настроить защитный функционал у этих инструментов и договориться с сотрудниками о процедуре проверки подлинности сотрудников ИТ/ИБ, подключающихся удаленно (ну и про юридические аспекты не забудьте, о чем будет сказано далее). Кто-то использует бесплатные GRR, osquery, встроенные Sysmon или Autorun Utility или коммерческий EnCase (пользователям Cisco AMP for Endpoints не надо беспокоиться — у них есть такой инструмент как Cisco Orbital, который позволяет проводить удаленное расследование). В ряде случаев можно научить пользователей запускать нужный скрипт, который сам соберет необходимые доказательства и защищенным образом передаст в SOC для анализа. Тут важно для себя решить, эти инструменты должны быть установлены заранее (для корпоративных устройств нет проблемы в их предустановке на корпоративный имидж ОС со всеми приложениями) или их надо устанавливать в случае возникновения каких-либо проблем. В последнем случае, однако, появляется риск, что тем самым мы дадим знать злоумышленнику, что его активность обнаружена и он может «покинуть» свою жертву, попутно затерев и все оставленные собой следы. Это непростой вопрос, который, конечно, лучше решать «на берегу», а не в процессе расследования удаленного инцидента.
Я думаю, что я еще вернусь с отдельным материалом по удаленному расследованию и сбору доказательств, а пока просто упомяну ряд вопросов, на которые надо быть готовым ответить при удаленном расследовании:
- Как получить доступ к домашним, мобильным и корпоративным удаленным устройствам? В условии зоопарка домашних устройств, этот вопрос не так прост, как кажется. Особенно это касается мобильных устройств, в отношении которых тоже может потребоваться проведение мероприятий по расследованию.
- Как получить доступ к логам и данным ИБ и какие вообще логи и артефакты на удаленных устройствах нам понадобятся? Как их собирать выборочно?
- Требуется ли административный удаленный доступ для проведения расследования и реагирования, например, сервисные учетные записи, sudo, ключи SSH? Требуется ли внесение изменений в ACL на домашних маршрутизаторах для удаленного доступа (а если они предоставлены и управляются оператором связи)?
- Требуется ли внесение изменений в «белые списки» приложений для работы инструментов расследования и сбора доказательств?
- Как удаленно установить инструменты для расследования и сбора доказательств?
- Как отслеживать включение выключенных удаленных устройств для проведения расследования?
- Как вы будете коммуницировать с жертвой?
Ответы на эти вопросы сильно зависят от имеющейся инфраструктуры, наличия корпоративных стандартов на используемые устройства, системное и прикладное ПО, а также от права сотрудникам использовать личные устройства для работы из дома.
Аутсорсинговые поставщики услуг
Возможно в условиях пандемии вы решите на время воспользоваться услугами аутсорсингого SOC и MDR-провайдера. Тем более, что с них сейчас можно и скидки выбивать :-) Но гораздо важнее понять, насколько ваш текущий аутсорсинговый контракт или контракты учитывают удаленную работу ваших аналитиков? MSSP/MDR/TIP/CERT/ФинЦЕРТ/ГосСОПКА принимают сообщения от ваших сотрудников, с их личных телефонов или адресов e-mail? Не блокируют ли они доступ не с корпоративных IP-адресов? Можно ли подключаться к дашборду у внешних провайдеров не через корпоративный VPN, с помощью split tunneling?
Законодательные требования
Про невозможность удаленной работы коммерческого SOC из-за ограничений ФСТЭК я уже выше писал. Но есть и еще ряд тем, о которых надо помнить при удаленной работе SOC. Знаете свежий анекдот? «Мои дети учатся дома. Прошу администрацию школы сдать деньги на новые шторы, покраску стен и ремонт мебели» :-) Так вот в ряде стран появляется практика, когда сотрудники начинают требовать от работодателя компенсацию за использование квартиры и домашнего компьютера в качестве рабочих инструментов. Думаю, что в России нам это пока не грозит, но сам пример достаточно показателен.
Врядли сотрудникам SOC предлагают выполнять свои служебные обязанности с личных компьютеров (хотя....), но вот рядовые сотрудники вполне могут подключаться к корпоративным ресурсам с домашних устройств. И поэтому возникает закономерный вопрос — на каком законном основании работодатель получает доступ к удаленному и личному компьютеру сотрудника при проведении расследований, сборе артефактов и т.п.? У вас в трудовом договоре или допсоглашении к нему есть пункт о праве компании проводить мониторинг работника? А детальный регламент, что можно, а что нельзя делать в рамках такого мониторинга, есть? Если нет, то вы нарушаете действующее законодательство и сотрудник имеет полное право послать вас при попытке доступа к личному устройству. Тоже касается и установки DLP-агентов или средств учета рабочего времени на домашних компьютерах.
И не забывайте, что ваш SOC может попасть в область действия (scope) какого-нибудь международного стандарта управления ИБ (например, в России уже несколько SOCов прошли сертификацию на соответствие ISO 27001). Продумайте, как вы будете проходить аудит с вашим удаленным SOC? Не будете же вы водить аудиторов по квартирам сотрудников. Или будете?..
Заключение
Вот такие зарисовки о том, с чем нам приходится сталкиваться при проектировании, аудите и разработке планов улучшения центров мониторинга ИБ, в том числе и в России и странах СНГ. Нельзя сказать, что все эти советы невыполнимы или требуют существенных финансовых, временных и людских затрат. Многое из это реализовать достаточно легко. Главное, не спускать эти вопросы на тормозах, так как их игнорирование может привести не только к увеличению времени на проведение расследований инцидентов при удаленной работе, но и даже к их пропуску. Также не стоит думать, что текущая пандемия — это временное явление и скоро все наладится. Если в организации всерьез думаю о непрерывности бизнеса и умеют просчитывать ситуацию на несколько шагов вперед, то мы поймем, что COVID-19 — это всего лишь знак; знак того, что ситуация может повториться уже следующей зимой. Поэтому «сани надо готовить летом». В любом случае, описанные выше советы лишними не будут и в обычной жизни SOC.
ЗЫ. И, кстати, не забудьте дезинфицировать основное помещение SOC перед тем как туда вернутся аналитики.
