– ИТ-шники – это серьезная группа риска с точки зрения информационной безопасности и за ними будет особый надзор
– ИТ-шники во многом являются подрядчиками СИБ, реализуя то, что они напридумывают и работая по их правилам
– ИТ-шники являются прокладкой между пользователями и СИБ и принимают на себя весь негатив закручивания гаек
Нужно сразу правильно выстраивать взаимоотношения между ИТ и СИБ. Правильно организованное взаимодействие между этими подразделениями может принести существенную пользу. В моем понимании правильное – это когда СИБ помогает сформировать правила и контролирует их исполнение через аудиты и другие контрольные мероприятия. А вот перетягивание функций администрирования, даже в минимальном объеме – это в конечном итоге рано или поздно приводило к нехорошим последствиям. Был случай когда чуть ли не день разбирались с проблемами, когда безопасность, которая заведовала антивирусом, перекидывалась мячом с админами, занимавшимися сетью.
Вообще, когда говорят об информационной безопасности первое, что приходит на ум – это возможность кому-то несанкционированно скопировать и передать кому-то некие данные. По факту и у нас были утечки данных и нам приносили данные других организаций, но вот сказать. что это принесло какой-то существенный вред или пользу я не могу. В свое время, когда Галицкому предложили построить систему, которая бы обеспечила супербезопасность он сказал: “Ну украдут у меня данные о моих продажах и остатках. И что они будут с ними делать? Я сам периодически не знаю как их можно использовать”. И я с ним по большому счету согласен. Утечка данных для некоторых компаний – это минимальный риск. Безусловно есть очень критичная информация, но решить вопросы ограничения доступа к ней – это по нынешним временам задача тривиальная. А что касается операционных данных, то убиваться, применяя технические средства для их защиты и выстраивая суперсистемы, тратя огромные деньги особого смысла нет. Когда у всех под рукой мобильный телефон с камерой, снять информацию используя монитор – это задачка для ребенка детсадовского возраста. При этом сказанное мной не означает, что нужно вообще расслабиться и ничего не делать. Вопрос соответствия затрат и рисков.
Более критичными являются случаи утраты информации вследствие злого умысла, либо неквалифицированных действий пользователей или ИТ-шников, при выполнении сервисных операций. Вирусы, хакеры, обиженные уволенные администраторы и даже любопытные пользователи, тыкающие куда попало – это те угрозы к которым нужно относится крайне серьезно.
Была одна интересная история. Пошли с безопасниками найти один телефонный разговор на станции записи телефонных переговоров. Нашли, прослушали. А потом инженер покачнулся и задел рукой клавиатуру. Мне потом стало интересно, какой умный человек в цифровой её части разместил клавиши “Del” и “Enter” таким образом, что одним простым слитным движением их можно нажать в нужной последовательности. Понятно, что и разработчики программы показали себя с нелучшей стороны, установив действие по умолчанию для вопроса “Вы уверены, что хотите удалить файл безвозвратно?” на “Да”. Короче, ползущая полоска удаления при округлившихся глазах, и потом много объяснений.
Серьезный подход к организации дистанционного доступа, максимальное ограничение прав доступа в соответствии с ролями, отслеживание и отработка всех рекомендаций по настройкам защиты от проникновений и вирусов – набор инструментов, который вы легко найдете в сети.
В это сложно поверить, но в большинстве компаний я, будучи ИТ-директором вообще не имел доступа в операционные рабочие базы.
Кстати, в моей практике был реальный классический случай, когда мальчик и девочка, занимавшиеся автоматизацией платежей организовали для себя тонюсенький ручеек от большого финансового потока. Закончилось все плачевно, но факт имел место быть.
Очень хорошим вариантом является – это периодическое привлечение внешнего аудита для проверки вашей информационной системы на предмет соответствия современным требованиям безопасности. Если ваше компания может себе это позволить – это точно будет не лишней строчкой в бюджете.
В моей практике случались случаи когда безопасники пытались встроиться и в процесс внесения изменений в ИТ-продукты, но, как правило ни к чему хорошему это не приводило. Полноценную ревизию кода все равно быстро не сделаешь, тестирование им отдавать тоже смысла нет. Поэтому дело обычно заканчивалось максимум формальным контролем исполнения процесса: кто делал, кто собирал, кто тестировал, если результаты тестов оформлены правильно – даем добро на установку. А дальше есть правила безопасности, которые должны соблюдаться неукоснительно:
– ничего не разрабатываем на рабочей базе
– обязательно тестируем, что изменение сильно ничего не поломает
– перед внесением изменений бэкапим, чтобы можно было откатится
– критичные операции лучше делать вдвоем: один смотрит, другой контролирует