Были ли у вас случаи, когда из-за требований к ИБ приходилось заново проектировать систему/ вносить значительные изменения в проект? Часто подразделения, отвечающие за ИБ, привлекаются к проекту на поздних этапах, из-за чего объем работы может вырасти в разы. Мы работаем с крупным бизнесом и государственными организациями, где традиционно сильны процедуры и регламенты, поэтому сполна можем поделиться своим опытом и советами на тему, как предотвратить такие ситуации. В этой статье речь пойдет о проблемах при внедрении СЭД, но, думаю, это актуально и для других проектов для крупных заказчиков.

Как это происходит на практике

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

В другом случае при реализации проекта внедрения в крупной компании на стадии пресейла РП заказчика уведомил об отсутствии регламентов и особых требований по ИБ, кроме общих, указанных в ТЗ. Эти требования уже реализованы в нашей платформе (Docsvision) и не должны были повлиять на ход проекта. Но на стадии согласования одного из проектных документов, содержащего описание системного ландшафта, в перечень согласующих были добавлены представители службы ИБ. В результате появились требования предоставить дополнительные документы: «Модель угроз», «Акт классификации» и «Перечень защищаемых ресурсов». Из-за нашего опыта ведения подобных проектов эти требования не застали нас врасплох, так как мы учли такие риски и заранее подготовили проекты документов.

Что касается СЭД

Часто документы, обработанные в СЭД, требуют отдельного внимания к сохранности от влияний негативного характера. Обеспечение информационной безопасности представляет собой комплекс организационных и технических мероприятий, которые должны выполняться в соответствии с разработанной политикой ИБ в компании и законодательством РФ в области ИБ.

На нашем опыте подготовки к внедрению автоматизированных систем как для крупных заказчиков (ТОП-100 РБК), так и средних, чаще присутствуют требования к функциональности, удобству и простоте применения. Про ИБ заказчики зачастую думают в последнюю очередь, поэтому иногда сталкиваемся с такими ситуациями:

1. Посреди проекта появляются новые требования по ИБ от соответствующего департамента и меняется скоуп проекта;

2. На этапе сдачи проекта к приемке подключается специалист ИБ и не принимает проект в промышленную эксплуатацию;

3. Эксплуатируемая система уязвима к угрозам ИБ.

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

Почему нужно принимать во внимание требования по обеспечению ИБ?

Основные причины:

1. Выполнение требований законодательства РФ. За их нарушение предусмотрена административная и, в отдельных случаях, уголовная ответственность как ответственных работников за данной АС, так и руководителя компании.

2. Обеспечение сохранности защищаемой информации. В зависимости от ее вида (ПДн/Государственный информационный ресурс (ГИР), КТ, ДСП и др.), организация несет определенные риски при нанесении ущерба, который может быть выражен в виде утраты, нарушения целостности, компрометации информации.

Безусловно эти причины взаимосвязаны, но на деле в одних организациях вопрос ИБ стоит формально (избежать проблем перед регулятором), в других – практически (обезопасить информацию).

Базовые принципы

Для защиты информации в автоматизированных системах должны быть учтены основные принципы из учебных и методических пособий:

1. Законность и обоснованность защиты. Защищаемой информации по правовому статусу требуется защита.

2. Системность. Предполагает необходимость учета всех взаимосвязанных, взаимодействующих и изменяющихся во времени элементов, условий и факторов.

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

4. Непрерывность защиты. Защита информации — это непрерывный процесс, предполагающий принятие мер на всех этапах жизненного цикла информационной системы, начиная с самых ранних стадий проектирования.

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

6. Гибкость. Внешние условия и требования с течением времени меняются. Принятые меры и установленные средства защиты могут обеспечивать как чрезмерный, так и недостаточный уровень защиты. Для обеспечения возможности варьирования уровня защищенности средства защиты должны обладать гибкостью.

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

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

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

На что обратить внимание?

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

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

В-третьих, всегда проводить встречи с представителями служб ИТ/ ИБ заказчика с протоколированием обсужденных вопросов и принятых решений. Это поможет избежать казусов в виде неожиданных требований и «правок» в проектной документации. Желательно включить их в состав рабочей группы проекта (банально, но, к сожалению, так не всегда получается).

Если же вам «повезло» и проект предусматривает реализацию требований ИБ (или проектирования подсистемы ИБ) и у вашей организации есть соответствующие лицензии на осуществление этой деятельности в области ЗИ (политика в области лицензирования отдельных видов деятельности определяется Постановлением Правительства Российской Федерации от 24 декабря 1994 г. № 1418 «О лицензировании отдельных видов деятельности»), то при построении (модернизации) подсистемы ИБ целесообразно реализовывать следующий цикл работ, включающий обязательный этап диагностического обследования с оценкой уязвимостей автоматизированной системы и угроз:

1.      Обследование:

• Аудит системы (комплексное обследование подсистемы ИБ);

• Описание существующих ИТ-ресурсов/ сервисов/ бизнес-процессов;

• Анализ угроз и уязвимостей;

• Анализ рисков.

2.      Проектирование:

• Разработка проектных решений по защите информации;

• Разработка рабочей и эксплуатационной документации на подсистему ИБ.

3.      Внедрение СрЗИ.

4.      Аттестация АС (при необходимости).

Есть ли оптимальное решение задачи защиты информации в СЭД?

При проектировании защищенной СЭД должны быть выполнены следующие условия:

1. Создание и администрирование комплексной системы защиты информации в СЭД должно обеспечиваться в соответствии с требованиями законодательства Российской Федерации, а также с принципами построения систем комплексной ЗИ, стандартами информационной безопасности, определяемыми документами ФСТЭК России, разработанной политикой информационной безопасности организации.

2. В соответствии с требованиями ФСТЭК России проектирование систем ЗИ осуществляется только лицензиатом по защите информации.

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

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

• На предпроектном этапе с заказчиком четко определите и зафиксируйте ответственность за выполнение требований ИБ;

• Привлекайте представителей служб ИБ на этапе проектирования;

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

Нормативная база по теме

1. Федеральный закон от 27 июля 2006 года №152-ФЗ "О персональных данных" (с изменениями на 30 декабря 2020 года);

2. Федеральный закон от 27 июля 2006 г. №149-ФЗ «Об информации, информационных технологиях и о защите информации» (с изменениями на 30 декабря 2020 года), принят Государственной Думой 8 июля 2006 года;

3. Указ Президента РФ от 06 марта 1997 №188 (ред. от 13.07.2015) «Об утверждении Перечня сведений конфиденциального характера» (с изменениями на 13 июля 2015 года);

4. Постановление Правительства РФ от 06.07.2015 N 676 "О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации";

5. Постановление Правительства РФ от 01.11.2012 N 1119 "Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных";

6. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. Классификация автоматизированных систем и требования по защите информации. Решение председателя Гостехкомиссии России от 30 марта 1992 года;

7. Руководящий документ. Концепция защиты средств вычислительной техники и автоматизированных систем от несанкционированного доступа к информации Утверждена решением Гостехкомиссии при Президенте Российской Федерации от 30 марта 1992 года.

8.  Положение по аттестации объектов информатизации по требованиям безопасности информации. Утверждено председателем ГТК при Президенте РФ 25 ноября 1994 года (обновлено 17 июля 2017 года);

9. Приказ ФСТЭК России от 11.02.2013 N 17 "Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах";

10. Приказ ФСТЭК России от 18.02.2013 N 21 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных";

11. ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы;

12. ГОСТ 34.201-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем;

13. ГОСТ Р 51583-2014 Защита информации. Порядок создания автоматизированных систем в защищенном исполнении.