Сканиране за уязвимости или тест за проникване

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

Какво всъщност прави сканирането за уязвимости

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

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

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

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

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

Така че сканирането отговаря добре на конкретен и важен въпрос: къде носим слабости, които вече са документирани и които инструмент може да разпознае? Третирането на сканирането като по-нисша дейност е грешка. То е хигиенният слой, а провалите в хигиената са това, с което живеят масовите нападатели.

Скенерът сравнява наблюдаваното с известни модели. Това ограничава откриването на проблеми, специфични за вашата бизнес логика, и на вериги от слабости. Част от резултатите се основават на косвени признаци, например банер с версия, без да е доказано, че уязвимият код е достижим в конкретното внедряване. Затова са възможни както погрешно отчетени уязвимости, така и пропуснати проблеми. Ръчната проверка добавя контекста и доказателствата.

Какво всъщност прави тестът за проникване

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

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

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

Навързване. Подробна страница с грешка, слабост при изброяване на потребители и слаба политика за пароли са всяка поединично с ниска критичност. Заедно те са завладяване на акаунт. Резултатът на тестера е доказан път от отправна позиция до последствие, и точно това можете да отнесете до борда, защото описва резултат, а не състояние.

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

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

Едно до друго

Измерение	Сканиране за уязвимости	Тест за проникване
Цел	Намиране и проследяване на известни, откриваеми от инструмент слабости в цялата среда	Установяване какво би могъл в действителност да постигне нападател срещу определен обхват
Обхват	Широк и плитък — всичко, към което можете да го насочите	Тесен и дълбок — системите, които имат най-голямо значение, разбрани както трябва
Дълбочина	Проверява състояния поединично спрямо база данни с подписи и конфигурации	Разсъждава за намерението, навързва констатации, преследва последствия
Кой го изпълнява	Собственият ви екип, непрекъснато; предимно без надзор, щом бъде конфигуриран	Опитни тестери, с ръце на клавиатурата, за договорен период
Какво получавате	Подреден списък от състояния с версии, местоположения и съвети за отстраняване; данни за тенденциите във времето	Доказани пътища на атака, потвърдена критичност във вашия контекст и обосновката зад всяка
Честота	Непрекъснато или поне седмично; в процеса за изграждане, където е възможно	Периодично и при значима промяна в система или в модела ѝ на сигурност
Кога да се използва	Винаги, като постоянна хигиена и като проверка при издаване	Преди пускане, след промяна в архитектурата, когато се изисква увереност, когато последствието от компрометиране е съществено
Какво усилие ви струва	Настройка, осигуряване на данни за достъп, донастройване и постоянната дисциплина изходът да бъде триажиран, а не игнориран	Определяне на обхват, работещи акаунти за всяка роля, среда с данни, достъпно техническо лице за контакт и капацитет да бъде поправено това, което се върне
Фалшиви положителни	Очаквани, често многобройни; триажът е ваша работа	Премахнати преди предаването; констатациите пристигат с доказателство
Какво не ви казва	Дали нещо намерено е използваемо във вашето внедряване; каквото и да е за оторизацията, бизнес логиката, навързаните пътища или слабостите, уникални за вашия код	Състоянието на средата извън обхвата; състоянието на каквото и да е следващата седмица; дали защитниците ви биха забелязали

Кое от двете всъщност ви трябва

За почти всяка организация отговорът е и двете, но не по едно и също време и не в еднакво количество. Ако избирате какво да направите следващо, поводите са конкретни.

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

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

Ако можете да направите само едно нещо това тримесечие и изобщо нямате сканиране, сканирайте: еднообразното покритие на известните проблеми е по-голямо незабавно намаляване на риска от дълбокото покритие на едно приложение — и е по-евтино. Ако имате сканиране, което никой не чете, поправете това, преди да купите каквото и да е — непрочетена констатация и неоткрита такава носят еднакъв риск.

Грешката, която купувачите правят

Скъпата грешка е да купите сканиране с вярата, че купувате тест. Тя е лесна за правене, защото пазарът не използва думите последователно: едно предложение може да казва „тест за проникване“, да достави подреден експорт от скенер и да е точно по собственото си вътрешно определение. После държите документ, който казва, че сте били тествани, и набор от рискове, които никой не е разгледал.

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

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

Как двете работят заедно през една година

Поставени едно срещу друго, те изглеждат като конкурентни покупки. Проведени както трябва, те са два слоя на една програма, всеки от които прави другия по-полезен.

Сканирането е непрекъснатият слой: седмично или по-често срещу външната среда, с удостоверяване срещу вътрешната, непрекъснато срещу облачната конфигурация и в процеса за изграждане срещу зависимостите и образите. Целта му в действителност не е да намира неща — тя е да поддържа базовото ниво на сигурност, така че нищо тривиално известно да не стои в продукционната среда, и да произвежда показателя, който показва дали отстраняването се случва. Третирайте неразрешените критични констатации, по-стари от собствената ви цел, като провал на процеса, а не като точка в списък със задачи.

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

Споделяйте резултатите от сканиране и предишните доказателства с тестера и записвайте валидирани, ограничени, невъзпроизведени и непроверени случаи. Изводите зависят от build версията и условията и могат да изискват преглед след промяна. Превръщайте подходящите находки в повторяеми проверки и запазете човешката работа за пътища без надеждно автоматично покритие.

Една ефективна годишна програма изглежда приблизително така: сканиране, което върви през цялото време, с констатации, които действително се затварят; един или два теста, поставени там, където последствието е най-голямо или промяната е била най-голяма; тези констатации са поправени и после тествани повторно, за да знаете, че поправката е влязла в сила; а уроците, които могат да се автоматизират, са върнати обратно в сканирането. Там, където откриването и реакцията са самият въпрос, това е трета дейност, а не по-дълбок тест — red teaming отговаря дали бихте забелязали, което нито едно от тези две не прави.

Полезният модел е, че сканирането ви казва за вашето състояние, а тестът — за вашите последствия. Състоянието е евтино за измерване, затова го измервайте постоянно. Последствието изисква някой да мисли, затова купувайте това умишлено, насочвайте го натам, където има значение, и се уверете, че лесните констатации са свършили първо.