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

Вопрос к руководителям проектов. Какие ответы вы сочли бы удовлетворительными, а какие — нет?

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

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

Легко. Верхняя -- 100. Нижняя -- 0. А вот за ради матожидания это да -- надо бы было подумать.

N>Вопрос к руководителям проектов. Какие ответы вы сочли бы удовлетворительными, а какие — нет?

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

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

N_>Легко. Верхняя -- 100.

Ты хочешь сказать, что ты не уверен, что вероятность взлома в течение месяца системы, за безопасность которой ты отвечаешь, меньше 99%?

N_>А вот за ради матожидания это да -- надо бы было подумать.

Матожидания какой величины?

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

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

N>Вопрос к руководителям проектов. Какие ответы вы сочли бы удовлетворительными, а какие — нет?

Лично я бы не удивился ответу 50/50 — т.е. "или сломают или не сломают".

Эта оценка в численном выражении имела бы смысл, если по ней была бы статистика.
Вероятность, она знаете ли, либо основана на статистике либо она 50 на 50.

К примеру, можно взять дефолтную WinXP, взять дефолтного админа,
поставить дефолтную конфигурацию, чью-нибудь статистику взломов за продолжительное время,
и по ней посчитать вероятность.
Вся проблема в том, что полученная таким образом цифра будет иметь практическую ценность
эквивалентную 50/50, т.е. никакую.
Так как любой самый незначительный неучтенный фактор может менять всю картину с точностью до наоборот.

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

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

N>Вопрос к руководителям проектов. Какие ответы вы сочли бы удовлетворительными, а какие — нет?

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

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

Если ИБшник привлекается к проекту на стадии, когда продукт уже близок к релизу (либо в продуктиве), то такую оценку также можно вывести на основе результатов тестов на проникновение, аудитов процесса разработки, архитектуры и кода проекта и т.п. Разница с предыдущим примером только в том, что стоит это примерно столько же (если не больше), но при этом является актуальным только на момент работы ИБшника. Т.е. с первым же коммитом после всех аудитов и оценок все может измениться как в худшую, так и в лучшую сторону.

Короче говоря, и в том и в другом случае, ответ дать вполне возможно, причем стоить это будет примерно одинаково, поэтому (коль скоро возник вопрос об обеспечении безопасности продукта) лучше "внедрять" ИБшник(а|ов) в проект на ранних стадиях и на постоянной основе, а не прибегать к услугам "консультантов по ИБ" от случая к случаю.

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

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

N>Вопрос к руководителям проектов. Какие ответы вы сочли бы удовлетворительными, а какие — нет?

Или речь идет о безопасности внутренней ИТ-инфраструктуры, не имеющей прямого отношения к какому-либо проекту?

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

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

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

Представтьте, что ваш шеф вызывает вас и просить назвать число — верхнюю границу для вероятности того, что в течение ближайшего месяца хакеры взломают вашу систему и получат права администратора, если за взлом обещан автомобиль "Калина" (вилла на островах, шанс прожить дольше месяца, прочее)

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

KV>Я правильно понимаю, что под "взламываемой системой" подразумевается тот самый "проект", к руководителям которого адресован второй вопрос? А под "спецом по компьютерной безопасности" подразумевается все же специалист по информационной безопасности, привлеченный в проект наряду с остальными участниками, с самого начала проекта?

Да, правильно.

KV>Просто постановка вопроса странная. Если в проекте есть ИБшник, то ответ на этот вопрос он должен был дать еще до непосредственной разработки системы (на этапе анализа угроз и оценки рисков по ИБ) для выработки контрмер и стратегии проекта по части минимизации выявленных рисков по ИБ. А в дальнейшем актуализировать эти оценки по мере проведения как ревью кода, так и аудитов процесса разработки.

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

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

S>Полный вопрос должен выглядеть так:

S>Представтьте, что ваш шеф вызывает вас и просить назвать число — верхнюю границу для вероятности того, что в течение ближайшего месяца хакеры взломают вашу систему и получат права администратора, если за взлом обещан автомобиль "Калина" (вилла на островах, шанс прожить дольше месяца, прочее)

Осталось только найти норму этой функции (в пространстве L²), и получится мат. ожидание стоимости взлома системы. Это и есть (единственный) параметр, от которого всё зависит. Его можно сравнить с прибылью, которую можно извлечь в результате успешного взлома, например.

Здравствуйте, nikov, Вы писали:
N>>>Вопрос к спецам по компьютерной безопасности. Представтьте, что ваш шеф вызывает вас и просить назвать число — верхнюю границу для вероятности того, что в течение ближайшего месяца хакеры взломают вашу систему и получат права администратора. Смогли бы вы дать ответ на такой вопрос?

N_>>Легко. Верхняя -- 100.

N>Ты хочешь сказать, что ты не уверен, что вероятность взлома в течение месяца системы, за безопасность которой ты отвечаешь, меньше 99%?

А вы всё ещё верите в абсолютно защищенные системы? Однако, помнится, даже в топ-менеджмент ЦРУ шпионы проникали.
Речь идёт о верхней границе. Верхняя -- 100. Если вложат достаточную сумму денег, то сломают любую защиту.

N_>>А вот за ради матожидания это да -- надо бы было подумать.

N>Матожидания какой величины?

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

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

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

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

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

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

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

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

N>Смогли бы вы дать ответ на такой вопрос?

Легко! 42%!

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

KV>[... .... ....]Зато после этого, у гипотетического "шефа" будет возможность получать оценку защищенности продукта регулярно, без каких-либо дополнительных тестов и аудитов

Слушай, относись к вещам проще: никого на самом деле не интересуют цифы вероятности взлома. Наукообразие — наш рулевой. Пойми простую вещь: пиплу скучно. Что хацкерам, что нечальнегам. Вот они и развлекаются. Я бы и рад узнать рецепты лечения этой болезни... Но, видимо, моя параецельсткость не дотягивает до нужной планки!

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

N>Вопрос к спецам по компьютерной безопасности. Представтьте, что ваш шеф вызывает вас и просить назвать число — верхнюю границу для вероятности того, что в течение ближайшего месяца хакеры взломают вашу систему и получат права администратора. Смогли бы вы дать ответ на такой вопрос?
Подходишь к серверу, выдёргиваешь шнур и смело говоришь, что вероятность сетевого взлома — 0%.

N>Вопрос к руководителям проектов. Какие ответы вы сочли бы удовлетворительными, а какие — нет?
Удовлетворил бы отчёт об истории уязвимостей смотрящего наружу софта, с экстраполяцией на следующие пару месяцев.

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

ГВ>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>[... .... ....]Зато после этого, у гипотетического "шефа" будет возможность получать оценку защищенности продукта регулярно, без каких-либо дополнительных тестов и аудитов

ГВ>Слушай, относись к вещам проще:

Да куда уж проще-то? Вот если бы nikov про защищенность ИТ-инфраструктуры в целом спросил...

ГВ>никого на самом деле не интересуют цифы вероятности взлома.

Угу. Расскажи это западным инвесторам с их задвигами по поводу достоверности финансовой отчетности (2google: "SOX 404") Хинт: им эти цифры нужны ежегодно, и если они будут меньше некоторого порога, то акции конторы снимаются с оборота на NYSE.

ГВ>Наукообразие — наш рулевой. Пойми простую вещь: пиплу скучно. Что хацкерам, что нечальнегам. Вот они и развлекаются. Я бы и рад узнать рецепты лечения этой болезни...

Когда скучающему начальнегу говоришь, что с вероятностью 90% процентов контора понесет убыток в размере (минимум) суточной прибыли с одного сервера, обслуживающего SMS на короткие номера, да еще и отдаешь ему отчет, где показано, что эти цифры взяты не с потолка... Скука куда-то улетучивается быстрее, чем ты успеваешь закончить фразу. Я проверял

ГВ>Но, видимо, моя параецельсткость не дотягивает до нужной планки!

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

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

N>>Вопрос к спецам по компьютерной безопасности. Представтьте, что ваш шеф вызывает вас и просить назвать число — верхнюю границу для вероятности того, что в течение ближайшего месяца хакеры взломают вашу систему и получат права администратора. Смогли бы вы дать ответ на такой вопрос?
C>Подходишь к серверу, выдёргиваешь шнур и смело говоришь, что вероятность сетевого взлома — 0%.

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

N>>Вопрос к руководителям проектов. Какие ответы вы сочли бы удовлетворительными, а какие — нет?
C>Удовлетворил бы отчёт об истории уязвимостей смотрящего наружу софта, с экстраполяцией на следующие пару месяцев.

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

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

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

N>Ты хочешь сказать, что ты не уверен, что вероятность взлома в течение месяца системы, за безопасность которой ты отвечаешь, меньше 99%?

Что такое 99%? 99 из 100 попыток? 99% времени во взломанном состоянии? 99% известных уязвимостей из всех? 99% их всех мировых хакеров, кому удастся?

Понятие «вероятность» применимо только к повторяемым событиям, которые можно 100 раз повторить, и сказать — процент такой-то. У единичных, и уж тем более у гипотетических событий (встретить динозавра) нет никакой вероятности.

На тупые вопросы надо давать научно-популярные ответы, вроде: 1%, один из миллиарда, 50/50 — либо случится, либо нет, ниже чем вероятность падения метеорита на сервер, и т.п. Либо читать лекцию

Здравствуйте, Кодёнок, Вы писали:

Кё>Понятие «вероятность» применимо только к повторяемым событиям, которые можно 100 раз повторить, и сказать — процент такой-то. У единичных, и уж тем более у гипотетических событий (встретить динозавра) нет никакой вероятности.

Никогда не встречал оценки вероятности катастроф? Например, оценку вероятности катастрофы на БАК?

Probability interpretations

Evidential probability, also called Bayesian probability, can be assigned to any statement whatsoever, even when no random process is involved

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

KV>Когда скучающему начальнегу говоришь, что с вероятностью 90% процентов контора понесет убыток в размере (минимум) суточной прибыли с одного сервера, обслуживающего SMS на короткие номера, да еще и отдаешь ему отчет, где показано, что эти цифры взяты не с потолка... Скука куда-то улетучивается быстрее, чем ты успеваешь закончить фразу. Я проверял

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

Здравствуйте, kochetkov.vladimir.

А на русском в инете что-нибудь есть по безопасности? Учебники там какие-нибудь?