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

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

FDS>>Ну да. Но когда говорят, что они мешают работать, то это имеются в виду явно все.
DOO>У меня на работе безопасность, собственно работе, не мешает. Делая такое же обобщение, я могу сказать, что проблем никаких нет

Ну дык и? Получили что? Что некоторые системы контроля версий, так же как и некоторые системы безопасности, мешают. Что и требовалось мне доказать. НЕКОТОРЫЕ системы мешают, а НЕКОТОРЫЕ — нет. Вот я линчо, и кодёнок, думаю, тоже, против тех, что мешают.
Лично мне, например, системы контроля версий, если они хорошие, удобные и исправно работают, никогда не мешали.

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

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


В СССР то же считали, что лучше на оборону кучу денег потратить, в итоге был нарушен принцип, что обороняемый объект стоит дороже, чем его оборона. Здесь то же самое: криво реализованный принцип наименьшего доступа может стоить больше, чем полное отсутствие какого-либо разграничения доступа вообще.

FDS>>Прикидываться не надо. Мои пользователи никогда не жалуются на то, что мои программы мешают (а если мешают, я убираю то, что мешает).
DOO>Не верю. Либо у тебя очень ограниченное число потребителей этой программы, либо ты далеко не все знаешь.

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

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


DOO>>>Cсылку на BST я дал только для демонтрации подхода (а не конкретного результата) — Белл с Ла Падулой не до конца довели идею
FDS>>Ага, вот она очень хорошая демонстрация получилась: доказывали доказывали, да додоказывались.
DOO>Это демонстрация одной конкретной ошибки одних конкретных исследователей, не более того.

И сколько ещё таких ошибок или просто упрощений, которые просто не найдены и никто не знает об этом?
А ведь мы доказываем безопасность системы.

DOO>Тот же McLean, если чо, очень много вариантов улучшения модели Бэла Ла Падула предложил — тот же Low watermark.

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

FDS>>Математикой вообще нельзя доказать безопасность, т.к. невозможно формализовать модель реальной системы.
DOO>А мужики-то не знали (с)

Почему не знали? Знали. Тот же kochetkov.vladimir говорил, что

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

DOO>И зачем же тогда есть модели HRU, take-grant, модель ИПС, MMS, low watermark и прочее?

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


FDS>>Поэтому все эти математические навороты могут быть полезны, но не более того. На них ничего нельзя основывать, потому что никто не знает, где и когда именно они откажут (или откажет их реализация).
DOO>Я даже не знаю какое понятное сравнение привести. Это примерно, как заявлять — зачем нужна теория алгоритмов? От нее багов все равно меньше не становится!

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

DOO>Модели разграничения доступа нужны были чтобы выбрать адекватные подходы к их реальному построению. Чтобы убедиться, что чистая модель мандатного доступа безопасна, но неэксплуатируема, что модель на основе матрицы доступа всегда имеет риск утечки права, что модель ИПС безопасна, но реализовать ее сложно и т.п.

И? Какое это отношение имеет к нашему спору? Какой пункт моих аргументов ты этим подвергаешь сомнению/опровергаешь?

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

А что, кто-то такой вывод делает?

DOO>Все имеет границы применимости.

Ага, именно об этом и речь. Вот цитаты Владимира и твои:

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

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

Однако выше ты почему-то говорил, что
DOO>Если интересно про математически, то советую погуглить "Basic Secuity Theorem" и главное работы с ее комментариями.

Ты уж определись, или можно строго математически доказать безопасность реальной системы или нет.
Вот как раз этим
DOO>Если интересно про математически
ты снимаешь с математических моделей границы применимости, объявляя их какой-то панацеей, фичей, которой можно реально доказать безопасность.

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

FDS>Тот же kochetkov.vladimir говорил
FDS>Вот цитаты Владимира

Я аж икать начал, полез сюда, смотрю — и правда меня всуе упоминают...

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

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

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

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

DOO> В этом отношении я всегда привожу пример: на работе мало у кого компьютер гвоздями к столу прибит — однако почему-то не тащат.
Люди приличные, видимо. Некоторые даже свои на работу приносят...

DOO>Или, например, знаменитая фишка про хакеров и директора столовой — нельзя сказать, что они находили несуществующие дыры...

Да, мне тоже нравится, однако для всех дыр, о которых я говорил, есть вещи, когда некто действительно мотивирован, чтобы их использовать. Вопрос лишь в том, когда найдётся человек, который захочет и сможет это сделать и таки сделает это.

FDS>>Потому что кто-то привыкает, что вот "мы всё математически строго доказали" и на всё остальное кладёт большую кучу дерьма.
DOO>Если кто-то привык все математически доказывать, то у него в продукте бардака, скорее всего, не будет

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

FDS>>Та же Common Criteria, насколько мне помниться, не использует как таковых математических моделей, а вот требование, чтобы на каждую цель атаки и угрозу было в документации написано, какие контрмеры приняты, как цель защищена — такое требование есть.
DOO>А там еще есть, так называемые, требования к среде и предположения безопасности. И можно в предположении написать, что все пользователи системы четко следуют инструкции

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

FDS>>Эксплуатируемость уязвимости не подойдёт?
DOO>Нет, не подойдет — см. выше ответ Владимиру.

Слова "интероперабельность" словари на gramota.ru тоже не знают, однако оно широко используется.


FDS>>Что значит "для нормально внедрённой ERP"? Наверное, как раз для таких, для которых эта уязвимость не была актуальной?
DOO>Речь шла о вполне конкретной ERP из 3-х букв. Просто я утверждаю, что у кого хватило денег на такую систему, хватит денег и на нормальную SAN и решение SAN-2-SAN backup, так что данные резервной копии никогда не попадут в сеть передачи данных.

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

А вот если выбирать для примера только правильно внедрённые системы, а про остальных говорить, что все лохи — тогда это уже совсем другой вопрос.
Поэтому я и спросил "Наверное, как раз для таких, для которых эта уязвимость не была актуальной?". Что понимается под правильно внедрёнными и знали ли те, кто внедрил неправильно о том, что у них она внедрена неправильно? Если знали — это их проблемы, а если не знали — то виноват разработчик и это дырка.

FDS>>Я не эта "одна фирма", которая что-то заявила, так что не надо приводить мне такой пример: я таких вещей никогда не заявлял.
DOO>Я тебе показал конкретный пример, казалось бы явной уязвимости, exploitability которой нулевой.

И что? Зачем ты мне его показал? Просто так, чтобы у меня время отнять?

FDS>>Да и уж, если серьёзно подходить к делу, не важно, эксплуатируемый баг это (т.е. уязвимость), или просто потенциал, для нормальной системы нужно удалять все известные потенциалы атак.
DOO>В результате система никогда не будет написана.

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

DOO>Ты еще предложи контроль НДВ каждый раз проводить

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

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

FDS>>Не знаю уж, кем ты работаешь, но, видимо, ты не представляешь, какая иногда радость бывает, когда видишь, что при проектировании системы примерно так и относились к багам: если не доказано, что они эксплуатируемые, то не надо их устранять.
DOO>Если они это адекватно оценили, то приведенные тобой следствия крайне сомнительны — если они и имеют место, то по какой-то иной причине. А если они на ходу стали придумывать отговорки, то это уже совсем другое дело.

И как отличить отговорки от "адекватно оценили"? И как понять, правильно ли они "адекватно оценили" или неправильно?
Можно всё что угодно "адекватно оценить", но это будут лишь догадки о том, возможно ли воспользоваться багом или нет. А исправление бага — это гарантия того, что им не воспользуются.

FDS>>1. По умолчанию без пароля — в любом случае плохо.
DOO>Почему? Докажи эту позицию. iSCSI target тоже частенько без пароля создается, но его там и включают-то редко.

Потому всегда есть возможность НСД. Или там какие-то особые ограничения?

FDS>>2. Фишка эта — фигня, конечно. Это значит, что просто багов нормальных не искали, а просто прорекламировать себя хотели
DOO>Ну у них много было — но почти каждый также отбивался: вокруг ERP такое окружение, что эксплуатировать эти дыры невозможно.

Это тоже ещё доказать надо, какое там окружение. Опять же, всё зависит от требования к эффективности защиты: если защищённость должна быть высокой, то они правы, а если и так сойдёт, то, конечно, можно очень много багов списать на невозможность их эксплуатации, и это, возможно, даже будет правильно.

DOO> Ну а шарага эта в рекламе особо не нуждается — ИМХО, каждый безопасник имел с их продуктами дело.

Ну вот, они значит ещё порекламировали, чтоб не забывали. Рекламы мало не бывает

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

KV>
(разницу между безопасностью и защищенностью выше я уже озвучивал)
Ты об этом?

За понятием "обеспечение защищенности информации" стоит исполнение вполне конкретного плана по устранению выявленных угроз.
За понятием "обеспечение безопасности информации" стоит исполнение вполне конкретного плана по противодействию выявленным рискам

Это немного не то, тут нет "безопасности", тут есть "обеспечение безопасности"

KV>А ответь мне на один простой вопрос: а зачем может понадобиться кому-либо доказывать безопасность какой-либо системы? .

Интерес очень простой. Мне совершенно не важно, как защищена система, если я заказчик. Она может быть вообще не защищена, мне важно, чтобы она была безопасна, т.е. чтобы при реализации рисков я не понёс существенного для меня ущерба и чтобы вероятность реализации была бы крайне низка.

KV> Какой в этом интерес, кроме академического?

А какой в этом академический интерес?

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

FDS>А второй раз уже не надо будет, если говорить про конкретные дыры.
Да ты что? Тебе так много кто-то готов заплатить за некую информацию из корпоративной системы, что ты рискнешь карьерой? Не верю

FDS>Плюс к этому — нет, не засекут, а если засекут, то слишком поздно и смогут понять, с какого компьютера, но не смогут понять, кто именно — этого вполне достаточно.
Почему ты так уверен, что не поймут, кто именно? Ты говоришь про дыру гипотетической прикладной системы. Допустим, что на этом гипотетическом предприятии NAC внедрен — подключение к сети по 802.1x с механизмом EAP-TLS, а ключ на персональной смарт-карте... В такой ситуации что?

DOO>> В этом отношении я всегда привожу пример: на работе мало у кого компьютер гвоздями к столу прибит — однако почему-то не тащат.
FDS>Люди приличные, видимо. Некоторые даже свои на работу приносят...
Ну и это тоже... А в случае информационной системы приличных людей не бывает?

DOO>>Или, например, знаменитая фишка про хакеров и директора столовой — нельзя сказать, что они находили несуществующие дыры...
FDS> Да, мне тоже нравится, однако для всех дыр, о которых я говорил, есть вещи, когда некто действительно мотивирован, чтобы их использовать. Вопрос лишь в том, когда найдётся человек, который захочет и сможет это сделать и таки сделает это.
Там тоже для каждой атаки можно найти гипотетическую мотивацию. Но опять же — если в той столовой была бы система охранного телевидения, то подобные фокусы уже не захотелось бы делать — и пофиг на конструкцию солонок.


FDS>>>Потому что кто-то привыкает, что вот "мы всё математически строго доказали" и на всё остальное кладёт большую кучу дерьма.
DOO>>Если кто-то привык все математически доказывать, то у него в продукте бардака, скорее всего, не будет
FDS>Дык всё не доказывают. Доказывают только нечто общеабстрактное, а конкретный код пишут люди, которые про это даже и не знают. А начальству говорят, вот мол, безопасность строго доказана
Ну тогда это не доказательство, а так — балшит.


FDS>>>Та же Common Criteria, насколько мне помниться, не использует как таковых математических моделей, а вот требование, чтобы на каждую цель атаки и угрозу было в документации написано, какие контрмеры приняты, как цель защищена — такое требование есть.
DOO>>А там еще есть, так называемые, требования к среде и предположения безопасности. И можно в предположении написать, что все пользователи системы четко следуют инструкции
FDS>И? Теперь мне можно ответить твоей цитатой "Это демонстрация одной конкретной ошибки одних конкретных исследователей, не более того"?
На самом деле нет. Это демонстрация, что не бывает сферической безопасности в вакууме — среда может и вынуждать дейстовать исключительно по инструкции (уж хз как).

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


FDS>>>Эксплуатируемость уязвимости не подойдёт?
DOO>>Нет, не подойдет — см. выше ответ Владимиру.
FDS>Слова "интероперабельность" словари на gramota.ru тоже не знают, однако оно широко используется.
Я за него тоже ругаю инженеров. Не подходит по требованиям ГОСТ 2.105 — в лучшем случае, это техницизм.

FDS>Если хватило денег, то совершенно не значит, что всё сделано правильно. Строго говоря, это уязвимость, если уж ты такой любитель математики.
Да уязвимость. Но я уж давно пытаюсь объяснить, что все уязвимости никогда не требуется устранить.

FDS>Другое дело, если реально сложно создать ERP-систему, которую не получится неправильно внедрить и предпринимаются меры, чтобы она была внедрена правильно, то, конечно, вряд ли это можно считать значимой уязвимостью.
Надо смотреть на конкретную инсталляцию. Нельзя рассматривать абстрактные уязвимости, если речь о реальной системе. Абстрактные уязвимости — для абстрактных систем, там где безопасность доказывают математически

FDS>А вот если выбирать для примера только правильно внедрённые системы, а про остальных говорить, что все лохи — тогда это уже совсем другой вопрос.
FDS>Поэтому я и спросил "Наверное, как раз для таких, для которых эта уязвимость не была актуальной?". Что понимается под правильно внедрёнными и знали ли те, кто внедрил неправильно о том, что у них она внедрена неправильно? Если знали — это их проблемы, а если не знали — то виноват разработчик и это дырка.
Еще раз — для той конкретной системы (про SAP речь, елки-палки) при внедрении всегда построят нормальную СРК. Но это была в первую очередь иллюстрация того, что фиг с ней, с конкретной системой — если строить грамотно, то даже известные уязвимости будет невозможно эксплуатировать.

DOO>>Я тебе показал конкретный пример, казалось бы явной уязвимости, exploitability которой нулевой.
FDS>И что? Зачем ты мне его показал? Просто так, чтобы у меня время отнять?
Чтобы обосновать свой тезис: устранять все уязвимости — никому не нужная утопия.

DOO>>В результате система никогда не будет написана.
FDS>Смотря как и что писать. На форуме уже обсуждалась популярная статья одно из разработчиков ПО для шаттлов — там неисправленных багов нет.
И снова вспоминаю упомянутую мной в начале книгу. Там как раз этот пример разбирался.
Есть там ошибки. Есть уязвимости. Это объективная реальность — это человеческая природа. Невозможно написать код без уязвимостей вообще.

DOO>>Ты еще предложи контроль НДВ каждый раз проводить
FDS>Почему бы и нет
Таааак. Тебя к регулирующим органам и близко не подпускать.
Нет — потому, что это парализует бизнес.


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

FDS>А уж недекларированные возможности проконтролировать легче, чем весь код перелопатить на предмет неоднократности бага.
Уверен? Представляешь сложность анализа Windows Server 2008 R2?

DOO>>Если они это адекватно оценили, то приведенные тобой следствия крайне сомнительны — если они и имеют место, то по какой-то иной причине. А если они на ходу стали придумывать отговорки, то это уже совсем другое дело.
FDS>И как отличить отговорки от "адекватно оценили"? И как понять, правильно ли они "адекватно оценили" или неправильно?
Ну хотя бы воспользовались общепринятыми стандартами оценки уязвимостей типа CVSS. Еще лучше провели процесс моделирования угроз в соответствии с SDL.

FDS>Можно всё что угодно "адекватно оценить", но это будут лишь догадки о том, возможно ли воспользоваться багом или нет.
Ну почему сразу догадки...

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

FDS>>>1. По умолчанию без пароля — в любом случае плохо.
DOO>>Почему? Докажи эту позицию. iSCSI target тоже частенько без пароля создается, но его там и включают-то редко.
FDS>Потому всегда есть возможность НСД. Или там какие-то особые ограничения?
Да. Там выделенная сеть, где участвуют только инициатор и target — некому совершать НСД (а в чистом SAN вообще нет понятия аутентификации — ужас-ужас).

DOO>>Ну у них много было — но почти каждый также отбивался: вокруг ERP такое окружение, что эксплуатировать эти дыры невозможно.
FDS>Это тоже ещё доказать надо, какое там окружение. Опять же, всё зависит от требования к эффективности защиты: если защищённость должна быть высокой, то они правы, а если и так сойдёт, то, конечно, можно очень много багов списать на невозможность их эксплуатации, и это, возможно, даже будет правильно.
Это неверно. Эксплуатируемость бага оценить можно. А вот требования, чтобы все механизмы безопасности были реализованы в самой прикладной системе не выдвыгал ни один стандарт в области ИБ за всю историю их существования — ибо не нужно.
Вон Oracle сейчас продвигает концепцию SOA в отношении security — типа в прикладной системе вообще не должно быть собственных механизмов безопасности — я так понимаю, ты бы это сразу в штыки встретил? А я так считаю — очень правильный подход. По многим причинам.

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

FDS>Ну дык и? Получили что? Что некоторые системы контроля версий, так же как и некоторые системы безопасности, мешают. Что и требовалось мне доказать. НЕКОТОРЫЕ системы мешают, а НЕКОТОРЫЕ — нет. Вот я линчо, и кодёнок, думаю, тоже, против тех, что мешают.
Почитай эту подветку сначала. Кодёнок попытался оспорить сам принцип наименьшего доступа, а не частную кривую реализацию у них на работе.

FDS>Лично мне, например, системы контроля версий, если они хорошие, удобные и исправно работают, никогда не мешали.
Лично мне например ... и далее по тексту.

FDS>У них криво реализован ... — это правильно на самом деле.
Блин. Ну и сказал (написал точнее). Ну ты ж меня понял?

FDS>Если всё правильно — блондинка ничего не похерит или похерит, но можно будет сделать откат.
Кто бы спорил.

FDS>А вот если эта блондинка — ценный сотрудник, и то, что она делает, очень нужно, но ни её начальник, ни начальник начальника не имеют права дать ей право заниматься этой нужной (и, в общем-то, непосредственно связанной со служебными обязанностями) деятельностью — вот это уже криво
Это точно также нарушает принцип наименьшего доступа — просто в другую сторону


FDS>В СССР то же считали, что лучше на оборону кучу денег потратить, в итоге был нарушен принцип, что обороняемый объект стоит дороже, чем его оборона.
Кстати, это тоже один из мифов, что система защиты не может стоить дороже защищаемой информации.

FDS>Здесь то же самое: криво реализованный принцип наименьшего доступа может стоить больше, чем полное отсутствие какого-либо разграничения доступа вообще.
И наоборот тоже. Вывод: надо реализовывать качественно, а не предоставлять всем полный доступ.

DOO>>Не верю. Либо у тебя очень ограниченное число потребителей этой программы, либо ты далеко не все знаешь.
FDS>Да, число ограниченное, конечно — я их всех знаю в лицо (на крайняк, под псевдонимами удалённо). Но и безопасность делается не для всего мира.
Когда она делается не для всего мира, а так, что всех субъектов знаешь лично — то тоже проблем нет.

FDS>Опять же, куча программ, те же системы контроля версий, лично мне никогда не мешают (если правильная система используется), а вот безопасность, почему-то мешает очень часто.
Потому что неправильно настраивают. Вот тут один человек как-то сказанул, что BI — это разводилова на бабки, потому что он никогда не видел толка от ее внедрения. Но это у нас, а в той же Америке BI очень в ходу и толку от него не мало. Внедрять надо уметь, а умелых внедрятелей (чего угодно) у нас крайне мало.

FDS>Чаще, чем все остальные программы вместе взятые (кроме моих собственных).
Это только твой опыт. Я же могу сказать точно также про DMS, системы электронного документооборота, ERP системы и т.д. и т.п.

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

DOO>Потому что неправильно настраивают. Вот тут один человек как-то сказанул, что BI — это разводилова на бабки, потому что он никогда не видел толка от ее внедрения. Но это у нас, а в той же Америке BI очень в ходу и толку от него не мало.

В некоторых компаниях у нас , на данных из BI вообще — весь бизнес строится

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

FDS>И сколько ещё таких ошибок или просто упрощений, которые просто не найдены и никто не знает об этом?
Ну упрощений, а обобщений. Сама модель Бэла Ла Падула функцию безопасности реализует. Этим пользуются до сиз пор, потому что они, по сути, первые формализовали модель мандатного доступа.

FDS>А ведь мы доказываем безопасность системы.
Конкретно модель Бэла Ла Падула доказывала безопасность системы с точки зрения выполнения правил разграничения доступа. Чтобы в их рассуждениях был смцсл для начала требуется выполнения ряда аксиом безопасности — т.е. предположений, связанных с безопасностью, но в других областях. Например, предположения, что все субъекты и объекты в системе однозначно (и верно) идентифицированы.

DOO>>Тот же McLean, если чо, очень много вариантов улучшения модели Бэла Ла Падула предложил — тот же Low watermark.
FDS>Это уже не важно. Важно, что никогда нельзя быть уверенным, что безопасность действительно доказана даже для математической модели.
Можно. Ты вцепился в факт, который демонстрирует совсем другую вещь и пытаешься показать несостоятельность всей ТОКБ — а мужики-то не знали.

FDS>>>Математикой вообще нельзя доказать безопасность, т.к. невозможно формализовать модель реальной системы.
DOO>>А мужики-то не знали (с)

FDS>Почему не знали? Знали. Тот же kochetkov.vladimir говорил, что
FDS>

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

Это называется модель ступенчатой загрузки. Тоже рассматривается в курсе ТОКБ, если чо.



DOO>>И зачем же тогда есть модели HRU, take-grant, модель ИПС, MMS, low watermark и прочее?
FDS>Это очень просто. Они существуют, для того, чтобы показать, что какая-то часть системы с определённой точки зрения безопасна (или чтобы просто использовать стандартную модель, которая общепринята и показана её успешность). Кроме этого, формальные доказательства могут помочь найти дыры в модели, т.е. тем самым повышают вероятность того, что система, основанная на этой модели, будет безопасна.
А сопромат существует для того, чтобы показать, что какая-то часть дома в каких-то условиях не развалится.
Любая теория имеет границы применимости. ТОКБ, в основном, изучает вопросы разграничения доступа в информационных системах, а остальное задается аксиомами. Соответственно, другие вопросы изучают другие разделы сей дисциплины. Это типичный научный подход — пока его еще никто особо критиковать не пытался.

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


FDS>А от теории алгоритмов багов действительно меньше не становится, об этом я и говорю.
Но она нужна, чтобы повысить общее качество программ, в каком-то смысле. Тут тоже самое...


DOO>>Модели разграничения доступа нужны были чтобы выбрать адекватные подходы к их реальному построению. Чтобы убедиться, что чистая модель мандатного доступа безопасна, но неэксплуатируема, что модель на основе матрицы доступа всегда имеет риск утечки права, что модель ИПС безопасна, но реализовать ее сложно и т.п.
FDS>И? Какое это отношение имеет к нашему спору? Какой пункт моих аргументов ты этим подвергаешь сомнению/опровергаешь?
Опровергаю? Вот это утверждение:

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

FDS>Ага, именно об этом и речь. Вот цитаты Владимира и твои:
KV>>безопасность — это не баззворд, просто это понятие дискредитировано недобросовестными поставщиками. юзеры это слово не любят и повторяют как ругательство, ибо неизбежные ограничения их )свобод, а эксперт по безопасности вполне в состоянии оценить эту самую безопасность. И, таки-да, это можно доказать строго и математически (я хз как математически, но логически — легко)

FDS>Очевидно, по твоим же словам, что
DOO>>Модели разграничения доступа нужны были чтобы выбрать адекватные подходы к их реальному построению.

FDS>Однако выше ты почему-то говорил, что
DOO>>Если интересно про математически, то советую погуглить "Basic Secuity Theorem" и главное работы с ее комментариями.

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

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

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

FDS>>А второй раз уже не надо будет, если говорить про конкретные дыры.
DOO>Да ты что? Тебе так много кто-то готов заплатить за некую информацию из корпоративной системы, что ты рискнешь карьерой? Не верю

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

DOO>Почему ты так уверен, что не поймут, кто именно? Ты говоришь про дыру гипотетической прикладной системы.

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

DOO>Ну и это тоже... А в случае информационной системы приличных людей не бывает?

Главное, что бывают неприличные

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

Ну дык директора же никто не заставлял именно солонками заниматься. Важно, что часто никакой системы нет и дыра сидит на дыре и вероятность, что кто-то воспользуется довольно высокая.

FDS>>>>Потому что кто-то привыкает, что вот "мы всё математически строго доказали" и на всё остальное кладёт большую кучу дерьма.
DOO>>>Если кто-то привык все математически доказывать, то у него в продукте бардака, скорее всего, не будет
FDS>>Дык всё не доказывают. Доказывают только нечто общеабстрактное, а конкретный код пишут люди, которые про это даже и не знают. А начальству говорят, вот мол, безопасность строго доказана
DOO>Ну тогда это не доказательство, а так — балшит.

Почему не доказательство? Часть системы-то действительно математически защищена.
А про остальное забывают за ненадобностью, даже не анализируя, на самом деле это остальное не надо или всё же надо.


DOO>На самом деле нет. Это демонстрация, что не бывает сферической безопасности в вакууме — среда может и вынуждать дейстовать исключительно по инструкции (уж хз как).

Ну и? Мы пришли к согласию? Я ведь именно про то и говорил, а ты всё со своей математикой заладил, а это и есть сфероконь.

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

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

FDS>>Слова "интероперабельность" словари на gramota.ru тоже не знают, однако оно широко используется.
DOO>Я за него тоже ругаю инженеров. Не подходит по требованиям ГОСТ 2.105 — в лучшем случае, это техницизм.

А какое используете?

FDS>>Если хватило денег, то совершенно не значит, что всё сделано правильно. Строго говоря, это уязвимость, если уж ты такой любитель математики.
DOO>Да уязвимость. Но я уж давно пытаюсь объяснить, что все уязвимости никогда не требуется устранить.

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

FDS>>Другое дело, если реально сложно создать ERP-систему, которую не получится неправильно внедрить и предпринимаются меры, чтобы она была внедрена правильно, то, конечно, вряд ли это можно считать значимой уязвимостью.
DOO>Надо смотреть на конкретную инсталляцию. Нельзя рассматривать абстрактные уязвимости, если речь о реальной системе. Абстрактные уязвимости — для абстрактных систем, там где безопасность доказывают математически

Когда мы готовим дистрибутив, мы готовим процесс инсталляции, и рассматриваем не конкретную инсталляцию, а весь набор инсталляций. Если не весь набор не безопасен по вине разработчика (т.е. пользователь весь процесс выполнил в соотв. с инструкцией по инсталляции), то это уязвимость системы даже если какое-то там окружение её всегда нейтрализует. Иначе мы начинаем опираться на очень сомнительную и болотистую почву заключений на уровне "mySql при использовании с apache всегда расположен на компьютере, недоступном из глобальной сети"

DOO>Еще раз — для той конкретной системы (про SAP речь, елки-палки) при внедрении всегда построят нормальную СРК.

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

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

DOO>Чтобы обосновать свой тезис: устранять все уязвимости — никому не нужная утопия.

Ты его никогда не обоснуешь. Потому что чем больше уязвимостей, тем больше вероятность реализации рисков в следствии их неизученного ещё взаимовлияния. Если ущерб от реализации будет серьёзным, то устранять такие вещи нужно.

DOO>>>В результате система никогда не будет написана.
FDS>>Смотря как и что писать. На форуме уже обсуждалась популярная статья одно из разработчиков ПО для шаттлов — там неисправленных багов нет.
DOO>И снова вспоминаю упомянутую мной в начале книгу. Там как раз этот пример разбирался.

Странно, я что-то никаких книг не заметил, можно ссылочку, я что-то пропустил

DOO>Есть там ошибки. Есть уязвимости. Это объективная реальность — это человеческая природа. Невозможно написать код без уязвимостей вообще.

Ты не переводи спор с одного на другое. Ты говоришь: "устранять все уязвимости — никому не нужная утопия", причём подразумеваешь именно известные уязвимости.
А объективная реальность — наличие уязвимостей неизвестных. Известные уязвимости всегда можно устранить полностью.

DOO>Таааак. Тебя к регулирующим органам и близко не подпускать.



DOO>Нет — потому, что это парализует бизнес.

Смотря как проводить. Если всё заново, снова здорова и в независимой лаборатории — конечно парализует.

FDS>>Ага, в тех же шаттлах, если обнаруживается баг, не только его исправляют, но ещё и весь код просматривают — вдруг где похожий затесался. Стоимость кода офигенная, но написали.
DOO>См. выше. Вернусь из командировки — специально накопаю цитату. Очень прикольно совпало, что ты пошел по заблуждениям, разбираемым в той книге.

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

FDS>>А уж недекларированные возможности проконтролировать легче, чем весь код перелопатить на предмет неоднократности бага.
DOO>Уверен? Представляешь сложность анализа Windows Server 2008 R2?

И? И там и там нужно анализировать. Если брать только то, что уже написано, анализировать придётся только часть компонентов (хотя, конечно, есть риск что-то пропустить во взаимодействии написанного и ненаписанного).

DOO>>>Если они это адекватно оценили, то приведенные тобой следствия крайне сомнительны — если они и имеют место, то по какой-то иной причине. А если они на ходу стали придумывать отговорки, то это уже совсем другое дело.
FDS>>И как отличить отговорки от "адекватно оценили"? И как понять, правильно ли они "адекватно оценили" или неправильно?
DOO>Ну хотя бы воспользовались общепринятыми стандартами оценки уязвимостей типа CVSS. Еще лучше провели процесс моделирования угроз в соответствии с SDL.

CVSS слишком пространная, насколько я понимаю.
Что такое SDL не знаю, вполне может быть, что всё круто. Вот только не остановится ли бизнес, пока какую-нибудь биллинговую систему будут анализировать/моделировать?

FDS>>Можно всё что угодно "адекватно оценить", но это будут лишь догадки о том, возможно ли воспользоваться багом или нет.
DOO>Ну почему сразу догадки...

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

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

Ответ некондиционен. Я привёл конкретный факт, а ты просто ушёл от ответа.

DOO> Все упирается в стоимость. Формальная верификация — это очень дорогостоящий процесс — его стоит реализовывать только там, где это очень-очень надо.

Я где-то вообще упоминал слово "верификация"? Опять споришь со сфероконём?

DOO>Да. Там выделенная сеть, где участвуют только инициатор и target — некому совершать НСД (а в чистом SAN вообще нет понятия аутентификации — ужас-ужас).

Ну тогда всё в норме.

DOO>Это неверно. Эксплуатируемость бага оценить можно.
Ммм. Разве я говорил, что нельзя? Проблема в том, что если баг есть, то какой бы он ни был, есть вероятность его эксплуатации. А вот пренебречь этой вероятностью или нет — это уже другой вопрос.

DOO> А вот требования, чтобы все механизмы безопасности были реализованы в самой прикладной системе не выдвыгал ни один стандарт в области ИБ за всю историю их существования — ибо не нужно.

Кто-то здесь говорил, что такое нужно?

DOO>Вон Oracle сейчас продвигает концепцию SOA в отношении security — типа в прикладной системе вообще не должно быть собственных механизмов безопасности — я так понимаю, ты бы это сразу в штыки встретил?

Почему? Было бы удобно, если это реально возможно правильно реализовать

DOO> А я так считаю — очень правильный подход. По многим причинам.

Ну и? Опять спор со сфероконём?

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

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

Уже читал. Оспаривал он именно частные кривые реализации. Вот только говорил он о том, что некоторые в данном случае — это почти все.
Короче говоря, он просто говорил, что не умеешь — не берись, и нафиг такая система нужна.
Да и принцип наименьшего доступа тоже ещё та хрень — реально провоцирует пользователя что-то взломать. Уж лучше дать права, чтоб сидел смирно.

FDS>>Лично мне, например, системы контроля версий, если они хорошие, удобные и исправно работают, никогда не мешали.
DOO>Лично мне например ... и далее по тексту.

Ну, значит плохие системы использовал или неправильно. Или мешали не они

FDS>>Если всё правильно — блондинка ничего не похерит или похерит, но можно будет сделать откат.
DOO>Кто бы спорил.

Ага, тогда пусть у неё будут права, пока до отката дело не дойдёт.
Есть принцип такой: не души инициативу, если блондинка хочет — значит надо!

FDS>>А вот если эта блондинка — ценный сотрудник, и то, что она делает, очень нужно, но ни её начальник, ни начальник начальника не имеют права дать ей право заниматься этой нужной (и, в общем-то, непосредственно связанной со служебными обязанностями) деятельностью — вот это уже криво
DOO>Это точно также нарушает принцип наименьшего доступа — просто в другую сторону

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

DOO>Кстати, это тоже один из мифов, что система защиты не может стоить дороже защищаемой информации.

Ммм. Скажем так, если она стоит дешевле, чем цена реализации рисков, то это просто не выгодно. Согласен, что система защиты может стоить дороже, но цена рисков всё равно будет больше стоимости защиты системы.

FDS>>Здесь то же самое: криво реализованный принцип наименьшего доступа может стоить больше, чем полное отсутствие какого-либо разграничения доступа вообще.
DOO>И наоборот тоже. Вывод: надо реализовывать качественно, а не предоставлять всем полный доступ.

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

DOO>Когда она делается не для всего мира, а так, что всех субъектов знаешь лично — то тоже проблем нет.

Ну, я встречал как раз, когда проблемы были.

DOO>Потому что неправильно настраивают. Вот тут один человек как-то сказанул, что BI — это разводилова на бабки, потому что он никогда не видел толка от ее внедрения. Но это у нас, а в той же Америке BI очень в ходу и толку от него не мало. Внедрять надо уметь, а умелых внедрятелей (чего угодно) у нас крайне мало.

Ага. Вот и получается, что пока внедрятелей нет, BI — разводилово. Такое же, как и принципы наименьшего доступа и всего остального.
Поэтому Кодёнок и говорил, что не нужен такой принцип: как только начнут нормально настраивать — мы все сразу будем за.

DOO>Это только твой опыт. Я же могу сказать точно также про DMS, системы электронного документооборота, ERP системы и т.д. и т.п.

Мой. Но мне, значит, мешает, и не только мне.
Кстати, интересно звучит, что ты то же самое можешь сказать про целый список систем: очевидно, что это наглое враньё Потому что я сказал, что одна система мешает больше, чем остальные вместе взятые.

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

DOO>Можно.

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

DOO> Ты вцепился в факт, который демонстрирует совсем другую вещь и пытаешься показать несостоятельность всей ТОКБ — а мужики-то не знали.
Про BST я лишь говорю как пример.

FDS>>>>Математикой вообще нельзя доказать безопасность, т.к. невозможно формализовать модель реальной системы.
DOO>>>А мужики-то не знали (с)

FDS>>Почему не знали? Знали. Тот же kochetkov.vladimir говорил, что
FDS>>

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

DOO>Это называется модель ступенчатой загрузки. Тоже рассматривается в курсе ТОКБ, если чо.

Причём тут как это называется?
Очевидно, что чтобы что-то доказать математически, надо хотя бы всё это рассмотреть (а на самом деле даже формализовать не получится)

DOO>>>И зачем же тогда есть модели HRU, take-grant, модель ИПС, MMS, low watermark и прочее?
FDS>>Это очень просто. Они существуют, для того, чтобы показать, что какая-то часть системы с определённой точки зрения безопасна (или чтобы просто использовать стандартную модель, которая общепринята и показана её успешность). Кроме этого, формальные доказательства могут помочь найти дыры в модели, т.е. тем самым повышают вероятность того, что система, основанная на этой модели, будет безопасна.
DOO>А сопромат существует для того, чтобы показать, что какая-то часть дома в каких-то условиях не развалится.

Только вот регулярно что-нибудь валится В том числе и по ошибкам расчётов, и по причине недостаточно хороших моделей расчётов
А так да — рассчитали и всё: полностью безопасно. Вот я как раз очень сильно против такого безрассудства.

DOO>Любая теория имеет границы применимости. ТОКБ, в основном, изучает вопросы разграничения доступа в информационных системах, а остальное задается аксиомами. Соответственно, другие вопросы изучают другие разделы сей дисциплины. Это типичный научный подход — пока его еще никто особо критиковать не пытался.

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

FDS>>Разве я говорю, что математические абстракции не нужны в безопасности? Ты меня невнимательно читаешь.
DOO>Ты говоришь, что математические абстракции — это профанация, которая ничего не имеет с реальной безопасностью реальных систем. Как-то так. Поправь, если ошибаюсь.

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

FDS>>А от теории алгоритмов багов действительно меньше не становится, об этом я и говорю.
DOO>Но она нужна, чтобы повысить общее качество программ, в каком-то смысле. Тут тоже самое...

Ага, согласен. Но с её помощью от багов не избавится, так же, как с помощью математики не доказать безопасность ИС.

DOO>>>Модели разграничения доступа нужны были чтобы выбрать адекватные подходы к их реальному построению. Чтобы убедиться, что чистая модель мандатного доступа безопасна, но неэксплуатируема, что модель на основе матрицы доступа всегда имеет риск утечки права, что модель ИПС безопасна, но реализовать ее сложно и т.п.
FDS>>И? Какое это отношение имеет к нашему спору? Какой пункт моих аргументов ты этим подвергаешь сомнению/опровергаешь?
DOO>Опровергаю? Вот это утверждение:
DOO>

DOO>Ага, вот она очень хорошая демонстрация получилась: доказывали доказывали, да додоказывались.
DOO>Математикой вообще нельзя доказать безопасность, т.к. невозможно формализовать модель реальной системы. Поэтому все эти математические навороты могут быть полезны, но не более того. На них ничего нельзя основывать, потому что никто не знает, где и когда именно они откажут (или откажет их реализация).
DOO>Проблема в том, что действительно серьёзные вещи, где допускаются дыры, в принципе не имеют математических моделей, а всякие математические абстракции ведутся, в общем-то, для формализации лишь узкой части концепции системы, которая, собственно, может быть формализована.

И в какой же части ты опровергаешь это утверждение?
1. невозможно формализовать модель реальной систем
Очевидно, ты сам говоришь, что невозможно, когда говоришь о границах применимости.
2. никто не знает, где и когда именно они откажут
А ты знаешь, когда именно откажут математические навороты?
Что-то я не вижу тут каких-то аргументов против этого утверждения
3. серьёзные вещи, где допускаются дыры, в принципе не имеют математических моделей
Погорячился. Надо было написать слово "некоторые действительно серьёзные вещи" и "приемлемых математических моделей".


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

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

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

DOO>Ну вот ты опять свою частную ситуацию обобщаешь на все остальное.

Ничего он не обобщает. Это ты невнимательно читаешь сообщения

DOO>Я много раз видел именно такое — негативное отношение к системам контроля версий. Или к системам управления документами — тоже самое "Да ну, блин. Сложно там как-то — check in/check out всякий. Мне проще так — по-старинке и т.п.". Это естественная реакция человека, чтобы ее побороть надо:

Её не надо бороть. Нужно, чтобы люди попробовали, но если они попробовали, а им не понравилось, значит что-то не так.

DOO>В вашем случае — СБ сделала вид, что решила проблему, вы сделали вид, что вас устраивает.
Почему это кто-то сделал вид? Не надо передёргивать факты

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

DOO>По-хорошему ваше непосредственное руководство должно бы было инициировать обсуждение вопроса на соответствующем уровне — тогда бы что-то менялось.

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

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

FDS>Здравствуйте, DOOM, Вы писали

DOO>>Ну вот ты опять свою частную ситуацию обобщаешь на все остальное.
FDS>Ничего он не обобщает. Это ты невнимательно читаешь сообщения

Плохое сравнение, никак не пересекающееся с описанной мной проблемой. Системы контроля версий у нас любят и не избегают, а папки проектов — не любят и избегают.

Где я плохо читаю?
Да и вообще — почему ты так уверенно трактуешь чужие слова? Пусть уж тогда сам Кодёнок скажет, что он имел ввиду. А так это будут лишь домыслы.

DOO>>Я много раз видел именно такое — негативное отношение к системам контроля версий. Или к системам управления документами — тоже самое "Да ну, блин. Сложно там как-то — check in/check out всякий. Мне проще так — по-старинке и т.п.". Это естественная реакция человека, чтобы ее побороть надо:
FDS>Её не надо бороть. Нужно, чтобы люди попробовали, но если они попробовали, а им не понравилось, значит что-то не так.
Ты имел опыт реальной автоматизации какого-то устоявшегося процесса? Судя по всему нет. Любое изменение от устоявшегося процесса требует перелома привычки — без этого никак. И уж точно никогда не будет (за исключением единичных случаев) сценария "попробовали — понравилось — стали пользоваться".

DOO>>В вашем случае — СБ сделала вид, что решила проблему, вы сделали вид, что вас устраивает.
FDS>Почему это кто-то сделал вид? Не надо передёргивать факты
Я не передергиваю. В описанной ситуации именно так — СБ делает вид, что все секурно (потому что они могли бы и запретить создавать шары на рабочих станциях, если уж так борются за контролируемый доступ), сотрудники сделали вид, что папки проектов их устраивают — потому что не стали нормальными методами добиваться исправления ситуации, а стали втихаря действовать по-старинке. Как это еще назвать тогда?

DOO>> В общем-то все недовольны, поставленные цели не достигнуты. Однако плачут, но кактус жуют...
FDS>А что делать, если всем наплевать на то, сколько кактусов жуют рядовые работники?
Если всем наплевать на эффективность бизнес процессов компании, то лучше из такой компании валить при первой же возможности.

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

DOO>>По-хорошему ваше непосредственное руководство должно бы было инициировать обсуждение вопроса на соответствующем уровне — тогда бы что-то менялось.
FDS>Ну да, а соответствующий уровень руководства, по-хорошему, должен эту проблему решить. И много ты видел таких "по-хорошему" в реале?
Как минимум мы стараемся у нас на работе.

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

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

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

FDS>Уже читал. Оспаривал он именно частные кривые реализации. Вот только говорил он о том, что некоторые в данном случае — это почти все.
Мне кажется ты сам себе противоречишь уже в этом предложении. Но это не суть — пустые домыслы. Пусть уж тогда сам Кодёнок говорит, что он имел ввиду.
FDS>Короче говоря, он просто говорил, что не умеешь — не берись, и нафиг такая система нужна.
Не умеешь — не берись — это универсальный принцип. Но не совсем верный. Браться за все сразу не надо — надо потихоньку — будешь и учиться параллельно.
Ну а попытка сразу завинтить все гайки к описанному и приводит

FDS>Да и принцип наименьшего доступа тоже ещё та хрень — реально провоцирует пользователя что-то взломать. Уж лучше дать права, чтоб сидел смирно.
Это видимо смотря какого пользователя. На самом деле для какой-нибудь операционистки в банке — это благо. У нее хоть голова не будет болеть, что она что-то сломает. Для инженера — далеко не благо. Однако, меня не напрягает почему-то отсутствие доступа к 1С'ке у нас на работе..
Или то, что работаю я не с правами энтерпрайз админа, хотя такая учетка у меня тоже есть на всякий пожарный

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

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

FDS>Есть принцип такой: не души инициативу, если блондинка хочет — значит надо!
Это никак не связано с инициативой. У меня от доступа в 1С явно не появится желания что-то посчитать за нашу бухгалтерию.

DOO>>Это точно также нарушает принцип наименьшего доступа — просто в другую сторону
FDS>Не нарушает. Потому что все дают только необходимые права, а если давать достаточные, то получится сразу ого-го сколько прав...
Надо давать достаточные. Только не заведомо достаточные (то бишь все подряд), а конкретно для этой роли. А то получается оценка длины бороды по Нильсу Бору.

DOO>>Кстати, это тоже один из мифов, что система защиты не может стоить дороже защищаемой информации.
FDS>Ммм. Скажем так, если она стоит дешевле, чем цена реализации рисков, то это просто не выгодно. Согласен, что система защиты может стоить дороже, но цена рисков всё равно будет больше стоимости защиты системы.
Что есть "цена рисков". К тому же, все эти стоимостные оценки просты только на бумаге — в реальной жизни все очень сложно. Взять ту же гос. тайну — тратить на ее защиту государство готово просто любые средства. Другой вопрос, а вся ли гос. тайна является действительно гос. тайной (особенно на фоне "секретной" кандидатской моего коллеги ).


DOO>>И наоборот тоже. Вывод: надо реализовывать качественно, а не предоставлять всем полный доступ.
FDS>Ага. Правильный вывод. Вот только пока что почему-то мало у кого это получается: то ли квалификации не хватает, то ли вообще это невозможно в некоторых случаях. А значит сам принцип кривой и нужен другой — который можно реализовать правильно.
Всегда все определяется доступными инструментами. Запрограммировать сложное логическое условие на ассемблере тоже нехилая задачка — но что с того?
Сейчас реально эффективных инструментов для управления доступом с, так называемым, self-service'ом — пруд пруди — они реально проще в использовании, чем традиционные бумажные должностные записки и даже классические Help Desk'и. Просто пока реально мало людей способных грамотно внедрить подобные системы.

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


FDS>Кстати, интересно звучит, что ты то же самое можешь сказать про целый список систем: очевидно, что это наглое враньё
Почему очевидно? Я бываю в очень разных организациях и беседую с очень разными людьми в этих организациях — у меня неплохая выборка...

FDS>Потому что я сказал, что одна система мешает больше, чем остальные вместе взятые.
Чем ты измерял мешательность?

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

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

DOO>>Можно.
FDS>Нельзя. Доказать что-либо математически про реальный мир принципиально нельзя, исключая некоторые модели, которые можно ясно формализовать (шахматы, например)
Угу. И расчитать давление газа в емкости тоже нельзя — ведь там такое грубейшее приближение.

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

FDS>Причём тут как это называется?
При том, что для ступенчатой загрузки есть своя основная теорема безопасности. И сводится она к тому, что (грубо) — если на предыдущем уровне все ОК, то на следующем можно на него внимания не обращать. Там проблема только в правильном разделении на уровни и граничных случаях — но это можно описать для стандартной x86 архитектуры (и, вроде, такие работы есть).
Вывод: рассматривая некую высокоуровневую программу, я за микрокод могу уже не заморачиваться.

FDS>Очевидно, что чтобы что-то доказать математически, надо хотя бы всё это рассмотреть (а на самом деле даже формализовать не получится)
Да-да. А чтоб посчитать давление газа в емкости надо рассчитать траекторию движения каждой его молекулы.

DOO>>А сопромат существует для того, чтобы показать, что какая-то часть дома в каких-то условиях не развалится.
FDS>Только вот регулярно что-нибудь валится В том числе и по ошибкам расчётов, и по причине недостаточно хороших моделей расчётов
Ты знаешь, как ни странно, но я проходил как-то курсы повышения квалификации именно по вопросам комплексного проектирования в строительстве. И там мужик рассказывал про самые известные случаи таких вот обрушений — хит-парад причин следующий:
1. Косяки строителей (наш известный мост через ул. Шевченко).
2. Нарушение правил эксплуатации и текущего ремонта (бассейн г. Чусовой).
3. Косяки проекта из-за внесения изменений после утверждения, которые банально толком не пересчитали (аквапарк в Москве).
Случаев, когда признавали виновными именно проектировщиков очень мало, а их методы расчета невероятно точны (на границе погрешности измерений) при всей их простоте. Вообще-то СНиПы не с потолка брали.

FDS>А так да — рассчитали и всё: полностью безопасно. Вот я как раз очень сильно против такого безрассудства.
Это не безрассудство. Я уже упоминал тут понятие функциональной безопасности — да там есть элемент вероятности, но можно задать уровень надежности в 9-10 "девяток". Например, для ж/д транспорта уровень надежности допускает сбой в 10^-10 случаев.


FDS>Ну почему же, научный подход много критиковали
несостоятельно

FDS>Вопрос как раз в том, что если ты утверждаешь, что безопасность можно доказать математически, то ты как раз забываешь об этих границах.
Нет, не забываю.

FDS>Здания часто тоже именно на границах применимости прочностных теорий рушатся.
Нет. Это не так. Приведи хотя бы один пример.

DOO>>Ты говоришь, что математические абстракции — это профанация, которая ничего не имеет с реальной безопасностью реальных систем. Как-то так. Поправь, если ошибаюсь.
FDS>Ммм. Что-то я не припомню, чтобы я такое говорил (наоборот, я говорил, что они могут помочь, а профанация — утверждать, что с их помощью можно указывать на безопасность системы).
Что тогда ты понимаешь под "помочь", если попытка доказательства безопасности — это профанация?
Кстати, еще тебе пример — доказательство того, что алгоритм решает определенную задачу необходимо, но из этого не следует, что конкретная реализация корректно описывает исходный алгоритм. Но тут уже для этого конкретного алгоритма можно построить серию тестов, которая покажет с вероятностью 99.(тут подставить сколько надо девяток), что он соответствует формальной модели. Это возможно? Да. На каждом шаге доказательство строго математическое. Увязана формальная модель и реальная система. Что еще забыл?


FDS>Ага, согласен. Но с её помощью от багов не избавится, так же, как с помощью математики не доказать безопасность ИС.
см. выше.


FDS>И в какой же части ты опровергаешь это утверждение?
FDS>1. невозможно формализовать модель реальной систем
Можно доказать, что реальная модель реализует формальную с заданной достоверностью.

FDS>Очевидно, ты сам говоришь, что невозможно, когда говоришь о границах применимости.
FDS>2. никто не знает, где и когда именно они откажут
? Странное утверждение. О границах применимости знают, значит знают когда на них наткнешься.

FDS>А ты знаешь, когда именно откажут математические навороты?
Еще более странное утверждение...

FDS>Что-то я не вижу тут каких-то аргументов против этого утверждения
FDS>3. серьёзные вещи, где допускаются дыры, в принципе не имеют математических моделей
FDS>Погорячился. Надо было написать слово "некоторые действительно серьёзные вещи" и "приемлемых математических моделей".
Неочевидное утверждение.

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

FDS>Я спорю с тем, что ты говорил, что математически можно доказать безопасность системы.
FDS>Обсчитать да, но самолёты по прежнему падают (как и здания, кстати), а системы будут содержать эксплуатируемые уязвимости.
Самолеты падают не из-за проблем в конструкции.

FDS>А то, что там при этом крутая математика — да, но она не доказывает ни на йоту, что самолёт безопасен.
Это наглое враньё (с)
FDS>Кроме этого, я могу без математики сконструировать тот же самолёт, просто работы это потребует больше, а безопасность всё равно останется такой же (в общем-то, плохой).

Ты правда так думаешь? Ну мне, пожалуйста, хотя бы высокоуровневый план нарисуй по сборке среднемагистрального авиалайнера.

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

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

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


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


DOO>>Ну и это тоже... А в случае информационной системы приличных людей не бывает?
FDS>Главное, что бывают неприличные
Но они же не тырят ноутбуки с работы?

DOO>>Там тоже для каждой атаки можно найти гипотетическую мотивацию. Но опять же — если в той столовой была бы система охранного телевидения, то подобные фокусы уже не захотелось бы делать — и пофиг на конструкцию солонок.
FDS>Ну дык директора же никто не заставлял именно солонками заниматься.
Ты заставляешь
Солонка в данном случае — это твоя ИС, вырванная из контекста. Можно убиться, реализуя в ней, на самом деле, ненужные функции, а можно сделать нормальное окружение.

FDS>Важно, что часто никакой системы нет
Почему ты так решил? Часто система как раз есть. Хотя бы операционная

FDS>Почему не доказательство? Часть системы-то действительно математически защищена.
Ну если тебя устраивает защищенность только этой части, то в чем вопрос? А если нет — то какое это доказательство?

FDS>А про остальное забывают за ненадобностью, даже не анализируя, на самом деле это остальное не надо или всё же надо.
О выделенном скорее судить принимающему работу, а не исполнителю.

DOO>>На самом деле нет. Это демонстрация, что не бывает сферической безопасности в вакууме — среда может и вынуждать дейстовать исключительно по инструкции (уж хз как).
FDS>Ну и? Мы пришли к согласию? Я ведь именно про то и говорил, а ты всё со своей математикой заладил, а это и есть сфероконь.
Ты не про то говорил. Ты упорно говоришь про необходимость устранения уязвимостей, несмотря на окружение.

FDS>Мягко говоря, очень далёк. Кроме определений нужны ещё и сами доказательства. Какие бы ни были строгие определения это не значит, что ими можно вообще хоть что-то математически доказать.
Вообще-то есть собственно механизм предикатов и т.п. Формальный язык — это основное требование, чтобы можно было проводить доказательства.

FDS>>>Слова "интероперабельность" словари на gramota.ru тоже не знают, однако оно широко используется.
DOO>>Я за него тоже ругаю инженеров. Не подходит по требованиям ГОСТ 2.105 — в лучшем случае, это техницизм.
FDS> А какое используете?
способность к взаимодействию. Это по сути стандартный перевод.

FDS>Но математически система становится незащищённой. Математике не объяснишь, что ты считаешь, что вот здесь никто не полезет (только брать от балды вероятности, например, того, что чел пойдёт на правонарушение заведомо зная, что его поймают).
Ты слово аксиома слышал? Оно задает априорные свойства модели. Там и можно определить, что мы считаем априорно выполнимым. Это и есть способ "сказать математике, что вот здесь никто не полезет".


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

FDS>Иначе мы начинаем опираться на очень сомнительную и болотистую почву заключений на уровне "mySql при использовании с apache всегда расположен на компьютере, недоступном из глобальной сети"
Это очень логичное требование.


DOO>> Но это была в первую очередь иллюстрация того, что фиг с ней, с конкретной системой — если строить грамотно, то даже известные уязвимости будет невозможно эксплуатировать.
FDS>И зачем было приводить такую иллюстрацию?
Как замечательно, что ответ на это я уже написал:
DOO>>Чтобы обосновать свой тезис: устранять все уязвимости — никому не нужная утопия.

FDS>Ты его никогда не обоснуешь. Потому что чем больше уязвимостей, тем больше вероятность реализации рисков в следствии их неизученного ещё взаимовлияния. Если ущерб от реализации будет серьёзным, то устранять такие вещи нужно.
Нет. Если у меня сервер, то мне пофигу на очередную дыру в редакторе Vim. Я его только сам использую и то для выполнения очень ограниченного числа операций.

FDS>>>Смотря как и что писать. На форуме уже обсуждалась популярная статья одно из разработчиков ПО для шаттлов — там неисправленных багов нет.
DOO>>И снова вспоминаю упомянутую мной в начале книгу. Там как раз этот пример разбирался.
FDS>Странно, я что-то никаких книг не заметил, можно ссылочку, я что-то пропустил
Ссылочка только на amazon, так что проку с нее: http://www.amazon.com/New-School-Information-Security/dp/0321502787

DOO>>Есть там ошибки. Есть уязвимости. Это объективная реальность — это человеческая природа. Невозможно написать код без уязвимостей вообще.
FDS>Ты не переводи спор с одного на другое. Ты говоришь: "устранять все уязвимости — никому не нужная утопия", причём подразумеваешь именно известные уязвимости.
FDS>А объективная реальность — наличие уязвимостей неизвестных. Известные уязвимости всегда можно устранить полностью.
А что значит "известная уязвимость"? Кому она должна быть известна? В какой момент? Т.е. ы все сводишь к тому, что ПО безопасно, если ты не нашел в нем дыру за N дней? Это и есть твой подход к гарантии безопасности? Странный он, мягко говоря.


DOO>>Нет — потому, что это парализует бизнес.
FDS>Смотря как проводить. Если всё заново, снова здорова и в независимой лаборатории — конечно парализует.
В любом случае парализует. Например, биллинговые системы операторов связи меняются практически непрерывно — когда там исследования проводить?

FDS>>>Ага, в тех же шаттлах, если обнаруживается баг, не только его исправляют, но ещё и весь код просматривают — вдруг где похожий затесался. Стоимость кода офигенная, но написали.
DOO>>См. выше. Вернусь из командировки — специально накопаю цитату. Очень прикольно совпало, что ты пошел по заблуждениям, разбираемым в той книге.
Ну как бы нашел:

Today it is not possible to write a computer program of any meaningful size in such a way that it can be proven that it does not have bugs, even when perfection is the goal. The space shuttle has been held up as a paragon of software-development virtue, but even its code has bugs. There have been cases where a vulnerability has been found in a piece of code that was written ten or twenty years earlier and reviewed many times.

FDS>ok, жду.
FDS>В принципе, это ничего не меняет. Можно всегда нарыть программы (скажем, не очень большие), где все известные баги сразу же устраняются. Как там шаттлы, это я уж так, например.
Скажем очень маленькие программы. Никто не застрахован от обнаружения ошибки даже через много лет (см. выше).

FDS>>>А уж недекларированные возможности проконтролировать легче, чем весь код перелопатить на предмет неоднократности бага.
DOO>>Уверен? Представляешь сложность анализа Windows Server 2008 R2?
FDS>И? И там и там нужно анализировать. Если брать только то, что уже написано, анализировать придётся только часть компонентов (хотя, конечно, есть риск что-то пропустить во взаимодействии написанного и ненаписанного).
Не понял этого утверждения.

DOO>>>>Если они это адекватно оценили, то приведенные тобой следствия крайне сомнительны — если они и имеют место, то по какой-то иной причине. А если они на ходу стали придумывать отговорки, то это уже совсем другое дело.
FDS>>>И как отличить отговорки от "адекватно оценили"? И как понять, правильно ли они "адекватно оценили" или неправильно?
DOO>>Ну хотя бы воспользовались общепринятыми стандартами оценки уязвимостей типа CVSS. Еще лучше провели процесс моделирования угроз в соответствии с SDL.

FDS>CVSS слишком пространная, насколько я понимаю.
Но достаточно адекватная

FDS>Что такое SDL не знаю, вполне может быть, что всё круто. Вот только не остановится ли бизнес, пока какую-нибудь биллинговую систему будут анализировать/моделировать?
SDL — это Secure Development Lifecycle. У MS, вроде, бизнес не встал.


FDS>>>Можно всё что угодно "адекватно оценить", но это будут лишь догадки о том, возможно ли воспользоваться багом или нет.
DOO>>Ну почему сразу догадки...
FDS>Потому что все оценки всегда базируются на экспертных заключениях, а они могут быть выданы такие, какие можется экспертам или хочется начальству экспертов.
Если экспертное заключение сформулировано строгими математическими утверждениями, то там нет места субъективности

FDS>>>А исправление бага — это гарантия того, что им не воспользуются.
DOO>>А написание максимально оптимизированных программ на голом асме — весомый вклад в борьбу с глобальным потеплением.
FDS>Ответ некондиционен. Я привёл конкретный факт, а ты просто ушёл от ответа.
Ответ в полной мере соответствует тезису. Можно много чего делать, казалось бы хорошего, но есть еще экономическая составляющая. Реализовывать в своей программе все требования к КСЗ СВТ 1-го класса — это глупо, если нет такого явного требования.


DOO>> Все упирается в стоимость. Формальная верификация — это очень дорогостоящий процесс — его стоит реализовывать только там, где это очень-очень надо.
FDS>Я где-то вообще упоминал слово "верификация"? Опять споришь со сфероконём?
А что ты понимаешь под верификацией тогда?


DOO>>Да. Там выделенная сеть, где участвуют только инициатор и target — некому совершать НСД (а в чистом SAN вообще нет понятия аутентификации — ужас-ужас).
FDS>Ну тогда всё в норме.
Дак паролей-то нету!! Как в норме?


DOO>>Это неверно. Эксплуатируемость бага оценить можно.
FDS>Ммм. Разве я говорил, что нельзя? Проблема в том, что если баг есть, то какой бы он ни был, есть вероятность его эксплуатации. А вот пренебречь этой вероятностью или нет — это уже другой вопрос.
Интересно — а вот выше ты согласился, что отсутствие по умолчанию аутентификации в iSCSI — это нормально.

DOO>> А вот требования, чтобы все механизмы безопасности были реализованы в самой прикладной системе не выдвыгал ни один стандарт в области ИБ за всю историю их существования — ибо не нужно.
FDS>Кто-то здесь говорил, что такое нужно?
Отсутствие какого-то механизма — тоже уязвимость