• Реальный Пример По Аудит Безопасности
• Реальный Пример По Аудита Безопасности

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

Лето этого года выдалось не таким жарким, как предыдущее, что касается погодных условий. Но это с лихвой компенсировалось жаркими баталиями вокруг стандартов в области информационной безопасности. Безусловно, первое место в этой номинации занимает «Закон о персональных данных». А вот второе место за стандартом платежных систем «PCI DSS». И это почетное место за ним закрепилось столь заслуженно, что в рамках обсуждения на конференции «Вопросы применения и соответствия стандартам PCI DSS/PA DSS» его даже хотели включить ссылкой в стандарт Банка России (СТО БР ИББС).

В данной статье речь пойдет как раз о стандарте PCI DSS 2.0, который обязателен для соответствия с 2012 года. О самом стандарте и комментариях к нему написано много.

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

Посмотреть на компании, как со стороны внешнего аудитора, так и изнутри в роли руководителя информационной безопасности, приводящего компанию к соответствию. Это как крупные процессинговые центры и банки, такие как «Millikart» (Баку) и «ОТП Банк» (Киев), «Общая карта» (Москва), так и совсем маленькие компании. Надеюсь, что мой опыт проведения аудитов, консалтинга и курирование проектов по приведению компаний в соответствие требованиям стандарта PCI DSS 1.2.1 и 2.0 в компаниях России, Украины и Азербайджана поможет мне простыми словами донести полезную информацию до читателей.

Накопившийся опыт и знания, наблюдения и замечания я бы хотел выразить в данной статье. Все высказанное в данной статье может значительно отличатся от мнений других аудиторов и консультантов, официальной позиции PCI Security Standards Council и других источников. Я не предлагаю неукоснительно следовать всему, о чем будет идти речь. Это всего лишь информация для принятия Вами собственных решений. Надеюсь, она поможет Вам принять правильные решения. Итак, с чего же начинается и и как проходит аудит?

Все начинается даже не с подписания договора на аудит или пред аудит. Все начинается с решения компании (читай директора) о необходимости прохождения аудита.

И тут есть два варианта развития событий: аудит необходимо пройти по требованию клиентов или платежных систем, что бывает – чаще, либо аудит инициируется и отстаивается перед директором компании (главой правления, материнской компанией) начальником отдела информационной безопасности (ИБ) - реже. В первом случае аудит спускается как «Божья кара» на сотрудников ИТ и ИБ подразделений, так как дополнительной работы добавится, в должностных инструкциях ее может и не быть, а зарплата остается на прежнем уровне. Тут все зависит от коллектива, руководителя ИБ и конкретной компании. Если коллектив удастся мотивировать, чем – это уже вопрос менеджмента и к данной статье не относится, то результат, безусловно, будет.

Результат будет, даже в том случае если персонал будет не мотивирован, но применяться будет уже иной метод – метод кнута. Но вот трудностей возникнет больше. По-иному обстоят дела, если инициатором выступает руководитель отдела ИБ. В таком случае с высокой долей вероятности процессы так или иначе уже соответствуют требованиям стандарта. Документация подготовлена, архитектура в корне не противоречит требованиям стандарта, начальник ИБ понимает, зачем это нужно.

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

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

Это как не желание «закрывая глаза» на недочеты, подвергать риску свою репутацию, так и просто неприемлемость принятия работ низкого качества. Безусловно, и они подвергаются давлению как с вашей стороны, как заказчика, так и со стороны собственного руководства.

Но данный класс экспертов больше хотят делать качественную работу, чем играть в корпоративные игры. Если есть необходимость пройти аудит, а не построить процессы (заранее говорю, что часть требований PCI DSS особенно в части документирования процессов тормозит работу самих бизнес процессов).

То лучше обратится к маленькому локальному игроку рынка. Аудиторы такой компании, как правило, более лояльны к формам реализации требований PCI DSS. Если же хочется получить не только толстый отчет, но и частичный консалтинг в рамках его проведения то однозначной рекомендации нет.

Выбирайте именно аудитора. Но окончательный выбор только за Вами. В рамках данной статьи не будет рассматриваться вопрос, по какой версии проводить аудит, так как к моменту ее публикации данный вопрос не будет актуален по причине обязательности второй версии с начала 2012 года. Что же изменилось во второй версии стандарта? Основные изменения коснулись уточнения пунктов, перегруппировки оных, вопросов выделения виртуальных инфраструктур.

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

Реальный Пример По Аудит Безопасности

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

И на этом этапе Вам может очень сильно помочь наличие документа, который я постараюсь разместить в блоге в течение недели. Данный документ был подготовлен мной, когда у меня появилась задача проведения аудита собственной компании на соответствие требования стандарта PCI DSS 2.0. Так же я проанализировал и оставил лучшее из двух переводов на русский язык самого стандарта PCI DSS 2.0: компании «Информзащита» и «Digital Security». Я постарался учесть в документе и корректные комментарии, которые были предоставлены другими специалистами по информационной безопасности.А так же добавил данные по типам требуемых проверок из документа «ROC Reporting Instructions for PCI DSS v2.0», который ощутимо облегчал работу в мою бытность аудитором. Наличие пунктов с указанием обязательности той или иной проверки может значительно сократить время и ресурсы на подготовку. Думаю, что он окажется, Вам полезен. Основные моменты, на которые стоит обратить внимание можно разделить на следующие пункты: 1.

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

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

Ознакомительные рассылки для персонала. Непрямая мотивация: сувениры по теме ИБ, конкурсы, плакаты, заставки. Как правило, последний пункт выполняется за личные деньги сотрудника, который больше всех заинтересован в результате проекта.

Это либо менеджер проектов, либо руководитель ИБ. Сюда же можно отнести заказ еды, во время пиковых фаз аудитов, закупка витаминов и противовирусных препаратов для сотрудников задействованных отделов в определенные времена года и пр. Кто-то скажет, что последний пункт больше похож на сказку и этим не стоит заниматься. Возможно, но посчитайте, каков будет ущерб от увеличения сроков аудита или простоя проектов по причине болезни ключевого сотрудника. А заразить его может кто угодно. После столь простой математической функции как умножение – времени сотрудника (его ЗП) на недополученную прибыль компании (хорошо, если не придется считать убытки), порой хочется купить ящик этих самых медикаментов и по пакету фруктов каждому.

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

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

Думаю, не стоит говорить, что нет компании, в которой бы абсолютно все было без нарушений. На то есть разные причины: слишком большие затраты на выполнение требований, нарушение или разрушение реальных бизнес процессов при исполнении требований, исторические закономерности. И тут все зависит от того, что покажут аудитору или что он увидит или найдет. Опять-таки не стоит забывать о возможности применения компенсационных мер. При подготовке к аудиту, безусловно, необходим человек компетентный в области аудита и стандартов, или тот, кто быстро может стать таковым (специалист смежной сферы). Так как аудиторам и представителям компании крайне желательно понимать друг друга, обладать высоким уровнем компетенций в сфере подлежащей аудиту. Когда проектом по прохождению аудита соответствия руководит не мотивированный и некомпетентный в вопросах проектного менеджмента и стандартов ИБ человек вероятность его успешного прохождения стремится к 0.

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

Необходимо, что бы все процессы подлежащие документированию в рамках требований PCI DSS (предоставленный документ Вам в помощь, там четко указано в каких случаях это необходимо) были документированы. Из нюансов рекомендую обратить внимание, что это чревато тем, что большинство процессов так и останутся только на бумаге.

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

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

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

Кстати, это можно автоматизировать. Я писал об этом, когда рассматривал вопрос «Построение процессов управления уязвимостями и соответствием» 4. Для проведения внутренних сканирований достаточно использовать любой более-менее качественный сетевой сканер с последними обновлениями. И разворачивать целый комплекс по управлению сетевыми уязвимостями в рамках соответствия PCI DSS совсем не обязательно. А вот что обязательно – это обработка результатов сканирования.

Все уязвимости, которые не могут быть устранены должны быть проанализированы. И если уязвимость обнаружена не ошибочно, для нее должны быть разработаны и внедрены компенсационные меры. Что же касается ежеквартального сканирования внешнего периметра (ASV) то достаточно просто купить лицензию на необходимое количество IP и проводить 4 раза в год сканирование самостоятельно. Естественно – это для тех случаев, когда у Вас нет уязвимостей в сканируемой инфраструктуре. А их не должно быть. В рамках подготовки к тесту на проникновение по приоритетности я бы выделил следующие особенности: - Донесение до сотрудников компании, что можно, а чего делать нельзя. Контроль мест хранения карточных данных.

Обновление систем. Именно в этой последовательности, как правило, возникают проблемы в рамках теста на проникновение. Обучение сотрудников является неотъемлемой частью улучшения безопасности. Но вот если у вас не все процессы, прописанные на бумаге, работают в действительности, то это как раз возможность рассказать сотрудникам кому и как они должны отвечать на вопросы. Что бы в рамках интервьюирования сотрудников не выяснилось что далеко не все процессы, отраженные на бумаге используются в действительности. Что касается планов реагирования, то если за текущий отчетный период они применялись нужно подготовить свидетельства. В противном случае – провести тестирование планов реагирования по результатам - составить акты.

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

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

Так как ни для одного из привлеченных отделов (может быть за исключением отдела безопасности) проект не является приоритетным. А поскольку основные проекты для задействованных подразделений ни кто не планирует останавливать, то отношения ждите соответствующего. А если Вы не заручились поддержкой руководства в этом вопросе Но не будем о грустном. Я являюсь сторонником ведения проектов по методологии PMBook, правда, позволяя себе сократить иногда количество отчетных бумажек. Данная методология позволяет корректно вести проекты и очень много вопросов, которые будут возникать у Вас в процессе ведения проекта уже предусмотрены заранее. Вот только если Вы с ней не знакомы, то потребуется время на ознакомление с ней и ее апробацию.

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

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

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

И еще опыт и крупицы знаний. Которые как раз можно почерпнуть в том числе, например из статей в профильной прессе.

Реальный Пример По Аудита Безопасности

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

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

Так как, услышав хоть какое-то несоответствие, аудитор обязательно распутает клубок – можете не сомневаться. Перед аудитом будьте готовы к тому, что как бы вы все не планировали, вы не успеете устранить все несоответствия и выполнить все задачи которые хотели к запланированным срокам. Так как в компании происходят непрерывные внесения изменений в системы, процессы, случаются авралы (обязательно в самый неподходящий момент), а сотрудникам кроме подготовки к аудиту нужно выполнять свои функциональные задачи. Рекомендую обязательно при планировании в зависимости от уровня зрелости процессов, загрузки сотрудников и своей сферы влияния закладывать от 10 до 35% дополнительного времени на риски. Да вот еще, что касается решений, которые рекомендуют компании по результатам аудита. Нужно понимать что, как правило, компании, которые проводят аудит, имеют подразделения, которые занимаются внедрением определенных решений и систем.

И можете не сомневаться, что не зависимо от их соответствия в полной мере вашим требованиям, рекомендовать к внедрению будут именно их. Просто имейте это виду. Ничего страшного в этом нет.

Если подразделение компании обладает реально выполненными успешными проектами, а данное решение и цена за услуги вас устраивает – смело соглашайтесь. Просто имейте виду, что не стоит слепо полагаться на рекомендации и внедрять дорогостоящие системы, что бы пройти аудит и забыть о них до следующего года. Не воспринимайте аудитора как врага. Воспринимайте его как союзника. Часто, результаты аудита могут показать руководству, что у вас действительно не хватает ресурсов, технологий или бюджета, и что это не вы сами придумали необходимость наличия бесполезных «игрушек» для ИТ или ИБ. Смело говорите об этом аудитору, пусть пишет в отчете. Но помните, такое можно говорить при предварительном аудите или экспертном аудите, но уж ни как не как несоответствие, на сертификационном.

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

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

Ниже мы опишем несколько реальных заказов на аудит компьютерной безопасности. Заказ 1: ICQ Заказчик Куваев (здесь и далее фамилии и информация, позволяющая идентифицировать фамилии, изменены) - сотрудник крупнооптовой фирмы-импортера компьютерных комплектующих, работает старшим менеджером по закупкам в США. Традиционно бо,льшая часть переговоров Куваева с партнерами происходит по ICQ. Руководство фирмы прочитало в газете 'Известия', что программа ICQ - ненадежная.

Учитывая, что список американских компаний, у которых закупается товар, есть информация конфиденциальная, цены и объемы закупок - средне-конфиденциальная, а из фирмы недавно со скандалом ушел один из ключевых сотрудников, руководство решило провести аудит компьютерной безопасности. Перед экспертом был поставлен вопрос: что может сделать враг с бюджетом в $1000? Изучение ситуации показало, что ICQ-номер Куваева зарегистрирован больше семи лет назад.

При регистрации нужно было указывать e-mail-адрес. Вероятно, в тот момент у Куваева не было e-mail-адреса или он не хотел его давать, - так или иначе, был указан адрес qwert(гав-гав)lkjlkj.asdfsdfs.com. Предположительно, Куваев набрал на клавиатуре случайную последовательность символов, выглядящую как e-mail-адрес (даже доменного имени asdfsdfs.com не существовало).

Атака состояла в регистрации доменного имени asdfsdfs.com, создании в домене компьютера lkjlkj.asdfsdfs.com и заведении на нем пользователя qwert; после этого в фирму Mirabilis (владельцы системы ICQ) была направлена просьба выслать якобы утраченный пароль на адрес, указанный при регистрации, что и было выполнено. Зная пароль, можно его сменить (то есть сделать невозможным пользование данным номером для легального адресата), а можно и получать всю текущую информацию от многочисленных поставщиков. Если бы атака была проведена врагом, как подсказал нам Куваев, враг мог уведомлять соединяющихся по ICQ поставщиков об изменении адреса склада в Финляндии и просить их срочно перенаправить поток грузов по новому адресу. Учитывая объемы поставок и принятую в этом бизнесе оплату с отсрочкой 60 суток после получения товара, враг мог неплохо поживиться и создать немало проблем организации, в которой работает Куваев Демонстрация уязвимости была осуществлена за двое суток, расходы по осуществленному пути составили $150. В Москве есть десятки организаций, способных осуществить такую атаку. Заказ 2: Кража информации из замкнутого помещения Специфика работы заказчика была такова, что клиенты в офис не приходили, а деятельность в целом носила сугубо конфиденциальный характер.

Перед аудитором был поставлен вопрос: может ли враг, располагающий суммой в $5000, украсть какие-либо данные. Персонал заказчика о мероприятиях уведомлен не был. Изучение ситуации показало, что физическая защищенность офиса исключает проникновение посторонних лиц; подкуп сотрудников тоже был маловероятен, благодаря специфике их подбора по национальному признаку и личной преданности заказчику. Удачной оказалась следующая атака: Наружное наблюдение позволило предположить, что системный администратор заказчика Чхеидзе увлекается мексиканскими народными песнями. Это было подтверждено осмотром открытых форумов Рунета, где Чхеидзе размещал сообщения по данной теме под своей фамилией. Сообщения Чхеидзе в форумах были проанализированы.

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

Основной удар планировался по линии продажи ему, как 'первому правильно ответившему на все три вопроса', за $20 слегка модифицированного 'фирменного' диска, которого в продаже в России не было и о цене которого в США ($110) Чхеидзе не раз сожалел в форумах. Но аудитору повезло - удалось обойтись более простыми средствами. На рабочем компьютере Чхеидзе был установлен Internet Explorer 5.01, хоть и с SP1, но без заплатки Q275609. Поэтому, пока Чхеидзе наслаждался музыкой и переписывал с сайта файлы, сайт переписал несколько файлов с сетевых дисков заказчика.

Показательна реакция руководства на демонстрацию распечаток файлов - побледневший начальник, не дожидаясь объяснений, позвонил в службу безопасности и потребовал организовать полную сверку журналов входа/выхода сотрудников с видеозаписью. Демонстрация уязвимости была осуществлена за девять суток, прямые расходы по осуществленному пути составили $1200. В Москве есть организации, способные осуществить такую атаку.

Заказ 3: Враждебный клиент Заказчик Петренко - работающий индивидуально консультант по таможенным вопросам. Важную информацию к клиентам и от них он, не доверяя Интернету, переносил в наручных часах, в которые было встроено устройство с энергонезависимой flash-памятью и USB-интерфейсом (далее - флэшка). Данные на флэшке - сугубо конфиденциальны.

Содержимое шифровалось идущим в комплекте с флэшкой программным обеспечением. Перед экспертом был поставлен вопрос: насколько такой способ гарантирует сокрытие данных в случае потери или физического изъятия флэшки при бюджете врага $2000? Изучение ситуации показало, что Петренко неправильно оценивает слабое место в системе. К одному из своих клиентов Петренко сел в машину, благодаря чему выяснилось, что клиента зовут Вахитов Сергей Рустемович. Заказчику позвонил сотрудник эксперта Дятлов, которого Петренко не знал в лицо. Он представился живущим в Норильске другом Сережи Вахитова, который якобы дал Дятлову телефон Петренко и посоветовал обсудить с ним свои таможенные проблемы. Дятлов рассказал выдуманную проблему с таможней, подобранную внешним специалистом по просьбе эксперта так, чтобы на ее решении консультант мог немало заработать и получить постоянного клиента.

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

На следующий день ничего не подозревающему Петренко были предъявлены и пароль, и все его файлы. Удивленный, он лишь огорченно вымолвил: 'Черт возьми, я так и думал, что она не просто так на ночь старалась остаться. Но как ей удалось открыть сейф?!' Демонстрация уязвимости была осуществлена за шесть суток, прямые расходы по осуществленному пути составили $800. В Москве есть десятки организаций, способных осуществить такую атаку. Заказ 4: Куда уходит Интернет?

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

Также исследование показало, что один из компьютеров без ведома Левитова использовался в качестве сервера для хранения и распространения фотографий и видеозаписей порнографического содержания. Кто именно организовал порносервер, выяснить не удалось, но счета за Интернет оплачивал Левитов. Заказ 5: Что русскому хорошо, то немцу смерть Российская компания, обслуживавшая компьютерный парк крупного корпоративного клиента, использовала программный комплекс автоматизации предприятий, поставляемый одной из ведущих немецких софтверных фирм. Руководство компании обдумывало поступившее от немецкой стороны предложение стать их эксклюзивными представителями на территории России и стран СНГ по системам САПР, дававшее возможность выйти с этими продуктами на рынок других корпоративных клиентов. План предусматривал значительные затраты как в виде платежей немецкой стороне, так и в виде вложений в России. Руководство компании поставило перед экспертом вопрос: верно ли утверждение немецкой стороны о невозможности взлома защиты данной программы и записи ее на пиратский CD? Бюджет врага был оставлен на усмотрение эксперта и задан как 'типичный для пирата'.

Исследование показало, что уровень цен на базовый модуль САПР данной фирмы в Германии составляет около 15000 евро (лицензия на десять пользователей), и каждый дополнительный модуль стоит от 700 до 4000 евро. Для домашнего пользователя программа интереса не представляет. Отсюда был сделан вывод о малой вероятности попадания программы к пиратам путем ее закупки и взлома легальной версии.

Однако вероятным является приобретение крупной компанией лицензии на десять пользователей, взлом защиты усилиями своих или сторонних специалистов и установка программы внутри компании на значительное число компьютеров. После этого при неблагоприятном стечении обстоятельств можно ожидать появления взломанного дистрибутива и у пиратов. Исходя из этого, бюджет проекта был оценен в $5000. Изучение предоставленного заказчиком дистрибутива показало, что для защиты используется комплекс, состоящий из двух частей: программной защиты, сделанной специалистами фирмы-разработчика, и ключа HASP фирмы Aladdin для LPT-порта. Как известно, некий хакер из Санкт-Петербурга еще в 2000 году написал низкоуровневый драйвер ключа HASP, который устанавливается на место стандартного драйвера и самостоятельно обрабатывает вызовы к ключу.

Однако фирма-разработчик либо не знала об этом, либо не сочла возможным приобрести новую версию HASP (для которой общеизвестного пути взлома по состоянию на сегодняшний день нет). Изучение программной защиты, написанной специалистами фирмы-разрабочика, показало, что она заключается в привязке к MAC-адресу сетевой карты (MAC-адрес представляет собой уникальный шестнадцатеричный серийный номер, назначаемый каждому сетевому устройству Ethernet для идентификации его в сети, например 12:34:56:78:90:AB). Атака на эту защиту состояла в установке второй сетевой карты, в которой можно изменять MAC-адрес (такие, вопреки стандарту и общественному мнению, существуют). Таким образом, было выяснено, что при наличии дистрибутива данной программы и одного HASP-ключа ее можно инсталлировать на любое количество компьютеров. Поточные расходы состоят в установке в каждый из компьютеров дополнительной сетевой карты стоимостью $10 (при инсталляции клиент-серверной версии дополнительную карту нужно вставлять только в сервер).

Эмулятор ключа можно записать на CD (то есть можно изготовить дистрибутив, позволяющий инсталлировать программу без оригинального носителя и без доступа к ключу HASP). Демонстрация уязвимости была осуществлена за пять суток, прямые расходы по осуществленному пути составили $500. В Москве есть организации, способные осуществить такую атаку. Заказ 6: Подмена системного администратора Заказчик - частная организация, созданная на базе существовавшей в СССР государственной структуры и участвующая в конкурсах на выполнение госзаказа. Перед экспертом был поставлен вопрос о том, может ли враг получить доступ к материалам конкурсной заявки при бюджете в $10000. Исследование показало, что здание, в котором расположена структура, по старой памяти охраняется вооруженными часовыми и войти в него непросто.

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

Один из провайдеров был небольшой организацией. Атака была произведена следующим образом: Преснякова, сисадмина мелкого провайдера, переманили на другую работу (представитель дружественной организации написал ему письмо с хвалебным комментарием статьи последнего в журнале 'Connect', завязалась переписка, в результате которой Преснякову предложили такую зарплату, от которой невозможно отказаться). Руководство провайдерской компании срочно стало искать нового сисадмина, в частности, дав об этом объявление на job.ru. К ним пришел на беседу человек, которого было невозможно не взять, особенно с учетом его склонности получать удовольствие от решения проблем, а не от большой зарплаты. Спустя сутки 'засланный казачок' наладил копирование всей внутренней почты, идущей, как вы помните, через провайдера. Полного текста искомой заявки в e-mail’ах не оказалось, но нашлись ее существенные куски.

Попутно обнаружились: два факта воровства; шантаж одного сотрудника другим; не известный руководству факт болезни ребенка одного из важных сотрудников (ребенку была нужна операция, которую делают в Израиле за $60000, а сотрудник имел право подписывать финансовые документы); фотография сотрудницы, использующей рабочее место для осуществления неподобающего поведения по отношению к неустановленному мужчине. Демонстрация уязвимости была осуществлена за восемнадцать суток. Прямые расходы по осуществленному пути составили $4800. В Москве есть организации, способные осуществить такую атаку.