пятница, 28 ноября 2014 г.

Обновление Incident Manager 1.5

С 26 ноября пользователям системы R-Vision доступна новая версия модуля Incident Manager, включающая в себя следующие изменения:
  • Добавлена возможность импортировать данные по инцидентам из файлов KliKO.
  • В форму редактирования события включены поля даты и времени завершения события
  • Внесены коррективы в форму Сводного отчета по инцидентам информационной безопасности
  • Добавлена опция выбора страны нахождения организации
  • Добавлены дополнительные справочники для описания инцидентов в соответствии с требованиями РС БР ИББС-2.5-2014
  • Добавлена возможность создания отчета по зафиксированным событиям безопасности
  • Добавлена возможность редактировать описание возможного уровня ущерба от реализации инцидента в качественных величинах (Настройки > Справочники > Уровни ущерба)
  • Реализованы ряд улучшений по интерфейсу модуля, повышающих удобство работы с системой
  • Добавлена возможность добавлять в форму описания инцидентов собственные поля типа "выпадающий список"
  • Добавлена возможность создавать собственные справочники для описания инцидентов информационной безопасности
  • Добавлена возможность настройки количества и наименования возможных уровней критичности инцидентов (Настройки > Справочники > Уровни критичности)
Краткий видео-обзор новых возможностей модуля можно посмотреть по ссылке:

http://www.youtube.com/watch?v=LP4RqZGT0fw


понедельник, 8 сентября 2014 г.

Новые функциональные возможности в R-Vision: Incident Manager

С сегодняшнего дня пользователям R-Vision: Incident Manager доступно обновление, содержащее дополнительные функциональные возможности: 

1) Архивирование событий и инцидентов

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

2) Уведомление пользователей

Добавлено 2 вида уведомлений по электронной почте:
  • Уведомление ответственного за обработку инцидента и/или рабочей группы об изменения в инциденте. Данная опция (активируется отдельно) позволит участникам группы, занимающимся обработкой инцидента, быть в курсе всех происходящих изменений.
  • Уведомление по заданным правилам. Данная опция позволяет настроить уведомление определенных пользователей в случае добавления в систему событий или инцидентов, отвечающих определенным условиям (например, уровень критичности, принадлежность к определенному объекту инфраструктуры и проч.)

3) Общее журналирование всех действий в модуле

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


4)  Оптимизирована работа интерфейса и устранены некоторые недочеты в работе модуля

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


среда, 18 июня 2014 г.

Изменения в порядке оценки соответствия требованиям стандарта Банка России

Распоряжениями Банка России от 17 мая 2014 года № Р-399 и № Р-400 с 1 июня 2014 года введены в действие:
  • пятая редакция стандарта Банка России «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Общие положения» (регистрационный номер СТО БР ИББС-1.0-2014); 
  • четвертая редакция стандарта Банка России «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Методика оценки соответствия информационной безопасности организаций банковской системы Российской Федерации требованиям СТО БР ИББС-1.0-2014» (регистрационный номер СТО БР ИББС-1.2-2014); 
В данной публикации будут рассмотрены ключевые изменения в порядке оценки соответствия требованиям новой редакции стандарта Банка России. 

1) Изменилось количество требований, по которым проводится оценка соответствия

Стандарт претерпел довольно серьезные изменения как в количественном, так и в качественном плане. Количественные изменения представлены в таблице и на диаграмме ниже:

СТО БР 2010      
СТО БР 2014      
Изменение
Общее количество частных показателей
425
491
+ 66
Групповой показатель M1
20
21
+ 1
Групповой показатель M2
17
19
+ 2
Групповой показатель M3
32
54
+ 22
Групповой показатель M4
16
12
- 4
Групповой показатель M5
23
24
+ 1
Групповой показатель M6
14
16
+ 2
Групповой показатель M7
25
23
- 2
Групповой показатель M8
13
7
- 6
Групповой показатель M9
23
60
+ 37
Групповой показатель M10
5
14
+ 9
Групповой показатель M11
14
15
+ 1
Групповой показатель M12
7
6
- 1
Групповой показатель M13
12
11
- 1
Групповой показатель M14
6
6
-
Групповой показатель M15
21
22
+ 1
Групповой показатель M16
4
4
-
Групповой показатель M17
4
4
-
Групповой показатель M18
7
8
+ 1
Групповой показатель M19
9
8
- 1
Групповой показатель M20
14
13
- 1
Групповой показатель M21
8
6
- 2
Групповой показатель M22
9
11
+ 2
Групповой показатель M23
9
10
+ 1
Групповой показатель M24
10
8
- 2
Групповой показатель M25
8
9
+ 1
Групповой показатель M26
8
8
-
Групповой показатель M27
10
11
+ 1
Групповой показатель M28
14
14
-
Групповой показатель M29
4
4
-
Групповой показатель M30
27
28
+ 1
Групповой показатель M31
8
9
+ 1
Групповой показатель M32
12
13
+ 1
Групповой показатель M33
8
9
+ 1
Групповой показатель M34
4
4
-



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

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

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

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

3) Учет уточняющих вопросов заменен на учет результатов оценки степени выполнения требований 382-П 

Оценка групповых показателей М1 - М6 по-прежнему ведется по трем направлениям: БПТП, БИТП и ОЗПД, однако теперь для оценки по направлению ОЗПД не требуется оценивать и учитывать уточняющие вопросы (фактически они убраны из стандарта), а вот для оценки по направлению БПТП необходимо учитывать результаты актуальной оценки соответствия требованиям Положения Банка России № 382-П. 

Более подробная информация об изменения в стандартах Банка России, а также о подходах к обеспечению контроля за соответствием различных требований нормативных документов по информационной безопасности мы расскажем на вебинаре, который пройдет 19 июня в 11:00 по московскому времени. Подробности и ссылка для регистрации на вебинар тут - http://rvision.pro/event/vebinar-rvision-compliance-manager-1-0/.

пятница, 16 мая 2014 г.

Практический риск-менеджмент: часть 2 (подходы к оценке рисков)

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


На представленном рисунке вы можете видеть 4 возможных подхода к проведению оценки рисков, составленных с использованием 2х критериев: степени субъективности результатов оценки и сложности / ресурсоемкости проведения оценки. 

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

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

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

Тип 2. Оценка группой экспертов в предметной области

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

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

Тип 3. Использование принятых стандартов / моделей

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

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

Тип 4. Формальная оценка в соответствии с заданной методологией

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

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

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

понедельник, 7 апреля 2014 г.

Внедрение GRC. 12 советов из реальной практики

В данной заметке мы приводим фрагмент перевода статьи "12 tips for implementing GRC" с сайта http://www.csoonline.com, в котором специалисты по информационной безопасности, управлению рисками и соответствием требованиям делятся практическими советами по внедрению средств автоматизации процессов по общему управлению, риск-менеджменту и контролю соответствия (т.н. GRC-решений). 

Dave Notch, CISO, Thomson Reuters
  • Первый совет от меня: не пытайтесь сразу все сделать идеально, даже если кажется что вы знаете что вы хотите получить. Используйте итеративный подход. Это позволит в динамике оценивать достигнутый прогресс, а также требования заинтересованных сторон (которые зачастую могут меняться, либо могут быть не известны в начале проекта).
  • Будьте готовы "выкинуть" часть проделанной работы.  По мере того, как вы будете понимать потребности и желания тех, для кого предназначена внедряемая GRC-система, вам возможно придется отказаться от некоторых достигнутых результатов. Не принимайте это на свой счет, это нормально, это часть естественного процесса обучения и адаптации.
  • Наладьте нормальный процесс управления активами (это не имеет никакого отношения к выбору технического решения). До тех пор, пока у вас нет четкого представления о том, чем вы владеете, у вас не получится определить истинные причины возникающих проблем.  В своей компании мы разделили все активы на 3 категории и используем эту модель как призму для анализа всех имеющихся процессов и взаимосвязей. 
  • Сформируйте команду, состоящую из представителей юридического отдела, кадровой службы, ИТ и безопасности. Это позволит избежать ненужного дублирования в деятельности и разрабатываемых нормативных документах.  Такой подход в том числе облегчает жизнь, когда вам в силу служебной необходимости приходится вникать в вопросы из смежных областей.  А в условиях современных крупных компаний это не редкость. Совместная работа позволяет значительно проще обрабатывать подобные ситуации, когда они возникают. 
Kristen Knight, Privacy Director/Sr. Privacy Officer, NA Philips Electronics North America
  • Убедитесь что вы понимаете то влияние, которое окажет внедряемый продукт на операционную деятельность компании, до того как начнете проект. GRC-решения по своей сути ориентированы на использование широким кругом лиц. Даже деятельность топ-менеджмента компании может быть затронута внедряемым решением, поэтому убедитесь заранее что они готовы пройти через обучение и адаптацию процессов под новый инструментарий.  Если бы я полностью осознавала особенности продукта во время принятия решения о его покупке, то я бы поняла насколько проблематично будет  привлечь к обучению очень занятых топ-менеджеров. 
  • Автоматизация деятельности, реализуемая GRC-решениями, требует определенной зрелости существующих процессов в организации. Все сотрудники компании должны одинаково понимать каким образом будет использоваться инструментарий в их деятельности. В нашем случае это не сработало по причине того, что только небольшое количество лиц, ответственных за контроль соблюдения требований по защите персональных данных, обладали необходимой экспертизой для того чтобы корректно заполнить предоставляемый системой опросник. 
  • Будьте готовы к тому, что внедрение системы займет больше времени чем предполагалось. Но в тоже самое время не бойтесь "дернуть стоп-кран", если вы видете что все идет не так, как планировалось. В конечном итоге не стоит забывать, что основной задачей проекта является успешно работающая система.
Tom Malta, Senior Technology Risk Executive in financial services, including Goldman Sachs, Morgan Stanley, and BNY Mellon
  • Очень важно понимать, что в конечно итоге вы получаете инструмент, который нуждается во внимании и наполнении его необходимой информацией. Поэтому внедрение GRC-решения должно сопровождаться принятием необходимых политик и процедур. Если у вас нет собственных процедур, то бывает проще использовать встроенные процедуры, предлагаемые в продукте. 
  • Постоянно взаимодействуйте с сотрудниками и руководством, доносите до заинтересованных сторон сведения о том, на какой стадии в настоящее время находится проект. 
  • Внедрение GRC процессов не должно быть завязано исключительно на внедрении какого-то решения. Есть несколько простых вещей, которые вы можете реализовать очень быстро для того чтобы обеспечить поддержку инициативам в области управления рисками и соответствием требованиями, такие как, например, создание специализированных отчетов, привязанных к установленным в компании ключевым показателям (KPI). 
Jeff Bardin, veteran CISO from Investor's Bank & Trust, State Street Bank and Hanover Insurance Group
  • Проведите пилотное внедрение всех модулей продукта в качестве предварительного проекта по оценке применимости решения в вашей компании. Если пилотное внедрение окажется успешным, то можете смело переходить к полноценному внедрению. Как правило следование этому правилу позволит сократить итоговую стоимость внедрения, а также значительно быстрее добиться необходимого результата. 
  • Большинство GRC-решений поставляются вместе с некоторыми коннекторами, которые обеспечивают интеграцию с другими системами безопасности и источниками данных. Используйте эту интеграцию для повышения эффективности работы системы. 

среда, 19 марта 2014 г.

Практический риск-менеджмент: часть 1 (методики)

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

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

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

Надо отметить, что большинство из имеющихся нормативных и отраслевых требований (PCI DSS, СТО БР, 152-ФЗ, 382-П, ISO 27001 и др.) не предписывают необходимость использования для оценки рисков какой-то конкретной методологии, оставляя выбор на усмотрение специалистов в организации. 

ISO 27005:2011

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


NIST SP800-30 

Довольно объемный документ (95 стр.), в котором также представлены подходы не только к оценке рисков, но и к организации деятельности по управлению рисками ИБ на различных уровнях (от стратегического до прикладного на уровне отдельных информационных систем).  В отличие от ISO 27005 данный документ содержит более развернутые описания каждого из элементов,  а также рекомендации по применению на практике в различных ситуациях. 


РС БР ИББС-2.2

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


OCTAVE

Методика, разработанная институтом Software Engineering Institute (SEI) | Carnegie Mellon University, изначально ориентированная именно на прикладное использование для оценки рисков. С момента появления было выпущено 3 модификации:  OCTAVE, OCTAVE-S (версия для небольших организаций), OCTAVE: Allegro (ускоренный метод проведения оценки).  Документы содержат детальные пояснения по каждому шагу процесса оценки рисков, с примерами рабочих и отчетных документов, формулами расчета и пр.  

Ссылка на страницу с официальными материалами

F.A.I.R (Factor Analysis of Information Risk)

Методика, разработанная экспертом по информационной безопасности по имени Jack J. Jones, с целью формирования более системного и детального подхода к оценке показателей рисков.  Джека не устраивал классический подход в оценке риска, состоящий из сопоставления всего 2х величин: ущерб и вероятность.  В связи с этим в методике FAIR был сформирован ступенчатый процесс получения и сопоставления различных показателей описывающих все составляющие риска (возможности нарушителя, критичность уязвимостей, слабость защиты и пр.). 

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

Ссылка на описание методологии (материал из библиотеки ISM SYSTEMS)

RiskIT

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

Ссылка на страницу с официальными материалами

Harmonized TRA Methodology

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

пятница, 14 марта 2014 г.

Обновление модуля Incident Manager (выгрузка в ПТК ПСД, API, интеграция с почтой)

Уважаемые пользователи RVision, хотим сообщить вам о выходе очередного обновления для модуля Incident Manager.  Теперь вам становятся доступны следующие опции: 

1) Выгрузка в формате ПТК ПСД.  Теперь сформированный отчет можно перевести в формат программы ПТК ПСД, что позволит исключить ручной набор данных для тех организаций, которые используют ПТК ПСД для предоставления отчетности в Центральный Банк по форме 0403203.


2) Удобная навигация по отчету.  Теперь вы можете прямо в сформированном отчете выбрать инцидент и перейти на соответствующую форму для уточнения данных по инциденту. 


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


4) Открытый API для интеграции с другими системами. API предоставляет возможность разработчикам программными средствами получать и записывать данные в базу данных Incident Manager.

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

пятница, 14 февраля 2014 г.

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

Молодые, энергичные, студенты и студентки, 

мы ищем 1-2 человек для прохождения краткосрочной (преддипломной) практики в коллективе молодой, инновационной компании ISM SYSTEMS. 

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

Нас в первую очередь интересуют конечно же студенты последних курсов, изучающих информационную безопасность или смежные специальности. Свое резюме напраляйте нам на электронную почту: info@ismsys.ru

P.S. На всякий случай оговоримся (хотя это обычно подразумевается), что в рамках подобной практики никакой финансовой компенсации не предусмотрено.

четверг, 13 февраля 2014 г.

Обновление RVision: версия 1.3 модуля Incident Manager

Уважаемые пользователи RVision, хотим сообщить вам о выходе новой версии (1.3) модуля Incident Manager. Мы довольно серьезно переработали интерфейс работы с системой, а также добавили ряд важных улучшений, которые позволят вам значительно облегчить ведение учета инцидентов информационной безопасности.

Среди ключевых изменений: 

1) Абсолютно новый интерфейс добавления информации по инциденту. Интерфейс допускает кастомизацию (добавление новых полей), одновременную работу с несколькими инцидентами, удобное отображение параметров в виде списков.


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


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


4) Удобная функция выбора региона, в котором выявлен инцидент.   Теперь данные по региону можно либо указать вручную, либо выбрать из справочника, составленного на основании официальных публикаций справочника ОКАТО.


5) Отчетность по обновленной форме 0403203 (включая выгрузку в Kliko). На основании данных по инцидентам теперь есть возможность получить выгрузку по форме 0403203, введенной в январе 2014 г.  Отчет может быть скачан в форматах DOC, PDF, KLIKO. Выгрузка в формате ПТК ПСД пока не реализована, но появится в ближайшее время.


6) Добавление инцидентов на основании шаблонов. Данная функция позволяет упростить ввод однотипной информации по инцидентам. С помощью шаблона вы можете заранее заполнить любые поля данными, которые будут автоматически внесены при добавлении инцидента.


7) Дополнительные изменения и улучшения. В общей сложности в рамках обновления было внесено более 80 изменений.


Обновление ! 

Далее мы публикуем запись вебинара от 13 февраля 2014 г., в рамках которого мы представили основные подходы к организации деятельности по управлению инцидентами информационной безопасности, обсудили новую форму отчетности ЦБ по инцидентам, а также возможности модуля Incident Manager по учету инцидентов и подготовке соответствующей отчетности.

четверг, 6 февраля 2014 г.

Обновление RVision: версия 2.3 модуля Risk Manager

Уважаемые пользователи RVision, хотим сообщить вам о выходе новой версии (2.3) модуля Risk Manager. Мы постарались учесть поступившие к нам пожелания пользователей, а также реализовать ряд улучшений, которые повысят удобство работы с модулем и упростят работу по управлению рисками информационной безопасности.

Среди ключевых изменений: 

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


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


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



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


5) Просмотр количественного уровня рисков. При просмотре перечня рисков теперь есть возможность просматривать не только качественное значение уровня рисков, но и их количественное выражение. 


6) Улучшение отчетности. Формирование детализированного реестра рисков теперь возможно в отношении выбранного перечня информационных систем. Помимо этого внесены корректировки в ряд отчетных документов: Сводный реестр рисков, Детализированный реестр рисков, План обработки рисков.


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


Кроме указанных изменений мы оптимизировали работу интерфейса системы, а также внесли ряд небольших улучшений (всего более 70 доработок).