Выпуск 23 ч.1 

Аудит защищенности информационных систем (ч1)

 

Гости студии Аркадия Прокудина:
 

АйТи – Юрий Наумкин

KPMG – Антон Сапожников

Positive Technologies – Евгения Поцелуевская

СовКомБанк – Никита Ремезов

 

Вопросы

 

1. Аудит защищенности ИС – Что это такое и какую значимость он несет для бизнеса?

2. Этапы аудита защищенности ИС: инициирование - сбор – анализ – рекомендации – отчет. Что зачем нужно и для чего?

3. Аудит защищенности nonstop-систем.

4. Аудит нормативно-правовой, документационный и технический

5. Инструменты аудита (тест на проникновение)

 

Длительность: 30 минут

Текст программы:

 

АРКАДИЙ ПРОКУДИН: Вы слушаете подкаст "Открытая безопасность" и с вами снова Аркадий Прокудин. Мы могли бы сегодня поговорить на разные темы по информационной безопасности, но самые активные из слушателей приняли участие в голосовании по выбору темы следующей программы. Голосование проходило в группах Facebook и LinkedIn, где Вы сами выбрали тему "Аудит защищённости информационных систем". Сама по себе тема наверняка для многих нудная и не совсем понятная с точки зрения бизнеса. Обычно это происходит как: приходишь к клиенту (к бизнесу) и говоришь - «Мы можем провести Вам аудит защищенности Вашей системы. Это стоит Х рублей». Клиент говорит: «Что я за это получу? Горы бумаг и указания на мои ошибки, которые вы можете продать моим конкурентам? Да пошли вы к черту!..» Давайте разберемся, где бизнес перестает понимать, что ему предлагают и кто должен бизнесу все это разъяснить – зачем платить за проверку, если ее наверняка можно провести самому? Ну, Вы скажете: «А кто это может разъяснить?» Ну кто, кто… разве что какой-нибудь крутой аудитор из «четверки». И я, естественно, пригласил Антона Сапожникова из KPMG. Аудитор?

АНТОН САПОЖНИКОВ: Конечно.

АРКАДИЙ ПРОКУДИН: Антон, добрый день.

АНТОН САПОЖНИКОВ: Всем привет!

АРКАДИЙ ПРОКУДИН: Многие тут же заерзают на стуле и скажут, мол, тоже мне эксперта долларового позвал, человек жизни не знает в России-матушке! И я пригласил ведущего аналитика Юрия Наумкина из интегратора АйТи (Информационные Технологии). Юрий?

ЮРИЙ НАУМКИН: Всем привет!

АРКАДИЙ ПРОКУДИН: Привет! Ну иные тролли скажут: «Да он не шарит в инструментах проверки защищенности, бумажки перекладывает!» И я позвал в гости Евгению Поцелуевскую из Positive Technologies. Евгения, здравствуйте!

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: Здравствуйте!

АРКАДИЙ ПРОКУДИН: Здравствуй! Наверняка уже «добрый вечер»!

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: Да.

АРКАДИЙ ПРОКУДИН: Добрый вечер! «О, нашел кого позвать! - скажут остальные, - Вендора пригласил! Он там, поди, ему под столом деньги передает за пиар. Ты б еще лучше заказчика пригласил, кровинушку нашу, того, кто своими руками все прошел!» И я позвал Никиту Ремезова, эксперта по безопасности СовКомБанка, который известен Вам по предыдущим выпускам. Никита, как слышно меня? Привет! А ему меня не слышно, потому что он подключится чуть попозже. Так вот, вот такой компанией мы собрались сегодня, чтобы раскрыть тему «Аудит защищенности информационных систем». Ну что, начнем, как говорится, как с книжки? Аудит защищенности информационных систем – что это такое вообще и какую значимость оно несет для бизнеса? Антон?

АНТОН САПОЖНИКОВ: Аудит, прежде всего, это некая проверка, анализ, либо аттестация в зависимости от того, что хочет получить в результате бизнес. Аудит может в каком-то случае гарантировать, что результат, полученный в ходе аудита, будет сохранен со временем, а с другой стороны, может предложить некие рекомендации по достижению каких-то бизнес-целей. Все очень сильно зависит от того, что хочет клиент, бизнес, и что от него требует та или иная ситуация.

АРКАДИЙ ПРОКУДИН: Бытует мнение, что аудит можно проводить только на соответствие чему-то.

АНТОН САПОЖНИКОВ: Мнение, конечно, имеет место быть, но вопрос в том, что такое «чему-то». Это может быть требование регулятора, требование закона, может быть требование каких-то стандартов, но нюанс в том, что, в принципе, можно определить самостоятельно, чему соответствовать, и помимо требований законов, могут быть желания соответствовать каким-то, назовем это «лучшие практики» или «лидирующие мировые практики», это могут быть стандарты из серии ISO, как мне кажется. Но, в принципе, нет регуляторов, которые требуют соответствия этим стандартам, это уже пожелание бизнеса, если у него есть такая необходимость или потребность.

АРКАДИЙ ПРОКУДИН: То есть, в принципе, каждый заказчик может сформировать такие для себя «сказочные» условия, при которых он будет считать себя защищенным. И вот он должен постоянно этим своим условиям соответствовать. Это же будет корректно?

АНТОН САПОЖНИКОВ: Вы же понимаете, любое аудиторское заключение будет сформулировано примерно так, что «мы проделали работу такую-то, такую-то, основываясь на опыте нашей команды и руководствуясь такими-то методиками (которые предварительно были согласованы с заказчиком), мы выявили такие-то или не выявили такие-то факты». Если мы говорим о какой-то аттестации условно, то в этом случае есть регламент по соответствию тому или иному стандарту, или чему-либо, на что мы аттестуем, и там тоже весьма объективные критерии соответствия или нет.

АРКАДИЙ ПРОКУДИН: Понятно. Ну вот приняли мы решение, что нам нужно соответствовать какому-то набору пунктов, а дальше что? Юра, какие этапы вообще при прохождении аудита желательно проходить?

ЮРИЙ НАУМКИН: На самом деле, определение набора пунктов, или, можно сказать, критериев аудита – это даже не первый этап в самом процессе аудита.

АРКАДИЙ ПРОКУДИН: С чего начинать?

ЮРИЙ НАУМКИН: На этот случай есть хороший документ – ISO 19011, который определяет весь процесс аудита систем менеджмента. Конечно не весь скоп аудита он охватывает, но, тем не менее, это такой хороший документ, в который стоит заглянуть человеку, который пытается аудит провести в первый раз. Если следовать этому документу и реалиям каким-то, то главное в аудите – это первоначально определить цели, что мы хотим получить и зачем это делаем, из чего уже вырождаются какие-то критерии, когда мы уже какую-то свою цель абстрактную пытаемся каким-то образом описать. Собственно говоря, вот эти критерии, как я считаю, и есть описание этого. Глобально весь этот первый шажочек называется инициированием и по жизненным реалиям, и по нашим стандартам в том числе, определение цели, определение критериев, определение скопа аудита, то есть области, она может ограничиться организацией, площадкой, возможно, некоторыми отделами в этой организации; определение сторон, занятых в процессе аудита, то есть определение команды аудиторов, определение тех людей, с которыми она будет работать в процессе проведения.

АРКАДИЙ ПРОКУДИН: То есть мы определили, что нам нужно достигнуть, что нам «аудировать», команду людей.

ЮРИЙ НАУМКИН: Да. Кто будет это делать и кому это пойдет, для того кто будет это делать.

АНТОН САПОЖНИКОВ: И зачем.

ЮРИЙ НАУМКИН: Самое главное зачем, изначально мы определили зачем, безусловно, без этого не возможно все остальное.

АРКАДИЙ ПРОКУДИН: То есть, получения пачки «бумажек» не может быть целю (аудита).

АНТОН САПОЖНИКОВ: Может быть.

АРКАДИЙ ПРОКУДИН: Может быть, в государственных организациях?

АНТОН САПОЖНИКОВ: Я бы не привязывал это к форме собственности.

АРКАДИЙ ПРОКУДИН: Согласен.

АНТОН САПОЖНИКОВ: Это зависит скорей от ситуации в конкретном месте.

АРКАДИЙ ПРОКУДИН: Так.

АНТОН САПОЖНИКОВ: Действительно, бывает такое, что кто-то хочет просто получить «бумажку».

АРКАДИЙ ПРОКУДИН: И положить её на полку.

АНТОН САПОЖНИКОВ: Ну, либо повесить куда-нибудь, или помахать.

АРКАДИЙ ПРОКУДИН: Понятно. Перед аудиторами, которые придут к нему с очередной проверкой.

АНТОН САПОЖНИКОВ: В принципе, да.

АРКАДИЙ ПРОКУДИН:  Вот, мы определили, так сказать scope, дальше что?

ЮРИЙ НАУМКИН: Дальше что. Дальше мы должны определиться с методикой и должны дать команде аудиторов формальное соглашение на работу (бизнес должен его дать). Под бизнесом я имею ввиду высшее руководство в организации, потому что, без APPROVE  с его стороны проводить аудит это заранее гиблое дело. Все зависит от предмета аудита. Конечно, если это какой-то внутренний аудит, который ограничен рамками одного отдела, и он будет проводиться его же сотрудниками такой APPROVE не требуется. У аудитора уже есть доступ ко всей необходимой ему информации. В случае если аудит распространяется за рамки одного какого-то отдела или бизнес направления, а тем более, если в аудите участвует несколько организаций, если это аудит внешний, такое разрешение просто необходимо, без него совершенно не возможно работать. То есть, нужна какая-то «бумажка», махая которой, аудитор сможет открывать двери.

АРКАДИЙ ПРОКУДИН: Ходить по отделам.

ЮРИЙ НАУМКИН: Да. Входить в кабинеты, задавать вопросы. Собственно говоря, когда такая «бумажка» уже получена, значит уже согласованы все документы, согласованы методики, цели и команда.

АРКАДИЙ ПРОКУДИН: Договор есть?

ЮРИЙ НАУМКИН: Да-да, договор есть. Всё, начинаем работать. Собственно говоря, начинается сбор. Сбор тоже сильно зависит от предмета аудита. Это может быть анкетирование людей в отделах. Анкетирование как в виде заранее каких-то подготовленных опросников, может быть применены всевозможные дополнительные технические средства, где люди будут заходить, допустим, на какой-нибудь веб-портал и заполнять там эти опросники, может быть хождение людей по кабинетам.

АРКАДИЙ ПРОКУДИН: То есть сбор информации только с людей. Евгения, вот у меня к тебе вопрос. На сколько эффективно проведение аудита без уведомления сотрудников, чтобы они не могли подготовиться.

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: Ну в нашем случае, как правило, когда мы подразумеваем оценку защищенности, я говорю со стороны Positive Technologies имеется ввиду какие-то работы такие как тестирование на проникновение и в этом случае как правило, действительно, уведомляются только те люди непосредственно которые участвуют в заключении договора специалиста службы безопасности. Рядовые пользователи, администраторы они в большинстве случаев не знают о происходящем. И это, помимо того, что позволяет выявить объективные какие-то недостатки в защите, то есть, администраторы например не могут заранее устранить какие-то уязвимости чтобы их потом не нашли.

АРКАДИЙ ПРОКУДИН:  Torrent закрыть, который сейчас у него работает.

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: И с другой стороны это позволяет выявить, в том числе, на сколько эффективно реализованы меры по реагированию на инциденты. На сколько, например, пользователи обращаются в службу поддержки если получают какие-то подозрительные письма, если мы говорим о проверках с использованием методов социальной инженерии. Насколько администраторы реагируют на какие-то подозрительные события в сети, пытаются ли они как-то сами скрыть следы.  Понимая, что видимо, они сделали что-то не так и кто-то их взломал. Или они действительно обращаются в службу безопасности, которая уже на этом этапе может им сказать: «Так, вот теперь ничего не трогай! Да, это у нас все легально».

АРКАДИЙ ПРОКУДИН: Итак, вот, мы..

АНТОН САПОЖНИКОВ: Можно я как-бы защищу.

АРКАДИЙ ПРОКУДИН: Кого, аудиторов?

АНТОН САПОЖНИКОВ: Аудиторов, о которых говорил Юрий. Все действительно зависит от методики. Не обязательно может быть анкетирование. Это может быть и реально запрос документации, анализ того как реализованы процессы те или иные, и, не только анализ дизайна их, но и с точки эффективности посмотреть, что были действительно выполнены действия, зафиксированы такие-то результаты, есть факты в журналах, что логи были просмотрены, что были такие-то инциденты. То есть, это не просто бумажная работа ради генерирования новой бумаги, а это может быть в том числе и анализ того как это работает на самом деле. Что касается pentest'ов, о которых говорила Евгения, поскольку я тоже участвую в такого рода активностях, не обязательно и далеко не всегда, возможно провести pentest’ы не уведомляя администраторов. Поскольку, это прежде всего первые люди которые могут быть заинтересованы в том чтобы их система работала. И именно поэтому они должны быть в курсе, что их сейчас будут валить и они будут готовы ночью прийти и поднять её.

АРКАДИЙ ПРОКУДИН: Согласен. Ну, вот мы начали сбор данных. Вот мы их собрали. Дальше что с ними делать?

ЮРИЙ НАУМКИН: Дальше аудитор должен произвести их анализ на предмет тех критериев о которых, мы собственно говоря, в процессе инициирования договорились и посмотреть на сколько объект аудита выполняет требования этих критериев. Очень абстрактная фраза, но поясню с точки зрения например аудита на те же перс.данные. Допустим, собрали документацию, посмотрели введены ли у нас те или иные процедуры, посмотрели уже в полях, насколько они выполняются реально, и собственно дали заключение - присутствуют у нас необходимые ли документы или необходимые журналы, собственно говоря, ведутся они или нет по факту.

АРКАДИЙ ПРОКУДИН: Так. Вот мы сделали анализ и дальше что. Нам нужно «бумажку» создать, мы дальше отчет создаем или какие-то рекомендации еще вырабатываем, нужны они или нет?

АНТОН САПОЖНИКОВ: Зависит от целей опять же. Если нужен аудит на проверку GAP-анализ условно говоря.

АРКАДИЙ ПРОКУДИН:  Где мы сейчас. Что нам надо.

АНТОН САПОЖНИКОВ: Да. То вам не хватает вот этого, тут не соответствуете. Это одна работа. А если вы хотите (не вы, а клиент) хочет еще рекомендацию получить, то дальше зависит от того, как уже действует аудитор, поскольку, например, компания, которая выполняет только сертификацию по тому или иному стандарту (сейчас преимущественно про ISO говорю), то они не дают рекомендацию по достижению, поскольку в этом случае они нарушают независимость своего аудита, чтобы не получилось ситуации, когда они аудируют тоже самое, что только-что порекомендовали. Но, в принципе, если мы говорим о проекте, некотором аудите, цель которого, это привести соответствие. А сертифицировать будет уже другая компания, другое лицо, то в принципе могут быть и разработаны какие-то рекомендации уже на месте, в конкретных реалиях, что и как лучше делать. Это в принципе относится как к pentest о которых говорила Евгения, к анализу защищенности систем с технической точки зрения, так и о соответствии или не соответствии стандартам, практикам и так далее.

АРКАДИЙ ПРОКУДИН: Хорошо. То есть, что зачем и для чего нужно во всех этапах аудита мы разобрали. Сначала мы определяем цель аудита, далее мы определяем, что мы будем «аудировать» - ставим границы, какие люди будут  привлечены сюда. Мы выделяем ответственного за аудит?

ЮРИЙ НАУМКИН: Да.

АРКАДИЙ ПРОКУДИН: То есть, у лица на котором будет проводиться аудит должен быть ответственный.

ЮРИЙ НАУМКИН: Ответственный должен быть с обеих сторон. Ответственный должен быть как со стороны аудируемых так и со стороны аудиторов. Вот, соответственно если аудит проводит команда аудиторов всегда должен быть назначен её руководитель.

АРКАДИЙ ПРОКУДИН: Вот мы назначили руководителей, потом мы сделали сбор данных, проанализировали  либо выдали отчет, либо выдали рекомендации. Евгения, вопрос к тебе. На сколько критично проведение аудита защищенности нонстоп-систем, которые нельзя останавливать? Грубо говоря, те же Pedi Gripal-ы на фабрике, они валятся целые сутки. Мы просто делали работу на этой фабрике.

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: Конечно, для систем, которые находятся в промышленной эксплуатации, нужно относиться к ним с особой осторожностью. Особенно если это какие-то промышленные системы, какие-то заводы или сеть телекоммуникационной компании.

АРКАДИЙ ПРОКУДИН: Ядерные боеголовки, например, штампуют круглые сутки.

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: На самом деле практически любая корпоративная информационная сеть крупного предприятия, как правило, её нельзя останавливать, потому что бизнес-процессы могут встать

АРКАДИЙ ПРОКУДИН: Можем ночью либо в выходные.

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: В общем по ситуации. По разному бывает. В принципе (начну из далека) с точки зрения методов проведения анализа защищенности и с точки зрения знаний о системе, которая есть у аудитора. По крупному можно разделить эти методы на две части. Белый ящик, когда есть много информации - максимум информации о системе, то есть, документация, например, исходные коды или доступ с административными привилегиями к системе. И черный ящик, когда наоборот у нас нет никаких предварительных знаний, никакого доступа кроме общедоступных интерфейсов и мы пытаемся каким-то образом проанализировать систему. Так вот если мы рассматриваем первый класс проверок, когда предоставляется информация о системе, здесь в принципе это как раз то, на что в основном стоит рассчитывать при анализе защищенности систем, для которых требуется повышенная доступность, потому что проанализировать документацию в принципе никакого риска. Если мы заходим в систему с правами администратора и так же как администратор просто смотрим какие-то «настроечки», тоже в принципе ничего страшного. Единственное, что здесь аккуратно надо использовать средства автоматизации. Потому что они могут создать дополнительную нагрузку. Если это какая-то важная промышленная система, можно её нечаянно уронить, если она критична к каким-то нагрузкам. Т. е. максимум делать руками или если используются средства автоматизации, то как минимум их протестировать в идентичной среде. Вот. Что касается проверок с использованием метода чёрный ящик, то есть тот же самый pentest, какие-то методы файзинга. Внешнее сканирование это конечно более рискованные операции. В принципе если их вообще не делать, то естественно получаем такую менее полную картину. В чем-то, можем не увидеть какие-то вектора атак. Поэтому, по возможности, их делать нужно, но в таком случае делать их нужно на тестовых стендах.

АРКАДИЙ ПРОКУДИН: Без хардкора на рабочей станции.

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: Без хардкора – да! По максимуму аккуратно, то есть тестовый стенд, идентичный промышленной системе. Как например мы проводим анализ защищенности АСУ ТП, промышленных систем. Это как правило, преимущественно, такие проверки делаются на тестовых стендах, слава Богу они как правило присутствуют, поскольку все равно нужно обкатывать новые версии систем и так далее, то есть какие-то такие вещи есть. Иногда есть возможность какие-то уязвимости верифицировать, что они присутствуют еще и в промышленной среде, если мы уже проверили их, что в тестовой системе они никаких проблем не вызывают, просто сделать скриншот, но это редкость. В принципе за рамки тестовых систем они не выходят.

АРКАДИЙ ПРОКУДИН: По твоему опыту есть какая-то разница аудита безостановочных систем (назовем их так) в промышленном производстве или в том же самом телекоме, или в том же самом процессинге банковском. Есть разница какая-то? Или подходы все одинаковые?

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: Разница есть. С промышленными системами сложней всего. Потому что, например, с точки зрения телекома, действительно, он должен действовать постоянно. Там есть своя специфика, есть свои сложности. Но, например, там можно больше применять методы анализа защищенности методом белого ящика. То есть, там например, у сетевого оборудования чаще можно взять просто конфигурацию и все понять, как что устроено. С точки зрения АСУ ТП, как правило, это какие-то такие бывают редкие системы, которые чтобы найти там что-то интересное надо сначала её как-то все таки пощупать, изучить.

АРКАДИЙ ПРОКУДИН: Наклонить правильно. Под правильным углом.

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: Да, чтобы получить не только результаты связанные с её какой-то не корректной настройкой, а именно самое интересное. То что может быть связано с какими-то уязвимостями в программном коде или, например, с возможностью выйти за пределы киоска со стороны оператора. То есть какие-то такие вещи все таки лучше пробовать руками, это как раз более рискованно.

АРКАДИЙ ПРОКУДИН: А вот при аудите тех же самых АСУ ТП систем, вся работа, я так понимаю, проводится на центре управления? Или сами элементы и инфраструктуру вы тоже проверяете?

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: Не обязательно. Мы смотрим все ключевые компоненты. Пытаемся провести мини pentest с некритичными проверками. Чтобы, например, проникнуть вообще из корпоративной сети в сеть АСУ ТП и внутри АСУ ТП мы можем смотреть, и вручную подходить к рабочим станциям оператора смотреть как, что настроено. Можем смотреть на как раз централизованную SCADA-систему и можем смотреть на контроллеры. Подключаться непосредственно к конечному оборудованию и смотреть как что устроено. Можно ли, например, подавать туда какие-то команды, что-то делать в обход централизованной системы управления.

АРКАДИЙ ПРОКУДИН:  Понятно.

АНТОН САПОЖНИКОВ: Самое смешное, что такой технический аудит не дает полной картины. Мы наблюдали, когда кнопка «критичная остановка производства» находится в свободном доступе для персонала и в принципе не важно какой там пароль стоит на системе, контроллере управляющим производством химическим. Любой желающий может подойти нажать эту кнопку и все остановится и так.

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: Да-да, безусловно проверка должна быть комплексной.

АРКАДИЙ ПРОКУДИН: Понятно. Подходя к комплексности, давайте поговорим об аудите не только техническом, но и документационном и нормативно-правовом. К этому вопросу я хотел бы перейти.

А.С Мне кажется здесь, если мы говорим про нормативно-правовую часть, то соответственно у нас есть любимые законы №152 и  № 242, для АСУ ТП это Приказ ФСТЭК №31 и прочие документы 382-П, СТО БР, в общем, у нас целая пачка всяких стандартов.

АРКАДИЙ ПРОКУДИН: Есть чему соответствовать. Найдем.

АНТОН САПОЖНИКОВ: Есть чему соответствовать, да. И там предъявляются требования которым нужно собственно соответствовать, в том числе в регуляторных внутренних документах, регламентах и прочем. Это что касается нормативно-правовой, ну собственно и документационой наверное тоже наверное в какой-то степени здесь релевантен. В основном озадачивается внимание на том, что требует регулятор.

АРКАДИЙ ПРОКУДИН: Отталкиваемся от того, что требует закон и что к нам придут проверять, правильно?

АНТОН САПОЖНИКОВ: Да.

ЮРИЙ НАУМКИН: Хотелось бы отметить, у нас очень серьезная особенность есть. У нормативно-правового аудита и документационного, то что помимо требования самих документов, существуют еще такие негласные практики того как проверяет тот или иной регулятор. И хорошо бы чтобы, команда аудиторов знала эти особенности о которых негде прочитать. Чтобы был опыт взаимодействия с этими регуляторами, потому что зачастую опыт и знания правоприменительных практик со стороны регулятора, потому что многие специалисты регулятора понимают те или иные положения нормативных документов по разному. Соответственно, если аудитор не будет знать как регулятор применяет те или иные практики, ему будет тяжело сформировать, скажем так, полезное для заказчика аудита заключение, и дать соответствующие рекомендации, если такие требуются.

АРКАДИЙ ПРОКУДИН: Евгения, мы поняли, что можно провести аудит документов на соответствие требованиями законодательства, а при проведении аудита технического, при тестах на проникновение, я не хочу сейчас рекламу какую-то рассказывать, рассказывать, что покупайте наших слонов… Набор инструментов, можно даже без названия инструментов. Набор инструментов по функционалу, который необходим аудитору, грубо говоря, если специалист по безопасности получил задание от своего руководителя сделать это самостоятельно.

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ: Что касается технического аудита, то методом технического аудита проверки не ограничиваются тестированием проникновения. Это такая некая особая категория анализа защищенности. Потому что, например, для того чтобы проводить какой-нибудь классический аудит на оценку соответствия какому-то стандарту, например, техническому стандарту ISO 27002, тоже нужны средства автоматизации зачастую. Т.е. какие-то средства для того, чтобы проверить локально настройки какого-то оборудования и так далее. Они специфичны в зависимости от цели аудита. Есть системы, чтобы проверять матрицу доступа в различных крупных ERP-системах, например, и так далее. Т. е. этим всем аудитор пользуется. Что касается тестирования на проникновение, тут на самом деле, я бы начала с того, что помимо инструментов, главный инструмент это голова аналитика. Голова эксперта. Поэтому если это просто какой-то произвольный специалист по информационной безопасности, которому сказали иди протестируй, то часто это заканчивается тем, что так к нам люди обращались. Нам сказали провести в соответствии с PCI DSS тестирование на проникновение, мы тут по сканировали и ничего не нашли, все нормально, а аудитор который собственно QSA пришел, сказал: «Что это? Разве это pentest? Просканировали и все…»

АРКАДИЙ ПРОКУДИН:  Скан-порт...

ЕВГЕНИЯ ПОЦЕЛУЕВСКАЯ:  Да-да, в принципе так и было. На что вот обратились к нам за pentest'ом. В первую очередь надо себе представлять, что это за работа и иметь некий опыт. От «балды» это не сделаешь. Что касается инструментов, которые используют эксперты в этой области. Это различные сканеры уязвимости те же самые, которые в принципе все знают. Это инструменты для первого этапа анализа защищенности. Зачастую используются специализированные системы для сбора данных, такие как FOCA, Maltego. Все данные, которые присутствуют в открытом доступе, о компании, о сотрудниках и так далее. Т.е. те системы, которые позволяют автоматизировать и находить всякие взаимосвязи с социальными сетями и так далее. Различные системы связанные с файзингом web-приложений, есть специфичные инструменты, универсальные платформы, безусловно, такие как Kali Linux и различные системы для эксплуатации уязвимостей для автоматизированного потока, сбора учетных данных и так далее. В зависимости от того, какие уязвимости мы ищем, и какие атаки используем. Здесь, с точки зрения инструментов, в принципе, если эксперт опытный, если у него есть голова на плечах, то как правило достаточно для большинства атак достаточно opensource-инструментов. В принципе в это вкладываться не нужно. Дополнительным бонусом при выборе компаний, которые будут делать pentest, является возможность проводить проверки с использованием средств более профессиональных. Например есть средство для эксплуатации уязвимостей Metasploit. Но это не панацея, потому что главное здесь, я повторюсь, это голова.

АНТОН САПОЖНИКОВ: Я бы добавил, что больше exploit в Core импактив, канвас, но у них нет бесплатных версий. Но я хотел не на этом заострить внимание, а на том, что технический аудит, это все таки тоже не про инструменты, а про методологию. Она может быть какая-то распространенная, общепринятая, типа OWASP testing guide или OSTM, так и в принципе основанная на нём, уже обработанная и отработанная экспертами какой-то локальной компании. Прежде всего, важно понимать заказчику, есть ли эта методология у эксперта, а не то, есть ли набор инструментов и будет ли он как обезьяна тыкать по всем в подряд клавишам.

АРКАДИЙ ПРОКУДИН: Очень хорошее замечание. Дать задание рядовому помощнику администратора, дать ему какую-нибудь программку на сканирование сети и сказать: «Подготовься к pentest на PCI», - нереально, если у него нет, как раз таки, методологии, по которой это все проводить. Правильно?

АНТОН САПОЖНИКОВ: Практически – да.

АРКАДИЙ ПРОКУДИН:  Вот на этой прекрасной ноте мы делаем паузу, а продолжение вы послушаете в следующем выпуске.