Когда спадет маркетинговая пена

Наталья КасперскаяАвтор: Наталья Касперская, генеральный директор компании InfoWatch


«!БДИ»:
Авторитет современных служб ИБ в глазах бизнеса не настолько высок, чтобы вызывать зависть коллег. Казалось бы, служба ИБ должна быть заинтересована в том, чтобы более тесно взаимодействовать с бизнесом и влиять на качество управления бизнес-рисками. Однако это мало где происходит. Как Вы считаете, в чем состоит причина такой странной ситуации?

Наталья Касперская:
На мой взгляд, низкий авторитет служб ИБ является следствием того, что обеспечение информационной безопасности, как и любой другой безопасности, подразумевает введение различных ограничений. Применение каждого средства защиты вызывает у людей дискомфорт. Например, автомобильные ремни безопасности сковывают движения водителя и пассажиров. Состоящая из десятка замков система защиты на входных дверях сложна и неудобна в использовании. Пропускная рамка на входе в аэропорт затрудняет передвижение.

Средства обеспечения информационной безопасности не являются исключением. ИБ – это тормоза для ИТ-специалистов, которые «парят высоко в небе», увлекаясь красотой технологий, восторгаясь лучшими образцами мобильных устройств, их эффективностью и удобством. Но они упускают из вида, что информация с таких устройств будет доступна кому-то еще. А если, к тому же, владельцем устройства является чиновник, допущенный к государственной тайне, то слежка за этим человеком становится тривиальной задачей.

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

Ваши примеры красноречивы и очень жизненны. Но ведь основа всякого бизнеса – не уменьшение рисков, а увеличение прибыли. Если появляются новые возможности, даже сопровождаемые новыми рисками, то бизнес идет на их реализацию, и остановить его невозможно.

На самом деле все зависит от модели угроз. Если владелец бизнеса не видит особых угроз для своего бизнеса в области ИТ, он может игнорировать определенные риски. Гораздо хуже, когда модель угроз не строится вообще, а предприятие реагирует только на уже произошедшие инциденты. В просторечье о таком подходе к информационной безопасности говорят «пока жареный петух не клюнет», а специалисты используют термин «инцидентный менеджмент». Например, «безопасник» очень крупного банка сказал мне однажды, что в этом банке ИБ основана именно на принципе реагирования на инциденты. Упомянутый банк установил антивирусную защиту лишь шесть лет назад, хотя антивирусы уже годами используются не только во всех компаниях, но и на большинстве домашних компьютеров.

Однако, с другой стороны, сейчас многие ИБ-практики реализуются на аппаратных платформах и переходят в область компетенции ИТ.

Я бы не согласилась с этим утверждением. Что Вы имеете в виду?

Антивирусы, спам-фильтры, файерволы уже реализованы на аппаратных платформах и требуют только грамотных настроек и контроля со стороны ИБ-службы. Возможно, следующей реализацией на аппаратных платформах станут DLP-решения?

Встроить DLP-систему в аппаратную платформу не удастся еще, как минимум, лет пять. По крайней мере, на сегодняшний день данная проблема не решена. И причина – вовсе не в программном обеспечении, а в необходимости определения объектов информации, которые надо защищать. Это невозможно сделать автоматически, да и большинство предприятий вообще не знают, как это сделать. Как правило, в компаниях никак не категоризирована информация, не установлены сроки и ограничения ее использования. А без подобных установок решение для защиты от утечек бесполезно – нельзя найти то, не знаю что. Чем точнее определены объекты защиты, тем эффективнее будет работать DLP-продукт.

InfoWatch не случайно пропагандирует концепцию pre-DLP => DLP => post-DLP. Она определяет, что если на этапе pre-DLP не задать правила и не провести качественную категоризацию информации, то DLP-система работать не будет.

Именно поэтому с точки зрения управления ИБ DLP является сложной организационно-технической задачей, которая не может быть полностью реализована на аппаратных платформах. DLP – это всегда организационные меры плюс софт плюс, возможно, аппаратная часть.

Еще одна область, в которой чисто аппаратные средства плохо работают, – это таргетированные атаки. С ними антивирусные компании, по их собственным признаниям, не в состоянии бороться. По сути, таргетированные атаки представляют собой усложненные вирусы; они уникальны, поскольку написаны с прицелом на конкретные предприятия, и довольно часто состоят из нескольких частей. Их очень сложно выявлять, поэтому методы борьбы включают в себя не только организационные меры, но и работу аналитика.

Задача ИБ-служб состоит не в том, чтобы обеспечить абсолютную безопасность, а в том, чтобы снизить риски бизнеса. Нужно четко это понимать и верно выстраивать ожидания бизнеса от ИБ: определить, по каким параметрам мы собираемся снизить риски, где они особенно критичны, а где – нет… И тогда мы возвращаемся к разработке модели угроз и плана противодействия им. Как все это можно автоматизировать и превратить в техническую задачу?

Когда мы говорим о постоянно изменяющейся задаче, которую нельзя автоматизировать, нам, наверное, стоит задаться вопросом, как этими изменениями управлять. И в поисках верного ответа, мне кажется, мы не можем обходить стороной практики управления ИБ. Думаю, все то, о чем Вы сейчас рассказывали, о важности настройки DLP-систем, должно учитывать управление ИБ.

То, что нам часто выдают за управление информационной безопасностью, ссылаясь на лучшие мировые практики, не всегда отвечает поставленным задачам.

Да, существуют определенные стандарты ИБ. Они в значительной степени снижают риски появления тех или иных угроз, поскольку прописывают набор неких действий, которые не должны привести к росту количества угроз. Например, нельзя пересылать незашифрованные сообщения, переходить по сомнительным ссылкам, открывать прикрепленные файлы, полученные от незнакомых адресатов…

Но проблема состоит в том, что в цифровом мире сложность задач постоянно растет, угрозы становятся все более сложными и изощренными, а следовательно, набором стандартных рекомендаций уже не обойтись. Их постоянно приходится перестраивать. Другими словами, авторы этих практик и стандартов должны постоянно их обновлять, идя в ногу со временем. В принципе, они так и делают, но всегда с опозданием. И они просто не могут не запаздывать: сначала проблема должна стать критичной, потом ее необходимо осознать, описать, обсудить, утвердить, и когда, наконец, на свет появятся какие-то рекомендации, они окажутся уже не столь актуальными, как хотелось бы.

Кроме того, для каждого предприятия в силу его индивидуальной специфики управление ИБ всегда будет не типовым, а уникальным. И внедрение на конкретном предприятии определенных стандартов, скажем ISO 27000, может оказаться слишком сложным и неоправданным. Так, InfoWatch является примером предприятия, на котором не имеет смысла внедрять стандарты ISO – прежде всего, потому, что объем затрат на их внедрение не оправдается возможными выгодами.

И это – большая проблема таких стандартов. Как правило, все они – довольно сложные и требуют серьезных ресурсов, что неоправданно для небольшого предприятия. СМБ-компании могут обойтись более простыми методами, однако и в данном случае встает вопрос управления ИБ.

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

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

Если вернуться к теме стремительных изменений на рынке, то, пожалуй, самым ярким примером является исчезающий периметр ИБ.

Периметр прорывают, в первую очередь, мобильные устройства, ноутбуки и смартфоны. Компаниям пытались их навязать несколько лет назад в виде концепции BYOD. Но многие концепции на практике оказываются ни чем иным, как маркетинговой пеной, после оседания которой ожидаемая эффективность заметно бледнеет. И, на мой взгляд, концепция BYOD – пример такой пены. На самом деле никакой концепции нет. Это – просто феноменальная способность маркетологов преобразовывать в продукт даже то, что им не является. Принеси любой смартфон в компанию, и с него можно будет входить в корпоративный периметр, а на службу ИБ ляжет непосильный груз: как закрыть все уязвимости, которые появятся в корпоративной инфраструктуре вместе с огромным многообразием устройств? По сути, BYOD – попросту привнесение хаоса в корпорацию.

Аналитики IDC уже стали отмечать снижение интереса к BYOD. Когда службе ИБ приходится выполнить ряд мероприятий по обеспечению безопасного доступа в корпоративную сеть с личных устройств сотрудников компании, затраты на это заметно снижают эффективность применения таких мер.

Можно ли с этим что-то сделать? Конечно, можно. Не приносить свой девайс, а использовать корпоративный, пусть не столь удобный и модный, но зато нормально вписанный в систему управления информационной безопасностью предприятия.

Как выглядит в постоянно изменяющихся и усложняющихся внешних условиях потребность в обновленных компетенциях служб ИБ?

На мой взгляд, самая абсурдная задача из тех, которые ставят перед службой ИБ, звучит как «не допустить проникновения или появления любых угроз». Это невозможно выполнить, о чем мы уже неоднократно говорили. В области обеспечения безопасности не бывает гарантий. Более корректно задачу службы ИБ можно сформулировать так: управлять рисками и снижать их. Управление рисками и потоками корпоративной информации – более правильный путь. И это – тот самый путь, который в свое время проложила практика DLP.

DLP-решения – одни из первых средств на рынке ИБ, которые стали требовать системной классификации и категоризации внутрикорпоративной информации и управлять ею для борьбы с утечками. Тогда считалось, что это необходимо для предотвращения утечек. Но сейчас не только InfoWatch как вендор, но и офицеры информационной безопасности компаний начинают понимать, что нужны не только и не столько защита от утечек, сколько систематизация информации и понимание общей ситуации с ИБ предприятия.

Именно на базе DLP был создан уникальный инструментарий для анализа состояния информационных потоков в компании с точки зрения ИБ, который позволяет анализировать полученные данные и работать на опережение. Только так можно отойти от распространенного в области ИБ инцидентного менеджмента. Например, если сотрудник стал заходить на сайты вакансий, то, вероятно, он ищет новую работу. А значит, он собрался уйти из компании и может унести с собой ценную информацию. Хотелось бы знать об этом заранее и спрогнозировать последствия его ухода еще до того, как он положит на стол заявления об уходе.

Таким образом, служба ИБ со своими компетенциями и практиками может и должна быть вовлечена в самые разные аспекты бизнеса. Но для этого ей надо понимать, как функционирует компания, как перемещается и используется информация внутри корпоративного периметра. К сожалению, крайне мало компаний применяют возможности DLP-систем для подобного анализа информации: большинство ограничивается их функционалом борьбы с утечками. Но я думаю, что такое отношение к DLP будет меняться.

Total votes: 0

Другие статьи
Поделиться:
 
 
Комментарии в Facebook
 

Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.