Как стать автором
Обновить

Комментарии 7

Интересно и по делу!
Кармы на плюсик нету, не обессудьте! )))
Спасибо, не плюсов ради :)
Спасибо за материал.
Может я упустил, но кмк начинают с того, а кто собственно наш противник. Отсюда появляется бюджет на ИБ, который уже тратится по Вашему плану. С противником главное не заиграться, но и нельзя недооценить. Хотя бюджет отрезвит ретивых руководителей.
От себя добавлю, что чаще всего встречал проблемы на границе систем в обмене данных. Два отличных приложения работают прекрасно по отдельности, а вот как одно в другое — и все. А еще человеческий фактор тут как тут.
По-хорошему, надо сделать взлом экономически невыгодным. Но если именно за вас взялись, то взломают все равно.
Благодарю за развернутый комментарий!
Да, все абсолютно верно.
Что касается противника, под вторым спойлером (**), как раз, было небольшое примечание, что деталями в этом материале умышленно пренебрегаю, т.к. описание полного подхода к моделированию и расстановке приоритетов привело бы к сильному увеличению размера статьи, и ее просто было бы невозможно прочитать. Если есть интерес к деталям, то постараюсь подробнее изложить все в отдельном материале. Если вкратце, то противников много, порой и мы сами себе, явно того не замечая, главное, хорошо осозновать собственные возможности и доступные ресурсы при выборе того или иного подхода.
Хороший пост, жду продолжения. Во многом, это про связь ISO 27k с ISO 9к — когда в компании уже четко определены процессы дающие итоговую прибыль, и понятно что важно, понятно что нужно защищать (на ИБ вопрос только как). Наверно, это не совсем правильно, когда специалист по безопасности выступает и в роли бизнес-аналитика — но это действительно реальность.

Деньги ещё не самое страшное. Самое страшное — это платёжные реквизиты и история списаний и зачислений. Вообще, я бы разделил:


  1. есть деньги пользователей,
  2. есть информация об этом,
  3. есть информация о том, откуда они получены и как пользователи их тратят (тут зависит от организации, конечно: у кого–то больше точек вывода, у кого–то меньше; чем меньше, тем спокойнее) и
  4. может быть информация о том, почему пользователь получает/тратит деньги именно так. В худшем случае окажется, что мы храним информацию о состоянии здоровья.
Тут, возможно, мне стоит радоваться, что подробной аналитики по пользователям у нас нет, поскольку мы не являемся платежной системой с развитой экосистемой ритейл-сервисов, а все наши продукты построены преимущественно вокруг действий пользователей с деньгами и над деньгами.
И опять же, информация о здоровье — это все та же информация, которую еще нужно злоумышленнику монетизировать или проэксплуатировать иным образом, а раскрытие подобной информации приводит к косвенному ущербу, т.е. прямой еще может не наступить, а в случае с финансовыми системами мы получаем сразу прямой ущерб без лишних условностей.

Вот еще пара хороших примеров, когда информационная безопасность слегка выходит за приделы «информационной»:
— медицинское оборудование для жизнеобеспечения, которое может удаленно управляться, соответственно реализация угрозы ведет к нанесению прямого вреда объекту, а не к косвенному, как могло бы быть при доступе к медицинской информации о нем (истории болезни, состоянии здоровья и т.п.);
— SCADA и промышленный IoT, тут также реализация угрозы может привестви к возможности управления защищаемым объектом, а ее эксплуатация — к нанесению вреда обществу и окружающей среде.

Идея в том, что есть информационная безопасность в чистом виде, когда мы защищаем информацию о чем-то, а получив информацию злоумышленник может действовать дальше, то ее не происходит прямое воздейтсвие на объект, информация о котором скомпрометирована, а есть информационная безопасность, которая защищает непосредственно объект от воздействия на него.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий