Как избежать «недекларированных возможностей»?

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

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

Ярким примером подобных решений можно назвать бизнес-линейку фирмы 1С. Продукты же 1С стоит привести и в качестве примера того, что стандартные решения необходимо дорабатывать. Не зря на протяжении многих лет стабильно высоким спросом на рынке труда пользуется позиция 1С-программиста. Эти продукты практически невозможно использовать, что называется out of the box, т.е. без настройки и модификации под собственные нужды. А если программист начинает редактировать исходный код или дописывает новые процедуры, кто поручится, что логика работы программы будет соответствовать заявленной?

Что «умеют» программы

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

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

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

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

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

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

Сертификация на страже интересов бизнеса

Собственно, проблема появления в программном обеспечении недекларированных возможностей и связанные с этим риски известны уже давно. Можно предположить, что и средства противодействия уже освоены. Обратимся к регуляторам. Гостехкомиссия России (орган-предшественник ФСТЭК) еще в конце прошлого века издала руководящий документ под названием «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей». Этот и ряд других, еще более ранних документов, до сих пор остаются базовыми для компаний, желающих пройти сертификацию – по сути доказать, что недекларированных возможностей в их программах нет.

Если отбросить рассуждения о надежности предлагаемых РД методах контроля отсутствия недекларированных возможностей (потому что вопрос это неоднозначный, хотя бы в силу давности документов), сертификация выглядит вполне надежным средством проверки программного обеспечения. Испытания проводятся и контролируются серьезными организациями, которые своей репутацией отвечают за выданный сертификат.

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

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

Что еще есть в арсенале?

Сертификация – далеко не единственный способ контроля отсутствия недекларированных возможностей. По данным Appercut Security, наиболее популярными мерами являются организационные. Их используют 74% компаний (данные по российскому рынку). Безусловно, и разъяснительные беседы, и специальные соглашения необходимы. Но только не в качестве основного инструмента. Ведь, по сути, компания полагается на порядочность конечного исполнителя, программиста.

Каким образом компании защищаются от появления недекларированных возможностей

Источник: Appercut Security, 2011

Сертификация находится на втором по популярности месте (18%). Но почувствуйте 4-кратный разрыв с оргмерами! К тому же помимо сертификации в эту долю попали и другие случаи сторонней экспертизы. В целом, аудит программного кода независимой стороной следует признать достаточно эффективной, но дорогостоящей мерой. В отношении аудита справедливы слова, сказанные по поводу сертификации. Контроль конкретной версии продукта подразумевает необходимость очередного аудита любой другой версии.

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

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

Более надежным инструментом можно назвать разделенный цикл разработки программных продуктов (SDLC). При этом основные уязвимые (с точки зрения внедрения и выявления закладок) этапы разработки, проектирование, написание кода, тестирование и внедрение выполняются поочередно с привлечением различных сотрудников и, желательно, консультантов по безопасности. В данном случае вероятность установки закладки снижается, а обнаружения, наоборот, возрастает.

Реже всего для контроля программного кода компании используют технические средства (сканеры). В отличие от сертификации, которая может длиться по нескольку месяцев, сканеры работают быстро и действительно могут проверять каждую сборку. Однако применяемость технических средств в России находится на уровне 9%.

Почему компании не применяют технические средства контроля программного кода

Источник: Appercut Security, 2011

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

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

Куда шагнет отрасль

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

Что касается сертификации, несмотря на все указанные недостатки, компании сертифицировали, сертифицируют и будут сертифицировать свои продукты. Для одних сертификат является обязательным требованием регулятора в отрасли, для других – необходимым условием тендера со стороны заказчика.

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