Речник

Речник по офанзивна сигурност, на разбираем език

Понятията, които използваме при определяне на обхвата, в докладите и при повторните тестове, обяснени на разбираем език. Всяко определение има собствена връзка, която можете да споделите с колега.

Видове тестване

Тест за проникване (penetration test)

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

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

Red team

Симулация на реален нападател с конкретна цел, която проверява дали защитният екип открива атаката и реагира.

Red team упражнението преследва договорена цел, например достъп до платежна система или извличане на ограничена извадка от чувствителни данни. Екипът проучва възможните пътища в разрешения обхват и се стреми да избегне откриване. Записва кои действия са предизвикали сигнали и как е реагирал защитният екип. Обикновено само малка контролна група в организацията знае за упражнението. Резултатът показва както възможностите на нападателя, така и ефективността на откриването и реакцията.Още →

Purple team

Упражнение, в което нападателят и защитаващият екип работят открито заедно, за да подобрят откриването.

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

Оценка на уязвимостите (vulnerability assessment)

Широк, предимно автоматизиран обход, който открива и приоритизира известни слабости в цялата среда.

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

Тестване за проникване, водено от заплахи

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

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

Предполагаем пробив (assumed breach)

Тест, който започва с допуснат вече получен достъп, например до обикновен потребителски акаунт или лаптоп.

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

Симулация на фишинг (phishing simulation)

Контролирана фишинг кампания, изпратена до собствените ви служители, за да измери кликванията и подаването на сигнали.

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

Тестване на сегментацията (segmentation testing)

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

Тестерът поставя хост в една зона и се опитва да достигне услуги в друга, като изброява какво действително преминава, а не какво твърди наборът от правила. Чести резултати са забравени управленски интерфейси, прекалено широки разрешаващи правила и споделена инфраструктура, която тихо свързва зони. PCI DSS изисква това на определени интервали за субекти, които използват сегментация, за да намалят обхвата на средата си с данни на картодържатели, защото нарушена граница връща съседната зона обратно в обхвата.Още →

Повторен тест (retest)

Повторна проверка, която установява дали корекциите са отстранили първоначално откритите проблеми.

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

Тестване за проникване като услуга (PTaaS)

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

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

Техники за атака

Kerberoasting

Заявяване на Kerberos билет за служебен акаунт и разбиването му офлайн, за да се възстанови паролата на акаунта.

Всеки удостоверен потребител в домейна може да поиска от контролер на домейна служебен билет за акаунт със зададен service principal name (SPN), а част от този билет е шифрована с ключ, изведен от паролата на акаунта. Нападателят използва билета за офлайн проверка на предполагаеми пароли, така че няма неуспешни входове и няма заключвания, които да предупредят някого. Служебните акаунти са обичайната цел, защото паролите им често са стари, избрани от човек и с прекомерни права. Защитите са дълги случайни пароли или групово управлявани служебни акаунти, премахване на ненужните SPN и сигнализиране при необичайни заявки за служебни билети.Още →

AS-REP roasting

Събиране на материал за разбиване от акаунти с изключено предварително удостоверяване в Kerberos, без да са нужни идентификационни данни.

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

NTLM relay

Препращане на прихванат опит за удостоверяване в Windows към друга услуга, така че нападателят да бъде удостоверен като съответния потребител.

Атакуващият никога не научава паролата; той предизвиква или прихваща обмена на съобщения за удостоверяване и го препредава към цел, която ще го приеме — обикновено LDAP интерфейс, файлов дял или услуга за сертификати. Препредаването към Active Directory Certificate Services е особено опустошително, защото може да донесе сертификат за удостоверяване от името на привилегирован акаунт. Мерките са подписване и обвързване на канала при LDAP и SMB, изключване на NTLM там, където вече не е нужен, и укрепване на защитата на крайните точки за издаване на сертификати.Още →

Pass-the-hash

Удостоверяване към Windows система с откраднат хеш на парола вместо със самата парола.

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

Password spraying

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

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

Credential stuffing

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

Нападателят разчита на повторно използвани пароли и изпробва изтекли комбинации от потребителско име и парола срещу други услуги. При голям брой опити дори ниската успеваемост може да доведе до компрометирани акаунти. Разпределянето на трафика през много прокси сървъри затруднява ограничаването само по IP адрес. Полезни мерки са многофакторно удостоверяване, проверка за известни компрометирани пароли, анализ на устройството и поведението и наблюдение за необичайни опити за вход.Още →

IDOR — нарушена оторизация на ниво обект

Достъп до чужди данни чрез подмяна на препратка към обект, когато сървърът не проверява правото за съответното действие.

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

SSRF — подправяне на заявки от страна на сървъра

Принуждаване на сървъра да извлече URL по избор на нападателя, така че заявките да идват отвътре на вашата мрежа.

Навсякъде, където приложение приема URL, име на хост или XML препратка и го извлича, нападателят може да го насочи към вътрешни услуги без външна достъпност. В облачни среди класическата цел е крайната точка с метаданни на инстанцията, която може да върне идентификационни данни за ролята на работното натоварване. Списъците със забранени адреси редовно се заобикалят с пренасочвания и DNS трикове, затова трайните корекции са списък с разрешени дестинации, посредник за извличане без достъп до мрежата нататък и използване на защитената версия на услугата за метаданни.Още →

Дефект в бизнес логиката (business-logic flaw)

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

Примери са завършване на поръчка след неуспешно плащане, многократно прилагане на една отстъпка или връщане на поръчка към предходно състояние, за да бъде редактирана. Заявките могат да са технически валидни, но да нарушават правилата на процеса. Откриването изисква разбиране на очакваното поведение, а отстраняването — сървърни проверки на състоянията и условията, които трябва винаги да са изпълнени. Същият процес трябва да бъде проверен и през други канали, например мобилния API.Още →

Ескалация на привилегии (privilege escalation)

Преминаване от достъпа, който имате, към повече достъп — като потребител с по-високи права или на системно ниво.

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

Странично движение (lateral movement)

Разпространяване от първата компрометирана машина към други, обикновено с легитимни идентификационни данни и вградени инструменти.

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

Инжектиране на формули (formula injection)

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

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

Инжектиране на промпти (prompt injection)

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

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

Инфраструктура и идентичност

Active Directory

Услугата за директории на Microsoft, която съхранява акаунтите, групите, компютрите и политиките за една Windows мрежа.

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

Контролер на домейна (domain controller)

Сървър, който съхранява копие на базата данни на директорията и отговаря на заявките за удостоверяване в домейна.

Тъй като съхранява данни за удостоверяване за всеки акаунт в домейна, административният достъп до един такъв сървър на практика е административен достъп до всичко, което домейнът защитава. Затова нападателите се целят директно в него или във всеки път, който дава права за репликация на директорията — те позволяват тайните да бъдат изтеглени, без изобщо да се влиза в сървъра. Третирането на контролерите на домейна като Tier 0, ограничаването на това кой може да ги администрира и наблюдението на заявките за репликация са базовите защити.Още →

Tier 0

Наборът от системи и акаунти, които могат да поемат контрол над вашата инфраструктура за идентичност, а оттам и над всичко останало.

Включва контролерите на домейна, акаунтите и групите, които ги администрират, сертифициращите органи, сървърите за синхронизация на идентичности, системите за резервни копия, които съхраняват техните данни, и всеки управленски инструмент, способен да разположи код върху тях. Смисълът да се именува нивото е идентификационни данни от Tier 0 никога да не се използват върху машини от по-ниско ниво, защото едно излагане там предава цялата среда. Повечето ангажименти откриват поне един неочакван член — обикновено агент за резервни копия, инструмент за наблюдение или шаблон за сертификат.Още →

Active Directory Certificate Services

Ролята на Windows за инфраструктура с публични ключове, която издава сертификати на потребители, компютри и услуги в домейна.

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

Service principal name

Идентификатор, който свързва услуга — например база данни или уеб приложение — с акаунта, под който тя работи.

Kerberos го използва, за да определи с чий ключ да бъде шифрован служебният билет, и точно затова от всеки акаунт, който носи такъв идентификатор, всеки удостоверен потребител може да поиска билет, подлежащ на разбиване. Service principal names често се задават на обикновени потребителски акаунти за удобство и после се забравят, когато услугата бъде извадена от употреба. Описването им, премахването на неизползваните и преместването на останалите към управлявани акаунти премахва по-голямата част от експозицията.Още →

Управляван служебен акаунт (managed service account)

Тип Windows акаунт, чиято парола се генерира и подменя автоматично от директорията, а не от човек.

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

Делегиране (delegation)

Функция на Windows, която позволява една услуга да се удостовери към друга от името на потребител.

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

Междинен сървър за достъп (jump host)

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

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

Сегментация (segmentation)

Разделяне на мрежата на зони, така че компрометация в една да не достигне до останалите.

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

EDR — откриване и реакция на крайни точки

Агентен софтуер, който записва дейността на хоста, вдига сигнали при подозрително поведение и може да изолира машината.

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

Уеб и API

OWASP Top 10

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

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

OWASP API Security Top 10

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

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

GraphQL introspection

Вградена GraphQL заявка, която връща пълната схема, включително типове, полета и налични операции.

Предназначена е за инструменти за разработка, но оставена включена в продукция, тя подава на нападателя пълна карта на API, включително полета, които потребителският интерфейс никога не извиква. Изключването ѝ намалява само удобството при откриване, тъй като схемите все още могат да бъдат възстановени чрез подсказки за полета, съобщения за грешка и клиентски пакети. Истинските контроли са оторизация на всеки resolver, ограничения за дълбочина и сложност на заявките и премахване на полета, които не бива да са достижими, вместо скриване на документацията им.Още →

CORS — споделяне на ресурси между източници

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

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

Content Security Policy

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

Основната ѝ цел е да намали въздействието на cross-site scripting, като отказва вградени и неочаквани скриптове, обикновено чрез nonce за всеки отговор или чрез хеш. Политики, отслабени с unsafe-inline, широки заместващи източници или доверени мрежи за доставка на съдържание, които ще хостват произволни скриптове, осигуряват малко реална защита. Това е втори слой защита: кодирането на изхода и безопасното шаблонизиране пак трябва да отстранят основното инжектиране.Още →

Clickjacking

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

Атакуващият зарежда целевото приложение в невидима или прикрита рамка върху собствената си страница, така че истинското кликване попада върху истински елемент — например бутон за потвърждение или разрешение. Въздействието зависи от това какво може да постигне едно удостоверено кликване, което прави потоците за одобрение и плащане обичайната грижа. Предотвратяването е отказ да бъдете поставени в рамка чрез директивата frame-ancestors в Content Security Policy, плюс изрична стъпка за потвърждение в самата страница при чувствителни действия.Още →

CSRF — подправяне на заявки между сайтове

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

Работи, защото браузърите прикачват бисквитките автоматично, така че заявка, изпратена от друг сайт, пристига напълно удостоверена. Защитите са токени срещу подправяне за всяка сесия, които страницата на нападателя не може да прочете, атрибутът SameSite на бисквитките и проверка на източника на заявките, променящи състояние. API, което се удостоверява с bearer токен в заглавка, а не с бисквитка, не е изложено по същия начин, затова рискът често се оценява погрешно при смесени архитектури.Още →

OAuth 2.0 и OpenID Connect

OAuth делегира достъп на приложение, без да се споделя парола; OpenID Connect добавя идентичност върху него.

OAuth издава токени за достъп, които казват какво може да прави едно приложение, а OpenID Connect добавя токен за идентичност, който казва кой е потребителят, и смесването на двете е честа грешка в дизайна. Дефектите, които се срещат на практика, са хлабаво съпоставяне на адреса за пренасочване, липсващ параметър state, токени, приемани без проверка на аудиторията или издателя, и implicit потоци, които поставят токени в адресната лента на браузъра. Актуалната препоръка е authorization code потокът с PKCE, точно съпоставяне на адреса за пренасочване и строга проверка на всяко твърдение в токена.Още →

PKCE

Разширение на OAuth, което не позволява откраднат код за оторизация да бъде разменен за токен от някой друг.

Proof Key for Code Exchange кара клиента да генерира случайна тайна, да изпрати само нейния хеш при започване на потока и след това да представи оригиналната стойност при обмен на кода за токен, така че код, прихванат на мобилно устройство или чрез пренасочване, е безполезен сам по себе си. Въведено е за публични клиенти, които не могат да пазят тайна — например мобилни и едностранични приложения — а сега се препоръчва и за поверителни клиенти. За да помогне всичко това, сървърът трябва да проверява стойността code challenge и да отхвърля неговия незащитен вариант.Още →

JSON Web Token (JWT)

Компактен формат за обмен на твърдения между системи, обикновено защитен с подпис или MAC и при нужда — шифрован.

JWT може да използва структура за подписване (JWS) или за шифроване (JWE). Подписан, но нешифрован токен може да бъде прочетен от всеки, който го получи, затова не трябва да съдържа тайни. Приложението проверява криптографската защита, допустимите алгоритми, издателя, аудиторията и срока на валидност, преди да се довери на съдържанието. Чести грешки са неочаквано приемане на неподписани токени, доверяване на подадени от нападателя алгоритми или адреси на ключове и използване на твърденията за роля или клиентска организация като достатъчно основание за достъп. Отнемането изисква механизъм на приложението, например кратка валидност със списък на отказани токени или версиониране.Още →

Обслужване на множество клиентски организации (multi-tenancy)

Една инстанция на приложение, обслужваща много клиенти, като границата между данните им се налага софтуерно.

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

Процес и отчитане

CVSS

Стандартна формула за оценяване на техническата критичност на уязвимост от нула до десет.

Common Vulnerability Scoring System оценява присъщи характеристики — как се достига проблемът, колко трудно е да бъде експлоатиран и какво засяга — което прави оценките сравними между доставчици. Умишлено не знае нищо за вашата среда, така че неудостоверен дефект в система, достижима само от един административен подмрежов сегмент, носи същата базова оценка като същия дефект в интернет. Съществуват метрики за средата и заплахата, които да коригират това, но често остават неизползвани, затова базовата оценка трябва да подпомага определянето на приоритета, а не да го определя.Още →

CVE

Уникален публичен идентификатор за една конкретна, публично разкрита уязвимост в даден продукт.

Common Vulnerabilities and Exposures дава на всички обща отправна точка, така че бележка към обновление, резултат от скенер и бюлетин за сигурност да могат да бъдат надеждно съпоставени. Идентификаторът описва дефекта, а не вашата експозиция: дали уязвимият път в кода е достижим, дали функцията е включена и дали компенсиращ контрол го блокира — всичко това променя отговора. Потвърждаването или отхвърлянето на допускането на скенер за даден идентификатор често струва повече от самата констатация.Още →

CWE

Каталог с типове софтуерни слабости, който описва класа на грешката, а не конкретен дефект в продукт.

Common Weakness Enumeration именува модела — например неправилно неутрализиране на вход или липсваща оторизация — и точно това го прави полезен за забелязване на повтарящи се теми в един доклад. Докато CVE казва кой продукт е засегнат, CWE казва какво се е объркало, така че съотнасянето на констатациите към него показва дали организацията има една лоша крайна точка, или повтарящ се навик в разработката. Това е правилното ниво на абстракция, на което се решава какво да се промени в обучението, общите библиотеки и прегледа на кода.

EPSS

Оценка на вероятността дадена уязвимост да бъде експлоатирана в реални условия през следващите трийсет дни.

Exploit Prediction Scoring System е модел, базиран на данни и поддържан като общностно усилие, и е предназначен да допълва критичността, а не да я замества. Съчетаването на висока оценка за критичност с ниска вероятност за експлоатация и познаването на собствената ви експозиция обикновено дава далеч по-кратък спешен списък, отколкото само критичността. Вероятностен е и се обновява непрекъснато, затова информира последователността на обновяването, а не дали дадена слабост изобщо трябва да бъде отстранена.

Правила на ангажимента (rules of engagement)

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

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

Обхват (scope)

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

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

Контролен екип (control team)

Малката група в организацията на клиента, която знае, че протича скрито упражнение, и го управлява.

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

Разказ за атаката (attack narrative)

Частта от доклада, която разказва как тестерът е стигнал от началната точка до въздействието.

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

Отстраняване (remediation)

Работата по поправяне на откритото от теста и проследяването, което потвърждава, че то действително е направено.

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

Отговорно разкриване (responsible disclosure)

Докладване на уязвимост на страната, която може да я отстрани, и задържане на детайлите, докато има корекция.

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

Писмо за закриване (closure letter)

Кратък подписан документ, който удостоверява, че констатациите от тест са повторно тествани и потвърдени като отстранени.

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

Доказателства (evidence)

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

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

Съответствие

DORA

Регламентът на ЕС за цифрова оперативна устойчивост, който задава правила за ИКТ риска при финансови субекти и техните критични доставчици.

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

TLPT

Тестване за проникване, водено от заплахи: тестване на реално работещи продукционни системи, изисквано от значимите финансови субекти по DORA.

Ангажиментът започва с фаза на разузнаване, която установява реалистични противници и сценарии, а тези сценарии след това определят фазата на red team срещу продукционните системи, поддържащи критични или важни функции. Трябва да обхване няколко такива функции, да включи съответните доставчици — трети страни, когато функциите зависят от тях, и да бъде изпълнен от тестери, отговарящи на изискванията в регламента. Органът преглежда документацията и издава атестация, така че процесът и неговите записи имат също толкова значение, колкото техническият резултат.Още →

TIBER-EU

Европейската рамка за red team тестване, водено от разузнавателна информация, за финансови институции, и моделът, върху който стъпва режимът на DORA.

Threat Intelligence-based Ethical Red Teaming определя фазите на упражнението, участващите роли и резултатите, протичайки от подготовка през разузнаване и red team до приключване, като органът действа като наблюдател. Целта ѝ е контролирано тестване срещу системи в продукционна среда с последователна документация в различните юрисдикции. Съществуват няколко национални варианта, а изискванията на DORA за тестване, водено от заплахи, са създадени така, че да се съгласуват с нея, а не да я заменят.Още →

NIS2

Директивата на ЕС, която повишава изискванията за киберсигурност при съществени и важни субекти в много сектори.

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

PCI DSS

Стандартът за сигурност на картовата индустрия за организации, които съхраняват, обработват или пренасят данни на картодържатели.

Версия 4.0 и нейната редакция 4.0.1 са текущите издания, структурирани около дванайсет изисквания и позволяващи както определено, така и персонализирано прилагане на всеки контрол. Необичайно предписателен е относно тестването: външно и вътрешно тестване за проникване поне веднъж годишно и след значима промяна, тестване на сегментацията за субекти, които разчитат на нея за намаляване на обхвата, и тримесечно сканиране за уязвимости. Как се валидира съответствието зависи от нивото на търговеца или доставчика на услуги — чрез въпросник за самооценка или чрез формална оценка.Още →

ISO 27001

Международен стандарт за система за управление на информационната сигурност, сертифицируем от акредитиран орган.

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

SOC 2

Атестационен доклад, изготвен от акредитирана одиторска фирма, за контролите на доставчик на услуги.

Това е доклад, а не сертификат: Type 1 покрива дали контролите са били подходящо проектирани към определен момент, а Type 2 — дали са действали ефективно през определен период, обикновено от три до дванайсет месеца. Обхватът се задава от избора на Trust Services Criteria от страна на организацията, а същността е в мнението на одитора и в списъка с изключения. Тестването за проникване не е посочено като изискване, но одиторите обичайно го приемат като доказателство за критериите за откриване на уязвимости и управление на промените.Още →

Trust Services Criteria

Петте категории контроли, спрямо които може да бъде определен обхватът на доклад по SOC 2, като сигурността винаги е включена.

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

Qualified Security Assessor (QSA)

Компания и лице, сертифицирани от PCI Security Standards Council да оценяват съответствието с PCI DSS.

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

Approved Scanning Vendor (ASV)

Организация, оправомощена да извършва външните сканирания за уязвимости, които PCI DSS изисква всяко тримесечие.

Одобрените доставчици на сканиране се валидират от PCI Security Standards Council и трябва да изготвят успешен доклад от сканиране срещу външните адреси на субекта поне веднъж на тримесечие и след значима промяна. Сканирането е автоматизирано и проверява за известни уязвимости и несигурни конфигурации; то изрично не е тест за проникване и не удовлетворява отделното изискване за годишно тестване. Неуспешните елементи трябва да бъдат отстранени, а сканирането — повторено, докато премине успешно.Още →

Искате това обяснено спрямо собствената ви среда?

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

Заявете оферта [email protected]

Поверителност от първия разговор

Можем да подпишем вашето NDA, преди да споделите чувствителни детайли. За запитването ви се прилага политиката ни за поверителност.

Как защитаваме информацията ви · Политика за поверителност