Код на пальцах
Автор
Илья Медведовский
Внутренняя разработка есть практически у любой крупной компании. Если ее нет, то, возможно, ее надо просто немного поискать
Продолжая начатую прошлой статьей тему безопасности бизнес-приложений, поговорим теперь о новой «модной» теме, связанной с SDL и анализом исходного кода. Почему в кавычках? Потому что этой теме уже давно пора было стать актуальной, но до сих пор для некоторых специалистов она таковой не является, несмотря на объективную необходимость.
На Западе данное направление давно и хорошо освоено, а у нас все еще остается экзотикой. Хотя отрадно, что понятие SDL (Security Development Lifeсycle) уже прочно вошло в нашу жизнь. И наконец настало время для популяризации темы статического анализа, неразрывно связанной с SDL. Почему это необходимо? Главным образом потому, что такой процесс — основа безопасной разработки. В свою очередь, без культуры разработки говорить о какой-либо безопасности прикладных систем не представляется возможным.
В настоящее время уровень зрелости российского рынка ИБ с точки зрения безопасной разработки и применяемых для реализации SDL технических алгоритмов, прежде всего статического анализа кода, находится на околонулевой отметке. В наших общих интересах максимально эффективно трудиться над изменением сложившейся ситуации.
SDL и анализ кода не для вас?
Возможно, вам кажется, что тема не имеет к вам отношения, поскольку вы не являетесь разработчиком уровня SAP, Microsoft или Cisco. Мы часто слышим такое: «Мы не софтверный вендор, мы — промышленная компания (читай: банк, ретейлер и т. д. — неважно). Мы не занимаемся разработкой, а значит, все это не для нас». Подобная убежденность порождает миф: «Мы не разрабатываем программное обеспечение, поэтому анализ кода нам не нужен».
А если копнуть глубже? Достаточно сказать, что если компания использует бизнес-приложения (SAP, Axapta, 1C, Lotus Notes и многие другие), то разработка внутри нее тоже ведется, причем серьезная. Она ведется на различных бизнес-языках, используемых в компании ERP-систем и систем документооборота. Крупный или даже средний банк, АБС которого меняется ежедневно и в которой буквально живут десятки программистов; SAP, в чьих недрах плодятся тысячи различных ABAP-программ; Lotus Notes, 1С и т. п., требующие постоянной кастомизации для бизнес-нужд. С каждым новым примером миф разбивается о реальность, не так ли? Внутренняя разработка есть практически у любой крупной компании. Если ее нет, то, возможно, ее надо просто немного поискать.
Несколько слов об SDL
Теперь перейдем непосредственно к анализу кода, не останавливаясь на деталях SDL.
Рис. Статический анализ vs Динамический анализ
Почему? Об SDL уже сказано довольно много и не хочется повторяться. Тем более, к некоторым элементам SDL все уже давно привыкли, хотя, может быть, нет понимания, что они являются таковыми. Ну, взять к примеру тест на проникновение.
Мы сосредоточимся на другом важнейшем элементе SDL — на анализе кода. Если тест на проникновение проводится уже на готовом софте или системе на итоговой стадии SDL, то анализ исходного кода становится одним из первых (но не первым!) и крайне важных этапов SDL. И поговорим мы теперь о простейших истинах, которые надо знать об анализе кода. Причем в первую очередь о статическом анализе.
Кому и зачем?
Так зачем и кому это нужно? Обратимся к цифрам: 50% компаний имеют опыт потери выручки вследствие инцидентов (Forrester Consulting); 95% уязвимостей содержатся в программном обеспечении (Software Magazine); 75% атак происходят на уровне приложений (Gartner).
Роль небезопасного кода в этой статистике трудно переоценить. Злоумышленник может эксплуатировать уязвимости в коде с тем же успехом, как и другие уязвимости на уровне приложения. Кроме того, закладка в коде программы предостаавляет разработчику-инсайдеру тайный доступ к информации после передачи кода в продуктивную систему. Все это означает, что разработка идет, код вместе с уязвимостями и закладками пишется, а служба ИБ не контролирует данный процесс. Никак. Нечем и некем.
Простой анализ рисков показывает, что кто-то внешний относительно разработки должен иметь возможность контроля исходного кода — в данном случае очевидна роль службы ИБ. Понятно, что теоретически перед разработкой должна стоять задача создавать безопасный код и тестировать его внутри на уязвимости. Но чтобы сделать эту схему жизнеспособной именно в службе ИБ, компании необходимо наладить относительно простой внешний контроль, основными элементами которого на разных стадиях SDL служат анализ кода и тест на проникновение, иначе вся безопасность разрабатываемых внутренних бизнес-приложений останется сугубо в теории и в умах разработчиков.
Основные виды анализа кода
Сегодня выделяют три основных вида анализа: статический, динамический и смешанный (динамический плюс статический)
Динамический и смешанный анализ — исключительно для пентестеров и программистов, для всех тех, кто напрямую вовлечен в процесс разработки и вынужден этим постоянно заниматься в ходе написания и тестирования кода. Статический же анализ гораздо проще, он проводится по исходному коду (а не по исполняемому, как динамический), не обязательно требует встраивания в процесс разработки и может быть внешним, сторонним элементом ее контроля. Его достаточно просто может на периодической основе внедрить и наладить служба информационной безопасности, что в принципе у нее не получится с другими видами анализа (или получится, но с очень большим трудом). Причем внедряется он на ранней стадии SDL. А потому названные методы анализа, в основном предназначенные для разработки, мы в дальнейшем вынесем за скобки и будем рассматривать лишь статический анализ как относительно легко внедряемый сторонний элемент контроля внутренней разработки для службы ИБ.
Статический анализ кода пришел в нашу жизнь еще в 1980-е годы. Все началось с простой постановки задачи, когда программисты решили, что было бы неплохо искать по простым паттернам (шаблонам) те или иные типовые куски в коде, которые свидетельствовали бы об отклонении от использования лучших практик программирования для данного языка. Так появился простой сигнатурный анализ исходного кода. С течением времени программисты поняли, что с помощью данного метода можно искать еще и другие недостатки в коде, ведущие к появлению различных уязвимостей. Это случилось несколько позже — уже в 1990-е, когда слово «уязвимости» вошло в обиход как повседневное, после появления знаменитого червя Морриса, поразившего Интернет в 1989 году.
Соответственно, еще в 1980-х возникло множество первых, в основном некоммерческих, инструментов статического анализа кода, которые были основаны на простых сигнатурных алгоритмах и постепенно пытались также искать уязвимости. Однако качество этих инструментов было ниже среднего, прежде всего из-за того, что применяемые ими алгоритмы сигнатурного анализа кода в принципе не позволяли обеспечить высокое покрытие (полноту) поиска уязвимостей (мало находили) при приемлемых показателях точности (генерировали огромное число ложных срабатываний), что делало невозможным практическое применение таких систем. И только в 2000 годах произошла алгоритмическая революция в поиске, когда простые сигнатурные алгоритмы поиска сменились гораздо более сложными алгоритмами, основанными на анализе потока данных. Именно широкое применение алгоритмов анализа потока данных позволило существенно повысить точность поиска уязвимостей в коде и стало основой для появления в начале 2000 года первых коммерческих продуктов по анализу кода, хорошо известных до сих пор.
Две большие разницы
Если вы планируете провести анализ кода, то прежде всего необходимо ответить на вопрос: «Это разовая акция или постоянный процесс?» Если разовая — пригласите сторонних аудиторов, специализирующихся в анализе кода. В таком случае абсолютно неважно, какими именно инструментами они пользуются (головой и руками, скриптами или современным мощным коммерческим инструментом анализа кода). Важна квалификация аудиторов. Профессионал в данном случае лучше самого совершенного автоматизированного средства анализа кода.
Если же вы планируете наладить у себя постоянный процесс, то вам надо задуматься о приобретении инструмента для анализа кода. И тут надо четко понимать, что основная задача любой автоматизированной системы анализа кода — максимально понизить требования к специалисту на стороне заказчика, который с ним работает. Потому что суперпрофессионалу — аудитору кода такой инструмент вовсе не обязателен. Для использования системы на стороне заказчика в его штате непременно нужен специалист (средний программист), который не является профессиональным аудитором кода, и качественное средство анализа. Именно такая связка способна реализовать надежный сторонний контроль службы ИБ над разрабатываемым кодом.
Качественный инструмент
Что отличается качественный инструмент анализа кода от некачественного? Чем нужно руководствоваться при выборе?
Полнота, точность, алгоритмы
Точность и полнота — два простых для понимания параметра — характеризуют любой инструмент статического анализа, предназначенный для поиска уязвимостей. Какой процент уязвимостей от 100 он ищет и какой при этом процент ложных срабатываний? Достойный ответ: свыше 80–90% уязвимостей при не более чем 10–20% ложных срабатываний. Простые сигнатурные инструменты ищут во многих случаях не более 20% от общего числа уязвимостей при высокой степени точности. Следует попробовать расширить диапазон поиска — количество ложных срабатываний будет расти по экспоненте и приблизится к ста процентам. Поэтому в основе средства статического анализа должны лежать алгоритмы, основанные на анализе потока данных, — это общемировая теория и основанная на ней практика, которой уже более 10 лет.
Команда и технологии.
Разработка качественного инструмента анализа кода — очень сложный и трудоемкий процесс. Найти 5–10 простых сигнатур, реализовав простой сигнатурный поиск, может «на коленке» любой студент. Выполнить анализ потока данных и постепенно повышать полноту и точность (а чем выше эти показатели — тем по экспоненте выше трудоемкость для разработчика) — способна только технологическая профессиональная команда..
Время добавления языка: постоянная борьба за качество
За несколько месяцев работы опытной команде удается реализовать анализ потока данных для одного языка и добиться более-менее приличного базового соотношения полнота/точность, но гораздо важнее, что будет потом. Каждый последующий процент улучшения качества поиска начнет требовать все больше времени и квалификации от разработчика, экспоненциально усложняя задачу.
Учет специфичных требований заказчика (application specific).
Любой современный инструмент статического анализа кода, основанный на анализе потока данных использует как простой сигнатурный анализ, так и анализ потока данных; при правильных настройках работает достаточно быстро; может искать как уязвимости, так и любые специфичные для данного приложения особенности или проверять, удовлетворяет ли код заранее заданным правилам, которые обычно легко описываются в виде простых сигнатур.
***
Тема анализа кода (неважно, статического, динамического или смешанного) достаточно сложна для понимания менеджером, так как требует программистских навыков. Мы попытались рассказать о сложном простыми словами . Надеюсь, что это поможет вам лучше понять простые основы, на которых базируется практика анализа кода.
Опубликовано 22.11.2013