cleaning up Sparks
This commit is contained in:
parent
b8d1d4e02f
commit
704e6dd07f
162 changed files with 393 additions and 1041 deletions
84
Corpus/Sparks/Information Security/CIS Controls.md
Normal file
84
Corpus/Sparks/Information Security/CIS Controls.md
Normal file
|
|
@ -0,0 +1,84 @@
|
|||
# CIS Critical Security Controls
|
||||
|
||||
https://www.cisecurity.org/controls
|
||||
|
||||
Cyber attacks exploit bad cyber hygiene
|
||||
CIS are security best practices for strengthening your security posture to defend agains top threats
|
||||
|
||||
maps to lots of frameworks
|
||||
|
||||
Safeguards are identified by attack patterns from the MITRE ATT&CK* framework
|
||||
we verified that the CIS Controls are effective at defending against 86% of the ATT&CK (sub-)techniques found in the ATT&CK framework. More importantly, the Controls are highly effective against the top five attack types found in industry threat data.
|
||||
|
||||
|
||||
Source: CIS Community Defense Model version 2.0
|
||||
|
||||
|
||||
3 levels:
|
||||
IG1, 2 and 3
|
||||
These CIS Controls Implementation Groups (IGs) are ment as a guidance to prioritize implementation.
|
||||
|
||||
IG1 is defined as “essential cyber hygiene”, targeted to small to medium-sized enterprises with limited IT and cybersecurity expertise.
|
||||
Their main concern is operational continuity.
|
||||
IG1 Safeguards are aimed to thwart general, non-targeted attacks.
|
||||
|
||||
IG2 enterprises have dedicated security staff, multiple departments with differing risk profiles, and regulatory compliance burdens.
|
||||
A major concern is loss of public confidence if a breach occurs.
|
||||
IG2 Safeguards help security teams cope with increased operational complexity.
|
||||
|
||||
IG3 enterprises employ security experts that specialize in the different facets of cybersecurity.
|
||||
IG3 assets contain sensitive information or functions that are subject to regulatory and compliance oversight. An IG3 enterprise must address availability of services and the confidentiality and integrity of sensitive data. Successful attacks can cause significant harm to the public welfare.
|
||||
Safeguards selected for IG3 must abate targeted attacks from a sophisticated adversary and reduce the impact of zero-day attacks.
|
||||
|
||||
|
||||
|
||||
Source: CIS Controls v8.1 PDF, pp 8-12
|
||||
|
||||
|
||||
List of the CIS Controls in v8, and how many Safeguards in each are applicable to each Implementation Group. [source](https://www.cisecurity.org/controls/implementation-groups)
|
||||
|
||||
See CIS_Controls_Version_8.1_6_24_2024.xlsx for a table that shows all safeguards mapped to the three Implementation Groups.
|
||||
|
||||
### CIS version 8 has 18 controls, you only gave me 9. Can you make this complete?
|
||||
|
||||
Certainly! Here's a complete table including all 18 CIS Controls in Version 8, with simplified implementation group indications. This serves as a high-level overview and the specifics for each safeguard would need to be obtained from the official CIS documentation.
|
||||
|
||||
| CIS Control | Safeguard (Control ID) | IG 1 | IG 2 | IG 3 |
|
||||
| --------------------------------------------------------- | ---------------------------------------- | ---- | ---- | ---- |
|
||||
| 1. Inventory and Control of Enterprise Assets | 1.1 Inventory of Assets | ✓ | ✓ | ✓ |
|
||||
| | 1.2 Address Unauthorized Assets | ✓ | ✓ | ✓ |
|
||||
| 2. Inventory and Control of Software Assets | 2.1 Inventory of Software | ✓ | ✓ | ✓ |
|
||||
| | 2.2 Address Unauthorized Software | ✓ | ✓ | ✓ |
|
||||
| 3. Data Protection | 3.1 Data Management | ✓ | ✓ | ✓ |
|
||||
| | 3.2 Data Recovery | | ✓ | ✓ |
|
||||
| 4. Secure Configuration of Enterprise Assets and Software | 4.1 Establish Secure Configurations | ✓ | ✓ | ✓ |
|
||||
| | 4.2 Secure Configuration Management | | ✓ | ✓ |
|
||||
| 5. Account Management | 5.1 Account Inventory | ✓ | ✓ | ✓ |
|
||||
| | 5.2 Admin Account Management | ✓ | ✓ | ✓ |
|
||||
| 6. Access Control Management | 6.1 Access Control Policy | ✓ | ✓ | ✓ |
|
||||
| | 6.2 Access Granting | ✓ | ✓ | ✓ |
|
||||
| 7. Continuous Vulnerability Management | 7.1 Vulnerability Scanning | ✓ | ✓ | ✓ |
|
||||
| | 7.2 Vulnerability Remediation | | ✓ | ✓ |
|
||||
| 8. Audit Log Management | 8.1 Log Retention and Management | ✓ | ✓ | ✓ |
|
||||
| | 8.2 Log Review | | ✓ | ✓ |
|
||||
| 9. Email and Web Browser Protection | 9.1 Email Protection | ✓ | ✓ | ✓ |
|
||||
| | 9.2 Web Browser Protection | ✓ | ✓ | ✓ |
|
||||
| 10. Malware Defenses | 10.1 Malicious Code Detection | ✓ | ✓ | ✓ |
|
||||
| | 10.2 Malware Defenses | ✓ | ✓ | ✓ |
|
||||
| 11. Data Recovery | 11.1 Data Recovery Mechanisms | ✓ | ✓ | ✓ |
|
||||
| 12. Network Infrastructure Management | 12.1 Network Inventory | ✓ | ✓ | ✓ |
|
||||
| | 12.2 Network Segmentation | | ✓ | ✓ |
|
||||
| 13. Security Awareness and Skills Training | 13.1 Security Awareness Program | ✓ | ✓ | ✓ |
|
||||
| | 13.2 Training and Exercises | | ✓ | ✓ |
|
||||
| 14. Security Operations Center (SOC) Functions | 14.1 Threat Detection | ✓ | ✓ | ✓ |
|
||||
| 15. Security Incident Management | 15.1 Incident Response Planning | ✓ | ✓ | ✓ |
|
||||
| | 15.2 Incident Response Testing | | ✓ | ✓ |
|
||||
| 16. Application Software Security | 16.1 Software Development Security | ✓ | ✓ | ✓ |
|
||||
| | 16.2 Application Testing | | ✓ | ✓ |
|
||||
| 17. Penetration Testing | 17.1 Penetration Testing and Red Teaming | | ✓ | ✓ |
|
||||
| 18. Cloud Security | 18.1 Cloud Security Posture Management | ✓ | ✓ | ✓ |
|
||||
| | 18.2 Cloud Workload Protection | | ✓ | ✓ |
|
||||
|
||||
```
|
||||
|
||||
This table presents an overview of the CIS Controls with a basic distinction of which implementation groups might adopt each safeguard as part of their cybersecurity strategy. The tick marks (✓) are placed based on the assumption that lower IG numbers cover more fundamental controls, while higher IG numbers represent more sophisticated measures. Always refer to the official CIS documents for precise guidelines and safeguards as they relate to your organization's needs.
|
||||
BIN
Corpus/Sparks/Information Security/CRF-Threat-Taxonomy-v2024.pdf
Normal file
BIN
Corpus/Sparks/Information Security/CRF-Threat-Taxonomy-v2024.pdf
Normal file
Binary file not shown.
40
Corpus/Sparks/Information Security/CRUD Matrices.md
Normal file
40
Corpus/Sparks/Information Security/CRUD Matrices.md
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
# CRUD Matrices
|
||||
|
||||
A CRUD matrix defines what actions a user (or process) is allowed to perform on a certain object, typically a data entity such as a table or record in a database.
|
||||
|
||||
CRUD is an acronym for:
|
||||
- Create - to create and store new data
|
||||
- Read - to retrieve and read data
|
||||
- Update - to change or modify then store the data.
|
||||
- Delete - to delete or remove the data
|
||||
|
||||
It is very valuable to combine a CRUD Matrix with the analysis of _user_ processes within the system, especially in the context of the _actors_ and _roles_ involved to complete the picture. ([source](https://www.unified-am.com/UAM/UAM/guidances/guidelines/uam_crud-matrix_F56BDB11.html))
|
||||
|
||||
This is a simple form, showing what access or usage an organizational role has with a particular object:
|
||||
|
||||
| | Create | Read | Update | Delete | Execute |
|
||||
| --------- | :----: | :----: | :----: | :----: | :-----: |
|
||||
| Manager | X | | | X | |
|
||||
| Author | X | X | X | X | |
|
||||
| Editor | | X | X | | |
|
||||
| Publisher | | X | X | | X |
|
||||
(Note that "crude" appears, which is create; read; update; delete; and execute.)
|
||||
|
||||
In the form below, we can see which authorizations each role has for different objects:
|
||||
|
||||
| | Order | Invoice | Customer | Employee | Product |
|
||||
| ------------- | :---: | :-----: | :------: | :------: | :-----: |
|
||||
| Sales VP | CRUD | CRUD | CRUD | CRUD | CRUD |
|
||||
| Sales Manager | CRUDE | CRUD | RU | R | R |
|
||||
| Sales Rep | CRUD | R | RU | R | R |
|
||||
| Stock Manager | - | - | - | R | RU |
|
||||
|
||||
A CRUD matrix is a helpful tool for [Access Control Models](../ISMS/Access%20Control%20Models.md), and several well-known CRUD extensions have been introduced to address specific needs, for example:
|
||||
([source](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete))
|
||||
|
||||
- **CRUDL (Create, Read, Update, Delete, List):** Adds a "List" operation to explicitly support retrieving collections of records, which is especially useful in applications where listing and searching are distinct from simple reading of single records.
|
||||
- **BREAD (Browse, Read, Edit, Add, Delete):** "Browse" and "Add" are used instead of "Read" and "Create," and "Edit" instead of "Update," reflecting terminology that is sometimes more intuitive for end-users or specific application domains.
|
||||
- **ABCD (Add, Browse, Change, Delete):** Similar to BREAD, this variant emphasizes "Browse" as a separate operation, and "Change" replaces "Update".
|
||||
- **DAVE (Delete, Add, View, Edit):** Reorders and renames the operations for clarity or branding in certain software contexts.
|
||||
- **CRAP (Create, Replicate, Append, Process):** Introduces "Replicate," "Append," and "Process" for systems needing more specialized data manipulation actions.
|
||||
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
# Architectural patterns for client segregation in SaaS systems
|
||||
|
||||
SaaS systems implement client segregation through several architectural patterns, each with distinct tradeoffs between security, efficiency, and complexity:
|
||||
|
||||
## Physical Segregation (Dedicated Infrastructure)
|
||||
|
||||
The most secure approach involves completely separate infrastructure per client - dedicated servers, databases, and networks. This provides the strongest isolation but comes with significant overhead. Each client essentially gets their own private instance, making resource utilization inefficient and operational complexity high due to managing multiple environments.
|
||||
|
||||
## Database-Level Segregation
|
||||
|
||||
A middle-ground approach uses shared application infrastructure but separate databases per client. This reduces infrastructure costs while maintaining strong data isolation. However, it still requires managing multiple database instances and can become complex with many clients. Connection pooling and backup strategies become more intricate.
|
||||
|
||||
## Schema-Level Segregation
|
||||
|
||||
Within a shared database, each client gets their own schema or database namespace. This approach balances resource efficiency with reasonable isolation - clients share the database engine but have separate table structures. It's operationally simpler than multiple databases but requires careful access control and schema management.
|
||||
|
||||
## Row-Level Security (RLS)
|
||||
|
||||
The most resource-efficient approach stores all client data in shared tables with tenant identifiers. Modern databases like PostgreSQL offer robust RLS features that automatically filter data based on the current client context. This maximizes resource utilization and simplifies operations but requires meticulous implementation to prevent data leakage.
|
||||
|
||||
## Hybrid Approaches
|
||||
|
||||
Many enterprise SaaS platforms combine multiple strategies. For example, high-value clients might get dedicated infrastructure while smaller clients share resources with row-level security. Some systems use shared infrastructure for computation but separate storage per client.
|
||||
|
||||
## Implementation Considerations
|
||||
|
||||
Beyond the core segregation model, systems must address connection pooling (ensuring connections don't leak between clients), caching strategies (preventing cross-client cache pollution), and audit logging (tracking data access per client). Authentication and authorization layers must be carefully designed to prevent privilege escalation between tenants.
|
||||
|
||||
The choice ultimately depends on the specific requirements around compliance, client size distribution, and acceptable risk levels. Financial services might require physical segregation, while a project management tool could effectively use row-level security.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
# Cracking passwords in 2024
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
45
Corpus/Sparks/Information Security/Customer Managed Keys.md
Normal file
45
Corpus/Sparks/Information Security/Customer Managed Keys.md
Normal file
|
|
@ -0,0 +1,45 @@
|
|||
# BYOK: Customer Managed Keys
|
||||
|
||||
|
||||
Asked Gemini, 30 juni 2025.
|
||||
Prompt: `What is meant by 'Bring your own encryption key?`
|
||||
|
||||
Related:
|
||||
- [a-8.24-Use-of-cryptography](../../Standards/ISO27x/OST/27002/EN/a-8.24-Use-of-cryptography.md)
|
||||
|
||||
|
||||
'Bring Your Own Encryption Key' (BYOK), also sometimes referred to as 'Bring Your Own Encryption' (BYOE) or 'Customer Managed Keys' (CMK), is a cloud computing security model that allows organizations to use and manage their own encryption keys for data stored in cloud environments, rather than relying on the cloud service provider to generate and manage the keys.
|
||||
|
||||
Here's a breakdown of what it means and why it's important:
|
||||
|
||||
**Key Principles of BYOK:**
|
||||
|
||||
- **Customer Control:** The primary benefit of BYOK is that it gives organizations greater control over their encryption keys. This means they have the ultimate say in who can access their encrypted data.
|
||||
|
||||
- **Key Generation:** Organizations typically generate their master encryption keys using their own on-premises key management systems or Hardware Security Modules (HSMs), which are highly secure, tamper-resistant devices designed for cryptographic operations.
|
||||
|
||||
- **Secure Import:** These self-generated keys are then securely imported into the cloud service provider's Key Management Service (KMS) or similar infrastructure. The methods of import are designed to be highly secure.
|
||||
|
||||
- **Key Usage by Cloud Provider:** Once imported, the cloud service provider uses the customer-provided keys to encrypt and decrypt the customer's data. However, the _master key itself_ remains under the customer's control, often residing within an HSM that the customer manages or controls access to.
|
||||
|
||||
- **Key Lifecycle Management:** Organizations maintain control over the entire lifecycle of their keys, including generation, rotation (regularly changing keys for security), revocation (disabling a key's access), and retirement (permanently deleting a key).
|
||||
|
||||
- **Auditing and Monitoring:** Many BYOK solutions offer robust auditing and monitoring features, allowing organizations to track how their keys are being used in the cloud, which aids in compliance and security oversight.
|
||||
|
||||
|
||||
**Why is BYOK important?**
|
||||
|
||||
- **Enhanced Security and Data Privacy:** By controlling their own keys, organizations significantly reduce their reliance on the cloud provider's security practices for key management. Even if the cloud provider's systems were compromised, the data would remain encrypted and inaccessible without the customer's keys.
|
||||
|
||||
- **Regulatory Compliance:** Many industry regulations (e.g., HIPAA, GDPR) and corporate security policies require organizations to maintain strict control over their encryption keys. BYOK helps meet these compliance requirements.
|
||||
|
||||
- **Data Sovereignty:** BYOK can help address data sovereignty concerns by allowing organizations to decide where their encryption keys are stored and processed, ensuring adherence to local data privacy laws.
|
||||
|
||||
- **Reduced Vendor Lock-in:** With BYOK, an organization's data encryption is not tied solely to a specific cloud provider's encryption solutions. This can make it easier to migrate data between different cloud providers or to a hybrid cloud environment, as the encryption is independent.
|
||||
|
||||
- **Transparency and Trust:** BYOK fosters greater transparency and trust between organizations and cloud providers, as the customer has independent assurance about their data security.
|
||||
|
||||
- **Defensible Deletion (Crypto-shredding):** If an organization decides to discontinue a cloud service or no longer needs certain data, they can simply delete their encryption keys. This renders the encrypted data permanently unreadable, even if copies of the encrypted data still exist on the provider's servers.
|
||||
|
||||
|
||||
In essence, BYOK shifts a significant portion of the encryption responsibility and control from the cloud service provider to the customer, providing a higher level of security and peace of mind for sensitive data in the cloud.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
# Data maturity model NL overheid
|
||||
|
||||
Een data maturity model helpt Nederlandse overheidsorganisaties bij het beoordelen, verbeteren en volwassen maken van hun datamanagementpraktijken. Het model dient als een raamwerk om de huidige status van een organisatie op het gebied van data te beoordelen en verbeterplannen te identificeren.
|
||||
|
||||
### Elaboratie:
|
||||
* Data Management Maturity Model (DMM):
Dit model, ontwikkeld door de ~[Realisatie IBDS](https://realisatieibds.nl/groups/view/c23ab74c-adb4-424e-917d-773a37968efe/kenniscentrum-van-de-ibds/wiki/view/2986e2c2-77c0-4624-8a4b-7bde2c56b70a/data-management-maturity-dmm)~, biedt een systematische benadering om de data management capaciteiten van overheidsorganisaties te verbeteren. Het helpt organisaties bij het beoordelen van hun huidige datamanagement en het identificeren van kansen voor verbetering.
|
||||
* Data Governance Maturity Model:
~[Sprinto](https://sprinto.com.en2nl.search.translate.goog/blog/data-governance-maturity-model/)~ beschrijft de volwassenheidsniveaus van data governance programma's. Het model helpt organisaties bij het beoordelen van hun huidige staat en bij het identificeren van stappen om hun data governance te verbeteren.
|
||||
* Data Maturity Assessment for Government:
Dit model, ook van ~[Realisatie IBDS](https://realisatieibds.nl/kennisbank/scan-datavolwassenheid)~, biedt een raamwerk om de gezondheid en sterkte van het data-ecosysteem van een overheidsorganisatie te meten en te verbeteren. Het helpt organisaties bij het identificeren van strategische verbeterpunten en bij het prioriteren van investeringen.
|
||||
* Morgens Data Maturity Model:
Dit model, ~[www.morgens.nl](https://www.morgens.nl/actueel/groei-in-datavolwassenheid-met-het-morgens-data-maturity-model/)~, helpt publieke sector organisaties bij het in kaart brengen van hun datavolwassenheid en het identificeren van stappen voor verbetering.
|
||||
* Data-Analytics Maturity Model:
Berenschot, in samenwerking met het A&O Fonds en de VNG, ontwikkelde een model dat helpt bij het beoordelen van de bereidheid van een organisatie om datagedreven te gaan werken.
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
# Dealing with a reported application vulnerability
|
||||
# Context
|
||||
A vulnerability in a widely used open source library is published.
|
||||
|
||||
This is based on the Log4j vulnerability, december 2021, [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228)
|
||||
|
||||
Log4j is a Java library maintained by the Apache Foundation, and the most popular logging library for Java.
|
||||
|
||||
The vulnerability is: user input containing JNDI Lookups is allowed, will be logged and evaluated, making an RCE attack possible. Disabling logging, while as a rule undesirable, plugs the hole.
|
||||
Source: https://logging.apache.org/log4j/2.x/
|
||||
|
||||
This vulnerability allows an attacker to run commands from a web server, unauthenticated (i.e. without needing to login).
|
||||
|
||||
# Steps
|
||||
|
||||
## 1. Identifying exposure
|
||||
- search your source code repositories for the name of the library
|
||||
- use dependency tools (also called Software Composition Analysis or SCA) to identify indirect use of the affected library , like GitHub's dependencyGraph, Snyk,[OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/), White source, etc.
|
||||
- not all versions may be affected, so check which version of the library you are using
|
||||
- find out if you are actually deploying the code that uses the vulnerability; if not, mark the code as "do not deploy". If it has, find out where.
|
||||
|
||||
## 2. Stopping the gap
|
||||
- If the vulnerability is deployed behind a Web Application Firewall (WAF) or Content Delivery Network (CDN), or if you are using Runtime Application Self-Protection (RASP), add the rules your vendor provides to prevent RCE.
|
||||
- If your vendor doesn't have rules available, search for them on the internet or write regex that blocks the attack.
|
||||
- Monitor to make shure it's working.
|
||||
- Update/patch the library containing the vulnerability as soon as it becomes available.
|
||||
|
||||
## 3. If you can't stop the gap
|
||||
Do an impact analyses and identify a treatment:
|
||||
- Option 1: Accept the Risk, keep monitoring the situation, spend your efforts on releasing the upgraded version of your software a.s.a.p.
|
||||
- Option 2: Avoid the risk, by shutting down the vulnerable systems immediately — In this example (log4j), stop logging temporarily.
|
||||
- Option 3: Mitigate the risk, by going through your code base, remove the dependency and comment out the code that calls it (uncomment it when the upgrade/patch has been applied).
|
||||
|
||||
|
||||
## Relevant ISO 27001 controls
|
||||
The main control of interest here is [ISO 27001 A 12.6.1 Management of technical vulnerabilities](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.6.1%20Management%20of%20technical%20vulnerabilities.md), which ensures timely awareness of vulnerabilities through [ISO 27001 A 6.1.4 Contact with special interest groups](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%206.1.4%20Contact%20with%20special%20interest%20groups.md), evaluation of an organization’s exposure, and having set [ISO 27001 A 16.1.1 Responsibilities and procedures](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2016.1.1%20Responsibilities%20and%20procedures.md) to enable a quick and effective response.
|
||||
|
||||
Stopping the gap:
|
||||
- [[ISO 27001 A 13.1.1 Network controls]]
|
||||
- [[ISO 27001 A 13.1.2 Security of network services]]
|
||||
- [ISO 27001 A 12.5.1 Installation of software on operational systems](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.5.1%20Installation%20of%20software%20on%20operational%20systems.md)
|
||||
|
||||
Preventative measures:
|
||||
- [ISO 27001 A 12.6.2 Restrictions on software installation](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.6.2%20Restrictions%20on%20software%20installation.md)
|
||||
- [[ISO 27001 A 14.1.1 Information security requirements analysis and specification]]
|
||||
- [[ISO 27001 14.2.1 Secure development policy]]
|
||||
- [[ISO 27001 A 14.2.7 Outsourced development]]
|
||||
- [ISO 27001 A 18 Compliance](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md) of systems
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Examples of Risk Avoidance
|
||||
|
||||
*ChatGPT prompt: In risk management, risks can be assigned a treatment strategy. Generally this is a choice between mitigate, transfer, accept or avoid. Give me some examples of possible courses of actions for risks in the 'avoid' category.*
|
||||
|
||||
*ChatGPT output, August 22, 2024:*
|
||||
|
||||
When a risk is categorized under 'avoid,' it means taking steps to eliminate the possibility of the risk occurring. Here are some examples of possible courses of action for risks in the 'avoid' category:
|
||||
|
||||
1. **Changing the Project Scope:**
|
||||
- If a project involves a high-risk task, one can alter the project's scope to exclude that task altogether, thereby avoiding the risk.
|
||||
|
||||
2. **Discontinuing a High-Risk Product or Service:**
|
||||
- If a specific product or service is prone to significant risks, a company might decide to discontinue it to avoid potential problems.
|
||||
|
||||
3. **Selecting an Alternative Strategy:**
|
||||
- Choosing an alternative strategy or approach that does not involve the identified risk. For example, if manual data entry is prone to errors (risk), an organization can implement automated systems.
|
||||
|
||||
4. **Relocating Operations:**
|
||||
- If a geographic area is susceptible to natural disasters, a company might relocate operations to a safer location to avoid the risk of disruption.
|
||||
|
||||
5. **Regulatory Compliance:**
|
||||
- Avoid engaging in business activities that do not comply with regulations and laws, thereby avoiding legal and regulatory risks.
|
||||
|
||||
6. **Technology Preclusion:**
|
||||
- Steering clear from using specific technologies that are unstable or have a history of security breaches.
|
||||
|
||||
7. **Supplier/Subcontractor Changes:**
|
||||
- Choosing not to engage with a supplier or subcontractor that has a poor track record of delivery or has posed risks in the past.
|
||||
|
||||
8. **Rejection of Risky Contracts or Clients:**
|
||||
- Declining business contracts or clients that present excessive risks or have a history of lawsuits and financial instability.
|
||||
|
||||
9. **Cancellation of Certain Events:**
|
||||
- Deciding not to host or participate in certain events (e.g., large gatherings during pandemics) to avoid health and safety risks.
|
||||
|
||||
10. **Elimination of Certain Processes:**
|
||||
- Permanently discontinuing processes that have inherent risks, like eliminating the dependency on a single, critical system.
|
||||
|
||||
By avoiding these identified risks, organizations or projects aim to sidestep potential negative impacts altogether rather than managing them through mitigation, transfer, or acceptance strategies.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
# Examples of vendor selection questionnaires
|
||||
|
||||
- [Dropbox](../../Literature%20notes/Dropbox%20Supplier%20Security%20Requirements.md)
|
||||
- [Google](https://vsaq-demo.withgoogle.com)
|
||||
|
||||
Related:
|
||||
- [Vendor security MoC](../Vendor%20security%20MoC.md)
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
|
||||
## Assen
|
||||
|
||||
- **Afdelingen** (financiële administratie, personeelszaken, pedagogiek en kwaliteit, facilitair, informatiemanagement, kinderopvanglocaties)
|
||||
- **Processen** (functiewaardering, salarisbetaling, crediteurenbeheer)
|
||||
- **Domeinen** (financiële gegevens, personele gegevens)
|
||||
- **Mate van vertrouwelijkheid** (geheim, vertrouwelijk, intern, openbaar)
|
||||
- **Objecten** (medewerker, klant, locatie, product)
|
||||
|
||||
Afdelingen en Processen zijn kenmerken van de organisatiestructuur, de begrippen Domeinen en Vertrouwelijkheid hebben betrekking op de informatieverzamelingen zèlf.
|
||||
|
||||
Domeinen zijn bijv.:
|
||||
- Cliënt data
|
||||
- Employee data
|
||||
- Product data (w/o Pedagogiek, de KOV locaties, voedsel, etc)
|
||||
- Process data (product/service delivery, client acquisition, orderflow, kwaliteitsmanagement, management overzichten)
|
||||
|
||||
Dat kruist met de organisatie structuur, bijv employee data bevat ook gegevens die voor de financiële afdeling nodig zijn (salaris afspraken).
|
||||
|
||||
Dat komt doordat de kern processen over meerdere afdelingen lopen.
|
||||
|
||||
|
||||
Van een medewerker worden de gegevens verwerkt over:
|
||||
- Functie
|
||||
- Beschikbaarheid
|
||||
- Contactgegevens
|
||||
- Gewerkte uren
|
||||
- Performance en beoordelingen
|
||||
- Inzetbaarheid
|
||||
- Kwalificaties
|
||||
- Ontwikkel plan
|
||||
- Inschaling
|
||||
- Salaris
|
||||
- Bankgegevens
|
||||
- Huisadres
|
||||
- VOG
|
||||
|
||||
Verschillende gegevens zijn meer of minder exclusief voor bepaalde functies/processen, bijv.:
|
||||
- De beschikbaarheid is van belang voor de Vestigingsmanager, voor het inplannen van een medewerker op een dag en groep.
|
||||
- De gewerkte uren zijn van belang voor de Vestigingsmanager (die ze moet accorderen) en de Salarisverwerking.
|
||||
|
||||
|
||||
## Gebruikersgroepen en Machtigingensets
|
||||
|
||||
- **Structuur:** In veel systemen worden gebruikers in groepen geplaatst (bijvoorbeeld 'Administrators', 'Gebruikers', 'Managers'). Aan deze groepen worden machtigingensets toegekend, die bepalen tot welke systeemobjecten, specifieke applicatieonderdelen of functionaliteiten de groepsleden toegang hebben.
|
||||
|
||||
**Hiërarchie**
|
||||
Sommige systemen kennen hiërarchische structuren waarbij rollen of groepen in lagen zijn opgebouwd, bijvoorbeeld met aparte autorisatiegroepen voor speciale systeembevoegdheden of beheerrechten
|
||||
|
||||
- **Detailniveau:** Moderne applicaties bieden vaak de mogelijkheid om rechten zeer fijnmazig toe te kennen, bijvoorbeeld aparte rechten voor lezen, schrijven, aanmaken, wijzigen of verwijderen van gegevens. Hoe fijnmaziger de rechten, hoe groter de beheerslast. Daarom wordt vaak een balans gezocht tussen detailniveau en beheersbaarheid. Het is ook mogelijk het beheer van de rechtenstructuur (deels) decentraal te beleggen. In een gemengd model kan het beheer van 'elevated rights' centraal belegd worden (bijv. op de afdeling informatiemanagemen) en het beheer van minder vergaande rechten bij applicatiebeheerders of teamleiders.
|
||||
|
||||
- Je kunt het hebben over niveaus van rechten: root, rechten kunnen uitdelen, alleen kijken, ook wijzigen. (CRUD)
|
||||
|
||||
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue