Контакты
Подписка 2024

Топ-8 ошибок соответствия ГОСТ 57580.1

Константин Чмиль, 20/10/23

Банковские и финансовые организации – “лакомые” кусочки для киберпреступников: атаки на них особенно часты, а способы кражи информации совершенствуются невероятными темпами. Регулятор вводит все новые положения, которые собраны в ГОСТ 57580.1 и ужесточаются год от года. Если постоянно проходить проверку на соответствие требованиям этого документа, то вероятность возникновения инцидентов можно свести к минимуму.

Автор: Константин Чмиль, консультант по ИБ RTM Group

№ 1. Всеми забытые учетные записи

В ходе проведения аудитов прав доступа были выявлены две главные проблемы: ручное управление доступом и избыточный доступ к данным организаций. Обе они свидетельствуют о несоответствии мере УЗП.3 "Контроль отсутствия незаблокированных учетных записей уволенных сотрудников" (подпроцесс "Управление учетными записями и правами субъектов логического доступа").

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

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

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

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

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

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

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

Известный случай. В 2014 г. бывший сотрудник "Альфа-Страхования" после увольнения воспользовался доступом к корпоративной системе: скачал базу данных заключенных договоров и передал ее посреднику для перепродажи. В результате – два года условно [1].

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

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

В чем опасность бесхозных "учеток"?

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

ris30

№ 2. "Заходите, гости дорогие": нарушение правил доступа к учетным записям после неудачных попыток аутентификации

Еще одна закономерность, выявленная в ходе аудитов, – игнорирование меры РД.11 (подпроцесс "Идентификация, аутентификация, авторизация (разграничение доступа) при осуществлении логического доступа"), требующей блокировать на 30 минут учетную запись пользователя после выполнения ряда неуспешных попыток аутентификации. Организации редко включают данное правило в свою политику, давая злоумышленникам возможность после нескольких неудачных попыток все-таки войти в учетную запись сотрудника и осуществить действия, влекущие за собой похищение конфиденциальных данных.

№ 3. "Хлипкие" пароли

Как показывает статистика [2], пароли – настоящая "головная боль" безопасников. По данным "Ростелеком-Солар" (дочерней структуры ПАО "Ростелеком"), 80% организаций не соблюдает базовых правил парольной защиты: специалисты по анализу защищенности смогли получить администраторские права практически в каждой из тестируемых организаций. Что уж говорить о киберпреступниках.

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

Еще одна проблема: примитивные пароли, на подбор которых у преступников уходит около минуты. Несмотря на то, что мера РД.21 и РД.22 (тот же подпроцесс) гласит о необходимости использования пользователем пароля не менее чем из восьми символов, а администратором – не менее чем из 16 символов, многие работники финансовых и банковских организаций ей пренебрегают.

Показателен случай, произошедший буквально несколько лет назад. В 2020 г. была взломана система крупнейшего создателя сейфов – шведской компании Gunnebo. Злоумышленники украли 19 ГБайт конфиденциальных данных, которые впоследствии были "слиты" в даркнет, а именно соглашения об обеспечении физической безопасности шведского парламента и нового офиса шведского министерства по налогам, схемы банковских хранилищ и систем наблюдения, за которые грабители банков охотно заплатят огромные деньги [3].

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

№ 4. Антивирус на "автопилоте"

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

№ 5. Отказ от регистрации неконтролируемого использования технологии мобильного кода

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

В итоге страдает защита от вредоносного мобильного кода.

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

№ 6. Игнорирование мер защиты образов виртуальных машин

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

Для примера: сотрудники ИТ-отдела организации объединили несколько физических серверов в один, на котором расположено несколько виртуальных машин, что снизило эффективность средств защиты, которые функционировали до внедрения. Следовательно, они не смогли обеспечить защиту и контроль, требования к которым указаны в процессе 7 "Защита среды виртуализации".

№ 7. Отсутствие управления инцидентами

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

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

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

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

№ 8. Отсутствие документации с правилами удаленного доступа

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

Лучшим решением в рамках этого требования является использование MDM (Mobile Device Management). MDM – это системы, с помощью которых ИТ-службы организаций могут управлять устройствами (телефонами, планшетами, ноутбуками и другой техникой, используемой в рабочих целях), находящимися у сотрудников. Без MDM меры данного процесса компенсировать крайне сложно.

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


  1. https://www.banki.ru/news/lenta/?id=8287417 
  2. https://rt-solar.ru/events/news/1840/ 
  3. https://siliconangle.com/2020/10/28/security-company-gunnebo-hacked-stolen-data-published-dark-web/ 
Темы:Банки и финансыЧек-листЖурнал "Информационная безопасность" №5, 2023ГОСТ 57580.1

Обеспечение кибербезопасности.
Защита АСУ ТП. Безопасность КИИ
Конференция | 28 июня 2024

Жми для участия
Обзоры. Спец.проекты. Исследования
Участвуйте в обзорах / исследованиях проекта "Информационная безопасность"!
Станьте автором журнала!
Статьи по той же темеСтатьи по той же теме

  • Пять главных ошибок при выборе NGFW
    Анна Комша, руководитель практики NGFW в Positive Technologies
    Как, не допустив ошибок, подойти к выбору NGFW, чтобы он стал основным средством сетевой обороны и успешно справлялся с базовыми сетевыми задачами?
  • Персональные данные в 2024 году. Чек-лист
    В 2023 г. произошли сотни утечек персональных данных. Ситуация обостряется с каждым годом и требует новых мер реагирования: технических – в виде создания все более совершенных средств защиты информации и организационных – в том числе правовых.
  • Как организовать процесс безопасной разработки в 5 шагов
    Константин Саматов, Член Правления Ассоциации руководителей службы информационной безопасности
    Разберем значение процесса РБПО в организации, его создание, сложности и пути их преодоления.
  • Ransomware и вы: как заметить атаку шифровальщика и что делать (чек-лист)
    Лада Антипова, специалист по реагированию на инциденты Angara SOC
    Cкорость работы шифровальщиков в большинстве случаев крайне высока, от нескольких минут до пары часов. Тем не менее, есть шансы минимизировать ущерб. Что для этого нужно, кроме внимания к деталям?
  • Актуальный чек-лист построения защиты объектов КИИ в 2023 г.
    Константин Саматов, Член Правления Ассоциации руководителей службы информационной безопасности
    Вопросы построения защиты объектов КИИ являются актуальными для специалистов по ИБ с 2018 г. Продолжая серию статей, рассмотрим вопросы обеспечения безопасности КИИ, актуальные на середину 2023 г.

Хотите участвовать?

Выберите вариант!

КАЛЕНДАРЬ МЕРОПРИЯТИЙ 2024
ПОСЕТИТЬ МЕРОПРИЯТИЯ
ВЫСТУПИТЬ НА КОНФЕРЕНЦИЯХ
СТАТЬ АВТОРОМ
Linux
23 мая. Инструменты миграции на защищенный Linux
Участвуйте!

More...
Обзоры. Исследования. Спец.проекты
Обзоры и исследования проекта "Информационная безопасность"
Жми, чтобы участвовать