Компания инвестирует в современные системы защиты периметра сети, шифрование и мониторинг — с технической точки зрения инфраструктура выглядит хорошо защищённой. При этом процесс отзыва доступа при увольнении сотрудника формализован плохо: бывшие сотрудники неделями или месяцами сохраняют доступ к корпоративным системам, потому что снятие доступа зависит от того, вспомнит ли HR сообщить IT-отделу. Самая совершенная техническая защита ничего не стоит, если процесс управления доступом на человеческом уровне остаётся дырявым.
Задокументированный реальный кейс провала проверки технических уязвимостей: 7 марта 2017 года было публично раскрыто уязвимость CVE-2017-5638 в Apache Struts вместе с готовым патчем. Служба информационной безопасности Equifax знала об уязвимости и предприняла попытку сканирования систем компании на её наличие — но сканирование не выявило уязвимые системы из-за технической ошибки в самом процессе проверки, и патч так и не был установлен. Уязвимость оставалась неустранённой более четырёх месяцев, пока 29 июля 2017 года служба безопасности не обнаружила подозрительный сетевой трафик в веб-портале для оспаривания кредитных данных. К этому моменту были скомпрометированы личные данные порядка 143 млн потребителей США. Итог — глобальное урегулирование с Федеральной торговой комиссией, Бюро финансовой защиты потребителей и властями 50 штатов на сумму от 575 до 700 млн долларов. Это прямая иллюстрация принципа: формальное наличие процесса сканирования уязвимостей не защищает от риска, если сам процесс сканирования технически некорректен и не проверяется независимо на предмет ложноотрицательных результатов. Дополнительная деталь расследования Конгресса США: истёкший цифровой сертификат для расшифровки внутреннего сетевого трафика ещё сильнее задержал обнаружение вторжения — злоумышленники находились внутри сети Equifax и извлекали данные на протяжении почти 76 дней (с середины мая по конец июля 2017 года), прежде чем их активность была замечена, а истечение сертификата означало, что весь зашифрованный трафик через конкретную систему мониторинга безопасности физически не мог быть проверен на протяжении почти 19 месяцев до самого инцидента — ещё один пример разрыва между формальным наличием средства защиты и его реальной работоспособностью.
Самая дорогая система защиты периметра бесполезна, если у бывшего сотрудника всё ещё есть действующий пароль от внутренней системы.
Происхождение и исследовательская база
Аудит информационной безопасности систематизирован в международных стандартах, в частности ISO/IEC 27001 (Системы менеджмента информационной безопасности) — стандарт явно охватывает не только технические средства защиты, но и организационные процессы: управление доступом, классификацию данных по чувствительности, готовность к реагированию на инциденты, обучение сотрудников — признавая, что человеческий фактор часто является более уязвимым звеном, чем технология. Именно поэтому управление доступом традиционно занимает центральное место в аудите информационной безопасности — оно находится на пересечении технологии и организационного процесса: техническая система прав доступа сама по себе нейтральна, а её реальная защитная ценность полностью определяется дисциплиной своевременного обновления этих прав при кадровых изменениях, что делает эту область одинаково зоной ответственности и ИТ-безопасности, и HR-процессов компании.
Ключевые идеи и принципы
Принцип: Управление доступом как приоритетная область проверки
Аудит явно проверяет, насколько своевременно предоставляется и отзывается доступ к системам — при найме, смене роли, увольнении сотрудника, — поскольку устаревшие или избыточные права доступа являются одной из самых распространённых и легко устранимых уязвимостей.
Принцип: Проверка технических уязвимостей инфраструктуры
Аудит включает техническую оценку — актуальность обновлений программного обеспечения, наличие известных уязвимостей, надёжность шифрования данных при хранении и передаче — как отдельный, но не единственный компонент общей защищённости.
Принцип: Готовность к инцидентам, а не только их предотвращение
Аудит проверяет не только меры предотвращения инцидентов, но и готовность компании обнаружить и отреагировать на инцидент, если он всё же произойдёт, — включая наличие плана реагирования и понимание сотрудниками своей роли при обнаружении подозрительной активности.
Ограничения, слепые зоны и критика
Полная защита от всех теоретически возможных угроз экономически недостижима — аудит должен приоритизировать усилия на защите наиболее критичных данных и систем, соразмерно реальным рискам, а не пытаться одинаково жёстко защищать всё. Технический аудит также быстро устаревает — новые уязвимости появляются постоянно, поэтому разовая проверка без регулярного повторения быстро теряет актуальность.
Типовые ошибки
Ошибка 1: Отзыв доступа при увольнении сотрудника не формализован системно.
Снятие прав доступа зависит от того, вспомнит ли кто-то сообщить об увольнении, а не от автоматизированного или чётко закреплённого процесса.
Как избежать: Формализовать процесс немедленного отзыва доступа как обязательную часть процедуры увольнения, не зависящую от человеческой памяти. Практический механизм — интеграция HR-системы учёта персонала с системой управления правами доступа, при которой изменение статуса сотрудника в HR-системе (увольнение, перевод в другое подразделение) автоматически инициирует пересмотр или отзыв соответствующих прав доступа, а не требует отдельного ручного действия от ИТ-отдела по отдельному запросу.
Ошибка 2: Аудит фокусируется только на технических средствах защиты, игнорируя организационные процессы.
Проверяется настройка технических систем защиты, но не проверяется, как реально организовано управление доступом и обучены ли сотрудники распознавать угрозы.
Как избежать: Включать в аудит организационные процессы наравне с техническими средствами защиты. Практическая проверка организационных процессов включает: тестирование того, действительно ли сотрудники распознают фишинговые попытки (через контролируемые симуляции), проверку скорости фактического отзыва доступа после тестового «увольнения», и аудит того, насколько подразделения реально следуют формально утверждённой политике классификации данных на практике, а не только на бумаге.
Ошибка 3: не проверяют независимо, действительно ли процесс сканирования уязвимостей корректно находит известные проблемы.
Служба безопасности Equifax формально запустила сканирование на предмет уязвимости Apache Struts, но само сканирование содержало техническую ошибку и не обнаружило уязвимые системы — организация считала риск закрытым, хотя реального покрытия проверкой не было, потому что никто не верифицировал корректность работы самого сканера на известной, уже раскрытой уязвимости.
Как избежать: Периодически тестировать сам процесс и инструменты сканирования уязвимостей на заведомо известных, уже раскрытых CVE, чтобы убедиться, что сканирование действительно находит то, для чего предназначено, а не просто формально запускается. Независимая проверка эффективности инструмента безопасности так же важна, как и его формальное наличие, — именно техническая ошибка в самом процессе сканирования, а не отсутствие процесса как такового, оставила Equifax уязвимой на протяжении месяцев после публикации патча.
Ошибка 4: не устанавливают доступные патчи безопасности в разумный срок после публичного раскрытия уязвимости.
Патч для Apache Struts CVE-2017-5638 был доступен с момента публичного раскрытия уязвимости 7 марта 2017 года, но фактически не был установлен более четырёх месяцев — разрыв между «патч существует» и «патч применён» остаётся главным окном для эксплуатации, независимо от того, насколько быстро была обнаружена сама уязвимость исследователями.
Как избежать: Устанавливать SLA на применение критичных патчей безопасности после их публикации (например, не более 30 дней для критичных CVE) и отслеживать соблюдение этого SLA как отдельную метрику. Важно, чтобы этот SLA отслеживался как явная управленческая метрика с ответственным за её соблюдение, а не оставался лишь формальной внутренней рекомендацией — именно разрыв между наличием патча и его реальной установкой, а не отсутствие патча как такового, стал непосредственной технической причиной масштаба ущерба в кейсе Equifax.
Ошибка 5: не сегментируют критичные системы так, чтобы компрометация одного компонента не давала доступ ко всей базе данных сразу.
После проникновения через уязвимый веб-портал злоумышленники получили доступ к базам данных с личными данными 143 млн человек — масштаб ущерба Equifax определялся не только фактом взлома одного компонента, но и отсутствием сегментации, ограничивающей распространение доступа вглубь инфраструктуры после первичного проникновения.
Как избежать: Проектировать сетевую архитектуру так, чтобы компрометация одного внешнего компонента (например, веб-портала) не давала прямого доступа к критичным внутренним базам данных без дополнительных барьеров. Этот принцип известен в информационной безопасности как сегментация сети (network segmentation) или архитектура «нулевого доверия» (zero trust) — каждый переход между сегментами сети требует отдельной аутентификации и авторизации, вместо модели, где однократный успешный взлом внешнего периметра даёт злоумышленнику широкий доступ ко всей внутренней инфраструктуре компании.
Главное, что нужно знать
Аудит информационной безопасности проверяет защищённость данных и систем не только через технические средства, но и через организационные процессы — прежде всего управление доступом, — которые часто являются более слабым звеном, чем сама технология. Готовность к инцидентам не менее важна, чем их предотвращение, поскольку полная защита от всех угроз недостижима.
План внедрения
Неделя 1: проверить актуальность прав доступа всех сотрудников к ключевым системам.
Неделя 2: оценить техническую защищённость инфраструктуры на предмет известных уязвимостей.
Неделя 3: проверить наличие и работоспособность плана реагирования на инциденты.
Неделя 4: устранить выявленные пробелы, начиная с наиболее критичных.
Далее: регулярно повторять аудит, поскольку угрозы и уязвимости постоянно меняются.
Как реализовать этот план с помощью фрейма «Аудит информационной безопасности» в OrgDevTools
Фрейм — четыре карточки: «Управление доступом» (своевременность выдачи и отзыва прав), «Технические уязвимости» (обновления, шифрование, сканирование — прямая зона провала Equifax), «Готовность к инцидентам» (план реагирования и обученность сотрудников) и «Устранение пробелов» (приоритет наиболее критичным уязвимостям).
Карточка «Технические уязвимости» структурно требует зафиксировать не только факт сканирования, но и его результат, — именно отсутствие такой явной фиксации позволило Equifax считать риск Apache Struts закрытым при формально запущенном, но фактически неработающем сканировании, оставившем уязвимость неустранённой более четырёх месяцев.