Cleaned up Literature folder
This commit is contained in:
parent
73a6380034
commit
fe5eda4e05
586 changed files with 53911 additions and 2475 deletions
|
|
@ -0,0 +1,17 @@
|
|||
An asset is any data, device or other component of an organisation’s systems that is valuable.
|
||||
|
||||
A vulnerability is a weakness that exposes an asset to possible compromise. Weaknesses can be organizational, logical, physical, or human.
|
||||
|
||||
A threat is any incident, be it intentional or accidental, that could negatively affect the confidentiality, integrity or availability of an asset.
|
||||
|
||||
A risk occurs when there's a chance of an asset being compromised, through the exposure of a vulnerability to a threat.
|
||||
|
||||
Adapted from source: [Vigilant Software](https://www.vigilantsoftware.co.uk/blog/risk-terminology-understanding-assets-threats-and-vulnerabilities), retrieved December 8, 2021.
|
||||
|
||||
[About Assets](../Sparks/About%20Assets.md)
|
||||
[Vulnerability](Vulnerability.md)
|
||||
[Threats MoC](Threats%20MoC.md)
|
||||
[Risks definitions](Risks%20definitions.md)
|
||||
|
||||
|
||||
|
||||
10
Corpus/Information Security/Risks/Attack Surface Analysis.md
Normal file
10
Corpus/Information Security/Risks/Attack Surface Analysis.md
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# Attack Surface Analysis
|
||||
|
||||
NIST Definition of Attack Surface: "The set of points on the boundary of a system, a system element, or an environment where an attacker can try to enter, cause an effect on, or extract data from, that system, system element, or environment." ([source](https://csrc.nist.gov/glossary/term/attack_surface))
|
||||
|
||||
|
||||
"Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities." [OWASP Attack Surface Analysis Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html)
|
||||
|
||||
Software Attack Surface Analysis – [Blogpost](https://blogs.perficient.com/2021/08/31/software-attack-surface-analysis/) by Perficient
|
||||
|
||||
What is an Attack Surface? (And How to Reduce It) – [Blogpost](https://www.okta.com/identity-101/what-is-an-attack-surface/) by Okta
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
By Jake Munroe of Recorde Future
|
||||
Source: [Recorded Future website](https://www.recordedfuture.com/iso-27002-threat-intelligence-new-security-standard/)
|
||||
Published: February 4, 2022
|
||||
Retrieved: March 7, 2022
|
||||
|
||||
Jake Munroe lists some uses of threat intelligence on the three layers as identified in [a-5.7-Threat-intelligence](../../Standards/ISO27x/OST/27002/EN/a-5.7-Threat-intelligence.md):
|
||||
|
||||
Strategic:
|
||||
- setting priorities and making informed security architecture and budget decisions
|
||||
- focussing your threat intelligenge programme in line with the organization's strategy, by defining and tracking Priority Intelligence Requirements [^PIR]
|
||||
- heightened awareness of relevant emerging threats, TTPs [^TTP], and threat groups
|
||||
|
||||
Tactical:
|
||||
- integrating Indicators of Compromise (IoC’s) into security tools to enable contextual intelligence
|
||||
- using detection rulesets from hunting packages on threat actors and malware
|
||||
|
||||
Operational:
|
||||
- better understanding of specific attacks and the relationships between threat actors, indicators, and TTPs
|
||||
- mapping threat intelligence to common frameworks like MITRE ATT&CK to classify behaviors, assess security gaps, and share intelligence with the cybersecurity community
|
||||
|
||||
|
||||
[^PIR]: An agreement to prioritize certain information collected and processed over others because of the organization’s critical need for this data. – [source](https://www.crowdstrike.com/falcon/2020/videos/priority-intelligence-requirements-your-key-to-working-smarter-with-more-impact/)
|
||||
[^TTP]: - Tactics, techniques and procedures (TTPs) are the “patterns of activities or methods associated with a specific threat actor or group of threat actors.” – [source](https://www.optiv.com/explore-optiv-insights/blog/tactics-techniques-and-procedures-ttps-within-cyber-threat-intelligence)
|
||||
BIN
Corpus/Information Security/Risks/CRF-Threat-Taxonomy-v2024.pdf
Normal file
BIN
Corpus/Information Security/Risks/CRF-Threat-Taxonomy-v2024.pdf
Normal file
Binary file not shown.
|
|
@ -0,0 +1,9 @@
|
|||
The FAIR institute positions FAIR as a standard for cyber risk quantification.
|
||||
|
||||
FAIR principles can be applied "to clarify organizational risk appetite and tolerance as a basis for risk management planning".
|
||||
|
||||
[Source](https://www.fairinstitute.org/blog/cyber-risk-management-establishing-a-blueprint-with-fair)
|
||||
|
||||
Related:
|
||||
- [Risk appetite definitions](Risk%20appetite%20definitions.md)
|
||||
- [Risk tolerance](..//Risk%20tolerance.md)
|
||||
|
|
@ -0,0 +1,76 @@
|
|||
# Managing Risks: A New Framework
|
||||
|
||||
by Robert S. Kaplan and Anette Mikes, June 2012
|
||||
|
||||
[Source](https://hbr.org/2012/06/managing-risks-a-new-framework)
|
||||
Retrieved January 3, 2024
|
||||
|
||||
In 2010 BP's Deepwater Horizon oil rig exploded in the Gulf of Mexico, causing one of the worst man-made disasters in history. A U.S. investigation commission attributed the disaster to management failures that crippled “the ability of individuals involved to identify the risks they faced and to properly evaluate, communicate, and address them.”
|
||||
|
||||
risk management is too often treated as a compliance issue that can be solved by drawing up lots of rules and making sure that all employees follow them.
|
||||
|
||||
rules-based risk management will not diminish either the likelihood or the impact of a disaster such as Deepwater Horizon, just as it did not prevent the failure of many financial institutions during the 2007–2008 credit crisis.
|
||||
|
||||
In this article, we present a new categorization of risk that allows executives to tell which risks can be managed through a rules-based model and which require alternative approaches.
|
||||
|
||||
## Risk Categories
|
||||
|
||||
**Category I: Preventable risks**. These are internal risks, arising from within the organization, that are controllable and ought to be eliminated or avoided. Examples are the risks from employees’ and managers’ unauthorized, illegal, unethical, incorrect, or inappropriate actions and the risks from breakdowns in routine operational processes.
|
||||
These risks are best managed through active prevention: monitoring operational processes and guiding people’s behaviors and decisions toward desired norms.
|
||||
|
||||
**Category II: Strategy risks**
|
||||
A company voluntarily accepts some risk in order to generate superior returns from its strategy. A bank assumes credit risk, for example, when it lends money; many companies take on risks through their research and development activities.
|
||||
These risks are not inherently undesirable.
|
||||
These risks cannot be managed through a rules-based control model: you need to reduce the probability that the assumed risks actually materialize and to improve the company’s ability to manage or contain the risk events, should they occur.
|
||||
|
||||
**Category III: External risks** arise from events outside the company and are beyond its influence or control. Risk management must focus on identification and impact mitigation.
|
||||
|
||||

|
||||
|
||||
While a compliance-based approach is effective for managing preventable risks, it is wholly inadequate for strategy risks or external risks, which require a fundamentally different approach based on open and explicit risk discussions.
|
||||
|
||||
That, however, is easier said than done; extensive behavioral and organizational research has shown that individuals have strong cognitive biases that discourage them from thinking about and discussing risk until it’s too late.
|
||||
|
||||
Rules about what to do and what not to do won’t help here. In fact, they usually have the opposite effect, encouraging a checklist mentality that inhibits challenge and discussion. Managing strategy risks and external risks requires very different approaches.
|
||||
|
||||
## Managing the different Risk Categories
|
||||
|
||||
### Managing Preventable Risks
|
||||
See: [Identifying and Managing Preventable Risks](../Identifying%20and%20Managing%20Preventable%20Risks.md)
|
||||
|
||||
### Managing Strategy Risks
|
||||
Over the past 10 years of study, we’ve come across three distinct approaches to managing strategy risks. all three encourage employees to challenge existing assumptions and debate risk information. Which model is appropriate for a given firm depends largely on the context in which an organization operates.
|
||||
|
||||
**Independent experts**
|
||||
Organizations that push technological innovation face high intrinsic risks. But the risks themselves are mostly 'calculeerbaar'. Risk management can be handled at the project level, for instance throuugh a project reveiw board with independent technical experts whose role is to challenge project engineers’ design, risk-assessment, and risk-mitigation decisions.
|
||||
|
||||
**Facilitators**
|
||||
For organizations with stable technological and market environments, and relatively predictable customer demand, *risks stem largely from seemingly unrelated operational choices across a complex organization that accumulate gradually and can remain hidden for a long time*.
|
||||
|
||||
Since no single staff group has the knowledge to perform operational-level risk management across diverse functions, firms may deploy a relatively small central risk-management group that collects information from operating managers. This increases managers’ awareness of the risks that have been taken on across the organization and provides decision-makers with a full picture of the company’s risk profile.
|
||||
|
||||
We observed this model in action at Hydro One, the Canadian electricity company. Chief risk officer John Fraser, with the explicit backing of the CEO, runs dozens of workshops each year at which employees from all levels and functions identify and rank the principal risks they see to the company’s strategic objectives. Employees use an anonymous voting technology to rate each risk, on a scale of 1 to 5, in terms of its impact, the likelihood of occurrence, and the strength of existing controls. The rankings are discussed in the workshops, and employees are empowered to voice and debate their risk perceptions. The group ultimately develops a consensus view that gets recorded on a visual risk map, recommends action plans, and designates an “owner” for each major risk.
|
||||
|
||||
Hydro One strengthens accountability by linking [capital](https://hbr.org/2020/05/what-managers-get-wrong-about-capital) allocation and budgeting decisions to identified risks.
|
||||
|
||||
**Embedded experts**
|
||||
For companies in highly volatile environments (such as the financial services industry), risk management requires embedded experts within the organization to continuously monitor and influence the business’s risk profile, working side by side with the line managers whose activities are generating new ideas, innovation, risks, and profits.
|
||||
The chief danger from embedding risk managers within the line organization is that they “go native,” aligning themselves with the inner circle of the business unit’s leadership team—becoming deal makers rather than deal questioners.
|
||||
|
||||
### Managing External Risks
|
||||
Different approaches can be used, see article:
|
||||
- tail-risk stress tests
|
||||
- scenario planning
|
||||
- war-gaming
|
||||
|
||||
|
||||
## Avoid Risk Silo's
|
||||
Companies tend to label and compartmentalize risk categories, e.g. financial risk, operational risk, reputation risk, supply chain risk, HR risk and IT risk. This creates the problem of risk silo's, inhibiting discussion of how risks interact, and lead to ineffective risk management.
|
||||
|
||||
## The Leadership Challenge
|
||||
Risk management focuses on the negative instead of the positive, and runs exactly counter to the “can do” culture most leadership teams try to cultivate.
|
||||
Risk management typically involves 'dispersing?' resources away from primary goals. That's why most companies need a separate function to handle strategy- and external-risk management.
|
||||
|
||||
a company’s ability to weather storms depends very much on how seriously executives take their risk-management function when the sun is shining and no clouds are on the horizon.
|
||||
|
||||
That was what separated the banks that failed in the financial crisis from those that survived. The failed companies had relegated risk management to a compliance function; their risk managers had limited access to senior management and their boards of directors.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
Laatste retrieval date: 5 februari 2025
|
||||
"We are planning to announce the release of the **OWASP Top 10:2025** in the first half of 2025"
|
||||
|
||||
https://owasp.org/Top10/
|
||||
|
||||
|
||||
Binary file not shown.
Binary file not shown.
|
|
@ -0,0 +1,65 @@
|
|||
# Risico's uit de praktijk
|
||||
|
||||
A [List of Post-Mortems](https://github.com/danluu/post-mortems) on Github
|
||||
|
||||
Search terms: Human Risk Human Error Breaches Incidents
|
||||
|
||||
## Voorbeelden van incidenten door menselijk handelen
|
||||
|
||||
[Als Word file, geanonimiseerd](../Voorbeelden%20van%20incidenten%20door%20menselijk%20handelen.docx)
|
||||
|
||||
March 2025: Google lets Chromecast SSL certificate expire.
|
||||
https://www.pcworld.com/article/2632196/some-older-chromecasts-are-suddenly-untrusted-cant-cast-anymore.html
|
||||
Door het laten verlopen van een SSL certificaat kunnen gebruikers wereldwijd enkele dagen hun Google Chromecast niet gebruiken (dus geen Netflix of YouTube streamen naar de TV).
|
||||
|
||||
### Haga-ziekenhuis
|
||||
sept 2019: Dienstoverdrachten worden gebruikt als boodschappenbriefjes en worden gevonden in winkelkarretje
|
||||
april 2018: 85 medewerkers bekijken ongeoorloofd het dossier van realityster Samantha de Jong ('Barbie')
|
||||
|
||||
### NL Healthcare / Orthopedium
|
||||
- Orthopedium: sinds software update kunnen de röntgenscanner en het EPD niet meer met elkaar overweg: het patiëntnummer moet opgezocht worden in het EPD en handmatig worden ingegeven in de software van de röntgenscanner
|
||||
- Orthopedium: de werkstations in de OK starten heel traag op. De afdelingssecretaresse heeft de inloggegevens van alle artsen in haar agenda, en logt ze ‘s ochtends alvast in. Daarbij rouleren operatieploegen gedurende de dag over de OK’s, zonder opnieuw in te loggen. Hierdoor worden verrichtingen geregistreerd op de verkeerde behandelaar. Dit wordt achteraf handmatig gecorrigeerd aan de hand van de planning van die dag.
|
||||
### Nederlandse Zorg Autoriteit
|
||||
- NZA: de onbeheerde netwerkmap voor de vakantiefoto’s, waar iedereen met een NZA-account bij kon, werd al snel ontdekt als plek om gemakkelijk grote dossiers en bestanden met elkaar te delen. Meestal werden die daarna niet verwijderd.
|
||||
- https://www.nrc.nl/nieuws/2014/04/10/iedereen-kon-grasduinen-op-de-v-schijf-1364850-a1395507
|
||||
### Prestige Data Breach
|
||||
Een goed werkend Proof of Concept wordt zonder de nodige veiligheidswaarborgen in productie genomen, met dramatische gevolgen.
|
||||
- [Prestige Data Breach](https://rkranendonk.medium.com/learning-points-from-the-prestige-data-breach-eac454b577d3)
|
||||
- Slechte architectuur: manipulatie van tekstbestanden op een file systeem i.p.v. een robuuste database
|
||||
- Publieke / te ruime toegang AWS Bucket door slechte configuratie of Free Tier (bijv. Miro)
|
||||
- Niet toepassen encryptie
|
||||
- Gegevens langer bewaren dan nodig
|
||||
- Meer gegevens verwerken dan nodig
|
||||
- In productie nemen van PoC oplossing
|
||||
### Junis
|
||||
- Versleuteld mailen werkt niet bij alle ketenpartners – het beleid is om gegevens over kinderen en ouders alleen versleuteld naar de samenwerkingspartners te mailen. Bij sommige ontvangers werkte het ontsleutelen van de mail niet goed, door een afwijkende configuratie van de mailserver. Dan maar onversleuteld verzenden, want het werk moet door. Dit werd wel gemeld bij ICT, maar omdat de zaken in de eigen systemen correct geconfigureerd was, werd het niet als probleem gezien.
|
||||
- Communicatie met ouders via WhatsApp – want het lukt niet alle ouders om de speciale app te installeren
|
||||
- Deurcodes pand worden aan ouders gegeven
|
||||
- Sleutels worden meegegeven aan externe onderhoudsmonteurs
|
||||
- Werken met beperkt aantal voorkeursleveranciers vergroot de afhankelijkheid
|
||||
- Ontbrekende of onvolledige verantwoording subsidieaanvraag onder tijdsdruk
|
||||
- Onvoorziene consequenties van eigen veranderingen en handelen voor andere afdelingen
|
||||
- Onvoorziene consequenties van veranderingen en handelen andere afdelingen voor ons
|
||||
- Minder mogelijkheden voor handmatig ingrijpen door toegenomen integratie
|
||||
- Niet tijdige of incorrecte mutatie in AFAS betekent geen toegang tot de juiste informatie op Intranet voor medewerker cluster
|
||||
- Verkeerde mdw/locatie in Qebble door onjuiste kostenplaats in AFAS/HR; kwaliteit roostering gaat omlaag
|
||||
- Makkelijk bestellen zonder verder gedoe – risico op foute invoer, verantwoordelijkheid correcte invoer verschuift naar verderop in het proces
|
||||
- Kinderopvangtoeslag – Problemen door ontbreken noodzakelijke kennis bij ouders
|
||||
- Ondersteuning IT zaken te weinig beschikbaar, onduidelijkheid waar je terecht moet (IT of FAB)
|
||||
- Verzenden cadeaus gastouders door derden vraagt om verstrekking NAW-gegevens
|
||||
- Indeling gegevens in verschillende bronsystemen matcht niet
|
||||
- Gevoelige informatie publiceren op verkeerde plek op SharePoint (wegens onduidelijke structuur en ontbreken aan instructies
|
||||
- Onvoldoende bewustzijn bij mdws over de toegankelijkheid van verschillende sites op Intranet en SharePoint
|
||||
- Weekberichten worden niet opgeslagen in Groepssites, maar in Clustersites, waar ook gevoelige informatie kan staan zoals ontruimingsplannen
|
||||
- PM’ers hebben privé telefoons en geen Office365 licentie. Hoe moeten ze Teams Chat gebruiken als WhatsApp niet mag? En communicatie met ouders kan ook niet via Teams.
|
||||
- Alle medewerkers met privemail-adres in CC personeelsnieuwsbrief
|
||||
- Gevoelige informatie wordt verstuurd naar privé adressen, bijv. in Weekbericht
|
||||
- Op een telefoon kun je Teams openen zonder in te loggen – unlock telefoon is genoeg
|
||||
- Gebruik beelden van kinderen niet mogelijk door niet aanleveren toestemmingsformulieren door PM'ers
|
||||
- Werken met iPads: invullen formulieren online werkt n iet goed, dan maar mailen naar huisadres en terug.
|
||||
- Zeer groot dienstverleners-landschap!
|
||||
- Gevoelige info besprekingen op vergaderbordjes / Onderwerp bespreking uit Outlook kan gevoelige info bevatten
|
||||
- PM’er maakt WhatsApp groepje aan voor ouders – niet alle ouders zijn er blij mij dat hun tel.nr. nu voor iedereen zichtbaar is
|
||||
- Secretariaat: Kans op insluipers wegens ontbreken sluitronde door beveiligingsfirma
|
||||
### Parnassia groep
|
||||
- In EPD kan niet gezocht worden op BSN, daardoor wordt gezocht op andere kenmerken. Gevolg is dat patiënten dubbel worden ingeschreven, en behandelingen/afspraken aan de verkeerde patient gekoppeld worden
|
||||
64
Corpus/Information Security/Risks/Risk Register Format.md
Normal file
64
Corpus/Information Security/Risks/Risk Register Format.md
Normal file
|
|
@ -0,0 +1,64 @@
|
|||
# Risk Register Format
|
||||
|
||||
According to ChatGPT on October 8, 2024 – Prompt: `what would be the elements in an information security risk register? Make it compliant with ISO 27002`
|
||||
|
||||
An information security risk register compliant with ISO/IEC 27002 is a key tool for managing and documenting risks associated with information security within an organization. ISO/IEC 27002 provides guidelines for organizational information security standards and information security management practices. Below are the elements typically found in a risk register aligned with these guidelines:
|
||||
|
||||
1. **Risk ID**:
|
||||
- A unique identifier for each risk to facilitate easy tracking and reference.
|
||||
|
||||
2. **Risk Description**:
|
||||
- A detailed explanation of the risk, including the nature of the risk, affected assets, and potential impacts.
|
||||
|
||||
3. **Assets Involved**:
|
||||
- Identification of the information assets associated with the risk. This can include data, hardware, software, or any resource that could be impacted.
|
||||
|
||||
4. **Risk Owner**:
|
||||
- The individual responsible for managing and monitoring the risk.
|
||||
|
||||
5. **Threat Source**:
|
||||
- Details about the origin or source of the threat that might exploit vulnerabilities in assets (e.g., internal, external, environmental).
|
||||
|
||||
6. **Vulnerability**:
|
||||
- A description of the weaknesses that could be exploited by the identified threats.
|
||||
|
||||
7. **Potential Impact**:
|
||||
- An assessment of the impact on the organization if the risk materializes (e.g., financial, reputational, operational).
|
||||
|
||||
8. **Likelihood of Occurrence**:
|
||||
- An assessment or rating of how likely it is that the risk event will occur.
|
||||
|
||||
9. **Risk Level**:
|
||||
- A calculated risk level, combining impact and likelihood to prioritize risks (e.g., low, medium, high).
|
||||
|
||||
10. **Existing Controls**:
|
||||
- Current controls in place designed to mitigate the risk. This could include technical, administrative, or physical controls.
|
||||
|
||||
11. **Effectiveness of Controls**:
|
||||
- Evaluation of how effective the current controls are in mitigating the risk.
|
||||
|
||||
12. **Risk Treatment Plan**:
|
||||
- A description of actions planned to mitigate, transfer, accept, or avoid the risk. This should follow the risk treatment strategy.
|
||||
|
||||
13. **Additional Controls Needed**:
|
||||
- Recommendations for additional controls or improvements needed to further mitigate or manage the risk.
|
||||
|
||||
14. **Residual Risk**:
|
||||
- The remaining risk after current and planned controls have been considered.
|
||||
|
||||
15. **Target Mitigation Date**:
|
||||
- The planned date by which risk mitigation actions should be implemented.
|
||||
|
||||
16. **Review Date**:
|
||||
- The date when the risk was last reviewed and when it should be reviewed next for any changes in status or control effectiveness.
|
||||
|
||||
17. **Status**:
|
||||
- The current status of the risk management process (e.g., new, in progress, mitigated, up for re-evaluation).
|
||||
|
||||
18. **Comments/Notes**:
|
||||
- Any additional information or notes relevant to the risk and its management.
|
||||
|
||||
19. **Approval and Sign-off**:
|
||||
- Details of who approved and signed off on the risk assessment and treatment plan.
|
||||
|
||||
The risk register should be regularly updated and reviewed to reflect changes in the risk landscape and incorporate new threats or vulnerabilities. This aligns with ISO/IEC 27002's emphasis on continuous improvement and adapting to the evolving security environment.
|
||||
Binary file not shown.
|
|
@ -0,0 +1,17 @@
|
|||
# Risk appetite definitions
|
||||
|
||||
Risk appetite is "The types and amount of risk, on a broad level, an organization is willing to accept in its pursuit of value." – [NIST](https://csrc.nist.gov/glossary/term/risk_appetite)
|
||||
|
||||
According to the PMBOK® Guide [(source)](http://cybersecurity-materiality.com/):
|
||||
- Risk Tolerance is the _"specified range of acceptable results."_
|
||||
- Risk Threshold is the _"level of risk exposure above which risks are addressed and below which risks may be accepted."_
|
||||
- Risk Appetite is the _"degree of uncertainty an organization or individual is willing to accept in anticipation of a reward."_
|
||||
|
||||
Articulate the risk appetite to:
|
||||
|
||||
- help guide risk and reward decision-making
|
||||
- help to embed the right risk culture
|
||||
|
||||
See [Collection of Kanban boards on information security topics](../Collection%20of%20Kanban%20boards%20on%20information%20security%20topics.md) for inspiration.
|
||||
|
||||
See also [Risk tolerance](..//Risk%20tolerance.md)
|
||||
7
Corpus/Information Security/Risks/Risk identification.md
Normal file
7
Corpus/Information Security/Risks/Risk identification.md
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
# Three Risk Identification Questions
|
||||
|
||||
Three Risk Identification Questions You Should Be Asking – according to this FAIR institute [blogpost](https://www.fairinstitute.org/blog/3-risk-identification-questions-you-should-be-asking):
|
||||
|
||||
1. Where are we experiencing loss today?
|
||||
2. What keeps you up at night?
|
||||
3. What are our most valuable assets, and what could happen to them that would lead to loss for our organization?
|
||||
30
Corpus/Information Security/Risks/Risk inventories.md
Normal file
30
Corpus/Information Security/Risks/Risk inventories.md
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
# Risk Inventories
|
||||
|
||||
See also:
|
||||
- [Threat Catalogues](../📚️%20Literature%20notes/Threat%20Catalogues.md)
|
||||
- [Software vulnerability databases](Software%20vulnerability%20databases.md)
|
||||
|
||||
[NEN7510 Risicos](../../Standards/ISO27x/OST/7510/NEN7510%20Risicos.md)
|
||||
|
||||
Zie ook:
|
||||
- map Risk and Threat modelling op icloud drive
|
||||
- Privacy schendingen van Daniel Solove, Kwetsbaarheden van ondersteunende bedrijfsmiddelen van de CNIL, Onvoorzien eigenlijk gebruik van Piims (BC 5701 cursusmap, Tab 5, Bijlagen 2 t/m 4)
|
||||
- Bijlage 2-4 van BC 5701 Risicomanagement (cursusmap)
|
||||
|
||||
[CSIAC evaluation of threat taxonomies](https://csiac.org/articles/evaluation-of-comprehensive-taxonomies-for-information-technology-threats/)
|
||||
[SCF Risk Categories for Establishing a Risk Catalog](../../Standards/other/SCF%20Risk%20Categories%20for%20Establishing%20a%20Risk%20Catalog.md)
|
||||
[SCF Threat Categories for Establishing a Threat Catalog](../../Standards/other/SCF%20Threat%20Categories%20for%20Establishing%20a%20Threat%20Catalog.md)
|
||||
|
||||
[](Taxonomy%20of%20Operational%20Cyber%20Security%20Risks.pdf)
|
||||
[CRF Threat Taxonomy 2024](CRF-Threat-Taxonomy-v2024.pdf)
|
||||
[Enisa Threat Taxonomy](https://www.enisa.europa.eu/topics/cyber-threats/threats-and-trends/enisa-threat-landscape/threat-taxonomy)
|
||||
[MITRE ATT&CK](https://attack.mitre.org)
|
||||
[MITRE D3FEND](https://d3fend.mitre.org)
|
||||
[](Open%20Group%20Risk%20Taxonomy%20Standard%203.01.pdf)
|
||||
[OWASP Top 10 CI-CD Security Risks](../../Standards/other/OWASP%20Top%2010%20CI-CD%20Security%20Risks.md)
|
||||
[Splunk Top 50 Security threats](https://www.splunk.com/pdfs/ebooks/top-50-security-threats.pdf)
|
||||
[Austin Songer's risk catalogue](https://songer.pro/risk-catalogue/), seemingly based on SCF's [SCF's SP-RMM Risk Management Model](../../Standards/SP-RMM%20Risk%20Management%20Model.pdf), which is also used in the [Risk Register Template Hyperproof](Risk%20Register%20Template%20Hyperproof.xlsx).
|
||||
|
||||
|
||||
[Risks of using personal email accounts in the workplace](Risks%20of%20using%20personal%20email%20accounts%20in%20the%20workplace.md)
|
||||
[Shadow IT risks](Shadow%20IT%20risks.md)
|
||||
36
Corpus/Information Security/Risks/Risk management.md
Normal file
36
Corpus/Information Security/Risks/Risk management.md
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
# Risk Management
|
||||
|
||||
#security/isms/risk_mgt
|
||||
|
||||
https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8286.pdf
|
||||
|
||||
https://securityboulevard.com/2020/12/why-you-need-to-have-a-risk-register-to-keep-track-of-cybersecurity-risks/
|
||||
|
||||
NIST recommends that organizations take a balanced view when evaluating risks, encouraging cybersecurity and risk professionals to identify “all sources of uncertainty — both positive (opportunities) and negative (threats)” in their risk registers.
|
||||
For instance, launching a new online service provides an opportunity for a company to innovate and improve its revenues, thus the leadership team may direct the organization to take a little more risk. This way, senior leaders can set the risk appetite and tolerance with both threats and opportunities in mind.
|
||||
When cybersecurity opportunities are included in a risk register, NIST recommends updating the risk response column using one of the following response types and describes the meaning of each:
|
||||
* Realize: Eliminate uncertainty to make sure the opportunity is actualized
|
||||
* Share: Allocate ownership to another party that is better able to capture the opportunity
|
||||
* Enhance: Increase the probability and positive impact of an opportunity
|
||||
* Accept: Take advantage of an opportunity if it happens to present itself
|
||||
|
||||
## Risk Register
|
||||
When you maintain detailed cybersecurity risk information in your risk register, you’re able to manage your cyber risks in a more strategic way, focus on the right areas given limited resources, and secure additional resources because your leadership team will start to understand the value of preventative security.
|
||||
Here are the key benefits of putting cyber security risks into a risk register:
|
||||
1. Once information is entered into a risk register, you can start to identify patterns from threats and system failures that result in adverse impacts.
|
||||
2. By committing to using a risk register, you have to go through a process of gathering all relevant parties and agreeing on a common scale for measuring risks across various business units (e.g. making sure everyone knows when to use a “high risk exposure” vs. a “moderate risk exposure”). By normalizing the tracking of risk information across different units, you will provide senior leaders with more relevant information that will help them prioritize risk response activities.
|
||||
3. Company leaders will have greater confidence in the risk response choices they make because the responses will be informed by the right context, including detailed risk information, enterprise objectives, and budgetary guidance.
|
||||
4. A risk register forces risk owners to write down accurate risk responses for risks they “own”. To do so, risk owners will need to verify whether risks are mitigated to the extent they believe they’d done: Check whether certain policies are up-to-date, and whether existing controls intended to mitigate threats are working as designed. Risk owners will talk to their compliance team or internal audit team to understand where risk management activities and compliance activities already intersect. These steps are important because they ultimately help decision-makers understand their potential exposure for achieving strategic, operations, reporting, and compliance objectives.
|
||||
5. Maintaining a risk register makes it possible to produce enterprise-level risk disclosures for required filings and hearings or for formal reports as required, should your organization experience a significant incident.
|
||||
|
||||
# The Importance of Continuous Monitoring
|
||||
#security/isms/kpis
|
||||
|
||||
Risks and threat vectors can change in a matter of minutes. Thus, it’s important to keep an eye on your risks at all times. NIST’s latest guidance emphasizes the importance of continuous monitoring and outlines several ways to monitor risks on an ongoing basis, including:
|
||||
* Setting up positive KPIs such as the number of critical business systems that include strong authentication protections
|
||||
* Setting up negative KPIs, such as the number of severe customer disruptions in the last 90 days
|
||||
* Teaching employees about the types of cybersecurity risk issues most likely to occur within the organization
|
||||
* Showing employees how they can alert key personnel to cybersecurity risk issues before they become significant
|
||||
* Conduct risk response exercises to train employees in recognizing, reporting, and responding to cybersecurity incidents
|
||||
|
||||
|
||||
22
Corpus/Information Security/Risks/Risk ownership.md
Normal file
22
Corpus/Information Security/Risks/Risk ownership.md
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
# Risk Ownership
|
||||
|
||||
See also [Asset ownership](Asset%20ownership.md), [Control ownership](../../ISMS/Control%20ownership.md)
|
||||
|
||||
**ISO 27001 explicit mention of risk ownership:**
|
||||
- C 6.1.2 c2: Risks should have an owner
|
||||
- C 6.1.3 f: Risk owners’ must approve the risk treatment plan and accept residual risks
|
||||
|
||||
[Risk owners vs. asset owners in ISO 27001:2013 | Advisera](https://advisera.com/27001academy/knowledgebase/risk-owners-vs-asset-owners-in-iso-270012013/)
|
||||
|
||||
> ISO 27001 noemt specifiek de verantwoordelijkheid voor het accepteren van restrisico’s (A 6.1.1)
|
||||
>
|
||||
|
||||
|
||||
|
||||
> Eigenaarschap van een asset en de bijbehorende risico’s wordt meestal bij de ‘business’ gelegd, die persoon is nl. verantwoordelijk voor correcte omgang met ‘zijn’ assets. Eigenaarschap van technische maatregelen ligt in veel gevallen bij de IT-functie, maar kan bijv. ook onder Vendor management vallen. Andere voorbeelden zijn de maatregel Screening van nieuwe medewerkers (A 7.1.1), vaak is HR de eigenaar, en fysieke beveiliging (A 11), vaak bij een afdeling Facilitair.
|
||||
|
||||
Risk ownership can be separated from asset ownership, when the asset owner has no direct interest in controlling the risk, i.e. impact of the risk does not hurt the asset owner. For instance: the marketing manager may not experience a negative from a GDPR purpose limitation overtreding.
|
||||
The risk ownership can then be assigned to a third party, for example a compliance officer.
|
||||
|
||||
|
||||
See also [Transfer in Risk Treatment](../../ISMS/Transfer%20in%20Risk%20Treatment.md).
|
||||
1
Corpus/Information Security/Risks/Risk prioritization.md
Normal file
1
Corpus/Information Security/Risks/Risk prioritization.md
Normal file
|
|
@ -0,0 +1 @@
|
|||
[risk-based prioritization](https://www.brinqa.com/blog/basics-of-risk-based-prioritization/)
|
||||
10
Corpus/Information Security/Risks/Risk tolerance.md
Normal file
10
Corpus/Information Security/Risks/Risk tolerance.md
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
NIST gives [several definitions](https://csrc.nist.gov/glossary/term/risk_tolerance) of Risk tolerance. These are the most useful:
|
||||
|
||||
"The organization’s or stakeholder’s readiness to bear the risk after risk treatment in order to achieve its objectives. Note: Risk tolerance can be influenced by legal or regulatory requirements."
|
||||
|
||||
"The level of risk that the Manufacturer is willing to accept in pursuit of strategic goals and objectives."
|
||||
|
||||
"The level of risk or the degree of uncertainty that is acceptable to an organization."
|
||||
|
||||
See also [Risk appetite definitions](Risk%20appetite%20definitions.md)
|
||||
|
||||
19
Corpus/Information Security/Risks/Risk treatment.md
Normal file
19
Corpus/Information Security/Risks/Risk treatment.md
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
|
||||
The CISSP study guide gives the following 'Risk responses' in Domain 1 (§1.9.3):
|
||||
|
||||
- Reduce or mitigate – implementation of safeguards and countermeasures to eliminate vulnerabilities or block threats
|
||||
- Assign or transfer – placement of the cost of loss onto another entity; insurance and outsourcing are common forms
|
||||
- Accept – analysis shows countermeasure costs would outweigh the possible cost of loss; also management has agreed to accept the consequences
|
||||
- Deter – implementing deterrents to would-be violators of security and policy
|
||||
- Avoid – selecting alternate options or activities that have less associated risk
|
||||
- Reject or ignore – unacceptable
|
||||
|
||||
|
||||
PMP Concepts ([source](https://www.pmlearningsolutions.com/blog/announcement-ppm-launching-pmp-concept-learning-series)) lists "three proactive approaches to handling a negative risk":
|
||||
|
||||
* Avoid – eliminate the risk
|
||||
* Transfer – shift the impact to a 3rd party
|
||||
* Mitigate – decrease the probability or impact
|
||||
|
||||
See also [Examples of Risk Avoidance](../Examples%20of%20Risk%20Avoidance.md).
|
||||
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
Related: [a-5.17-Authentication-information](../../Standards/ISO27x/OST/27002/EN/a-5.17-Authentication-information.md)
|
||||
|
||||
Risk-Based Authentication (RBA) takes the normal user patterns into account (like location, devices, etc.) and requests extra authentication when abnormal activities occur.
|
||||
BIN
Corpus/Information Security/Risks/Risk_Assessment_Process.gif
Normal file
BIN
Corpus/Information Security/Risks/Risk_Assessment_Process.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.5 MiB |
37
Corpus/Information Security/Risks/Risks definitions.md
Normal file
37
Corpus/Information Security/Risks/Risks definitions.md
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
# Risk definitions
|
||||
|
||||
[Assets, Vulnerabilities, Threats, Risks](Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
|
||||
[Vulnerability](Vulnerability.md)
|
||||
[_Information security concepts MoC](../_Information%20security%20concepts%20MoC.md)
|
||||
[Assets, Vulnerabilities, Threats, Risks](../📚️%20Literature%20notes/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
|
||||
|
||||
|
||||
See also slide decks made for workshop sessions. Those for Kaliber, Nedap and Networking4AL are the most recent.
|
||||
|
||||
See also [Risk appetite definitions](Risk%20appetite%20definitions.md)
|
||||
See also [Classificatie van risico's](../../ISMS/Classificatie%20van%20risico's.md)
|
||||
|
||||
## Definitions
|
||||
[Source](http://cybersecurity-materiality.com/)
|
||||
|
||||
A **weakness** is a deficiency in controls where it is probable that reasonable threats will not be prevented or detected in a timely manner that directly, or indirectly, affects assurance that the organization can adhere to its stated risk tolerance.
|
||||
|
||||
A **risk** is a situation where someone or something valued is exposed to danger, harm or loss.
|
||||
|
||||
A **threat** is a person or thing likely to cause damage or danger.
|
||||
|
||||
An **incident** is an occurrence that actually or potentially jeopardizes the Confidentiality, Integrity, Availability or Safety (CIAS) of a system, application, service or the data that it processes, stores and/or transmits
|
||||
### Material risks
|
||||
A weakness, risk, threat or incident is considered 'material' if the potential financial impact exceeds one of the following thresholds[^1]:
|
||||
|
||||
- ≥ 5% of pre-tax profit;
|
||||
- ≥ 5% of revenue;
|
||||
- ≥ 1% of total equity; and/or
|
||||
- ≥ 0.5% of total assets.
|
||||
|
||||
[Source](http://cybersecurity-materiality.com/)
|
||||
|
||||
[^1]: SEC, Generally Accepted Accounting Principles (**GAAP**) and International Financial Reporting Standards (**IFRS**)
|
||||
|
||||
|
||||
**The official ISO definition of risk** is "the effect of uncertainty on objectives," meaning any circumstance, event, or issue that could impede or alter the achievement of an organization's goals, whether those effects are positive or negative deviations from what was expected. This definition is used within key standards like ISO 31000, ISO 27001, and ISO 9001, emphasizing that risk encompasses any factor that threatens or impacts an organization's ability to reach its intended outcomes.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# Risks of using personal email accounts in the workplace
|
||||
|
||||
[Source](https://www.doyleclayton.co.uk/resources/news/Using-personal-emails-for-work-purposes/)
|
||||
|
||||
## Business risks
|
||||
- Loss of audit trails / - Grijs communicatie circuit, ook met externen (klanten, leveranciers, concurrenten)
|
||||
- Difficulties retrieving data in case of litigation
|
||||
- Increases exposure to hackers due to lower protection level of personal devices
|
||||
- Increases exposure to hackers due to less 'prudent' behaviour on personal devices
|
||||
- Het is voor attackers denkelijk gemakkelijke om toegang te krijgen tot een privé mailbox en de inhoud daarvan te gebruiken voor phishing
|
||||
... both may lead to security breaches
|
||||
- Data leakage when company data remains in the individuals mailbox after he/she leaves the company
|
||||
- Loss of access/control/IPR when employee has admin-rights on SaaS app and leaves the company (possibily to a competitor) – Ultimaker case
|
||||
|
||||
|
||||
## GDPR related risks
|
||||
|
||||
Several GDPR obligations might not be met when personal data is sent to private mailboxes or is available on personal devices:
|
||||
- obligation to inform data subjects in case of a breach (you do not know who they are)
|
||||
- obligation to have appropriate security safeguards in place to protect personal data – permitting use of personal email addresses for work activity is likely to fall foul of this.
|
||||
- the individual will become the data controller instead of the organization, without the required data protection controls
|
||||
- if the individual moves to or is located overseas, it might constitute unlawful cross border transfer.
|
||||
- harder to comply with Data Subject Access Requests (DSARs) because they will not know what data is held, where it has gone and how long it is retained.
|
||||
|
||||
The ICO’s [detailed DSAR guidance](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/right-of-access/) also raises the possibility that personal email accounts do, sometimes, fall inside the scope of a DSAR. The guidance states:
|
||||
|
||||
- A policy should restrict staff’s permission to hold information about customers, contacts or other employees on their own devices, in private email accounts or on private instant messaging applications
|
||||
- Staff accessing systems remotely (for example via a secure website) should not hold personal data on equipment the employer does not control
|
||||
- If staff may hold personal data on their own devices, they might be processing that data on the employer’s behalf, so this could be within a DSAR’s scope. This depends on the purpose for which the employer holds the information, and its context
|
||||
- The ICO does not expect employers to instruct staff to search their private emails, personal devices or private instant messaging applications in response to a DSAR, unless the employer has a good reason to believe they are holding relevant personal data
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 87 KiB |
|
|
@ -0,0 +1,9 @@
|
|||
# Risks vs Threats vs Vulnerabilities
|
||||
[Source](https://securecontrolsframework.com/risk-management-model/)
|
||||
|
||||
Risks, threats and vulnerabilities are commonly misunderstood.
|
||||
|
||||
Fundamentally, vulnerability and risk management practices exist to achieve a minimum level of protection for an organization, which equates to a reduction in the total risk due to the protections offered by implemented controls. This can be conceptualized as a "risk management ecosystem" as it pertains to an organization's overall cybersecurity & data protection efforts.
|
||||
|
||||
These ecosystem components have unique meanings that need to be understood to reasonably protect people, processes, technology and data, as shown below:
|
||||

|
||||
Binary file not shown.
|
|
@ -0,0 +1,11 @@
|
|||
# Security Threat Modeling
|
||||
|
||||
[CISSP_OSG_Chapter_14](../../Standards/CISSP/CISSP_OSG_Chapter_14.md#Understanding%20access%20control%20attacks)
|
||||
|
||||
https://insights.sei.cmu.edu/blog/threat-modeling-12-available-methods/
|
||||
|
||||
Related:
|
||||
- [Create a threat analysis chatbot](../../Various/Create%20a%20threat%20analysis%20chatbot.md)
|
||||
|
||||
|
||||

|
||||
163
Corpus/Information Security/Risks/Shadow IT risks.md
Normal file
163
Corpus/Information Security/Risks/Shadow IT risks.md
Normal file
|
|
@ -0,0 +1,163 @@
|
|||
See also:
|
||||
- [Cloud Service Risk Mitigation Roadmap](../../ISMS/Policy%20examples/Cloud%20Service%20Risk%20Mitigation%20Roadmap.md)
|
||||
- [Shadow IT Policy for Responsible Technology Adoption](../../ISMS/Policy%20examples/Shadow%20IT%20Policy%20for%20Responsible%20Technology%20Adoption.md)
|
||||
- [Cloud Service Risk Assessment Guide](../../ISMS/Policy%20examples/Cloud%20Service%20Risk%20Assessment%20Guide.md)
|
||||
- [Cloud Service Approval Process](../../ISMS/Policy%20examples/Cloud%20Service%20Approval%20Process.md)
|
||||
- [Cloud Service Employee Guidelines](../../ISMS/Policy%20examples/Cloud%20Service%20Employee%20Guidelines.md)
|
||||
- [Surveys on Shadow IT usage](../Surveys%20on%20Shadow%20IT%20usage.md)
|
||||
|
||||
- [Dutch versions WiP](../../../Clients/Humankind/Beleid%20voor%20Gebruik%20van%20SaaS%20HK.md)
|
||||
|
||||
# Risks of Uncontrolled Cloud Software Usage
|
||||
|
||||
When employees independently choose and use cloud services, especially free tier:
|
||||
|
||||
## 1. Data Continuity and Availability Risks
|
||||
### 1.1 Loss of Data
|
||||
- Original Example: Loss of data through discontinuity of service
|
||||
- Detailed Implications:
|
||||
* Unexpected service termination
|
||||
* Lack of robust backup mechanisms
|
||||
* Potential permanent data loss
|
||||
* Disruption of critical business operations
|
||||
* Challenges in data recovery
|
||||
### 1.2 Service Reliability Challenges
|
||||
- Risks associated with free-tier or unsupported services:
|
||||
* Unpredictable service availability
|
||||
* Limited or no data preservation guarantees
|
||||
* No contractual obligations for data retention
|
||||
* Minimal disaster recovery provisions
|
||||
|
||||
## 2. Access Management Vulnerabilities
|
||||
### 2.1 Access Control Risks
|
||||
- Original Example: Loss of access because the service is registered on a personal account
|
||||
- Specific Concerns:
|
||||
* Individual employee account ownership
|
||||
* No centralized access management
|
||||
* Difficulty revoking access upon employee departure
|
||||
* Potential unauthorized continued access
|
||||
* Lack of systematic account tracking
|
||||
### 2.2 Authentication Challenges
|
||||
- Consequences of personal account registration:
|
||||
* Weak password practices
|
||||
* No multi-factor authentication enforcement
|
||||
* Inconsistent access security standards
|
||||
* Increased risk of unauthorized access
|
||||
|
||||
## 3. Data Privacy and Exposure Risks
|
||||
### 3.1 Personal Data Breaches
|
||||
- Original Example: Personal data breaches due to business model monetization
|
||||
- Detailed Risk Analysis:
|
||||
* Data used as product or revenue stream
|
||||
* Potential unauthorized data sharing
|
||||
* Lack of transparent data usage policies
|
||||
* Monetization through user information exploitation
|
||||
|
||||
### 3.2 Data Sharing and Exposure Mechanisms
|
||||
- Risks in free-tier service models:
|
||||
* Using customer data as example use cases
|
||||
* Potential public exposure of sensitive information
|
||||
* Limited user consent mechanisms
|
||||
* Unclear data anonymization practices
|
||||
|
||||
## 4. Compounded Risk Scenarios
|
||||
|
||||
### 4.1 Integrated Risk Landscape
|
||||
Combining the original examples reveals complex vulnerabilities:
|
||||
- Personal accounts increase data breach potential
|
||||
- Service discontinuity amplifies data loss risks
|
||||
- Monetization models compromise data privacy
|
||||
- Lack of centralized control exacerbates security challenges
|
||||
|
||||
## 5. Mitigation Strategies
|
||||
### 5.1 Comprehensive Risk Reduction
|
||||
- Implement centralized cloud service governance
|
||||
- Develop clear account management protocols
|
||||
- Establish rigorous vendor assessment processes
|
||||
- Create employee training on data protection
|
||||
- Develop robust backup and recovery mechanisms
|
||||
### 5.2 Technical Safeguards
|
||||
- Centralized identity and access management
|
||||
- Regular security audits of cloud services
|
||||
- Implement data loss prevention technologies
|
||||
- Develop comprehensive data retention policies
|
||||
- Create secure data migration and exit strategies
|
||||
## 6. Organizational Resilience
|
||||
### 6.1 Cultural Transformation
|
||||
- Foster a security-aware organizational culture
|
||||
- Encourage responsible technology adoption
|
||||
- Create transparent communication channels
|
||||
- Develop collaborative IT governance models
|
||||
### 6.2 Continuous Improvement
|
||||
- Regular risk assessment processes
|
||||
- Adaptive security policies
|
||||
- Ongoing employee education
|
||||
- Dynamic vendor management approach
|
||||
|
||||
# Alternative enumeration
|
||||
## Compliance and Regulatory Violations
|
||||
- GDPR requirements
|
||||
- HIPAA regulations (if health-related information is involved)
|
||||
- Local child protection and data privacy laws
|
||||
- Industry-specific compliance standards
|
||||
## Lack of Centralized Security Control
|
||||
- No centralized security policy enforcement
|
||||
- Inconsistent security configurations
|
||||
- Inability to implement organization-wide security standards
|
||||
- Difficult to conduct comprehensive security audits
|
||||
- No standardized access management
|
||||
## Authentication and Access Management Risks
|
||||
- Weak or reused passwords
|
||||
- Lack of multi-factor authentication
|
||||
- No centralized identity management
|
||||
- Difficulty revoking access when employees leave
|
||||
- Potential for unauthorized account sharing
|
||||
## Data Sovereignty and Geographical Risks
|
||||
Free-tier cloud services might:
|
||||
- Store data in jurisdictions with different privacy laws
|
||||
- Have unclear data residency policies
|
||||
- Potentially expose sensitive information to international data transfer risks
|
||||
- Lack transparency about data center locations
|
||||
## Integration and Interoperability Vulnerabilities
|
||||
Uncontrolled software adoption can lead to:
|
||||
- Incompatible systems and data silos
|
||||
- Increased attack surface through multiple integration points
|
||||
- Potential security gaps between different cloud services
|
||||
- Challenges in data migration and consolidated security monitoring
|
||||
## Malware and Third-Party Risk
|
||||
Free-tier cloud services might introduce:
|
||||
- Higher risk of malware infiltration
|
||||
- Less rigorous vendor security screening
|
||||
- Potential integration with other unknown third-party services
|
||||
- Limited security update and patch management
|
||||
## Unsupported and Obsolete Software Risks
|
||||
- Services might discontinue free tiers unexpectedly
|
||||
- Limited or no technical support
|
||||
- Delayed or non-existent security patches
|
||||
- Potential end-of-life scenarios leaving data vulnerable
|
||||
## Shadow IT Proliferation
|
||||
Uncontrolled adoption can:
|
||||
- Create a culture of bypassing IT governance
|
||||
- Encourage further unauthorized software usage
|
||||
- Undermine organizational security policies
|
||||
- Create unpredictable IT infrastructure complexity
|
||||
## Intellectual Property and Confidentiality Risks
|
||||
Free-tier services might:
|
||||
- Include broad terms of service allowing data mining
|
||||
- Grant service providers extensive usage rights
|
||||
- Enable unintended sharing of confidential information
|
||||
- Compromise organizational intellectual property
|
||||
## Financial and Resource Allocation Risks
|
||||
- Potential hidden costs of "free" services
|
||||
- Inefficient software licensing
|
||||
- Duplicated functionality across different services
|
||||
- Unexpected migration or transition expenses
|
||||
# Recommended Mitigation Strategies
|
||||
|
||||
- Develop a comprehensive Shadow IT policy
|
||||
- Implement cloud service approval processes
|
||||
- Conduct regular security awareness training
|
||||
- Use Cloud Access Security Brokers (CASB)
|
||||
- Establish clear guidelines for cloud service selection
|
||||
- Centralize and standardize cloud service procurement
|
||||
|
||||
|
|
@ -0,0 +1 @@
|
|||
[OSV.dev: A distributed vulnerability database for Open Source](https://osv.dev)
|
||||
BIN
Corpus/Information Security/Risks/TLP_Impact_matrix_NL.xlsx
Normal file
BIN
Corpus/Information Security/Risks/TLP_Impact_matrix_NL.xlsx
Normal file
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 138 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 138 KiB |
Binary file not shown.
28
Corpus/Information Security/Risks/Threat Catalogues.md
Normal file
28
Corpus/Information Security/Risks/Threat Catalogues.md
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
See also [Risk inventories](Risk%20inventories.md)
|
||||
|
||||
https://cs4e.pages.labranet.jamk.fi/ooc/30-Cyber_Attack/01-Threats_and_Attacks/
|
||||
|
||||
Austin Songer has published a [threat catalogue](https://songer.pro/threat-catalogue/), seemingly based on the [HITRUST Threat Catalogue](https://hitrustalliance.net/product-tool/hitrust-threat-catalogue/)
|
||||
|
||||
## Voor Nederland
|
||||
|
||||
**MAPGOOD**
|
||||
[Bron: VNG](https://www.informatiebeveiligingsdienst.nl/product/handreiking-diepgaande-risicoanalyse-methode-gemeenten/)
|
||||
MAPGOOD = Mensen, Apparatuur, Programmatuur, Gegevens, Organisatie, Omgeving en Diensten
|
||||
|
||||

|
||||

|
||||
|
||||
**RAVIB**
|
||||
[Bron](https://www.ravib.nl/files/Offline%2520dreigingsanalyse.ods)
|
||||

|
||||
[RAVIB dreigingen en maatregelen 2022](https://www.ravib.nl/koppelingen) (dropdown selecteert 2022)
|
||||
|
||||
NEN7510: 54 risico’s uit het Praktijkhandboek.
|
||||
|
||||
LINDDUN GO
|
||||
|
||||
OWASP
|
||||
RISMAN
|
||||
Data Maturity Models, zie [Data maturity model NL overheid](../../Standards/Data%20maturity%20model%20NL%20overheid.md)
|
||||
|
||||
BIN
Corpus/Information Security/Risks/Threat scenario elements.jpeg
Normal file
BIN
Corpus/Information Security/Risks/Threat scenario elements.jpeg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 149 KiB |
12
Corpus/Information Security/Risks/Threats MoC.md
Normal file
12
Corpus/Information Security/Risks/Threats MoC.md
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
# Threats MoC
|
||||
|
||||
[Risks vs Threats vs Vulnerabilities](Risks%20vs%20Threats%20vs%20Vulnerabilities.md)
|
||||
|
||||
[Threat Intelligence](../Threat%20Intelligence.md)
|
||||
[Threat intelligence sources](../Threat%20intelligence%20sources.md)
|
||||
[Threat Modeling](Security%20Threat%20Modeling.md)
|
||||
[Threat Catalogues](Threat%20Catalogues.md)
|
||||
[SCF Threat Categories for Establishing a Threat Catalog](../../Standards/other/SCF%20Threat%20Categories%20for%20Establishing%20a%20Threat%20Catalog.md)
|
||||
[Privacy Threat Modeling](../../Various/Privacy%20Threat%20Modeling.md)
|
||||
[Security Threat Modeling](Security%20Threat%20Modeling.md)
|
||||
|
||||
Binary file not shown.
|
|
@ -0,0 +1,15 @@
|
|||
Source version date: 4 oktober 2021
|
||||
Accessed: 14 oktober 2021
|
||||
https://danielmiessler.com/blog/its-time-for-vendor-security-2-0/
|
||||
|
||||
## It's Time for Vendor Security 2.0 - Daniel Miessler
|
||||
|
||||
Miessler proposes treating vendors and vendor solutions as a risk and perform a Vendor Risk Assessment on them: look for "an understanding of 1) the integration of that vendor into your business, 2) what could go wrong if/when they were/are compromised, and 3) what you can do to mitigate that risk".
|
||||
|
||||
Assume a breach will happen and take preventive measures to reduce the impact, by improving the risk visibility, and look for ways to reduce the scope, penetration, and access that the vendor tool has to minimum levels.
|
||||
|
||||
Related:
|
||||
- [Awareness](../Sparks/Awareness.md)
|
||||
- [Vendor security MoC](../../ISMS/Vendor%20security%20MoC.md)
|
||||
- [Risk analysis methods](../../ISMS/Risk%20analysis%20methods.md)
|
||||
|
||||
18
Corpus/Information Security/Risks/Vulnerability.md
Normal file
18
Corpus/Information Security/Risks/Vulnerability.md
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
# Vulnerability
|
||||
A vulnerability is a weakness that exposes an asset to possible compromise. Weaknesses can be organizational, logical, physical, or human.
|
||||
|
||||
|
||||
|
||||
See also:
|
||||
- [Assets](..//Assets.md)
|
||||
- [Risks](..//Risks.md)
|
||||
- [Threat](../📚️%20Literature%20notes/Threat.md)
|
||||
- [Vulnerability Disclosure Policy](../../ISMS/Policy%20examples/Vulnerability%20Disclosure%20Policy.md)
|
||||
- [Dealing with a reported application vulnerability](../Dealing%20with%20a%20reported%20application%20vulnerability.md)
|
||||
- [Software vulnerability databases](Software%20vulnerability%20databases.md)
|
||||
- (https://www.google.nl/search?q=software+vulnerability+databases)
|
||||
- [API Endpoint Vulnerabilities](https://www.reblaze.com/blog/api-security/how-hackers-attack-your-mobile-apps-part-3-api-endpoint-vulnerabilities/)
|
||||
- [NSA and CISA publish hardening guides](https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/2716980/nsa-cisa-release-kubernetes-hardening-guidance/utm_source/nsa-cisa-release-kubernetes-hardening-guidance/)
|
||||
- [ISO 27001 A 12.6 Technical vulnerability management](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.6%20Technical%20vulnerability%20management.md)
|
||||
- [a-8.8-Management-of-technical-vulnerabilities](../../Standards/ISO27x/OST/27002/EN/a-8.8-Management-of-technical-vulnerabilities.md)
|
||||
|
||||
BIN
Corpus/Information Security/Risks/risk-matrix-example.numbers
Normal file
BIN
Corpus/Information Security/Risks/risk-matrix-example.numbers
Normal file
Binary file not shown.
Loading…
Add table
Add a link
Reference in a new issue