Безопасное приложение или снова «кот в мешке»?
Банкам нужны новые ответа для предотвращения рисков, которые связаны с уязвимостями ПО.
Александр Пуха, ведущий консультант департамента информационной безопасности АМТ-ГРУП
Специфика деятельности банков обязывает их уделять повышенное внимание вопросам обеспечения информационной безопасности. Одни продвинулись в этом деле дальше, иные до тех пор пока отстают, но возможно сказать о том, что большая часть за последние годы выстроило комплексные совокупности обеспечения информационной безопасности.
До недавнего времени атаки как правило концентрировались на сетевом уровне, и возможностей классических сетевых средств защиты (системы предотвращения и межсетевые экраны вторжений) было достаточно для их отражения. Сейчас отмечается другая тенденция: фокус атак сместился на прикладной уровень – веб-сервисы, ERP, CRM, СУБД, IP-телефонию; последние изучения отрасли говорят о том, что около 75% атак на текущий сутки реализуются именно на прикладном уровне.
Сетевые средства защиты не в силах справляться с подобными атаками, поскольку они не трудятся на уровне их реализации. Сохранять надежду лишь на защиту периметра уже запрещено. Нужны новые ответа для предотвращения рисков, которые связаны с уязвимостями ПО (потом – ПО).
На данный момент такими ответами являются статический и динамический анализ приложений.
Любое ПО уязвимо
сложность и Разнообразие ПО, каждый день применяемого современными организациями, непрерывно возрастают. Будь то коммерческий продукт, личная разработка, приложение, созданное на заказ, либо приложение с открытым исходным кодом, оно может содержать уязвимости, предоставляющие преступникам возможность взять несанкционированный доступ к ресурсам и информации организации, что, со своей стороны, может приводить к нарушениям бизнес-процессов, утечкам тайных сведений, нанесению ущерба репутации, нарушению требований законодательств и иным негативным последствиям.
От качества применяемых ИТ-ответов в значительной степени зависят эффективность процессов организации, ее возможность и конкурентоспособность скоро приспособиться к изменяющимся внешним условиям. Борьба за рынок предъявляет все новые требования к бизнесу, что, со своей стороны, ставит дополнительные задачи перед работами, несущими ответственность за информационные разработки.
Повсеместным делается применение ПО собственной разработки и созданного на заказ, поскольку данное ПО может всецело удовлетворять всем потребностям организации и являться конкурентным преимуществом на рынке. Это особенно актуально для больших организаций, имеющих разветвленную сеть филиалов и трудящихся в часовых и различных городах поясах.
Реальность такова, что при разработке ПО сомостоятельно либо на заказ внимание разработчиков прежде всего сосредоточено на реализации заданного функционала. Вопросам информационной безопасности, в большинстве случаев, внимание уделяется по остаточному принципу. Как следствие, полученные приложения владеют очень низкой защищенностью от несанкционированного доступа.
Отсутствие нужных механизмов обеспечения информационной безопасности, некорректно написанный код либо кроме того особые «закладки», покинутые разработчиками смогут стать обстоятельством инцидентов, каковые принесут организации большой вред.
Будь то приложение сторонней либо собственной разработки, имеете возможность ли вы верить втом, что оно достаточно безопасно? Всецело ли вы доверяете сторонним разработчикам? есть ли ПО собственной разработки более доверенным, чем сторонней?
Опасаюсь, что как правило ответом на все поставленные вопросы будет «НЕТ».
В этот самый момент стоит отыскать в памяти всем известное правило, в соответствии с которому надежность всей совокупности защиты определяется надежностью ее самого не сильный звена. Уповать на «хороший» комплект средств защиты в складывающихся условиях уже запрещено.
Организациям нужны действенные ответы, разрешающие удостовериться, что реализация применяемого ПО соответствует требованиям, уровень качества – ожиданиям, и его применение не формирует угрозы для обрабатываемой в организации информации. Как было упомянуто выше, на данный момент такими ответами являются статический и динамический анализ приложений.
Статический анализ
Статический анализ является анализомисходного кода приложения, создаваемый без его настоящего исполнения. С его помощью возможно не допустить неточности до их внесения в состав главного кода программы и обеспечивать, что новый код соответствует стандарту, будь то код собственной разработки либо код, полученный от стороннего разработчика.
Исходные тексты приложений являются объемным источником информации, где имеется суть искать не только чисто технические неточности, ведущие к тем либо иным видам защищенности свойств приложения и нарушения безопасности, вместе с тем логические неточности — передача паролей в открытом виде, неверный выбор методов шифрования. Применение разных техник статического анализа разрешает удачно распознать все разнообразие типов уязвимостей, логических неточностей, других проблем и дефектов реализации.
Анализ исходного кода может производиться как «вручную», так и с применением специальных инструментов автоматизации. И в том, и в другом случае он разрешает обнаруживать программные неточности еще на ранней фазе создания проекта, перед тем, как создается исполняемый файл. И это крайне важно – так как существенно действеннее и экономичнее защищать приложения на протяжении их разработки, а не по окончании их развертывания.
Методики «ручного» анализа разрешают досконально проверить код, в теории разрешая взять самые полные и релевантные результаты. Одновременно с этим его качественное исполнение требует важных временных наличия и затрат высококвалифицированных экспертов, являющихся не просто качественными разработчиками, а талантливых посмотреть на код программы глазами взломщика, отыскать в нем тот «ключик», что возможно возможно использован преступником.
Но что же делать, в случае если временные и человеческие затраты, нужные для исполнения анализ кода «вручную», не приемлемы для бизнеса? Как быть, в случае если чтобы не отстать от соперников, сервис нужно реализовать еще «день назад»? Так как организации стремятся выпустить приложение в эксплуатацию как возможно скорее, и это особенно критично в случаях, в то время, когда оно разрешит взять конкурентные преимущества, оптимизировать процессы, привлечь новых клиентов, повысить лояльность ветхих.
Согласитесь, в аналогичных случаях вопросы безопасности производимого приложения не будут играться решающую роль, и связанные риски не должны останавливать организацию. Но и вовсе не уделять внимания вопросам безопасности также запрещено. В этих обстоятельствах на помощь приходят средства автоматизации процессов анализа кода.
Применение средств автоматизации разрешает в разы сократить требуемые временные затраты. В базе аналогичных ответов лежат знания и опыт, накопленные их разработчиками, что разрешает ожидать от них качественных результатов. Наряду с этим трудящийся с ними эксперт не обязательно обязан владеть столь же большим уровнем компетенций, как эксперт, делающий «ручной» анализ кода.
Инструменты автоматизации разрешают выполнить трудоемкий процесс анализа в приемлемые сроки, посмотреть в самые «чёрные» уголки исходного кода и обеспечить полное покрытие кодовой базы приложения.
Но статический анализ, и это особенно актуально, в то время, когда мы говорим о его автоматизации, имеет один значительный недочёт. С математической точки зрения – это алгоритмически неразрешимая задача. Принцип работы средства статического анализа основан на проверке кода с применением шаблонов и фиксированного набора правил.
Эта особенность ведет к двум последствиям, каковые нельзя не учитывать: наличию в коде уязвимостей, каковые инструменту найти не удалось, и к происхождению фальшивых срабатываний. Так, в случае если для определенной уязвимости либо неточности еще не было создано соответствующего правила, инструмент ее не найдёт.
И в случае если инструмент говорит вам что-нибудь в стиле «Уязвимостей не найдено – Ваше приложение защищено», в действительности это указывает «Проверил то, что имеется в базе, больше отыскать не могу». Инструмент не сможет сообщить вам, какая неприятность более критична и требует немедленного исправления, а какая может и подождать, потому, что не связана с важными рисками либо вовсе есть не проблемой, а изюминкой разработки.
Для получения самые эффективных результатов обязана существовать «золотая середина». Инструмент автоматизации разрешает сократить временные трудозатраты, исключить солидную часть рутинной работы, но анализ взятых результатов, их выбор и корректировка нужных последующих действий – дело рук человека.
К главным факторам, на каковые нужно обратить внимание при выборе инструмента автоматизации анализа направляться отнести:
— степень совместимости с существующей методикой разработки;
— наличие помощи языков программирования, применяемых внутренними и/либо сторонними разработчиками;
— качественная помощь от производителя ответа, наличие широкой, неизменно поддерживаемой правил и базы шаблонов;
— возможность независимой настройки правил в соответствии с существующими изюминками стиля разработки;
— прозрачность и простота эксплуатации средства автоматизации;
— использования рекомендации и простота понимания по итогам анализа.
Динамический анализ
Кое-какие категории уязвимостей смогут быть найдены, лишь в то время, когда приложение запущено на выполнение. В этом случае на помощь приходят инструменты динамического анализа приложений. Их применение разрешает разработчику замечать либо диагностировать поведение приложения на протяжении его выполнения, в совершенном случае это должно осуществляться конкретно в среде эксплуатации.
Специфика работы инструментов динамического анализа такова, что разрешает найти уязвимости лишь в тех участках кода, каковые исполняются. Анализ выполняется посредством комплекта данных, каковые подаются на вход исследуемой программе. Исходя из этого эффективность анализа зависит от количества и качества входных данных для тестирования.
Как раз от этого зависит полнота покрытия кода тестируемого результатов и приложения. К вторым недочётам динамического анализа направляться отнести возможность его применения только на поздних этапах разработки, и необходимость самостоятельно выяснить фрагмент исходного кода, соответствующий функции либо процедуре, на протяжении выполнения которой появилась неточность.
Преимуществами динамического анализа есть низкий уровень фальшивых срабатываний, поскольку обнаружение неточности происходит в момент ее происхождения в программе. Так, найденная неточность есть не предсказанием, сделанным на базе анализа исходного кода, а констатацией факта ее происхождения. Помимо этого, анализ в рабочей среде дает возможность приобрести самые релевантные результаты, учесть особенности среды, воздействующие на возможность проведения атаки.
Оптимистичное заключение
Количество вероятных векторов атаки на информационные совокупности организаций со временем лишь возрастает. Защита на уровне устройств и сети – это не панацея, и в случае если применяемые в организации приложения содержат уязвимости, то становятся уязвимы и корпоративные информационные совокупности в целом. Организации должны пересмотреть собственный отношение к безопасности кода применяемых приложений.
Нужно уходить от реактивного подхода, заключающегося в реагировании на произошедшие инциденты, к предупредительному. Определять и ликвидировать неточности в уже существующих приложениях не хватает, более принципиально важно обеспечить надёжную разработку на протяжении создания и в течении всего жизненного цикла; принципиально важно думать о безопасности ПО везде, где это вероятно.
Любая из методик, будь то статический либо динамический анализ, имеет собственные сильные и не сильный стороны. В зависимости от преследуемых особенностей и целей процесса разработки организация может выбрать самая подходящую методику, или применять эти инструменты в тандеме, что, в конечном счете, окажет помощь разработчикам создавать ПО лучшего качества и в более маленькие сроки. Необходимо помнить: чем раньше будет найдена программная неточность, тем стремительнее и дешевле ее возможно исправить.
