ГлавнаяО насНовостиСтатьиРешенияКонтакты
Украинский интегратор защиты персональных данных

Про уязвимый код и картонные бронежилеты

Уязвимости

Рано или поздно каждый растущий бизнес сталкивается с необходимостью автоматизировать свои бизнес-процессы. Какой подход правильнее и безопаснее – "коробочное" решение или бизнес-приложение, написанное с нуля?

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

Компромиссом между двумя крайними подходами является покупка базового приложения или платформы, предполагающих последующую доработку до требований бизнеса – так называемую кастомизацию. Наиболее часто встречающиеся платформы для построения бизнес-систем – 1С, SAP R/3, Microsoft Dynamics, Oracle EBS, IBM Lotus Notes, EMC Documentum, БОСС и другие. Кастомизация представляет собой дописывание на встроенных языках программирования модулей, специфичных для процессов конкретного предприятия.

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

Безопасность разработки

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

Пока компания пользуется типовым, "коробочным" программным обеспечением, все процессы контроля качества и безопасности данных находятся у разработчиков таких продуктов. Все упомянутые ранее платформы производятся крупнейшими в своих сегментах компаниями, весьма озабоченными собственной репутацией и доверием, которое вызывает их бренд. Они могут себе позволить всесторонний контроль качества платформы и стандартных приложений, развернутых на ней. На каждом этапе разработки, начиная с проектирования, используются лучшие практики и продукты для поиска ошибок, неоптимальных конструкций "бутылочных горлышек", других некорректностей. Стенды для функционального и нагрузочного тестирования в таких компаниях стоят, без преувеличения, десятки миллионов долларов. Это неудивительно: по данным компании HP, при разработке тиражных продуктов один доллар, вложенный на этапе тестирования, экономит до 30 долларов на поддержке продукта.

Затевая собственную разработку (или глубокую кастомизацию), заказчик остается один на один с проблемой контроля качества – все тестирование придется делать самому или делегировать подрядчику, совсем не такому богатому и именитому, как Microsoft или IBM. Обычно ни один заказчик не обладает собственной экспертизой в разработке программного обеспечения – все же это не основной вид деятельности его компании. Зачастую соблюдение тех же стандартов, что и при создании тиражных продуктов, настолько усложняет и удорожает разработку, что от таких стандартов качества приходится отказываться. При этом использование стандартной и даже сертифицированной бизнес-платформы не предохраняет от угроз, привносимых программистами, – самые защищенные системы доверяют командам, приходящим по стандартным программным интерфейсам (API), поэтому в дописанном программном коде могут встречаться конструкции, сводящие на нет усилия разработчиков платформы.

Всегда ли "коробочное" решение безопасней?

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

Для разработки программ с нуля чаще всего используются традиционные языки программирования и среды разработки – Java, C++, .NET. Для веб-разработки применяются PHP, Python, в последнее время Ruby. Для этих платформ существует большое количество программных средств контроля качества кода и систем поиска уязвимостей, в том числе и бесплатных. Доработки "коробочных" приложений производятся чаще всего на малораспространенных скриптовых языках, а то и на проприетарных скриптах (1C, LotusScript, ABAP4, X++). Для Java, например, таких средств несколько десятков. Много ли вы знаете средств автоматизированого аудита программного кода 1С? Объявив конкурс на "ручной" аудит исходного кода на традиционных языках, вы получите десятки предложений. Причем в России всего десяток квалифицированных аудиторов кода ABAP и совсем нет аудиторов кода 1С.

Также нельзя исключать "эффект картонного бронежилета" – ложного чувства защищенности, которое возникает у заказчиков кастомизированной системы, попавших под очарование сильного бренда. Абсолютное большинство компаний, разрабатывающих свои внутренние бизнес-приложения с нуля, понимает, что надеяться не на кого, и так или иначе тестирует приложения на предмет наличия опасных программных конструкций, обращаясь в специальные лаборатории или используя специализированные программные инструменты. Разработчики же систем, основанных на бизнес-платформах (особенно это касается 1С), исключительно редко прибегают к исследованию кода, считая, что само наличие мощного решения в своей основе гарантирует защиту. Как картонный бронежилет опаснее, чем отсутствие бронежилета (человек без бронежилета хотя бы старается не высовываться), так и уверенность в том, что на защищенной платформе создаются защищенные приложения опаснее знания, что никто, кроме тебя самого, не может обеспечить защиту.

Модель угроз

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

Специалисты рассматривают четыре основные группы угроз приложениям: ошибки ввода, манипуляции с правами доступа, "логические бобмы" и "закладки".

Ошибки ввода – возможность воздействовать на приложение через стандартные формы ввода с правами пользователя. Вводя не те данные, которые ожидает программа (например, вместо пароля запрос к базе данных), можно при неправильно спроектированной системе обработки вводимой информации получить незапланированный ответ от приложения: в конкретном примере – получить список пользователей системы с их паролями. Атака на такую уязвимость называется "инъекция" (injection), особенно она опасна в веб-приложениях, у которых теоретическое число пользователей – все пользователи сети Интернет. Запрограммированные ошибки ввода возможностью "инъекций" не исчерпываются, но являются наиболее часто встречающимися ошибками этого рода. Например, группы хакеров утверждают, что на сайте Банка России некоторое время существовала уязвимость, позволяющая методом "инъекции" менять курс доллара, отображаемый на сайте.

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

"Логические бомбы" – функции программы, позволяющие менять действие приложения в зависимости от получения команд извне или по расписанию. Случайное зацикливание программы, приводящее к подвисанию приложения, – самый безобидный пример такой уязвимости. Встречаются и специальные функции, вносящие в деятельность программы регулярные возмущения, мотивирующие пользователя вызывать техническую поддержку и продлять контракт именно с данным разработчиком. Это не "городские легенды", а реальная практика привязывания заказчика к себе, солидные компании-разработчики такими методами, конечно, брезгуют, а вот фрилансеры – нет.

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

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

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

Не пора ли начинать бояться?

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

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

Автор статьи: Рустэм Хайретдинов


allCIO.ru (28.03.2013 в 09:53) | вверх страницы | к списку статей

Общие вопросы:

Что нас ждет в 2011 году и о чем необходимо задуматься сегодня?
Что такое защита персональных данных?
Для чего это необходимо?
Если не выполнять требования Закона?
Типовые нарушения
Какие риски неисполнения требований законодательства?
Сколько потребуется времени и средств?
Что необходимо делать?
Кому доверить внедрение защиты персональных данных?
ГлавнаяО насНовостиСтатьиРешенияКонтакты
Контактная информация
© 2003-2013 ООО "Ди Эй Кей продакшн"