Бумажная безопасность vs Практическая безопасность

Рейтинг:   / 3
ПлохоОтлично 

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

Бумажная безопасность – это в первую очередь безопасность, которая пытается защитить информацию на основе стандартов, то есть берёт ФСТЭК-овский / ФСБ-шный / ГОСТ-ый / ISO-шный документ и начинает его исполнять. Сюда же относится организационная безопасность предприятия и стратегический (не технический) подход в решении проблем, учитывающий психологию людей и структуру (в т.ч. финансовую) организации. Практическая безопасность – это, к примеру, та, которая патчит всё подряд: что увидел, то запатчил; что опасно, на то цепляем логирование, антивирусы, "огненные стены" и прочие радости жизни админа, т.е. все проблемы ИБ она решает исключительно техническими мерами. Кто важнее и какой подход правильнее, как влияет на бизнес современная мировая кибербезопасность, что об этом говорят мировые best practice? Разговор нам предстоит долгий...

Чем отличается бумажная безопасность от практической в историческом контексте?

Для начала разберёмся конкретнее с вопросом: что такое безопасность? Обычно, произнося слово "информационная безопасность", мы говорим о классическом треугольнике и первое, что приходит в голову - это конфиденциальность информации: надо сохранять всё в секрете - тяжёлое наследство спец.служб всего мира, о котором уже многое сказано. В середине 80-х люди поняли, что неплохо бы, чтобы информация была ещё и неизменённой, а спустя ещё несколько лет – добавилось желание сделать её доступной, ибо иначе она становится столь же бесполезной, как и изменённая.

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

В этот самый момент возникновения классического треугольника и произошло разделение на теоретиков и практиков. Теоретическая ИБ всегда строится на принципах управления рисками, основываясь на целях ИС и целях работы компании. Практики имеют ту же цель - защита информации на предприятии, - но идут они уже от практической задачи, от имеющейся системы и средств (не от целей). Какой из этих подходов лучше или хуже? Они оба одинаково ущербны по одной простой причине. Представим ситуацию: программист закончил писать программу и совершил в ней по средней статистике 1 критическую ошибку на 1000 строк кода, говоря о хорошем качестве ПО. Далее, программа выходит на рынок и в какой-то момент времени хакеры, пользователи и какие-то другие люди увидели в ней какой-то процент ошибок (в среднем около 2%, говоря о первых релизах), определяющий на момент инсталляции программы перечень известных уязвимостей. А дальше встречаются 2 умных человека – теоретик и практик – и говорят: "вот эти 2% уязвимостей – их надо исследовать… Либо практически, либо как-то ещё". Что делает практик: он закрывает какую-то часть из этих 2%, вторую часть не закрывает просто в силу того, что он до них не дошёл. Теоретик тоже закрывает какую-то – примерно ту же по объёму, но другую часть уязвимостей. В итоге, остаётся какая-то незакрытая часть, которая у практика никак не называется (потому что он до них не добрался), а у теоретика именуется гордым словом "управление рисками", и мы эти риски принимаем. То есть мы их закинули и приняли, как данность и ничего с ними не поделаешь.

Ключевой вопрос здесь в том, а от чего, собственно, мы защищаемся? Сейчас, в силу того, что информационные системы стали хорошо интегрироваться друг с другом, мы переходим к проблеме кибербезопасности как таковой. Кибербезопасность – это некоторая надстройка над защитой ИС, которая рассматривает не одну конкретную ИС и её безопасность, а взаимодействие различных систем в целом. И одна из главных проблем обеспечения современной кибербезопасности – это обработка больших объёмов данных. У нас уже столько данных скопилось, что мы их обработать-то не можем. Это приоритетное направление мин. обороны США. Они занимаются обработкой по различным срезам (география, время и т.д.), находят и анализируют корреляцию найденных данных, прогнозируют инциденты и измеряют в результате уровень защищённости системы. Это к ответу на вопрос о том, что делать с оставшимися 98% ошибок, которые мы не видим совсем. Прогнозная часть в данном случае выходит на первый уровень.

Современное положение дел на рынке ИБ

Сейчас безопасность во всём мире уходит на аутсорс. Потому что специалист по безопасности должен демонстрировать хорошие компетенции на стыке IT, права и психологии. В реальной жизни – на объекте – от чистого «теоретика» и чистого хакера пользы мало. Это при разговоре с потенциальным заказчиком демонстрация уязвимости его системы хороша. Но хакер бесполезен, когда отдел маркетинга при планировании PR акций сливает всю конфиденциальную информацию, включая know-how подрядчику. Так же как бесполезны тонны инструкций, если ядром сети управляет нечистый на руку аутсорсер или на систему не ставятся критические update. В итоге, нам нужен грамотный хакер, юрист, да ещё и психолог. Держать таких вот ангелов на предприятии часто выходит себе дороже.

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

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

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

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

Как работает теоретик? Теоретик – это, прежде всего, применение нормативных документов и лучших практик, которое может длиться год, два, три... А вот на вопрос: "когда защищать-то будем?", - обычно звучит ответ: "вот сейчас мы 3 месяца классифицируем ресурсы, потом мы пишем политику безопасности, затем пишем ТЗ, потом согласуем с компетентными органами и года так через ~3-4 дойдём до установки всего этого дела на железо". Да, действительно есть мировые известные best practice, которые гарантируют, что в результате мы получим хорошую защищённую систему. Правда, когда-то там, через пару-тройку лет... Но зато теоретик при этом работает с системой в целом, рассматривает её, как живой организм. Он понимает, где что проваливается в системе и от чего или кого это зависит. Если мы работаем в условиях ограниченных ресурсов (а так бывает в 100% случаев), то создание сбалансированной системы защиты, которая подразумевает размазывание выделенных денег таким образом, что на всех ресурсах возникает примерно одинаковый в соответствии с потребностями уровень защищённости, - это та задача, с которой теоретик справляется хорошо. Во многом благодаря использованию пресловутого управления рисками, то есть мы смотрим на возможную угрозу, оцениваем последствия, вероятность, стоимость защиты от него с учётом остаточного риска и принимаем решение, защищаться от него или же нет.

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

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

Теоретик подразумевает, что люди все разумные, следуют как минимум основам инструкций и главное, не делают дебильных ошибок. Что понимается под «дебильными ошибками»?.. Тут вспоминается пример с международным банковским форумом, который проводился вот недавно – в начале 2013 года. На него по неизвестным причинам не позвали одного известного российского хакера. Он с горя взломал сайт этого форума (посвящённый вопросам информационной безопасности) и написал там: "что это за безопасники такие, которые берут деньги за защиту, и сами себя защитить не могут"? Вполне разумное высказывание. Ошибка там состояла в элементарной непроверке данных в регистрационной форме – вещь, о которой на самом форуме говорили раз, наверное, 50. Инструкций тут, как видно, оказалось мало даже профессиональным безопасникам. Чего уж говорить о рядовых сотрудниках.

Ещё один аспект различий в методологии мышления теоретика и практика. Рассмотрим ситуацию, в которой сейчас часто оказываются крупные организации, ставящие перед собой цель поддержания конфиденциальности информации. Есть сотрудник, есть КТ, с которой он работает. Есть угроза инсайдерской утечки и соответствующие каналы. Перекрыть все каналы по всем известным причинам невозможно, поэтому остаётся перекрывать хотя бы часть или играть на психологии. Как часто решают данную проблему практики? Они пытаются всяческими способами контролировать все исходящие потоки информации: смотрят почту, исходящий трафик на разные протоколы и т.д. (вручную и/или по результатам сигналов DLP-систем). Стаёт вопрос о законности данных действий: прямое противоречие с 24 статьёй Конституции очевидно. Практики уходят дальше в детали технической реализации: включить пункты о таком контроле в трудовой договор (полнейшая глупость), скрывать факт наличия этого контроля, основываться на автоматической (без участия человека) обработке информации от DLP, уволив потом человека по искусственному поводу, и многое-многое другое, что всё равно проблему адекватно не решает и/или создаёт массу новых проблем. Теоретик же способен посмотреть на эту ситуацию с другого уровня абстрагирования и не углубляться в технические решения всё глубже и глубже, а посмотреть на корень проблемы и концептуальные пути её решения. Рассмотрим возможные варианты теоретика.
Первый вариант: посадить сотрудника на процент от прибыли компании (такой, что б его текущая средняя зарплата осталась той же/смешанный вариант; добавить гибкую систему премий в случае увеличения прибыли Компании). В этом случае, продавая секреты компании и нанося ей тем самым фактический урон, он наносит его и себе; конечно, это не исключает инсайдинг, но завербовать такого человека куда как сложнее, да и искать пути для продажи самостоятельно он тоже вряд ли станет.
Второй вариант: включить DLP-систему в режиме скрытого мониторинга (если мы оповестим всех о наличии такой системы, то фактически скажем: «дорогой, мы вот здесь вот пути тебе перекрыли, так что не ломись и ищи другой», - а другой – ясное дело – найдётся), а далее при выявлении системой подозрений, безопасник подходит к человеку и говорит: «а покажи-ка, что у тебя в том-то письме, не утащил ли ты там конфу», - и человек становится в логическую вилку: либо он показывает (добровольно, т.е. не нарушает Конституцию) и себя раскрывает, либо же не показывает, признавая по факту свою вину и его увольняют, ничего не читая (это уже вопрос чисто техники: к примеру, не показывает, т.к. там личное, личная переписка на работе запрещена, отсюда предупреждение; 3 таких набрал и до свидания). 
Третий вариант: все отправляемые письма должны ставиться человеком (добровольно) в копию сотруднику отдела ИБ, если нет в копии безопасника, система не даёт отправить письмо. Вариант также неплох, но хуже первого тем, что во-первых, полностью исключает личную переписку, в отличие от второго (а она бывает очень нужна: ситуации бывают различные), плюс человек знает, что данный путь перекрыт и просто будет искать другой, тогда как при работе в скрытом режиме он может легко себя выдать.
Вот, собственно три возможных (но далеко не всех) концептуальных подхода теоретика, учитывающих и особенности работы компании и главное, психологию преступника, которая отнюдь не маловажна.

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

Итоги

Так какая система безопаснее: которую построил теоретик или которую построил практик? Ответ: ни та, ни другая. Спор тут бессмысленный - всё равно, что спросить, какая нога лучше: правая или левая.

Безопасность ИС в современном мире состоит из двух частей: из сложности самих структурных элементов ИС и сложности их взаимодействия и взаимосвязей - это и есть в очень условном смысле деление зон практика и теоретика. И второй элемент безопасности, представляющий по факту эффект эмерджентности системы, здесь важнее. Это как раз то, с чем в начале 90-х столкнулись разработчики ПО, формулируя принципы ООП, как основу борьбы со сложностью и проектировщики промышленных СУБД, создавая реляционную теорию.

Что же касается сложности элементов, то даже здесь ситуация непростая и содержит в себе два аспекта: сложность самого элемента и динамика развития этого элемента. Рассмотрим ОС Windows 7 - это около 7 миллионов строк кода. Как уже было сказано, на 1000 строк - одна ошибка, то есть всего около 7000 критических ошибок. Это не компьютер, управлявший кораблём Аполлон при высадке на Луне, где можно было предусмотреть все возможные случаи и состояния и всё строго описать. Кроме того, эти ошибки windows 7 уже никогда не будут исправлены (!), потому что новая система (с примерно тем же количеством уязвимостей) выйдет гораздо раньше, чем до них доберётся поддержка Microsoft. Тут мало того, что всё большое и непонятное, так ещё и постоянно изменяется (с выходом новых версий). Надо учитывать, что когда компания выпускает патч, он тоже содержит какие-то строчки кода с точно таким же качеством...

Что можно сказать в итоге? Практики нужны любой компании. Теоретики тоже нужны, но их соотношение должно быть ~1:3-1:5. То есть нужен некий штат, который стоит денег. Именно поэтому современная безопасность и уходит на аутсорс в отдельные компании. В остальном же: всё в наших руках.

A.S.

Понравилась статья? Хотите читать этот блог?

Ваш e-mail: *

Ваше имя: *

Добавить комментарий


Защитный код
Обновить

Вы здесь: Home Юридические вопросы Орг. безопасность