Проблемы внедрения ИБ в больших организациях10.11.2020 11:33

Всем привет!

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

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

На заводе работают порядка 16 000 человек на 5600 автоматизированных рабочих местах (АРМах). Инфраструктура расположена в двух ЦОДах плюс в мобильном ЦОДе. Итого 119 объектов/отделов на 15 площадках.

Состав внедряемых подсистем:

СЗИ от НСД плюс централизованное управление;
платы СДЗ плюс централизованное управление;
межсетевые экраны;
VPN-шлюзы;
система обнаружения вторжений;
анализ защищенности;
USB-токены;
SIEM-система;
антивирусная защита.

Вендоров называть не буду, чтобы не сочли за рекламуЛучше расскажу про сроки. Начало работ — 15 июля 2019 года, окончание — 27 декабря 2019 года.
Можно долго дискутировать, какие проекты проще: ИТ или ИБ. С одной стороны, ИБ-проекты сильно опираются на готовую нормативную базу, что упрощает выбор технических решений и организационных мероприятий. ИТ-проекты же крайне бизнес-зависимы (за исключением инфраструктурных, конечно). В первую очередь здесь необходимо учитывать требования функционального заказчика, который будет взрывать мозг вам и вендору.

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

В рамках данного проекта мы должны были выполнить (сокращенный перечень):

постановление Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»;
приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»;
приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»;
приказ ФСТЭК России от 28.02.2017 № 31 «Об утверждении Требований к обеспечению защиты информации, содержащейся в информационных системах управления производством, используемых организациями оборонно-промышленного комплекса»;
приказ ФСТЭК России от 29.05.2009 № 191 «Об утверждении Положения по защите информации при использовании оборудования с числовым программным управлением, предназначенного для обработки информации ограниченного доступа, не содержащей сведений, составляющих государственную тайну»;
приказ ФСБ России от 10.07.2014 № 378 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности».

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

Система защиты должна была быть аттестована, а потом проверена регуляторами, что очевидным образом максимально повышает приоритет задаче: неукоснительное выполнение требований.
Требования прописаны в государственном контракте, и несмотря на то, что в данном списке есть неприменимые к заводу нормативно-правовые акты (НПА), их требования необходимо выполнять.
Некоторые НПА предъявляют разные требования к одним и тем же элементам, а следовательно реализовывать их надо будет все. Т.е., если один НПА предъявляет минимальные требования, а другой — повышенные, реализовывать надо будет по максимуму.
В информационной безопасности, к сожалению, небольшой перечень решений, которые можно было бы применить. Так что если средство защиты не подходит к конкретной ИТ-архитектуре, то заменить его очень сложно, тем более в рамках четкого ТЗ по 44-ФЗ.
При отсутствии технической возможности выполнения требований, можно применить организационные мероприятия. Но это потребует огромного количества согласований и может растянуться на годы в такой огромной организации, как военный завод. А срок исполнения проекта ограничен.

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

Четкие этапы внедрения новых мер.
Сроки данных этапов.
Ответственных за выполнение плана.
Обязательное обучение сотрудников и ответственных.
Быть принятым на уровне организации.

Источник
Так случилось, что данный проект изначально вел другой интегратор. В течение трёх лет по всем правилам был проведен аудит и техническое проектирование. В начале 2019 года завод готов был заключить договор с единственным поставщиком на работы по внедрению, но… интегратор ушел, что называется, «в несознанку». Он перестал отвечать на письма и звонки, а когда все же удалось с ним связаться, ответил, что данный проект его не интересует.

Это породило две проблемы — в проекте была чужая спецификация, и сроки уже начали поджимать.

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

Проблема крылась в другом: за строчкой в спецификации — 5600 СДЗ — может скрываться внедрение на одной площадке, а может и по всей области (в итоге площадок оказалось 15). В данной строке не виден парк конечных станций, их распределение и готовность к внедрению.

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

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

Посмотрев первоначальный проект и предполагаемые проблемы, стало понятно, что всю спецификацию надо менять. Например, прошлый проектировщик заложил 2000 плат СДЗ с локальным (!) управлением, что должно было стать катастрофой ещё на этапе внедрения.

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

В связи с отказом от выполнения работ предыдущего поставщика сильно сократился срок внедрения. Первоначально планировалось все реализовать за 12 месяцев, но т.к. пришлось организовывать конкурс, его отыгрывать, проводить пресейльные мероприятия, согласовать и организовать подписание договора по 44-ФЗ с казначейским сопровождением, в чистом остатке на внедрение у нас оставалось менее 6 месяцев.

В принципе, этот срок был уже на грани возможностей. Камнем преткновения стала установка 5600 плат СДЗ (средство доверенной загрузки, которое защищает рабочую станцию на этапе загрузки BIOS). Каждая плата должна быть установлена в компьютер путем нехитрых манипуляций: прийти на место, выгнать пользователя, снять крышку корпуса, вставить плату, загрузиться, протестировать плату, провести настройку, завинтить крышку, отдать компьютер пользователю.

В идеале, это занимает 15 минут. При планировании же мы ориентировались на час работы. Итого 5600 трудо-часов. Применив нехитрые статистические методы, стало ясно, что на эту работу потребуется минимум 10 человек. Собственно, на этом работу можно было бы и закончить. Ни один интегратор в здравом уме не отправил бы 10 инженеров в командировку из Москвы на 3 месяца крутить компьютеры. Во-первых, это очень дорого и накладно, а, во-вторых, это верный способ этих инженеров потерять.

Выручило нас то, что у ЛАНИТ в данном регионе есть ресурсный центр (у нас их несколько по России), который плотно взаимодействует с региональными вузами. В этот момент у них начался очередной раунд стажировки студентов. Договорившись с коллегами, обеспечив транспорт, питание и контроль над молодыми специалистами, мы получили 15 стажеров на внедрение плат.

15 июля 2019 года ГИП, руководитель проекта, три аналитика и три инженера из Москвы, 15 студентов-стажеров, руководитель ресурсного центра, его заместитель, бригадир стажеров и два представителя вендоров зашли на завод, чтобы начать работу.

Каждая более или менее крупная организация обрастает большим количеством сопутствующих бизнес-процессов и в конце концов бюрократией в хорошем смысле слова. Организация работы 20 человек уже требует определенного упорядочивания, что сложно сделать народными методами, то есть устно. Появляются положения, регламенты, инструкции (я уже писал, о том, как они появляются), что в конечном счете приводит к наличию множества параллельных структур, которые напрямую в проекте не участвуют, но мнение которых надо учитывать (бюрократия в плохом смысле слова).

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

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

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

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

По всем ключевым вопросам общение делилось на три стадии.

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

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

Способов закрепления договоренностей немного (в порядке убывания).

Протокол рабочей группы с подписями участников (за полгода я подписал их десятки).
Официальное письмо заказчика. Часто, чтобы что-то двинулось, надо, чтобы заказчик послал соответствующий запрос или требование. Разумеется, это письмо будете писать вы.
Официальное письмо исполнителя. Если нет ничего лучше, пишите официальные письма. Проблема данного способа в том, что письмо совершенно спокойно может потеряться в канцелярии или у секретарей. У нас однажды 15 коробок с платами потерялось на проходной, что уж говорить о листе бумаги.
Проектная документация. Иногда при понимании всех причастных можно требуемое прописать в утверждаемых документах. Мол, оно всегда там было.
Письмо электронной почтой. В крайнем случае фиксируйте все в электронной переписке. В случае чего вы сможете сослаться на то, что информировали заказчика. Хотя шансов немного.

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

Надеюсь, и вы довольны, что прочитали мой пост. Буду рад ответить на вопросы.

Наши вакансии