Измеряем безопасность вашего ПО

Рассказывает Фил Зито, автор блога «Building Automation Monthly»

Вы уверены, что ваше ПО безопасно?

Как измерить его безопасность?

Эти вопросы в наше время волнуют все IT-сообщество — каждый день возникает какая-то новая дыра, угроза, баг. Кроме того, разработчиков просят писать все более сложные, комплексные программы и делать это быстрее конкурентов, что, конечно, отрицательно сказывается на качестве кода.

Особенно это актуально для стремительно развивающейся сферы интернета вещей, куда стремятся как и крупные компании, так и мелкие старт-апы. И все они сталкиваются с одними и теми же проблемами: отсутствие каких-либо общепринятых стандартов и огромный поток данных.

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

Каковы угрозы?

Для того, чтобы найти угрозы, вам нужна модель. Как ни странно, модели, которые существуют для нахождения угроз, называются… барабанную дробь, пожалуйста… модели угроз! Гениально!

В данный момент существует несколько моделей угроз. О них существует множество информации, в том числе и работы Microsoft, OWASP и San’s.

Но как их использовать? Вот здесь находится отличная презентация на эту тему, созданная Microsoft и посвященная использованию модели STRIDE, раскрывающая многие детали касательно моделирования угроз.

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

• Топ-25 программных ошибок, составленный CWE/SAN;
• Топ-10 угроз безопасности веб-приложениям, составленный OWASP.

Как только вы поймете, как эти угрозы работают, вы сможете смоделировать ваше приложение и понять, если в нем дыры в безопасности. Например, Угроза А-1 в топе, составленном OWASP, — это инъекция. Зная это, вы строите модель вашей базы данных, всех ее источников и пользователей. Как только это сделано, необходимо лишь взглянуть на каждую из «границ доверия».

«Граница доверия» — это место в приложении, где злоумышленник может вмешаться в процесс или поток данных. В нашем случае это HTML-форма, в которую вводятся данные, поступающие в БД SQL. Лучше убедиться, что вы используете подготовленные данные для БД. «Подготовленные данные» — это данные, которые заранее структурированы таким образом, чтобы облегчить их обработку и дальнейшее использование и исключить любой риск для безопасности приложения. Очевидно, что данные должны подготавливаться до их поступления в БД.

Хорошо, теперь вы умеете моделировать ваш сценарий использования, поток данных и «границы доверия». Теперь необходимо попробовать применить к модели все возможные уязвимости, существующие для вашего сценария использования. Заметьте, что существуют автоматические инструменты, проверяющие наличие таких угроз, как CWE-120 (копирование буферов без проверки длин строк).

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

1. Обеспечение безопасности — это не магия (в большинстве случаев).
2. Есть несколько принципов, и следуя им, вы будете лучше большинства компаний, которые занимаются разработкой ПО. Да, на самом деле.

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

Как они нас достигают?

Итак, о том, как угрозы вас настигают. Существует концепция, называемая «поверхность атаки». «Поверхность атаки» — это та часть приложения, через которую злоумышленник может осуществить атаку. Время для реально плохой аналогии…

Я живу в Висконсине, и тут куча москитов. Москиты — это плохо, и если я хочу защититься от их атак, то надеваю длинные штаны, рубашку с длинными рукавами и обрызгиваюсь репеллентом. Защита вашей поверхности атаки — это, по сути, то же самое.

«Поверхность атаки», согласно модели OSI, делится на семь слоев:

• Слой 1 (физический) — физический доступ к системе.
• Слой 2 (канальный) — DoS с помощью разрушения сети, подмена маршрутизатора.
• Слой 3 (сетевой) — перехват трафика.
• Слой 4 (транспортный) — TCP-атаки, изменение передаваемых данных.
• Слой 5 (сеансовый) — «угон» сеанса связи.
• Слой 6 (представительский) — переполнение буфера с помощью манипулирования потоком данных, перехват данных, вводимых пользователями.
• Слой 7 (прикладной) — бэкдоры, баги, небезопасные участки приложения.

Как видите, существует множество способов проникнуть в систему. Это один из моих любимых способов оценивания безопасности вашего ПО. Если ваше приложение обеспечивает работу сетей, то больше внимания следует отдавать сетевым уязвимостям, если же оно прикладное — то стоит смотреть на уровни 6–7. Просматривая поверхность атаки вашего приложения и поддерживающие его подсистемы, вы выявите все возможные дыры в безопасности.

Как мне быть в курсе положения дел?

Главное в кибер-безопасности — это то, что приходится постоянно учиться. Ситуация меняется каждую секунду — перекомпилировать эксплойт так, чтобы его сигнатура прошла антивирус, ничего не стоит. Так как быть в курсе последних событий? Ну, вы читаете эту статью — уже хорошо!

Ниже приведен список сайтов, которые необходимо регулярно посещать, чтобы оставаться информированным:

• ICS-CERT;
• US-CERT;
• Национальная база уязвимостей;
• Exploit-DB.

Реальная жизнь — это не обучение в университете, и никто в ней вам сам знания не даст, необходимо проводить исследование самому. Лично я чувствую себя оскорбленным, если кто-то превосходит меня, особенно если это злоумышленник. Поймите, что в странах третьего мира сидит множество людей, которым буквально нечего делать, кроме как искать эксплойты в вашей системе.

Вы обманываете себя, если думаете, что можете небрежно относиться к безопасности приложения, думая, что последствия этого никогда не проявятся.

Заключение

Почему я написал эту статью на сайте, посвященном интернету вещей? Ваши системы будут доступны с настольных компьютеров, с телефонов… из ОБЛАКА (божественный голос). И когда вы сцепляете все это вместе, обязательно появляются угрозы для безопасности, необходимо их понимать и устранять.

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

Перевод статьи «How to measure security of your software»