Здравствуйте, DOOM, Вы писали:
DOO>Настоящая безопасность всегда оперирует очень четкими почти математическими определениями.
В итоге дыр оставляют огромное количество, которые видны невооружённым взглядом. Математикой такие вещи в принципе невозможно описать, хотя, наверное, она может помочь, чтобы найти большее количество огрех.
Здравствуйте, DOOM, Вы писали:
DOO> Это кто ж вам так криво сделал процедуру замещения? Конечно ей не пользуются — она же нежизненная ни фига. В какой реальной ситуации может потребоваться больному сотруднику предоставлять доступ на свой компьютер? Инициатором будет не он, это же очевидно. И решение принимать должен не он. DOO>А дальше все просто — в вашем IDM'е должен быть определен процесс замещения, который может инициировать тот, кто должен его инициировать в жизни (сам замещающий сотрудник, начальник и т.п.) и согласовать предоставление должен тот, кто в жизни это делает (например, непосредственный руководитель).
Ну ок, с больничными действительно есть проблема, глупо спорить. Я вот тут внезапно узнал, что сейчас оформить себе командировку или отпуск без настраивания замещения уже невозможно. А фичу инициирования замещения не замещаемым уже реализуют. Так что happy end, все ок
Здравствуйте, DOOM, Вы писали:
DOO>3. Сделать в вашем IDM'е (а я таки узнал, что вы используете ) процесс замещения, который не будет отличаться от своего "некомпьютерного" собрата.
Не слышу соболезнований, по поводу того, какой IMD мы используем Но у меня есть большие сомнения по поводу того, что он вообще принимает участие в текущей реализации замещений (правда не в курсе, т.к. это централизованная система и я хз деталей реализации).
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>7. Разработчики: С чем? Вы нам напишите четко, что вас не устраивает и как должно быть, DOO>Ты им SDL и Threat Modelling Tool в зубы выдай и скажи — вот, написал
Тут есть один политический ньюанс — как правило это не наши разработчики, т.к. мы 70-80% разработки аутсорсим И вот хрен им, а не TMT. Пусть в визио рисуют и сами описания угроз вписывают
KV>>Но ведь суть сказанного мной от этого не меняется, просто мне показалось, что на CIA это объяснить легче и писать нужно меньше, но не более того
FDS>Если наши разногласия только в этом, то дальнейший спор, конечно, бессмыслен.
Здравствуйте, minorlogic, Вы писали:
M>Приведу пример.
M>Некоторые участники форума с завидным постоянством употребляют термин "безопасный язык" уязвимость и т.п. в контексте использования например языка С в линуксе. M>Без указания опасностей, угроз или конкретных проблем слово "безопастность" превращается в чистейший бессмысленный базворд.
"Кто он?! Назовите мне имя это подлеца, сэр!" (с)
По-моему, мы еще в той теме выяснили, что типобезопасность "некоторых" языков не спасла бы от race-condition в ядре, к чему сейчас было это вспоминать —
Кроме того, не смущает, что в понятие типобезопасность (type-safety), отсутствует слово "security"?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>По-моему, мы еще в той теме выяснили, что типобезопасность "некоторых" языков не спасла бы от race-condition в ядре, к чему сейчас было это вспоминать —
"race-condition" = это да, вполне себе конкретная проблема. А абстрактная безопасность это базворд.
Переполнение стека/буфера вполне себе проблема , но для 100% систем с которыми я работал это не проблема безопасности , это просто баг. и т.п.
KV>Кроме того, не смущает, что в понятие типобезопасность (type-safety), отсутствует слово "security"?
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>По-моему, мы еще в той теме выяснили, что типобезопасность "некоторых" языков не спасла бы от race-condition в ядре, к чему сейчас было это вспоминать —
M>"race-condition" = это да, вполне себе конкретная проблема. А абстрактная безопасность это базворд.
Да я вроде нигде об абстрактной безопасности и не говорил
M>Переполнение стека/буфера вполне себе проблема , но для 100% систем с которыми я работал это не проблема безопасности , это просто баг. и т.п.
Тоже уже обсуждали. Не сам факт того, что это переполнение буфера, делает сей баг уязвимостью, а то, позволяет ли он реализовать какую-либо из угроз, определенных в требованиях к нашей системе как нежелательных либо неприемлиемых. Там весь спор (и по-моему, без моего осбого участия) шел на тему, где искать ту грань, когда угрозу нежелательно игнорировать на уровне требований к системе и по каким критериям оценивать значимость или незначимость тех или иных угроз.
KV>>Кроме того, не смущает, что в понятие типобезопасность (type-safety), отсутствует слово "security"? M>Не смущает, но и не понял
Safety и security — хоть и считаются синонимами, но употребляются в различных контекстах. Safety — безопасность от случайных опасностей, security — защищенность от предумышленных действий. Type-security было бы у нас в том случае, если бы в языке напрочь отсутствовала любая возможность даже явного приведения типов.
А упомянул я про это потому, что этот самый type-safety, это safety процесса разработки системы, а не ее эксплуатации. Т.е. это безопасность программера от случайной ошибки в типах, но, строго говоря, и не более того. Короче понятие "типобезопасность" чисто по своему смыслу вообще не имеет отношения к понятию safety системы и уж тем более к ее security.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Тоже уже обсуждали. Не сам факт того, что это переполнение буфера, делает сей баг уязвимостью, а то, позволяет ли он реализовать какую-либо из угроз, определенных в требованиях к нашей системе как нежелательных либо неприемлиемых. Там весь спор (и по-моему, без моего осбого участия) шел на тему, где искать ту грань, когда угрозу нежелательно игнорировать на уровне требований к системе и по каким критериям оценивать значимость или незначимость тех или иных угроз.
Вот опять абстрактные угрозы ... Ну какие угрозы существую для программы расчета ПИ? Вы как бы за кадром априори подразумеваете существование угроз ... причем абстрактных.
Здравствуйте, minorlogic, Вы писали: M>Вот опять абстрактные угрозы ... Ну какие угрозы существую для программы расчета ПИ?
Для абстрактной программы расчета ПИ существует масса абстрактных угроз
M>Вы как бы за кадром априори подразумеваете существование угроз ... причем абстрактных.
Это не я подразумеваю, если что. Вы просто путаете понятие риска с понятием угрозы, считая что это что-то такое с чем необходимо сразу же бороться, что оно несет негативный оттенок и т.п. Это не так. Информационная угроза — это лишь возможность нарушения одного из условий пребывания информации в определенном состоянии. Т.е. просто один из критериев оценки тех или иных свойств и состояний информации, но не более того. Оно не может существовать или не существовать. Оно просто есть везде, где есть информация. Вас же не смущает, что к информации применимо такое понятие как "информационная энтропия"? Вы же на задаетесь вопросом существования или не существования энтропии в программе расчета числа ПИ? Ну, замените слово "угроза" на "возможность перехода информации из одного состояния в другое по X-ой причине", так будет длинее и неудобнее, но смысл останется ровно тот же. То что информационная угроза есть, еще не значит она будет реализована или даже что она может быть реализована. А вот вероятность реализации угрозы вкупе с рядом других параметров типа ущерба, воспроизводимости, сложности реализации и т.п. называется риском и меры по обеспечению security информационной системы направлены на риски, а не на угрозы.
Здравствуйте, DOOM, Вы писали:
DOO>Я вот вообще каждый раз удивляюсь — почему Владимир работает в эксплуатации, а не в каком-нибудь консалтинге по вопросам ИБ.
Если бы ты знал, как этому удивляется сам Владимир...
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, DOOM, Вы писали:
DOO>>Настоящая безопасность всегда оперирует очень четкими почти математическими определениями.
FDS>В итоге дыр оставляют огромное количество, которые видны невооружённым взглядом. Математикой такие вещи в принципе невозможно описать, хотя, наверное, она может помочь, чтобы найти большее количество огрех.
Ну тебе уже много раз написали: не требуется устранить все дыры — это утопия.
Ну и если мы об уязвимостях говорим, то не надо забывать, что у каждой уязвимости есть характеристика exploitablity (кстати, кто даст адекватный русскоязычный аналог — уж тройку точно обещаю ).
Дак вот иной раз окружение не позволяет использовать эту уязвимость. Пример: но одной выставке по безопасности одна фирма, специализирующаяся на penetration testing'е рассказывала про то, что у всех могучих ERP есть куча уязвимостей, про которые забывают и привели кучу примеров. Дак вот — ни одна упомянутая уязвимость не была актуальна для нормально внедренной ERP (с соответсвующей КСЗИ).
Запомнилось хорошо почему-то фишка с учетной записью для бэкапов, которая по умолчанию без пароля и имеет возможность подключиться к некой шаре с бэкапом и типа забрать все данные. Возникает вопрос — а вы много внедрений ERP видели, где бэкап делается через шары в сети передачи данных? Я вот ни одного..
Здравствуйте, FDSC, Вы писали:
FDS>Параноидальность, например, это ведь тоже не от большого ума.
Это профессиональная деформация. У нас же часто в СБ садят пенсионеров ФСБшников и прочую братию. Они привыкли мыслить, что мы сказали — вы реализовали. И пофиг на все. Понятно, что в такой ситуации защита информации скорее мешает бизнесу, чем помогает.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, DOOM, Вы писали:
DOO>>Хорошее сравнение — системы контроля версий. Тоже блин, сложности какие-то лишние — только работать мешают, заразы. Ату их! FDS>Некоторые системы контроля версий тоже мешают работать.
Ключевое слово некоторые.
Нельзя экстраполировать опыт одной ситуации на все.
FDS>Кодёнок правильно перечислил кучу основных моментов, которые мешают не потому что так надо, а потому что так есть (бестолковость организации защиты)
Ты же согласен, что могут возникнуть точно такие же аргументы, если криво внедрить систему контроля версий или электронного документооборота (я это постоянно вижу).
FDS>Посмотри, DOOM, всё то же самое, что и у меня (http://rsdn.ru/forum/philosophy/3816680.1.aspx
), только теперь вместо ответа, что это бестолковость руководства, ты отвечаешь, что так и должно быть,
Нет. Ты меня неправильно понял. Я отвечаю, что это универсальные проблемы, присущие любой автоматизации, если она влияет на бизнес процесс. Это какую-нибудь ерунду типа DNS, DHCP, AD и прочей инфраструктурщины внедрить легко — тут не надо "ломать" пользователей. А все остальное — сложно. Чрезвычайно сложно.
В качестве эксперимента, можешь назвать мне отрасль, в которой вы занимаетесь автоматизацией и я попробую прикинуться таким же консервативным пользователем, которому ваша автоматизация только мешает — наверное тогда будет понятнее, что я имею ввиду
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, DOOM, Вы писали:
DOO>>Если интересно про математически, то советую погуглить "Basic Secuity Theorem" и главное работы с ее комментариями.
FDS>А как насчёт погуглить "McLean System-Z"?
Это попадает в разряд "работ с ее комментариями"
Cсылку на BST я дал только для демонтрации подхода (а не конкретного результата) — Белл с Ла Падулой не до конца довели идею, на самом деле их BST может быть сформулирована чисто абстрактно — есть модель системы, которая задается множеством состояний, функцией перехода и начальным состоянием. Есть условие безопасности системы, есть ограничения перехода (модель безопасности). Доказывается, что если в системе исходное состояние удовлетворяет условие безопасности, а все переходы соответсвуют ограничениям, то система остается безопасной.
Этот подход используется и во всех остальных моделях разграничения доступа — и в HRU, и в тех же моделях McLean'а и в модели ИПС и т.д.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Ну ок, с больничными действительно есть проблема, глупо спорить. Я вот тут внезапно узнал, что сейчас оформить себе командировку или отпуск без настраивания замещения уже невозможно.
Ну это тоже не вызовет восторга у пользователей.
KV>А фичу инициирования замещения не замещаемым уже реализуют. Так что happy end, все ок
Ну вот и замечательно.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Не слышу соболезнований, по поводу того, какой IMD мы используем
А я его в глаза не видел. Но подозреваю, что он такой же, как и прочие "лидеры рынка IDM".
Интересно, сколько времени понадобится Forefront Identity Manager'у, чтобы стать практически монополистом на этом рынке
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, minorlogic, Вы писали: M>>Вот опять абстрактные угрозы ... Ну какие угрозы существую для программы расчета ПИ? KV>Для абстрактной программы расчета ПИ существует масса абстрактных угроз M>>Вы как бы за кадром априори подразумеваете существование угроз ... причем абстрактных. KV>Это не я подразумеваю, если что. Вы просто путаете понятие риска с понятием угрозы, считая что это что-то такое с чем необходимо сразу же бороться, что оно несет негативный оттенок и т.п. Это не так.
В общем надо бы уже где-то тут засветить вот эту картинку:
А вообще я бы советовал 1-ю часть ОК прочитать всем
Это кто ж вам так криво сделал процедуру замещения? Конечно ей не пользуются — она же нежизненная ни фига. В какой реальной ситуации может потребоваться больному сотруднику предоставлять доступ на свой компьютер? Инициатором будет не он, это же очевидно. И решение принимать должен не он.
узнал, что сейчас оформить себе командировку или отпуск без настраивания замещения уже невозможно. А фичу инициирования замещения не замещаемым уже реализуют. Так что happy end, все ок 
) процесс замещения, который не будет отличаться от своего "некомпьютерного" собрата.
И вот хрен им, а не TMT. Пусть в визио рисуют и сами описания угроз вписывают 
