В рубрику "Оборудование и технологии" | К списку рубрик | К списку авторов | К списку публикаций
Современный рынок программных продуктов офисного назначения представляет собой динамичную среду с растущей конкуренцией. Продолжительная эволюция офисных приложений породила определенный подход к оценке возможностей программного обеспечения данного класса. В современных российских реалиях существенным конкурентным преимуществом является наличие сертификатов, позволяющих применять продукт в государственных организациях. Получение такого сертификата возможно только при соблюдении ряда требований относительно:
Если с первыми двумя пунктами определенная ясность присутствует, то проблема оценки безопасности информационной системы (равно как и входящих в нее отдельных программных продуктов) является предметом споров и обсуждений.
С точки зрения оценки рисков главной особенностью социальной сферы является существенно большая тяжесть убытков от компрометации системы у третьих лиц, чем непосредственных эксплуатантов. Например, определенные государственные услуги на портале 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).
Широкое распространение мобильных устройств и возможность широкополосного подключения к сети Интернет позволяет работать без привязки к рабочему месту, однако в данном случае требования к безопасности облачной инфраструктуры в связи с ростом числа угроз серьезно ужесточаются. Так, имеет место угроза злоупотребления возможностями, предоставленными потребителям (020). В случае если пользователь подключается к облаку с помощью личного ноутбука или мобильного телефона (такая форма организации труда имеет собственное название – BYOD, Bring Your Own Device), администратор безопасности не может взять устройство под контроль. В результате становятся актуальными угрозы, связанные с установкой программного обеспечения (186), способного к негласному получению пользовательских данных различными способами (062, 008, 041, 042, 201, 159).
Стоит также отметить угрозу некорректной реализации политики лицензирования в облаке (064), угрозу непрерывной модернизации облачной инфраструктуры (070), угрозу потери управления собственной инфраструктурой при переносе ее в облако, а также угрозу привязки к поставщику облачных услуг (141). К указанным проблемам эксплуатационного характера следует отнести также возможный конфликт юрисдикций различных стран (040) при внедрении территориально распределенного облака.
Изначально разработка велась несколькими независимыми коллективами, результатом труда которых являются программные модули. Далее эти модули компонуются в конкретные программные продукты, имеющие товарные названия. Очевидно, что различные продукты обладают различной функциональностью, поэтому для минимизации избыточности в релизах компоненты должны быть минимальными. С другой стороны, процесс компоновки из десятков и сотен модулей сопряжен с большими проблемами, поэтому был выделен ряд базовых составляющих, разрабатываемых и проверяемых по отдельности, которые затем собираются в релиз. Для каждого такого модуля целостно и логически связно ведется история изменений во времени (задачи в Jira, коммиты кода, билды).
В настоящий момент разработка защищенной версии продукта находится в стороне от базовой. Базовый продукт имеет определенный релизный цикл (несколько релизов в год). При этом процесс сертификации проводится не для каждого релиза. Из-за временных затрат на разработку защищенной версии она по функциональности отстает от актуальной. С целью гомогенизации процесса разработки, направленной на соответствие требованиям разработки от ФСТЭК, требуется значительная реорганизация механизма взаимодействия подразделений. Другими словами, необходима интеграция процессов безопасности в производство основной версии продукта, а также изменение порядка взаимодействия между отделами разработки.
Интеграция процессов обеспечения безопасной разработки предполагает формализацию требований по сертификации для отделов DevOps. Так, в идеале требуется, чтобы релизы отдельных программных компонентов собирались и тестировались на защищенных дистрибутивах в эталонной среде.
В процессе интеграции и централизации ресурсов возникает необходимость в создании единого репозитория собственных и сторонних программных продуктов. Контроль сторонних продуктов (3-rd party) производится на наличие выявленных уязвимостей и проверку лицензионной чистоты. Серьезную проблему в сфере защиты интеллектуальной собственности представляют так называемые copyleft-лицензии, требующие раскрытия исходных кодов на производные программные модули. Для борьбы с подобным явлением планируется ввести единый репозиторий доверенных сторонних пакетов. Чтобы пакет стал доверенным, необходима проверка его лицензии, корректности указанной в метаданных версии, а также выявление наиболее существенных уязвимостей.
Существующая система технической поддержки взаимодействует непосредственно с разработчиками и группой, занимающейся обучением сотрудников и клиентов. В данный механизм добавляется новое направление – взаимодействие с отделом безопасности информации в части применения СЗИ и работы в защищенной среде.
Внесение изменений в устоявшийся технологический процесс в большинстве случаев сопряжено со значительными затратами – финансы, время, труд. Перед проведением реорганизации всегда следует учитывать ее целесообразность, оценивая как затраты, так и возможные позитивные и негативные последствия. В случае если потребность в изменениях диктуется внешними факторами, такими как изменение законодательства, освоение новых сфер деятельности, равно как и новых рынков сбыта продукции, необходимо выстраивать процесс таким образом, чтобы внедрение новых процессов не останавливало деятельность предприятия.
Выход закона о КИИ является серьезным шагом в области государственного регулирования деятельности в сфере обеспечения общественной безопасности.
Так, проект приказа ФСТЭК России "О внесении изменений в Требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации, утвержденные приказом Федеральной службы по техническому и экспортному контролю от 25 декабря 2017 г. № 239" предусматривает:
1. Запрет на осуществление технической поддержки программных (программно-аппаратных) средств зарубежными организациями или организациями, находящимися под контролем иностранных физических и (или) юридических лиц, что означает неизбежный переход к использованию отечественного программного обеспечения в значимых объектах КИИ, прежде всего в информационных системах (лояльные к изменениям), а в последующем и автоматизированных системах управления (консервативные к изменениям).
2. Новые требования к безопасной разработке, выявлению уязвимостей и недкларированных возможностей в прикладном программном обеспечении, включающие анализ результатов моделирования угроз безопасности информации, анализ исходного кода статистическими и динамическими (для объектов КИИ первой и второй категории значимости) методами, вряд ли могут быть реализованы в отношении прикладного программного обеспечения зарубежных разработчиков.
Опубликовано: Журнал "Information Security/ Информационная безопасность" #1, 2020