Вставляем палки в колеса на аудиторских проверках, или Как сделать аудит ИБ максимально некомфортным для аудитора

    Привет, Хабр! Спустя 9 лет на проектах по аудитам ИБ за спиной мне нестерпимо хочется взять и написать книгу «1000 и 1 попытка обмануть аудитора». Начну, пожалуй, с первой главы — поделюсь вредными советами, как можно «успешно» пройти аудит, получив минимальное количество замечаний от аудитора.

    Зачем вообще компании проводят аудит информационной безопасности? Причин может быть несколько:

    • чтобы получить объективную оценку состояния ИБ (для себя);
    • потому что аудит является обязательным (для регуляторов);
    • потому что аудит требуют партнеры или головная организация (для других).

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

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

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

    P.S. Перечисленное под катом не является вымыслом, все это случалось и периодически встречается на реальных проектах.


    Готовимся к аудиторской проверке


    Подготавливаем персонал – обучаем, что нужно говорить и что нельзя показывать


    Залог успешной диверсионной подготовки персонала (особенно в условиях грядущих военных действий) — тщательное предварительное обучение. Как правило, оно направлено на:

    • повышение осведомленности о текущем вооружении аудитора, его приемах, техниках и болевых точках;
    • выработку и совершенствование командных навыков по запутыванию, сокрытию следов, а также оттачивание методики «стрелочник».

    Очевидно, что чем меньше информации узнает аудитор, тем меньше несоответствий обнаружит, а где мало несоответствий, там мало проблем (и работы). Значит, задача-максимум аудируемой компании — скрыть возможные проблемные области (информационные системы, отдельные элементы ИТ-инфраструктуры и пр.), обучив специалистов тому, что можно показывать, а что не нужно.

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

    Работает ли этот прием? Плохо: используем различные комплексные проверки — и стройные договоренности начинают «сыпаться».

    Игнорируем предварительный запрос информации


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

    Примеров можно привести много, итог один: со многим приходится разбираться на месте, открывая для себя новое уже в ходе аудита. Успешна ли такая тактика? Нет, просто больше времени приходится тратить «внеурочно».

    Только разовые пропуска, только хардкор!


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

    Иногда встречаются совсем запрещенные приемы. Например, условием допуска на площадки одного из заказчиков стала разработка регламента его предоставления. Доступ кому был нужен? Нам! Вот мы и писали, как будем его получать и с кем согласовывать.

    Приводят ли к чему-то такие «сложности»? Очевидно, что нет: мы любим пораньше вставать (если все-таки ложимся спать).

    Усложняем управление проектом


    Вам надо — вы и организовывайте. Хард-версия для опытных




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

    Хорошая попытка затягивания сроков, но с нашими менеджерами и выстроенной системой эскалаций работает плохо :-).

    Мы попробовали, но у нас не получилось. Лайт-версия для новичков


    Больше дегтя — меньше меда. Делаем план-график максимально неудобным и непредсказуемым. Идеальный день аудитора на площадке должен выглядеть так: беседа на час в 9.00, потом на 30 минут в 13.00 и следующая в 18.00. Информацию о запланированных на следующий день встречах высылаем строго в 23.55. Чем больше хаоса, тем выше шанс, что аудиторы забудут о той самой распечатке на черновике письма с внутренним обучением.

    Аудитор должен быть гибким, поэтому еще один лайфхак — менять местами интервью прямо в день проведения. Сам план интервью всегда преследует определенную логику, например, сначала изучается функционал системы, а потом проверяются ее компоненты (СУБД и пр.). Но это — Спарта, и логика — для слабаков, потому:
    «Мы там хотели с вами в пятницу с DBA поговорить, но у нашего специалиста 15 минут свободного времени появилось, он сейчас придет».
    Враг будет разгромлен? Нет, такое мы встречаем часто и умеем с этим бороться.

    Аудит по фотографии — самый честный аудит


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

    • Подготовка кучи опросников с памяткой по их заполнению.
    • Получение огромного количества неструктурированного материала (каждый может понять вопрос по-разному).
    • Созвоны со специалистами для уточнения информации.
    • Выстраивание из всего материала какой-то стройной картины.
    • Уход на новый круг уточнения.

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

    Проводим интервью


    Театр начинается с вешалки — выбираем лучшие места для беседы


    Если все-таки отбиться не получилось и встреч с аудиторами не избежать, вот вам ТОП лучших мест для проведения интервью. Аудиторам точно понравится — не благодарите.

    • На детской площадке у грибка.
    • В туалетной комнате, переоборудованной дополнительно в коммутационную.
    • В машине (ночью).
    • В столовой.

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

    А не шпион ли ты часом?


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

    • NDA на компанию, где работает аудитор;
    • личный NDA аудитора с вами;
    • рабочий пропуск;
    • копию трудовой книжки;
    • письмо, заваренное руководителем компании;
    • паспорт.

    Только после этого выдавайте «военную тайну». Нет с собой копии трудовой — ну что ж, придется запланировать встречу еще раз.

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

    Берем массой, или Чем больше, тем интереснее (нет)


    Как сделать деловую встречу максимально бесполезной? Рецепт прост: открываем любую статью в Интернете по эффективным совещаниям и превращаем полезное в неполезное:

    • Всегда определяйтесь с повесткой собрания заранее. Никогда не сообщайте коллегам о цели встречи. Скажите, что это ПРО БЕЗОПАСНОСТЬ, и ТАМ вам все расскажут НУЖНЫЕ ЛЮДИ (почувствовали мурашки?).
    • Число участников должно быть минимальным, не более 7 человек. Снимите просторную переговорку и позовите большую часть ИТ-специалистов. Они будут друг друга дополнять, и аудиторы сэкономят кучу времени (нет).
    • Не затягивайте совещание дольше, чем на час. Запланируйте встречу часа на четыре под конец рабочего дня, чтобы точно снять все вопросы.
    • Убедитесь в том, что все принимают активное участие в обсуждении. Раздраженный работник — лучший собеседник. Поэтому приглашайте и HR, и DBA, и всех остальных: пусть ждут, когда до них дойдет очередь.

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

    Работает? Плохо, но попытка хорошая.

    Играем в «Данетки», или Я угадаю эту мелодию с одной ноты




    Активизируем секретное оружие — запоминаем правила игры в «Данетки».

    Задача работника: минимизировать психологические пытки аудиторов, заставить их грамотно формулировать вопросы, чтобы на них можно было отвечать только «Да» или «Нет».

    Задача аудитора: отгадать почему мужчина заходит в бар и просит стакан воды, бармен внезапно достает ружье и направляет на мужчину. Мужчина говорит «Спасибо» и уходит ответы на свои вопросы:
    — Какие средства автоматизации управления заявками у вас используются?
    — Да!
    — Какие технологии виртуализации используются в компании?
    — Все!

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

    Добавляем цензуру


    Вы думали, что цензура, это — система надзора за содержанием и распространением информации, печатной продукции, музыкальных и сценических произведений и прочего? Нет. Цензура — это вовремя выставленный за спиной аудитора ИБ-шник. В таком важном мероприятии, как аудит, нет места фантазиям и домыслам аудитора. Поэтому:
    «Это не у нас неправильно, это вы неправильно поняли, и вопросы ваши неправильные».
    Задача цензора — помочь работнику не завалить экзамен. Помощь может заключаться в следующем:

    • Отфильтровываем на свой вкус «неправильные» вопросы. Апеллируем границами аудита либо вопросами не по адресу или не по существу.
    • Отвечаем за аудируемого (вдруг он забыл, о чем раньше с ним успели договориться).
    • Заглядываем в записи аудитора и даем замечания.

    Сюрреализм? Он самый. Однако такой опыт тоже был в нашей практике. Прямо скажем: получалось у заказчика плохо, хотя идея — огонь!

    Уходим в цикл и переводим стрелки


    Важно запутать врага, чтобы он не смог сделать опасное аудиторское заключение и навредить вам. Еще одно ядерное оружие, как и «Данетки». Записывайте универсальную формулу.
    Работник N: «Я это не знаю, я работник N, это знает другой работник N+1».

    Работник N+1: «Я работник N+1, вас обманули, это зона ответственности работника N».

    Работник ИБ: «К сожалению, у нас закончились свободные слоты у работников N и N+1, вам надо работать с той информацией, что есть».
    Работать в таком режиме сложно, а значит цель достигнута? Нет, бороться можно и нужно: мы предварительно прозваниваем специалистов, ведем протоколы встреч и прочее.

    Держи мышку, я пошел, или Хочешь лучше узнать систему — сделай это сам!


    Любой аудитор — это специалист с большой буквы. Так что он должен заочно знать абсолютно все используемые вами технологии на уровне администратора, уметь за 5 минут пересобрать ядро Linux и наизусть знать ваш SAP. Поэтому лучший способ заставить его понервничать — дать ему «порулить». Пусть сам разбирается в архитектуре ваших систем, выстраиваемых годами. Можно просто рядом посидеть и помолчать.

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

    Быстро поправили — значит, не было


    Знаете правило пяти секунд? Отлично, используйте его и на аудите. Отвлеките аудитора и смело вносите правки в настройки безопасности. Или вообще не отвлекайте и вносите при нем: быстро исправили — значит, не было. Можно не объяснять — не работает.

    Усложняем процедуру получения свидетельств


    У нас суперсекретная информация


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

    Отдельно вспоминается несколько случаев.

    • Как-то нам распечатали конфигурацию сетевого оборудования на паре пачек «Снегурочки» без разрешения выноса материала с площадки.
    • В другой раз от нас требовали обосновывать каждый запрашиваемый скриншот.
    • На еще одном проекте передавать все свидетельства можно было только на бумаге.

    Кто-то обоснованно возразит: наверное, в этих компаниях был строгий режим коммерческой тайны? Нет. Его не было вообще.

    Поможет ли это как-то снизить качество работ? Спорно. У нас есть и не такой опыт: например, создание отчета через VDI заказчика с закрытым буфером, портами и сетью Интернет с получением свидетельств на диске с грифом КТ курьером. Как тебе, Дэвид Блейн?

    Используем магию графического редактора




    Как сказал великий Сунь-Цзы в книге «Искусство войны»:
    «Война — это путь обмана. Поэтому, если ты и можешь что-нибудь, показывай противнику, будто не можешь; если ты и пользуешься чем-нибудь, показывай ему, будто ты этим не пользуешься».
    На войне все способы хороши, поэтому использование графического редактора увеличивает ваши шансы на победу. Все «неудобные» свидетельства у вас на руках, остается чуть навести makeup перед отправкой. У этого вектора есть небольшой шанс при удаленном запросе информации или плохой памяти аудитора. Минус: получается неловко, когда аудитор решил проверить ранее предоставленные скриншоты на площадке. Но кого это останавливало?

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

    Затягиваем согласование отчета


    Запятые — это важно


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

    Отлично работает также включение в цепочку согласования большого количества специалистов. Наш девиз: «Аудит на полгода, согласуем за полтора!». Подольше тяните, а там уже и градус накала спадет, и часть работ станет неактуальной (появится новое, старое выведется из эксплуатации).

    Работает плохо, читай выше про менеджеров.

    ***

    Конечно, большинство наших проектов по аудиту проходит в штатном режиме, и здесь приведены наиболее яркие примеры того, как такие работы можно превратить в долгое мероприятие. Выводы каждый сделает сам: взять на вооружение и «успешно» проходить проверки, либо сделать ваш следующий совместный аудит с интегратором чуть лучше.

    Улыбайтесь чаще :-)
    Инфосистемы Джет
    Системный интегратор

    Похожие публикации

    Комментарии 24

      +1

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

        +2
        Да, работа конечно веселая, для людей с крепкой нервной системой :-).
        Но у меня есть один вопрос, который относится к ИБ вообще.
        Где проходит граница между безопасностью и работоспособностью системы/бизнеса?
        Т.е. я четко понимаю, что самая безопасная система — это та, которую отключили, ну и в граничном случае еще и сожгли.
        Если закрыть все риски по безопасности и проводить жесткий аудит, то можно найти причины остановить любую работающую айти компанию.
        Я вижу что на этой теме пасется просто куча больших и мелких бизнесов, толкающих заказчикам всякие решения «сквозного шифрования» и тому подобный «гербалайф».
        Админы конечно могут забрать у всех доступ ко всему, все перекрыть, зашифровать, запаковать и опечатать (это по-моему их голубая мечта). Но как в таких условиях работать?
          +2
          суть не в том, чтобы забрать доступ, а в том, чтобы усилить систему внутреннего контроля.
          если речь про банки, где крутится много денег и риски высоки — то нужно много людей (бюрократия), которые бы проверяли, перепроверяли, утверждали, контролировали, измеряли и прочее-прочее каждое изменение.
          Формула, что чем больше людей вовлечено, значит тем больше распределение ответственности и полномочий, и один человек не зафакапит систему.

          В целом смотрят на зрелость процессов по (capability maturity model), чем больше денег крутится, значит тем выше риск, и нужно чтобы процессы были более зрелые, более бюрократичные, больше людей, больше бумаги, больше согласований и разрешений.

          это касается и внутреннего контроля (рисковики контролят фронт-офис, бек-офис контролит мидл-офис, внутренний аудит контролирует бек-офис, внешний аудит контролирует всех внутри, регуляторы-государство смотрят и на тех и других).

          Кстати не всегда для безопасника решение забрать доступ. Доступ достаточно защитить, например не по паролю, а по второму фактору (токен) и дать доступ на время, а не на постоянку и т.д.
          Целые многомиллиардные компании создаются на одной простой идее, что доступ к серверам надо защищать (Израильский Cyberark например)
            +2
            Ну вот пример, из далекой галактики… В одном банке имеется отдел разработки. Там программисты пишут и кастомизируют банковский софт. Продакшн огорожен со всех сторон, так что только админы имеют к нему полный доступ. Программистов туда не пускают на пушечный выстрел — все каналы перекрыты на уровне файрволов внутренней сети, не говоря уже про логины/пароли. У разрабов отдельная сеть, ибо они, о ужас!, подключаются к интернету со своих десктопов, подкачивают всякие пакеты и обновляют версии IDE, а некоторые даже читают хабр :-). В один прекрасный момент в продакшене начинает крэшится важная программа. Админы информируют, но починить то сами не могут. Привычный вариант «выключить и включить» внезапно не помогает. Предоставляют разрабам лог и дамп, но воспроизвести ошибку не тестовой среде не получается. Понятно, надо разработчикам доступиться до продакшена с нормальными такими правами и своими тулами, чтобы просмотреть, что в этой программе происходит, чтобы быстро понять проблему. Админы — ни в какую, мол, это невозможно никогда! Мы вам не верим и все такое. Ок, начальник отдела разработки пишет докладную мол нам нужен такой то доступ, без него исследовать проблему не представляется возможным, на тесте ошибка не воспроизводится, и со спокойной душой идет домой, рабочий день закончился.
            Админы, думая, что они самые умные, обложились тоннами всяких документов по безопасности, которые предписывают «не пущать». Где-то к ночи, проблема доходит до самого верха, где понимают, что если не починить все до утра, проблемы начнутся немаленькие… Дальше, я оставлю читателю домыслить развитие событий :-).
            Вы спросите, а почему мол о такой ситуации не позаботились заранее, не продумали процедуру доступа для разрабов к продакшену для решения подобных ситуаций? Ха, так, конечно, о такой ситуации отдел разработки предупреждал и боролся за доступ (все ответы «низзя» заботливо сохранены).
            Но админы и безопасники встали стеной и предъявили кучу всяких рекомендаций по безопасности, разграничению доступа и т.п. В том числе и тот аргумент, что если разрабы вдруг получат доступ к проду, то аудиторы этот факт выявят и не одобрят.
            К чему я все это пишу? А к тому, что, IMHO, ставить во главу угла безопасность — это путь к краху. Первостепенной, мне кажется, должна быть надежность работы системы, а не бюрократическая составляющая. Конечно, бюрократия нужна. Но дело в приоритетах. Иначе получите вышеописанную ситуацию — с бюрократией все ок, аудиты пройдены, да система упала и починить ее в рамках установленных безопасниками процессов не представляется возможным.
              +3
              сразу могу сказать что корень проблемы не в безопасниках. Проблема в незрелых процессах управления ИТ инцидентами.

              Обычно как происходит когда находится проблема:
              1. Хелпдеск/коллцентр/ServiceNow или другая система мониторинга сообщает о проблема и создает Инцидент с № и фиксирует время начала проблем. Саппорт первой линии, ответственные за серваки пытается починить/перезагрузить/перевести траффик на бекапные серваки (hot standby)
              2. Если по истечении установленных SLA (30 минут скажем) инцидент не закрыт, он автоматом эскалируется на второй уровень. Т.к. сервак уровня ядра банка — это уровень 0, инцидент ставится на высокий приоритет и извещается вся Major Incident Team. А это значит что никто из МИТ не уходит домой и все сидят на одном конференс-звонке и решают проблему сообща. в МИТ (также называется Technology Command Center) сидят все представители ИТ: и девопсы и админы и безопасники и прогеры и тестеры, и даже вендора зовут если понадобится.
              3. Цель MIT — не разобраться в проблеме, а восстановить работоспособность системы. Если проблема возникла после недавнего апдейта, то софт откатывается на версию назад. Диагностика и нахождение причины проблемы не самое главное!
              4. когда система заработала, тогда программисты могут сами спокойно сидеть и разбираться в чем была проблема, воссоздавать полностью боевую среду у себя в тесте и пробовать разные штуки, и писать отчеты об инциденте

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

              У аудитора будут вопросы если доступ в прод давать без инцидента — это проблема да.
                0
                Ага. Да. В той истории, как раз оказалось, внезапно, что можно и из дома залогиниться в прод. И, да, работать через расшаренный терминал через цитрикс предлагали.
                Конечно, именно о таком режиме работы по выявлению багов мечтают разработчики :-).
                Ребята, зачем разрабу ваш расшаренный ssh терминал через два гейта, если мне нужно подтянуть дебаггер? Разработчику может быть некомфортно работать в терминале, где все настроено строго под выполнение рутинных админских задач по бакапу и т.д. и нет ничего, что разраб использует ежедневно и к чему привык.
                По аналогии, я вот свою машину могу вести в любом состоянии с закрытыми глазами кажется. Все действия на автомате, руки сами все делают… Пришлось тут по случаю рулить чужой — я почувствовал себя новичком на площадке. Почему в принципе вы считаете, что админы настолько доверенные люди, что только им позволено, а разрабы могу исключительно через расшаренный экран под пристальным надзором комманды из админов с пальцем на красной кнопке, типа только мышь не туда скользнула — сразу рубим сеть :-).
                Насчет вот этих всех авралов… Есть вообще-то трудовое законодательство. И 8-часовой рабочий день. И, потом, проблему можно было спокойно решить в рабочее время.
                Потом, вот эти все фантазии, насчет давать внезапно доступ только по инциденту…
                Человек в первый раз в жизни зайдет на тот энвайромент — а там все по-другому, чем на его дев машине. Нет привычных комманд, шорткатов, тулов и т.д.
                Весь мой опыт говорит — без регулярного опыта работы на проде, сходу, ночью, куча времени будет потрачена на совершенно левые не относящиеся к проблеме вещи.
                  +1

                  Написано же — нет нужды понимать в чём проблема и тащить отладчик и вот это всё. Это не задача первостепенной важности. Задача первостепенной важности — это сделать корректный Rollback/переключение на резерв, а разбор полётов устраивать уже потом.

                    0
                    Так я же пояснил, что крэш может не быть связан с релизом непосредственно. Большинство ошибок релиза вылавливаются еще на этапе PIV.
                    И в любом случае, разговор же здесь не про время, а про нахождение ошибки. Вот на проде идут крэши. На тесте они не воспроизводятся. Сложность системы такая, что можно очень долго гадать что там и как и реальный действенный способ понять что происходит — это дать доступ разрабам к проду. А откатить релиз который уже давно в проде — ну, попытайтесь получить разрешение ;-). Когда в релизе изменена методика финансового подсчета чего нибудь там по требованию законодательства и циферки уже 3 недели считаются по новой методе. Откатить бд системы в ядре банка на 3 недели тоже? Удачи ;-). Безумству храбрых поем мы песню, как сказал великий писатель.
                  0
                  Однажды, когда я еще был молодой и горячий, когда мне когда понадобилось для фикса посмотреть — что же там именно не так на проде (логи и внутренности которого огорожены по небалуйся), то я залил небольшую заплатку, чтобы оно логи пересылало куда мне надо было, а потом вместе с фиксом — выпилил ее из кода обратно.
                  С тех пор утекло уже времени, и я уже спокойно и неторопливо делаю эскалацию «нужен доступ» в таких случаях, но мысль :«есть доступ разраба к исходникам? Есть доступ пользователя к рабочей системе? Ну ок, можете обпаролиться там и обзапрещаться хоть на все сервера» — до сих пор со мной %)
                    0
                    Хех, скажу более, такая ситуация совсем нередко встречается. Разрабам приходится встраивать в софт закладки, чтобы в случае чего на проде быстро и в комфортных условиях посмотреть ошибку. Классический случай, когда некая комбинация действий в клиенте открывает консоль.
                    Т.е. все эти драконовские меры на самом деле ведут к появлению очень мрачных вещей.
                      +1

                      У нас такое не прокатит) А если прокатит и узнают — уволят примерно минут за 20, уже были преценты. К тому же, подобные закладки нужно еще через ревью протащить.

                        0
                        1) Что, и даже Spring Actuator (там в зависимостях добавляется пару строк, а в коде ничего даже не отсветит) не прокатит?
                        2) тогда было другое время, можно было делать деплой не из одной ветки — так что до ревью там дело не дошло ;)

                        UPD: Не то чтобы я всем советую так делать, просто я считаю, что антипаттерны тоже нужно знать и понимать, и система безопасности которая учитывает еще и людей (ака «вода дырку найдет, одними только правилами ей не запретишь, поэтому давайте всем жить дружно и помогать»), чем система безопасности которая работает как бюрократическая машина (напишите заявку на разрешение запроса получения доступа, в течение 10 дней мы вам ответим)…
                          0

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


                          Кстати, если система безопасности, не даёт вам творить непотребства, вроде тех, что вы описываете — это и есть тот случай, когда она учитывает ещё и людей, с их невероятной самоуверенностью в собственной непогрешимости :)


                          P.S.
                          Мое мнение предвзято. Я по образованию ИБ-шник, и хоть сейчас я только программист, мне душу греет любой грамотно выстроенный цугундер и я всегда всячески способствую его улучшению в любой компании, где работаю.

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

                            2) +1 к «менять процесс». Я обеими руками за такое. Мне всегда приятно, когда есть вменяемые правила, защищающие меня, прод и бизнес от случайной ошибки (ака DROP TABLES или rm -rf / на проде). Проблема когда это все невменяемое (фичи добавляем каждый день, зато посмотреть логи с сервера — «пишите прошение на неделю вперед» а на следующей неделе: «мы их заархивировали, теперь они на сервере недоступны, а из архива нужно по другой процедуре делать запрос», и непонятно — плакать или смеяться)…

                            UPD: «попросить младшего безопасника дать доступ неофициально» — давным давно, когда еще никто не работал из дома, это выглядело так: приходит к админу\безопаснику делегация из меня и начальства, я сажусь за комп этого безопасника\админа и с его клавиатуры делается все то там нужно срочно сделать. Естественно, цугундер, если «акелла промахнулся» будет всем. Однако, как этому человеческому взаимодействию могут противостоять «бездушные правила»? (Я до сих пор видел видел только увеличение «секирбашки» центром, активно компенсируемое их необязательностью на местах. Но, может, есть иные варианты?)
                      0
                      Добавлю, что, конечно, все процессы схожие с описанными выше в компании были, все эскалировалось примерно как вы описали и т.д. Но смысл в том, что ты можешь хоть обписаться процессами и получить 100500 подписей под вашими документами, собрать десятки митингов с менеджерами, админами, разрабабами и т.д. Пока разработчик который знает эту программу не откроет ее в дебаггере на проде и не посмотрит что там в реальности происходит, ничего с места не сдвинется.
                      Я не говорю, что это требуется в каждом случае. Если ошибка вопроизводится на деве по логам и дампам, ее конечно можно и будут исследовать там. Но бывает что не воспроизводится.
                      Более того, ошибка может быть никак не связана с последним релизом. Это может быть древний баг который просто ждал своего часа (наступления некоторой комбинации в данных и действиях пользователя и т.п.). Так что вы очень лихо это априори решили, что откат последнего релиза сразу восстановит систему. Далеко не всегда. Вы бесполезно потратите время на откат, который сам по себе уже может быть проблемой, например когда фичи нового релиза — это требования изменившегося законодательства. Кроме того, откат — не всегда быстрый процесс. Он может быть гораздо дольше чем исследовать проблему и быстро установить фикс.
                +1
                Интерестная статья. Но возникает вопрос — а как вы даете оценку проекта(с точки зрения ваших трудозатрат)? ну т.е. проект где все идет гладно, можно выполнить быстро. Где на каждом шаге вставляются палки в колеса — займет гораздо больше времени. Или часть работ выполняется по фактическим затратам?
                  +1
                  Спасибо! К сожалению такие проекты, особенно когда до этого мы не работали/не знаем особенности этого заказчика, становятся для нас сюрпризом. Оценка трудозатарт обычно рассчитывается для штатного проекта, так как спрогнозировать умышленное затягивание работ довольно сложно на этапе пресейла. Работы в любом случае выполняются всегда до их завершения, а поиск необходимых трудозатарт — это уже внутренняя кухня
                  +2

                  Люблю подобные статьи.


                  Эта мне очень напомнила статью Как успешно пройти любой пентест (вредные советы) и по содержанию, и по стилю изложения


                  Хотя не могу с уверенностью сказать, какая лучше :)

                    0
                    • чтобы получить объективную оценку состояния ИБ (для себя);
                    • потому что аудит является обязательным (для регуляторов);
                    • потому что аудит требуют партнеры или головная организация (для других).


                    Любой из перечисленных видов аудита преследует основную позитивную цель — сделать компанию лучше, локализовав текущие проблемы.

                    Правда в том, что только первый вариант еще куда ни шло. Во всех остальных случаях всё делается на отвали.

                      –1
                      Почему бы аудитору не пойти по другому пути? По окончанию опроса работника аудитором озвучивается, что будет записано в протокол, чтобы работник понимал, всю ответственность. Если компанией за установленный срок не были предоставлены свидетельства, подтверждающие выполнение пункта аудита, значит пункт не выполняется.
                        0
                        Соглашусь, путь верный и хорошо работает при отказе предоставлять информацию/«забывчивости» и пр. Однако это решение частной проблемы — получения информации в рамках интервью, от отфотошопленных скриншотов и прочих вещей в статье не спасет :)
                          0
                          Видимо, я неоднозначно выразился. Я в первом предложении описал вариант решения для опроса, во вотором — решение общей проблемы. Насколько мне известно, скриншоты не являются фактами подтверждения за исключением тех случает, когда их делали сами аудиторы либо они были нотариально заверенные. Аудитор должен придерживаться принципа «никому не доверять».
                          0
                          Интересно, за что карму испортили.!?
                          0
                          Детский сад, какой-то. Ну испортите Вы аудитору жизнь — а дальше что? Писать-то отчет по аудиту будет он. А если аудит заказал перспективный заказчик?

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

                          Самое читаемое