Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Ну ок, с больничными действительно есть проблема, глупо спорить. Я вот тут внезапно узнал, что сейчас оформить себе командировку или отпуск без настраивания замещения уже невозможно. DOO>Ну это тоже не вызовет восторга у пользователей.
Ну блин, часто у пользователей и сама необходимость делать свою работу не вызывает восторга, если что Я не считаю, что безопасность может когда-нибудь стать 100% удобной. Это ведь всегда какие-то ограничения свобод пользователей, будь то отсутствие определенных прав, ограничение на использование съемных дисков, антивирус мешающий качать кряки, запрет на закачку кряков, установку какого-либо софта или отсутствие прав админа. Тут все, что можно сделать — это попытаться максимально сгладить углы, чтобы все эти ограничения оказывали минимум негативного влияния на бизнес-процессы и, собственно, комфортность работы пользователей с ИС. И тут либо компромис, когда пользователи не очень недовольны и воспринимают ИБ как неизбежное зло, понимая необходимость всего это, и, в то же время, когда закрыто или минимизировано большинство рисков по ИБ. В противном случае, будет перекос либо в сторону довольных пользователей, либо перетянутых гаек
Здравствуйте, DOOM, Вы писали:
FDS>>А как насчёт погуглить "McLean System-Z"? DOO>Это попадает в разряд "работ с ее комментариями"
DOO>Cсылку на BST я дал только для демонтрации подхода (а не конкретного результата) — Белл с Ла Падулой не до конца довели идею
Ага, вот она очень хорошая демонстрация получилась: доказывали доказывали, да додоказывались.
Математикой вообще нельзя доказать безопасность, т.к. невозможно формализовать модель реальной системы. Поэтому все эти математические навороты могут быть полезны, но не более того. На них ничего нельзя основывать, потому что никто не знает, где и когда именно они откажут (или откажет их реализация).
Проблема в том, что действительно серьёзные вещи, где допускаются дыры, в принципе не имеют математических моделей, а всякие математические абстракции ведутся, в общем-то, для формализации лишь узкой части концепции системы, которая, собственно, может быть формализована.
Re[7]: О том, как плохо понимать термин безопасность по учеб
Здравствуйте, DOOM, Вы писали:
FDS>>В итоге дыр оставляют огромное количество, которые видны невооружённым взглядом. Математикой такие вещи в принципе невозможно описать, хотя, наверное, она может помочь, чтобы найти большее количество огрех. DOO>Ну тебе уже много раз написали: не требуется устранить все дыры — это утопия.
Ты прочитай ещё раз, что я написал: FDS>>В итоге дыр оставляют огромное количество, которые видны невооружённым взглядом.
Ещё раз повторю, чтобы было понятно: огромное количество дыр, т.е.очень много, эти дыры видны невооружённым взглядом, т.е. сев за взлом я за несколько дней нахожу способ залогиниться не зная пароля (заметь, при том, что я вовсе не специализируюсь на взломе).
Потому что кто-то привыкает, что вот "мы всё математически строго доказали" и на всё остальное кладёт большую кучу дерьма.
Та же Common Criteria, насколько мне помниться, не использует как таковых математических моделей, а вот требование, чтобы на каждую цель атаки и угрозу было в документации написано, какие контрмеры приняты, как цель защищена — такое требование есть.
DOO>Ну и если мы об уязвимостях говорим, то не надо забывать, что у каждой уязвимости есть характеристика exploitablity (кстати, кто даст адекватный русскоязычный аналог — уж тройку точно обещаю ).
Эксплуатируемость уязвимости не подойдёт?
Спасибо, тройка мне не нужна, не в ВУЗе учусь.
DOO>Дак вот иной раз окружение не позволяет использовать эту уязвимость. Пример: но одной выставке по безопасности одна фирма, специализирующаяся на penetration testing'е рассказывала про то, что у всех могучих ERP есть куча уязвимостей, про которые забывают и привели кучу примеров. Дак вот — ни одна упомянутая уязвимость не была актуальна для нормально внедренной ERP (с соответсвующей КСЗИ).
Что значит "для нормально внедрённой ERP"? Наверное, как раз для таких, для которых эта уязвимость не была актуальной?
Я не эта "одна фирма", которая что-то заявила, так что не надо приводить мне такой пример: я таких вещей никогда не заявлял.
Да и уж, если серьёзно подходить к делу, не важно, эксплуатируемый баг это (т.е. уязвимость), или просто потенциал, для нормальной системы нужно удалять все известные потенциалы атак. Не знаю уж, кем ты работаешь, но, видимо, ты не представляешь, какая иногда радость бывает, когда видишь, что при проектировании системы примерно так и относились к багам: если не доказано, что они эксплуатируемые, то не надо их устранять. Это означает: 1. Низкое качество кода 2. Как следствие, ненулевую и достаточно высокую вероятность найти дырку
А вот когда видишь, что в системе не то что простейших багов нет, но ещё и при вводе некорректных данных тебе вежливое сообщение выводится, что, мол, извини чел, вот эти данные некорректны там-то и там-то, вот тут одно расстройство.
DOO>Запомнилось хорошо почему-то фишка с учетной записью для бэкапов, которая по умолчанию без пароля и имеет возможность подключиться к некой шаре с бэкапом и типа забрать все данные. Возникает вопрос — а вы много внедрений ERP видели, где бэкап делается через шары в сети передачи данных? Я вот ни одного..
1. По умолчанию без пароля — в любом случае плохо.
2. Фишка эта — фигня, конечно. Это значит, что просто багов нормальных не искали, а просто прорекламировать себя хотели
Здравствуйте, DOOM, Вы писали:
FDS>>Некоторые системы контроля версий тоже мешают работать. DOO>Ключевое слово некоторые. DOO>Нельзя экстраполировать опыт одной ситуации на все.
Ну да. Но когда говорят, что они мешают работать, то это имеются в виду явно все.
FDS>>Кодёнок правильно перечислил кучу основных моментов, которые мешают не потому что так надо, а потому что так есть (бестолковость организации защиты) DOO>Ты же согласен, что могут возникнуть точно такие же аргументы, если криво внедрить систему контроля версий или электронного документооборота (я это постоянно вижу).
Естественно. Но пока система не начала работать нормально — к использованию она не пригодна.
Поэтому логика, что, давайте мы не будем излишне напрягаться часто срабатывает. Хотя часто она срабатывает слишком сильно, и потом люди носятся с больной головой: то заказы воруют, то кто-то нахамил покупателю, а кто — непонятно, то кому-то зарплату не выдали, а деньги ушли куда-то, то ещё что.
FDS>>Посмотри, DOOM, всё то же самое, что и у меня (http://rsdn.ru/forum/philosophy/3816680.1.aspx
), только теперь вместо ответа, что это бестолковость руководства, ты отвечаешь, что так и должно быть, DOO>Нет. Ты меня неправильно понял. Я отвечаю, что это универсальные проблемы, присущие любой автоматизации, если она влияет на бизнес процесс. Это какую-нибудь ерунду типа DNS, DHCP, AD и прочей инфраструктурщины внедрить легко — тут не надо "ломать" пользователей. А все остальное — сложно. Чрезвычайно сложно.
Ага, но безопасность сама по себе должна быть адекватной. Если она не адекватна, то она может нанести больше вреда, чем пользы. И Кодёнок это очень правильно отметил
DOO>В качестве эксперимента, можешь назвать мне отрасль, в которой вы занимаетесь автоматизацией и я попробую прикинуться таким же консервативным пользователем, которому ваша автоматизация только мешает — наверное тогда будет понятнее, что я имею ввиду
Прикидываться не надо. Мои пользователи никогда не жалуются на то, что мои программы мешают (а если мешают, я убираю то, что мешает). Исключение составляют программы для автоматизации тестов: тут разработчики часто жалуются, что слишком много тестов — слишком много багов.
А вот то, что жалуются на безопасность я вижу сплошь и рядом даже там, где, казалось бы, никакой и безопасности нет.
Значит с ней проблемы есть, в отличие от автоматизации других процессов.
Re[8]: О том, как плохо понимать термин безопасность по учеб
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, DOOM, Вы писали:
DOO>>exploitablity (кстати, кто даст адекватный русскоязычный аналог — уж тройку точно обещаю ).
KV>А чем, собственно, сама "эксплуатируемость" не нравится?
Например, тем, что gramota.ru такого слова не знает. Да и в целом об него в документации точно спотыкаться будешь.
Re[8]: О том, как плохо понимать термин безопасность по учеб
Здравствуйте, FDSC, Вы писали:
FDS>Ты прочитай ещё раз, что я написал: FDS>FDS>>В итоге дыр оставляют огромное количество, которые видны невооружённым взглядом. FDS>Ещё раз повторю, чтобы было понятно: огромное количество дыр, т.е.очень много, эти дыры видны невооружённым взглядом, т.е. сев за взлом я за несколько дней нахожу способ залогиниться не зная пароля (заметь, при том, что я вовсе не специализируюсь на взломе).
Даже это не всегда критично
Например, если речь о внутренней сети и там применяются хорошие средства сбора и анализа событий, то такие твои действия тут же засекут — по голове настучат, второй раз не полезешь. В этом отношении я всегда привожу пример: на работе мало у кого компьютер гвоздями к столу прибит — однако почему-то не тащат.
Или, например, знаменитая фишка про хакеров и директора столовой — нельзя сказать, что они находили несуществующие дыры...
FDS>Потому что кто-то привыкает, что вот "мы всё математически строго доказали" и на всё остальное кладёт большую кучу дерьма.
Если кто-то привык все математически доказывать, то у него в продукте бардака, скорее всего, не будет
FDS>Та же Common Criteria, насколько мне помниться, не использует как таковых математических моделей, а вот требование, чтобы на каждую цель атаки и угрозу было в документации написано, какие контрмеры приняты, как цель защищена — такое требование есть.
А там еще есть, так называемые, требования к среде и предположения безопасности. И можно в предположении написать, что все пользователи системы четко следуют инструкции
FDS>Эксплуатируемость уязвимости не подойдёт?
Нет, не подойдет — см. выше ответ Владимиру.
FDS>Что значит "для нормально внедрённой ERP"? Наверное, как раз для таких, для которых эта уязвимость не была актуальной?
Речь шла о вполне конкретной ERP из 3-х букв. Просто я утверждаю, что у кого хватило денег на такую систему, хватит денег и на нормальную SAN и решение SAN-2-SAN backup, так что данные резервной копии никогда не попадут в сеть передачи данных.
FDS>Я не эта "одна фирма", которая что-то заявила, так что не надо приводить мне такой пример: я таких вещей никогда не заявлял.
Я тебе показал конкретный пример, казалось бы явной уязвимости, exploitability которой нулевой.
FDS>Да и уж, если серьёзно подходить к делу, не важно, эксплуатируемый баг это (т.е. уязвимость), или просто потенциал, для нормальной системы нужно удалять все известные потенциалы атак.
В результате система никогда не будет написана. Ты еще предложи контроль НДВ каждый раз проводить
FDS>Не знаю уж, кем ты работаешь, но, видимо, ты не представляешь, какая иногда радость бывает, когда видишь, что при проектировании системы примерно так и относились к багам: если не доказано, что они эксплуатируемые, то не надо их устранять.
Если они это адекватно оценили, то приведенные тобой следствия крайне сомнительны — если они и имеют место, то по какой-то иной причине. А если они на ходу стали придумывать отговорки, то это уже совсем другое дело.
FDS>А вот когда видишь, что в системе не то что простейших багов нет, но ещё и при вводе некорректных данных тебе вежливое сообщение выводится, что, мол, извини чел, вот эти данные некорректны там-то и там-то, вот тут одно расстройство.
DOO>>Запомнилось хорошо почему-то фишка с учетной записью для бэкапов, которая по умолчанию без пароля и имеет возможность подключиться к некой шаре с бэкапом и типа забрать все данные. Возникает вопрос — а вы много внедрений ERP видели, где бэкап делается через шары в сети передачи данных? Я вот ни одного.. FDS>1. По умолчанию без пароля — в любом случае плохо.
Почему? Докажи эту позицию. iSCSI target тоже частенько без пароля создается, но его там и включают-то редко.
FDS>2. Фишка эта — фигня, конечно. Это значит, что просто багов нормальных не искали, а просто прорекламировать себя хотели
Ну у них много было — но почти каждый также отбивался: вокруг ERP такое окружение, что эксплуатировать эти дыры невозможно. Ну а шарага эта в рекламе особо не нуждается — ИМХО, каждый безопасник имел с их продуктами дело.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, DOOM, Вы писали:
FDS>>>А как насчёт погуглить "McLean System-Z"? DOO>>Это попадает в разряд "работ с ее комментариями"
DOO>>Cсылку на BST я дал только для демонтрации подхода (а не конкретного результата) — Белл с Ла Падулой не до конца довели идею FDS>Ага, вот она очень хорошая демонстрация получилась: доказывали доказывали, да додоказывались.
Это демонстрация одной конкретной ошибки одних конкретных исследователей, не более того.
Причем не столько ошибки в результате, сколько в его обобщении.
Тот же McLean, если чо, очень много вариантов улучшения модели Бэла Ла Падула предложил — тот же Low watermark.
FDS>Математикой вообще нельзя доказать безопасность, т.к. невозможно формализовать модель реальной системы.
А мужики-то не знали (с)
И зачем же тогда есть модели HRU, take-grant, модель ИПС, MMS, low watermark и прочее?
FDS>Поэтому все эти математические навороты могут быть полезны, но не более того. На них ничего нельзя основывать, потому что никто не знает, где и когда именно они откажут (или откажет их реализация).
Я даже не знаю какое понятное сравнение привести. Это примерно, как заявлять — зачем нужна теория алгоритмов? От нее багов все равно меньше не становится!
Модели разграничения доступа нужны были чтобы выбрать адекватные подходы к их реальному построению. Чтобы убедиться, что чистая модель мандатного доступа безопасна, но неэксплуатируема, что модель на основе матрицы доступа всегда имеет риск утечки права, что модель ИПС безопасна, но реализовать ее сложно и т.п.
FDS>Проблема в том, что действительно серьёзные вещи, где допускаются дыры, в принципе не имеют математических моделей, а всякие математические абстракции ведутся, в общем-то, для формализации лишь узкой части концепции системы, которая, собственно, может быть формализована.
Из этого надо делать вывод, что они не нужны и неадекватны?
Все имеет границы применимости.
Здравствуйте, FDSC, Вы писали:
FDS>Ну да. Но когда говорят, что они мешают работать, то это имеются в виду явно все.
У меня на работе безопасность, собственно работе, не мешает. Делая такое же обобщение, я могу сказать, что проблем никаких нет
DOO>>Нет. Ты меня неправильно понял. Я отвечаю, что это универсальные проблемы, присущие любой автоматизации, если она влияет на бизнес процесс. Это какую-нибудь ерунду типа DNS, DHCP, AD и прочей инфраструктурщины внедрить легко — тут не надо "ломать" пользователей. А все остальное — сложно. Чрезвычайно сложно.
FDS>Ага, но безопасность сама по себе должна быть адекватной. Если она не адекватна, то она может нанести больше вреда, чем пользы. И Кодёнок это очень правильно отметил
А в чем у них собственно неадекватность безопасности? У них криво реализован принцип наименьшего доступа — это правильно на самом деле. Когда у него какая-нибудь блондинка легким движением мыши похерит всю работу за день, он это осознает.
FDS>Прикидываться не надо. Мои пользователи никогда не жалуются на то, что мои программы мешают (а если мешают, я убираю то, что мешает).
Не верю. Либо у тебя очень ограниченное число потребителей этой программы, либо ты далеко не все знаешь.
Re[9]: О том, как плохо понимать термин безопасность по учеб
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, DOOM, Вы писали:
DOO>>Например, тем, что gramota.ru такого слова не знает. Да и в целом об него в документации точно спотыкаться будешь.
S>Чем классика "применимость/критичность" не устраивает?
Критичность это точно не то.
Вот рассмотрим расчет базового уровня уязвимости CVSS. Там следующие параметры:
Уже на их основании расcчитывается Impact (ущерб) и Exploitability (?).
Критичность — это уже метрика, которая зависит от значения базового уровня (т.е. слово занято).
Применимость — тоже не то по смыслу. Эксплуатируемость ближе, но, как я уже сказал, для технической документации не годится.
Сложность применения — уже вроде как занято в Access Complexity.
Ну и т.п.
Re[11]: О том, как плохо понимать термин безопасность по уче
Здравствуйте, DOOM, Вы писали:
DOO>Критичность это точно не то.
Тогда составные термины аля "эффективный (результирующий) уровень (степень, стойкость) уязвимости". Лучше сегодня не спрашивайте — мозг тяжело поражён канцеляризмом.
Re[12]: О том, как плохо понимать термин безопасность по уче
S>Тогда составные термины аля "эффективный (результирующий) уровень (степень, стойкость) уязвимости".
Вот так оно пока примерно и выглядит в документах
Здравствуйте, DOOM, Вы писали:
Кё>>И т.д. И т.п. Общедоступная шара — это простой интерфейс, я кладу, они берут, мне надо, я беру. Запросы через кого-то — это интерфейс, который 5-минутное дело рястягивает на сутки (это если никто не в отпуске и не с ненормированным графиком). Какой человек в своем уме захочет его использовать? DOO>Угу. А потом начнется: DOO>Какой "?№!№ удалил мой файл? DOO>Хорошее сравнение — системы контроля версий. Тоже блин, сложности какие-то лишние — только работать мешают, заразы. Ату их!
Плохое сравнение, никак не пересекающееся с описанной мной проблемой. Системы контроля версий у нас любят и не избегают, а папки проектов — не любят и избегают.
Кё>Плохое сравнение, никак не пересекающееся с описанной мной проблемой. Системы контроля версий у нас любят и не избегают, а папки проектов — не любят и избегают.
Ну вот ты опять свою частную ситуацию обобщаешь на все остальное.
Я много раз видел именно такое — негативное отношение к системам контроля версий. Или к системам управления документами — тоже самое "Да ну, блин. Сложно там как-то — check in/check out всякий. Мне проще так — по-старинке и т.п.". Это естественная реакция человека, чтобы ее побороть надо:
1. Сделать так, чтобы переход на что-то новое не был революционным (например, сделать вам пресловутые проектные папки, но для начала не настраивать там разграничение доступа вообще, потом привыкните — начать гайки закручивать).
2. Сделать так, чтобы работать по-старому было невозможно (например, запретить создание шар на рабочих станциях с помощью групповой политики).
В вашем случае — СБ сделала вид, что решила проблему, вы сделали вид, что вас устраивает. В общем-то все недовольны, поставленные цели не достигнуты. Однако плачут, но кактус жуют... По-хорошему ваше непосредственное руководство должно бы было инициировать обсуждение вопроса на соответствующем уровне — тогда бы что-то менялось.
Здравствуйте, Кодёнок, Вы писали:
Кё>Вторжение — не их проблема, защита от него — не их обязанности.
Это не совсем так. Коль скоро сотруднику в силу исполнения его служебных обязанностей, был предоставлен доступ к информации, составляющей коммерческую тайну, он несет ответственность за ее неразглашение в рамках своих полномочий, что закреплено даже в ТК, вообще-то (п. 6 ч. 1 ст. 81 ТК РФ). Не говоря уже об умышленных действиях по разглашению КТ, которые рассматриваются уже на уровне УК (ст.183 ч.2).
Кроме того, компания, в которой предпринимаются меры по защите КТ (а не просто юридически-необоснованно закручиваются гайки везде и вся), под роспись ознакамливает сотрудников при приеме на работу с условиями, на которых им будет предоставлен доступ к КТ (а он будет предоставлен практически каждому сотруднику, т.к. это необходимо для того, чтобы он мог исполнять свои обязанности). Как правило там есть примерно такие два пукнта:
1. Работники Компании несут персональную ответственность за соблюдение режима коммерческой тайны на конкретном участке работы в пределах своих должностных обязанностей в соответствии с настоящим документом.
2. Работник Компании может быть привлечен к ответственности в случаях:
• умышленного или неосторожного разглашения ИКТ;
• утраты материальных носителей ИКТ;
• нарушения требований настоящего Порядка и других регламентирующих документов Компании в части вопросов доступа и работы с ИКТ.
Поэтому, процитированное в самом верху утверждение, вообще говоря действительности не очень соответствует. Кое-что входит и в обязанности каждого такого сотрудника.
Здравствуйте, Кодёнок, Вы писали:
Кё>Мой пример: для обмена файлами есть папки проектов, куда имеют доступ только участники проектов. Но все продолжают пользоваться общедоступной шарой. Если ее закрыть, открывают свою.
Описанная ситуация с шарой и творческими людьми, обычно широко распространена в стартапах и небольших компаниях, где во-первых, обеспечение информационной безопасности стоит на задних планах, а во вторых, имеет место обычное человеческое доверие между членами всего небольшого коллектива, без которого этот стартап развалится еще до того, как в полный рост успеют проявиться проблемы по ИБ. А когда коллектив вырастает, и в нем начинают появляться сотрудники, доверять которым в общем-то не следовало бы, то рано или поздно наступает час Х когда руководство компании впервые знакомится с таким понятием, как инцидент по ИБ. И шары обычно заканчиваются очень быстро. А у особо впечатлительного руководства после побежденных шар может проснуться кураж и все компы окажутся закованными в железные ящики с амбарными замками и огромными красными кнопками питания в качестве единственного элемента этого дизайнерского решения. Кто считает, что я шучу, welcome вот сюда
. После того же, как такое руководство с удивлением обнаруживает, что железные ящики, в общем-то не очень спасают, начинается накрутка гаек туда, где и резьбы-то никогда не было. Доступ в интернет организовывается только с одного терминального сервера, причем перечень приложений, которые там можно запустить жестко регламентирован. У сотрудников отбираются права локальных админов (это у разработчиков, если что), а их трафик подлежит регулярному ревью назначенными на это дело лицами. Но и это не спасает, поэтому начинаются репрессии и здесь, на RSDN, в форуме "Предложения о работе от прямых работодателей" с завидной регулярностью начинают появляться вакансии в эту контору.
Предыдущий абзац описывает совершенно реальную контору, название которой можно найти по приведенной ссылке. Все описанное там я видел собственными глазами и готов подтвердить, в случае чего. Правда было это, где в 2004-2005 году, а сейчас, насколько я знаю, там с этим немного попроще. Но немного.
Так вот, описанное выше не имеет никакого отношения к информационной безопасности, это какая-то пародия на нее, случившаяся из-за того, что кто-то решил, что он лучше экспертов по безопасности знает, как правильно защитить информационные активы компании и как организовать при этом работу с персоналом. Из-за того, что кто-то решил, что лишь техническими мерами он сможет закрыть все риски, которые в общем-то тоже никто и не считал. И вот после таких контор, у людей и формируется мнение об ИБ, как о драконах, загоняющих творческих сотрудников в какие-либо немыслимые рамки. Но к правильному управлению ИБ это не имеет никакого отношения.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Кодёнок, Вы писали:
Кё>>Вторжение — не их проблема, защита от него — не их обязанности.
KV>Это не совсем так. Коль скоро сотруднику в силу исполнения его служебных обязанностей, был предоставлен доступ к информации, составляющей коммерческую тайну, он несет ответственность за ее неразглашение в рамках своих полномочий, что закреплено даже в ТК, вообще-то (п. 6 ч. 1 ст. 81 ТК РФ). Не говоря уже об умышленных действиях по разглашению КТ, которые рассматриваются уже на уровне УК (ст.183 ч.2).
Это конечно все так. Но у нас и пьяными за руль садятся, хотя и за это есть ответственность. По этой причине надо все-таки с конечного пользователя максимум обязанностей по защите информации снимать или делать так, чтобы их исполнение было легким и непринужденным.
Здравствуйте, DOOM, Вы писали:
DOO>А вообще я бы советовал 1-ю часть ОК прочитать всем
Ты думаешь, без ссылки кто-нибудь решится на поиск таинственных буковок "ОК"? А те, кто решатся, будут искать 50/50, одни "Оранжевую Книгу", вторые "Общие Критерии"
).
