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.

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

Отзыв про CRISC Review Manual 6-th

Прочитал официальный курс от ISACA под названием CRISC Review Manual 6-th Edition (2015 год). Касаемо года курса подумал, что, беря во внимание санкции, это нормально, да и в оценке рисков ничего не меняется, т.к. методология по оценке рисков весьма консервативна. Поэтому лучше прочитать что есть, чем не прочитать ничего. Еще мне казалось из названия, курс будет исключительно про процесс оценки рисков. А оказалось всё совсем не так. На самом деле ситуация с курсом следующая.

CRISC - полноценный курс для специалиста ИБ, в котором методология оценки рисков занимает совсем небольшую часть. В основном рассказывается, с какими угрозами и с каких сторон может столкнуться организация. Что любую технологию или решение нужно рассматривать всесторонне. Например, что МСЭ это не только ПАК, который нужно разместить в ЦОД, а нужно правильно раздать роли по его администрированию, не забыв об обучении администраторов, регулярно проверять правила и конфиги, создать общий процесс управления изменениями, собирать логи, направлять их в SIEM, устанавливать процесс реагирования на инциденты на основании них. По другим средствам защиты или решениям, нужно поступать аналогичным образом. 

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

Рекомендую и одновременно разыскиваю 7-ю версию курса.