Чем отличается проблема от инцидента. Описание ключевых процессов управления ит-услугами
5.3.1 Обработка Инцидента.
Большинство ИТ-подразделений и специализированных групп в той или иной степени вовлечены в обработку Инцидентов. Служба Service Desk отвечает за мониторинг процесса разрешения всех зарегистрированных Инцидентов и фактически является владельцем всех Инцидентов. Этот процесс в большей части работает по принципу реагирования. Для того чтобы продуктивно и эффективно реагировать, требуются формальные методы работы, которые могут поддерживаться программными средствами.
Инциденты, которые Служба Service Desk сразу не может разрешить, могут быть переданы для обработки одной из специализированных групп. Разрешение или Обходное решение должно быть представлено в максимально короткие сроки для того, чтобы восстановить обслуживание Пользователей с минимальным влиянием на их работу. После устранения причины Инцидента и восстановления согласованной услуги Инцидент закрывается.
На Рисунке 5.2 показаны процессы, происходящие в течение жизненного цикла Инцидента. В Приложении 5Д эти процессы представлены с другой точки зрения.
Рисунок 5.2 - Жизненный цикл Инцидента.
Статус Инцидента отражает его текущее положение в жизненном цикле, иногда называемое «позицией в диаграмме последовательности выполняемых действий». Каждый сотрудник должен знать все возможные статусы и их значения. Несколько примеров категорий статусов:.
■ новый;.
■ принят;.
■ определены сроки;.
■ назначен/передан специалисту;.
■ в работе (Work In Progress, WIP);.
■ ожидание;.
■ разрешен;.
■ закрыт.
В течение жизненного цикла Инцидента важно, чтобы запись о нем поддерживалась в актуальном состоянии. Это позволит любому сотруднику группы обслуживания предоставлять Заказчику самые свежие данные о ходе обработки запроса. Некоторые примеры действий по обновлению записей:.
■ обновить исторические сведения;.
■ изменить статус (например, со статуса «новый» на статус «в работе» или «ожидание»);.
■ изменить влияние на бизнес и приоритет;.
■ ввести потраченное время и затраты;.
■ отследить статус эскалации.
Описание, первоначально заявленное Заказчиком, может измениться по ходу жизненного цикла Инцидента. Тем не менее, важно оставить описание исходных симптомов как для анализа, так и для того, чтобы можно было ссылаться на жалобу, используя формулировки, содержащиеся в первоначальном запросе. Например, Заказчик мог заявить, что не работает принтер, а было определено, что неполадка была вызвана сбоем в сети. При ответе Заказчику сначала лучше объяснить, что Инцидент с принтером разрешен, вместо того чтобы говорить о разрешении проблем с сетью.
Проверенная история Инцидента необходима при анализе хода его обработки, особенно это важно при разрешении вопросов, связанных с нарушением SLA. В ходе жизненного цикла Инцидента следует регистрировать следующие обновления записи о нем:.
■ имя человека, сделавшего изменение в записи;.
■ дата и время изменения;.
■ что именно этот человек изменил (например, приоритет, статус, историю);.
■ почему было внесено изменение;.
■ потраченное время.
Если внешним поставщикам запрещено обновлять записи Службы Service Desk (что и рекомендуется), тогда необходимо определить процедуру обновления записей за поставщика. Это гарантирует надлежащий учет использованных ресурсов. Тем не менее, если программное обеспечение допускает возможность выделить класс Инцидентов, устраняемых внешними поставщиками, и проводить предварительную проверку введенной информации, то в некоторых организациях может оказаться весьма удобным разрешить внешним поставщикам обновлять информацию напрямую. В случае принятия такого решения вам необходимо определить, какую информацию вы не готовы предоставить поставщику и насколько подробно вы должны быть информированы о действиях поставщика.
Такая же ситуация может возникнуть, когда Служба Service Desk обновляет запрос вместо специалиста службы технической поддержки, находящегося вне офиса. Иногда может понадобиться обновить учетную запись Инцидента постфактум, например, если специалисты работают в вечернее время, а Служба Service Desk должна обновлять записи вместо них на следующее утро.
5.3.2 Первая, вторая и третья линии поддержки.
Часто подразделения и (специализированные) группы поддержки, не входящие в состав Службы Service Desk, называются группами поддержки второй или третьей линии. Они обладают более специализированными навыками, дополнительным временем или другими ресурсами для разрешения Инцидентов. Исходя из этого, Служба Service Desk называется первой линией поддержки. На Рисунке 5.3 показано, как эта терминология связана с действиями в процессе Управления инцидентами, о которых говорилось в предыдущих параграфах.
Заметьте, что третья и/или N-я линия поддержки могут со временем включать внешних поставщиков, которые могут иметь прямой доступ к средствам регистрации Инцидентов (в зависимости от правил безопасности и технических вопросов).
Рисунок 5.3 ~ Первая, вторая и третья линии поддержки.
5.3.3 Сравнение функциональной и иерархической эскалации.
«Эскалация» - механизм, способствующий своевременному разрешению Инцидента. Он может сработать на любом этапе процесса разрешения.
Передача Инцидента от групп поддержки первой линии к группам поддержки второй линии или дальше называется «функциональной эскалацией» и происходит по причине недостатка знаний или квалификации. Предпочтительно, чтобы функциональная эскалация происходила в случаях, когда истекает согласованное время, отведенное на разрешение Инцидента. Автоматическая функциональная эскалация, которая вызывается по истечении определенного периода времени, должна быть тщательно спланирована и не должна превышать согласованное (в SLA) время разрешения.
«Иерархическая эскалация» может произойти в любой момент процесса разрешения, если существует вероятность того, что разрешение Инцидента не удастся завершить вовремя или оно окажется неудовлетворительным. В случае, если не хватает знаний или квалификации, иерархическая эскалация обычно производится вручную (Службой Service Desk или другим персоналом поддержки). Возможность проведения автоматической иерархической эскалации может рассматриваться после некоторого критичного периода времени, когда становится очевидным, что своевременно разрешить Инцидент не удастся. Предпочтительно, чтобы эскалация происходила задолго до истечения времени, отведенного (в SLA) на разрешение. Это позволит линейному руководству, имеющему соответствующие полномочия, принять меры по исправлению ситуации, например нанять специалистов внешнего поставщика.
5.3.4 Приоритет.
Приоритет Инцидента первоначально определяется его влиянием на бизнес и срочностью, с которой необходимо обеспечить разрешение или Обходное решение. Целевые показатели для разрешения Инцидентов или обработки запросов обычно включаются в SLA. На практике целевые показатели разрешения Инцидентов часто связаны с категориями. Примеры категорий и приоритетов, а также систем их кодирования, можно найти в Приложениях 5А и 5Б соответственно.
Службе Service Desk отводится важная роль в процессе Управления инцидентами:.
■ обо всех Инцидентах сообщается в Службу Service Desk, и ее сотрудники регистрируют Инциденты; в случаях, когда Инциденты генерируются автоматически, процесс все равно должен включать регистрацию через Службу Service Desk;.
■ основная масса Инцидентов (возможно, до 85% при высоком уровне навыков персонала) будет разрешена Службой Service Desk;.
■ Служба Service Desk - «независимое» подразделение, которое наблюдает за ходом разрешения всех зарегистрированных Инцидентов.
Ниже приведен перечень основных действий, которые выполняются Службой Service Desk после получения уведомления об Инциденте:.
■ запись основных сведений - включая время и полученные подробности о симптомах;.
■ если сделан запрос на обслуживание, заявка обрабатывается в соответствии со стандартными процедурами в данной организации;.
■ для дополнения записи об Инциденте на основе CMDB происходит выбор Учетных элементов (УЭ), являющихся, по сообщению, причиной Инцидента;.
■ установка соответствующего приоритета и передача Пользователю уникального номера Инцидента, автоматически генерируемого системой (чтобы сообщать его при дальнейших обращениях в службу);.
■ оценка Инцидента и, по возможности, предоставление рекомендаций по его разрешению: часто это возможно для стандартных Инцидентов или, когда его причиной является известная Проблема/ошибка;.
■ закрытие записи об Инциденте после его успешного разрешения: добавление сведений о действиях, связанных с разрешением, и установка соответствующего кода категории;.
■ передача Инцидента группе поддержки второй линии (т.е. специализированной группе) после неудачной попытки разрешения или при выяснении того, что необходим более высокий уровень поддержки.
5.3.5 Связи между Инцидентами, Проблемами, Известными ошибками и Запросами на Изменение (RFC).
Инциденты, возникшие в результате отказов или ошибок в ИТ-инфраструктуре, приводят к реальным или потенциальным отклонениям от запланированной работы ИТ-услуг.
Причина Инцидентов может быть очевидна, и тогда для устранения этой причины не потребуется дальнейшее расследование. В результате будет проведен ремонт, определено Обходное решение или оформлен RFC, который исправит ошибку. В некоторых случаях устранить сам Инцидент - т.е. его влияние на Заказчика можно довольно быстро. Возможно, просто требуется перезагрузка компьютера или повторная инициализация канала связи без выявления причины, лежащей в основе Инцидента.
В случаях, когда исходная причина Инцидента неизвестна, возможно, следует оформить запись о Проблеме. Таким образом, Проблема на самом деле является показателем неизвестной ошибки в инфраструктуре. Обычно запись о Проблеме оформляется только тогда, когда необходимость ее расследования оправдана серьезностью проблемы.
Влияние такой Проблемы часто будет оцениваться на основе влияния (как реального, так и потенциального) на бизнес-услуги, а также на основе числа заявленных похожих Инцидентов, которые, возможно, имеют одну и ту же исходную причину. Создание учетной записи Проблемы может быть уместно даже тогда, когда последствия Инцидента были устранены. Следовательно, запись о Проблеме может рассматриваться независимо от связанных с ней записей об Инцидентах, и как запись о Проблеме, так и расследование ее причины может продолжаться даже после того, как первоначальный Инцидент был успешно закрыт.
Успешная обработка записи о Проблеме приведет к идентификации корневой ошибки; эта запись может стать записью Известной ошибки после того, как разработано Обходное решение и/или RFC. Эта логическая цепочка, от первоначального уведомления до разрешения исходной проблемы, показана на Рисунке 5.4.
Рисунок 5.4 - Связи между Инцидентами, Проблемами, Известными ошибками и Запросами на Изменение (RFC).
Таким образом, мы имеем следующие определения:.
■ Проблема: неизвестная исходная причина одного и более Инцидентов.
■ Известная ошибка: Проблема, которая успешно диагностирована и для которой известно Обходное решение.
■ RFC: Запрос на Изменение любого компонента ИТ-инфраструктуры или любого аспекта ИТ-услуг.
Проблема может привести к множеству Инцидентов; также возможно, что Проблема не будет диагностирована до тех пор, пока не случится несколько Инцидентов в какой-нибудь период времени. Обработка Проблем значительно отличается от обработки Инцидентов и, следовательно, описана процессом Управления проблемами.
Во время процесса разрешения Инцидент проверяется на наличие связей в базе данных Проблем и Известных ошибок. Его также следует проверить на наличие связей в базе данных Инцидентов, чтобы определить, существуют ли похожие незакрытые Инциденты, и были ли разрешены предыдущие похожие Инциденты. Если уже доступно Обходное решение или разрешение, Инцидент может быть сразу же разрешен. В противном случае, процесс Управления инцидентами несет ответственность за разрешение или поиск Обходного решения с минимальным прерыванием бизнес-процесса.
Когда процесс Управления инцидентами находит Обходное решение, оно будет проанализировано командой Управления проблемами, которая потом обновит соответствующую запись о Проблеме (см. Рисунок 5.5). Необходимо отметить, что соответствующая запись о Проблеме может в этот момент еще не существовать например, Обходное решение может состоять в том, чтобы отослать отчет по факсу из-за сбоя в канале связи, но записи о Проблеме по поводу этого сбоя в канале связи может еще не быть; в этом случае команда Управления проблемами должна ее создать. Итак, в процесс входят действия, когда Служба Service Desk связывает Инциденты, которые являются результатом зарегистрированной Проблемы.
Рисунок 5.5 - Обработка Обходных решений и разрешений инцидента.
Также возможно, что группа Управления проблемами во время расследования Проблемы, связанной с Инцидентом, найдет Обходное решение или разрешение самой Проблемы и/или некоторых связанных с ней Инцидентов. В этом случае группа Управления проблемами должна сообщить об этом процессу Управления инцидентами для того, чтобы изменить статус открытых Инцидентов на «Известная ошибка» или «Закрыт».
Когда во время регистрации Инцидента предполагается, что этот Инцидент должен рассматриваться как Проблема, тогда он должен быть сразу же направлен на рассмотрение в процесс Управления проблемами, где, при необходимости, оформляется новая запись о Проблеме. Процесс Управления инцидентами будет, как всегда, нести ответственность за продолжение работы по разрешению Инцидента для минимизации его влияния на бизнес-процессы.
В России сложилась интересная ситуация с расследованием инцидентов в сфере информационной безопасности. Большинство инцидентов замалчивается - если, конечно, дело не касается банковских счетов и финансовых транзакций. Администраторы и служба ИБ (если она есть) пытаются предпринять какие-то меры, затем все отчитываются перед руководством и об инциденте забывают. О полноценном расследовании речи, как правило, не идет, потому что либо безопасностью заниматься в компании просто некому, либо есть отдел, который разработал политику безопасности, внедрил современные технические средства, но этим и ограничивается. Ликвидация последствий сводится к смене чувствительной информации, такой как пароли и ключи, переустановке пары-тройки операционных систем (не всегда тех, которые необходимо).
Если следовать букве закона, когда обнаруживается инцидент информационной безопасности, нужно обращаться в государственные органы правопорядка. Но коммерческие структуры редко на это идут: мало того что приходится открыто признаться в собственном косяке, так еще и возникает множество вопросов - лицензионный ли софт, обеспечиваются ли меры, требуемые регуляторами… Потому у плохих ребят складывается ложное ощущение абсолютной безопасности, особенно если эти ребята занимаются взломом ради морального удовлетворения, а не ради коммерческой выгоды. Об одном таком случае я и расскажу в этой статье.
ТТХ
Компания N достаточно прогрессивна в своей сфере, поэтому внутреннее обеспечение службы ИТ на высоте: хорошие средства коммуникации, современное оборудование, приличные зарплаты. В свое время была создана служба безопасности, курирующая вопросы информационной, экономической и физической безопасности. Приглашенный подрядчик помог построить защищенную ИТ-инфраструктуру и ввести режим коммерческой тайны.
IT-инфраструктура представляет собой следующее:
- серверы располагаются в демилитаризованной зоне, доступ по сети в ДМЗ ограничивается межсетевыми экранами;
- повсеместно введена виртуализация серверов;
- присутствует сегментация сети с ограничением доступа между сегментами. Рабочие станции разнесены по VLAN’ам, с фильтрацией трафика между ними, в соответствии с внутренней иерархией;
- права доступа пользователям выделяются по принципу минимальных привилегий;
- централизовано софт обновляется только для продуктов Microsoft;
- ведется централизованный мониторинг серверов, правда, в основном с позиции доступности.
Инцидент
В начале года костяк топ-менеджмента компании N отправился на корпоративный выезд в далекие страны. Поездка предполагала не только развлечения, но и рабочие моменты, однако им не суждено было состояться: материал, который планировали презентовать и обсудить по-современному - с мобильного планшета, был утерян.
Прекрасное солнечное утро омрачилось: смартфоны и планшеты всех собравшихся в отеле на берегу океана (и не только их) оказались девственно чисты.
Данная информация была доведена до службы безопасности, которая разумно предположила, что тут не обошлось без внешнего вмешательства. Очевидно, что у всех сразу аккаунты iCloud взломать не могли, и служба безопасности заподозрила, что угроза исходит из корпоративной сети. Удаленно очистить мобильные устройства можно только через соответствующий сервис, например через корпоративный сервер Microsoft Exchange. Команда, позволяющая очистить устройство пользователя с адресом [email protected], выглядит следующим образом:
Clear-MobileDevice -Identity WM_TonySmith -NotificationEmailAddresses "[email protected]"
ИТ-службе поставили задачу проверить журналы сервера OWA: не было ли подозрительной активности в отношении аккаунтов пострадавших и компрометации пароля администратора сервера MS Exchange. Администраторы обнаружили зацепку - доступ к аккаунтам пострадавших в предшествующие инциденту дни неоднократно осуществлялся с нескольких нетипичных для них IP-адресов. Как я позже выяснил, засвеченные IP-адреса были выходными Tor-нодами.
Анализ логов OWA
Логи OWA хранятся по умолчанию в %SystemRoot%\System32\logfiles\w3svc1 . Структура логов - обычные текстовые файлы, изучать которые без вспомогательного инструмента, особенно при большом количестве пользователей, утомительно. На помощь придет Log Parser - очень ценный инструмент, который пригодится не только в подобной ситуации.
Для удобства преобразуем все имеющиеся логи в один файл формата CSV:
C:\Program Files\Log Parser 2.2>LogParser.exe -i:iisw3c "select * into d:\temp\alllog.log from %SystemRoot%\System32\logfiles\w3svc1\*" -o:csv
После чего составим список событий, отражающих доступ пользователей к OWA:
C:\Program Files\Log Parser 2.2>LogParser.exe -i:csv "select cs-username, date,time, c-ip, cs-uri-stem, cs(User-Agent) FROM d:\temp\alllog.log to d:\temp\access.csv" -o:csv
Выясняем, кто обращался к функциям OWA, отвечающим за удаление данных с устройства:
C:\Program Files\Log Parser 2.2>LogParser.exe -i:csv "select cs-username, date, time, c-ip, cs-uri-stem, cs-uri-query, cs(User-Agent) FROM d:\temp\alllog.log to d:\temp\access2.csv WHERE cs-uri-query LIKE "%wipe%"" -o:csv
Судя по системным логам, аккаунт администратора сервера OWA скомпрометирован не был. Целый день админы читали логи серверов, а служба безопасности тем временем беседовала со всеми админами по очереди, предполагая, что диверсант внутри компании. Однако это ни к чему не привело. Тогда они обратились по старому знакомству ко мне.
Поставили они такие задачи:
- установить источник угрозы - внутренний или внешний;
- выяснить сценарий атаки;
- определить последствия - скомпрометированные аккаунты и системы;
- определить дальнейшие действия для ликвидации угрозы.
Оказавшись на месте, я опросил ИТ-персонал. По итогам составил схему сети, определил расположение серверов и сервисов, собрал информацию об используемых операционных системах, настройке межсетевых экранов, парольной политике, политике обновления софта, персональных зонах ответственности администраторов.
Перепроверил результаты анализа логов администраторами. С помощью ntfswalk проанализировал MFT на наличие удаленных в последнее время файлов. Сервер OWA был чист и нетронут.
Так как скомпрометированы были пароли нескольких сотрудников сразу, я решил, что начать надо с того места, где хранятся пароли. Любой хакер, попадая в корпоративную сеть, сперва спешит полакомиться хешиками. Вопрос этот избитый, и детали получения хешей, думаю, знают все. Такой сценарий надо отработать первым - как наиболее вероятный. В данном случае доменная авторизация была настроена почти на всех устройствах, за исключением сетевого оборудования и Linux-серверов. Исходя из этого, я решил обследовать контроллеры домена.
Первым делом настроил отдельный сервер, на который стали зеркалировать трафик с потенциально скомпрометированных узлов и трафик, циркулирующий через шлюзы, в интернет. Подобные данные могут пригодиться в дальнейшем для выявления несанкционированного доступа.
Я получил актуальные копии виртуальных машин и начал с ними разбираться. Подключив виртуальные жесткие диски к своей системе, запустил процесс восстановления данных - есть вероятность обнаружить удаленные логи файлов, которые использовал злоумышленник. Для этого можно взять любой удобный софт для восстановления данных, результат будет примерно одинаков. Я предпочитаю R-Studio.
Так как у меня в исследовании были только образы виртуальных машин, процедура несколько упрощалась - не нужно тратить время на снятие образов жесткого диска и оперативной памяти. Файлы жестких дисков виртуальных машин можно либо конвертировать в raw , либо монтировать как есть, с помощью соответствующих утилит. Образ RAM и файл сохраненного состояния можно сконвертировать в «сырой» образ. Не стоит забывать и про файлы подкачки - в них тоже порой находится много интересного. Volatility версии 2.3 умеет все это разбирать и конвертировать в случае необходимости.
Отличия работы с физической системой от виртуальной в том, что образ памяти заполучить сложнее - это связано с риском повредить текущее состояние и потерять данные, которые могут оказаться существенными. Также при исследовании физической системы необходимо применять дополнительные инструменты и методики для определения скрытых областей (например, Host Protected Area - HPA и Device Configuration Overlay - DCO).
Обследовать Windows-машины в моем случае я решил по следующему сценарию:
Помимо этого, можно извлечь содержимое процесса в файл для дальнейшего исследования.
След найден
В оперативной памяти одного из контроллеров домена обнаружились явные признаки компрометации:
- процесс svchost.exe запущен из C:\Windows\WOW64 , а не из System32 , как ему полагается;
- исходящие сетевые соединения, на IP-адрес частного хостинга в Штатах;
- неизвестный процесс запущен с PPID , не отображающимся в списке процессов.
Процесс был идентифицирован с помощью утилиты vol.exe .
Vol.exe pslist -f image.vmem --profile=Win2008R2SP1x64 >pslist Offset(V) Name PID PPID 0xfffffa801996cb30 spintlx64.exe 2820 1388 ....
Но PID 1388 больше нигде не значился, что всегда очень подозрительно. В первую очередь необходимо было извлечь тело этого процесса и проверить хотя бы антивирусом.
vol.exe dumpfiles -r spintlx64 -f image.vmem —profile=Win2008R2SP1x64 -D ./
При проверке на VirusTotal показатель выявления был 34/50. При поверхностном анализе обнаружилось, что дата компиляции и сборки бинарника 1992-06-19 22:22:17 , а найденный при офлайн-анализе образа диска файл имел типичные для малвари изменения в атрибутах. Дата создания, изменения, последнего обращения были одинаковы и гораздо старше остальных системных файлов. Файл имел небольшой вес, создавал логи в зашифрованном виде и отправлял их по сети посредством HTTPS. С виду - типичный кейлоггер. Интересно, теперь предстоит разобраться, откуда и когда он попал в систему.
После восстановления данных все лог-файлы были загружены в Event Log Explorer для дальнейшего анализа. Штатные средства в такой ситуации не подходят: они не так поворотливы при поиске, а размеры логов очень большие (>30 Гб).
Отсортировав события по сетевому адресу источника, я получил несколько записей логов, показывающих, что осуществлялся сетевой вход (тип 3) одного из администраторов с сервера Zabbix . По событию входа была определена дата установки кейлоггера. Ее подтвердило время появления первых файлов, создаваемых кейлоггером, - они удалялись, но их получилось восстановить вместе с атрибутами. Больше ничего подозрительного ни в логах, ни в памяти, ни в реестре обнаружено не было. Дополнительно я проанализировал домашние каталоги пользователей сервера, но это не принесло новых результатов.
Завершив работу с контроллером домена, я переключил внимание на сервер Zabbix - именно с него осуществлялся доступ к контроллеру домена по сети.
Обследование Linux-системы концептуально не отличается от обследования Windows-системы. Ищем все то же самое: историю действий, производимых с системой. Если копнуть глубже, то исследовать можно все, от аппаратного уровня до истории запуска Microsoft Paint или набранных текстов. Но к счастью, обычно такой задачи не стоит. Зачастую задача достаточно конкретна и нет необходимости тратить время на то, что не принесет результата.
В данном случае предстояло обследовать Linux-систему на предмет несанкционированного доступа. О сервере предварительно было известно следующее: установлен Suse Linux , Apache + PHP + MySQL + Zabbix с сопутствующим программным обеспечением - всем знакомым LAMP . Выяснилось, что сотрудник, ответственный за сервер, с ОС Linux общается на «вы». Установил и обслуживал сервер его предшественник, который давно ушел из компании.
Для виртуального образа диска сервера был запущен поиск удаленных файлов. Стоит заметить, что, когда имеешь дело с образами, всегда лучше работать с копией, а полученный оригинал хранить отдельно. Естественно, желательно протестировать работоспособность любого программного обеспечения до того, как приступать к исследованию. Приходилось сталкиваться с тем, что образы памяти, созданные разными способами, выдавали при исследовании разный результат. Хотя не стоит исключать вариант, что в систему исследователя закрался вирус, - может быть и такое.
Изучать образ содержимого оперативной памяти системы Linux можно тем же комплектом Volatility, желательно последнего стабильного релиза, хотя после версии 2.0 он вполне справляется. Существует некоторая разница в сравнении с анализом образов RAM семейства Windows - в Volatility нет и в принципе не может быть шаблонов структуры памяти для каждого ядра. Поэтому шаблон придется создать. Для этого необходимо:
- запустить копию исследуемой системы;
- скопировать туда директорию volatility/tools/linux ;
- собрать проект, получив в результате файл module.dwarf , и скопировать его вместе с актуальным /boot/System.map того ядра, на котором работала система при снятии образа RAM, обратно на систему исследователя;
- упаковать оба файла, например в Linux.zip , и поместить архив в volatility/plugins/overlays/linux/ .
Теперь при запуске Volatility с ключом --info созданный тобой профайл будет виден в списке и с ним уже можно начать работу над образом. Без этого ничего не получится, потому что Volatility необходимо знать структуры данных ядра (module.dwarf) и иметь имена переменных, функций и их адреса в памяти (System.map).
Вернемся к исследованию. У меня было подозрение, что система, на которой установлен Zabbix, был скомпрометирована. Осталось понять, как и кто это сделал. Лишних ключей для SSH, посторонних учетных записей в системе не обнаружилось. Я предположил, что в системе есть backdoor , а возможно, и руткит. Для установки подобного рода софта зачастую требуются максимальные привилегии. Это очевидно, достаточно вспомнить основные принципы работы более-менее передовых руткитов в Linux-системах:
В первую очередь необходимо было проверить самые простые вещи, а именно историю выполненных команд: vol -f image.vmem -profile=Linux,x86 linux_bash
История команд была совсем небольшой, и первое, что бросилось в глаза, - это insmod rt.ko . Кстати, в файле истории на диске, конечно, ничего подобного не было, более того, восстановить какие-либо данные из файла истории также не удалось - содержимое уже было перезаписано быстро генерирующимися логами. Так что без образа памяти эти данные были бы неизвестны. Далее предстояло найти упомянутый в истории команд модуль ядра. Модуль был обнаружен на диске в директории PHP-скриптов интерфейса Zabbix.
Последующий анализ этого файла показал, что он прячет сам себя, маскирует при необходимости файлы, предоставляет привилегии root по команде. Управление ведется через файловую систему /proc/rt . С сетью не взаимодействует.
Просмотр сетевых соединений в образе памяти показал, что веб-сервер с Zabbix доступен из интернета. Конечно, я об этом не спрашивал, но подразумевал, что систему мониторинга в сеть никто не выставляет. Позже я выяснил у администраторов, что они так следят за системой, когда находятся вне офиса (несмотря на наличие VPN-аккаунта у каждого). Удобно, ничего не скажешь.
Я обратил внимание на Zabbix и пожалел, что не присмотрелся к нему раньше, - версия была подозрительно старая - 1.8.4 . Поиск по exploit-db.com показал, что в данной версии в скрипте popup.php присутствует SQL-инъекция, позволяющая получить хеши пользователей (CVE: 2011-4674). Проверка уязвимости показала ее полную работоспособность.
Схема подключения злоумышленника стала очевидна: через веб-шелл запускался back connect , предоставляющий интерактивный шелл, после чего привилегии повышались с помощью руткита. При такой схеме злоумышленник использовал этот хост как промежуточный для передачи зловреда на контроллер домена, а также для передачи базы ntds.dit и SYSTEM . Для эффективного поиска с помощью утилиты md5deep была создана база MD5-хешей всех файлов, восстановленных с образа сервера, после чего среди них произведен поиск хеша кейлоггера. Как результат - искомый файл был найден (правда, не с тем именем), а рядом лежал psexec и другие сопутствующие утилиты, которые были удалены.
Теперь можно было точно сказать, как произошел инцидент: злоумышленник, воспользовавшись уязвимостью Zabbix, получил и подобрал хеш пароля администратора Zabbix. С помощью скриптов Zabbix был загружен и запущен вспомогательный инструмент, в частности ncat для создания обратного соединения, с помощью которого был загружен и запущен локальный эксплойт, - версия ядра была полуторагодовалой давности.
Кстати говоря, Zabbix хранит скрипты в БД, и их следы были обнаружены в файле ibdata1.
После повышения привилегий злоумышленник использовал данную систему и подобранные пароли, которые у одного из админов оказались одинаковыми как в домене, так и в Linux-системе, для проникновения на контроллер домена. Получив доступ к контроллеру домена с правами администратора домена, злоумышленник завладел базой данных хешей паролей пользователей. Так как правила генерации паролей пользователями были весьма простые, а пароли не менялись по несколько лет, они были подобраны без особого труда. Обладая учетными данными большинства пользователей, злоумышленник мог читать их почту.
Ради эксперимента я попробовал сбрутить хеши пользователей домена. Легко и непринужденно за пару часов были вскрыты 90% паролей.
По всей видимости, когда злоумышленнику надоело просто читать почту, он решил ее удалить - тем самым развлечься, или отомстить, или выполнить заказ конкурентов? Его мотивация мне неизвестна.
В итоге система Zabbix была переведена в изолированный сегмент, сетевой трафик поставлен на запись, настроена IDS. Я ждал подключений хулигана, но это уже совсем другая история…
Как защитить свой iDevice
Любой iDevice общается с корпоративным сервером Exchange при помощи протокола ActiveSync. С позиции пользователя - защититься по умолчанию никак нельзя. Политика сервера Exchange подразумевает, что если устройство подключено к корпоративной сети, то администратор должен иметь возможность когда угодно управлять этим устройством для прекращения доступа к конфиденциальной информации. Помимо этого, пользователь, в случае утери или кражи, может зайти в OWA через любой браузер и запустить процесс удаленной очистки.
Если в организации имеется понимающий администратор Exchange - обратиться к нему и попросить убрать права на выполнение данной операции, а еще лучше - убрать доступ к пункту «Мобильные устройства» из веб-интерфейса OWA.
Вердикт
Настало время подвести итоги. К сложившейся ситуации привели ошибки администрирования сети и систем:
- слабая парольная политика - не установлена сложность пароля, не установлен срок действия пароля;
- отсутствует патч-менеджмент - кроме продуктов Microsoft, завязанных на WSUS, системы и софт не обновляется;
- не везде установлено антивирусное ПО - например, на контроллере домена антивирус, скорее всего, помог бы предупредить кражу хешей пользователей;
- отсутствует единая политика по доступу в интернет, доступ разграничивается без внятных правил;
- сеть не сегментирована;
- не осуществляется лог-менеджмент;
- лень.
Действует Редакция от 27.12.2007
Наименование документ | "НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ. ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. МЕНЕДЖМЕНТ ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК ТО 18044-2007" (утв. Приказом Ростехрегулирования от 27.12.2007 N 513-ст) |
Вид документа | приказ, стандарт, гост |
Принявший орган | ростехрегулирование |
Номер документа | 18044-2007 |
Дата принятия | 01.01.1970 |
Дата редакции | 27.12.2007 |
Дата регистрации в Минюсте | 01.01.1970 |
Статус | действует |
Публикация |
|
Навигатор | Примечания |
"НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ. ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. МЕНЕДЖМЕНТ ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК ТО 18044-2007" (утв. Приказом Ростехрегулирования от 27.12.2007 N 513-ст)
6 Примеры инцидентов информационной безопасности и их причин
Инциденты ИБ могут быть преднамеренными или случайными (например, являться следствием какой-либо человеческой ошибки или природных явлений) и вызваны как техническими, так и нетехническими средствами. Их последствиями могут быть такие события, как несанкционированные раскрытие или изменение информации, ее уничтожение или другие события, которые делают ее недоступной, а также нанесение ущерба активам организации или их хищение. Инциденты ИБ, о которых не было сообщено, но которые были определены как инциденты, расследовать невозможно и защитных мер для предотвращения повторного появления этих инцидентов применить нельзя.
Ниже приведены некоторые примеры инцидентов ИБ и их причин, которые даются только с целью разъяснения. Важно заметить, что эти примеры не являются исчерпывающими.
6.1 Отказ в обслуживании
Отказ в обслуживании является обширной категорией инцидентов ИБ, имеющих одну общую черту.
Подобные инциденты ИБ приводят к неспособности систем, сервисов или сетей продолжать функционирование с прежней производительностью, чаще всего при полном отказе в доступе авторизованным пользователям.
Существует два основных типа инцидентов ИБ, связанных с отказом в обслуживании, создаваемых техническими средствами: уничтожение ресурсов и истощение ресурсов.
Некоторыми типичными примерами таких преднамеренных технических инцидентов ИБ "отказ в обслуживании" являются:
Зондирование сетевых широковещательных адресов с целью полного заполнения полосы пропускания сети трафиком ответных сообщений;
Передача данных в непредусмотренном формате в систему, сервис или сеть в попытке разрушить или нарушить их нормальную работу;
Одновременное открытие нескольких сеансов с конкретной системой, сервисом или сетью в попытке исчерпать их ресурсы (то есть замедление их работы, блокирование или разрушение).
Одни технические инциденты ИБ "отказ в обслуживании" могут возникать случайно, например в результате ошибки в конфигурации, допущенной оператором, или из-за несовместимости прикладного программного обеспечения, а другие - преднамеренными. Одни технические инциденты ИБ "отказ в обслуживании" инициируются намеренно с целью разрушения системы, сервиса и снижения производительности сети, тогда как другие - всего лишь побочными продуктами иной вредоносной деятельности.
Например, некоторые наиболее распространенные методы скрытого сканирования и идентификации могут приводить к полному разрушению старых или ошибочно сконфигурированных систем или сервисов при их сканировании. Следует заметить, что многие преднамеренные технические инциденты типа "отказ в обслуживании" часто инициируются анонимно (то есть источник атаки неизвестен), поскольку злоумышленник обычно не получает информации об атакуемой сети или системе.
Инциденты ИБ "отказ в обслуживании", создаваемые нетехническими средствами и приводящие к утрате информации, сервиса и (или) устройств обработки информации, могут вызываться, например, следующими факторами:
Нарушениями систем физической защиты, приводящими к хищениям, преднамеренному нанесению ущерба или разрушению оборудования;
Случайным нанесением ущерба аппаратуре и (или) ее местоположению от огня или воды/наводнения;
Экстремальными условиями окружающей среды, например высокой температурой (вследствие выхода из строя системы кондиционирования воздуха);
Неправильным функционированием или перегрузкой системы;
Неконтролируемыми изменениями в системе;
Неправильным функционированием программного или аппаратного обеспечения.
6.2 Сбор информации
В общих чертах инциденты ИБ "сбор информации" подразумевают действия, связанные с определением потенциальных целей атаки и получением представления о сервисах, работающих на идентифицированных целях атаки. Подобные инциденты ИБ предполагают проведение разведки с целью определения:
Наличия цели, получения представления об окружающей ее сетевой топологии и о том, с кем обычно эта цель связана обменом информации;
Потенциальных уязвимостей цели или непосредственно окружающей ее сетевой среды, которые можно использовать для атаки.
Типичными примерами атак, направленных на сбор информации техническими средствами, являются:
Сбрасывание записей DNS (системы доменных имен) для целевого домена Интернета (передача зоны DNS);
Отправка тестовых запросов по случайным сетевым адресам с целью найти работающие системы;
Зондирование системы с целью идентификации (например, по контрольной сумме файлов) операционной системы хоста;
Сканирование доступных сетевых портов на протокол передачи файлов системе с целью идентификации соответствующих сервисов (например электронная почта, протокол FTP, сеть и т. д.) и версий программного обеспечения этих сервисов;
Сканирование одного или нескольких сервисов с известными уязвимостями по диапазону сетевых адресов (горизонтальное сканирование).
В некоторых случаях технический сбор информации расширяется и переходит в несанкционированный доступ, если, например, злоумышленник при поиске уязвимости пытается получить несанкционированный доступ. Обычно это осуществляется автоматизированными средствами взлома, которые не только производят поиск уязвимости, но и автоматически пытаются использовать уязвимые системы, сервисы и (или) сети.
Инциденты, направленные на сбор информации, создаваемые нетехническими средствами, приводят к:
Прямому или косвенному раскрытию или модификации информации;
Хищению интеллектуальной собственности, хранимой в электронной форме;
Нарушению учетности, например, при регистрации учетных записей;
Неправильному использованию информационных систем (например, с нарушением закона или политики организации).
Инциденты могут вызываться, например, следующими факторами:
Нарушениями физической защиты безопасности, приводящими к несанкционированному доступу к информации и хищению устройств хранения данных, содержащих значимые данные, например ключи шифрования;
Неудачно и (или) неправильно конфигурированными операционными системами по причине неконтролируемых изменений в системе или неправильным функционированием программного или аппаратного обеспечения, приводящим к тому, что персонал организации или посторонний персонал получает доступ к информации, не имея на это разрешения.
6.3 Несанкционированный доступ
Несанкционированный доступ как тип инцидента включает в себя инциденты, не вошедшие в первые два типа. Главным образом этот тип инцидентов состоит из несанкционированных попыток доступа в систему или неправильного использования системы, сервиса или сети. Некоторые примеры несанкционированного доступа с помощью технических средств включают в себя:
Попытки извлечь файлы с паролями;
Атаки переполнения буфера с целью получения привилегированного (например, на уровне системного администратора) доступа к сети;
Использование уязвимостей протокола для перехвата соединения или ложного направления легитимных сетевых соединений;
Попытки расширить привилегии доступа к ресурсам или информации по сравнению с легитимно имеющимися у пользователя или администратора.
Инциденты несанкционированного доступа, создаваемые нетехническими средствами, которые приводят к прямому или косвенному раскрытию или модификации информации, нарушениям учетности или неправильному использованию информационных систем, могут вызываться следующими факторами:
Разрушением устройств физической защиты с последующим несанкционированным доступом к информации;
Неудачной и (или) неправильной конфигурацией операционной системы вследствие неконтролируемых изменений в системе или неправильного функционирования программного или аппаратного обеспечения, приводящих к результатам, подобным тем, которые описаны в последнем абзаце 6.2.
11 октября 2012 в 10:58Работа с инцидентами информационной безопасности
- Информационная безопасность
Доброго дня, уважаемый хабрахабр!
Я продолжаю публикацию статей из практики по информационной безопасности.
В этот раз речь пойдёт о такой важной составляющей, как инциденты безопасности. Работа с инцидентами займёт львиную долю времени после установления режима информационной безопасности (приняты документы, установлена и настроена техническая часть, проведены первые тренинги).
Информирование об инцидентах
Перво наперво необходимо получить информацию об инциденте. Этот момент необходимо продумать ещё на этапе формирования политики безопасности и создания презентаций по ликбезу в ИБ для сотрудников.
Основные источники информации:
1. Helpdesk.
Как правило (и это хорошая традиция) о любых неполадках, неисправностях или сбоях в работе оборудования звонят или пишут в хелпдеск вашей IT-службы. Поэтому необходимо заранее «встроиться» в бизнес-процесс хелпдеска и указать те виды инцидентов, с которыми заявку будут переводить в отдел информационной безопасности.
2. Сообщения непосредственно от пользователей.
Организуйте единую точку контакта, о чём сообщите в тренинге по ИБ для сотрудников. На данный момент отделы ИБ в организациях, как правило, не очень большие, зачастую из 1-2 человек. Поэтому будет несложно назначить ответственного за приём инцидентов, можно даже не заморачиваться с выделением адреса электропочты под нужды IS Helpdesk.
3. Инциденты, обнаруженные сотрудниками ИБ.
Тут всё просто, и никаких телодвижений для организации такого канала приёма не требуется.
4. Журналы и оповещения систем.
Настройте оповещения в консоли антивируса, IDS, DLP и других систем безопасности. Удобнее использовать аггрегаторы, собирающие данные также из логов программ и систем, установленных в вашей организации. Особое внимание нужно уделить точкам соприкосновения с внешней сетью и местам хранения чувствительной информации.
Хоть инциденты безопасности разнообразны и многообразны, их довольно легко разделить на несколько категорий, по которым проще вести статистику.
1. Разглашение конфиденциальной или внутренней информации, либо угроза такого разглашения.
Для этого необходимо иметь, как минимум, актуальный перечень конфиденциальной информации, рабочую систему грифования электронных и бумажных носителей. Хороший пример - шаблоны документов, практически на все случаи жизни, находящиеся на внутреннем портале организации или во внутренней файлопомойке, по умолчанию имеют проставленный гриф «Только для внутреннего использования».
Немного уточню про угрозу разглашения, в предыдущем посте я описывал ситуацию, когда документ с грифом «Только для внутреннего использования» был вывешен в общем холле, смежным с другой организацией. Возможно, самого разглашения и не было (вывешено было после окончания рабочего дня, да и замечено было очень быстро), но факт угрозы разглашения - на лицо!
2. Несанкционированный доступ.
Для этого необходимо иметь список защищаемых ресурсов. То есть тех, где находится какая-либо чувствительная информация организации, её клиентов или подрядчиков. Причём желательно внести в эту категорию не только проникновения в компьютерную сеть, но и несанкционированный доступ в помещения.
3. Превышение полномочий.
В принципе можно объединить этот пункт с предыдущим, но лучше всё-таки выделить, объясню почему. Несанкционированный доступ подразумевает доступ тех лиц, которые не имеют никакого легального доступа к ресурсам или помещениям организации. Это внешний нарушитель, не имеющий легального входа в вашу систему. Под превышением полномочий же понимается несанкционированный доступ к каким-либо ресурсам и помещениям именно легальных сотрудников организации.
4. Вирусная атака.
В этом случае необходимо понимать следующее: единично заражение компьютера сотрудника не должно повлечь за собой разбирательство, так как это можно списать на погрешность или пресловутый человеческий фактор. Если же заражен ощутимый процент компьютеров организации (тут уже исходите из общего количества машин, их распределенности, сегментированности и тд), то необходимо разворачивать полновесную отработку инцидента безопасности с необходимыми поисками источников заражения, причин и т.д.
5. Компрометация учетных записей.
Этот пункт перекликается с 3
. Фактически инцидент переходит из 3
в 5
категорию, если в ходе расследования инцидента выясняется, что пользователь в этот момент физически и фактически не мог использовать свои учётные данные.
Классификация инцидента
С этим пунктом в работе с инцидентами можно поступить 2-мя путями: простым и сложным.
Простой путь: взять соглашение об уровне сервиса вашей IT-службы и подогнать под свои нужды.
Сложный путь: на основе анализа рисков выделить группы инцидентов и/или активов, в отношении которых решение или устранение причин инцидента должны быть незамедлительными.
Простой путь неплохо работает в небольших организациях, где не так уж и много закрытой информации и нет огромного количества сотрудников. Но стоит понимать, что IT-служба исходит в SLA из своих собственных рисков и статистики инцидентов. Вполне возможно, что зажевавший бумагу принтер на столе генерального директора будет иметь очень высокий приоритет, в том случае, как для вас важнее будет компрометация пароля администратора корпоративной БД.
Сбор свидетельств инцидента
Есть особенная прикладная наука - форензика, которая занимается вопросам криминалистики в области компьютерных преступлений. И есть замечательная книга Федотова Н.Н. «Форензика - компьютерная криминалистика». Я не буду сейчас расписывать детально аспекты форензики, просто выделю 2 основных момента в сохранении и предоставлении свидетельств, которых необходимо придерживаться.
Для бумажных документов: подлинник хранится надежно с записью лица, обнаружившего документ, где документ был обнаружен, когда документ был обнаружен и кто засвидетельствовал обнаружение. Любое расследование должно гарантировать, что подлинники не были сфальсифицированы
Для информации на компьютерном носителе: зеркальные отображение или любого сменного носителя, информации на жестких дисках или в памяти должны быть взяты для обеспечения доступности. Должен сохраняться протокол всех действий в ходе процесса копирования, и процесс должен быть засвидетельствован. Оригинальный носитель и протокол (если это невозможно, то, по крайней мере, одно зеркальное отображение или копия), должны храниться защищенными и нетронутыми
После устранения инцидента
Итак, инцидент исчерпан, последствия устранены, проведено служебное расследование.
Но работа на этом не должна завершаться.
Дальнейшие действия после инцидента:
Переоценка рисков, повлекших возникновение инцидента
подготовка перечня защитных мер для минимизации выявленных рисков, в случае повторения инцидента
актуализация необходимых политик, регламентов, правил ИБ
провести обучение персонала организации, включая сотрудников IT, для повышения осведомленности в части ИБ
То есть необходимо предпринять все возможные действия по минимизации или нейтрализации уязвимости, повлекшей реализацию угрозы безопасности и, как результат, возникновение инцидента.
1.
Ведите журнал регистрации инцидентов, где записывайте время обнаружения, данные сотрудника, обнаружившего инцидент, категорию инцидента, затронутые активы, планируемое и фактическое время решения инцидента, а так же работы, проведенные для устранения инцидента и его последствий.
2.
Записывайте свои действия. Это необходимо в первую очередь для себя, для оптимизации процесса решения инцидента.
3.
Оповестите сотрудников о наличие инцидента, что бы во-первых они не мешали вам в расследовании, во-вторых исключили пользование затронутыми активами на время расследования.
Прежде чем мы пойдем в глубь выбранной темы — приведу трактование из большого энциклопедического словаря.
ИНЦИДЕНТ (от лат. incidens, родительный падеж incidentis — случающийся) , случай, происшествие (обычно неприятное); столкновение, недоразумение.
Поэтому давайте сегодня рассмотрим инцидент, который возникает сплошь и рядом между мужчиной и женщиной — через призму столкновения их интересов. И здесь совсем неважно был ли этот инцидент между мужем и женой, парнем и девушкой, подчиненной(женщиной) и начальником (мужчиной).
Просто я хочу показать, что суть такого конфликта у всех его проявлений остается общей. Чтобы не быть голословной и не размазывать кашу по тарелке начну с практических примеров.
Муж и жена.
Она приходит счастливая домой (ей удалось сделать все задуманное и даже больше). Переступает порог собственной квартиры и по обыкновению ждет знака внимания со стороны своего мужа.
Но! Вместо традиционной и шутливой реакции с его стороны — КТО ТАМ? Она слышит затянувшееся молчание.
Недоумение, непонимание и прочие реакции мигом пронеслись в ее голове и теле одновременно.
Три коротких шага из прихожей в зал показались ей вечностью. А ее бурные фантазии успели розыграться не на шутку.
Следующий миг оказался еще более удивительным, когда она увидела своего благоверного мирно восседающим в кресле с газетой в руках.
Жене, совсем наоборот, хотелось не просто общения, а еще и внимания и благодарности в свой адрес по-поводу ее результатов.
Вот вам две полярности, две планеты, два разных уровня пребывания сознания, два разных желания.
И сколько не изучай теорий, практик по-поводу того, как вести себя в подобной ситуации — нюансы таких инцидентов оказываются всегда сильнее. А посему определеный тупик в виде непонимания , как быть в подобной ситуации обеспечен.
Но прежде чем я покажу выход из данной ситуции. Давайте рассмотрим еще один пример.
Начальник, подчиненная.
Ей было дано производственное задание, которое нужно было сделать к определенному сроку. В силу разных обстоятельств (а главное благодаря своему бессознательному выбору) — сроки были упущены, а задание ни сделано во — время.
В глубине души она надеялась не некоторое снисхождение со стороны начальника, а посему на очередную оперативку шла спокойно и уверенно.
Для начальника встреча с исполнительцей данного задания определяла успех его компании на целый год. Считанные часы отделяли его от долгожданного договора на поставки в другой город. Дело оставалось за малым — получить необходимые расчеты от подчиненной.
Идя на оперативку он и мысли не допускал о том, что оно может быть просрочено.
А теперь пустите в ход свое воображение и представьте какой произошел инцидент в этот день. К вашим фантазиям добавлю только один факт — эта девушка была уволена с работы.
Безусловно сейчас можно очень долго рассуждать по- этому поводу.
Но я думаю, что вы в своей жизни уже достаточно анализировали подобные ситуации. А посему не буду забирать ваше драгоценное время и сразу перейду к сути.
С одной стороны кажется, что это совсем разные ситуации и объединить их нельзя.
И я с вами соглашусь, в том случае, если подойти к их рассмотрению с внешней стороны.
Я же хочу вам показать суть данных конфликтов и убедить вас в том, что она у них единая.
И так для начала рассмотрим причину конфликта .
Как в первом, так и во втором случае, причиной таких инцидентов стали — НЕ ОПРАВДАННЫЕ ОЖИДАНИЯ.
Да именно они являются охилесовой пятой в рассмотренных конфликтах (и не только).
Что здесь важно понять?
Как только мы выстраиваем определенный план действий (своих, другого человека) перед встречей с ним, то автоматически (этот механизм работает без сбоя) мы включаем у себя чувство ожидания и надежды.
А какие программы лежат в этих словах (осмелюсь вам еще раз напомнить)?
О (ум) — ЖИД — дАН . НАД —ад -Е- ДА .
Вот и все!
Сначала мы запускаем остановку (Оум ЖИД) своей творческой энергии. А потом лелеем себя надеждой и начинаем играть в игру — пройти (НАД -Адом через ДА т.е. согласие).
Как в первом (у жены и у мужа), так и во — втором случае (у начальника и подчиненной), каждый игрок лелеял свои ожидания.
В итоге разность энергий вложенная в их ожидания вызвала взрыв (конфликт) «на макоронной» фабрике.
В задачке спрашивается, а как можно было избежать данного инцидента?
С одной стороны, все очень просто — нужно научиться слушать слышать себя и человека, с которым ты общаещься здесь и сейчас. Только при этом условии, игра становится осознанной и будет напоминать игру на фортепьяно. Слушание и слышание одной музыкальной клавиши, включает четкое понимание какую из них нажать в следующий момент, чтобы музыка звучала органичнно.
Но чтобы получать свои результаты от такого общения — конечно же требуются определенные умения и навыки. Понятно что в один момент мы не становимся мастерами, а это значит их можно развивать только постепенно.
Главное было бы желание.
Однако мой ответ был бы не полным если бы я не сказала о главном.
О ключе, который позволяет вырабатывать осознанный подход к любой коммуникации, с любым человеком или коллективом и избегать подобных инцидентов.
Сутью такого КЛЮЧА является формирование у себя стратегического мышления или подхода. В переводе на русский язык — это означает, что перед любой встречей с кем бы то нибыло (с мужем, женой, начальником…), вы всегда заранее определяете суть своей игры (мы все здесь на Земле играем — это нужно понимать), в которой четко формулируете свой конечный результат.
Сейчас вы мне можете возразить и сказать: «Вот завернула! Это какой я еще должна (ен) определять результат при общении с мужем (женой)! Ведь каждый день замучаешься это делать!».
И тем ни менее, как подтверждает мой личный и опыт моих клиентов —
Осознанный подход к своей жизни, четкое понимание того, чего ты хочешь в каждом жизненном миге (с этим или иным человеком) открывает пространство для успешной и безконфликтной жизни.
Поэтому мне не надо верить — это можно только проверить.
P.S. Сейчес самое благодатное время для изменения своих деструктивных программ.
Дело утопающих, дело рук самих утопающих.
С вами была Пеняйчева Любовь .