20 февраля 2013
Безопасность заказных приложений
Доверять программистам или проверять их работу?
Реалии сегодняшнего дня
По опросам журнала Computerworld 60% компаний планируют в текущем году набирать в штат программистов. Большинство таких компаний вовсе не производители программного обеспечения – это обычные компании, для которых производство программного обеспечения не основной бизнес или не бизнес вообще. При всем выборе готовых бизнес-приложений большинство компаний все же занимаются собственной доработкой «коробочных приложений», либо разрабатывают свои приложения «с нуля». Иногда это связано с уникальностью бизнес-процессов (особенно это характерно для уникальных компаний, которых в нашей стране достаточно), иногда – с существенной избыточностью готовых решений, но так или иначе, современные компании уже не могут работать без своего собственного программного обеспечения.
Деловое программное обеспечение содержит жизненно важную для деятельности предприятия информацию, а также ключевые процессы ее обработки. Нарушения безопасности такого приложения чревато потерей или утечкой данных, неавторизованными транзакциями, перехватом управления и другими, чувствительными для компании угрозами. Поэтому заботиться о защищенности самого приложения, а не только инфраструктуры, в которой оно исполняется (точки ввода и обработки данных, каналы передачи), необходимо в течении всего жизненного цикла приложения.
Производство делового программного обеспечения – сложный многоэтапный процесс, включающий в себя проектирование, кодирование и тестирование. Даже в самом простом программном обеспечении часть недостатков выявляются уже на этапе эксплуатации и тогда требуется оперативно их исправлять. Для того, чтобы все эти процессы увеличивали не только функциональность и стабильность приложения, но и его безопасность и безопасность обрабатываемых данных, на каждом этапе должна создаваться и проверяться соответствующая компонента безопасности. Описание таких компонент и действий с ними описываются в руководствах по безопасной разработке приложений и, с несколькими вариациями от разных производителей средств разработки, носят название SDL (Security Development Lifecycle).
Казалось бы, чего выдумывать – все рекомендации есть, применяй и пиши безопасные приложения. Однако в случаях, когда дела касается заказной разработки (custom development или off-shore development) и разработки собственными силами (in-house development), то рекомендации SDL часто нарушаются или игнорируются.
По данным HP Fortify, один доллар, вложенный в контроль качества программного обеспечения на этапе разработки экономит 30 долларов на этапе эксплуатации. Такое соотношение, рассчитанное для тиражного программного обеспечения, не выполняется для проприетарных приложений – заказчик всего один. Разработчикам ставится в качестве контрольных параметров стоимость разработки, ее функциональность, стабильность, возможно, переносимость, но практически никогда – защищенность. Если с web-приложениями, которые открыты для доступа всем пользователям Интернет, еще действуют стереотипы про всемогущих хакеров, заставляющие заботиться о безопасности хотя бы web-доступа, то требования по защищенности внутренних приложений (ERP, документооборот, бухгалтерия, кадры) зачастую ограничиваются длинной пароля и частотой его смены.
Любое сотрудничество, в том числе и сотрудничество заказчика и разработчика, прежде всего, вопрос доверия. Если начать подозревать исполнителя в недобрых намерениях, то лучше вообще отказаться от сотрудничества. Но это не означает, что нужно вообще отказаться от сотрудничества и строить отношения только на доверии – все-таки вы делегируете ключевую функцию своего бизнеса.
Не преувеличена ли угроза, исходящая от разработчиков заказных приложений? Не превысит ли стоимость борьбы с такими угрозами экономию от более безопасной работы приложений? Каждая компания решает этот вопрос для себя самостоятельно, исходя из важности данных и процессов и стоимости самой разработки. Чем важнее для бизнеса компании реализуемый в программном обеспечении процесс, тем выше цена ошибки.
Сколько компаний впало в зависимость от собственных разработчиков? В частных разговорах руководители небольших банков жалуются, что боятся ухода команды разработчиков своей банковской системы больше, чем давления со стороны государства. Что увольнение или долгая болезнь ключевого программиста может поставить под угрозу новые маркетинговые программы или новую отчетность для регуляторов – все это надо запрограммировать. О том, что кроме заявленного функционала, в программах может находиться что-то еще, руководители компаний предпочитают не думать, иначе у них возникает ощущение полной беспомощности. Случаев шантажа (неявного или прямого) программистами своих работодателей не так уж и мало, почти все попытки шантажа являются успешными – компании предпочитают платить (огромное выходное пособие увольняющимся, повышенную зарплату и бонусы остающимся, продление и расширение контрактов подрядчикам), но не ставить под угрозу безопасность ключевых бизнес-процессов, реализованных в заказном программном обеспечении. Поэтому такие случаи и не становятся публичными, не выливаются в судебные процессы, а по-тихому решаются внутри компании.
Попробуем классифицировать угрозы, исходящие от программистов.
Первый класс – некорректное программирование, то есть ненамеренное и бескорыстное внесение в код программных конструкций, приводящих к недекларируемым возможностям программного обеспечения. Например, одной из наиболее часто встречающихся (но не единственной) таких некорректностей является возможность проведения атаки типа «инъекция». Такая возможность появляется в случаях отсутствия процесса предварительной обработки данных при вводе или некорректности такого процесса. В случае, например, SQL Injection, отсутствие обработки вводимой в поле формы информации позволяет ввести вместо данных SQL-запрос и получить данные, к которым у пользователя не должно быть доступа, включая чувствительную информацию, пароли и т.д.
Некорректность может быть идеальной с точки зрения программирования, ущербным может быть реализованный бизнес-процесс. Например, если вы при описании задачи программисту не укажете точно, что платежное поручение формируется только при заведении платежных документов в соответствующую базу документов, он может выстроить процессы печати платежки и занесения платежки независимыми параллельно. А это, сами понимаете, открывает сотрудникам возможность осуществлять незапланированные платежи.
Поскольку такие некорректности создаются ненамеренно, то в их поиске и исправлении заинтересованы сами программисты, поэтому если ваша модель угроз ограничивается такими некорректностями, то здесь разработчики являются вашими союзниками и инструменты контроля могут выбираться совместно с ними.
Второй класс – намеренно, но без злого умысла, внесенные в код приложения недекларированные возможности. Это технические учетные записи, отладочная информация и другие приемы разработки, упрощающие отладку, тестирование и поддержку системы. Когда заказчик всего один, зачастую гораздо эффективнее экономически не выпускать «заплатку», а поправить код «руками» (что, кстати, категорически запрещено в рекомендациях SDL). Для этого разработчик оставляет себе учетную запись, через которую может практически полностью управлять приложением – создавать пользователей с любыми правами, менять код (особенно в приложениях, написанных на интерпретируемых языках), менять структуру таблиц и т.п. Внесенные в код из чистых побуждений, такие конструкции, особенно, если о них не знает заказчик, со временем могут стать серьезной угрозой. Программисты меняют работу, переходят на «темную сторону» информационной безопасности, поэтому такие «тайные ходы»становятся известными третьим лицам, да и сами программисты или их работодатели иногда меняют намерения, которые, подкрепленные такими возможностями, дают злоумышленникам неограниченную власть над данными и процессами приложения. Сейчас, например, в Сети активно обсуждается найденный в работающей системе ДБО во время аудита кода отладочный код, пересылающий информацию о всех транзакциях на определенный почтовый адрес. Ничего плохого разработчик не имел ввиду, но налицо нарушение требований к обработке финансовых транзакций.
Разработчики в общем случае не особенно скрывают от заказчика наличие таких свойств у продуктов. Но и не слишком афишируют. Правильной стратегией в отношении к этому классу некорректного программирования будет требование декларирования всех таких функций в рамках передачи продукта в эксплуатацию. По завершению тестирования и приемки продукта необходимо деактивировать (не обязательно удалять) отладочный функционал и поставить под полный контроль все технические учетные записи. Если необходимо ими пользоваться – пожалуйста, но доступ должен предоставляться заказчиком каждый раз по запросу разработчика с обоснованием цели доступа и с контролем результатов внесенных изменений.
Третий и самый опасный класс некорректного программирования – злонамеренно оставленные «закладки». Вряд ли программисты работают на вашего конкурента, спецслужбы, организованную преступность или другое государство, хотя чем черт не шутит. Большинство обнаруженных закладок в бизнес-приложениях – банальный способ привязать заказчика к себе. Это могут быть триггеры, позволяющие демонстрировать власть над приложением без авторизации в нем, например, отправкой e-mail или SMS на определенные адреса, или даже пополнением счета через платежный терминал на определенную, некруглую сумму, например 660 рублей (реальный случай в сотовом ритейлере). Если ваше приложение позволяет, чтобы данные попадали в него через такие шлюзы, настоятельно рекомендуем проверить обработчик ввода и обратить внимание на необычные проверки значений поступивших данных. Это могут быть триггеры, «будильники», выставленные на определенные даты, чтобы прервать в определенное время работу приложения и заставить заказчика обратиться в техподдержку, заплатить за продление лицензии, купить новую версию и так далее.
Искать закладки, заложенные враждебным государством – тяжелый труд, однако со злонамеренными программистами-любителями бороться не так сложно. Есть всего дюжина способов манипуляции доступом, и проверить их наличие – вопрос воли заказчика. Также на практике не очень сложно найти триггеры, запускающие процессы по поступлению команды извне или таймеру. На самом деле такими вещами занимаются не самые квалифицированные программисты, уверенные в своей полной безнаказанности – ну кто всерьез будет изучать код простого бухгалтерского приложения? Квалифицированные программисты, способные обмануть дорогой сканер и матерого аудитора кода и так зарабатывают достаточно для того, чтобы не рисковать в личных целях репутацией, а то и свободой. Ну и нам остается молиться, чтобы данные в наших приложениях не были интересны врагам, имеющим достаточные ресурсы для внедрения в программистские команды, работающие над нашими приложениями «джеймсов бондов» с экстремальными навыками программирования.
Исследование заказных бизнес-приложений на предмет некорректного программирования с помощью традиционных средств тестирования тиражных приложений наталкивается на объективные трудности – отсутствие специалистов, способных интерпретировать результаты работы такого инструмента, необходимость выстраивания бизнес-процессов под требования SDL, использование проприетарных языков, отсутствие у заинтересованных специалистов и информационной безопасности влияния на команду и процедуры разработки и другие. Ручной аудит кода тоже мало помогает в таких случаях – среднее время выхода нового билда у активного корпоративного приложения – от нескольких дней до месяца, а сроки исследование кода в лаборатории – несколько месяцев, то есть заключения об исследовании приложения будут выдаваться, в лучшем случае, на позапрошлую версию, а ведь нужно еще время на исправление найденных некорректных программных конструкций.
В последнее время стали появляться специализированные решения, позволяющие искать образцы некорректного программирования в быстроменяющихся приложениях, в том числе и на проприетарных языках (ABAP4, 1C, LotusScript и т.д.) и даже «из облака», но и они работают только при постановке процессов контроля кода, на что требуется воля руководства компании, призванного объединить различные и часто противоречивые требования бизнес-подразделений, разработчиков и сотрудников информационной безопасности.
Стоит ли это делать любой компании, использующей проприетарное программное обеспечение? Точного ответа на это нет – построение процесса контроля кода стоит денег и применения административных ресурсов. Доверять полностью, принимать риски частично или жестко контролировать код – решать руководителям бизнеса. Если вы задумываетесь над тем, стоит ли это делать, обратите внимание на следующий факт – почти треть компаний, проаудировавших код своих приложений, поменяли программистов или подрядчиков. Как вы думаете, почему?
