Пентесты против аудита

r's Choice

"toxa: Пентесты против аудитов".

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

очень лаконично и всё по делу. характерно не только для украинского рынка, но и для многих других незрелых (недостаточно зрелых? всё ещё не зрелых?) рынков (ЕМЕА) и/или компаний. имо, мастрид для любого ИТ-менеджера или менеджера отвечающего за ИТ функции в организации, вне зависимости от размера оной. да и вообще, я обоими руками за внедрение процессного подхода в любой сфере деятельности организации, в частности, в любимом ИТ :)

1 day ago

25 comments

Dmytro Ponomar'ov не понял только куда линк делся.. пусть будет в комментариях: http://toxa.livejournal.com/487821.html

Vladimir Matviychuk, CISA, CISM Тесты на проникновение - это не только "блэкбокс-хакинг". "Грейбокс" тестирование с точки зрения затратна порядок эффективнее

Volodymyr Styran Статья оставила противоречивое впечатление. Вроде и правильные вещи изложены, но "как-то так" (с).

Vladimir Tkachenko Как правило "черный ящик" используется для теста самого аудитора при проверке его квалификации. И, иногда, при double blind black box - для проверки на устойчивость целевой системы к взлому. (Опираюсь на методику OSSTMM )
Согласен с Владимиром - "серый" экономит время, деньги и ресурсы обеих сторон. А статья была когда-то в Хакере по этому поводу более пространная, возможно этого же автора.

Volodymyr Styran "Как правило "черный ящик" используется для теста самого аудитора при проверке его квалификации."

Любопытный вывод, интересно из каких посылок =)

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

Любые споры на тему penetration test vs audit vs vulnerability assessment -- бессмысленны. Потому что эти три мероприятия преследуют три совершенно разные цели и при этом являются совершенно различными по своей природе.

Пентест -- это proof of concept, одноразовый акт тестирования системы на предмет устойчивости к компрометации в определенных временных, квалификационных и бюджетных пределах. Не более и не менее. Все, что видно из результата пентеста, это то, что данная команда, располагая вот такими ресурсами и такой вот подготовкой, за такое-то время и при наличии таких-то актуальных уязвимостей в исследуемой системе, смогла (или не смогла) это самую систему скомпрометировать. Точка. Блекбокс, грейбокс, 2*балйнд и пр. -- это методические ароматы одного и того же процесса, варьируются они в четких пределах. Как правило, предоставляя одной из сторон-участниц какую-то дополнительную информацию о дизайне и эффективности имеющихся в системе контролей, тем самым просто "подкручивая" параметры процесса. И как следствие удерживая результат тестирования в не менее четких рамках. "ДА" или "НЕТ".

Аудит -- это проверка системы контролей. Проверка в ключе А) соответствия (адекватности) выполняемых контролей актуальным для системы рискам и Б) эффективности этих контролей. Очевидно, диапазон результатов тут совершенно иной, и он значительно шире по сравнению с пентестом.

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

Надеюсь кому-то это было интересно. Естественно, готов к конструктивным возражениям, ибо "век живи -- век учись" (С).

Vladimir Tkachenko To Volodymyr Styran: Из определения аудита, выше следует вывод, что нужно определить риски для системы, а потом проводить аудит.
Таким образом, приходим к картине, когда в 99% случаев аудит делается не на какой-то базе (оцененых рисках), а просто по методике (кам) и опирается на неточные данные должностных лиц предприятия (банка). Пусть меня поправят представители Big4. Думаю они с этим сталкиваются сплошь и рядом.
Впрочем я бы немного поправил (или добавил)вот что. Аудит проводится и проверяет соответствие требованиям стандартов (как международных (27K), национальных (КСЗИ) , отраслевых (PCI DSS, HIPAA...) так и внутренних корпоративных) или законодательных актов (пример соответствие требованиям Закона о защите ПДн РФ)

Volodymyr Styran Я не совсем понял, что звучит в первых двух абзацах, возражение, или перефразирование вышесказанного =)

По второй части: если проводится аудит на соответствие системы контрллей какому-то стандарту или регуляции, то да. Но это частный случай.

Vladimir Tkachenko По поводу первой части -перефразирование и уточнение. Вцелом согласен с Вашим мнением.

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

При этом ИТ аудит фокусируется на информационной безопасности предприятия и имеет целью получить независимую оценку текущему состоянию безопасности и указать на определенные пробелы и недостатки в системе ИБ.

Vladimir Gninyuk Полностью разделяю мнение Volodymyr Styran касательно Пентестов. Для меня всегда загадка: пентест это проверка ИС или самого "пентестера". Очень здорово описано.

Касательно аудита, то я всегда руководствуюсь формулировкой, что "аудит это установления соответствия чего-то чему-то" (с)...

Dmytro Ponomar'ov @Volodymyr Styran - согласен полностью! но суть-то та же что и по линку у автора в ЖЖ ;) по-крайней мере, в моём восприятии двух текстов.

т.е. аудит - это проверка существующей системы контролей (наличие, полнота, дизайн, частично - качество). пентест - проверка качества уже существующей системы контролей, воплощенных в конкретной системе. до определённого этапа развития компании или её процессов смысла в пентестах не вижу никакого. к примеру, если в организации нет security awareness training - зачем нанимать кого-то чтоб проверить насколько осведомлены сотрудники о том что такое соц инжинерия? они не осведомлены! если не существует процесса безопасной разработки внутренних приложений - к чему проверять как разработчики защищаются от эскалации полномочий, угона сессий итп. они не делают этого никак! даже если ненароком они и отфильтруют inputs для предотвращения инъекций, то 90% что они не фильтруют их же в закодированном виде. продолжать можно бесконечно.

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

@ Vladimir Tkachenko - соответствие каким-либо стандартам, это compliance audit. с точки зрения внутреннего аудитора, это очень малая часть "реального аудита" (consultancy audit). нужны оба подхода, но выгоды для организации гораздо ощутимее во втором случае, когда в качестве заключений аудита он аполучает анализ реальных причин почему "что-то не работает" и как сделать "чтоб заработало", обычно подкреплённое предложением action plan-a. ну и опять-таки, для проведине compliance audit-a достаточно любого аудитора "в теме" с правильным опросником в руках. для consultancy - понимание реальных процессов в организации, взаимоотношений между структурными подразделениями, сильных и слабых сторон персоналий, технической специфики итд итп, что невозможно получить от внешнего аудитора за 1-2 недели филдворка

Volodymyr Styran Еще столько же. Трудно что-то добавить.

Andriy Lysyuk, CCIE#10933, CISSP, CISM, CISA Для пентестов есть еще и white-box approach. White-box в том числе оценивает риски компрометации системы контролей инсайдерами.

Alex Bodryk Как-то выпущен из виду психологический момент - ну не верит народ что "хождением по кабинетам с бумажками" можно что-то исправить. Обычному (не ИТ) топу нужен "взлом", как весомое, реальное доказательство существования угроз и рисков.

Dmytro Ponomar'ov @Alex Bodryk - отнюдь нет! обычному топу, впрочем как и любому отвечающему за ИТ, нужен разговор и агрументы на его языке. иными словами: риски, SWOT, ROI, TCO. и никаких "купите мне фейловер файервол, потому что без него всё может упасть". и пока безопасность и менеджмент разговаривает на разных языках, ни денег, ни понимания не будет.

что касается "доказательств". как я говорил ранее - при отсутствии внедрённого процессного подхода, возьмите любого более-менее грамотного внутреннего технаря, заплатите ему 100-200 баксов премии и за 2 дня вы получите на гора массу реальных фактов влома системы. экономия будет сколько? пару тысяч уе? ну да, вы не получите рекомендаций и репорта, но это как раз будет ещё более наглядно для менеджмента. особенно при правильной презентации.

Vladimir Tkachenko Дмитрий :-)

1) 100-200 маловато и 2 дня маловато. думаю 500 и дней 4-5
2) Экономия в некоторых случаях будет 50 -70 К USD
3) Вопрос к общественности - кто-нибудь у себя КОГДА-НИБУДЬ пытался считать ROSI (Return On Security Investment)?

Dmytro Ponomar'ov Владимир, ну я, безусловно, утрировал в примере :)

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

в нескольких наших банках считают ROI для определённых проектов.

Dmytro Ponomar'ov *бюджета, конечное. прошу прощения

Vladimir Tkachenko To Dmytro Ponomar'ov : Вопрос наверное риторический. Я только поправлю есть разница между ROI и ROSI. При ROSI берется во внимание "потусторонняя" и непонятная (до первого инцидента) нашим менеджерам величина - возможного ущерба, если не внедрить мероприятия (средства) по ИБ.

Volodymyr Styran Вы не Recovery Oriented System Indicators имеете в виду?

Dmytro Ponomar'ov @Vladimir Tkachenko - значит считал ROI. ROSI никогда не доводилось считать

Alex Bodryk Дмитрий, может у меня топы неправильные как источник (в конце концов там их только пара организаций, но ОЧЕНЬ больших), но их умозрительные вещи как-то риски, SWOT, ROI, TCO волнуют слабо - они или считать их не умеют (и понимать соответственно), или слишком хорошо умеют (сами что хочешь обоснуют). Я сталкивался с тем что заключение аудита ИБ начали иметь ввиду через 2 года, в другой же организации главной задачей информационной безопасности являлось хранение (и моментальное уничтожение в случае маски-шоу - которое там было вполне вероятным) компрометирующих документов (на бумажном носителе)...С другой сторони - ну что, мало таких топов? Покажите мне организацию без черного бюджета. Или где топы все грамотные (иллюстрирую слова примером - http://habrahabr.ru/blogs/personal/91585/ ). Можно конечно надеяться на "правильную" организацию - то есть ту где вышеперечисленные моменты будут не основополагающими, однако выпускать из виду реальность нельзя.

Vladimir Gninyuk Я прошу прощения, но Alex, посмотрите пожалуйста с чего автор (он же Дмитрий) начал дискуссию: если организация не достигла определенного уровня зрелости, то многие техники там не работают.

"Уровень зрелости" определяется не количеством денег и масштабами организации, а "количеством и качеством поставленных процессов". Вот и не понимают некоторые, что такое SWOT, ROI, TCO. При этом коллеги (Володя Ткаченко, например) пишут, что некоторым ROI мало им ROSI подавай.

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

Dmytro Ponomar'ov @Alex Bodryk - согласен с Владимиром.

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

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

что касается вашего примера с "маски шоу", то я вижу тут 2 причины. первая - это действительно наиболее существенный риск для организации, тогда всё правильно, именно от него и нужно защищаться. и вторая - недоработка подразделения/человека отвечающего за ИБ - это именно он должен идентифицировать, оценить и доводить до руководства возможные риски ИБ, а не наоборот.

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

1 hour ago
Comments