Как искать уязвимости

Поиск уязвимостей в стандартном ПО

Поиск уязвимостей в прикладном ПО

Для собственного ПО

Для заказного ПО

Резюме

Поиск уязвимостей в стандартном ПО

Для стандартного программного обеспечения проблема поиска уязвимостей конфигурирования и эксплуатации решена, имеется множество решений. Они называются сканерами безопасности. В том числе эта же проблема решена методически, для каждого стандартного программного обеспечения имеется множество разнообразных документов, которые описывают, как необходимо конфигурировать и эксплуатировать данное стандартное программное обеспечение, и как его эксплуатировать нельзя.

Т.е. имея в штате администратора, которому можно поставить задачу по безопасной конфигурации стандартного программного обеспечения, и проверяя его работу используя сканер безопасности (неважно как он работает в режиме черного ящика или в режиме белого ящика), можно решить задачу наличия уязвимостей в стандартном программном обеспечении.

Поиск уязвимостей в прикладном ПО

Перейдем к прикладному программному обеспечению (т.е. к заказному и собственному ПО). Выше мы говорили о том, почему для поиска недостатков в прикладном программном обеспечение, как разработанном на заказ, так и собственном, не так хорошо подходят сканеры общего назначения. В первую очередь потому, что производители программного обеспечения, производители стандартных сканеров, ничего не знают о Вашем программном обеспечении, не знают версионности, не знают, как правильно конфигурировать Ваше программное обеспечение. Один из основных моментов – они также не умеют искать эти уязвимости этапа кодирования.

Для поиска уязвимостей этапа кодирования в собственном программном обеспечении, а чаще всего это собственное программное обеспечение представляет из себя web-приложения, придуманы статические анализаторы кода и анализаторы кода, которые работают в режиме черного ящика (по-английски – web application scanner). Тем не менее, в отличие от своих собратьев, которые устанавливают уязвимости конфигурирования и эксплуатации для стандартного программного обеспечения и делают это достаточно хорошо, сканеры собственного кода прикладного программного обеспечения работают не так хорошо. В силу, во-первых, большого многообразия технологий, которые используются при реализации собственного прикладного программного обеспечения, а во-вторых, в силу того, что большинство собственного прикладного программного обеспечения решает конкретные задачи (т.е. business specific), для которых общие проверки заранее предусмотреть очень тяжело.

Таким образом, давайте сформулируем и рассмотрим задачу поиска уязвимостей этапов проектирования, а также разработки и кодирования для прикладного ПО (заказного и собственного).

Для собственного ПО

Рассмотрим вначале задачу борьбы с уязвимостями этапов проектирования, а также разработки и кодирования для собственного ПО.

В целом, эта задача неплохо решена уже с методической точки зрения. Компанией Microsoft был придуман особый цикл разработки, который называется Secure Software Development Lifecycle (SDLC), в котором описаны необходимые шаги и мероприятия, позволяющие управляемо контролировать защищенность конечных программных продуктов. Такая разработка становится более дорогой, нежели обычная разработка, которая в основном учитывает только функциональные требования. Тем не менее, на выходе во втором случае получается более качественный продукт и считается, что итоговая стоимость владения программным продуктом в случае применения SDLC меньше за счет снижения средств на поддержку и исправление ошибок в дальнейшем по сравнению со стандартной разработкой, в которой упор делается только на функциональные программные возможности.

Кроме того компания сама обладает экспертизой по разработке и тестированию кода, это значит, что в целом разработчикам достаточно объяснить, как правильно делать, и как неправильно делать. Можно ожидать, что процесс будет в дальнейшем сходиться к нужному результату с точки зрения снижения недостатков этапов проектирования, а также разработки и кодирования.

Для заказного ПО

Намного больше проблем возникает в задаче борьбы с уязвимостями этапов проектирования и кодирования при заказе программного обеспечения. Источник всех проблем – это отсутствие экспертизы у Заказчика. Действительно, если бы у Заказчика была достаточная экспертиза в целом по программированию, по разработке, тестированию и приемке программного обеспечения, можно было бы либо своими силами разработать соответствующий программный продукт, либо же предъявить на этапе разработки достаточно серьезные требования к опасности итогового продукта. В силу того, что такой экспертизы нет, программное обеспечение заказывается так, что в техническом задании присутствуют в основном функциональные требования и принимается программное обеспечение методом проверки этих же самых функциональных требований. То есть если программное обеспечение выполняет все функции, которые от него ожидаются, значит такое программное обеспечение устраивает Заказчика.

Можно представить такой вариант, что Заказчик программного обеспечения при заказе берет классические требования к информационной безопасности и прописывает их в техническом задании. Это может быть сформулировано на достаточно высоком уровне. Например, отсутствие уязвимостей авторизации, отсутствие уязвимостей аутентификации, отсутствие уязвимостей, связанных с некорректной обработкой входных данных и т.д. На первый взгляд, это может решить проблему, но только на первый взгляд. Дело в том, что проверить выполнимость этих требований при отсутствии экспертизы на этапе сдачи программного обеспечения не реально. Именно поэтому задача борьбы с уязвимостями этапов проектирования и кодирования в заказном программном обеспечении по факту обычно возникает намного позже приемки. Другими словами, владелец заказного программного обеспечения, которое не было разработано с применением тактики защитного кодирования чаще всего подвергается какой-то атаке, и уже по факту возникновения инцидента появляется задача проверки.

Таким образом, из-за отсутствия экспертизы у Заказчика в отношении правильного цикла разработки программного обеспечения, единственно возможным выходом является привлечение внешней экспертизы. Либо постфактум, либо для новых приложений после того, как какие-то ошибки уже были совершены на этапе заказа и на этапе приемки программного обеспечения.

Резюме

Как же методически правильно бороться с различными классами недостатков в программном обеспечении различного рода?

В стандартном программном обеспечении имеет смысл бороться с уязвимостями внедрения и конфигурирования, а также эксплуатации. С этим успешно справляются стандартные сканеры стандартного же программного обеспечения.

В собственном прикладном программном обеспечении в случае, если программное обеспечение разрабатывается самостоятельно, имеет смысл бороться с этими уязвимостями на этапе разработки и кодирования, внедряя так называемые SDLC. Если же это не целесообразно делать, то, как минимум, необходимо добавлять требования на этапе заказа программного обеспечения, постановки задачи программистам и проверять эти требования на этапе тестирования безопасности продукта.

Как бы то ни было, обучение собственных разработчиков антипаторному программированию, то есть тому, что не нужно делать – это задача достаточно понятно решаемая.

В случае приобретения заказного программного обеспечения без внешней экспертизы никак не обойтись. Другими словами, единственным вариантом у владельца заказного программного обеспечения является привлечение внешних экспертов для проверки безопасности их программных продуктов. После случая, если это внимание у Заказчика заказных программных продуктов появляется на этапе заказа программного продукта, то имеет смысл привлекать некоторую третью стороннюю организацию, которая обладает экспертизой, и на этапе формирования требований, на этапе утверждения технического проекта заказного программного обеспечения, и на этапе приемки этого программного обеспечения. Так чтобы анализ защищенности программного обеспечения не отстоял от этапа разработки во времени на какой-то длительный срок.