Проблематика разработки программного обеспечения, функционирующего в рамках КИИ
Александр Буравцов, 18/03/20
Александр Буравцов
Современный рынок программных продуктов офисного назначения представляет собой динамичную среду с растущей конкуренцией. Продолжительная эволюция офисных приложений породила определенный подход к оценке возможностей программного обеспечения данного класса. В современных российских реалиях существенным конкурентным преимуществом является наличие сертификатов, позволяющих применять продукт в государственных организациях. Получение такого сертификата возможно только при соблюдении ряда требований относительно:
- происхождения продукта (согласно постановлению Правительства РФ от 16 ноября 2015 г. № 1236 он должен быть российского производства)¹;
- его функциональности (постановление Правительства РФ от 23 марта 2017 г. № 325 регламентирует состав и перечень базовых функций офисного ПО)²;
- безопасности.
Если с первыми двумя пунктами определенная ясность присутствует, то проблема оценки безопасности информационной системы (равно как и входящих в нее отдельных программных продуктов) является предметом споров и обсуждений.
Важнейшим источником сведений о возможных угрозах, связанных с эксплуатацией облачных систем, является банк данных угроз (БДУ), размещенный на сайте ФСТЭК в открытом доступе.
С точки зрения оценки рисков главной особенностью социальной сферы является существенно большая тяжесть убытков от компрометации системы у третьих лиц, чем непосредственных эксплуатантов. Например, определенные государственные услуги на портале www.gosuslugi.ru облагаются пошлиной. Объем этой пошлины зависит от вида и формы предоставления услуги, но очевидно, что на ее исполнение тратится значительно больший ресурс. В случае неработоспособности сайта в течение одной недели отсутствие дохода от уплаты пошлин окажется существенно меньшим злом, чем несвоевременная выдача загранпаспорта, просрочка платежей с последующим начислением пени и т.п. Но и эти убытки понесет несостоявшийся потребитель услуги. Показательным примером является инцидент с обнаружением программы Stuxnet, результатом которого стала атака на энергосистему США. Энергетики понесли существенно меньшие потери, чем потребители их услуг. Поэтому принятие Федерального закона от 26.07.2017 № 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации"³ является существенным событием в сфере ИБ.
Закон вводит новое понятие о КИИ как о среде, в рамках которой функционирует информационная система. Впервые допускается, что компрометация информационной системы может привести к утрате и повреждению объектов материального мира, а возможный ущерб от этих действий носит не только прямой, но и косвенный характер, проявляясь как в первом звене, так и в последующих звеньях цепочки потребителей услуг. Вполне естественно, что закон о КИИ далек от совершенства, а значит нормативно-правовая база будет постоянно развиваться, что неизбежно породит проблемы, характерные для переходного периода.
Фактически сейчас перед разработчиками отечественного программного обеспечения стоит задача переориентации процессов производства и сертификации продуктов в условиях с размытыми требованиями, не имеющими четкой и однозначной интерпретации. В связи с этим предлагается подход к решению указанной проблемы, разработанный в ООО "Новые Облачные Технологии" для ряда продуктов сервиса "Мой Офис".
Помимо уже опубликованных законов и подзаконных актов, на федеральном портале размещается информация о готовящихся законопроектах. Можно в реальном времени наблюдать различные этапы их прохождения вместе с изменениями4. Стоит обратить внимание и на различные тематические сайты, где эксперты публикуют свои комментарии и мнения5-8.
Как определить основные риски?
Определим основные направления угроз. В качестве первичного критерия возьмем этап жизненного цикла, а в качестве вторичного - субъект, являющийся источником угрозы. В интересующем нас контексте под "производством" следует понимать не только само создание программного кода, но и весь процесс, от формирования первичных требований к функциональности продукта до его непосредственной установки на "боевой" сервер. Специфика современной разработки такова, что этот процесс итеративен, т.е. внедрение новых функций в приложение, равно как и обновление на стороне потребителя, производится постоянно на всем процессе жизненного цикла продукта. В зарубежной практике данный подход называется CI/CD (Continuous Integration/Continuous Delivery).
Важнейшим источником сведений о возможных угрозах, связанных с эксплуатацией облачных систем, является банк данных угроз (БДУ), размещенный на сайте ФСТЭК9 в открытом доступе. Стоит отметить, что публикуемые материалы являются переводом CVE, при этом ссылки на оригинальные описания присутствуют. На основе данного перечня можно выделить несколько классов проблем, характерных для облачных решений. В скобках будут даны ссылки на конкретные уязвимости.
С чего начать производство?
Цикл производства предполагает привлечение большого числа различных специалистов, поэтому первостепенную значимость принимает четкая постановка задач и контроль их выполнения. Так, требуется определить круг лиц, допущенных к программному коду с целью локализации угрозы внедрения в продукт сторонних компонентов, содержащих уязвимости (165, 188, 191). Далее, необходимо обеспечить целостность среды сборки и тестирования с целью минимизации возможности несанкционированного внесения в ее конфигурацию изменений (012, 023). Стоит упомянуть отдельно угрозу внедрения системной избыточности (166) в сборке программного продукта, а также угрозу нарушения технологии обработки информации путем несанкционированного внесения изменений в образы виртуальных машин (048), затрагивающую продукты, формой дистрибуции которых являются docker-контейнеры.
Особую проблему в данном контексте представляет утечка цифровых подписей (162). Эта ситуация опасна тем, что в случае компрометации ключей разработчика под угрозу попадают не только собственные продукты, но и абсолютно любой программный продукт, подписанный скомпрометированным ключом.
Проблематика обеспечения безопасности облачных сервисов
С точки зрения информационной безопасности облачный сервис представляет собой сущность с размытым периметром. В случае если не приняты организационные и технические меры по ограничению периметра, в защищаемой системе остаются открытыми уязвимости, связанные с получением несанкционированного доступа к объектам облачной инфраструктуры (065, 103, 135), затрудняется поиск точки отказа в случае недоступности услуг пользователям (043, 140, 162, 164). Противоположную проблему представляет общедоступность ресурсов (101), вызванная незащищенным администрированием (055), неопределенностью ответственности (066) и несогласованностью политик безопасности (096). Так, система с широким открытым периметром может быть изучена и атакована (046, 104, 098, 099, 100, 102, 187, 031, 176, 177, 015, 016, 028, 030). Так или иначе, недостаточное внимание к защищаемой инфраструктуре может быть расценено пользователями как злоупотребление доверием (021) и недобросовестное исполнение обязательств (054), а в конечном итоге привести к его потере (134).
Интеграция процессов обеспечения безопасной разработки предполагает формализацию требований по сертификации для отделов DevOps. Так, в идеале требуется, чтобы релизы отдельных программных компонентов собирались и тестировались на защищенных дистрибутивах в эталонной среде.
Широкое распространение мобильных устройств и возможность широкополосного подключения к сети Интернет позволяет работать без привязки к рабочему месту, однако в данном случае требования к безопасности облачной инфраструктуры в связи с ростом числа угроз серьезно ужесточаются. Так, имеет место угроза злоупотребления возможностями, предоставленными потребителям (020). В случае если пользователь подключается к облаку с помощью личного ноутбука или мобильного телефона (такая форма организации труда имеет собственное название – BYOD, Bring Your Own Device), администратор безопасности не может взять устройство под контроль. В результате становятся актуальными угрозы, связанные с установкой программного обеспечения (186), способного к негласному получению пользовательских данных различными способами (062, 008, 041, 042, 201, 159).
Стоит также отметить угрозу некорректной реализации политики лицензирования в облаке (064), угрозу непрерывной модернизации облачной инфраструктуры (070), угрозу потери управления собственной инфраструктурой при переносе ее в облако, а также угрозу привязки к поставщику облачных услуг (141). К указанным проблемам эксплуатационного характера следует отнести также возможный конфликт юрисдикций различных стран (040) при внедрении территориально распределенного облака.
Опыт "Новых Облачных Технологий"
Изначально разработка велась несколькими независимыми коллективами, результатом труда которых являются программные модули. Далее эти модули компонуются в конкретные программные продукты, имеющие товарные названия. Очевидно, что различные продукты обладают различной функциональностью, поэтому для минимизации избыточности в релизах компоненты должны быть минимальными. С другой стороны, процесс компоновки из десятков и сотен модулей сопряжен с большими проблемами, поэтому был выделен ряд базовых составляющих, разрабатываемых и проверяемых по отдельности, которые затем собираются в релиз. Для каждого такого модуля целостно и логически связно ведется история изменений во времени (задачи в Jira, коммиты кода, билды).
Серьезную проблему в сфере защиты интеллектуальной собственности представляют так называемые copyleft-лицензии, требующие раскрытие исходных кодов на производные программные модули. Для борьбы с подобным явлением планируется ввести единый репозиторий доверенных сторонних пакетов.
В настоящий момент разработка защищенной версии продукта находится в стороне от базовой. Базовый продукт имеет определенный релизный цикл (несколько релизов в год). При этом процесс сертификации проводится не для каждого релиза. Из-за временных затрат на разработку защищенной версии она по функциональности отстает от актуальной. С целью гомогенизации процесса разработки, направленной на соответствие требованиям разработки от ФСТЭК, требуется значительная реорганизация механизма взаимодействия подразделений. Другими словами, необходима интеграция процессов безопасности в производство основной версии продукта, а также изменение порядка взаимодействия между отделами разработки.
Интеграция процессов обеспечения безопасной разработки предполагает формализацию требований по сертификации для отделов DevOps. Так, в идеале требуется, чтобы релизы отдельных программных компонентов собирались и тестировались на защищенных дистрибутивах в эталонной среде.
В процессе интеграции и централизации ресурсов возникает необходимость в создании единого репозитория собственных и сторонних программных продуктов. Контроль сторонних продуктов (3-rd party) производится на наличие выявленных уязвимостей и проверку лицензионной чистоты. Серьезную проблему в сфере защиты интеллектуальной собственности представляют так называемые copyleft-лицензии, требующие раскрытия исходных кодов на производные программные модули. Для борьбы с подобным явлением планируется ввести единый репозиторий доверенных сторонних пакетов. Чтобы пакет стал доверенным, необходима проверка его лицензии, корректности указанной в метаданных версии, а также выявление наиболее существенных уязвимостей.
Существующая система технической поддержки взаимодействует непосредственно с разработчиками и группой, занимающейся обучением сотрудников и клиентов. В данный механизм добавляется новое направление – взаимодействие с отделом безопасности информации в части применения СЗИ и работы в защищенной среде.
Внесение изменений в устоявшийся технологический процесс в большинстве случаев сопряжено со значительными затратами – финансы, время, труд. Перед проведением реорганизации всегда следует учитывать ее целесообразность, оценивая как затраты, так и возможные позитивные и негативные последствия. В случае если потребность в изменениях диктуется внешними факторами, такими как изменение законодательства, освоение новых сфер деятельности, равно как и новых рынков сбыта продукции, необходимо выстраивать процесс таким образом, чтобы внедрение новых процессов не останавливало деятельность предприятия.
Выход закона о КИИ является серьезным шагом в области государственного регулирования деятельности в сфере обеспечения общественной безопасности.
1 Постановление Правительства Российской Федерации от 16 ноября 2015 г. № 1236 “Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд”.
2 Постановление Правительства Российской Федерации от 23 марта 2017 г. № 325 “Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных”.
3 Федеральный закон от 26.07.2017 № 187-ФЗ “О безопасности критической информационной инфраструктуры Российской Федерации”.
4 Нормативные правовые акты [Электронный ресурс] // Федеральный портал проектов нормативных правовых актов. 2019. Дата обновления: 10.02.2020. URL: https://regulation.gov.ru/projects?type=Grid (дата обращения 10.02.2020).
5 Нормативные документы в области ГосСОПКА и безопасности КИИ [Электронный ресурс] // Positive Technologies. 2019. Дата публикации: 23.07.2019. URL: https://www.ptsecurity.com/ru-ru/research/knowledge-base/terminology-gossopka-kii-full- version/ (дата обращения 10.02.2020).
6 187-ФЗ. Практическое пособие по проведению работ связанных с выполнением требований 187-ФЗ “О безопасности объектов КИИ в РФ” [Электронный ресурс] // ООО “ИЦ РЕГИОНАЛЬНЫЕ СИСТЕМЫ”. 2019. Дата публикации: 29.04.2019. URL: https://www.ec-rs.ru/blog/all/187-fz-bezopasnost-obektov-kriticheskoy-informatsionnoy-infrastruktury-organizatsii/ (дата обращения 10.02.2020).
7 FAQ КИИ. Совсем коротко, но очень полезно о КИИ [Электронный ресурс] // ООО “ИЦ РЕГИОНАЛЬНЫЕ СИСТЕМЫ”. 2019. Дата публикации: 06.02.2019. URL: https://www.ec-rs.ru/blog/all/faq-kii-sovsem-korotko-no-ochen-polezno-o-kii/ (дата обращения 10.02.2020).
8 Обзор российского законодательства по защите критической информационной инфраструктуры [Электронный ресурс] // habr.com. 2019. Дата публикации: 27.11.2019. URL: https://habr.com/ru/post/477812/ (дата обращения 10.02.2020).
9 Банк данных угроз безопасности информации [Электронный ресурс] // ФАУ “ГНИИИ ПТЗИ ФСТЭК России”. 2020. Дата обновления: 06.02.2020. URL: https://bdu.fstec.ru/threat (дата обращения 10.02.2020).
Комментарий эксперта
Константин Саматов
Ассоциация руководителей служб информационной безопасности (АРСИБ)
- Запрет на осуществление технической поддержки программных (программно-аппаратных) средств зарубежными организациями или организациями, находящимися под контролем иностранных физических и (или) юридических лиц, что означает неизбежный переход к использованию отечественного программного обеспечения в значимых объектах КИИ, прежде всего в информационных системах (лояльные к изменениям), а в последующем и автоматизированных системах управления (консервативные к изменениям).
- Новые требования к безопасной разработке, выявлению уязвимостей и недекларированных возможностей в прикладном программном обеспечении, включающие анализ результатов моделирования угроз безопасности информации, анализ исходного кода статистическими и динамическими (для объектов КИИ первой и второй категории значимости) методами, вряд ли могут быть реализованы в отношении прикладного программного обеспечения зарубежных разработчиков.
Опубликовано: Журнал "Information Security/ Информационная безопасность" #1, 2020