О сборе логов

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

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

Адаптируя свой лог-менеджмент к этой новой парадигме получается примерно следующее:
а) собирать логи надо все и обрабатывать централизованно (т.е. искать по всем сразу), поскольку едва ли удастся угадать где что полезного можно будет обнаружить в рамках расследования,
б) хранить именно сырые логи и иметь возможность в будущем их по-разному анализировать, - технологии атак меняются, меняются и подходы их обнаружения и расследования, а раз так, то надо иметь возможность делать различные выборки, по-разному отображая одни и те же данные; иными словами, по мере расследования я буду получать все новую информацию, которая позволит мне строить более точные запросы к данным и доставать все новые детали,
в) хранить логи надо долго, так как, обнаружив сейчас постэксплуатацию, надо уметь ее "отмотать" на неопределенно долгий срок назад, с целью понять "как это было" и "с чего все началось", чтобы, в конце концов, имея целостную картину, выработать эффективное противостояние.

Получается, что в таких условиях задача службы мониторинга уже не просто "как можно раньше прокукарекать и заткнуть все, что получится", а именно расследовать с целью выработки более эффективных мер. Тут хорошая аналогия вспоминается из практики: в логах антивируса фиксировалось постоянно заражение и успешное лечение одной и той же рабочей станции. В целом, можно было бы забить - заражение завершалось успешным лечением, однако несложное исследование показало, что дроппер не обнаруживался этим антивирусом, причем сидел уже настолько хорошо, что самые свежие сигнатуры были ни по чем, а то, что успешно лечилось - это уже его "полезные нагрузки" и вопрос был только в некотором временном лаге, когда-таки прилетел бы "правильно запакованный\пересобранный" малварь, приведший уже к последствиям, совпадающим с мотивами злоумышленника. Этот банальный пример показывает, что здесь мы видим именно постэксплуатацию, ибо прошляпили как залетел и как закрепился дроппер. Анализ проводился на большом периоде, поскольку попытки закачать "полезную нагрузку" не были чаще чем раз в день, причем разброс по времени был случаен. Но уже потом, вытащив дроппер, было интересно поискать его следы в логах Web-прокси, почтовой системы, пошариться SCCM-ом и антивирусом по всем десктопам в интерпрайзе, поискать его в логах системы контроля доступа к периферийным устройствам и вообще везде, от чего у нас есть логи (очевидно желание все это сделать одним поиском). Причем, с учетом того, что "грамотный" дроппер, закрепившись, не стал бы палиться сразу, ретроспективный анализ следов его залета к нам необходимо проводить на неопределенной глубине данных.

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

Сканеры уязвимостей@Enterprise

Следуя правильной причинно-следственной логике, прежде чем выбирать инструмент решения, следует понять задачу. Очевидно, сканер уязвимостей нужен для поиска уязвимостей, чтобы их потом латать и так, постепенно, улучшать свои ИТ-системы в предположении, что минимизация уязвимостей == повышение безопасности, наверно, это так и есть. 
Ранее, мы разбирались с уязвимостями (кому лень читать, можно послушать), в совокупности с предположением, что в компании не разрабатывается ПО, с необходимостью сканера не все понятно. 
Вообще, аудит мне подтверждает две вещи: что я делаю правильные вещи, и что я делаю эти вещи правильно. Второе - это аудит соответствия. Первое - пентест, этакая Зарница,  в идеале, может, даже и без оповещения, что мы в состоянии игры. Как я не раз отмечал, в большом интерпрайзе управляемость - один из важнейших моментов, а следовательно, обычно, есть централизованные системы управления элементами ИТ-комплекса, типа SCCM, выполняющих любые виды инвентаризации. Чем вам такая инвентаризация не аудит соответствия? Сейчас уже у любого производителя есть руководство по безопасной настройке, так называемые hardening-гайды, - аудит соответствия такому гайду легко автоматизировать, да и многие производители имеют автоматизированные инструменты, которые проверят соответствие (некоторые потом даже предложат и исправить) - совсем нетрудно дергать такие проверялки при инвентаризации. В общем, очевидно, уязвимости конфигурации средствами инвентаризации легко закрываются. 
Но закрываются и ошибки разработчиков, поскольку уязвимости коммерческого ПО решаются для интерпрайза единственным образом - установкой патчей. Если я имею дело с 0-day, то такие риски компенсируются другими "эшелонами" моей безопасности: сегментацией, "навесными" средствами с разными модными технологиями, типа "virtual patch", контролем доступа, постоянным мониторингом и пр. К тому же, если производитель нормальный (я рекомендую, и от души желаю, работать только с нормальными производителями), скорее всего он выпустит какие-нибудь рекомендации, что нам всем делать, пока он не выпустил патч. Производитель, в софте которого вы нашли уязвимость, а затем безрезультатно закидываете его enhancements request-ами с требованиями исправить проблему, - не достоин называться "нормальным", поэтому неразумно держать сканер исключительно для таких случаев.
Перейдем к пентестам. Здесь мы пытаемся удостоверитья, что мы делаем правильные вещи. Безусловно, здесь уже нужна автоматизация... Но, в случае уязвимости конфигурации - эксплуатация тривиальна, как правило, можно и не пробовать, а в случае уязвимости ПО - вопрос эксплуатируемости, обычно, исследован вендором, и этому исследованию можно и нужно верить, а проверять экплуатируемость сканером - ну разве что только из спортивного интереса - насколько хорошо производитель сканера реализовал эксплоит. Более того, исследовать вопрос насколько правильные вещи я делаю, мне едва ли нужно часто. А раз так, то, наврено, эффективнее нанять профессиональную команду, где натренированные практики будут использовать десятки инструментов, чем я-любитель буду в автоматизированном режиме использовать один, имеющейся у меня сканер.
Прниципиальная вещь: сканер не находит неизвестные уязвимости и вряд ли найдет больше, чем известно "нормальному" производителю исследуемого ПО.

Любопытно, что даже если я разрабатываю ПО, мне тоже едва ли подходит off-the-shelf сканер, - значительно эффективнее будет работать моя продуктовая безопасность, которая знает мои продукты лучше производителя сканера и имеет специализованные инструменты, адаптированные под мою продукцию, понимает, что дейстительно критично и поэтому может правильно расставлять приоритеты.

Подводя итог всему написанному, хочется все-таки понять, когда же мне нужен сканер:
0. У меня огромный разнородный ИТ-комплекс, поэтому мне невозможно детально разбираться с каждым, используемым у меня производителем (заниматься харденинком его решений), мне проще запустить комбайн, который на приемлемом уровне решит проблему (ну или хотя бы сделает что-то, что лучше, чем ничего).
1. Я не знаю свою инфраструктуру. Отсканировал - получил какое-то представление (почти п.0, но с условием необходимости быстрых результатов при отсутствии времени).
2. У меня нет систем управления ИТ-инфраструктурой, поэтому я это компенсирую сканером, реализовав следующий процесс управления ИТ-инфраструктурой: отсканировал --> нашел узявимости --> устранил --> отсканировал --> ...
2,5. У меня плохие отношения с ИТ, поэтому я не могу использовать их системы управления ИТ-инфраструкурой и должен обязательно иметь свою штуку.
3. У меня стандартные системы, чтобы в сканере под них были сигнаруты\профили.
4. Я не хочу разбираться с безопасной настройкой каждой из используемых у меня систем, мне удобнее иметь комбайн, который все мои ошибки конфигурации (в целом, отсутствующий патч тоже можно считать уязвимостью конфигурации) найдет мне в виде уязвимостей (тоже почти п.0, но при отсутствии объективной невозможности разобраться с рекомендациями производителей, я просто лентяй).
5. Меня вынудил комплайнс, требующий от меня наличия сканера, или инструмента управления уязвимостями, или еще чего подобного.
6. У меня есть желание поразвлечься - посмотреть эксплуатируемость стандартных уязвимостей (== доступных в сигнатурах\проверках сканера)
7. Я хочу\должен кому-то что-то продемонстрировать или доказать, сделать вау-эффект, или эффективность моей работы характеризуется количетсвом найденных уязвимостей.
8. Сканер - это мой инструмент situational awareness (что-то около п.1) - фундаментальное требование для эффективной работы SOC.

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

Сертификация аутентификации

...при сертификации не ищутся уязвимости - она всего лишь подтверждает функционал продукта и его соответствие требованиям регулятора.

Алексей Лукацкий

Отличный пост Алексея: все подробнейшим образом рассказано, объяснено, даны ссылки на руководящие документы, ... - методически и систематически все на высшем уровне.

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

Есть, например, такое требование: "МЭ должен обеспечивать идентификацию и аутентификацию администратора МЭ при его локальных запросах на доступ". Аутентификация, с точки зрения их же, регуляторов, терминов: "Проверка принадлежности субъекту доступа предъявленного им идентификатора; подтверждение подлинности". Можно предположить, что принадлежащим субъекту идентификатором в контексте данного определения считается пароль, который пользователь сам себе назначил (==известен только ему). Из чего, несложно понять простую логику: если пользователь проходит проверку принадлежности ему идентификатора, предъявляя системе идентификатор (пароль), ему не принадлежащий, то такое поведение системы нельзя считать обеспечением аутентификации. Говоря совсем просто: аутентификация, работающая с ошибкой, приводящей к НСД, не может называться аутентификацией, ибо сама по себе нужна лишь для того, чтобы НСД не было. Итого: в устройстве нет аутентификации, подтверждение ее наличия сертификатом - ошибка, из которой надо извлечь соответствующие уроки...

Конкретно в этом случае все было еще хуже, приведу цитату: "The argument to the strcmp call is <<< %s(un='%s') = %u, which is the backdoor password, and was presumably chosen so that it would be mistaken for one of the many other debug format strings in the code. This password allows an attacker to bypass authentication through SSH and Telnet. If you want to test this issue by hand, telnet or ssh to a Netscreen device, specify any username, and the backdoor password. If the device is vulnerable, you should receive an interactive shell with the highest privileges", так как я во-первых, предъявляя не свой пароль успешно аутентифицируюсь, а во-вторых, после этого я еще и авторизуюсь максимальным админом, ну, как минимум, не с полномочиями, указанного при аутентификации аккаунта.

... но вернемся к извлеченным урокам....
Вообще, внедряя процесс и инвестируя в него, необходимо всегда помнить цель, не надо инвестировать в тот процесс, который не приводит к цели, или степень приближения к цели не оправдывает инвестиций. Цель сертификации - подтверждение качества товара, защита потребителя. Если какой-то из видов сертификации этой цели не достигает, или достигает не нужной не той цели, в ней нет смысла => ее надо или изменить, или отменить. Если любая из заявленных функций может быть скомпрометирована наличием НДВ, так давайте оставим только сертификацию на НДВ. Отзыв сертификатов, при этом, - тоже нормальное решение ("не пойманный - не вор" - неподходящий в этом случае принцип), если практика показала, что в сертифицированном на НДВ продукте все-таки нашлись НДВ, логичны два последствия: а) отзыв сертификата, б) lessons learned для процесса сертификации - это нормально, так как ничего не стоит на месте и подходы к сертификации подтверждению качества продукта также должны эволюционировать.

ЗЫ: вот и Фортинет порадовал. Я когда-то в шею гнал разработчиков, хардкодящих пароли, а вот, оказывается, это общая практика....

Почему биометрия слаба?

Мы не требуем от вас невозможного, мы прекрасно понимаем, что при современных методах допроса у вас нет никаких шансов сохранить тайну

Р. Хайнлайн, "Двойная звезда" 

Если читать книжки по безопасности, то оттуда можно узнать, что биометрия - наиболее стойкий фактор аутентификации из оставшихся двух ("что я знаю" и "что я имею"). С ментальной точки зрения - это правильно, ибо подтвердить что я - это я наилучшим образом может фактор "что я есть", поскольку остальные два связаны с наличием некоторой тайны/секрета, биометрия же, по своей изначальной сути, не может быть препарирована, даже с использованием современных методов допроса.

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

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

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

Фактическое назначение сертификации

Много было написано об нереализации сертификацией своей основной задачи: защиты потребителя от некачественного товара, и вот очередное событие (дам несколько ссылок: раз, два, три ), причем продукт был сертифицирован. 

В очередной раз перечитал на что была сертификация... и только сейчас до меня дошло фактическое ее назначение! Сертификация мне подтверждает, что продукт, который я приобретаю может быть отнесен к определенному классу, беря во внимание наш пример, с чего начали, сертификация мне подтверждает, что покупаемый мною Juniper NetScreen-ISG может называться межсетевым экраном. Хорошо то, что сертификация по факту имеет смысл: если у вас есть сомнения в классификации того или иного продукта - сертификат вам подскажет, однако плохо то, что это знание мне, в общем-то, не нужно, поскольку я выбираю инструмент под свои цели и задачи, => мне важно что продукт умеет и насколько хорошо фактически он это делает, а не то, как он классифицируется или как называется.

 

О нарушении причинно-следственной связи

Очень странный вопрос мне на днях озвучили. Оказывается есть следующая проблема: компании покупают сложные решения безопасности (такие как SIEM, DLP, IDM и т.п.) и затем эти решения "не приживаются", вплоть до полного неиспользования... что с этим делать?

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

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

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

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

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

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

Не торопитесь покупать и ставить все подряд, сначала поймите свои цели.

Американское руководство по саботажу

Любая палка имеет, как минимум, два конца

Владимир Солдатов

Обычно истина - совокупность противоположных предположений (= Правда где-то посередине)

Из личного опыта

Если вы сложно решаете простое, то сложное вы не решите вовсе

Из личного опыта

Я много троллил глупости и абсурдности, но все еще сомневался в системности бессмыслия, в том, что, в конечном счете, идиотизм имеет цель, хотя и депутат Федоров открытым текстом говорил о бюрократии как об инструменте снижения эффективности, следовательно, - развале, и вот моим сомнениям положил конец документ (дам несколько ссылок: раз, два, три ) - далее по тексту буду называть его "методичка"....

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

Теперь я понял, что вся работа по сбору и анализу "техник" была напрасна - в методичке все они изложены в лучшем виде, систематизированы, даны рекомендации по их применению. То, с чем я наиболее часто сталкивался, и что попало в качестве "техник" в мои записки, изложено в разделе (11) General Interference with Organizations and Productions, поэтому, казалось бы, достаточно ознакомиться до способности уметь узнавать "техники" - это и позволит определять "засланца" на основании методички.

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

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