Живееме во конкурентен свет каде многу технологии еволуираат брзо и нудат моќни и робусни компоненти кои се едноставни за користење во ИТ заедницата. Како што технологиите еволуираат, постоечките системи мигрираат кон системи со поголема стабилност и ефективност и на тој начин многу денешни компании целосно се фокусираат кон изработување на скалабилен, портабилен и робустен софтвер кој за корисникот изгледа убаво и е интуитивен, а воедно и добро си ја врши својата функција, но најчесто безбедноста на овие апликации се става на второ место, и тоа е така заради неколку клучни аргументи:
- Ретки се експертите кои навистина разбираат како да го заштитат системот од повеќе аспекти
- Ретки се клиентите кои навистина разбираат зошто вреди да се вложи во безбедноста
- Повеќето корисници не се навлезени во таа област и “слепо” им веруваат на апликациите
- Имплементирањето на безбедност може да кошта многу пари, труд и да одзема дополнително време
- Не постои детален а лесен начин за автоматизирање на тестирање на безбедноста
- Технологиите еволуираат, па експертите треба да бидат во тек за да ги заштитат
- Дури и да постои начин на тестирање, слабостите треба да се поправат во најкраток можен рок.
- Безбедноста од повеќе аспекти е одговорност на целите тимови а не само на експертот.
Проблем со кој компаниите се соочуваат:
Без разлика дали компанијата изработува свој продукт, или работи на постоечки компонент и го подобрува, заради честите кратки рокови за доставување на барањата, се докажало дека квалитетот на имплементираните барања се намалува ретроспективно затоа што не му се остава доволно време на тестерите кои исто така го користат своето ограничено време на пишување тестови кои ги проверуваат поглавните сценарија а воедно немаат време за да се фокусираат на поголемата слика и да напишат сценарија кои се помалку веројатни да се случат, па со тоа сите доставуваат продукт со помал квалитет.
Продуктот иако функционира беспрекорно за корисникот, сѐ уште може да ги содржи аномалиите, но повеќето корисници го користат системот по очекуваните сценарија и затоа не го кршат, додека апликацијата е сѐ уште изложена кон светот за оние кои разбираат како да ја скршат и да ги злоупотребат слабостите кои не се покриени од безбедносен карактер.
Цената на еден breach може да се исплати со големи финансиски суми но што е пострашно, и со довербата на корисниците кои го користат тој систем.
Експертите за апликациска безбедност најчесто ги предлагаат овие решенија:
- Да се оддели време, буџет, експертиза за самостојно тестирање на безбедноста (Најскапо на кратки периоди, најисплатливо на долги периоди).
- Да се користат најновите компоненти од добро-поддржани frameworks и stacks кои ќе го минимизираат ризикот (некои од овие технологии имаат вградена заштита до некое ниво).
- Да се плати за надворешен етички пентест на секој release, со тоа што друга компанија го тестира вашиот систем и ви доставува документ со сите аномалии кои на крајот ќе треба да се поправат.
Иако сите од наведените опции се валидни, некогаш клиентот ги нема потребните време, буџет или експерти кои можат да го направат ова безбедносно тестирање, па затоа бараат некое половично решение:
Multi-layered security testing (Економичен и разумен trade-off помеѓу ресурсите што ги има клиентот во време, буџет и експертиза и помеѓу ефективното тестирање на безбедност на повеќе нивоа во апликацијата / системот).
Овој релативно нов и хибриден начин на тестирање безбедност не е идеален но значително го крева квалитетот на безбедносното ниво а воедно и заштедува на многу време, буџет и ресурси затоа што најголемиот дел од овој вид тестирање се случува автоматски. Мулти-слојното безбедносно тестирање на апликации најчесто е најефективно во микросервисни архитектури, но често пати се употребува и во позастарени системи.
Овој начин на тестирање се состои од следниов процес:
- Се припрема околина каде системот би се тестирал и многу е важно околината да изгледа што повеќе како продукциски сетап.
- Се извршуваат сите позитивни тестови на back-end или front-end (ова се нарекува baseline) и се редиректираат на договорен порт.
- Се пресретнуваат сите request / response од тестовите на договорениот порт со proxy за понатамошно безбедносно евалуирање.
- Се ре-извршуваат позитивните тестови со предефинирани измени на request-ите кои ќе се обидат да го скршат системот на повеќе нивоа и се архивира нивниот ефект во апликацијата.
- Кога тестовите се извршат целосно, експертот за безбедност ги разгледува резултатите и документира на што треба да се обрне најмногу внимание и ги консултира тимовите како да се заштитат од овој вид на аномалија.
Позитивни тестови – – – – – – > Proxy кое ги пресретнува request-ите – – – – – – > Таргетирана апликација
Резултати од евалуацијата < – – – – – – Proxy кое ги пренесува response-ите < – – – – – – Таргетирана апликација
Мулти-слојното тестирање на безбедност е релативно нов концепт кој се употребува најчесто во странски проекти, и најчесто е базирано на OWASP Top 10 стандардот кој се грижи да обезбеди безбедносно тестирање на следните аспекти:
A1:2017-Injection
A2:2017-Broken Authentication
A3:2017-Sensitive Data Exposure
A4:2017-XML External Entities (XXE)
A5:2017-Broken Access Control
A6:2017-Security Misconfiguration
A7:2017-Cross-Site Scripting (XSS)
A8:2017-Insecure Deserialization
A9:2017-Using Components with Known Vulnerabilities
A10:2017-Insufficient Logging&Monitoring
Во зависност од алатката која ќе ги извршува овие автоматизирани евалуации, зависи и квалитетот на резултатите. Секако, на крајот најдобро е експертот да потврди кои од пронајдените слабости се валидни, и на тој начин да се крене свесноста за состојбата на системот, а воедно и да се заштеди голема количина на време.
Најчесто поставувани прашања:
- Зошто извршуваме позитивни тестови првично? – Затоа што секое позитивно сценарио стига до секоја функционалност на системот. На тој начин се осигуриме дека ја покриваме максималната површина за евалуирање на системот.
- Што постигнуваме со пресретнувањето на сообраќајот на прокси ниво? – Постигнуваме ефект на задржување на реквестот и моќта да го измениме додека е сѐ уште валиден.
- Што всушност прави Engine-от за безбедносна евалуација? – Во целост тој ги реизвршува пресретнатите тестови со измени кои ги претвораат тестовите во негативни тестови кои се обидуваат да го скршат системот и доколку успеат тоа ќе се забележи во response-от што ќе се врати назад.
- Која е функцијата на експертот? – Тој може да одлучи дали најдените слабости во контекстот се реални заради што постојат ситуации каде системите иако се однесуваат на неочекуван начин, не се кршат или не откриваат никаква слабост.
- Дали ова тестирање е етичко? – Пред било какво тестирање е добро да се потврди со клиентот и доколку е можно да се набави писмена лиценца или договор во кој вие изјавувате дека вашите тестови имаат етички цели и дека клиентот се согласува со овој тип на тестирање. Оваа статија има за цел само да го презентира начинот на тестирање а не и самата имплементација заради безбедносни причини.
Стани премиум член и доби пристап до сите содржини, специјален попуст на над 2.200 производи во ИТ маркет, верификуван профил и можност за огласување на ИТ Огласник. Плус ќе го поддржиш медиумот кој го градиме цели 16 години!
Доколку веќе имаш премиум членство, најави се тука.
