Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, AShirmanov, Вы писали:
AS>>таблицу деактуализации угроз,
KV>Угрозу можно либо устранить, либо минимизировать связанные с ней риски. Сделать ее менее актуальной (деактуализировать), это то же самое, что уговорить бизнес, что ущерб, связанный с ней, его не должен волновать 
Думаю произошло просто небольшое терминологическое расхождение. Я имел в виду "деактуализация угроз" — как процесс, в ходе которого разработчик описывает каким образом угроза перестает быть актуальной для защищаемой системы. С бизнесом здесь нужно обсуждать только стоимость и уместность предлагаемых мер. Например, угрозу удаленной атаки переполнения буфера в приложении можно деакутализировать через настройку сетевого IPS, который, скажем, уже куплен и стоит на периметре у заказчика. В этом случае можно не проводить анализ кода своего приложения на наличие уязвимостей типа переполнение буфера, что снижает стоимость защитных мер. (Это фантазийный пример просто для иллюстрации — я не призываю оставлять код с уязвимостями
). И т.д. по всем выявленным угрозам должны приводится либо организационные меры (замок на двери серверной), программные механизмы самого приложения, иные технические меры (безопасная конфигурация сети, инсталляция защитных продуктов типа антивирусов IPS и т.д.)
KV>"думаю, что Синклера не интересуют программисты" == "думаю, что Синклера не интересуют безопасники", опечатался. В общем-то, и для программиста зачастую не владеть несколькими языками на таком уровне — признак недостатка опыта, хотя и не всегда. Безопасник же, в чьи обязанности входит работа с кодом, обязан знать все языки с которыми ему предстоит работать, причем на довольно высоком уровне. Либо должно быть несколько безопасников.
Может, я неверно понял ТС, но им требовался довольно конкретный труд: оценка API, которые выдают 3rd parties, на предмет безопасности. Я даже не уверен, что речь идет о реализации этого API, — возможно, необходимо оценивать лишь интерфейс.
SD>>Что ж тут непонятного? Владельцам сервера может быть совершенно некритична утрата достоверности механизма аутентификации.
KV>Тогда зачем этот механизм реализовывали и тратили время разработчиков? 
Очень просто: вероятность использования этой уязвимости и потенциальный вред от этого действия обойдется дешевле, чем устранение уязвимости. Проще говоря, дешевле потерять админку к RSDN, чем купить SSL-сертификат (мы берем пачками по $53 в год — надо думать, админка от RSDN дешевле).
KV>В Билайне, один такой менеджер однажды отправился искать другую работу. Именно по причине подобного волевого решения. По-всякому бывает 
Это одно из тех редких исключений, которое только подтверждает общее правило (а именно, наплевательское отношение к безопасности в целом и к безопасности клиентской части в особенности). Допускаю, что в некоторых более зрелых компаниях ситуация в этом отношении лучше. Но если в компании уже много лет не могут начать доверять собственным инженерам (в т.ч. безопасникам), то — сомнительно мне, что будут безопасника слушать. Коли уж заранее задаются вопросом "а не тролль ли он".
KV>Меня пугает любой сервер, включенный в любую сеть. Вопрос только в степени паранойи 
Согласен. Однако, некоторые порты (тот же DNS) пугают меньше — протокол открыт, проще сам по себе и лучше изучен (в отличие от проприетарного msrpc).
KV>Ага, а knocking sequence выбирать криптографически-стойкую, да 
Проще всего поднять там RRAS и пускать на сервер по RDP только из виртуальной сети. Но есть причины, связанные с текущим провайдером, по которым это (и порт-нокинг и впн) реализовать нереально.
RRAS (и вообще любой вариант специализированного access point для внутреннего периметра) это наиболее правильное решение, но, как мне кажется, и более дорогостоящее. В этом плане мне импонирует подход Microsoft c Exchange Server, где тот же CAS всегда является отдельным сервером (хотя эту роль и можно влепить в т.ч. и рядом с остальными ролями, но будет ругаться analyzer).
KV>А вот, если кто-нибудь украдет аккаунт администратора сайта... <...> А это — нагрузка на сервер и прямой путь к DDoS-условиям, что в рамках RSDN куда более вероятная угроза, чем man-in-the-middle на администратора сайта.
Собственно, примерно этими соображениями я и руководствовался выше.
В принципе, будь у меня много лишнего времени, можно было бы взглянуть и на сайт, CMS, движок форума. Поскольку они самописные, скорее всего, описания уязвимостей (как для того же phpbb) вряд ли где выложены и классифицированы. То есть искать придется вручную, самостоятельно. Но при этом, опять же, в силу проприетарности движка, уверен, их (уязвимостей) там больше, чем в открытых или коммерческих продуктах сравнимого уровня функциональности.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>5. Задать вопрос, что он знает про этап вывода из эксплуатации, какие меры должны быть предприняты на остальных этапах, чтобы снизить риски уязвимостей на этом (это реально коварный вопрос, если ответит — брать не раздумывая).
Мне ничего кроме подмены (фишинг) выведенной из эксплуатации системы в надежде перехват данных от невыведенных из эксплуатации механизмов интеграции с другими системами ничего в голову не пришло. Есть что почитатьна тему?
