Предыстория

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

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

Вот как подобный доступ был бы согласован:

Бот

Если не человек выполняет согласование, значит согласование выполняет программа.

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

Так как какие же правила можно написать для бота?

Политика сетевой безопасности

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

Давайте рассмотрим пример нескольких положений такой политики сетевой безопасности:

Неправда ли неплохо? Мне кажется достаточно красивый способ написания политики сетевой безопасности. На картинке прямоугольник это граница VLAN.

Давайте рассмотрим несколько стрелок на изображении выше:

• доступ (1) из DMZ в DMZ другого VLAN (другой информационной системы) разрешен так как стрелка нарисована;

• доступ из DMZ в DB запрещен так как стрелка не нарисована;

• доступ из DMZ в APP разрешен так как стрелка нарисована;

• доступ (3) из APP в DB разрешен так как есть стрелка;

• доступ между APP и DMZ разрешен по любым портам так как есть стрелка;

• доступ из DB в DMZ запрещен так как стрелки нет;

• доступ из DB в APP запрещен так как стрелки нет;

• доступ (2) от пользователей к DMZ и APP серверам разрешен так как стрелка нарисована.

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

Сетевой доступ

Напомним как выглядит правило на межсетевом экране уровня сети:

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

Дополним сетевой доступ другими техническим полями и получим следующее:

Можно кликнуть на IP, на сеть и посмотреть связные доступы и другие параметры. Пример клика на IP:

Реестр информационных систем

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

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

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

Реестр сетей

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

Правила бота

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

1. IP адреса;

2. группы IP адресов;

3. система;

4. порт;

5. протокол;

6. действие: согласовать доступ, отклонить.

При написании правил воспользуемся форматом YAML и опишем для примера следующие (выделенные ранее цифрами 1,2,3) разрешенные сетевые доступы из политики сетевой безопасности.

Правило номер 1 (разрешен доступ из DMZ любой системы в DMZ любой другой системы):

PROM_allow:
    comment: Разрешено в чужую DMZ по HTTPS по TCP
    src:
      purpose:
        zones:
          - PROM_DMZ # с сервера из любой DMZ сети любой системы
    dst:
      purpose:
        zones:
          - PROM_DMZ # можно к серверу в любой DMZ сети любой системы
    ports: [443]     # по порту 443
    protocols: [TCP] # транспорт TCP
    action: [allow]  # согласовать доступ

Правило номер: 2 (разрешено пользователям системы обращаться к серверам своей системы):

USERS_allow:
    comment: Согласовывать доступ своим пользователям
    src:
      purpose:
        zones:
          - USERS # из сетей помеченных как пользовательские
    dst:
      purpose:
        zones:
          - DMZ
					- APP
    ports: [any]  # по всем портам
    busines: same # вот этот параметр и отвечает за самое интересное:
                  # доступ разрешен только в свои DMZ сети
    protocols: [TCP]
    action: [allow]

Как вы понимаете любой доступ пользователей своей системы будет согласован к серверам своей системы так как указан порт "any", соответственно мы должны анализировать журнал согласованных доступов на предмет злоупотреблений.

Правило номер 3 (разрешен доступ в сегмент баз данных своей системы по портам SQL-net):

DB_allow:
    comment: Разрешено в свою DB по SQL-net
    src:
      purpose:
        zones:
          - APP # с сервера из любой APP сети
    dst:
      purpose:
        zones:
          - DB  # можно к серверу в любой DMZ сети
    business: same          # только со своего же сервера
    ports: [1520-1525,5432] # только стандартные доступы к базе данных
    protocols: [TCP]        # транспорт TCP
    action: [allow]         # согласовать доступ

А теперь давайте напишем защитное правило запрещающее опасные доступы:

 DB_BLOCK:
    comment: Доступ из DB запрещен куда-либо
    src:
      purpose:
        zones: [DB] # из сегмента баз данных
    dst:
      purpose:
        groups: [APP,DMZ] # в сегменты приложений и демилитаризованную зону
    ports: [any]
    protocols: [any]
    action: [deny] # действие: отклонить доступ при согласовании

Возвращаясь к первой заявке с которой началась статья получается такое правило:

ANY_to_KMS_allow:
    comment: Разрешено до сервера активации лицензий KMS Microsoft
    src:
      purpose:
        zones: [any] # конечно же реализована защита что any
    dst:						 # это внутренние сети, а не внешние
      purpose:
        hosts: [192.168.2.111]
    ports: [1688] # Разрешаем только порты KMS
    protocols: [TCP]
    action: [allow]

Приоритет правил

Естественно как правила межсетевого экранирования применяются к сетевым пакетам в последовательном порядке так и правила согласования этих правил писать необходимо в определенном порядке:

По умолчанию разрешающие правила (VIP правила разрешающие), например:

ANY_to_SIEM_0.3:
    comment: Разрешено из ANY до серверов безопасников для журналирования по Syslog для целей SOC
    src:
      purpose:
        zones: [any]
    dst:
      purpose:
        hosts: [192.168.3.33]
    ports: [514] # порт syslog
    protocols: [UDP/TCP] #TCP на случай если строка лога большая
    action: [allow]

По умолчанию запрещающие правила (100% запрещающие), например:

DB_Block:
    comment: Запрещено из базы в интернет напрямую
    src:
      purpose:
        zones:
          - DB
    dst:
      purpose:
        zones: INTERNET # кастомная своя зона
    ports: [any]        # запрещено по всем портам
    protocols: [any] 		# запрещено по всем протоколам
    action: [deny]      # от слова совсем

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

Согласовать нельзя досогласовать

Начиная отклонять доступы неизбежно наткнетесь на следующие недовольства:

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

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

3. другие.

Мы начали делать так: если 80% доступов в согласовании бот сопоставил с разрешающим правилом, то 80% доступов согласовываем, а остальные либо неизвестные либо запрещенные отклоняет. Естественно было недовольство из разряда "доступ нормальный, но вы его отклонили, почему?".

Тогда мы решили и переработали систему следующим образом:

1. все доступы, что попали под разрешающие правила - мы согласовываем;

2. все доступы, что попали под запрещающие правила - мы отклоняем;

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

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

Статистика

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