Проблематика безопасности 1С: сложность контроля кастомизации
Когда мы говорим о безопасности ERP, я называю это сердцем компании, в котором содержится наиболее ценная, критически важная информация. Я думаю, многим сегодня это понятно. Это и данные клиентов, и инженерная информация, и номера банковских счетов, и персональные данные сотрудников, и интеллектуальная собственность. И все это, конечно, в общей сложности всегда является и будет являться лакомым кусочком для злоумышленников.
Какая здесь есть проблематика, тоже ни для кого не секрет. Понятно, что ни одна 1С из коробки не открывается и в большинстве случаев не удовлетворяет требованиям заказчиков. У заказчиков есть свои особенности бизнес-процессов, и в большинстве случаев 1С дорабатывается бесконечное количество раз, как и любое другое ПО.
И тут мы сталкиваемся с тем, что следить за контролем настроек, кодом и веб-приложениями достаточно сложно. Особенно если не использовать какие-либо автоматизированные средства, а делать это по старинке: проводить аудиты людьми. Здесь есть и человеческий фактор, и дороговизна, и отсутствие экспертности, и долгий временной цикл, и так далее.
Решение: автоматизированный продукт SafeERP и его функционал
Мы предлагаем все это автоматизировать и применять такой продукт, как SafeERP.
Наш продукт разрабатывается с 2012 года. Только подумайте, какая у нас накоплена экспертиза. Мы начинали с защиты SAP и продолжаем развивать этот продукт, он называется Security Suite. В нем у нас есть анализ кода ABAP – это в случае SAP – и контроль платформы. У нас была рабочая группа с SAP, и мы многое переняли из экспертизы самого вендора.
И вот с недавнего времени, уже как три года, даже больше, у нас появился другой модуль – он называется Extension Module. По опыту SAP мы теперь также комплексно подходим к вопросу безопасности 1С. То есть у нас есть поиск уязвимостей в коде 1С и контроль настроек 1С.
Помимо всего прочего, этот же модуль дополнен инструментами безопасной разработки, такими как статический анализ кода популярных языков программирования, динамический анализ кода. Есть даже автоматизированный пентест, и с недавнего времени из новинок вышел еще SCA – контроль open source.
Какие задачи решает наш модуль, связанный с 1С? Это поиск и выявление недекларированных возможностей в коде, тех самых уязвимостей в коде 1С. Мы ищем их по своим собственным сценариям. Большая часть сценариев у нас, конечно же, на безопасность: мы компания в области информационной безопасности. Но также есть сценарии на качество, чтобы этим инструментом было полезно пользоваться и разработчикам.
Кроме того, в одном интерфейсе можно выявлять потенциально небезопасные настройки платформы 1С, контролировать безопасность кластера 1С, роли пользователей, журналирование и настройки журналирования. В коде можно выделять расширения, внешние обработки. Код мы берем напрямую из базы данных 1С, из конфигурации 1С.
В общем, инструмент достаточно широкий с точки зрения того, как вы можете его использовать и настраивать под себя.
Кейс 1: Контроль настроек 1С: роль имеет права на объекты нескольких подсистем
Теперь поговорим о кейсах – какие случаи бывают на практике и как все это защищать.
Заказчик – крупный логистический оператор, у которого 1С лежит в основе всех ключевых бизнес-процессов: от управления складом до финансового учета.
На этапе внутреннего расследования заказчик выявил, что у него есть учетная запись, которая совмещает в себе несколько ролей: роль инициатора закупок, роль операциониста и роль согласующего. Любой злоумышленник, получив доступ к такой учетной записи мог сделать все что угодно. Например, создать фирму-однодневку в справочнике контрагентов, сделать фиктивную заявку, сам же ее утвердить, сгенерировать счет, провести платежное поручение и, как следствие, вывести себе куда-нибудь деньги.
Такое могло бы произойти. И какая здесь уязвимость? Нарушен, наверное, самый базовый принцип информационной безопасности – принцип разделения обязанностей. Конечно, так не должно быть, чтобы учетная запись работала сразу в нескольких подсистемах.
Потенциальные последствия этого всего, думаю, многим понятны: финансовые потери, налоговые риски, искажение отчетности, юридическая ответственность, вплоть до уголовной.
Так как заказчик использовал наш инструмент, он мог выявить это, активировав контроль настроек. У нас есть сценарий «Роль имеет права на объекты нескольких подсистем». Заказчик мог делать проактивную защиту и заранее выявлять нелегитимное количество ролей у одного пользователя. Но также мог бы выявить это и постфактум. Конечно, постфактум разбирать такой инцидент намного хуже, потому что он бы уже случился.
На изображении видно, что у нас есть сценарий. Это достаточно критическая проверка с высоким статусом. Соответственно, можно искать или сужать круг подозреваемых. И, как следствие, конечно, это нужно делать регулярно: регулярно следить за такими ролями, чтобы ни у кого не было избыточных прав.
Итоги этого проекта – устранение уязвимости в кратчайшие сроки, снижение рисков и сохранение репутации. Утечка данных предотвращена.
Кейс 2: Возможность открытия внешних отчетов и обработок из режима «1С:Предприятия»
Следующий кейс – компания, федеральная сеть магазинов, использующая 1С для управления товарооборотом. Здесь тоже понятно, что 1С – это ключевой инструмент, содержащий миллионы данных клиентов.
Сотрудники этой компании начали получать странные письма, например «Акт сверки.erf» и «Обновление цен.epf». Сотрудники, ни о чем не подозревая, открывали эти письма через режим 1С:Предприятия, и тем самым внедрялся вредоносный код. Он мог перехватывать логины и пароли, сохранять их на внешний сервер, повреждать данные о товарных остатках, вызывая хаос в логистике, и блокировать доступ к критическим данным.
На этапе расследования было выявлено, что у многих пользователей в этой компании был разрешен запуск внешних отчетов и обработок через режим 1С:Предприятия.
Потенциальные последствия этого всего – массовое заражение рабочих станций вирусами-шифровальщиками, простой бизнеса, утечка персональных данных, финансовые манипуляции и так далее.
Как это можно было бы предотвратить, используя SafeERP? У нас есть возможность запустить анализ системных настроек, где как раз подсвечивается, что у многих пользователей активирована возможность открытия внешних отчетов и обработок из режима 1С:Предприятия.
Какие меры здесь следует принять? Блокировать опасные настройки и отключить эту возможность там, где она не нужна. А в большинстве случаев она не нужна. Также нужно делать централизованное управление такими отчетами. Все внешние отчеты и обработки теперь в этой компании проходят через защищенный корпоративный портал.
Еще одна мера – обучение сотрудников кибергигиене. Это различные образовательные лекции на тему того, что, когда вы открываете письма, нужно следить за тем, откуда они пришли.
Ну и автоматизация контроля: теперь SafeERP на постоянной основе, в режиме заданного расписания, проверяет системные настройки 1С.
Итоги проекта – угроза нейтрализована, запуск внешних файлов заблокирован, инцидент с вредоносным кодом устранен. Как следствие, повышен уровень защиты. Теперь любые данные клиентов и финансовая отчетность изолированы от несанкционированного доступа.
И проактивная защита SafeERP исключает повторение данного сценария, так как работает, в отличие от людей, и днем, и ночью.
Кейс 3: Контроль целостности профилей безопасности 1С
Следующий кейс – это контроль целостности профилей безопасности.
Здесь у нас крупное промышленное предприятие, которое также автоматизирует процессы управления через 1С. Это и склад, и логистика. После недавнего обновления 1С у предприятия начали возникать аномалии: самопроизвольные изменения в файлах, шифрование документов, попытки подключения систем к внешним IP-адресам. Сотрудники это заметили.
На этапе расследования было выявлено, что были активированы такие настройки, как полный доступ к файловой системе сервера, доступ к COM-объектам и внешним компонентам, доступ к привилегированному режиму и функциям криптографии.
Соответственно, мошенник с такими настройками мог внедрить вредоносный код, подменять реквизиты поставщиков, собирать данные о запасах, блокировать выполнение критических задач.
Потенциальные последствия этого всего – полная остановка производства, утечка коммерческой тайны, финансовые манипуляции и так далее.
Сотрудники этой компании на этапе расследования активировали контроль безопасности кластера 1С, который есть в SafeERP, и выявили, что опасные настройки там, где они должны были быть выключены, оказались включены.
Какие меры были приняты? Эти настройки быстро вернули в режим «выключено», сегментировали права: сделали отдельные профили для разработчиков, администраторов и пользователей. Также настроили аудит конфигурации на постоянной основе, то есть запуск по расписанию и постоянную проверку конфигураций и настроек безопасности кластера через SafeERP.
Итоги – угроза устранена за сутки, вредоносный код удален, риски снижены, исключен доступ к критическим ресурсам и обеспечена проактивная защита.
Кейс 4: Привилегированный режим 1С
Следующий кейс уже связан с анализом кода.
Наверное, для вас опять же не секрет, что некоторые разработчики часто используют метод «УстановитьПривилегированныйРежим». И вот в одной компании разработчик установил этот режим во внешней обработке, связанной с полномочиями, и тем самым сделал обход стандартных проверок прав доступа.
Делал он это не специально, а потому что ему так было удобно. И злоумышленник – назовем это так, хотя вообще это был внутренний сотрудник, экономист – узнал, что есть такая возможность: назначать любые права кому угодно. Возможно, он пил пиво с этим разработчиком, мы точно не знаем.
И он назначил себе роль администратора системы. Потом внедрил расширение, где сделал себе перечисление 1% с каждой транзакции на счет. Тем самым он модифицировал бизнес-логику, внедрил скрипты для перехвата информации и создал скрытые базы данных для дальнейшего шантажа.
Потенциальные последствия этого всего – финансовые потери из-за манипуляций с отчетностью, крупная утечка данных, остановка операционной деятельности для различных проверок и аудита.
Этого всего могло бы не произойти, если бы компания применяла статический анализ кода, который как раз ищет в коде такие методы, как «УстановитьПривилегированныйРежим». Мы их также подсвечиваем красным и даем рекомендации, как их исправить.
Не везде это критичный случай, но следить за этим в любом случае нужно. И также разработчик может самостоятельно проверять свой код перед тем, как переносить его в прод.
80% утечек в 1С происходят из-за избыточных прав и ошибок в кастомизированном коде, а не из-за сложных хакерских атак, как многие представляют. И регулярный аудит – это ваша лучшая защита.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
Вступайте в нашу телеграмм-группу Инфостарт