О сути интеграторов, поглощений и разделения труда в ИТ-индустрии (краткий очерк)

Судя по экономическим и околоэкономическим новостям в ИТ, этот год богат на различного рода поглощения одними компаниями других. Где-то это серьезные изменения, и они могут иметь существенные последствия для российской ИБ-действительности (например, как тут), где-то - небольшие и, на чей-то собственный экспертный взгляд, совсем незначительные изменения, последствия которых как минимум неочевидны. Не вдаваясь в подробности особенностей рынка, хотелось бы очень кратко обсудить, зачем это все и как на это реагировать.
Так например, на этой неделе состоялась покупка копанией Treolan, входящей в ГК "ЛАНИТ", компании SafeLine, ранее принадлежавшей ГК "ИНФОРМЗАЩИТА". Об некоторых возможных особенностях данного поглощения можно почитать и даже порассуждать здесь и здесь. Являясь в настоящий момент сотрудником ГК "ЛАНИТ", считаю некорректным обсуждать это публично и каким-то образом высказывать свое личное мнение на этот счет. Однако, если абстрагироваться от лишних сущностей и сосредоточиться на главном - некая организация, являющаяся крупным системным интегратором приобретает авторизованного дистрибьютора программных и аппаратных решений в области ИБ. Это, как и, к примеру, приобретение компанией McAfee небольшой финской компании Stonesoft - производителя средств сетевой безопасности (преимущественно, МСЭ с функциями защиты канала, в том числе - пожалуй, самого популярного в России VPN-решения) - по-моему в первую очередь говорит о желании консолидировать компентенции в различных (относительно различных, само собой, потому что в ИТ-управлении все очень тесно взаимосвязано) областях ИТ-деятельности. Что приведет к тому, что компания-выгодоприобретатель станет обладать возможностями по полному охвату ИТ заказчиков, построению комплексной ИТ-деятельности и, соответственно, более глобальным проектам.
По моему собственному опыту, заказчики сейчас более ориентированы на построение комплексной ИТ-деятельности по тем или иным направлениям (управление кадрами, управление клиентами, в общем - та или иная автоматизация бизнес-процессов). И использование решений специализированных производителей или поставщиков возможно исключительно в условиях  ограничений, таких как:

• необходимость соответствия законодательству (использование исключительно сертифицированных СЗИ, к примеру);
• необходимость соответствия рекомендациям (использование "строго рекомендованных" решений, к примеру);
• приверженность поставщику
• и т.д.

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

Закладку вам за воротник или к вопросу НДВ в документах по ПДн

С 1-го ноября прошлого года, с того самого дня, как было принято Постановление Правительства РФ №1119, специалисты и заинтересованные лица из числа операторов персональных данных наперебой задают себе, друг другу и регулятору несколько вопросов, касающихся угроз 1-го, 2-го и 3-го типа (если кто не помнит/не знает или вообще не понимает, о чем речь - даю ссылку на замечательную запись и дискуссию в комментариях тут). Вопросы вкратце следующие:

1. Как вообще можно, не проводя анализ используемого ПО, определить наличие НДВ и актуальность связанных с ними угроз?
2. Как можно защититься от угроз, связанных с НДВ, не влияя на код ПО или процесс его производства?
3. Зачем вообще регулятору надо было акцентировать внимание на НДВ?

Как вообще можно определить наличие НДВ и актуальность связанных с ними угроз.
Не вдаваясь в подробности терминологии, принятой в мире и РФ в отношении безопасности приложений, инфраструктуры и прочего, не вступая в грубые дискуссии с коллегами (пример дискуссии оживленной, но интеллигентной - по ссылке выше), попробую ответить на все эти вопросы, не общественности ради, а может быть даже больше для себя, чтобы утрясти эти спорные моменты в голове.
Под НДВ в системном или прикладном ПО понимается возможность, функциональная или иная, присутствующая в ПО, но не описанная в документации, не заявленная на этапе создания ПО и, возможно, даже не известная никому, за исключением разработчика или высококвалифицированного исследователя (тех, кто называется в Методических рекомендациях ФСБ нарушителями Н4-Н6).
В данном случае важно понимать, что уязвимость и НДВ - понятия не тождественные. Не всякая уязвимость объясняется наличием НДВ, и не всякая НДВ влечет за собой уязвимость. Однако тот факт, что во многих случаях эти ситуации совпадают, заставил экспертное сообщество, занимающееся разработкой НПА обратить на это внимание. И с этого момента принято считать, что любые НДВ создают уязвимость, которую теоретически может использовать злоумышленик для реализации угрозы. Угрозы, связанные с использованием НДВ в системном или прикладном ПО (в точной формулировке ПП РФ №1119), могут быть актуальны при весьма определенных условиях, специфических и крайне редко встречающихся. Это и ценность обрабатываемой информации, и технология обработки информации, и характер НДВ, и - на мой взгляд, самое главное - модель нарушителя. Сочетание этих факторов и приводит к тому, что в подавляющем большинстве случаев угрозы, связанные с НДВ, неактуальны для защищаемых ИСПДн (и тут я согласен с господином Лукацким, хотя и, как мне кажется, привожу более весомые аргументы :-)). Вступив недавно с одним коллегой-разработчиком в около-философский спор: он утверждал, что никакие СЗИ не способны защитить от недостатков ПО, т.е. от НДВ, я сформулировал два наглядных примера:
Пример 1: При разработке ПО, обрабатывающего персональные данные, разработчиком явно была создана защитая в код и не отображающаяся ни в каких списках и перечнях учетная запись, позволяющая получить полный доступ ко всем данным вполне легально (без обхода функций разграничения доступа, соответственно, без появления инцидента ИБ). Является ли данная учетная запись НДВ? Несомненно. Будет ли угроза, связанная с этой НДВ, актуальной для ИС, где будет использоваться это ПО? Вряд ли. Звучит странно, но это совершенно логично, потому что о существовании данной НДВ знает только разработчик либо лицо, обладающее возможностью изучить исходный код ПО (например, кто-то в сговоре с разработчиком). Очевидно, что данным лицам нет смысла проводить исследовательскую работу, изучение исходных кодов (для не-разработчика), или нарушать соглашения с заказчиком вплоть до нарушений законодательства и соответствующего наказания (для разработчика). Для получения несанкционированного доступа к персональным данным есть гораздо более простые способы, и нарушители, выполняющие подобные действия, гораздо более низкого уровня, чем те, которые могут использовать НДВ. Следовательно, в данном случае угрозы, связаные с НДВ, будут неактуальны. Конечно, данный вывод можно сделать только по итогам анализа и моделирования угроз, но в большинстве случаев, он будет именно таким.
Пример 2: В качестве системного ПО используется ОС семейства Microsoft Windows. НДВ, существующие в Windows, известны и даже описаны в соответствующей литературе (что, кстати, звучит крайне интересно - недекларированные возможности документированы..), поэтому использовать их может не только разработчик ПО (представить, что Microsoft, при взаимодействии с иностранной технической разведкой, будет взламывать ИСПДн ЖЭКа, очень сложно), но и любое лицо, обладающее навыками разработки средств атак. Будет ли угроза, связанная с НДВ в СПО, актуальной для этой ИСПДн? Далеко не факт. Только в данном случае неактуальность будет обусловлена не соответствующей моделью нарушителя (требуется более низкая квалификация и меньшая осведомленность о системе), а особенностями обработки информации. Прямого доступа к ОС сервера, обслуживающего пользователей (в том числе, потенциального злоумышленника), нет ни у кого, кроме администратора, а следовательно выполнить некий произвольный программный код, чтобы воспользоваться известной НДВ в ОС, будет невозможно. И вновь угрозы, связанные с НДВ, неактуальны, хотя уже и по другой причине. И снова, данный вывод можно сделать только по итогам анализа угроз, который должен делать специалист, умеющий строить правильные причинно-следственные связи, а не паникер-оператор, который считает, что именно его ИСПДн будет объектом атаки по всем возможным фронтам.

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

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

Врагу не сдается наш гордый...

Не так давно автор данного материала ознакомился с одним крайне неплохим продуктом для, как модно нынче выражаться, защиты от внутренних угроз, а в простонародье - DLP-мониторинга. Материал, конечно, имел рекламный характер (к которым я отношусь крайне насторожено, как уже писал тут), однако, рациональное зерно в нем присутствовало. В связи с этим, а также с некоторыми процессами в области регулирования ИБ в России (официальный выход 21-го приказа ФСТЭК, подготовка новых ДСПшных ГОСТ и т.д.), захотелось сказать два слова о так называемых комплексных системах информационной безопасности, которые некоторые вендоры громко называют "будущим корпоративной ИБ" (имея ввиду, конечно, в первую очередь продукты собственного производства).
До недавнего времени базовые подходы к защите ИС были заложены еще в далеком 92-ом году руководящим документом Гостехкомиссии: четыре технологии защиты (разграничение доступа, регистрация и учет, криптография и контроль целостности), реализованные в виде четырех подсистем (в 58-ом приказе ФСТЭК к ним добавились еще три подсистемы), классификация ИС (АС) по архитектуре и свойствам и весьма специфические организационные меры. В связи с этим у производителей и интеграторов в области ИБ сложилась, на мой взгляд, порочная практика по разработки типовых, "шаблонных" решений по защите ИС и АС (а позднее - и ИСПДн), не разбираясь ни в ценности обрабатываемой информации, ни в технологии обработки, ни в чем подобном. И, кажется, результатом именно такой практики и стало появление комплексных систем обеспечения информационной безопасности (назовем ее КСОИБ, но будем понимать, что речь идет исключительно о техническом, как правило, програмном средстве, а не о применении комплексного подхода к безопасности).
К достоинствам применения программных КСОИБ можно отнести следующее:

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

К недостаткам таких систем можно отнести следующее:

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

Из приведенных списков очевидно, что КСОИБ могут быть эффективным решением для небольших и средних коммерческих организаций (то, что называется на Западе Small and Medium Business), где:

1. малые масштабы автоматизированной системы 
2. небольшое число актуальных угроз информационной безопасности (или низкий уровень риска, если выражаться языком риск-менеджмента)
3. отсутствуют требования по использованию сертифицированных СЗИ в системе сертификации ФСТЭК и (или) ФСБ
4. отсутствует потребность в сложных организационных мерах по защите и малое число ИТ и ИБ персонала (возможно, совмещение ролей администратора ИС и администратора ИБ)

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

О нелегком выборе артиста или к вопросам выбора информационных систем

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

Простота. Хуже воровства?

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

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

Физическое блокирование USB-устройств

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

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

Вполне закономерно, что проанализировав такое количество угроз, идущих от данного типа устройств, специалисты пришли к выводу, что безопаснее и удобнее будет отключить USB-шину в ПЭВМ, заблокировав таким образом взаимодействие с USB. Многие сотрудники СБ в организациях считают этот способ до сих самым эффективным для обеспечения безопасности, и применяют его, несмотря на воинствующие крики ИТ-специалистов и функциональных сотрудников. Однако, стоит ли это делать? Проанализируем ряд факторов.

• многие внешние устройства используют USB-интерфейс для подключения к ПЭВМ. Без многих подобных устройств работы с ПЭВМ становится затруднительной (USB-мышь, клавиатуры, веб-камера, микрофон и т. д.). Устройств, использующих "старые" интерфейсы (COM, PS/2, LPT), практически не осталось, или найти их сложнее, чем остальные;
• многие средства защиты используют USB-носители в качестве элементов. USB-ключи для криптосредств, USB-токены - все это не совсем обычные USB-устройства, которые нельзя использовать для скрытого хищения данных или заражения ПЭВМ вредоносной программой, однако, если заблокировать USB, то их применение будет невозможно, так как возможностей фильтровать USB-устройства или избирательно блокировать USB-порты ПЭВМ в широком доступе либо не существует, либо их реализация не оправдана с точки зрения эффективности;
• на ПЭВМ многих типов просто физически не осталось других интерфейсов для взаимодействия с "внешним миром". Если заблокировать USB, единственным каналом остается ЛВС. Ее, конечно, контролировать проще, однако, это серьезный удар по производительности функциональных сотрудников.

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

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

Исключение рисков через физическое сегментирование информационной системы

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

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

Между тем, заняться бы стоило. Практика показывает, что логические средства, несмотря на сертификаты ФСТЭК, гарантии разработчика и прочие плюсы, могут давать промашку, а также могут быть просто выключены пользователем или сброшены системой в результате ошибки. Ясно, что все эти события будут в дальнейшем обнаружены в качестве инцидентов, и, при должной скорости реакции группы CERT, будут разрешены без ущерба, однако, иногда лучше перестраховаться. К примеру, отключение производственной ЛВС от Интернета и выделение одного-двух ПЭВМ в качестве "справочных" для доступа в глобальную сеть может быть вполне оправдано. В действительности, редким функциональным специалистам требуется доступ в Интернет непосредственно с рабочего места, как правило, им необходимо получить какую-то справочную информацию. А выделение отдельной ЛВС для сотрудников, взаимодействующих с информацией особого уровня доступа, и физическое отделение ее от остальной ЛВС организации может быть оправдано в первую очередь с точки зрения защиты от инсайдерских утечек. Как правило, в таких ситуациях следуют аргументы, мол, все можно запомнить и "унести в голове", однако, согласитесь, что сложно "унести в голове" распиновку микроконтроллера или производственную схему.

Фактически, у данного подхода есть только два явных недостатка:

• его категорически нельзя применять к ПЭВМ, которым необходимо иметь доступ в отделяемые сети в режиме реального времени. Например, заставить программиста, работающего с секретной информацией, время от времени бегать к "справочному" компьютеру, чтобы залезть в Гугл, можно без потерь производительности, а вот заставить то же самое делать банковского кредитного специалиста или менеджера турфирмы получится вряд ли;
• он не перекрывает ряд угроз и требует применения дополнительных методов. Например, никто не мешает сотруднику, работающему на ПЭВМ, находящемся в физически изолированной ЛВС без доступа в Интернет, скопировать свою работу на флешку и унести ее на ПЭВМ с доступом в Интернет. В таком случае для полного перекрытия следует применять этот метод в совокупности с предыдущим. Организация, конечно, будет иметь некоторые проблемы из числа тех, что обозначены в факторах, препятствующих отключению USB, но, согласитесь, что найти PS/2-мыши и другие не-USB-внешние устройства на некоторые ПЭВМ, работающие с информацией особого уровня доступа, проще, чем на все ПЭВМ в организации.

Из всех рассматриваемых в настоящей статье методов, данный метод является наиболее действенным и рекомендуется к применению.

Использование собственных подсистем ИБ системного и прикладного ПО, применяемых в защищаемых информационных системах

В 2009 году автору довелось побывать в рамках конференции по ИБ на пленарном заседании, посвященном самому животрепещущему вопросу ИБ последних лет - защите персональных данных. Незаметно, словно зима в декабре, к операторам персональных данных подкрался срок (тогда - первый) начала проверок соответствия ИСПДн требованиям, и те всполошились, увидев, что им предстоит проделать не только серьезную аналитическую и архитектурную работу, но и вложить немало средств в применение систем защиты информации. Тогда представители регуляторов, присутствующие на заседании, предложили минимизировать затраты путем реализации некоторых требований через использование встроенных подсистем ИБ различного ПО, которое уже используется в рассматриваемых ИСПДн. Речь, конечно, шла об операционных системах семейства Windows и сопутствующих продуктах корпорации Microsoft, которые так кстати на тот момент прошли сертификацию на соответствие требованиям по НСД и НДВ в ФСБ и ФСТЭК и оказались пригодны к использованию в ИСПДн.

Собственно, с тех пор прошло три года. За это время Microsoft даже выложил на своем сайте целое руководство, в котором красочно описал, как собственными силами можно покрыть большую часть требований к подсистемам управления доступом, регистрации и учета, а также обеспечения целостности в ИСПДн вплоть до класса К1. Фактически, ничего сверхъестественного в данных требованиях действительно нет, большинство многопользовательских систем реализуют их с избытком. На самом деле, применение средств защиты, реализованных через штатные функции операционных систем, серверов приложений и иных системных и прикладных программных средств, действительно возможно и может существенно упростить развертывание защиты, соответствующей требованиям (например, требованиям к АС, изложенным в соответствующем руководящем документе Гостехкомиссии/ФСТЭК). Но существует одно НО.

Сертификация. Под сертификацией понимается процесс подтверждения оценки соответствия объекта требованиям, предъявляемым к нему. Сертификация является процессом, инициируемым производителем объекта, выполняемым соответствующим органом по сертификации и периодически подтверждаемым. Так вот. Закрытие требований безопасности штатными средствами возможно только в случае, если применяются сертифицированные версии ОС, серверов и т. д. Самостоятельно Microsoft в России сертификацию не осуществляет, за него это делали некоторые распространители. И только системы, приобретенные у этих распространителей (которых можно пересчитать по пальцам) являются сертифицированными и годными к применению в качестве СЗИ. Поскольку на сертифицированную версию той же ОС Windows было потрачено больше средств, чем на обычную (распространитель сдал репрезентативную выборку из партии на анализ в испытательную лабораторию и оплатил услуги по сертификации), то и стоят они дороже. Вероятность, что те ОС, которые используются в данный момент в защищаемой информационной системе, пусть даже они являются лицензионными и купленными у официального распространителя, будут сертифицированными очень мала. С любителями СПО вообще все грустно. Коробочные версии систем на базе Linux, сертифицированные ФСТЭК, также существуют, однако их применение полностью нейтрализует все "плюсы", которые есть этих операционных системах, такие как открытость кода, возможность изменений и бесплатность.
Поэтому данный подход может быть применен только в случае проектирования новой информационной системы и наличия правильного поставщика программных средств. В иных случаях действует один из законов ИБ, согласно которому иногда правильнее будет добавить к неэффективному СЗИ еще одно, наложенное, вместо того, чтобы удалять его и заменять на аналогичное, эффективное.

Вывод

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

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

Антивирусные войны

Не так давно здесь была опубликована агрегированная статистика рынка антивирусных средств в России. Согласно этой статистике, в последние два года два производителя - ESET и "Лаборатория Касперского" - вышли на наиболее высокий уровень продаж, обеспечив себя фактически самые высокие доли рынка, остальные производители сильно сдали позиции.
Справедливость данной статистики, конечно, вызывает ряд вопросов. Прежде всего, графики всегда выглядят красиво и эффектно, пока не прочитаешь их заголовки. А заголовок следующий: "Изменения доле ключевых игроков на антивирусном рынке России в 2005-2011 годах". То есть перед нами статистика продаж. И, если продажи специализированных средств защиты информации, таких как СЗИ от НСД, есть объективный показатель выбора специалистов (закупки СЗИ, все-таки, время от времени контролируются уполномоченными сотрудниками подразделений безопасности), то продажи такого массового средства, как антивирус - это показатель работы маркетологов.
Антивирусные системы сами по себе - предмет споров среди специалистов. Настойчивые "легенды" о бесполезности таких средств против 0day-вирусов и нетипичных атак заставляют специалистов отказываться от них, заменяя их функционал межсетевыми экранами и системами обнаружения вторжений. При этом, если применение антивирусных средств в организациях, как правило, является результатом комплексной политики, то домашние пользователи, составляющие от 40% рынка, выбирают по совершенно иным принципам, далеко не самым объективным и адекватным.
Поэтому воспринимать данную статистику стоит исключительно в контексте работы маркетологов и PR-специалистов.

"Пода-а-а-айте жалобную книгу" или еще раз о требованиях к ИСПДн

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

Немного истории новейшего времени

Речь сегодня пойдет о методах и способах обеспечения безопасности персональных данных при их обработке в ИСПДн. Слово "требования" старательно избегается, и вот почему. Как известно, изначально нормативная база по защите персональных данных состояла из следующих документов:

• Собственно, сам закон "О персональных данных";
• Положение о защите персональных данных в ИСПДн;
• "Приказ трех", он же порядок классификации ИСПДн (где вводятся знаменитые и до конца не понятые до сих пор понятия "типовой" и "специальной" ИСПДн);
• Знаменитое "четырехкнижье", которое являлось документом с грифом "ДСП", и выдавалось только лицензиатам ФСТЭК для организации работ по обеспечению информационной безопасности.

Стоит отметить специфический характер данных документов. Если первые три прошли утверждение в МинЮсте и формально были приняты в качестве легитимных документов, имеющих юридическую силу в правовом поле (например, при рассмотрении дел в суде), то "четырехкнижье" такое утверждение не прошли. Особо въедливые специалисты поспешили окрестить эти документы "необязательными и вообще незаконными", хотя сомнений в добровольно-принудительном характере "рекомендаций" регуляторов вопросов ни у кого не возникало. Впоследствии "четырехкнижье" было частично отменено, остались только Базовая модель угроз и Методика определения актуальных угроз, с которых был снят гриф "ДСП", а вместо Рекомендаций было введено знаменитое "Положение о методах и способах защиты...", известное в среде специалистов как Приказ №58. Стоит заметить, что данный документ был зарегистрирован в МинЮсте, что отмело в дальнейшем все вопросы к его правоприменимости. Данный документ включил в себя большую часть положений предыдущих документов ФСТЭК и ФСБ по защите ПДн, поэтому формально ничего нового не произошло. На самом же деле произошло следующее.
Изначально ИСПДн целиком и полностью позиционировалась как АС. Классификация ИСПДн и классификация АС, границы которой совпадают с границами ИСПДн, - два самостоятельных (хоть и взаимосвязанных) мероприятия, а требования по защите к ИСПДн совпадают с требования к АС. Требования к АС, если кто забыл, находятся в руководящем документе ГТК "Автоматизированные системы. Защита от НСД. Классификация АС и требования по защите информации". Требования по защите информации к АС являются именно требованиями, то есть обязательны для выполнения в защищаемых АС и оцениваются при аттестации. Тут кроется еще одна "красивая легенда" защиты персональны данных - аттестация. Аттестации ИСПДн в природе никогда не существовало, а существовал и существует аттестация АС. Для ИСПДн классов К1 и К2 аттестация АС была обязательной. Требования, опять же, определялись актом классификации АС, тогда как классификация ИСПДн была призвана не столько определить требования по защите (вернее, не только это), сколько определить характеристики ИСПДн через понятные интуитивно категории, позволяющие явно указать, кому, когда и сколько чего грозит, в случае нарушений и реализации рисков.
С введением приказа №58 стало очевидно, что защита ИСПДн пошла своим, если можно так сказать, уникальным путем развития. Фактически, состоялся переход от системы оценки соответствия (как это называлось на западе - комплаенса) к системе защиты с полным перекрытием, то есть защиты была не в соответствии каким-то ранее установленным характеристикам (впрочем, весьма правдивым в большинстве случаев), а в соответствии с требованиями ситуации (фактически, ранний риск-менеджмент). Требования к АС по прежнему составляют основу для защиты ИСПДн соответствующего класса. Однако, следуя формулировки нового нормативного документа, он предоставляет не обязательный к реализации набором требований к ИСПДн различных классов, а комплекс мер, судя по всему, достаточных для защиты этих ИСПДн. В документе нет ни слова об обязательности этих комплексов, а само понятие "требования" тщательно вычищено из него и заменено на политкорректное "методы и способы защиты..", предполагая, что этим можно воспользоваться, а вот нужно ли - решать вроде как вам.
Со своей точки зрения автор хочет напомнить, что данная формулировка создает обманчивую иллюзию возможности трактовать этот документ как набор рекомендаций. При этом не стоит забывать, что обязательность рекомендаций высших регуляторов никогда не была под сомнением. Если даже Стандарт Банка России, являясь необязательным просто по факту своего происхождения (обязательность применения ГОСТов была отменена в 2004 году), является фактически обязательным для финансовых и кредитных организаций в зоне ответственности этого самого Банка, то что говорить о "рекомендация" регулятора, гораздо более властного, чем ЦБ РФ?

Проблемы и несоответствия

Следует отметить, что с вводом приказа №58 и применением его в качестве авторитетного источника фактических требований к ИСПДн различных классов, выявился ряд проблем, большинство из которых не решено до сих пор, или имеет исключительно локальное решение, основанное на опыте наиболее крупного интегратора или авторитетного регулятора. Далее приводятся некоторые наиболее явные несоответствия с практикой и "объективной реальностью".

1. "Отмена" аттестации
   Факт отмены был зафиксирован исключительно через отсутствие соответствующего требования в составе документа. Действительно, регуляторы и крупные интеграторы признают, что необходимость аттестации АС для ИСПДн больше не регламентируется. Однако, былинный документ ГТК "Специальные требования и рекомендации по технической защите конфиденциальной информации", известный больше как СТР-К, вполне явно говорит в статье 2.17, что "объекты информатизации должны быть аттестованы на соответствие требованиям по защите информации...". Согласно Положению об аттестации, на основе которого до сих пор и осуществляется эта пресловутая оценка соответствия, под объектом информатизации в том числе понимается АС. Если сложить это с тем фактом, что СТР-К обязателен для применения в государственных учреждениях, становится понятно, почему подавляющее большинство государственных заказчиков считают аттестацию по прежнему обязательным "знаком соответствия" разрабатываемых систем. ФСТЭК с ними вполне соглашается.
2. Требования к антивирусной защите, системе обнаружения вторжений и анализу защищенности
   Данные системы защиты от НСД начисто отсутствуют в РД 1992 года, поэтому их использование - исключительная прерогатива ИСПДн. Большинством специалистов применение этих систем считается обязательным. Логика этого, впрочем, понятна. Необходимость развертывания этих систем, это как минимум - дополнительный "кусок хлеба". Однако, приказ №58 дает весьма расплывчатые объяснения по этому поводу.
   Применение антивирусной защиты регламентируется пунктом 2.3 приказа, гласящим, что "в информационных системах, имеющих подключение к информационно-телекоммуникационным сетям международного информационного обмена..., или при функционировании которых предусмотрено использование съемных носителей информации, используются средства антивирусной защиты". Хотя формулировка "используются" наводит на мысль, что это не совсем то же самое, что "необходимо использовать" или "требуется использование", с этой подсистемой вопросов возникает меньше всего.
   Применение системы обнаружения вторжений и систем анализа защищенности регламентируется пунктом 2.4 приказа, где сказано: "при взаимодействии информационных систем с информационно-телекоммуникационными сетями международного обмена...методами и способами защиты информации от несанкционированного доступа являются: ...-обнаружение вторжений в информационную систему... - анализа защищенности информационных систем...". В целом, претензии к формулировке в части обязательности те же, что и раньше, но появляется новая проблема - пункт 2.2. того же приказа гласит: "...методы и способы защиты информации от несанкционированного доступа...в зависимости от класса информационной системы определяются оператором (уполномоченным лицом) в соответствии с приложением к настоящему Положению". А в приложении расписаны требования к основным подсистемам ИБ для каждого класса в пунктах 2-4. Об этих системах - ни слова. Все становится более-менее ясно в пунктах 5 и 6, где упоминаются эти две системы. Однако, структура документа и непрозрачные формулировки опять не дают понять, к чему именно и насколько необходимо применять эти средства защиты.
3. Формулировка требований к ИСПДн в зависимости от класса и характеристик, заданных оператором (типовые и специальные ИСПДн)
   Вдаваться в воспоминания "трехголового" приказа нет смысла, стоит лишь отметить, что он сформулирован таким образом, что классы К1-К4 применяются ко всем ИСПДн, однако признаки классификации есть в явном виде только для типовых ИСПДн. Эту проблему до сих (то есть до ввода положения об уровнях защищенности, которое уничтожит старую систему классификации) пытаются решить технические специалисты. Большинство приняло позицию, что для специальных ИСПДн класс определяется на основе модели угроз в соответствии с вербальным описанием класса, данным в пункте 14 этого приказа (там  же, где употребляется противоречивая формулировка "По результатам анализа исходных данных типовой информационной системе присваивается один из следующих классов), тем более, что на основе этих классов определяются требования к защите. Согласно пункту 15 "приказа Трех", класс специальной ИСПДн определяется на основе актуальных угроз безопасности. То есть фактически, для типовой ИСПДн для классификации достаточно классификационных признаков, а для специальной необходим перечень актуальных угроз. Однако, некоторые специалисты, по мнению автора, путают причину и следствие.
   Данный пример автором был почерпнут при анализе околотехнической брошюры одного известного российского производителя средств защиты. В ней говорится, что для ИСПДн К1 и К2 применение АПМДЗ является обязательным на основе существования актуальной угрозы загрузки с внешнего носителя. Авторы брошюры, то есть производители АПМДЗ, рассматривают необходимость применения средства защиты для защиты от актуальной угрозы, что совершенно верно. Однако, они утверждают, что актуальность угрозы определяется классом ИСПДн. Так, например "в системах К1 все оцениваемые угрозы являются актуальными по причине высокого уровня показателя опасности...". Эта фраза справедлива отчасти, однако, согласно документации, определить, является ли система К1 или нет, возможно только после определения актуальных угроз. А значит, могут быть угроз, неактуальные даже с учетом класса системы К1.
   Следует отметить, что угроза загрузки с внешнего носителя (приведенная в документе "Базовая модель угроз..." для ИСПДн практически каждого из возможных типов) будет актуальна в большинстве случаев, это объективный факт. На основе результата анализа угроз будет принято вполне закономерное решение нейтрализовать эту угрозу применением АПМДЗ, о чем и говорят авторы брошюры. Однако, нейтрализация актуальных угроз, согласно действующим нормативным документам, применяется настолько гибко только в отношении специальных ИСПДн, где определяющим является модель угроз, а не требования к классу из приказа №58. Если рассматриваемая ИСПДн - типовая, то применяются "методы и способы", описанные в приказе №58, а там про те же АПМДЗ - ни слова.

Вывод

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