Безопасность: общая ответственность (часть 4)

• Безопасность: общая ответственность (часть 2)
• Безопасность: общая ответственность (часть 3)
• Безопасность: общая ответственность (часть 6)

Введение

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

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

Не переоценивайте и не недооценивайте пользователей

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

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

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

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

Определить обязанности конечного пользователя

В соответствии с предостережением о том, что вы не можете ожидать, что пользователи будут «просто знать», что является хорошей практикой безопасности, а что нет, важно определить обязанности пользователей в письменной форме и убедиться, что пользователи подписались о получении и понимании эти политики.

Политика должна быть четкой и действенной. Например:

• [определенного]
• [конкретно укажите регулярность, т. е. еженедельно, раз в две недели, ежемесячно. Не оставляйте детали открытыми для интерпретации].
• [указанные]
• [определенные]

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

Имейте в виду, однако, что лучше свести вашу политику к минимуму. Если вы сделаете его слишком длинным, пользователи просто пролистнут его и не будут задумываться о том, чтобы понять требования. Хорошее эмпирическое правило заключается в том, что они должны быть в состоянии прочитать его за 10 минут или меньше. Концентрация внимания сегодня — особенно в быстро меняющемся деловом мире — коротка.

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

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

Учитывайте человеческий фактор

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

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

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

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

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

Резюме

В этой, четвертой части нашей серии статей, посвященных безопасности как общей ответственности, мы завершили обсуждение обязанностей конечных пользователей. В части 5 мы поговорим об обязанностях поставщиков программного обеспечения.

• Безопасность: общая ответственность (часть 2)
• Безопасность: общая ответственность (часть 3)
• Безопасность: общая ответственность (часть 6)