Я слышал о фирмах безопасности, которые консультируют по вопросам безопасности систем клиентов. Все, кого я знаю в этой области, являются сетевыми инженерами, но я знаю, что программисты также участвуют в обеспечении безопасности. Что на самом деле делают программисты, которые проводят аудит / консалтинг? Проходят ли они буквально через кодовую базу в поисках каждой уязвимости в унаследованных системах людей? Я всегда предполагал, что это то, что они сделали, но кажется, что это было бы крайне ненадежно и не сделало бы намного больше, чем ложное чувство безопасности. Примечание: я не говорю о программистах, которые пишут алгоритмы шифрования или что-то в этом роде, а только о тех, кто занимается аудитом / консалтингом по безопасности программного обеспечения.
источник
Ответы:
Откровенно говоря, мы стараемся не проходить через вашу кодовую базу, мы пытаемся написать инструменты, чтобы сделать это для нас.
Во-первых, теория. Безопасность - это требование к программной системе, поэтому, как и другие требования (функциональность, удобство использования, доступность, производительность и т. Д.), Ее следует учитывать на каждом этапе рабочего процесса разработки программного обеспечения - от сбора требований до развертывания и обслуживания. Действительно, это возможно, и существует руководство, чтобы помочь командам разработчиков программного обеспечения сделать это. Несмотря на то, что я в основном работаю с разработчиками iOS, мое любимое описание «жизненного цикла безопасной разработки» взято из Microsoft Press .
В этой модели безопасность приложений начинается, когда мы пытаемся получить требования от наших пользователей. Нам нужно выяснить их проблемы с безопасностью и конфиденциальностью, что непросто, потому что мы эксперты, а не пользователи, и там, где они понимают свои требования безопасности, им может быть трудно их выразить. Нам также необходимо выяснить, каким рискам будет подвержено программное обеспечение при развертывании и какой уровень риска является приемлемым.
Мы разрабатываем наше приложение с учетом этих требований. Мы пишем код с целью удовлетворения этих требований и избежания дополнительных рисков, связанных с ошибками безопасности на уровне кода. Мы тестируем программное обеспечение, чтобы убедиться, что наша модель его безопасности соответствует тому, что мы действительно создали, а затем мы внедряем программное обеспечение таким образом, чтобы соответствовать предположениям, которые мы сделали в отношении среды, когда создавали эту вещь. Наконец, мы предоставляем поддержку и обслуживание, которые помогают пользователю использовать программное обеспечение в соответствии с их требованиями безопасности и позволяют им (и нам) реагировать на новые изменения в представленных рисках.
Хорошо, так много для теории. На практике , по причинам, которые очень хорошо объяснены (хотя и не технически) в Geekonomics и которые в основном связаны с тем, как компании-разработчики мотивированы, большинство из вышеперечисленных вещей не происходит. Вместо этого мы получаем это. Разработчики будут:
То, что на самом деле делает большинство специалистов по безопасности приложений, это, как вы говорите, поиск ошибок. Это действительно прославленная проверка кода, но это очень сфокусированная проверка кода, выполненная людьми, которые являются экспертами в тех ошибках, которые ищет этот обзор, поэтому все еще есть ценность в получении внешней помощи в этом. Конечно, это общее правило: всегда приглашайте кого-нибудь еще проверить, кто не был вовлечен в создание вещи.
Если мы примем вышеизложенное как истинное, то из этого следует, что люди, принимающие решения о покупке, скорее всего приравнивают «способного охранника» к «находит много ошибок». Те, кто заставляет компьютеры выполнять работу за них, найдут больше ошибок, чем те, кто этого не делает, поэтому, конечно, они в значительной степени полагаются на инструменты статического анализа и будут стремиться тратить больше времени на расширение инструментов, чем на кодирование конкретных проблем для конкретных клиентов. Затем мы заключаем, что специалисты по безопасности приложений с большей вероятностью пишут инструменты для чтения кода, чем для чтения кода.
** Предупреждение: остается только личное мнение и спекуляция **
Реальность сломана. Вы заметите, что теория безопасности программного обеспечения заключалась в определении и реагировании на риск использования программной системы, в то время как практика заключалась в том, чтобы находить как можно больше ошибок. Несомненно, это все еще уменьшит риск, но только как побочный эффект. Суть игры стала менее важной, чем «победа», поэтому правила изменены, чтобы было легче выиграть.
Что вы можете как разработчик программного обеспечения сделать с этим? Играйте в игру по оригинальным правилам. Найдите в своей команде кого-то (желательно на самом деле в вашей команде, а не подрядчика, чтобы он был заинтересован в достижении долгосрочных результатов, а не в быстрой победе), который понимает важность безопасности и обучает у них бежевцев. Дайте этому человеку ответственность за руководство группой в обеспечении сквозной безопасности, описанной в начале моего ответа.
Кроме того, дайте этому человеку полномочия следовать . Если дизайн не выражает требования безопасности, он должен быть пересмотрен. Если реализация не соответствует требованиям безопасности, она не должна быть выпущена . Ваш сотрудник по безопасности может сделать вызов, но ему должно быть разрешено действовать в соответствии с этим решением. Я понимаю, что это может звучать так, будто парень из службы безопасности говорит: «Безопасность OMFG - это самое важное», но я не это имею в виду. Если ваш продукт не соответствует требованиям к функциональности, удобству использования или производительности, вы также не должны выпускать эту вещь.
Почему вы хотите это сделать? Это должно быть дешевле: мы все видели (и, вероятно, цитировали за дешевую +10 репутацию) таблицу Code Complete, где дефекты становятся дороже, чем позже вы их исправляете, верно? Ну и дефекты безопасности тоже дефекты. В реальных правилах игры большинство из них - это проблемы в требованиях, которые зафиксированы в обслуживании. Это дешево?
Хорошо, теперь, что я могу сделать в качестве охранника? Что ж, получается, что я тоже могу отказаться от игры по измененным правилам. Я могу сказать разработчикам, что это все о снижении риска, что это может быть сделано на каждом этапе, и тогда я могу помочь им сделать это.
источник
Из 15 лет работы программ обеспечения безопасности для небольших и чрезвычайно больших приложений, сред, систем и т. Д. Я бы сказал, что есть всего понемногу. В моих командах всегда было несколько хардкорных программистов.
На детальном уровне некоторые из них сводятся к очень глубокому анализу кода - в качестве примера я сейчас работаю над многомиллионной строкой кода, использую инструменты для сужения возможных проблем, а затем рассматриваю каждый из них, чтобы классифицировать.
(По общему признанию я тогда передаю разработчикам, чтобы исправить или объяснить мне, почему проблема не представляет риск)
Но это конкретное мероприятие, для которого профиль риска имеет смысл проводить такого рода ресурсоемкую работу.
Гораздо более стандартным и гораздо более эффективным с точки зрения затрат является попытка понять профиль рисков организации и сосредоточиться на рисках сверху вниз, например:
Со стороны программирования действительно только в последние два, с обзором кода и пользовательского тестирования проникновения. Для некоторых организаций это имеет очень низкое значение, например, если у вас есть многоуровневые элементы управления безопасностью, которые уже были тщательно проверены (например, различные типы шифрования), тогда, хотя вы можете проверить свою реализацию, вы обычно не собираетесь перепроверять все код, как это было сделано ранее.
источник
Я никогда не сталкивался с тем, что идет намного дальше, чем обсуждение неясного подхода к архитектуре / передовым методам во время проектирования и / или запуск комплектов тестирования атак / фриттов / исключений для готовых проектов.
Почти во всех случаях я даже могу сказать, какие инструменты они используют по векторам атаки, которые они пробуют, и то, как осуществляется атака после того, как один из аудитов проходит в существующей системе.
Я полагаю, что есть некоторые, которые на самом деле занимают время, чтобы исследовать код и провести некоторое тестирование / тестирование белого ящика, но я еще не сталкивался с ними в реальной жизни.
источник