Home

Автор: Коллин Грин (Collin Greene)

Оригинал статьи: https://medium.com/@collingreene/why-product-security-is-hard-52e3f73178#.l1376jjjv

Перевод: Ольга Алифанова

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

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

Создание ПО – тяжелая работа

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

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

Мы знаем, что создать идеальное ПО возможно, но это очень трудно, и зачастую не в приоритете. Nasa и марсоход "Curiosity" – это пример оптимизированного соотношения качества к нулевому количеству багов, потому что стоимость бага в ПО крайне высока.

Неизвестное неизвестное

Тестирование демонстрирует присутствие, а не отсутствие багов

- Дийкстра, отчет 1969 года.

Если бы мы заранее знали все уязвимости, которые мы ищем, не было бы никакого смысла их искать.

Количество уязвимостей в 100000 строках кода, из которых состоит сервис $foo, заранее не известно. Вселенная не дает нам точной цифры вроде "вы нашли 16 из 27 багов, продолжайте поиски!"

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

Отсутствие доказательств – это не доказательство отсутствия.

Потенциальные недостатки этого моста неизвестны, пока мы не начнем их искать.

Противоречия

Даже процесс измерения полного набора багов, которые может найти в определенном коде человек, различается в зависимости от того, кто их ищет, как, и что они ели на завтрак.

Я проводил опыт в Фейсбуке – 10 компаний, консультирующих по безопасности, проводили аудит одного и того же кода. Код, аудит которого уже был тщательно проведен моей командой. Все десять компаний нашли одинаковый список поверхностных багов (около половины), но все остальные найденные ими баги различались, включая и те, о которых мы сами не знали. Каждый человек привносит в поиск багов свой опыт поисков багов безопасности. Сравните это с чем-либо вроде производительности (другой атрибут качества ПО), где измерение прогресса – дело простое и обычное.

Противоречивость – другой способ поговорить о вероятностях. Как и поиск золотого песка, поиск багов безопасности включает трату сил на вероятность, а не на обещание, находки.

Оппозиция

Мы не всегда знаем, кто наши конкуренты.

И слова, что нации активно пытаются ломать ПО конкурентов, не так уж далеки от истины.

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

Удельный вес

Правильно определить серьезность уязвимости довольно тяжело. На работе мы дискутируем по этому поводу ежедневно, когда обсуждаем награды за найденные баги. Стоит ли один действительно отличный баг, который приводит к захвату чужой учетки, десяти менее критичных багов? Ста? Двум инженерам по безопасности тяжко прийти к общему времени, но вложения времени – это необходимое условие того, чтобы безопасность была на высоте. Мы пришли к выводу, что лучшая система оценки критичности багов – это CVSS.

Ограничения

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

Временные рамки

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

Обсудить в форуме