Здравствуйте, 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>Неправильно. Общее правило — стоимость взлома защиты должна превышать стоимость защищаемого объекта. Таким образом смысл взлома пропадает. А сама защита при этом может быть как очень дешевой, типа амбарного замка, так и очень дорогой.

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

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

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


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