🔒 Информационная безопасность — Гигиена внутренних коммуникаций

В прошлом году мы с вами рассуждали на тему Информационной безопасности под призмой разработки программного продукта / абстрактной системы. Но сегодня поговорим о неочевидной части информационной безопасности — наш реальный мир.

1. Проблема открытости обсуждений

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

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

Что делать? Если нет вомзожности ограничить такие задачи на узкий круг очень доверенных сотрудников, постарайтесь не освещать на митингах такие проблемы. Делайте отдельные встречи "оперативного штаба", не посвящая в проблемы остальную часть команды.

2. Грязные следы в переписке

Я за свою практику несколько раз становился свидетелем таких сценариев:

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

Заказчики узнают не только о проблемах, но и о внутренней кухне, что повлечет за собой сильные потери как для продукта, так и для компании.

Что делать? Старайтесь разделить коммуникации между разработкой и бизнесом. Никогда не ленитесь создать новое чистое письмо и вставить туда только то, что нужно. Это кажется лишней рутиной, но это правда важно. 3. Доступ клиентов к конечным программистам

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

С одной стороны это хорошо... Для заказчика. Но очень плохо для вас.

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

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

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

📝 А какие проблемы информационной безопасности из реального мира можете привести вы?

Автор: 👍 Валентин Драздов, главный по программной роботизации (RPA) и не только 🐍