Пользователь
0,0
рейтинг
24 февраля 2015 в 17:51

Разработка → Кнут и… кнут информационной безопасности на предприятии из песочницы

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

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

C горячей и горящей частью опуса закончу, не за эмоции речь, переключаемся на конструктив. Все, кто с этим сталкивался, поймет и немало дополнит. Речь сейчас хочу завести о том, что с этим делать? Ведь в основе ИБ на предприятии лежит крайне конструктивная и разумная цель — предотвращение утечек данных, которые потом по этому самому предприятию могут вдарить, и часто — очень больно. Здесь стоит учесть не только (и не столько) финансовые риски, сколько репутационные и прочие другие риски, которые несомненно исполнились бы, когда-нибудь бы, возможно бы, *-бы *-бы *-бы.

Основные кейсы, которые пытается закрыть собой ИБ на мой недальновидный взгляд, такие:

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

2. Ограничение НСД «из вне». Ну тут всё понятно. Вкупе с програмнно-аппаратными комплексами из первого пункта решение этих типовых задач сложности не представляет.

3. Ограничение НСД «из нутрей» организации ко всему тому, что перечислено в п 1. Здесь несколько подробней, т.к. главная угроза НСД в ИБ — сотрудник предприятия — преобладает в качестве потенциальной угрозы. К указанному оборудованию, перво-наперво, необходим доступ админам всех мастей, программистам и\или аналитикам, и иногда непосредственно бизнесу, который использует какое-нибудь ПО для верчения данных, отчётов, и всего такого, что ему, бизнесу, надо. Как ни странно, здесь уровень сложностей и проблем, создаваемых ИБ, не так высок. Т.к. админам доступ нужен для своей админской магии, аналитики часто просто работают на ПО, которое поставили админы, бизнес «сказал надо, значит надо» и ему сделали доступ, потому что ИБ работает на бизнес, а не наоборот. Больше всех страдают разработчики, которым подавай сервера, доступы, непонятное ПО, самописное непонятное ПО, при этом чтобы и данные были живые. Всё это подпадает по собственноручно написанные нормативные акты и какие-нибудь-ещё акты, приказы, нормы, угрозы-риски, которые же сами безопасники и написали в ходе трудовой деятельности. Здесь и срабатывает эффект бутылочного горлышка, что пока разработчики вкупе с менеджерами согласуют (если это вообще возможно) все эти бесконечные согласования, то бизнес стоит и ждёт. Потому что сам поймал себя в ловушку картбланша для ИБ, потому что не продумал механизм эскалации рисков и их оценки, потому что вникать и понять этот пласт информационных угроз, которые, на минуточку, включают практически весь спектр IT-дисциплин, ну просто невозможно.

Какие варианты выхода из ситуации я вижу (придумал, прочувствовал):

1. Первый, он же главный, возможность принятия рисков руководителем бизнес-подразделения, который заказывает что-то, что упёрлось в сложность согласования ИБшниками. Очень часто бизнесу нужны инструменты, которые должны быстро решить\проверить какую-нибудь мысль\концепт руководителя. Эти точечные, или акупунктурные, уколы могут быть очень действенны и полезны для выполнения бизнес-задач. И если с другой долгой тягомотиной — закупкой оборудования — вопрос можно решить обратившись к хостингам, то вопрос ИБ встает в полный рост. Данные, которые нужно обработать, находятся во внутренних системах и их нужно передать в системы внешние. Тут два есть два варианта: очень долгий и быстрый неправомерный. Думаю, не стоит объяснять, каким вариантом чаще пользуются люди, которым нужно выполнить задачу.

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

3. Упрощение деятельности по согласованию всех своих же ограничений. Ведь они все равно будут согласованы, потому что «нужно», но это сэкономит гекалитры крови, пролитой на полях аутлучных согласований.

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

С любовью, ненавистью и пониманием,
%работникнейм%
@Crossover
карма
0,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (22)

  • –1
    С учетом того, что согласно отчетам секьюрити-компаний о крупных атаках (банки, большие гос. и комерс. сруктуры), первым шагом заражения становится запуск пришедшего по почте эксплоита или вообще ехе-файла, то кому-то живется вполне весело и вольготно на Руси, их не предупреждают, не запрещают, не пытаются впихнуть в бутылочное горлышко… а Вам… а Вам просто не повезло :)
  • +2
    Я давно несу мысль, что задачи сисадмина (обобщая — девопса) противоположны задачам ИБ. Задачей сисадмина является «чтобы оно работало» (у лиц с санкционированным доступом). Задачей ИБ является «чтобы оно не работало» (у лиц с несанкционированным доступом). Проблема в том, что текст в скобках уже никого не волнует.

    Решением проблемы является учёт интересов обоих сторон в KPI работы «противоположного» отдела. То есть оставленная дыра мимо безопасников — намыленная шея сисадмина. Тормоза с согласованием или неразумный запрет, препятствующий работе остальных отделов — намыленная шея безопасника.

    Вот вторую часть-то и забывают. Хотя PKI простой — «время, потраченное остальными сотрудниками на согласование и преодоление запрета для осуществления своей служебной деятельности». Не может быть нулём, но может к нему стремиться. Уменьшили время за месяц — получили премию. Ухудшили — минус к показателям эффективности службы.
    • –1
      Бывали казусы, когда согласование с ИБ занимало время, превосходящее в несколько раз время на проектирование, разработку и внедрение проекта. Делают проект на хостинге\локальном компе\наручных часах, а после обкатки и тестирования уже выводят в поле полки для борьбы с IT и ИБ.
  • +1
    Интересно, а что вкладывается в понятие «возможности принятия рисков руководителем бизнес-подразделения»? Я почему-то вижу только два варианта:
    1. Если происходит инцидент, то руководитель несет реальную и большую ответственность (штраф/гонения/увольнение) => никто из руководства в подавляющем числе случаев не будет брать на себя такой риск.
    2. Если происходит инцидент, то руководитель пожимает плечами и тяжело вздыхает: «Ну что ж, косяк, бывает», и никакой ответственности не наступает. В этом случае можно вообще отказаться от всяких согласований с СБ — пусть все творят что хотят.
    Таким образом, будет либо хаос и анархия, либо прежняя ситуация с нескончаемой чередой согласований.
    Не согласны?
    • –1
      Поясню на примере. Есть идея реализовать %фичанейм%, которая повысит %оченьважныйKPIнейм%. При этом данные, которыми предполагается вертеть не представляют никакой угрозы безопасности, ни какое-нибудь там 152-ФЗ или, прости господи, PCI DSS. Однако к этой реализации применяются те же самые меры, как и для всего остального — гибкости то нет, нормативы один, гребенка одна. И вот в этом случае, дабы безопасность не упарывалась на согласованиях, руководитель кастует заклинание «Принимаю риски». И всё. Безопасники имеют виноватого на случай ЕСЛИ что-то произойдет, бизнес имеет свою фичу и никто из этих двух не имеет геморрой.

      По пунктам 1 и 2, ИБ в этом случае тоже не несет ответственности, но виноватого ищет и найдет. И анархию можно контролировать, контролируя опорные точки и сверхважные инфраструктурные цели, к которым вряд ли относятся десктопы менеджеров.
      • 0
        Ой, а я себе вообще другую ситуацию рисовал. Что речь идет о каких-то временных вещах и коротких сроках (скажем, доступ к сайту открыть или флеш-накопитель разрешить подключать и т. п.). Тут, действительно, идея с взятием руководителем ответственности на себя еще может иметь право на жизнь — но такие заявки и так обычно согласуются без проблем.
        А с долговоременными фичами вообще все плохо, ИМХО. Хорошо, пусть есть проект «Разработка системы анализа %данных%». И, допустим, начальник отдела или управления сказал: «Все норм, пусть делают, всю ответственность я беру на себя, важных данных там нет». ОК.
        Систему сделали и внедрили. ОК.
        После этого прошел месяц/год, и начальник внезапно уволился/эмигрировал/умер. Кто теперь должен «брать ответственность»? И. о. начальника?
        • 0
          Хороший вопрос. Если проект не подпадает под явные зоны ответственности ИБ, то его вроде как и вносить в список угроз не нужно. Соответственно, ответственность за угрозу (которой вроде как и нет, данные-то несекурные), переходит к преемнику бравшего ответственность, как и всё другое «наследство».
          • 0
            И здесь получается плохо, т. к. человек может и не согласиться с мнением предшественника или просто не захотеть лишней ответственности. Особенно если придет человек новый (из другого отдела, например): ему нужно будет какое-то время вникать в происходящее. А отвечать за что-то, с чем даже не знаком, — это как-то неправильно.
            Не говоря уже о периоде поиска нового руководителя — получается, что в это время с системой может происходить все, что угодно, и никто ни за что не будет отвечать.
      • +2
        При этом данные, которыми предполагается вертеть не представляют никакой угрозы безопасности, ни какое-нибудь там 152-ФЗ или, прости господи, PCI DSS.


        проходит полгода, в чью то светлую голову приходит мысль — а давайте мы на серваке *** еще и &@#% будем крутить. И тут приходят они…

        Порядок нужен. Просто порядок зачастую подменяют видимостью работы, то бишь бюрократией. А это уже зона ответсвенности хозяина и топ-менеджмента.
  • –2
    Служба безопасности на любом мало-мальски крупном предприятии это вотчина конторских пенсионеров. Причем слово «информационная» в ИБ для них пустой звук. Цель всех инструкций и актов как раз и заключается в снятии ответственности со службы безопасности. Они запрещают всё, и если вдруг что-то таки случится, то «они предупреждали». Ну и наказывать нарушителей — это самая приятная их обязанность…

    На своей первой работе сталкиваясь с таким подоходом со стороны СБ, я тоже психовал по началу. Потом успокоился. Просто делал свою работу и всё… Обычно на практике у них просто не хватает квалификации, чтобы понять что делают айтишники. Поэтому особых проблем с ними не возникает…
    Конечно бывает попадаются особо ретивые. Тогда хоть увольняйся, жизни не будет. Но подобная ретивость у этой братии обычно не от большого ума…
    • –2
      ВАУ
    • –1
      подписываюсь под каждым словом. пять лет проработал в крупной федеральной сетке, конторских пенсионеров подтверждаю. При предполагаемом сожжении провинившегося на каждый чих, админский пароль знала каждая блондинка-секретарша. При том что технари на самом деле были достаточно сильные.
    • –1
      Точно всё описано. Был по обе стороны баррикад. Пенсионеров подтверждаю с тем уточнением, что эти пенсионеры — из «бывших» опер- итдитп, а действительно адекватных там очень мало.

      И очень яростно подтверждаю это:
      Ну и наказывать нарушителей — это самая приятная их обязанность…

      и это
      Обычно на практике у них просто не хватает квалификации, чтобы понять что делают айтишники

      хотя последнее не потому что там на самом деле админы ИБ бездари, а просто потому что начальство там другое, с другими (своими) задачами и крутым либидосамомнением.
    • 0
      Верно. Это не романтизированный образ «анти-хакера», который отбивается от атак АсидБёрнов и КрэшОверрайдов. Это больше склочный, бюрократический образ обиженного недооценённого сотрудника, который делает сизифов труд и никто его, по большому счёту, в рассчёт особо не берет. Всем нужно делать своё дело, работу работать, а не блюсти бесконечные нормы безопасности, и из-за эффекта недооценнёности они рожают тысячи нормативных актов и норм, чтобы хоть количеством добиться «услышимости».
    • 0
      Ну а что мешало обратиться к своему руководству и описать Ваши проблемы?
      Или руководство тоже дрожало в страхе от ИБ?

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

      Если и Топ менеджмент согласен в внедренным подходом, значит эта конкретная организация так работает. Либо смирится либо уходить.
      • 0
        Мне ничего не мешало и проблем у меня не было. У меня в конечном счете сложились нормальные отношения с ИБ. Я помогал им решать их проблемы, а они не мешали мне выполнять мою работу. Все люди, независимо от профессиональной принадлежности…

        Горячие линии, угнетаемый работник?! Что это? 0_о

        Это вообще-то было в середине 90-х прошлого века. Да и угнетать меня было проблематично, я уже тогда отлично знал, что такое «жить по уставу» или, как теперь модно говорить, итальянская забастовка. Достаточно начать скурпулезно выполнять инструкции отдела ИБ и через некоторое время они и руководство сами начинали выть… ))
  • 0
    В целом автор прав. Чем крупнее предприятие, тем больше ИБ связана с бюрократией и прочим перекладыванием бумажек. Это и отпугивает многих специалистов области ИБ работать в больших компаниях. Им просто становится скучно делать монотонную далеко не творческую работу.

    Мне кажется выходом из положения может служить частичное доверие + контроль. Безопасность во многом коррелирует с психологией. Внутренние безопасники, наблюдая за работой людей смотрят за их поведением, могут строить модель человека и прогнозировать поведения человека, если дать ему чуть больше прав.
    • 0
      Я долгое время думал над тем, как можно сдвинуть эту систему хотя бы в уровень адекватного. Общая мысль проста — не нужно грести всех под одну гребенку, и уборщицу и системного архитектора. Без корреляции скажем так роли, или access rules, для разных сотрудников ИБ на предприятии является тем, чем она есть. Плюс ко всему имеет место быть и обычная лень, когда безопаснику лень разбираться во всех хитрослетениях системы, чтобы адекватно составить правила доступа. А если этих систем еще и в несколько раз больше, чем безопасников — то система просто ступорится и всё, аллес.
  • +1
    «ЕСЛИ ЧТО, МЫ ЖЕ ПРЕДУПРЕЖДАЛИ!». Таким образом, складывается ситуация, когда ИБ риски обозначает, но ответственность не несет — её несут сотрудники.

    Менеджмент ИБ, это встраивание в плоть и кровь организации собственно процессов ИБ.

    Существуют владельцы активов или процессов. Задача ИБ оценить актив и предоставить владельцу актива, сопутствующие этому активу риски. Объяснить ему на пальцах, что будет при этом, этом и этом.

    Если риск предполагает существенные финансовые/репутационные/прочие потери в случае его реализации, рассмотрение риска надо выносить на уровень ТОП.

    А дальше руководство решает, принимать этот риск на себя или закрывать его (4 действия по классике).

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

    Высшее руководство видит всю картину в целом и выносит решение по каждому пункту. Берет на себя ответственность по каждому параметраму. Рискует своими деньгами.

    Если все стало завязано только на ИБ, которое «душит». Значит что-то не то с общим риск менеджментом. Надо писать свой пост на имя Генерального, а не сюда.
    • –1
      Существуют владельцы активов или процессов. Задача ИБ оценить актив и предоставить владельцу актива, сопутствующие этому активу риски. Объяснить ему на пальцах, что будет при этом, этом и этом.

      В теории, теория и практика — это одно и то же. Но на практике это совершенно разные вещи. Раздутые из мухи в дирижабль риски, которые представляются на оценку топ-менеджменту, да еще оформленные казённым языком, провоцируют у оного лютое чувство паранойи. («Давайте запретим пользователям запускать все (!) экзешники на компьютере. Все экзешники, всем пользователям. Ведь это несет риск запуска на компьютере вируса, а вирус может увести ВСЮ КЛИЕНТСКУЮ СИСТЕМУ». Утрирую немного, но как на это должен реагировать топ-менджмент?
      • 0
        Топ менеджмент это люди которые нацелены на получение прибыли. Хозяин бизнеса нанимает этих людей, чтобы они крутили ему механизмы все этой махины, которая должна делать деньги.

        Топ менеджмент должен задать себе вопрос, если мы запретим все exe, что будет с нашими бизнес-процессами? Что будет в конечном итоге с нашей прибылью?

        И взять ответственность за свое решение на себя.

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

      • 0
        Ну, СБ-то как-то ухитряется «протолкнуть» свою позицию. Что мешает руководству вашего направления заняться тем же и оформить казенным языком лютую необходимость расширения прав доступа сотрудников? Раздуть дирижабль вашей работы, которой мешает политика безопасности организации?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.