Иерархия безопасников - Форум по вопросам информационной безопасности

Добрый день.

Такой вопрос, в какой последовательности, в порядке возрастания по подчинению вышестоящему, должны располагаться следующие должности:
- администратор ИБ;
- администратор ИБ ИС;
- ответственный за безопасность и обработку ПДн.

Просто немного запутался в них и хотелось бы прояснить этот момент.

В приведенной вами "конфигурации" нет иерархии...
По классике, имеется служба безопасности. По классике (опять-таки), нач. СБ подчиняется непосредственно руководителю организации. В состав СБ входят как дежурные физ.охраны, так и информационщики. А они уже могут назначаться как угодно и по любой удобной схеме. Да, существует такой полумифический в конфиденциальных ИС персонаж, как "ответственный за защиту информации (безопасность информации)". Пошел он из системы ЗГТ. Суть в том, что администратор следит за стабильностью системы защиты, а также контактирует с пользователями ИС. И, как правило, исключительно в технической части. В случае подозрения на несанкционированный доступ - либо решает самостоятельно (в рамках своих инструкций), либо обращается к "ответственному", который уже принимает решение (в рамках уже для него установленных инструкций). Также "ответственный" следит за выполнением организационно-режимных мероприятий и подчиняется нач. СБ непосредственно.

Иными словами, никто не будет против, если при недостатке штата "ответственный" и "администратор" совпадут в одном лице. Можно функции разнести между разными сотрудниками, и тогда ранг "ответственного" будет, в целом, выше ранга "администратора".

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

"Администратор безопасности"..., это больше про навесные СЗИ и местечковые армы.

Сейчас многие информационные системы (erp, plm, mes и др ) имеют встроенные средства обеспечения безопасности, причём тесно интегрированные в основной функционал. ( про сертификацию не надо, речь про практическое ИБ). Тут либо под каждую систему набирать "администраторов безопасности", что дорого, либо обязать соблюдать практические нормы ИБ, просто штатных администраторов. Учить их выстраивать защищенную архитектуру.

Роль безопасника сводится к контролю и аудиту, а "исполнители" разбросаны по системам.

to Dfg
И сертифицированные СЗИ - это тоже практика. Разница лишь в цене и меньшем вопросе со стороны регуляторов...

Информационная система - это не только программно-аппаратный состав. Уже надоело слушать вопросы в стиле "у нас на ПК установлена такая-то информационная система, можем мы на этот ПК еще одну налепить?". А встроенные средства аудита и контроля имеют все-таки программные продукты (СУБД, ОС, прикладное ПО различного типа, прошивки аппаратных средств и т.д.). Причем их сертифицированные версии от несертифицированных различаются минимально (разве что добавление функционала от версии к версии происходит в разы медленнее)...

Правила хорошего тона запрещают в качестве безопасников использовать сисадминов. Да и не нужно сисадминам заниматься защищенной архитектурой - в части защиты они должны просто выполнять требования (приказы) штатных безопасников. Конечно, это справедливо для случая серьезных организаций с нужным объемом штата сотрудников. В противном случае, да, действует правило "сисадмин-эникейщик + безопасник-универсал + ты-ж-программист"... И тогда ни у кого не возникает вопросов по иерархии, подчинению, контролю и аудиту, ага :)

1. Брать на каждую позицию Админа по Ибшнику? Ну в принципе если компания готова платить то наверное где то такое и есть.)

Пример почтовый сервис, можно конечно взять иб-шника чтобы настройки крутил связанные с безопасностью (dkim, spf, etc) Но зачем, если это можно выдвинуть требования админу почтовика а затем проверить и поставить на контроль.

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

При таком подходе мониторинг должен быть реальным и непрерывным. Например все критические конфиги технически мониториться на изменение.

Ну или штат ИБ делать равным штату ИТ, и пусть каждый ИБшник свой уголок охраняет и зорко следит за ИТ соседом )

2. Периметровые вещи в виде накладных и пограничных СЗИ. SecretNet, МЭ, Ids и прочее вот тут да, 100% вотчина ИБ. Тут нет двойного функционала, тут все заточено на бещопасность, безопасность тут основная услуга. ИТ там делать нечего.

2 Dfg ИМХО

ИБ (в том числе представитель разработчика, например) ставит рамочные условия ИТ, а те в этих рамках "эникеят", Например, ИБ определено, какие программы и полномочия давать пользователю (из простых и повсеместных), а ИТ выбирает нюансы реализации. Естественно,чем больше структура, тем меньше общих работ у этих администраторов. Например, установка драйвера принтера - полномочия ИТ, а решения на разрешение доступа к сетевому ресурсу - полномочия ИБ. То есть ИТ "ближе к клиенту", а ИБ ориентировано на профилактику и отражение угроз. В свою очередь и ИТ могут заказать ИБ конфигурации настроек для общих встроенных систем (тех же экранов) Всё от квалификации.
"Ответственные" - это как раз интерфейс при обращении к административному ресурсу, в том числе физической охране, кадрам, постановкам задач (количество, состав и разграничения информации). Админы это получают уже "в нарезке"
Речь не об иерархии, а о разграничении работ и полномочий. Формально всё замыкается на Первое лицо, контролируется федеральными структурами: ФСБ, ФСТЭК, РКН и пр., и ведомственными проверяющими, у кого есть.

Идеальный процесс:
Начало -> Руководство дает ИТ-задачу отделу ИТ и частично отделу ИБ (да-да, для контроля) -> отдел ИТ предлагает реализацию и показывает ее отделу ИБ -> отдел ИБ либо "заворачивает" реализацию обратно (по своим причинам, не всегда обязательным к понимаю отделом ИТ), либо вносит уточняющие коррективы и передает обратно отделу ИТ -> отдел ИТ реализацию внедряет и при всех сложностях/уточнениях советуется с отделом ИБ -> отдел ИБ проверяет безопасность реализации и либо заставляет переделать, либо дает "зеленый свет" -> нанести, подождать, смыть, повторить (с) -> Конец...
Увы, это плохо работает из-за большого числа шагов процесса и, зачастую, из-за недостатка квалификации ИБшников в ИТ-технологиях по сравнению с ИТшниками. Смешной боянЪ с патчем ядра KDE под FreeBSD это наглядно демонстрирует - ИБшник чувствует, что ядро нужно патчить аккуратно, но как именно - не в курсе. Ибо ИТшники могут позволить себе изучать новые технологии, явно связанные с их работой, а у ИБшников есть иной геморрой, требующий всецелого внимания (привет регулятор, ага!) Добавим сюда обязанность постоянного контроля всех реализаций, внедренных отделом ИТ, - получим работу на износ.
Выход, найденный во многих конторах, это введение понятия "степень доверия", в рамках которых ИБ не столько перекладывает обязанности на ИТ, сколько позволяет им делать свою работу и осуществлять последующий контроль без существенного влияния со своей стороны. Недостатки такого подхода очевидны, но достоинства, увы, зачастую решают...
Потому, думается мне, разделение ИБ и ИТ отделов делать в большинстве случаев не надо. Так и коллектив получается устойчивей (нет случаев аля "Это гов*ки из ИБ мне только что такую шикарную систему конференции завернули! А х*р им в рыло - внедрю по-тихому, чтобы не зря столько времени маны курил и тестил"), и работа ИБ/ИТ идет параллельно (привет АСЗИ, ага). Это, конечно, не призыв к админам-безопасникам и безопасникам-эникейщикам, но предложение решать проблемы не на уровне взаимодействия отделов со своими зонами ответственности, а на уровне конкретных лиц, работающих в команде (тандеме)...

Вот теперь, каюсь, грешен - получилось в духе той самой "агасофии". Можете ругать, товарищи, если что не так... :)
*в сторону* активная работа над диссертацией меняет восприятие и подход к обработке информации, ага...