Ответ сколько стоит безопасность
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 17.11.09 00:24
Оценка: 118 (10)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Какую плату следует уплатить за обеспечение безопасности ?


Как и обещал — "нетрадиционный" (и весьма развернутый) ответ Дело в том, что я задолбался вещать здесь про безопасность как по-настоящему нетрадиционными способами (в форме сказок
Автор: kochetkov.vladimir
Дата: 29.10.08
и рассказов
Автор: kochetkov.vladimir
Дата: 14.07.08
), так и в виде вполне себе формальных постов (раз
Автор: kochetkov.vladimir
Дата: 07.12.08
, два
Автор: kochetkov.vladimir
Дата: 03.06.08
) и ссылок/описаний тех или иных способов обеспечения безопасности (раз
Автор: kochetkov.vladimir
Дата: 20.02.09
, два
Автор: kochetkov.vladimir
Дата: 21.10.09
) (ссылки надерганы случайно, их конечно же больше, но лень все искать), а в ответ получать непонимание того, когда все это нужно применять и мою позицию по этому поводу.

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

Небольшой дисклеймер: я работаю не только на основном месте работы, но и периодически (хотя и не так периодически, как хотелось бы, но тем не менее) фрилансю, занимаясь ровно тем же самым, чем и на основном месте работы, поэтому в дальнейшем, под "работой" я буду подразумевать как то, так и другое, т.к. разницы между ними практически нет. Кроме того, я официально работаю в направлении безопасности уже 4ый год и успел как продвинуться нашей замысловатой карьерной лестнице
Автор: kochetkov.vladimir
Дата: 04.10.09
, так и получать высокие оценки в ходе ежегодной оценке персонала
Автор: kochetkov.vladimir
Дата: 11.02.08
, что дает мне повод считать избранные мной методики и стратегию управления информационной безопасностью не такими уж и неэффективными. Я не хвастаюсь, а просто указываю на весьма неудобный факт тем, что решит поспорить об эффективности этих методик и подходов.

Итак, давай пойдем логическим путем и попытаемся понять: чем же я занимаюсь в рабочее время? Моя должность называется "региональный менеджер по информационной безопасности" и единственной возлагаемой на меня задачей является решение всех вопросов, связанных с обеспечением информационной безопасности в нашем регионе (всегда рад объяснить, ваш Кэп ) Именно решение вопросов, а не обеспечение как таковое, т.к. второе лежит на плечах тех, кто является администратором либо владельцем той или иной системы/ресурса/процесса и т.п. Я лишь выступаю в роли эксперта в моменты принятия ответственными сотрудниками решений относительно обеспечения безопасности на их системах и в роли аудитора, контролируя выполнение этих решений в дальнейшем.

Обеспечение инФормационной безопасности суть — процесс, направленный на предотвращение убытков от вероятной реализации ряда угроз в отношении некоторых информационных активов, в защите которых мы заинтересованы. Согласен? Из этого следует сразу два важных вывода: сей процесс бесприбыльный, а следовательно отношение его стоимости к величине предотвращенных потерь должно в лучшем случае — стремиться к нулю, а в худшем — уж никак не должно быть равным или больше единицы. Так вот моей основной обязанностью является (каким бы это несвойственным для меня не казалось) максимально-возможное снижение стоимости принимаемых решений относительно безопасности при приемлемом уровне этой самой безопасности, в соответствии с политикой ИБ компании. Иными словами, у меня нет возможности тыкать безопасность во все щели и, тем самым, вгонять компанию в нецелесообразные затраты, не имея на то четких оснований, которые мне приходится не только озвучивать, но и порой защищать, если вдруг что. Даже, если бы мне этого сильно хотелось...

Каким же образом это происходит?

Из сказанного выше следует, что для принятия тех или иных решений по безопасности нам необходимо (хотя и не всегда достаточно):

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

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

а) угроза — нарушение одного из свойств безопасности информации. Есть несколько классификаций соответствия угроз и свойств безопасности, мне больше по душе, активно применяемый в MS "STRIDE" (spoofing, tampering, repudiation, information disclosure, denial of service и elevation of privilege):

Угроза                  Свойство
---------------------------------------------------
Подмена данных          Проверка подлинности
Изменение данных        Целостность
Аннулирование           Невозможность аннулирования
Раскрытие информации    Конфиденциальность
Отказ в обслуживании    Доступность
Повышение прав доступа  Авторизованность


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

К слову сказать "уязвимость" это способ/возможность, позволяющий реализовать ту или иную угрозу.

б) риск — совокупность факторов, позволяющих оценить значимость для нас той или иной угрозы, выявленной на предыдущем этапе. И опять-таки, я не отличусь оригинальностью и упомяну подход, применяемый в MS — "DREAD". Дело в том, что оценка рисков в классическом понимании (с четким выражением финансовой составляющей) крайне затруднена в том случае, если речь идет о рисках связанных с информационными угрозами. Сколько для оператора сотовой связи будет стоить разглашение тарифного плана, который он собирается выкинуть на рынок через неделю, чтобы оторвать у конкурентов очередной кусок абонентской базы? А сколько будет стоить разглашение детализации одного абонента? А во что выльется разглашение финансового отчета для инвесторов до его публикации в паблик? Вряд ли вообще возможно оценить в рублях все три риска. Однако, если мы абстрагируемся от денег, и разобьем все риски на три категории "низкий", "средний" и "высокий", то станет очевидно, что (в сравнении друг с другом) ситуация с абонентом это "низкий риск", с тарифным планом "средний", а с финансовым отчетом "высокий". Это уже дает нам возможность принимать те или иные решения относительно, например, приоритетов минимизации этих рисков, их финансировании и т.п. Так вот DREAD, это именно такая методология, позволяющая очень быстро оценить относительную величину того или иного риска применительно к информационным угрозам. Расшифровывается оно как "damage potential, reproducibility, exploitability, affected users, discoverability" и выглядит следующим образом:

(D) Ущерб:
        (3) захват контроля на системой
        (2) разглашение строго-конфиденциальной информации
        (1) разглашение конфиденциальной информации
(R) Воспроизводимость:
        (3) В любое время, безусловно
        (2) При выполнении тех или иных условий
        (1) Затруднена
(E) Эксплуатируемость:
        (3) даже индусом
        (2) профи
        (1) гуру
(A) Масштаб влияния:
        (3) все пользователи системы
        (2) некоторые из пользователей
        (1) несколько пользователей либо только анонимные пользователи
(D) Обнаруживаемость:
        (3) легкая, либо информация об уязвимости выложена в паблик
        (2) затруднена
        (1) скрыта


Циферки — это баллы, которые необходимо просуммировать и получить относительную оценку анализируемого риска: 12-15 — высокий, 8-11 — средний и 5-7 низкий.

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

Вот примерно так все и выглядит. Заметь, все описанное выше применимо как к самим процессам разработки ПО, так и к проектам, которые разрабатываются в рамках этих процессов. То же самое к вопросу о процессах эксплуатации ПО и эксплуатируемых продуктах. Это самое важное, поэтому повторю еще раз: безопасность процесса разработки продукта — это не то же самое, что безопасность самого продукта. Угрозы и риски там совершенно разные и закрываются/минимизируются они на разных уровнях и с различными затратами.

Очень хотелось привести реальные примеры, но уже безумно хочется спать, а через 4 часа — идти на работу (оценивать риски, ага), поэтому еще один момент и баиньки:

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

Надеюсь, намек понятен

Если есть вопросы, буду рад на них ответить

P.S (из разряда, "не удержался"):

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

Вот и в безопасности обычно — ровно то же самое, пока не приходим мы...

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.