Кибер риски как пишется

Всего найдено: 20

Как правильно пишется «кибер клуб»?

Ответ справочной службы русского языка

Пишется слитно: киберклуб.

Добрый день! Подскажите, пожалуйста, все ли в порядке здесь с пунктуацией: «Например, если вы занимаетесь IT-решениями в области кибербезопасности, и ваши клиенты относятся к малому бизнесу – расскажите об опасности отсутствия общественного Wi-Fi». Спасибо!

Ответ справочной службы русского языка

Запятая перед и ваши не требуется: Например, если вы занимаетесь IT-решениями в области кибербезопасности и ваши клиенты относятся к малому бизнесу – расскажите об опасности отсутствия общественного Wi-Fi. Вместо тире можно поставить запятую.

Как правильно: «киберспортивные турниры проходят по следующим дисциплинам» или «в дисциплинах»?

Ответ справочной службы русского языка

Оба варианта возможны.

Уточните пожалуйста правильное русское написание слова опен-спейс (open space), открытого офисного пространства. Через дефис или раздельно?

Ответ справочной службы русского языка

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

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

Ответ справочной службы русского языка

В числе статей по истории и историческим наукам, опубликованных на сайте проекта «Киберленинка», мы нашли несколько подобных примеров. Следовательно, запрета на использование вопросительного знака в конце названий научных статей нет.

Уважаемая «Грамота», снова прошу помощи. Как правильно написать прилагательное «кибер_физический»? Слитно или через дефис? По сути, это две разнородные характеристики, поэтому хочется поставить дефис. Но есть правило, что в сложных словах первая часть «кибер» пишется слитно. Помогите разобраться!

Ответ справочной службы русского языка

Словарной фиксации нет. Корректно слитное написание.

Здравствуйте! Обоснованно ли я употребил двойное тире? С развитием технологий в медицине и кибернетике главная цель образования – помочь человеку реализоваться в жизни – станет более доступна.

Ответ справочной службы русского языка

Такой вариант пунктуационного оформления корректен.

Скажите, есть слова с частью «кибер«. Но почти нет правил, которые говорили бы о правописании её со словами. В научных статьях встречается «киберустройство», в иных статьях есть «кибер-нож». Где-то слитно, где-то раздельно, где-то через дефис. При переводе статьи возник вопрос: «А как будет правильно: кибер ядро, кибер-ядро или киберядро?»

Ответ справочной службы русского языка

Сложные слова с первой частью кибер— пишутся слитно. Правильно: киберядро.

Здравствуйте. Слово «кибератака» пишется слитно, а «киберсоставляющая » тоже? «…в последние годы к ним подключается и киберсоставляющая».

Ответ справочной службы русского языка

Первая часть сложных слов кибер… пишется слитно: киберсоставляющая.

кибер-угроза или киберугроза? В различных источниках, в ом числе и нормативно-правовых, написание отличается.

Ответ справочной службы русского языка

Первая часть сложных слов кибер… пишется слитно: киберугроза.

Здравствуйте.
На сайте нашей администрации В разделе Новости в теме «Безопасный интернет» прочитал такую фразу: В Российской Федерации расширен перечень информаций, распространение которых в сети Интернет признано незаконным.
На мое замечание о неправильности написания слова информациЙ, пресс-служба ответила, что по правилам русского языка допускается Й в конце данного слова.
Но я считаю, что в данном случае допущена ошибка. Рассудите.
С уважением.
Геннадий

Ответ справочной службы русского языка

Слово информация многозначное. Приведем его значения.

ИНФОРМАЦИЯ, -и; ж. [лат. informatio — разъяснение, изложение]
1. =Информирование. Сообщить в порядке информации. Средства массовой информации
(о газетах, радио, телевидении).
2. Сообщение о состоянии дел где-л., о каких-л. событиях, процессах и т.п. Снабдить нужной информацией. Дать подробную информацию о происшедшем.
3. Спец. Сведения о положении дел в окружающем мире, его свойствах, протекающих в нём процессах и т.п. Поток информации. Теория информации
(раздел кибернетики, изучающий способы измерения и передачи информации). Генетическая и.
(заложенные в наследственных структурах сведения о его строении и функциях).

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

Новые слова такие, как киберпреступность, кибермашина, киберпространство пишутся слитно, а как написать кибер-очкарик (для названия статьи) — слитно или через дефис?

Ответ справочной службы русского языка

Верно: киберочкарик.

Уважаемая редакция! В орфографическом словаре указано, что кибер— — составная часть сложных слов, которая пишется слитно. А как тогда быть с кибер-рисками? Киберриск смотрится совсем неприглядно.

Ответ справочной службы русского языка

И в этом случае правильно слитное написание: киберриск.

Уважаемые сотрудники «Грамоты»! Как правильно написать: кибер лютики-цветочки или киберлютики-цветочки? Или еще как? Спасибо.

Ответ справочной службы русского языка

Орфографически правильно: кибер-лютики-цветочки.

Киберобщение или кибер-общение? Вообще-то по правилам «кибер«, являющаяся частью слова, пишется слитно, но в данном случае слово начинается с гласной…

Ответ справочной службы русского языка

Тем не менее правильно слитное написание: киберобщение.

Киберугрозы в период пандемии взлетели на новый уровень. Переход компаний в онлайн, а сотрудников — на удаленку, пройденный в «пожарном» режиме, открыл новые просторы для мошенников, хакеров и прочих злоумышленников.

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

Хайп как угроза

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

Начнем с мифов. Киберриски — это не новая реальность, созданная ковидом. Они существовали еще в 80-х и приобрели новое качество с развитием интернета и онлайн-сервисов.

В банковском секторе риски, связанные со счетами, переводами, пластиковыми картами и остальным финансовым трафиком успешно страхуются во всем мире уже не одно десятилетие. Как и информационные утечки, ЧП с базами данных и т. д. Крупные компенсации тоже есть. Например, «Ингосстрах» выплатил по одному из таких случаев 7 млн долларов.

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

Из-за пандемии мировой интерес к таким страховкам возрос на порядки (если говорить о России, то рост спроса здесь скромнее, но это все равно увеличение в разы).

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

Киберриски, которые реально можно застраховать:

1. Целенаправленная (таргетированная) компьютерная атака
2. Внедрение вредоносных компьютерных программ (вирусов), разработанных третьими лицами
3. Внезапные и непредвиденные технические сбои в работе ПО и/или «железа»
4. Непреднамеренные ошибки персонала, которые привели к таким сбоям

Последствия, которые тоже страхуются:

1. Утрата электронных данных и/или ПО
2. Хищение интеллектуальной собственности в электронной форме
3. Неправомерное использование вычислительных ресурсов третьими лицами (спам-рассылки, участие в botnet-сети от вашего имени, майнинг и др.)
4. Перерывы в коммерческой (производственной) деятельности из-за сбоев информационной системы или недоступности электронных данных
5. Кибервымогательство
6. Хищение денег/ценных бумаг в электронной форме со счетов третьими лицами
7. Претензии третьих лиц (нарушение конфиденциальности, разглашение персональных данных и т. д.) Сюда же входит ответственность за ущерб их жизни и здоровью
8. Гибель или повреждение компьютерного, производственного оборудования, а также готовой продукции, в результате реализации любого из застрахованных рисков.

Список с подробностями есть у нас на сайте.

Суть работы с киберрисками

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

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

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

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

Еще раз кратко:

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

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

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

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

Information technology risk, IT risk, IT-related risk, or cyber risk is any risk related to information technology.^[1] While information has long been appreciated as a valuable and important asset, the rise of the knowledge economy and the Digital Revolution has led to organizations becoming increasingly dependent on information, information processing and especially IT. Various events or incidents that compromise IT in some way can therefore cause adverse impacts on the organization’s business processes or mission, ranging from inconsequential to catastrophic in scale.

Assessing the probability or likelihood of various types of event/incident with their predicted impacts or consequences, should they occur, is a common way to assess and measure IT risks.^[2] Alternative methods of measuring IT risk typically involve assessing other contributory factors such as the threats, vulnerabilities, exposures, and asset values.^[3][4]

Definitions[edit]

ISO[edit]

IT risk: the potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization. It is measured in terms of a combination of the probability of occurrence of an event and its consequence.^[5]

Committee on National Security Systems[edit]

The Committee on National Security Systems of United States of America defined risk in different documents:

• From CNSS Instruction No. 4009 dated 26 April 2010^[6] the basic and more technical focused definition:

  Risk – Possibility that a particular threat will adversely impact an IS by exploiting a particular vulnerability.

• National Security Telecommunications and Information Systems Security Instruction (NSTISSI) No. 1000,^[7] introduces a probability aspect, quite similar to NIST SP 800-30 one:

  Risk – A combination of the likelihood that a threat will occur, the likelihood that a threat occurrence will result in an adverse impact, and the severity of the resulting impact

National Information Assurance Training and Education Center defines risk in the IT field as:^[8]

1. The loss potential that exists as the result of threat-vulnerability pairs. Reducing either the threat or the vulnerability reduces the risk.
2. The uncertainty of loss expressed in terms of probability of such loss.
3. The probability that a hostile entity will successfully exploit a particular telecommunications or COMSEC system for intelligence purposes; its factors are threat and vulnerability.
4. A combination of the likelihood that a threat shall occur, the likelihood that a threat occurrence shall result in an adverse impact, and the severity of the resulting adverse impact.
5. the probability that a particular threat will exploit a particular vulnerability of the system.

NIST[edit]

Many NIST publications define risk in IT context in different publications: FISMApedia^[9] term^[10] provide a list. Between them:

• According to NIST SP 800-30:^[11]

  Risk is a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization.

• From NIST FIPS 200^[12]

  Risk – The level of impact on organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals resulting from the operation of an information system given the potential impact of a threat and the likelihood of that threat occurring.

NIST SP 800-30^[11] defines:

IT-related risk

The net mission impact considering:

1. the probability that a particular threat-source will exercise (accidentally trigger or intentionally exploit) a particular information system vulnerability and
2. the resulting impact if this should occur. IT-related risks arise from legal liability or mission loss due to:
   1. Unauthorized (malicious or accidental) disclosure, modification, or destruction of information
   2. Unintentional errors and omissions
   3. IT disruptions due to natural or man-made disasters
   4. Failure to exercise due care and diligence in the implementation and operation of the IT system.

Risk management insight[edit]

IT risk is the probable frequency and probable magnitude of future loss.^[13]

ISACA[edit]

ISACA published the Risk IT Framework in order to provide an end-to-end, comprehensive view of all risks related to the use of IT. There,^[14] IT risk is defined as:

The business risk associated with the use, ownership, operation, involvement, influence and adoption of IT within an enterprise

According to Risk IT,^[14] IT risk has a broader meaning: it encompasses not just only the negative impact of operations and service delivery which can bring destruction or reduction of the value of the organization, but also the benefitvalue enabling risk associated to missing opportunities to use technology to enable or enhance business or the IT project management for aspects like overspending or late delivery with adverse business impact

Measuring IT risk[edit]

You can’t effectively and consistently manage what you can’t measure, and you can’t measure what you haven’t defined.^[13][15]

Measuring IT risk (or cyber risk) can occur at many levels. At a business level, the risks are managed categorically. Front line IT departments and NOC’s tend to measure more discrete, individual risks. Managing the nexus between them is a key role for modern CISO’s.

When measuring risk of any kind, selecting the correct equation for a given threat, asset, and available data is an important step. Doing so is subject unto itself, but there are common components of risk equations that are helpful to understand.

There are four fundamental forces involved in risk management, which also apply to cybersecurity. They are assets, impact, threats, and likelihood. You have internal knowledge of and a fair amount of control over assets, which are tangible and intangible things that have value. You also have some control over impact, which refers to loss of, or damage to, an asset. However, threats that represent adversaries and their methods of attack are external to your control. Likelihood is the wild card in the bunch. Likelihoods determine if and when a threat will materialize, succeed, and do damage. While never fully under your control, likelihoods can be shaped and influenced to manage the risk.
^[16]

Mathematically, the forces can be represented in a formula such as: where p() is the likelihood that a Threat will materialize/succeed against an Asset, and d() is the likelihood of various levels of damage that may occur.^[17]

The field of IT risk management has spawned a number of terms and techniques which are unique to the industry. Some industry terms have yet to be reconciled. For example, the term vulnerability is often used interchangeably with likelihood of occurrence, which can be problematic. Often encountered IT risk management terms and techniques include:

Information security event

An identified occurrence of a system, service or network state indicating a possible breach of information security policy or failure of safeguards, or a previously unknown situation that may be security relevant.^[5]

Occurrence of a particular set of circumstances^[18]

• The event can be certain or uncertain.
• The event can be a single occurrence or a series of occurrences. :(ISO/IEC Guide 73)

Information security incident

is indicated by a single or a series of unwanted information security events that have a significant probability of compromising business operations and threatening information security^[5]

An event [G.11] that has been assessed as having an actual or potentially adverse effect on the security or performance of a system.^[19]

Impact^[20]

The result of an unwanted incident [G.17].(ISO/IEC PDTR 13335-1)

Consequence^[21]

Outcome of an event [G.11]

• There can be more than one consequence from one event.
• Consequences can range from positive to negative.
• Consequences can be expressed qualitatively or quantitatively (ISO/IEC Guide 73)

The risk R is the product of the likelihood L of a security incident occurring times the impact I that will be incurred to the organization due to the incident, that is:^[22]

R = L × I

The likelihood of a security incident occurrence is a function of the likelihood that a threat appears and the likelihood that the threat can successfully exploit the relevant system vulnerabilities.

The consequence of the occurrence of a security incident are a function of likely impact that the incident will have on the organization as a result of the harm the organization assets will sustain. Harm is related to the value of the assets to the organization; the same asset can have different values to different organizations.

So R can be function of four factors:

• A = Value of the assets
• T = the likelihood of the threat
• V = the nature of vulnerability i.e. the likelihood that can be exploited (proportional to the potential benefit for the attacker and inversely proportional to the cost of exploitation)
• I = the likely impact, the extent of the harm

If numerical values (money for impact and probabilities for the other factors), the risk can be expressed in monetary terms and compared to the cost of countermeasures and the residual risk after applying the security control. It is not always practical to express this values, so in the first step of risk evaluation, risk are graded dimensionless in three or five steps scales.

OWASP proposes a practical risk measurement guideline^[22] based on:

• Estimation of Likelihood as a mean between different factors in a 0 to 9 scale:
  • Threat agent factors
    • Skill level: How technically skilled is this group of threat agents? No technical skills (1), some technical skills (3), advanced computer user (4), network and programming skills (6), security penetration skills (9)
    • Motive: How motivated is this group of threat agents to find and exploit this vulnerability? Low or no reward (1), possible reward (4), high reward (9)
    • Opportunity: What resources and opportunity are required for this group of threat agents to find and exploit this vulnerability? full access or expensive resources required (0), special access or resources required (4), some access or resources required (7), no access or resources required (9)
    • Size: How large is this group of threat agents? Developers (2), system administrators (2), intranet users (4), partners (5), authenticated users (6), anonymous Internet users (9)
  • Vulnerability Factors: the next set of factors are related to the vulnerability involved. The goal here is to estimate the likelihood of the particular vulnerability involved being discovered and exploited. Assume the threat agent selected above.
    • Ease of discovery: How easy is it for this group of threat agents to discover this vulnerability? Practically impossible (1), difficult (3), easy (7), automated tools available (9)
    • Ease of exploit: How easy is it for this group of threat agents to actually exploit this vulnerability? Theoretical (1), difficult (3), easy (5), automated tools available (9)
    • Awareness: How well known is this vulnerability to this group of threat agents? Unknown (1), hidden (4), obvious (6), public knowledge (9)
    • Intrusion detection: How likely is an exploit to be detected? Active detection in application (1), logged and reviewed (3), logged without review (8), not logged (9)
• Estimation of Impact as a mean between different factors in a 0 to 9 scale
  • Technical Impact Factors; technical impact can be broken down into factors aligned with the traditional security areas of concern: confidentiality, integrity, availability, and accountability. The goal is to estimate the magnitude of the impact on the system if the vulnerability were to be exploited.
    • Loss of confidentiality: How much data could be disclosed and how sensitive is it? Minimal non-sensitive data disclosed (2), minimal critical data disclosed (6), extensive non-sensitive data disclosed (6), extensive critical data disclosed (7), all data disclosed (9)
    • Loss of integrity: How much data could be corrupted and how damaged is it? Minimal slightly corrupt data (1), minimal seriously corrupt data (3), extensive slightly corrupt data (5), extensive seriously corrupt data (7), all data totally corrupt (9)
    • Loss of availability How much service could be lost and how vital is it? Minimal secondary services interrupted (1), minimal primary services interrupted (5), extensive secondary services interrupted (5), extensive primary services interrupted (7), all services completely lost (9)
    • Loss of accountability: Are the threat agents’ actions traceable to an individual? Fully traceable (1), possibly traceable (7), completely anonymous (9)
  • Business Impact Factors: The business impact stems from the technical impact, but requires a deep understanding of what is important to the company running the application. In general, you should be aiming to support your risks with business impact, particularly if your audience is executive level. The business risk is what justifies investment in fixing security problems.
    • Financial damage: How much financial damage will result from an exploit? Less than the cost to fix the vulnerability (1), minor effect on annual profit (3), significant effect on annual profit (7), bankruptcy (9)
    • Reputation damage: Would an exploit result in reputation damage that would harm the business? Minimal damage (1), Loss of major accounts (4), loss of goodwill (5), brand damage (9)
    • Non-compliance: How much exposure does non-compliance introduce? Minor violation (2), clear violation (5), high-profile violation (7)
    • Privacy violation: How much personally identifiable information could be disclosed? One individual (3), hundreds of people (5), thousands of people (7), millions of people (9)
  • If the business impact is calculated accurately use it in the following otherwise use the Technical impact
• Rate likelihood and impact in a LOW, MEDIUM, HIGH scale assuming that less than 3 is LOW, 3 to less than 6 is MEDIUM, and 6 to 9 is HIGH.
• Calculate the risk using the following table

IT risk management[edit]

IT risk management can be considered a component of a wider enterprise risk management system.^[23]

The establishment, maintenance and continuous update of an information security management system (ISMS) provide a strong indication that a company is using a systematic approach for the identification, assessment and management of information security risks.^[24]

Different methodologies have been proposed to manage IT risks, each of them divided into processes and steps.^[25]

The Certified Information Systems Auditor Review Manual 2006 produced by ISACA, an international professional association focused on IT Governance, provides the following definition of risk management: «Risk management is the process of identifying vulnerabilities and threats to the information resources used by an organization in achieving business objectives, and deciding what countermeasures, if any, to take in reducing risk to an acceptable level, based on the value of the information resource to the organization.»^[26]

The NIST Cybersecurity Framework encourages organizations to manage IT risk as part the Identify (ID) function:^[27][28]

Risk Assessment (ID.RA): The organization understands the cybersecurity risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals.

• ID.RA-1: Asset vulnerabilities are identified and documented
• ID.RA-2: Cyber threat intelligence and vulnerability information is received from information sharing forums and source
• ID.RA-3: Threats, both internal and external, are identified and documented
• ID.RA-4: Potential business impacts and likelihoods are identified
• ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk
• ID.RA-6: Risk responses are identified and prioritized

Risk Management Strategy (ID.RM): The organization’s priorities, constraints, risk tolerances, and assumptions are established and used to support operational risk decisions.

• ID.RM-1: Risk management processes are established, managed, and agreed to by organizational stakeholders
• ID.RM-2: Organizational risk tolerance is determined and clearly expressed
• ID.RM-3: The organization’s determination of risk tolerance is informed by its role in critical infrastructure and sector specific risk analysis

IT risk laws and regulations[edit]

In the following a brief description of applicable rules organized by source.^[29]

OECD[edit]

OECD issued the following:

• Organisation for Economic Co-operation and Development (OECD) Recommendation of the Council concerning guidelines governing the protection of privacy and trans-border flows of personal data (23 September 1980)
• OECD Guidelines for the Security of Information Systems and Networks: Towards a Culture of Security (25 July 2002). Topic: General information security. Scope: Non binding guidelines to any OECD entities (governments, businesses, other organisations and individual users who develop, own, provide, manage, service, and use information systems and networks). The OECD Guidelines state the basic principles underpinning risk management and information security practices. While no part of the text is binding as such, non-compliance with any of the principles is indicative of a serious breach of RM/RA good practices that can potentially incur liability.

European Union[edit]

The European Union issued the following, divided by topic:

• Privacy
  • Regulation (EC) No 45/2001 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data provide an internal regulation, which is a practical application of the principles of the Privacy Directive described below. Furthermore, article 35 of the Regulation requires the Community institutions and bodies to take similar precautions with regard to their telecommunications infrastructure, and to properly inform the users of any specific risks of security breaches.
  • Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data require that any personal data processing activity undergoes a prior risk analysis in order to determine the privacy implications of the activity, and to determine the appropriate legal, technical and organisation measures to protect such activities;is effectively protected by such measures, which must be state of the art keeping into account the sensitivity and privacy implications of the activity (including when a third party is charged with the processing task) is notified to a national data protection authority, including the measures taken to ensure the security of the activity. Furthermore, article 25 and following of the Directive requires Member States to ban the transfer of personal data to non-Member States, unless such countries have provided adequate legal protection for such personal data, or barring certain other exceptions.
  • Commission Decision 2001/497/EC of 15 June 2001 on standard contractual clauses for the transfer of personal data to third countries, under Directive 95/46/EC; and Commission Decision 2004/915/EC of 27 December 2004 amending Decision 2001/497/EC as regards the introduction of an alternative set of standard contractual clauses for the transfer of personal data to third countries. Topic: Export of personal data to third countries, specifically non-E.U. countries which have not been recognised as having a data protection level that is adequate (i.e. equivalent to that of the E.U.). Both Commission Decisions provide a set of voluntary model clauses which can be used to export personal data from a data controller (who is subject to E.U. data protection rules) to a data processor outside the E.U. who is not subject to these rules or to a similar set of adequate rules.
  • International Safe Harbor Privacy Principles (see below USA and International Safe Harbor Privacy Principles )
  • Directive 2002/58/EC of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector
• National Security
  • Directive 2006/24/EC of 15 March 2006 on the retention of data generated or processed in connection with the provision of publicly available electronic communications services or of public communications networks and amending Directive 2002/58/EC (‘Data Retention Directive’). Topic: Requirement for the providers of public electronic telecommunications service providers to retain certain information for the purposes of the investigation, detection and prosecution of serious crime
  • Council Directive 2008/114/EC of 8 December 2008 on the identification and designation of European critical infrastructures and the assessment of the need to improve their protection. Topic: Identification and protection of European Critical Infrastructures. Scope: Applicable to Member States and to the operators of European Critical Infrastructure (defined by the draft directive as ‘critical infrastructures the disruption or destruction of which would significantly affect two or more Member States, or a single Member State if the critical infrastructure is located in another Member State. This includes effects resulting from cross-sector dependencies on other types of infrastructure’). Requires Member States to identify critical infrastructures on their territories, and to designate them as ECIs. Following this designation, the owners/operators of ECIs are required to create Operator Security Plans (OSPs), which should establish relevant security solutions for their protection
• Civil and Penal law
  • Council Framework Decision 2005/222/JHA of 24 February 2005 on attacks against information systems. Topic: General decision aiming to harmonise national provisions in the field of cyber crime, encompassing material criminal law (i.e. definitions of specific crimes), procedural criminal law (including investigative measures and international cooperation) and liability issues. Scope: Requires Member States to implement the provisions of the Framework Decision in their national legal frameworks. Framework decision is relevant to RM/RA because it contains the conditions under which legal liability can be imposed on legal entities for conduct of certain natural persons of authority within the legal entity. Thus, the Framework decision requires that the conduct of such figures within an organisation is adequately monitored, also because the Decision states that a legal entity can be held liable for acts of omission in this regard.

Council of Europe[edit]

• Council of Europe Convention on Cybercrime, Budapest, 23.XI.2001, European Treaty Series-No. 185. Topic: General treaty aiming to harmonise national provisions in the field of cyber crime, encompassing material criminal law (i.e. definitions of specific crimes), procedural criminal law (including investigative measures and international cooperation), liability issues and data retention. Apart from the definitions of a series of criminal offences in articles 2 to 10, the Convention is relevant to RM/RA because it states the conditions under which legal liability can be imposed on legal entities for conduct of certain natural persons of authority within the legal entity. Thus, the Convention requires that the conduct of such figures within an organisation is adequately monitored, also because the Convention states that a legal entity can be held liable for acts of omission in this regard.

United States[edit]

United States issued the following, divided by topic:

• Civil and Penal law
  • Amendments to the Federal Rules of Civil Procedure with regard to electronic discovery. Topic: U.S. Federal rules with regard to the production of electronic documents in civil proceedings. The discovery rules allow a party in civil proceedings to demand that the opposing party produce all relevant documentation (to be defined by the requesting party) in its possession, so as to allow the parties and the court to correctly assess the matter. Through the e-discovery amendment, which entered into force on 1 December 2006, such information may now include electronic information. This implies that any party being brought before a U.S. court in civil proceedings can be asked to produce such documents, which includes finalised reports, working documents, internal memos and e-mails with regard to a specific subject, which may or may not be specifically delineated. Any party whose activities imply a risk of being involved in such proceedings must therefore take adequate precautions for the management of such information, including the secure storage. Specifically: The party must be capable of initiating a ‘litigation hold’, a technical/organisational measure which must ensure that no relevant information can be modified any longer in any way. Storage policies must be responsible: while deletion of specific information of course remains allowed when this is a part of general information management policies (‘routine, good-faith operation of the information system’, Rule 37 (f)), the wilful destruction of potentially relevant information can be punished by extremely high fines (in one specific case of 1.6 billion US$). Thus, in practice, any businesses who risk civil litigation before U.S. courts must implement adequate information management policies, and must implement the necessary measures to initiate a litigation hold.
• Privacy
  • California Consumer Privacy Act (CCPA)
  • California Privacy Rights Act (CPRA)
  • Gramm–Leach–Bliley Act (GLBA)
  • USA PATRIOT Act, Title III
  • Health Insurance Portability and Accountability Act (HIPAA) From an RM/RA perspective, the Act is particularly known for its provisions with regard to Administrative Simplification (Title II of HIPAA). This title required the U.S. Department of Health and Human Services (HHS) to draft specific rule sets, each of which would provide specific standards which would improve the efficiency of the health care system and prevent abuse. As a result, the HHS has adopted five principal rules: the Privacy Rule, the Transactions and Code Sets Rule, the Unique Identifiers Rule, the Enforcement Rule, and the Security Rule. The latter, published in the Federal Register on 20 February 2003 (see: http://www.cms.hhs.gov/SecurityStandard/Downloads/securityfinalrule.pdf), is specifically relevant, as it specifies a series of administrative, technical, and physical security procedures to assure the confidentiality of electronic protected health information. These aspects have been further outlined in a set of Security Standards on Administrative, Physical, Organisational and Technical Safeguards, all of which have been published, along with a guidance document on the basics of HIPAA risk management and risk assessment <http://www.cms.hhs.gov/EducationMaterials/04_SecurityMaterials.asp>. European or other countries health care service providers will generally not be affected by HIPAA obligations if they are not active on the U.S. market. However, since their data processing activities are subject to similar obligations under general European law (including the Privacy Directive), and since the underlying trends of modernisation and evolution towards electronic health files are the same, the HHS safeguards can be useful as an initial yardstick for measuring RM/RA strategies put in place by European health care service providers, specifically with regard to the processing of electronic health information. HIPAA security standards include the following:
    • Administrative safeguards:
      • Security Management Process
      • Assigned Security Responsibility
      • Workforce Security
      • Information Access Management
      • Security Awareness and Training
      • Security Incident Procedures
      • Contingency Plan
      • Evaluation
      • Business Associate Contracts and Other Arrangements
    • Physical safeguards
      • Facility Access Controls
      • Workstation Use
      • Workstation Security
      • Device and Media Controls
    • Technical safeguards
      • Access Control
      • Audit Controls
      • Integrity
      • Person or Entity Authentication
      • Transmission Security
    • Organisational requirements
      • Business Associate Contracts & Other Arrangements
      • Requirements for Group Health Plans
  • International Safe Harbor Privacy Principles issued by the US Department of Commerce on July 21, 2000 Export of personal data from a data controller who is subject to E.U. privacy regulations to a U.S. based destination; before personal data may be exported from an entity subject to E.U. privacy regulations to a destination subject to U.S. law, the European entity must ensure that the receiving entity provides adequate safeguards to protect such data against a number of mishaps. One way of complying with this obligation is to require the receiving entity to join the Safe Harbor, by requiring that the entity self-certifies its compliance with the so-called Safe Harbor Principles. If this road is chosen, the data controller exporting the data must verify that the U.S. destination is indeed on the Safe Harbor list (see safe harbor list)
  • The United States Department of Homeland Security also utilizes Privacy Impact Assessment (PIA) as a decision making tool to identify and mitigate risks of privacy violations.^[30]
• Sarbanes–Oxley Act
• FISMA

As legislation evolves, there has been increased focus to require ‘reasonable security’ for information management. CCPA states that «manufacturers of connected devices to equip the device with reasonable security.»^[31] New York’s SHIELD Act requires that organizations that manage NY residents’ information “develop, implement and maintain reasonable safeguards to protect the security, confidentiality and integrity of the private information including, but not limited to, disposal of data.” This concept will influence how businesses manage their risk management plan as compliance requirements develop.

Standards organizations and standards[edit]

• International standard bodies:
  • International Organization for Standardization – ISO
  • Payment Card Industry Security Standards Council
  • Information Security Forum
  • The Open Group
• United States standard bodies:
  • National Institute of Standards and Technology – NIST
  • Federal Information Processing Standards – FIPS by NIST devoted to Federal Government and Agencies
• UK standard bodies
  • British Standard Institute

Short description of standards[edit]

The list is chiefly based on:^[29]

ISO[edit]

• ISO/IEC 13335-1:2004 – Information technology—Security techniques—Management of information and communications technology security—Part 1: Concepts and models for information and communications technology security management http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=39066. Standard containing generally accepted descriptions of concepts and models for information and communications technology security management. The standard is a commonly used code of practice, and serves as a resource for the implementation of security management practices and as a yardstick for auditing such practices. (See also http://csrc.nist.gov/publications/secpubs/otherpubs/reviso-faq.pdf)
• ISO/IEC TR 15443-1:2005 – Information technology—Security techniques—A framework for IT security assurance reference:http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=39733 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Security assurance – the Technical Report (TR) contains generally accepted guidelines which can be used to determine an appropriate assurance method for assessing a security service, product or environmental factor
• ISO/IEC 15816:2002 – Information technology—Security techniques—Security information objects for access control reference:http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=29139 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Security management – Access control. The standard allows security professionals to rely on a specific set of syntactic definitions and explanations with regard to SIOs, thus avoiding duplication or divergence in other standardisation efforts.
• ISO/IEC TR 15947:2002 – Information technology—Security techniques—IT intrusion detection framework reference:http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=29580 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Security management – Intrusion detection in IT systems. The standard allows security professionals to rely on a specific set of concepts and methodologies for describing and assessing security risks with regard to potential intrusions in IT systems. It does not contain any RM/RA obligations as such, but it is rather a tool for facilitating RM/RA activities in the affected field.
• ISO/IEC 15408-1/2/3:2005 – Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model (15408-1) Part 2: Security functional requirements (15408-2) Part 3: Security assurance requirements (15408-3) reference: http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm Topic: Standard containing a common set of requirements for the security functions of IT products and systems and for assurance measures applied to them during a security evaluation. Scope: Publicly available ISO standard, which can be voluntarily implemented. The text is a resource for the evaluation of the security of IT products and systems, and can thus be used as a tool for RM/RA. The standard is commonly used as a resource for the evaluation of the security of IT products and systems; including (if not specifically) for procurement decisions with regard to such products. The standard can thus be used as an RM/RA tool to determine the security of an IT product or system during its design, manufacturing or marketing, or before procuring it.
• ISO/IEC 17799:2005 – Information technology—Security techniques—Code of practice for information security management. reference: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=39612&ICS1=35&ICS2=40&ICS3= (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Standard containing generally accepted guidelines and general principles for initiating, implementing, maintaining, and improving information security management in an organization, including business continuity management. The standard is a commonly used code of practice, and serves as a resource for the implementation of information security management practices and as a yardstick for auditing such practices. (See also ISO/IEC 17799)
• ISO/IEC TR 15446:2004 – Information technology—Security techniques—Guide for the production of Protection Profiles and Security Targets. reference: http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm Topic: Technical Report (TR) containing guidelines for the construction of Protection Profiles (PPs) and Security Targets (STs) that are intended to be compliant with ISO/IEC 15408 (the «Common Criteria»). The standard is predominantly used as a tool for security professionals to develop PPs and STs, but can also be used to assess the validity of the same (by using the TR as a yardstick to determine if its standards have been obeyed). Thus, it is a (nonbinding) normative tool for the creation and assessment of RM/RA practices.
• ISO/IEC 18028:2006 – Information technology—Security techniques—IT network security reference: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=40008 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Five part standard (ISO/IEC 18028-1 to 18028-5) containing generally accepted guidelines on the security aspects of the management, operation and use of information technology networks. The standard is considered an extension of the guidelines provided in ISO/IEC 13335 and ISO/IEC 17799 focusing specifically on network security risks. The standard is a commonly used code of practice, and serves as a resource for the implementation of security management practices and as a yardstick for auditing such practices.
• ISO/IEC 27001:2005 – Information technology—Security techniques—Information security management systems—Requirements reference: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=42103 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Standard containing generally accepted guidelines for the implementation of an Information Security Management System within any given organisation. Scope: Not publicly available ISO standard, which can be voluntarily implemented. While not legally binding, the text contains direct guidelines for the creation of sound information security practices The standard is a very commonly used code of practice, and serves as a resource for the implementation of information security management systems and as a yardstick for auditing such systems and/or the surrounding practices. Its application in practice is often combined with related standards, such as BS 7799-3:2006 which provides additional guidance to support the requirements given in ISO/IEC 27001:2005 <http://www.bsiglobal.com/en/Shop/Publication-Detail/?pid=000000000030125022&recid=2491>
• ISO/IEC 27001:2013, the updated standard for information security management systems.
• ISO/IEC TR 18044:2004 – Information technology—Security techniques—Information security incident management reference: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=35396 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Technical Report (TR) containing generally accepted guidelines and general principles for information security incident management in an organization.Scope: Not publicly available ISO TR, which can be voluntarily used.While not legally binding, the text contains direct guidelines for incident management. The standard is a high level resource introducing basic concepts and considerations in the field of incident response. As such, it is mostly useful as a catalyst to awareness raising initiatives in this regard.
• ISO/IEC 18045:2005 – Information technology—Security techniques—Methodology for IT security evaluation reference: http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm Topic: Standard containing auditing guidelines for assessment of compliance with ISO/IEC 15408 (Information technology—Security techniques—Evaluation criteria for IT security) Scope Publicly available ISO standard, to be followed when evaluating compliance with ISO/IEC 15408 (Information technology—Security techniques—Evaluation criteria for IT security). The standard is a ‘companion document’, which is thus primarily of used for security professionals involved in evaluating compliance with ISO/IEC 15408 (Information technology—Security techniques—Evaluation criteria for IT security). Since it describes minimum actions to be performed by such auditors, compliance with ISO/IEC 15408 is impossible if ISO/IEC 18045 has been disregarded.
• ISO/TR 13569:2005 – Financial services—Information security guidelines reference: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=37245 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Standard containing guidelines for the implementation and assessment of information security policies in financial services institutions. The standard is a commonly referenced guideline, and serves as a resource for the implementation of information security management programmes in institutions of the financial sector, and as a yardstick for auditing such programmes. (See also http://csrc.nist.gov/publications/secpubs/otherpubs/reviso-faq.pdf)
• ISO/IEC 21827:2008 – Information technology—Security techniques—Systems Security Engineering—Capability Maturity Model (SSE-CMM): ISO/IEC 21827:2008 specifies the Systems Security Engineering – Capability Maturity Model (SSE-CMM), which describes the essential characteristics of an organization’s security engineering process that must exist to ensure good security engineering. ISO/IEC 21827:2008 does not prescribe a particular process or sequence, but captures practices generally observed in industry. The model is a standard metric for security engineering practices.

BSI[edit]

• BS 25999-1:2006 – Business continuity management Part 1: Code of practice Note: this is only part one of BS 25999, which was published in November 2006. Part two (which should contain more specific criteria with a view of possible accreditation) is yet to appear. reference: http://www.bsi-global.com/en/Shop/Publication-Detail/?pid=000000000030157563. Topic: Standard containing a business continuity code of practice. The standard is intended as a code of practice for business continuity management, and will be extended by a second part that should permit accreditation for adherence with the standard. Given its relative newness, the potential impact of the standard is difficult to assess, although it could be very influential to RM/RA practices, given the general lack of universally applicable standards in this regard and the increasing attention to business continuity and contingency planning in regulatory initiatives. Application of this standard can be complemented by other norms, in particular PAS 77:2006 – IT Service Continuity Management Code of Practice <http://www.bsi-global.com/en/Shop/Publication-Detail/?pid=000000000030141858>.The TR allows security professionals to determine a suitable methodology for assessing a security service, product or environmental factor (a deliverable). Following this TR, it can be determined which level of security assurance a deliverable is intended to meet, and if this threshold is actually met by the deliverable.
• BS 7799-3:2006 – Information security management systems—Guidelines for information security risk management reference: http://www.bsi-global.com/en/Shop/Publication-Detail/?pid=000000000030125022&recid=2491 (Note: this is a reference to the BSI page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Standard containing general guidelines for information security risk management.Scope: Not publicly available BSI standard, which can be voluntarily implemented. While not legally binding, the text contains direct guidelines for the creation of sound information security practices. The standard is mostly intended as a guiding complementary document to the application of the aforementioned ISO 27001:2005, and is therefore typically applied in conjunction with this standard in risk assessment practices

Information Security Forum[edit]

• Standard of Good Practice

See also[edit]

References[edit]

External links[edit]

• Internet2 Information Security Guide: Effective Practices and Solutions for Higher Education
• Risk Management – Principles and Inventories for Risk Management / Risk Assessment methods and tools, Publication date: Jun 01, 2006 Authors:Conducted by the Technical Department of ENISA Section Risk Management
• Clusif Club de la Sécurité de l’Information Français
• 800-30 NIST Risk Management Guide
• 800-39 NIST DRAFT Managing Risk from Information Systems: An Organizational Perspective
• FIPS Publication 199, Standards for Security Categorization of Federal Information and Information
• FIPS Publication 200 Minimum Security Requirements for Federal Information and Information Systems
• 800-37 NIST Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach
• FISMApedia is a collection of documents and discussions focused on USA Federal IT security
• Duty of Care Risk Analysis Standard (DoCRA)

Information technology risk, IT risk, IT-related risk, or cyber risk is any risk related to information technology.^[1] While information has long been appreciated as a valuable and important asset, the rise of the knowledge economy and the Digital Revolution has led to organizations becoming increasingly dependent on information, information processing and especially IT. Various events or incidents that compromise IT in some way can therefore cause adverse impacts on the organization’s business processes or mission, ranging from inconsequential to catastrophic in scale.

Assessing the probability or likelihood of various types of event/incident with their predicted impacts or consequences, should they occur, is a common way to assess and measure IT risks.^[2] Alternative methods of measuring IT risk typically involve assessing other contributory factors such as the threats, vulnerabilities, exposures, and asset values.^[3][4]

Definitions[edit]

ISO[edit]

IT risk: the potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization. It is measured in terms of a combination of the probability of occurrence of an event and its consequence.^[5]

Committee on National Security Systems[edit]

The Committee on National Security Systems of United States of America defined risk in different documents:

• From CNSS Instruction No. 4009 dated 26 April 2010^[6] the basic and more technical focused definition:

  Risk – Possibility that a particular threat will adversely impact an IS by exploiting a particular vulnerability.

• National Security Telecommunications and Information Systems Security Instruction (NSTISSI) No. 1000,^[7] introduces a probability aspect, quite similar to NIST SP 800-30 one:

  Risk – A combination of the likelihood that a threat will occur, the likelihood that a threat occurrence will result in an adverse impact, and the severity of the resulting impact

National Information Assurance Training and Education Center defines risk in the IT field as:^[8]

1. The loss potential that exists as the result of threat-vulnerability pairs. Reducing either the threat or the vulnerability reduces the risk.
2. The uncertainty of loss expressed in terms of probability of such loss.
3. The probability that a hostile entity will successfully exploit a particular telecommunications or COMSEC system for intelligence purposes; its factors are threat and vulnerability.
4. A combination of the likelihood that a threat shall occur, the likelihood that a threat occurrence shall result in an adverse impact, and the severity of the resulting adverse impact.
5. the probability that a particular threat will exploit a particular vulnerability of the system.

NIST[edit]

Many NIST publications define risk in IT context in different publications: FISMApedia^[9] term^[10] provide a list. Between them:

• According to NIST SP 800-30:^[11]

  Risk is a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization.

• From NIST FIPS 200^[12]

  Risk – The level of impact on organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals resulting from the operation of an information system given the potential impact of a threat and the likelihood of that threat occurring.

NIST SP 800-30^[11] defines:

IT-related risk

The net mission impact considering:

1. the probability that a particular threat-source will exercise (accidentally trigger or intentionally exploit) a particular information system vulnerability and
2. the resulting impact if this should occur. IT-related risks arise from legal liability or mission loss due to:
   1. Unauthorized (malicious or accidental) disclosure, modification, or destruction of information
   2. Unintentional errors and omissions
   3. IT disruptions due to natural or man-made disasters
   4. Failure to exercise due care and diligence in the implementation and operation of the IT system.

Risk management insight[edit]

IT risk is the probable frequency and probable magnitude of future loss.^[13]

ISACA[edit]

ISACA published the Risk IT Framework in order to provide an end-to-end, comprehensive view of all risks related to the use of IT. There,^[14] IT risk is defined as:

The business risk associated with the use, ownership, operation, involvement, influence and adoption of IT within an enterprise

According to Risk IT,^[14] IT risk has a broader meaning: it encompasses not just only the negative impact of operations and service delivery which can bring destruction or reduction of the value of the organization, but also the benefitvalue enabling risk associated to missing opportunities to use technology to enable or enhance business or the IT project management for aspects like overspending or late delivery with adverse business impact

Measuring IT risk[edit]

You can’t effectively and consistently manage what you can’t measure, and you can’t measure what you haven’t defined.^[13][15]

Measuring IT risk (or cyber risk) can occur at many levels. At a business level, the risks are managed categorically. Front line IT departments and NOC’s tend to measure more discrete, individual risks. Managing the nexus between them is a key role for modern CISO’s.

When measuring risk of any kind, selecting the correct equation for a given threat, asset, and available data is an important step. Doing so is subject unto itself, but there are common components of risk equations that are helpful to understand.

There are four fundamental forces involved in risk management, which also apply to cybersecurity. They are assets, impact, threats, and likelihood. You have internal knowledge of and a fair amount of control over assets, which are tangible and intangible things that have value. You also have some control over impact, which refers to loss of, or damage to, an asset. However, threats that represent adversaries and their methods of attack are external to your control. Likelihood is the wild card in the bunch. Likelihoods determine if and when a threat will materialize, succeed, and do damage. While never fully under your control, likelihoods can be shaped and influenced to manage the risk.
^[16]

Mathematically, the forces can be represented in a formula such as: where p() is the likelihood that a Threat will materialize/succeed against an Asset, and d() is the likelihood of various levels of damage that may occur.^[17]

The field of IT risk management has spawned a number of terms and techniques which are unique to the industry. Some industry terms have yet to be reconciled. For example, the term vulnerability is often used interchangeably with likelihood of occurrence, which can be problematic. Often encountered IT risk management terms and techniques include:

Information security event

An identified occurrence of a system, service or network state indicating a possible breach of information security policy or failure of safeguards, or a previously unknown situation that may be security relevant.^[5]

Occurrence of a particular set of circumstances^[18]

• The event can be certain or uncertain.
• The event can be a single occurrence or a series of occurrences. :(ISO/IEC Guide 73)

Information security incident

is indicated by a single or a series of unwanted information security events that have a significant probability of compromising business operations and threatening information security^[5]

An event [G.11] that has been assessed as having an actual or potentially adverse effect on the security or performance of a system.^[19]

Impact^[20]

The result of an unwanted incident [G.17].(ISO/IEC PDTR 13335-1)

Consequence^[21]

Outcome of an event [G.11]

• There can be more than one consequence from one event.
• Consequences can range from positive to negative.
• Consequences can be expressed qualitatively or quantitatively (ISO/IEC Guide 73)

The risk R is the product of the likelihood L of a security incident occurring times the impact I that will be incurred to the organization due to the incident, that is:^[22]

R = L × I

The likelihood of a security incident occurrence is a function of the likelihood that a threat appears and the likelihood that the threat can successfully exploit the relevant system vulnerabilities.

The consequence of the occurrence of a security incident are a function of likely impact that the incident will have on the organization as a result of the harm the organization assets will sustain. Harm is related to the value of the assets to the organization; the same asset can have different values to different organizations.

So R can be function of four factors:

• A = Value of the assets
• T = the likelihood of the threat
• V = the nature of vulnerability i.e. the likelihood that can be exploited (proportional to the potential benefit for the attacker and inversely proportional to the cost of exploitation)
• I = the likely impact, the extent of the harm

If numerical values (money for impact and probabilities for the other factors), the risk can be expressed in monetary terms and compared to the cost of countermeasures and the residual risk after applying the security control. It is not always practical to express this values, so in the first step of risk evaluation, risk are graded dimensionless in three or five steps scales.

OWASP proposes a practical risk measurement guideline^[22] based on:

• Estimation of Likelihood as a mean between different factors in a 0 to 9 scale:
  • Threat agent factors
    • Skill level: How technically skilled is this group of threat agents? No technical skills (1), some technical skills (3), advanced computer user (4), network and programming skills (6), security penetration skills (9)
    • Motive: How motivated is this group of threat agents to find and exploit this vulnerability? Low or no reward (1), possible reward (4), high reward (9)
    • Opportunity: What resources and opportunity are required for this group of threat agents to find and exploit this vulnerability? full access or expensive resources required (0), special access or resources required (4), some access or resources required (7), no access or resources required (9)
    • Size: How large is this group of threat agents? Developers (2), system administrators (2), intranet users (4), partners (5), authenticated users (6), anonymous Internet users (9)
  • Vulnerability Factors: the next set of factors are related to the vulnerability involved. The goal here is to estimate the likelihood of the particular vulnerability involved being discovered and exploited. Assume the threat agent selected above.
    • Ease of discovery: How easy is it for this group of threat agents to discover this vulnerability? Practically impossible (1), difficult (3), easy (7), automated tools available (9)
    • Ease of exploit: How easy is it for this group of threat agents to actually exploit this vulnerability? Theoretical (1), difficult (3), easy (5), automated tools available (9)
    • Awareness: How well known is this vulnerability to this group of threat agents? Unknown (1), hidden (4), obvious (6), public knowledge (9)
    • Intrusion detection: How likely is an exploit to be detected? Active detection in application (1), logged and reviewed (3), logged without review (8), not logged (9)
• Estimation of Impact as a mean between different factors in a 0 to 9 scale
  • Technical Impact Factors; technical impact can be broken down into factors aligned with the traditional security areas of concern: confidentiality, integrity, availability, and accountability. The goal is to estimate the magnitude of the impact on the system if the vulnerability were to be exploited.
    • Loss of confidentiality: How much data could be disclosed and how sensitive is it? Minimal non-sensitive data disclosed (2), minimal critical data disclosed (6), extensive non-sensitive data disclosed (6), extensive critical data disclosed (7), all data disclosed (9)
    • Loss of integrity: How much data could be corrupted and how damaged is it? Minimal slightly corrupt data (1), minimal seriously corrupt data (3), extensive slightly corrupt data (5), extensive seriously corrupt data (7), all data totally corrupt (9)
    • Loss of availability How much service could be lost and how vital is it? Minimal secondary services interrupted (1), minimal primary services interrupted (5), extensive secondary services interrupted (5), extensive primary services interrupted (7), all services completely lost (9)
    • Loss of accountability: Are the threat agents’ actions traceable to an individual? Fully traceable (1), possibly traceable (7), completely anonymous (9)
  • Business Impact Factors: The business impact stems from the technical impact, but requires a deep understanding of what is important to the company running the application. In general, you should be aiming to support your risks with business impact, particularly if your audience is executive level. The business risk is what justifies investment in fixing security problems.
    • Financial damage: How much financial damage will result from an exploit? Less than the cost to fix the vulnerability (1), minor effect on annual profit (3), significant effect on annual profit (7), bankruptcy (9)
    • Reputation damage: Would an exploit result in reputation damage that would harm the business? Minimal damage (1), Loss of major accounts (4), loss of goodwill (5), brand damage (9)
    • Non-compliance: How much exposure does non-compliance introduce? Minor violation (2), clear violation (5), high-profile violation (7)
    • Privacy violation: How much personally identifiable information could be disclosed? One individual (3), hundreds of people (5), thousands of people (7), millions of people (9)
  • If the business impact is calculated accurately use it in the following otherwise use the Technical impact
• Rate likelihood and impact in a LOW, MEDIUM, HIGH scale assuming that less than 3 is LOW, 3 to less than 6 is MEDIUM, and 6 to 9 is HIGH.
• Calculate the risk using the following table

IT risk management[edit]

IT risk management can be considered a component of a wider enterprise risk management system.^[23]

The establishment, maintenance and continuous update of an information security management system (ISMS) provide a strong indication that a company is using a systematic approach for the identification, assessment and management of information security risks.^[24]

Different methodologies have been proposed to manage IT risks, each of them divided into processes and steps.^[25]

The Certified Information Systems Auditor Review Manual 2006 produced by ISACA, an international professional association focused on IT Governance, provides the following definition of risk management: «Risk management is the process of identifying vulnerabilities and threats to the information resources used by an organization in achieving business objectives, and deciding what countermeasures, if any, to take in reducing risk to an acceptable level, based on the value of the information resource to the organization.»^[26]

The NIST Cybersecurity Framework encourages organizations to manage IT risk as part the Identify (ID) function:^[27][28]

Risk Assessment (ID.RA): The organization understands the cybersecurity risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals.

• ID.RA-1: Asset vulnerabilities are identified and documented
• ID.RA-2: Cyber threat intelligence and vulnerability information is received from information sharing forums and source
• ID.RA-3: Threats, both internal and external, are identified and documented
• ID.RA-4: Potential business impacts and likelihoods are identified
• ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk
• ID.RA-6: Risk responses are identified and prioritized

Risk Management Strategy (ID.RM): The organization’s priorities, constraints, risk tolerances, and assumptions are established and used to support operational risk decisions.

• ID.RM-1: Risk management processes are established, managed, and agreed to by organizational stakeholders
• ID.RM-2: Organizational risk tolerance is determined and clearly expressed
• ID.RM-3: The organization’s determination of risk tolerance is informed by its role in critical infrastructure and sector specific risk analysis

IT risk laws and regulations[edit]

In the following a brief description of applicable rules organized by source.^[29]

OECD[edit]

OECD issued the following:

• Organisation for Economic Co-operation and Development (OECD) Recommendation of the Council concerning guidelines governing the protection of privacy and trans-border flows of personal data (23 September 1980)
• OECD Guidelines for the Security of Information Systems and Networks: Towards a Culture of Security (25 July 2002). Topic: General information security. Scope: Non binding guidelines to any OECD entities (governments, businesses, other organisations and individual users who develop, own, provide, manage, service, and use information systems and networks). The OECD Guidelines state the basic principles underpinning risk management and information security practices. While no part of the text is binding as such, non-compliance with any of the principles is indicative of a serious breach of RM/RA good practices that can potentially incur liability.

European Union[edit]

The European Union issued the following, divided by topic:

• Privacy
  • Regulation (EC) No 45/2001 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data provide an internal regulation, which is a practical application of the principles of the Privacy Directive described below. Furthermore, article 35 of the Regulation requires the Community institutions and bodies to take similar precautions with regard to their telecommunications infrastructure, and to properly inform the users of any specific risks of security breaches.
  • Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data require that any personal data processing activity undergoes a prior risk analysis in order to determine the privacy implications of the activity, and to determine the appropriate legal, technical and organisation measures to protect such activities;is effectively protected by such measures, which must be state of the art keeping into account the sensitivity and privacy implications of the activity (including when a third party is charged with the processing task) is notified to a national data protection authority, including the measures taken to ensure the security of the activity. Furthermore, article 25 and following of the Directive requires Member States to ban the transfer of personal data to non-Member States, unless such countries have provided adequate legal protection for such personal data, or barring certain other exceptions.
  • Commission Decision 2001/497/EC of 15 June 2001 on standard contractual clauses for the transfer of personal data to third countries, under Directive 95/46/EC; and Commission Decision 2004/915/EC of 27 December 2004 amending Decision 2001/497/EC as regards the introduction of an alternative set of standard contractual clauses for the transfer of personal data to third countries. Topic: Export of personal data to third countries, specifically non-E.U. countries which have not been recognised as having a data protection level that is adequate (i.e. equivalent to that of the E.U.). Both Commission Decisions provide a set of voluntary model clauses which can be used to export personal data from a data controller (who is subject to E.U. data protection rules) to a data processor outside the E.U. who is not subject to these rules or to a similar set of adequate rules.
  • International Safe Harbor Privacy Principles (see below USA and International Safe Harbor Privacy Principles )
  • Directive 2002/58/EC of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector
• National Security
  • Directive 2006/24/EC of 15 March 2006 on the retention of data generated or processed in connection with the provision of publicly available electronic communications services or of public communications networks and amending Directive 2002/58/EC (‘Data Retention Directive’). Topic: Requirement for the providers of public electronic telecommunications service providers to retain certain information for the purposes of the investigation, detection and prosecution of serious crime
  • Council Directive 2008/114/EC of 8 December 2008 on the identification and designation of European critical infrastructures and the assessment of the need to improve their protection. Topic: Identification and protection of European Critical Infrastructures. Scope: Applicable to Member States and to the operators of European Critical Infrastructure (defined by the draft directive as ‘critical infrastructures the disruption or destruction of which would significantly affect two or more Member States, or a single Member State if the critical infrastructure is located in another Member State. This includes effects resulting from cross-sector dependencies on other types of infrastructure’). Requires Member States to identify critical infrastructures on their territories, and to designate them as ECIs. Following this designation, the owners/operators of ECIs are required to create Operator Security Plans (OSPs), which should establish relevant security solutions for their protection
• Civil and Penal law
  • Council Framework Decision 2005/222/JHA of 24 February 2005 on attacks against information systems. Topic: General decision aiming to harmonise national provisions in the field of cyber crime, encompassing material criminal law (i.e. definitions of specific crimes), procedural criminal law (including investigative measures and international cooperation) and liability issues. Scope: Requires Member States to implement the provisions of the Framework Decision in their national legal frameworks. Framework decision is relevant to RM/RA because it contains the conditions under which legal liability can be imposed on legal entities for conduct of certain natural persons of authority within the legal entity. Thus, the Framework decision requires that the conduct of such figures within an organisation is adequately monitored, also because the Decision states that a legal entity can be held liable for acts of omission in this regard.

Council of Europe[edit]

• Council of Europe Convention on Cybercrime, Budapest, 23.XI.2001, European Treaty Series-No. 185. Topic: General treaty aiming to harmonise national provisions in the field of cyber crime, encompassing material criminal law (i.e. definitions of specific crimes), procedural criminal law (including investigative measures and international cooperation), liability issues and data retention. Apart from the definitions of a series of criminal offences in articles 2 to 10, the Convention is relevant to RM/RA because it states the conditions under which legal liability can be imposed on legal entities for conduct of certain natural persons of authority within the legal entity. Thus, the Convention requires that the conduct of such figures within an organisation is adequately monitored, also because the Convention states that a legal entity can be held liable for acts of omission in this regard.

United States[edit]

United States issued the following, divided by topic:

• Civil and Penal law
  • Amendments to the Federal Rules of Civil Procedure with regard to electronic discovery. Topic: U.S. Federal rules with regard to the production of electronic documents in civil proceedings. The discovery rules allow a party in civil proceedings to demand that the opposing party produce all relevant documentation (to be defined by the requesting party) in its possession, so as to allow the parties and the court to correctly assess the matter. Through the e-discovery amendment, which entered into force on 1 December 2006, such information may now include electronic information. This implies that any party being brought before a U.S. court in civil proceedings can be asked to produce such documents, which includes finalised reports, working documents, internal memos and e-mails with regard to a specific subject, which may or may not be specifically delineated. Any party whose activities imply a risk of being involved in such proceedings must therefore take adequate precautions for the management of such information, including the secure storage. Specifically: The party must be capable of initiating a ‘litigation hold’, a technical/organisational measure which must ensure that no relevant information can be modified any longer in any way. Storage policies must be responsible: while deletion of specific information of course remains allowed when this is a part of general information management policies (‘routine, good-faith operation of the information system’, Rule 37 (f)), the wilful destruction of potentially relevant information can be punished by extremely high fines (in one specific case of 1.6 billion US$). Thus, in practice, any businesses who risk civil litigation before U.S. courts must implement adequate information management policies, and must implement the necessary measures to initiate a litigation hold.
• Privacy
  • California Consumer Privacy Act (CCPA)
  • California Privacy Rights Act (CPRA)
  • Gramm–Leach–Bliley Act (GLBA)
  • USA PATRIOT Act, Title III
  • Health Insurance Portability and Accountability Act (HIPAA) From an RM/RA perspective, the Act is particularly known for its provisions with regard to Administrative Simplification (Title II of HIPAA). This title required the U.S. Department of Health and Human Services (HHS) to draft specific rule sets, each of which would provide specific standards which would improve the efficiency of the health care system and prevent abuse. As a result, the HHS has adopted five principal rules: the Privacy Rule, the Transactions and Code Sets Rule, the Unique Identifiers Rule, the Enforcement Rule, and the Security Rule. The latter, published in the Federal Register on 20 February 2003 (see: http://www.cms.hhs.gov/SecurityStandard/Downloads/securityfinalrule.pdf), is specifically relevant, as it specifies a series of administrative, technical, and physical security procedures to assure the confidentiality of electronic protected health information. These aspects have been further outlined in a set of Security Standards on Administrative, Physical, Organisational and Technical Safeguards, all of which have been published, along with a guidance document on the basics of HIPAA risk management and risk assessment <http://www.cms.hhs.gov/EducationMaterials/04_SecurityMaterials.asp>. European or other countries health care service providers will generally not be affected by HIPAA obligations if they are not active on the U.S. market. However, since their data processing activities are subject to similar obligations under general European law (including the Privacy Directive), and since the underlying trends of modernisation and evolution towards electronic health files are the same, the HHS safeguards can be useful as an initial yardstick for measuring RM/RA strategies put in place by European health care service providers, specifically with regard to the processing of electronic health information. HIPAA security standards include the following:
    • Administrative safeguards:
      • Security Management Process
      • Assigned Security Responsibility
      • Workforce Security
      • Information Access Management
      • Security Awareness and Training
      • Security Incident Procedures
      • Contingency Plan
      • Evaluation
      • Business Associate Contracts and Other Arrangements
    • Physical safeguards
      • Facility Access Controls
      • Workstation Use
      • Workstation Security
      • Device and Media Controls
    • Technical safeguards
      • Access Control
      • Audit Controls
      • Integrity
      • Person or Entity Authentication
      • Transmission Security
    • Organisational requirements
      • Business Associate Contracts & Other Arrangements
      • Requirements for Group Health Plans
  • International Safe Harbor Privacy Principles issued by the US Department of Commerce on July 21, 2000 Export of personal data from a data controller who is subject to E.U. privacy regulations to a U.S. based destination; before personal data may be exported from an entity subject to E.U. privacy regulations to a destination subject to U.S. law, the European entity must ensure that the receiving entity provides adequate safeguards to protect such data against a number of mishaps. One way of complying with this obligation is to require the receiving entity to join the Safe Harbor, by requiring that the entity self-certifies its compliance with the so-called Safe Harbor Principles. If this road is chosen, the data controller exporting the data must verify that the U.S. destination is indeed on the Safe Harbor list (see safe harbor list)
  • The United States Department of Homeland Security also utilizes Privacy Impact Assessment (PIA) as a decision making tool to identify and mitigate risks of privacy violations.^[30]
• Sarbanes–Oxley Act
• FISMA

As legislation evolves, there has been increased focus to require ‘reasonable security’ for information management. CCPA states that «manufacturers of connected devices to equip the device with reasonable security.»^[31] New York’s SHIELD Act requires that organizations that manage NY residents’ information “develop, implement and maintain reasonable safeguards to protect the security, confidentiality and integrity of the private information including, but not limited to, disposal of data.” This concept will influence how businesses manage their risk management plan as compliance requirements develop.

Standards organizations and standards[edit]

• International standard bodies:
  • International Organization for Standardization – ISO
  • Payment Card Industry Security Standards Council
  • Information Security Forum
  • The Open Group
• United States standard bodies:
  • National Institute of Standards and Technology – NIST
  • Federal Information Processing Standards – FIPS by NIST devoted to Federal Government and Agencies
• UK standard bodies
  • British Standard Institute

Short description of standards[edit]

The list is chiefly based on:^[29]

ISO[edit]

• ISO/IEC 13335-1:2004 – Information technology—Security techniques—Management of information and communications technology security—Part 1: Concepts and models for information and communications technology security management http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=39066. Standard containing generally accepted descriptions of concepts and models for information and communications technology security management. The standard is a commonly used code of practice, and serves as a resource for the implementation of security management practices and as a yardstick for auditing such practices. (See also http://csrc.nist.gov/publications/secpubs/otherpubs/reviso-faq.pdf)
• ISO/IEC TR 15443-1:2005 – Information technology—Security techniques—A framework for IT security assurance reference:http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=39733 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Security assurance – the Technical Report (TR) contains generally accepted guidelines which can be used to determine an appropriate assurance method for assessing a security service, product or environmental factor
• ISO/IEC 15816:2002 – Information technology—Security techniques—Security information objects for access control reference:http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=29139 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Security management – Access control. The standard allows security professionals to rely on a specific set of syntactic definitions and explanations with regard to SIOs, thus avoiding duplication or divergence in other standardisation efforts.
• ISO/IEC TR 15947:2002 – Information technology—Security techniques—IT intrusion detection framework reference:http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=29580 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Security management – Intrusion detection in IT systems. The standard allows security professionals to rely on a specific set of concepts and methodologies for describing and assessing security risks with regard to potential intrusions in IT systems. It does not contain any RM/RA obligations as such, but it is rather a tool for facilitating RM/RA activities in the affected field.
• ISO/IEC 15408-1/2/3:2005 – Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model (15408-1) Part 2: Security functional requirements (15408-2) Part 3: Security assurance requirements (15408-3) reference: http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm Topic: Standard containing a common set of requirements for the security functions of IT products and systems and for assurance measures applied to them during a security evaluation. Scope: Publicly available ISO standard, which can be voluntarily implemented. The text is a resource for the evaluation of the security of IT products and systems, and can thus be used as a tool for RM/RA. The standard is commonly used as a resource for the evaluation of the security of IT products and systems; including (if not specifically) for procurement decisions with regard to such products. The standard can thus be used as an RM/RA tool to determine the security of an IT product or system during its design, manufacturing or marketing, or before procuring it.
• ISO/IEC 17799:2005 – Information technology—Security techniques—Code of practice for information security management. reference: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=39612&ICS1=35&ICS2=40&ICS3= (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Standard containing generally accepted guidelines and general principles for initiating, implementing, maintaining, and improving information security management in an organization, including business continuity management. The standard is a commonly used code of practice, and serves as a resource for the implementation of information security management practices and as a yardstick for auditing such practices. (See also ISO/IEC 17799)
• ISO/IEC TR 15446:2004 – Information technology—Security techniques—Guide for the production of Protection Profiles and Security Targets. reference: http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm Topic: Technical Report (TR) containing guidelines for the construction of Protection Profiles (PPs) and Security Targets (STs) that are intended to be compliant with ISO/IEC 15408 (the «Common Criteria»). The standard is predominantly used as a tool for security professionals to develop PPs and STs, but can also be used to assess the validity of the same (by using the TR as a yardstick to determine if its standards have been obeyed). Thus, it is a (nonbinding) normative tool for the creation and assessment of RM/RA practices.
• ISO/IEC 18028:2006 – Information technology—Security techniques—IT network security reference: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=40008 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Five part standard (ISO/IEC 18028-1 to 18028-5) containing generally accepted guidelines on the security aspects of the management, operation and use of information technology networks. The standard is considered an extension of the guidelines provided in ISO/IEC 13335 and ISO/IEC 17799 focusing specifically on network security risks. The standard is a commonly used code of practice, and serves as a resource for the implementation of security management practices and as a yardstick for auditing such practices.
• ISO/IEC 27001:2005 – Information technology—Security techniques—Information security management systems—Requirements reference: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=42103 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Standard containing generally accepted guidelines for the implementation of an Information Security Management System within any given organisation. Scope: Not publicly available ISO standard, which can be voluntarily implemented. While not legally binding, the text contains direct guidelines for the creation of sound information security practices The standard is a very commonly used code of practice, and serves as a resource for the implementation of information security management systems and as a yardstick for auditing such systems and/or the surrounding practices. Its application in practice is often combined with related standards, such as BS 7799-3:2006 which provides additional guidance to support the requirements given in ISO/IEC 27001:2005 <http://www.bsiglobal.com/en/Shop/Publication-Detail/?pid=000000000030125022&recid=2491>
• ISO/IEC 27001:2013, the updated standard for information security management systems.
• ISO/IEC TR 18044:2004 – Information technology—Security techniques—Information security incident management reference: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=35396 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Technical Report (TR) containing generally accepted guidelines and general principles for information security incident management in an organization.Scope: Not publicly available ISO TR, which can be voluntarily used.While not legally binding, the text contains direct guidelines for incident management. The standard is a high level resource introducing basic concepts and considerations in the field of incident response. As such, it is mostly useful as a catalyst to awareness raising initiatives in this regard.
• ISO/IEC 18045:2005 – Information technology—Security techniques—Methodology for IT security evaluation reference: http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm Topic: Standard containing auditing guidelines for assessment of compliance with ISO/IEC 15408 (Information technology—Security techniques—Evaluation criteria for IT security) Scope Publicly available ISO standard, to be followed when evaluating compliance with ISO/IEC 15408 (Information technology—Security techniques—Evaluation criteria for IT security). The standard is a ‘companion document’, which is thus primarily of used for security professionals involved in evaluating compliance with ISO/IEC 15408 (Information technology—Security techniques—Evaluation criteria for IT security). Since it describes minimum actions to be performed by such auditors, compliance with ISO/IEC 15408 is impossible if ISO/IEC 18045 has been disregarded.
• ISO/TR 13569:2005 – Financial services—Information security guidelines reference: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=37245 (Note: this is a reference to the ISO page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Standard containing guidelines for the implementation and assessment of information security policies in financial services institutions. The standard is a commonly referenced guideline, and serves as a resource for the implementation of information security management programmes in institutions of the financial sector, and as a yardstick for auditing such programmes. (See also http://csrc.nist.gov/publications/secpubs/otherpubs/reviso-faq.pdf)
• ISO/IEC 21827:2008 – Information technology—Security techniques—Systems Security Engineering—Capability Maturity Model (SSE-CMM): ISO/IEC 21827:2008 specifies the Systems Security Engineering – Capability Maturity Model (SSE-CMM), which describes the essential characteristics of an organization’s security engineering process that must exist to ensure good security engineering. ISO/IEC 21827:2008 does not prescribe a particular process or sequence, but captures practices generally observed in industry. The model is a standard metric for security engineering practices.

BSI[edit]

• BS 25999-1:2006 – Business continuity management Part 1: Code of practice Note: this is only part one of BS 25999, which was published in November 2006. Part two (which should contain more specific criteria with a view of possible accreditation) is yet to appear. reference: http://www.bsi-global.com/en/Shop/Publication-Detail/?pid=000000000030157563. Topic: Standard containing a business continuity code of practice. The standard is intended as a code of practice for business continuity management, and will be extended by a second part that should permit accreditation for adherence with the standard. Given its relative newness, the potential impact of the standard is difficult to assess, although it could be very influential to RM/RA practices, given the general lack of universally applicable standards in this regard and the increasing attention to business continuity and contingency planning in regulatory initiatives. Application of this standard can be complemented by other norms, in particular PAS 77:2006 – IT Service Continuity Management Code of Practice <http://www.bsi-global.com/en/Shop/Publication-Detail/?pid=000000000030141858>.The TR allows security professionals to determine a suitable methodology for assessing a security service, product or environmental factor (a deliverable). Following this TR, it can be determined which level of security assurance a deliverable is intended to meet, and if this threshold is actually met by the deliverable.
• BS 7799-3:2006 – Information security management systems—Guidelines for information security risk management reference: http://www.bsi-global.com/en/Shop/Publication-Detail/?pid=000000000030125022&recid=2491 (Note: this is a reference to the BSI page where the standard can be acquired. However, the standard is not free of charge, and its provisions are not publicly available. For this reason, specific provisions cannot be quoted). Topic: Standard containing general guidelines for information security risk management.Scope: Not publicly available BSI standard, which can be voluntarily implemented. While not legally binding, the text contains direct guidelines for the creation of sound information security practices. The standard is mostly intended as a guiding complementary document to the application of the aforementioned ISO 27001:2005, and is therefore typically applied in conjunction with this standard in risk assessment practices

Information Security Forum[edit]

• Standard of Good Practice

See also[edit]

References[edit]

External links[edit]

• Internet2 Information Security Guide: Effective Practices and Solutions for Higher Education
• Risk Management – Principles and Inventories for Risk Management / Risk Assessment methods and tools, Publication date: Jun 01, 2006 Authors:Conducted by the Technical Department of ENISA Section Risk Management
• Clusif Club de la Sécurité de l’Information Français
• 800-30 NIST Risk Management Guide
• 800-39 NIST DRAFT Managing Risk from Information Systems: An Organizational Perspective
• FIPS Publication 199, Standards for Security Categorization of Federal Information and Information
• FIPS Publication 200 Minimum Security Requirements for Federal Information and Information Systems
• 800-37 NIST Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach
• FISMApedia is a collection of documents and discussions focused on USA Federal IT security
• Duty of Care Risk Analysis Standard (DoCRA)