сообщение, но там обсуждение ушло куда-то в совсем технические дебри, поэтому отвечу отдельной темой, ибо чистая философия
Процитирую фразу мыщъха оттуда:
безопасность -- это буззворд. юзеры это слово любят и повторяют как мантру, но оценить безопасность не может даже эксперт по этой самой безопасности
и, чуть ниже по ветке:
это можно доказать. строго и математически
Для тех, кому лень читать весь следующий поток сознания, вот сухая выжимка сказанного мной ниже:
безопасность — это не баззворд, просто это понятие дискредитировано недобросовестными поставщиками. юзеры это слово не любят и повторяют как ругательство, ибо неизбежные ограничения их свобод, а эксперт по безопасности вполне в состоянии оценить эту самую безопасность. И, таки-да, это можно доказать строго и математически (я хз как математически, но логически — легко)
Спасибо за внимание
Всех, кого данный посыл заинтересовал, прошу под кат.
Собственно, кат
А теперь, я, с вашего позволения, чуть-чуть пофилософствую, ибо осознания того, что я занимаюсь ненужным делом не только в свое свободное время, как мы недавно выяснили, но еще и в рабочее, моя изнеженная психика просто не вынесет
Для начала, попробую доказать утверждение мыщъха о том, что оценить безопасность нельзя:
Информационная система, по определению, есть система обработки, хранения и передачи информации. Именно у информации есть состояние безопасности. Информация находится в состоянии безопасности тогда, когда выполняются ровно три условия:
1. Она конфиденциальна, т.е. ее могут получить только те приемники, которые имеют на это право
2. Она целостна, т.е. ее передача от источника А к приемнику Б не вносит изменений в нее
3. Она доступна, т.е. все приемники, имеющие право получать эту информацию, могут получить ее в данный момент времени
А давайте теперь прикинем: можем ли мы заложить необходимые и достаточные "метаусловия" выполнения этих условий в саму информацию? Конфиденциальность — да, информация, например, может быть зашифрована ключом, который есть только у лиц, имеющих право на доступ к ней. Целостность — тоже да, ибо коды коррекции, цифровые подписи и т.п. Доступность... упс. Доступность зависит от таких внешних факторов, как например, канал передачи информации. Т.е. мы можем лишь обеспечить лишь необходимые условия доступности при кодировании информации (например, использовать алгоритм кодирования известный принимающей стороне), но этого еще недостаточно для обеспечения ее доступности.
А следовательно (внимание, это очень важно), мы не можем оценить состояние безопасности информации, рассматривая ее в отрыве от ИС, в которой она хранится, обрабатывается и передается. Не вопрос, давайте рассмотрим и ИС. Чем там у нас является ИС по определению? "Совокупностью программных и технических средств, обеспечивающих хранение, обработку и передачу информации". А что такое программные средства в архитектуре Фон-Неймана (и не только в ней, как мы однажды выяснили)? Да точно такая же информация с тем же самым состоянием безопасности и условиями для его обеспечения, оценить которое в отрыве от ИС, обрабатывающей эту информацию мы не можем. А чем у нас является ИС? См. выше. Чтобы добить спрошу: а с какой вероятностью конечная информация находится в состоянии безопасности, если ИС третьего уровня вложенности в этом состоянии не находится? И вот пока мы не пройдем по всей этой рекурсии вплоть до микрокода процессора, в лучшем случае, или до взаимодействия элементарных частиц в кристаллах кремния в худшем, мы строго-логически не может сколь-нибудь точно измерить безопасность всей этой эко-системы.
Тут ты совершенно прав. Неправ ты в том, что измерить-то ее нельзя, но вот оценить вполне можно. В реальном мире никого не волнует насколько уязвима система, и никто не требует столь детальной оценки ее безопасности. Как правило, это происходит следующим образом: "Володя, вот наша новая система е-платежей, которую для нас разработал подрядчик, вот ее исходники (30-40Мб архива), через неделю дай свою оценку по ее готовности к эксплуатации в продуктиве". И если маркетологи прогнозируют существенный доход от этой системы (а они всегда прогнозируют существенный доход от своих систем), то если я через неделю хотя бы заикнусь о том, что мол система наверное небезопасна, потому что я успел дойти только до микрокода и в продуктив ее нельзя, меня уволят нахрен в тот же день, потому что от меня ждут ровно двух вещей:
1. Выявления рисков информационной безопасности, существующих в этой системе
2. Рекомендаций по их устранению, или минимизации ущерба в случае их реализации
Выделенное — важно, потому что если прогнозируемый, но минимизированный ущерб несоизмерим с ожидаемой прибылью, то система будет запущена в эксплуатацию, какой-бы дырявой она не была. Разумеется при этом учитывается не только ущерб в финансовом отношении, но и репутационный, косвенный от возможных судебных исков и т.п. Но учитывается он также приближенно, как и уровень прибыли маркетологами, поэтому в целом, для бизнеса, данный подход является более чем приемлемым. Об одном из подходов я подробно писал здесь
Считаться же баззвордом это понятие стало от того, что на фоне реальной сложности с проведением такой оценки, многие security-компании стали этим бессовестно пользоваться, чтобы впихнуть свои решения или услуги доверчивым клиентам. Но то, что ими это понятие активно дискредитируется, еще не значит, что оно на самом деле таковым является.
Если же говорить о математической строгости, то можно математически строго доказать небезопасность любой реализованной информационной системы и разговаривать, в общем-то, будет больше не о чем. Но жить тогда станет совсем скучно
KV>безопасность — это не баззворд, просто это понятие дискредитировано недобросовестными поставщиками. юзеры это слово не любят и повторяют как ругательство, ибо неизбежные ограничения их свобод, а эксперт по безопасности вполне в состоянии оценить эту самую безопасность. И, таки-да, это можно доказать строго и математически (я хз как математически, но логически — легко)
Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, minorlogic, Вы писали: M>>Вот опять абстрактные угрозы ... Ну какие угрозы существую для программы расчета ПИ? KV>Для абстрактной программы расчета ПИ существует масса абстрактных угроз M>>Вы как бы за кадром априори подразумеваете существование угроз ... причем абстрактных. KV>Это не я подразумеваю, если что. Вы просто путаете понятие риска с понятием угрозы, считая что это что-то такое с чем необходимо сразу же бороться, что оно несет негативный оттенок и т.п. Это не так.
В общем надо бы уже где-то тут засветить вот эту картинку:
А вообще я бы советовал 1-ю часть ОК прочитать всем
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, vmpire, Вы писали:
V>>"Безопастность" — это абстрактное понятие, которое ничего конкретного не означает, и, соответственно, не может быть не измерено не оценено. KV>Оно означает отношение среднего-арифметического оценки незакрытых рисков к среднему арифметическому оценки их общего числа
Это просто одна из метрик, собираемых по рискам. Таких метрик можно придумать много, они, бесспорно, полезны, но, на мой взгляд, к безопасности отношения не имеют.
V>>Именно в этом смысле оно обычно употребляется маркетологами. KV>Мы говорим о разных маркетологах, если что. Я, упоминая "маркетологов" имел ввиду тех, кто заинтересован в вводе в экплуатацию какой-либо системы, не связанной с непосредственно обеспечением безопаностьи. Можно заменить моих "маркетологов" на "финансистов" или "технарей", чтобы не смущало.
Это меняет дело. В таком случае, ваши маркетологи явно имеют в виду под безопасностью что-то конкретное. Только нужно узнать у них, что именно
KV>Я подобные вопросы слышу ежедневно, если что Вот только звучат они несколько иначе: KV>(решается вопрос о вводе в эксплуатацию новой системы) KV>1. Разработчики: вот наша безопасная система KV>2. Я: почему вы считаете ее безопасной? KV>3. Разработчики: данные передаются по https KV>4. Я: Зачем? (там оно нафиг не упало, весь трафик шифровать) KV>5. Разработчики: чтобы удовлетворить требования по ИБ к системе KV>6. Я: И? Ну ок, а с repudiation вот тут и denial of service вот здесь, что будем делать? KV>7. Разработчики: С чем? Вы нам напишите четко, что вас не устраивает и как должно быть, у нас все сроки в прошлом полугодии вышли, а вы нам внедрение тормозите (еще и руководству жалуются иногда, чтобы наверняка прикрыться).
Ой, как это всё знакомо...
Конечно, поставим firewall и наша система будет безопасной
KV>Я конечно описал крайний случай, но разработчики крайне редко общаются с безопасниками в терминах "угрозы-риски-контрмеры", это безопасники общаются с ними именно так. А в целом — да, вы правы. Плясать нужно от конкретных угроз, а не гоняться за химерами. Почитайте мое сообщение по той ссылке.
V>>То есть, по моему мнению, специалист по безопасности занимается вполне конкретной работой. Только результирующая оценка "безопасности" это нечто гораздо большее, чем одно число, показывающее "безопасность системы в процентах". KV>Ну, у нас это отчет, описывающий все выявленные риски, их критичность, сценарии атак и рекомендации по устранению или минимизации. Но руководству по итогам работы прхиодит именно одно число, по формуле, которую я привел в начале. Ибо руководство банально не поймет того, что в этих отчетах написано, а цифра нагляднее и понятнее.
Можно хотя бы выдавать не одно число а три-четыре. Это руководство, обычно, осиливает.
Типа, "безопастность от внутренних угроз", "безопастность от внешних угроз", "безопастность от потери данных", "безопастность от разглашения данных".
Заодно, так можно лучше объяснить, над чем сейчас идёт работа.
Здравствуйте, MozgC, Вы писали:
IT>>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
MC>Юзер зачастую не способен правильно оценить опасность и может считать предлагаемые для повышения безопасности действия — излишней параноидальностью. Некоторые даже приклеивают sticky notes с паролями на монитор, а когда им запрещаешь это делать — они считают это параноидальностью
Во! У меня как раз есть хороший пример с паролями и бестолковостью админов (надеюсь бывшей) одной большой компании. Когда-то давным давно в IBM мне нужно было иметь с десяток паролей от разных систем. У всех систем было разное время истечения срока паролей, разные требования и т.п. Например, в одной из них было требование к паролю ровно 8 символов. 8, не 4, не 10, а именно 8 и только 8. Запомнить десяток разношёрстных и постоянно меняющихся паролей я, естественно, не мог и закончилось всё, само-собой, файликом passwords.txt на десктопе. Когда я пришёл работать в Morgan Stanley, то меня приятно удивило насколько люди в этой конторе понимают эту проблему и сколько в неё вкладывают. В частности и я сам как разработчик обязан следовать определённым правилам. В MS у меня один пароль, ровно один (кроме payroll системы, но это отдельная история). Кроме этого каждый сотрудник компании должен прослушать специальный обучающий курс, где как раз всё чётко сказано и разъяснено и насчёт безопасности вообще и мониторов в частности.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, kochetkov.vladimir, Вы писали:
IT>>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
KV>В идеале — да. Но у нас юзеры не любят, к примеру, что им предоставляют только те полномочия во внутренних системах, которые им необходимы для исполнения их служебных обязанностей. Например админ, у которого в обязанности входит администрирование лишь одного куста в иерархии AD, почему-то требует права домен-админа и не получив их, клянет именно безопасность в том, что ему вставляют палки в колеса. Или вот еще, юзеры очень не любят, что у нас запрещено работать под чужой учеткой и также клянут нас за это при любом удобном случае. Где тут что-то из перечисленного тобой?
Мой пример: для обмена файлами есть папки проектов, куда имеют доступ только участники проектов. Но все продолжают пользоваться общедоступной шарой. Если ее закрыть, открывают свою.
Почему?
Потому что дизайнер не может эскиз положить, у него прав не оказалось, надо ждать до завтра, пока откроют.
Потому что пришел новенький, ему еще не завели, и что его теперь, домой отправлять?
Потому что баг пересекся с другим отделом, надо выцеплять кого-то, чтобы тебе дали инсталлер их софтины.
Потому что четкое разграничение прав — это как идеальная женщина, не может существовать и ее характеристики противоречат сами себе. Всегда, постоянно надо сделать что-то, на что прав быть не должно, но в этот конкретный раз — очень надо.
И т.д. И т.п. Общедоступная шара — это простой интерфейс, я кладу, они берут, мне надо, я беру. Запросы через кого-то — это интерфейс, который 5-минутное дело рястягивает на сутки (это если никто не в отпуске и не с ненормированным графиком). Какой человек в своем уме захочет его использовать?
Самое главное, эта бюрократия тормозит самых ценных, увлеченных людей, которые могут сделать все и сразу, если не вставлять им палки в колеса. А лодырям дает оправдания: не сделал, прав не было, все еще не сделал, ответа жду, через три дня родил.
Здравствуйте, IT, Вы писали:
IT>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
Прям-таки любых?
Обобщать-то не надо. Идеальная система должна работать незаметно для пользователя, иначе может сработать:
— отторжение самой системы (ну с этим еще можно справится)
— эффект компенсации риска (а вот с этим хуже).
Примером последнего могут служить такие интересные факты, что повышение безопасности автомобиля слабо влияет на общее число жертв ДТП — поставили ABS, стали хуже соблюдать дистанцию, понаставили ремней, подушек и т.п. — стали гонять под 200 и так далее.
Здравствуйте, DOOM, Вы писали:
DOO>Я вот вообще каждый раз удивляюсь — почему Владимир работает в эксплуатации, а не в каком-нибудь консалтинге по вопросам ИБ.
Если бы ты знал, как этому удивляется сам Владимир...
Здравствуйте, DOOM, Вы писали:
DOO>А вообще я бы советовал 1-ю часть ОК прочитать всем
Ты думаешь, без ссылки кто-нибудь решится на поиск таинственных буковок "ОК"? А те, кто решатся, будут искать 50/50, одни "Оранжевую Книгу", вторые "Общие Критерии"
И, таки-да, это можно доказать строго и математически (я хз как математически, но логически — легко)
Если интересно про математически, то советую погуглить "Basic Secuity Theorem" и главное работы с ее комментариями.
KV>Всех, кого данный посыл заинтересовал, прошу под кат.
Поехали
KV>1. Выявления рисков информационной безопасности, существующих в этой системе KV>2. Рекомендаций по их устранению, или минимизации ущерба в случае их реализации
s/риск/угроза
Риск реализовать нельзя, правда угрозу устранить тоже (кстати, это просто-таки ключевой момент, который упорно не понимают наши регуляторы: можно хоть их кожи вон лезть, но объективная угроза, например, ограбления квартиры будет существовать всегда и повлиять на ее существование невозможно, а вот затруднить реализацию — всегда пожалуйста).
KV>Если же говорить о математической строгости, то можно математически строго доказать небезопасность любой реализованной информационной системы и разговаривать, в общем-то, будет больше не о чем. Но жить тогда станет совсем скучно
С другой стороны можно доказать безопасность нереализованной. Между прочим знаменитая оранжевая книга писалась не вдруг, а было очень много исследований на тему и постулаты TCSEC'а во многом переплетаются с базовыми аксиомами теоретических моделей защищенных компьютерных систем.
И еще по поводу точных оценок — рассчитать надежность, например, отдельно взятого самолета тоже невозможно... Но мы же считаем эту технику надежной и никто не говорит, что это баззворд. Потому что есть оценка этой самой надежности. И этим занимается теория функциональной безопасности (правда тут безопасность — safety, а не security). Есть даже международные стандарты в этой области (например, ISO 61508).
сообщение, но там обсуждение ушло куда-то в совсем технические дебри, поэтому отвечу отдельной темой, ибо чистая философия
KV>Процитирую фразу мыщъха оттуда:
KV>
KV>безопасность -- это буззворд. юзеры это слово любят и повторяют как мантру, но оценить безопасность не может даже эксперт по этой самой безопасности
KV>и, чуть ниже по ветке:
KV>
KV>это можно доказать. строго и математически
KV>Для тех, кому лень читать весь следующий поток сознания, вот сухая выжимка сказанного мной ниже:
KV>
KV>безопасность — это не баззворд, просто это понятие дискредитировано недобросовестными поставщиками. юзеры это слово не любят и повторяют как ругательство, ибо неизбежные ограничения их свобод, а эксперт по безопасности вполне в состоянии оценить эту самую безопасность. И, таки-да, это можно доказать строго и математически (я хз как математически, но логически — легко)
"Безопастность" — это абстрактное понятие, которое ничего конкретного не означает, и, соответственно, не может быть не измерено не оценено. Именно в этом смысле оно обычно употребляется маркетологами.
Но вот "Безопастность чего-то от чего-то" — уже вполне конкретный термин, с которым можно работать (оченивать, доказывать...)
"Безопастность" не существует без отрыва от модели угроз и описания предмета защиты. А если вышеуказанное описано, то не возникает вопроса о безопасности уровня процессора и ниже.
Сравните, к примеру, несколько вопросов к специалисту по безопасности и подумайте, какие могут быть ответы:
1. Мы передаём информацию по https. Это безопасно?
2. Мы передаём информацию по https. Считаем угрозой перехват передаваемых данных в канале передачи. Это безопасно?
3. Мы передаём информацию по https. Считаем угрозой перехват информации через взлом нашего web-сервера из внутренней сети. Это безопасно?
4. Мы передаём информацию по https. Считаем угрозой перехват факта передачи информации другой стороне. Это безопасно?
То есть, по моему мнению, специалист по безопасности занимается вполне конкретной работой. Только результирующая оценка "безопасности" это нечто гораздо большее, чем одно число, показывающее "безопасность системы в процентах".
А именно оно зачастую нужно маркетологу
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>А мы коллеги, я так понимаю?
Частично. Мне приходилось пару раз делать аудит секьюрити системы, но это не основное моё занятие. Основное — всё-таки программирование.
В прошлом ещё был админом. А секьюрити было (и частично осталось) хобби.
MC>Юзер зачастую не способен правильно оценить опасность
Вот это правильные слова.
MC>Некоторые даже приклеивают sticky notes с паролями на монитор
А это следствие, но не причина. Знание пароля пользователем накладывает на него обязанности по защите этой информации, а "Юзер зачастую не способен правильно оценить опасность" (с) — собственно, что же вы хотели?
Вывод — создаешь нормальную систему защиты, сделай так, чтобы не пользователь должен был принимать решения, связанные с безопасностью.
Здравствуйте, IT, Вы писали:
IT>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
Юзер зачастую не способен правильно оценить опасность и может считать предлагаемые для повышения безопасности действия — излишней параноидальностью. Некоторые даже приклеивают sticky notes с паролями на монитор, а когда им запрещаешь это делать — они считают это параноидальностью
KV>Или вот еще, юзеры очень не любят, что у нас запрещено работать под чужой учеткой
А это не должно быть запрещено.
Надо:
1. Понять почему возникает такая необходимость (наверное нужен доступ к информации сотрудника, который сейчас на обеде/в отпуске и т.п.)
2. Сделать так, чтобы использовать чужую учетку было невозможно в принципе (например, сильная аутентификация на токенах, которые по совместительству ключи для СКУДов, чтоб даже из комнаты без него выйти нельзя было)
3. Сделать в вашем IDM'е (а я таки узнал, что вы используете ) процесс замещения, который не будет отличаться от своего "некомпьютерного" собрата.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Это при том, что у нас есть и работает механизм замещения (предоставления прав замещамого аккаунту замещающего на период отсутствия сотрудника), о котором все знают, но не все используют, т.к. там сотруднику надо совершить несколько неизбежных действий руками, чтобы один раз настроить замещение по всем системам на конкретного замещающего. Разумеется, сотрудники откладывают это на потом (хотя там дел — на 10-15 минут) и когда они внезапно уходят на больничный, настроить свое замещение уже не могут (ну, только если у них нет удаленного доступа в сетку).
Это кто ж вам так криво сделал процедуру замещения? Конечно ей не пользуются — она же нежизненная ни фига. В какой реальной ситуации может потребоваться больному сотруднику предоставлять доступ на свой компьютер? Инициатором будет не он, это же очевидно. И решение принимать должен не он.
А дальше все просто — в вашем IDM'е должен быть определен процесс замещения, который может инициировать тот, кто должен его инициировать в жизни (сам замещающий сотрудник, начальник и т.п.) и согласовать предоставление должен тот, кто в жизни это делает (например, непосредственный руководитель).
Re[7]: О том, как плохо понимать термин безопасность по учеб
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, DOOM, Вы писали:
FDS>>>А как насчёт погуглить "McLean System-Z"? DOO>>Это попадает в разряд "работ с ее комментариями"
DOO>>Cсылку на BST я дал только для демонтрации подхода (а не конкретного результата) — Белл с Ла Падулой не до конца довели идею FDS>Ага, вот она очень хорошая демонстрация получилась: доказывали доказывали, да додоказывались.
Это демонстрация одной конкретной ошибки одних конкретных исследователей, не более того.
Причем не столько ошибки в результате, сколько в его обобщении.
Тот же McLean, если чо, очень много вариантов улучшения модели Бэла Ла Падула предложил — тот же Low watermark.
FDS>Математикой вообще нельзя доказать безопасность, т.к. невозможно формализовать модель реальной системы.
А мужики-то не знали (с)
И зачем же тогда есть модели HRU, take-grant, модель ИПС, MMS, low watermark и прочее?
FDS>Поэтому все эти математические навороты могут быть полезны, но не более того. На них ничего нельзя основывать, потому что никто не знает, где и когда именно они откажут (или откажет их реализация).
Я даже не знаю какое понятное сравнение привести. Это примерно, как заявлять — зачем нужна теория алгоритмов? От нее багов все равно меньше не становится!
Модели разграничения доступа нужны были чтобы выбрать адекватные подходы к их реальному построению. Чтобы убедиться, что чистая модель мандатного доступа безопасна, но неэксплуатируема, что модель на основе матрицы доступа всегда имеет риск утечки права, что модель ИПС безопасна, но реализовать ее сложно и т.п.
FDS>Проблема в том, что действительно серьёзные вещи, где допускаются дыры, в принципе не имеют математических моделей, а всякие математические абстракции ведутся, в общем-то, для формализации лишь узкой части концепции системы, которая, собственно, может быть формализована.
Из этого надо делать вывод, что они не нужны и неадекватны?
Все имеет границы применимости.
Здравствуйте, Кодёнок, Вы писали:
Кё>Мой пример: для обмена файлами есть папки проектов, куда имеют доступ только участники проектов. Но все продолжают пользоваться общедоступной шарой. Если ее закрыть, открывают свою.
Описанная ситуация с шарой и творческими людьми, обычно широко распространена в стартапах и небольших компаниях, где во-первых, обеспечение информационной безопасности стоит на задних планах, а во вторых, имеет место обычное человеческое доверие между членами всего небольшого коллектива, без которого этот стартап развалится еще до того, как в полный рост успеют проявиться проблемы по ИБ. А когда коллектив вырастает, и в нем начинают появляться сотрудники, доверять которым в общем-то не следовало бы, то рано или поздно наступает час Х когда руководство компании впервые знакомится с таким понятием, как инцидент по ИБ. И шары обычно заканчиваются очень быстро. А у особо впечатлительного руководства после побежденных шар может проснуться кураж и все компы окажутся закованными в железные ящики с амбарными замками и огромными красными кнопками питания в качестве единственного элемента этого дизайнерского решения. Кто считает, что я шучу, welcome вот сюда
. После того же, как такое руководство с удивлением обнаруживает, что железные ящики, в общем-то не очень спасают, начинается накрутка гаек туда, где и резьбы-то никогда не было. Доступ в интернет организовывается только с одного терминального сервера, причем перечень приложений, которые там можно запустить жестко регламентирован. У сотрудников отбираются права локальных админов (это у разработчиков, если что), а их трафик подлежит регулярному ревью назначенными на это дело лицами. Но и это не спасает, поэтому начинаются репрессии и здесь, на RSDN, в форуме "Предложения о работе от прямых работодателей" с завидной регулярностью начинают появляться вакансии в эту контору.
Предыдущий абзац описывает совершенно реальную контору, название которой можно найти по приведенной ссылке. Все описанное там я видел собственными глазами и готов подтвердить, в случае чего. Правда было это, где в 2004-2005 году, а сейчас, насколько я знаю, там с этим немного попроще. Но немного.
Так вот, описанное выше не имеет никакого отношения к информационной безопасности, это какая-то пародия на нее, случившаяся из-за того, что кто-то решил, что он лучше экспертов по безопасности знает, как правильно защитить информационные активы компании и как организовать при этом работу с персоналом. Из-за того, что кто-то решил, что лишь техническими мерами он сможет закрыть все риски, которые в общем-то тоже никто и не считал. И вот после таких контор, у людей и формируется мнение об ИБ, как о драконах, загоняющих творческих сотрудников в какие-либо немыслимые рамки. Но к правильному управлению ИБ это не имеет никакого отношения.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Кодёнок, Вы писали:
Кё>>Вторжение — не их проблема, защита от него — не их обязанности.
KV>Это не совсем так. Коль скоро сотруднику в силу исполнения его служебных обязанностей, был предоставлен доступ к информации, составляющей коммерческую тайну, он несет ответственность за ее неразглашение в рамках своих полномочий, что закреплено даже в ТК, вообще-то (п. 6 ч. 1 ст. 81 ТК РФ). Не говоря уже об умышленных действиях по разглашению КТ, которые рассматриваются уже на уровне УК (ст.183 ч.2).
Это конечно все так. Но у нас и пьяными за руль садятся, хотя и за это есть ответственность. По этой причине надо все-таки с конечного пользователя максимум обязанностей по защите информации снимать или делать так, чтобы их исполнение было легким и непринужденным.
Здравствуйте, IT, Вы писали:
IT>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
В идеале — да. Но у нас юзеры не любят, к примеру, что им предоставляют только те полномочия во внутренних системах, которые им необходимы для исполнения их служебных обязанностей. Например админ, у которого в обязанности входит администрирование лишь одного куста в иерархии AD, почему-то требует права домен-админа и не получив их, клянет именно безопасность в том, что ему вставляют палки в колеса. Или вот еще, юзеры очень не любят, что у нас запрещено работать под чужой учеткой и также клянут нас за это при любом удобном случае. Где тут что-то из перечисленного тобой?
Здравствуйте, vmpire, Вы писали:
V>"Безопастность" — это абстрактное понятие, которое ничего конкретного не означает, и, соответственно, не может быть не измерено не оценено.
Оно означает отношение среднего-арифметического оценки незакрытых рисков к среднему арифметическому оценки их общего числа
V>Именно в этом смысле оно обычно употребляется маркетологами.
Мы говорим о разных маркетологах, если что. Я, упоминая "маркетологов" имел ввиду тех, кто заинтересован в вводе в экплуатацию какой-либо системы, не связанной с непосредственно обеспечением безопаностьи. Можно заменить моих "маркетологов" на "финансистов" или "технарей", чтобы не смущало.
V>Но вот "Безопастность чего-то от чего-то" — уже вполне конкретный термин, с которым можно работать (оченивать, доказывать...) V>"Безопастность" не существует без отрыва от модели угроз и описания предмета защиты. А если вышеуказанное описано, то не возникает вопроса о безопасности уровня процессора и ниже.
Как раз это и описано по той ссылке, которую я привел в конце сообщения
V>Сравните, к примеру, несколько вопросов к специалисту по безопасности и подумайте, какие могут быть ответы:
Я подобные вопросы слышу ежедневно, если что Вот только звучат они несколько иначе:
(решается вопрос о вводе в эксплуатацию новой системы)
1. Разработчики: вот наша безопасная система
2. Я: почему вы считаете ее безопасной?
3. Разработчики: данные передаются по https
4. Я: Зачем? (там оно нафиг не упало, весь трафик шифровать)
5. Разработчики: чтобы удовлетворить требования по ИБ к системе
6. Я: И? Ну ок, а с repudiation вот тут и denial of service вот здесь, что будем делать?
7. Разработчики: С чем? Вы нам напишите четко, что вас не устраивает и как должно быть, у нас все сроки в прошлом полугодии вышли, а вы нам внедрение тормозите (еще и руководству жалуются иногда, чтобы наверняка прикрыться).
Я конечно описал крайний случай, но разработчики крайне редко общаются с безопасниками в терминах "угрозы-риски-контрмеры", это безопасники общаются с ними именно так. А в целом — да, вы правы. Плясать нужно от конкретных угроз, а не гоняться за химерами. Почитайте мое сообщение по той ссылке.
V>То есть, по моему мнению, специалист по безопасности занимается вполне конкретной работой. Только результирующая оценка "безопасности" это нечто гораздо большее, чем одно число, показывающее "безопасность системы в процентах".
Ну, у нас это отчет, описывающий все выявленные риски, их критичность, сценарии атак и рекомендации по устранению или минимизации. Но руководству по итогам работы прхиодит именно одно число, по формуле, которую я привел в начале. Ибо руководство банально не поймет того, что в этих отчетах написано, а цифра нагляднее и понятнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
IT>>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
KV>В идеале — да. Но у нас юзеры не любят, к примеру, что им предоставляют только те полномочия во внутренних системах, которые им необходимы для исполнения их служебных обязанностей. Например админ, у которого в обязанности входит администрирование лишь одного куста в иерархии AD, почему-то требует права домен-админа и не получив их, клянет именно безопасность в том, что ему вставляют палки в колеса. Или вот еще, юзеры очень не любят, что у нас запрещено работать под чужой учеткой и также клянут нас за это при любом удобном случае. Где тут что-то из перечисленного тобой?
Давай добавим сюда недостаточный уровень обучения ваших юзеров. Но опять же вопрос — ваших юзеров вообще кто-нубудь когда-нибудь чему-нибудь из области безопасности учил? Хотя бы какие-нибудь элементарные азы? В моей конторе я обязан прослушать ряд курсов по безопасности и внутренним правилам компании, после чего должен ответить на ряд вопросов или поставить галку acknowledge. Естественно, есть вводная при поступлении на работу и ежегодные повторялки напоминалки. А если я это всё буду игнорировать, то мною серьёзно займётся Compliance Department. Всё это, кстати, сделано опять же без паранойки, а в максимально удобной и ненавязчивой для юзера форме. Итого, я знаю про безопасность, она знает про меня, мы друг друга уважаем и стараемся лишний раз не докучать друг другу.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vmpire, Вы писали:
KV>>Ну, у нас это отчет, описывающий все выявленные риски, их критичность, сценарии атак и рекомендации по устранению или минимизации. Но руководству по итогам работы прхиодит именно одно число, по формуле, которую я привел в начале. Ибо руководство банально не поймет того, что в этих отчетах написано, а цифра нагляднее и понятнее. V>Можно хотя бы выдавать не одно число а три-четыре. Это руководство, обычно, осиливает. V>Типа, "безопастность от внутренних угроз", "безопастность от внешних угроз", "безопастность от потери данных", "безопастность от разглашения данных". V>Заодно, так можно лучше объяснить, над чем сейчас идёт работа.
Очень здравая идея, пасиб. Попробую пропихнуть у нас.
Здравствуйте, IT, Вы писали:
IT>Давай добавим сюда недостаточный уровень обучения ваших юзеров.
У нас повышение осведомленности пользователей по ИБ выделено в отдельный субпроцесс, имеющий свой бюджет, ответственных, план мероприятий и т.п.
IT>Но опять же вопрос — ваших юзеров вообще кто-нубудь когда-нибудь чему-нибудь из области безопасности учил? IT>Хотя бы какие-нибудь элементарные азы? В моей конторе я обязан прослушать ряд курсов по безопасности и внутренним правилам компании, после чего должен ответить на ряд вопросов или поставить галку acknowledge. Естественно, есть вводная при поступлении на работу
Разумеется. При приеме на работу сотрудник получает все необходимые материалы, проходит обязательный курс во внутреннем e-learning'е и, если имеет хотя бы одного подчиненного, то общается лично со мной на предмет его роли в обеспечении безопасности, концепий безопасности компании, роли нашего подразделения и т.п.
IT>и ежегодные повторялки напоминалки.
Рассылаем, раз-два в году проводим добровольные тренинги по ИБ. Желающих, кстати, всегда предостаточно.
IT>А если я это всё буду игнорировать, то мною серьёзно займётся Compliance Department.
А это кто такие?
IT>Всё это, кстати, сделано опять же без паранойки, а в максимально удобной и ненавязчивой для юзера форме. Итого, я знаю про безопасность, она знает про меня, мы друг друга уважаем и стараемся лишний раз не докучать друг другу.
Игорь я не утверждаю, что во всех компаниях со всеми пользователями дела обстоят именно так, как я описал. Но я и категорически не согласен с тем, что причинами недовольства пользователей безопасниками являются исключительно те, которые озвучил ты. Люди работают разные, бывает и полнейший неадекват со стороны пользователей, бывают какие-то просчеты в наших процессах и процедурах, бывает разный менталитет, бывают и мои косяки Но, например, для решения какого-либо вопроса с админами в Краснодаре, мне достаточно позвонить их руководителю, обрисовать проблему, пути ее решения, после чего он даст своим ребятам команду и они все сделают. Если буду звонить ребятам напрямую — без команды от руководителя не сделают ничего. А вот, если мне вдруг что-то понадобится от админа столичной штаб-квартиры, мне нужно будет перечислить ему все политики и приказы, в соответствии с которыми он должен удовлетворить мою просьбу/требование, объяснить ему, что ему будет, если он этого не сделает (не угрожать, они сами это в открытую спрашивают) и на каком вообще основании я ему вдруг позвонил. А на Северном-Кавказе, я должен позвонить админу, поинтересоваться его здрововьем и успехами, здоровьем и успехами его родных и домашних животных, расказать ему о своих и, между делом спросить "ну что ж ты меня, брат, перед руководством подставляешь? обидеть хочешь, да?". После чего проблема будет решена в кратчайшие сроки, причем после этого он перезвонит, заверит что все хорошо и никаких обид и быть не могло, скажет, что уже выбрал барашка к моему приезду и ждет в гости (и упаси меня боже, в очередной командировке к ним, отказаться от угощения и застолья — худшего способа его обидеть, наверное нет).
Я это к тому, что тут либо индивидуальный подход, либо недовольные будут, каким бы идеальным не был сам процесс security-management'а. А сохранять индивидуальный подход, когда ты один на три с гаком тысячи сотрудников в двух регионах очень нелегко
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Но, например, для решения какого-либо вопроса с админами в Краснодаре
Есть еще один путь — работать исключительно по процедурам несмотря ни на что. Это тоже работает отлично, благо процедуры у нас достаточно гибкие и прошедшие испытание временем. Но в этом случае, неизбежно недовольство со стороны большинства из тех, кого "отпроцедурили" по полной программе, т.к. все любят, когда к ним относятся по-человечески и с пониманием и никто не любит, когда на него давят бюрократией, даже не пытаясь решить вопрос простым звонком.
Кроме того, одна из самых дурацких особенностей человеческой психологии — это воспринимать все хорошее как должное и забывать об этом, но при этом старательно помнить все плохое. И это тоже является одной из причин нелюбви пользователей, т.к. департамент ИБ — это одно из немногих подразделений, которое обязано взаимодействовать со всеми другими подразделениями. А значит, что и негатива у этих подразделений, чисто количественно, всегда будет больше, чем по отношению к любой другой службе. В данном случае, прямыми "собратьями по несчатью" у нас являются служба безопасности, HR и работники корпоративной столовой
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Для тех, кому лень читать весь следующий поток сознания, вот сухая выжимка сказанного мной ниже:
KV>
KV>безопасность — это не баззворд, просто это понятие дискредитировано недобросовестными поставщиками. юзеры это слово не любят и повторяют как ругательство, ибо неизбежные ограничения их свобод, а эксперт по безопасности вполне в состоянии оценить эту самую безопасность. И, таки-да, это можно доказать строго и математически (я хз как математически, но логически — легко)
Слово "безопасность" (подразумевается информационная безопасность) — это определённо базворд. Примерно как и XML. Никакого реального смысла ни за тем, ни за другим не стоит.
Правильным термином является скорее "защита информации" — та самая, которая процесс направленный на ... (целостность, конфиденциальность, доступность).
Защита информации является процессом достижения этих определённых целей какими либо своими методами, но как и любой реальный процесс никогда своих целей не достигает и не может достигнуть в принципе.
Хороший пример — это криптографические протоколы, которые математически уже столь сложны, что проверить их принципиальную "безопасность" могут лишь единицы криптографов. Но даже и при этом, все эти протоколы состоят из примитивов, которые математически опираются на "достаточно долгий процесс взлома простым перебором".
Тут как говорится: Атаки всегда становятся только лучше. И рано или поздно, но любой алгоритм и/или протокол будет взломан, а на его базе уже были построены тысячи систем и протоколов.
P.S. Пример из реальной жизни криптографов: процесс взлома алгоритмов семейства MD (MD5, SHA-1). Cуть взлома заключается в примитивном компьютерном переборе и поиске неподвижных "точек" алгоритма хеширования, которые затем объединяются в неподвижный путь. Алгоритм хеширования сам по себе настолько сложный (хоть и примитивный внутри), что существование и/или несуществование неподвижных путей внутри алгоритма доказать вычислительно невозможно. И вся "безопасность" алгоритма держалась на вычислительной трудности выполнения этой задачи. Но вначале нашлась одна почти случайная коллизия, а затем все быстро пробежали путь от нахождения новых коллизий до создания поддельных сертификатов X.500 ... Вся история улучшения этой примитивной атаки подробно описана: MD5 considered harmful today.
С Уважением, Andir!
Re: О том, как плохо понимать термин безопасность по учебнку
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Информационная система, по определению, есть система обработки, хранения и передачи информации. Именно у информации есть состояние безопасности. Информация находится в состоянии безопасности тогда, когда выполняются ровно три условия:
KV>1. Она конфиденциальна, т.е. ее могут получить только те приемники, которые имеют на это право
Нет. Ещё её могут изменять те приёмники, которые имеют на это право (и не должны изменять те, которые не имеют на это права, что можно сделать даже в системе, используемой только на чтение). Ещё её могут использовать те приёмники, которые имеют право, НЕ ПОЛУЧАЯ её при этом (например, запуск серверного скрипта при работе с web-приложением). Или, второй вариант, другое использование, кроме как для хранения и передачи у ИС нет, но тогда она не может обрабатывать информацию и действительно будет в "состоянии" — причём только в одном.
KV>2. Она целостна, т.е. ее передача от источника А к приемнику Б не вносит изменений в нее
Нет. Потому что целостность не ограничивается передачей информации: она включает в себя и целостность (осмысленность) при обработке, почему-то про неё ты забыл.
Кроме этого, необходимо удостоверится, что получена именно запрашиваемая информация (для чего используются те же сертификаты серверов)
KV>3. Она доступна, т.е. все приемники, имеющие право получать эту информацию, могут получить ее в данный момент времени
А так же изменить и использовать в другом виде, если есть права. Да?
А так же
4. Есть резервные копии данной информации, т.е. она защищена от физического уничтожения
KV>А давайте теперь прикинем: можем ли мы заложить необходимые и достаточные "метаусловия" выполнения этих условий в саму информацию?
KV> Конфиденциальность — да,
Нет
KV> информация, например, может быть зашифрована ключом, который есть только у лиц, имеющих право на доступ к ней.
А как ключ выдавать? А что будет, если нужно будет отозвать права? А как точно определить, что именно этот пользователь имеет право? А если её считают из-за спины пользователя или с использованием ПЭМИН? А как определить, что информация действительно зашифрована этим ключом и её нигде не осталось в памяти или, как это бывает в потоковых алгоритмах шифрования, что тем же ключом не зашифрована другая информация?
Всё это невозможно зашить в защищаемую информацию.
Мало того, это влечёт за собой рассмотрение не только ИС, где хранится информация, но и других вещей: например, что будет, если пользователь потеряет свой ключ (или его уведут).
Очевидно, в случае утери или намеренной кражи ключа конфиденциальность будет нарушена (в итоге получается, нужен ещё пароль на ключ, но его можно забыть, выпытать и т.д.)
Т.е. появляется ещё две системы: пользователи и внешний мир.
KV> Целостность — тоже да, ибо коды коррекции, цифровые подписи и т.п.
Нет. В связи с тем, что для того, чтобы информация была целостная, мне нужно не только доказать целостность информации при передаче, но и целостность информации на сервере. Грубо говоря, если я передаю число пользователей некоторой сети, то цифровая подпись не поможет мне, если это число будет равно "ER000" или "TUX08"
Таким образом, приходим к тому, что и здесь затрагивается ИС. Кроме этого, под целостностью здесь понимается осмысленность, т.е., по сути, здесь затрагивается вопрос и о методах подделки алгоритма вычисления такого числа (например, в электронном голосовании нам не только надо обеспечить целостность данных о количестве проголосовавших, но и обеспечить надёжный алгоритм защиты от искажения голосования [например, дачи ложных голосов]).
А что в итоге? А в итоге, ты обеспечиваешь целостность информации в части системы, а я её ломаю совершенно в другой части
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, IT, Вы писали:
IT>>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
KV>В идеале — да. Но у нас юзеры не любят, к примеру, что им предоставляют только те полномочия во внутренних системах, которые им необходимы для исполнения их служебных обязанностей. Например админ, у которого в обязанности входит администрирование лишь одного куста в иерархии AD, почему-то требует права домен-админа и не получив их, клянет именно безопасность в том, что ему вставляют палки в колеса. Или вот еще, юзеры очень не любят, что у нас запрещено работать под чужой учеткой и также клянут нас за это при любом удобном случае. Где тут что-то из перечисленного тобой?
Например,
1. СБ предоставляет не все полномочия, хотя ей кажется, что все. Пример: когда была ОС MS Windows 98 доходило до того, что запрет на работу с дискетами человек вынужден был ломать BIOS путём программного сброса и последующей CMOS. Причём часть данных в системе действительно он не имел права уносить на дискете, а часть — имел право и имел такую необходимость.
То же касалось, если не ошибаюсь, Windows 2000, в которой нельзя было пользоваться флэш-памятью из-под обычного аккаунта пользователя, так как это считалось установкой нового устройства и было запрещено.
2. СБ задерживает создание нового аккаунта по неизвестным причинам. В итоге запрошенный аккаунт создаётся только через несколько месяцев после соотв. запроса: естественно ведётся работа под чужими аккаунтами.
3. Система безопасности не позволяет давать полномочия другим пользователям, в то время как это необходимо и обоснованно, а выдача полномочий через СБ практически невозможна (выдаётся с существенной задержкой и слишком много запросов приходится отправлять). В итоге администратор требует себе дополнительных прав, но СБ считает, что они ему не нужны (в то время, как ему таких запросов может потребоваться удовлетворить по десятку в день на пике активности)
пункт 3 — это параноидальность. Первый и второй пункты — это бестолковость, причём не интерфейса СЗИ, а бестолковость СБ, которая препятствует нормальной работе пользователей с обеспечением всех требований безопасности
Re[2]: О том, как плохо понимать термин безопасность по учеб
Я искренне прошу меня извинить, но при беглом прочтении твоего сообщения, мне показалось что в нем смешаны в одну кучу совершенно различные понятия и подходы к пониманию безопасности информации, а также на одном уровне рассматриваются информационные потоки различных уровней абстракции ИС. Кроме того, упомянут процесс управления disaster recovery, который к безопасности информации вообще имеет лишь опосредованное отношение. Но даже несмотря на это, я не увидел ничего, прямо противоречащего тому, что утверждал я. Поэтому после вывода:
FDS>А что в итоге? А в итоге, ты обеспечиваешь целостность информации в части системы, а я её ломаю совершенно в другой части
я чувствую что меня облили водой и подожгли
Я честно попытаюсь завтра прочесть это еще раз на свежую голову и дать развернутый ответ, но на всякий случай хочу заметить, что мое понимание термина "безопасность" сформировалось не после прочтения учебника (который, я уже и не помню когда читал), а на основе довольно продолжительного опыта управления процессом обеспечения ИБ в 16 филиалах двух регионов нашей компании.
Впрочем, возможно из-за того, что я не помню содержание учебника, у нас имеет место некоторое рассогласование терминологии. Я применял ту, которая используется в нашей компании в силу сложившейся практики
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, FDSC, Вы писали:
KV>Я искренне прошу меня извинить, но при беглом прочтении твоего сообщения, мне показалось что в нем смешаны в одну кучу совершенно различные понятия и подходы к пониманию безопасности информации, а также на одном уровне рассматриваются информационные потоки различных уровней абстракции ИС.
А настоящая безопасность всегда оперирует различными уровнями абстракций, а так же вообще неабстрактными понятиями. Например, ты оперировал двумя: просто говорил о потоках информации, и говорил о информационной системе.
KV> Кроме того, упомянут процесс управления disaster recovery,
я его не упоминал совершенно: я сказал "обеспечение безопасности от физического уничтожения", возможно, немного запутав и указав, что именно резервным копированием. Ведь нужно ещё и охранять дата-центр, правда? Резервные копии — это не обязательно disaster recovery
KV> который к безопасности информации вообще имеет лишь опосредованное отношение.
Это точно, в отличии от физической защиты информации.
KV> Но даже несмотря на это, я не увидел ничего, прямо противоречащего тому, что утверждал я.
Жаль. Прямое противоречие тут очень просто:
1. Охрана дата-центра — это процесс обеспечения безопасности ИС. Из твоих пунктов он никак не следует (ну, я не думаю, что стоит понимать доступность в таком развёрнутом варианте, что под неё и ещё и физическую защиту понимать).
2. Резервная копия — тоже, в частности, процесс обеспечения безопасности информации. Из твоих пунктов никак не следует.
3. Обеспечение прав на выполнение, обработку и прочее — то же не в твоём списке (а ты указал, что это исчерпывающий список)
4. Обеспечение проверки подлинности сервера тоже непонятно в какой пункт засунуть (это и не конфиденциальность, т.к. правильная информация не читается вообще, это не целостность, т.к. правильная информация не передаётся и, следовательно, не искажается [хотя здесь всё зависит от конкретных определений, но ты не определил ни уровень абстракции, ни сами определения, кроме этого ссылки на ЭЦП и контрольные суммы откровенно даёт понять о чём идёт речь — ты защищает информацию на сервере и считаешь, что она находится в состоянии безопасности, тогда как часть системы в виде приёмника не находится в безопасности], информация по прежнему может быть доступна, но обращение идёт к другой информации [тоже можно сказать, конечно, что ты имел в виду более широкое понятие, но тогда вообще для кого ты пишешь? Для спецов, которые и так это уже знают?]
KV>я чувствую что меня облили водой и подожгли
А я думал, что я тебя поджёг, а потом облил водой.
KV>Я честно попытаюсь завтра прочесть это еще раз на свежую голову и дать развернутый ответ
жду
KV> но на всякий случай хочу заметить, что мое понимание термина "безопасность" сформировалось не после прочтения учебника (который, я уже и не помню когда читал),
Я знаю, Владимир. Я как раз хотел тебе показать, что твоё понимание термина "безопасность" пошло от твоей рутины: ты занимаешься специфическими проблемами безопасности, но она никак не исчерпывает всего. Твои три пункта совершенно не годятся в качестве руководства по анализу уровня безопасности системы, т.к. пункты то ли слишком широки, чтобы вообще пытаться из них выжать что-то конкретное, то ли неполны.
KV> а на основе довольно продолжительного опыта управления процессом обеспечения ИБ в 16 филиалах двух регионов нашей компании.
Так же как мой пост не на основе учебника, а на основе опыта работы с информационными системами как мелких, так и крупных фирм. Когда я вижу, что спец. говорит чушь, я должен его поправить: потому что или он непонятно что-то написал, или что-то не понимает/забыл. Вариант, что я чего-то не понял довольно мизерный, так как при написании сообщения я просто вспоминал реальные случаи нарушения безопасности ИС из моего личного опыта.
KV>Впрочем, возможно из-за того, что я не помню содержание учебника, у нас имеет место некоторое рассогласование терминологии.
Проблема не в том, что ты не помнишь учебника, а в том, что это не форум профессионалов ИБ и кроме тебя никто не обязан вообще знать терминологию. Панимаешь куда я клоню?
KV> Я применял ту, которая используется в нашей компании в силу сложившейся практики
Да-да, именно это я и охарактеризовал в заголовке сообщения: "О том, как плохо понимать термин безопасность по учебнику". Я не говорил про учебник, я имел в виду как раз скорее установившуюся практику. Здесь согласен. Просто не нашёл более короткого слова, если честно.
Вот как раз ваша установившаяся практика очень вредна.
Здравствуйте, Andir, Вы писали:
A>Слово "безопасность" (подразумевается информационная безопасность) — это определённо базворд. Примерно как и XML. Никакого реального смысла ни за тем, ни за другим не стоит.
Почему это за XML нет никакого реального смысла? Смысл есть и вполне реальный. То, что конкретная XML-разметка не имеет ни малейшего смысла в отрыве от размеченной ей информации и схемы разметки — да, это так. Но это практически тоже самое что утверждал я, говоря о рассмотрении понятия "безопасности информации" в отрыве от ИС в которой она циркулирует Или я неверно понял аналогию?
A>Правильным термином является скорее "защита информации" — та самая, которая процесс направленный на ... (целостность, конфиденциальность, доступность).
И по-моему, мы все-таки говорим о разных вещах:
За понятием "обеспечение защищенности информации" стоит исполнение вполне конкретного плана по устранению выявленных угроз.
За понятием "обеспечение безопасности информации" стоит исполнение вполне конкретного плана по противодействию выявленным рискам
Тем не менее, это два совершенно различных процесса, и не один из них баззвордом не является. Первое — говорит о том, что мы должны сделать, чтобы нас не поломали. Второе — что мы должны сделать, чтобы нас, если и поломали, то ущерб, понесенный нами оказался минимальным. Ты же сам далее рассуждаешь, что достичь полной защищенности невозможно в принципе. Из этого чисто логически следует, что необходимо предпринять еще что-то, чтобы максимально обезопаситься от того, от чего не удалось защититься.
Простой пример:
Аутентификация в системе интернет-банкинга логином и паролем. Угроза — нарушение конфиденциальности учетных данных при передаче от браузера серверу. Фактор — информация передается в открытом виде. Контрмера — заворачиваем трафик в https. Защитили? Нет, ибо угроза — все то же нарушение конфиденциальности учетных данных при передаче, но с новым фактором — пользователь прошляпил сообщение о фальшивом сертификате. Контрмера — на данном уровне абстракции и/или этапе workflow невозможна, т.к. фактор человеческий.
Получаем риск — реализацию данной угрозы с большой степенью вероятности и потенциальным ущербом равным сумме на счету у клиента + его кредитным лимитом. Минимизируем риск — вводим дополнительную аутентификацию через иной канал связи на каждую транзакцию по выводу средств со счета: отправляем пользователю SMS с кодом, требуем ввести его для подтверждения. Т.о. даже если MiM атака на процесс аутентификации будет успешно реализована, не обладая кодами подтверждения, атакующий не сможет нанести нам ущерб.
Первый абзац — обеспечение защищенности. Второй — безопасности. В первом мы боремся с атаками, во втором — с их последствиями.
И кроме того:
За понятием "безопасность информации" стоит вполне конкретное состояние информации в текущий момент времени, определяемое выполнением перечисленных мной условий. За понятием "защищенность информации" стоит ровно то же самое Насколько мне известно, применительно к состоянию информации, эти два термина применяются как синонимы, возможно отсюда и идет путаница в дальнейшей терминологии, т.к. применительно к процессу они уже означают разные вещи. Но и это понятие является таким же "баззвордом" как например "первая производная". Величина напрочь абстрактная, но это не мешает ей существенно облегчать жизнь при оценке той или иной системы.
Здравствуйте, FDSC, Вы писали:
FDS>Твои три пункта совершенно не годятся в качестве руководства по анализу уровня безопасности системы
*совсем уставшим голосом, засыпая* одну вещь таки-скажу сегодня. Это — не моя модель, это CIA, одна из многих общепринятых моделей безопасности информации. В исходном сообщении я привел ссылку на одну из моих старых тем, там я описываю этот же процесс но на модели STRIDE, которая по сути практически та же CIA, только с аутентификацией, авторизацией и аутентичностью, т.е. тем, о чем ты сейчас и говорил, как о недостающих звеньях.
Но ведь суть сказанного мной от этого не меняется, просто мне показалось, что на CIA это объяснить легче и писать нужно меньше, но не более того
Все это, безусловно имеющие право на жизнь ситуации, но в нашем случае они не применимы. Я кстати отношусь не к СБ, а к ИТ и СБ у нас к информационной безопасности вообще никакого отношения не имеет. Поэтому ниже, везде, где под "СБ" я подписываюсь "мы" я имею ввиду "ИТ".
FDS>Например, FDS>1. СБ предоставляет не все полномочия, хотя ей кажется, что все. Пример: когда была ОС MS Windows 98 доходило до того, что запрет на работу с дискетами человек вынужден был ломать BIOS путём программного сброса и последующей CMOS. Причём часть данных в системе действительно он не имел права уносить на дискете, а часть — имел право и имел такую необходимость.
Мы не обладаем эксклюзивным правом определять полномочия сотрудников. В этом процессе, наравне с нами участвуют, как минимум непосредственный руководитель сотрудника и бизнес-владельцы той системы или информации к которой сотрудник просит доступ. Если их решение не будет совпадать с нашим, то далеко не факт, что оно будет принято с учетом наших интересов. Другое дело, что руководителям очень часто удобнее сказать сотруднику, что доступ зарубили злые ИБшники, нежели объяснять реальные причины отказа.
В том примере с админом (реальном, кстати) доступ был зарублен всеми тремя сторонами одновременно. А негатив пошел только на ИБ
FDS>2. СБ задерживает создание нового аккаунта по неизвестным причинам. В итоге запрошенный аккаунт создаётся только через несколько месяцев после соотв. запроса: естественно ведётся работа под чужими аккаунтами.
Мы вообще не участвуем в процессе создания аккаунтов, этот процесс полностью автоматизирован и зависит только от того, как быстро HR оформит карточку сотрудника в ERP. Под чужими аккаунтами же чаще всего работают, замещая болеющих сотрудников, либо сотрудников в отпусках. Это при том, что у нас есть и работает механизм замещения (предоставления прав замещамого аккаунту замещающего на период отсутствия сотрудника), о котором все знают, но не все используют, т.к. там сотруднику надо совершить несколько неизбежных действий руками, чтобы один раз настроить замещение по всем системам на конкретного замещающего. Разумеется, сотрудники откладывают это на потом (хотя там дел — на 10-15 минут) и когда они внезапно уходят на больничный, настроить свое замещение уже не могут (ну, только если у них нет удаленного доступа в сетку).
FDS>3. Система безопасности не позволяет давать полномочия другим пользователям, в то время как это необходимо и обоснованно, а выдача полномочий через СБ практически невозможна (выдаётся с существенной задержкой и слишком много запросов приходится отправлять). В итоге администратор требует себе дополнительных прав, но СБ считает, что они ему не нужны (в то время, как ему таких запросов может потребоваться удовлетворить по десятку в день на пике активности)
Предоставление прав у нас тоже автоматизировано в большей части систем и исполнение таких заявок идет мимо как нас, так и администраторов В том случае, админ хотел собирать логи с DC, но их можно было тогда получать только с правами домен-админа. Он хотел получать информацию о логонах/логоффах пользователей и на базе этой информации определять одновременную работу под одной учеткой на разных компах. Но это совершенно не входило в его обязанности, поэтому ему и отказали давать столь широкие права на пустом месте.
FDS>пункт 3 — это параноидальность. Первый и второй пункты — это бестолковость, причём не интерфейса СЗИ, а бестолковость СБ, которая препятствует нормальной работе пользователей с обеспечением всех требований безопасности
Мы (ИТ) имеем SLA (соглашения об уровне сервиса) подписанные со всеми основными департаментами компании. В частности, там прописаны и критерии "нормальной работы пользователей", причем весьма подробно. Нарушение SLA ведет к крайне негативным последствиям на очередной этапе оценки персонала (есть у нас такой процесс), поэтому его соблюдение является у ИТшников одной из первоочередных целей. Все, что выходит за рамки SLA — идет либо сразу лесом, либо на усмотрение ИТшников.
Ладно, я прошу прощения, что чуть-чуть поморочил голову... Тем админом был я сам около 6 лет назад, еще до перевода в департамент ИБ Но негатив в сторону ИБшников у меня тогда был конкретный, хотя сейчас я и понимаю, что был неправ
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, FDSC, Вы писали:
KV>Все это, безусловно имеющие право на жизнь ситуации, но в нашем случае они не применимы. Я кстати отношусь не к СБ, а к ИТ и СБ у нас к информационной безопасности вообще никакого отношения не имеет. Поэтому ниже, везде, где под "СБ" я подписываюсь "мы" я имею ввиду "ИТ".
Я просто привёл пример того, что может быть. Ты, как сотрудник ИБ, просто не знаешь, почему именно пользователи что-то делают. Видимо, 10-15 минут работы по настройке — это для них много и муторно (да и знают ли они, как настраивать?) и так далее. Все нарушения режима всегда имеют причину.
KV>Ладно, я прошу прощения, что чуть-чуть поморочил голову... Тем админом был я сам около 6 лет назад, еще до перевода в департамент ИБ Но негатив в сторону ИБшников у меня тогда был конкретный, хотя сейчас я и понимаю, что был неправ
Ты как раз был прав в некотором смысле — со своей точки зрения. Проблема как раз в том, что как только такие админы уходят на ИБ, они сразу же забывают свои проблемы. В итоге специалист по ИБ думает, что пользователи — это одно и работают так-то, а пользователи на самом деле совершенно другое и работают по другому.
Короче говоря, как всегда забывают про людей: конечно, в этом виноваты не специалисты по ИБ (точнее, не только они). Если бы вы сделали скрипт автоматической настройки замещения пользователя — не было бы у вас проблемы работы под чужими аккаунтами. Если пользователи делают так, значит вы им на голову сыплите проблемы, которые они решать не хотят.
Опять же, это пример зашоренности (а может быть, и недостатка средств), которая сейчас очень распространена: как всегда во всём обвиняют стрелочника, будь то конкретный пользователь или специалист по ИБ.
Re[5]: О том, как плохо понимать термин безопасность по учеб
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>В исходном сообщении я привел ссылку на одну из моих старых тем, там я описываю этот же процесс но на модели STRIDE, которая по сути практически та же CIA, только с аутентификацией, авторизацией и аутентичностью, т.е. тем, о чем ты сейчас и говорил, как о недостающих звеньях.
Я там не только о аутентификации говорил. Я бы даже сказал, о ней я как раз промолчал .
С исходном, это в каком?
KV>Но ведь суть сказанного мной от этого не меняется, просто мне показалось, что на CIA это объяснить легче и писать нужно меньше, но не более того
Да нет, надо просто писать, что это модель и она имеет свои ограничения. Я почему так взъелся: видно, что ты говоришь о каком-то конкретном случае (конкретной модели угроз), но есть и другие. А говоришь так, как будто эта система вообще общая для всех ИС.
Если наши разногласия только в этом, то дальнейший спор, конечно, бессмыслен.
Здравствуйте, MozgC, Вы писали:
MC>Юзер зачастую не способен правильно оценить опасность и может считать предлагаемые для повышения безопасности действия — излишней параноидальностью. Некоторые даже приклеивают sticky notes с паролями на монитор, а когда им запрещаешь это делать — они считают это параноидальностью
Не способен понять — это имхо редкие-редкие исключения.
Гораздо чаще, это всё осознанно. Вторжение — не их проблема, защита от него — не их обязанности. Они не понимают, зачем им прилагать усилия для решения не их проблем. Поэтому по принципу K.I.S.S., делают простые пароли, одинаковые ко всем аккаунтам и записывают их туда, где их легко достать. Управлять простым способом или сложным — для них выбор очевиден, а как оно для тебя — о тебе они заботиться не собираются.
Здравствуйте, IT, Вы писали:
IT>Давай добавим сюда недостаточный уровень обучения ваших юзеров.
Обучение тут не поможет. Вот ты дорогу вообще всегда на зеленый переходишь? Или все-таки нет? Научили что ли плохо?
IT>Но опять же вопрос — ваших юзеров вообще кто-нубудь когда-нибудь чему-нибудь из области безопасности учил? Хотя бы какие-нибудь элементарные азы?
У них — думаю да
IT>В моей конторе я обязан прослушать ряд курсов по безопасности и внутренним правилам компании, после чего должен ответить на ряд вопросов или поставить галку acknowledge. Естественно, есть вводная при поступлении на работу и ежегодные повторялки напоминалки. А если я это всё буду игнорировать, то мною серьёзно займётся Compliance Department. Всё это, кстати, сделано опять же без паранойки, а в максимально удобной и ненавязчивой для юзера форме. Итого, я знаю про безопасность, она знает про меня, мы друг друга уважаем и стараемся лишний раз не докучать друг другу.
Это хорошо, но тоже не идеально. В идеале все решения, связанные с безопасностью, должны приниматься профессионалами, а не пользователями.
Здравствуйте, FDSC, Вы писали:
FDS>1. СБ предоставляет не все полномочия, хотя ей кажется, что все.
Сразу возникает ряд вопросов:
1. Почему "все" или "не все" определяет СБ, а не непосредственный руководитель, которому явно виднее, чем тебе заниматься?
2. Почему СБ предоставляет? Это вообще не их работа...
FDS>Пример: когда была ОС MS Windows 98 доходило до того, что запрет на работу с дискетами человек вынужден был ломать BIOS путём программного сброса и последующей CMOS. Причём часть данных в системе действительно он не имел права уносить на дискете, а часть — имел право и имел такую необходимость.
Что тут сказать. Были способы сделать это все адекватнее — но не стали.
FDS>То же касалось, если не ошибаюсь, Windows 2000, в которой нельзя было пользоваться флэш-памятью из-под обычного аккаунта пользователя, так как это считалось установкой нового устройства и было запрещено.
Вопрос можно было решить более тонкой настройкой прав, чем тупо давать админа.
FDS>2. СБ задерживает создание нового аккаунта по неизвестным причинам. В итоге запрошенный аккаунт создаётся только через несколько месяцев после соотв. запроса: естественно ведётся работа под чужими аккаунтами.
Ну а если бы эти же несколько месяцев человека не знала бы бухгалтерия? Пришлось бы естественно работать за чужую зарплату?
Вообще неправильно эти процессы разделять — если человек появился в компании, то он должен появится одновременно и в кадровой системе, и в службе каталога, и в телефонном справочнике и картотеке медицинского кабинета и много где еще.
FDS>3. Система безопасности не позволяет давать полномочия другим пользователям, в то время как это необходимо и обоснованно, а выдача полномочий через СБ практически невозможна (выдаётся с существенной задержкой и слишком много запросов приходится отправлять). В итоге администратор требует себе дополнительных прав, но СБ считает, что они ему не нужны (в то время, как ему таких запросов может потребоваться удовлетворить по десятку в день на пике активности).
Еще раз. Есть бизнес процессы. Есть безопасность этих процессов.
Если такой бардак — значит никто не анализировал ни сами процессы, ни требования к их безопасности. Просто тупо взяли какой-нибудь идиотский документ типа СТР-К и реализовали.
FDS>пункт 3 — это параноидальность. Первый и второй пункты — это бестолковость, причём не интерфейса СЗИ, а бестолковость СБ, которая препятствует нормальной работе пользователей с обеспечением всех требований безопасности
Все три пункта это бестолковость. Причем не только (не столько) СБ, а сколько руководства.
И вообще — найти нормального безопасника гораздо сложнее чем, например, нормального админа.
Я вот вообще каждый раз удивляюсь — почему Владимир работает в эксплуатации, а не в каком-нибудь консалтинге по вопросам ИБ.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>7. Разработчики: С чем? Вы нам напишите четко, что вас не устраивает и как должно быть,
Ты им SDL и Threat Modelling Tool в зубы выдай и скажи — вот, написал
Здравствуйте, Andir, Вы писали:
A>Слово "безопасность" (подразумевается информационная безопасность) — это определённо базворд. Примерно как и XML. Никакого реального смысла ни за тем, ни за другим не стоит. A>Правильным термином является скорее "защита информации" — та самая, которая процесс направленный на ... (целостность, конфиденциальность, доступность).
Карл Маркс и Фридрих Энгельс — это 4 разных человека. В том смысле, что безопасность информации, информационная безопасность и защита информации — это разные вещи. Причем очень разные.
Про информационную безопасность в этой ветке вообще ни слова не прозвучало, если что. Только про безопасность информации.
И безопасность информации это вовсе не "баззворд". Как правильно написал Владимир — это состояние, а защита информации — это процесс, усиленно пытающийся это состояние обеспечить.
Если мы говорим о каких-то измерениях, то оценивать надо, очевидно, состояние, а не процесс.
A>Защита информации является процессом достижения этих определённых целей какими либо своими методами, но как и любой реальный процесс никогда своих целей не достигает и не может достигнуть в принципе. Свои цели достигаются всегда. Не достижимы идеальные. Например, проектируя высоконадежную систему никто не станет закладывать доступность 100% — это недостижимо.
A>Хороший пример — это криптографические протоколы, которые математически уже столь сложны, что проверить их принципиальную "безопасность" могут лишь единицы криптографов.
Все симметричные протоколы построены на идее гаммирования с обратной связью или без нее (обычно задается режимом). 99% использует конструкцию Фейстеля. Так что не надо — все там изучено вдоль и поперек. Шифры замечательно оцениваются по параметру криптостойкости (иначе к чему был этот долгий процесс выбора реализации AES?).
A>Но даже и при этом, все эти протоколы состоят из примитивов, которые математически опираются на "достаточно долгий процесс взлома простым перебором".
Э-э-э-э-э... А ты точно хорошо ориентируешься в теме?
A>Тут как говорится: Атаки всегда становятся только лучше. И рано или поздно, но любой алгоритм и/или протокол будет взломан, а на его базе уже были построены тысячи систем и протоколов.
Ну и дальше что? Почему до сих пор много где применяют DES, хотя он давно уже не является криптостойким?
Хинт: если ты ломаешь криптографическое сообщение за 2 минуты, а оно живет 1 минуту и дальше оно уже бесполезно, то грош цена твоему взлому.
A>P.S. Пример из реальной жизни криптографов: процесс взлома алгоритмов семейства MD (MD5, SHA-1). Cуть взлома заключается в примитивном компьютерном переборе и поиске неподвижных "точек" алгоритма хеширования, которые затем объединяются в неподвижный путь. Алгоритм хеширования сам по себе настолько сложный (хоть и примитивный внутри), что существование и/или несуществование неподвижных путей внутри алгоритма доказать вычислительно невозможно. И вся "безопасность" алгоритма держалась на вычислительной трудности выполнения этой задачи. Но вначале нашлась одна почти случайная коллизия, а затем все быстро пробежали путь от нахождения новых коллизий до создания поддельных сертификатов X.500 ... Вся история улучшения этой примитивной атаки подробно описана: MD5 considered harmful today.
Хэш функции это какбе не шифры. С ними ситуация другая, но и там математики хватает, просто у нас иной раз не любят заморачиваться "по мелочам"
Здравствуйте, Кодёнок, Вы писали:
Кё>И т.д. И т.п. Общедоступная шара — это простой интерфейс, я кладу, они берут, мне надо, я беру. Запросы через кого-то — это интерфейс, который 5-минутное дело рястягивает на сутки (это если никто не в отпуске и не с ненормированным графиком). Какой человек в своем уме захочет его использовать?
Угу. А потом начнется:
Какой "?№!№ удалил мой файл?
Кто написал эту чушь?
Почему мне дали не последнюю версию файла??
и т.д. и т.п.
Хорошее сравнение — системы контроля версий. Тоже блин, сложности какие-то лишние — только работать мешают, заразы. Ату их!
Re[4]: О том, как плохо понимать термин безопасность по учеб
Здравствуйте, FDSC, Вы писали:
FDS>А настоящая безопасность всегда оперирует различными уровнями абстракций, а так же вообще неабстрактными понятиями. Например, ты оперировал двумя: просто говорил о потоках информации, и говорил о информационной системе.
Настоящая безопасность всегда оперирует очень четкими почти математическими определениями. Именно это создает трудности при прочтении твоего сообщения — ты используешь термины иначе.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Контрмера — заворачиваем трафик в https. Защитили? Нет, ибо угроза — все то же нарушение конфиденциальности учетных данных при передаче, но с новым фактором — пользователь прошляпил сообщение о фальшивом сертификате. Контрмера — на данном уровне абстракции и/или этапе workflow невозможна, т.к. фактор человеческий.
Это еще можно пытаться лечить повышая образованность пользователей, объясняя смысл "зелёной полоски" в браузере. Реальной технической урозой является атака man in the browser, что делает куча троянов, например Zeus.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Некоторые участники форума с завидным постоянством употребляют термин "безопасный язык" уязвимость и т.п. в контексте использования например языка С в линуксе.
Без указания опасностей, угроз или конкретных проблем слово "безопастность" превращается в чистейший бессмысленный базворд.
Здравствуйте, DOOM, Вы писали:
DOO>Хорошее сравнение — системы контроля версий. Тоже блин, сложности какие-то лишние — только работать мешают, заразы. Ату их!
Некоторые системы контроля версий тоже мешают работать.
Кодёнок правильно перечислил кучу основных моментов, которые мешают не потому что так надо, а потому что так есть (бестолковость организации защиты)
), только теперь вместо ответа, что это бестолковость руководства, ты отвечаешь, что так и должно быть, хотя Кодёнок просто сказал всё то же самое в более абстрактных словах: и всё, оказывается, что так и должно быть.
Re[5]: О том, как плохо понимать термин безопасность по учеб
Здравствуйте, 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 информационной системы направлены на риски, а не на угрозы.
Здравствуйте, 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'у, чтобы стать практически монополистом на этом рынке
Здравствуйте, 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>Ну да. Но когда говорят, что они мешают работать, то это имеются в виду явно все.
У меня на работе безопасность, собственно работе, не мешает. Делая такое же обобщение, я могу сказать, что проблем никаких нет
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. Работник Компании может быть привлечен к ответственности в случаях:
• умышленного или неосторожного разглашения ИКТ;
• утраты материальных носителей ИКТ;
• нарушения требований настоящего Порядка и других регламентирующих документов Компании в части вопросов доступа и работы с ИКТ.
Поэтому, процитированное в самом верху утверждение, вообще говоря действительности не очень соответствует. Кое-что входит и в обязанности каждого такого сотрудника.
Здравствуйте, DOOM, Вы писали:
IT>>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности. DOO>Прям-таки любых?
Любых чего?
DOO>Обобщать-то не надо. Идеальная система должна работать незаметно для пользователя, иначе может сработать: DOO>- отторжение самой системы (ну с этим еще можно справится) DOO>- эффект компенсации риска (а вот с этим хуже).
DOO>Примером последнего могут служить такие интересные факты, что повышение безопасности автомобиля слабо влияет на общее число жертв ДТП — поставили ABS, стали хуже соблюдать дистанцию, понаставили ремней, подушек и т.п. — стали гонять под 200 и так далее.
Не совсем понял к чем ты споришь и к чему эта аналогия.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
DOO>>- эффект компенсации риска (а вот с этим хуже). DOO>>Примером последнего могут служить такие интересные факты, что повышение безопасности автомобиля слабо влияет на общее число жертв ДТП — поставили ABS, стали хуже соблюдать дистанцию, понаставили ремней, подушек и т.п. — стали гонять под 200 и так далее.
IT>Не совсем понял к чем ты споришь и к чему эта аналогия.
Он говорит о законе сохранения рисков, являющегося прямым следствием твоего закона сохранения сложности. Минимизируя риск на одном уровне, мы просто переносим его на другой...(ну и далее по тексту)
Здравствуйте, DOOM, Вы писали:
IT>>Давай добавим сюда недостаточный уровень обучения ваших юзеров. DOO>Обучение тут не поможет. Вот ты дорогу вообще всегда на зеленый переходишь? Или все-таки нет? Научили что ли плохо?
Дорогу я перехожу, когда на ней нет машин. Если Нью-Йорк начнёт переходить дорогу только на зелёный, то он остановится. Что касается обучения и твоих уличных аналогий, то в качестве примера можно привести ещё одну. Например, пересечение двойной сплошной в штатах не является смертным грехом в отличии от России по той причине, что водители это делают лишь в случае необходимости и не злоупотребляют таким послаблением. Что будет если перестать наказывать за двойную сплошную в России? Вот такое обучение получается.
IT>>В моей конторе я обязан прослушать ряд курсов по безопасности и внутренним правилам компании, после чего должен ответить на ряд вопросов или поставить галку acknowledge. Естественно, есть вводная при поступлении на работу и ежегодные повторялки напоминалки. А если я это всё буду игнорировать, то мною серьёзно займётся Compliance Department. Всё это, кстати, сделано опять же без паранойки, а в максимально удобной и ненавязчивой для юзера форме. Итого, я знаю про безопасность, она знает про меня, мы друг друга уважаем и стараемся лишний раз не докучать друг другу.
DOO>Это хорошо, но тоже не идеально. В идеале все решения, связанные с безопасностью, должны приниматься профессионалами, а не пользователями.
Ну да. Кто по-твоему должен принимать решение о правах доступа пользователей к системе?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, DOOM, Вы писали:
IT>>>Давай добавим сюда недостаточный уровень обучения ваших юзеров. DOO>>Обучение тут не поможет. Вот ты дорогу вообще всегда на зеленый переходишь? Или все-таки нет? Научили что ли плохо?
IT>Дорогу я перехожу, когда на ней нет машин. Если Нью-Йорк начнёт переходить дорогу только на зелёный, то он остановится. Что касается обучения и твоих уличных аналогий, то в качестве примера можно привести ещё одну. Например, пересечение двойной сплошной в штатах не является смертным грехом в отличии от России по той причине, что водители это делают лишь в случае необходимости и не злоупотребляют таким послаблением. Что будет если перестать наказывать за двойную сплошную в России? Вот такое обучение получается.
Вывод: обучение также имеет свои границы применимости. Всегда останется какой-нибудь шибко умный, из-за которого все пойдет насмарку.
DOO>>Это хорошо, но тоже не идеально. В идеале все решения, связанные с безопасностью, должны приниматься профессионалами, а не пользователями. IT>Ну да. Кто по-твоему должен принимать решение о правах доступа пользователей к системе?
О правах доступа пользователей к системе — никто. Это должно быть автоматически.
А вот о доступе сотрудника к информации — владелец этой самой информации. Если ты руководишь проектом у тебя возникает вопрос, что кому должно быть доступно? Вряд ли. Теперь представим идеальную систему управления проектами, где ты создаешь проект, собираешь команду, накидываешь исходные данные и даже не вспоминаешь о таких мелочах, как доступ — вот это правильная система.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, DOOM, Вы писали:
IT>>>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности. DOO>>Прям-таки любых?
IT>Любых чего?
систем безопасности.
IT>Не совсем понял к чем ты споришь и к чему эта аналогия.
Я спорю с тезисом "Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности".
Юзеры не любят именно саму безопасность — это свойственно человеку.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Он говорит о законе сохранения рисков, являющегося прямым следствием твоего закона сохранения сложности. Минимизируя риск на одном уровне, мы просто переносим его на другой...(ну и далее по тексту)
Т.е. у проблемы нет решения?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, DOOM, Вы писали:
DOO>>>Это хорошо, но тоже не идеально. В идеале все решения, связанные с безопасностью, должны приниматься профессионалами, а не пользователями. IT>>Ну да. Кто по-твоему должен принимать решение о правах доступа пользователей к системе? DOO>О правах доступа пользователей к системе — никто. Это должно быть автоматически. DOO>А вот о доступе сотрудника к информации — владелец этой самой информации.
А доступ к информации имеет отношение к безопасности?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Он говорит о законе сохранения рисков, являющегося прямым следствием твоего закона сохранения сложности. Минимизируя риск на одном уровне, мы просто переносим его на другой...(ну и далее по тексту)
IT>Т.е. у проблемы нет решения?
Есть. Но очень сложное.
Вот сравни: в одной стране принимают закон, что все велосипедисты должны ездить в шлемах — компенсация риска работает, проку от меры очень мало.
В другой стране понимают, что большинство ДТП приходится на столкновение велосипедов с автомобилями, поэтому их надо изолировать друг от друга и делают выделенные дорожки для велосипедистов. Тут эффект компенсации риска уже не работает, потому что угрозу сделали неактуальной. Остается только эффект чудака на букву м — когда велосипедист выпрется на автомобильную дорогу и наоборот. Но тут уж ничего не поделаешь — и самолеты падают
Вот в таком русле и надо мыслить, внедряя решения по ИБ — они не должны быть сильно заметными, но при этом их должно быть чертовски сложно обойти. Как выше в моем примере с идеальной системой управления проектами.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, DOOM, Вы писали:
DOO>>>>Это хорошо, но тоже не идеально. В идеале все решения, связанные с безопасностью, должны приниматься профессионалами, а не пользователями. IT>>>Ну да. Кто по-твоему должен принимать решение о правах доступа пользователей к системе? DOO>>О правах доступа пользователей к системе — никто. Это должно быть автоматически. DOO>>А вот о доступе сотрудника к информации — владелец этой самой информации.
IT>А доступ к информации имеет отношение к безопасности?
А это уже как повернешь.
В конечном итоге необходимость защиты информации должен определить владелец (ну некому больше!) об этом даже наши самые зашоренные документы в один голос говорят. Просто кроме этого он уже не обязан ничего определять — никаких конкретных мер, моделей доступа и т.п. Только, что эту информацию должны видеть не все, а только те, кому он разрешит. Это не совсем security decision, о котором я говорил выше.
Здравствуйте, DOOM, Вы писали:
IT>>Не совсем понял к чем ты споришь и к чему эта аналогия.
DOO>Я спорю с тезисом "Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности". DOO>Юзеры не любят именно саму безопасность — это свойственно человеку.
Человеку свойственно относится индифферентно к вещам, которые ему не мешают и никак не трогают. Более того, я, к примеру, очень люблю безопасность у себя дома и даже плачу за неё деньги. Но когда Online Shield периодически достаёт одними и теми же сообщениями без возможности настроить всё как мне надо, то я начинаю его ненавидеть. А проблемка лишь в бестолковом и непродуманном интерфейсе.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, DOOM, Вы писали:
DOO>>>>>Это хорошо, но тоже не идеально. В идеале все решения, связанные с безопасностью, должны приниматься профессионалами, а не пользователями. IT>>>>Ну да. Кто по-твоему должен принимать решение о правах доступа пользователей к системе? DOO>>>О правах доступа пользователей к системе — никто. Это должно быть автоматически. DOO>>>А вот о доступе сотрудника к информации — владелец этой самой информации.
IT>>А доступ к информации имеет отношение к безопасности? DOO>А это уже как повернешь.
Как можно так повернуть, чтобы доступ к информации не имел отношения к безопасности?
DOO>В конечном итоге необходимость защиты информации должен определить владелец (ну некому больше!) об этом даже наши самые зашоренные документы в один голос говорят. Просто кроме этого он уже не обязан ничего определять — никаких конкретных мер, моделей доступа и т.п. Только, что эту информацию должны видеть не все, а только те, кому он разрешит. Это не совсем security decision, о котором я говорил выше.
Ну то есть получается, что решения связянные с безопасностью принимают не профессионалы, а сами пользователи. Т.е. система противоречива и не может быть идеальной в принципе.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, DOOM, Вы писали:
IT>>>Не совсем понял к чем ты споришь и к чему эта аналогия.
DOO>>Я спорю с тезисом "Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности". DOO>>Юзеры не любят именно саму безопасность — это свойственно человеку.
IT>Человеку свойственно относится индифферентно к вещам, которые ему не мешают и никак не трогают.
На самом деле бывает, что действие не мешает и никак не трогает — но его еще надо сделать. А мотивации внутренней на это действие нет — только дубинка внешняя. Это не только к безопасности относится — так человек встречает все новое и непривычное. Ту же систему контроля версий (помню свое первое знакомство с VSS )
IT>Более того, я, к примеру, очень люблю безопасность у себя дома и даже плачу за неё деньги.
У тебя и ник соответствующий
Мне вот безопасности на работе хватает и я никак не могу себя заставить настроить iptables на своем домашнем сервере, поставить snort и сделать его таки основным шлюзом в иннет
IT>Но когда Online Shield периодически достаёт одними и теми же сообщениями без возможности настроить всё как мне надо, то я начинаю его ненавидеть. А проблемка лишь в бестолковом и непродуманном интерфейсе.
Еще раз: на работе тебя никто не должен ни о чем спрашивать, что потребует от тебя решения по безопасности (то, что я назвал security decision — честно говоря, мне трудно дать четкое определение этому понятию, загляну в разрекламированную тут мною книгу, термин я оттуда подчерпнул).
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, DOOM, Вы писали:
DOO>>>>>>Это хорошо, но тоже не идеально. В идеале все решения, связанные с безопасностью, должны приниматься профессионалами, а не пользователями. IT>>>>>Ну да. Кто по-твоему должен принимать решение о правах доступа пользователей к системе? DOO>>>>О правах доступа пользователей к системе — никто. Это должно быть автоматически. DOO>>>>А вот о доступе сотрудника к информации — владелец этой самой информации.
IT>>>А доступ к информации имеет отношение к безопасности? DOO>>А это уже как повернешь. IT>Как можно так повернуть, чтобы доступ к информации не имел отношения к безопасности?
Черт. Уже и в книжку заглянул — термина security decision нет в предметном указателе, придется отдуваться самому.
Итак. Скажем следующее: решение о необходимости ограничения доступа к информации может быть принято только ее владельцем — ну некому больше тупо... А раз он принял решение доступ ограничить — то он наверное знает кому его надо таки предоставить. Это, так сказать, априорная информация в нашей системе. База индукции. Но это не является решением, связанным с обеспечением безопасности. Надеюсь, я понятно объяснил? Владелец по сути задачу поставил — а система ее выполнила — она занимается обеспечением безопасности, а не владелец.
IT>Ну то есть получается, что решения связянные с безопасностью принимают не профессионалы, а сами пользователи.
Решения, связанные с обеспечением безопасности принимают только профессионалы.
IT>Т.е. система противоречива и не может быть идеальной в принципе.
Нет. Система гордая — пока не пнешь, не полетит. Кто-то внешний все равно задачу ставит.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Он говорит о законе сохранения рисков, являющегося прямым следствием твоего закона сохранения сложности. Минимизируя риск на одном уровне, мы просто переносим его на другой...(ну и далее по тексту)
IT>Т.е. у проблемы нет решения?
Продолжим намеки аналогиями
"Конфиденциально", "доступно", "целостно" — выберите любые два
Здравствуйте, DOOM, Вы писали:
A>>Хороший пример — это криптографические протоколы, которые математически уже столь сложны, что проверить их принципиальную "безопасность" могут лишь единицы криптографов. DOO>Все симметричные протоколы построены на идее гаммирования с обратной связью или без нее (обычно задается режимом). 99% использует конструкцию Фейстеля. Так что не надо — все там изучено вдоль и поперек. Шифры замечательно оцениваются по параметру криптостойкости (иначе к чему был этот долгий процесс выбора реализации AES?).
Простая структура отнюдь не означает простоты для анализа шифра. На примере того же DES, до сих пор не известно как влияют на криптостойкость выбор S-блоков и почему для DES были выбраны одним агенством, известным в узких кругах, именно эти блоки.
AES — это вполне определённый шифр Rijndael, который математически очень сложен для его оценки. Вот, например, мнение Шнайера: http://www.schneier.com/blog/archives/2009/07/another_new_aes.html
A>>Но даже и при этом, все эти протоколы состоят из примитивов, которые математически опираются на "достаточно долгий процесс взлома простым перебором". DOO>Э-э-э-э-э... А ты точно хорошо ориентируешься в теме?
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, DOOM, Вы писали:
A>>>Хороший пример — это криптографические протоколы, которые математически уже столь сложны, что проверить их принципиальную "безопасность" могут лишь единицы криптографов. DOO>>Все симметричные протоколы построены на идее гаммирования с обратной связью или без нее (обычно задается режимом). 99% использует конструкцию Фейстеля. Так что не надо — все там изучено вдоль и поперек. Шифры замечательно оцениваются по параметру криптостойкости (иначе к чему был этот долгий процесс выбора реализации AES?).
A>Простая структура отнюдь не означает простоты для анализа шифра. На примере того же DES, до сих пор не известно как влияют на криптостойкость выбор S-блоков и почему для DES были выбраны одним агенством, известным в узких кругах, именно эти блоки.
Вообще-то вопрос влияния S-блоков на подобные шифры определенным образом изучен... Для того же ГОСТ 28147 найдены уязвимые последовательности S-блоков (а конкретные S-блоки у нас тоже выдает только одно конкретное ведомство, что используют для раздувания слухов о том, что они скрывают конкретные S-блоки умышленно).
А вообще логика странная — вон физики-то вообще, что ни придумают все равно каждый раз натыкаются на новую ситуацию, требующую объяснения. При этом, вроде, никто под сомнение не ставит, что физика описывает картину мира.
A>AES — это вполне определённый шифр Rijndael, который математически очень сложен для его оценки. Вот, например, мнение Шнайера: http://www.schneier.com/blog/archives/2009/07/another_new_aes.html
Тем не менее оценка проводилась и многие кандидаты были забракованы по разным причинам.
A>>>Но даже и при этом, все эти протоколы состоят из примитивов, которые математически опираются на "достаточно долгий процесс взлома простым перебором". DOO>>Э-э-э-э-э... А ты точно хорошо ориентируешься в теме? A>А сам-то разбираешься?
Ну как бы 1.5 года критографии было и еще семестр криптопротоколов... Давненько правда, но помню еще что-то...
Здравствуйте, DOOM, Вы писали:
A>>Простая структура отнюдь не означает простоты для анализа шифра. На примере того же DES, до сих пор не известно как влияют на криптостойкость выбор S-блоков и почему для DES были выбраны одним агенством, известным в узких кругах, именно эти блоки. DOO>Вообще-то вопрос влияния S-блоков на подобные шифры определенным образом изучен... Для того же ГОСТ 28147 найдены уязвимые последовательности S-блоков (а конкретные S-блоки у нас тоже выдает только одно конкретное ведомство, что используют для раздувания слухов о том, что они скрывают конкретные S-блоки умышленно).
"Определённым образом" изучен — это конечно так, никто и не говорит, что нельзя их совсем изучить. Речь только о том, что суть их влияния на свойства шифра до конца проанализировать не удалось. Найти простые блоки, которые делают шифр уязвимым можно хоть перебором, но суть от этого не меняется.
DOO>А вообще логика странная — вон физики-то вообще, что ни придумают все равно каждый раз натыкаются на новую ситуацию, требующую объяснения. При этом, вроде, никто под сомнение не ставит, что физика описывает картину мира.
Физика — это физика, у неё другая логика развития. Криптография — это математика.
A>>AES — это вполне определённый шифр Rijndael, который математически очень сложен для его оценки. Вот, например, мнение Шнайера: http://www.schneier.com/blog/archives/2009/07/another_new_aes.html DOO>Тем не менее оценка проводилась и многие кандидаты были забракованы по разным причинам.
И? Как это меняет то, что сложность AES превосходит наши возможности для его анализа? Оценить и провести простой анализ вполне можно, но провести полный анализ современных шифров невозможно — они слишком сложны.
A>>>>Но даже и при этом, все эти протоколы состоят из примитивов, которые математически опираются на "достаточно долгий процесс взлома простым перебором". DOO>>>Э-э-э-э-э... А ты точно хорошо ориентируешься в теме? A>>А сам-то разбираешься? DOO>Ну как бы 1.5 года критографии было и еще семестр криптопротоколов... Давненько правда, но помню еще что-то...
Отлично, значит можешь попробовать аргументированно возразить, а не переходить на личности и квалификацию собеседника.
Здравствуйте, Andir, Вы писали:
DOO>>А вообще логика странная — вон физики-то вообще, что ни придумают все равно каждый раз натыкаются на новую ситуацию, требующую объяснения. При этом, вроде, никто под сомнение не ставит, что физика описывает картину мира. A>Физика — это физика, у неё другая логика развития. Криптография — это математика.
Да то же самое — мы не можем обсчитать движение атомов даже одной песчинки, а туда же — предсказываем движение объектов солнечной системы.
A>>>AES — это вполне определённый шифр Rijndael, который математически очень сложен для его оценки. Вот, например, мнение Шнайера: http://www.schneier.com/blog/archives/2009/07/another_new_aes.html DOO>>Тем не менее оценка проводилась и многие кандидаты были забракованы по разным причинам. A>И? Как это меняет то, что сложность AES превосходит наши возможности для его анализа? Оценить и провести простой анализ вполне можно, но провести полный анализ современных шифров невозможно — они слишком сложны.
Для шифра можно показать, что он, например, является совершенным по Шеннону. Причем достаточно легко. Можно еще провести кучу формальных проверок, которые, к примеру, никогда не пройдет шифр простой замены.
Этого достаточно для применения. То, что теоретически может найтись сочетание из специально подобранных параметров криптосистемы, когда пространство ключей удастся сузить — это то самое движение молекул песчинки.
A>>>>>Но даже и при этом, все эти протоколы состоят из примитивов, которые математически опираются на "достаточно долгий процесс взлома простым перебором". DOO>>>>Э-э-э-э-э... А ты точно хорошо ориентируешься в теме? A>>>А сам-то разбираешься? DOO>>Ну как бы 1.5 года критографии было и еще семестр криптопротоколов... Давненько правда, но помню еще что-то... A>Отлично, значит можешь попробовать аргументированно возразить, а не переходить на личности и квалификацию собеседника.
Ну на личности переходить я не собирался. Просто сильно удивило заявление.
Прошу извинить, если задело.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>
KV>>безопасность — это не баззворд, просто это понятие дискредитировано недобросовестными поставщиками. юзеры это слово не любят и повторяют как ругательство, ибо неизбежные ограничения их свобод, а эксперт по безопасности вполне в состоянии оценить эту самую безопасность. И, таки-да, это можно доказать строго и математически (я хз как математически, но логически — легко)
IT>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
Я бы даже больше сказал, юзеры не только любят безопасность, но еще и требуют ее. А "ограничения личных свобод" не только не неизбежны, но и очень часто вообще не возникают. Как пример Win-UAC
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, FDSC, Вы писали:
FDS>>Ну да. Но когда говорят, что они мешают работать, то это имеются в виду явно все. DOO>У меня на работе безопасность, собственно работе, не мешает. Делая такое же обобщение, я могу сказать, что проблем никаких нет
Ну дык и? Получили что? Что некоторые системы контроля версий, так же как и некоторые системы безопасности, мешают. Что и требовалось мне доказать. НЕКОТОРЫЕ системы мешают, а НЕКОТОРЫЕ — нет. Вот я линчо, и кодёнок, думаю, тоже, против тех, что мешают.
Лично мне, например, системы контроля версий, если они хорошие, удобные и исправно работают, никогда не мешали.
DOO>А в чем у них собственно неадекватность безопасности? У них криво реализован принцип наименьшего доступа — это правильно на самом деле. Когда у него какая-нибудь блондинка легким движением мыши похерит всю работу за день, он это осознает. У них криво реализован ... — это правильно на самом деле.
Если всё правильно — блондинка ничего не похерит или похерит, но можно будет сделать откат.
А вот если эта блондинка — ценный сотрудник, и то, что она делает, очень нужно, но ни её начальник, ни начальник начальника не имеют права дать ей право заниматься этой нужной (и, в общем-то, непосредственно связанной со служебными обязанностями) деятельностью — вот это уже криво
В СССР то же считали, что лучше на оборону кучу денег потратить, в итоге был нарушен принцип, что обороняемый объект стоит дороже, чем его оборона. Здесь то же самое: криво реализованный принцип наименьшего доступа может стоить больше, чем полное отсутствие какого-либо разграничения доступа вообще.
FDS>>Прикидываться не надо. Мои пользователи никогда не жалуются на то, что мои программы мешают (а если мешают, я убираю то, что мешает). DOO>Не верю. Либо у тебя очень ограниченное число потребителей этой программы, либо ты далеко не все знаешь.
Да, число ограниченное, конечно — я их всех знаю в лицо (на крайняк, под псевдонимами удалённо). Но и безопасность делается не для всего мира.
Опять же, куча программ, те же системы контроля версий, лично мне никогда не мешают (если правильная система используется), а вот безопасность, почему-то мешает очень часто. Чаще, чем все остальные программы вместе взятые (кроме моих собственных). Ну, скажем так, сейчас безопасность не мешает, но раньше мешала (когда другой заказчик был)
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> Какой в этом интерес, кроме академического?
А какой в этом академический интерес?
Re[10]: О том, как плохо понимать термин безопасность по уче
Здравствуйте, 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) тех же самолетов — ты там тоже никогда в жизни не обсчитаешь вообще все, но теория и подход позволяют разбить задачу на подзадачи, выделить наиболее критичные моменты, сформулировать общие подходы и т.д. и т.п. Это как бы и есть прикладное применение научных методов и с чем ты тут споришь — мне непонятно
Re[11]: О том, как плохо понимать термин безопасность по уче
Здравствуйте, 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 системы и т.д. и т.п.
Мой. Но мне, значит, мешает, и не только мне.
Кстати, интересно звучит, что ты то же самое можешь сказать про целый список систем: очевидно, что это наглое враньё Потому что я сказал, что одна система мешает больше, чем остальные вместе взятые.
Нельзя. Доказать что-либо математически про реальный мир принципиально нельзя, исключая некоторые модели, которые можно ясно формализовать (шахматы, например)
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>Кроме этого, я могу без математики сконструировать тот же самолёт, просто работы это потребует больше, а безопасность всё равно останется такой же (в общем-то, плохой).
Ты правда так думаешь? Ну мне, пожалуйста, хотя бы высокоуровневый план нарисуй по сборке среднемагистрального авиалайнера.
Re[12]: О том, как плохо понимать термин безопасность по уче
Здравствуйте, 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>Кто-то здесь говорил, что такое нужно?
Отсутствие какого-то механизма — тоже уязвимость
И вот пока мы не пройдем по всей этой рекурсии вплоть до микрокода процессора, в лучшем случае, или до взаимодействия элементарных частиц в кристаллах кремния в худшем, мы строго-логически не может сколь-нибудь точно измерить безопасность всей этой эко-системы.
Если нам не помогут, то мы тоже никого не пощадим.
(там оно нафиг не упало, весь трафик шифровать)
Вы нам напишите четко, что вас не устраивает и как должно быть, у нас все сроки в прошлом полугодии вышли, а вы нам внедрение тормозите 
И вот хрен им, а не TMT. Пусть в визио рисуют и сами описания угроз вписывают 
