Последний рубеж обороны

В последнее время много говорят о защите ГИС (государственных информационных систем) — ФСТЭК выпускает требования, проводятся конференции, круглые столы, экспертные советы и даже заседания профильных комитетов Думы и Совета Федерации.

Почему понадобились отдельные требования именно по государственным системам? По мнению автора, на это есть две причины: внешняя и внутренняя.

Внешняя причина

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

Количество атак на государственные ресурсы увеличивается с каждым годом, и оставлять без внимания такие угрозы нельзя. Проблема настолько «горячая», что официальные лица даже предлагали приравнять атаку на государственные информационные системы к государственной измене, со всеми вытекающими из этого последствиями для атакующего. Это не параноидальный случай: если посмотреть на опыт стран НАТО, то так называемый Таллинский протокол содержит положение, приравнивающее кибератаку на ресурсы стран блока к настоящей, «горячей» агрессии, то есть по декларированным сценариям возможна ситуация, когда в ответ на кибератаку будет нанесен ракетный удар. Другой вопрос, куда его наносить? Ведь определить, кто конкретно является киберагрессором не так просто, как засечь старт ракеты с пусковой установки.

Вторая причина — внутренняя

К сожалению, основную, функциональную часть государственных систем — собственно приложения, автоматизирующие работу государственных органов и оказывающие государственные услуги населению — нельзя купить готовыми, поэтому они разрабатываются самостоятельно. Ну нет ни у одного производителя программного обеспечения в прайс-листе лицензии «Автоматизация единого государственного экзамена России 3.2». Мало того что большинство автоматизируемых государственных процессов уникально, они еще и постоянно меняются, причем без предупреждения. Такие процессы можно автоматизировать только заказной разработкой, которая при наличии законов, регламентирующих госзакупки, становится очень непростой. Время написания частного технического задания на такую систему соизмеримо с временем на написание самого программного обеспечения. Но без технического задания не выделят денег из бюджета, более того, даже не разрешат объявить конкурс. Не говоря уже о том, что разработка занимает много месяцев, за которые из-за принятых законодательных или подзаконных актов требования к государственной системе могут драматически измениться, вплоть до исчезновения необходимости самой системы ввиду отмены конкретного государственного процесса или даже расформирования ведомства. Поэтому технические задания на подобные системы пишутся в самом общем виде, а в процессе реализации проекта сторонами принимаются многочисленные поправки.

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

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

Основные принципы защиты ведомственных приложений

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

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

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

Пренебрежение защитой приложений может повлечь за собой серьезные проблемы с функционированием государственных информационных систем. Поскольку производители компонентов инфраструктуры все большее внимание уделяют средствам защиты, вектор атак постепенно смещается в область приложений, для проникновения в систему используются уязвимости в конкретном программном обеспечении. Целевые атаки на приложения с помощью их уязвимости могут иметь цель нарушить работу системы (DoS/DDoS — атаки, или «падение» системы), похитить пользовательские данные (как персональные, так и служебные, например, учетные данные и пароли) или провести незапланированные разработчиком операции, в частности мошеннические.

Что особенного?

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

· Это не проект, а процесс: его можно начать, но нельзя завершить, сказав: «Все, мы закончили, наше приложение защищено». Изменения в заказных приложениях происходят постоянно: меняются процессы государственного управления, используемые технологии, требования регуляторов и т. д., поэтому никакое заказное приложение в государственной информационной системе не может остановиться в развитии. А значит, надо контролировать не только одно из состояний приложения в конкретный момент, но и весь процесс внесения и принятия изменений.

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

· Проблему нельзя решить покупкой какого-нибудь инструмента. Во многом традиции корпоративной информационной безопасности связаны с конкретным типом решения — например, для борьбы с вирусами нужен антивирус, со спамом — антиспам, с вторжениями — система предотвращения вторжений. Однако нет такого «волшебного» инструмента, который бы нажатием кнопки «сделать все хорошо» снял бы проблемы защиты приложений.

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

«Переходящий красный вымпел»

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

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

Контроль на каждом этапе жизненного цикла

Процесс разработки заказных ведомственных решений должен быть выстроен следующим образом.

На этапе проектирования нужно предусмотреть роли пользователей систем — от суперадминистратора до гостя, и для каждой роли запланировать свой профиль с доступом только к определенным данным и процессам. Все права и все действия каждого пользователя должны контролироваться и документироваться не функциями кода, а настройками.

На этапе кодирования сгенерированный исходный код приложения должен контролироваться на наличия соответствия различным требованиям — правилам безопасного программирования, совместимости с другими корпоративными и служебными приложениями, лучшим практикам разработки, требованиям регуляторов и т. д. В случае, когда информационная система разрабатывается не с нуля, а на базе какой-то бизнес-платформы (1С, SAP, MS Dynamics, IBM Lotus и т. д.), необходимо также учитывать при контроле исходного кода и все рекомендации производителей платформы.

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

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

Процесс, а не проект

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

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