Можно поинтересоваться - какая целевая ниша у этого продукта? Явно не по соседству с MaxPatrol его ставить и нагружать такой спецификой местных ИБшников. Тут скорее для каких-то хардкорных аудиторов и веб-программеров.Конечно, повышение защищенности приложений далеко не так увлекательно, как обеспечение соответствия очередной ветке регулирования законодательства о защите персональных данных, но все же.
Хотелось многое написать, но пусть вместо нас говорит рынок.
Согласно Verizon 2013 Data Breach Investigations Report, атаки на Web-приложения использовались в ~27% всех инцидентов ИБ в крупных корпорациях.
Осознают это и владельцы информационных систем. В общей сложности в 2012 году специалисты компании Positive Technologies изучили порядка 400 веб-приложений в рамках различных работ, начиная от инструментального сканирования и заканчивая анализом исходного кода. Результаты показывают положительный тренд, но в целом, ситуация достаточно далека от идеала.
Интерес к теме присутствует во всех отраслях экономики, причем серьезно вырос спрос со стороны государственных органов.
Здесь нет ничего удивительного, государственное управление сейчас активно автоматизируется, та же Универсиада в Казани – это 14 информационных систем, в состав которых входит несколько приложений.
Пусть вас не обманывает небольшой процент запросов на оценку защищенности из финансовой сферы. За тот же период было проведено более десятка работ по глубокому анализу защищенности платежных систем, включая ДБО.
В области информационных технологий озабоченность AppSec еще выше, и это заметно по активному развитию Bug Bounty. Цитирую.
Крупные компании вовсю используют привычные и относительно новые методы анализа защищенности, включая распространённый во всем мире вариант crowd-sourcing – Bug Bounty program. К активно спонсирующему российских вайтхэт Yandex недавно присоединился QIWI с достаточно приятными расценками, достигающими 150 000 рублей за уязвимость.Не отстают и регуляторы.
Традиционный драйвер ИБ в виде регуляторов тоже не обходит эту область стороной. Кроме привычных требований раздела 6 PCI DSS и стандарта PA DSS существует 7.3.5 СТО БР ИББС 1.0, косвенно затрагивающего безопасность приложений АБС.
В недавно утвержденном приказом ФСТЭК России №17 документе «Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» содержится тезис о необходимости проводить «анализ уязвимостей информационной системы», что может трактоваться достаточно широко, включая поиск уязвимостей реализации в программном обеспечении разработанном специально для ГАС. А уж если вспомнить о приказе N21, где явно обозначена "...проверка системного и (или) прикладного программного обеспечения, включая программный код, на отсутствие недекларированных возможностей"...
Таким образом, тема безопасности приложений вполне востребована рынком. Однако платить каждый раз пентестерам или держать штат доброхакеров для приемки новых разработок не всегда эффективно. Поэтому и ищут компании методы оптимизации затрат. Один из них, использование автоматизированных средств.
Более того, если разработка ведется in-house или есть плотный контакт с разработчиком, то возникает желание перенести анализ защищенности как можно ближе к процессу R&D, поскольку чем раньше выявлена уязвимость, тем дешевле ее устранять. Отсюда и возникает интерес к SDLC [1], [2], [3], где автоматизированные средства весьма и весьма полезны.
Прелесть SAST в этом контексте, что анализировать можно не все приложение, и нет необходимости иметь его полностью рабочую и развернутую версию, что согласитесь – не редкость в процессе разработки (пока нас всех не догнал DevOps).
Резюмируя и отвечая на вопрос:
Целевая аудитория, это специалисты по безопасности в крупных компаниях, специалисты по QA/безопасности в компаниях-разработчиках, аудиторы/пентестеры. Харкора при эксплуатации здесь быть не должно. Хардкор в принципах работы, но в них вникать не обязательно.
Комментариев нет:
Отправить комментарий