Infosec

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

У меня на этом рынке стаж работы приближается к круглой дате, если не считать профильное образование в этой области и за это время сформировалось устойчивое мнение о рынке ИБ в России и карьере в этой области. Дальше об этом речь и пойдет. Всё описанное дальше скорее для тех, кто решает ворваться (на самом деле достаточно просто шагнуть) в этот рынок или посмотреть на что-то другое.

Часто на разных ресурсах специализацию в области ИБ описывают как нечто сложное, загадочное, неопознанное и романтичное. В основном у всех, кто ещё не знаком с этой областью работа в ИБ ассоциируется непосредственно с хакерами и создается впечатление, что все ИБшники обладают этими навыками (взламывают сайты, крадут пароли, пробивают по IP и т.д.). Из-за этого вход на этот рынок выглядит максимально сложным и кандидату чаще кажется невозможным устроиться на работу ИБшником, не обладая этими знаниями. Однако, реалии таковы, что большинство специалистов ИБ даже не представляет, как это происходит. Более того значительная часть специалистов не особо и в ИТ разбираются. От чего же это так?

Рынок ИБ делится так же, как и все остальные рынки на заказчиков и исполнителей. Начнем с описания работы на стороне заказчиков.

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

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

Однако, недопонимание встречается не только со стороны ИТ, но и ИБ из-за отсутствия необходимых технических компетенций (а когда им их повышать, если они только что и делают, так это пишут проклятые бумажки): требования законодательства обязуют использовать в информационных системах средства от несанкционированного доступа, которое жрет достаточно много компьютерных ресурсов так ещё и является агентским решением, которое должно устанавливаться на каждую рабочую станцию в организации. А если это предприятие с 4к пользователями, где парк машин с ОС Windows 7 и не потому, что сложно закупить (хотя это тоже требует не мало финансов) новые версии Windows 10, а потому что этот парк компьютеров устаревший и не потянет эту операционную систему, а тут ещё и агент средства защиты информации будет жрать ресурсы как бешеный.

В итоге для того, чтобы внедрить только одно решение уже потребуется обновить парк компьютеров! Просто представьте сколько это денег! А они не у каждого ГОСа есть, а зачастую ещё главная отраслевая компания распоряжается этими финансами, а не само предприятие.

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

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

Несомненно, вы начнете разбираться в законодательной базе, это полезно. Но для того, чтобы изучить эту базу и понять требуется не так много времени. Для такой работы не требуется специфических знаний в ИБ. Но HR упорно продолжают писать в требованиях, что вы должны знать как работать с различными средствами защиты информации, знать всю законодательную базу, иметь высшее специализированное образование и вообще опыт работы не менее 3-х лет (это всё там даже применить не получится). А ЗП предложат всего 60-80к. Не так давно увидел объявление одной такой крупной компании в Москве:

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

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

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

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

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

Compound File это довольно сложный универсальный бинарный формат файлов, лежащий в основе форматов офисных документов до MS Office 2007 (doc, xls, ppt, msg, ), отчасти MS Office 2007+ (например vbaProject.bin внутри xlsm) и других.
Под катом краткое описание как Compound File устроен внутри, которое, надеюсь, будет полезно как ликбез и поможет читателю лучше понимать что делают утилиты или про что пишут в статьях про CFB файлы.


Устройтсво CFB файла сильно напоминает устройство диска с FAT. Логически CFB хранит древовидную структуру объектов, подобную файловой системе с директориями (тип объекта в CFB STORE) и файлами (в CFB STREAM). Каждый объект имеет имя.
Весь файл разбит на сектора размером 512 байт для v3 и 4096 байт для v4. Это, на мой взгляд, главная разница между v3 и v4. Дальше цифры для примеров я буду приводить для v3 (и в скобках для v4). В начальном секторе хранится заголовок файла и начало таблицы DIFAT (см. ниже). Значение содержимого других секторов определяется динамически по таблицам DIFAT и FAT (да, она прям так и называется, как в файловой системе), фиксированных значений сектор n содержит информацию типа t больше нет.
Всего максимум может быть 0xFFFFFFFA секторов. Номера секторов больше 0xFFFFFFFA являются маркерами и фактически ни на какой сектор не указывают. Например 0xFFFFFFFE (EndOfChain) означает, что текущий сектор последний в списке.

DIFAT

DIFAT Double Indirection File Access Table. Это массив 4х байтных номеров секторов, в которых находится FAT. Первые 109 записей хранятся в первом секторе файла (пять из них выделены жёлтым внизу КДПВ). Если файл больше 6.8 Мбайт (436 Мбайт для v4), то следующие сектора DIFAT хранятся как односвязный список. Номер первого сектора из этого списка хранится в заголовке. В кажом из этих секторов хранится 127 (1023) указателей на сектора с FAT, а в последних 4х байтах номер следующего сектора DIFAT.

FAT

FAT File Access Table. Это массив из 4х байтных значений. Работает так же, как в одноимённой файловой системе. Каждому сектору в файле (кроме заголовочного) соответствует 4х байтное значение в FAT.
Для чтения потока данных (STREAM) нужно знать длину потока (в байтах) и номер первого сектора этого потока. Номер следующего сектора всегда записан в элементе FAT, соответствующем текущему сектору. В элементе FAT, соответствующем последнему сектору в потоке, будет записано значение 0xFFFFFFFE (EndOfChain).

Directory

Это структура, которая хранит информацию обо всех остальных объектах в файле, аналог структуры каталогов. Сама она хранится в виде потока данных, длина и первый сектор которого записаны в заголовке файла. Представляет из себя массив 128 байтных записей. Каждая запись соответствует хранимому объекту. Объекты в directory имеют имя и бывают 4х видов:

1. ROOT корень дерева каталогов. В directory хранится в элементе 0, имя всегда Root Entry. По сути является директорией, но хранит информацию о потоке данных с MiniStream (см. ниже).
2. STORE директория. Логически является вместилищем других объектов типа STORE или STREAM. Физически дочерние объекты хранятся в виде списка (ещё точнее чёрно-красного дерева), а в STORE хранится указатель на один из дочерних объектов. Никакой поток данных к STORE не прицеплен, но есть ClSid GUID приложения, к которому относится содержимое этой директории.
3. STREAM файл. Хранит информацию о потоке данных (первый сектор и длина); дочерних объектов и ClSid нет.
4. UNKNOWN пустой объект. Запись, (почти) забитая 0, чисто технически нужна для дополнения списка Directory до длины, кратной длине сектора.

У каждого объекта есть временные метки: время создания и время модификации, правда часто они просто заполнены 0.
Пример дерева директорий небольшого doc файла:
Root_storage:Root Entry 06090200-0000-0000-c000-000000000046
- Stream:\x01CompObj[106]
- Stream:\x01Ole[20]
- Stream:1Table[4640]
- Stream:Data[374]
- Stream:\x05SummaryInformation[172]
- Stream:WordDocument[198510]
- Storage:ObjectPool 00000000-0000-0000-0000-000000000000
- Stream:\x05DocumentSummaryInformation[116]

MiniStream и MiniFAT

В принципе описанного выше достаточно для хранения данных, но в CFB предусмотрена ещё оптимизация для хранения коротких потоков данных меньше 4096 байт.
При хранении потока данных, длина которого не кратна длине сектора, в последнем секторе остаётся некоторое количество неиспользуемых байт. Чем больше сектор тем больше таких байт в среднем остаётся. Для борьбы с этой проблемой все небольшие (меньше 4096 байт) потоки данных хранятся не в обычных секторах по 512 (4096) байт и FAT, а в отдельном потоке, разбитом на сектора по 64 байта. Этот поток называется MiniStream, а информация для сцепления его секторов в потоки хранится в MiniFAT. Работает это всё совершенно аналогично основной FAT.
И MiniFAT, и MiniStream хранятся как обычные (не Mini) потоки данных. Номер первого сектора и длина MiniFAT хранятся в заголовке, а информация о MiniStream в объекте Root Entry (логической причины хранить именно там не вижу).
Получается такая матрёшка: файл разделён на 512 (4096) байтные сектора, а один из потоков, состоящих из этих секторов, рассматривается как последовательность 64 байтных секторов, и в нём уже хранятся мини потоки данных.
Откуда читать поток данных: из большой FAT или из MiniStream, определяется только по его размеру (меньше 4096 из MiniStream, иначе как обычный поток).

Где же текст/картинка/таблица/макрос?

CFB используется как хранилище, позволяющее сохранить данные разных приложений в одном файле. Если вы хотите докопаться до человекочитаемых данных, то надо парсить потоки данных, извлечённые из CFB, в соответствии с форматом данных приложения. Эта тема выходит за пределы данной статьи (но см. ссылки).

Выводы

По идее такая структура файла была разработана для ускорения внесения отдельных изменений в файл без его полной перезаписи. Не думаю, что это свойство ценно сейчас для обычных офисных документов размером несколько мегабайт.
В общем структура файла CFB просто кладезь для стеганографии, основанной на формате файла. Т. е. сделать совершенно корректный файл, который при открытии в ворде покажет Hello world, а внутри будет ещё много, которые правильный парсер будет считать просто мусором вообще не проблема.
С другой стороны огромный простор для ошибок, путаницы и т.п., огромное количество избыточных записей. Например, можно зациклить цепочку секторов, образующую поток. Наивный парсер при чтении такого файла зависнет.
P.S. Файлы MS Office 2007 и старше (docx, xlsx, pptx, docm,) имеют совершенно другой формат. Внутри там тоже дерево директорий, только вместо CFB там используется ZIP (да, их можно прям раззиповать). Однако макросы, например, хранятся внутри документа в файле vbaProject.bin, который является Compound файлом.

Ссылки

• Сам CFB очень хорошо (на мой взгляд) документирован: [MS-CFB]: Compound File Binary File Format
• [MS-DOC]: Word (.doc) Binary File Format для тех, кто хочет полноценно разобрать doc.
• [MS-OVBA]: Office VBA File Format Structure о том, как хранятся макросы, в том числе в Office 2007+ (docm, xlsm, ...)
• Ещё пара статей на Хабре про парсинг DOC от Rembish:
  Текст любой ценой: WCBFF и DOC и Текст любой ценой: Miette
  
• Для практического анализа файлов MS Office (как до 2007 Офиса, так и после), в том числе подозрительных, рекомендую набор утилит OleTools. Их можно использовать и как отдельные программы, и как модули Python.
• Ещё полезный набор утилит OleDump
• CFB extractor, появившийся в процессе написания этой статьи. Из полезного умеет доставать из CFB файла все потоки данных (включая потоки, не имеющие соответствующей записи в директории).