8 недостатков по версии ФСТЭК и что с этим делать

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

1.

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

2.

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

3.

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

4. 

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

5.

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

6. 

Здесь всё аналогично. Будет достаточно персонала, появятся более лучшие результаты.

7.

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

8.

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

What would I do?

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

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

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

Итак, я предложу меры сразу для парирования внутреннего нарушителя, ибо с внешним всё более-менее понятно. По каждой мере я сразу буду давать комментарии и ограничения, если таковые будут. За основу я непременно беру давно полюбившиеся мне материалы от Алексея Лукацкого про 10 базовых защитных мер от ФСТЭК и 8 защитных мер по версии австралийского аналога ФСТЭК.

 

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

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

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

3.       DLP контроль. На основании перечня конфиденциальной информации нужно иметь контроль информации, которая пересекает контролируемую зону. Это прежде всего эл. почта, web, USB. На каждом ПК и сервере должны быть установлены агенты DLP системы и должен осуществляться контроль выделенным персоналом. Я не большой специалист по DLP, есть много, которые много умнее меня, но смысл здесь в том, что нужно иметь возможность мониторить весь трафик, который выходит из организации через эти 3 канала потенциальных утечек. Лучше иметь превентивный контроль, установив DLP в разрыв.

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

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

6.       Стандарты безопасности. Чтобы создать замкнутую программную среду и выполнить так называемый харденинг, не обойтись без стандартов безопасности на ОС, сетевое оборудование, СУБД. Стандарт безопасности – очень важная вещь, так как он устанавливает конкретные настройки, чтобы системы были безопасными. Сразу появляется ограничение в виду процессов по импортозамещению по многих организациях. Чтобы не делать пустую работу, типа применили стандарт сегодня, а от Windows отказались завтра, предлагается начинать разрабатывать стандарты сразу по мере импортозамещения. Например, заменили МСЭ, сделайте стандарт для него и примените. Заменили СУБД, сделайте стандарт для неё и примените. Когда замените Windows на любые рус Linux, сделаете тоже самое. По мере применения стандартов безопасности, нужно начинать думать о процессе их контроля. То есть вам потребуется механизм комплаенса для них.

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

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

9.       Технологические учетные записи. Необходимо защитить все технологические УЗ. Самый действенный способ установить на них сложный пароль с длинной с прицелом на будущее. Так как такие пароли никто не запоминает, их всегда хранят в системах хранения паролей, а для ввода используют копипаст, длина пароля может быть любой, можно и 50 символов. Главное, чтобы системы нормально воспринимали такую длину. Если не воспринимают это повод для их доработки. Дело в том, что это исключит возможность его подбора в перспективе, а так как процесс смены паролей для ТУЗ не простой, лучше сразу установить наиболее сложный, чтобы реже проводить последующие смены. Стоит ли говорить, что все пароли должны быть уникальными.

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

Cybersecurity Career Master Plan

Прочитал отличную книгу под вызывающим названием Cybersecurity Career Master Plan (2021 год).

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

Как айтишникам ставить задачи по SMART

SMART is a mnemonic acronym that stands for the following:

• Specific (what, who, where, and why)

• Measurable (motivational)

• Achievable (realistic)

• Relevant (in line with the overall dream)

• Time-based (end date and time-driven)

Это означает, что мы адресно и четко должны писать задания, задания должны быть точно выполнимы (не выполнить всё на свете и быстро), ставим реалистичный срок. Мы сами должны понимать, как будем проверять выполнение заданий. Выполнено / не выполнено уже будет зависеть от многих иных факторов.

Пример 1:

to: servicedesk@bank.ru

Добрый день!

В соответствии с требованиями политики ИБ прошу отключить следующие учетные записи до конца рабочей недели (02.09.2022 пятница).

Ivanov

Petrov

Sidorov

Скрипт для отключения у вас имеется (или прилагается).

С уважением

 

Становление ИБ в организации

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

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

Буду рассматривать актуальные риски ИБ текущего времени:

• риски нарушения непрерывности бизнеса;
• риски несоответствия 152-ФЗ и утечек персональных данных;
• риски несоответствия PCI DSS.

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