среда, 21 ноября 2012 г.

Чуть-чуть об ИБ-терминологии

Под впечатлением от вчерашнего просмотра большого количества вебинаров и докладов по ИБ от представителей типаИБшных компаний и типаИБшных подразделений софверных компаний:

То, что хочет сделать с информацией атакующий, называется угрозой
То, благодаря чему он может это сделать, называется уязвимостью
То, как он может это сделать, называется атакой
То, с какой вероятностью у него это удастся и какие последствия может повлечь, называется риском
То, что мешает атакующему сделать то, что он хочет, называется защищенностью
То, что снижает вероятность успеха атакующего и минимизирует последствия, называется безопасностью

Господа докладывающие, ну неужели это так трудно запомнить?( Вас же слушать невозможно, когда SQL-injection за 7 минут оказывается и уязвимостью, и атакой, и угрозой, и (внезапно) риском. Это атака и ничего больше. Также, как неправильная обработка данных является уязвимостью, а не угрозой. Также, как нарушение конфиденциальности информационного потока является угрозой, а не уязвимостью или риском. Я уже молчу о том, что безопасность у вас означает все, что угодно (причем в рамках одного и того же вебинара/доклада): от защищенности до риск-менеджмента, патч-менеджмента и прочих SDL (что, конечно же, имеет отношение к безопасности, но никак не является ей самой).

Потратьте PLS 20 минут своего времени и освойте эту терминологию. Если не по этому посту, то по "общим критериям", хотя бы. А то, помимо затруднения в восприятии ваших слов, еще и складывается ощущение, что вы совершенно не понимаете, о чем вообще докладываете =/

18 комментариев:

  1. "То, что хочет сделать с информацией атакующий, называется угрозой"
    Я бы перефразировала. "То, что МОЖЕТ"
    "То, как он может это сделать, называется атакой"
    "То, с какой вероятностью у него это удастся и какие последствия может повлечь,"
    То, насколько вероятна успешная атака.

    Олеся.

    ОтветитьУдалить
  2. Очень больная тема, но зато очень простой способ оценить уровень профессионализма.

    ОтветитьУдалить
  3. Олесь, в том-то и дело, что существование угрозы не зависит от возможностей атакующего. Коль скоро конфиденциальность какого-либо информационного потока является критичным состоянием с т.з. ее владельца, угроза нарушения этого состояния появляется автоматом, как критерий, который необходимо учитывать при оценке защищенности системы. Безотносительно конкретных моделей атакующего и существования реальных способов воздействия на это состояние (уязвимостей). Что касается атаки, то при оценке риска необходимо учитывать не только вероятность успеха, но и потенциальный ущерб от ее проведения, чтобы принимать адекватные решения по управлению данным риском.

    ОтветитьУдалить
  4. Да Олеся я, блин.21 ноября 2012 г., 14:47

    "Олесь, в том-то и дело, что существование угрозы не зависит от возможностей атакующего."
    Э... ты делал когда нибудь модель нарушителя? Я всегда указывала необходимый уровень подготовки и кто он - инсайдер, внешний и т.п.

    ОтветитьУдалить
  5. пример: угроза аля съем инфы в темной железной комнате с монитора... кто? естественно, кто имеет доступ. естественно, кто имеет фотик. А фотики отбирают на входе.
    так что вот тут я буду отчаянно спорить, ибо в банках поработала достаточно и к тому же грушница.

    ОтветитьУдалить
  6. Спасибо! А английским названиям терминов можешь научить?

    ОтветитьУдалить
  7. Картинка в тему из Общих Критериев

    ОтветитьУдалить
  8. а это уже "актуальность угрозы" или "вероятность успешной атаки, связанной с данной угрозой"

    ОтветитьУдалить
  9. (20:38:30) pew-pew1: теперь вместо
    ххх: "там была бага"
    ууу: "какая?"
    ххх: "скуль"
    станет
    ххх: там была уязвимость
    ууу: какая?
    ххх: недостаточная обработка входящих данных
    ууу: а конкретнее?
    ххх: не экранировались входящие параметры в данные sql запроса
    (20:40:36) pew-pew2: yyy:И что?
    xxx: мы применили атаку внедрения операторов SQL :)

    ОтветитьУдалить
  10. А скулю не надо устранять. Надо устранять недостаточную обработку входных данных (почему - подробно расписывал здесь: http://habrahabr.ru/post/149152/). А пока диалоги проходят по первому сценарию, мы и будем иметь то, что имеем: когда после устранения скули, в том же месте оставляют хранимую XSS, устранив ксску, оставляют открытый редирект и т.п. Разработчику не нужно знать об атаках, он должен бороться с уязвимостями.

    ОтветитьУдалить
  11. Подразумевался диалог двух пентестеров, а не пентестер-девелопер. В суждениях о терминологии я совершенно согласен, но это излишества в обыденной речи. Вы же не говорите - конденсат воды в атмосфере, просто пошел дождь. Хотя в физическом смысле никуда он не "пошел" и не может идти вовсе. По этому, на мой взгляд, в _простой речи_ вполне себе можно говорить про sqli как и про уязвимость и про атаку. Тоже касается и презентаций/вебинаров, я просматривая их интересуюсь сутью, а не терминологической "водой"

    ОтветитьУдалить
  12. Пожалуй, проплюсую тезис про необходимость оценки "уместности" правильного или упрощенного подхода: иногда надо "фильтровать базар", а иногда это не требуется.


    Например, у меня бы монокль в виски упал от удивления, если бы ко мне на спикер пати на конфе обратились с фразой наподобие: "сударь, не считаете ли вы, что только валидации входных параметров совершенно не достаточно для защиты от injection-атак на запросы к downstream компонентам?" :)

    ОтветитьУдалить
  13. Мне стоило бы сразу пояснить, что речь идет о докладах/вебинарах ИБшников (ну... пусть будут пентестеры) для разработчиков. Т.е. именно о диалоге пентестер-разработчик. И проблема в том, что первые мыслят категориями атак, что совершенно не мешает им использовать практически любую терминологию для достижения своих целей, а вот разработчикам стоило бы мыслить категориями уязвимостей, т.к. устранить (или не допустить) уязвимость гораздо проще и фундаментальнее, чем бороться с каждой атакой в отдельности.

    ОтветитьУдалить
  14. Выше ответил... вопрос не столько в коммуникациях, сколько в том, что они приводят разработчиков к неправильному пониманию собственных целей и путей их достижения в плане обеспечения защищенности кода.

    ОтветитьУдалить
  15. Вот, не рискну пока))

    ОтветитьУдалить
  16. Да, я именно этот раздел и подразумевал)

    ОтветитьУдалить
  17. Ну имхо, это придирки, даже скорее правило хорошего тона, оценивающее уровень профессионализма безопасника. Сам во время общения называю sqli, xss, lfi уязвимостями)) Так понятнее.

    ОтветитьУдалить
  18. > То, что мешает атакующему сделать то, что он хочет,
    > называется защищенностью

    Защищённость, если использовать русский язык -- это степень защиты, а не меры её повышения.

    > То, что снижает вероятность успеха атакующего и минимизирует последствия,
    > называется безопасностью

    Безопасность, опять же, если использовать русский язык, это величина обратная опасности, т.е. риску, а не меры воздействия на неё.


    Впрочем, нельзя не допустить, что используемый в среде ИБ жаргон смутировал уже вот настолько.

    ОтветитьУдалить

Пожалуйста, будьте вежливы к автору и остальным посетителям этого блога