Добрый день, Володя!

Во-первых, долг платежом красен. Ты мне некий промоушно сделал, отвечаю тем же

Но не ради этого я новый топик начал, конечно.

Вопрос мой такой, к тебе как специалисту, ну и ко всем остальным тоже.

Какую плату следует уплатить за обеспечение безопасности ?

Ведь безопасность — не только в мире ИТ. Она во многих отраслях есть, но нигде ее не добиваются любой ценой. Всегда ищут некий компромисс между безопасностью и ценой.

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

А можно сделать автомобили, которые были бы побезопаснее ? Конечно, можно. Да и сделали уже давно — БТР называются. Только что-то на них по городам обычно не ездят.

И автомобиль, который пешеходов давить не будет, тоже можно сделать. Опыт есть. Когда сто с лишним лет назад в Лондоне появились автобусы и несколько человек под них попали, муниципалитет (или как он там называется) Лондона принял решение — перед каждым автобусом должен идти человек с флагом и тем самым предупреждать пешеходов о том, какое страшное чудовище на них надвигается. И точно, наезды исчезли. Только вот что-то этот опыт недолго продержался

Конечно, можно сказать, что мои аргументы некорректны. В не-ИТ областях приходится очень дорого платить за безопасное решение, вплоть до неприемлемой цены. В ИТ создается впечатление, что безопасное решение стоит не намного больше, чем опасное — напишите код корректно, и не будет уязвимостей.

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

Вот, кстати, твой пример с пайпами. Там ошибка. Ее надо исправить, и все, и ее исправят. Но ты хочешь, чтобы ее не было изначально, поэтому готов на введение туда управляемого кода (я не обсуждаю технической возможности делать это в ядре ОС). Я не хочу в N-й раз доказывать. что управляемый код будет медленнее. Примем это на минуту как некий постулат, исключительно для данного момента. Так вот, готов ты заплатить за этот потенциально безопасный код, если быстродействие упадет в 1.1 раза ? В 1.5 раза ? В 2 раза ?

И другой пример. Безопасность ядерного ректора — любой ценой. Безопасность банковских операций — ИМХО уже не любой, а только если цена будет ниже возможного ущерба. А вот безопасность сайта заборостроительной компании ?

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

PD>Добрый день, Володя!

PD>Во-первых, долг платежом красен. Ты мне некий промоушно сделал, отвечаю тем же

PD>Но не ради этого я новый топик начал, конечно.

PD>Вопрос мой такой, к тебе как специалисту, ну и ко всем остальным тоже.

PD>Какую плату следует уплатить за обеспечение безопасности ?

PD>Ведь безопасность — не только в мире ИТ. Она во многих отраслях есть, но нигде ее не добиваются любой ценой. Всегда ищут некий компромисс между безопасностью и ценой.

PD>Например, автомобиль — штука небезопасная. При столкновении двух автомобилей дело обычно плохо. Да и при наезде его на пешехода тоже.

PD>А можно сделать автомобили, которые были бы побезопаснее ? Конечно, можно. Да и сделали уже давно — БТР называются. Только что-то на них по городам обычно не ездят.

После этого даже читать не стал.
Угадай что будет при столкновении двух бэтэров на скорости 60 км в час? Что будет если БТР наедет на пешехода хотябы на скорости 10 км в час?

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

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

G>Угадай что будет при столкновении двух бэтэров на скорости 60 км в час? Что будет если БТР наедет на пешехода хотябы на скорости 10 км в час?

А ты еще одну строчку прочитай все же. Там написано. как в свое время обеспечили, чтобы не наезжали на пешехода

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

PD>Например, автомобиль — штука небезопасная. При столкновении двух автомобилей дело обычно плохо. Да и при наезде его на пешехода тоже.

Знаешь сколько средств вклдаывают в разработку средств для повышения безопасности автомобилей?

PD>А можно сделать автомобили, которые были бы побезопаснее ? Конечно, можно. Да и сделали уже давно — БТР называются. Только что-то на них по городам обычно не ездят.

Хочу видеть краштест, эмулирующий столкновение двух БТР на скорости около 60 км/ч, и эффект на водителя и пассажиров!
Я почему-то уверен, что сами БТР будут относительно целыми, а вот люди в них — в лучшем случае "почти как живые". БТР относительно безопасен только при столкновении с легким авто. В противном же случае — физику никто не отменял и отсутствие деформации кузова приведет к повышенной деформации пассажиров.

PD>И автомобиль, который пешеходов давить не будет, тоже можно сделать. Опыт есть. Когда сто с лишним лет назад в Лондоне появились автобусы и несколько человек под них попали, муниципалитет (или как он там называется) Лондона принял решение — перед каждым автобусом должен идти человек с флагом и тем самым предупреждать пешеходов о том, какое страшное чудовище на них надвигается. И точно, наезды исчезли. Только вот что-то этот опыт недолго продержался

Что, часто давили людей с флагами?

Вряд ли большим спросом будет пользоваться транспорт двигающийся не быстрее пешехода. Ты удачно выбрал себе пример. Но есть и другие.

PD>Конечно, можно сказать, что мои аргументы некорректны. В не-ИТ областях приходится очень дорого платить за безопасное решение, вплоть до неприемлемой цены. В ИТ создается впечатление, что безопасное решение стоит не намного больше, чем опасное — напишите код корректно, и не будет уязвимостей.

Твои аргументы некорректны в том, что якобы в не-ИТ всегда безумно дорого надо платить за безопасность и потому, якобы, это никто не делает. Да, есть такие случаи. Но есть и масса других:
Например, банальные плакаты соблюдения техники безопасности и требования одевать очки когда работаешь на токарном станке. Безопасность токарного станка сразу увеличивается в разы, и без всякой супер-навороченной жутко дорогой системы отлова металлической стружки.

Или, например, требования ставить УЗО во всех жилых домах. При этом стоимость УЗО составляет очень небольшую часть от всей электрики, зато число ударов жителей током кардинально сокращается.

Или требование прокладывать в домах медную проводку. Да, она заметно дороже аллюминиевой, но на фоне общей стоимости дома — эта разница просто копейки. Зато число пожаров резко снижается.

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

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

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

G>>Угадай что будет при столкновении двух бэтэров на скорости 60 км в час? Что будет если БТР наедет на пешехода хотябы на скорости 10 км в час?

PD>А ты еще одну строчку прочитай все же. Там написано. как в свое время обеспечили, чтобы не наезжали на пешехода

Ну да, сделали скорость движения транспорта равной скорости движения пешехода. В ИТ это полностью аналогично неиспользованию компьютеров.

Любые преимущества повышают риски, обеспечение безопасности — уменьшение рисков. Можно конечно уменьшать риски путем уменьшения преимуществ (путь C++), но это идиотское решение. Можно уменьшать риски применяя новые технологические подходы (как в современных автомобилях). Почти все подходы имеют недостатки, тем не менее от этих подходов никто не отказывается.

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

F>Я почему-то уверен, что сами БТР будут относительно целыми, а вот люди в них — в лучшем случае "почти как живые". БТР относительно безопасен только при столкновении с легким авто.

Ну я примерно это и имел в виду. Не нравится БТР — танк возьми. .


PD>>И автомобиль, который пешеходов давить не будет, тоже можно сделать. Опыт есть. Когда сто с лишним лет назад в Лондоне появились автобусы и несколько человек под них попали, муниципалитет (или как он там называется) Лондона принял решение — перед каждым автобусом должен идти человек с флагом и тем самым предупреждать пешеходов о том, какое страшное чудовище на них надвигается. И точно, наезды исчезли. Только вот что-то этот опыт недолго продержался

F>Что, часто давили людей с флагами?



F>Твои аргументы некорректны в том, что якобы в не-ИТ всегда безумно дорого надо платить за безопасность и потому, якобы, это никто не делает.

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

F>И подобных примеров в не-ИТ масса — буквально делайте дело правильно, используйте накопленную статистику, и уязвимостей будет меньше.

Да бога ради, только при чем это все тут ? Я же ясно вопрос сформулировал — какую плату готовы заплатить. Ты приводишь примеры, когда можно очень дешево. OK, пусть так. Но не все решения дешевы (даже не в ИТ) Вот я просто и спрашиваю — сколько платить готовы. В ИТ, конечно.

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

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

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

D>Общее правило — стоимость защиты не должна превышать стоимости защищаемого объекта.

Не стоимости, а прибыльности
Защищаемый объект в голом виде может стоит и дешевле самой защиты, но в целом комплекс "объект+защита" должен оставаться прибыльным.

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

F>Не стоимости, а прибыльности
F>Защищаемый объект в голом виде может стоит и дешевле самой защиты, но в целом комплекс "объект+защита" должен оставаться прибыльным.

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

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

PD>Вопрос мой такой, к тебе как специалисту, ну и ко всем остальным тоже.
PD>Какую плату следует уплатить за обеспечение безопасности ?
PD>Я о другом хочу тебя спросить — как сейчас соизмеряют требования к безопасности с возможным ущербом и возможным ухудшением других потребительских качеств ? Есть такие расчеты, методики ? Можно ли на основании их (если они есть) сказать — а вот этой потенциальной угорозой безопасности можно пренебречь, если затраты на создание безопасного решения больше чем N ? Или же принцип только один — давай безопасность любой ценой, всякая уязвимость должна быть ликвидирована, чего бы это ни стоило ?

У меня, к сожалению, в последние дни совершенно не хватает времени еще и на участие в местных топиках (вон, в КСВ — про git тему завел и всех кинул ), но постараюсь ответить на эти вопросы максимально развернуто, хоть и в несколько необычной манере. Я предлагаю разделить топик на две ветки: в этой я отвечу на микро-вопросы относительно прошлой темы, а попозже, следом — на редлайн о плате за безопасность, прозвучавший выше. Хорошо?

PD>Вот, кстати, твой пример с пайпами. Там ошибка. Ее надо исправить, и все, и ее исправят. Но ты хочешь, чтобы ее не было изначально, поэтому готов на введение туда управляемого кода (я не обсуждаю технической возможности делать это в ядре ОС). Я не хочу в N-й раз доказывать. что управляемый код будет медленнее. Примем это на минуту как некий постулат, исключительно для данного момента.

Выделенное неверно. Я там упомянул всуе сингулярити, исключительно ради примера того, что из этой идеи может получиться нечто стоящее, не более того. Я не призываю переписывать ядро линукса на чем-бы то ни было (как правильно там заметили, гонки за ресурсами возможны и в управляемых средах, этот риск мы ими не закроем), я говорил о необходимости иного подхода к разработке столь стратегически-важных компонентов ОС. Дело в том, что у Линуса весьма специфичное отношение к вопросам безопасности его детища: он признает их багами, но не более значимыми чем любые другие с одной стороны, и менее значимыми по причине того, что в ядре обычных багов еще очень и очень много. Например, на предложение жестко запретить выделение памяти в младших адресах (чтобы срубить на корню все уязвимости, аналогичные той, с пайпами) как это было ранее сделано в OpenBSD, он ответил дословно следующее:

:

I think the OpenBSD crowd is a bunch of masturbating monkeys, in
that they make such a big deal about concentrating on security to the
point where they pretty much admit that nothing else matters to them.

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

Btw, and you may not like this, since you are so focused on security, one
reason I refuse to bother with the whole security circus is that I think
it glorifies — and thus encourages — the wrong behavior.

It makes "heroes" out of security people, as if the people who don't just
fix normal bugs aren't as important.

<ПосланиеЛинусу>
Блин, чувак, какая слава, какие герои, ты вообще о чем?! На твоем ядре построена безопасность не одной сотни компаний, о каких более приоритетных багах ты говоришь? Что делать всем этим компаниям пока ты расставляешь приоритеты и рассуждаешь о значимости тех или иных изменений? Свою безопасность тебе доверяет куча народа из числа десктоп-пользователей, уверенных (почем зря, кстати), что линукс — это панацея от существующих информационных угроз. Он весьма близок к этому, по сравнению с остальными радикальными альтернативами, да, но ровно до тех пор, пока в нем не будет обнаружена очередная уязвимость, ушедшая в паблик, которую ты не захочешь закрывать из нежелания обидеть тех, кто правит обычные баги

Да — это опенсорс и любой желающий может взять твое ядро и пропатчить его по самые к-хм... Но лучше тебя и окружающих тебя людей, занимающихся ядром, этого не сделает никто. Также, как и никто кроме тебя, не имеет такого авторитета, чтобы убедить использовать именно их версию. Также, как и никто кроме тебя, не сможет повлиять на цикл разработки ядра, чтобы сделать его по-настоящему безопасным.
</ПосланиеЛинусу>

Павел хочу сразу спросить: вопрос о целесообразности обеспечения безопасности в ядре ОС общего назначения, как таковом, надеюсь не стоит?

PD>Так вот, готов ты заплатить за этот потенциально безопасный код, если быстродействие упадет в 1.1 раза ? В 1.5 раза ? В 2 раза ?

Да, я тут прикинул... Я готов пойти на 10-кратное снижение быстродействия там, где существуют реальные угрозы удаленного проникновения в мою систему, ради устранения или существенной минимизации этих угроз. Возможно больше, тут уже надо торговаться Но это IMHO и, разумеется, оно будет отличаться от любого другого IMHO на эту тему

PD>И другой пример. Безопасность ядерного ректора — любой ценой. Безопасность банковских операций — ИМХО уже не любой, а только если цена будет ниже возможного ущерба. А вот безопасность сайта заборостроительной компании ?

Безопасность во всех трех случаях имеет цену, которую вполне реально, если не рассчитать, то хотя бы прикинуть ее порядок. Разница лишь в этих порядках, но и только. Но об этом напишу чуточку позже, ок?

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

KV>Например, на предложение жестко запретить выделение памяти в младших адресах (чтобы срубить на корню все уязвимости, аналогичные той, с пайпами) как это было ранее сделано в OpenBSD, он ответил дословно следующее:
Это не так просто как кажется.

KV>Да — это опенсорс и любой желающий может взять твое ядро и пропатчить его по самые к-хм... Но лучше тебя и окружающих тебя людей, занимающихся ядром, этого не сделает никто. Также, как и никто кроме тебя, не имеет такого авторитета, чтобы убедить использовать именно их версию. Также, как и никто кроме тебя, не сможет повлиять на цикл разработки ядра, чтобы сделать его по-настоящему безопасным.
Конкретно тут ты ошибаешься. Очень немногие используют ядро с kernel.org. Большинство людей используют ядра от производителей дистрибутива, у которых есть команды секьюритипатчателей.

KV>Безопасность во всех трех случаях имеет цену, которую вполне реально, если не рассчитать, то хотя бы прикинуть ее порядок. Разница лишь в этих порядках, но и только. Но об этом напишу чуточку позже, ок?

Будет интересно почитать.
Если брать официальные методики МВД, применяемые, например, для оценок ущерба в случае "пиратства" то картина печальна. Статья на тему.
Обоснованные оценки защищаемых активов дать крайне сложно.

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

C>Это не так просто как кажется.
C>Конкретно тут ты ошибаешься. Очень немногие используют ядро с kernel.org. Большинство людей используют ядра от производителей дистрибутива, у которых есть команды секьюритипатчателей.

Так вот именно из-за того, что это не так просто в т.ч. потому, что это было бы весьма ломающее изменение, вноситься оно должно централизованно, а не на уровне каждого конкретного дистрибутива. Да дело даже не в конкретно этой уязвимости, ее несложно закрыть, например, грамотной настройкой политик в пропатченном selinux'е, не сломав при этом работу тех же эмуляторов. Дело в продемонстрированном отношении к вопросам обеспечения безопасности ядра в целом. Позиция Линуса была бы (с моей т.з.) достойной понимания, будь она аргументирована несколько сильнее нежели "есть задачи поважнее", "все openbsd'шники др"№;ры от безопасности" и "безопасность обеспечивают те, кто стремится к славе и званию героя". А так (опять же — на мой взгляд), это просто безответственный треп того, кто как начинал все это just for fun, так и продолжает, не осознав, что несет "некоторую" ответственность за принимаемые им решения Не думаю, что в рамках обсуждения какой-либо другой уязвимости, Линус бы радикально поменял свою точку зрения.

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

C>>Это не так просто как кажется.
C>>Конкретно тут ты ошибаешься. Очень немногие используют ядро с kernel.org. Большинство людей используют ядра от производителей дистрибутива, у которых есть команды секьюритипатчателей.
KV>Так вот именно из-за того, что это не так просто в т.ч. потому, что это было бы весьма ломающее изменение, вноситься оно должно централизованно, а не на уровне каждого конкретного дистрибутива.
Куда ты будешь их централизованно вносить? В CentOS сейчас 2.6.18, в Debian'е — 2.6.26, в Ubuntu — 2.6.31.

KV>Да дело даже не в конкретно этой уязвимости, ее несложно закрыть, например, грамотной настройкой политик в пропатченном selinux'е, не сломав при этом работу тех же эмуляторов.
Это тоже не полный патч, он не всё решает.

KV>Дело в продемонстрированном отношении к вопросам обеспечения безопасности ядра в целом. Позиция Линуса была бы (с моей т.з.) достойной понимания, будь она аргументирована несколько сильнее нежели "есть задачи поважнее", "все openbsd'шники др"№;ры от безопасности" и "безопасность обеспечивают те, кто стремится к славе и званию героя". А так (опять же — на мой взгляд), это просто безответственный треп того, кто как начинал все это just for fun, так и продолжает, не осознав, что несет "некоторую" ответственность за принимаемые им решения Не думаю, что в рамках обсуждения какой-либо другой уязвимости, Линус бы радикально поменял свою точку зрения.
Линус рулит в том, что он умеет перекладывать ответственность. Он как-то очень явно сказал, что считает безопасников вообще сумасшедшими Так что пусть отвечают сами за свои проблемы. С точки зрения самого Линуса ему всё пофиг — он просто принимает патчи от безопасников.

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

PD>Какую плату следует уплатить за обеспечение безопасности ?

Как и обещал — "нетрадиционный" (и весьма развернутый) ответ Дело в том, что я задолбался вещать здесь про безопасность как по-настоящему нетрадиционными способами (в форме сказок

Автор: kochetkov.vladimir
Дата: 29.10.08

и рассказов

Автор: kochetkov.vladimir
Дата: 14.07.08

), так и в виде вполне себе формальных постов (раз

Автор: kochetkov.vladimir
Дата: 07.12.08

, два

Автор: kochetkov.vladimir
Дата: 03.06.08

) и ссылок/описаний тех или иных способов обеспечения безопасности (раз

Автор: kochetkov.vladimir
Дата: 20.02.09

, два

Автор: kochetkov.vladimir
Дата: 21.10.09

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

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

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

Автор: kochetkov.vladimir
Дата: 04.10.09

, так и получать высокие оценки в ходе ежегодной оценке персонала

Автор: kochetkov.vladimir
Дата: 11.02.08

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

Итак, давай пойдем логическим путем и попытаемся понять: чем же я занимаюсь в рабочее время? Моя должность называется "региональный менеджер по информационной безопасности" и единственной возлагаемой на меня задачей является решение всех вопросов, связанных с обеспечением информационной безопасности в нашем регионе (всегда рад объяснить, ваш Кэп ) Именно решение вопросов, а не обеспечение как таковое, т.к. второе лежит на плечах тех, кто является администратором либо владельцем той или иной системы/ресурса/процесса и т.п. Я лишь выступаю в роли эксперта в моменты принятия ответственными сотрудниками решений относительно обеспечения безопасности на их системах и в роли аудитора, контролируя выполнение этих решений в дальнейшем.

Обеспечение инФормационной безопасности суть — процесс, направленный на предотвращение убытков от вероятной реализации ряда угроз в отношении некоторых информационных активов, в защите которых мы заинтересованы. Согласен? Из этого следует сразу два важных вывода: сей процесс бесприбыльный, а следовательно отношение его стоимости к величине предотвращенных потерь должно в лучшем случае — стремиться к нулю, а в худшем — уж никак не должно быть равным или больше единицы. Так вот моей основной обязанностью является (каким бы это несвойственным для меня не казалось) максимально-возможное снижение стоимости принимаемых решений относительно безопасности при приемлемом уровне этой самой безопасности, в соответствии с политикой ИБ компании. Иными словами, у меня нет возможности тыкать безопасность во все щели и, тем самым, вгонять компанию в нецелесообразные затраты, не имея на то четких оснований, которые мне приходится не только озвучивать, но и порой защищать, если вдруг что. Даже, если бы мне этого сильно хотелось...

Каким же образом это происходит?

Из сказанного выше следует, что для принятия тех или иных решений по безопасности нам необходимо (хотя и не всегда достаточно):

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

Выделенное — и есть три фазы процесса обеспечения информационной безопасности в рамках одного субпроцесса/проекта/системы/ресурса и т.п. Теперь по пунктам (галопом, т.к. в инете полно статей на этот счет):

а) угроза — нарушение одного из свойств безопасности информации. Есть несколько классификаций соответствия угроз и свойств безопасности, мне больше по душе, активно применяемый в MS "STRIDE" (spoofing, tampering, repudiation, information disclosure, denial of service и elevation of privilege):

Угроза                  Свойство
---------------------------------------------------
Подмена данных          Проверка подлинности
Изменение данных        Целостность
Аннулирование           Невозможность аннулирования
Раскрытие информации    Конфиденциальность
Отказ в обслуживании    Доступность
Повышение прав доступа  Авторизованность

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

К слову сказать "уязвимость" это способ/возможность, позволяющий реализовать ту или иную угрозу.

б) риск — совокупность факторов, позволяющих оценить значимость для нас той или иной угрозы, выявленной на предыдущем этапе. И опять-таки, я не отличусь оригинальностью и упомяну подход, применяемый в MS — "DREAD". Дело в том, что оценка рисков в классическом понимании (с четким выражением финансовой составляющей) крайне затруднена в том случае, если речь идет о рисках связанных с информационными угрозами. Сколько для оператора сотовой связи будет стоить разглашение тарифного плана, который он собирается выкинуть на рынок через неделю, чтобы оторвать у конкурентов очередной кусок абонентской базы? А сколько будет стоить разглашение детализации одного абонента? А во что выльется разглашение финансового отчета для инвесторов до его публикации в паблик? Вряд ли вообще возможно оценить в рублях все три риска. Однако, если мы абстрагируемся от денег, и разобьем все риски на три категории "низкий", "средний" и "высокий", то станет очевидно, что (в сравнении друг с другом) ситуация с абонентом это "низкий риск", с тарифным планом "средний", а с финансовым отчетом "высокий". Это уже дает нам возможность принимать те или иные решения относительно, например, приоритетов минимизации этих рисков, их финансировании и т.п. Так вот DREAD, это именно такая методология, позволяющая очень быстро оценить относительную величину того или иного риска применительно к информационным угрозам. Расшифровывается оно как "damage potential, reproducibility, exploitability, affected users, discoverability" и выглядит следующим образом:

(D) Ущерб:
        (3) захват контроля на системой
        (2) разглашение строго-конфиденциальной информации
        (1) разглашение конфиденциальной информации
(R) Воспроизводимость:
        (3) В любое время, безусловно
        (2) При выполнении тех или иных условий
        (1) Затруднена
(E) Эксплуатируемость:
        (3) даже индусом
        (2) профи
        (1) гуру
(A) Масштаб влияния:
        (3) все пользователи системы
        (2) некоторые из пользователей
        (1) несколько пользователей либо только анонимные пользователи
(D) Обнаруживаемость:
        (3) легкая, либо информация об уязвимости выложена в паблик
        (2) затруднена
        (1) скрыта

Циферки — это баллы, которые необходимо просуммировать и получить относительную оценку анализируемого риска: 12-15 — высокий, 8-11 — средний и 5-7 низкий.

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

Вот примерно так все и выглядит. Заметь, все описанное выше применимо как к самим процессам разработки ПО, так и к проектам, которые разрабатываются в рамках этих процессов. То же самое к вопросу о процессах эксплуатации ПО и эксплуатируемых продуктах. Это самое важное, поэтому повторю еще раз: безопасность процесса разработки продукта — это не то же самое, что безопасность самого продукта. Угрозы и риски там совершенно разные и закрываются/минимизируются они на разных уровнях и с различными затратами.

Очень хотелось привести реальные примеры, но уже безумно хочется спать, а через 4 часа — идти на работу (оценивать риски, ага), поэтому еще один момент и баиньки:

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

Надеюсь, намек понятен

Если есть вопросы, буду рад на них ответить

P.S (из разряда, "не удержался"):

А приходила в голову мысль, что тебя мог грабануть таксист, ты мог попасть в аварию, расплатиться с таксистом не той купюрой, упасть с лестницы, нарваться в подъезде на киллера, который перепутает тебя с жертвой или (не дай бог), зайти по запарке и подпитию в гей-клуб, расположенный по соседству с твоим подъездом?

Вот и в безопасности обычно — ровно то же самое, пока не приходим мы...

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

Сегодня занят, просмотрел твой ответ, но не вник как следует. Отвечу завтра.

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

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

PD>Сегодня занят, просмотрел твой ответ, но не вник как следует. Отвечу завтра.

Да все ок, я сам не сразу вник, когда с утра прочитал

Кстати, я совершенно не раскрыл тему "так что делать обычному разработчику?". Постараюсь вечером исправиться...

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

Прочитал твой ответ. Интересно, спасибо за информацию. Но это не то, о чем я хотел узнать.

Меня , в сущности, интересует один вопрос. Плата за безопасность. Вот ты пишешь

>б) риск — совокупность факторов, позволяющих оценить значимость для нас той или иной угрозы, выявленной на предыдущем этапе.

А нет пока угрозы, и ничего не выявлено. Идет разработка, причем такого ПО, которое не является прикладным, а поэтому оценить риск крайне сложно ИМХО. Но при разработке надо принять некие решения по безопасности, а за них придется платить. Подчеркиваю — еще никто не увидел угрозы, она только потенциальна. Сколько платить готовы ? Не только деньгами. Ресурсами, скоростью работы и т.д.

Я привел пример с лондонским автобусом, он не всем понравился, сказали, что довожу до абсурда. В общем, верно. Ладно, приведу пример менее ad absurdum.

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

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

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

Но не проходит эта идея. И главная причина, почему не проходит — несоразмерная плата. Если при чтениии каждого байта будет проверка прав доступа — это даст скорость телеги.

Вот это меня и интересует. Сколько платить готовы в обычной ситуации ?

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

PD>А нет пока угрозы, и ничего не выявлено. Идет разработка, причем такого ПО, которое не является прикладным, а поэтому оценить риск крайне сложно ИМХО.

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

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

P>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>А нет пока угрозы, и ничего не выявлено. Идет разработка, причем такого ПО, которое не является прикладным, а поэтому оценить риск крайне сложно ИМХО.

P>В этом месте у меня вопросец образовался. Если ПО не прикладное, значит, системное. А к системному ПО требования по безопасности всегда высокие, нет? Риск, разумеется, оценить сложно, поэтому оцениваем сверху.

А где вопрос-то ?

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

P>>В этом месте у меня вопросец образовался. Если ПО не прикладное, значит, системное. А к системному ПО требования по безопасности всегда высокие, нет? Риск, разумеется, оценить сложно, поэтому оцениваем сверху.

PD>А где вопрос-то ?

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

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

P>Здравствуйте, Pavel Dvorkin, Вы писали:

P>>>В этом месте у меня вопросец образовался. Если ПО не прикладное, значит, системное. А к системному ПО требования по безопасности всегда высокие, нет? Риск, разумеется, оценить сложно, поэтому оцениваем сверху.

PD>>А где вопрос-то ?

P>Одни отвечают вопросом на вопрос, другие задают вопросы в утвердительной форме. Так какие требования по безопасности должны предъявляться к ПО, если оно не прикладное?

Вот на это я и хочу ответ от Владимира Кочеткова получить.

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

PD>А нет пока угрозы, и ничего не выявлено.

Не выявлено или не выявлялось?

PD>Идет разработка, причем такого ПО, которое не является прикладным, а поэтому оценить риск крайне сложно ИМХО. Но при разработке надо принять некие решения по безопасности, а за них придется платить. Подчеркиваю — еще никто не увидел угрозы, она только потенциальна. Сколько платить готовы ? Не только деньгами. Ресурсами, скоростью работы и т.д.

Как я написал ответом раньше, требования по безопасности формируются на этапе разработки ТЗ. Если эти требования не были сформированы, то до принятия каких-либо решений по безопасности, их не плохо бы было сформировать, чтобы не гоняться за химерами по всему проекту, пытаясь побороть то, о чем пока у разработчиков и четкого представления-то нет.

PD>Тебе дали книгу читать. Ты сидишь и читаешь. И тут выясняется, что содержимое книги изменилось, и узнать это новое содержимое ты прав не имеешь, а поэтому надо у тебя книгу срочно отобрать.

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

PD>В рамках модели безопасности Windows NT это невозможно. Проверка доступа производится при открытии ресурса, и если ресурс успешно открыт, доступ разрешен вплоть до закрытия. Так что администратор может сколько угодно менять разрешения на этот файл — пока я его не закрою, доступ у меня будет, вот следующий раз не смогу открыть.

Да, это риск, который необходимо принимать во внимание при построении подсистемы безопасности нашей ИС на основе разрешений доступа к объектам ФС. И?

PD>Но не проходит эта идея. И главная причина, почему не проходит — несоразмерная плата. Если при чтениии каждого байта будет проверка прав доступа — это даст скорость телеги.

Если фантазировать на эту тему, то не надо проверять доступ при чтении каждого байта. При изменении разрешений на объект ФС, можно помечать все живые хэндлы этого объекта как инвалидные и, при очередном обращении к таким хэндлам повторно запускать проверку доступа и либо сбрасывать флаг инвалидности, либо возвращать нарушение прав доступа

PD>Вот это меня и интересует. Сколько платить готовы в обычной ситуации ?

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

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

P>>Одни отвечают вопросом на вопрос, другие задают вопросы в утвердительной форме. Так какие требования по безопасности должны предъявляться к ПО, если оно не прикладное?
PD>Вот на это я и хочу ответ от Владимира Кочеткова получить.

"Ну так бы сразу и сказал" (с)

Но боюсь, что я не смогу ответить на этот вопрос. И вот почему:

забудем тогда на время про тот процесс, который я описал выше, он проходит чуть позднее чем то, о чем ты спросил. Формирование требований по безопасности к информационной системе, вообще говоря, лежит в несколько иной плоскости и происходит при постановке нефункциональных требований к продукту на этапе подготовки ТЗ на его разработку, вообще-то (либо на этапе пересмотра ТЗ, если таковой имеет место). Если обратиться к ГОСТ'у о ТЗ на ИС, то про требования по информационной безопасности там написано ровно следующее:

В требования к защите информации от несанкционированного доступа включают требования, установленные в НТД, действующей в отрасли (ведомстве) заказчика.

и все иными словами, какие заказчик сформирует требования, те и будут предъявляться к ПО безотносительно того, прикладное оно или системное. Это позиция, описанная с т.з. исполнителя, разумеется у заказчика есть некие формальные основания для предъявления тех или иных требований. Как правило, эти требования формируются исходя из замечательного руководящего документа, описывающего их применительно к различным классам защищенности ПО. Необязательно строго следовать ему (если только нет намерения сертифицировать систему в будущем), но брать за основу или что-то аналогичное — самое то.

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

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

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

PD>>Вот на это я и хочу ответ от Владимира Кочеткова получить.

KV>Но боюсь, что я не смогу ответить на этот вопрос. И вот почему:
[...]

Именно такого ответа я и ожидал. Как разработчик могу сказать, что так оно и есть, только не смог бы сформулировать это доступно.

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

KV>Кстати, я совершенно не раскрыл тему "так что делать обычному разработчику?". Постараюсь вечером исправиться...

Знакомый разрабатывает конвертер из одного формата ГИС в другой. Что вы ему посоветуете ?

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

C>Куда ты будешь их централизованно вносить? В CentOS сейчас 2.6.18, в Debian'е — 2.6.26, в Ubuntu — 2.6.31.

Вот-вот. Бардак тот еще

KV>>Да дело даже не в конкретно этой уязвимости, ее несложно закрыть, например, грамотной настройкой политик в пропатченном selinux'е, не сломав при этом работу тех же эмуляторов.
C>Это тоже не полный патч, он не всё решает.

Что именно он не решает в плане null-dereferences (не спорю, просто любопытно)?


C>Линус рулит в том, что он умеет перекладывать ответственность. Он как-то очень явно сказал, что считает безопасников вообще сумасшедшими Так что пусть отвечают сами за свои проблемы. С точки зрения самого Линуса ему всё пофиг — он просто принимает патчи от безопасников.

Фигасе, наши проблемы... А ничего, что уязвимости в ядро вносят его разработчики а не безопасники?

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

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

KV>>Кстати, я совершенно не раскрыл тему "так что делать обычному разработчику?". Постараюсь вечером исправиться...

M>Знакомый разрабатывает конвертер из одного формата ГИС в другой. Что вы ему посоветуете ?

А что конкретно в плане безопасности его беспокоит при разработке этого конвертера?

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

KV>А что конкретно в плане безопасности его беспокоит при разработке этого конвертера?

Абсолютно ничего.
Именно об этом я пытаюсь намекнуть.

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

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

KV>>А что конкретно в плане безопасности его беспокоит при разработке этого конвертера?

M>Абсолютно ничего.
M>Именно об этом я пытаюсь намекнуть.

Именно поэтому я поставил тому сообщению смайлик.

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

Иными словами, если к разрабатываемой системе не применимы требования по ИБ, то почему бы и нет? Лишь бы это решение было аргументировано и обосновано, а не взято с потолка

Совсем другое дело — это уровень культуры написания безопасного кода у отдельно взятого разработчика в отрыве от какого-либо проекта. Я как раз сейчас об этом и пишу (там будет шанс понаставить мне минусов )

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

C>>Это тоже не полный патч, он не всё решает.
KV>Что именно он не решает в плане null-dereferences (не спорю, просто любопытно)?
WINE и DOSBOX с ним не работают. А если им разрешить, то всё написание эксплоита сводиться к запуску кода под WINE.

Сейчас этот вопрос решается, stay tuned.

C>>Линус рулит в том, что он умеет перекладывать ответственность. Он как-то очень явно сказал, что считает безопасников вообще сумасшедшими Так что пусть отвечают сами за свои проблемы. С точки зрения самого Линуса ему всё пофиг — он просто принимает патчи от безопасников.
KV>Фигасе, наши проблемы... А ничего, что уязвимости в ядро вносят его разработчики а не безопасники?
А безопасники не пишут новые фичи

Если серьёзно, то безопасники играют в разработке Линукса ту же роль, что и остальные. Если им не понравится какой-то предлагаемый патч, то они точно так же могут его NAKнуть. Безопасностью отдельных дистрибутивов занимаются сами дистрибутивы.

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

KV>Иными словами, если к разрабатываемой системе не применимы требования по ИБ, то почему бы и нет? Лишь бы это решение было аргументировано и обосновано, а не взято с потолка

А вы часто пытаетесь в языковые (к примеру) диспуты вставить что то про безопасность... Как бы о какой безопасности может идти речь если этого не требуется.

KV>Совсем другое дело — это уровень культуры написания безопасного кода у отдельно взятого разработчика в отрыве от какого-либо проекта. Я как раз сейчас об этом и пишу (там будет шанс понаставить мне минусов )

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

Я уверен что перечисленные выше 2 задачи требуют для решения неординарного мастерсва и опыта, и являются достаточно узкими предметными областями.

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

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

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

KV>>Иными словами, если к разрабатываемой системе не применимы требования по ИБ, то почему бы и нет? Лишь бы это решение было аргументировано и обосновано, а не взято с потолка

M>А вы часто пытаетесь в языковые (к примеру) диспуты вставить что то про безопасность... Как бы о какой безопасности может идти речь если этого не требуется.

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

KV>>Совсем другое дело — это уровень культуры написания безопасного кода у отдельно взятого разработчика в отрыве от какого-либо проекта. Я как раз сейчас об этом и пишу (там будет шанс понаставить мне минусов )

M>Написание "безопасного" кода,я думаю даже термин такой не стоит использовать. Потому что существует непересекающиеся задачи, как написание надежного (отказоустойчивого) системного ПО, или защита конфиденциальной информации.

И написание безопасного кода не относится ни к одному, ни к другому

M>Я уверен что перечисленные выше 2 задачи требуют для решения неординарного мастерсва и опыта, и являются достаточно узкими предметными областями.
M>А вот если програмист пытается ручками написать механизм интернет оплаты не используя надежные инструментальные средства, то это уже простите банальное профанство.

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

Прокоментирую пассаж про линукс.

Существует некоторое к-во проектов для **ix систем направленных на высокую надежность системы. Речь идет о верифицированном коде, микроядрах и т.п.
Несмотря на успехи в этих областях, нет огромного спроса на эти разработки. Т.е. спрос рождает предложение.
Опять же посмотрите что делают с микроядром в яблочных операционках.

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

KV>А причем тут безопасность кода?

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

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

PD>Какую плату следует уплатить за обеспечение безопасности ?

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

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

GN>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Какую плату следует уплатить за обеспечение безопасности ?

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

Хм... В ядре ОС тоже ? В графике ? В других требовательных к ресурсах областях ?

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

D>Общее правило — стоимость защиты не должна превышать стоимости защищаемого объекта. Только считать надо не только прямые убытки и расходы, а и косвенные вещи вроде удобства пользования, которое сказывается на комфорте пользователей, репутации компании и т.д.
D>Так что и безопасность ядерного реактора не любой ценой (безопаснее всего его не запускать), а только такой, чтобы от реактора все-таки можно было получить выгоду.

Неправильно. Общее правило — стоимость взлома защиты должна превышать стоимость защищаемого объекта. Таким образом смысл взлома пропадает. А сама защита при этом может быть как очень дешевой, типа амбарного замка, так и очень дорогой.

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

PD>Здравствуйте, gear nuke, Вы писали:

GN>>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Какую плату следует уплатить за обеспечение безопасности ?

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

PD>Хм... В ядре ОС тоже ? В графике ? В других требовательных к ресурсах областях ?

С чего это ядро стало требовательно к ресурсам? Посмотри сколько времени твой компутер проводит в режиме ядра, а сколько в пользовательском.
А вот как раз безопасность в ядре гораздо важнее.

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

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

G>Неправильно. Общее правило — стоимость взлома защиты должна превышать стоимость защищаемого объекта. Таким образом смысл взлома пропадает. А сама защита при этом может быть как очень дешевой, типа амбарного замка, так и очень дорогой.

Безопасность имеет много критериев.
Описываемая тобой оценка хороша для оценки риска похищения информации. Но она совсем не подходит к оценке риска отказа в обслуживании.

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

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


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

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

PD>Хм... В ядре ОС тоже ? В графике ? В других требовательных к ресурсах областях ?

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