сообщение, но там обсуждение ушло куда-то в совсем технические дебри, поэтому отвечу отдельной темой, ибо чистая философия
Процитирую фразу мыщъха оттуда:
безопасность -- это буззворд. юзеры это слово любят и повторяют как мантру, но оценить безопасность не может даже эксперт по этой самой безопасности
и, чуть ниже по ветке:
это можно доказать. строго и математически
Для тех, кому лень читать весь следующий поток сознания, вот сухая выжимка сказанного мной ниже:
безопасность — это не баззворд, просто это понятие дискредитировано недобросовестными поставщиками. юзеры это слово не любят и повторяют как ругательство, ибо неизбежные ограничения их свобод, а эксперт по безопасности вполне в состоянии оценить эту самую безопасность. И, таки-да, это можно доказать строго и математически (я хз как математически, но логически — легко)
Спасибо за внимание
Всех, кого данный посыл заинтересовал, прошу под кат.
Собственно, кат
А теперь, я, с вашего позволения, чуть-чуть пофилософствую, ибо осознания того, что я занимаюсь ненужным делом не только в свое свободное время, как мы недавно выяснили, но еще и в рабочее, моя изнеженная психика просто не вынесет
Для начала, попробую доказать утверждение мыщъха о том, что оценить безопасность нельзя:
Информационная система, по определению, есть система обработки, хранения и передачи информации. Именно у информации есть состояние безопасности. Информация находится в состоянии безопасности тогда, когда выполняются ровно три условия:
1. Она конфиденциальна, т.е. ее могут получить только те приемники, которые имеют на это право
2. Она целостна, т.е. ее передача от источника А к приемнику Б не вносит изменений в нее
3. Она доступна, т.е. все приемники, имеющие право получать эту информацию, могут получить ее в данный момент времени
А давайте теперь прикинем: можем ли мы заложить необходимые и достаточные "метаусловия" выполнения этих условий в саму информацию? Конфиденциальность — да, информация, например, может быть зашифрована ключом, который есть только у лиц, имеющих право на доступ к ней. Целостность — тоже да, ибо коды коррекции, цифровые подписи и т.п. Доступность... упс. Доступность зависит от таких внешних факторов, как например, канал передачи информации. Т.е. мы можем лишь обеспечить лишь необходимые условия доступности при кодировании информации (например, использовать алгоритм кодирования известный принимающей стороне), но этого еще недостаточно для обеспечения ее доступности.
А следовательно (внимание, это очень важно), мы не можем оценить состояние безопасности информации, рассматривая ее в отрыве от ИС, в которой она хранится, обрабатывается и передается. Не вопрос, давайте рассмотрим и ИС. Чем там у нас является ИС по определению? "Совокупностью программных и технических средств, обеспечивающих хранение, обработку и передачу информации". А что такое программные средства в архитектуре Фон-Неймана (и не только в ней, как мы однажды выяснили)? Да точно такая же информация с тем же самым состоянием безопасности и условиями для его обеспечения, оценить которое в отрыве от ИС, обрабатывающей эту информацию мы не можем. А чем у нас является ИС? См. выше. Чтобы добить спрошу: а с какой вероятностью конечная информация находится в состоянии безопасности, если ИС третьего уровня вложенности в этом состоянии не находится? И вот пока мы не пройдем по всей этой рекурсии вплоть до микрокода процессора, в лучшем случае, или до взаимодействия элементарных частиц в кристаллах кремния в худшем, мы строго-логически не может сколь-нибудь точно измерить безопасность всей этой эко-системы.
Тут ты совершенно прав. Неправ ты в том, что измерить-то ее нельзя, но вот оценить вполне можно. В реальном мире никого не волнует насколько уязвима система, и никто не требует столь детальной оценки ее безопасности. Как правило, это происходит следующим образом: "Володя, вот наша новая система е-платежей, которую для нас разработал подрядчик, вот ее исходники (30-40Мб архива), через неделю дай свою оценку по ее готовности к эксплуатации в продуктиве". И если маркетологи прогнозируют существенный доход от этой системы (а они всегда прогнозируют существенный доход от своих систем), то если я через неделю хотя бы заикнусь о том, что мол система наверное небезопасна, потому что я успел дойти только до микрокода и в продуктив ее нельзя, меня уволят нахрен в тот же день, потому что от меня ждут ровно двух вещей:
1. Выявления рисков информационной безопасности, существующих в этой системе
2. Рекомендаций по их устранению, или минимизации ущерба в случае их реализации
Выделенное — важно, потому что если прогнозируемый, но минимизированный ущерб несоизмерим с ожидаемой прибылью, то система будет запущена в эксплуатацию, какой-бы дырявой она не была. Разумеется при этом учитывается не только ущерб в финансовом отношении, но и репутационный, косвенный от возможных судебных исков и т.п. Но учитывается он также приближенно, как и уровень прибыли маркетологами, поэтому в целом, для бизнеса, данный подход является более чем приемлемым. Об одном из подходов я подробно писал здесь
Считаться же баззвордом это понятие стало от того, что на фоне реальной сложности с проведением такой оценки, многие security-компании стали этим бессовестно пользоваться, чтобы впихнуть свои решения или услуги доверчивым клиентам. Но то, что ими это понятие активно дискредитируется, еще не значит, что оно на самом деле таковым является.
Если же говорить о математической строгости, то можно математически строго доказать небезопасность любой реализованной информационной системы и разговаривать, в общем-то, будет больше не о чем. Но жить тогда станет совсем скучно
KV>безопасность — это не баззворд, просто это понятие дискредитировано недобросовестными поставщиками. юзеры это слово не любят и повторяют как ругательство, ибо неизбежные ограничения их свобод, а эксперт по безопасности вполне в состоянии оценить эту самую безопасность. И, таки-да, это можно доказать строго и математически (я хз как математически, но логически — легко)
Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
Если нам не помогут, то мы тоже никого не пощадим.
сообщение, но там обсуждение ушло куда-то в совсем технические дебри, поэтому отвечу отдельной темой, ибо чистая философия
KV>Процитирую фразу мыщъха оттуда:
KV>
KV>безопасность -- это буззворд. юзеры это слово любят и повторяют как мантру, но оценить безопасность не может даже эксперт по этой самой безопасности
KV>и, чуть ниже по ветке:
KV>
KV>это можно доказать. строго и математически
KV>Для тех, кому лень читать весь следующий поток сознания, вот сухая выжимка сказанного мной ниже:
KV>
KV>безопасность — это не баззворд, просто это понятие дискредитировано недобросовестными поставщиками. юзеры это слово не любят и повторяют как ругательство, ибо неизбежные ограничения их свобод, а эксперт по безопасности вполне в состоянии оценить эту самую безопасность. И, таки-да, это можно доказать строго и математически (я хз как математически, но логически — легко)
"Безопастность" — это абстрактное понятие, которое ничего конкретного не означает, и, соответственно, не может быть не измерено не оценено. Именно в этом смысле оно обычно употребляется маркетологами.
Но вот "Безопастность чего-то от чего-то" — уже вполне конкретный термин, с которым можно работать (оченивать, доказывать...)
"Безопастность" не существует без отрыва от модели угроз и описания предмета защиты. А если вышеуказанное описано, то не возникает вопроса о безопасности уровня процессора и ниже.
Сравните, к примеру, несколько вопросов к специалисту по безопасности и подумайте, какие могут быть ответы:
1. Мы передаём информацию по https. Это безопасно?
2. Мы передаём информацию по https. Считаем угрозой перехват передаваемых данных в канале передачи. Это безопасно?
3. Мы передаём информацию по https. Считаем угрозой перехват информации через взлом нашего web-сервера из внутренней сети. Это безопасно?
4. Мы передаём информацию по https. Считаем угрозой перехват факта передачи информации другой стороне. Это безопасно?
То есть, по моему мнению, специалист по безопасности занимается вполне конкретной работой. Только результирующая оценка "безопасности" это нечто гораздо большее, чем одно число, показывающее "безопасность системы в процентах".
А именно оно зачастую нужно маркетологу
Здравствуйте, IT, Вы писали:
IT>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
Юзер зачастую не способен правильно оценить опасность и может считать предлагаемые для повышения безопасности действия — излишней параноидальностью. Некоторые даже приклеивают sticky notes с паролями на монитор, а когда им запрещаешь это делать — они считают это параноидальностью
Здравствуйте, IT, Вы писали:
IT>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
В идеале — да. Но у нас юзеры не любят, к примеру, что им предоставляют только те полномочия во внутренних системах, которые им необходимы для исполнения их служебных обязанностей. Например админ, у которого в обязанности входит администрирование лишь одного куста в иерархии AD, почему-то требует права домен-админа и не получив их, клянет именно безопасность в том, что ему вставляют палки в колеса. Или вот еще, юзеры очень не любят, что у нас запрещено работать под чужой учеткой и также клянут нас за это при любом удобном случае. Где тут что-то из перечисленного тобой?
Здравствуйте, vmpire, Вы писали:
V>"Безопастность" — это абстрактное понятие, которое ничего конкретного не означает, и, соответственно, не может быть не измерено не оценено.
Оно означает отношение среднего-арифметического оценки незакрытых рисков к среднему арифметическому оценки их общего числа
V>Именно в этом смысле оно обычно употребляется маркетологами.
Мы говорим о разных маркетологах, если что. Я, упоминая "маркетологов" имел ввиду тех, кто заинтересован в вводе в экплуатацию какой-либо системы, не связанной с непосредственно обеспечением безопаностьи. Можно заменить моих "маркетологов" на "финансистов" или "технарей", чтобы не смущало.
V>Но вот "Безопастность чего-то от чего-то" — уже вполне конкретный термин, с которым можно работать (оченивать, доказывать...) V>"Безопастность" не существует без отрыва от модели угроз и описания предмета защиты. А если вышеуказанное описано, то не возникает вопроса о безопасности уровня процессора и ниже.
Как раз это и описано по той ссылке, которую я привел в конце сообщения
V>Сравните, к примеру, несколько вопросов к специалисту по безопасности и подумайте, какие могут быть ответы:
Я подобные вопросы слышу ежедневно, если что Вот только звучат они несколько иначе:
(решается вопрос о вводе в эксплуатацию новой системы)
1. Разработчики: вот наша безопасная система
2. Я: почему вы считаете ее безопасной?
3. Разработчики: данные передаются по https
4. Я: Зачем? (там оно нафиг не упало, весь трафик шифровать)
5. Разработчики: чтобы удовлетворить требования по ИБ к системе
6. Я: И? Ну ок, а с repudiation вот тут и denial of service вот здесь, что будем делать?
7. Разработчики: С чем? Вы нам напишите четко, что вас не устраивает и как должно быть, у нас все сроки в прошлом полугодии вышли, а вы нам внедрение тормозите (еще и руководству жалуются иногда, чтобы наверняка прикрыться).
Я конечно описал крайний случай, но разработчики крайне редко общаются с безопасниками в терминах "угрозы-риски-контрмеры", это безопасники общаются с ними именно так. А в целом — да, вы правы. Плясать нужно от конкретных угроз, а не гоняться за химерами. Почитайте мое сообщение по той ссылке.
V>То есть, по моему мнению, специалист по безопасности занимается вполне конкретной работой. Только результирующая оценка "безопасности" это нечто гораздо большее, чем одно число, показывающее "безопасность системы в процентах".
Ну, у нас это отчет, описывающий все выявленные риски, их критичность, сценарии атак и рекомендации по устранению или минимизации. Но руководству по итогам работы прхиодит именно одно число, по формуле, которую я привел в начале. Ибо руководство банально не поймет того, что в этих отчетах написано, а цифра нагляднее и понятнее.
Здравствуйте, MozgC, Вы писали:
IT>>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
MC>Юзер зачастую не способен правильно оценить опасность и может считать предлагаемые для повышения безопасности действия — излишней параноидальностью. Некоторые даже приклеивают sticky notes с паролями на монитор, а когда им запрещаешь это делать — они считают это параноидальностью
Во! У меня как раз есть хороший пример с паролями и бестолковостью админов (надеюсь бывшей) одной большой компании. Когда-то давным давно в IBM мне нужно было иметь с десяток паролей от разных систем. У всех систем было разное время истечения срока паролей, разные требования и т.п. Например, в одной из них было требование к паролю ровно 8 символов. 8, не 4, не 10, а именно 8 и только 8. Запомнить десяток разношёрстных и постоянно меняющихся паролей я, естественно, не мог и закончилось всё, само-собой, файликом passwords.txt на десктопе. Когда я пришёл работать в Morgan Stanley, то меня приятно удивило насколько люди в этой конторе понимают эту проблему и сколько в неё вкладывают. В частности и я сам как разработчик обязан следовать определённым правилам. В MS у меня один пароль, ровно один (кроме payroll системы, но это отдельная история). Кроме этого каждый сотрудник компании должен прослушать специальный обучающий курс, где как раз всё чётко сказано и разъяснено и насчёт безопасности вообще и мониторов в частности.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, kochetkov.vladimir, Вы писали:
IT>>Юзеры не любят не саму безопасность, а излишнюю параноидальность, слабую информативность и бестолковость интерфейсов систем безопасности.
KV>В идеале — да. Но у нас юзеры не любят, к примеру, что им предоставляют только те полномочия во внутренних системах, которые им необходимы для исполнения их служебных обязанностей. Например админ, у которого в обязанности входит администрирование лишь одного куста в иерархии AD, почему-то требует права домен-админа и не получив их, клянет именно безопасность в том, что ему вставляют палки в колеса. Или вот еще, юзеры очень не любят, что у нас запрещено работать под чужой учеткой и также клянут нас за это при любом удобном случае. Где тут что-то из перечисленного тобой?
Давай добавим сюда недостаточный уровень обучения ваших юзеров. Но опять же вопрос — ваших юзеров вообще кто-нубудь когда-нибудь чему-нибудь из области безопасности учил? Хотя бы какие-нибудь элементарные азы? В моей конторе я обязан прослушать ряд курсов по безопасности и внутренним правилам компании, после чего должен ответить на ряд вопросов или поставить галку acknowledge. Естественно, есть вводная при поступлении на работу и ежегодные повторялки напоминалки. А если я это всё буду игнорировать, то мною серьёзно займётся Compliance Department. Всё это, кстати, сделано опять же без паранойки, а в максимально удобной и ненавязчивой для юзера форме. Итого, я знаю про безопасность, она знает про меня, мы друг друга уважаем и стараемся лишний раз не докучать друг другу.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, 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>Ну, у нас это отчет, описывающий все выявленные риски, их критичность, сценарии атак и рекомендации по устранению или минимизации. Но руководству по итогам работы прхиодит именно одно число, по формуле, которую я привел в начале. Ибо руководство банально не поймет того, что в этих отчетах написано, а цифра нагляднее и понятнее.
Можно хотя бы выдавать не одно число а три-четыре. Это руководство, обычно, осиливает.
Типа, "безопастность от внутренних угроз", "безопастность от внешних угроз", "безопастность от потери данных", "безопастность от разглашения данных".
Заодно, так можно лучше объяснить, над чем сейчас идёт работа.
Здравствуйте, 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>А мы коллеги, я так понимаю?
Частично. Мне приходилось пару раз делать аудит секьюрити системы, но это не основное моё занятие. Основное — всё-таки программирование.
В прошлом ещё был админом. А секьюрити было (и частично осталось) хобби.
Здравствуйте, 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 это объяснить легче и писать нужно меньше, но не более того
И вот пока мы не пройдем по всей этой рекурсии вплоть до микрокода процессора, в лучшем случае, или до взаимодействия элементарных частиц в кристаллах кремния в худшем, мы строго-логически не может сколь-нибудь точно измерить безопасность всей этой эко-системы.
Если нам не помогут, то мы тоже никого не пощадим.
(там оно нафиг не упало, весь трафик шифровать)
Вы нам напишите четко, что вас не устраивает и как должно быть, у нас все сроки в прошлом полугодии вышли, а вы нам внедрение тормозите 
