Обвинение поставщика в случае нарушения безопасности

Игра с обвинением — это то, что мы все время от времени практикуем, когда что-то идет не так, мы не хотим, чтобы нас поймали с сумкой. И когда нас обвиняют в том, что мы виноваты, наша естественная реакция — поднять руки и сказать: «Не я!» Поэтому нередко, когда происходит нарушение безопасности, бизнес или организация немедленно пытается переложить вину на поставщика. «Это вина программного обеспечения» — простой способ избавить вашу компанию от любой ошибки в этом вопросе. Но как часто это действительно так?

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

1. Бам — тебя взломали!!!
2. Виноват софт!
3. Нам также нужно конфисковать сервер, на котором работает программное обеспечение!
4. Похоже, админа действительно следует винить — он стал мошенником.
5. Подождите, кто вообще нанял этого парня? Какие виды контроля мы имели над ним и почему они не применялись последовательно?
6. Я думаю, что мы все здесь потерпели неудачу, это явный провал нашей корпоративной культуры. Нам необходимо провести полный обзор наших политик безопасности и процессов их применения.
7. Идем дальше, что сделано, то сделано. Нам просто нужно убедиться, что это никогда не повторится.

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

Причины удобства

Как организация, которая разработала тщательно продуманную политику безопасности, эффективные средства контроля и четко определенные процессы, в конечном итоге становится жертвой взлома? Часто это происходит из соображений удобства, например, когда администратору необходимо «обойти правила», чтобы «выполнить работу». Но инициатива такого отклонения от правил часто исходит не от самих администраторов, а от кого-то из высшего руководства компании, которое сообщает администратору, что то-то и то-то является «высокоприоритетным» и «не говорите мне о правильном процессе», но « просто сделай это."

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

Четвертый протокол

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

• Громко жалуйтесь. К сожалению, за это вас могут уволить.
• Пожаловаться письменно. Теперь вы даете руководству еще больше боеприпасов на случай, если они захотят вас уволить.
• Заткнись и слушайся. Вас все равно уволят, если запрошенное действие приведет к взлому организации.

Или вы можете попробовать Четвертый протокол и просто попытаться быть разумным. (Для тех из вас, кто хорошо разбирается в кино, вы поймете, что я имею в виду фильм с таким же названием, в котором снимались Пирс Броснан и Майкл Кейн, и упоминаемый протокол является одним из последних средств: ядерный вариант.) Под этим я подразумеваю, что вы просто пытаетесь сделать следующее:

1. Объясните спокойным тоном, почему запрошенное действие может поставить под угрозу не только организацию, но и карьеру человека, первоначально запросившего действие.
2. Опишите, как работают ваши ИТ-системы и почему в первую очередь были установлены меры безопасности, которые вам нужно обойти.
3. Попросите человека, делающего запрос, тщательно взвесить риски действия с очевидной срочностью его необходимости.
4. Постарайтесь понять, почему запрошенное действие считается высокоприоритетным и срочным.
5. Предложите некоторые возможные альтернативы запрошенному действию, которое может быть выполнено без обхода политики безопасности, средств контроля и процессов организации.

Эффективное управление после нарушения безопасности

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

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