Изберете език
Редовните оценки показват какво е изложено на риск и какво трябва да се отстрани първо.
Много слабости възникват още при разработката: уязвими зависимости, изложени идентификационни данни, слаба валидация на входните данни или несигурна логика за оторизация.
Компрометирани идентификационни данни и прекомерни права могат да превърнат малка слабост в сериозен инцидент.
Превенцията намалява риска, но никоя среда не бива да разчита само на нея.
Сигналите са полезни, когато обясняват какво се е случило, кои системи може да са засегнати и какви действия трябва да последват. Добре настроените известия помагат на екипа ви да се съсредоточи върху инцидентите, които изискват действие.
Следим логовете, събитията при автентикация, поведението на приложенията, промените в инфраструктурата и мрежовата активност за признаци на компрометиране.
Разследваме събитието, откриваме засегнатите системи и изолираме компрометираните акаунти, приложения или сървъри. Ако има съмнение за изтекли данни за достъп или секрети, ги сменяме.
Възстановяваме засегнатите системи безопасно и съхраняваме логовете и техническите доказателства, необходими за разследването.
Анализът след инцидента открива първопричината, а изводите се използват за подобряване на вашите защитни механизми.
Новите версии, зависимостите, потребителските акаунти, интеграциите и облачните услуги могат да добавят риск дори към сигурно конфигурирана среда. Сигурността трябва да се развива заедно със системите, които защитава.
Да, но не във всеки случай продукционната среда е най-подходящото място за това.
Преди началото се уточнява точният обхват: кои системи могат да бъдат тествани, какви действия са допустими, какво трябва да се избягва и с кого да се осъществи контакт при неочакван проблем. Проверки, които могат да променят данни, да задействат външни услуги, да генерират голям трафик или да повлияят на реални потребители, могат да бъдат ограничени или преместени в тестова среда.
В много случаи достатъчно задълбочена проверка може да бъде направена и върху реално работеща система, без нормалната ѝ работа да бъде нарушавана.
Зависи от това колко задълбочена трябва да бъде проверката и какво искате да установите.
При тест от гледна точка на външен потребител понякога са достатъчни само адресът на приложението или API крайните точки. За по-подробна оценка може да са необходими тестови профили с различни роли, API документация, информация за конфигурацията или достъп до част от изходния код.
По-широкият достъп не прави теста по-лесен, а позволява да бъдат проверени различни типове рискове. Например профили на обикновен потребител, мениджър и администратор дават възможност да се установи дали една роля може да получи достъп до функции или информация, предназначени за друга.
Не задължително.
Проверката може да бъде извършена без никаква вътрешна информация, с обикновен потребителски профил или с допълнителен достъп до код, конфигурация и архитектурна документация.
Подходът зависи от целта на оценката. Ако искате да разберете какво би могъл да открие външен нападател без предварителни знания, ограничен достъп често е по-подходящ. Ако целта е да се открият по-дълбоки проблеми в правата за достъп, бизнес логиката, реализацията или архитектурата преди пускане, допълнителната техническа информация позволява много по-пълна проверка.
Не е необходимо да чакате продуктът да бъде напълно завършен.
Подходящ момент обикновено е преди по-голямо пускане или след съществени промени в автентикацията, потребителските права, плащанията, API интерфейсите, инфраструктурата, работата с чувствителни данни или интеграциите с външни системи.
При вече работещ продукт е по-разумно нуждата от нова проверка да се определя според промените в риска, а не само според календара. Нова система за вход или сериозна промяна в потребителските права например е много по-основателна причина за повторна оценка от чисто визуална промяна по интерфейса.
Не. Никоя проверка по сигурността не може да даде подобна гаранция.
Пенетрейшън тестът оценява конкретни системи, в конкретен обхват и към конкретен момент. Той показва какви слабости са открити и какво е било проверено, но след края му приложението, инфраструктурата и зависимостите продължават да се променят.
Резултатът е ясна представа за текущия риск, най-важните проблеми и къде допълнителната защита ще има най-голям ефект.
Да, като съдържанието може да бъде съобразено с това кой ще го използва.
Разработчиците обикновено имат нужда от технически детайли, с които да възпроизведат и отстранят проблема. За ръководството са по-важни тежестта на риска, възможното отражение върху бизнеса, засегнатите системи и приоритетите за действие. Клиенти, партньори, отдели по снабдяване или одитори често се нуждаят от по-кратко обобщение без чувствителни технически подробности.
Когато е необходимо, информацията може да бъде разделена в различни нива на подробност, така че техническите екипи да разполагат с всичко необходимо за отстраняване на проблемите, без излишно да се разпространява информация, която сама по себе си може да бъде чувствителна.
Разработваме корпоративен софтуер от първоначалната стартъп идея.