Тестването не е достатъчно: необходимостта от RASP

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

Въпреки това, тестването на уязвимост, независимо дали е бяла кутия, черна кутия или сива кутия, има своите ограничения. В резултат на това средното уеб приложение в производствена употреба съдържа редица уязвимости, които излагат организацията и нейните клиенти на риск. Необходим е нов подход към управлението на уязвимостите, който увеличава тестването на уязвимостите при разработка със защита в реално време в производството, за да се защитят уеб приложенията срещу експлоатация.

Ограниченията на тестването за уязвимост

Сигурността на уебсайта е все по-приоритет за приложенията. Всъщност много организации говорят за преминаване от DevOps към DevSecOps практики. Решаваща част от този процес е интегрирането на тестовете за сигурност в практиките за разработка. На теория тази интеграция би намалила броя на уязвимостите в приложенията, които достигат до производство.

Въпреки тези усилия за добавяне на тестове към работните процеси на разработчиците, уязвимостите все още се изплъзват през пукнатините. Всъщност през 2019 г. средното уеб приложение в производството се използва съдържа 22 уязвимости.

Не всички от тези пропуснати уязвимости са причинени от неуспех да се вградят добри тестове за сигурност в процесите на развитие на организацията. Традиционните практики за сигурност на приложенията, включително тестване на бяла кутия, имат своите ограничения.

Софтуерна сложност

Един от най-големите приноси за пропуснатите уязвимости в уеб приложенията е сложността на кода на приложението. Средното уеб приложение включва приблизително 1,000 библиотеки и зависимости на трети страни. Тези зависимости представляват значителен риск за сигурността на приложението, тъй като то наследява уязвимостите на всички функции, които импортира от библиотеки на трети страни.

Това използване на код на трети страни се превръща в сериозен проблем, ако една организация разчита на тестване на бяла кутия за откриване на уязвимости. В много случаи тези тестове са фокусирани само върху кода, разработен вътрешно, а не върху външните библиотеки, от които кодът зависи. Уязвимост в код на трета страна може да е невидима за тестовия екип, но да остави приложението отворено за експлоатация.

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

Познания за разработчиците

Изострянето на предизвикателствата пред управлението на уязвимостите в уеб приложенията е фактът, че повечето разработчици не получават специализирано обучение по сигурността. Като цяло обучението за разработчици е фокусирано върху изучаването на езиците, платформите, процесите и инструментите, необходими за създаване на приложенията, които тяхната организация изисква, а не върху това как да защитят тези приложения.

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

Скорост на актуализации на кода

В миналото много организации използваха практики за разработка на наследен код. Процеси като Waterfall създават приложения като единна, монолитна програма. В резултат на това тези приложения имаха дълги срокове за разработка и рядко се актуализираха. Сега организациите възприемат съвременни процеси за разработка, като Agile, Scrum и DevOps. При тези процеси кодът е модулиран, което позволява по-бързото разработване и актуализиране на части. Някои организации, които са приели DevOps, създават нови издания ежедневно или дори по-бързо.

Тези бързи цикли на разработка налагат и ускоряване на темпото на тестване на сигурността. Ако една организация няма установени зрели практики на DevSecOps, със стабилно и автоматизирано тестване на сигурността на приложенията, може да е невъзможно да се извърши цялостно тестване на сигурността в рамките на тези ускорени цикли на издаване на софтуер. В повечето случаи, когато датите за сигурност и пускане са в конфликт, не е крайният срок за пускане, който екипът за разработчици жертва.

Управление на уязвимостите в производството

Въпреки най-добрите намерения, повечето организации не са готови да приемат практиките на DevSecOps. Тези практики изискват интегриране и автоматизиране на стабилно тестване на сигурността на приложенията в непрекъснатия работен процес за интеграция и тестване на екипа за разработка.

В резултат на това производственият код ще съдържа уязвимости. Опитът за управление на тези уязвимости чрез наследени практики, като ръчно създаване и прилагане на корекции, е нескачаем подход към сигурността. Организациите разчитат на непрекъснато нарастващ брой приложения – съдържащи нарастващи списъци със зависимости – което прави твърде лесно пренебрегването на критична уязвимост или актуализация.

Въпреки че опитът за коригиране на уязвимостите в разработката е важен, организациите трябва също да приемат и да се подготвят за факта, че производственият код ще съдържа експлоатируеми уязвимости. Самозащитата на приложенията по време на изпълнение (RASP) помага за справяне с тези проблеми чрез интегриране на мониторинг на сигурността в потенциално уязвимо приложение.

Ако входовете, изходите или поведението на приложението станат аномални, RASP решението може да предприеме действия, за да предупреди екипа по сигурността за потенциална атака или да я блокира напълно. Тази способност за извършване на „виртуално корекция“ на приложение въз основа на дълбоко вникване в неговата вътрешна работа му позволява да защити приложение срещу експлоатация на пропуснатите по време на тестването уязвимости.