Современное производство программного обеспечения — сложный процесс, от разработчика требуется не только писать код, но и справляться с целым комплексом сопутствующих задач: отслеживать изменения, проводить тестирование, соблюдать стилистические правила и внутренние стандарты, учитывать безопасность и применять best practices по обеспечению ИБ уже во время написания кода.
Но есть и хорошие новости. Разработчику доступно большое число инструментов, которые упрощают труд: от линтеров до анализаторов и систем автоматизированного тестирования — все они встраиваются в среду разработки и помогают решать сложные задачи, не отвлекаясь от творческой части работы. В этой статье я, Евгений Иляхин, архитектор процессов безопасной разработки в Positive Technologies, как раз расскажу о крайне полезных инструментах, которые автоматизируют рутину и повышают качество кода, позволяя программисту сосредоточиться на разработке новой фичи или поиске оптимального решения.
Традиционно за безопасность отвечают AppSec- и DevSecOps-специалисты, однако важно вовлечь самих разработчиков в процесс обеспечения безопасности, так как отправка кода на тот же статический анализ каждый раз требует значительных ресурсов, в то время как редкие проверки могут привести к большому количеству пропущенных уязвимостей и большому числу задач по исправлению дефектов в дальнейшем. Чтобы решить эту проблему, разработчики могут использовать современные инструменты, которые позволяют им проводить локальные проверки качества кода, выявлять и исправлять уязвимости до коммита. Эти инструменты интегрируются в среду разработки и позволяют автоматизировать проверки, соблюдать стандарты безопасности и повысить уровень защищенности разрабатываемого ПО. Такой подход обеспечивает быструю обратную связь, позволяя разработчикам немедленно получать уведомление о выявленных проблемах и исправлять их на раннем этапе разработки. Кроме того, затронем несколько решений класса test-time-проверок, позволяющих проводить выборочные проверки уже готовых приложений вне границ пайплайна, не оказывая влияния на процесс разработки. О них и поговорим ниже.
SonarLint
SonarLint — это бесплатное расширение для IDE (таких как Visual Studio Code, IntelliJ IDEA, Eclipse) от Sonar с открытым исходным кодом, которое помогает разработчикам находить и устранять проблемы непосредственно во время написания кода. Плагин анализирует код, выявляя стилистические ошибки, дублирование, несоответствия правилам кодирования и другие недостатки, которые могут сделать код менее читаемым, понятным и поддерживаемым. SonarLint уведомляет разработчиков о выявленных проблемах, часто предлагая решения или советы по их исправлению. Проблемы подсвечиваются прямо в коде, а также отображаются в панели PROBLEMS.
SonarLint также предоставляет в контекстном меню дополнительную информацию о проблемах, включая описания, примеры и ссылки на лучшие практики.
В некоторых случаях он может помочь и с поиском ряда типовых уязвимостей за счет идентификации опасных паттернов кодирования, которые могут привести к проблемам с безопасностью. Однако стоит понимать, что SonarLint — это линтер, а не инструмент статического анализа, который может обнаруживать более серьезные уязвимости и проблемы безопасности. Он не может заменить полноценный статический анализ, но является ценным дополнением к процессу разработки, помогая специалистам писать более чистый и структурированный код, что снижает риск появления ошибок и уязвимостей, которые могут возникнуть из-за непонимания кода или его сложной структуры.
SonarLint также предоставляет информацию о результатах анализа кода в виде отчетов. Эти отчеты могут быть использованы для отслеживания качества кода и для определения областей, которые требуют дополнительного внимания.
SonarLint поддерживает множество языков программирования, включая Java, C#, JavaScript, Python, PHP, C, C++, Go и другие.
SonarLint может работать как автономно, так и в сочетании с инструментом статического анализа SonarQube. Второй вариант более предпочтителен, поскольку SonarQube позволяет создавать новые правила и связывать их с каждым языком программирования, в то время как SonarLint использует лишь набор встроенных правил.
Плагин Semgrep
Semgrep — плагин для IDE (поддерживает интеграцию с Visual Studio Code и IntelliJ IDEA), который позволяет получать информацию о потенциальных ошибках и уязвимостях, а также соблюдать стандарты кода во время его написания. Semgrep интегрируется в качестве pre-commit-проверки, позволяя сканировать код перед каждым коммитом в репозиторий. Это дает возможность разработчикам быстро исправлять проблемы, предотвращая попадание небезопасного кода в производственную среду.
Плагин Semgrep отличается своей гибкостью и удобством использования. Он прост в изучении и использовании благодаря собственному языку паттернов и наличию готовых правил сканирования, а функция Аutofix позволяет автоматически исправлять некоторые найденные ошибки, применяя предлагаемое самим инструментом решение из готовых правил. Это делает Semgrep доступным даже для разработчиков, не имеющих глубоких знаний в области безопасности. В нем также можно настроить свои правила сканирования в соответствии с конкретными требованиями проекта, в том числе добавить исключения и уровни опасности уязвимостей.
Кроме того, плагин способен выявлять скомпрометированные зависимости и подсвечивать места, где они используются, и затронутую версию.
Semgrep поддерживает сканирование кода на разных языках, включая JavaScript, Python, Go, C++, Java, PHP, Ruby, C# и другие.
Сам же Semgrep — это полноценный статический анализатор с открытым исходным кодом, который использует собственный язык паттернов для определения правил сканирования кода. Благодаря анализу семантики и контекста кода Semgrep проводит более гибкое сканирование, выявляя ошибки и уязвимости. Например, он способен обнаружить SQL-инъекцию даже без явного присутствия ключевых слов SQL, распознавая паттерн, похожий на атаку, и предупреждая разработчика о возможной уязвимости. Для максимальной эффективности Semgrep может быть внедрен в процесс CI/CD.
Плагин PT AI
Еще один плагин для IDE (поддерживает интеграцию с Visual Studio Code и IntelliJ IDEA) — PT Application Inspector .
Плагин проводит локальные проверки исходного кода на устройстве разработчика до коммита в Git, выявляя уязвимости, недокументированные функции и секреты (конфиденциальные данные, например креды) в коде по мере его написания, а также проверяя конфигурационные файлы с точки зрения безопасности. Благодаря встроенным модулям SCA плагин обнаруживает не только уязвимости исходного кода и недостатки конфигурационных файлов, но и уязвимые сторонние компоненты и библиотеки, используемые при разработке приложений.
Инструмент по результатам сканирования предоставляет статистику по уязвимостям, показывает уровень опасности уязвимостей, информацию о них, пути эксплуатации и рекомендации по исправлению, которые включают ссылки на документацию, примеры кода.
Плагин позволяет прямо в среде разработки управлять уязвимостями, устанавливая их статусы, отмечая ложные срабатывания, подтверждая реальные проблемы, а также фильтруя результаты (например, отмечая ложные срабатывания или подтверждая реальные проблемы).
Инструмент может сравнить результаты двух сканирований в рамках проекта при повторном сканировании и наглядно показать разницу.
Плагин работает автономно, используя те же модули анализа, что и энтерпрайз-решение PT Application Inspector, но может использоваться совместно с ним. Интеграция позволяет нескольким членам команды одновременно работать с уязвимостями и их статусами в IDE и веб-интерфейсе PT AI Enterprise Edition, тем самым повышая безопасность кода. Статусы обнаруженных уязвимостей синхронизируются автоматически, и все члены команды могут оценить текущий уровень угрозы.
Плагин PT AI поддерживает языки программирования C#, Go, Java, JavaScript, Kotlin, PHP, Python, Ruby, SQL и TypeScript.
Gitleaks
Gitleaks — это open-source-инструмент, который используется для поиска потенциальных секретов в исходном коде и Git-репозиториях. Инструмент сканирует файлы и код на наличие секретов, таких как API-ключи, токены доступа, пароли, ключи SSH, данные кредитных карт, а также других типов конфиденциальной информации, например личных данных пользователей, номеров телефонов и адресов электронной почты. Обнаруживая секреты в коде, которых там быть не должно, Gitleaks предотвращает их публикацию, предупреждая разработчика о потенциальных проблемах, которые могут привести к утечке конфиденциальных данных и другим серьезным последствиям.
Gitleaks использует несколько механизмов для поиска секретов. Он анализирует код, используя регулярные выражения, чтобы найти известные форматы секретов, например строки, начинающиеся с secret или password. Кроме того, Gitleaks использует машинное обучение, чтобы выявлять новые паттерны и форматы, которые могут указывать на наличие секретов.
Gitleaks используется в качестве pre-commit hook, то есть запускается перед каждым коммитом, сканируя файлы на наличие секретов и блокируя коммит, если обнаруживает опасные данные. Это гарантирует, что секреты не попадут в репозиторий.
Git-secrets
Git-secrets — еще один инструмент с открытым исходным кодом, предназначенный для обнаружения секретов. Как и Gitleaks, он помогает разработчикам предотвратить случайное попадание секретов (например, API-ключей, токенов доступа, паролей) в репозитории Git.
Git-secrets работает как pre-commit hook. Это означает, что он запускается перед каждым коммитом и проверяет файлы на наличие секретов, блокируя коммит, если таковые обнаружены.
Функциональность Git-secrets более ограничена, чем у Gitleaks, так как он использует только набор регулярных выражений для поиска секретов, в то время как Gitleaks применяет более продвинутые методы. Тем не менее в некоторых случаях использованию Git-secrets может быть отдано предпочтение из-за его следующих преимуществ:
простота установки и настройки;
низкие системные требования;
скорость сканирования;
гибкая интеграция с Git.
Таким образом, если вам нужен простой и быстрый инструмент для предотвращения коммита секретов в Git, Git-secrets может быть отличным выбором.
Trivy Secret Scanning
Trivy Secret Scanning — это часть инструмента Trivy, предназначенная для обнаружения секретов, таких как токены API, ключи доступа и пароли, утечка которых может представлять угрозу безопасности проекта. Trivy Secret может сканировать различные объекты, включая конфигурационные файлы и Docker-образы. Trivy Secret Scanning имеет набор встроенных правил для сканирования секретов, которые можно расширить или, наоборот, отключить, если нужна более быстрая проверка.
Сам по себе Trivy — это многофункциональный инструмент с открытым исходным кодом, предназначенный для выявления уязвимостей в различных программных компонентах: образах контейнеров, файловых системах и зависимостях. Помимо сканирования секретов, разработчики могут использовать Trivy для других типов pre-commit-проверок, таких как сканирование уязвимостей в зависимостях и образах контейнеров. Однако Trivy не блокирует коммиты или уязвимые компоненты самостоятельно. Вместо этого он предоставляет информацию о найденных уязвимостях и рекомендации по их исправлению. Эта информация помогает разработчику быстро оценить степень опасности и принять решение о дальнейших действиях.
Внедрение Trivy Secret Scanner также может осуществляться различными способами. Существуют плагины IDE, также можно настроить Git hooks, запускающие проверку при каждом коммите, что гарантирует сканирование кода перед отправкой его в репозиторий. Кроме того, возможно внедрение как Trivy Secret Scanning, так и других модулей Trivy в систему CI/CD-пайплайн, что позволит автоматизировать проверки на всех этапах разработки.
PT BlackBox Scanner
PT BlackBox Scanner — это открытое решение для динамического анализа веб-приложений, разработанное компанией Positive Technologies. Сервис предоставляется в виде облачного решения со свободным доступом, что позволяет проводить отдельные проверки готового приложение без привязки к процессу разработки. Чтобы воспользоваться PT BlackBox Scanner, вам не нужно устанавливать какое-либо программное обеспечение или настраивать сложные конфигурации. Достаточно ввести доменное имя веб-ресурса на официальном сайте сервиса, и PT BlackBox Scanner автоматически проведет анализ, имитируя реальные атаки на ваше приложение.
Сервис выявляет различные типы уязвимостей, которые могут быть использованы злоумышленниками для получения несанкционированного доступа к данным, нарушения целостности приложения или даже установления полного контроля над ним. PT BlackBox Scanner не ограничивается только сканированием самого веб-приложения, но также проводит анализ его периметра, выявляя поддомены и открытые порты, которые могут быть использованы для атак.
Результаты сканирования предоставляются в виде подробных отчетов и статистики, отображающейся на дашбордах. Вы также можете фильтровать уязвимости по уровню опасности. К каждой уязвимости прилагается детальная информация, включая описание, способы эксплуатации и конкретные рекомендации по исправлению.
Несмотря на то что PT BlackBox Scanner — это урезанная версия полного решения, которая не поддерживает такую гибкую настройку сканирования, она является ценным инструментом для разработчиков и владельцев веб-приложений. С помощью быстрого сканирования можно выявить ошибки в работе приложения, версионные уязвимости, а также неточности, допущенные при установке приложения. Это позволяет оценить общий уровень безопасности сканируемого приложения и получить необходимые рекомендации по устранению уязвимостей.
OWASP ZAP
OWASP ZAP (Zed Attack Proxy) — еще один бесплатный инструмент с открытым исходным кодом для сканирования веб-приложений. Он функционирует как прокси-сервер, перехватывая весь трафик между браузером и веб-приложением, анализируя его и выявляя уязвимости.
OWASP ZAP предлагает гибкие варианты использования. Он может проводить сканирование по требованию, его необязательно встраивать в конвейеры CI/CD. Это особенно удобно, когда нужно быстро проверить безопасность приложения или отдельных его компонентов. Кроме того, OWASP ZAP интегрируется с популярными IDE, такими как Visual Studio Code и IntelliJ IDEA, предоставляя плагины для запуска сканирования прямо из среды разработки. Это позволяет специалистам выявлять и исправлять уязвимости еще на ранних этапах создания приложения.
Инструмент предоставляет разнообразные методы сканирования, включая активное и пассивное, а также ручное сканирование, которое позволяет проводить более детальный анализ с использованием специальных инструментов и техник. OWASP ZAP может обнаружить различные типы уязвимостей, которые могут быть использованы злоумышленниками, например, для SQL-инъекции, межсайтового скриптинга (XSS), обхода аутентификации.
Результаты сканирования отображаются в виде подробных отчетов, которые можно фильтровать по типу уязвимости, уровню опасности и другим параметрам. К каждой найденной уязвимости прилагается детальная информация, включая ее описание, способы эксплуатации и конкретные рекомендации по исправлению.
Важно отметить, что мы сосредоточились на инструментах, которые могут быть полезны разработчикам при локальной проверке кода или выборочном тестировании, обойдя стороной (почти) классический джентльменский набор AppSec-инструментов, используемых специалистами по безопасности приложений. Эти инструменты позволяют разработчикам, не обладающим глубокой экспертизой в безопасной разработке, самостоятельно выявлять и устранять уязвимости, способствуя созданию более защищенных приложений и сокращению времени, затрачиваемого на исправление ошибок.
Мы представили лишь небольшой список инструментов из множества доступных (а их тысячи). Призываем вас поделиться своим опытом и дополнить его, рассказав о том, какими инструментами пользуетесь вы.
Однако всегда стоит помнить: сами по себе инструменты не могут обеспечить безопасность. Ключевым фактором являются процессы и люди. Только при пересечении трех элементов — инструментов, процессов и компетенций — можно говорить о грамотном внедрении DevSecOps, AppSec.
Основные результаты
За последний год атакам подвергались 55% опрошенных компаний, из них около 25% были атакованы меньше полугода назад. Чаще всего скомпрометированными оказывались удаленные устройства.
Среди опрошенных компаний 79% указали, что изменения в их ИТ-среде происходят чаще, чем раз в квартал. При этом только 21% опрошенных заказывают услуги по ручному тестированию на проникновение, из них регулярные пентесты делают только 64%.
В среднем компании используют от 10 до 30 продуктов для ИБ. При этом планы на закупку новых решений в перспективе до двух лет есть у 63% опрошенных компаний.
Кибератаки в российских организациях
Злоумышленники проникают в инфраструктуру предприятия, используя разные методы: в ход идут и социальная инженерия, и рассылки с вредоносными вложениями, и эксплуатация уязвимостей.
Несмотря на значительные инвестиции в инфраструктуру безопасности, за последний год жертвами кибератак стали 55% опрошенных организаций, из которых каждая четвертая была атакована в последние полгода. Остальные участники опроса отметили, что сталкивались с инцидентами безопасности более полутора лет назад, и только небольшая часть компаний никогда не подвергалась кибератакам.
Последствия кибератак
Восемь из десяти опрошенных компаний столкнулись с серьезными последствиями кибератак в 2024 году, и лишь 13% компаний отметили, что не получили значительного урона от взлома. Четверть организаций сообщили о финансовых потерях — это говорит о том, что одной из главных целей для злоумышленников остаются деньги. Такое же количество компаний (чуть более 25%) сообщили о репутационных потерях. Однако самые большие риски связаны с непрерывностью бизнеса: 48% опрошенных отметили, что атака привела к незапланированным простоям, из-за которых компании были вынуждены приостановить ключевые процессы или потеряли контроль над оборудованием. Влияние атаки на конфиденциальные данные отметили 34% респондентов, а для 18% компаний инцидент привел к юридическим проблемам.
Злоумышленники атакуют по всем направлениям, не ограничиваясь конкретными векторами или отдельными сегментами инфраструктуры компаний. Периметр организации сильно размыт, и хакеры вынуждены тщательно готовиться к кибератаке — изучать инфраструктуру и собирать данные. Исследование показывает, что под угрозой находятся не только удаленные или локальные устройства, но и облачная инфраструктура, которой требуются специальные средства защиты. Можно предположить, что с ростом использования облачных решений число атак на них будет только расти.
Используемые продукты для ИБ
Большинство организаций, участвовавших в опросе, используют от 10 до 30 решений для ИБ, и только 20% компаний используют менее 10 автоматизированных средств защиты. Несмотря на преимущества многоуровневого обеспечения безопасности, на практике такое количество систем не решает проблемы. При неправильной настройке решения производят много уведомлений о потенциальных проблемах и инцидентах, что затрудняет мониторинг и управление инфраструктурой, ограничивая способность организации обнаруживать угрозы и реагировать на них. Кроме того, поддержка работоспособности множества систем и их интеграции между собой требует дополнительных ресурсов, которые не все компании могут себе позволить.
Количество используемых продуктов для ИБ зависит от размера компании: в крупных компаниях в 2,5 раза чаще используется более 30 продуктов. Менее 10 систем чаще используют компании, в которых работает менее 2000 сотрудников. Среди крупных компаний встречаются и такие, которые используют для защиты инфраструктуры более 50 решений.
Мы уточнили у компаний, планируют ли они закупки решений для информационной безопасности в краткосрочной или долгосрочной перспективе.
Результат опроса показывает, что для крупных компаний более характерно долгосрочное планирование: планы на 5 и более лет имеют 13% очень крупных компаний, тогда как среди организаций размером 1000–2000 сотрудников такие планы имеют только 3% компаний. При этом подавляющее большинство компаний (63%) имеет планы по закупкам систем для ИБ только в перспективе ближайших 1–2 лет, что говорит о тактическом уровне планирования. Возможно, для стратегического планирования компаниям не хватает информации о том, на каком уровне безопасности они находятся в данный момент.
Проблема №1
Несмотря на инвестиции в ИБ, компании все еще недостаточно защищены и постоянно сталкиваются с кибератаками, что вынуждает их закупать новые средства защиты. С одной стороны, это говорит о том, что компании выстраивают эшелонированную защиту и многоступенчатую безопасность. С другой стороны — большое количество СЗИ создает много событий безопасности, которые требуют внимательного изучения службой ИБ, затрудняя определение приоритетных инцидентов и потенциальных угроз.
Почему компании все еще уязвимы к кибератакам
Знание собственной инфраструктуры
По данным опроса, каждая третья компания (30%), независимо от числа сотрудников, не уверена, что обладает точной информацией об аппаратном и программном обеспечении, которое формирует основу операционной деятельности. При этом практически любой ИТ-актив компании может стать входной точкой для злоумышленников, и специалисты, отвечающие за безопасность, должны знать, что именно нужно защищать.
Сложность ИТ-инфраструктуры растет во всех компаниях, и они вынуждены внедрять новые решения для управления безопасностью и поддержания киберустойчивости. Развертывание нового ПО, добавление или удаление рабочих станций неизбежно меняют инфраструктуру. Каждое изменение создает новые потенциальные бреши, которые могут использовать злоумышленники. Инфраструктура компаний состоит из дата-центров, ДМЗ, сегментов рабочих станций, географически распределенных офисов с разными часовыми поясами, тестовых сегментов и т. д. Все эти сегменты имеют различный уровень и особые требования к защите ИБ, контролировать которые в моменте очень сложно.
Изменение активов в инфраструктуре
Около 80% опрошенных компаний, независимо от размера, добавляют или отключают активы минимум раз в квартал, что сильно меняет инфраструктуру и может оказать влияние на уровень защищенности. Добавление и отключение активов (серверов, сетевых устройств, ПО, систем управления БД, а также различных видов конфиденциальных данных) может спровоцировать появление дополнительных уязвимостей и незащищенных мест, которые могут быть использованы для проведения атак.
Проблема №2
Сложность инфраструктуры компаний непрерывно растет: постоянно меняется количество активов, увеличивается количество средств защиты — это требует постоянной проверки настроек и состояния СЗИ, источников событий и процессов ИБ (мониторинг, реагирование, харденинг, treat hunting и т. д.). Из-за динамичных изменений инфраструктуры компании не всегда точно знают о состоянии ИТ-активов и том, как настроена их безопасность, что создает дополнительные уязвимые места, которыми могут воспользоваться злоумышленники.
Оценка защищенности
Оценка защищенности инфраструктуры может выявить узкие места и неэффективные процессы, которые необходимо оптимизировать для улучшения киберустойчивости компании. Разнообразие методов анализа защищенности позволяет выбрать наиболее подходящие, в зависимости от ресурсов и уровня зрелости ИБ в компании. По данным исследования «Готовы ли российские компании противостоять кибератакам?» , наиболее объективную оценку уровня защищенности можно получить, если проводить анализ, действия которого имеют максимальное сходство с действиями реальных злоумышленников.
Регулярная оценка состояния безопасности
Более 90% компаний проводят оценку безопасности и защищенности, 61% из них делают это регулярно.
Это связано с тем, что многим компаниям необходимо соблюдать требования регуляторов в области защиты информации, несоответствие которым может привести к серьезным штрафам. Кроме того, регулярная оценка инфраструктуры помогает выявлять и устранять слабые места, которые могут быть использованы для проникновения в систему и кражи данных, менять процессы, плейбуки и сценарии реагирования на угрозы, а также сфокусироваться на самых вероятных векторах атак.
Бюджет на тестирование безопасности
Компании, которые инвестируют не только в системы для информационной защиты, но и в их тестирование, имеют меньше шансов столкнуться с кибератаками, утечками данных и другими кибер угрозами , что способствует стабильному и успешному развитию бизнеса.
В среднем на оценку защищенности тратится около 10–30% бюджета, в более крупных компаниях затраты несколько выше. Некоторые компании могут неправильно оценивать важность тестирования защищенности, не придавать ему значения и направлять основную часть бюджета на выстраивание процессов защиты инфраструктуры.
Методы проверки безопасности
Мы опросили компании, которые регулярно тестируют защищенность, и выяснили, что самые популярные способы проверки — аудит безопасности и использование сканеров уязвимостей. Почти в два раза реже используются киберучения и специализированные программы. При этом ручной пентест заказывают только 21% компаний, хотя в мире наблюдается устойчивый рост интереса к подобным услугам.
Результаты тестирования
Традиционно во многих отраслях проверка защищенности возникла как необходимость соответствовать требованиям регуляторов. Нет сомнений в том, что эти требования, даже если они навязаны регулирующими органами, по-прежнему в некоторой степени стимулируют компании проводить тестирование на безопасность.
Однако основной причиной для проверки защищенности является необходимость приоритизации закупок и выбора действительно нужных решений. Кроме того, немаловажным фактором называют демонстрацию результатов топ-менеджменту для информирования о рисках кибербезопасности как внутри компании, так и за ее пределами. Из опрошенных специалистов по ИБ 48% сообщили, что делятся результатами с высшим руководством, так как с увеличением числа громких нарушений приходит осознание важности кибербезопасности, понимание бизнес-рисков и возможного финансового ущерба от последствий атак. Экспертные знания в области ИБ становятся все более распространенными среди топ-менеджмента. Вполне вероятно, что управленцы все чаще будут запрашивать отчеты для оценки состояния безопасности, поэтому важно, чтобы эти отчеты были исчерпывающими и понятными. Результаты проверки также выходят за пределы организаций. В связи с ростом рисков от третьих лиц и возможности компрометации через цепочку поставок 20% опрошенных компаний делятся результатами со своими клиентами.
Частота заказа ручного пентеста
Среди всех опрошенных компаний 79% сообщают, что их инфраструктура меняется не реже одного раза в квартал, однако услуги по ручному тестированию на проникновение заказывают только 21%.
Периодичность проведения регулярных пентестов очень важна, так как чем меньше интервал между проверками, тем более актуальную информацию о наличии уязвимостей и потенциальных действиях злоумышленника будет получать отдел ИБ. Каждый день хакеры совершенствуют тактики и техники атак, появляется информация о ранее неизвестных уязвимостях, динамично изменяется инфраструктура — все это значительно влияет на состояние защищенности. Для оперативного реагирования на угрозы необходимо регулярно проверять безопасность критически важных узлов и ключевых систем.
Частота проведения пентеста зависит от множества факторов, включая тип организации, характеристики информационной системы и изменение ландшафта угроз. Не всегда есть возможность проводить тестирование при внесении изменений в цифровые активы, например при внедрении новых технологий, обновлении ПО или изменении бизнес-процессов. Зачастую компании проводят пентест для соблюдения отраслевых стандартов и требований регуляторов. Например, согласно положению 683-П Центрального банка РФ , банки и НКО обязаны проводить тестирование на проникновение ежегодно.
По результатам исследования, только 11% компаний проводят непрерывный пентест, а 14% заказывают пентест ежемесячно. Проверяют защищенность тестированием на проникновение раз в квартал 39% компаний. Остальные заказывают такие услуги гораздо реже и делают это нерегулярно либо по запросу.
Контроль и проверка кибербезопасности, а также оценка эффективности работы средств защиты информации — две основные мотивации для проведения тестирования на проникновение, кроме выполнения требований регуляторов. Пентест также используется для оценки потенциального ущерба от атак и для выбора стратегии инвестирования в обеспечение безопасности. Это говорит о том, что компании начинают использовать пентест не только для выполнения требований регулирующих органов, но и для оценки реального состояния киберустойчивости инфраструктуры.
Барьеры для пентеста
Двумя главными препятствиями для заказа регулярного тестирования на проникновение являются отсутствие бюджета, а также угроза нарушения непрерывности бизнес-процессов. Прежде всего, перед службой ИБ стоит задача обеспечить безопасность ИТ-среды и бесперебойность бизнес-операций. Руководители ИТ и ИБ с осторожностью относятся к пентестам, поскольку многие сталкивались с простоями в работе. Это говорит о том, что компаниям необходимо работать только с самыми опытными командами, которые имеют хорошую репутацию и многолетний опыт работы по оказанию таких услуг и могут обеспечить высокий уровень проверки безопасности с минимальным риском для процессов. Немало компаний, особенно представители небольшого бизнеса, также озадачены необходимостью принятия мер по исправлению обнаруженных проблем безопасности.
Кто отвечает за проверку безопасности
Только в 10% крупных компаний есть своя команда пентестеров (red team). Примерно в половине опрошенных компаний есть специалисты, которые отвечают исключительно за организацию оценки безопасности, а у 41% опрошенных этой задачей занимаются специалисты со смежными обязанностями.
Очевидно, есть определенная нехватка квалифицированных кадров, которые отвечали бы за выстраивание процессов тестирования безопасности и были поглощены только этими задачами.
Проблема №3
С одной стороны, компании хотели бы проверять киберустойчивость не только для выполнения требований регулятора, но и для понимания реальной ситуации с безопасностью в своих инфраструктурах. С другой — на рынке есть дефицит квалифицированных команд для проведения качественного пентеста, а внутри компаний недостаточно собственных ресурсов для выстраивания процесса тестирования. Кроме того, российские компании испытывают недостаток бюджета на проведение регулярных проверок и опасаются нарушения бизнес-процессов.
Как обеспечить регулярную проверку безопасности
Российские компании вынуждены работать в условиях изменений IT-инфраструктуры и постоянно меняющегося ландшафта киберугроз. Возможность проводить регулярный ручной пентест есть не у всех компаний, но есть потребность минимизировать риски безопасности, выявлять проблемы защиты и тщательно планировать закупки решений для ИБ с учетом возможностей и потребностей ИТ-инфраструктуры.
Обеспечить регулярное тестирование защищенности могут инструменты, которые проводят автоматические пентесты
