Критерии оценки экрана веб-приложений (стр. 3 )

Межсетевой экран уровня веб-сервера (тип «Г») – межсетевой экран, применяемый на сервере, обслуживающем сайты, веб-службы и веб-приложения, или на физической границе сегмента таких серверов (сервера). Межсетевые экраны типа «Г» могут иметь программное или программно-техническое исполнение и должны обеспечивать контроль и фильтрацию информационных потоков по протоколу передачи гипертекста, проходящих к веб-серверу и от веб-сервера;

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

2.2.  Анализ зарубежных практик.

Первым значимым драйвером рынка экранов веб-приложений стало обновление стандарта безопасности индустрии платежных карт PCI DSS в части требования 6.6 в 2008 году. В результате обновления у сертифицирующихся организаций появилась альтернатива при обеспечении информационной безопасности своих веб-приложений: организация может сама выбирать — либо поддерживать бизнес-процессы по анализу защищенности веб-приложений (внедрению процессов цикла безопасной разработки), либо внедрять и обслуживать экран веб-приложений. Новый вариант стандарта и определил первые ключевые требования для систем экранирования веб-приложений. Выполнение данных требований до сих пор актуально для многих разработчиков, так как стандарт особенно важен в финансовой и банковских сферах.

Общие требования к экрану веб-приложений по версии PCI DSS:

·  системные компоненты экрана веб-приложений должны соответствовать требованиям PCI DSS;

·  возможность реагирования на угрозы, описанные в OWASP Top Ten;

·  инспектирование запросов и ответов на соответствии с политикой безопасности, журналирование событий;

·  предотвращение утечки данных — инспекция ответов сервера на наличие критичных данных;

·  применение как позитивной, так и негативной модели безопасности;

·  инспектирование всего содержимого веб-страниц, включая HTML, DHTML и CSS, а также нижележащих протоколов доставки содержимого (HTTP/HTTPS);

·  инспектирование сообщений веб-сервиса (SOAP, XML);

·  инспектирование любого протокола или конструкции данных, использующихся для передачи данных веб-приложения вне зависимости от того, является ли он проприетарным или стандартизованным (как для входящих, так и исходящих потоков данных);

·  защита от угроз, направленных непосредственно на экран веб-приложений;

·  поддержка SSL\TLS-терминации соединения;

·  предотвращение или обнаружение подделки идентификатора сессии;

·  автоматическое скачивание обновлений сигнатур атак и применение их;

·  возможность установки режима отказоустойчивости;

·  поддержка устройством клиентских SSL-сертификатов;

·  поддержка аппаратного хранения ключей.

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

Более серьезно к формированию критериев для экранов веб-приложений сделал проект Web Application Firewall Evaluation Criteria (WAFEC), который поддерживался сразу двумя профильными организациями, это, Open Web Application Security Project (OWASP) и Web Application Security Consortium (WAFEC). Данный проект преследовал две основные цели, это помочь в общем понимании роли экрана веб-приложений в защите их, и предоставить инструмент для обоснованного выбора соответствующего продукта класса экран веб-приложений. Первая версия выпущенного документы появилась на свет в 2006 году и была широко распространена в области защиты веб-приложений. В 2013 году команда вновь собралась, для того, чтобы выпустить вторую версию документа, но до сих пор так и не получилось сформировать новые требования для экранов веб-приложений, в то время как критерии из первой версии документа успели устареть и во многом уже не отражают эффективность экранов веб-приложений, так как не учитывают новые угрозы, уязвимости и появившееся технологии защиты с 2006 года. Однако несмотря на эти проблемы, изданный документ WAFEC представляет собой хорошо организованный документ, с четкой и понятной структурой на основе которой можно продолжить трансформацию документа, убрать устаревшие критерии и добавить актуальные. Переработка критериев с учетом результатов исследования представленной в данной магистерской диссертации представлены в Приложении 1.

2.3.  Описание общих требований к экрану веб-приложений.

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

·  Imperva Web Application Firewall;

·  F5 Application Security Manager;

·  Positive Technologies Application Firewall.

Проанализировав основные лидирующие продукты на мировом рынке, можно сформировать список защитных механизмов, которые обычно присущи WAF:

·  проверка протокола;

·  машинное обучение эталонной модели;

·  сигнатурный анализ;

·  специализированные механизмы;

·  пользовательские правила выявления нелегитимных запросов;

·  защита от атак типа «Отказ в обслуживании»;

·  интеграция со сторонними решениями.

1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 

9. 

10. 

11. 

12. 

13. 

14. 

15. 

16. 

17. 

18. 

19. 

20. 

21. 

22. 

23. 

24. 

25. 

26. 

27. 

28. 

29. 

30. 

31. 

32. 

33. 

34. 

35. 

36. 

37. 

38. 

39. 

40. 

41. 

42. 

43. 

44. 

45. 

46. 

47. 

48. 

49. 

50. 

51. 

52. 

53. 

54. 

55. 

56. 

57. 

58. 

59. 

60. 

61. 

62. 

63. 

64. 

65. 

66. 

67. 

68. 

69. 

70. 

71. 

72. 

73. 

74. 

75. 

2.3.1  Проверка протокола.

Проверка протокола — это базовый механизм пассивной защиты от потенциальных атак, которые производятся с использованием нетипичного применения возможностей HTTP. Его цель состоит в том, чтобы оставить злоумышленникам как можно меньше места для маневра, ограничив запрос специальными проверками. В первую очередь это проверка HTTP-заголовков на соответствие RFC, однако этого недостаточно, и производители идут дальше, используя ограничения по «лучшим практикам» и собственным правилам, сформулированным в процессе анализа возможных уязвимостей. Обычно применяются следующие ограничения:

·  требования RFC;

·  длина и количество заголовков, параметров;

·  временные рамки;

·  проверка JSON, XML сущностей;

·  отсутствие недопустимых значений.

2.3.2  Машинное обучение.

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

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

Примеры описывающие характеристики машинного обучения приведены в таблице 4.

Таблица 4 – Характеристики машинного обучения.

Характеристика машинного обучения	Примеры
Данные на входе алгоритма обучения	Помимо идентификаторов доступа из запроса пользователя, различные реализации позволяют вносить дополнительные сведения, которые повышают эффективность обучения. Например, могут учитываться следующие данные: ·  запросы от доверенных узлов (зона тестирования); ·  тип параметра: dynamic, static, hidden, read-only; ·  ответы веб-приложения.
	Продолжение Таблицы 4.
Характеристика машинного обучения	Примеры
Алгоритм обучения	Сердце машинного обучения, математический аппарат, нацеленный на обнаружение аномалий в самом глубоком понимании прикладного обеспечения. Например, ·  метод опорных векторов (Support Vector Machine); ·  случайный лес (Random forest); ·  нейронные сети (Neural Networks); ·  скрытая модель Маркова (Hidden Markov Model).
Способ принятия решения	Во избежание рекурсивного обучения в машинном обучении должны применяться понятные критерии готовности элемента к внесению его в эталонную модель. Например, это могут быть следующие критерии: ·  время обучения; ·  количество запросов, содержащих обучаемый элемент; ·  пороги энтропии элемента.
Техника оптимизации модели	В ходе цикла разработки защищаемое веб-приложение постоянно меняет свою модель поведения. Несоответствие выученной эталонной модели с реальной приводит к блокировке клиентских запросов. Для того чтобы этого не случалось, каждый механизм машинного обучения снабжается техникой по оптимизации эталонной модели. Могут использоваться следующие техники: ·  интерфейс ручной корректировки модели; ·  привлечение “учителя” для машинного обучения; ·  эвристический анализ запросов нарушающих текущую модель, с последующей её оптимизацией.
Возможности настройки	Машинное обучение — это сложный совокупный процесс, необходимость в конфигурировании которого может зависеть как от количественных показателей трафика, так и от качественных характеристик веб-приложения. Например, может возникнуть потребность в конфигурировании: ·  максимального времени обучения; ·  порогов срабатывания; ·  способа принятия решения; ·  математических параметров алгоритма обучения.
	Продолжение Таблицы 4.
Характеристика машинного обучения	Примеры
Формат эталонных моделей	Машинное обучение может быть разработано для построения модели: ·  позитивной; ·  негативной. Так же, в зависимости от обучения, модель может содержать различные объекты, в типичной реализации оптимально считается содержать: ·  идентификатор ресурса (URI/URL); ·  параметры прикладных сущностей (HTTP, XML/JSON entity); ·  идентификатор сессии (Cookie).

2.3.3  Сигнатурный анализ.

Сигнатурный анализ — одна из самых старых и востребованных технологий обеспечения защиты приложений. Связано это с тем, что атаки на веб-приложения в большинстве случаев производятся на основе уже известных уязвимостей с использованием готовых инструментальных средств. Причем интенсивность таких атак в открытом интернете настолько велика, что публичные веб-приложения подвергаются им практически ежеминутно. В теории механизм защиты, основанный на машинном обучении и составляющий эталонную модель, перекрывает необходимость использования сигнатурного анализа. Некоторые производители экранов веб-приложений в связи с этим отказываются от концепции наработок сигнатур. Однако есть ряд ситуаций, когда данный механизм защиты крайне полезен — например, в период обучения эталонной модели сигнатуры являются дополнительным рубежом защиты от эксплуатирования известных уязвимостей. Кроме того, запросы, которые были признаны нелегитимными, не подаются на вход процессу машинного обучения, что делает обучение более чистым. Экран веб-приложений должен обладать широкой и актуальной базой сигнатур для всех разновидностей веб-приложений. Более того, производителю желательно содержать собственный исследовательский центр, который будет агрегировать актуальные угрозы, чтобы своевременно формировать обновления.