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,52 @@
|
|||
February 2, 2022
|
||||
|
||||
Relevant ISO 27001 clauses/controls:
|
||||
- [ISO 27001 A.14.2 Security in development and support processes](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A.14.2%20Security%20in%20development%20and%20support%20processes.md)
|
||||
|
||||
R.vanderveer@sig.eu
|
||||
@robvanderveer
|
||||
www.sig.eu/security
|
||||
Contributor to ISO standards
|
||||
|
||||
Maturity
|
||||
* Level 2 = Testing
|
||||
* late in the process, rework creates stress, separate from the primary development process allows it to be postponed
|
||||
* Level 3 = Treat Modelling
|
||||
* Hygiene Approach = List of Do’s and Don’ts - requirements , guidelines, training
|
||||
* Level 4 = Scanning tools (code scanning, dependencies)
|
||||
* Level 5 =
|
||||
* Tool integration and dashboard, expert tool config, expert code/design/privacy review, organization guidance, team coaching, culture change
|
||||
|
||||
OWASP SAMM is a good process framework. Also has self assessment tools to establish base level.
|
||||
owaspsamm.org
|
||||
owaspsamm.org/guidance/agile
|
||||
Recommended: OWASP ASVS and MASVS
|
||||
OWASP security wayfinder
|
||||
|
||||
OpenCRE.org provides an interactive content linking platform for uniting security standards!
|
||||
|
||||
|
||||
Key building blocks of successful secure software development:
|
||||
- Everybody should own the problem (product owners, management, teams)
|
||||
- Collaboration between security experts and developer
|
||||
- Tailored training, based on principles
|
||||
- Provide standard software bv uil ding blocks and frameworks
|
||||
- [Threat modeling](Risks/Security%20Threat%20Modeling.md) and situational Testing against these threats
|
||||
- Automated testing
|
||||
- Manual verification against checklists
|
||||
- Privacy and Maintainability
|
||||
- Integrate (single glass pane of findings)
|
||||
- Cross-team knowledge exchange (Security Guild)
|
||||
- Legacy code – Basically all the code that was driven when you had a lower security maturity level.
|
||||
|
||||
# Changing responsibilities in Software Development
|
||||
Martin Knobloch
|
||||
@knoblochmartin
|
||||
Martinknobloch@owasp.org
|
||||
|
||||
Everything you can put in a repository can be considered source code.
|
||||
|
||||
From cascaded development to extreme programming meant moving away from a linear process to a chaotic process
|
||||
|
||||
Security is everybody’s responsibility. Shared responsibility means having a common/shared view (unified dashboard) on vulnerabilities.
|
||||
Monitor for trends, and correlations between business events (process and tools changes, new functionality, etc.) and changes in the security posture
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
# Agile Development for Application Security Managers
|
||||
|
||||
|
||||
|
||||
Downloaded from: [Quotium.com](http://www.quotium.com/content/uploads/2014/02/Agile-development-for-Application-security-managers2.pdf) on February 11, 2022
|
||||
|
||||
|
||||
|
||||
Quotium are the vendors of a 'run-time code & data analysis application security testing solution for the software development life-cycle', called Seeker.
|
||||
|
||||
This booklet explains the Agile way of working with a non-development manager in mind. Medium quality, in my opinion.
|
||||
It is moderately suitable for distribution to them in a company setting.
|
||||
|
||||
Relevant ISO 27001 clauses/controls:
|
||||
- [ISO 27001 A.14.2.1 Secure development policy](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A.14.2.1%20Secure%20development%20policy.md)
|
||||
|
||||
Related:
|
||||
- [DevSecOps and ISO 27k](../Various/Business%20processes/DevSecOps%20and%20ISO%2027k.md)
|
||||
|
||||
# Achieving Application Security in Agile
|
||||
Weave security thinking into the Agile process. Adding it on later will be less secure, more costly and will probably achieve not enough attention because of release deadlines.
|
||||
|
||||
The author(s) state that, to be succesful, you have to use Agile's own principles when implementing application security.
|
||||
|
||||
## Define Clear Objectives and Requirements
|
||||
Answering the following questions for (with?) the developers is a good first step in defining the requirements:
|
||||
|
||||
- What are the specific areas of focus in developing securely and testing for security?
|
||||
- What security standards should the development team strive to meet or exceed? (This could be industry standards like OWASP, PCI-DSS, internal organization requirements or something else)
|
||||
- How often should developers test for security and who is responsible for doing these tests?
|
||||
- Do these tests replace periodical penetration tests and security audits or are utilized alongside these testing methods?
|
||||
|
||||
## Integrate with the developer's processes and tools
|
||||
- Include security tickets in the existing ticketing / bug tracking / taks management software.
|
||||
- Accommodate frequent code changes: don't you testing tools or methods that take a long time to run or require manual interpretation of results.
|
||||
- Create security stories: requirements are specified in the form of user stories.
|
||||
|
||||
|
||||
## Help Create an Agile Application Security Workflow
|
||||
Answer these questions:
|
||||
- who should run security testing, should each developer run on their own code, or maybe have one QA member who is responsible for security testing?
|
||||
- How often should security tests be performed – should they be on every piece of code or after integration?
|
||||
- Who should the results be delivered to? Development or security?
|
||||
- Who is responsible for signing off?
|
||||
|
||||
Provide a training program for developers.
|
||||
|
||||
Have the principle of continuous improvement also apply the Secure Development program.
|
||||
|
||||
**-> Where is the Review / Lessons Learned part, which is essential in the Agile cycle?**
|
||||
**-> Where is the Definition of Done?**
|
||||
|
||||
|
||||
Binary file not shown.
|
|
@ -0,0 +1,9 @@
|
|||
# Applying Zero Trust Principles to Enterprise Mobility
|
||||
|
||||
|
||||
|
||||
|
||||
Source: https://www.cisa.gov/sites/default/files/publications/Zero_Trust_Principles_Enterprise_Mobility_For_Public_Comment_508C.pdf
|
||||
|
||||
Related:
|
||||
[ISO 27001 A 6.2.1 Mobile device policy](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%206.2.1%20Mobile%20device%20policy.md)
|
||||
Binary file not shown.
|
|
@ -0,0 +1,179 @@
|
|||
# Authentication Methods Used for Network Security
|
||||
|
||||
Source: https://www.sailpoint.com/identity-library/authentication-methods-used-for-network-security/
|
||||
|
||||
While just one facet of cybersecurity, [authentication](https://www.sailpoint.com/identity-library/authentication) methods are the first line of defense. This is the process of determining whether a user is who they say they are. [Not to be confused](https://www.sailpoint.com/identity-library/difference-between-authentication-and-authorization/) with the step it precedes—authorization—authentication is purely the means of confirming digital identification, so users have the level of permissions to access or perform a task they are attempting.
|
||||
|
||||
There are many authentication methods, ranging from [passwords](https://www.sailpoint.com/identity-library/password-management-best-practices/) to fingerprints, to confirm the identity of a user before allowing access. Doing so adds a layer of protection and prevents security lapses like [data breaches](https://www.sailpoint.com/identity-library/how-compromised-credentials-lead-to-data-breaches/), though it’s often the combination of different types of authentication that provides secure system reinforcement against possible threats.
|
||||
|
||||
## Definition of authentication
|
||||
|
||||
In the context of [cybersecurity](https://www.sailpoint.com/identity-library/cybersecurity), authentication is the process of verifying and confirming the [identity](https://www.sailpoint.com/identity-library/digital-identity) of a user, device, or system before granting access to resources or information. It is a front-line defensive security measure used to ensure that individuals or entities can only access [sensitive data](https://www.sailpoint.com/identity-library/sensitive-data) or perform specific actions for which they are authorized.
|
||||
|
||||
The primary objective of authentication is to prevent [unauthorized access](https://www.sailpoint.com/identity-library/unauthorized-access) and protect assets (e.g., applications, data, and systems) from malicious activities, such as identity theft, data breaches, and [ransomware](https://www.sailpoint.com/identity-library/ransomware-mitigation) attacks. The systems used to implement and enforce authentication policies also support [compliance](https://www.sailpoint.com/identity-library/compliance-management) efforts.
|
||||
|
||||
## Importance of authentication in cybersecurity
|
||||
|
||||
Authentication is used to protect nearly every digital asset in an organization’s environment. It plays a critical role in protecting data, maintaining system and , and ensuring compliance with internal policies and [external regulations](https://www.sailpoint.com/identity-library/what-is-regulatory-compliance). The following are several of the most commonly cited reasons why authentication is an important part of an organization’s overall security posture.
|
||||
|
||||
### Prevents unauthorized access
|
||||
|
||||
Authentication ensures that only authorized users can access systems, applications, and data. This is fundamental to protecting digital assets from being accessed by unauthorized individuals or malicious actors.
|
||||
|
||||
### Protects sensitive data
|
||||
|
||||
Most organizations create, store, and handle sensitive data such as [personally identifiable information](https://www.sailpoint.com/identity-library/personally-identifiable-information) (PII) collected by human resources departments, financial information used by accounting teams, and intellectual property created and used by various groups in an organization.
|
||||
|
||||
Authentication mechanisms help safeguard this information from unauthorized access and potential [breaches](https://www.sailpoint.com/identity-library/security-breach) by verifying identities before granting access.
|
||||
|
||||
### Mitigates security risks
|
||||
|
||||
By verifying the identity of users and entities, authentication reduces the risk of [cyber attacks](https://www.sailpoint.com/identity-library/cyber-attack) that can result in identity theft, financial loss, operational disruption, and data breaches. It defends against these and other threats with strong [access controls](https://www.sailpoint.com/identity-library/what-are-the-different-types-of-access-control-systems) administered through a layered approach.
|
||||
|
||||
### Supports accountability
|
||||
|
||||
Authentication tools can create logs that detail all access instances. They can track which individual or entity accessed what resources and when tracing specific actions back to particular users or devices. This plays a vital role in monitoring for potential issues, auditing and investigations, and reporting in the wake of a security incident.
|
||||
|
||||
### Supports compliance
|
||||
|
||||
Authentication is a requirement for compliance with many regulations and standards, such as [General Data Protection Regulation](https://www.sailpoint.com/identity-library/gdpr-compliance-identity-governance-guide) (GDPR), [Health Insurance Portability and Accountability Act](https://www.sailpoint.com/identity-library/hipaa) (HIPAA), [Payment Card Industry Data Security Standard](https://www.sailpoint.com/identity-library/pci-dss-compliance) (PCI DSS), [Sarbanes-Oxley Act](https://www.sailpoint.com/identity-library/sox)(SOX), [Federal Information Security Management Act](https://www.sailpoint.com/identity-library/fisma-compliance-checklist) (FISMA), [Gramm-Leach-Bliley Act](https://www.sailpoint.com/identity-library/gramm-leach-bliley-act) (GLBA), ISO/IEC 27001, and many international security and privacy laws. These mandate that organizations implement and maintain robust authentication measures to protect sensitive data and ensure privacy.
|
||||
|
||||
### Enhances trust
|
||||
|
||||
Strong authentication mechanisms ensure compliance with laws and standards and build trust among users, customers, and partners. The use of robust authentication demonstrates that the organization takes security seriously and is committed to protecting its data.
|
||||
|
||||
### Reduces social engineering risks
|
||||
|
||||
[Social engineering](https://www.sailpoint.com/identity-library/social-engineering) is the use of psychological manipulation as an attack vector for perpetrating malicious activities. Deception is used to trick individuals into breaking personal and organizational security protocols to support criminal activities.
|
||||
|
||||
Using advanced authentication methods, such as [multi-factor authentication](https://www.sailpoint.com/identity-library/what-is-multi-factor-authentication) (MFA), prevents cyber attackers from gaining unauthorized access to applications, systems, or data from a single point of failure, such as [compromised credentials](https://www.sailpoint.com/identity-library/how-compromised-credentials-lead-to-data-breaches). Layered approaches to authentication make it exponentially more difficult for attackers to gain access successfully because even if one layer of authentication has been compromised, others are still in place. These additional verification steps have proven to be highly effective in thwarting unauthorized access.
|
||||
|
||||
### Supports identity management
|
||||
|
||||
Authentication plays a critical role in [identity and access management](https://www.sailpoint.com/identity-library/identity-and-access-management-security-checklist)(IAM). It helps organizations manage user identities and control access to resources by ensuring that only authorized users can access systems and data. Identity management systems (IDMS) use authentication methods (e.g., multi-factor authentication) to verify users' identities before granting access. Identity service providers (IdPs) are often used to support authentication systems, such as MFA and [single sign-on](https://www.sailpoint.com/identity-library/what-is-user-provisioning-and-single-sign-on)(SSO).
|
||||
|
||||
## Types of authentication
|
||||
|
||||
Based on their associated factors, there are three primary types of authentication: knowledge, possession, and inherence. Each has its pros and cons, but when used in conjunction, these types of authentication provide powerful protection from unauthorized access.
|
||||
|
||||
### Knowledge-based authentication (something you know)
|
||||
|
||||
[Knowledge-based authentication](https://www.sailpoint.com/identity-library/what-is-knowledge-based-authentication) uses information that a user knows, such as a username and password combination or personal information, to verify their identity before they are allowed to proceed. The level of security offered by knowledge-based authentication depends on the type used. There are two types of knowledge-based authentication—static and dynamic.
|
||||
|
||||
Static knowledge-based authentication uses pre-selected information stored in the authentication system. In addition to credentials, examples of static authentication factors are security questions, such as first pet, favorite color, or mother's maiden name. Static verification offers the benefit of simplicity, but the common nature of the questions asked makes it easier for cyber attackers to find the answers.
|
||||
|
||||
Dynamic knowledge-based authentication generates random questions to authenticate users. It increases security by making it harder to research answers in advance. Because dynamic knowledge-based authentication generates questions on the fly, cyber attackers cannot predict the information that they need to circumvent security systems. These questions come from various data sources, such as collected credit history, financial information, and public records.
|
||||
|
||||
### Possession-based authentication (something you have)
|
||||
|
||||
With possession-based authentication, a user’s identity is verified using physical possession of a specific object or device. These devices include a hardware token, a smart card, a USB key, and mobile devices, usually smartphones. The device is registered to an individual user and linked to the user’s identity, creating a unique connection between the user and the device.
|
||||
|
||||
Once set up, the device can be used as part of authentication processes. When a user attempts to log in to a resource, they are prompted to present the object or a unique identifier associated with the object. For instance, a token or smartphone could present a unique security code, and a scanner could be used to capture a person’s fingerprint. Possession factors offer enhanced protection because it is difficult for cyber attackers to get the device or spoof it.
|
||||
|
||||
### Inherence-based authentication (something you are)
|
||||
|
||||
Inherence-based authentication verifies a user’s identity with their inherently unique biological traits that are nearly impossible to replicate or fake, such as a user’s fingerprint, voice, or iris. This is a very secure authentication method, but it has limitations.
|
||||
|
||||
One of the biggest concerns about inherence-based authentication is [privacy](https://www.sailpoint.com/identity-library/data-privacy), as this approach requires the collection and storage of an individual’s characteristics. Other drawbacks of inherence-based authentication are related to its implementation. This type of authentication requires specialized devices that can capture and process the data, and these systems can be costly and complex to support.
|
||||
|
||||
## Authentication methods
|
||||
|
||||
Authentication keeps invalid users out of databases, networks, and other resources. These types of authentication use factors, a category of credential for verification, to confirm user identity. Here are just a few authentication methods.
|
||||
|
||||
### Single-factor / primary authentication
|
||||
|
||||
Historically the most common form of authentication, single-factor authentication is also the least secure, as it only requires one factor to gain full system access. It could be a username and password, pin-number or another simple code. While user-friendly, single-factor authentication systems are relatively easy to infiltrate by [phishing](https://www.sailpoint.com/identity-library/spear-phishing-vs-phishing), key logging, or mere guessing. As there is no other authentication gate to get through, this approach is highly vulnerable to attack.
|
||||
|
||||
### Two-factor authentication (2FA)
|
||||
|
||||
By adding a second factor for verification, [two-factor authentication](https://www.sailpoint.com/identity-library/two-factor-authentication)reinforces security efforts. It is an added layer that essentially double-checks that a user is, in reality, the user they’re attempting to log in as—making it much harder to break. With this method, users enter their primary authentication credentials (like the username / password mentioned above) and then must input a secondary piece of identifying information.
|
||||
|
||||
The secondary factor is usually more difficult, as it often requires something the valid user would have access to, unrelated to the given system. Possible secondary factors are a one-time password from an authenticator app, a phone number, or device that can receive a push notification or SMS code, or a [biometric](https://www.sailpoint.com/identity-library/biometric-authentication) like fingerprint (Touch ID) or facial (Face ID) or voice recognition.
|
||||
|
||||
2FA significantly minimizes the risk of system or resource compromise, as it’s unlikely an invalid user would know or have access to both authentication factors. While two-factor authentication is now more widely adopted for this reason, it does cause some user inconvenience, which is still something to consider in implementation.
|
||||
|
||||
### Single sign-on (SSO)
|
||||
|
||||
With SSO, users only have to log in to one application and, in doing so, gain access to many other applications. This method is more convenient for users, as it removes the obligation to retain multiple sets of credentials and creates a more seamless experience during operative sessions.
|
||||
|
||||
Organizations can accomplish this by identifying a central domain (most ideally, an IAM system) and then creating secure SSO links between resources. This process allows domain-monitored user authentication and, with single sign-off, can ensure that when valid users end their session, they successfully log out of all linked resources and applications.
|
||||
|
||||
### Multi-factor authentication (MFA)
|
||||
|
||||
Multi-factor authentication is a high-assurance method, as it uses more system-irrelevant factors to legitimize users. Like 2FA, MFA uses factors like biometrics, device-based confirmation, additional passwords, and even location or behavior-based information (e.g., keystroke pattern or typing speed) to confirm user identity. However, the difference is that while 2FA always utilizes only two factors, MFA could use two or three, with the ability to vary between sessions, adding an elusive element for invalid users.
|
||||
|
||||
## Common authentication factors
|
||||
|
||||
Each authentication factor belongs to a specific category of security controls. Security analysts choose factors in each category based on their requirements, availability, cost, ease of implementation, and other criteria. By blending factors from different categories, the overall security posture is significantly enhanced, as it is difficult for a bad actor to acquire or spoof many of these factors. The following are the main categories of authentication factors.
|
||||
|
||||
### Passwords
|
||||
|
||||
[Passwords](https://www.sailpoint.com/identity-library/password-management-best-practices) are a form of knowledge-based authentication. Users are required to enter their credentials, a username and password combination, to verify their identity. The credentials are validated by checking them against a database of users’ credentials.
|
||||
|
||||
Credentials are either issued by an IT or security team or established when a user first attempts to access a service. Credentials for sensitive systems and data are usually issued by IT or security teams, whereas credentials for accounts (e.g., banks, stores, or services) are often set up by the user.
|
||||
|
||||
Beyond protecting the database where credentials are stored, the security of passwords as authentication is predicated on the establishment and enforcement of [password policies](https://www.sailpoint.com/identity-library/password-policy). A key among these is the use of strong passwords.
|
||||
|
||||
CISA (the federal government’s [Cybersecurity and Infrastructure Security Agency](https://www.cisa.gov/)) recommends strong passwords be long, ideally at least 16 characters. CISA also recommends making them random by combining a string of capital and lowercase letters, numbers, and symbols or using a passphrase (e.g., SharkIceCardPurple). Another CISA recommendation for strong passwords is to make them unique, using different passwords for each account.
|
||||
|
||||
### PINs
|
||||
|
||||
The PIN (personal identification number) factor uses a numeric code or password to authenticate the identity of a user. PINs are often used as part of possession authentication. They are dynamically generated and presented on devices for users to enter as part of an authentication process. Common uses for PINs as knowledge-based authentication are for ATMs and mobile devices (e.g., smartphones and tablets).
|
||||
|
||||
### Security tokens
|
||||
|
||||
Security tokens are used for possession-based authentication. They can be hardware-based or software-based. Examples of hardware-based security tokens are USB tokens, smart cards, portable devices that display time-restricted codes, NFC (near-field communication) tokens for contactless authentication, and Bluetooth tokens that pair with a device when in proximity to authenticate. Software-based tokens include mobile authentication apps, one-time codes sent via text messages or email, push notifications that require users to validate a login attempt and browser extensions that generate and manage [one-time passwords](https://www.sailpoint.com/identity-library/one-time-password) for web-based authentication.
|
||||
|
||||
### Biometrics
|
||||
|
||||
Biometrics is considered a stronger authentication factor than passwords or PINs because it leverages physical or behavioral characteristics that are unique to individuals to verify their identity. These are difficult to forge or steal.
|
||||
|
||||
Types of biometric factors include fingerprints, facial recognition, hand geometry, iris recognition, retinal scans, voice recognition, gait analysis, vein patterns, DNA matching, and ear shape recognition. Users present their biometrics during the authentication process, and they compare them to the records that they have provided.
|
||||
|
||||
Biometrics are used for a number of access control use cases. These range from facial recognition to access a smartphone or fingerprint recognition to access a computer system to retinal and hand geometry scans to gain entry to a secured building or area or voice recognition to access account information from a phone.
|
||||
|
||||
### Location
|
||||
|
||||
Geolocation can be used as an authentication factor by internet protocol (IP) addresses, global positioning system (GPS) coordinates, and network information to determine whether a user’s access request originates from an expected or trusted location. With location-based authentication, a baseline of normal login locations is established, and anomalies are flagged and trigger further authentication.
|
||||
|
||||
### Behavior
|
||||
|
||||
Behavioral authentication is different from other types in that it supports continuous identity verification. It establishes user behavior baselines and monitors activity to detect deviations in how users interact with devices and applications. For example, keystroke analysis detects the unique timing patterns of how a user types, including the speed and pressure of key presses. Mouse movement can also be tracked and analyzed, such as the way a user typically navigates a screen. Behavior analytics tools can even track how a user holds and moves their device, including grip strength and angle.
|
||||
|
||||
## What are the most common authentication protocols?
|
||||
|
||||
Authentication protocols are the designated rules for interaction and verification that endpoints (laptops, desktops, phones, servers, etc.) or systems use to communicate. For as many different applications that users need access to, there are just as many standards and protocols.
|
||||
|
||||
Selecting the right authentication protocol for the organization is essential for ensuring secure operations and use compatibility. Here are a few of the most commonly used authentication protocols.
|
||||
|
||||
### Password authentication protocol (PAP)
|
||||
|
||||
While common, PAP is the least secure protocol for validating users, due mostly to its lack of encryption. It is essentially a routine log in process that requires a username and password combination to access a given system, which validates the provided credentials. It’s now most often used as a last option when communicating between a server and desktop or remote device.
|
||||
|
||||
### Challenge handshake authentication protocol (CHAP)
|
||||
|
||||
CHAP is an identity verification protocol that verifies a user to a given network with a higher standard of encryption using a three-way exchange of a “secret.” First, the local router sends a “challenge” to the remote host, which then sends a response with an MD5 hash function. The router matches against its expected response (hash value), and depending on whether the router determines a match, it establishes an authenticated connection—the “handshake”—or denies access. It is inherently more secure than PAP, as the router can send a challenge at any point during a session, and PAP only operates on the initial authentication approval.
|
||||
|
||||
### Extensible authentication protocol (EAP)
|
||||
|
||||
This protocol supports many types of authentication, from one-time passwords to smart cards. When used for wireless communications, EAP is the highest level of security as it allows a given access point and remote device to perform mutual authentication with built-in encryption. It connects users to the access point that requests credentials, confirms identity via an authentication server, and then makes another request for an additional form of user identification to again confirm via the server—completing the process with all messages transmitted, encrypted.
|
||||
|
||||
### Kerberos
|
||||
|
||||
[Kerberos](https://www.sailpoint.com/identity-library/kerberos-authentication-protocol) is a protocol that is used for network authentication. It uses cryptographic keys to create tickets. Once a ticket is issued, it is used to validate the identity of clients and servers during a network session in lieu of passwords. It is often used in large environments to support SSO.
|
||||
|
||||
### LDAP
|
||||
|
||||
[LDAP](https://www.sailpoint.com/identity-library/lightweight-directory-access-protocol) (Lightweight Directory Access Protocol) is an open, standard protocol used for managing and maintaining directory information, such as authentication servers. Because applications can quickly query user information for authentication, it is widely used to manage organizations’ user credentials.
|
||||
|
||||
### OAuth 2.0
|
||||
|
||||
[OAuth](https://www.sailpoint.com/identity-library/oauth) (Open Authorization) 2.0 is an industry-standard authorization framework that allows a website or application to access resources hosted by other web apps on behalf of a user. Access is limited to authorized actions for each user. The broad appeal of OAuth 2.0 is that the client app can perform actions on behalf of a user, and the user never has to share their credentials because the exchange is handled through application programming interfaces (APIs) and passed authentication tokens.
|
||||
|
||||
### RADIUS
|
||||
|
||||
RADIUS (Remote Authentication Dial-In User Service) is a network protocol that provides centralized authentication and accounting. It allows [remote users](https://www.sailpoint.com/identity-library/remote-access-security) to access virtual private network (VPN) servers, which accept requests from remote users and establish secure connections to a private network.
|
||||
|
||||
### SAML
|
||||
|
||||
[SAML](https://www.sailpoint.com/identity-library/security-assertion-markup-language) (Security Assertion Markup Language) is an open, standard, XML-based protocol for exchanging authentication and authorization data between identity providers (IdPs) and service providers. It enables single sign-on authentication across service providers.
|
||||
14
Corpus/Information Security/Authentication information.md
Normal file
14
Corpus/Information Security/Authentication information.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
# Authentication information
|
||||
|
||||
ISO 27002:2013: 09.2.4, 09.3.1, 09.4.3
|
||||
ISO 27002:2022: 5.17 (Managing authentication information, including advising personnel on how to handle authentication information.)
|
||||
|
||||
[Sterke wachtwoorden in 2024](Sterke%20wachtwoorden%20in%202024.md)
|
||||
|
||||
**NCSC over authenticeren**
|
||||
- [Authenticatie als onderdeel van Digitale Weerbaarheid](https://www.ncsc.nl/wat-kun-je-zelf-doen/weerbaarheid/beschermen/authenticatie)
|
||||
- [NCSC Infosheet Volwassen Authenticeren](../Standards/NCSC/NCSC%20Infosheet%20Volwassen%20Authenticeren.md)
|
||||
- [NCSC_Factsheet_Volwassen_Authenticeren](../Standards/NCSC/NCSC_Factsheet_Volwassen_Authenticeren.md)
|
||||
- [NCSC Factsheet Gebruik Tweefactorauthenticatie](../Standards/NCSC/NCSC%20Factsheet%20Gebruik%20Tweefactorauthenticatie.md)
|
||||
- [Choosing the right type](https://www.ncsc.gov.uk/guidance/authentication-methods-choosing-the-right-type)
|
||||
|
||||
163
Corpus/Information Security/BCP_Bedrijfscontinuïteitsplanning.md
Normal file
163
Corpus/Information Security/BCP_Bedrijfscontinuïteitsplanning.md
Normal file
|
|
@ -0,0 +1,163 @@
|
|||
# Bedrijfscontinuïteitsplanning
|
||||
|
||||
*In het Engels: Business Continuity Planning (BCP)*
|
||||
|
||||
Producten:
|
||||
- [BCP Workshops](../Standards/ISO27x/Implementation%20Products/BCP%20Workshops.md)
|
||||
|
||||
## Literatuur
|
||||
|
||||
- BCP.mindnode op iCloud > Best Practices
|
||||
- evt. [CIS Controls](../Standards/CIS%20Controls.md) als raamwerk
|
||||
- ISO-22301-2019 'Business continuity management systems' en ISO-22313-2020 'Guidance on the use of ISO 22301'
|
||||
- [CISSP, Chapter 3](../Standards/CISSP/CISSP_OSG_Chapter_3.md)
|
||||
|
||||
|
||||
Bedrijfscontinuïteitsplanning is een continu proces, met als doel het implementeren en onderhouden van beleid, procedures en processen om de impact van verstoringen te beheersen. Met andere woorden: bedrijfscontinuïteitsplanning richt zich op de continuïteit van bedrijfsprocessen, zo nodig met andere middelen.
|
||||
|
||||
Belangrijke onderdelen van Bedrijfscontinuïteitsplanning zijn de Bedrijfsimpact Analyse ([BIA](../ISMS/Business%20Impact%20Analysis%20(BIA).md)) en het Herstelplan ('Disaster Recovery Plan' / [DRP](..//Disaster%20Recovery%20Planning.md)).
|
||||
De BIA richt zich op het identificeren van de impact van verstoringen op de bedrijfsprocessen, en het Herstelplan richt zich op het herstel van de normale bedrijfsprocessen na een verstoring en de eventuele inzet van alternatieve middelen of werkwijzen .
|
||||
|
||||
Zie ook: [Het belang van een Bedrijfscontinuïteitsplan](../ISMS/Belang%20van%20een%20BCP.md) / [The importance of having a business continuity plan](Importance%20of%20a%20BCP.md).
|
||||
|
||||
|
||||
## Aanpak
|
||||
|
||||
1. Analyse
|
||||
2. Planning maatregelen
|
||||
3. Testen: scenario's simuleren en aanpassingen maken
|
||||
4. Implementatie maatregelen
|
||||
5. Testen maatregelen
|
||||
6. Oefen periodiek de scenario's en pas ze aan waar nodig
|
||||
|
||||
**NOG TOEVOEGEN**
|
||||
Het proces (Beleid) volgens welke dit hele plan tot stand komt en beoordeeld/herzien wordt, en wie daarvoor verantwoordelijk zijn.
|
||||
|
||||
## Analyse
|
||||
|
||||
Zie: [Business Impact Analysis (BIA)](../ISMS/Business%20Impact%20Analysis%20(BIA).md)
|
||||
|
||||
Stappen:
|
||||
- Bepalen bedrijfskritische processen (prioriteiten bepalen) en informatie-assets
|
||||
- Dreigingsanalyse
|
||||
- Belangen stakeholders, wet- en regelgeving, compliance verplichtingen
|
||||
- Bepalen minimaal acceptabel niveau van functioneren tijdens verstoringen (tov Normaal)
|
||||
- Analyseren processen en afhankelijkheden
|
||||
- intern en extern, mensen en middelen, systemen en verbindingen
|
||||
|
||||
### Bedrijfskritische processen en assets
|
||||
|
||||
Tabel vullen:
|
||||
|
||||
| Kritisch proces | Kritische middelen | Alternatief bij verstoring | Fail-over scenario | Recovery scenario |
|
||||
| --------------- | ------------------ | -------------------------- | ------------------ | ----------------- |
|
||||
|
||||
### Dreigingsanalyse
|
||||
|
||||
- Bepaal dreigingen – mens & natuur, bijvoorbeeld:
|
||||
- Wegvallen van kritische IT-componenten of diensten (defecten, gerichte aanvallen, ransomware, interruption of service)
|
||||
- Wegvallen van medewerkers op sleutelposities (epidemie!)
|
||||
- Onbereikbaarheid pand
|
||||
- Brand
|
||||
- Bepaal kans en impact – H/M/L, voor prioriteit
|
||||
- Bepaal impact op kritische assets
|
||||
- Bepaal impact op processen en belangen stakeholders – intern en extern
|
||||
|
||||
|
||||
## Planning maatregelen
|
||||
|
||||
1. Bepaal doelen
|
||||
2. Ontwerp Fail-over scenario’s
|
||||
3. Identificeer noodvoorzieningen
|
||||
4. Bepaal Recovery strategies
|
||||
5. Stel draaiboeken op
|
||||
|
||||
### Bepaal doelen
|
||||
|
||||
- MTPD – Maximum tolerable period of disruption (business process)
|
||||
- MTD – Maximum Tolerable Downtime (assets) – uit de lucht zijn
|
||||
- RPO – Recovery Point Objective (assets) – acceptable data loss; the point in time that you wish to recover to
|
||||
- RTO – Recovery Time Objective (processen) – hersteltijd tot normaal
|
||||
|
||||
### Fail-over scenario’s
|
||||
Zoek alternatieve invulling van de bedrijfskritische processen.
|
||||
Voorbeelden:
|
||||
- Mobiele hotspots i.p.v. vaste internetverbinding
|
||||
- Gebruik Acceptatie-omgeving als Productie-omgeving
|
||||
- Uitwijklocatie, noodstroomvoorziening
|
||||
|
||||
Aandachtspunten:
|
||||
- De dreiging moet niet dezelfde impact hebben op de alternatieve oplossing
|
||||
- Werk processen uit voor switch-over en switch-back
|
||||
|
||||
### Identificeer noodvoorzieningen
|
||||
Identificeer bestaande noodvoorzieningen en bepaal of ze voldoen
|
||||
|
||||
### Bepaal Recovery strategies
|
||||
|
||||
- Back-ups – test restores!
|
||||
- Hot/warm/cold standbys
|
||||
- High-availability systems
|
||||
- Proces uitwerken en testen
|
||||
|
||||
### Stel Draaiboeken op
|
||||
Aspecten:
|
||||
- Mensen
|
||||
- Middelen
|
||||
- Externe partijen
|
||||
- Rollen en Verantwoordelijkheden (RASCI)
|
||||
- Communicatie naar stakeholders
|
||||
- inhoud voorbereiden
|
||||
- contactpersonen en -gegevens
|
||||
|
||||
## Scenario's simuleren
|
||||
Scenario's opstellen o.b.v. risicoanalyse
|
||||
|
||||
## Implementatie maatregelen
|
||||
- Betrek stakeholders, w/o leveranciers, autoriteiten, nooddiensten
|
||||
- Maak duidelijke afspraken, zorg voor periodieke check!
|
||||
- Stel procedures en instructies op, incl. het Pre-disaster proces
|
||||
- Train de direct betrokkenen adhv scenario’s
|
||||
- Stel Emergency-Response guidelines op – ook BHV
|
||||
- COMMUNICEER!
|
||||
|
||||
## Aandachtspunten vanuit ISO 27001
|
||||
- Uitgangspunt: handhaven van de beveiligingsniveaus in een ongunstige situatie
|
||||
- Vaststellen hoe en in welke omstandigheden van het beleid mag worden afgeweken
|
||||
- Compenserende IB-maatregelen als handhaven niet mogelijk is (noodmaatregelen)
|
||||
- Documenteer afwijkingen in een logboek
|
||||
|
||||
## Aandachtspunten Uitvoering BCP
|
||||
- Turbulentie geeft extra risico’s
|
||||
- Focus ligt op Beschikbaarheid, Vertrouwelijkheid en Integriteit naar de achtergrond
|
||||
- Let op Data in Transit
|
||||
- Patching and configuration management on backup systems
|
||||
- Toegang tot netwerken, systemen, faciliteiten en ruimtes
|
||||
- Fysieke beveiliging op uitwijklocaties
|
||||
|
||||
|
||||
[^1]: NIST definieert het andersom: MTD = The amount of time mission/business process can be disrupted without causing significant harm to the organization’s mission; RTO = The maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes, and the MTD.
|
||||
|
||||
|
||||
## Links
|
||||
|
||||
See also:
|
||||
- [Disaster Recovery Planning](..//Disaster%20Recovery%20Planning.md)
|
||||
- [Checklist for auditing Business Continuity and Disaster Recovery](../Literature/Checklists%20Gerardus%20Blokdyk/Checklist%20for%20auditing%20Business%20Continuity%20and%20Disaster%20Recovery.md)
|
||||
- [Ransomware Playbook](Ransomware%20Playbook.md)
|
||||
|
||||
ISO controls:
|
||||
- 5.29:
|
||||
- [a-5.29-Information-security-during-disruption](../Standards/ISO27x/OST/27002/EN/a-5.29-Information-security-during-disruption.md)
|
||||
- [[ISO_27002_2022_NL_BT 5.29 Informatiebeveiliging tijdens een verstoring]]
|
||||
- [[ISO_27002_2022_NL_NN 5.29 Informatiebeveiliging tijdens een verstoring]]
|
||||
- 5.30:
|
||||
- [a-5.30-ICT-readiness-for-business-continuity](../Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md)
|
||||
- [ISO_27002_2022_5.30_PE ICT readiness for business continuity](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.30_PE%20ICT%20readiness%20for%20business%20continuity.md)
|
||||
- [a-5.30-ICT-gereedheid-voor-bedrijfscontinuiteit](../Standards/ISO27x/OST/27002/NL/a-5.30-ICT-gereedheid-voor-bedrijfscontinuiteit.md)
|
||||
- [[ISO_27002_2022_NL_NN 5.30 ICT-gereedheid voor bedrijfscontinuïteit]]
|
||||
- 5.31:
|
||||
- [ISO_27002_2022_5.31_OT Legal, statutory, regulatory and contractual requirements](../iso27diy-corp/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.31_OT%20Legal%2C%20statutory%2C%20regulatory%20and%20contractual%20requirements.md)
|
||||
- 5.24:
|
||||
- [a-5.24-Information-security-incident-management-planning-and-preparation](../Standards/ISO27x/OST/27002/EN/a-5.24-Information-security-incident-management-planning-and-preparation.md)
|
||||
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
Related:
|
||||
- [a-5.17-Authentication-information](../Standards/ISO27x/OST/27002/EN/a-5.17-Authentication-information.md)
|
||||
- [Multi-factor authentication](..//Multi-factor%20authentication.md)
|
||||
|
||||
Daniel Miessler:
|
||||
- [The Consumer Authentication Strength Maturity Model (CASMM) V6](https://danielmiessler.com/blog/casmm-consumer-authentication-security-maturity-model/)
|
||||
- [Not All MFA is Equal, and the Differences Matter a Lot](https://danielmiessler.com/blog/not-all-mfa-is-equal-and-the-differences-matter-a-lot/)
|
||||
|
||||
40
Corpus/Information Security/CRUD Matrices.md
Normal file
40
Corpus/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.
|
||||
|
||||
208020
Corpus/Information Security/Certified Ethical Hacker Exam Guide 2021.pdf
Normal file
208020
Corpus/Information Security/Certified Ethical Hacker Exam Guide 2021.pdf
Normal file
File diff suppressed because one or more lines are too long
29
Corpus/Information Security/Client segregation in SaaS.md
Normal file
29
Corpus/Information Security/Client segregation in SaaS.md
Normal file
|
|
@ -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,38 @@
|
|||
# Collection of Kanban boards on information security topics
|
||||
|
||||
The planning function of AuditGlue may take the form of a (series of) Kanban boards.
|
||||
|
||||
For inspiration, below is a collection of Kanban boards on information security topics, published by [The Art of Service](../Sparks/The%20Art%20of%20Service.md). Offering Kanban's in cooperation with them should be considered.
|
||||
|
||||
Note that these boards where created with Airtable.com.
|
||||
|
||||
|
||||
### Information security Kanban boards
|
||||
- [DevOps](https://theartofservice.com/devops-kanban)
|
||||
- [Data Governance](https://theartofservice.com/data-governance-kanban)
|
||||
- [Security Architecture](https://theartofservice.com/security-architecture-kanban)
|
||||
- [Security Operations Center](https://theartofservice.com/security-operations-center-kanban)
|
||||
- [Data Loss Prevention](https://theartofservice.com/Data-Loss-Prevention-kanban)
|
||||
- [Data Centric Security](https://theartofservice.com/data-centric-security-kanban)
|
||||
- [Threat Modeling](https://theartofservice.com/threat-modeling-kanban)
|
||||
- [Information Security Policies](https://theartofservice.com/information-security-policies-kanban)
|
||||
- [Center of Excellence requirements](https://theartofservice.com/Center-of-Excellence-kanban)
|
||||
- [Reliability Engineering requirements](https://theartofservice.com/reliability-engineering-kanban)
|
||||
- [GRC Management](https://theartofservice.com/grc-management-kanban)
|
||||
- [Cybersecurity policies](https://theartofservice.com/cybersecurity-policy-kanban)
|
||||
- [Enterprise Risk Management plan](https://theartofservice.com/enterprise-risk-management-plan-kanban)
|
||||
- [Software Asset Management](https://theartofservice.com/software-asset-management-kanban)
|
||||
- [Vulnerability Remediation](https://theartofservice.com/vulnerability-remediation-kanban)
|
||||
- [Risk Appetite](https://theartofservice.com/risk-appetite-kanban)
|
||||
- [IT Strategy](https://theartofservice.com/information-technology-strategy-kanban)
|
||||
- [Supply Chain security](https://theartofservice.com/supply-chain-cybersecurity-kanban)
|
||||
- [Process Governance](https://theartofservice.com/process-governance-kanban)
|
||||
|
||||
|
||||
### Related notes:
|
||||
- [📼 ISO27DIY Video Series](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/📼%20ISO27DIY%20Video%20Series.md)
|
||||
- [ISO27DIY Additional resources](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO27DIY%20Additional%20resources.md)
|
||||
- [List of possible partners](../../AuditGlue/List%20of%20possible%20partners.md)
|
||||
- [ISO27DIY Workshop Overview template](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/📒%20Templates/ISO27DIY%20Workshop%20Overview%20template.md)
|
||||
- [Advised Documents for ISO 27001](../../../iso27DIY-gis/reference/Advised%20Documents%20for%20ISO%2027001.md)
|
||||
- [💾 AuditGlue software](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/💾%20AuditGlue%20software.md)
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
# Cracking passwords in 2024
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
45
Corpus/Information Security/Customer Managed Keys.md
Normal file
45
Corpus/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.
|
||||
3
Corpus/Information Security/Data Governance.md
Normal file
3
Corpus/Information Security/Data Governance.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
[Checklist for auditing Data Governance](../Literature/Checklists%20Gerardus%20Blokdyk/Checklist%20for%20auditing%20Data%20Governance.md)
|
||||
[Data security lifecycle](Data%20security%20lifecycle.md)
|
||||
|
||||
16
Corpus/Information Security/Data security lifecycle.md
Normal file
16
Corpus/Information Security/Data security lifecycle.md
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
Source: "The 6 Phases of Data Security", [Cloud Security Alliance website](https://cloudsecurityalliance.org/blog/2021/10/14/the-6-phases-of-data-security/)
|
||||
Published: October 14, 2021
|
||||
Retrieved: March 8, 2022
|
||||
|
||||
### Data Security Lifecycle vs Information Lifecycle Management
|
||||
|
||||
Information Lifecycle Management is a tool to help understand the security boundaries and controls around data from its creation through retirement. Although Information Lifecycle Management is a fairly mature field, it doesn’t map well to the needs of security professionals.
|
||||
|
||||
The Data Security Lifecycle is different from Information Lifecycle Management in that it reflects the different needs of the security audience. It includes six phases from creation to destruction. Once created, data can bounce in between phases without restriction, and may not pass through all stages (not all data is eventually destroyed).
|
||||
|
||||
1. **Creation** is the generation of new digital content, or the alteration of existing content.
|
||||
2. **Storing** is the act of committing the digital data to some sort of storage repository and typically occurs nearly simultaneously with creation.
|
||||
3. Data is viewed, processed, or used in some sort of **activity**, not including modification.
|
||||
4. Information is **made accessible** to others, such as in between users, to customers, and to partners.
|
||||
5. Data leaves active use and enters **long-term storage**.
|
||||
6. Data is permanently **destroyed** using physical or digital means.
|
||||
|
|
@ -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,23 @@
|
|||
# Dealing with ransomware attacks
|
||||
|
||||
See also:
|
||||
[a-8.7-Protection-against-malware](../Standards/ISO27x/OST/27002/EN/a-8.7-Protection-against-malware.md)
|
||||
|
||||
Vuistregel is dat een ransomware aanval gemiddeld 16 dagen duurt, en dus 16 maal de Dagomzet kost.
|
||||
|
||||
Ransomware attack vectors:
|
||||
|
||||
- Malware.
|
||||
- Email Attachments.
|
||||
- Web Pages.
|
||||
- Pop Ups.
|
||||
- Instant Messages.
|
||||
- Text Messages.
|
||||
- Social Engineering.
|
||||
- Misconfigured VPN
|
||||
|
||||
Guidance:
|
||||
- [Ransomware Playbook](Ransomware%20Playbook.md)
|
||||
- [UK NCSC](https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks)
|
||||
- [CISA](https://www.cisa.gov/stopransomware/how-can-i-protect-against-ransomware)
|
||||
- [NIST](https://csrc.nist.gov/CSRC/media/Projects/ransomware-protection-and-response/documents/NIST_Tips_for_Preparing_for_Ransomware_Attacks.pdf)
|
||||
39
Corpus/Information Security/Examples of Risk Avoidance.md
Normal file
39
Corpus/Information Security/Examples of Risk Avoidance.md
Normal file
|
|
@ -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](../ISMS/Policy%20examples/Dropbox%20Supplier%20Security%20Requirements.md)
|
||||
- [Google](https://vsaq-demo.withgoogle.com)
|
||||
|
||||
Related:
|
||||
- [Vendor security MoC](../ISMS/Vendor%20security%20MoC.md)
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
# Frameworks for defining roles and responsibilities in IT
|
||||
|
||||
Several established frameworks exist for defining roles and responsibilities within IT departments. Here are the most widely used ones:
|
||||
|
||||
**RACI Matrix (Responsible, Accountable, Consulted, Informed)**
|
||||
This is one of the most popular frameworks for clarifying who does what in IT projects and operations. It assigns four levels of involvement to each role for every task or decision, making it clear who owns what and who needs to be kept in the loop.
|
||||
|
||||
**ITIL (Information Technology Infrastructure Library)**
|
||||
ITIL provides comprehensive guidance on IT service management roles and responsibilities. It defines specific roles like Service Owner, Process Owner, and Process Manager, along with their accountabilities across the service lifecycle. ITIL v4 emphasizes value streams and practices rather than rigid processes.
|
||||
|
||||
**COBIT (Control Objectives for Information and Related Technologies)**
|
||||
This framework focuses on IT governance and management, defining roles and responsibilities for ensuring IT aligns with business objectives. It provides clear accountability structures for IT leadership, process owners, and stakeholders.
|
||||
|
||||
**DevOps Role Models**
|
||||
Various DevOps frameworks define roles like Site Reliability Engineers, Platform Engineers, and DevOps Engineers, emphasizing shared responsibility between development and operations teams. These frameworks stress cross-functional collaboration over traditional silos.
|
||||
|
||||
**TOGAF (The Open Group Architecture Framework)**
|
||||
For enterprise architecture, TOGAF defines roles such as Enterprise Architect, Solution Architect, and Business Architect, along with their responsibilities in architecture governance and development.
|
||||
|
||||
**Agile IT Frameworks**
|
||||
SAFe (Scaled Agile Framework) and other agile methodologies define IT roles like Product Owner, Scrum Master, and Release Train Engineer, with responsibilities centered around iterative delivery and continuous improvement.
|
||||
|
||||
**Cybersecurity Frameworks**
|
||||
NIST Cybersecurity Framework and ISO 27001 define security-specific roles and responsibilities, including Chief Information Security Officer (CISO), Security Analyst, and Incident Response Team roles.
|
||||
|
||||
Most organizations combine elements from multiple frameworks rather than adopting just one, tailoring the approach to their specific needs, size, and industry requirements.
|
||||
|
|
@ -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)
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
# ICT readiness for business continuity
|
||||
|
||||
See:
|
||||
- [BCP_Bedrijfscontinuïteitsplanning](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
|
||||
- [Business Impact Analysis (BIA)](../ISMS/Business%20Impact%20Analysis%20(BIA).md)
|
||||
- [Disaster Recovery Planning](../ISMS/Disaster%20Recovery%20Planning.md)
|
||||
- [a-5.30-ICT-readiness-for-business-continuity](../Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md)
|
||||
|
||||
16
Corpus/Information Security/Identification.md
Normal file
16
Corpus/Information Security/Identification.md
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
# Identification
|
||||
|
||||
Identification is the claim of a subject of its identity.
|
||||
|
||||
See also:
|
||||
- [Authentication](../Standards/ISO27x/Authentication.md)
|
||||
- [Authorization](../Standards/ISO27x/Authorization.md)
|
||||
- [Identity and Access Management (IAM)](Identity%20and%20Access%20Management%20(IAM).md)
|
||||
|
||||
# Identification
|
||||
Identification is the claim of a subject of its identity.
|
||||
|
||||
See also:
|
||||
- [Authentication](../Standards/ISO27x/Authentication.md)
|
||||
- [Authorization](../Standards/ISO27x/Authorization.md)
|
||||
- [Identity and Access Management (IAM)](Identity%20and%20Access%20Management%20(IAM).md)
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
Sidebar from [Managing Risks - A New Framework](Risks/Managing%20Risks%20-%20A%20New%20Framework.md)
|
||||
|
||||
Companies cannot anticipate every circumstance or conflict of interest that an employee might encounter. Thus, the first line of defense against preventable risk events is to provide guidelines clarifying the company’s goals and values.
|
||||
|
||||
**Define the Mission**
|
||||
A well-crafted mission statement serves as a “true north” for all employees.
|
||||
E.g. Johnson & Johnson’s “We believe our first responsibility is to the doctors, nurses and patients, to mothers and fathers, and all others who use our products and services”.
|
||||
|
||||
**Articulate the Values** that guide employee behavior toward all stakeholders
|
||||
|
||||
**Set Boundaries** for what is and what is not allowed. Companies need corporate codes of business conduct that prescribe behaviors relating to conflicts of interest, antitrust issues, trade secrets and confidential information, bribery, discrimination, and harassment.
|
||||
top managers must serve as role models and demonstrate that they mean what they say. Companies must institute strong internal control systems, such as the segregation of duties and an active whistle-blowing program, to reduce not only misbehavior but also temptation. A capable and independent internal audit department tasked with continually checking employees’ compliance with internal controls and standard operating processes also will deter employees from violating company procedures and policies and can detect violations when they do occur.
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
## How IAM works
|
||||
|
||||
With IAM, you manage access control by defining _who_ (identity) has _what access_ (role) for _which resource_. For example, Compute Engine virtual machine instances, Google Kubernetes Engine (GKE) clusters, and Cloud Storage buckets are all Google Cloud resources. The organizations, folders, and projects that you use to organize your resources are also resources.
|
||||
|
||||
In IAM, permission to access a resource isn't granted _directly_ to the end user. Instead, permissions are grouped into _roles_, and roles are granted to authenticated _principals_. (In the past, IAM often referred to principals as _members_. Some APIs still use this term.)
|
||||
|
||||
An _allow policy_, also known as an _IAM policy_, defines and enforces what roles are granted to which principals. Each allow policy is attached to a resource. When an authenticated principal attempts to access a resource, IAM checks the resource's allow policy to determine whether the action is permitted.
|
||||
|
||||
See:
|
||||
- [Identification](Identification.md) – "This is who I am"
|
||||
- [Authentication](../Standards/ISO27x/Authentication.md) – "This is how I prove it"
|
||||
- [Authorization](../Standards/ISO27x/Authorization.md) – "... then this is what you get access to"
|
||||
- [CISSP_Domain_5_1](../Standards/CISSP/CISSP_Domain_5_1.md), [CISSP_Domain_5_2](../Standards/CISSP/CISSP_Domain_5_2.md)
|
||||
- [Roles in Identity and Access Management (IAM)](Roles%20in%20Identity%20and%20Access%20Management%20(IAM).md)
|
||||
|
||||
## How IAM works
|
||||
|
||||
With IAM, you manage access control by defining _who_ (identity) has _what access_ (role) for _which resource_. For example, Compute Engine virtual machine instances, Google Kubernetes Engine (GKE) clusters, and Cloud Storage buckets are all Google Cloud resources. The organizations, folders, and projects that you use to organize your resources are also resources.
|
||||
|
||||
In IAM, permission to access a resource isn't granted _directly_ to the end user. Instead, permissions are grouped into _roles_, and roles are granted to authenticated _principals_. (In the past, IAM often referred to principals as _members_. Some APIs still use this term.)
|
||||
|
||||
An _allow policy_, also known as an _IAM policy_, defines and enforces what roles are granted to which principals. Each allow policy is attached to a resource. When an authenticated principal attempts to access a resource, IAM checks the resource's allow policy to determine whether the action is permitted.
|
||||
|
||||
See:
|
||||
- [Identification](Identification.md) – "This is who I am"
|
||||
- [Authentication](../Standards/ISO27x/Authentication.md) – "This is how I prove it"
|
||||
- [Authorization](../Standards/ISO27x/Authorization.md) – "... then this is what you get access to"
|
||||
- [CISSP_Domain_5_1](../Standards/CISSP/CISSP_Domain_5_1.md), [CISSP_Domain_5_2](../Standards/CISSP/CISSP_Domain_5_2.md)
|
||||
- [Roles in Identity and Access Management (IAM)](Roles%20in%20Identity%20and%20Access%20Management%20(IAM).md)
|
||||
17
Corpus/Information Security/Impact categories.md
Normal file
17
Corpus/Information Security/Impact categories.md
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
# Impact Categories
|
||||
|
||||
Impact Categories are the types of business consequences that matter most to an organization's leadership, because they affect the organization's ability to achieve its objectives.
|
||||
|
||||
Below is a list of examples of Impact Categories:
|
||||
|
||||
- **Operational**: Disruption of day-to-day processes, workforce capability, system functionality, and the organization's ability to deliver products or services
|
||||
- **Financial**: Direct financial losses, increased costs, reduced revenue, market value decline, or threats to financial stability
|
||||
- **Strategic**: Inability to achieve long-level organizational goals, loss of competitive position, or forced changes to business direction
|
||||
- **Compliance**: Legal penalties, regulatory sanctions, loss of licenses or certifications, or mandatory remediation costs
|
||||
- **Reputational**: Loss of customer trust, damage to brand value, negative media attention, or erosion of stakeholder confidence
|
||||
- **Health and Safety**: Physical harm to employees, customers, or the public, or creation of unsafe conditions
|
||||
- **Environmental**: Environmental damage, pollution incidents, or failure to meet sustainability commitments
|
||||
- **Competitive Advantage**: Loss of proprietary knowledge, patents, trade secrets, or strategic business intelligence
|
||||
- **National Security**: Consequences for critical infrastructure, public safety, or national interests
|
||||
|
||||
You can expand and adapt this list as you see fit. Engage your management in a dialogue about areas of impact, and aim to establish the categories that are most important to them. This will help in weighing priorities later on.
|
||||
26
Corpus/Information Security/Importance of a BCP.md
Normal file
26
Corpus/Information Security/Importance of a BCP.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
# The importance of having a business continuity plan
|
||||
|
||||
Having a business continuity plan (BCP) is crucial for an organization for several reasons:
|
||||
|
||||
1. **Minimizing Downtime:** A BCP helps ensure that critical business functions can continue during and after a disaster or unexpected event. This minimizes downtime and the associated financial losses.
|
||||
|
||||
2. **Risk Management:** Identifying potential risks and preparing for them in advance allows an organization to manage and mitigate these risks more effectively. A BCP identifies vulnerabilities and puts safeguards and procedures in place to address them.
|
||||
|
||||
3. **Safeguarding Data and Assets:** A comprehensive BCP includes strategies to protect and recover important data and organizational assets, reducing the risk of data loss or corruption and ensuring business activities can continue without significant disruption.
|
||||
|
||||
4. **Maintaining Customer Confidence:** Promptly and efficiently responding to a crisis helps maintain trust with customers, suppliers, and other stakeholders, demonstrating that the organization is reliable and resilient even under challenging circumstances.
|
||||
|
||||
5. **Ensuring Compliance:** Many industries are subject to regulatory requirements regarding disaster recovery and business continuity. A formal BCP ensures compliance with these regulations, helping to avoid legal issues and penalties.
|
||||
|
||||
6. **Protecting Employees:** A BCP prioritizes employee safety by having procedures in place for communication, evacuation, and continuity of work in a safe environment. Ensuring the welfare of employees fosters loyalty and productivity.
|
||||
|
||||
7. **Financial Stability:** By minimizing operational disruptions and financial losses, a BCP supports the financial stability of an organization during and after an unforeseen event. This stability can be crucial for meeting contractual obligations and maintaining investor confidence.
|
||||
|
||||
8. **Competitive Advantage:** Organizations that can maintain operations during disruptions have a competitive advantage over those that cannot. This reliability can be a differentiating factor in the marketplace.
|
||||
|
||||
9. **Facilitating Recovery:** A BCP provides a clear roadmap for recovery, detailing roles, responsibilities, and procedures to be followed in the aftermath of a disruption, which accelerates the return to normal operations.
|
||||
|
||||
10. **Building Organizational Resilience:** The process of developing and maintaining a BCP helps foster a culture of resilience, ensuring that the organization is better prepared for a wide range of potential threats and changes in the business environment.
|
||||
|
||||
Overall, a well-crafted business continuity plan helps an organization anticipate, respond to, and recover from disruptions, ensuring long-term sustainability and success.
|
||||
|
||||
58
Corpus/Information Security/Incident Response Planning.md
Normal file
58
Corpus/Information Security/Incident Response Planning.md
Normal file
|
|
@ -0,0 +1,58 @@
|
|||
[SANS Incident Response Plan](../Standards/SANS/SANS%20Incident%20Response%20Plan.md)
|
||||
|
||||
[Checklist for auditing Incident Response Plan](../Literature/Checklists%20Gerardus%20Blokdyk/Checklist%20for%20auditing%20Incident%20Response%20Plan.md)
|
||||
|
||||
See also:
|
||||
- [Ransomware Playbook](Ransomware%20Playbook.md)
|
||||
- [a-5.30-ICT-readiness-for-business-continuity](../Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md)
|
||||
- [BCP_Bedrijfscontinuïteitsplanning](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
|
||||
|
||||
|
||||
|
||||
ISO 27002 5.24 Planning and preparation [PE](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.24_PE%20Information%20security%20incident%20management%20planning%20and%20preparation.md)/ [OT](../Standards/ISO27x/OST/27002/EN/a-5.24-Information-security-incident-management-planning-and-preparation.md)
|
||||
|
||||
CISSP Incident Response Steps[^1]:
|
||||
|
||||
- Detection
|
||||
- monitoring, alerts
|
||||
- Response
|
||||
- decide if it is a security incident
|
||||
- alert the CSIR Team
|
||||
- Mitigation
|
||||
- contain the incident, limit effect or scope
|
||||
- Reporting
|
||||
- Recovery
|
||||
- return to fully functioning state
|
||||
- Remediation
|
||||
- root cause analysis
|
||||
- Lessons Learned
|
||||
- ISO 27002 5.27 [PE](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.27_PE%20Learning%20from%20information%20security%20incidents.md) / [OT](../Standards/ISO27x/OST/27002/EN/a-5.27-Learning-from-information-security-incidents.md)
|
||||
- prevent from re-occurring
|
||||
- improve incident response
|
||||
|
||||
|
||||
[^1]: CISSP Chapter 17, Preventing and Responding to Incidents, p.739
|
||||
|
||||
ChatGPT identifies the following steps:
|
||||
|
||||
### in information security incident response, what other actions are there, then mitigation and remediation
|
||||
|
||||
In information security incident response, there are several key actions in addition to mitigation and remediation. These typically align with the stages of an incident response process. Here's an overview:
|
||||
|
||||
1. **Preparation**: This involves establishing and training an incident response team, developing and updating an incident response plan, and ensuring tools and resources are available for effective incident management.
|
||||
|
||||
2. **Identification**: This stage focuses on detecting and identifying security incidents through monitoring, alerts, and reports. It involves confirming whether a security breach or event has occurred.
|
||||
|
||||
3. **Containment**: Once an incident is identified, immediate containment efforts are taken to limit damage, prevent further intrusion, and isolate affected systems. This can be broken down into short-term containment (immediate response) and long-term containment (applying temporary fixes).
|
||||
|
||||
4. **Eradication**: This involves removing the root cause of the incident, such as eliminating malware from all affected systems, closing vulnerabilities that were exploited, and ensuring that the threat is completely neutralized.
|
||||
|
||||
5. **Recovery**: During this phase, affected systems are restored and returned to normal operations. It includes validating systems to ensure they are operational and secure, implementing additional monitoring, and verifying that vulnerabilities are resolved.
|
||||
|
||||
6. **Improvement**: Also known as lessons learned, this step involves reviewing and analyzing the incident and the response. The objective is to learn from the event, improve future incident response, and update policies and procedures.
|
||||
|
||||
7. **Communication**: Throughout the incident response process, consistent communication is crucial. This includes informing relevant stakeholders, providing updates, reporting to compliance bodies if necessary, and managing public relations if the incident affects external parties.
|
||||
|
||||
8. **Post-Incident Review**: A detailed review is conducted after the incident is resolved to evaluate what happened, what was done well, what could be improved, and how to prevent similar incidents in the future.
|
||||
|
||||
These actions combined create a comprehensive approach to effectively manage and respond to security incidents in an organized manner.
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
# Incident Response playbooks
|
||||
|
||||
[Repository](https://github.com/certsocietegenerale/IRM/tree/main) of Incident Response playbooks by CERT Societe Generale
|
||||
68
Corpus/Information Security/Kerberoasting.md
Normal file
68
Corpus/Information Security/Kerberoasting.md
Normal file
|
|
@ -0,0 +1,68 @@
|
|||
# How does Kerberoasting work
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kerberoasting is a cyberattack that exploits weaknesses in the Kerberos authentication protocol to steal service account credentials in Active Directory environments. Here's how it works:
|
||||
|
||||
## Attack Process
|
||||
|
||||
1. **Initial Access**
|
||||
Attackers first gain authenticated access to the network using compromised domain user credentials. No elevated privileges are required at this stage[3](https://www.vaadata.com/blog/what-is-kerberoasting-attack-and-security-tips-explained/)[7](https://www.ibm.com/think/topics/kerberoasting).
|
||||
|
||||
2. **Service Ticket Harvesting**
|
||||
The attacker queries Active Directory for accounts with Service Principal Names (SPNs), which identify network services. Using tools like PowerShell or BloodHound, they request Kerberos service tickets (TGS tickets) for these accounts[1](https://www.sentinelone.com/cybersecurity-101/threat-intelligence/what-is-kerberoasting-attack/)[8](https://www.rapid7.com/fundamentals/kerberoasting-attack/). These tickets are encrypted with the service account's password hash[5](https://www.picussecurity.com/resource/blog/kerberoasting-attack-explained-mitre-attack-t1558.003).
|
||||
|
||||
3. **Ticket Extraction**
|
||||
Tools like **Mimikatz** or **Rubeus** extract the encrypted ticket data from memory. The attack specifically targets tickets using the weaker RC4_HMAC_MD5 encryption type rather than more secure AES encryption[2](https://blog.quest.com/understanding-kerberoasting-attacks-and-how-to-prevent-them/)[4](https://www.strongdm.com/what-is/kerberoasting).
|
||||
|
||||
4. **Offline Password Cracking**
|
||||
Attackers use brute-force tools like **Hashcat** or **John the Ripper** to crack the hashes offline. Success depends on password strength:
|
||||
|
||||
- Weak passwords (<25 characters) are vulnerable
|
||||
|
||||
- Computer/managed service accounts (with 120+ character passwords) are generally safe[2](https://blog.quest.com/understanding-kerberoasting-attacks-and-how-to-prevent-them/)[5](https://www.picussecurity.com/resource/blog/kerberoasting-attack-explained-mitre-attack-t1558.003)
|
||||
|
||||
|
||||
|Attack Stage|Key Tools Used|Vulnerability Exploited|
|
||||
|---|---|---|
|
||||
|Ticket Harvesting|PowerShell, BloodHound|SPN misconfigurations|
|
||||
|Ticket Extraction|Mimikatz, Rubeus|RC4_HMAC_MD5 encryption|
|
||||
|Password Cracking|Hashcat, John the Ripper|Weak service account passwords|
|
||||
|
||||
## Why It's Effective
|
||||
|
||||
- **Stealth**: No network traffic generated during cracking[4](https://www.strongdm.com/what-is/kerberoasting)
|
||||
- **Legitimate Appearance**: Uses normal Kerberos functions[6](https://www.crowdstrike.com/en-us/cybersecurity-101/cyberattacks/kerberoasting/)
|
||||
- **High Reward**: Service accounts often have elevated privileges[3](https://www.vaadata.com/blog/what-is-kerberoasting-attack-and-security-tips-explained/)
|
||||
|
||||
## Mitigation Strategies
|
||||
|
||||
- **Enforce strong passwords** (25+ chars) for service accounts[2](https://blog.quest.com/understanding-kerberoasting-attacks-and-how-to-prevent-them/)[4](https://www.strongdm.com/what-is/kerberoasting)
|
||||
- **Use AES encryption** instead of RC4 for Kerberos tickets[2](https://blog.quest.com/understanding-kerberoasting-attacks-and-how-to-prevent-them/)[7](https://www.ibm.com/think/topics/kerberoasting)
|
||||
- **Implement Managed Service Accounts** with auto-rotated passwords[5](https://www.picussecurity.com/resource/blog/kerberoasting-attack-explained-mitre-attack-t1558.003)
|
||||
- **Monitor** for abnormal TGS ticket requests[4](https://www.strongdm.com/what-is/kerberoasting)[8](https://www.rapid7.com/fundamentals/kerberoasting-attack/)
|
||||
- **Enable Multi-Factor Authentication** for sensitive accounts[4](https://www.strongdm.com/what-is/kerberoasting)
|
||||
|
||||
|
||||
The attack chain demonstrates how attackers leverage legitimate protocol features to escalate privileges, making detection challenging without proper monitoring and encryption standards[1](https://www.sentinelone.com/cybersecurity-101/threat-intelligence/what-is-kerberoasting-attack/)[5](https://www.picussecurity.com/resource/blog/kerberoasting-attack-explained-mitre-attack-t1558.003). Regular password rotation and eliminating weak encryption types remain critical defenses[2](https://blog.quest.com/understanding-kerberoasting-attacks-and-how-to-prevent-them/)[4](https://www.strongdm.com/what-is/kerberoasting).
|
||||
|
||||
### Citations:
|
||||
|
||||
1. [https://www.sentinelone.com/cybersecurity-101/threat-intelligence/what-is-kerberoasting-attack/](https://www.sentinelone.com/cybersecurity-101/threat-intelligence/what-is-kerberoasting-attack/)
|
||||
2. [https://blog.quest.com/understanding-kerberoasting-attacks-and-how-to-prevent-them/](https://blog.quest.com/understanding-kerberoasting-attacks-and-how-to-prevent-them/)
|
||||
3. [https://www.vaadata.com/blog/what-is-kerberoasting-attack-and-security-tips-explained/](https://www.vaadata.com/blog/what-is-kerberoasting-attack-and-security-tips-explained/)
|
||||
4. [https://www.strongdm.com/what-is/kerberoasting](https://www.strongdm.com/what-is/kerberoasting)
|
||||
5. [https://www.picussecurity.com/resource/blog/kerberoasting-attack-explained-mitre-attack-t1558.003](https://www.picussecurity.com/resource/blog/kerberoasting-attack-explained-mitre-attack-t1558.003)
|
||||
6. [https://www.crowdstrike.com/en-us/cybersecurity-101/cyberattacks/kerberoasting/](https://www.crowdstrike.com/en-us/cybersecurity-101/cyberattacks/kerberoasting/)
|
||||
7. [https://www.ibm.com/think/topics/kerberoasting](https://www.ibm.com/think/topics/kerberoasting)
|
||||
8. [https://www.rapid7.com/fundamentals/kerberoasting-attack/](https://www.rapid7.com/fundamentals/kerberoasting-attack/)
|
||||
|
||||
---
|
||||
|
||||
Answer from Perplexity: [pplx.ai/share](pplx.ai/share)
|
||||
6
Corpus/Information Security/Maturity Models.md
Normal file
6
Corpus/Information Security/Maturity Models.md
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
# Maturity Models
|
||||
|
||||
- [CMMI Process Maturity](../Standards/other/CMMI%20Process%20Maturity.md)
|
||||
- [SP-CMM Security & Privacy maturity](../Standards/other/SP-CMM%20Security%20&%20Privacy%20maturity.md)
|
||||
- [CASSM Consumer Authentication Strength](CASSM%20Consumer%20Authentication%20Strength%20Maturity%20Model.md)
|
||||
- [C2M2 Cybersecurity Capability Maturity](../Standards/other/C2M2%20Cybersecurity%20Capability%20Maturity.md)
|
||||
20
Corpus/Information Security/OT Security.md
Normal file
20
Corpus/Information Security/OT Security.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
Operational Technology Security – or OT Security
|
||||
|
||||
|
||||
[Fortinet article](https://www.fortinet.com/solutions/industries/scada-industrial-control-systems/what-is-ot-security)
|
||||
Mentions "Industrial Internet of Things (IIOT) Devices" and SCADA (see CISSP book)
|
||||
|
||||
Relationship to ISO 27k:
|
||||
- most obvious to [ISO 27001 A 13 Communications security](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2013%20Communications%20security.md)
|
||||
- also ISA/IEC 62443 series – wasn't that the thing at Ultimaker?
|
||||
- Detailled Google Groups [post](https://groups.google.com/g/iso27001security/c/DhgybAN7pxk?pli=1) mentions:
|
||||
- [Generic SCADA Risk Management Framework](https://www.tisn.gov.au/Documents/SCADA-Generic-Risk-Management-Framework.pdf)
|
||||
- [ISO 27019 Information security controls for the energy utility industry]([https://www.iso.org/standard/68091.html](https://www.iso.org/standard/68091.html))
|
||||
- [Presentation]([https://isms.jp/csms/doc/JIP-CSMS120E-10.pdf](https://isms.jp/csms/doc/JIP-CSMS120E-10.pdf)) on the relation between 27001 (ISMS Implementation) and IEC 62443 (CSMS Implementation)
|
||||
|
||||
See also:
|
||||
- [](../Standards/SANS/SANS_CIS_poster_Winter2016_CSCs.pdf)
|
||||
- [](../Standards/other/CIS_Controls_V7_Poster.pdf)
|
||||
- AuditScripts-CIS-Controls-Master-Mappings-v7.1c.xlsx (in the Attachments folder, linking in editor to this file type is not supported)
|
||||
|
||||
|
||||
47
Corpus/Information Security/PEST analysis How To.md
Normal file
47
Corpus/Information Security/PEST analysis How To.md
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
# PEST analysis How To
|
||||
|
||||
A PEST analysis ([Wikipedia](https://en.wikipedia.org/wiki/PEST_analysis)) provides a frame for identifying macro-environmental factors that may be relevant to your organization and the security of your information.
|
||||
|
||||
PEST is an acronym for:
|
||||
- Political
|
||||
- Economic
|
||||
- Social (incl. cultural)
|
||||
- Technological
|
||||
|
||||
Many variants have been made.
|
||||
|
||||
DESTEP adds Demographic and Ecological to the mix.
|
||||
|
||||
|
||||
Walk through the different categories in the first column, and try to think of relevant issues and trends. Just jot down what pops into your mind. Don't overthink it. You can always revisit this document later and add or refine as you see fit.
|
||||
|
||||
This analysis is about overall issues and trends – we will deal with requirements and expectations of specific groups and individuals later.
|
||||
We'll also ignore specific laws and regulations for now.
|
||||
|
||||
Let's look at some examples:
|
||||
|
||||
Try to express the issues as risks *or* opportunities for your organization and your information security.
|
||||
|
||||
| Issues and Trends | Relevance to your organization | Relevance to information security |
|
||||
| -------------------------------------------------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
|
||||
| **Demographic** | | |
|
||||
| Aging population | Increased competition for young talent | Users have trouble memorizing passwords |
|
||||
| Internationalization of Workforce | Attract talent in a global workforce market | Employees with family living under hostile regimes may experience pressure to disclose information |
|
||||
| **Ecological** | | |
|
||||
| Global warming increases flooding danger | Offices are below sea level | Datacenter may become disfunctional |
|
||||
| COVID pandemic | Increase in remote working from uncontrolled environments | Higher risks of shoulder-surfing, eavesdropping and inadequate network security |
|
||||
| **Socio-cultural** | | |
|
||||
| Less reading, more AV-media consumption | Training and instruction may need to be adapted | Consider use of media to increase security training effectiveness |
|
||||
| **Technological** | | |
|
||||
| Increase in network-enabled devices (IoT) | Employees may use IoT devices in work environment | Increase in IoT-associated risks |
|
||||
| **Economic** | | |
|
||||
| Government funding for cybersecurity awareness programme | Possibility to secure funding | Adapt in-company training to match funding requirements |
|
||||
| **Political** | | |
|
||||
| Government chooses sides in an international conflict | Organization becomes possible target for state actors | Advanced and persistent threat to InfoSec |
|
||||
| Intensified enforcement of privacy laws | Closer scrutiny, possible penalties for non-compliance | Monitor compliance across the organization |
|
||||
|
||||
Don't worry too much about if something should be classified as one or the other, the point is that you can demonstrate that you have awareness of your environment and are able to act upon it in a structured way.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
# Passwordless Authentication
|
||||
|
||||
https://www.onelogin.com/learn/passwordless-authentication
|
||||
|
||||
3
Corpus/Information Security/Phishing-Resistant MFA.md
Normal file
3
Corpus/Information Security/Phishing-Resistant MFA.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
## Multi-factor authentication (MFA)
|
||||
|
||||
Implementing Phishing-Resistant MFA: [CISA fact sheet](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf)
|
||||
26
Corpus/Information Security/Prioritisering Support.md
Normal file
26
Corpus/Information Security/Prioritisering Support.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
Related:
|
||||
- [ISO 27001 A.14.2 Security in development and support processes](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A.14.2%20Security%20in%20development%20and%20support%20processes.md)
|
||||
|
||||
|
||||
**Impact-Urgentie-matrix**
|
||||
|
||||
Urgentie | Kwalificatie (impact) | Scope Hoog | Scope Middel | Scope Laag
|
||||
-------- | --------------------- | -------- | ------------- | ----
|
||||
. | . | Alle gebruikers | Deel van de gebruikers | Eén gebruiker
|
||||
Kritiek | Primaire bedrijfsprocessen kunnen niet uitgevoerd worden | R1 | R1 | R2
|
||||
Hoog | Niet-primaire bedrijfsprocessen kunnen niet uitgevoerd worden. Klant kan met beperkte hinder door werken | R2 | R2 | R3
|
||||
Normaal | Klant kan met weinig hinder door werken - reguliere vragen | R3 | R3 | R4
|
||||
|
||||
*In het voorbeeld hierboven wordt de Urgentie gekwalificeerd op basis van de verstoring van bedrijfsprocessen en de Scope (reikwijdte) op basis van het aantal gebruikers dat hinder ondervindt. Alternatief is de impact te kwalificeren naar het aantal functionaliteiten van de applicatie dat niet meer beschikbaar – maar dat is dan aanbodgedreven.*
|
||||
|
||||
|
||||
**Specificatie reactie- en oplossingstijd**
|
||||
|
||||
Prioriteit | Reactietijd | Oplossing
|
||||
-------- | -------- | ------
|
||||
R1 | 30 minuten gedurende Werkuren | Onderzoek naar oplossing start direct na constateren probleem. Oplossing of Algemeen acceptabele oplossing binnen 24 uur (90%), 100% in 48 uur. Structurele oplossing binnen 30 kalenderdagen.
|
||||
R2 | Binnen 4 uur gedurende Werkuren (90%), 100% binnen 8 uur gedurende Werkuren. | Binnen 14 dagen een Algemeen acceptabele oplossing. Structurele oplossing volgens releasekalender.
|
||||
R3 | Binnen 2 Werkdagen gedurende Werkuren (90%), 100% binnen 5 Werkdagen gedurende Werkuren. | Binnen 14 dagen uitsluitsel of vraag/Incident wordt opgelost of geëscaleerd naar ontwikkelafdeling.
|
||||
R4 | Binnen 14 dagen | Binnen 30 dagen uitsluitsel of Wens/Incident wordt opgelost of geëscaleerd naar ontwikkelafdeling.
|
||||
|
||||
|
||||
49
Corpus/Information Security/Privileged Access Management.md
Normal file
49
Corpus/Information Security/Privileged Access Management.md
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
---
|
||||
Related:
|
||||
- "[a-8.2-Privileged-access-rights](../Standards/ISO27x/OST/27002/EN/a-8.2-Privileged-access-rights.md)"
|
||||
---
|
||||
|
||||
## What is Privileged Access Management?
|
||||
|
||||
September 24, 2020 • 2 minute read
|
||||
|
||||
Privileged Access Management (PAM), or Privileged Account Management is a component of Identity and Access Management (IAM) that is designed to manage and monitor privileged access to accounts and applications, alerting system administrators on high-risk events.
|
||||
|
||||
Privileged access means higher access rights than other users. These elevated access rights are usually given to superusers and allow for full control of systems, applications and data.
|
||||
|
||||
PAM implementation is grounded in the principle of least privilege, granting all employees the minimum level of access with the ability to assign and elevate privileges as necessary. With measures like proxy technology and session management, PAM avoids comprising organizational systems and offers improved control and visibility to support auditing efforts and faster incident response.
|
||||
|
||||
PAM adds a layer of security to reduce risk, protect against external threats, and support organizational compliance.
|
||||
|
||||
## What Problems Does PAM Solve?
|
||||
|
||||
PAM helps to safeguard privileged access, users, and credentials against potential threat and [security breaches](https://www.sailpoint.com/identity-library/how-compromised-credentials-lead-to-data-breaches/). Beyond that, PAM offers your organization simplified onboarding and offboarding, increased productivity and compliance, and time saved. Its process automation streamlines workflows with simplified authentication and removed manual integration, allowing users to put more of their time into projects while ensuring everyone has the appropriate level of access to what they need.
|
||||
|
||||
And with records and live monitoring capability for sensitive information, you mitigate risk and have an inventory of activity prepared for audits and internal review.
|
||||
|
||||
## How Does PAM Work?
|
||||
|
||||
PAM is a high-assurance solution. It’s a centralized control that’s scalable across users and privileged accounts, with [password management](https://www.sailpoint.com/identity-library/password-management-best-practices/) and monitoring tools built in to reduce risk without sacrificing the end-user experience. Using proxy technology, PAM puts space between the privileged user and the information they’re trying to access, giving them access upon authentication and authorization, without ever revealing the password to them. Proxy servers can also record privileged activity, whether for later review or live audit.
|
||||
|
||||
## PAM Subcategories
|
||||
|
||||
Here are the management and monitoring tools PAM offers that might be a good fit for your organization.
|
||||
|
||||
### Shared access password manager (SAPM)
|
||||
|
||||
This measure removes the possibility of human error with storing, remembering, or coming up with unique passwords. It grants access to shared critical accounts with multi-factor authentication and establishes an audit trail to track activity.
|
||||
|
||||
### Superuser privilege management (SUPM)
|
||||
|
||||
Superusers are those who have the highest level of privilege within an organization (often the IT team) and can modify privileges, files, settings, users, or data. The superuser privilege manager capability allows superusers to designate temporary and permanent privilege elevations while hiding the account and password from the end-user.
|
||||
|
||||
### Privileged session management (PSM)
|
||||
|
||||
Privileged session management is a heightened security and compliance measure. It allows remote recording and review of active sessions and end session capability if needed. It connects the privileged admin with their target information without revealing the access password.
|
||||
|
||||
### Application access password manager (AAPM)
|
||||
|
||||
This functionality places password access in a centralized, secure location. It releases credentials at the correct time using an application programming interface (API), replacing the need for hard-coded passwords entirely.
|
||||
|
||||
Source: [Sailpoint](https://www.sailpoint.com/identity-library/what-is-privileged-access-management/), retrieved December 22, 2021
|
||||
|
||||
149
Corpus/Information Security/Ransomware Playbook.md
Normal file
149
Corpus/Information Security/Ransomware Playbook.md
Normal file
|
|
@ -0,0 +1,149 @@
|
|||
Also see:
|
||||
- [Mitigation steps for businesses](https://www.nomoreransom.org/en/prevention-advice-for-businesses.html) from the Europol [No More Ransom project](https://www.nomoreransom.org/nl/index.html).
|
||||
- [Nationaal Cyber Security Centrum](https://www.ncsc.nl/onderwerpen/ransomware)
|
||||
|
||||
See also:
|
||||
- [a-5.30-ICT-readiness-for-business-continuity](../Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md)
|
||||
- [BCP_Bedrijfscontinuïteitsplanning](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
|
||||
- [Disaster Recovery Planning](../ISMS/Disaster%20Recovery%20Planning.md)
|
||||
|
||||
3 Phases:
|
||||
- Prevention
|
||||
- During the attack
|
||||
- After the attack
|
||||
|
||||
# Prevention
|
||||
- Identify specific techniques attackers are using [A 5.7](../Standards/ISO27x/OST/27002/EN/a-5.7-Threat-intelligence.md)
|
||||
- Workforce education
|
||||
- Remove vulnerabilities / Attack surface reduction
|
||||
- Business Continuity Planning (BCP)
|
||||
- Ransom payment policy
|
||||
|
||||
## Workforce education
|
||||
|
||||
[ISO 27002 A 6.3](../iso27diy-corp/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.3_OT%20Information%20security%20awareness%2C%20education%20and%20training.md)
|
||||
|
||||
Education programs should address the following:
|
||||
|
||||
- Use caution when opening links or attachments by considering:
|
||||
- Do I know the sender?
|
||||
- Does this look suspicious?
|
||||
- Is this something that I should open or a link I should follow?
|
||||
|
||||
- Use a Virtual Private Network (VPN) to gain the benefits of implemented security controls.
|
||||
- Do not provide personal details when answering emails, phone calls, texts, or other messages,
|
||||
- Contact the IT department as soon as possible if you receive suspicious communication.
|
||||
- Validate IT resources and communications to ensure communications from new contacts are not an attempt at social engineering.
|
||||
- Alert the IT department before traveling internationally.
|
||||
|
||||
See also the [Guidelines for Regular Users](https://www.nomoreransom.org/en/prevention-advice-for-users.html) from the Europol No More Ransom project.
|
||||
|
||||
## Attack surface reduction
|
||||
|
||||
**Backup and restore**
|
||||
- Regularly back up your systems, online and offline. Up to date backups are the most effective way of recovering from a ransomware attack.
|
||||
- Ensure that you create offline backups that are kept in a different location (ideally offsite), from your network and systems, and/or in a cloud service designed for this purpose.
|
||||
- Perform tests on the critical information restoring process
|
||||
|
||||
**Coverage**
|
||||
- Periodically check your coverage (know what you are *not* monitoring) as part of your vulnerability management (VM) program [A 8.8](../Standards/ISO27x/OST/27002/EN/a-8.8-Management-of-technical-vulnerabilities.md)
|
||||
- Identify critical information assets
|
||||
- Store sensitive data in compartmented locations.
|
||||
- Ensure that critical assets are isolated through network segmentation [A 8.22](../Standards/ISO27x/OST/27002/EN/a-8.22-Segregation-of-networks.md)
|
||||
|
||||
**Testing and plugging for vulnerabilities**
|
||||
- Regularly run penetration tests
|
||||
- Scan for vulnerabilities in installed software
|
||||
- Scan your operating systems
|
||||
- See that all software is up to date and available patches are installed [A 8.8](../Standards/ISO27x/OST/27002/EN/a-8.8-Management-of-technical-vulnerabilities.md)
|
||||
- Know indicators of ransomware and block them from executing (e.g. by scanning mails for executable attachments)
|
||||
- Disable the execution of email attachments
|
||||
- block malicious websites, applications, protocols, etc. through content inspection
|
||||
- Implement blacklisting/whitelisting rules based on live threat intelligence feeds
|
||||
- Use anti-spear-phishing software that inspects links and attachments at the mail server
|
||||
- Keep antivirus and anti-malware products up to date
|
||||
- Disable scripting and macro's (e.g. MS Office macros)
|
||||
- preventing activation of OLE packages in Microsoft Word
|
||||
- Disable Windows PowerShell
|
||||
- Use RDP (Remote Desktop Protocols) only when absolutely necessary, and then only with MFA
|
||||
- Block access to high-risk category websites (adult material, games, gambling, advertisements, peer-to-peer file sharing)
|
||||
- Monitor data exfiltration: many ransomware campaigns come with the threat of releasing data to encourage businesses to pay the ransom
|
||||
- Implement measures such as hard disk encryption, inactivity timeouts, privacy screens, strong authentication, Bluetooth disability and removable media control and encryption (e.g. USB drives).
|
||||
- Disable (or constrict) use of removable media
|
||||
- Implement a process to remotely disable access to a device that has been lost or stolen.
|
||||
- permit the installation of apps from official sources only
|
||||
- Turn on local firewalls
|
||||
- develop effective use policies for use of public Wi-Fi networks
|
||||
|
||||
**Identity and Access Management**
|
||||
- Manage account permissions, especially for administrative rights on endpoints ([A 5.15](../Standards/ISO27x/OST/27002/EN/a-5.15-Access-control.md), [A 5.18](../Standards/ISO27x/OST/27002/EN/a-5.18-Access-rights.md)). This includes:
|
||||
- Restricting write permissions for servers
|
||||
- Restricting admin users and privileged accounts
|
||||
- Granting users the lowest-level system permissions that still allow them to do their job
|
||||
- Removing abilities for users to install and run unapproved software applications / use Application whitelisting
|
||||
- Limiting administrative tools on workstations
|
||||
- creating separate user accounts for privileged and non-privileged activities
|
||||
- Organise access rights based on the principles of least privilege, need to know principle and segregation of duties
|
||||
- ensure the use of unique passwords, esp. for accounts with elevated rights
|
||||
- Use enhanced passwords and change them on a regular basis
|
||||
- Use multi-factor authentication (MFA)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- Train your staff
|
||||
- Consider cyber liability insurance
|
||||
|
||||
|
||||
|
||||
## Business Continuity Planning (BCP)
|
||||
[A 5.29](../Standards/ISO27x/OST/27002/EN/a-5.29-Information-security-during-disruption.md), [A 5.30](../Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md)
|
||||
|
||||
- Employ a comprehensive data backup and recovery plan for all high-value data
|
||||
- Backups should be isolated on external storage devices or in the cloud, disconnected and inaccessible from any potentially infected computer once the backup is completed.
|
||||
See also [BCP_Bedrijfscontinuïteitsplanning](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
|
||||
|
||||
## Ransom payment policy
|
||||
if your files are encrypted, what do you do?
|
||||
|
||||
|
||||
# During the attack
|
||||
Remove infected systems from the environment, by disabling physical network ports or removing the network cable.
|
||||
|
||||
Check the Europol [No More Ransom project ](https://www.nomoreransom.org), specifically to see if a decryption solution is available with the [Crypto Sheriff ](https://www.nomoreransom.org/crypto-sheriff.php?lang=en)tool or on their [Decryption Tools](https://www.nomoreransom.org/en/decryption-tools.html) page.
|
||||
|
||||
## Infected… What to do next?
|
||||
|
||||
1. Immediately disconnect, but don’t switch off the infected device(s) from all network connections, whether wired, wireless or mobile phone based.
|
||||
2. In very serious cases, consider whether turning off your Wi-Fi, disabling any core network connections (including switches), and disconnecting from the internet might be necessary.
|
||||
3. Reset credentials, including passwords (especially for administrator and other system accounts), but verify that you are not locking yourself out of systems that are needed for recovery.
|
||||
4. [Report the incident](https://www.nomoreransom.org/en/report-a-crime.html) to your national police or other competent authority.
|
||||
5. Preserve any evidence, in coordination with the competent authorities investigating the attack: create a forensic image of affected systems (or a system snapshot), create a RAM dump of the affected systems, and preserve any netflow or other network traffic logs.
|
||||
6. Visit [www.nomoreransom.org](https://www.nomoreransom.org/) to check whether your business was infected with one of the ransomware variants for which we have [decryption tools](https://www.nomoreransom.org/en/decryption-tools.html) available free of charge. If that’s not the case, proceed with the recovery steps.
|
||||
7. Safely wipe the infected devices and reinstall the OS.
|
||||
8. Before you restore from a backup, verify that it is free from any malware. You should only restore if you are very confident that the backup and the device you are connecting it to are clean.
|
||||
9. Connect devices to a clean network to download, install and update the OS and all other software.
|
||||
10. Install, update, and run antivirus software.
|
||||
11. Reconnect to your network.
|
||||
12. Monitor network traffic and run antivirus scans to identify if any infection remains.
|
||||
|
||||
# After the attack
|
||||
Inspect your environment to:
|
||||
- confirm the attackers no longer have a presence in your system
|
||||
- know if they have stolen data or caused other harm
|
||||
|
||||
Harden your systems against a similar attack
|
||||
rebuild or recover systems impacted by the attack.
|
||||
|
||||
- rebuild systems from known-good baseline images to counter undetected threats.
|
||||
- scan systems with an up-to-date anti-malware solution to remove malware and related artifacts.
|
||||
- block malicious domain(s) and IP addresses. This should be performed at all appropriate network filtering and domain name server devices such as firewalls, web proxies, switches, and DNS servers.
|
||||
- terminate malicious processes on the compromised endpoint(s) identified.
|
||||
- quarantine affected endpoints from the network.
|
||||
- lock affected compromised account(s) until the credentials can be rotated.
|
||||
- changing affected account(s) password(s) as soon as possible to prevent an attacker from leveraging the credentials to access services.
|
||||
- determining whether other users received malicious communications and removing them from all mailboxes.
|
||||
- blocking the sender’s email address (if applicable).
|
||||
|
||||
|
||||
BIN
Corpus/Information Security/Red Blue Purple-pyramid-miessler.png
Normal file
BIN
Corpus/Information Security/Red Blue Purple-pyramid-miessler.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 228 KiB |
14
Corpus/Information Security/Red, Blue, and Purple Teams.md
Normal file
14
Corpus/Information Security/Red, Blue, and Purple Teams.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
# Red, Blue, and Purple Teams
|
||||
|
||||
By Daniel Miessler
|
||||
[Source](https://danielmiessler.com/study/red-blue-purple-teams/), retrieved December 23, 2021
|
||||
|
||||
- **Red Team** tests the effectiveness of a security program by emulating the tools and techniques of likely attackers.
|
||||
- **Blue Team** is the internal security team that defends against attackers. Should be distinguished from standard security operations teams, as most do not have a mentality of constant vigilance against attack.
|
||||
- **Purple team** integrates the defensive tactics and controls from the Blue Team with the threats and vulnerabilities found by the Red Team. Exists to ensure and maximize the effectiveness of both. Not a team as such, but rather a permanent dynamic between Red and Blue.
|
||||
|
||||
|
||||
|
||||
Related:
|
||||
[ISO 27001 A.14.2.8 System security testing](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A.14.2.8%20System%20security%20testing.md)
|
||||
[ISO 27001 A.14.2.9 System acceptance testing](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A.14.2.9%20System%20acceptance%20testing.md)
|
||||
|
|
@ -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.
|
|
@ -0,0 +1,78 @@
|
|||
# Roles in Identity and Access Management (IAM)
|
||||
|
||||
See also: [Access Control Models](../ISMS/Access%20Control%20Models.md)
|
||||
|
||||
## Rollen in autorisatiebeheer
|
||||
|
||||
- Wie bepaalt de autorisaties per rol? – opstellen autorisatiematrix (autorisaties per rol)
|
||||
- Wie wijst de autorisaties toe aan personen? - toekennen rol(len) aan persoon
|
||||
- Wie configureert het in het systeem?
|
||||
- Wie controleert periodiek of het klopt?
|
||||
|
||||
## In general
|
||||
|
||||
In the context of assigning rights to information access and administrative privileges within software applications, the roles of Data Owner, Data Steward, IT Administrator, Security Officer, and User play distinct and interconnected parts:
|
||||
|
||||
**Data Owner**:
|
||||
- **Role**: The Data Owner is an individual or a business unit that is responsible for the data within the organization. They have ultimate accountability for the data's use, quality, and security.
|
||||
- **Responsibilities**:
|
||||
- Define who should have access to the data and what level of access is required.
|
||||
- Set data protection policies and ensure compliance with legal and organizational standards.
|
||||
- Approve access requests and make decisions about data usage.
|
||||
- Oversee data lifecycle management, including data classification and retention.
|
||||
|
||||
**Data Steward**:
|
||||
- **Role**: The Data Steward acts as a custodian of data on behalf of the Data Owner, ensuring that data governance policies are implemented and adhered to.
|
||||
- **Responsibilities**:
|
||||
- Maintain data quality, integrity, and protection.
|
||||
- Implement data management policies and procedures established by the Data Owner.
|
||||
- Facilitate data accessibility for authorized users and ensure security measures are applied.
|
||||
- Monitor and audit data usage to ensure compliance with established guidelines.
|
||||
|
||||
**IT Administrator**:
|
||||
- **Role**: IT Administrators are responsible for the technical implementation and maintenance of IT systems, including managing access controls and user accounts.
|
||||
- **Responsibilities**:
|
||||
- Implement and manage access control systems and permissions according to policies defined by Data Owners.
|
||||
- Ensure systems are secure, updated, and operating efficiently.
|
||||
- Troubleshoot and resolve access-related issues for users.
|
||||
- Collaborate with security personnel to enforce security measures and monitor for breaches.
|
||||
|
||||
**Security Officer**:
|
||||
- **Role**: The Security Officer focuses on protecting an organization's data and IT infrastructure from breaches and ensuring compliance with security policies.
|
||||
- **Responsibilities**:
|
||||
- Develop, implement, and oversee security policies and procedures to safeguard data.
|
||||
- Conduct risk assessments and audits to identify vulnerabilities.
|
||||
- Respond to security incidents and breaches by implementing corrective actions.
|
||||
- Provide guidance and training to staff on security best practices and compliance requirements.
|
||||
|
||||
**User**:
|
||||
- **Role**: Users are the individuals or entities that require access to data and applications for daily operational tasks.
|
||||
- **Responsibilities**:
|
||||
- Access and use data and applications in compliance with organizational policies and procedures.
|
||||
- Protect access credentials and report any security incidents or suspicious activities.
|
||||
- Adhere to data handling and privacy standards set forth by Data Owners and Security Officers.
|
||||
- Participate in relevant training programs to stay informed about security practices.
|
||||
|
||||
|
||||
Each of these roles contributes to a comprehensive framework for managing information security, ensuring that applications and data are accessed appropriately and remain protected from unauthorized access or misuse. The coordination between these roles helps in aligning technical controls with organizational policies to maintain security and compliance.
|
||||
|
||||
|
||||
## IAM for Google Cloud
|
||||
[Source](https://cloud.google.com/iam/docs/understanding-roles)
|
||||
### Basic roles
|
||||
|
||||
| Role | Permissions |
|
||||
| ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Viewer | Permissions for read-only actions that do not affect state, such as viewing (but not modifying) existing resources or data. |
|
||||
| Editor | All viewer permissions, **plus** permissions for actions that modify state, such as changing existing resources. |
|
||||
| Owner | All Editor permissions **and** permissions for the following actions: - Manage roles and permissions for a project and all resources within the project. - Set up billing for a project. |
|
||||
|
||||
### Access approval roles
|
||||
|
||||
| Role | Permissions |
|
||||
| ----------- | ----------------------------------------------- |
|
||||
| Approver | Act on access approval requests |
|
||||
| Editor | Update the Access Approval configuration |
|
||||
| Invalidator | Invalidate approved requests |
|
||||
| Viewer | View access approval requests and configuration |
|
||||
|
||||
|
|
@ -0,0 +1,84 @@
|
|||
See also:
|
||||
- [a-5.2-Information-security-roles-and-responsibilities](../Standards/ISO27x/OST/27002/EN/a-5.2-Information-security-roles-and-responsibilities.md)
|
||||
- [a-5.3-Segregation-of-duties](../Standards/ISO27x/OST/27002/EN/a-5.3-Segregation-of-duties.md)
|
||||
|
||||
For examples of defined roles, see:
|
||||
- Platform 161, ISP §3.6
|
||||
- Open-ICT
|
||||
- Methode NHC
|
||||
- [OrgFit Architectuurprincipes Humankind](../../Clients/Humankind/OrgFit%20Architectuurprincipes%20Humankind.md)
|
||||
|
||||
Related:
|
||||
- [Asset ownership](../Sparks/Asset%20ownership.md)
|
||||
- [Control ownership](../ISMS/Control%20ownership.md)
|
||||
- [Risk ownership](Risks/Risk%20ownership.md)
|
||||
- [Segregation of Duties](../ISMS/Segregation%20of%20Duties.md)
|
||||
- [Access Control Models](../ISMS/Access%20Control%20Models.md)
|
||||
|
||||
**Roles according to CISSP (p. 23 ev.):**
|
||||
* Senior Manager: decides on policies, ultimately responsible.
|
||||
* Security Professional: writes and implements the policies.
|
||||
* Data Owner: classifies information, ultimately responsible for protection of his data.
|
||||
* Data Custodian: responsible for implementing the controls.
|
||||
* User: has access to the protected information. Responsible for understanding and following the security policy.
|
||||
* Auditor: reviews the policy, verifies that it is properly implemented, and that the implemented controls are adequate.
|
||||
|
||||
**Roles according to [source](https://groups.google.com/g/iso27001security/c/z4DwcXmZGo4):**
|
||||
|
||||
Information security functions are generally split across several areas :
|
||||
|
||||
1. Information security management
|
||||
- setting direction;
|
||||
- setting policy;
|
||||
- analysing and advising on the treatment of information security risks;
|
||||
- developing or commissioning standards, procedures and guidelines, plus security awareness and training materials;
|
||||
- liaising with general management, risk management, HR, legal etc. on information security matters;
|
||||
- security incident management;
|
||||
- ISMS management and direction.
|
||||
- line management for the security function;
|
||||
- Staffed with security managers and security officers.
|
||||
2. Information security administration/operations
|
||||
- user access management (access rights, passwords, joiners/movers/leavers);
|
||||
- log analysis;
|
||||
- security awareness & training delivery;
|
||||
- assisting with incidents and investigations etc.
|
||||
- Staffed with security analysts.
|
||||
3. Information security architecture & design
|
||||
- pushing information security deep into IT application development, IT procurement etc.;
|
||||
- providing architectural guidance, policies and standards on various security matters (such as authentication, cryptography and security logs) etc.
|
||||
- Staffed with security architects.
|
||||
4. Physical/site security
|
||||
- often an independent function but with close liaison to information security.
|
||||
- Staffed with security guards.
|
||||
5. Fraud
|
||||
- again, often independent but with liaison, especially for incident investigation and analysis.
|
||||
- Staffed with fraud specialists.
|
||||
|
||||
[This article](https://ins2outs.com/roles-required-implementing-isoiec-27001-information-security-management-system/) defines 6 roles and assigns responsibilities to each role:
|
||||
* Employee
|
||||
* Information Security Officer
|
||||
* IT Administrator
|
||||
* Top Management
|
||||
* Internal auditor
|
||||
* Data Protection Officer
|
||||
|
||||
[This article](https://risk3sixty.com/2019/09/03/iso-27001-understanding-security-roles-and-responsibilities-and-why-they-are-vital-to-the-success-of-your-security-program/) identifies five ‘typical roles and responsibilities’:
|
||||
* Security leadership
|
||||
* Security risk management
|
||||
* Internal audit
|
||||
* Control owners
|
||||
* All employees
|
||||
|
||||
[This article](https://info-savvy.com/iso-27001-clause-5-3-and-clause-7-1-resources-and-roles-responsibility/) identifies somewhat different roles:
|
||||
* Information owners;
|
||||
* Process owners;
|
||||
* Asset owners (e.g. application or infrastructure owners);
|
||||
* Risk owners;
|
||||
* Information security coordinating functions or persons (this particular role is generally a supporting role within the ISMS);
|
||||
* Project managers;
|
||||
* Line managers;
|
||||
* Information users.
|
||||
|
||||
|
||||
|
||||
|
||||
176
Corpus/Information Security/Safeguard information in Transit.md
Normal file
176
Corpus/Information Security/Safeguard information in Transit.md
Normal file
|
|
@ -0,0 +1,176 @@
|
|||
# Safeguard information in transit
|
||||
|
||||
https://gemini.google.com/app/5252e842a604bd7a
|
||||
|
||||
Measures to safeguard information in transit are crucial to prevent unauthorized access, modification, or eavesdropping while data is being transferred between locations or systems.1 Here's a breakdown of key measures:
|
||||
|
||||
### 1. Encryption
|
||||
|
||||
Encryption is the most fundamental measure to protect data in transit. It transforms data into an unreadable format (ciphertext), making it incomprehensible to anyone who intercepts it without the correct decryption key.2
|
||||
|
||||
- **Types of Encryption:**
|
||||
- **Symmetric Encryption:** Uses the same key for both encryption and decryption.3 It's faster but requires secure key exchange. Examples include AES (Advanced Encryption Standard), and Triple DES.
|
||||
|
||||
- **Asymmetric Encryption:** Uses a pair of keys: a public key for encryption and a private key for decryption. The public key can4 be shared, but the private key remains secret. Examples include RSA (Rivest–Shamir–Adleman) and ECC (Elliptic Curve Cryptography). Asymmetric encryption is often used to securely exchange symmetric keys.
|
||||
- **Protocols Utilizing Encryption:**
|
||||
- **Transport Layer Security (TLS) / Secure Sockets Layer (SSL):** These protocols establish an encrypted connection between a client and a server, ensuring the confidentiality and integrity of5 data transmitted over networks, including the internet. HTTPS (HTTP over SSL/TLS) is a common application of this for secure web browsing.6
|
||||
|
||||
- **Secure Shell (SSH):** Provides a secure channel for network services by encrypting the traffic.7 It's commonly used for remote server administration and secure file transfers (SFTP, SCP).8
|
||||
|
||||
- **IPsec (Internet Protocol Security):** A suite of protocols used to secure IP communications by authenticating and encrypting each IP packet of a communication session.910 It's often used for VPNs (Virtual Private Networks).11
|
||||
|
||||
- **Wireless Protected Access (WPA2, WPA3):** Security protocols used to encrypt data transmitted over Wi-Fi networks.12
|
||||
|
||||
|
||||
### 2. Secure Communication Protocols
|
||||
|
||||
Using secure communication protocols ensures that data is transmitted over encrypted and authenticated channels.13
|
||||
|
||||
- **HTTPS:** The secure version of HTTP, using TLS/SSL to encrypt web traffic between a user's browser and a web server.14
|
||||
|
||||
- **SFTP (Secure File Transfer Protocol):** A secure protocol for transferring files that uses SSH for encryption and authentication.15
|
||||
|
||||
- **FTPS (FTP Secure):** An extension to the File Transfer Protocol (FTP) that adds support for TLS and SSL encryption.
|
||||
|
||||
### 3. Network Security Controls
|
||||
|
||||
Implementing robust network security controls helps to protect the networks used to transmit data from unauthorized access and malicious activities.16
|
||||
|
||||
- **Firewalls:** Control network traffic by allowing or blocking connections based on predefined security rules.17
|
||||
|
||||
- **Intrusion Detection and Prevention Systems (IDPS):** Monitor network traffic for suspicious activity and can automatically block or prevent potential attacks.18
|
||||
|
||||
- **Network Segmentation:** Dividing the network into isolated segments to limit the impact of a security breach.19
|
||||
|
||||
- **Network Access Control (NAC):** Enforces security policies on devices and users before granting access to the network.20
|
||||
|
||||
- **VPNs (Virtual Private Networks):** Create secure, encrypted tunnels over a public network, such as the internet, to protect data transmitted between the user and the private network.21
|
||||
|
||||
|
||||
### 4. Authentication and Authorization
|
||||
|
||||
Verifying the identity of users and systems and ensuring they only have access to the data and resources they are authorized to use is critical.
|
||||
|
||||
- **Strong Authentication Methods:** Using strong passwords, multi-factor authentication (MFA), biometrics, or digital certificates to verify user identities.22
|
||||
|
||||
- **Role-Based Access Control (RBAC):** Limiting data access based on user roles and responsibilities within an organization.
|
||||
- **Mutual Authentication:** Ensuring that both the client and the server authenticate each other before establishing a secure connection.23
|
||||
|
||||
|
||||
### 5. Physical Security
|
||||
|
||||
For data transmitted via physical media (e.g., hard drives, tapes), physical security measures are essential.
|
||||
|
||||
- **Secure Transportation:** Using secure couriers or methods for transporting physical media.24
|
||||
|
||||
- **Tamper-Proof Packaging:** Protecting media from unauthorized access or modification during transit.25
|
||||
|
||||
- **Encryption at Rest:** Encrypting the data stored on the physical media itself adds an extra layer of security in case of loss or theft.26
|
||||
|
||||
|
||||
### 6. Monitoring and Logging
|
||||
|
||||
Continuously monitoring network traffic and logging access attempts and data transfers can help detect and respond to security incidents.27
|
||||
|
||||
- **Security Information and Event Management (SIEM) Systems:** Aggregate and analyze security logs from various sources to identify28 potential threats.29
|
||||
|
||||
- **Audit Trails:** Maintaining detailed records of data access and transfer activities.30
|
||||
|
||||
|
||||
### 7. Security Policies and Procedures
|
||||
|
||||
Establishing and enforcing clear security policies and procedures for data handling and transmission is crucial.
|
||||
|
||||
- **Data Classification:** Categorizing data based on its sensitivity to ensure appropriate security measures are applied.31
|
||||
|
||||
- **Secure Data Handling Guidelines:** Providing employees with guidelines on how to handle and transmit sensitive data securely.
|
||||
- **Regular Security Training:** Educating employees about data security best practices and potential threats.
|
||||
|
||||
By implementing a combination of these measures, organizations can significantly enhance the security of their information while it is in transit, reducing the risk of data breaches and ensuring the confidentiality, integrity, and availability of their valuable data.
|
||||
## 2
|
||||
|
||||
Ensuring data availability means that authorized users can access and use the information they need, whenever they need it. This is a critical aspect of information security, alongside confidentiality and integrity.1 Here are several security measures that can be applied to ensure data availability:
|
||||
|
||||
### 1. Redundancy and Fault Tolerance2
|
||||
|
||||
Implementing redundant systems and components minimizes single points of failure and ensures that if one part fails, another can take over seamlessly.3
|
||||
|
||||
- **Hardware Redundancy:**
|
||||
- **RAID (Redundant Array of Independent Disks):** Combines multiple physical disk drives into a single logical unit to provide data redundancy and improve performance.4 Different RAID levels offer varying degrees of fault tolerance.5
|
||||
|
||||
- **Redundant Power Supplies:** Protect against power outages affecting a single power source.6
|
||||
|
||||
- **Redundant Network Interfaces:** Provide alternative network connections in case of a failure.7
|
||||
|
||||
- **Clustering:** Grouping multiple servers to work together. If one server fails, another in the cluster can take over its workload.8
|
||||
|
||||
- **Software Redundancy:**
|
||||
- **Load Balancing:** Distributes network traffic across multiple servers to prevent any single server from being overwhelmed and becoming unavailable.9
|
||||
|
||||
- **Failover Systems:** Standby systems that automatically take over in the event of a primary system failure.10
|
||||
|
||||
|
||||
### 2. Backups and Disaster Recovery
|
||||
|
||||
Regularly backing up data and having a robust disaster recovery plan is essential for restoring data and services after an outage or disaster.11
|
||||
|
||||
- **Regular Data Backups:** Performing frequent backups of critical data to separate storage media or locations.12 Different backup strategies (full, incremental, differential) can be employed.13
|
||||
|
||||
- **Offsite Backups:** Storing backups in a geographically separate location to protect against localized disasters.
|
||||
- **Disaster Recovery Plan (DRP):** A documented plan outlining the procedures for recovering IT infrastructure and data after a disruptive event.14 This includes steps for data restoration, system recovery, and business continuity.15
|
||||
|
||||
- **Regular Testing of Backups and DRP:** Periodically testing the backup and recovery processes to ensure their effectiveness and identify any potential issues.16
|
||||
|
||||
|
||||
### 3. Power Management and Protection
|
||||
|
||||
Stable and reliable power is crucial for the continuous operation of IT systems.17
|
||||
|
||||
- **Uninterruptible Power Supplies (UPS):** Provide short-term battery backup during power outages, allowing systems to shut down gracefully or continue operating for a limited time.18
|
||||
|
||||
- **Surge Protectors:** Protect equipment from power surges that can cause hardware damage and downtime.19
|
||||
|
||||
- **Redundant Power Circuits:** Having multiple power feeds to a data center or critical infrastructure.20
|
||||
|
||||
- **Backup Generators:** Provide long-term power backup during extended power outages.21
|
||||
|
||||
|
||||
### 4. Environmental Controls
|
||||
|
||||
Maintaining the proper environmental conditions is essential for the reliable operation of hardware.22
|
||||
|
||||
- **Temperature and Humidity Control:** Preventing overheating and excessive humidity that can damage equipment and lead to failures.
|
||||
- **Fire Suppression Systems:** Protecting against fire hazards that can cause significant data loss and system unavailability.
|
||||
|
||||
### 5. Network Resilience
|
||||
|
||||
Ensuring the network infrastructure is robust and can withstand failures is critical for data accessibility.
|
||||
|
||||
- **Redundant Network Paths:** Having multiple network connections and paths to prevent a single point of failure from disrupting connectivity.23
|
||||
|
||||
- **Redundant Network Devices:** Implementing backup routers, switches, and other network devices.
|
||||
- **Quality of Service (QoS):** Prioritizing critical network traffic to ensure essential services remain available even during periods of high network load.24
|
||||
|
||||
|
||||
### 6. Security Measures Against Attacks
|
||||
|
||||
Protecting systems and data from security threats that can lead to unavailability is paramount.
|
||||
|
||||
- **Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) Protection:** Implementing measures to mitigate and prevent attacks that aim to overwhelm systems and make them unavailable. This includes firewalls, intrusion prevention systems, traffic filtering, and content delivery networks (CDNs).
|
||||
- **Malware Protection:** Using antivirus and anti-malware software to prevent infections that can corrupt or delete data and disrupt system operations.
|
||||
- **Intrusion Detection and Prevention Systems (IDPS):** Identifying and blocking malicious attempts to access or disrupt systems.25
|
||||
|
||||
- **Regular Security Patching and Updates:** Keeping operating systems, applications, and firmware up to date to address known vulnerabilities that attackers could exploit to cause downtime.26
|
||||
|
||||
- **Access Control and Authentication:** Implementing strong authentication and authorization mechanisms to prevent unauthorized access that could lead to accidental or malicious data deletion or system disruption.27
|
||||
|
||||
|
||||
### 7. Monitoring and Alerting
|
||||
|
||||
Continuous monitoring of systems and infrastructure helps detect potential issues before they lead to outages.28
|
||||
|
||||
- **System Monitoring Tools:** Tracking resource utilization, performance metrics, and system health to identify anomalies and potential failures.29
|
||||
|
||||
- **Automated Alerting:** Configuring alerts to notify administrators of critical events or potential problems so they can be addressed proactively.
|
||||
|
||||
By implementing a comprehensive set of these security measures, organizations can significantly improve the availability of their data and minimize the risk of disruptions that could impact business operations. The specific measures adopted will depend on the organization's specific needs, risk tolerance, and resources.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
Source: Agile Project Management for Dummies, Mark C. Layton, 2012
|
||||
Pages 73-74
|
||||
|
||||
Scrum roles:
|
||||
- Product owner: represents the business needs of the project;
|
||||
- Development team: cross-functional team that performs the day-to-day work, ideally dedicated to the project;
|
||||
- Scrum master: protects the team from organizational distractions, clearing roadblocks/impediments, keeping the process consistent.
|
||||
|
||||
Scrum artifacts:
|
||||
- Product backlog: full list of (current) requirements for the product, often in the form of user stories;
|
||||
- Sprint backlog: list of requirements and tasks for a given sprint, selected by the Product owner and the Development team in the sprint planning;
|
||||
- Product increment: the usable product.
|
||||
|
||||
Scrum events:
|
||||
- Sprint planning meetings, in which the scrum team decides what will be in the sprint backlog;
|
||||
- Daily scrum meeting, in which each team member states what was completed yesterday, what will be worked on today, and any impediments stand in the way of progress;
|
||||
- Sprint review meeting, where the development team, at the end of each sprint, demonstrates the results of the sprint to the stakeholders;
|
||||
- Sprint retrospective, an internal team meeting in which the scrum team members (PO, SM, DT) evaluate the sprint that was just finished and how the process can be improved for the next sprint.
|
||||
|
|
@ -0,0 +1,115 @@
|
|||
# Securely migrating SaaS applications
|
||||
## Migration steps
|
||||
|
||||
*Prompt: what are the steps in migrating from one SaaS application to another?*
|
||||
|
||||
Migrating from one SaaS (Software as a Service) application to another can be a complex process that requires careful planning and execution. Here are the general steps to follow:
|
||||
|
||||
1. **Assess Current Requirements and Future Needs:**
|
||||
- Evaluate the current application to understand its functionality, limitations, and usage.
|
||||
- Define the requirements and expectations for the new application.
|
||||
- Consider future scalability and potential growth needs.
|
||||
|
||||
2. **Research and Selection:**
|
||||
- Identify alternative SaaS applications that meet your requirements.
|
||||
- Compare features, pricing, support, user reviews, and compatibility with existing systems.
|
||||
- Conduct trials or demos if possible to assess usability and fit.
|
||||
|
||||
3. **Plan the Migration:**
|
||||
- Create a detailed migration plan outlining timelines, responsibilities, and resources needed.
|
||||
- Identify data to be migrated and determine the data mapping process.
|
||||
- Establish success metrics and KPIs for the migration project.
|
||||
|
||||
4. **Prepare the Data:**
|
||||
- Cleanse and validate data to ensure accuracy and consistency.
|
||||
- Backup all data to prevent data loss during migration.
|
||||
- Decide on the method of data transfer (manual, automated tools, third-party services).
|
||||
|
||||
5. **Configure the New Application:**
|
||||
- Set up the new SaaS application according to your organization’s needs.
|
||||
- Customize settings, user roles, permissions, and workflows.
|
||||
- Integrate with other critical systems and tools if necessary.
|
||||
|
||||
6. **Execute the Migration:**
|
||||
- Conduct a pilot migration with a subset of data to test the process.
|
||||
- Address any issues identified during the pilot phase.
|
||||
- Perform the full migration once the pilot is successful and adjustments are made.
|
||||
|
||||
7. **Testing and Validation:**
|
||||
- Perform thorough testing to ensure that all data has been migrated accurately.
|
||||
- Validate the functionality of the new application against predefined success metrics.
|
||||
- Ensure that integrations and workflows operate as intended.
|
||||
|
||||
8. **Training and Change Management:**
|
||||
- Train users on the new application and provide resources like guides and tutorials.
|
||||
- Communicate changes effectively across the organization to minimize resistance.
|
||||
- Address user feedback and provide ongoing support.
|
||||
|
||||
9. **Go Live and Monitor:**
|
||||
- Transition fully to the new application once testing and training are complete.
|
||||
- Monitor the application for any issues post-migration.
|
||||
- Collect feedback and make adjustments to optimize performance and user experience.
|
||||
|
||||
10. **Review and Optimization:**
|
||||
- Review the migration process to identify lessons learned and areas for improvement.
|
||||
- Optimize processes and settings based on user feedback and operational needs.
|
||||
- Plan for regular evaluations to ensure the application continues to meet business requirements.
|
||||
|
||||
Throughout the migration process, maintain clear communication with stakeholders and ensure there is a contingency plan in place in case issues arise.
|
||||
|
||||
## Information security during these steps
|
||||
|
||||
*Prompt: what activities should be undertaken with regards to information security for these different steps?*
|
||||
|
||||
Information security is critical during the migration from one SaaS application to another to protect sensitive data and ensure compliance with relevant regulations. Here’s how security considerations can be integrated into each step of the migration process:
|
||||
|
||||
1. **Assess Current Requirements and Future Needs:**
|
||||
- Conduct a security audit of the current application to identify vulnerabilities and gaps.
|
||||
- Evaluate security requirements for the new application, including compliance standards such as GDPR, HIPAA, or others relevant to your industry.
|
||||
|
||||
2. **Research and Selection:**
|
||||
- Assess the security features of potential SaaS alternatives, including data encryption, access controls, and compliance certifications.
|
||||
- Review the security policies and incident history of prospective vendors.
|
||||
- Choose a vendor with a strong track record in information security.
|
||||
|
||||
3. **Plan the Migration:**
|
||||
- Develop a security plan that outlines measures to protect data during the migration.
|
||||
- Establish clear security roles and responsibilities for the migration team.
|
||||
- Include a risk management plan with identified risks and mitigation strategies.
|
||||
|
||||
4. **Prepare the Data:**
|
||||
- Classify data based on sensitivity and apply appropriate levels of encryption.
|
||||
- Ensure data is backed up securely before any migration activities.
|
||||
- Implement data loss prevention measures to protect data integrity.
|
||||
|
||||
5. **Configure the New Application:**
|
||||
- Use strong authentication mechanisms and enforce the principle of least privilege for user roles.
|
||||
- Configure security settings, such as encryption and two-factor authentication, according to best practices.
|
||||
- Set up audit logs and monitoring to track access and changes in the application.
|
||||
|
||||
6. **Execute the Migration:**
|
||||
- Use secure methods and tools for data transfer, such as encrypted connections and VPNs.
|
||||
- Regularly monitor the migration process for any unauthorized access or anomalies.
|
||||
- Maintain a record of data transfer activities for accountability and auditing purposes.
|
||||
|
||||
7. **Testing and Validation:**
|
||||
- Perform security testing, including vulnerability scans and penetration tests, on the new application.
|
||||
- Validate that access controls and data protection measures are functioning as required.
|
||||
- Ensure that data integrity and confidentiality are maintained during and after the migration.
|
||||
|
||||
8. **Training and Change Management:**
|
||||
- Provide security awareness training for users focused on the new application’s security features and protocols.
|
||||
- Communicate the importance of security practices such as strong passwords and phishing awareness.
|
||||
- Have a clear procedure for reporting security incidents or vulnerabilities found by users.
|
||||
|
||||
9. **Go Live and Monitor:**
|
||||
- Implement continuous monitoring for security threats using security information and event management (SIEM) systems.
|
||||
- Regularly review access logs and unusual activity alerts.
|
||||
- Establish an incident response plan to quickly address any security issues post-go-live.
|
||||
|
||||
10. **Review and Optimization:**
|
||||
- Conduct a post-migration security review to identify any weak points or vulnerabilities.
|
||||
- Optimize security configurations based on feedback and security audits.
|
||||
- Plan for regular security audits and updates to adapt to new threats or changes in regulatory requirements.
|
||||
|
||||
By embedding security considerations throughout the migration process, you can mitigate risks and ensure that your data remains protected before, during, and after the transition.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 483 KiB |
|
|
@ -0,0 +1,13 @@
|
|||
# The Seven Dimensions of Security Culture
|
||||
|
||||
The Security Culture Survey measures the sentiments of your users towards security in your organization – the psychological and social aspects that drive social behavior. Specifically, the SCS measures seven dimensions of security culture which include:
|
||||
|
||||
- **ATTITUDES -** The feelings and beliefs that employees have toward the security protocols and issues.
|
||||
- **BEHAVIOR -** The actions and activities of employees that have direct or indirect impact on the security of the organization.
|
||||
- **COGNITION -** The employees’ understanding, knowledge and awareness of security issues and activities.
|
||||
- **COMMUNICATION -** The quality of communication channels to discuss security-related events, promote a sense of belonging, and provide support for security issues and incident reporting.
|
||||
- **COMPLIANCE -** The knowledge of written security policies and the extent that employees follow them.
|
||||
- **NORMS -** Unwritten expectations regarding appropriate behaviors pertaining to usage of information technology in organizational context, perception of what practices are normal and unproblematic.
|
||||
- **RESPONSIBILITY -** The employees’ perceived role as a critical factor in sustaining or endangering the security of the organization.
|
||||
|
||||
https://research.knowbe4.com/security-culture-survey
|
||||
34
Corpus/Information Security/Single Sign On (SSO).md
Normal file
34
Corpus/Information Security/Single Sign On (SSO).md
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
Related:
|
||||
- [a-5.17-Authentication-information](../Standards/ISO27x/OST/27002/EN/a-5.17-Authentication-information.md)
|
||||
- [Types of SSO](Types%20of%20SSO.md)
|
||||
|
||||
Single Sign-On or SSO is an authentication process that allows consumers to log in to multiple independent applications with a single set of credentials. With SSO, users can access a suite of applications via one single login, irrespective of the platform, technology, or domain used.
|
||||
|
||||
On a similar note, it is also a challenge for both users and IT administrators to secure thousands of accounts and related user data.
|
||||
|
||||
For both users and IT administrators, securely handling thousands of accounts and related user data is challenging. Enterprises use single sign-on as a single strategy to improve IT security, improve user experience, and cut IT cost in one go.
|
||||
|
||||
## Advantages of SSO
|
||||
|
||||
- **Reduces password fatigue.** Remembering one password instead of many makes users’ lives easier. As a tangential benefit, it gives users greater incentive to come up with strong passwords.
|
||||
- **Simplifies username and password management.** When changes of personnel take place, SSO reduces both IT effort and opportunities for mistakes. Employees leaving the organization relinquish their login privileges.
|
||||
- **Improves identity protection.** With SSO, companies can strengthen identity security with [techniques](https://www.renovodata.com/blog/2015/05/20/protecting-email) such as two-factor authentication (2FA) and multifactor authentication (MFA).
|
||||
- **Increases speed where it is most needed.** In settings such as hospitals, defense industries, and emergency services, where large numbers of people and departments demand rapid and unfettered access to the same applications, SSO is especially helpful. In such cases, preventing errors and malware intrusion can be the difference between life and death.
|
||||
- **Relieves help desk workloads.** Fewer users calling for help with lost passwords saves money and improves security.
|
||||
- **Reduces security risks for your customers, vendors, and partner entities.** Connections between allied companies always present vulnerabilities, which SSO can reduce.
|
||||
- **Effective SSO solutions are available.** There is no reason for any organization to create its own system or to develop deep SSO expertise. RenovoData’s consultants understand available offerings and can help identify the [best choices for your company](https://www.renovodata.com/blog/2016/11/16/cheap-or-best-tool).
|
||||
|
||||
## SSO’s challenges
|
||||
|
||||
- **Extra-strong passwords must be enforced.** If an SSO account is cracked, others under the same authentication can also be endangered. -> combine with [Phishing-Resistant MFA](Phishing-Resistant%20MFA.md)
|
||||
- **When SSO is down, access to all connected sites is stopped.** This is a big reason to exercise great care in choosing an SSO system. It must be exceptionally reliable and plans should be in place for dealing with breakdowns.
|
||||
- **What’s more, when your identity provider goes down, your SSO does too.** The provider’s vulnerability to any kind of interruption becomes your vulnerability as well, and it is probably beyond your control. Once again, the choice of vendors is critical.
|
||||
- **If a hacker breaches your identity provider user account, all your linked systems could be open to attack.** This can be a classic single point of failure and should be headed off in the planning process. On the plus side, high-quality identity providers have top-notch security.
|
||||
- **SSO can take longer than expected to set up.** Each environment is different, so added steps in implementation can crop up. One example is the task linking the identity provider to the service provider.
|
||||
- **SSO is risky for multi-user computers.** What happens when one user is logged in and another needs to use the machine?
|
||||
- **Reduced sign-on (RSO) may be needed to accommodate different levels of access.** With RSO, additional authentication servers may be required.
|
||||
- **SSO using social networking services can create conflict.** This can be the case with workplaces that block social media sites and government connections where censorship is involved.
|
||||
- **Some SSO-linked sites may give their user data to third-party entities.** This is an area requiring careful attention.
|
||||
|
||||
|
||||
|
||||
77
Corpus/Information Security/Software due diligence.md
Normal file
77
Corpus/Information Security/Software due diligence.md
Normal file
|
|
@ -0,0 +1,77 @@
|
|||
# Software Due Diligence
|
||||
|
||||
Risk Dimensions:
|
||||
- Legal
|
||||
- Security
|
||||
- Quality
|
||||
|
||||
Aspects:
|
||||
- product / strategy: is the software competative? Is there a roadmap?
|
||||
- people/organization
|
||||
- process and tools used by the teams
|
||||
- architecture/design
|
||||
- code: quality, security, IP/licensing
|
||||
|
||||
## Consolidated code base
|
||||
|
||||
Code is a collection of pieces from different sources, and software is built by assembling from different sources:
|
||||
- commercial third party
|
||||
- legacy from a previoius product or acquisition
|
||||
- open source
|
||||
- code from outsourced production
|
||||
|
||||
Of code bases audited in 2020 , >70% was open source.
|
||||
|
||||
## Legal aspect
|
||||
|
||||
- Copyright law is applicable to software
|
||||
- Using code without proper licensing can lead to lawsuits, loss of IP, reputational damage, loss of money, time and resources
|
||||
|
||||
Of code bases audited in 2020, 65% contained licenses with "potential to cause conflict", 26% contained components that were not licensed or contained custom licenses.
|
||||
|
||||
## Security
|
||||
|
||||
Of code bases audited in 2020, 84% contained open source code with known vulnerabilities, and 60% contained high-risk vulnerabilities.
|
||||
The vast majority of these vulnerabilities where publicised and fixes where available, but not implemented.
|
||||
|
||||
## Quality
|
||||
Architectural quality influences developer productivity:
|
||||
- better design health: 20 KLOC per year per developer, 80% of time spent on features vs. 20% on repair -vs- 8 KLOC, 30% on features, 70% on repair
|
||||
|
||||
clear hierarchy, modular built, relatively few interdependencies
|
||||
|
||||
## Approaching the risks
|
||||
|
||||
Acquisition:
|
||||
- due dilligence, incl. disclosures and discussions with coders and architects, third party code audits
|
||||
- deal terms
|
||||
- plan for remediation
|
||||
|
||||
Divesting (Selling stuff off):
|
||||
- anticipate in acquisition
|
||||
- implement best practicises before selling off
|
||||
- pre-sales due dilligence (to prevent law suits by buyers)
|
||||
|
||||
|
||||
## Related ISO clauses and controls
|
||||
|
||||
A 6.1.4 Contact with special interest groups
|
||||
A 12.6.1 Management of technical vulnerabilities
|
||||
A 14.1.1 Information security requirements analysis and specification
|
||||
A 18.1.2 Intellectual property rights
|
||||
> fix vulnerabilities through patches and updates.
|
||||
|
||||
|
||||
Source: https://www.synopsys.com/blogs/software-security/software-risks-private-equity-buyouts/
|
||||
Phil Odence, of Black Duck / Synopsys
|
||||
|
||||
Additional resources offered on website:
|
||||
- [Best practices eBook](https://www.synopsys.com/software-integrity/resources/ebooks/software-audits-in-mergers-acquisitions.html?intcmp=sig-blog-pebuyout)
|
||||
- [Due diligence framework white paper](https://www.synopsys.com/software-integrity/resources/white-papers/evaluating-tech-mergers-acquisitions.html?intcmp=sig-blog-pebuyout)
|
||||
- [Software due diligence checklist](https://www.synopsys.com/software-integrity/resources/white-papers/software-due-diligence.html?intcmp=sig-blog-pebuyout)
|
||||
- [Open source data-based study](https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html?intcmp=sig-blog-pebuyout)
|
||||
|
||||
|
||||
|
||||
> Paul doet software DD
|
||||
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
# Sterke wachtwoorden in 2024
|
||||
|
||||
[Cracking passwords in 2024](Cracking%20passwords%20in%202024.md), HOW MUCH TIME DOES IT TAKE?
|
||||
|
||||
**Three Random Words**
|
||||
[NCSC Three Random Words](https://www.ncsc.gov.uk/collection/top-tips-for-staying-secure-online/three-random-words)
|
||||
[NCSC The logic behind three random words](https://www.ncsc.gov.uk/blog-post/the-logic-behind-three-random-words)
|
||||
https://expertinsights.com/insights/is-using-three-random-words-the-best-way-to-create-a-secure-password/
|
||||
|
||||
46
Corpus/Information Security/Surveys on Shadow IT usage.md
Normal file
46
Corpus/Information Security/Surveys on Shadow IT usage.md
Normal file
|
|
@ -0,0 +1,46 @@
|
|||
Asked Perplexity.com on 28 april 2025:
|
||||
> Are there sources to support the following claim: "The average employee uses 5-20 apps in their work that are not mandated by the IT dept, and are not behind SSO"
|
||||
|
||||
Yes, the search results provide relevant data points to support parts of this claim, though not the exact 5-20 range:
|
||||
|
||||
1. **App proliferation**:
|
||||
|
||||
- **Average app usage per employee** has risen significantly, with desk workers now using **11 apps** (up from 6 in 2019)[5](https://www.ciodive.com/news/gartner-digital-worker-tools-IT/649844/).
|
||||
|
||||
- **Shadow IT prevalence**: Over **one-third of enterprise apps** are classified as shadow IT (non-IT-sanctioned tools)[5](https://www.ciodive.com/news/gartner-digital-worker-tools-IT/649844/), suggesting employees frequently adopt apps without formal approval.
|
||||
|
||||
2. **SSO limitations**:
|
||||
While the search results don’t quantify how many apps lack SSO integration, **Okta’s ecosystem** (a major SSO provider) is mentioned as a common enterprise tool[6](https://www.reddit.com/r/privacy/comments/pzyy17/my_employer_is_forcing_everyone_to_download/). However, the rapid growth in app counts (e.g., **255 apps**for mid-market companies[4](https://chiefmartec.com/2023/04/how-big-is-your-tech-stack-really-heres-the-latest-data/)) implies many tools operate outside centralized authentication systems.
|
||||
|
||||
3. **Supporting inferences**:
|
||||
|
||||
- **App overload** is explicitly cited as a productivity drain, with employees switching between **13 apps 30 times daily**[3](https://www.ciodive.com/news/app-switching-enterprise-asana-report/594233/).
|
||||
|
||||
- **User frustration** with app sprawl (e.g., 26% of workers report inefficiency due to app overload[3](https://www.ciodive.com/news/app-switching-enterprise-asana-report/594233/)) indirectly supports the idea that employees adopt non-mandated tools to fill workflow gaps.
|
||||
|
||||
|
||||
**Conclusion**: The data confirms **rising app usage** and **shadow IT prevalence**, aligning with the claim’s premise. While the exact 5-20 range isn’t directly cited, the growth from 6 to 11 mandated apps[5](https://www.ciodive.com/news/gartner-digital-worker-tools-IT/649844/) and the high shadow IT rate[5](https://www.ciodive.com/news/gartner-digital-worker-tools-IT/649844/) suggest non-mandated app usage likely falls within or exceeds this range. The SSO aspect, though not quantified, is plausible given the scale of app sprawl[4](https://chiefmartec.com/2023/04/how-big-is-your-tech-stack-really-heres-the-latest-data/)[5](https://www.ciodive.com/news/gartner-digital-worker-tools-IT/649844/).
|
||||
|
||||
**Key sources**:
|
||||
|
||||
- **Gartner**: 11 apps per desk worker[5](https://www.ciodive.com/news/gartner-digital-worker-tools-IT/649844/).
|
||||
|
||||
- **Zylo**: 255+ apps in mid-market tech stacks[4](https://chiefmartec.com/2023/04/how-big-is-your-tech-stack-really-heres-the-latest-data/).
|
||||
|
||||
- **Asana**: 13-app daily switching[3](https://www.ciodive.com/news/app-switching-enterprise-asana-report/594233/).
|
||||
|
||||
|
||||
### Citations:
|
||||
|
||||
1. [https://firstup.io/blog/14-employee-mobile-usage-statistics-company-cant-ignore/](https://firstup.io/blog/14-employee-mobile-usage-statistics-company-cant-ignore/)
|
||||
2. [https://www.worktechacademy.com/the-very-real-problem-of-app-overload-in-the-workplace/](https://www.worktechacademy.com/the-very-real-problem-of-app-overload-in-the-workplace/)
|
||||
3. [https://www.ciodive.com/news/app-switching-enterprise-asana-report/594233/](https://www.ciodive.com/news/app-switching-enterprise-asana-report/594233/)
|
||||
4. [https://chiefmartec.com/2023/04/how-big-is-your-tech-stack-really-heres-the-latest-data/](https://chiefmartec.com/2023/04/how-big-is-your-tech-stack-really-heres-the-latest-data/)
|
||||
5. [https://www.ciodive.com/news/gartner-digital-worker-tools-IT/649844/](https://www.ciodive.com/news/gartner-digital-worker-tools-IT/649844/)
|
||||
6. [https://www.reddit.com/r/privacy/comments/pzyy17/my_employer_is_forcing_everyone_to_download/](https://www.reddit.com/r/privacy/comments/pzyy17/my_employer_is_forcing_everyone_to_download/)
|
||||
7. [https://thebusinessdive.com/productivity-apps-statistics](https://thebusinessdive.com/productivity-apps-statistics)
|
||||
8. [https://www.strongdm.com/blog/small-business-cyber-security-statistics](https://www.strongdm.com/blog/small-business-cyber-security-statistics)
|
||||
|
||||
---
|
||||
|
||||
Answer from Perplexity: [pplx.ai/share](pplx.ai/share)
|
||||
12
Corpus/Information Security/Threat Intelligence.md
Normal file
12
Corpus/Information Security/Threat Intelligence.md
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
|
||||
Primary ISO 27001 control: [5.7 Threat intelligence](../MoCs/ISO_27002_2022_5.7_MoC%20Threat%20intelligence.md)
|
||||
Applied in:
|
||||
- [Clause 6.1.2](../ISMS/Qualifying%20vs%20quantifying%20risks.md) Information security risk assessment
|
||||
|
||||
Relevant to:
|
||||
- asset management
|
||||
- vulnerability management
|
||||
|
||||
|
||||
[Introduction to Threat Intelligence and Risk Management](https://threatconnect.com/blog/threat-intelligence-risk-management-the-intelligence-process/)
|
||||
|
||||
21
Corpus/Information Security/Threat intelligence sources.md
Normal file
21
Corpus/Information Security/Threat intelligence sources.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
- OSTINT?
|
||||
|
||||
## Organizations
|
||||
[Citeum](https://www.citeum.org/en/) | @CiteumHQ
|
||||
|
||||
## Software and services
|
||||
- [VirusTotal](https://www.virustotal.com/gui/services-overview) | @virustotal
|
||||
- [OpenCTI](https://demo.opencti.io/dashboard?) | @LuatixHQ
|
||||
- [Malpedia](https://malpedia.caad.fkie.fraunhofer.de)
|
||||
- [Recorded Future](https://www.recordedfuture.com/platform/)
|
||||
|
||||
|
||||
## Blogs
|
||||
https://bartblaze.blogspot.com | @bartblaze
|
||||
https://blog.malwaremustdie.org | @malwaremustd1e
|
||||
|
||||
### Articles
|
||||
- [15 top open-source intelligence tools](https://www.csoonline.com/article/3445357/what-is-osint-top-open-source-intelligence-tools.html) | CSOonline
|
||||
|
||||
## Related
|
||||
- [Threat Intelligence](Threat%20Intelligence.md)
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 539 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 848 KiB |
39
Corpus/Information Security/Types of SSO.md
Normal file
39
Corpus/Information Security/Types of SSO.md
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
Related:
|
||||
- [a-5.17-Authentication-information](../Standards/ISO27x/OST/27002/EN/a-5.17-Authentication-information.md)
|
||||
- [Single Sign On (SSO)](Single%20Sign%20On%20(SSO).md)
|
||||
|
||||
## Types of Single Sign On (SSO) Authentication
|
||||
|
||||
### **Enterprise Single Sign On (E-SSO)**
|
||||
|
||||
Enterprise SSOs are implemented in **enterprise application integration** (EAI) environments. Therefore, with a single set of sign-in credentials, users are allowed to access all integrated applications within an enterprise, whether they exist **on premise** or **on the** [**cloud**](https://www.chakray.com/top-5-cloud-programming-languages/).
|
||||
|
||||
### **Web single sign-on (Web-SSO)**
|
||||
|
||||
This solution is ideal for applications that can be accessed through the web, such as websites or web services. Its goal is to verify a user’s identity on multiple applications at once without the person having to identify themselves repeatedly. It relies on an external or third-party authentication system.
|
||||
|
||||
A proxy SSO server running the authentication system handles access data and performs the confirmation of user identity. Then, it transfers the result to the computer running the web service or website that requested it. The SSO server and web service communicate via tokens in a way that is mostly invisible to the user. When the user is attempting to sign on to the website or web service, the authentication system generates a **global token** and sends the value to the user. Consequently, the user can enter the global token into the website, which in turn corroborates the value with the authentication system to ensure the user’s identity before granting them access. If the user is already signed in to the authentication system, the SSO server transmits their credentials along with a **local token** to the website, signifying a successful login.
|
||||
|
||||
### **Federated identity**
|
||||
|
||||
Federated Identity Management (FIM) or federated SSO broadens the scope of standard SSO technologies by uniting multiple organisations under one authentication system. While traditional SSO allows access to several systems within one enterprise, FIM allows access to several systems within **many different enterprises**. However, both methods authenticate the user through one identity.
|
||||
|
||||
### **Open ID**
|
||||
|
||||
A decentralised approach to SSO technologies, Open ID functions on the concept of a **relying party** (RP) and an **identity provider** (IDP). The RP is the website or service that wishes to authenticate the user, whilst the IDP performs the authorisation by recording the user’s chosen identity (which is portrayed through a URL identifier called an OpenID). The multipoint interactions between the user, RP, and IDP occur through a user-agent like a browser.
|
||||
|
||||
### **OAuth**
|
||||
|
||||
OAuth is not one particular technology, but rather a standard that is available for all to implement. It functions on the principle of **Access Tokens** and can help realise SSO. A client or user interacts with an **Authorisation Server** to receive an access token that would help them validate their identity with a **Resource Server**. Resource servers are in charge of delegating a resource to an authorised client.
|
||||
|
||||
### **Kerberos-based SSO**
|
||||
|
||||
This protocol allows users (the client) to utilise a **t****icket-granting ticket** or **Ticket to Get Tickets** (TGT) after the verification of their credentials. A TGT is swapped for a **service ticket** from the **ticket-granting service** (TGS). Service tickets permit the user access to protected services over the network (for example, a mail server).
|
||||
|
||||
### **Smart-card Authentication**
|
||||
|
||||
Instead of implementing software to authenticate the same set of credentials such as in conventional SSO processes, hardware devices like the smart-card can be used to achieve similar results.
|
||||
|
||||
### **Security Assertion Markup Language**
|
||||
|
||||
SAML is an open standard based on XML that can empower SSO implementations. It consists of two parts, namely the SAML identity provider (IdP) and the [SAML](https://www.chakray.com/wso2-identity-server-integration-spring-boot-security-saml/) service provider (SP). Initially, the principal or the user requests to connect to the SP. In turn, the SP asks the IdP for an **authentication assertion**. Once this is issued, the SP delivers the service needed by the user or decides to opt out of it.
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
See also [a-8.27-Secure-system-architecture-and-engineering-principles](../Standards/ISO27x/OST/27002/EN/a-8.27-Secure-system-architecture-and-engineering-principles.md)
|
||||
|
||||
https://www.unified-am.com/uam-online/
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue