Исторически сложилось так, что за доступность внутренних приложений в крупных компаниях отвечают разработчики и службы ИТ, а за конфиденциальность и целостность – службы информационной безопасности. «Повисшее» приложение – не проблема «безопасников», поэтому в критерии их деятельность исследовать возможность «уронить» приложение не входит.
С появлением веб-приложений и атак типа DoS/DDoS ситуация изменилась, и обеспечение доступности снова вернулось в зону ответственность информационной безопасности. Однако в массе своей, информационная безопасность рассматривает такую ответственность как обеспечение «навесной» безопасности путём покупки анти-DDoS в виде сервиса и/или продукта. Ни в архитектуру приложения, ни в оптимизацию его интерфейса информационная безопасность не лезет, оставляя себе и подрядчикам анализ входящего траффика.
Однако один нерадивый программист или архитектор может ненамеренно нанести приложению, а значит – и компании, ущерб, который не сможет нанести даже армия наёмных хакеров. Неправильно построенный запрос, неверно выставленный таймаут, плохо проработанный API к другим проприетарным приложениям, неоптимально организованная очередь и другие огрехи проектирования и кодирования могут «положить» приложение не хуже массированной DDoS-атаки. При наличии в коде приложения логической бомбы можно устроить DoS-атаку одним запросом.
Когда задаёшься вопросом – кто отвечает за поиск таких программных конструкций при тестировании и приёмке, и разработка, и служба информационной безопасности кивают друг на друга. Безопасники традиционно отвечают за «традиционные уязвимости» – инъекции, кросс-скриптинг, зашитые в коде пароли и другие понятные им нарушения. Для того, чтобы понять, какой запрос правильный, а какой – нет, надо понимать, что запрос «делает», то есть – разобраться в том, как приложение работает. Разработчики же тестируют в основном нагрузку и функционал, исследовать код на такие нарушения – не их работа. Можно было бы пригласить исследовательскую лабораторию, но беда в том, что в бизнес-приложениях код меняется быстрее, чем работают лаборатории: в среднем, веб-приложение обновляется раз в неделю, хотя есть и такие, которые обновляются ежедневно и даже чаще. Лаборатория же исследует продукты не меньше месяца, поэтому вы всегда будете иметь отчет о качестве поза-поза-прошлой сборки.
Что делать? Единственный способ – встраивать процесс контроля опасных программных конструкций в процесс разработки и приёмки. Но прежде всего – решить, кто отвечает за эту, пока «серую» область защиты приложений.
