Вопросы от новичка

[VOprosnikMe]

1. Методология и стандарт. Хотелось бы узнать в чем заключается разница между методологией и стандартом. Вроде как оба термина подразумевают под собой описание действий, каких то конкретных стадий проведений. Либо никакой разницы нет?

2. Почему нет единой классификациям уязвимостей? По какой стоит ориентироваться?
Знаю что существует CVE, какие есть ещё?

2.5. Для каждой методологии необходимо придерживаться какой то своей классификациям уязвимостей? Либо это на свой выбор?

3. Что слудет понимать под словом "вендор"?
4. Что слудет понимать под "ISS"?

зы. совсем новичек, сильно не пинать, интересует сфера веб-приложений.

[box_roller]

Если у вас хватило сил и умения написать это сообщение на интернет форуме, то рекомендую сделать следующий важный шаг. Попробуйте внести ваши вопросы в системы поиска по интернету.
Например: первая ссылка гугла по слову "вендор" дает исчерпывающий ответ.

Удачи!

[Алексей Лукацкий]

Википедия проще ;-)

[xell]

5 балофф

[VOprosnikMe]

С вопросами 3 и 4 разобрался.
Вопросы с 1-2.5 остаются для меня открыты т.к. если начинаешь читать форумы, либо какие то статьи по данным вопрос то путаешься ещё больше.
Если вы укажите мне линки где я смогу найти ответы на свои вопросы то буду вам очень признателен.

[Алексей Лукацкий]

1. Как говорит Википедия, методология - это учение о системе понятий и их отношений, — система базисных принципов, методов, методик, способов и средств их реализации в организации и построении научно-практической деятельности людей. А стандарт по той же Википедии - это образец, эталон, модель, принимаемые за исходные для сопоставления с ними др. подобных объектов. Т.е. методологий может быть несколько, но только одна (а может и не одна) из них будет считаться образцом для других, т.е. стандартом. Например, методологий защиты банков есть немало, а вот стандарт в России один - СТО БР ИББС.

2. Потому что нет. Хотите, можете создать свою и продвинуть ее у всех игроков рынка Vulnerability Management. Если вы знаете только CVE, то на нее и ориентируйтесь. Хотя если вы не вендор в области сканеров, то зачем вам вообще эта классификация?

2.5. На ваш выбор.

[VOprosnikMe]

2. Потому что нет. Хотите, можете создать свою и продвинуть ее у всех игроков рынка Vulnerability Management. Если вы знаете только CVE, то на нее и ориентируйтесь. Хотя если вы не вендор в области сканеров, то зачем вам вообще эта классификация?

Представим ситуацию. Меня попросили проверить веб-окружение какой либо фирмы, проекта (т.е. сайт). Мною были найдены уязвимости, я ведь должен дать им описание и оценить их риск по какой то шкале, критериям в своем отчете. И как раз для этого нам лучше всего воспользоваться уже готовой классификациям уязвимостей. Правильно?

2.5. На ваш выбор.

Указывает ли на это какой то документ?

[Ерохин Сергей]

1. Методология - система базисных понятий, методов и методик.
1.1. Метод - если на пальцах, то это то с помощью чего вы хотите что-то делать (опсиание мат аппарата для оценки уязвимостей web-сайтов, ну например использование случайных процессов для прогнозирования уязвимостей web-сайтов (Марковские пройессы, теория автоматов.....)).
1.2. Методика - то как вы это будете делать с подробным описанием (1 шаг - сканирование портов с использованием сканеров безопасности, 2 шаг - определение сервисов на этих портах, 3 шаг - определение уязвимостей сервисов, 4 шаг - прогнозирование уязвимостей с использованием теории автоматов).
Таким образом методология - это комплекс всех методов, методик которую можно применить к оценки уязвимостей web-сайтов.
1.3.Стандарт - это свод требований, который не включает в себя опсиание методов и методик осуществления конкретного действия.

Вот в этом и разница .

2. Наберите в поиске "Классификация уязвимостей автореферат". Увидете научны труды различных людей по данному направлению. В научных трудах все уже есть , но практическое применение страдает.

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

Представим ситуацию. Меня попросили проверить веб-окружение какой либо фирмы, проекта (т.е. сайт). Мною были найдены уязвимости, я ведь должен дать им описание и оценить их риск по какой то шкале, критериям в своем отчете. И как раз для этого нам лучше всего воспользоваться уже готовой классификациям уязвимостей. Правильно?

Давайте разберем эту ситуацию подробнее.

Мною были найдены уязвимости........

1. Как вы их нашли?
2. С помошью чего искали?

я ведь должен дать им описание и оценить их риск по какой то шкале

1. если вы их искали с помощью сканера безопасности, то он вам даст сам описание .
2. Оценивать риск чего?! Возникновения новых уязвимостей? Опасности уязвимости?
3. Если Вы хотите оценить опасность уязвимостей, то вы должны определить угрозы ИБ и ресурсы (информацию) на которые могут действовать угрозы через уязвимости. Далее оцениваете риск = Вероятность возникновения уязвимости (если вы нашли уязвимость, то вероятность = 1) * вероятность возникновения угрозы * цена потерь.
4. После того как вы оценили риск по опасности каждой уязвимосте можете классифицировать по степени опасности, например, по такой шкале:
низкая опасность (ущерб от эксплуотации уязвимости меньше 10000 руб)
средняя опасность (ущерб от эксплуотации уязвимости от 10000 до 100000 руб)
высокая опасность (ущерб от эксплуотации уязвимости более 100000 руб).
5. Основные критери - деньги (сколько можно потерять и сколько нужно потратить, все прекрасно понимают если нужно потратить 100 000, а потерять 1000, то ни кто даже не задумается над этим); репутация (как утечка может повлять на отношения с партнерами, клиентами)......

PS Если хотите получить какой-то более развернутый и практический ответ, то вам лучше попробовать завести общение, например, со специалистами из positive technologis.

[Алексей Лукацкий]

Представим ситуацию. Меня попросили проверить веб-окружение какой либо фирмы, проекта (т.е. сайт). Мною были найдены уязвимости, я ведь должен дать им описание и оценить их риск по какой то шкале, критериям в своем отчете. И как раз для этого нам лучше всего воспользоваться уже готовой классификациям уязвимостей. Правильно?


Указывает ли на это какой то документ?

Сошлитесь на меня ;-)

[VOprosnikMe]

Давайте разберем эту ситуацию подробнее.
1. Как вы их нашли?
2. С помошью чего искали?

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


Как я на данный момент представляю отчет:
1. Общее описание найденной уязвимости.
1.5. Указание на методику поиска уязвимостей.
2. Указание на придерживаемую методологию.
2.5. Указание на найденную уязвимость.
3. Совет по устранению уязвимости.

Совсем криво?
Чувствую что оценка риска той или иной найденной уязвимости для меня пока не возможна, уж больно сложно.

PS Если хотите получить какой-то более развернутый и практический ответ, то вам лучше попробовать завести общение, например, со специалистами из positive technologis.

Мне кажется это не возможным, эти грозные ребята просто не станут тратить свое время.

[Алексей Лукацкий]

Если вы смогли САМИ РУКАМИ найти уязвимости, то эти "грозные ребята" могут вас и на работу взять ;-)

[malotavr]

1. Методология и стандарт. Хотелось бы узнать в чем заключается разница между методологией и стандартом. Вроде как оба термина подразумевают под собой описание действий, каких то конкретных стадий проведений. Либо никакой разницы нет?

Это перпендикулярные понятия

См. Webster:

Definition of METHODOLOGY
1: a body of methods, rules, and postulates employed by a discipline : a particular procedure or set of procedures
2: the analysis of the principles or procedures of inquiry in a particular field

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

Стандарт, как правило, направлен на решение практических задач, поэтому обычно опиывает метод. Но бывают и стандарты, описывающие меодологию - см. например, ISO 18045 Common Methodology for Information Technology Security Evaluation, описывающий методологию оценки функций безопасности.

2. Почему нет единой классификациям уязвимостей? По какой стоит ориентироваться?
Знаю что существует CVE, какие есть ещё?

CVE - это не классификация, а каталог уязвимостей. Возможно, вы имели в виду CVSS? CVSS де-факто является стандартом классификации уязвимостей, однако у него есть ряд недостатков, которые затрудняют его практическое применение. Например, удаленно эксплуатируемое переполнение буфера в MS SQL Server, позволяюее получить права sa полный контроль над СУБД, имеет высший уровень критичности. Но это - уязвимость одного из компонентов информационной системы. Вполне возможна ситуация, когда получение полного контроля над одной изз СУБД системы не дает нарушителю никаких дополнительных возможностей, в этом случае классификация уязвимости по CVSS никак не коррелирует с критичностью этой же уязвимости в контексте всей системы. В каждом частном случае обычно удается дать оценку уязвимлсти, но придумать универсальное общее решение не удается (про методологию совсем молчу )

Кроме того, не всегда удается связать уязвимость с возможными последствиями ее эксплуатации. Например, отсутствие парольной политики - несомненно, уязвимость, но как оценить ее возможные последствия?

2.5. Для каждой методологии необходимо придерживаться какой то своей классификациям уязвимостей? Либо это на свой выбор?

Раз уж вас интересует веб, то методика CVSS в сочетании с классификациями WASC и/или OWASP решит большинство возникающих у вас задач

[malotavr]

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


Как я на данный момент представляю отчет:
1. Общее описание найденной уязвимости.
1.5. Указание на методику поиска уязвимостей.
2. Указание на придерживаемую методологию.
2.5. Указание на найденную уязвимость.
3. Совет по устранению уязвимости.

Совсем криво?

Это от заказчика зависит - некоторым достаточно просто предоставить табличку с найденными уязвимостями и рекомендациями по их устранению.

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

Какое-то ранжирование все равно нужно. Попробуйте воспользоваться CVSSом.

Мне кажется это не возможным, эти грозные ребята просто не станут тратить свое время.

Да уж, мы такие грозные-грозные Напишите в личку, пообщаемся.

[malotavr]

глюк>

[Dima Korne]

Добрый день. Банк, предоставляющий услугу интернет-банкинг, для обеспечения безопасности вводит Etoken ключи. они будут закупаться и раздаваться клиентам, которые уже пользуются этой системой но без ключей. какова роль информационной безопасности в этом случае? помогите, пожалуйста, разобраться. где должны храниться Etoken ключи и кем они выдаются клиентам? какие документы должны быть составлены и что в нем должно быть прописано? Специалист информац.безопасности организации какую роль должен играть в этом проекте? как он должен контролировтаь процесс? кто сталкивался, помогите советом, пожалуйста!

[Ерохин Сергей]

какова роль информационной безопасности в этом случае?

Роль ИБ в том, что вы обосновали необходимость обязательного использования eToken .

где должны храниться Etoken ключи и кем они выдаются клиентам?

eToken в банке должны храниться у материально ответственного сотрудника, надо разбирать конкретный случай. Кто генерирует ключи клиента? Если банк, то тот человек который генерирует пусть выдает ключи. Если сам клиент, то после того как он сгенерирует ключ он должен распечатать два экземпляра сертификата окрытого ключа, с одной стороны его подписывает клиент, с другой стороны ответственный сотрудник в банке, так вот пусть этот сотрудник по банку и выдает ключи.

какие документы должны быть составлены и что в нем должно быть прописано?

Только финансовые документы: счет, счет-фактура и акт приема передачи eToken.
Журнал учета криптосредств у вас должен вестись независимо от того, на чем храниться ключ.

Специалист информац.безопасности организации какую роль должен играть в этом проекте? как он должен контролировтаь процесс?

Он должен установить и настроить работу с eToken, распечатать сертификат открытого ключа, раз в 1,2,3 месяца менять пин код на eToken (1,2,3, как регламентируется их внутренними порядками)

[VOprosnikMe]

Расскажите, пожалуйста, про такие системы оценки уязвимости как SANS, US-CERT. В каких случаих они хороши, а в каких их явно не стоит использовать?

[don_huan]

http://www.kb.cert.org/vuls/html/fieldhelp#metric
Метрика используемая в US-CERT не подходит для описания точеных уязвимостей в отчете. Эта метрика подходит именно для описания уязвимостей в распространенных продуктах (так как собственно и отражает этот факт). В отчете по пен-тесту/аудиту конкретной сети, данная метрика лишняя, так как мне плевать много ли в Интернете ещё такого ПО. Кроме того, данная метрика отображается одной цифрой, что не очень понятно бывает 8)

У SANS метрик не помню. Там вроде топ-20 и все.

ИМХО. Юзать надобно CVSS2. Можно и самому легко считать для "своих" уязвимостей, и для известных багов, в CVE, почти везде используется CVSS2.

[Dima Korne]

Добрый день, подскажите, пожалуйста, где можно в интернете скачать Стандарт и ISO - Международные стандарты безопасности информационных технологий. где подробно описано, что и как делать по каждому пункту. т.к. нашел, но там все вкратце описнао. спасибо. или Российские стандарты по информационной безопасности.

[Алексей Лукацкий]

Яндекс/Google поможет... или не поможет

[Ерохин Сергей]

Добрый день, подскажите, пожалуйста, где можно в интернете скачать Стандарт и ISO - Международные стандарты безопасности информационных технологий. где подробно описано, что и как делать по каждому пункту. т.к. нашел, но там все вкратце описнао. спасибо. или Российские стандарты по информационной безопасности.

Есть на этом форуме хорошая ветка Стандарты и методики........

[goergr]

Заказчик требует перед началом аудита предоставить ему классификацию уязвимостей по их тяжести (высокая степень риска, средняя степень риска ... ). Для меня это немного странно т.к. классифицировать тяжесть степени уязвимости не учитываю различные факторы при её эксплуатации бессмысленно и не правильно.
Рассудите нас, кто прав и как поступить в данной ситуации.

[box_roller]

Заказчик требует перед началом аудита предоставить ему классификацию уязвимостей по их тяжести (высокая степень риска, средняя степень риска ... ). Для меня это немного странно т.к. классифицировать тяжесть степени уязвимости не учитываю различные факторы при её эксплуатации бессмысленно и не правильно.
Рассудите нас, кто прав и как поступить в данной ситуации.

А вы учитывайте. Это же не "сферический конь в вакууме". А конкретная (их) уязвимость для конкретной (их) системы. Если им нужна справочная информация, то можно взять любой общедоступный годовой отчет по уязвимостям и тяжести их последствий.

[Ерохин Сергей]

Заказчик требует перед началом аудита предоставить ему классификацию уязвимостей по их тяжести (высокая степень риска, средняя степень риска ... ). Для меня это немного странно т.к. классифицировать тяжесть степени уязвимости не учитываю различные факторы при её эксплуатации бессмысленно и не правильно.
Рассудите нас, кто прав и как поступить в данной ситуации.

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

Видимо, все это должно быть как-то так.

[malotavr]

Заказчик требует перед началом аудита предоставить ему классификацию уязвимостей по их тяжести (высокая степень риска, средняя степень риска ... ). Для меня это немного странно т.к. классифицировать тяжесть степени уязвимости не учитываю различные факторы при её эксплуатации бессмысленно и не правильно.
Рассудите нас, кто прав и как поступить в данной ситуации.

Заказчик прав. Когда вы скажете ему, что "эта учзвимость пипец как опасна", ему необходимо будет понимать, что вы вкладываете в понятия "опасна" и "пипец как"

Опять-таки, чем вам CVSS как система классификации не угодил?

[goergr]

Заказчик прав. Когда вы скажете ему, что "эта учзвимость пипец как опасна", ему необходимо будет понимать, что вы вкладываете в понятия "опасна" и "пипец как"

Опять-таки, чем вам CVSS как система классификации не угодил?

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

[Алексей Лукацкий]

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

Не так. Почти по всем опубликованным уязвимостям уже известны значения CVSS. Достаточно посмотреть базу NVD. Для "своих" дыр можно использовать калькулятор CVSS - http://www.security-database.com/cvss.php#AV

[goergr]

Гадание на кофейной гуще прям. Не зная того какая уязвимость будет присутствовать, а так же не зная при каких условиях её возможно будет применить нам необходимо её отнести в группу риска. Как вы себе это представляете?
Вы же знаите что для одной уязвимости в CVSS получается разный вектор при разных факторах, а следовательно изменяется и сама оценка.

[Turkish]

Не зная того какая уязвимость будет присутствовать, а так же не зная при каких условиях её возможно будет применить нам необходимо её отнести в группу риска. Как вы себе это представляете?

При оценке защищенности принято брать наихудшие условия эксплуатации.

[Ерохин Сергей]

Гадание на кофейной гуще прям. Не зная того какая уязвимость будет присутствовать, а так же не зная при каких условиях её возможно будет применить нам необходимо её отнести в группу риска. Как вы себе это представляете?
Вы же знаите что для одной уязвимости в CVSS получается разный вектор при разных факторах, а следовательно изменяется и сама оценка.

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

Задайте одинаковое начальное условие, т.е. факторы влияющие на разные уязвимости должны быть одинаковыми.