На рынке технологического аудита прослеживается выделение двух основных направлений - безопасность инфраструктуры и безопасность приложений. Чтобы совсем все просто: первые - ломают домен Windows, получают root-а в UNIX или админов в сетевом оборудовании или СУБД, вторые - делают НСД в приложениях, говоря жаргонизмом, занимаются AppSec-ом.
В целом, действительно, умения инфраструктурного пентестера отличаются от скилов AppSec-овца, однако, не меньшие различия можно проследить между спецом по Web-у (причем, внутри Web-а тоже можно подробить) и, скажем, по SAP-у (где, кстати, тоже приложения сильно различаются и спец по HR не сразу подхватит FI или MM, а еще есть деление на R/3 и Java и много чего другого), хотя оба относятся к AppSec-овцам.
С позиции Заказчика это разделение на AppSec и инфраструктуру также выглядит искусственным, придуманным для удобства Поставщика и не нужным для Заказчика. И объяснение этому очень простое: инфраструктура не несет в себе бизнес-ценности. Ее назначение - обеспечение работы приложений (конечно же с достижением должного уровня сервиса), которые уже, в свою очередь, автоматизируют процессы Заказчика, а следовательно, имеют бизнес-ценность. И в общем-то, если мы говорим о Безопасности, как о функции защиты бизнес-процессов предприятия, логичный приоритет Безопасности - AppSec, обеспечение безопасности приложений, поддерживающих бизнес-процессы предприятия.
Но всем известна очевидная истина: любая система может быть скомпрометирована с более низкого уровня: "безопасное приложение" может быть скомпрометировано с уровня небезопасной ОС, "безопасная ОС" - с уровня небезопасного железа, да и в самой ОС в ядерном режиме не работает никакая безопасность, навороченная в пользовательском режиме, любые логические контроли можно обойти при физическом доступе к устройству и т.п. Это раз.
Во-вторых, часты случаи, когда защиту от тех или иных атак нет возможности реализовать непосредственно в приложении, поэтому мы вынуждены вынести обеспечение безопасности не уровень инфраструктуры. Примером здесь может быть случай, когда приложение не обеспечивает конфиденциальность и целостность своего трафика и мы строим шифрованные туннели VPN, или когда нет стойкой аутентификации на уровне приложения мы также можем решить проблему на сетевом/транспортном/сессионном уровне (смотря кто какой протокол для VPN предпочитает). Сюда же можно отнести всякие "изолированные сегменты", "воздушные зазоры" и прочие варианты "навесной безопасности", когда нет "интегрированных" средств.
Поэтому, конечная цель Безопасность приложения, очевидно, не достигается только контролем безопасности на уровне самого приложения и, решая, казалось бы исключительно AppSec-ную задачу, всегда надо проверять весь стек технологий (следует заметить, что, конечно же, корректно привязываться не уровням модели OSI и стеку технологий по ней распределенному, а к модели потенциального нарушителя, однако, практически всегда, инфраструктурный вектор компрометации приложения имеется в наличии), а, следовательно, желающему получить более или менее комплексное решение задачи контроля безопасности приложения, необходимо включать в объем работ инфраструктурную часть, релевантную исследуемому приложению.
В целом, действительно, умения инфраструктурного пентестера отличаются от скилов AppSec-овца, однако, не меньшие различия можно проследить между спецом по Web-у (причем, внутри Web-а тоже можно подробить) и, скажем, по SAP-у (где, кстати, тоже приложения сильно различаются и спец по HR не сразу подхватит FI или MM, а еще есть деление на R/3 и Java и много чего другого), хотя оба относятся к AppSec-овцам.
С позиции Заказчика это разделение на AppSec и инфраструктуру также выглядит искусственным, придуманным для удобства Поставщика и не нужным для Заказчика. И объяснение этому очень простое: инфраструктура не несет в себе бизнес-ценности. Ее назначение - обеспечение работы приложений (конечно же с достижением должного уровня сервиса), которые уже, в свою очередь, автоматизируют процессы Заказчика, а следовательно, имеют бизнес-ценность. И в общем-то, если мы говорим о Безопасности, как о функции защиты бизнес-процессов предприятия, логичный приоритет Безопасности - AppSec, обеспечение безопасности приложений, поддерживающих бизнес-процессы предприятия.
Но всем известна очевидная истина: любая система может быть скомпрометирована с более низкого уровня: "безопасное приложение" может быть скомпрометировано с уровня небезопасной ОС, "безопасная ОС" - с уровня небезопасного железа, да и в самой ОС в ядерном режиме не работает никакая безопасность, навороченная в пользовательском режиме, любые логические контроли можно обойти при физическом доступе к устройству и т.п. Это раз.
Во-вторых, часты случаи, когда защиту от тех или иных атак нет возможности реализовать непосредственно в приложении, поэтому мы вынуждены вынести обеспечение безопасности не уровень инфраструктуры. Примером здесь может быть случай, когда приложение не обеспечивает конфиденциальность и целостность своего трафика и мы строим шифрованные туннели VPN, или когда нет стойкой аутентификации на уровне приложения мы также можем решить проблему на сетевом/транспортном/сессионном уровне (смотря кто какой протокол для VPN предпочитает). Сюда же можно отнести всякие "изолированные сегменты", "воздушные зазоры" и прочие варианты "навесной безопасности", когда нет "интегрированных" средств.
Поэтому, конечная цель Безопасность приложения, очевидно, не достигается только контролем безопасности на уровне самого приложения и, решая, казалось бы исключительно AppSec-ную задачу, всегда надо проверять весь стек технологий (следует заметить, что, конечно же, корректно привязываться не уровням модели OSI и стеку технологий по ней распределенному, а к модели потенциального нарушителя, однако, практически всегда, инфраструктурный вектор компрометации приложения имеется в наличии), а, следовательно, желающему получить более или менее комплексное решение задачи контроля безопасности приложения, необходимо включать в объем работ инфраструктурную часть, релевантную исследуемому приложению.
1 comment:
Post a Comment