Часть 1. Введение
Цель данного исследования, спонсируемого компанией Rezilion - понять состояние процессов DevSecOps организаций по управлению уязвимостями по всей поверхности атаки на программное обеспечение. Ponemon Institute опросил 634 практиков в области ИТ и ИТ-безопасности, которые имеют представление о поверхности атаки их организаций и эффективности управления уязвимостями.
Все организации внедрили DevSecOps или находятся в процессе внедрения DevSecOps. Согласно исследованию, отсутствие подходящих инструментов безопасности является основным препятствием для эффективности DevSecOps. За этой проблемой следует отсутствие интеграции рабочих процессов и растущее количество уязвимостей.
Ключевым моментом исследования является время, затрачиваемое на устранение огромного количества уязвимостей, что снижает производительность и влияет на финансы организации. Более половины участников исследования (66 процентов) заявили, что их бэклог состоит из более чем 100 000 уязвимостей. Семьдесят семь процентов респондентов утверждают, что на обнаружение, определение приоритетов и устранение одной уязвимости в производственной среде уходит более 21 минуты, а 80 процентов утверждают, что их организации тратят более 16 минут на обнаружение одной уязвимости в продуктивных средах.
В основе успешной программы управления уязвимостями лежит согласованность действий DevSecOps и команды разработчиков, позволяющая добиться как внедрения инноваций, так и обеспечения безопасности при создании продуктов. На рисунке 1 показана взаимосвязь между DevSecOps и операционной деятельностью. Только 47 процентов респондентов утверждают, что команда разработчиков в их организациях обеспечивает как улучшение клиентского опыта, так и безопасность приложений. 53 процента респондентов обеспокоены тем, что отсутствие прозрачности и приоритетов в практике безопасности DevOps ставит безопасность продуктов под угрозу.
Пятьдесят пять процентов респондентов утверждают, что их разработчики, команды по безопасности продуктов и команды по соблюдению нормативных требований согласуют свои действия и понимают уровень безопасности их организаций и сферу ответственности друг друга для создания безопасных продуктов.
Рис. 1. Мнения о состоянии DevSecOps и управления уязвимостями.
Ниже приведены основные выводы из исследования.
В данном исследовании мы определили DevSecOps (сокращение от development, security and operations) как автоматизацию интеграции безопасности на каждом этапе жизненного цикла разработки программного обеспечения от начального проектирования до интеграции, тестирования, развертывания и доставки.
По мнению 45 процентов респондентов, две основные причины для внедрения DevSecOps - это улучшение взаимодействия между разработкой, безопасностью и операционными подразделениями и сокращение времени на исправление уязвимостей. Помимо улучшения взаимодействия и сокращения времени на исправление уязвимостей, 41 процент респондентов утверждают, что DevSecOps автоматизирует поставку безопасного программного обеспечения без замедления цикла разработки (SDLC).
Почти половина респондентов утверждает, что в их организациях есть накопившиеся уязвимости. Сорок семь процентов респондентов утверждают, что за последние 12 месяцев в организациях были приложения, которые были признаны уязвимыми, но не были исправлены. В среднем 1,1 миллиона отдельных уязвимостей находились в таком «резерве» за последние 12 месяцев, и в среднем 46 процентов из них были устранены. Однако, по словам респондентов, их организации были бы удовлетворены, если бы устранены были хотя бы 29 процентов уязвимостей за год.
По мнению 47 процентов респондентов, неспособность определить приоритеты исправлений является основной причиной существования отставания в устранении уязвимостей. Основной причиной существования отставания является отсутствие достаточной информации о рисках эксплуатации уязвимостей (45 процентов респондентов) и отсутствие эффективных инструментов (43 процента респондентов).
Сорок семь процентов респондентов утверждают, что в их организациях принята стратегия «сдвига вправо», которая обеспечивает постоянную обратную связь с пользователями. Пятьдесят один процент респондентов считают, что преимущества данной стратегии позволяют инженерам тестировать более качественно.
Компании несколько более эффективны в приоритезации наиболее важных уязвимостей, чем в их исправлении. Пятьдесят два процента респондентов утверждают, что определение приоритетов критических уязвимостей в их организациях крайне эффективно, но только 43 процента респондентов утверждают, что своевременное исправление уязвимостей крайне эффективно.
В основном исправление уязвимостей откладывается из-за сложности отслеживания своевременности исправления уязвимостей. За сложностью отслеживания (51 процент респондентов) следует невозможность вывести критически важные приложения и системы из эксплуатации, чтобы их можно было быстро обновить (49 процентов респондентов).
Автоматизация значительно сокращает время устранения уязвимостей. Пятьдесят шесть процентов респондентов заявили, что их организации используют автоматизацию для помощи в управлении уязвимостями. Из них 59 процентов респондентов утверждают, что их организации автоматизируют распространение исправлений, 47 процентов - автоматизируют расстановку приоритетов, а 41 процент - автоматизируют отчетность. Каждую неделю команда ИТ-безопасности тратит большую часть своего времени на устранение уязвимостей. Шестьдесят процентов респондентов, применяющих автоматизацию, утверждают, что она значительно сокращает время на устранение уязвимостей (43 процента) или сокращает его незначительно (17 процентов).
DevOps - это подход, основанный на принципах бережливости и гибкости, позволяющий быстро создавать программное обеспечение, которое позволяет организациям быстро использовать деловые возможности. Пятьдесят один процент респондентов утверждают, что в той или иной степени участвуют в деятельности DevOps в своей организации. 52 процента респондентов заявили, что они участвуют в управлении уязвимостями, а 49 процентов респондентов заявили, что они участвуют в обеспечении безопасности приложений.
Определенные функции важны для создания безопасных приложений или сервисов. Шестьдесят пять процентов респондентов говорят, что возможность выполнять тесты как часть рабочего процесса вместо того, чтобы останавливать, тестировать, исправлять и перезапускать разработку, очень важна, а 61 процент респондентов сообщают, что автоматизация работы с уязвимостями, сканирования и устранения последствий на каждом этапе SDLC очень важны.
Невозможность быстрого обнаружения уязвимостей и угроз является причиной номер один, по которой уязвимости в приложениях трудно устранить. Шестьдесят один процент респондентов утверждают, что устранять уязвимости в приложениях сложно или очень сложно. Причина трудностей заключается в неспособности быстро выявлять уязвимости (55 процентов респондентов), невозможности быстро выполнить исправления в боевых приложениях (49 процентов респондентов), а также в отсутствии необходимых инструментов безопасности (43 процента респондентов).
Более половины организаций уделяют внимание только тем уязвимостям, которые представляют наибольший риск. Пятьдесят три процента респондентов считают, что важно сосредоточиться только на тех уязвимостях, которые представляют наибольший риск, а не на устранении всех уязвимостей. Сорок девять процентов респондентов утверждают, что их организация устраняет все уязвимости, поскольку не знает, какие из них представляют наибольший риск.
Тестирование приложений и ведение реестра критически важных для бизнеса приложений - это шаги, которые у многих респондентов были полностью или частично реализованы. 45 процентов респондентов заявили, что их организации тестируют приложения на наличие уязвимостей автоматизированно, а 44 процента респондентов - что их организации создали и ведут реестр приложений и оценивают их критичность для бизнеса.
Список материалов программного обеспечения (SBOM) - это список компонентов, входящих в состав программного обеспечения. Поставщики программного обеспечения часто создают продукты, собирая пакеты из компонентов с открытым исходным кодом и коммерческих компонентов. SBOM описывает компоненты продукта. Динамический SBOM обновляется автоматически при каждом обновлении или изменении. Сорок один процент респондентов утверждают, что их организации используют SBOM. Оценка рисков и соответствие нормативным требованиям - две главные особенности SBOM этих организаций. Хотя 70 процентов респондентов сообщают, что непрерывные автоматические обновления важны или очень важны, только 47 процентов утверждают, что их SBOM поддерживают непрерывные обновления.
Растущая поверхность атаки на программное обеспечение вызывает большую озабоченность. Семьдесят один процент респондентов заявили, что их организации обеспокоена или очень обеспокоена рисками, связанными с растущей поверхностью атаки на программное обеспечение. Еще больший процент респондентов (77 процентов) считают, что этот вопрос важен или очень важен.
Несмотря на озабоченность, большинство организаций неэффективны как в понимании поверхности атаки, так и в ее защите. Только 43 процента респондентов считают, что эффективность их организаций очень высока, и только 45 процентов респондентов сообщают, что их организации эффективны в понимании поверхности атаки.
Снижение комплексности и устранение уязвимостей, которые можно использовать в атаках, являются наиболее важными шагами для защиты приложений. Шестьдесят процентов респондентов утверждают, что устранение комплексности в уязвимостях, которые можно эксплуатировать (56 процентов респондентов), снизит киберриски. За этим следует знание всех компонентов программного обеспечения (51 процент респондентов). Только 26 процентов респондентов утверждают, что регулярное сканирование сети снижает риски.
Часть 2. Анализ результатов исследования.
В этом разделе мы приводим анализ результатов исследования, полные выводы представлены в Приложении к данному отчету.
DevSecOps: преимущества и проблемы.
Большинство организаций достигли понимания необходимости принятия подхода DevSecOps. Все организации, представленные в данном исследовании, либо планируют, либо уже запланировали внедрение DevSecOps для повышения безопасности при разработке приложений.
Согласно рисунку 2, 69 процентов респондентов утверждают, что их организации либо достигли зрелой стадии, когда DevOps полностью перешел в DevSecOps, а безопасность интегрирована на каждом этапе SDLC (29 процентов респондентов), либо начинают интегрировать DevSecOps на каждом этапе жизненного цикла разработки ПО.
Рис. 2: Что лучше всего описывает степень зрелости DevSecOps в вашей организации?
По мнению 45% респондентов, две основные причины внедрения DevSecOps - это улучшение взаимодействия между командами разработки, безопасности и операционными командами и сокращение времени на исправление уязвимостей. На рисунке 3 перечислены преимущества подхода DevSecOps. Помимо улучшения взаимодействия и сокращения времени на исправление уязвимостей, 41 процент респондентов утверждают, что такой подход позволяет автоматизировать поставку безопасного программного обеспечения без замедления цикла разработки.
Рис. 3: Каковы основные причины внедрения DevSecOps?
Для достижения зрелости DevSecOps организациям необходимы правильные инструменты безопасности. На рисунке 4 представлен список проблем на пути к достижению полностью эффективного DevSecOps. Основными препятствиями являются отсутствие эффективных инструментов безопасности (54 процента респондентов), отсутствие интеграции рабочих процессов (53 процента респондентов) и растущее количество уязвимостей (52 процента респондентов).
Рис. 4: Какие проблемы стоят на пути к созданию полностью эффективного DevSecOps?
Сокращение количества накопленных уязвимостей.
Почти половина респондентов утверждает, что в их организациях есть накопившиеся уязвимости. Сорок семь процентов респондентов утверждают, что за последние 12 месяцев в организациях были приложения, которые были определены как уязвимые, но не были исправлены. В среднем 1,1 миллиона уязвимостей находились в этом списке за последние 12 месяцев, и в среднем 46 процентов из них были устранены. Однако, по словам респондентов, их организации были бы удовлетворены, если бы были устранены хотя бы 29 процентов уязвимостей за год.
По мнению 47 процентов респондентов, неспособность определить приоритеты исправлений является основной причиной существования отставания. Согласно рисунку 5, основной причиной существования отставаний является отсутствие достаточной информации о рисках эксплуатации уязвимостей (45 процентов респондентов) и отсутствие эффективных инструментов (43 процента респондентов).
Рис. 5: Какие проблемы возникли при устранении отставания?
Стратегия «сдвига влево» - когда решение проблем и другие действия переносятся как можно ближе к конечному пользователю. Эффективный подход «сдвига влево» не должен увеличивать объем работы для разработчиков, а наоборот, должен помочь им быть более эффективными. Сдвиг влево должен сократить отставание разработчиков в поиске уязвимостей и помочь им определить приоритеты, которые могут быть использованы при создании инновационных продуктов.
Основной проблемой для реализации стратегии сдвига влево является отсутствие интегрированных инструментов безопасности. Пятьдесят два процента респондентов утверждают, что их организации приняли стратегию сдвига влево, как описано выше. Респонденты считают, что существуют проблемы, вызванные стратегией сдвига влево, которые затрудняют создание инновационных приложений или сервисов. Как показано на рисунке 6, проблемами являются отсутствие интегрированных инструментов безопасности, увеличение объема работы для разработчиков и слишком большое количество уязвимостей.
Рис. 6: Какие проблемы создает стратегия «сдвига влево» для создания инновационных приложений или сервисов?
Сорок семь процентов респондентов утверждают, что их организации приняли стратегию «сдвига вправо», которая обеспечивает непрерывную обратную связь с пользователями. Пятьдесят один процент респондентов считают, что преимущества стратегии позволяют инженерам более качественно тестировать разработанные приложения.
Организации несколько эффективнее определяют приоритеты наиболее важных уязвимостей, чем их исправляют. Респондентов попросили оценить эффективность своих организаций в определении приоритетов и исправлении уязвимостей по шкале от 1 до 10. На рисунке 7 представлены ответы 7+. Как видно из рисунка, 52 процента респондентов утверждают, что приоритезация критических уязвимостей в их организациях очень эффективна, но только 43 процента респондентов считают своевременное исправление уязвимостей высокоэффективным.
Рис. 7: Эффективность определения приоритетов и своевременного исправления уязвимостей по шкале от 1 до 10 , ответы 7+
Как показано на рисунке 8, оценка уязвимости по шкале безопасности Common Vulnerability Scoring System (CVSS) является методом номер один для определения приоритетности уязвимостей. За ним следует определение того, какие подверженные риску активы являются наиболее важными для бизнеса, и собственные метрики оценки (оба показателя использовали 23 процента респондентов).
Рис. 8: Каков ваш основной метод приоритезации уязвимостей.
В большинстве случаев исправление уязвимостей задерживается из-за сложности отслеживания. На рисунке 9 представлены причины, вызывающие серьезные задержки в процессах исправления уязвимостей. За сложностью отслеживания (51 процент респондентов) следует невозможность вывести критически важные приложения и системы из эксплуатации, чтобы их можно было быстро обновить (49 процентов респондентов).
Рис. 9: Какие факторы вызывают серьезные задержки в вашем процессе исправления уязвимостей?
Большая часть времени, еженедельно затрачиваемого на управление уязвимостями, посвящена устранению уязвимостей (40 процентов) и определению приоритетов 35 процентов, как показано на рисунке 10.
Рис. 10: Сколько времени ваша команда тратит еженедельно на следующие виды деятельности по управлению уязвимостями?
Автоматизация значительно сокращает время на устранение уязвимостей. Пятьдесят шесть процентов респондентов утверждают, что их организации используют автоматизацию для помощи в управлении уязвимостями. Из них 59 процентов респондентов утверждают, что их организации автоматизируют исправления, 47 процентов утверждают, что автоматизирована расстановка приоритетов, а 41 процент утверждают, что автоматизирована отчетность.
Как показано выше, каждую неделю команда ИТ-безопасности тратит большую часть своего времени на устранение уязвимостей. Согласно рисунку 11, 60 процентов респондентов, использующих автоматизацию, утверждают, что она значительно сокращает время на устранение уязвимостей (43 процента) или незначительно сокращает его (17 процентов).
Рис. 11: Как автоматизация повлияла на время, необходимое для устранения уязвимостей?
Ниже приводится разбивка времени на обнаружение, определение приоритетов и устранение одной уязвимости в разработке, производстве и инфраструктуре.
Согласно результатам исследования:
- В разработке больше всего времени уходит на приоритезацию и устранение уязвимостей.
- В боевых средах больше всего времени тратится на обнаружение и устранение уязвимостей.
- В инфраструктуре инженеры ИТ/инфраструктуры тратят больше всего времени на определение приоритетности уязвимостей.
- В инфраструктуре команда по управлению уязвимостями тратит больше всего времени на определение приоритетов и устранение уязвимостей.
Согласно рисунку 12, в разработке на обнаружение одной уязвимости уходит в среднем 23 минуты, на определение приоритетности одной уязвимости - 27 минут, а на устранение одной уязвимости - 29 минут.
Рис. 12: Время на обнаружение, определение приоритетов и устранение одной уязвимости в процессе разработки (экстраполированные значения).
В процессе эксплуатации систем на обнаружение одной уязвимости уходит 29 минут, на определение приоритетов - 28 минут, а на устранение одной уязвимости - 29 минут, как показано на рисунке 13.
Рис. 13: Время на обнаружение, определение приоритетов и устранение одной уязвимости в боевых средах (экстраполированные значения).
Шестьдесят три процента респондентов считают инфраструктуру своих организаций критически важной. Согласно рисунку 14, в среднем на обнаружение одной уязвимости у ИТ-инженеров уходит 16 минут, на определение приоритетности одной уязвимости - 23 минуты, а на устранение одной уязвимости у - 12 минут.
Рис. 14: Время обнаружения, приоритезации и устранения одной уязвимости инженерами ИТ (экстраполированные значения).
В среднем, командам по управлению уязвимостями требуется 11 минут для обнаружения уязвимости, 12 минут для приоритезации и 12 минут для устранения, как показано на рисунке 15.
Рис. 15: Время обнаружения, приоритезации и устранения одной уязвимости командами управления уязвимостями в инфраструктуре (экстраполированные значения).
Разработка безопасных приложений и сервисов.
DevOps - это подход, основанный на принципах бережливости и гибкости, позволяющий быстро разрабатывать программное обеспечение, которое позволяет организациям использовать все рыночные возможности. Пятьдесят один процент респондентов утверждают, что в той или иной степени участвуют в деятельности DevOps в своей организации. Как показано на рисунке 16, 52 процента респондентов заявили, что они участвуют в управлении уязвимостями, а 49 процентов респондентов заявили, что они участвуют в обеспечении безопасности приложений.
Рис. 16: Как вы участвуете в деятельности DevOps вашей организации?
Определенные функции важны для создания безопасных приложений или сервисов. Респондентов попросили оценить определенные функции при создании безопасных приложений или услуг по шкале от 1 до 10. На рисунке 17 представлены очень важные функции (7+ по 10-балльной шкале). Шестьдесят пять процентов респондентов считают, что возможность проводить тесты в рамках рабочего процесса вместо остановки, тестирования, исправления и перезапуска разработки очень важна, а 61 процент респондентов считают, что автоматизация поиска уязвимостей, сканирования и устранения последствий на каждом этапе SDLC очень важна.
Рис. 17: Важность функций для создания безопасных приложений по шкале от 1 до 10, ответы 7+.
Невозможность быстрого обнаружения уязвимостей и угроз является причиной номер один, по которой уязвимости в приложениях трудно устранить. Шестьдесят один процент респондентов утверждают, что устранять уязвимости в приложениях сложно или очень сложно. Как показано на рисунке 18, 55 процентов респондентов сообщают о неспособности быстро обнаруживать уязвимости, а 49 процентов респондентов - о неспособности быстро внедрять исправления в боевых средах, за которыми следует отсутствие необходимых инструментов безопасности (43 процента респондентов).
Рис. 18: Почему трудно устранять уязвимости в приложениях?
Текущие решения, используемые для устранения уязвимостей в приложениях, слишком сложны. На рисунке 19 перечислены болевые точки текущих технологий, используемых для устранения уязвимостей. Как видно из рисунка, 53 процента респондентов говорят о чрезмерной сложности, 47 процентов - о проблемах масштабируемости и 45 процентов - о трудностях совместимости.
Рис. 19: Какие основные проблемные точки в текущих решениях, используемых для устранения уязвимостей в приложениях?
Более половины организаций фокусируются только на тех уязвимостях, которые представляют наибольший риск. Согласно Рисунку 20, 53 процента респондентов считают, что важно сосредоточиться только на тех уязвимостях, которые представляют наибольший риск, а не на устранении всех уязвимостей. Сорок девять процентов респондентов утверждают, что их организация устраняет все уязвимости, поскольку не знает, какие из них представляют наибольший риск.
Рис. 20: Восприятие устранения уязвимостей.
Тестирование приложений и ведение реестра критически важных приложений - это шаги, которые были полностью или частично реализованы. Как показано на рисунке 21, для управления уязвимостями 45% респондентов тестируют приложения на наличие уязвимостей автоматизированно, а 44% респондентов утверждают, что их организации создали и ведут реестр приложений и оценивают их критичность для бизнеса.
Рис. 21: Полностью или частично реализованные шаги, предпринятые для управления рисками безопасности приложений.
Список материалов программного обеспечения (SBOM) - это список компонентов, входящих в состав программного обеспечения. Поставщики программного обеспечения часто создают продукты, собирая компоненты с открытым исходным кодом и коммерческие компоненты. SBOM описывает компоненты продукта. Динамический SBOM обновляется автоматически при каждом выпуске или изменении. Сорок один процент респондентов утверждают, что их организации используют SBOM.
Оценка рисков и соответствие нормативным требованиям - две главные особенности SBOM этих организаций, как показано на рисунке 22. Хотя 70 процентов респондентов говорят, что непрерывные автоматические обновления важны или очень важны, только 47 процентов утверждают, что их SBOM поддерживает непрерывные обновления.
Рис. 22: Какие из перечисленных ниже функций являются особенностями SBOM вашей организации.
Минимизация рисков в области атак на программное обеспечение.
Растущая поверхность атак на программное обеспечение вызывает серьезную озабоченность. Респондентов попросили оценить уровень их озабоченности растущей поверхностью атаки на программное обеспечение, а также важность сокращения поверхности атаки на программное обеспечени. На рисунке 23 представлены ответы 7+ по 10-балльной шкале. Семьдесят один процент респондентов заявили, что их организации очень или очень обеспокоены рисками, создаваемыми растущей поверхностью атаки программного обеспечения. Больший процент респондентов (77 процентов) считают, что это важно или очень важно.
Рис. 23: Обеспокоенность растущей поверхностью атак и важность ее сокращения по шкале от 1 до 10, ответы 7+.
Несмотря на озабоченность, большинство организаций неэффективны как в исследовании поверхности атаки, так и в ее защите. Респондентов попросили оценить свой уровень эффективности в обеспечении безопасности на протяжении всего SDLC и знании поверхности атаки своей организации. На рисунке 24 представлены ответы 7+ по 10-балльной шкале. Только 43 процента респондентов заявили, что эффективность их организаций очень высока, и только 45 процентов респондентов заявили, что их организации эффективны в исследовании поверхности атаки.
Рис. 24: Эффективность в обеспечении безопасности SDLC и знание поверхности атаки по шкале от 1 до 10, ответы 7+.
Снижение комплексности и устранение уязвимостей, которые можно эксплуатировать, являются наиболее важными шагами для защиты поверхности атаки. Как показано на рисунке 25, 60 процентов респондентов утверждают, что устранение комплексности поверхности атаки программного обеспечения, уязвимостей, которые можно эксплуатировать (56 процентов респондентов), уменьшит угрозы. За этим следует знание всех компонентов программного обеспечения (51 процент респондентов). Только 26 процентов респондентов утверждают, что регулярное сканирование сети снизит риски кибератак.
Рис. 25: Наиболее важные шаги по снижению угроз для поверхности атаки программного обеспечения.
Часть 3. Методология.
В качестве участников данного опроса были отобраны 16 510 практиков в области ИТ и ИТ-безопасности, осведомленных о поверхности атаки их организаций и эффективности управления уязвимостями. В таблице 1 показано 698 ответов. В ходе отсева и проверки надежности пришлось удалить 64 анкеты. Наша окончательная выборка состояла из 634 анкет или 3,8 процента ответов.
|
Охват исследования |
Кол-во |
% |
|
Общий охват |
16 510 |
100% |
|
Возвраты |
698 |
4.2% |
|
Отклоненные или отсеянные |
64 |
0.4% |
|
Окончательная выборка |
634 |
3.8% |
Диаграмма 1 показывает канал прямого подчинения респондента. Двадцать один процент респондентов подчиняется непосредственно CISO/CSO или руководителю службы информационной безопасности, 20 процентов респондентов - руководителю бизнес-подразделения или генеральному директору, 18 процентов респондентов - CIO, CTO или руководителю корпоративного ИТ, а 16 процентов респондентов - руководителю комплаенс-службы или внутреннего аудита.
Диаграмма 1: Канал подчинения респондентов.
Как показано на диаграмме 2, 59 процентов респондентов представляют организации с численностью сотрудников более 5 000 человек.
Диаграмма 2: Численность сотрудников с полной занятостью.
Диаграмма 3 отражает отраслевую направленность организаций респондентов. Данная диаграмма показывает, что наибольшую часть опрошенных представляют финансовые сервисы (18 процентов), которые включают банки, управление инвестициями, страхование, брокерские сервисы и платежные системы. Далее следуют промышленные предприятия (9 процентов респондентов), фармацевтические и биотехнологические компании (8 процентов респондентов), ИТ-компании (8 процентов респондентов), органы федерального правительства (7 процентов респондентов) и медицинские учреждения (7 процентов респондентов).
Диаграмма 3: Отраслевая направленность.
Часть 4. Ограничения исследования.
Существуют ограничения, присущие опросным исследованиям, которые необходимо учитывать, прежде чем делать выводы из полученных результатов. Ниже перечислены конкретные ограничения, которые характерны для большинства веб-опросов.
- Непредвзятость ответов: Текущие выводы основаны на выборке ответов на опрос. Мы разослали опросы репрезентативной выборке людей, в результате чего было получено большое количество пригодных для использования ответов. Несмотря на проверку отсутствия ответов, всегда существует вероятность того, что люди, не принявшие участие в исследовании, существенно отличаются по своим базовым убеждениям от тех, кто заполнил опросник.
- Предвзятость выборки: Точность основана на контактной информации и степени, в которой список является репрезентативным для профессионалов в области ИТ или ИТ-безопасности. Мы также признаем, что результаты могут быть предвзятыми из-за внешних событий, таких как освещение в СМИ. Наконец, поскольку мы использовали веб-метод сбора данных, возможно, что ответы, полученные не через веб-сайт путем почтового опроса или телефонного звонка, привели бы к другой картине результатов.
- Нерелевантные результаты: Качество исследования основано на честности конфиденциальных ответов, полученных от испытуемых. Хотя в процесс проведения опроса можно включить определенные системы сдержек и противовесов, всегда существует вероятность того, что испытуемый не предоставил точных ответов.
Часть 5. Приложение с подробными результатами.
В следующих таблицах представлены проценты ответов на все вопросы. Данные получены в июле 2022.
|
Охват исследования |
Кол-во |
|
Общая выборка |
16 510 |
|
Возвраты |
698 |
|
Отклоненные |
64 |
|
Окончательная выборка |
634 |
|
Доля ответов |
3.8% |
|
Что лучше всего определяет ваш уровень знаний о поверхности атаки программного обеспечения и управлении уязвимостями? |
|
|
Очень хорошо осведомлены |
37% |
|
Осведомлены |
44% |
|
Слабо осведомлены |
19% |
|
Знания отсутствуют (конец опроса) |
0% |
|
Итого |
100% |
|
Приняла ли ваша организация подход DevSecOps или находится в процессе принятия DevSecOps? |
|
|
Да |
100% |
|
Нет (конец опроса) |
0% |
|
Итого |
100% |
|
Какими из перечисленных ниже видов деятельности вы занимаетесь? Выберите все подходящие варианты. |
|
|
Выявление уязвимостей |
47% |
|
Обеспечение соответствия требованиям |
43% |
|
Внедрение технологий безопасности |
53% |
|
Приоритезация уязвимостей |
62% |
|
Устранение уязвимостей |
58% |
|
Обеспечение безопасности приложений и данных |
53% |
|
Безопасность цепочки поставок |
60% |
|
Тестирование приложений |
49% |
|
Безопасная разработка |
55% |
|
Ничего из перечисленного (конец опроса) |
0% |
|
Итого |
100% |
|
Выберите должность, которая лучше всего описывает вашу роль в сфере ИТ/ кибербезопасности. |
|
|
ИТ-директор (CIO) |
11% |
|
Директор по ИБ (CISO) |
15% |
|
Главный архитектор безопасности |
4% |
|
Директор по безопасности (CSO) |
6% |
|
Комплаенс/юридическая служба |
5% |
|
Команда DevSecOps |
15% |
|
Менеджер ИТ |
11% |
|
Менеджер ИБ |
8% |
|
Инженер по безопасности |
12% |
|
Операционный центр безопасности (SOC) |
8% |
|
Тестировщик продуктов безопасности |
5% |
|
Ничего из перечисленного (конец опроса) |
0% |
|
Итого |
100% |
Представления о DevSecOps и DevOps.
|
Оцените каждое утверждение по следующей шкале: полностью согласен\согласен |
|
|
Наша команда разработчиков способна обеспечить как улучшение клиентского опыта, так и безопасность приложений. |
47% |
|
Я обеспокоен тем, что отсутствие прозрачности и приоритетов в практике безопасности DevOps ставит безопасность продуктов под угрозу. |
53% |
|
Разработчики, команды по безопасности продуктов и команды по соблюдению нормативно-правового соответствия согласуют свои действия, чтобы понимать уровень безопасности нашей организации и сферу ответственности друг друга для создания безопасных продуктов. |
55% |
Общие сведения о DevSecOps и DevOps.
|
Принимаете ли вы какое-либо участие в процессах DevOps вашей организации? |
|
|
Да |
51% |
|
Нет (пропустите следующий вопрос) |
49% |
|
Итого |
100% |
|
Если да, то как вы в этом участвуете? Выберите все подходящие варианты. |
|
|
Обеспечение соответствия требованиям |
37% |
|
Безопасность приложений |
49% |
|
Разработка |
42% |
|
Производство |
45% |
|
Управление уязвимостями |
52% |
|
Прочее (укажите) |
7% |
|
Итого |
232% |
|
Что лучше всего описывает степень зрелости DevSecOps в вашей организации? |
|
|
Ранняя стадия - организация только начинает планировать внедрение |
31% |
|
Средняя стадия - организация спланировала и определила свой подход и начинает интегрировать безопасность на каждом этапе жизненного цикла разработки программного обеспечения |
40% |
|
Зрелая стадия - DevOps полностью перешел в DevSecOps, а безопасность интегрирована на каждом этапе жизненного цикла разработки |
29% |
|
Итого |
100% |
|
Каковы основные причины, по которым ваша организация внедряет или уже внедрила DevSecOps? Выберите четыре варианта. |
|
|
Возможность решать проблемы безопасности по мере их возникновения |
30% |
|
Устранение проблем безопасности обходится дешевле |
32% |
|
Автоматизация поставки безопасного программного обеспечения без замедления цикла разработки |
41% |
|
Исключение дублирующих проверок и ненужных переделок |
40% |
|
Централизованный подход к проверке кода |
39% |
|
Сфокусированный подход к определению приоритетов и устранению рисков |
33% |
|
Улучшение взаимодействия между отделами разработки, безопасности и эксплуатации |
45% |
|
Ограничение времени, которое есть у злоумышленника на эксплуатацию уязвимостей в системах, предназначенных для публичного использования |
32% |
|
Сокращение затрат на исправление кода |
40% |
|
Сокращение времени на исправление уязвимостей |
45% |
|
Сокращение отставания в процессе устранения уязвимостей |
19% |
|
Прочее (укажите) |
4% |
|
Итого |
400% |
|
Какие проблемы стоят на пути к созданию полностью эффективного DevSecOps? Выберите четыре варианта. |
|
|
Растущее число уязвимостей |
52% |
|
Рост числа уязвимостей в системе безопасности приложений |
43% |
|
Недостаток бюджета |
36% |
|
Отсутствие автоматизации |
27% |
|
Отсутствие четкого руководства |
17% |
|
Отсутствие эффективных инструментов безопасности |
54% |
|
Отсутствие эффективных средств тестирования |
32% |
|
Отсутствие собственных специалистов |
18% |
|
Отсутствие обучения по вопросам безопасности |
27% |
|
Отсутствие интеграции рабочих процессов |
53% |
|
Руководство недооценивает риски небезопасных приложений |
12% |
|
Не считается приоритетом организации |
11% |
|
Давление, связанное со скоростью выпуска новых продуктов |
15% |
|
Прочее (укажите) |
3% |
|
Итого |
400% |
|
Приняла ли ваша организация стратегию «сдвига влево»? |
|
|
Да |
52% |
|
Нет (переход в следующий раздел) |
48% |
|
Итого |
100% |
|
Если да, то какие проблемы создает стратегия «сдвига влево» для возможности создания инновационных приложений или сервисов? Выберите все подходящие варианты. |
|
|
Увеличение объема работы для разработчиков |
43% |
|
Отсутствие интегрированных инструментов безопасности |
51% |
|
Слишком много уязвимостей, которые необходимо устранять |
40% |
|
Прочее (укажите) |
4% |
|
Итого |
138% |
|
Приняла ли ваша организация стратегию «сдвига вправо»? |
|
|
Да |
47% |
|
Нет (переход в следующий раздел) |
53% |
|
Итого |
100% |
|
Если да, то преимущество стратегии заключается в том, что она дает инженерам возможность тестировать больше, тестировать вовремя и тестировать позже. |
|
|
Полностью согласны |
23% |
|
Согласны |
28% |
|
Не уверены |
11% |
|
Не согласны |
24% |
|
Полностью не согласны |
14% |
|
Итого |
100% |
SDLC и управление уязвимостями.
Используя следующую 10-балльную шкалу, оцените важность следующих функций для создания безопасных приложений или сервисов.
|
Возможность выполнять тесты в рамках рабочего процесса вместо остановки, тестирования, исправления и перезапуска разработки. |
|
|
1-2 |
7% |
|
3-4 |
15% |
|
5-6 |
13% |
|
7-8 |
33% |
|
9-10 |
32% |
|
Итого |
100% |
|
Экстраполированное значение |
6.86 |
|
Автоматизация сканирования и устранения уязвимостей на каждом этапе SDLC. |
|
|
1-2 |
12% |
|
3-4 |
15% |
|
5-6 |
12% |
|
7-8 |
30% |
|
9-10 |
31% |
|
Итого |
100% |
|
Экстраполированное значение |
6.56 |
|
Оцените эффективность вашей организации в деле приоритезации уязвимостей. |
|
|
1-2 |
10% |
|
3-4 |
17% |
|
5-6 |
21% |
|
7-8 |
23% |
|
9-10 |
29% |
|
Итого |
100% |
|
Экстраполированное значение |
6.38 |
|
Оцените своевременность устранения уязвимостей в вашей организации. |
|
|
1-2 |
21% |
|
3-4 |
15% |
|
5-6 |
21% |
|
7-8 |
30% |
|
9-10 |
13% |
|
Итого |
100% |
|
Экстраполированное значение |
5.48 |
|
Сколько времени ваша команда тратит еженедельно на следующие виды деятельности по управлению уязвимостями? |
|
|
Выявление уязвимостей |
25% |
|
Приоритезация уязвимостей |
35% |
|
Устранение уязвимостей |
40% |
|
Итого |
100% |
|
Сколько в среднем времени требуется для обнаружения одной уязвимости в процессе разработки системы? |
|
|
Менее 5 минут |
4% |
|
5-10 минут |
10% |
|
11-15 минут |
15% |
|
16-20 минут |
22% |
|
21-30 минут |
23% |
|
Более 30 минут |
26% |
|
Итого |
100% |
|
Экстраполированное значение |
23.1 |
|
Сколько в среднем времени требуется для обнаружения одной уязвимости в процессе эксплуатации системы? |
|
|
Менее 5 минут |
5% |
|
5-10 минут |
2% |
|
11-15 минут |
8% |
|
16-20 минут |
8% |
|
21-30 минут |
30% |
|
Более 30 минут |
47% |
|
Итого |
100% |
|
Экстраполированное значение |
29.3 |
|
Сколько в среднем времени требуется для приоритезации одной уязвимости в процессе разработки системы? |
|
|
Менее 5 минут |
3% |
|
5-10 минут |
4% |
|
11-15 минут |
8% |
|
16-20 минут |
22% |
|
21-30 минут |
23% |
|
Более 30 минут |
40% |
|
Итого |
100% |
|
Экстраполированное значение |
27.3 |
|
Сколько в среднем времени требуется для приоритезации одной уязвимости в процессе эксплуатации системы? |
|
|
Менее 5 минут |
4% |
|
5-10 минут |
5% |
|
11-15 минут |
6% |
|
16-20 минут |
8% |
|
21-30 минут |
41% |
|
Более 30 минут |
36% |
|
Итого |
100% |
|
Экстраполированное значение |
27.6 |
|
Сколько в среднем времени требуется для устранения одной уязвимости в процессе разработки системы? |
|
|
Менее 5 минут |
0% |
|
5-10 минут |
1% |
|
11-15 минут |
5% |
|
16-20 минут |
12% |
|
21-30 минут |
45% |
|
Более 30 минут |
37% |
|
Итого |
100% |
|
Экстраполированное значение |
29.2 |
|
Сколько в среднем времени требуется для устранения одной уязвимости в процессе эксплуатации системы? |
|
|
Менее 5 минут |
5% |
|
5-10 минут |
2% |
|
11-15 минут |
8% |
|
16-20 минут |
8% |
|
21-30 минут |
32% |
|
Более 30 минут |
45% |
|
Итого |
100% |
|
Экстраполированное значение |
29.0 |
|
Считает ли ваша организация свою инфраструктуру критически важной? |
|
|
Да |
63% |
|
Нет |
37% |
|
Итого |
100% |
|
Сколько в среднем времени требуется для обнаружения одной уязвимости ИТ-инженерами? |
|
|
Менее 5 минут |
25% |
|
5-10 минут |
32% |
|
11-15 минут |
8% |
|
16-20 минут |
6% |
|
21-30 минут |
10% |
|
Более 30 минут |
19% |
|
Итого |
100% |
|
Экстраполированное значение |
15.7 |
|
Сколько в среднем времени требуется для обнаружения одной уязвимости командой управления уязвимостями? |
|
|
Менее 5 минут |
32% |
|
5-10 минут |
33% |
|
11-15 минут |
15% |
|
16-20 минут |
9% |
|
21-30 минут |
6% |
|
Более 30 минут |
5% |
|
Итого |
100% |
|
Экстраполированное значение |
10.9 |
|
Сколько в среднем времени требуется для приоритезации одной уязвимости ИТ-инженерами? |
|
|
Менее 5 минут |
4% |
|
5-10 минут |
10% |
|
11-15 минут |
15% |
|
16-20 минут |
22% |
|
21-30 минут |
23% |
|
Более 30 минут |
26% |
|
Итого |
100% |
|
Экстраполированное значение |
23.1 |
|
Сколько в среднем времени требуется для приоритезации одной уязвимости командой управления уязвимостями? |
|
|
Менее 5 минут |
32% |
|
5-10 минут |
24% |
|
11-15 минут |
20% |
|
16-20 минут |
12% |
|
21-30 минут |
3% |
|
Более 30 минут |
9% |
|
Итого |
100% |
|
Экстраполированное значение |
12.2 |
|
Сколько в среднем времени требуется для устранения одной уязвимости ИТ-инженерами? |
|
|
Менее 5 минут |
21% |
|
5-10 минут |
39% |
|
11-15 минут |
21% |
|
16-20 минут |
8% |
|
21-30 минут |
6% |
|
Более 30 минут |
5% |
|
Итого |
100% |
|
Экстраполированное значение |
11.5 |
|
Сколько в среднем времени требуется для устранения одной уязвимости командой управления уязвимостями? |
|
|
Менее 5 минут |
24% |
|
5-10 минут |
33% |
|
11-15 минут |
21% |
|
16-20 минут |
10% |
|
21-30 минут |
5% |
|
Более 30 минут |
7% |
|
Итого |
100% |
|
Экстраполированное значение |
12.0 |
|
Как только вы обнаруживаете критическую уязвимость в своей среде, в среднем сколько времени в среднем уходит на исправление? |
|
|
Немедленно |
1% |
|
1 неделя |
3% |
|
2 недели |
6% |
|
3 недели |
7% |
|
4 недели |
10% |
|
5 недель |
11% |
|
6 недель |
14% |
|
7 недель |
16% |
|
8 недель |
15% |
|
9 недель |
13% |
|
Более 9 недель |
4% |
|
Итого |
100% |
|
Экстраполированное значение (в неделях) |
6.08 |
|
Использует ли ваша организация автоматизацию в управлении уязвимостями? |
|
|
Да |
56% |
|
Нет |
44% |
|
Итого |
100% |
|
Если да, то какие шаги вы автоматизируете? Выберите все подходящие варианты. |
|
|
Приоритезация |
47% |
|
Установка обновлений |
59% |
|
Отчетность |
41% |
|
Прочее (укажите) |
3% |
|
Итого |
150% |
|
Если да, то как автоматизация повлияла на время, необходимое для устранения уязвимостей? |
|
|
Значительное сокращение времени реагирования |
43% |
|
Незначительное сокращение времени реагирования |
17% |
|
Без изменений в сроках реагирования |
22% |
|
Увеличение времени реагирования |
18% |
|
Итого |
100% |
|
Какой ваш основной метод приоритезации уязвимостей? |
|
|
Общая система оценки уязвимостей CVSS |
30% |
|
Определение того, какие уязвимости используются злоумышленниками в своих целях |
21% |
|
Определение какие уязвимые активы являются наиболее важными для бизнеса |
23% |
|
Собственные метрики оценки |
23% |
|
Прочее (укажите) |
3% |
|
Итого |
100% |
|
Какие из перечисленных ниже факторов вызывают серьезные задержки в вашем процессе исправления уязвимостей? Выберите все подходящие варианты. |
|
|
Человеческий фактор |
32% |
|
Моя организация не терпит простоя, необходимого для исправления ошибок |
28% |
|
Организационные проблемы |
45% |
|
Мы не можем легко отследить, своевременно ли устраняются уязвимости |
51% |
|
Мы не можем отключить критически важные приложения и системы, чтобы быстро их исправить |
49% |
|
Мы не думаем, что злоумышленник воспользуется нашими уязвимостями |
37% |
|
У нас нет общего представления о приложениях и активах для команд по безопасности и ИТ |
45% |
|
У нас недостаточно ресурсов, чтобы справиться с объемом исправлений |
43% |
|
У нас нет возможности привлечь ИТ-отдел или другие отделы к ответственности за исправления. |
36% |
|
Мы используем электронную почту и электронные таблицы для управления процессом, поэтому все ускользает от внимания |
29% |
|
Прочее (укажите) |
3% |
|
Итого |
398% |
Риски безопасности приложений.
|
Насколько сложно устранять уязвимости в приложениях? |
|
|
Очень сложно |
36% |
|
Сложно |
25% |
|
Средне |
16% |
|
Не сложно |
14% |
|
Легко |
9% |
|
Итого |
100% |
|
[Если очень трудно или трудно] Почему трудно устранять уязвимости в приложениях? Выберите все подходящие варианты. |
|
|
Невозможность быстрого обнаружения уязвимостей и угроз |
55% |
|
Невозможность быстро выполнять исправления для приложений в производстве |
49% |
|
Отсутствие необходимых инструментов безопасности |
43% |
|
Нехватка квалифицированного персонала |
38% |
|
Нехватка ресурсов |
15% |
|
Прочее (укажите) |
5% |
|
Итого |
205% |
|
Были ли в вашей организации за последние 12 месяцев отставания по уязвимостям (т.е. приложения, которые были определены как уязвимые, но уязвимости не были устранены)? |
|
|
Да |
47% |
|
Нет |
48% |
|
Не знаю |
5% |
|
Итого |
100% |
|
За последние 12 месяцев, какое приблизительное количество отдельных уязвимостей было в списке отставания? |
|
|
Менее 10 000 |
3% |
|
10 001 – 40 000 |
7% |
|
40 001 – 60 000 |
10% |
|
60 001 – 100 000 |
14% |
|
100 001 – 250 000 |
12% |
|
250 001 – 500 000 |
16% |
|
500 001 – 1 000 000 |
13% |
|
1 000 001 – 2 500 000 |
9% |
|
2 500 001 – 5 000 000 |
8% |
|
Более 5 000 000 |
8% |
|
Итого |
100% |
|
Экстраполированное значение |
1 086 220 |
|
За последние 12 месяцев, в среднем, какой процент уязвимых приложений был исправлен? |
|
|
Менее 5% |
4% |
|
5-10% |
12% |
|
11-25% |
17% |
|
26-50% |
21% |
|
51-75% |
25% |
|
76-100% |
21% |
|
Итого |
100% |
|
Экстраполированное значение |
46% |
|
Какой процент устранения этих уязвимостей будет считаться успехом? |
|
|
Менее 5% |
22% |
|
5-10% |
13% |
|
11-25% |
15% |
|
26-50% |
31% |
|
51-75% |
14% |
|
76-100% |
5% |
|
Итого |
100% |
|
Экстраполированное значение |
29% |
|
За последние 12 месяцев сколько времени потребовалось для устранения отставания? |
|
|
Менее 1 недели |
5% |
|
1-2 недели |
17% |
|
3-4 недели |
23% |
|
5-6 недель |
29% |
|
7-8 недель |
13% |
|
9-10 недель |
6% |
|
Более 10 недель |
7% |
|
Итого |
100% |
|
Экстраполированное значение (в неделях) |
5.02 |
|
С какими трудностями пришлось столкнуться при устранении отставания? Выберите все подходящие варианты. |
|
|
Неумение расставлять приоритеты |
47% |
|
Отсутствие эффективных инструментов |
43% |
|
Нехватка ресурсов |
38% |
|
Недостаточно информации о рисках |
45% |
|
Слишком трудоемко |
28% |
|
Прочее (укажите) |
3% |
|
Итого |
204% |
|
Каковы основные проблемы текущих решений, используемых для устранения уязвимостей в приложениях? Выберите три ответа. |
|
|
Сложность реализации |
42% |
|
Высокий процент ложных срабатываний |
30% |
|
Проблемы совместимости |
45% |
|
Чрезмерная сложность |
53% |
|
Плохая поддержка со стороны поставщика |
26% |
|
Проблемы масштабируемости |
47% |
|
Медленное исправление уязвимых приложений |
36% |
|
Слишком дорого |
18% |
|
Прочее (укажите) |
3% |
|
Итого |
300% |
|
Оцените по 10-балльной шкале насколько важно для вашей организации сократить отставание по уязвимостям. |
|
|
1-2 |
1% |
|
3-4 |
13% |
|
5-6 |
16% |
|
7-8 |
23% |
|
9-10 |
47% |
|
Итого |
100% |
|
Экстраполированное значение |
7.54 |
|
Для нашей организации важно сосредоточиться только на тех уязвимостях, которые представляют наибольший риск, а не концентрироваться на устранении всех уязвимостей. |
|
|
Полностью согласны |
25% |
|
Согласны |
28% |
|
Не уверены |
15% |
|
Не согласны |
18% |
|
Полностью не согласны |
14% |
|
Итого |
100% |
|
Наша организация устраняет все уязвимости, поскольку не знает, какие из них представляют наибольший риск. |
|
|
Полностью согласны |
23% |
|
Согласны |
26% |
|
Не уверены |
18% |
|
Не согласны |
14% |
|
Полностью не согласны |
19% |
|
Итого |
100% |
|
Ниже приведены пять стратегически важных шагов по управлению безопасностью приложений. Пожалуйста, укажите, в какой степени ваша организация выполняет каждый из них (полностью или частично). |
|
|
Создание и ведение реестра приложений и оценка их критичности для бизнеса. |
44% |
|
Автоматизированное тестирование приложения на наличие уязвимостей. |
45% |
|
Определение потенциальных рисков и приоритезация уязвимостей. |
42% |
|
Устранение уязвимостей как можно быстрее. |
36% |
|
Определение метрик, измерение прогресса и обеспечение соответствия требованиям. |
32% |
|
Насколько вы знакомы с программной спецификацией материалов (SBOM)? |
|
|
Плотно знакомы |
32% |
|
Знакомы |
34% |
|
Что-то слышали |
19% |
|
Не знакомы |
15% |
|
Итого |
100% |
|
Внедрила ли ваша организация подход SBOM? |
|
|
Да |
41% |
|
Нет |
59% |
|
Итого |
100% |
|
Оцените по 10-балльной шкале важность автоматических обновлений в вашем организации. |
|
|
1-2 |
0% |
|
3-4 |
16% |
|
5-6 |
14% |
|
7-8 |
24% |
|
9-10 |
46% |
|
Итого |
100% |
|
Экстраполированное значение |
7.50 |
|
Что из перечисленного присуще SBOM вашей организации? Выберите все подходящие варианты. |
|
|
Соблюдение нормативных требований |
54% |
|
Непрерывные обновления |
47% |
|
Экономия затрат |
44% |
|
Инвентаризация программных активов |
38% |
|
Соблюдение лицензионных требований |
37% |
|
Оценка рисков |
56% |
|
Безопасность цепочки поставок |
49% |
|
Прочее (укажите) |
2% |
|
Итого |
327% |
|
Оцените по 10-балльной шкале обеспокоенность вашей организации по поводу роста поверхности атаки на приложения. |
|
|
1-2 |
3% |
|
3-4 |
10% |
|
5-6 |
16% |
|
7-8 |
32% |
|
9-10 |
39% |
|
Итого |
100% |
|
Экстраполированное значение |
7.38 |
|
Оцените по 10-балльной шкале эффективность покрытия безопасности всего процесса разработки программного обеспечения. |
|
|
1-2 |
22% |
|
3-4 |
18% |
|
5-6 |
17% |
|
7-8 |
25% |
|
9-10 |
18% |
|
Итого |
100% |
|
Экстраполированное значение |
5.48 |
|
Оцените по 10-балльной шкале знание поверхности атаки на приложения вашей организации. |
|
|
1-2 |
24% |
|
3-4 |
21% |
|
5-6 |
10% |
|
7-8 |
25% |
|
9-10 |
20% |
|
Итого |
100% |
|
Экстраполированное значение |
5.42 |
|
Оцените по 10-балльной шкале важность уменьшения поверхности атаки на приложения для вашей организации. |
|
|
1-2 |
5% |
|
3-4 |
6% |
|
5-6 |
12% |
|
7-8 |
34% |
|
9-10 |
43% |
|
Итого |
100% |
|
Экстраполированное значение |
7.58 |
|
Каковы наиболее важные шаги по снижению угроз атаки на программное обеспечение вашей организации? Выберите все подходящие варианты. |
|
|
Устранение сложности поверхности атаки программного обеспечения |
60% |
|
Устранение уязвимостей, которые можно использовать |
56% |
|
Знание всех компонентов программного обеспечения |
51% |
|
Знание какие компоненты программного обеспечения могут быть эксплуатированы в атаке |
46% |
|
Сегментация сети |
48% |
|
Получение обновлений об угрозах в режиме реального времени |
35% |
|
Регулярное сканирование сети |
26% |
|
Прочее (укажите) |
4% |
|
Итого |
326% |
Демографические данные организации и респондентов.
|
Какая у вас должность? |
|
|
Генеральный/исполнительный директор |
4% |
|
Операционный директор |
3% |
|
Финансовый директор, контролер или руководитель финансового отдела |
5% |
|
ИТ-директор, технический директор или руководитель корпоративного ИТ-отдела |
18% |
|
Руководитель отдела разработки программного обеспечения |
11% |
|
Руководитель бизнес-подразделения или топменеджер |
20% |
|
Руководитель отдела соответствия или внутреннего аудита |
16% |
|
CISO/CSO или руководитель службы ИТ-безопасности |
21% |
|
Прочее |
2% |
|
Итого |
100% |
|
Каково количество работников в вашей организации? |
|
|
Менее 1 000 |
21% |
|
1 000 – 5000 |
20% |
|
5 001 – 10 000 |
17% |
|
10 001 – 25 000 |
23% |
|
25 001 – 75 000 |
10% |
|
Более 75 000 |
9% |
|
Итого |
100% |
|
Какова отрасль деятельности вашей организации? |
|
|
Телекоммуникации |
2% |
|
Потребительские товары |
5% |
|
Оборона |
1% |
|
Образование и исследования |
2% |
|
Энергетика и ЖКХ |
6% |
|
Развлечения и СМИ |
3% |
|
Федеральное правительство |
7% |
|
Финансовые сервисы |
18% |
|
Здравоохранение |
7% |
|
Туризм |
2% |
|
Промышленное производство |
9% |
|
Фармацевтика и биотехнологии |
8% |
|
Профессиональные сервисы |
3% |
|
Розничная торговля |
5% |
|
Онлайн-торговля |
3% |
|
Услуги |
6% |
|
Местное управление |
3% |
|
ИТ |
8% |
|
Перевозки |
2% |
|
Прочее (укажите) |
0% |
|
Итого |
100% |
О Ponemon Institute.
Продвигаем ответственное управление информацией.
Ponemon Institute занимается независимыми исследованиями, которые способствуют развитию ответственного управления информацией и конфиденциальностью в бизнесе и государственном управлении. Наша миссия заключается в проведении высококачественных эмпирических исследований по важнейшим вопросам, влияющим на управление и безопасность конфиденциальной информации о людях и организациях.
Мы придерживаемся строгих стандартов конфиденциальности данных, неприкосновенности частной жизни и этических норм проведения исследований. Мы не собираем никакой персональной информации от частных лиц (или идентифицируемой информации компании в наших бизнес-исследованиях). Кроме того, мы придерживаемся строгих стандартов качества, чтобы гарантировать, что испытуемым не задают лишних, нерелевантных или некорректных вопросов.
Источник: https://www.rezilion.com
