Comments 24
Вы ещё забыли рассказать про то, как при комплексном аудите иногда пентестеры в итоге дают вам скрины того что нужно, вместо сопротивляющихся работников заказчика.
Да, работа конечно веселая, для людей с крепкой нервной системой :-).
Но у меня есть один вопрос, который относится к ИБ вообще.
Где проходит граница между безопасностью и работоспособностью системы/бизнеса?
Т.е. я четко понимаю, что самая безопасная система — это та, которую отключили, ну и в граничном случае еще и сожгли.
Если закрыть все риски по безопасности и проводить жесткий аудит, то можно найти причины остановить любую работающую айти компанию.
Я вижу что на этой теме пасется просто куча больших и мелких бизнесов, толкающих заказчикам всякие решения «сквозного шифрования» и тому подобный «гербалайф».
Админы конечно могут забрать у всех доступ ко всему, все перекрыть, зашифровать, запаковать и опечатать (это по-моему их голубая мечта). Но как в таких условиях работать?
Но у меня есть один вопрос, который относится к ИБ вообще.
Где проходит граница между безопасностью и работоспособностью системы/бизнеса?
Т.е. я четко понимаю, что самая безопасная система — это та, которую отключили, ну и в граничном случае еще и сожгли.
Если закрыть все риски по безопасности и проводить жесткий аудит, то можно найти причины остановить любую работающую айти компанию.
Я вижу что на этой теме пасется просто куча больших и мелких бизнесов, толкающих заказчикам всякие решения «сквозного шифрования» и тому подобный «гербалайф».
Админы конечно могут забрать у всех доступ ко всему, все перекрыть, зашифровать, запаковать и опечатать (это по-моему их голубая мечта). Но как в таких условиях работать?
суть не в том, чтобы забрать доступ, а в том, чтобы усилить систему внутреннего контроля.
если речь про банки, где крутится много денег и риски высоки — то нужно много людей (бюрократия), которые бы проверяли, перепроверяли, утверждали, контролировали, измеряли и прочее-прочее каждое изменение.
Формула, что чем больше людей вовлечено, значит тем больше распределение ответственности и полномочий, и один человек не зафакапит систему.
В целом смотрят на зрелость процессов по (capability maturity model), чем больше денег крутится, значит тем выше риск, и нужно чтобы процессы были более зрелые, более бюрократичные, больше людей, больше бумаги, больше согласований и разрешений.
это касается и внутреннего контроля (рисковики контролят фронт-офис, бек-офис контролит мидл-офис, внутренний аудит контролирует бек-офис, внешний аудит контролирует всех внутри, регуляторы-государство смотрят и на тех и других).
Кстати не всегда для безопасника решение забрать доступ. Доступ достаточно защитить, например не по паролю, а по второму фактору (токен) и дать доступ на время, а не на постоянку и т.д.
Целые многомиллиардные компании создаются на одной простой идее, что доступ к серверам надо защищать (Израильский Cyberark например)
если речь про банки, где крутится много денег и риски высоки — то нужно много людей (бюрократия), которые бы проверяли, перепроверяли, утверждали, контролировали, измеряли и прочее-прочее каждое изменение.
Формула, что чем больше людей вовлечено, значит тем больше распределение ответственности и полномочий, и один человек не зафакапит систему.
В целом смотрят на зрелость процессов по (capability maturity model), чем больше денег крутится, значит тем выше риск, и нужно чтобы процессы были более зрелые, более бюрократичные, больше людей, больше бумаги, больше согласований и разрешений.
это касается и внутреннего контроля (рисковики контролят фронт-офис, бек-офис контролит мидл-офис, внутренний аудит контролирует бек-офис, внешний аудит контролирует всех внутри, регуляторы-государство смотрят и на тех и других).
Кстати не всегда для безопасника решение забрать доступ. Доступ достаточно защитить, например не по паролю, а по второму фактору (токен) и дать доступ на время, а не на постоянку и т.д.
Целые многомиллиардные компании создаются на одной простой идее, что доступ к серверам надо защищать (Израильский Cyberark например)
Ну вот пример, из далекой галактики… В одном банке имеется отдел разработки. Там программисты пишут и кастомизируют банковский софт. Продакшн огорожен со всех сторон, так что только админы имеют к нему полный доступ. Программистов туда не пускают на пушечный выстрел — все каналы перекрыты на уровне файрволов внутренней сети, не говоря уже про логины/пароли. У разрабов отдельная сеть, ибо они, о ужас!, подключаются к интернету со своих десктопов, подкачивают всякие пакеты и обновляют версии IDE, а некоторые даже читают хабр :-). В один прекрасный момент в продакшене начинает крэшится важная программа. Админы информируют, но починить то сами не могут. Привычный вариант «выключить и включить» внезапно не помогает. Предоставляют разрабам лог и дамп, но воспроизвести ошибку не тестовой среде не получается. Понятно, надо разработчикам доступиться до продакшена с нормальными такими правами и своими тулами, чтобы просмотреть, что в этой программе происходит, чтобы быстро понять проблему. Админы — ни в какую, мол, это невозможно никогда! Мы вам не верим и все такое. Ок, начальник отдела разработки пишет докладную мол нам нужен такой то доступ, без него исследовать проблему не представляется возможным, на тесте ошибка не воспроизводится, и со спокойной душой идет домой, рабочий день закончился.
Админы, думая, что они самые умные, обложились тоннами всяких документов по безопасности, которые предписывают «не пущать». Где-то к ночи, проблема доходит до самого верха, где понимают, что если не починить все до утра, проблемы начнутся немаленькие… Дальше, я оставлю читателю домыслить развитие событий :-).
Вы спросите, а почему мол о такой ситуации не позаботились заранее, не продумали процедуру доступа для разрабов к продакшену для решения подобных ситуаций? Ха, так, конечно, о такой ситуации отдел разработки предупреждал и боролся за доступ (все ответы «низзя» заботливо сохранены).
Но админы и безопасники встали стеной и предъявили кучу всяких рекомендаций по безопасности, разграничению доступа и т.п. В том числе и тот аргумент, что если разрабы вдруг получат доступ к проду, то аудиторы этот факт выявят и не одобрят.
К чему я все это пишу? А к тому, что, IMHO, ставить во главу угла безопасность — это путь к краху. Первостепенной, мне кажется, должна быть надежность работы системы, а не бюрократическая составляющая. Конечно, бюрократия нужна. Но дело в приоритетах. Иначе получите вышеописанную ситуацию — с бюрократией все ок, аудиты пройдены, да система упала и починить ее в рамках установленных безопасниками процессов не представляется возможным.
Админы, думая, что они самые умные, обложились тоннами всяких документов по безопасности, которые предписывают «не пущать». Где-то к ночи, проблема доходит до самого верха, где понимают, что если не починить все до утра, проблемы начнутся немаленькие… Дальше, я оставлю читателю домыслить развитие событий :-).
Вы спросите, а почему мол о такой ситуации не позаботились заранее, не продумали процедуру доступа для разрабов к продакшену для решения подобных ситуаций? Ха, так, конечно, о такой ситуации отдел разработки предупреждал и боролся за доступ (все ответы «низзя» заботливо сохранены).
Но админы и безопасники встали стеной и предъявили кучу всяких рекомендаций по безопасности, разграничению доступа и т.п. В том числе и тот аргумент, что если разрабы вдруг получат доступ к проду, то аудиторы этот факт выявят и не одобрят.
К чему я все это пишу? А к тому, что, IMHO, ставить во главу угла безопасность — это путь к краху. Первостепенной, мне кажется, должна быть надежность работы системы, а не бюрократическая составляющая. Конечно, бюрократия нужна. Но дело в приоритетах. Иначе получите вышеописанную ситуацию — с бюрократией все ок, аудиты пройдены, да система упала и починить ее в рамках установленных безопасниками процессов не представляется возможным.
сразу могу сказать что корень проблемы не в безопасниках. Проблема в незрелых процессах управления ИТ инцидентами.
Обычно как происходит когда находится проблема:
1. Хелпдеск/коллцентр/ServiceNow или другая система мониторинга сообщает о проблема и создает Инцидент с № и фиксирует время начала проблем. Саппорт первой линии, ответственные за серваки пытается починить/перезагрузить/перевести траффик на бекапные серваки (hot standby)
2. Если по истечении установленных SLA (30 минут скажем) инцидент не закрыт, он автоматом эскалируется на второй уровень. Т.к. сервак уровня ядра банка — это уровень 0, инцидент ставится на высокий приоритет и извещается вся Major Incident Team. А это значит что никто из МИТ не уходит домой и все сидят на одном конференс-звонке и решают проблему сообща. в МИТ (также называется Technology Command Center) сидят все представители ИТ: и девопсы и админы и безопасники и прогеры и тестеры, и даже вендора зовут если понадобится.
3. Цель MIT — не разобраться в проблеме, а восстановить работоспособность системы. Если проблема возникла после недавнего апдейта, то софт откатывается на версию назад. Диагностика и нахождение причины проблемы не самое главное!
4. когда система заработала, тогда программисты могут сами спокойно сидеть и разбираться в чем была проблема, воссоздавать полностью боевую среду у себя в тесте и пробовать разные штуки, и писать отчеты об инциденте
В вашем случае наверное вы просили доступ в прод без создания Большого Инцидента, еще до эскалации до менеджмента. Надо было прописать жесткие SLA — типа если проблема в АБС в течении рабочего дня и поддержка первой линии не решает ее за полчаса, то инцидент эскалируется до руководства, созывается большая команда и в рамках инцидента и решают проблему, и никакой аудитор не будет против что вот Васе дали доступ в прод.
У аудитора будут вопросы если доступ в прод давать без инцидента — это проблема да.
Обычно как происходит когда находится проблема:
1. Хелпдеск/коллцентр/ServiceNow или другая система мониторинга сообщает о проблема и создает Инцидент с № и фиксирует время начала проблем. Саппорт первой линии, ответственные за серваки пытается починить/перезагрузить/перевести траффик на бекапные серваки (hot standby)
2. Если по истечении установленных SLA (30 минут скажем) инцидент не закрыт, он автоматом эскалируется на второй уровень. Т.к. сервак уровня ядра банка — это уровень 0, инцидент ставится на высокий приоритет и извещается вся Major Incident Team. А это значит что никто из МИТ не уходит домой и все сидят на одном конференс-звонке и решают проблему сообща. в МИТ (также называется Technology Command Center) сидят все представители ИТ: и девопсы и админы и безопасники и прогеры и тестеры, и даже вендора зовут если понадобится.
3. Цель MIT — не разобраться в проблеме, а восстановить работоспособность системы. Если проблема возникла после недавнего апдейта, то софт откатывается на версию назад. Диагностика и нахождение причины проблемы не самое главное!
4. когда система заработала, тогда программисты могут сами спокойно сидеть и разбираться в чем была проблема, воссоздавать полностью боевую среду у себя в тесте и пробовать разные штуки, и писать отчеты об инциденте
В вашем случае наверное вы просили доступ в прод без создания Большого Инцидента, еще до эскалации до менеджмента. Надо было прописать жесткие SLA — типа если проблема в АБС в течении рабочего дня и поддержка первой линии не решает ее за полчаса, то инцидент эскалируется до руководства, созывается большая команда и в рамках инцидента и решают проблему, и никакой аудитор не будет против что вот Васе дали доступ в прод.
У аудитора будут вопросы если доступ в прод давать без инцидента — это проблема да.
Ага. Да. В той истории, как раз оказалось, внезапно, что можно и из дома залогиниться в прод. И, да, работать через расшаренный терминал через цитрикс предлагали.
Конечно, именно о таком режиме работы по выявлению багов мечтают разработчики :-).
Ребята, зачем разрабу ваш расшаренный ssh терминал через два гейта, если мне нужно подтянуть дебаггер? Разработчику может быть некомфортно работать в терминале, где все настроено строго под выполнение рутинных админских задач по бакапу и т.д. и нет ничего, что разраб использует ежедневно и к чему привык.
По аналогии, я вот свою машину могу вести в любом состоянии с закрытыми глазами кажется. Все действия на автомате, руки сами все делают… Пришлось тут по случаю рулить чужой — я почувствовал себя новичком на площадке. Почему в принципе вы считаете, что админы настолько доверенные люди, что только им позволено, а разрабы могу исключительно через расшаренный экран под пристальным надзором комманды из админов с пальцем на красной кнопке, типа только мышь не туда скользнула — сразу рубим сеть :-).
Насчет вот этих всех авралов… Есть вообще-то трудовое законодательство. И 8-часовой рабочий день. И, потом, проблему можно было спокойно решить в рабочее время.
Потом, вот эти все фантазии, насчет давать внезапно доступ только по инциденту…
Человек в первый раз в жизни зайдет на тот энвайромент — а там все по-другому, чем на его дев машине. Нет привычных комманд, шорткатов, тулов и т.д.
Весь мой опыт говорит — без регулярного опыта работы на проде, сходу, ночью, куча времени будет потрачена на совершенно левые не относящиеся к проблеме вещи.
Конечно, именно о таком режиме работы по выявлению багов мечтают разработчики :-).
Ребята, зачем разрабу ваш расшаренный ssh терминал через два гейта, если мне нужно подтянуть дебаггер? Разработчику может быть некомфортно работать в терминале, где все настроено строго под выполнение рутинных админских задач по бакапу и т.д. и нет ничего, что разраб использует ежедневно и к чему привык.
По аналогии, я вот свою машину могу вести в любом состоянии с закрытыми глазами кажется. Все действия на автомате, руки сами все делают… Пришлось тут по случаю рулить чужой — я почувствовал себя новичком на площадке. Почему в принципе вы считаете, что админы настолько доверенные люди, что только им позволено, а разрабы могу исключительно через расшаренный экран под пристальным надзором комманды из админов с пальцем на красной кнопке, типа только мышь не туда скользнула — сразу рубим сеть :-).
Насчет вот этих всех авралов… Есть вообще-то трудовое законодательство. И 8-часовой рабочий день. И, потом, проблему можно было спокойно решить в рабочее время.
Потом, вот эти все фантазии, насчет давать внезапно доступ только по инциденту…
Человек в первый раз в жизни зайдет на тот энвайромент — а там все по-другому, чем на его дев машине. Нет привычных комманд, шорткатов, тулов и т.д.
Весь мой опыт говорит — без регулярного опыта работы на проде, сходу, ночью, куча времени будет потрачена на совершенно левые не относящиеся к проблеме вещи.
Написано же — нет нужды понимать в чём проблема и тащить отладчик и вот это всё. Это не задача первостепенной важности. Задача первостепенной важности — это сделать корректный Rollback/переключение на резерв, а разбор полётов устраивать уже потом.
Так я же пояснил, что крэш может не быть связан с релизом непосредственно. Большинство ошибок релиза вылавливаются еще на этапе PIV.
И в любом случае, разговор же здесь не про время, а про нахождение ошибки. Вот на проде идут крэши. На тесте они не воспроизводятся. Сложность системы такая, что можно очень долго гадать что там и как и реальный действенный способ понять что происходит — это дать доступ разрабам к проду. А откатить релиз который уже давно в проде — ну, попытайтесь получить разрешение ;-). Когда в релизе изменена методика финансового подсчета чего нибудь там по требованию законодательства и циферки уже 3 недели считаются по новой методе. Откатить бд системы в ядре банка на 3 недели тоже? Удачи ;-). Безумству храбрых поем мы песню, как сказал великий писатель.
И в любом случае, разговор же здесь не про время, а про нахождение ошибки. Вот на проде идут крэши. На тесте они не воспроизводятся. Сложность системы такая, что можно очень долго гадать что там и как и реальный действенный способ понять что происходит — это дать доступ разрабам к проду. А откатить релиз который уже давно в проде — ну, попытайтесь получить разрешение ;-). Когда в релизе изменена методика финансового подсчета чего нибудь там по требованию законодательства и циферки уже 3 недели считаются по новой методе. Откатить бд системы в ядре банка на 3 недели тоже? Удачи ;-). Безумству храбрых поем мы песню, как сказал великий писатель.
Однажды, когда я еще был молодой и горячий, когда мне когда понадобилось для фикса посмотреть — что же там именно не так на проде (логи и внутренности которого огорожены по небалуйся), то я залил небольшую заплатку, чтобы оно логи пересылало куда мне надо было, а потом вместе с фиксом — выпилил ее из кода обратно.
С тех пор утекло уже времени, и я уже спокойно и неторопливо делаю эскалацию «нужен доступ» в таких случаях, но мысль :«есть доступ разраба к исходникам? Есть доступ пользователя к рабочей системе? Ну ок, можете обпаролиться там и обзапрещаться хоть на все сервера» — до сих пор со мной %)
С тех пор утекло уже времени, и я уже спокойно и неторопливо делаю эскалацию «нужен доступ» в таких случаях, но мысль :«есть доступ разраба к исходникам? Есть доступ пользователя к рабочей системе? Ну ок, можете обпаролиться там и обзапрещаться хоть на все сервера» — до сих пор со мной %)
Хех, скажу более, такая ситуация совсем нередко встречается. Разрабам приходится встраивать в софт закладки, чтобы в случае чего на проде быстро и в комфортных условиях посмотреть ошибку. Классический случай, когда некая комбинация действий в клиенте открывает консоль.
Т.е. все эти драконовские меры на самом деле ведут к появлению очень мрачных вещей.
Т.е. все эти драконовские меры на самом деле ведут к появлению очень мрачных вещей.
У нас такое не прокатит) А если прокатит и узнают — уволят примерно минут за 20, уже были преценты. К тому же, подобные закладки нужно еще через ревью протащить.
1) Что, и даже Spring Actuator (там в зависимостях добавляется пару строк, а в коде ничего даже не отсветит) не прокатит?
2) тогда было другое время, можно было делать деплой не из одной ветки — так что до ревью там дело не дошло ;)
UPD: Не то чтобы я всем советую так делать, просто я считаю, что антипаттерны тоже нужно знать и понимать, и система безопасности которая учитывает еще и людей (ака «вода дырку найдет, одними только правилами ей не запретишь, поэтому давайте всем жить дружно и помогать»), чем система безопасности которая работает как бюрократическая машина (напишите заявку на разрешение запроса получения доступа, в течение 10 дней мы вам ответим)…
2) тогда было другое время, можно было делать деплой не из одной ветки — так что до ревью там дело не дошло ;)
UPD: Не то чтобы я всем советую так делать, просто я считаю, что антипаттерны тоже нужно знать и понимать, и система безопасности которая учитывает еще и людей (ака «вода дырку найдет, одними только правилами ей не запретишь, поэтому давайте всем жить дружно и помогать»), чем система безопасности которая работает как бюрократическая машина (напишите заявку на разрешение запроса получения доступа, в течение 10 дней мы вам ответим)…
Надо менять процесс, а не тащить на прод дыры в ИБ. Я не припомню ещё ни одной ситуации, когда бы было оправдано тащить на прод непонятно что, вместо того, чтобы скорректировать процесс получения доступов.
Кстати, если система безопасности, не даёт вам творить непотребства, вроде тех, что вы описываете — это и есть тот случай, когда она учитывает ещё и людей, с их невероятной самоуверенностью в собственной непогрешимости :)
P.S.
Мое мнение предвзято. Я по образованию ИБ-шник, и хоть сейчас я только программист, мне душу греет любой грамотно выстроенный цугундер и я всегда всячески способствую его улучшению в любой компании, где работаю.
1) система всегда даст возможность «творить непотребства» (кроме случаев выключенной или отключенной системы) — цугундер будет разве что постфактум. И то — разве что если логи не потрутся. Иногда доходит до смешного — когда проще попросить младшего безопасника дать доступ неофициально, чем согласовывать старшего «по процедуре» (вот вам и польза от софтскиллз с межличностным общением)
2) +1 к «менять процесс». Я обеими руками за такое. Мне всегда приятно, когда есть вменяемые правила, защищающие меня, прод и бизнес от случайной ошибки (ака DROP TABLES или rm -rf / на проде). Проблема когда это все невменяемое (фичи добавляем каждый день, зато посмотреть логи с сервера — «пишите прошение на неделю вперед» а на следующей неделе: «мы их заархивировали, теперь они на сервере недоступны, а из архива нужно по другой процедуре делать запрос», и непонятно — плакать или смеяться)…
UPD: «попросить младшего безопасника дать доступ неофициально» — давным давно, когда еще никто не работал из дома, это выглядело так: приходит к админу\безопаснику делегация из меня и начальства, я сажусь за комп этого безопасника\админа и с его клавиатуры делается все то там нужно срочно сделать. Естественно, цугундер, если «акелла промахнулся» будет всем. Однако, как этому человеческому взаимодействию могут противостоять «бездушные правила»? (Я до сих пор видел видел только увеличение «секирбашки» центром, активно компенсируемое их необязательностью на местах. Но, может, есть иные варианты?)
2) +1 к «менять процесс». Я обеими руками за такое. Мне всегда приятно, когда есть вменяемые правила, защищающие меня, прод и бизнес от случайной ошибки (ака DROP TABLES или rm -rf / на проде). Проблема когда это все невменяемое (фичи добавляем каждый день, зато посмотреть логи с сервера — «пишите прошение на неделю вперед» а на следующей неделе: «мы их заархивировали, теперь они на сервере недоступны, а из архива нужно по другой процедуре делать запрос», и непонятно — плакать или смеяться)…
UPD: «попросить младшего безопасника дать доступ неофициально» — давным давно, когда еще никто не работал из дома, это выглядело так: приходит к админу\безопаснику делегация из меня и начальства, я сажусь за комп этого безопасника\админа и с его клавиатуры делается все то там нужно срочно сделать. Естественно, цугундер, если «акелла промахнулся» будет всем. Однако, как этому человеческому взаимодействию могут противостоять «бездушные правила»? (Я до сих пор видел видел только увеличение «секирбашки» центром, активно компенсируемое их необязательностью на местах. Но, может, есть иные варианты?)
Добавлю, что, конечно, все процессы схожие с описанными выше в компании были, все эскалировалось примерно как вы описали и т.д. Но смысл в том, что ты можешь хоть обписаться процессами и получить 100500 подписей под вашими документами, собрать десятки митингов с менеджерами, админами, разрабабами и т.д. Пока разработчик который знает эту программу не откроет ее в дебаггере на проде и не посмотрит что там в реальности происходит, ничего с места не сдвинется.
Я не говорю, что это требуется в каждом случае. Если ошибка вопроизводится на деве по логам и дампам, ее конечно можно и будут исследовать там. Но бывает что не воспроизводится.
Более того, ошибка может быть никак не связана с последним релизом. Это может быть древний баг который просто ждал своего часа (наступления некоторой комбинации в данных и действиях пользователя и т.п.). Так что вы очень лихо это априори решили, что откат последнего релиза сразу восстановит систему. Далеко не всегда. Вы бесполезно потратите время на откат, который сам по себе уже может быть проблемой, например когда фичи нового релиза — это требования изменившегося законодательства. Кроме того, откат — не всегда быстрый процесс. Он может быть гораздо дольше чем исследовать проблему и быстро установить фикс.
Я не говорю, что это требуется в каждом случае. Если ошибка вопроизводится на деве по логам и дампам, ее конечно можно и будут исследовать там. Но бывает что не воспроизводится.
Более того, ошибка может быть никак не связана с последним релизом. Это может быть древний баг который просто ждал своего часа (наступления некоторой комбинации в данных и действиях пользователя и т.п.). Так что вы очень лихо это априори решили, что откат последнего релиза сразу восстановит систему. Далеко не всегда. Вы бесполезно потратите время на откат, который сам по себе уже может быть проблемой, например когда фичи нового релиза — это требования изменившегося законодательства. Кроме того, откат — не всегда быстрый процесс. Он может быть гораздо дольше чем исследовать проблему и быстро установить фикс.
Интерестная статья. Но возникает вопрос — а как вы даете оценку проекта(с точки зрения ваших трудозатрат)? ну т.е. проект где все идет гладно, можно выполнить быстро. Где на каждом шаге вставляются палки в колеса — займет гораздо больше времени. Или часть работ выполняется по фактическим затратам?
Спасибо! К сожалению такие проекты, особенно когда до этого мы не работали/не знаем особенности этого заказчика, становятся для нас сюрпризом. Оценка трудозатарт обычно рассчитывается для штатного проекта, так как спрогнозировать умышленное затягивание работ довольно сложно на этапе пресейла. Работы в любом случае выполняются всегда до их завершения, а поиск необходимых трудозатарт — это уже внутренняя кухня
Люблю подобные статьи.
Эта мне очень напомнила статью Как успешно пройти любой пентест (вредные советы) и по содержанию, и по стилю изложения
Хотя не могу с уверенностью сказать, какая лучше :)
- чтобы получить объективную оценку состояния ИБ (для себя);
- потому что аудит является обязательным (для регуляторов);
- потому что аудит требуют партнеры или головная организация (для других).
Любой из перечисленных видов аудита преследует основную позитивную цель — сделать компанию лучше, локализовав текущие проблемы.
Правда в том, что только первый вариант еще куда ни шло. Во всех остальных случаях всё делается на отвали.
Почему бы аудитору не пойти по другому пути? По окончанию опроса работника аудитором озвучивается, что будет записано в протокол, чтобы работник понимал, всю ответственность. Если компанией за установленный срок не были предоставлены свидетельства, подтверждающие выполнение пункта аудита, значит пункт не выполняется.
Соглашусь, путь верный и хорошо работает при отказе предоставлять информацию/«забывчивости» и пр. Однако это решение частной проблемы — получения информации в рамках интервью, от отфотошопленных скриншотов и прочих вещей в статье не спасет :)
Видимо, я неоднозначно выразился. Я в первом предложении описал вариант решения для опроса, во вотором — решение общей проблемы. Насколько мне известно, скриншоты не являются фактами подтверждения за исключением тех случает, когда их делали сами аудиторы либо они были нотариально заверенные. Аудитор должен придерживаться принципа «никому не доверять».
Интересно, за что карму испортили.!?
Детский сад, какой-то. Ну испортите Вы аудитору жизнь — а дальше что? Писать-то отчет по аудиту будет он. А если аудит заказал перспективный заказчик?
Sign up to leave a comment.
Вставляем палки в колеса на аудиторских проверках, или Как сделать аудит ИБ максимально некомфортным для аудитора