От техники безопасности — к безопасной технике!
Думаю, никто не станет возражать против того, что нам всем хотелось бы испытывать доверие к используемым нами средствам, в том числе и средствам автоматизации банковских процессов, программным продуктам. Это то, что нас объединяет.
В одном из действующих стандартов доверие определяется как основание для уверенности в том, что сущность отвечает своим целям. Мне кажется, это определение подходит для взгляда на ИТ- среду как с точки зрения специалистов ИБ, так и с точки зрения служб ИТ. Все зависит от того, о каких целях идет речь. Проблема заключается в том, что промежуточные («свои») цели у тех и у других достаточно различаются, хотя конечная цель, сверхзадача одна: поддержка эффективного банковского бизнеса.
На мероприятиях, посвященных применению информационных технологий в банках, не услышишь о проблемах взаимодействия с представителями ИБ. Участники таких мероприятий с энтузиазмом говорят о новых продуктах, сервисах и возможностях. Но почему же это волнует службы информационной безопасности? Ответ не нов: потому что блеск в глазах айтишника рано или поздно отливается слезами пользователя, вытирать которые должны почему-то не те, кто их вызвал.
Вот характерные примеры. Несколько лет назад активно обсуждались хищения при использовании систем дистанционного банковского обслуживании у клиентов, мол, у них там антивирусов нет, того нет, другого нет. Что они ставят коробку с дистрибутивом на системный блок, считая, что установили антивирус и т. д. И вообще, эти клиенты такие глупые и необразованные, надо повышать их грамотность.
Грамотность, конечно, повышать надо, но в то же время, подумайте, у клиента вообще-то совершенно другие задачи. Почему он должен заботиться о том, что ему нужно что-то там поставить, что именно поставить, да как это всё должно взаимодействовать? По-хорошему, ему нужно поставить только клиентскую часть ДБО и ни о чем больше не думать, просто соблюдать инструкции и не ломать голову про какие-то там антивирусы и межсетевые экраны.
Другой пример. Несколько месяцев назад у меня образовалось четыре карточки одного и того же банка — весьма известного, крупного российского банка, и как-то мне понадобилось перевести деньги с карточки. Я вставил карточку в банкомат, ввел ПИН, а банкомат мне показывает все мои четыре карты с остатками средств, и спрашивает: с какого счета будем переводить? Шок. То есть, если одна карта окажется скомпрометированной, можно потерять деньги со всех четырех. И кто такое придумал?
Причем меня не то, что не спросили, меня даже не уведомили об этом! Видимо посчитали, что это так удобно и приятно клиенту. Казалось бы, да, на первый взгляд, удобно. Не надо четыре карты вставлять, если ты не помнишь, на какой у тебя что лежит. Но с кем бы из знакомых я не говорил об этом — как с людьми из сферы ИБ, так и с обычными гражданами — у всех реакция была резко отрицательной.
Получается, ИТ-бизнес думает о своём и всем нам диктует свои решения. А мы собираемся на свои семинары-конференции и рассказываем друг другу, как они нас не понимают. Причина состоит в том, что сейчас положение таково: риски информационной безопасности создают одни, а понижать их должны другие. При таком базовом условии говорить об общих сверхзадачах можно до бесконечности и называется это просто: толочь воду в ступе. Пока нет ответственности за деяния свои, эти деяния будет продолжаться. Таков у нас статус-кво.
Есть ли выход? Конечно, есть. Был в советское время такой лозунг: «От техники безопасности — к безопасной технике!» Тогда сфера ИТ еще не появилась, но принципы были правильные. И неплохо бы этими принципами воспользоваться сегодня. Техника должна быть безопасной изначально! А значит тот, кто предоставляет ИТ-сервисы, тот и должен обеспечивать доверие к ним, включая их безопасность. Он не должен воспринимать требования безопасности как что-то если не чрезмерное, то по крайней мере внешнее, ему не нужное, и главное, как то, что должны обеспечить другие — специалисты по ИБ.
За функционал ИТ-изделия в конечном виде должна отвечать служба ИТ. Твое изделие, ты его выпускаешь (или принимаешь к использованию), с помощью него ты предоставляешь сервисы, вот и сделай так, чтобы оно было надежным и работало правильно.
Понятно, что в этом созидательном процессе должны участвовать и специалисты ИБ, но пользователям ведь неважно как устроен и укомплектован сборочный цех (и какие есть еще цеха), им важен продукт, который этот цех выпускает.
Аналогия, как известно, всегда страдает неполнотой, но тем не менее, мы покупаем автомобиль всегда с тормозами, АБС, подушками и т. д., а не собираем все это потом по отдельности, мучаясь и разбираясь, да какое оно должно быть, да как привинтить, да будет ли оно совместно работать.
Конечно, автомобиль и ИТ-сервис — это несколько разные продукты. И подход к созданию системы безопасности в них немного отличен. Например, как определить функционал? Проблема в том, что пока он точно не определен, появляется соблазн сделать его послабее, а значит, нужны тщательно прописанные требования, обязательные к исполнению. Соответственно для измерения (оценки) выполнения требований должны использоваться определенные метрики. Выбор требований и метрик должен быть определен в документах.
На различных форумах мы активно обсуждали общие перечни угроз, модели угроз, варианты наборов угроз… Все течет, все изменяется, и угрозы в первую очередь. В данном случае необходимо для каждого продукта сформулировать цели безопасности и задать варианты требований применительно к определенному типу и набору угроз. И такая модель безопасности продукта не должна быть статичной. Необходима привязка к стадиям жизненного цикла. На стадии разработки и внедрения — одни угрозы, на стадии эксплуатации — другие, модернизации — третьи, вывода — четвертые.
Понятно, что на этих стадиях к безопасности продукта предъявляются разные требования. Кроме того, разный характер угроз отражается в требованиях к функциям безопасности, и требованиях доверия, направленных на достижение уверенности, что эти функции реализуются так, как надо.
Необходимы соответствующие процедуры подтверждения соответствия.
Безусловно, ни одна компания, какой бы крупной, умной и авторитетной она ни была, не сможет решить эти вопросы в одиночку. Тут нужны комплексные компетенции и серьезная организация. Такие дела делаются только сообща.
Не менее важно другое. Все это в принципе можно выработать, но без обязательности применения эффекта не будет.
Что может заставить изменить статус-кво и запустить процесс разработки системы требований и придания обязательности их применению?
На VIII Уральском форуме «Информационная безопасность финансовой сферы» говорилось, что надвигается вал нормативных изменений. Вот, собственно, и возможность предпринять усилия, чтобы эти изменения шли именно в таком направлении. От техники безопасности — к безопасной технике.
(1).png)