Избор на подходящата защитна стена за уеб приложения
Предприятиятa/организациите, втурнали се да отговорят на изискванията за съвместимост с PCI (Payment Card Industry) нормите, могат се окажат в сериозно затруднение, когато започнат да избират защитна стена за уеб приложенията си (Web Application Firewall - WAF). Знаете ли какво да търсите? Как да внедрите и управлявате ефективно устройството или софтуера? Как ще го адаптирате към вашата съществуваща инфраструктура? Ние ще подчертаем ключовите съображения по време на оценяването на продуктите така, че вашата компания да е в съответствие с нормите. Защитната стена за уеб приложения или защитна стена на приложен слой е устройство или софтуер, разработени, за да защитят уеб приложенията срещу атаки и „изтичане„ на информация. Стената е разположена между уеб клиента и уеб сървъра и анализира съобщенията на приложното ниво за наличие на нарушения в програмираната политика за сигурност. Защитните стени за уеб приложения се ползват за решаване на проблеми на сигурността, различни от тези на мрежовите защитни стени и системите за разкриване/предотвратяване (IDS/IPS) на проникване, които са разработени да защитят мрежовия периметър. Но преди да се хвърлите да купувате, ще трябва да разучите устройството, поставено пред вашите приложни сървъри.
Какво трябва да знаете
Всеки път, когато влезе в сила нова законодателна рамка или нови изисквания за сигурност, онези, които отговарят за съответствието, често са склонни да се втурнат в процеса на вземане на решения. Много системни администратори базират своето решение върху търговската реклама на един производител или на специфична потребност или функция, на която вече са попаднали.
Резултатът, повече или по-малко, няма да отговаря или ще бъде с по-ниска от оптималната сигурност. Дори и кратките срокове не ви освобождават от старателен подход при избора. За да изберете защитен механизъм, такъв, какъвто е защитната стена за уеб приложения, трябва да си отговорите на следните въпроси:
• Какви функции трябва да има тя въз основа на целите на политиката за сигурност и законовите изисквания?
• Кои допълнителни услуги ще бъдат много ценни?
• Как ще разположите защитната стена във вашата съществуваща мрежа - имате ли вътрешнофирмени умения да я ползвате коректно и ефективно?
• Какво влияние ще окаже тя върху съществуващите услуги и потребители и на каква цена?
Новите изисквания за съответствие, като PCI стандартите за сигурност на данни (Payment Card Industry Data Security Standard - PCI DSS), изискват от вас да актуализирате или поне да ревизирате политиката си за сигурност, преди да можете да си отговорите на първия въпрос. Добрата политика за сигурност дефинира вашите цели и изисквания за защита на данните. Тази основа ви позволява да дефинирате какви механизми за защита са подходящи, за да отговорят на вашите изисквания. Тъй като всяко уеб приложение е уникално, сигурността трябва да бъде настроена спрямо клиента, така че да го защитава срещу идентифицираните потенциални заплахи, определени по време на фазата на моделиране на заплахите при разработването на вашата програма за жизнения цикъл на сигурността. Прегледайте срещу кои от тези заплахи ви предпазва защитната стена, която обсъждате – например анализира параметрите, пускани чрез „бисквитки“ или URL-и и предоставя защита срещу всички топ десет уязвимости на приложенията, според OWASP (Open Web Application Security Project), както и всички задължителни за съответствието допълнителни изисквания.
Избoр на защитна стена за уеб приложения
За да гарантирате, че защитната стена отговаря на намеренията за съответствие с PCI DSS, трябва да сравните нейните възможности с тези, препоръчани в документа „Допълнителна информация: изискване 6.6. Разяснения относно прегледите на кода и защитните стени за приложения„ (Хипервръзка: https://www.pcisecuritystandards.org/pdfs/infosupp_ 6_6_applicationfirewalls_codereviews.pdf), издаден от Съвета за PCI стандарти за сигурност.
Функциите на защитната стена трябва да са в състояние да инспектират и управляват съдържание на уеб страницата, като HTML, Dynamic HTML (DHTML) и CSS (cascading style sheets), както и протоколите, които вашите приложения ползват, като HTTP и HTTPS.
Проверете също така колко бързо производителят е внедрявал новите протоколи в миналото. Запознайте се с неговата политика за разработки и поддръжка, за да определите дали той поддържа специфичните протоколи на клиента или защитава определен набор от протоколи за приложения. В допълнение защитната стена трябва да може да преглежда съобщенията на уеб услугите - обикновено това са SOAP и XML. Попитайте производителя на защитната стена за уеб приложения за неговите процеси за автоматично актуализиране и прилагането на динамични сигнатури. Подобни разговори ще випомогнат да оцените неговите (на производителя) услуги за помощ и техническа поддръжка. Накрая попитайте за евентуални допълнителни разходи за специфични функции. Например някои приложения може да изискват поддръжка на хардуерно хранилище за ключовете, което отговаря на изискванията и нормите на FIPS. Производителят на защитната стена за уеб приложения може да поддържа това изискване, но на драматично по- висока цена.
Докато подготвяте списъка с изискванията, отделете време да разберете техническите подходи и дълбочината на третиране, която всяка защитна стена ползва, за да покрие една или повече области на сигурността. Можете ли да създадете „бял„ списък с типовете данни и обхвати и да създадете правила, като комбинирате „белите„ и „черните„ списъци? Колко силна е защитната стена срещу атаки, насочени срещу самата нея? Например тя трябва да се стартира под управлението на подсилена операционна система, вероятно с компоненти, работещи в непривилегирована и затворена работна среда. Ако сигурността на продукта не е солидна като камък, вероятно ще трябва да приключите дискусиите в именно този момент.
Софтуер срещу хардуер
Документът PCI „Допълнителна информация„ определя, че защитната стена за уеб приложения може да бъде реализирана чрез софтуер, работещна стандартен сървър с широко разпространена операционна система, или върху хардуерно устройство. То може да бъде единично, отделно устройство или да е интегрирано в другите мрежови компоненти. По този начин можете да избирате от голям набор защитни стени за уеб приложения, които се предлагат на пазара.
Софтуерните защитни стени обикновено са по- евтини и много гъвкави. Хардуерните устройства по принцип са по-лесни за инсталиране и конфигуриране, отчасти защото тяхната операционна система вече е с подсилена защита, докато със софтуерната защитна стена ще трябва допълнително да я укрепвате. (Защитната стена за уеб приложения не може да ви защити срещу некачествени конфигурации или уязвимости във вашите сървъри.)
Ако се спрете на софтуерно базиран продукт - изберете такъв, който работи на платформа, която е позната на специалистите от вашия ИТ отдел. В обратния случай проверете какво обучение и поддръжка се предлагат от производителя на защитната стена и колко струват те.
Има, разбира се, защитни стени за уеб приложения, базирани на софтуер с отворен код, катонапример ModSecurity (http://modsecurity.org) и AQTRONIX WebKnight (http://www.aqtronix.com). Ако те отговарят на вашите изисквания, ще можете значително да намалите своите разходи, но ще е необходимо да се обучи персоналът да инсталира, конфигурира и обслужва защитната стена. Много проекти с отворен код имат изключителни форуми за поддръжка, но за разлика от закупения продукт няма да бъдете в състояние да се обадите на службата за помощ в критична ситуация.
Производителността и мащабируемостта са други важни съображения, когато се оценяват възможностите на хардуера или софтуера. Някои устройства може да са ограничени по отношение на броя транзакции за час, които могат да обработят. Други може да имат ограничения в широчината на честотната лента. Ще трябва да изберете мащабируема и гъвкава защитна стена, ако смятате да увеличите уеб дейностите си или да добавяте нови приложения в близко бъдеще.
Софтуерните продукти често предлагат по-лесен път за актуализация, отколкото устройствата, но хардуерните защитни стени за приложения са по- подходящи за сайтове с високо натоварване, които изискват висока пропускателна способност.
Ако имате голямо приложение, което изисква повече от една защитна стена, тогава централизираният мениджмънт може да се окаже критична функция, за да може политиките на защитната стена да се въвеждат и управляват от едно място.
Нашият съвет е да не фиксирате избора дали защитната стена да бъде софтуерна или хардуерна, докато не разберете дали тя отговаря на вашите цели и дали имате вътрешнофирмени умения да я конфигурирате и управлявате.
Помощта е налице
Планирайте да отделите повече време за пълното оценяване на продуктите за защитни стени за уеб приложения. След като веднъж ограничите избора си до тези, които покриват вашите базови изисквания, как ще сравните различните възможности?
Консорциумът за сигурност на уеб приложения (Web Application Security Consortium – WASC, хипервръзка: http://www.webappsec.org/) създава и препоръчва стандарти за сигурност на уеб приложения. Той е разработил критерии за оценка на защитна стена за уеб приложения (Web Application Firewall Evaluation Criteria WAFEC хипервръзка: http://www.webappsec.org/projects/wafec/) за сравнителни анализи. Тяхната методология на тестване може да бъде ползвана от всеки сравнително умел техник за независимо оценяване на качеството на решението за защитна стена.
Ползвайте техните критерии като част от вашия процес по оценяване. Следвайте препоръките на Консорциума за сигурност на уеб приложения, за да обърнете специално внимание на внедряванетона ползваната архитектура, поддръжката за HTTP, HTML и XML, използваните техники за откриване и защита, възможностите за записване на лог файлове и отчетност, управление и производителност.
Внедряване на защитната стена за уеб приложения
Поздравления. Вие избрахте, закупихте и инсталирахте защитната стена за уеб приложения с необходимите възможности за съответствие. Но това не означава, че сте съвместими. Правилното позициониране, конфигуриране, администриране и мониторинг са от изключителна важност.
Инсталацията трябва да следва четири стъпки на жизнения цикъл на сигурността: защита, наблюдение, тестване и усъвършенстване. Това е непрекъснат процес, който се връща отново към себе си в непрекъснат цикъл на защита. Преди което и да е устройство да бъде свързано към вашата мрежа, трябва да гарантирате, че сте документирали мрежовата инфраструктура и сте подсилили хардуера, където то работи. Това означава да се приложат софтуерни патчове,както и да се отдели време за конфигуриране на устройството за увеличена сигурност.
Конфигурирането ще произлезе директно от бизнес правилата, които сте установили в политиката си по сигурност (например позволени набори от знаци). Ако подходите към конфигурирането на защитната стена по този начин, правилата и филтрите ще се самодефинират. Защитните стени за уеб приложения могат да покажат технически проблеми в дадена мрежа или приложение като фалшиво положително сигнализиране за нападение или задръствания от трафик.
Внимателното тестване е от изключителна важност, по-специално ако вашият сайт позволява ползването на ненужни хедъри, URL-и или бисквитки, или специфично съдържание, което не може да покрие уеб стандартите. Ако сте стартирали многоезикова версия на приложението, трябва да се предвиди време за допълнително тестване, тъй като може да се окаже, че трябва да се поддържат различни кодови таблици.
Тестовете трябва да наподобяват „живо„ приложно обкръжение дотолкова, доколкото е възможно. Това ще постави всички въпроси по системната интеграция, които защитната стена за уеб приложения може да предизвика, преди внедряването. Тествайте стресово защитната стена,ползвайки инструментите с тестове Microsoft Web Application Stress and Capacity Analysis Tools или AppPerfect Load Tester. Това също ще спомогне за откриване на всякакви задръствания, предизвикани от разполагането на защитната стена за уеб приложения.
Управление на защитна стена за уеб приложения
След като веднъж сте инсталирали и стартирали защитната стена, оценете дали някои бъдещи промени в защитната стена могат да въздействат върху вашите уеб приложения, и обратното. Вие, разбира се, трябва да документирате надлежно промените, които правите в мрежовата си инфраструктура, за бъдещи справки и решаване на потенциални проблеми при експлоатацията. Това включва проследяване на всички промени в нейната конфигурация, понастоящем и в бъдеще.
Промените в производственото обкръжение трябва винаги да се реализират, като се наблюдава прозорецът за поддръжка. Вие трябва да сте сигурни, че всички засегнати страни в организацията са предварително уведомени за времето и обхвата на предстоящите промени. За да гарантирате, че конфигурациите не са променени случайно или без да се прилага съответният процес, трябва да контролирате физическия, както и логическия достъп до устройствата за сигурност. Стриктното следване на политиките за контрол на промените, непрекъсваемостта на бизнеса и политиките за възстановяване след бедствия и аварии ще изиграе съществена роля в сигурността на защитната стена за уеб приложения и защитата на вашия бизнес.
Понеже защитните стени на ниво приложение изследват по-скоро цялостния мрежов трафик, отколкото само адресите и портовете, те имат много по-разширени потенциални възможности за записване на логове и могат да записват специфични приложни команди. Дотук добре, но не позволявайте на този потенциал и информация да се прахосват. Анализите на лог файловете могат да ви предупредят за предстоящи или текущи атаки. Трябва да сте сигурни, че сте дефинирали каква информация желаете да бъде записвана от защитната стена в лог файловете – за предпочитане е това да са пълните данни за заявките и отговорите, включително съдържанието на заглавните части и тялото на съобщенията. Проверете дали вашият персонал има достатъчно опит и адекватно време, за да преглежда и анализира лог файловете.
Уеб приложенията никога няма да бъдат защитени на 100 процента. Дори да не е налице вътрешен натиск за по-бързото внедряване на уеб приложения, винаги ще има уязвимости, които са отворени за заплахите. Когато сте инсталирали и експлоатирате защитна стена за уеб приложенията като част от многослоен защитен модел, можете да следите, непрекъснато да наблюдавате и да търсите следи от проникване. Защитната стена може също така да спомогне до откриете разликата от бързането да отстраните дадена уязвимост и наличието на време и място да решите проблема с уязвимостта според вашето разписание.
Стъпка по стъпка:
Да изберем защитна стена за уеб приложенията си
Следвайте тези основни стъпки при подбора на подходяща защитна стена за уеб приложенията:
1Използвайте поставените в политиката за сигурност цели, за да дефинирате какви контроли трябва да има защитната ви стена за уеб приложения.
2 Разгледайте видовете рискове, които покрива всеки един продукт.
3 Тествайте работоспособността и мащабируемостта на продукта.
4 Оценете техническата поддръжка, предлагана от производителя.
5 Преценете дали притежавате изискваните вътрешно-фирмени умения да я обслужвате и управлявате. Балансирайте сигурността, пропускателната способност и общите разходи. – Майкъл Коб
Какво следва?
Защитната стена за уеб приложения е само началото
ЗА ДА СЕ ПРЕБОРИ с постоянно нарастващата сложност на атаките срещу приложенията, защитата, предлагана от стената, трябва да бъде интегрирана в платформите за сигурност на приложенията. Тази структура, поддържана от производители като F5 и Barracuda, комбинира защитната стена, защитата на данните, XML гейтуеите за сигурност и управлението на приложния трафик, за да предостави по-цялостно покритие на сигурността.
Сред предимствата й е възможността за сравнение на информацията от всички тези устройства, за да се определи прецизно дали трафикът е потенциално злонамерен. Това прави трафик контрола, анализа и отчетността много по-ефективни. Администраторите могат да конфигурират един-единствен набор от правила на политиката и параметри, вместо да налагат всяка политика на няколко различни устройства, което значително намалява административното натоварване. Поглеждайки в бъдещето, е изключително важно защитните стени за приложения или каквото и да друго на тяхно място, да дават възможност за интерпретиране на данните по същия начин, както приложението, което те защитават. Това ще доведе след себе си до някаква форма на скрипт машина, за да се премахне всяко объркване, така че защитният механизъм да види заявката в същата форма, в която ще я види браузърът. Това ще улесни много оценката дали кодът е злонамерен или не. Да се надяваме, че ще видим такава форма на динамичен анализ в следващото поколение защитни устройства. – Майкъл Коб
За незапознати: PCI DSS
Какво трябва да знаете за PCI DSS?
Стандартът за сигурност на данните на индустрията за платежни карти (THE PAYMENT CARD INDUSTRY Data Security Standard, PCI DSS) е разработен от Съвета за PCI стандарти за сигурност под формата на отворен форум през 2006 г. Съветът е част от PCI, индустриална организация, създадена от големите компании за кредитни карти, и е отговорен за постоянните разработки, управление, обучение и осъзнаване на PCI DSS.
Обаче Съветът за PCI стандарти не налага в практиката стандарта, нито определя глоби за всяко нарушение. Прилагането в практиката е оставено на отделните кредитни компании. PCI DSS не заменя индивидуалните програми за съответствие на компаниите за кредитни карти, но в него са включени технически изисквания за съответствие на сигурността на данните. Всички търговци, които приемат кредитни или дебитни карти, издадени от големите компании за кредитни карти, трябва да отговарят на стандарта.
Според стандарта PCI DSS организацията трябва да е в състояние да гарантира на нейните клиенти, че данните от техните кредитни карти, информацията за сметките и транзакциите им е опазена от хакери или каквото и да било злонамерено проникване в системата чрез прилагане на разнообразни специфични мерки за гарантиране защитата на данните. Те включват изграждане и експлоатация на защитена ИТ мрежа, защита на данните на картодържателя, поддържане на програма за управление на уязвимостите и политики за сигурност на информацията.
Съответствието със стандарта се определя на четири нива и нивото на съответствие, изисквано от търговеца, се базира на годишния размер на транзакциите с платежни карти, които той е обработил. Ниво 1 – най- високото ниво, може също така да бъде наложено за транзакции, които са били атакувани или по друг начин са подложени на висок риск. Единичното нарушение на всяко от изискванията може да предизвика общ статус на несъответствие и да има за резултат налагане на глоби и възможно спиране или отнемане на при- вилегиите за обработка на карти, докато търговецът покрие изискванията за PCI съвместимост.
За повече детайли посетете сайта PCI Security Standards Council – Майкъл Коб