Основным фактором бурного развития информационных систем является оперативное обновление программного обеспечения. В свою очередь, повышение оперативности потребовало коренных изменений в технологической цепочке производства программных продуктов: темпы разработки ускорились, уровень технической осведомленности пользователя за последние 20 лет существенно вырос, потребители стали более ответственно выбирать решения. При этом важным конкурентным преимуществом является наличие технической поддержки и возможности устранять ошибки и расширять функциональность программных систем в режиме непрерывного обновления. Возникли такие понятия, как CI (Continuous Integration – постоянная интеграция, оперативное расширение функциональности) и CD (Continuous Delivery – постоянная поставка, в значении "дистрибуция"), а также обобщенное понятие CI/CD. Концепция организации технологического процесса, в которой реализуется CI/CD, получила название DevOps (Development Operations).
В основе DevOps лежит методология гибкой разработки программных продуктов. Гибкость предполагает жесткое разделение полномочий между участниками процесса при высокой степени автоматизации процессов сборки, тестирования и развертывания. Применение данного подхода позволяет создавать масштабные программные продукты, делегируя задачи производства и контроля качества сравнительно небольшим командам специалистов, наращивая по мере увеличения числа программных модулей количество команд и перераспределяя их полномочия.
Основной (и на данный момент неразрешенной) проблемой гибкой разработки является обеспечение безопасности производственного процесса. Локус внимания экспертов по безопасности DevOps направлен на то, чтобы не дать потенциальному злоумышленнику внести в работающую систему изменения, которые приведут к изменениям в логике обработки информации – повышению привилегий доступа с последующим изменением, удалением и/или разглашением хранящихся в системе сведений об объектах реального или виртуального мира. Однако сама среда предприятия, в рамках которой производится разработка программных продуктов, также может стать объектом исследования, а затем и атаки.
По мере того как данное явление стало массовым, назрела необходимость включить в список объектов защиты среду не только функционирования, но и разработки. Так зародилась концепция DevSecOps, которая основана на поддержке безопасности системы с момента создания среды для ее разработки.
В настоящий момент DevSecOps стала трендом, набирающим все большую популярность – проводятся семинары, конференции. Но полноценная реализация данной концепции невозможна при противоречиях с действующим законодательством.
Прежде чем перейти к анализу текущего правового поля, следует сделать одно важное замечание. Несмотря на внешнюю новизну тренда DevSecOps, схожие требования к процессу разработки, отладки и развертывания программных продуктов применялись и ранее, однако в основе мотивации к их практической реализации была ненадежность аппаратного и алгоритмического обеспечения. Например, контроль четности создавался как механизм обеспечения гарантированной передачи данных по каналам связи, а логические ошибки в программном коде могли быть результатом не злого умысла, но недоработкой конкретного языка программирования (пример – создание языка ADA, в основе дизайна которого лежит недопущение подобного рода ошибок).
Законодательство, помимо основной своей функции, заключающейся в регулировании общественных отношений, представляет собой репрезентативный показатель зрелости того или иного явления в обществе. В Российской Федерации законодательство в сфере защиты информации стало интенсивно развиваться с середины 2000-х гг., когда многим явлениям в данной сфере были даны определения, на основе которых стало возможным вести регуляторную деятельность.
На данный момент актуальными и наиболее ярко обсуждаемыми стали дополнения о безопасности критической информационной инфраструктуры Российской Федерации, фактически определяющие направление по обеспечению безопасности государства в сфере, связанной с созданием, хранением, передачей и преобразованием информации:
Стоит отметить, что деятельность регулятора в данном контексте не ограничивается – в Кодексе об административных правонарушениях (КоАП РФ) предусмотрен перечень общественно опасных деяний, связанных с разглашением либо сокрытием информации:
Виды нарушений, касающиеся самой информации и средств ее обработки, представлены в следующих статьях УК РФ: l ст. 272. "Неправомерный доступ к компьютерной информации"; l ст. 273. "Создание, использование и распространение вредоносных компьютерных программ"; l ст. 274. "Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей"; l ст. 274.1. "Неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации".
Современный подход к организации бизнес-процессов построен на широком использовании программных продуктов, в том числе на базе веб-технологий: официальные сайты, форумы, корпоративные порталы, интернет-магазины и аукционы, порталы услуг, электронные торговые площадки – все это стандартные элементы информационной инфраструктуры любой современной компании. Нарушение их штатного функционирования вследствие реализации одной или нескольких угроз информационной безопасности может привести к существенным финансовым и репутационным издержкам. По данным исследования компании Positive Technologies за 2019 г., злоумышленники активно используют уязвимости веб-сайтов: 92% веб-приложений позволяют проводить атаки на пользователей, а 82% найденных уязвимостей связаны с ошибками при разработке кода. Бреши безопасности в 16% исследованных сайтах давали возможность контролировать не только само веб-приложение, но и сервер, на котором оно запущено1.
Для того чтобы этого избежать, необходимо в процессе проектирования, создания и эксплуатации программного обеспечения применять методы безопасной разработки и анализа безопасности исходного кода.
Анализ безопасности исходного кода – это анализ программного обеспечения на предмет выявления уязвимостей информационной безопасности, допущенных при его разработке.
Существует три группы методов анализа исходного кода:
Статические методы анализа исходного кода могут быть использованы при создании и эксплуатации программного обеспечения, а динамические – на этапе ввода в эксплуатацию и в процессе эксплуатации.
Безопасность приложения – один из основных критериев качества разрабатываемого продукта. Проверка безопасности программы делается на разных этапах различными методиками и инструментами. Программный продукт в зависимости от специфики обсуждения можно описать по-разному:
Для каждого представления создаются свои регламенты и техники обеспечения безопасности. Если рассматривать программный продукт как совокупность уникального кода, заимствованного открытого кода и логики работы программы в соответствии с ее назначением, то его проверку на уязвимости можно представить тремя способами:
Имеет смысл проверять код программы уже на этапе написания. Это позволит на ранних стадиях выявить закравшиеся ошибки и уязвимости, в том числе и наследованные из открытого кода. Компоненты Open Source можно проверить на наличие известных уязвимостей еще до включения в программный проект или на стадии сборки. В части открытого кода сфокусироваться на первоочередных уязвимостях достаточно просто, так как продвинутые инструменты анализа композиции программ (SCA) идентифицируют фактические вызовы уязвимых методов, проще говоря, указывают на потенциально эксплуатируемые уязвимости. Этап проверки итогового кода программы обычно бывает трудоемким, инструменты статического анализа кода обнаруживают потенциально опасные фрагменты, и приходится разбираться, какие из обнаруженных проблем реальные, а какие для данного проекта не несут угроз. Сканирование кода и проверка информации об известных уязвимостях Open Source – разные по своей сути технологии, но обе критично важны для выявления и устранения уязвимостей на ранних стадиях цикла разработки (SDLC), до развертывания приложения.
После создания программы требуется убедиться, что ее фактическое поведение соответствует ожидаемому. Эту задачу решают инструменты динамического анализа, фаззинг-тестирование, пентесты и др. Множество атак на приложения реализуется путем передачи в программу таких данных, при обработке которых возникает неучтенная разработчиками ситуация, впоследствии используемая хакером в своих интересах. На этапе проверки поведения программы необходимо предусмотреть возможные нарушения такого рода. Проверка поведения программы необходима не только перед запуском системы в эксплуатацию, ее нужно регулярно проводить во время работы программы для выявления не обнаруженных ранее брешей.
Эта сложная и неоднозначная аналитическая задача решается путем диагностики архитектуры программного продукта и оценки выбранных схем логической реализации. Адекватное составление модели угроз на этапе проектирования продукта позволяет предугадать возможные сценарии атак и методы защиты. Это основополагающая проверка, требующая значительных экспертных усилий, она не может быть заменена проверкой кода или тестом поведения программы.
Безопасность приложения – один из основных критериев качества разрабатываемого продукта.
Как правило, в начале разработки модель угроз делают, но вот в ходе развития продукта, при добавлении новых фич и выпуске мажорных обновлений даже опытные команды время от времени забывают обновить модель угроз, проанализировать новую логику и ее реализацию.
Сканирование кода, анализ композиции и проверка поведения не заменяют друг друга. Эти технологии вместе на выходе позволяют создавать безопасные программные продукты, но для получения практической пользы должны быть правильно подобраны инструменты безопасной разработки. Остановимся на одном из типов оценки исходного кода.
Инструменты анализа композиции программы зародились на рубеже тысячелетий на основе методов сканирования кода, которые выявляли фрагменты кода и сопоставляли его с базами данных Open Source. Такие инструменты применялись различными компаниями, но они давали существенное количество ложных срабатываний, замедляли работу, а самое главное – не подходили для гибких сред разработки. Однако потребность в специализированных инструментах контроля Open Source росла и была обусловлена следующими факторами:
Три способа проверки на уязвимость:
Со временем системы проверки Open Source переродились в инструменты непрерывного управления компонентами Open Source, интегрируемыми с различными инструментами разработки – репозиториями, инструментами сборки, серверами непрерывной интеграции. Переход к обнаружению уязвимостей и проблем с лицензированием в режиме реального времени позволил управлять открытым исходным кодом и идентифицировать проблемы на более ранних этапах процесса, когда их легче и быстрее устранить.
Функционал подобных инструментов довольно широк. Инструменты анализа композиции приложения проводят инвентаризацию всех компонентов Open Source в приложении, включая прямые и транзитивные зависимости, и предоставляют информацию о каждом компоненте, в том числе данные о лицензии и наличии уязвимостей.
Инструменты с наиболее развитым функционалом, в частности WhiteSource, способны снизить число уведомлений об уязвимостях в компонентах Open Source на 70% благодаря запатентованным алгоритмам приоритизации по фактическим вызовам уязвимых методов.
Сканирование кода, анализ композиции и проверка поведения не заменяют друг друга. Эти технологии вместе на выходе позволяют создавать безопасные программные продукты.
WhiteSource агрегирует информацию об уязвимостях из разных источников в собственную базу данных и предлагает разработчикам на выбор варианты исправления, от ссылок на обновления до рекомендаций по изменению системных настроек и блокировки различных функций.
Крылатое выражение "время – деньги" как нельзя лучше характеризует ситуацию с разработкой ПО. От разработчиков требуют нереальных, на первый взгляд, вещей: сделать продукт быстро и при этом чтобы он получился безопасным. В таких условиях не обойтись без автоматизации. WhiteSource может автоматизировать весь процесс отбора, утверждения и отслеживания компонентов Open Source, автоматически применять политики для блокировки уязвимого или проблемного компонента.
Использование Open Source поднимает еще один вопрос, требующий внимания команды разработки, – о лицензионной чистоте. Каждый компонент Open Source, а также любой компонент, от которого он может зависеть, имеет лицензию, условия которой нужно соблюдать. Существует свыше 200 различных лицензий Open Source, у каждой из которых свои условия. Выбор компонента с неподходящей лицензией может привести к самым разным последствиям, от необходимости изменения компонента до судебного иска о нарушении авторских прав. SCA-решение также призвано автоматизировать процесс соблюдения лицензионной чистоты, чтобы освободить разработчиков от несвойственных им задач.
Современный рынок программных продуктов офисного назначения представляет собой динамичную среду с растущей конкуренцией. Продолжительная эволюция офисных приложений породила определенный подход к оценке возможностей программного обеспечения данного класса. В современных российских реалиях существенным конкурентным преимуществом является наличие сертификатов, позволяющих применять продукт в государственных организациях. Получение такого сертификата возможно только при соблюдении ряда требований относительно:
Если с первыми двумя пунктами определенная ясность присутствует, то проблема оценки безопасности информационной системы (равно как и входящих в нее отдельных программных продуктов) является предметом споров и обсуждений.
Важнейшим источником сведений о возможных угрозах, связанных с эксплуатацией облачных систем, является банк данных угроз (БДУ), размещенный на сайте ФСТЭК в открытом доступе.
С точки зрения оценки рисков главной особенностью социальной сферы является существенно большая тяжесть убытков от компрометации системы у третьих лиц, чем непосредственных эксплуатантов. Например, определенные государственные услуги на портале 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). Эта ситуация опасна тем, что в случае компрометации ключей разработчика под угрозу попадают не только собственные продукты, но и абсолютно любой программный продукт, подписанный скомпрометированным ключом.
Автоматизация дает ускорение разработки продукта, но сама по себе она не гарантирует его безопасность. При этом безопасность кода сегодня – один из основных критериев качества разрабатываемого продукта. Чтобы выпускать релизы часто и не жертвовать безопасностью, необходимо встроить в конвейер разработки ПО инструменты проверки качества кода, такие как SAST, DAST, SCA.
Инструменты SCA2 интегрируются с репозиториями, инструментами сборки, серверами непрерывной интеграции и позволяют обнаруживать проблемы с безопасностью в компонентах Open Source на самых ранних этапах разработки, реализуя таким образом принцип Shift Left, когда исправления можно делать быстрее и проще. И здесь опять же требуется платформа оркестрации, которая позволит видеть состояние каждого программного компонента и проекта в целом, находить наиболее влияющие на скорость разработки задачи, запускать проверки безопасности насколько возможно раньше, чтобы не тормозить выпуски и иметь полную прозрачность конвейера разработки.
Критично важно предоставлять разработчикам свободу и одновременно контролировать их. И это возможно. Оставьте разработчикам свободу выбора инструментов и сред. При этом XebiaLabs может предоставить платформу, которая даст руководству компании уверенность, что они получают то, что нужно. Баланс между свободой и контролем достигнут.
Крупные компании годами инвестировали значительные средства в инструменты, подобные Jenkins и Jira, и они стали основой для их работы. Эти компании не хотят их менять, да им и не нужно этого делать. XebiaLabs интегрирует существующие инструменты и предлагает корпоративные функции, которые способствуют масштабируемости, соответствию требованиям и скорости разработки.
Разработка ПО очень важна для успеха, она является частью любой организации, потому что сегодня большинство крупных компаний стали разработчиками программного обеспечения. Без разработки нет бизнеса, поэтому она должна быть продуктивной, а для этого нужно предоставить разработчикам возможность использовать любимые инструменты. Однако очень часто конвейер разработки довольно сегментирован и не всегда дает прозрачность ситуации. Использование платформы оркестрации релизов, например XebiaLabs DevOps Platform, добавляет необходимую ясность и управляемость, не мешая командам разработчиков, какие бы инструменты и среды они ни использовали – Microsoft Azure, AWS, Kubernetes или другие решения. И бизнес, и разработчики получают то, что хотят. Вам не нужно вносить серьезные изменения, чтобы быстро повысить эффективность процесса доставки программного обеспечения.
Скорость релизов имеет все большее значение. Во многих компаниях уже существуют "островки скорости", часто порожденные тремя типами команд:
Организация выиграет, когда найдет все три такие команды и объединит их практики. Инноваторы, автоматизаторы и оптимизаторы, работающие вместе, являются золотым фондом компании.
Упрощенные, автоматизированные процессы позволят вам освоить инновации и ускориться в целом, а "островки скорости" превратить в "магистрали".
