О чем стесняются спросить безопасность?

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

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

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

Более масштабные последствия для бизнеса имела афера программиста из компании «Акционерный капитал» (являющейся реестродержателем акций компании «Татнефть»), похитившего в 2005 году с помощью специально разработанного программного модуля 110 тыс. акций «Татнефти» на сумму 5,7 млн руб. и осужденного за это на пять с половиной лет. Мошенники «одалживали» акции, снимая их со счетов, прокручивали на ММВБ, после чего возвращали, оставляя себе прибыль. Для этого в компьютерной программе Kapital, проводящей операции с ценными бумагами, программист-инсайдер создал специальную папку, в которую поместил модуль, позволявший выбирать из базы данных владельцев акций «Татнефти» физических лиц, имевших не меньше 300 акций. Затем со счета каждого из них на счета, контролировавшиеся мошенниками, переводилось по 100 акций, после чего ценные бумаги перемещались на ММВБ. Доходы, полученные от операций на бирже, перечислялись на «карточные» счета в казанском филиале банка «Зенит». Эти счета были также зарегистрированы на подставных лиц, те снимали с них деньги и передавали мошенникам. Основной задачей программиста-инсайдера было ввести в заблуждение компьютерную систему реестродержателя, чтобы она не заметила исчезновения акций со счетов законных владельцев.

По мнению Евгения Климова, вице-президента Ассоциации профессионалов в области информационной безопасности RISSPA (Russian Information Systems Security Professional Association), нельзя утверждать, что ПО вообще не подвергается проверке на предмет поиска недекларированных возможностей (НДВ). Для этого существует целая процедура сертификации в соответствии с требованиями государственных стандартов. Проблема заключается в том, что непонятно, для кого такая процедура является обязательной, а для кого — нет. Эта неопределенность обусловлена отсутствием внятных нормативных актов, регулирующих отрасль ИБ.

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

Чем защищаться?

Что касается серьезных бизнес-приложений уровня того же SAP, то здесь пока публично неизвестно о случаях внедрения программных закладок и их использования. Однако в прошлом году экспертное сообщество обеспокоил доклад SAP Backdoors, сделанный на конференции BlackHat USA 2010. В нем рассказывается по крайней мере о четырех путях внедрения программных закладок в инсталляции продуктов компании SAP.

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

Технический способ защиты предполагает передачу кода ПО, разработанного самостоятельно или на заказ, на аудит внешним экспертам. В качестве технических средств для поиска программных закладок могут использоваться сканеры кода, которые способны по определенным алгоритмам обнаруживать подозрительные части кода. Кроме того, для обнаружения закладок могут использоваться тестовые среды и анализаторы потенциальных уязвимостей. Например, для приложений SAP подобные технические средства и услуги предоставляет ряд компаний (Onapsis и Virtual Forge), которые используют статический и динамический анализ кода.

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

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

Аудит сокровенного

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

Классические сканеры приложений хорошо справляются с поставленной им задачей — поиском критических уязвимостей в коде приложений, у их разработчиков накоплен колоссальный опыт поиска уязвимостей. Но у бизнес-приложений есть и своя специфика: существенная часть уязвимостей безупречна с точки зрения языка, но использует специфику архитектуры приложения или особенности бизнес-процесса. Например, ни один существующий сканер не признает ошибкой в коде АБС изменение номера банковского счета клиента в обход процедуры, а опасность такой операции в коде очевидна. С точки зрения программирования команда на одновременную блокировку двигателей всех автомобилей, защищенных спутниковой сигнализацией, не является подозрительной, а с точки зрения бизнеса может привести к непоправимым последствиям. Никто не знает функционал и архитектуру приложения лучше, чем сам заказчик разработки. Очевидно, что в дополнение к существующим на рынке сканерам и сервисам заказчику нужен инструмент контроля своих собственных разработок, который можно самостоятельно или с помощью сторонних консультантов настраивать на обнаружение специфических для бизнес-приложения уязвимостей.

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

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