«Рисковая vs Ресурсная» модели ИБ

Повторюсь чем «хороша» «рисковая модель».
Качественная оценка рисков так или иначе подгоняется под представления принимающих риски и утверждающих на практике.
Количественная оценка вроде бы должна невелировать недостатки качественной оценки… но тут две проблемы:
1 — чего это вы мне принесли количественную оценку, не бьющуюся с качественной которая прошла раньше и принята.
2 — при наличии десятка методов рассчета — всегда есть «корректирующий коэфициент» который приводит результат к ожидаемому…
Ну можно еще вякнуть кто коэфициента нет! Но тогда есть статистические данные на основе которых… ну вы поняли wink emoticon
А что же заставляет руководителей бизнеса принимать Такую качественную оценку? А реальные ресурсы заставляют! «Ресурсная модель» работает на практике стекая с бумаги в реальность… а вот «рисковая» часто на бумаге и остается!
ПИ218: Корректировка системы ИБ Ресурсом сильнее корректировки ее Риском! (с) swan

Тринадцать граней профессии ИБ

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

Грань 1. Роль ИБ

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

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

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

Грань 2. Взаимоотношения с бизнесом

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

Грань 3. Современный облик службы безопасности

Современное представление подразумевает наличие трех направлений безопасности в компании: экономической, физической и информационной. Часто подразделение включает в себя директора по безопасности (CSO) и менеджеров по каждому из направлений. Забудьте про CISO! Взаимодействием с директорами и владельцами компании будет заниматься CSO, а вы будете взаимодействовать с CSO и руководителями департаментов в той степени и на том уровне, который воспринимается бизнесом.

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

Грань 4. Взаимоотношения с ИТ

Современный облик взаимоотношений с департаментом ИТ обусловлен как объективными, так и субъективными факторами.

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

К субъективным можно отнести особенности менеджмента компании, человеческий фактор и восприятие роли ИБ руководством компании и владельцами бизнеса.

Все эти факторы определяют новый облик службы ИБ: координирующие, управляющие функции и комплайнс обеспечивает менеджер по ИБ в связке с руководством ИТ-департамента, а эксплуатацией и выполнением требований занимаются специалисты ИТ-подразделений. Исключение составляют специализированные системы контроля и защиты.

Грань 5. Угрозы и уязвимости

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

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

Грань 6. Риски

C рисками та же история, что и с угрозами. Существуют только те риски, которые воспринимает бизнес. Других просто не существует! Начинающие специалисты по информационной безопасности часто упоминают троицу: конфиденциальность, целостность, доступность. Со временем для многих становится очевидным, что их обучали обеспечивать прежде всего конфиденциальность, но на практике требуется обеспечивать непрерывность бизнес-процессов и устойчивость функционирования информационных систем.

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

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

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

Грань 7. Средства и системы защиты информации

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

  1. Системы и средства, обеспечивающие базовые механизмы защиты, формирующие «периметр» и функционирующие на нем. Данный класс обеспечивает выполнение правила: все информационные технологии, включенные в периметр, могут делать что угодно, находиться в любом состоянии внутри периметра, но влияние на них извне и влияние их вовне контролируется. К таким системам и средствам можно отнести межсетевые экраны, защищенные шлюзы и прокси, антиспам, антивирусы на периметре и т. п.
  2. Системы и средства, обеспечивающие базовые механизмы защиты внутри периметра на системном уровне (средства AD, антивирусы, средства архивирования, встроенные механизмы ИС и т. п.).
  3. Системы и средства, выполняющие свои функции на прикладном уровне (DLP, IPS, WAF, SIEM, IDS и т. п.).
  4. Системы и средства поддержки системы менеджмента информационной безопасности. Сюда можно отнести системы автоматизации менеджмента рисков, построения моделей, аналитические системы, системы отчетности и т. п.

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

При выборе средств и систем защиты обращайте внимание не на те, которые кажутся лучшими на момент выбора, а на те, которые долго держатся среди лучших и есть уверенность, что они будут стабильно развиваться и оставаться в лидерах. Опыт показывает, что продукт-лидер в той или иной области – событие временное. Сегодня он впереди, а завтра разработчик или прекратил его поддержку продукта, или обанкротился, или его купил другой вендор, или… И не забывайте, все системы содержат уязвимости и недокументированные возможности/недостатки. Часто о них не знают даже поставщики.

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

Грань 8. Вендоры и интеграторы

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

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

Грань 9. Стандарты и требования регуляторов

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

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

Грань 10. Интерпретация

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

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

Грань 11. Учет и контроль

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

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

Грань 12. Аутсорсинг

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

Конечно, речь не идет о специальных системах, которые должны эксплуатироваться собственными специалистами по ИБ. А вот обслуживание таких систем тоже можно передать на аутсорсинг.

Грань 13. Это вы сами

Роль личности во всех сферах деятельности очень высока. Какие бы технические средства ни применялись, они не могут функционировать самостоятельно, без специалистов, и не способны охватить все направления бизнеса компании. Эффективность защиты зависит прежде всего от человека, и заменить специалиста по информационной безопасности попросту нечем! Необходимо формировать репутацию и демонстрировать доверие в компании и отрасли.
И напоследок несколько советов специалистам по ИБ: http://goo.gl/NPjO6G

Понятие Периметра в сфере ИБ.

вена-золота-10715371На сегодняшний день, специалисты все чаще говорят о размытии периметров или даже о том, что пора забыть о Периметре вообще.
Не могу согласиться с такой постановкой вопроса. Дело в том, что Периметр — это не просто линия на бумаге, определяющая зону сети или информационной системы (ИС) или еще чего то… Периметр — многомерная сущность! Периметр всегда был многомерным!
Любая ИС всегда представлена на различных уровнях абстракции не полностью! Какая то часть представлена на уровне сети, да еще и на разных уровнях модели OSI, другая часть представлена на системном уровне, третья на прикладном уровне! И даже в бухгалтерских отчетах или отчетах финансовой аналитики информационная система представлена частично, но не вся! Кроме того, информационная система и ее компоненты представлены ЗА пределами компании в которой она внедрена и эксплуатируется. На уровнях представления Интернет, пользователей, разработчиков и т.п.
Понятие Периметра не деградировало — а наоборот ЭВОЛЮЦИОНИРУЕТ с добавлением все новых и новых уровней абстракции и измерений! Если мы не вполне способны представлять или считать с учетом появления новых уровней — это не значит, что мы должны отказаться от них! Потому как эти, не учтенные, измерения — есть источники и средства влияния на ИС и порождают каналы утечки.
Периметр всегда был многомерным, появляются новые измерения и уровни абстракции которые мы еще не привыкли учитывать. Но мы научимся! Это сродни представления многомерного объекта на плоскости. Проекция кажется хаотичной, границ не понять, но это вполне себе объект!

О конструктивных предложениях представителей отрасли в НПА регуляторов

zayacПочему то представители регуляторов и не только они стали настойчиво предлагать включиться в работу над НПА специалистов отрасли. При этом, стимулом является только «вы не критикуйте если не участвуете» или «все ради совершенствования отрасли». При этом специалистов привлекают в режиме «вы пишите, а мы посмотрим» этакий «синдром троечника — начальника пионерского отряда». Попробовали специалисты этим заняться пару лет — не понравилось! По сути в интересах регулятора пару «синих цветочков перекрасили в красный» и на этом все! Специалисты отрасли выпускают материал по тем или иным НПА и критикуют по разному. Пожалуй, схема: «Регулятор стремится улучшать отрасль — пусть проявит себя! Пусть изучает материалы специалистов отрасли на блогах, на конференциях, которые поддерживает, у отраслевых сообществ которые поддерживает и т.п. Пусть воспринимает что нужно в НПА!» Вполне себе подход?!

Продление сертификатов ФСТЭК (информационное письмо)

zayacЛюбопытный документ ФСТЭК (по сути заплатка скотчем):

ИНФОРМАЦИОННОЕ СООБЩЕНИЕ ПО ВОПРОСУ ПРОДЛЕНИЯ СРОКОВ ДЕЙСТВИЯ СЕРТИФИКАТОВ СООТВЕТСТВИЯ НА СРЕДСТВА ЗАЩИТЫ ИНФОРМАЦИИ, ЭКСПЛУАТИРУЕМЫЕ НА ОБЪЕКТАХ ИНФОРМАТИЗАЦИИ

от 23 января 2015 г. N 240/24/223 Ссылка на ИС: http://goo.gl/3v76TZ

В ИС указано, что в соответствии с 608 и 199: «на отдельные экземпляры средств защиты информации, эксплуатируемые на объекте (объектах) информатизации, продление сроков действия сертификатов соответствия может быть обеспечено организацией, эксплуатирующей данные средства защиты, и проведено по упрощенной схеме»

Однако ни 608 ни 199 не содержат такого! 199 п. 3.7 говорит: «Продление срока действия сертификата может проводиться по упрощенной схеме, включающей проверку конструкторской, технологической, эксплуатационной документации и условий производства сертифицированных средств защиты информации. Заявитель для продления срока действия сертификата … бла бла бла»

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

Возможно я ошибаюсь, но тут явная ошибка авторов ИС!

Далее о возможностях продления: если «средство защиты информации функционирует с требуемой эффективностью» — понятно о чем речь но не совсем. Условия применения и требования к среде — должны быть в документации. Если условия изменились и так применять нельзя. А если не изменились — то все работает как положено! Если речь об эффективности — то тут очень абстрактное понятие и не очень годится…

Ну и еще набор не существенных требований…

Нельзя сказать что проблемы нет, но информационным письмом она не решается.

Ссылка на ПП 608: http://goo.gl/MWg3nP Ссылка на Положение (199): http://goo.gl/rN5yCC

Кризис? Осмотреться в отсеках!

zayacОднажды наступил кризис и нам сказали: Денег выделять будем только на самое важное, или не будем, повышайте эффективность уже имеющихся систем защиты!

Писать про то как себя вести в кризис Вендорам, Интеграторам, Поставщикам и другим жителям нашей отрасли? Да они сами лучше меня знают… Поговорим про Заказчиков, да что там, расскажу про себя.

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

Знать. Контролировать. Защищать. Влиять.

  1. Знать.
  • Информационные активы компании;
  • ИТ-инфраструктуру компании;
  • Владельцев информационных активов;
  • Потребителей информационных активов;
  • Порядок хранения, передачи, обработки данных;
  • Требования, предъявляемые правовыми и нормативными актами;
  • Бизнес-процессы, связанные с обработкой информационных активов;
  • Планы развития или реорганизации ИТ-инфраструктуры и связанных процессов;
  • Источники угроз безопасности информации и т.п.
  1. Контролировать.
  • Состояние защищенности информационных активов;
  • Изменения: в ИТ-инфраструктуре компании; в информационных активах компании; в перечне субъектов доступа; в информационных потоках; в правилах разграничения доступа; в бизнес-процессах, связанных с ИТ-инфраструктурой; в нормативных и правовых актах и т.п.
  • Порядок разграничения доступа к информационным активам;
  • Исполнение политик информационной безопасности;
  • Источники угроз безопасности информации и т.п.
  1. Защищать.
  • Информационные активы компании;
  • ИТ-инфраструктуру компании включая: средства вычислительной техники; средства связи и каналы связи (сетевую инфраструктуру); СХД; Мобильные и носимые устройства.
  • Персональные данные; Информационные активы партнеров; Информацию, влияющую на репутацию компании и т.п.
  1. Влиять.

На:

  • планы развития ИТ-инфраструктуры компании;
  • порядок обработки информационных активов;
  • порядок разграничения доступа к информационным активам; Формирование и исполнение политик обработки информации;
  • выработку решений, затрагивающих ИТ-инфраструктуру компании;
  • источники угроз безопасности информации.

Как может выглядеть состояние по каждому направлению:

333

Очевидно, что очередность идет от Знаний к Контролю и только потом к Защите и Влиянию. Каждый уровень опирается на предыдущий. И тут важнейшими являются Знания и Контроль, или как говорят в нашей среде «глазастость»! Да, можете нарисовать себе подобное и расставить метки по каждому направлению. Полезно составить перечень того что нужно сделать для того чтобы повысить «глазастость» и что этому мешает.

Теперь обратимся к следующим координатам:

Дело в том, что системы, помогающие обеспечить указанные выше 4 направления тоже можно поделить на 4 класса по степени первоочередности и влиянию на все аспекты безопасности. Вы можете сами составить свою картину, но моя такая:

  1. Системы, обеспечивающие базовые «Знание, Контроль, Защиту» (ЗКЗ) на периметре. (межсетевые экраны, WSA, ESA, анти-спам, антивирусы на периметре и т.п.)
  2. Системы, обеспечивающие базовые ЗКЗ внутри периметра. (AD, антивирусы, бэкапы, встроенные механизмы и т.п.)
  3. Системы, обеспечивающие ЗКЗ на прикладном уровне (DLP, IPS, SIEM, IDS и т.п.)
  4. Системы поддержки типа автоматизации менеджмента рисков, отчетности и т.п.

Тут важно понимать, очередность тоже идет от 1 к 4 уровню.

Системы 1 класса как правило уже есть. Эти системы очевидны, задачи по их применению понятны и тут сильно не разгуляешься. Закупили – внедрили – поддержка. Системы 2 уровня или встроенные, или стараются применять «бесплатные» версии или аналоги на свою голову.

В кризисные времена системы 3 уровня восходят на трон! Они начинают превращаться в нечто особенное и вот почему:

Из-за того, что они обладают некоторыми свойствами привыкания пользователей к ним и в условиях, когда Заказчик не готов за них платить можно использовать это свойство, внедряя такие системы в режиме «продолжительный пилот». Когда Заказчик будет готов вкладывать в ИБ – куда нести деньги становится очевидным!

Очевидно применение средств, повышающих «глазастость» и тут нет альтернативы DLP системам. Прежде всего отечественным! Хотя бы потому что они гибче и возможность прямого общения с разработчиком – огромный плюс. Вообще нужно отметить, что месяц применения DLP продуктов компании INFOWATCH окупает ее стоимость полностью! При этом, система позволяет использовать ее не только по «прямому назначению». Известны примеры, когда продукты INFOWATCH использовались как некий специализированный SIEM и с его помощью, за счет автоматизированного анализа активностей в сети были выявлены и APT атаки и несколько уникальных BOTNET активностей которые не удавалось выявить другими специализированными средствами, что делает их систему уникальным средством с широкими возможностями. Так же системы INFOWATCH позволяют работать с данными косвенно демонстрирующими активность использования ресурсов и тут уж насколько хватит смекалки ее пользователям для работы. Это еще раз подтверждает, что грамотно сделанный продукт в грамотных руках специалиста это сила!

Именно на повышение уровня Знаний и широких возможностей Контроля в кризисное время – делают особенным применение продуктов 3 класса.

Итак, если случился кризис и бюджеты ограничены: внедряйте DLP систему. Если вы еще последуете моему совету и выберете продукты компании INFOWATCH – у вас будет целый набор скрытых дополнительных возможностей в части их не стандартного применения! Гарантирую, это даст максимальный эффект и окупится в течении месяца!

И запомните: Знать и Контролировать – вот функции, важность которых в кризис возрастает кратно!

Женщина в профессии ИБ:

В своей работе мне приходилось и руководить и взаимодействовать и подчиняться женщинам. Самым выраженными профессиональными качествами женщин в профессии ИБ я бы отметил ответственность. Исполнительность у женщин тоже веский аргумент при формировании рабочих групп. Кто то может сказать, что творческая составляющая у женщин ниже чем у мужчин но это не так! У женщин есть особенность — они всегда более детально представляют процессы. Там где мужчина поставит перед собой 3 вопроса по предмету деятельности, женщина поставит 15! И если мужчина готов махнуть рукой на один вопрос, женщина так легко их не бросит.

Поделюсь секретом, если вы хотите сформировать эффективную команду для решения сложной задачи или спасения критического проекта, сделайте два шага: 1) пусть команду возглавит пара из мужчины и женщины; 2) команду должна собрать эта пара самостоятельно.

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

Товарищество #RISC представляет новый специальный проект. Мы хотим рассказать о женщинах, работающих в отрасли ИБ. Они успешны и прекрасны в обычной и профессиональной жизни. Их объединяет профессионализм, способность противостоять обстоятельствам, упорство в достижении намеченных целей, но у каждой из них своя история.

Наша первая героиня – Олеся Шелестова. Олеся Шелестова: в Twitter про меня писали: «Блондинка продает пароли»

Наша вторая героиня — Анна Гольдштейн.

А я, пользуясь случаем передаю привет прекрасным женщинам, с которыми имел и имею честь трудиться: Мария Рыхлик, Светлана Максименко, Елена Радченко, Раиса Николаевна, Виктория Дмитриевна, Людмила Валентиновна, Лариса Голубкова, Мария Сидорова, Светлана Бедарева, Ирина Рощина, Марина Сухарева, Эльвира Перегудова, всем сотрудницам групп БИ/РСО организаций, ведомств и в/ч. Извиняюсь если кого не упомянул, но вас много и вы решаете ключевые задачи.

Видео

Видео-обращение #RISC2015 + подарки Товариществу

Друзья, еще несколько слов о нашем новогоднем проекте. На получение подарка имеют право все члены товарищества вступившие в нашу группу в Facebook до 29 декабря 2014 года. Подарок представляет собой конверт, который Вы получите по почте или лично в руки, с набором лицензий на программное обеспечение и скидок — Acronis True Image, Parallels Desktop, Adguard, Kaspersky Internet Security, 20% скидка на обучение в АИС. Для получения подарка необходимо написать письмо на mail@risc.expert в котором указать ФИО, ссылку на профиль в Facebook, электронную почту, контактный номер телефона и адрес доставки. ‪#‎RISC‬ ‪#‎RISC2015‬

Метод #49

zayacРасскажу сегодня немножко про один из методов, помогающих выявлять программные закладки. Данный метод я реализовал в макете еще в 97 году в системе «swan» и представлял в дипломе. У меня он был реализован для ПО без исходных текстов, но вы увидите, что он масштабируется на все уровни абстракции и годится для анализа с исходными текстами(это еще и повышает эффективность). Современную базу системы вы можете увидеть тут: http://www.cloudast.ru

логин пароль (test|test)

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

Итак. Как утрированно выглядит программа: как совокупность линейного кода и узлов ветвления.Метод 49_1

1,2,3,4 — команды условного или безусловного перехода (jmp,jz и т.п.). Узел 4 и блок кода, помеченный оранжевым — это тело программной закладки. Но мы никуда не торопимся.

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

  1. мы должны контролировать полностью выполнение программы
  2. сформировать профиль/карту кода программы
  3. отслеживать сегменты кода программы на предмет их контрольных сумм
  4. в процессе выполнения программы проводить остановку ее выполнения и анализировать команды которые только будут выполняться до следующего узла и останавливать программу после перехода, чтобы в карте покрытия указать реальный маршрут
  5. если на какой то команде ветвления отработали все варианты — данный узел убирается из карты маршрутов и в следующий раз программа на данном узле не останавливается

По сути первый запуск в таком режиме значительно замедляет программу. Однако, каждый прогон значительно ускоряет! Если изначально маршрутная карта, которая строится прямо в процессе выполнения кода, использует узел 2 (см. рис. выше) для остановки и анализа. То в последующем он не используется. По сути, за несколько часов набирается статистика, позволяющая оживить контролируемую программу до приемлемого уровня.

База узлов ветвления тает, быстродействие растет. Карта схлопывается до такого вида:Метод 49_2

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

Ну и маленький коллаж реализации 17-ти летней давности. Метод 49_3

Simply program password protection by SWAN

Совсем забыл про эту свою поделку 10-летней давности. Думал что совсем потерял. Но нет живет и работает!

  1. Назначение программы и основные возможности.
  • Программа «Simply program password protection» предназначена для простой и приятной установки пароля на запуск приложений пользователя.
  • Программа не претендует на полную защиту от хакеров, так как не использует средств шифрования и др. «хитрые штучки», однако для своих домашних и детей – любителей поиграть очень даже помогает, а если они нас обхитрят – напишите мне, и мы что ни будь придумаем!
  • Программа имеет приятный нестандартный интерфейс и поддерживает смену этого интерфейса, так чтобы Вы сами могли его поменять используя конфигуратор.
  • Программа не использует драйвера, службы, комбинирование с памятью и другие «навороты» с операционной системой, что повышает надежность программы. Есть и другие приятные моменты, например, программа автоматически передает защищаемой программе параметры командной строки, с которыми она запускается. Если Вы поставили защиту на популярный Вьювер файлов *.PDF «Adobe Reader 6.0», то все связи с файлами остаются. Если Вы откроете в файловом менеджере файл типа *.PDF то автоматически запустится связанная с этим расширением программа, но перед запуском спросит пароль, если пароль верный, то запустится «Adobe Reader 6.0» и откроет Ваш документ, как обычно.
  • Программа написана на языке ассемблер (masm32) для использования в среде Microsoft windows XP.
  1. Совместимость

Программа тестировалась на ПЭВМ типа IBM PC с операционной системой windows XP,2000 и Server 2003. Совместимость с другими ОС компании Микрософт не проверялась.

  1. Установка программы

Установка программы происходит привычным для Вас образом: – Вы запускаете дистрибутив и, никаких сложностей у Вас не возникнет. Единственная просьба, не устанавливайте программу на дискеты или диски где мало свободного места. Это вызвано не только объемом самой программы, но и размерами программ на которые Вы будете ставить защиту.

  1. Использование программы (Установка)

После установки программы вы можете ее запустить. На экране появится окно программы – установщика паролей следующего вида:

sppp1

Порядок работы следующий:

  • Нажимаем кнопку (ВЫБОР/SEL…) и в появившемся окне выбираем программу для защиты… и нажимаем (Открыть)sppp2
  • На экране появится окно… в котором появился путь к защищаемой программе. Если защищаемая программа запущена, то из нее нужно выйти. Теперь заполняем поле пароля (например, 123)sppp3
  • Теперь Вы можете выбрать внешний вид (skin) будущей программы нажав на кнопку (настрой/conf..). На экране появится программа конфигуратор, в которой Вы можете выбрать SKIN программы, например, …sppp4
  • Наконец нажимаем кнопку (Установка/Setup)
  • На экране должно появиться сообщение…sppp5

Это предупреждение будет появляться всегда, когда Вы устанавливаете пароль. Никто не идеален и, на всякий случай, что бы можно было восстановиться в случае сбоев, программа сохраняет в своем каталоге файл (OLD.EXE) – это старый файл защищаемой программы.

  • Следующим появится окно…sppp6

После нажатия на (ОК) программа заменит оригинальный файл на файл защищенный паролем. На этом установка завершена.

  1. Использование программы (Запуск защищенной программы)

При запуске защищенной программы непосредственно через ее иконку или файл менеджер (прямой запуск) появится следующее окно…sppp7

Порядок работы следующий:

  • В окошко пароля вводим этот самый пароль.
  • В окошко для параметров командной строки вводим параметры (если они необходимы).
  • Если хотим запустить приложение нажимаем кнопку (ВЫП…/RUN) и если пароль введен верно, то программа запустится.
  • Если хотим снять пароль с программы нажимаем кнопку (Restore/Восстановить) после нажатия мы увидим следующее сообщение…sppp8

Таким образом, программа указывает, где лежит восстановленная программа. Для полного восстановления имя файла нужно изменить на старое – удалить из имени (_OLD).

НЕ «ЧТО» А «КАК»

Что покупать из средств и систем защиты информации? Вопрос ТАК остро уже не стоит.

А вот КАК покупать — это тема статьи… Может Алексей Волков возьмется?…

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

Это я к чему? Если недавно чаще спрашивали «что брать», «как архитектуру строить», то сейчас чаще спрашивают «как покупать», через кого, по какой схеме по какому графику… Это, я считаю, забавная тенденция…

Как выжить при подготовке к формированию СМИБ

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

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

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

Читателю может показаться, что настоящая статья посвящена «бумажной» безопасности. «Знаем мы, что такое СМК, — гора стандартов, которые никто практически не выполняет! Это то же самое!» Да, коллеги, я знаю, что такое «мертвые СМК» и что для их выполнения и поддержания в актуальном состоянии нужен штат из десятков человек с функциями, не очевидными для бизнеса.

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

С суахили на квайгонский

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

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

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

Тут нужно сделать первое отступление. Дело в том, что любая информационная система представляется многомерной сущностью. В общем случае ИС включает информационную, техническую, организационную, юридическую и административную составляющие. Различные руководители, владельцы бизнес-процессов и сотрудники подразделений видят ИС по-своему, но вам надо свести все уровни представлений и сформировать общую картину с установкой четких границ ИС. Например, с точки зрения ИТ Customer Relationship Management (CRM) — это может быть СУБД, веб-сервер, файловый сервер, пул носителей, комплект системного и прикладного ПО. С точки зрения пользователей — ряд интегрированных веб-сервисов. С точки зрения бизнеса — элементы бизнес-процессов и т. д. С разных точек зрения и в зависимости от способов взаимодействия информационная система — вещь абстрактная, с размытым периметром. И только вы должны собрать этот пазл полностью для оценки ИС как многомерной сущности.

Вернемся к сбору данных. Я рекомендую его начинать не с уровня бизнеса, а с ИТ-подразделения и сформировать данные лучше всего в виде трехуровневых таблиц:

Первый уровень — перечень информационных систем (ИС) с указанием их наименования, владельца, ответственного за функционирование, пользователей, статуса и описания целей применения.

Второй уровень — должен представлять собой декомпозицию для каждой ИС на уровне сервисов и услуг с указанием наименования подсистемы, сервиса/услуги, ответственного, потребителей, числа пользователей, статуса сервиса и описания.

Третий уровень — декомпозиция для каждой ИС на техническом уровне с указанием места, типа, состава аппаратной и программной составляющих на системном и прикладном уровне и т.п .

Добавлю несколько замечаний. Уровень абстракции собираемой информации должен быть достаточным для понимания всеми сторонами, формирования требований к СОИБ, СМИБ, и их интерпретации для оценки рисков владельцами информации и руководителями бизнеса. Указание владельцев, ответственных и потребителей необходимо на уровне ролей/должностей/бизнес-единиц, а не ФИО конкретных специалистов.

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

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

Классификация и классики

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

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

Дать совет по оформлению данных, связанных с перечнем обрабатываемой информации отдельными подразделениями и бизнес-единицами, весьма сложно. Тут я вам посоветовать не осмелюсь. У каждого эти данные персонализированы, и не факт, что форма их представления одинакова для различных потребителей информационных систем. Единственное, что важно помнить, — собираемые сведения нужно периодически обновлять, и форма должна это учитывать.

Мы помним, что к топ-менеджменту нужно идти в последнюю очередь. Поэтому начинайте сбор данных с ИТ-подразделения. И тут надо сделать второе отступление и вспомнить К. Маркса.

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

Получается, что отдел БС также является потребителем ИС, но риски для них специфичные и в большей части связаны с обеспечением устойчивости, а не конфиденциальности. Рассматриваемая информационная система, опять же, функционирует не на пустом месте. Если на прикладном уровне ее обслуживает отдел БС, то на системном уровне, пожалуй, отдел ИТ! И, по сути, отдел БС — это потребитель услуг уже отдела ИТ в части сервисов для построения ИС. Но, опять же, отдел ИТ — потребитель своих же ИС на системном уровне, и это их орудия труда! И отдел ИТ так же оценивает риски со своей спецификой. Например, качество электроэнергии, сроки лицензий системного ПО, выход из строя аппаратной части и т.п.

Конфиденциальность не в чести

Закончив формирование сценариев нарушения ИБ и сбор оценок рисков у ИТ и топ-менеджеров в такой многоуровневой модели, вы получите 2–3 уровня рисков связных систем, которые после систематизации выдают более полную картину для обработки рисков в целом по компании. В данном случае мы не рассматриваем отношения с внешним миром (партнеры, подрядчики и т. д.). Нужно отметить, что многие ответы на вопрос «что и как защищать?» станут очевидны.

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

Не стоит увлекаться методами их оценки. В ряду качественных и количественных оценок существует множество методов и средств. Однако, уверяю вас, что два-три опытных эксперта выдают в результате оценки рисков вполне хорошие результаты. А вот для оценки эффективности мер – рекомендую применять автоматизированные средства которых на рынке вполне достаточно.

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

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

Списывать нужно с умом

Вернемся к построению СОИБ и СМИБ. При их формировании рекомендую воспользоваться лучшими практиками, но не слепо. К лучшим практикам относятся ISO 27001, СТО БР и другие стандарты. Но чтобы не утонуть и не обременять себя выполнением всех положений, которые могут вас не касаться, возьмите последние версии стандартов и адаптируйте их под нужды вашей компании. Просто возьмите стандарт и смело перепишите, вырезая лишнее и уточняя особенности вашей компании. Вовсе не нужно смотреть на стандарты как на иконы!

В результате у вас получится документ, содержащий базу для формирования трех высокоуровневых документов: политики ИБ компании, требований к СОИБ и требований к СМИБ.

В общем, структура документов СОИБ и СМИБ включает четыре уровня.

  1. Документы, определяющие корпоративную политику ИБ.
  2. Документы, формирующие частные политики ИБ.
  3. Документы, формирующие процедуры и правила по реализации частных политик.
  4. Документы, содержащие свидетельства выполненной деятельности в части ИБ.
  5. Как формировать базовые документы и внедрить их я постараюсь рассказать в следующий раз.

 

Методы контроля избыточного использования программным обеспечением ресурсов АС

В основе методов лежит возможность программного средства «SWAN» по контролю ППО в процессе его функционирования.

Метод 1 основан на анализе времени, затраченного контролируемым ППО на выполнение фрагментов программного кода. Преимущество метода заключается в том, что для его реализации не требуется модификация контролируемого ПО и среды его функционирования.

Метод включает в себя выполнение следующей последовательности действий:

  1. Для контролируемой программы формируется перечень точек контроля в его адресном пространстве.
  2. Проводится нагрузочное тестирование программы под контролем программного средства «SWAN».
  3. Программным средством «SWAN» проводится сбор и анализ данных о временных ресурсах затрачиваемых на выполнение фрагментов программного кода.
  4. Формируется профиль, содержащий контролируемые параметры.
  5. Данный профиль используется программным средством «SWAN» для выявления аномалий в процессе выполнения контролируемого ПО.

Метод 2 основан на периодическом получении и анализе данных о ресурсах, занятых контролируемой программой из среды функционирования.

Метод включает в себя выполнение следующей последовательности действий:

  1. Для контролируемой программы формируется перечень точек контроля в его адресном пространстве.
  2. Проводится нагрузочное тестирование программы под контролем программного средства «SWAN».
  3. Программным средством «SWAN» в заданных контрольных точках проводится сбор и анализ данных о ресурсах занятых контролируемой программой из среды функционирования.
  4. Формируется профиль, содержащий контролируемые параметры.
  5. Данный профиль используется программным средством «SWAN» для выявления аномалий в процессе выполнения контролируемого ПО.

Метод выявления неиспользуемых фрагментов программного кода, контролируемого ПО

В основе метода лежит возможность программного средства «SWAN» по контролю ППО в процессе его функционирования.

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

Выявление неиспользуемых фрагментов программного кода позволяет значительно сократить сроки и трудоемкость выявления возможных программных закладок и недостатков контролируемого ППО.

Метод включает в себя выполнение следующей последовательности действий:

  1. Для контролируемой программы формируется шаблон – незаполненная «карта покрытия» ее программного кода. Шаблон представляет собой «слепок» программного кода контролируемой программы.
  2. Проводится нагрузочное тестирование контролируемой программы с использованием программного средства «SWAN».
  3. В процессе выполнения контролируемой программы ПС «SWAN» проводит сравнение кода, выполняемого контролируемой программой с подготовленным шаблоном (эталоном) и формирует «карту покрытия».
  4. Проведение анализа полученной «карты покрытия» позволяет выявить неиспользуемые в процессе тестирования фрагменты программного кода, контролируемого ПО для их дальнейшего анализа.

Метод выявления и предотвращения выполнения опасного и недокументированного программного кода

В основе метода лежит возможность программного средства «SWAN» по контролю ППО в процессе его функционирования и оценке безопасности фрагментов программного кода до их выполнения.

Метод основан на функциональных возможностях программного средства «SWAN» по контролю выполнения программ с точностью до отдельной команды центрального процессора, контролю и изменению алгоритма выполнения программы, оценке безопасности кода программы до его выполнения.

Метод включает в себя выполнение следующей последовательности действий:

  1. Для контролируемой программы формируется перечень запрещенных функций. Данный перечень включает в себя набор программных конструкций, отображающих на уровне программного кода недопустимые функции контролируемой программы.
  2. Проводится нагрузочное тестирование программы под контролем программного средства «SWAN».
  3. Программным средством «SWAN» проводится сбор данных об алгоритме выполнения контролируемой программы.
  4. На основе перечня запрещенных функций и полученных данных об алгоритме выполнения контролируемой программы формируется уточненный профиль, содержащий контролируемые параметры и ограничения для программы:
    • запрет на передачу управления в определенные области памяти (область данных, стека и т.п.);
    • запрет на вызов или передачу управления в отдельные области программного кода, реализующего функционал, определенный как небезопасный или ограниченный по использованию;
    • запрет на использование отдельных функций ОС или библиотек;
    • и т.п.
  5. Данный профиль используется программным средством «SWAN» для выявления аномалий в процессе выполнения контролируемого ПО, анализа допустимости выполнения определенных профилем функций.
  6. В случае необходимости программным средством «SWAN» обеспечивается превентивное ограничение функционала, изменение алгоритма работы или блокирование отдельных функций контролируемой программы.

Данный метод позволяет осуществлять внутренний аудит контролируемой программы в процессе ее выполнения.

Данный метод обладает следующими преимуществами по сравнению с внешним аудитом, который заключается в формировании «ловушек» обращений программы к API функциям операционной системы:

  1. Обращения программы к API функциям операционной системы обнаруживаются до их непосредственного вызова.
  2. Метод позволяет выявлять и предотвращать попытки доступа контролируемой программы к ресурсам компьютера, осуществляемые в обход стандартных интерфейсов взаимодействия операционной системы.
  3. Метод исключает конфликты с антивирусными и другими средствами защиты информации, которые используют собственные механизмы контроля обращения программ к ресурсам операционной системы.
  4. Метод позволяет выявлять недокументированные функциональные возможности контролируемой программы, для которой не представлены исходные тексты.

Метод анализа безопасности исходников для Бизнес-языков

zayacРазница между анализом исходников «обычных» и «бизнес» языков программирования существенна.

Часто разработчики анализаторов исходников, разработанных на таких «бизнес-языках» заходят в тупик.

Этот тупик связан с вопросом: «Что же считать опасным куском кода?». И тут начинается кто во что горазд.

100% решения в решении данной задачи просто нет. Напоминаем, что безопасность — она относительно целевой системы и кусок кода в одном случае может считаться опасным в другой нет. Немного легче с «обычными» языками программирования. Их еще можно считать «системными». Ну просто потому, что есть с кого списывать😉

Сейчас предложу один из методов. С бизнес-языками и сложнее и проще одновременно.

Дело в том, что бизнес-языки чаще оперируют объектами, привязанными к бинесу а системные к объектам ОС.

Как же определить опасные места в коде бизнес-языков? Идти нужно от информационных объектов!

Составляется перечень информационных объектов. Проводится оценка критичности для каждого такого объекта. Например, объект содержащий ФИО сотрудника имеет критичность 4 по 5-ти балльной шкале. А ФИО генерального директора критичность =1. И по такому принципу объектам присваиваются уровни критичности. Такой же подход применяется к функциям бизнес-языка. Например функция «удаления объекта» может получить уровень критичности =1, а функция «определение типа данных» = 5.

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

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

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

При прочих трудностях — этот метод вполне ЧЕСТНЫЙ… Не так ли, коллеги😉

И да, помним правило: эффективность анализатора кода на языке ХХХ линейно зависит от уровня документирования правил безопасной разработки на языке ХХХ. Ибо скажите что искать в коде, а найти не проблема…

Товарищество RISC проведет свой первый семинар в Санкт-Петербурге

risc10030 сентября 2014 года товарищество RISC совместно с экспертами CyberSecurity PriceWaterhouseCoоpers (PwC) проведет в Санкт-Петербурге первый очный семинар «Роль человека в обеспечении информационной безопасности».
Место проведения: г. Санкт-Петербург, деловой комплекс BolloevCenter, пер. Гривцова, 4. Участие в семинаре RISC бесплатное, необходимо лишь пройти предварительную регистрацию тут.

Программа семинара:

09:30-10:00 — Встреча и регистрация участников семинара, приветственный кофе
10:00-10:10 — Открытие семинара, приветственное слово организаторов
10:10-10:50 — «Темные пятна в ИБ, где ваше слабое звено» Роман Чаплыгин, PWC
10:50-11:30 — «Повышение осведомленности пользователей по вопросам ИБ» Алексей Митюшов, «Аэроэкспресс»

11:30-12:00 — кофе-брейк

12:00-12:40 — «Проблемы взаимодействия ИБ и ИТ департаментов: взгляд со стороны ИБ» Юрий Шойдин, АРСИБ
12:40-13:20 — «ИБ и ИТ — казнить нельзя помиловать: взгляд со стороны ИТ» Алексей Широких, Сколковский институт науки и технологий («Сколтех»)

13:20-13:50 — кофе-брейк

13:50-14:30 — «Проблематика подбора специалистов по ИБ на российском рынке труда» Дмитрий Мананников, SPSR-express
14:30-15:10 — «Человек смотрящий» Андрей Прозоров, Infowatch
15:10-15.30 — Подведение итогов семинара