На IDM or not IDM

Игорь, несмотря на то, что я буду стараться быть кратким, все-таки я решил воспользоваться своей возможностью писать постом, а не комментом :-)

1. Разные оргдокументы, требующие живых подписей, полагаю писались до нового закона о ЭП, откуда читаем в Статье 4:

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

+ по новому закону не обязательно использовать ГОСТовый.

Т.е., в целом, ничего не мешает двигаться в сторону электронного согласования.

Далее по рискам.

2.То, что Администратор царь и Бог - согласен. Но можно это компенсировать аудитом на отчуждаемое хранилище. Никто не собирается играть с админом в кошки-мышки, и риск его нелояльности не стоит пытаться компенсировать исключительно техническими мерами. Но можно:
а) Построить отчет соответствия фактических доступов в системе согласованным. Здесь уже многое зависит от реализации отчета, но технически практически все можно предусмотреть: предоставление доступа непосредственно аккаунтам, а не через согласованные группы, предоставление доступа через несогласованные группы, нелегитимное включение групп в группы, и т.п. б) вести аудит использования административных прав и критичных операций и забирать лог "к себе" (в SIEM) в, практически, реальном времени.
3. Фильтр твой - ужасен: "Если человеку действительно надо - он упорствует и получает доступ".
4. "Риски, связанные с использованием Избирательной модели управления доступом" - вообще, я тут о том, что есть принципиальная проблема в том, что некоторая сущность, Владелец ресурса, на свое усмотрение принимает решение о присвоении\неприсвоении доступа. Вообще-то такое доверие Владельцу небезопасно: он может ошибаться как по доброте душевной, так и по злому умыслу. Ролевая модель в этом плане предпочтительнее, поскольку ее можно привязать к штатке или каким-либо другим функциональным образованиям, тогда присвоение роли будет происходить при назначении пользователя на позицию (штатную или функциональную, например, роль в проекте), что уже выполняется более или менее коллегиально, а не по решению какого-то там Владельца ресурса.
5. С устареванием прав можно бороться:
- принудительной инициализацией пересмотра прав пользователей при его движении по штатке,
- предоставление доступа на время Проекта или просто на время (в случае необходимости, пользователи будут продливать - тоже сродни твоему "фильтру", но менее цинично :-)).
6. Про SOD-ы. Не все так просто: "есть доступ" и "нет доступа". Есть роли, которые нельзя совмещать и тебе это известно: Разработчик и Тестировщих, Разработчик и Пользователь, Бухгалтер и Казначей, пр. При проектировании бизнес-процесса необходимо выделять критичные операции, которые недопустимо совершить кому-то единолично. Тут и наши любимые админы: да они могут все, но от их действий должен остаться аудиторский след, причем в месте, где они не смогут "потереть логи" => администратор системы и администратор безопасности должны быть разными людьми. Аудит, традиционно, должен быть независим. В общем, роли, которые недопустимо совмещать, найдутся. Так вот, при присвоении ролей, следует проверять SOD-ы, т.е. есть пользователю присваивается Роль2, а у него, скажем, уже есть Роль1, дающая с Ролью2 конфликт высокого риска, такое присвоение не должно свершиться. Очевидно, что недопустимость совмещения Роли1 с Ролью2, разумнее проверять автоматически. Это сможет сделать IDM.
7. Избыточность полномочий частично компенсируется мерами изложенными в 5. Но твой пост на эту тему крайне интересен - пиши.

Далее пост твой сводится к извечному выбору между разработкой и коробочным решением. Тебе же известно, что я тоже наколеночник со стажем :-) и со времен работы в РосНИИРОС свято верю, что gcc и perl достаточно для реализации чего угодно :-) Но, я на личном опыте знаю чего стоит разобраться в коде талантливого программиста (а вы часто делаете комментарии? Вот я с тех пор часто, хотя не уверен, что это поможет тем, кому достанутся мои труды), поэтому все эти скрипты и "программки" имеют достаточно высокую вероятность умереть с уходом разработчика. Попробую систематизировать выбор тезисами (не буду их расшифровывать, если будут спорные моменты, лучше напрягусь и сделаю отдельный пост):
1. надо стараться выбирать коробочное решение. Стоимость его поддержки в будущем - ниже.
2. надо стараться настройку выполнять силами будущей поддержки. Либо, если уж настройка выполняется в проекте, будущая поддержка должна плотно участвовать в настройке.
3. если коробочное решение в своей типовой\рекомендуемой конфигурации не удовлетворяет потребностям, следует посмотреть в сторону изменения бизнес-процессов в соответствие с тем, что запрограммировано в коробочном решении.
4. должно быть нормальное описание конфигурации и Configuration Management.
5. если коробочное решение не удовлетворяет и требуется более 30% доработки - выбираем разработку. Тут поясню. Коробочные решения предлагают некие встроенные языки: Sun Java IDM - x-press, SAP - ABAP, у 1С - свой, русскоязычный, и т.п. Все эти языки создают иллюзию бесконечной гибкости (иллюзию? Я вас уверяю, что писать на C# куда приятнее, чем на X-Press + практически никаких ограничений!). Так вот, если предстоит "допиливать" более 30% коробочной бизнес-логики, и обойти это никак - берите Visual Studio, Java NetBeans, perl+vi или что вы там любите - это будет лучше.
6. если вы уж взялись за разработку, то тут уже надо хорошенько подумать о том, как потом не похоронить творение с уходом разработчика, чтобы "человечек с хорошими штанами" мог как-то поддерживать, а еще лучше и развивать, эту разработку. Тут можно предложить - документировать код по формальным правилам (ох, только правила надо придумать....).

Linux - не все так плохо

Читал книжку, Linux глазами хакера, 3-е издание. Прочитал странную вещь:

Прошу прощения, что криво, но хотелось именно процитировать.

Еще с дремучего издания Андрея Робачевского известно, что символьная ссылка ссылается на имя файла (у нее даже размер равен имени файла с путем :-)), т.е. несмотря на то, что символьная ссылка имеет права 0777, это не значит, что будет полный доступ к файлу. Тем не менее, не поленился проверить. Думаю, комментарии излишни:

root@daczcsvst60pde:/# ln -s /etc/shadow /etc/shadow.lnk

root@daczcsvst60pde:/# ll /etc/shadow*

-rw-r----- 1 root shadow 1218 Feb 6 17:50 /etc/shadow

-rw------- 1 root root 1218 Feb 6 17:50 /etc/shadow-

lrwxrwxrwx 1 root root 11 Mar 14 22:04 /etc/shadow.lnk -> /etc/shadow

svsoldatov@daczcsvst60pde:/$ cat /etc/shadow

cannot read /etc/shadow: Permission denied

svsoldatov@daczcsvst60pde:/$ cat /etc/shadow.lnk

cannot read /etc/shadow.lnk : Permission denied

Может, я что неправильно понял?

IDM or not IDM

Не говорите, что эфир не существует! Только начал упорядочивать на бумаге порядок оформления заявок на доступ к информационным ресурсам, как Сергей затрагивает тему IDM!

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

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

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

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

Потом появились заявки на блокировку учетных записей. Сделали их для борьбы с мертвыми душами. Но такой способ блокировки не был принят пользователями.

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

Что имеем сейчас:

• почти 20000 заявок собранных за 3 года.
• категорированный перечень из более чем 150 информационных ресурсов
• дикие трудозатраты на оформление и сопровождение заявок
• историю доступа пользователей к ресурсам
• некое подобие шаблона прав для пользователей, когда вновь принятому сотруднику высылается список заявок оформленных его предшественником
• випов, получающих доступ куда хочется посредством движения бровью

А теперь давайте посмотрим, как мы подвержены рискам указанным тут:

• Предоставление группой эксплуатации (ИТ) доступа, отличного от согласованного - какая ни была бы ИС - с IDM или без него, администратор всегда сможет дать доступ по высшему повелению или внутреннему позыву.
• Предоставление доступа на основании «некорректного» согласования (доступ не согласован в установленном порядке) - ну для этого мы имеем историю заявок для определенной позиции. Кстати говоря, нельзя не упомнить здесь следующее - 90% сотрудников пишут заявку на доступ в Интернет, к внешней электронной почте и сменным носителям. Рассматривать все эти заявки - долго, поэтому на первую заявку мы с вероятностью 98% отвечаем отказом. Если человеку действительно надо - он упорствует и получает доступ. Вот такой фильтр.
• Риски, связанные с использованием Избирательной модели управления доступом - решаем на коленке, через просмотр истории заявок для новых сотрудников
• невозможность выявления некорректных прав пользователей - центральный сервер syslog собирает и хранит записи об изменениях в структуре АД, планируем делать ежедневный diff для АД и максимально автоматизировано сравнивать его с табличкой в шарепоинте
• устаревание прав ввиду изменения бизнес-процессов Компании - почему мне не верится, что IDM может помочь "бороться" с любовью людей "переставлять мебель" спонтанно и быстро
• некорректное совмещение критичных полномочий в информационных системах - но ведь мы не военное ведомство. У нас по сути групп доступа 2 - сотрудники имеющие доступ к коммерческой тайне и сотрудники не имеющие к тайне доступа... Неужели без IDM-ма не справимся с этими 2-мя группами?
• избыточные полномочия пользователей в случае изменения их статуса в бизнес-процессах Компании - а вот этому посвятим следующий пост.

Что мы видим? Наняв человечка с минимальной квалификацией и хорошими штанами, выплачивая ему 7-15 т.р. в месяц мы можем получить естественно-интеллектуальную систему управления учетными записями. С больничными и отпуском есть проблема, но размер зарплаты позволяет нам организовать холодный или даже горячий резерв!

IDM для Информационной безопасности

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

Преимущества от внедрения IDM получат все: ИТ, так как повысят свою efficiency - многие работы будут автоматизированы, Бизнес, так как использование бизнес-ролей и ролевой модели доступа с привязкой к корпоративной оргструктуре и/или бизнес-процессам Компании позволят им понимать к чему сотрудники имеют доступ, Безопасность, так как будут адресованы ряд ключевых рисков, связанных с контролем доступа.

На безопасности хочется остановиться подробнее, отметив основное, что на мой взгляд должно объективно стимулировать движение в сторону подобных решений. Все-таки 21ый век на дворе и ручно-бумажно-пешконосный контроль доступа выглядит несовременно :-)

Риск: Предоставление группой эксплуатации (ИТ) доступа, отличного от согласованного.

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

Риск: Предоставление доступа на основании «некорректного» согласования (доступ не согласован в установленном порядке).

Контроль: Процесс согласования доступа жестко запрограммирован в IDM: правильность маршрута согласования обеспечена конфигурацией IDM.

Риск: Риски, связанные с использованием Избирательной модели управления доступом (discretionary access control, DAC)

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

Риск: невозможность выявления некорректных прав пользователей (некорректно присвоенных ранее или устаревших ввиду различного рода изменений в компании).

Контроль: IDM позволяет проводить сравнение своей базы доступов (корректно согласованных) с фактическим состоянием технических прав в обслуживаемых информационных системах. Таким образом, обеспечивается проведение периодического технического аудита полномочий пользователей, что позволит выявлять ошибки и злоупотребления.

Риск: устаревание прав ввиду изменения бизнес-процессов Компании.

Контроль: IDM предоставляет ответственным от бизнеса удобный интерфейс просмотра и корректирования бизнес-ролей пользователей. IDM позволяет этот процесс инициировать принудительно по расписанию, что позволит обеспечить выполнение требований безопасности. Подобный аудит безнес-ролей пользователей позволит в большей степени соблюдать принцип Минимума полномочий (Least Privilege) – не нужные, устаревшие права будут отобраны по инициативе бизнеса.

Риск: некорректное совмещение критичных полномочий в информационных системах.

Контроль: IDM позволяет автоматизировать соблюдение принципа Разделения ответственности (Segregation of Duties, SOD): Роли которые нельзя совмещать у одного пользователя не смогут быть запрошены и/или присвоены.

Риск: избыточные полномочия пользователей в случае изменения их статуса в бизнес-процессах Компании.

Контроль: IDM интегрируется с системами кадрового учета, таким образом, любое кадровое изменение пользователя будет инициировать процесс пересмотра прав пользователя в информационных системах.

Перечисленное - первое, что пришло в голову. Если что забыл - комментарии приветствуются.

Все в аутсорсинг!

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

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

Поскольку все читали модные книжки про ITIL, CobIT и т.п., аутсорсинг ИТ - распространенное явление. Всем понятны процессы, метрики, услуги, компоненты, SLA-и и прочие атрибуты качественного аутсорсинга.

Почему-то иногда (или зачастую), тем не менее, ИТ-аутсорсинговая компания остается дочерней компанией Заказчика. Это позволяет Заказчику влиять на различные внутренние процессы Подрядчика, что, очевидно, перекашивает аутсорсинг.

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

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

Но, вернемся к тому, что мультисорсинг неплох и попробуем сформулировать критерии вывода услуг на рынок. Я бы предложил следующие критерии:
1. Критичность. Как бы мы не верили в эффективный (== способный предоставить достойное качество сервиса) рынок, не все можно распродавать. Сюда относятся услуги, которые критичны по качеству, по доступности, по безопасности и т.п. Вопрос спорный, - идеалист может возразить, что теоретически можно все предусмотреть SLA-ем, но на практике создать идеальный SLA крайне сложно, а есть случаи, когда ошибаться нельзя. Тут еще такой момент: в высокотехнологичном сервисе, квалификация приемщика услуг должна быть не ниже Подрядчика, банально, чтобы понять и оценить. Да, мы придумываем метрики, пытаемся все померить и посчитать, чтобы численно выразить что такое плохо и что такое хорошо, но на практике не все так просто :-( Скажу даже больше, высококвалифицированный ИТшник, как и Безопасник должен постоянно быть "в бою", - и потому что для обладания экспертизой нужно иметь постоянную практику, и потому что в мире ИТ все крайне динамично меняется. В общем, как минимум, экспертиза какая-то быть должна надежная (== своя).
2. Наличие предложения на рынке. Нам нужна конкуренция, как единственный механизм обеспечения качества. Если на рынке нет\мало поставщиков, удовлетворяющих всем необходимым требованиям, очевидно это нельзя зааутсорсить.
3. Внутренние компетенции по услуге. Если мы обладаем высоким уровнем внутренней компетенции, бенчмаркинг показывает высокую эффективность (effectiveness & efficiency) нашего сервиса, это не надо продавать. Отсюда, кстати небольшое следствие: если что-то мы делать не умеем или делаем плохо, давайте попробуем это зааутсорсить. Но тут надо учесть то, что для приемки также нужна экспертиза (см. 1).
4. Степень соответствия стратегии. Да, у Подрядчика тоже должна быть Стратегия и, как следует из ISACAиных книжек про Governance, она должна тесно коррелировать со стратегией Заказчика\Компании. Стратегически важные сервисы не надо продавать.
5. Степень формализации требований Заказчика к услуге. Тут все понятно: не надо продавать то, что неформализовано, - тяжело оценить степень соответствия ожиданиям. Тоже, вроде как, все понятно, но если мы аутсорсимся потому что сами делаем плохо (п 3), очевидно оно у нас не формализовано, надо с этим что-то делать :-(
6. Себестоимость. Критерий сильно коррелирует с 3, ибо полностью про efficiency, но, думаю его стоит выделить отдельно. Смысл прост: если что-то мы делаем дороже, чем можно это купить на рынке, это стоит вывести на рынок. Если услуга на рынке стоит дороже, чем мы сами это делаем, лучше делать самому.
7. Стоимость управления и контроля. Нельзя аутсорсить ответственность! А раз ответственность от Заказчика никуда не девается, Подрядчика надо контролировать. Контроль должен быть осуществим, он должен быть дешевле, собственно, стоимости работ.

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

В заключение о правильном подходе:
1. придумать критерии,
2. пропустить через них все услуги Подрядчика
3. Вывести то, что по критериям надо выводить.
Идем от услуг и критериев, не от штата на баррель :-)

Понять лог keylogrecorder

Неплохая статья на Хабре о Meterpreter, способствует желанию все испробовать. Наибольший интерес, конечно, вызывает кейлоггер, - действительно, полезная штука. Проблема только в том, что, как правило, русские люди пишут по-русски, тогда как keylogrecorder, конечно, об этом не догадывается. Как следствие - просмотр логов его работы не дает желанных результатов :-(. Получается что-то типа такого:

$ cat test.txt

Ujybvs dtiybvb kexfvb?

C jrhtcns[ ujh e;t cytuf

C,t;fkb venysvb hexmzvb

Yf gjnjgktyyst keuf

<return> 'nj ntcn <ctrl> Ntcn 'nj <lctrl> <alt> Fktrcfylh Cthuttdbx Geirby<lmenu>

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

Первое что приходит на ум - Perl-овый tr, что-нибудь типа:

tr/`qwertyuiop[]asdfghjkl;'zxcvbnm,./ёйцукенгшщзхъфывапролджэячсмитьбю/

При этом программка выглядит так:

$ cat tr1.pl

#!/usr/bin/perl -w

while (){
   tr/`qwertyuiop[]asdfghjkl;'zxcvbnm,./ёйцукенгшщзхъфывапролджэячсмитьбю/;
   print;
}

Но не все так просто, к моему глубочайшему сожалению. Русские буквы, бывает, кодируются UTF-8 в 2 байта, а английские - в 1 байт...

Абсолютно рабочим вариантом является recode наш tr (всю Perl-овую программку) в кодировку где русские буквы однобайтовые, например так:

$ recode UTF-8..KOI8r tr-koi8r.pl

Затем, этим tr-koi8r.pl можно уже транслировать продукт keylogrecorder-а.

$ cat test.txt | ./tr-koi8r.pl >test2.txt

Помним, что у нас локаль - UTF-8...

у меня на Debian оно выглядит так:

$ locale

LANG=en_US.utf8

LANGUAGE=

LC_CTYPE="en_US.utf8"

LC_NUMERIC="en_US.utf8"

LC_TIME="en_US.utf8"

LC_COLLATE="en_US.utf8"

LC_MONETARY="en_US.utf8"

LC_MESSAGES="en_US.utf8"

LC_PAPER="en_US.utf8"

LC_NAME="en_US.utf8"

LC_ADDRESS="en_US.utf8"

LC_TELEPHONE="en_US.utf8"

LC_MEASUREMENT="en_US.utf8"

LC_IDENTIFICATION="en_US.utf8"

LC_ALL=

..., поэтому результат, test2.txt, следует вернуть в юникод:

$ recode KOI8r..UTF-8 test2.txt

И..., вуаля, уже что-то:

$ cat test2.txt

Uонимы вешними лучами?

C окрестых гор уже снега

Cбежали мутными ручьями

Yа потопленные луга

<rуегкт> это тест <cекд> Nест это <lcекд> <aде> Fлександр Cергеевич Gушкин<lmутг>

Есть кое-какие артефакты, но это потому, что заглавные буквы я забыл (:-) указать в tr, перевелись и управляющие клавиши, типа <lctrl> <alt> и т.п. Тем, не менее, в целом, такой вариант перевода трудов keylogrecorder-а, также возможен: программка на Perl в три строчки, дважды recode и все!

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

$ cat trc.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int checkIfCtrl(char *p);

int main(int argc, char **argv){
   const int n = 512;
   char *buf, *buf2, *ten, *tru, *tb, *tb2;
   char *enl = "`qwertyuiop[]asdfghjkl;'zxcvbnm,.~QWERTYUIOP{}ASDFGHJKL:ZXCVBNM<>\"";
   char *rul = "ёйцукенгшщзхъфывапролджэячсмитьбюЁЙЦУКЕНГШЩЗХЪФЫВАПРОЛДЖЯЧСМИТЬБЮЭ";
   char *enl1 = "/?&^$";
   char *rul1 = ".,?:;";
   int b = (int) strlen(rul)/strlen(enl), i;
   //char *words[] = {"<Next>","<Prior>","<Return>","<Ctrl>","<LCtrl>","<Alt>","<LMenu>","<Back>","<Delete>","<N3>","<N0>","<Right>","<Tab>"};
   //int wn = 13;
   int wil;

   buf = (char *) malloc(n);
   memset(buf,0,n);
   buf2 = (char *) malloc(n*b);
   memset(buf2,0,n*b);

   while( 0 != fgets(buf,n,stdin) ){
      tb2 = buf2;
      for(tb = buf; *tb != '\0'; tb++){
         /*for (i=0; i<wn; i++){ //ctrl
            wil = strlen(words[i]);
            if (strncmp(tb,words[i],wil) == 0){
               memcpy(tb2,tb,wil);
               tb += wil;
               tb2 += wil;
            }
         }*/
         if( (wil = checkIfCtrl(tb)) > 0){ //ctrl
            memcpy(tb2,tb,wil);
            tb += wil;
            tb2 += wil;
         }
         if ( (ten = strchr(enl, *tb)) != 0 ){
            tru = rul + b*(ten-enl);
            memcpy(tb2,tru,b);
            tb2 += b;
         }
         else if ( (ten = strchr(enl1, *tb)) != 0 ){
            tru = rul1+(ten-enl1);
            memcpy(tb2,tru,1);
            tb2 += 1;
         }
         else {
            memcpy(tb2,tb,1);
            tb2 += 1;
         }
      }
      printf(buf2);
      memset(buf2,0,n*b);
      memset(buf,0,n);
   }
   
   free(buf2);
   free(buf);
   return 0;
}
/////////////////////////////////////////////////////////////////////////
int checkIfCtrl(char *p){
   int lmax = 10, i, flag=0;
   char b='<', e='>';
   
   if(*p == b){
      for(i=0; i<lmax; i++){
         if (*(p+i) == e){
            flag = 1+i;
            break;
         }
      }
   }
   return flag;
}

Сразу прошу снисхождения к моим навыкам академического программирования. Но, если есть предложения по развитию этой микро-программки (во термин - micro-soft), буду рад их увидеть.

Компилируем:

$ gcc trc.c -o trc

Результат работы:

$ cat test.txt | ./trc

Гонимы вешними лучами,

С окрестых гор уже снега

Сбежали мутными ручьями

На потопленные луга

<return> это тест <ctrl> Тест это <lctrl> <alt> Александр Сергеевич Пушкин<lmenu>

Совсем хорошо!

Кривовато, правда... Более правильным кажется использование штатных С-шных функций для двухбайтовых символов, описанных в wchar.h и wctype.h, но просто и быстро у меня это почему-то не получилось (помню на VC под win пару лет назад получалось), поэтому я эту идею бросил, может, в следующий раз...

Представленные здесь варианты решили мою задачу, надеюсь, могут быть полезны и вам.

Verified by Visa

Любопытная статья и еще более любопытный документ. Названия тянут на бомбу, но по сути изложены очевидные вещи. Речь идет о безопасности протокола аутентификации владельцев карты Visa при выполнении ими online-покупок. В целом, мое мнение, чтобы написать подбные "труды" достаточно самому хотя бы раз выполнить покупку картой виза через Интернет и прочитать статью на Wikipedia. Конечно, я делал и то и другое, поэтому позволю себе тут рассуждения. Читать лучше сразу PDF, так как статья содержит в себе еще меньше пользы, хотя размер их соизмерим :-) Полезная нагрузка начинается с главы 2, где повествуется об уязвимостях схемы 3DS.
Самая первая уязвимость, видимо, самая важная - "Confusing the user - hiding security cues" о том, что окно аутентификации при реализации 3DS открывается в iFrame и поэтому не видно домена (а также того, как браузер подсвечивает строку URL с неправильным сертификатом TLS), запросившего аутентификацию. Может, в какой-то мере, это снижает безопасность, но:
1. Ничто не мешает банку аутентифицировать в новом окне браузера, тогда даже и строку URL будет видно со всеми ее подсветками.
2. Легитимность сайта подтверждается его сертификатом. При этом, если сертификат протух, не на тот сайт или выдан неизвестным CA браузер выбрасывает промптер предупржедения в котором подробнейшим образом указана проблема, предлагается посмотреть сертификат собственноручно, и только после добавления в исключения все-таки показать его контент. Обход столь сложной процедуры возможен только если:
-- "зловредный" CA, выдавший сертификат подложному сайту, каким-то образом "протрастщен" (добавлен в доверенные удостоверяющие центры) на endpoint-е => мой endpoint компрометирован => есть масса других способов утащить мои секреты и обмануть меня.
-- секретный ключ CA компрометирован и я об этом не знаю (или никто об этом не знает) и злоумышленники подписывают им сертификаты всем негодяям подряд. На этот риск я не могу сильно вилять => его не следует рассматривать

Отдельно следует поговорить про безопасность endpoint-а. Поскольку это элемент платежной системы, безусловно, к нему должны предъявляться требования. Идеально, если банк мог бы проверить их выполнение, но на практике это крайне сложно, поэтому, в обязательном порядке:
- банк должен давать рекомендации для пользователей сервиса "Online Shopping-а"
- желательно наличие каких-либо сервисов от банков, где можно было бы проверить этот compliance (не обязательно online-овых)
- должна быть четко определена ответственность клиента в данном сервисе: клиент должен отвечать только за полное соблюдение требований, но не за весь сервис.

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

Уверен, что для наведения порядка в этом 3DS, Visa должна выпустить ряд требований к реализации этого 3DS, как это сделано, например в PCI DSS.

Но вернемся к статье.
В П 2.2. "Activation during shopping" указана уязвимость слабой аутентификации клиента, указано, что кто-то спрашивает только день рождения. Согласен, что это бред и процедура здесь должна быть аналогична применяемым в системах ДБО. Где-то это какие-то секретные ключи, за которыми надо пешком сходить в банк, где-то это SMS-уведомления с одноразовыми паролями. Если кто-то реализовал глупость, не следует ее сразу обобщать на всех. Также указано, еще более веселая мысль о том, что сайт запрашивает у клиента персональную информацию и это делает его более склонным к социальной инженерии, когда уже фишеры будут запрашивать то же самое: ответил банку, ответит и фишеру. Даже комментировать не буду :-)

В П 2.3 "Informed consent and password choice" утверждается, что: Пользователь, сконцентрированный на приобретение товара (сценарий activation during shopping (ADS)) будет выбирать слабый пароль. Контроль оцевиден: банк не должен принимать простые пароли и вообще реализовывать политику: сложность, длина, периодическая смена, автоблокировка при неправильных вводах.

П 2.4 "Liability shifting" посвящен тому, что Банк "по-тихому" взваливает всю ответственность за компрометацию на клиента. Это тоже необходимо разрулить Визе (как я отмечал выше): пользовать может (и должен!) следовать только четко указанным требованиям, отвечать за все он не может технически (и не должен!). Снимать ответственность полностью с пользователя - не правильно, так как его endpoint - компонента общей системы и ее компрометаци приводит к компрометации системы.

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

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

П 2.7 - про Privacy. О этот вечный баланс между Security и Privacy:

Нужно помнить следующее:
1. Про аутсорсинг. Если есть объективные причины мои данные передавать аутсорсеру и аутсорсер обязуется охранять мои данные не хуже банка, какой для меня риск? Я на днях ходил в ГИБДД за справкой о ДТП там на входе мои паспортные данные записали в журнальчик... меня больше беспокоит этот журнальчик, кто его читает, как он утилизируется и т.п. Причем такой журнальчик есть практически везде. А мы тут голову ломаем о том что говорить Роскомнадзору и ФСБ, когда ФЗ-152 - нигде не работает.
2. В конечном счете, меня, как субъекта можно аутентифицировать только моими персональными данными. У меня больше ничего нет.

Сухой остаток:
1. Ждем от Visa требований к реализации протоколов аутентификации.
2. От банков ждем требований по безопасности endpoint-а (кое-где видел, но Visa должна обязать такие требования готовить).
3. То, что аутентификационные механизмы отданы на реализацию банкам - правильно, с Visa только требования и разделение ответственности.