Как стать автором
Обновить

Как оценивать технический риск ИБ при разработке приложений

Уровень сложностиПростой
Время на прочтение9 мин
Количество просмотров2.4K
Всего голосов 2: ↑2 и ↓0+2
Комментарии2

Комментарии 2

А как вы вообще взаимодействуйте с информацией, которую получаете на графиках, как доносите проблемы до менеджмента, что "циферки показывают тут не очень"? Предположим я сделал анализ приложения и увидел что у меня "все плохо", как понять где плохо и с чего начать копать?
Спасибо за статью!

У нас, как у вендора ПО, хорошо работают требования клиентов - нельзя эксплуатировать в ПРОМ ПО содержащее критические уязвимости. Поэтому тут всё однозначно.

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

Иногда работает самое банальное - ТОП уязвимых или неуязвимых систем (по STD или WRI). Делаете рейтинг и рассылаете на регулярной основе заинтересованным лица - для информации. Со временем начинает работать спортивный принцип: почему наша система хуже (ниже или выше в рейтинге), чем у Петрова?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий