Ситуация на нашем рынке и за рубежом. Ключевые инструменты российского рынка
Ритейл, как товарный, так и финансовый, просто не может существовать как бизнес, без сквозной автоматизации, – слишком много клиентов, слишком много транзакций, слишком большой ассортимент товара, чтобы такой объем данных можно было обработать вручную. От четкости работы автоматизированной системы напрямую зависит прибыль, час простоя такой системы может стоить для большой розничной сети миллионы долларов, поэтому бизнес напрямую заинтересован в надежности и безопасности такой системы.
Большинство ритейловых информационных систем разрабатывается собственными силами компаний, иногда с привлечением третьих сторон – компаний, специализирующихся на заказной разработке программного обеспечения или контрактных разработчиков. Даже если в пресс-релизах написано, что компания внедрила у себя ERP, CRM, SCM, BI и другую систему известного производителя, будьте уверены, что над внедрением трудились десятки или даже сотни программистов, «кастомизирующих» упомянутое уважаемое решение под нужды конкретной компании. И поддерживать такую систему, адаптировать ее под быстроменяющуюся бизнес-среду и развивать по требованиям бизнеса будет не меньшее количество разработчиков – штату программистов в крупных ритейловых компаниях могут позавидовать большинство резидентов Сколково.
Однако те компании, которые разрабатывают программное обеспечение на продажу и те, которые пишут его для себя – два совершенно разных способа разработки. Баланс бизнес-требований и требований безопасности приложений при разработке «для себя» («in-house development”) сильно перекошен в сторону функционала, а требования к безопасности ограничиваются в основном устойчивостью («чтоб не падала»).
На самом деле проблем с безопасностью гораздо больше, чем об этом принято говорить. Зарабатывая на жизнь аудитом кода заказных бизнес-приложений, мы регулярно сталкиваемся с определенными типами угроз, которые сознательно игнорируются компаниями.
Прежде всего - это бизнес-ошибки (поскольку по программному коду не всегда можно определить умысел, из презумпции невиновности будем считать их именно ошибками, а не намеренными закладками). Большинство программ типа «купи что-то, получи что-то» реализуются в виде отдельных процедур, загружаемых на серверы магазинов и на кассовые аппараты, поэтому незначительная ошибка в цене или скидке сразу тиражируется на десятки и сотни тысяч терминалов. Практически анекдотически звучит для наблюдателя, но это практически типовой случай – программист ставит закрывающую скобку не в том месте, и большая скидка распространяется не только на конкретную неликвидную модель сотового телефона, но и на все сотовые телефоны, включая новейшие смартфоны. Час работы сотен магазинов – и сгенерированы десятки миллионов рублей убытков. При тестировании модуля не проверяется бизнес-логика, а лишь ее стабильность, поэтому служба ИТ как бы в убытках не виновата.
Ошибки в web-приложениях (интернет-магазинах, личных кабинетах в программах лояльности, платежных приложениях), приводящие к возможности пользователям выполнить действия, на которые они не авторизованы, характерны не только для ритейловых информационных систем, но от этого не становятся менее опасными. Поскольку такие приложения «смотрят» в Сеть, то предельное количество потенциальных пользователей – все интернет-пользователи, среди которых могут находиться и злоумышленники, и просто любители попрактиковаться во взломе. В одном банке во время исследования системы интернет–банкинга была найдена возможность изменения валюты счета без изменения суммы, то есть клиент мог положить 1000 рублей и щелчком мыши превратить их в 1000 долларов.
Пока еще не ставший массовым мобильный банкинг, кроме несомненного удобства, добавит добросовестным пользователям новых рисков не обнаружить на своем счету денег, бонусных баллов и пр.
Даже если система пишется «для внутреннего пользования», это не значит, что такие ошибки не опасны – среди сотрудников могут находиться не только лояльные исполнители.
«Городские легенды» о «закладках», которые оставляют мстительные программисты, и которые активизируются после их увольнения и уничтожают данные и сами разработки, тоже встречаются довольно часто. Каждый разработчик подсознательно заинтересован как можно дольше «доить» заказчика, а переход от фантазий к планам мести за неповышенную зарплату или невыплаченную премию к конкретным действиям – вопрос лишь воспитания, поскольку все возможности для этого есть. В нашей коллекции есть десятки подтверждений этому, включая случай, когда команда на отключение системы была дана уволенным программистом путем пополнения счета на 666 рублей.
Инструменты для исследования кода давно известны, но практически не применяются при разработке бизнес-систем. По результатам опроса на сайте securitylabs.ru, только 7% компаний, разрабатывающих бизнес-приложения для собственных нужд, используют какие-либо средства контроля качества кода, остальные полностью полагаются на порядочность разработчиков.
Большие и жизненно важные бизнес-системы перед приемкой отдаются третьей стороне на анализ различными инструментами, однако для быстроменяющихся систем этот метод не работает – приложение меняется быстрее, чем работают такие лаборатории. Например, в розничном бизнесе приложения меняются еженедельно, если не ежедневно, а срок исследования ПО в лаборатории – несколько месяцев.
Выходом из такой «расходящейся» ситуации является постановка процессов полуавтоматизированного анализа кода в процессе разработки, который настроен на детектирование опасных программных конструкций всех описанных типов. Можно использовать для этого системы анализа кода, встроенные в среду разработки, можно использовать отдельные продукты и «облачные» сервисы по аудиту кода.
Такие средства быстро и практически без настройки находят ошибки программирования. Однако для детектирования безупречных, с точки программирования, но опасных, с точки зрения бизнес-процесса, программных структур требуется квалифицированная настройка. В этом случае нужна команда, которая с одной строны, хорошо понимает языки программирования, на котором реализовано приложение (разработчики), с другой – архитектуру и бизнес-процессы (архитекторы), реализованные в приложении, а в третьих – могут смоделировать атаки в заданном языке и архитектуре (исследователи-«безопасники»).
Системы контроля исходного кода для бизнес-приложений появились совсем недавно, и первыми их использовать начали организации, в которых риски, порожденные ошибками и закладками ПО являются критическими – это военные ведомства и энергетические компании. Но уже есть решения, которые могут себе позволить и те организации, для которых риски, порожденные заказным ПО, не так критичны – это финансовые компании, розничные и телекоммуникационные компании. В России же такие проекты пока единичны.
Орфография и пунктуация в данном тексте сохранены в том виде, в котором они были предложены автором.
