Здравствуйте, nikov, Вы писали:

N>Ну, допустим, шеф почему-то не спрашивал раньше конкретных чисел, а тут заинтересовался. Интересно, какие же есть методики для оценки этой вероятности, и как определисть, какой уровень является приемлемым?

Ну, наиболее наглядная и быстрая методика из числа таких "срезовых" оценок — это blackbox-тест на проникновение (пентест), в ходе которого иммитируются возможные действия атакующего по реализации тех или иных информационных угроз, список которых определяется на этапе формирования требований к результатам теста (за основу берется, как правило STRIDE). Т.е. пытаемся взломать нашу же систему, основываясь лишь на той информации, которой может обладать атакующий. Все выявленные уязвимости ранжируются по вероятности и сложности их эксплуатации, типу, потенциальному ущербу и т.п. (подробнее — гуглить и википедить про STRIDE и DREAD, вкратце, там правда о другом процессе, но применимо и к результатам пентестов, есть тут: http://msdn.microsoft.com/en-us/library/aa302419.aspx). После чего, руководством (или ответственными за этот процесс людьми) принимаются решения о необходимости и целесообразности принятия контрмер по каждой из них, на основании отношения возможного ущерба, вызыванного реализацией каждой из выявленных угроз, к совокупной стоимости устранения этой угрозы в продукте.

Понятно, что достоверность такой оценки зависит от квалификации пентестера, и если она окажется ниже чем у реального атакующего, то оценка не будет достоверной. Повысить эффективность такого тестирования можно, если озадачить им несколько спецов (хотя бы двух), причем использующих различные методики и инструменты. В нашей конторе она используется при приемке у подрядчиков разработанного ими для нас ПО (в основном, веб-приложений, но бывали и исключения) либо при оценке систем приобретенных компаний, перед началом их интеграции с нашими системами. Собственно, около 30-40% рабочего времени сейчас у меня уходит именно на такие тесты в связи с недавним приобретением нами парочки провайдеров проводной и магистральной связи

Использовать какие-либо другие методики для "срезовых" оценок, лично мне представляется пустой тратой ресурсов в случае, если они не интегрированы в сам процесс разаботки на регулярной основе. Можно провести секьюрити-ревью кода продукта, построить модель угроз, провести по ней оценку рисков, наложить на нее результаты ревью, провести аудит процесса внесения изменений в продукт и т.п. Но если обеспечение безопасности создаваемого продукта не интегрировано в процесс его разработки, то толку от этого будет мало, т.к. (как я уже написал выше) любой последующий коммит, приход в команду нового члена, даже минимальное изменение НФТ и ФТ, и т.п. может поломать всю эту оценку, либо сделать ее недостоверной.

Поэтому существуют методики организации полного цикла разработки безопасного ПО. Из наиболее полных и распространенных, это ваш (кстати ) SDL и рекомендации OWASP. И то и другое, применимо к большинству существующих методик управления программными проектами. И то и другое, возможно внедрить в процесс разработки ПО на этапах, отличных от начала проекта. Правда это существенно сложнее, но все же возможно, живые подтверждения тому видел сам, в одном даже принимал участие. Зато после этого, у гипотетического "шефа" будет возможность получать оценку защищенности продукта регулярно, без каких-либо дополнительных тестов и аудитов