cleaning up Sparks
This commit is contained in:
parent
b8d1d4e02f
commit
704e6dd07f
162 changed files with 393 additions and 1041 deletions
|
|
@ -1,14 +0,0 @@
|
|||
Zie ook [AVG Rechtmatigheid van de verwerking](../Standards/AVG/AVG%20Rechtmatigheid%20van%20de%20verwerking.md)
|
||||
|
||||
Noodzakelijk voor de uitvoering van een contract, voorbeeld: naam en adres zijn nodig om de bestelde spullen te kunnen leveren. Maar let op “absoluut noodzakelijk”.
|
||||
|
||||
Wettelijke verplichting, voorbeeld: bewaren kopie paspoort onder de Belastingwet.
|
||||
|
||||
Gerechtvaardigd belang: marketing wordt met name genoemd in de AVG. Maar let op balans tussen belang van de organisatie en impact op privacy van het individu
|
||||
(‘proportionaliteit’). Kijk altijd of er alternatieven zijn die minder impact hebben (‘subsidiariteit’).
|
||||
|
||||
Instemming (consent): niet de sterkste. Consent moet vrijelijk gegeven worden (dus geen machtsongelijkheid of beperking van dienstverlening) en voor een helder gecommuniceerd doel (en dan mag je de gegevens niet voor iets anders gebruiken). Kan bovendien worden ingetrokken.
|
||||
|
||||
Algemeen belang: bijv. verwerking van gegevens door de Belastingdienst. Niet van toepassing voor Balance.
|
||||
|
||||
Vitaal belang: bijv. verwerking van gegevens door ambulance diensten. Niet van toepassing voor Balance.
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
This next part is about the iso 27001 industry and its actors. Correct the following text so that the proper terms are used. Expand with other actors and their roles if necessary. This is the text:
|
||||
|
||||
- the standards organization develops the standard for a certain domain
|
||||
- the certification bureau checks if the standard is properly implemented within the organization and issues a certificate
|
||||
- Clients, regulatory bodies and other stakeholders of the organization demand the organization to be certified to proof adequate risk control within the domain
|
||||
- the organization implements the standard to get certified
|
||||
- the implementation consultant helps the organization to implement the standard
|
||||
- the internal auditor checks if the standard is properly implemented within the organization
|
||||
- The external auditor works for the certification bureau
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY/journey
|
||||
- type/explainer
|
||||
---
|
||||
|
||||
## Journey
|
||||
|
||||
We’ll start with analyzing the context of where the ISMS will operate. We’ll look at your organization, it’s structure and processes, important stakeholders and internal and external developments.
|
||||
|
||||
From that we’ll help you identify risks and opportunities, and define risk mitigating measures.
|
||||
|
||||
Together we will create policies, procedures and guidelines, and control implementation plans.
|
||||
|
||||
Gradually, we’ll work towards your first internal audit.
|
||||
|
||||
|
||||
++ increased understanding
|
||||
++ actually improving your security posture
|
||||
We know that we need to get your organization along, so we’ll start with risks and opportunities that matter to your stakeholders.
|
||||
|
||||
## Timeline
|
||||
we will adapt to your pace, but we will actively coach you, like your sports watch would.
|
||||
|
||||
## Interaction model
|
||||
|
||||
|
||||
Work iteratively, you can always come back later
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
# Interactie met de gebruiker
|
||||
|
||||
1. Gebruiker kiest een Lesmodule uit menu
|
||||
2. Content wordt getoond. Filmpje, tekst, afbeelding.
|
||||
3. De gebruiker krijgt een ‘taak’. Hij/zij heeft de keuze die nu uit te voeren, of te parkeren in de persoonlijke Takenlijst[^1] (onderdeel van GRC). De taak bevat een verwijzing naar de content, zodat die later weer opgepakt kan worden.
|
||||
4. De taak kan bestaan uit bijv:
|
||||
5. het uploaden van een document
|
||||
6. het invullen van een vragenlijst
|
||||
7. het vullen van een tabel (simpele spreadsheet met rij/kolom totalen bijv)
|
||||
8. Wat de gebruiker toevoegt wordt opgeslagen in de GRC-module
|
||||
9. De input van de gebruiker wordt gebruikt om nieuwe content te genereren, bijv. een beleidsdocument. Dit kan gebeuren met templates, logische regels, of LLM.
|
||||
10. Gegenereerde content wordt ter controle aangeboden aan de gebruiker. Die moet daar wijzigingen in aan kunnen brengen en uiteindelijk de productie akkoord verklaren.
|
||||
11. Na akkoord is er een wijziging in het ‘volwassenheidsniveau’ van het ISMS. Deze komt tot uitdrukking in het ‘Implementatie Dashboard’ (onderdeel van GRC). – kan dynamisch gegenereerd worden
|
||||
|
||||
- [ ] Uitwerken: Er zit onderlinge afhankelijkheid in: soms kun je stap 3 pas nemen als je stap 1 gedaan.
|
||||
- [ ] Volwassenheidsniveaus benoemen.
|
||||
|
||||
|
||||
[^1]: in een latere versie kunnen taken toegewezen worden aan een andere gebruiker.
|
||||
|
||||
|
||||
|
|
@ -1,417 +0,0 @@
|
|||
# The Merchant Vessel's Voyage: An ISMS Implementation Story
|
||||
|
||||
## **The Premise**
|
||||
|
||||
You're the captain of a merchant trading vessel, transporting valuable cargo across established trade routes. Your mission: deliver precious goods safely to distant ports while building a reputation for reliability and security that will sustain your trading company for years to come.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 1: Charting the Destination** (Setting the Goals)
|
||||
|
||||
Before leaving port, you gather your officers and backers around the navigation table. What defines success for this voyage?
|
||||
|
||||
- **The cargo's safe arrival**: Your hold contains valuable spices, silk, medical herbs, fine instruments - goods that merchants await
|
||||
- **The crew's safe return**: A ship without seasoned sailors is just expensive timber
|
||||
- **Maintaining your reputation**: In the trading world, trust is currency
|
||||
- **Regulatory compliance**: You must satisfy the Harbor Master's requirements and international maritime codes to operate legally
|
||||
- **Sustainable operations**: This isn't a single voyage - you're building a trading enterprise
|
||||
|
||||
You define your **scope**: Which routes will you sail? Which ports are included? What cargo types will you carry?
|
||||
|
||||
Your **security objectives** become clear: confidentiality (cargo manifests and trade secrets), integrity (goods arrive uncontaminated and authentic), availability (reliable delivery schedules).
|
||||
|
||||
You announce these goals to all stakeholders - the ship's owners, the crew, the merchants whose goods you carry.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 2: Reading the Waters** (External Issues)
|
||||
|
||||
Before you can plan your route, you must understand the world through which you'll sail:
|
||||
|
||||
- **Pirate activity**: Which waters are most dangerous? What are their tactics? Are they after cargo, ransom, or the ship itself?
|
||||
- **Weather patterns**: Monsoon seasons, hurricane zones, fog-prone straits
|
||||
- **Geopolitical tensions**: Which nations are at war? Where are trade embargoes? Which flags grant safe passage where?
|
||||
- **Port regulations**: Different harbors have different requirements - quarantine rules, inspection protocols, docking fees
|
||||
- **Competition**: Other trading companies, their routes, their security measures
|
||||
- **Technology changes**: New navigation instruments, faster ships, encrypted communication methods between trading houses
|
||||
- **Economic conditions**: Which goods are in demand? Where are prices best?
|
||||
|
||||
You gather intelligence from:
|
||||
|
||||
- Harbor masters' reports
|
||||
- Returning captains' debriefings
|
||||
- Maritime insurance underwriters
|
||||
- Coastal watchtowers' signals
|
||||
- Trading guild bulletins
|
||||
|
||||
This **external context** shapes every decision you'll make.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 3: Knowing Your Vessel** (Internal Issues, Assets, Strengths & Weaknesses)
|
||||
|
||||
Now you turn your attention inward. What are you working with?
|
||||
|
||||
### **Your Assets to Protect:**
|
||||
|
||||
- **The cargo** (your primary information assets): Spices in the forward hold, medicinal herbs requiring cool storage, sealed letters of credit, navigation charts showing profitable routes
|
||||
- **The ship itself**: Hull integrity, sail condition, water-tightness of hatches
|
||||
- **Your crew**: The navigator's expertise, the surgeon's knowledge, the carpenter's skills
|
||||
- **Your reputation and relationships**: Trust with merchants, favorable insurance rates, preferential port access
|
||||
- **Supporting systems**: The ship's boat (your backup), fresh water supplies, repair materials
|
||||
|
||||
### **Strengths:**
|
||||
|
||||
- Experienced first mate who's sailed these waters for 20 years
|
||||
- Recently reinforced hull
|
||||
- Disciplined crew with low turnover
|
||||
- Strong relationships with key ports
|
||||
|
||||
### **Weaknesses:**
|
||||
|
||||
- The navigator is brilliant but aging, with no clear successor trained
|
||||
- Your encryption methods for sensitive documents are known by former crew who now sail for competitors
|
||||
- The starboard cargo hold has a persistent leak
|
||||
- Only two crew members can operate the new navigational instruments
|
||||
- Your emergency procedures exist mostly in the captain's head
|
||||
|
||||
You conduct a thorough **inventory and assessment**: Who has access to what? Where are critical vulnerabilities? What depends on single points of failure?
|
||||
|
||||
---
|
||||
|
||||
## **Episode 4: Mapping the Dangers** (Risk Assessment)
|
||||
|
||||
With your destination set, external conditions understood, and internal capabilities assessed, you now systematically identify what could go wrong:
|
||||
|
||||
### **Risk Identification:**
|
||||
|
||||
- **Pirates in the Straits of Malacca**: High likelihood, severe impact (loss of cargo and possible crew)
|
||||
- **Storm season in the South China Sea**: Medium likelihood, catastrophic impact
|
||||
- **Crew illness/scurvy**: Medium likelihood, major impact on operations
|
||||
- **Cargo contamination from hold leak**: High likelihood, moderate impact
|
||||
- **Navigator incapacitation**: Low likelihood, severe impact
|
||||
- **Insider threat** (disgruntled crew revealing routes to competitors): Low likelihood, moderate impact
|
||||
- **Port authority seizure** due to paperwork errors: Medium likelihood, major impact
|
||||
- **Fire in the cargo hold**: Low likelihood, catastrophic impact
|
||||
|
||||
### **Risk Analysis:**
|
||||
|
||||
For each risk, you assess:
|
||||
|
||||
- **Likelihood**: Based on historical data (ships lost in these waters), current intelligence (pirate activity reports), ship conditions (that leaky hold)
|
||||
- **Impact**: What happens if this occurs? Loss of cargo value? Crew lives? Ship itself? Reputation damage?
|
||||
- **Existing controls**: What are you already doing? You have fire buckets, a daily inspection routine, experienced crew
|
||||
|
||||
### **Risk Evaluation:**
|
||||
|
||||
You plot these on a risk matrix with your officers. Which risks are acceptable for a merchant vessel? Your risk appetite is moderate - you're not running military secrets that require extreme measures, but you can't afford frequent losses either.
|
||||
|
||||
You prioritize: High likelihood + high impact risks must be addressed immediately. Low likelihood + low impact risks you'll accept.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 5: Plotting the Course** (Risk Treatment - Identifying Measures)
|
||||
|
||||
For each significant risk, you now decide your strategy:
|
||||
|
||||
### **Avoid:**
|
||||
|
||||
- **Don't sail during peak storm season**: Delay departure by three weeks
|
||||
- **Avoid notorious pirate waters entirely**: Take the longer, safer route
|
||||
|
||||
### **Reduce:**
|
||||
|
||||
- **Pirate encounters**: Sail in convoy with other merchants, hire additional armed crew, reinforce the captain's cabin (where valuables are stored), establish communication signals between convoy ships
|
||||
- **Cargo contamination**: Repair the hold leak, use sealed containers, implement daily inspection rounds
|
||||
- **Navigation failure**: Train two junior officers in advanced navigation, maintain duplicate charts stored separately, establish position verification protocols
|
||||
- **Fire**: Implement strict rules about open flames, station fire watch, conduct monthly fire drills, store water barrels strategically
|
||||
|
||||
### **Transfer:**
|
||||
|
||||
- **Cargo loss**: Purchase maritime insurance (though it's expensive and has limitations)
|
||||
- **Crew injury**: Contract with a maritime medical service in major ports
|
||||
|
||||
### **Accept:**
|
||||
|
||||
- **Minor cargo spoilage**: Some loss of spice potency is inevitable over long voyages; build this into pricing
|
||||
- **Wear on sails and rigging**: Routine deterioration; maintain replacement supplies
|
||||
|
||||
You create a **Statement of Applicability** - essentially a ship's security manifest that lists all maritime security controls, which ones you're implementing, which you're not, and why.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 6: The Ship's Standing Orders** (Policies and Procedures)
|
||||
|
||||
Now you formalize how your ship will operate. These aren't just the captain's whims - they're documented protocols that ensure consistency even when you're sleeping:
|
||||
|
||||
### **Access Control Policy** ("Who Goes Where"):
|
||||
|
||||
- **Cargo holds**: Only the quartermaster and captain have keys; entry logged in the ship's book
|
||||
- **Captain's cabin** (sensitive documents): Captain only; first mate has sealed emergency key
|
||||
- **Navigation room**: Navigator and trained officers only
|
||||
- **Critical supplies** (medical stores, emergency rations): Surgeon and quartermaster access; usage logged
|
||||
|
||||
### **Watch Standing Procedures** (Continuous Monitoring):
|
||||
|
||||
- Four-hour watches with clear handoff protocols
|
||||
- What to look for: other ships, weather changes, coastal landmarks
|
||||
- How to sound alarms for different threats
|
||||
- Night signal procedures
|
||||
|
||||
### **Cargo Handling Protocols**:
|
||||
|
||||
- Inspection upon loading (verify against manifest)
|
||||
- Daily hold inspections (check for water, pests, shifting)
|
||||
- Verification before unloading (ensure seals intact)
|
||||
- Chain of custody documentation
|
||||
|
||||
### **Emergency Response Procedures**:
|
||||
|
||||
- **Fire**: Specific roles assigned, equipment locations, communication signals
|
||||
- **Pirate attack**: Battle stations, valuable cargo disposal procedures (if necessary), surrender signals (if absolutely necessary)
|
||||
- **Man overboard**: Stop signals, rescue boat launch, recovery procedures
|
||||
- **Taking on water**: Damage assessment, pumping priorities, emergency port protocols
|
||||
|
||||
### **Navigation Protocols**:
|
||||
|
||||
- Position verification twice daily
|
||||
- Cross-checking between celestial navigation and known landmarks
|
||||
- Backup navigation methods
|
||||
- How to handle disagreement between navigator and captain
|
||||
|
||||
### **Communication Security**:
|
||||
|
||||
- How to encode sensitive messages
|
||||
- Which information can be shared in port
|
||||
- Procedures when crew members depart
|
||||
- How to verify identity of ships claiming to be friendly
|
||||
|
||||
### **Maintenance Standards**:
|
||||
|
||||
- Daily inspections (rigging, hull, pumps)
|
||||
- Weekly maintenance (sail repairs, deck treatment)
|
||||
- Monthly drills (fire, abandon ship, battle)
|
||||
- Equipment testing schedules
|
||||
|
||||
### **Crew Management**:
|
||||
|
||||
- Hiring procedures (background checks with previous captains)
|
||||
- Security training for new crew
|
||||
- Disciplinary procedures
|
||||
- Departure protocols (what they can take, what they must return)
|
||||
|
||||
Each policy answers: **What** must be done, **Why** it matters, **Who** is responsible, **When** and **How** it's done, and **What to do if** something goes wrong.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 7: Casting Off** (Implementation)
|
||||
|
||||
The planning is complete. Now comes the actual voyage - putting your measures into action:
|
||||
|
||||
### **Pre-Departure:**
|
||||
|
||||
- Reinforce the cargo hold (that leak must be fixed)
|
||||
- Install the new secure storage in the captain's cabin
|
||||
- Conduct security training for the crew on the new protocols
|
||||
- Brief all hands on the voyage plan and their roles
|
||||
- Load cargo with new inspection procedures
|
||||
- Verify all equipment is aboard and functional
|
||||
|
||||
### **Underway:**
|
||||
|
||||
- The watch rotation begins according to standing orders
|
||||
- Daily hold inspections reveal the repairs are holding
|
||||
- You drill the crew on emergency procedures weekly
|
||||
- Navigation protocols are followed - the junior officers are learning
|
||||
- Access logs are maintained for all sensitive areas
|
||||
- Incident reports are filed when protocols aren't followed (the cook accessed medical supplies without the surgeon present - why? turns out for a legitimate minor burn, but the procedure needs clarification)
|
||||
|
||||
### **Continuous Adjustment:**
|
||||
|
||||
- Three days out, you receive signals that pirates have been sighted ahead; you adjust course and increase watches
|
||||
- A storm forces you to secure cargo differently than planned - you document the new method
|
||||
- One crew member proves unreliable at watch; they're reassigned and additional training provided to their replacement
|
||||
|
||||
Implementation means **living** the procedures daily, not just having them written down.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 8: Keeping the Ship Supplied** (Resources and Competence)
|
||||
|
||||
A ship doesn't sail on good intentions. Throughout the voyage, you must ensure:
|
||||
|
||||
### **Financial Resources:**
|
||||
|
||||
- Budget for unexpected port fees
|
||||
- Reserve funds for emergency repairs
|
||||
- Insurance premiums
|
||||
- Crew wages (security depends on crew loyalty)
|
||||
|
||||
### **Human Resources:**
|
||||
|
||||
- Adequate crew size for watch rotations
|
||||
- Specialized skills: navigator, surgeon, carpenter, sailmaker
|
||||
- Training time - you can't expect new crew to know complex procedures instantly
|
||||
- Succession planning - you're actively training that junior navigator
|
||||
|
||||
### **Physical Resources:**
|
||||
|
||||
- Spare rigging and sails
|
||||
- Repair materials (timber, pitch, nails)
|
||||
- Security equipment (weapons, locks, sealing wax)
|
||||
- Safety equipment (fire buckets, rescue lines, ship's boat)
|
||||
- Extra supplies beyond minimum (because delays happen)
|
||||
|
||||
### **Knowledge Resources:**
|
||||
|
||||
- Navigation charts (and backups)
|
||||
- Ship's library of maritime procedures
|
||||
- Current intelligence from ports
|
||||
- Documentation of your own procedures and lessons learned
|
||||
|
||||
### **Time:**
|
||||
|
||||
- Adequate voyage timeline (rushing leads to cutting security corners)
|
||||
- Maintenance windows (you must occasionally heave-to for repairs)
|
||||
- Training time during long passages
|
||||
- Rest for crew (exhausted sailors make mistakes)
|
||||
|
||||
You establish **competence requirements**: What must each role know? The first mate must be able to take command. The quartermaster must know cargo handling. All crew must know basic emergency procedures.
|
||||
|
||||
You track **awareness**: Does everyone understand why these security measures matter? They'll follow procedures better if they understand they're protecting their own interests (cargo arrives = they get paid; ship is safe = they live).
|
||||
|
||||
---
|
||||
|
||||
## **Episode 9: The Ship's Log** (Documentation)
|
||||
|
||||
From the moment you leave port, you maintain meticulous records. In the maritime world, if it's not in the log, it didn't happen:
|
||||
|
||||
### **The Master Log:**
|
||||
|
||||
- Daily entries: position, weather, course, significant events
|
||||
- All decisions and why they were made
|
||||
- All incidents and how they were handled
|
||||
- Changes to procedures
|
||||
|
||||
### **Specialized Logs:**
|
||||
|
||||
- **Cargo manifest**: What's aboard, where it's stored, condition checks
|
||||
- **Watch log**: Who was on duty when, what they observed
|
||||
- **Maintenance log**: Repairs, inspections, equipment status
|
||||
- **Incident reports**: Anything unusual, even if minor
|
||||
- **Training records**: Who's been trained on what procedures
|
||||
- **Access logs**: Who entered sensitive areas when
|
||||
|
||||
### **Charts and Plans:**
|
||||
|
||||
- Navigation charts with your actual route (vs. planned)
|
||||
- Cargo stowage plans
|
||||
- Emergency evacuation plans
|
||||
- Crew roster with roles and competencies
|
||||
|
||||
### **Why This Matters:**
|
||||
|
||||
- **Learning**: What worked? What didn't? Your next voyage will be safer
|
||||
- **Accountability**: If something goes wrong, you can trace what happened
|
||||
- **Compliance**: Port authorities and insurers require documentation
|
||||
- **Continuity**: If you're incapacitated, your first mate needs to know everything
|
||||
- **Evidence**: If crew or cargo disputes arise, you have records
|
||||
- **Improvement**: You can't improve what you don't measure
|
||||
|
||||
The ship's log is your organizational memory - it outlasts any single voyage.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 10: Harbor Master's Inspection** (Audit and Review)
|
||||
|
||||
### **Internal Reviews (Ongoing):**
|
||||
|
||||
Throughout the voyage, you conduct regular self-assessments:
|
||||
|
||||
- **Daily bridge briefings**: What happened in the last 24 hours? What's ahead? Are procedures being followed?
|
||||
- **Weekly officer meetings**: Deeper review of security effectiveness, crew morale, equipment status
|
||||
- **Incident reviews**: Whenever something goes wrong (or almost goes wrong), you gather the relevant crew and analyze: What happened? Why? What will we do differently?
|
||||
- **Monthly drills**: Testing emergency procedures and evaluating performance
|
||||
|
||||
### **Port Audits (External):**
|
||||
|
||||
When you reach port, several inspections occur:
|
||||
|
||||
**Harbor Master's Security Inspection:**
|
||||
|
||||
- Are your cargo manifests accurate?
|
||||
- Are dangerous goods properly stored and documented?
|
||||
- Does your crew have proper credentials?
|
||||
- Are your safety and security measures adequate?
|
||||
- Do you meet international maritime security codes?
|
||||
|
||||
The Harbor Master is like your ISO 27001 auditor - they verify you're following established maritime security standards.
|
||||
|
||||
**Cargo Survey:**
|
||||
|
||||
- Merchants' representatives inspect their goods
|
||||
- Verifying seals are intact
|
||||
- Checking condition matches manifest
|
||||
- This proves your controls worked (or reveals where they didn't)
|
||||
|
||||
**Insurance Assessment:**
|
||||
|
||||
- Your insurer may inspect to verify you followed security protocols
|
||||
- This affects future premiums and coverage
|
||||
|
||||
### **Post-Voyage Review (Management Review):**
|
||||
|
||||
After reaching your destination, you conduct a comprehensive review with your officers and the ship's owners:
|
||||
|
||||
**What Worked:**
|
||||
|
||||
- The convoy strategy - no pirate encounters despite sailing through risky waters
|
||||
- Junior navigator training - you now have backup capability
|
||||
- Daily hold inspections caught problems early
|
||||
|
||||
**What Didn't:**
|
||||
|
||||
- The new watch rotation led to gaps in dawn coverage twice
|
||||
- Access logging was inconsistently followed (people got busy)
|
||||
- Fire drill times were too slow - crew needs more practice
|
||||
|
||||
**Metrics Analysis:**
|
||||
|
||||
- Incidents logged: 12 (down from 18 last voyage)
|
||||
- Security procedure compliance: 94% (target was 95%)
|
||||
- Cargo loss: 0.5% (within acceptable range)
|
||||
- On-time arrival: 2 days early (good)
|
||||
- Crew injuries: 1 minor (excellent)
|
||||
|
||||
**Risk Reassessment:**
|
||||
|
||||
- Are the risks you identified still accurate?
|
||||
- Did new risks emerge? (You encountered fog banks that weren't in your initial assessment)
|
||||
- Have external conditions changed? (Political tensions have eased in certain waters)
|
||||
- Are your controls still appropriate?
|
||||
|
||||
**Decisions for Next Voyage:**
|
||||
|
||||
- Adjust watch rotation based on lessons learned
|
||||
- Implement new access control procedure to improve compliance
|
||||
- Conduct more frequent fire drills
|
||||
- Update risk assessment to include fog navigation
|
||||
- Invest in better equipment for certain controls
|
||||
|
||||
### **Continuous Improvement:**
|
||||
|
||||
The voyage doesn't truly end when you reach port. You've learned from this journey, updated your procedures, and you're already preparing for the next departure. The ship's standing orders are now revised - Version 2.0 - incorporating everything you've learned.
|
||||
|
||||
You share lessons with other captains in your trading company. Best practices spread through the fleet.
|
||||
|
||||
**ISO Certification Parallel:** This comprehensive review - with documented evidence from your logs, demonstrated effectiveness of controls, and commitment to continuous improvement - is what convinces the Harbor Master (auditor) to certify your ship as meeting international security standards. The certificate isn't the end goal; it's recognition that you operate a secure, reliable, continuously improving operation.
|
||||
|
||||
---
|
||||
|
||||
## **The Journey Continues**
|
||||
|
||||
Unlike a fortress that, once built, stands static, your merchant vessel is always in motion. The sea changes. Threats evolve. Crews turn over. New ports open. Technology advances.
|
||||
|
||||
Your ISMS is the same - not a project with an end, but an operational discipline. The standing orders (policies) guide daily operations. The log (documentation) captures your organizational memory. The crew (your people) execute with competence and awareness. The inspections (audits) verify effectiveness. And the voyage (your business) continues, safer and more resilient because of the system you've built.
|
||||
|
||||
**The ISO 27001 certificate is your Letter of Marque** - official recognition that your vessel meets the standards required to trade safely in international waters, protecting the valuable cargo (information) entrusted to your care.
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
# iso27DYI: How this works
|
||||
|
||||
|
||||
## Structure
|
||||
|
||||
We've divided the ISMS implementation into a number of Episodes.
|
||||
|
||||
|
||||
- setting the goals
|
||||
- what's the lay of the land (relevant external issues)
|
||||
- how's our equipe, our assets that need to be protected (internal issues, strengths and weaknesses)
|
||||
- knowing the risks
|
||||
- identifying measures to mitigate the risks
|
||||
- creating the recipes (policies) for resilience in different areas / domains
|
||||
- implementing the risk mitigating measures
|
||||
- ensuring resources to implement and maintain everything
|
||||
- all the while documenting stuff as we go allong
|
||||
- audit and review how we're doing.
|
||||
|
||||
For every element of the ISO 27001 you need to be able to tell the auditor:
|
||||
|
||||
- what your method is for implementing the requirement
|
||||
- how and when you monitor the results of your implementation
|
||||
- how and when you evaluate the results and identify possible improvements
|
||||
- when you are planning to implement these improvements
|
||||
- who's involved and who's responsible for each of these steps.
|
||||
|
||||
In ISO27DIY we deal with this by providing Policy Cards for every Clause and Control of the ISO 27001.
|
||||
|
||||
There's always our Controls Library with everything in Plain English, support by our consultants. When the time is ready, you can plan a preliminiary audit.
|
||||
|
||||
## Principles
|
||||
- work with what you got - keep doing what you do but make it 'compliant'
|
||||
- work iteratively - you can always come back later
|
||||
|
||||
# Metadata
|
||||
- which 'slots' this scene fills
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
# Access Control
|
||||
|
||||
While [authorization](../Standards/ISO27x/Authorization.md) is primarily concerned with establishing the policies and rules that dictate access (i.e. *what* a person or system is allowed to do), **access control** is the _system_ or _process_ that enforces those defined permissions.
|
||||
|
||||
See:
|
||||
- [Gedachten over rechtenstructuren](Gedachten%20over%20rechtenstructuren.md)
|
||||
- [Authorization vs Access Control](Authorization%20vs%20Access%20Control.md)
|
||||
- [Access Control Models](Access%20Control%20Models.md)
|
||||
- [ISO 27001 A 9 Access control](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%209%20Access%20control.md)
|
||||
- [a-5.15-Access-control](../Standards/ISO27x/OST/27002/EN/a-5.15-Access-control.md)
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
- dev
|
||||
- appsec
|
||||
- "#vibecoding"
|
||||
- SupaBase
|
||||
---
|
||||
# Application Security for Vibe Coding
|
||||
|
||||
**Suggested approaches**
|
||||
|
||||
- post your code into GPT or Claude and ask it to analyse the code for security vulnerabilities
|
||||
- Open a program on Yeswehack and let people test your security for you
|
||||
- use snyk.io or sonarcloud.io or sonarqube to continuously scan for security vulnerabilities
|
||||
- GitHub already scans for exposed keys and libraries that need to updated. Not on private repos though I believe (unless you have a paid plan).
|
||||
- Look up your tech stack and see if any CVEs are on it. If so look at what migrations can be taken.
|
||||
- Have Cursor create a security plan and then run through it.
|
||||
- Big thing to look for is where your API keys are located, set up a secure system for that. Maybe use Amazon Secrets Manager of HashiCorp Vault. Or see below for Supabase edge functions.
|
||||
|
||||
Tips from [u/MoCoAICompany](https://www.reddit.com/user/MoCoAICompany/):
|
||||
1. Make sure no one has access to your API keys or secrets (**I'm using Supabase edge functions for this,** but there's a lot of options).
|
||||
2. Any user data should be protected and more important user data (think credit card info, social security numbers etc) should be encrypted. The easiest way to handle this is to not have user data or to minimize it as much as possible for the mvp. A few apps I'm building use anonymous users only (this lets me use Supabase edge functions to protect my keys but they don't need to log in)
|
||||
3. Keeping things simple if possible is a great way to minimize security risk. Or like using Stripe for payment platforms and piggy backing on their security.
|
||||
4. Have Al run a security audit on this stuff or get a good security audit prompt.
|
||||
5. Lastly, any API key you put out into the wild you should put a max spend limit on it - like $10, $50 whatever you want so that just in case the keys are stolen you have max losses based on that and also get an email saying your at your limit and then can change keys (and fix security)
|
||||
https://mocoai.com/ai-consulting/
|
||||
|
||||
[u/infinitelogins](https://www.reddit.com/user/infinitelogins/) mentioned working on a supabase misconfiguration scanner
|
||||
|
||||
## Checklists
|
||||
**Aikido** [Vibe Check: The vibe coder’s security checklist](https://www.aikido.dev/blog/vibe-check-the-vibe-coders-security-checklist)
|
||||
Application Security Checklist [on GitHub](https://gist.github.com/al3rez/c029a2cd879f2bf0b0be6806d8fe9530)
|
||||
Full Stack Security Guide [on GitHub](https://github.com/cpjet64/vibecoding/blob/main/full-stack-security-guide.md)
|
||||
[Top 10 Tips](https://www.reddit.com/r/vibecoding/comments/1kp2ncz/security_tips_for_secure_vibe_coding/) from u/PhraseProfessional54
|
||||
[Security Audit Prompt](https://raw.githubusercontent.com/scragz/kornelius/refs/heads/main/prompts/audit/security.prompt) from u/scragz
|
||||
|
||||
|
||||
**Aikido** security masterclasses on [YouTube](https://www.youtube.com/@aikidosecurity)
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Zie ook: [DPOaaS offer Glownexus](../Literature%20notes/DPOaaS%20offer%20Glownexus.md)
|
||||
|
||||
|
|
@ -1 +0,0 @@
|
|||
... for the implementation.
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
From a [LinkedIn post](https://www.linkedin.com/feed/update/urn:li:activity:7272490322453028864/) by [Mads Bundgaard Nielsen](https://www.linkedin.com/in/mbundgaard/)
|
||||
|
||||
1. Perform a Stakeholder analysis, mapping them on two dimensions:
|
||||
a) Strategic importance: Stakeholder can influence path to strategic objectives
|
||||
b) Incident sensitivity: Negative reaction is influenced by your incidents.
|
||||
- Note the important and sensitive stakeholders.
|
||||
|
||||
2. Identify events that can impact your reputation with important stakeholders: breach, service disruption, delays, budget exceedance, ransomware, fraud, etc.
|
||||
- Bear in mind: Not all event types evoke the same reaction from the same stakeholder.
|
||||
|
||||
3. List the possible impact from negative reactions (see notes for examples); Ask yourself “what would I see, if my reputation with `stakeholder` was diminished?”. 1-3 tangible metrics will probably immediately pop up, and if not, its probably not an important stakeholder after all.
|
||||
|
||||
4. Identify levers: What actions (preemptive or reactive) are you able to take or plan? Probably only a handful. The good news is that your levers almost certainly mitigate >90% of the negative reputation outcomes.
|
||||
|
||||
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
Bron: mail Remco Landegge, Security Expert Radboud UMC, 2 december 2024
|
||||
|
||||
*Zie ook: [Risk ownership](Risk%20ownership.md)*
|
||||
|
||||
Team Architectuur, Security, Compliance and Informatie analyse
|
||||
Stafdienst Informatie Management
|
||||
|
||||
Elke [vrijdag](canary:event?ts=755175605.00) in de even weken roostervrij.
|
||||
Dit is het model wat wij gebruiken voor eigenaarschap binnen onze organisatie. Als je er iets van gebruikt dan alle verwijzingen naar Radboudumc verwijderen a.u.b.
|
||||
|
||||
Heb ook nog even naar jouw canvas aanpak gekeken, dit is grotendeels hetzelfde als wij nu hanteren binnen onze eigen risico methodiek (die ook al bekend is op de afdelingen). Het denken in risico’s is voor ziekenhuizen geen onbekend terrein 😉
|
||||
|
||||
**4.2 Wie is de eigenaar van een bedrijfsmiddel/bedrijfsproces?**
|
||||
|
||||
Het komt voor dat eigenaarschap van een bedrijfsmiddel en/of een bedrijfsproces onduidelijk is. In die gevallen kan het eigenaarschap van een bedrijfsproces/bedrijfsmiddel via het onderstaande schema worden bepaald.
|
||||
|
||||
|
||||
|
||||
Bovenstaande figuur beschrijft vier situaties:
|
||||
|
||||
**_Situatie 1: Bedrijfsmiddel/bedrijfsproces_** **_binnen één organisatieonderdeel. (B1)_**
|
||||
|
||||
Wanneer een bedrijfsmiddel/bedrijfsproces binnen slechts één organisatieonderdeel (centrum, afdeling, ondersteunende dienst, instituut) wordt gebruikt, dan is het hoofd/directie van het organisatieonderdeel de eigenaar **(E1)**. In deze situatie gaat het voor de instituten alleen over de bedrijfsmiddelen en bedrijfsprocessen die zij binnen hun eigen organisatieonderdeel nodig hebben, het gaat [hier](canary:event?ts=754743605.00) niet om de bedrijfsmiddelen/bedrijfsprocessen die nodig zijn binnen de complete kerntaak.
|
||||
|
||||
|
||||
**_Situatie 2: Bedrijfsmiddel/bedrijfsproces_** **_binnen meerdere afdelingen of een afdeling en een centrum. (B2)_**
|
||||
|
||||
Wanneer een bedrijfsmiddel of bedrijfsproces door verschillende afdelingen of een afdeling en een centrum wordt gebruikt, dan is de directie van de kerntaak waarin het bedrijfsmiddel/bedrijfsproces wordt gebruikt de eigenaar **(E2)**. Om te borgen dat alle belanghebbenden binnen de afdeling en/of centrum zijn betrokken bij het nemen van besluiten over functionaliteiten, beveiliging en service niveaus stelt de eigenaar zich onafhankelijk en facilitair op.
|
||||
|
||||
**_Situatie 3: Bedrijfsmiddel/bedrijfsproces_** **_binnen meerdere instituten. (B3)_**
|
||||
|
||||
Wanneer een bedrijfsmiddel of bedrijfsproces binnen de verschillende kerntaken wordt gebruikt, bepalen de directies van de betrokken instituten wie de eigenaar is **(E3)**. Om te borgen dat alle belanghebbenden binnen de instituten zijn betrokken bij het nemen van besluiten over functionaliteiten, beveiliging en service niveaus stelt de eigenaar zich onafhankelijk en facilitair op.
|
||||
|
||||
**_Situatie 4: Bedrijfsmiddel/bedrijfsproces_** **_beslaan (zo goed als) alle Radboudumc onderdelen. (B4)_**
|
||||
|
||||
Wanneer een bedrijfsmiddel of bedrijfsproces binnen het gehele Radboudumc bestaat zonder dat eigenaarschap genomen wordt, dient primair bepaald te worden of het bedrijfsproces of bedrijfsmiddel wel nodig is. De drie instituutsdirecties en de directeuren van de ondersteunende diensten bepalen gezamenlijk of het bedrijfsmiddel/proces wel nodig is. Indien dat het geval is, wijst men in samenspraak een eigenaar aan **(E4)**. Indien men [hier](canary:event?ts=754743605.00) niet in samenspraak uitkomt, wijst de RvB een eigenaar aan **(E4)**.
|
||||
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
|
||||
See also:
|
||||
- [Asset ownership policy of RUMC](Asset%20ownership%20policy%20of%20RUMC.md)
|
||||
- [Risk ownership](Risk%20ownership.md)
|
||||
- [Control ownership](Control%20ownership.md)
|
||||
|
||||
|
||||
**ISO 27001 explicit mention of asset ownership:**
|
||||
- A.8.1.2 Asset should have an owner
|
||||
- A.9.2.5 Asset owners must periodically evaluate access rights
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
* The relationship can be summarized as: A threat exploits an exposed vulnerability to damage an asset, which results in a risk to the organization.
|
||||
* A risk can be seen as a theoretical threat scenario. If a risk "materializes," an anticipated or potential threat has actually taken place, exploiting a vulnerability and affecting an asset, which results in actual harm or loss.
|
||||
* The relationship between assets, vulnerabilities, and threats is often called the Operations Security Triple.
|
||||
|
||||
[Assets](Assets.md)
|
||||
[Vulnerability 1](Vulnerability%201.md)
|
||||
[Threat](../📚️%20Literature%20notes/Threat.md)
|
||||
[Risks](Risks.md)
|
||||
|
||||
See also: [](../Attachments/Certified%20Ethical%20Hacker%20Exam%20Guide%202021.pdf)
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
See also:
|
||||
- slide decks made for workshop sessions. Those for Kaliber, Nedap and Networking4AL are the most recent.
|
||||
|
||||
An "information asset" refers to a valuable and meaningful piece of information that an organization or individual possesses, uses, or relies upon to achieve their objectives. Information assets can take various forms, including data, documents, intellectual property, proprietary knowledge, and more. They are considered valuable resources that contribute to decision-making, operational efficiency, innovation, and overall business success. Here are a few definitions of "information asset":
|
||||
|
||||
1. **ISO/IEC 27000:2018** (Information Security Management Systems - Overview and Vocabulary):
|
||||
"Information asset: Anything that has value to an organization (e.g. printed documents, electronic documents, intellectual property, personal data, knowledge of processes, physical items)."
|
||||
|
||||
2. **NIST Special Publication 800-53** (Security and Privacy Controls for Federal Information Systems and Organizations):
|
||||
"Information asset: Information and the information systems that process, store, and transmit that information."
|
||||
|
||||
3. **The Data Management Body of Knowledge (DAMA-DMBOK)**:
|
||||
"Information asset: A resource of value that an organization uses to understand, operate, and innovate."
|
||||
|
||||
4. **The University of Texas at Austin - Information Security Office**:
|
||||
"Information asset: Any knowledge that has potential value to an organization or an individual, including but not limited to business data, personal data, research data, proprietary data, and internal and external communications."
|
||||
|
||||
5. **Gartner IT Glossary**:
|
||||
"Information asset: A collection of information that is defined and managed as a standalone entity and is considered of value."
|
||||
|
||||
In essence, an information asset is a piece of information that holds value and significance, whether for its role in decision-making, competitive advantage, regulatory compliance, research, or other organizational functions. Proper management, protection, and utilization of information assets are crucial to an organization's success and security.
|
||||
|
||||
## Related:
|
||||
|
||||
- [Assets, Vulnerabilities, Threats, Risks](Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
|
||||
- [Asset management in ISO 27001](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208%20Asset%20management.md)
|
||||
- [Asset lifecycle in the Defensive Security Handbook](../📚️%20Literature%20notes/Asset%20lifecycle.md)
|
||||
- [Asset ownership](Asset%20ownership.md)
|
||||
- [How to develop an Asset Inventory](How%20to%20develop%20an%20Asset%20Inventory.md)
|
||||
- [Asset management in the Defensive Security Handbook](../Literature%20notes/Def_Sec_Handbook_Chapter_2.md)
|
||||
|
||||
|
|
@ -1,54 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- iso27DIY
|
||||
- design
|
||||
- audit
|
||||
---
|
||||
For a browser-based application with dynamic search results on a collection of 300 text files (around 500 words each), where speed and simplicity are key, a client-side only approach is ideal. This means no server-side processing for the search itself, making it incredibly fast and simple to deploy.
|
||||
Here's the suggested tech stack:
|
||||
Frontend (Browser)
|
||||
* HTML: For the structure of your page (search input, results area, etc.).
|
||||
* CSS: For styling and making it look good.
|
||||
* JavaScript: This is where the magic happens for the search functionality.
|
||||
* Vanilla JavaScript: For the core logic. You can easily fetch your text files and implement the search.
|
||||
* A Lightweight JavaScript Search Library: This is crucial for speed and efficiency when dealing with full-text search. Directly looping through all files and doing indexOf or includes will be slow for dynamic updates, especially as the number of files grows or if you want more advanced features like fuzzy matching or relevancy scoring.
|
||||
Recommended Libraries (choose one):
|
||||
* Lunr.js: A popular and well-regarded client-side full-text search engine. It builds an in-memory index of your content, allowing for very fast searches. It supports stemming, stop words, and basic relevancy. It's relatively small and easy to use.
|
||||
* Elasticlunr.js: A fork of Lunr.js that offers more flexibility and features like query-time boosting. If you find Lunr.js a bit too basic, Elasticlunr.js is a good alternative without much added complexity.
|
||||
* Fuse.js: Excellent for fuzzy searching and highly customizable. If your users might have typos or partial matches, Fuse.js is a great choice.
|
||||
* FlexSearch: Claims to be very fast and memory-efficient. Worth exploring if you hit performance bottlenecks with Lunr/Elasticlunr.
|
||||
How it Works (Simplified Flow)
|
||||
* Load Files: When the application loads, you'll use JavaScript's fetch API to retrieve all 300 text files.
|
||||
* Optimization: Instead of loading 300 separate files, consider combining them into one large JSON file where each entry contains the file's content and its associated topic/metadata. This reduces network requests.
|
||||
* Example JSON structure:
|
||||
[
|
||||
{
|
||||
"id": "file1",
|
||||
"title": "Topic of File 1",
|
||||
"content": "This is the content of file 1..."
|
||||
},
|
||||
{
|
||||
"id": "file2",
|
||||
"title": "Topic of File 2",
|
||||
"content": "This is the content of file 2..."
|
||||
}
|
||||
// ... more files
|
||||
]
|
||||
|
||||
* Index Data: Once the data is loaded (from the single JSON file), you'll use your chosen JavaScript search library (e.g., Lunr.js) to build an in-memory search index from the content of these files. This indexing happens once when the page loads.
|
||||
* User Input: As the user types in the search input field, listen for input events (or keyup with a debounce for performance).
|
||||
* Perform Search: Use the search library to query the index with the user's current input. The library will quickly return matching file IDs (and potentially relevancy scores).
|
||||
* Display Results: Based on the matching file IDs, dynamically update the HTML to show the titles/snippets of the identified files. As the user types more, the search results will instantly refine.
|
||||
Advantages of this Stack
|
||||
* Simplicity: No backend server is needed for the search itself. All processing happens in the user's browser. This means easier deployment (just static files) and fewer moving parts.
|
||||
* Speed: Once the initial indexing is done (which should be quick for 300 files of 500 words each), subsequent searches are near-instantaneous as they operate on an in-memory index.
|
||||
* Cost-Effective: You only need static file hosting (e.g., GitHub Pages, Netlify, Vercel, or even a simple web server like Nginx or Apache).
|
||||
* Offline Capability: If you use a Service Worker, you could potentially cache the files and the search index, allowing users to search even without an internet connection after the first visit.
|
||||
Potential Considerations (and why they might not be an issue here)
|
||||
* Initial Load Time: Loading 300 text files (even in one JSON) will take some time. However, for 300 files * 500 words = 150,000 words total, this is still relatively small (probably a few hundred KB to a MB or two). Modern browsers can handle this very efficiently. You can show a loading spinner during this phase.
|
||||
* Memory Usage: Storing the index in memory will consume some RAM in the user's browser. Again, for this dataset size, it should be perfectly fine for most modern devices.
|
||||
* Updates: If your text files change frequently, you'd need to re-deploy the updated JSON file. If real-time updates were critical, a server-side solution with a database and search engine (like Elasticsearch or Solr) would be necessary, but that goes against "as simple as possible."
|
||||
* Scalability: This client-side approach scales well in terms of concurrent users (as there's no server load for search), but not in terms of the amount of data. For millions of files or very large files, you'd need a server-side search solution. But for 300 files, it's perfect.
|
||||
This approach provides excellent performance for dynamic search results while keeping the development and deployment incredibly straightforward.
|
||||
|
||||
https://g.co/gemini/share/7cf82cbfdd34
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
[Seven Dimensions of Security Culture](../Literature%20notes/Seven%20Dimensions%20of%20Security%20Culture.md)
|
||||
|
||||
|
|
@ -1,77 +0,0 @@
|
|||
The ISO27DIY video series teaches you a workshop based approach for implementing an ISO 27001-compliant Information Security Management System (ISMS) in your own organization. The ISO27DIY video series will be available for free.
|
||||
|
||||
These are the current blurbs on the different properties:
|
||||
– see also [🧰 Resource portal](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/🧰%20Resource%20portal.md)
|
||||
|
||||
# ISO27DIY.com website
|
||||
Main website via [Carrd.co](https://iso27diy.com):
|
||||
> ISO27DIY offers a method for implementing an ISO 27001- compliant Information Security Management System (ISMS) in your organization. The ISO27DIY workshop video series will be available for free
|
||||
|
||||
Description for bookmarks and search engine listings:
|
||||
> Learn how to implement ISO 27001 yourself
|
||||
|
||||
# Rent-a-DPO personal site
|
||||
Personal site via [Carrd.co](https://rent-a-dpo.co):
|
||||
> **Trust is Good, Secure is Better**
|
||||
>
|
||||
> Hi, I’m Richard Kranendonk. Since 2017 I’ve helped dozens of organizations, from local charities to internationals, to achieve and maintain their ISO 27001 certification, and to become and remain GDPR compliant.
|
||||
>
|
||||
> Building on 20+ years experience in implementing information technology and organizational change, I can help you design and execute your information security and data protection strategy.
|
||||
>
|
||||
|
||||
**Title:** Rent-a-DPO
|
||||
**Description:** ISO 27001 information security management | GDPR data protection | Strategy and execution
|
||||
|
||||
# Twitter
|
||||
[iso27diy twitter bio](https://twitter.com/iso27diy):
|
||||
🧰 Do ISO 27001 yourself 🔖 Get certified without hiring consultants ⚖️ Control your information security 🧘♀️ Make customers feel safe!
|
||||
|
||||
@richardk twitter bio
|
||||
Making the Internets safer by helping organizations protect their data | @ISO27DIY | ISO 27001 | GDPR | CISSP | ECPC-B | #buildinpublic #indiehacker #nocode
|
||||
|
||||
**Proposed coming out tweet:**
|
||||
It took me a burnout and a psycho boss to make the jump and start building my own service. I feel excited and scared at the same time.
|
||||
#buildinpublic #indiehacker #nocode @thisiskp_ @IndieHackers @makerpad @NocodeHQ
|
||||
|
||||
|
||||
# Revue
|
||||
[Revue](https://www.getrevue.co/app/accounts/ISO27DIY/edit)
|
||||
Newsletter issues description: ISO27DIY newsletter – Learn how to implement ISO 27001 yourself
|
||||
|
||||
# Gumroad
|
||||
|
||||
[Gumroad iso27diy profile](https://app.gumroad.com/iso27diy)
|
||||
ISO27DIY – a method for implementing ISO 27001 in your organization. Get yourself certified.
|
||||
|
||||
[Gumroad personal profile]
|
||||
[Gumroad community introduction](https://community.gumroad.com/c/gumroad-introductions/making-the-jump)
|
||||
|
||||
# Indie Hackers
|
||||
[Indie Hackers profile](https://www.indiehackers.com/rkranendonk)
|
||||
> Making the Internets safer, one ISO 27001 certification at a time 👷♂️ ISO27DYI workshop video series 🎬 AuditGlue documentation software 📑
|
||||
|
||||
[Introduction post:](https://www.indiehackers.com/post/making-the-jump-7ed124b1d1)
|
||||
|
||||
> Hi, I’m Richard. I finally decided to make the jump and start building my own service. I feel excited and scared at the same time.
|
||||
>
|
||||
> I firmly believe that it’s essential that every organization is able to manage their Cybersecurity risks. Not only from a commercial standpoint – being a trustworthy service provider –, but also because safety of information is a requirement for personal freedom and the stability of our society.
|
||||
>
|
||||
> Organizations, especially smaller ones, should be able to acquire the necessary skills without needing to spend large amounts of cash on consultant fees and expensive software.
|
||||
>
|
||||
> So here’s what I’m building:
|
||||
>
|
||||
> 1. a series of YouTube videos, explaining how you can implement ISO 27001* in your organization yourself.
|
||||
> 2. an accompanying membership portal, ISO27DIY.com offering support and additional resources (tooling, templates, example documents, etc.)
|
||||
> 3. a place to create and collect all the necessary documentation to get your ISO 27001 certification: AuditGlue.com
|
||||
>
|
||||
> *) If you’re not familiar with ISO 27001, it’s an international standard for managing information security. Certification for this standard is increasingly becoming a knock-out criterium for vendor selection shortlists.
|
||||
>
|
||||
> I would really appreciate it if you’d sign up for my newsletter on ISO27DIY.com, even if it’s just for moral support ;-)
|
||||
|
||||
Product motivation:
|
||||
> Every organization should be able to manage their information security and achieve ISO 27001 certification, without the need for expensive software or consultants.
|
||||
|
||||
# NoCodeHQ
|
||||
|
||||
# Makerpad community
|
||||
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- prompting
|
||||
---
|
||||
Create a website for iso27DYI.com.
|
||||
Use this logo and this hero image.
|
||||
The landing page must look like this:
|
||||
|
||||
The subscription part will be handled by MailerLite.com.
|
||||
I want a ‘hamburger menu’ in the top right.
|
||||
|
||||
There is a blog page at iso27DYI.com/blog.
|
||||
|
||||
The site will be hosted at Netlify.com
|
||||
|
||||
Use the Hugo framework (see https://gohugo.io/).
|
||||
|
||||
Do not create custom JavaScript unless absolutely necessary.
|
||||
|
||||
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
Borging van security is idealiter in bestaande management systemen en sturcturen van de organisatie.
|
||||
Dat moet breder zijn dan alleen medewerkers die direct betrokken zijn bij security of IT.
|
||||
|
||||
Zo moet er een wedersijdse reflectie zijn tussen het functiehuis en de -profielen en de RBAC voor applicaties.
|
||||
Bijv,: de inkoper mag niet de creditfacturen ter betaling stellen. Of: de medewerker van de Klantenservice die extra rechten nodig heeft in het CRM, dat moet ook te zien zijn in de functieomschrijving.
|
||||
|
||||
En de management verantwoordelijkhden voor veilig werken opp de afdeling, moeten ook leiden tot performance evaluatie op dat punt, naast performance op personeel, klanten en financieen.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Bijv wanneer alle admin accounts gecompromiteerd zijn: een Master account dat alleen toegankelijk is met een passkey op een usb stick in een fysieke kluis ⠀
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
To encourage people to report vulnerabilities, introduce something comparable to a Bug bounty program.
|
||||
|
||||
Use gamification and fun prizes.
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,67 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- iso27DIY
|
||||
- dev
|
||||
- SupaBase
|
||||
---
|
||||
# Building functionality in Supabase
|
||||
Supabase offers several ways to build functionality beyond just SQL and Edge Functions. Here are the main approaches:
|
||||
|
||||
## Core Functionality Building Methods
|
||||
|
||||
**1. SQL Functions (Database Functions)**
|
||||
|
||||
- Postgres has built-in support for SQL functions that live inside your database and can be used with the API
|
||||
- Created directly in the database using SQL
|
||||
- Accessible via the Dashboard’s SQL editor
|
||||
|
||||
**2. Edge Functions**
|
||||
|
||||
- Deno-based serverless functions
|
||||
- Run on the edge for low latency
|
||||
- Good for custom business logic and integrations
|
||||
|
||||
**3. Database Functions & RPC (Remote Procedure Calls)**
|
||||
|
||||
- RPC in Supabase allows developers to invoke custom PostgreSQL functions directly from the client side, particularly useful for encapsulating complex operations
|
||||
- RPC enables executing database functions directly, allowing batching of multiple operations into a single RPC call
|
||||
- Called using the `.rpc()` method in client libraries
|
||||
|
||||
## Additional Functionality Methods
|
||||
|
||||
**4. Database Triggers**
|
||||
|
||||
- PostgreSQL triggers that automatically execute functions when certain database events occur
|
||||
- Can be combined with SQL functions for automated workflows
|
||||
|
||||
**5. Row Level Security (RLS) Policies**
|
||||
|
||||
- Policy-based access control that acts as business logic
|
||||
- Enforces rules at the database level
|
||||
|
||||
**6. Auto-generated REST APIs**
|
||||
|
||||
- Automatic CRUD operations based on your database schema
|
||||
- No additional code needed for basic operations
|
||||
|
||||
**7. Real-time Subscriptions**
|
||||
|
||||
- Listen to database changes in real-time
|
||||
- Automatically generated based on your tables and RLS policies
|
||||
|
||||
**8. GraphQL API**
|
||||
|
||||
- Auto-generated GraphQL APIs available alongside REST
|
||||
- Provides flexible querying capabilities
|
||||
|
||||
**9. Webhooks**
|
||||
|
||||
- Database webhooks that can trigger external services
|
||||
- Can be set up to respond to database events
|
||||
|
||||
**10. PostgREST Extensions**
|
||||
|
||||
- Custom PostgreSQL extensions that extend functionality
|
||||
- Can be installed to add specialized features
|
||||
|
||||
The most common approaches for custom business logic are SQL functions (accessed via RPC), Edge Functions, and database triggers, with each serving different use cases depending on where you want the logic to run and how complex your requirements are.
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
Business Impact Analysis (BIA) is an activity within the proces of Business Continuity Planning ([BCP](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)).
|
||||
|
||||
The goal of a Business Impact Analysis (BIA) process is
|
||||
|
||||
A Business Impact Analysis (BIA) examines the potential impacts of disruptions, such as financial losses, reputational damage, regulatory penalties, and operational continuity.
|
||||
The outcomes help to prioritize business activities and resources to enable the resumption of product and service delivery after a (major) disruption[^1].
|
||||
|
||||
Guidelines and tooling:
|
||||
- [Guidelines for business impact analysis ISO 22317](../Standards/ISO27x/ISO%2022317%20Guidelines%20for%20business%20impact%20analysis.md)
|
||||
- [Assessing reputational risks](Assessing%20reputational%20risks.md)
|
||||
- [BIA Workshop](../Standards/ISO27x/Implementation%20Products/BIA%20Workshop.md)
|
||||
- [TLP impact matrix](../Literature%20notes/Traffic%20Light%20Protocol%20TLP.md)
|
||||
- Afhankelijkheid tussen systemen/voorzieningen?
|
||||
- Resource Breakdown Structure (RBS)
|
||||
- Fishbone Diagram (Ishikawa/Cause and Effect): Useful for identifying root causes of dependencies and resource constraints in processes.
|
||||
|
||||
ISO 27001 Controls:
|
||||
- [5.29:](../MoCs/ISO_27002_2022_5.29_MoC%20Information%20security%20during%20disruption.md) Information security during disruption
|
||||
- [5.30:](../MoCs/ISO_27002_2022_5.30_MoC%20ICT%20readiness%20for%20business%20continuity.md) ICT readiness for business continuity
|
||||
- [5.9:](../MoCs/ISO_27002_2022_5.9_MoC%20Inventory%20of%20information%20and%20other%20associated%20assets.md) Inventory of information and other associated assets – regarding assets marked Critical on the Availability aspect
|
||||
|
||||
[^1]: See [Disaster Recovery Planning](Disaster%20Recovery%20Planning.md)
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 6.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 229 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 287 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 51 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 208 KiB |
|
|
@ -1,88 +0,0 @@
|
|||
# C4 model for software architecture
|
||||
|
||||
The four layers, or Cs, are: **Context, Containers, Components, and Code**.
|
||||
|
||||
The C4 model is a technique for visualizing software architecture using a **hierarchical set of four core diagrams**, which provide different levels of abstraction.1 The four layers, or Cs, are: **Context, Containers, Components, and Code**.2 This structure allows you to zoom in from a high-level overview to implementation-level details.3
|
||||
|
||||
Here is the full C4 model table including all four levels:
|
||||
|
||||
| Aspect | Level 1: System Context | Level 2: Container | Level 3: Component | Level 4: Code/Classes |
|
||||
| ------------ | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
|
||||
| Purpose | Shows the system as a whole and its external users and systems interacting with it. Defines system scope and boundaries. | Breaks the system into high-level technology units (applications, services, databases) that can be deployed independently. | Details the internal structure of a container, consisting of cooperating units of code or services. | Shows the detailed design of the individual components, including classes or code elements. |
|
||||
| Focus | Who uses the system and what external systems it interacts with. | What applications/services/data stores make up the system and how they communicate. | How each container is organized internally in terms of functionality and code structure. | The implementation specifics such as classes, methods, relationships, and code organization. |
|
||||
| Detail Level | High-level, abstract view | Mid-level, technical architecture view | Low-level, detailed design view | Very low-level, source code or design diagrams |
|
||||
| Example | Web application used by customers, admins, and external payment service | Web app, database, API service | Authentication module, data repository, business logic component | Class diagrams, method calls within the authentication module |
|
||||
| Deployment | N/A (conceptual boundary definition) | Independent deployable units | Runs inside a container, not independently deployable | Runs inside components, part of the source code base |
|
||||
|
||||
Level 4 is optional and is generally only needed when an extremely detailed design of the software's internals is required. It bridges the gap between abstract design and actual source code[1][2][3].
|
||||
|
||||
Sources
|
||||
[1] C4 model https://en.wikipedia.org/wiki/C4_model
|
||||
[2] Container diagram https://c4model.com/diagrams/container
|
||||
[3] Component https://c4model.com/abstractions/component
|
||||
|
||||
---
|
||||
|
||||
## 1. Context Diagram (Level 1) 🌍
|
||||
|
||||
The Context diagram provides the **highest-level view**—the "big picture."4 It shows the software system you are describing at the center and how it **fits into the world around it**.5
|
||||
|
||||
- **Focus:** The system in scope, its users (**People**), and the **other software systems** it directly interacts with (external dependencies).
|
||||
|
||||
- **Purpose:** To give all stakeholders, including non-technical ones, a quick and easy-to-understand view of the system's role, scope, and key dependencies. – *Who uses the system and why?*
|
||||
|
||||
|
||||
|  |  |
|
||||
| ------------------------ | ---------------------- |
|
||||
Bronnen:
|
||||
https://mstack.nl/blogs/software-architecture-documentation-using-the-c4-model/
|
||||
https://dev.to/anwaar/c4-model-real-world-example-with-google-maps-3ano
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 2. Container Diagram (Level 2) 📦
|
||||
|
||||
The Container diagram zooms **inside the system** to show its high-level technology choices and the **major structural building blocks**.8 A "container" is an independently deployable/executable unit.9
|
||||
|
||||
- **Focus:** The **containers** (e.g., web applications, mobile apps, databases, separate server-side applications/microservices) that make up the software system, how they interact, and the technology used for each.10
|
||||
|
||||
- **Purpose:** To show software development teams and technical stakeholders the structure of the system and the communication between the major parts.11
|
||||
|
||||
- **Analogy:** The floor plan of a building, showing the different rooms and how they connect (e.g., kitchen, bedrooms, garage).12
|
||||
|
||||
|  |  |
|
||||
| ------------------- | -------------------- |
|
||||
|
||||
---
|
||||
|
||||
## 3. Component Diagram (Level 3) 🧩
|
||||
|
||||
The Component diagram zooms **inside a single container** to show the internal structure.13
|
||||
|
||||
- **Focus:** The **components** (e.g., services, modules, repositories, controllers) that reside within a single container, their responsibilities, and how they interact with each other and with other containers/systems.14
|
||||
|
||||
- **Purpose:** To help developers and architects understand the internal design and organization of the code within a container before diving into code.
|
||||
|
||||
- **Analogy:** Inspecting a single room in the building, showing the furniture, appliances, and internal wiring.15
|
||||
|
||||
|
||||
|  |  |
|
||||
| ------------------- | -------------------- |
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 4. Code Diagram (Level 4) 💻
|
||||
|
||||
The Code diagram provides the **lowest level of detail**, zooming inside a single component.16
|
||||
|
||||
- **Focus:** Implementation-level details, such as **classes, interfaces, objects, and functions**.17
|
||||
|
||||
- **Purpose:** To explain the detailed design of complex or particularly important components.18 This level often relies on existing modeling techniques like UML class diagrams and can often be automatically generated by tools, making it an **optional** level in many cases.19
|
||||
|
||||
- **Analogy:** A detailed schematic diagram of a single appliance in the room, showing its internal parts and electrical connections.
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 33 KiB |
|
|
@ -1 +0,0 @@
|
|||
[Repository](https://github.com/certsocietegenerale/IRM/tree/main) of Incident Response playbooks by CERT Societe Generale
|
||||
|
|
@ -1,233 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- business_process
|
||||
---
|
||||
Related:
|
||||
- [8.25 Secure development life cycle](../Standards/ISO27x/OST/27002/EN/a-8.25-Secure-development-life-cycle.md)
|
||||
- [8.28 Secure coding](../Standards/ISO27x/OST/27002/EN/a-8.28-Secure-coding.md)
|
||||
- [8.29 Security testing in development and acceptance](../Standards/ISO27x/OST/27002/EN/a-8.29-Security-testing-in-development-and-acceptance.md)
|
||||
|
||||
# CI/CD pipeline components
|
||||
|
||||
Asked Gemini, june 2025
|
||||
|
||||
Prompt: `what are the typical components of a CI/CD pipeline and what products are used to implement them?`
|
||||
|
||||
A CI/CD pipeline is a set of automated processes that enable continuous integration, continuous delivery, and continuous deployment of software.1 2It automates the steps involved in building, testing, and deploying software, significantly reducing errors and accelerating delivery.3
|
||||
|
||||
Here are the typical components (stages) of a CI/CD pipeline and the products commonly used to implement them:
|
||||
|
||||
## Typical Components of a CI/CD Pipeline:
|
||||
|
||||
1. **Source Code Management (SCM) / Version Control:**
|
||||
|
||||
- **Purpose:** This is the starting point. Developers commit their code changes to a shared repository, and the pipeline is often triggered by these commits.4 It tracks all changes, enables collaboration, and allows for reverting to previous versions.5
|
||||
|
||||
- **Activities:** Code commits, branching, merging, pull requests.
|
||||
|
||||
- **Key aspects:** Ensures a single source of truth for the codebase.
|
||||
|
||||
2. **Build Stage:**
|
||||
|
||||
- **Purpose:** Transforms the source code into an executable or deployable artifact.6
|
||||
|
||||
- **Activities:** Compiling code (e.g., Java to JAR/WAR, C++ to executables), linking libraries, packaging applications (e.g., into Docker images, ZIP files), running static code analysis (linting, security scans), and basic unit tests.
|
||||
|
||||
- **Key aspects:** Creates the deployable "product" and ensures the code is syntactically correct and meets initial quality standards.
|
||||
|
||||
3. **Test Stage:**
|
||||
|
||||
- **Purpose:** Verifies the quality and functionality of the built artifact. This is a critical stage for catching bugs early.7
|
||||
|
||||
- **Activities:**
|
||||
|
||||
- **Unit Tests:** Test individual components or functions of the code in isolation.8
|
||||
|
||||
- **Integration Tests:** Verify that different modules or services work correctly together.9
|
||||
|
||||
- **Functional Tests (Acceptance Tests):** Validate that the software meets specified requirements from an end-user perspective.10
|
||||
|
||||
- **Performance Tests:** Assess the application's behavior under load and stress.11
|
||||
|
||||
- **Security Tests (SAST/DAST):** Static Application Security Testing (SAST) scans code without executing it; Dynamic Application Security Testing (DAST) inspects the running application for vulnerabilities.12
|
||||
|
||||
- **Key aspects:** Automated testing is crucial for speed and reliability.13 If tests fail, the pipeline typically stops, providing immediate feedback.
|
||||
|
||||
4. **Artifact Repository:**
|
||||
|
||||
- **Purpose:** Stores the successfully built and tested artifacts, ensuring a single, canonical version is used throughout the rest of the pipeline.
|
||||
|
||||
- **Activities:** Publishing and versioning built artifacts.
|
||||
|
||||
- **Key aspects:** Provides a reliable source for deployments and enables easy rollbacks if needed.14
|
||||
|
||||
5. **Deployment Stage:**
|
||||
|
||||
- **Purpose:** Deploys the application to various environments (e.g., development, staging/UAT, production).
|
||||
|
||||
- **Activities:**
|
||||
|
||||
- **Deployment to Staging/UAT:** The application is deployed to an environment that closely mirrors production for further testing, including user acceptance testing (UAT).15
|
||||
|
||||
- **Automated Deployment to Production:** If all tests and approvals pass, the application is automatically deployed to the production environment.16 This can involve various strategies like blue/green deployments or canary deployments for minimizing downtime and risk.17
|
||||
|
||||
- **Infrastructure as Code (IaC):** Automating the provisioning and configuration of infrastructure.18
|
||||
|
||||
- **Key aspects:** Automates the release process, ensuring consistency and speed.
|
||||
|
||||
6. **Monitoring and Feedback:**
|
||||
|
||||
- **Purpose:** Continuously monitor the deployed application in production, collect metrics, and provide feedback to the development team.19
|
||||
|
||||
- **Activities:** Logging, performance monitoring, error tracking, alerting, and reporting.20
|
||||
|
||||
- **Key aspects:** Enables rapid detection of issues, facilitates quick responses, and supports continuous improvement based on real-world usage.21
|
||||
|
||||
|
||||
## Products Used to Implement CI/CD Pipeline Components:
|
||||
|
||||
Many tools can be combined to build a CI/CD pipeline, or you can use all-in-one platforms.22
|
||||
|
||||
### **Integrated CI/CD Platforms (often combining many stages):**
|
||||
|
||||
These platforms offer comprehensive features covering multiple stages of the CI/CD pipeline.
|
||||
|
||||
- **GitLab CI/CD:** Built directly into the GitLab platform, providing a complete DevOps solution from source code management to deployment and monitoring.23
|
||||
|
||||
- **GitHub Actions:** Native to GitHub, allowing for automation of workflows directly within GitHub repositories.24
|
||||
|
||||
- **Azure DevOps (Azure Pipelines):** Microsoft's comprehensive suite of DevOps tools, including CI/CD pipelines, repos, boards, and test plans.25
|
||||
|
||||
- **CircleCI:** A cloud-based CI/CD platform known for its speed, support for containerized builds, and flexible workflows.26
|
||||
|
||||
- **Jenkins:** A highly extensible, open-source automation server with a vast plugin ecosystem, making it adaptable to almost any CI/CD workflow.27 While primarily a CI tool, it can orchestrate CD.
|
||||
|
||||
- **Travis CI:** A popular cloud-based CI service that integrates well with GitHub repositories.28
|
||||
|
||||
- **TeamCity:** A powerful CI/CD server from JetBrains, known for advanced build configurations.29
|
||||
|
||||
- **Bamboo (Atlassian):** An enterprise-grade CI/CD server that integrates seamlessly with other Atlassian tools like Jira and Bitbucket.30
|
||||
|
||||
- **GoCD:** An open-source CI/CD tool that provides value stream mapping for visualizing pipelines.31
|
||||
|
||||
- **Harness:** A continuous delivery-as-a-service platform with AI-augmented capabilities.32
|
||||
|
||||
- **Codefresh:** A CI/CD platform built for Kubernetes, Docker, and Helm workflows.33
|
||||
|
||||
- **Bitbucket Pipelines:** Integrated directly into Atlassian's Bitbucket for seamless CI/CD.34
|
||||
|
||||
- **AWS CodePipeline:** A fully managed CI/CD service from Amazon Web Services, integrating with other AWS developer tools.35
|
||||
|
||||
- **Google Cloud Build:** Google's high-performance CI/CD platform, integrated with Google Cloud services.36
|
||||
|
||||
|
||||
### **Specific Tooling for Individual Stages:**
|
||||
|
||||
- **Source Code Management (SCM):**
|
||||
|
||||
- **Git:** (Distributed Version Control System)37
|
||||
|
||||
- **GitHub:** Popular cloud-based Git repository hosting.
|
||||
|
||||
- **GitLab:** (Offers both SCM and integrated CI/CD)38
|
||||
|
||||
- **Bitbucket:** (Offers both SCM and integrated CI/CD)39
|
||||
|
||||
- **Azure Repos:** (Part of Azure DevOps)40
|
||||
|
||||
- **Build Tools:**
|
||||
|
||||
- **Maven (Java)41**
|
||||
|
||||
- **Gradle (Java, Kotlin)42**
|
||||
|
||||
- **npm/Yarn (JavaScript/Node.js)**
|
||||
|
||||
- **Webpack (JavaScript module bundler)43**
|
||||
|
||||
- **Docker:** For building container images.
|
||||
|
||||
- **Make/CMake (C/C++)**
|
||||
|
||||
- **Testing Frameworks/Tools:**
|
||||
|
||||
- **Unit Testing:**
|
||||
|
||||
- **JUnit (Java)**
|
||||
|
||||
- **pytest (Python)**
|
||||
|
||||
- **Jest (JavaScript)**
|
||||
|
||||
- **NUnit (.NET)**
|
||||
|
||||
- **Integration/Functional Testing:**
|
||||
|
||||
- **Selenium (Web UI automation)44**
|
||||
|
||||
- **Cypress (Front-end testing)45**
|
||||
|
||||
- **Playwright (Web automation)46**
|
||||
|
||||
- **Postman/Newman (API testing)**
|
||||
|
||||
- **Cucumber (Behavior-Driven Development - BDD)47**
|
||||
|
||||
- **Performance Testing:**
|
||||
|
||||
- **JMeter**
|
||||
|
||||
- **Gatling**
|
||||
|
||||
- **Locust**
|
||||
|
||||
- **Security Testing (SAST/DAST):**
|
||||
|
||||
- **SonarQube (Static Analysis, Code Quality)48**
|
||||
|
||||
- **Snyk (Security scanning)49**
|
||||
|
||||
- **OWASP ZAP (DAST)**
|
||||
|
||||
- **Trivy (Container image scanning)50**
|
||||
|
||||
- **Artifact Repositories:**
|
||||
|
||||
- **JFrog Artifactory:** Universal artifact repository manager.51
|
||||
|
||||
- **Nexus Repository Manager:** Supports various formats (Maven, npm, Docker, etc.).
|
||||
|
||||
- **Docker Hub/Amazon ECR/Google Container Registry:** For Docker images.52
|
||||
|
||||
- **Deployment/Orchestration Tools:**
|
||||
|
||||
- **Kubernetes:** Container orchestration platform.53
|
||||
|
||||
- **Helm:** Package manager for Kubernetes.54
|
||||
|
||||
- **Ansible:** Automation engine for configuration management and deployment.55
|
||||
|
||||
- **Terraform:** Infrastructure as Code (IaC) for provisioning cloud resources.56
|
||||
|
||||
- **AWS CodeDeploy:** Deployment service for various compute services.57
|
||||
|
||||
- **Azure Pipelines (Deployment Release Pipelines):** Part of Azure DevOps.58
|
||||
|
||||
- **Spinnaker:** Open-source, multi-cloud continuous delivery platform.59
|
||||
|
||||
- **Argo CD:** Kubernetes-native continuous delivery (GitOps).60
|
||||
|
||||
- **Octopus Deploy:** Specialized in release orchestration and complex deployments.
|
||||
|
||||
- **Monitoring and Logging:**
|
||||
|
||||
- **Prometheus & Grafana:** For monitoring metrics and creating dashboards.61
|
||||
|
||||
- **ELK Stack (Elasticsearch, Logstash, Kibana):** For centralized logging and analysis.
|
||||
|
||||
- **Datadog/New Relic/Dynatrace:** Application Performance Monitoring (APM) tools.62
|
||||
|
||||
- **PagerDuty:** For on-call management and incident response.63
|
||||
|
||||
|
||||
The specific combination of tools will depend on the project's language, architecture (e.g., monolith, microservices), cloud provider, team size, and existing infrastructure.
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
... door een onafhankelijke Partij
|
||||
|
||||
Uit opdracht: "Bescherming tegen actuele *externe* dreigingen".
|
||||
|
||||
Dus een [Pentest](../../Clients/Humankind/Pentest%20Humankind.md).
|
||||
|
||||
Het andere subject onder de kop "Voorzien in basisveiligheid" is:
|
||||
> Verzekering Beschikbaarheid: backups en noodvoorzieningen, calamiteitenplan
|
||||
|
||||
Heeft het zin om de check op afdoende Backups en noodvoorzieningen door de leveranciers mee te nemen in de Scan? Want dat kan eigenlijk alleen afgelezen worden uit de SLA's?
|
||||
|
||||
**Gesprek 13 augustus:**
|
||||
Opties:
|
||||
* Scenario 1: scan aan de buitenkant met kans op restrisico’s in de binnenkant (niet de voorkeur)
|
||||
* Scenario 2: contractonderhandeling met Ilionx doorzetten, in gesprek gaan met Ilionx, jullie hoeven niks op papier te zetten maar er zit wel iemand bij die lastige vragen stelt. Dus een onafhankelijke techneut die vragen stelt. Plus een pentest.
|
||||
|
||||
**Vraagstelling**
|
||||
Wie zijn jullie?
|
||||
Scope:
|
||||
- Ilionx
|
||||
- Infrastructuur op eigen locaties (wifi) - steekproef op 1 locatie - internetverbinding, modem, wifi-router, accesspoints
|
||||
- Niet: EDM, want Nox en Barracuda
|
||||
- Niet MerCash/KidsVision, want al NFIR scan gedaan
|
||||
- Er is een reactie geweest van KidsConnect over wat ze gaan doen met de bevindingen van de NFIR scan, die mag John met mij delen.
|
||||
Ruimte voor suggesties in aanpak
|
||||
Heb je voldoende voor een eerste aanbieding? Of moet je meer weten
|
||||
|
||||
|
|
@ -1,738 +0,0 @@
|
|||
Source: [LinkedIn](https://www.linkedin.com/pulse/insider-threat-prevention-strategy-ask-gerardus-blokdyk/)
|
||||
Author: [Gerardus Blokdyk](https://www.linkedin.com/in/gerardblokdijk/)
|
||||
Publication date: March 25, 2022
|
||||
Retrieved from on December 16, 2024
|
||||
|
||||
1. How does your organization verify that all cleared employees have completed the required insider threat awareness training?
|
||||
|
||||
2. Which organization information does your insider threat detection program leverage?
|
||||
|
||||
3. Does your organization have a defined insider threat management program that involves cooperation among multi disciplinary areas of your organization as human resources, IT and legal?
|
||||
|
||||
4. How does your organization work to identify observable and reportable external cyber threats that may be linked to internal cyber insider threat activities?
|
||||
|
||||
5. Does your organization have a formal incident response plan with provisions for insider threat attacks?
|
||||
|
||||
6. How does your organization close the gap between the initial attack, discovering the insider threat actors deeds and taking action to shut down or otherwise mitigate the event?
|
||||
|
||||
7. Do your CSPs have a formalized insider threat program?
|
||||
|
||||
8. Aside from DLP/CASB solutions, what additional data security solutions does your organization leverage to protect against insider threats?
|
||||
|
||||
9. How does your organization fund and staff a program office to implement your organizations insider threat policy?
|
||||
|
||||
10. Does the insider threat program personnel receive regular, timely access to all relevant and credible information to identify violations, areas of concern or potential insider threat matters?
|
||||
|
||||
11. Can proactive insider threat detection leverage information already being collected for records management purposes, and what would be the ethical and legal fallout of approaches?
|
||||
|
||||
12. What administrative policies and procedures do you have in place for insider threat management?
|
||||
|
||||
13. How is your organization monitoring malicious or inadvertent insider threat risk caused by disgruntled or displaced employees and contractors?
|
||||
|
||||
14. Does your insider threat program have all the necessary components to be effective?
|
||||
|
||||
15. How can social and behavioral factors improve analytics for risk analysis, including operational security and insider threat detection?
|
||||
|
||||
16. How will insider threat awareness training best be accomplished and documented for your organization workforce?
|
||||
|
||||
17. Does any application have any insider threat detection and response capability?
|
||||
|
||||
18. Does your insider threat detection program leverage information from across your organization?
|
||||
|
||||
19. What does it take to build an effective insider threat program within your organization?
|
||||
|
||||
20. Does your organization have a program to identify and/or mitigate the insider threat?
|
||||
|
||||
21. Which departments within your organization participate with your insider threat related program?
|
||||
|
||||
22. Has your organization experienced potential issues of insider threat from current or recently separated employees, contractors, or vendors?
|
||||
|
||||
23. Does your organization have the appropriate controls to detect and prevent an insider attack?
|
||||
|
||||
24. What information type is more difficult to protect against insider threat activities?
|
||||
|
||||
25. Does your organization ignore the insider threat in favor of the outsider threat?
|
||||
|
||||
26. What relationship exists between your organizations program and the insider threat programs established by the various cleared contractors that work for your organization?
|
||||
|
||||
27. Does your organization have a dedicated team or department responsible for monitoring and/or responding to insider threats?
|
||||
|
||||
28. What preventative measures work best to disrupt the insider threat cycle before mission critical or sensitive data is compromised or leaked?
|
||||
|
||||
29. Do you anticipate utilizing a full time insider threat program team or a part time program team?
|
||||
|
||||
30. What does a security roadmap that includes insider threats look like for your organization?
|
||||
|
||||
31. Does security and privacy awareness training include information on recognizing and reporting indicators of insider threat?
|
||||
|
||||
32. Does any initiative become prone to insider threat or is it going to bring more value to mitigate it?
|
||||
|
||||
33. How long does it typically take your organization to mitigate and stop an insider attack?
|
||||
|
||||
34. How would an apparent insider threat change your response and communication procedures?
|
||||
|
||||
35. What role can technology now play in improving insider threat detection and response?
|
||||
|
||||
36. Does an insider threat program also encompass detection and investigation of inside threats?
|
||||
|
||||
37. Have arrangements to deal with the potential insider threat and changed control environment associated with remote working been put in place?
|
||||
|
||||
38. How does your organization allocate resources to mitigate or curtail insider threats?
|
||||
|
||||
39. How is insider threat awareness training accomplished and documented for your organizations workforce?
|
||||
|
||||
40. Should your organization use technical measures like restricting access to curtail the risk of insider attack?
|
||||
|
||||
41. How are you positioned to pursue a risk based insider threat monitoring program?
|
||||
|
||||
42. Do you believe your organization has invested enough to mitigate the risk of insider threats?
|
||||
|
||||
43. How do you position an insider threat program to your workforce?
|
||||
|
||||
44. How does cloud adoption complicate the insider threat, and what is your organization doing about it?
|
||||
|
||||
45. How effective do you consider your insider threat prevention and detection methods?
|
||||
|
||||
46. How do you create a culture of awareness and support to catch problems early and disrupt a possible insider threat before it ever exists?
|
||||
|
||||
47. Where is potentially anomalous or risky behavior associated with an insider threat reported?
|
||||
|
||||
48. What is the policy to thwart insider threat in your cybersecurity organizations?
|
||||
|
||||
|
||||
|
||||
## **Organized by Key Themes: SECURITY, DATA, RISK, INSIDER, THREAT, MANAGEMENT, PRODUCT, PROJECT, DESIGN, DEVELOP:**
|
||||
|
||||
|
||||
|
||||
### SECURITY:
|
||||
|
||||
|
||||
|
||||
How do you create a culture of awareness and support to catch problems early and disrupt a possible insider threat before it ever exists?
|
||||
|
||||
Lead application security solutions, data loss prevention solutions, insider threat solutions, enterprise vulnerability management and support business development (merger, acquisition, divestiture) security and IT solutions.
|
||||
|
||||
|
||||
|
||||
What is the visibility and messaging put out to your organization on the insider program?
|
||||
|
||||
Make sure the Information Security Incident Response team is responsible for managing the detection and reporting of information security and insider threat incidents, supporting all organization Business Units.
|
||||
|
||||
|
||||
|
||||
What auditing and tracking does your organization get when using an external cloud application?
|
||||
|
||||
Invest in planning, organizing and leading IT security projects related to network, system and data security, to include insider threat detection, enterprise information security reporting, auditing, as well as system risk management and mitigation.
|
||||
|
||||
|
||||
|
||||
Is your organization protected against someone who knows your system better than anyone else?
|
||||
|
||||
Confirm that your design is leveraging advanced threat assessment technology and involvement in building high-level information security infrastructure, you develop adaptive solutions uniquely tailored to your (internal) customers business objectives to protect sensitive data against sophisticated threats in an increasingly complex security environment.
|
||||
|
||||
|
||||
|
||||
What are the biggest challenges your organization faces in establishing whether an event or incident is an insider threat?
|
||||
|
||||
Make sure your company manage all enterprise cyber, data protection, and insider threat programs, including establishing incident response, 24x7 security operations center, and security engineering, architecture and intelligence teams.
|
||||
|
||||
|
||||
|
||||
How do you speed up security investigations and reduce the impact of insider threats?
|
||||
|
||||
Guarantee your strategy performs as a member of the security team to invest in the execution of an insider threat program.
|
||||
|
||||
|
||||
|
||||
How will you manage the risk of your hardware or software becoming unsupported?
|
||||
|
||||
Support the daily monitoring, escalation, and remediation of information security and insider threat events with relevant teams that support the incident response process.
|
||||
|
||||
|
||||
|
||||
How do you use your incident response planning for more than data breaches?
|
||||
|
||||
Make sure your company is involved in working with Insider Threat regulations and information security reports.
|
||||
|
||||
|
||||
|
||||
What environments, logical and geographical does your deployment need to reach/support?
|
||||
|
||||
Ensure you have involvement building and leading a team to Support Insider risk program including data loss prevention, email security, forensics and data collection (including cloud).
|
||||
|
||||
|
||||
|
||||
Does your organization have a dedicated team or department responsible for monitoring and/or responding to insider threats?
|
||||
|
||||
Make sure the team works closely with peers responsible for Threat Management, Malware Analysis, Insider Threat, and Security Automation.
|
||||
|
||||
|
||||
|
||||
### DATA:
|
||||
|
||||
|
||||
|
||||
Are the risks associated with cloud computing actually higher than the risks your organization is facing form internal systems?
|
||||
|
||||
Make sure the Director, Insider Threat serves as the Insider Risk Working Group chairperson, working to govern the program, identify, prioritize and implement insider risk use cases, and coordinating across business units to ensure those responsible and accountable for data are kept consulted and informed.
|
||||
|
||||
|
||||
|
||||
Does your organization deserve credit for trying to identify and prioritize its data?
|
||||
|
||||
Support log ingestion activities in partnership with application owners and analytics platform teams, run threat modelling, co-relate data and build policies to identify insider threats in critical business applications.
|
||||
|
||||
|
||||
|
||||
Do you have a budget specifically allocated for investment in enabling technologies to reduce the insider threat?
|
||||
|
||||
Continue to leverage and enhance User Activity Monitoring (UAM), Data Loss Prevention (DLP), and SIEM technology solutions to address risk as it relates to all aspects of Insider Threat risk.
|
||||
|
||||
|
||||
|
||||
Who will be responsible for protecting the privacy rights of the public and employees affected by the interface?
|
||||
|
||||
Certify your organization is responsible for Exceptions Risk Management for Insider Threat Operations as well as data movement reviews, data collection and analysis, and identification of anomalous patterns of data.
|
||||
|
||||
|
||||
|
||||
Does your organization have policies describing how to identify and respond to at risk employees?
|
||||
|
||||
Safeguard that your team develops analytical models that leverage relevant data from the Insider Threat detection tools, and other applicable data sources, to identify anomalies potentially indicative of an insider threat.
|
||||
|
||||
|
||||
|
||||
How do you define an insider threat?
|
||||
|
||||
Define business and technical requirements for data loss and insider threat detection and prevention solutions.
|
||||
|
||||
|
||||
|
||||
Which technologies do you use as part of your organizations threat hunting approach?
|
||||
|
||||
Manage IT Security Program involving services to include cybersecurity operations, continuous monitoring, security information and event management, security architecture, security engineering, vulnerability scanning, endpoint security, security analytics, network access control, penetration testing, data forensics, security data ingestion and analysis, incident analysis, threat monitoring/hunt and security situational awareness.
|
||||
|
||||
|
||||
|
||||
Do your CSPs have a formalized insider threat program?
|
||||
|
||||
Interface so that your organization is developing and analyzing data based on current and past insider threat cases and the significance of trends.
|
||||
|
||||
|
||||
|
||||
How do you improve privilege review technology to better enable vital business practices?
|
||||
|
||||
Support the implementation of data collection and analysis systems to enable insider threat detection activities.
|
||||
|
||||
|
||||
|
||||
### RISK:
|
||||
|
||||
|
||||
|
||||
How are security cultures developed in your organizations that you engage with?
|
||||
|
||||
Develop experience working with Data Loss Prevention (DLP), insider threat detection and response, Cloud Access System Brokers (CASB), SIEM solutions, and User Behavior Analytics (UBA) to address risk as it relates to Insider Threat, sensitive data exfiltration, identity access management, and/or fraud.
|
||||
|
||||
|
||||
|
||||
How do you create a culture of awareness and support to catch problems early and disrupt a possible insider threat before it ever exists?
|
||||
|
||||
Oversee that your company develops response strategies and technical support documents, summaries, reports, presentations and other designated products that help support the Insider Threat program and other organizational entities identification of team member centric risk.
|
||||
|
||||
|
||||
|
||||
Does your program incorporate a focus on external stakeholders as third parties to include supply chain providers?
|
||||
|
||||
Assure your organization provides threat information and identify best practices for managing supply chain and insider risks, from economic and threat perspectives.
|
||||
|
||||
|
||||
|
||||
What is the solution to reducing your exposure and defending against corresponding high risk insider threats?
|
||||
|
||||
Provide leadership and support to the Insider Threat Steering Committee to ensure the risk from Insider Threats is continually managed and reducing, if outside risk appetite.
|
||||
|
||||
|
||||
|
||||
Do you have a good understanding of the programs your personnel are performing on?
|
||||
|
||||
Develop experience leading, coordinating, and performing risk assessments, including insider threat related activities.
|
||||
|
||||
|
||||
|
||||
Is a system of perimeter controls maintained to deter or detect unauthorized introduction or removal of classified information from the facility?
|
||||
|
||||
Develop and maintain an insider threat risk convergence model.
|
||||
|
||||
|
||||
|
||||
What are the main benefits of using a threat hunting platform for security analysts?
|
||||
|
||||
Make sure your personnel is providing tailored intelligence and insider threat risk analysis.
|
||||
|
||||
|
||||
|
||||
Does the person of concern have problems with supervisors, management, or leadership?
|
||||
|
||||
Manage ownership of the intellectual property focused Insider Risk Manager Insider Threat program.
|
||||
|
||||
|
||||
|
||||
What are the leading practices for combating insider threats, and how do ours differ?
|
||||
|
||||
Assure your staff has involvement in developing an IS audit strategy that reflects your organizations risk profile, regulatory/legal requirements, current threat trends, and IS industry best practices.
|
||||
|
||||
|
||||
|
||||
How do you reign in privileged users and protect against insider threat?
|
||||
|
||||
Provide analytical support and/or other input to facilitate Sensitive Information Protection, Insider Risk, Employee Relations, Legal, or Human Relations efforts to protect sensitive content and confidential information.
|
||||
|
||||
|
||||
|
||||
### INSIDER:
|
||||
|
||||
|
||||
|
||||
How are you positioned to pursue a risk based insider threat monitoring program?
|
||||
|
||||
Provide support to create, build, implement and maintain Insider Threat use cases with risk focused user entity behavior analytics, user access monitoring tools, data loss prevention, and/or other related capabilities.
|
||||
|
||||
|
||||
|
||||
Is there an advanced monitoring mechanism in the solution allowing to measure the potential performance bottlenecks and to give clear information about what should be done to fix the limitation?
|
||||
|
||||
Be sure your process is responding to, investigating, and documenting potential insider threat indicators displayed by contractors and/or organization employees.
|
||||
|
||||
|
||||
|
||||
What approaches, if any, are currently being used for the safety and security of your organization?
|
||||
|
||||
Guarantee your workforce reviews information to identify anomalous behavior indicative of an insider threat, and to use detection and analysis tools in the development of a comprehensive view of the potential threat.
|
||||
|
||||
|
||||
|
||||
Does your organization ensure all classified IS users will be trained on responsibilities and the training will include information related to the insider threat program?
|
||||
|
||||
Assure your workforce is managing the corporate insider threat program to include training, execution and compliance.
|
||||
|
||||
|
||||
|
||||
Is it feasible to measure knowledge, knowledge sharing and knowledge management within your organization using the COBIT 5 framework?
|
||||
|
||||
Make sure your workforce works with Insider Threat committee to make sure of compliance with reporting and maintaining a safe work environment.
|
||||
|
||||
|
||||
|
||||
Are procedures established to review classified holdings on a recurring basis for the purpose of maintaining classified inventories to the minimum required for classified operations?
|
||||
|
||||
Liaison so that your group provides support to CSM for establishment and maintaining of Insider Threat Program.
|
||||
|
||||
|
||||
|
||||
What does it take to build an effective insider threat program within your organization?
|
||||
|
||||
Partner with internal teams to build out Insider threat related programs.
|
||||
|
||||
|
||||
|
||||
What department in your organization should be involved in an insider threat program?
|
||||
|
||||
Establish that your process is involved in Counterintelligence, Insider Threat, and access control systems.
|
||||
|
||||
|
||||
|
||||
What really needs to be determined is how the team will be structured and where it will be located?
|
||||
|
||||
Cultivate an enterprise program that embeds insider risk processes into your daily operations.
|
||||
|
||||
|
||||
|
||||
How do you detect an insider threat?
|
||||
|
||||
Collaborate on the build and implementation of processes and technologies to detect high risk insider activities that are accidental or malicious in nature.
|
||||
|
||||
|
||||
|
||||
### THREAT:
|
||||
|
||||
|
||||
|
||||
How are guidelines going to be adhered to in your organization and how is your business going to manage the service management requirements?
|
||||
|
||||
Make sure the Program Manager is responsible for leading collaboration and partnership with cross-functional stakeholders and business unit leadership across the organization to guide Insider Threat inquiries, investigations, and incidents.
|
||||
|
||||
|
||||
|
||||
How do you know if systems are trustworthy?
|
||||
|
||||
Guarantee your team is serving as key coordinator between multiple/cross discipline stakeholders to ensure enterprise wide integration of Insider Threat program efforts.
|
||||
|
||||
|
||||
|
||||
Does your organization have policies and practices mandating security awareness training?
|
||||
|
||||
Interface so that your design is identifying and recommending process improvement methodologies and principles to optimize the Insider Threat program and implement best practices.
|
||||
|
||||
|
||||
|
||||
Does the solution provide a supported and documented API to automate functionality, to push data into the solution?
|
||||
|
||||
Provide consulting support services to organization and private sector (internal) clients related to the development of insider threat programs.
|
||||
|
||||
|
||||
|
||||
Do you supplement traditional incident focused approaches to threat discovery with an approach that feeds metadata to a pattern focused analytic?
|
||||
|
||||
Verify that your team is responsible for identifying and developing Insider Threat Detection Use cases focused on insider threats.
|
||||
|
||||
|
||||
|
||||
Does your organization provide security awareness training on recognizing and reporting potential indicators of insider threat?
|
||||
|
||||
Guarantee your staff is collecting, analyzing and interpreting qualitative and quantitative data from multiple sources for the purpose of documenting investigations, analyzing findings and provide Insider threat metrics.
|
||||
|
||||
|
||||
|
||||
Does your organization ensure all classified IS users will be trained on responsibilities and the training will include information related to the insider threat program?
|
||||
|
||||
Trained and proficient working with data loss protection (DLP), user entity behavior analytics (UEBA), digital forensics and/or Insider Threat tools.
|
||||
|
||||
|
||||
|
||||
Do your cleared employees, as well as yourself, know what a violation is and to whom you should report it?
|
||||
|
||||
Invest in the development of an Insider Threat program from the ground up, including the development of Concept of Operations and Standard Operating Procedure documents that build on (internal) clients existing acceptable use and need to know policies.
|
||||
|
||||
|
||||
|
||||
Do the countermeasures interdict the threat during or just prior to the attack?
|
||||
|
||||
Be certain that your organization works with Directors on inter divisional communication for the success of compliance programs, insider threat program, quality and safety standards and business strategies.
|
||||
|
||||
|
||||
|
||||
How does your cybersecurity program apply industry standards and best practices?
|
||||
|
||||
Make headway so that your team is identifying and facilitating implementation of Insider Threat program best practices.
|
||||
|
||||
|
||||
|
||||
### MANAGEMENT:
|
||||
|
||||
|
||||
|
||||
How do you integrate policy and compliance with an effective Insider Threat program?
|
||||
|
||||
Ensure your strategy performs data discovery, data classification, insider threat management and Data Loss Prevention (DLP) tasks.
|
||||
|
||||
|
||||
|
||||
What is the probability of a given observed sequence with respect to your model?
|
||||
|
||||
Make sure there is program management and collaboration across diverse stakeholders for Insider Threat programs.
|
||||
|
||||
|
||||
|
||||
What value would user activity monitoring provide in overcoming insider threats?
|
||||
|
||||
Research or develop methodologies for conducting digital/electronic forensics, intrusion detection, insider threat monitoring, risk management, and incident response and remediation.
|
||||
|
||||
|
||||
|
||||
Are your employees properly screened for clearance and need to know prior to attending classified meetings?
|
||||
|
||||
Coordinate with legal, privacy, human resource, and compliance internal business partners on the intention and scope of the Insider Risk Management Program.
|
||||
|
||||
|
||||
|
||||
What is the biggest barrier to achieving the necessary agility to respond to changes in the insider threat environment?
|
||||
|
||||
Develop experience working on a team to implement new business programs and/or technologies and navigating change management issues.
|
||||
|
||||
|
||||
|
||||
Does an insider threat program also encompass detection and investigation of inside threats?
|
||||
|
||||
Establish and mature the enterprise threat management program to include threat aggregation, analysis, modeling, hunts, and insider.
|
||||
|
||||
|
||||
|
||||
What are an employees beliefs about the outcomes of compliance and noncompliance that influence beliefs about the overall assessment of consequences?
|
||||
|
||||
Assess and design security management functions as related to cyberspace.
|
||||
|
||||
|
||||
|
||||
What are the leading practices for combating insider threats, and how do yours differ?
|
||||
|
||||
Verify that your organization is involved in Cloud (AWS/Azure) change management tools and practices.
|
||||
|
||||
|
||||
|
||||
Does your organization have a defined insider threat management program that involves cooperation among multi disciplinary areas of your organization as human resources, IT and legal?
|
||||
|
||||
Interact and maintain highly effective partnerships with line of business management, COO team and staff.
|
||||
|
||||
|
||||
|
||||
Does security training include how to communicate employee and management concerns regarding potential indicators of insider threat?
|
||||
|
||||
Ensure strong business acumen and project management expertise.
|
||||
|
||||
|
||||
|
||||
### PRODUCT:
|
||||
|
||||
|
||||
|
||||
Does your program incorporate a focus on external stakeholders as third parties to include supply chain providers?
|
||||
|
||||
Safeguard that your team investigations, Brand Protection, Business Risk analytics/reporting, Ecommerce Enforcement, Insider Threat, Physical Security, Product Integrity, Supply Chain Security and Technical Security Countermeasures.
|
||||
|
||||
|
||||
|
||||
Does the solution provide a supported and documented API to automate functionality, to pull data from the solution?
|
||||
|
||||
Work on a support team providing support services for a Production application.
|
||||
|
||||
|
||||
|
||||
How do you maximize the value of your content and boost visibility and control over your sensitive data, all while safeguarding your business from ransomware and insider threats?
|
||||
|
||||
Work with Product team to plan new features, gather requirements and propose solutions.
|
||||
|
||||
|
||||
|
||||
How do you create a culture of awareness and support to catch problems early and disrupt a possible insider threat before it ever exists?
|
||||
|
||||
Be on a monthly On Call schedule to support Production environment after business hours.
|
||||
|
||||
|
||||
|
||||
How would you characterize the effectiveness of your organization to monitor, detect, and respond to insider threats?
|
||||
|
||||
Make sure your process troubleshoots business and production issues.
|
||||
|
||||
|
||||
|
||||
What information needs to be captured to perform the prioritization and to give the human analysts a good starting point?
|
||||
|
||||
Make headway so that your team is facilitating prioritization sessions for the product backlog.
|
||||
|
||||
|
||||
|
||||
Does business development and human resources understand the nature of existing threats and information to be aware of that may place your organization at risk?
|
||||
|
||||
Help the Scrum Team understand the need for clear and concise Product Backlog items.
|
||||
|
||||
|
||||
|
||||
What impacts do emerging information technologies have on the capabilities and limitations of the personnel security adjudicative guidelines to mitigate insider threats?
|
||||
|
||||
Apply best practice approaches and guide the product team through the process.
|
||||
|
||||
|
||||
|
||||
How do you maximize the value of your content and boost visibility and control over your sensitive data, all while safeguarding your business from ransomware and insider threats?
|
||||
|
||||
Make headway so that your design ensures the Product Owner knows how to arrange the Product Backlog to maximize value.
|
||||
|
||||
|
||||
|
||||
Does your facility have procedures in place that will help recognize and stop a threat from within?
|
||||
|
||||
Maintain availability and performance SLAs based on business and product requirements.
|
||||
|
||||
|
||||
|
||||
### PROJECT:
|
||||
|
||||
|
||||
|
||||
How do you improve privilege review technology to better enable vital business practices?
|
||||
|
||||
Verify that your team is involved in RESTful and SOAP-based web services involvement working with geographically separate project teams Liaison so that your workforce is involved in unit testing and automated testing tools Guarantee your group is involved in secure coding practices involvement implementing web content management systems in a large corporate environment.
|
||||
|
||||
|
||||
|
||||
How important are the effected components to the ICS and to operations in general?
|
||||
|
||||
Establish that your team provides status updates on work projects and any technical issues that present risk to project timeline with priority by selected project framework.
|
||||
|
||||
|
||||
|
||||
Does your organization have a defined insider threat management program that involves cooperation among multi disciplinary areas of your organization as human resources, IT and legal?
|
||||
|
||||
Capture and disseminate information pertaining to issues and risks with contingency and mitigation plans defined by Teams and the project charter and tracked in the team repository.
|
||||
|
||||
|
||||
|
||||
Will the number and type of users requiring access to the classified systems and networks change?
|
||||
|
||||
Make sure your team projects include significant business process and/or technology change.
|
||||
|
||||
|
||||
|
||||
Do you integrate customized tenant requirements into your security incident response plans?
|
||||
|
||||
Disseminate information to all Team members through transmittal methods directed by your organization per the project communication plan.
|
||||
|
||||
|
||||
|
||||
Are the numbers of clearances held to a minimum consistent with contractual requirements?
|
||||
|
||||
Ensure your organization manages projects from intake to delivery serving as both Business Analyst and Project Manager.
|
||||
|
||||
|
||||
|
||||
Have arrangements to deal with the potential insider threat and changed control environment associated with remote working been put in place?
|
||||
|
||||
Facilitate change management activities between the project team and IT service groups.
|
||||
|
||||
|
||||
|
||||
Do you have access to a comprehensive range of visualization and multidimensional analytics for the timely delivery of intelligence, including threat and fraud analytics?
|
||||
|
||||
Confirm that your process motivates project team in order to deliver project outcomes.
|
||||
|
||||
|
||||
|
||||
What metrics do you use to measure trustworthiness without alienating employees?
|
||||
|
||||
Make headway so that your design informs team members of risks and issues associated with each project.
|
||||
|
||||
|
||||
|
||||
How do you create a culture of awareness and support to catch problems early and disrupt a possible insider threat before it ever exists?
|
||||
|
||||
Provide project management support to the IT business area.
|
||||
|
||||
|
||||
|
||||
### DESIGN:
|
||||
|
||||
|
||||
|
||||
Are you aware of any incidents that involved the use of information found on social networking media to negatively impact your organization?
|
||||
|
||||
Oversee that your company is involved in insider threat analysis, mitigation and program design.
|
||||
|
||||
|
||||
|
||||
Do you have access to a comprehensive range of visualization and multidimensional analytics for the timely delivery of intelligence, including threat and fraud analytics?
|
||||
|
||||
Apply architectural and engineering concepts to design a solution that meets operational requirements, such as scalability, maintainability, security, reliability, extensibility, flexibility, availability and manageability Act as a key interface to your internal (internal) customers, and work closely with the delivery team to help deliver successful solution insights to your internal business leaders.
|
||||
|
||||
|
||||
|
||||
How will you manage the risk of your hardware or software becoming unsupported?
|
||||
|
||||
Certify your design gathers requirements, designs and deploys network solutions to support business alignment.
|
||||
|
||||
|
||||
|
||||
How do you synthesize social science and technical research output to respond to insider threat problems?
|
||||
|
||||
Safeguard that your operation analyzes business requirements and problems and drives research to design quality technical solutions.
|
||||
|
||||
|
||||
|
||||
What are the leading practices for combating insider threats, and how do ours differ?
|
||||
|
||||
Manage, monitor, and operate applications Lead other team members in design and coding phases.
|
||||
|
||||
|
||||
|
||||
Are you aware of any incidents that involved the use of information found on social networking media to negatively impact your organization?
|
||||
|
||||
Assure your operation is involved in design systems in large scale organizations.
|
||||
|
||||
|
||||
|
||||
How do you balance being a great place to work with the risk of insider threat?
|
||||
|
||||
Oversee that your personnel is maintaining operational effectiveness and efficiency by performing research on new LAN/WAN technology, designing changes to LAN and WAN activities, developing testing procedures and implementing changes Protects LAN/WAN networks by assessing current security posture.
|
||||
|
||||
|
||||
|
||||
What administrative policies and procedures do you have in place for insider threat management?
|
||||
|
||||
Manage Business Process Design understanding.
|
||||
|
||||
|
||||
|
||||
Is open shelf or bin storage of classified information, media, or equipment approved?
|
||||
|
||||
Confirm that your organization is documenting requirements and system design using approved organization formats.
|
||||
|
||||
|
||||
|
||||
Has a tcp been established to control access to all export controlled information?
|
||||
|
||||
Make sure your team has involvement with Design Thinking.
|
||||
|
||||
|
||||
|
||||
### DEVELOP:
|
||||
|
||||
|
||||
|
||||
What does a security roadmap that includes insider threats look like for your organization?
|
||||
|
||||
Develop experience developing strategy for insider threat programs to include working with various stakeholders like Privacy, Human Resources and Legal.
|
||||
|
||||
|
||||
|
||||
What auditing and tracking does your organization get when using an external cloud application?
|
||||
|
||||
Safeguard that your workforce provides monitoring and analysis of insider and external threats using network security tools and custom developed scripts.
|
||||
|
||||
|
||||
|
||||
How do you detect insider threats or non malware threats?
|
||||
|
||||
Develop and implement criteria to identify anomalous user behavior leading indicating insider threat activity.
|
||||
|
||||
|
||||
|
||||
Do you have any concerns regarding security threats coming from authorised users?
|
||||
|
||||
Identify and develop Insider Threat Detection Use cases focused on insider risks.
|
||||
|
||||
|
||||
|
||||
Do you conduct background investigations or currently monitor network activity?
|
||||
|
||||
Identify and develop Insider Threat Detection use cases and conduct Insider Threat investigations.
|
||||
|
||||
|
||||
|
||||
What are the constructs influencing the information security policy compliance existing in extant literature?
|
||||
|
||||
Warrant that your strategy provides guidance on business requirements to team members in developing the application.
|
||||
|
||||
|
||||
|
||||
What information type is more difficult to protect against insider threat activities?
|
||||
|
||||
Ensure your comprehensive solution enables CIOs and CSOs develop viable defensive positions to protect organization assets from insider threats.
|
||||
|
||||
|
||||
|
||||
What percentage of your IT budget are you currently spending for prevention and detection of insider incidents or attacks?
|
||||
|
||||
Make sure the Technical Business Analyst is responsible for analysis of (internal) client opportunities, validation of opportunities and use cases, develop documented analysis and recommend best practice solutions to Automation Product Managers for automation solutioning.
|
||||
|
||||
|
||||
|
||||
How may an insider first try to remove or disclose protected information from your organization?
|
||||
|
||||
Conduct open source research about industry trends and developments in protecting IP and countering Insider Threats.
|
||||
|
||||
|
||||
|
||||
How are security cultures developed in your organization and your organizations that you engage with?
|
||||
|
||||
Ensure your workforce works with team to identify potential risks, develop contingency plans.
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
**Definition:**
|
||||
"A *data classification* identifies the value of the data to the organization. Classification labels, the method by which they are assigned, and the required protection associated with the different labels, are identified in a policy."
|
||||
Source: [CISSP_OSG_Chapter_5](../Standards/CISSP/CISSP_OSG_Chapter_5.md#Defining%20data%20Classifications)
|
||||
|
||||
Classification criteria should be risk based, for instance on potential damage to the organization, the privacy of individuals, national security, economic interests, or other critical concerns.
|
||||
|
||||
See also:
|
||||
[Datatags System](../Literature%20notes/Datatags%20System.md)
|
||||
[Def_Sec_Handbook_Chapter_2](../Literature%20notes/Def_Sec_Handbook_Chapter_2.md#Information%20classification)
|
||||
[ISO 27002:2022 NL A5.12](../Standards/ISO27x/OST/27002/NL/a-5.12-Classificeren-van-informatie.md)
|
||||
[Designing an information management scheme](../Literature%20notes/Designing%20an%20information%20management%20scheme.md)
|
||||
[Data classification examples from SANS forum](Data%20classification%20examples%20from%20SANS%20forum.md)
|
||||
[Key Topics for a Classified Information Security Policy](Key%20Topics%20for%20a%20Classified%20Information%20Security%20Policy.md)
|
||||
[Traffic Light Protocol (TLP)](../Literature%20notes/Traffic%20Light%20Protocol%20TLP.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
[CISSP_OSG_Chapter_4](../Standards/CISSP/CISSP_OSG_Chapter_4.md)
|
||||
[Continuous Compliance products](Continuous%20Compliance%20products.md)
|
||||
[ISO 27001 A 18 Compliance](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md)
|
||||
|
|
@ -1,194 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- iso27DIY
|
||||
- architecture
|
||||
- SupaBase
|
||||
- LLMgenerated
|
||||
---
|
||||
To connect an LLM to Supabase and create content based on organizational data, you'll need to build a system that retrieves data, constructs prompts, and sends them to an LLM API. Here's how to approach this:
|
||||
|
||||
## 1. Set up Supabase Connection
|
||||
|
||||
First, establish a connection to your Supabase database:
|
||||
|
||||
```javascript
|
||||
import { createClient } from '@supabase/supabase-js'
|
||||
|
||||
const supabaseUrl = 'your-supabase-url'
|
||||
const supabaseKey = 'your-supabase-anon-key'
|
||||
const supabase = createClient(supabaseUrl, supabaseKey)
|
||||
```
|
||||
|
||||
## 2. Design Your Database Schema
|
||||
|
||||
Structure your tables to store:
|
||||
- Organization data (name, industry, values, etc.)
|
||||
- Prompt templates with placeholders
|
||||
- Generated content history
|
||||
|
||||
```sql
|
||||
-- Organizations table
|
||||
CREATE TABLE organizations (
|
||||
id UUID PRIMARY KEY,
|
||||
name TEXT,
|
||||
industry TEXT,
|
||||
description TEXT,
|
||||
values JSONB,
|
||||
created_at TIMESTAMP DEFAULT NOW()
|
||||
);
|
||||
|
||||
-- Prompt templates table
|
||||
CREATE TABLE prompt_templates (
|
||||
id UUID PRIMARY KEY,
|
||||
name TEXT,
|
||||
template TEXT,
|
||||
variables JSONB,
|
||||
created_at TIMESTAMP DEFAULT NOW()
|
||||
);
|
||||
```
|
||||
|
||||
## 3. Create the Integration Logic
|
||||
|
||||
Build functions to retrieve data and construct prompts:
|
||||
|
||||
```javascript
|
||||
// Fetch organization data
|
||||
async function getOrganizationData(orgId) {
|
||||
const { data, error } = await supabase
|
||||
.from('organizations')
|
||||
.select('*')
|
||||
.eq('id', orgId)
|
||||
.single()
|
||||
|
||||
if (error) throw error
|
||||
return data
|
||||
}
|
||||
|
||||
// Fetch prompt template
|
||||
async function getPromptTemplate(templateId) {
|
||||
const { data, error } = await supabase
|
||||
.from('prompt_templates')
|
||||
.select('*')
|
||||
.eq('id', templateId)
|
||||
.single()
|
||||
|
||||
if (error) throw error
|
||||
return data
|
||||
}
|
||||
|
||||
// Construct the final prompt
|
||||
function constructPrompt(template, orgData) {
|
||||
let prompt = template.template
|
||||
|
||||
// Replace placeholders with actual data
|
||||
prompt = prompt.replace('{{organization_name}}', orgData.name)
|
||||
prompt = prompt.replace('{{industry}}', orgData.industry)
|
||||
prompt = prompt.replace('{{description}}', orgData.description)
|
||||
|
||||
// Handle JSON data
|
||||
if (orgData.values) {
|
||||
prompt = prompt.replace('{{values}}', JSON.stringify(orgData.values))
|
||||
}
|
||||
|
||||
return prompt
|
||||
}
|
||||
```
|
||||
|
||||
## 4. Connect to Your LLM
|
||||
|
||||
Choose your LLM provider (OpenAI, Anthropic, etc.) and set up the API call:
|
||||
|
||||
```javascript
|
||||
// Example with OpenAI
|
||||
import OpenAI from 'openai'
|
||||
|
||||
const openai = new OpenAI({
|
||||
apiKey: process.env.OPENAI_API_KEY
|
||||
})
|
||||
|
||||
async function generateContent(prompt) {
|
||||
const response = await openai.chat.completions.create({
|
||||
model: "gpt-4",
|
||||
messages: [
|
||||
{
|
||||
role: "system",
|
||||
content: "You are a content creator for organizations."
|
||||
},
|
||||
{
|
||||
role: "user",
|
||||
content: prompt
|
||||
}
|
||||
],
|
||||
max_tokens: 1000,
|
||||
temperature: 0.7
|
||||
})
|
||||
|
||||
return response.choices[0].message.content
|
||||
}
|
||||
```
|
||||
|
||||
## 5. Create the Main Function
|
||||
|
||||
Tie everything together:
|
||||
|
||||
```javascript
|
||||
async function createOrganizationContent(orgId, templateId) {
|
||||
try {
|
||||
// 1. Fetch organization data
|
||||
const orgData = await getOrganizationData(orgId)
|
||||
|
||||
// 2. Fetch prompt template
|
||||
const template = await getPromptTemplate(templateId)
|
||||
|
||||
// 3. Construct the prompt
|
||||
const finalPrompt = constructPrompt(template, orgData)
|
||||
|
||||
// 4. Generate content with LLM
|
||||
const generatedContent = await generateContent(finalPrompt)
|
||||
|
||||
// 5. Store the result back in Supabase
|
||||
const { data, error } = await supabase
|
||||
.from('generated_content')
|
||||
.insert({
|
||||
organization_id: orgId,
|
||||
template_id: templateId,
|
||||
content: generatedContent,
|
||||
created_at: new Date()
|
||||
})
|
||||
|
||||
return generatedContent
|
||||
|
||||
} catch (error) {
|
||||
console.error('Error generating content:', error)
|
||||
throw error
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 6. Advanced Features
|
||||
|
||||
Consider adding:
|
||||
|
||||
**Dynamic prompt building**: Use more sophisticated template engines like Handlebars or Mustache for complex data insertion.
|
||||
|
||||
**Caching**: Store frequently used prompts and data to reduce database calls.
|
||||
|
||||
**Batch processing**: Process multiple organizations or content types simultaneously.
|
||||
|
||||
**Real-time updates**: Use Supabase's real-time features to trigger content generation when data changes.
|
||||
|
||||
**Error handling**: Implement robust error handling and retry logic for API calls.
|
||||
|
||||
## Example Usage
|
||||
|
||||
```javascript
|
||||
// Generate marketing copy for a specific organization
|
||||
const content = await createOrganizationContent(
|
||||
'org-uuid-123',
|
||||
'marketing-template-uuid-456'
|
||||
)
|
||||
|
||||
console.log(content)
|
||||
```
|
||||
|
||||
This architecture gives you flexibility to store various types of organizational data, create reusable prompt templates, and generate contextual content at scale. You can extend it by adding user authentication, content approval workflows, or integration with other services.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
# The ISMS in its context
|
||||
|
||||
The primary purpose of the ISMS is to Control information security risks, that may impede on the organization achieving its goals.
|
||||
|
||||
The ISMS does not exist in a vacuum. It interacts with the internal and external context of the organization. 
|
||||
|
||||
An effective ISMS relies on a relationship between / the interplay of organizational goals, its context, threats and risks to the CIA of information, and available resources.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
@mikepsecuritee @richardk @iso27diy @tugboatlogic @TrustVanta @DrataHQ @DrataHQ has an incredible product😎
|
||||
Tweet by @amanda_robs 22 nov 2021
|
||||
|
||||
@mikepsecuritee @richardk @iso27diy @tugboatlogic @TrustVanta @DrataHQ You might also want to check out @merkely_ 😇
|
||||
Tweet by @meekrosoft 23 nov 2021
|
||||
|
||||
|
||||
|
|
@ -1 +0,0 @@
|
|||
[Threat Modeling](../📚️%20Literature%20notes/Privacy%20Threat%20Modeling.md)
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
# Cracking passwords in 2024
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,220 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
- dev
|
||||
- llm
|
||||
- agent
|
||||
- LLMgenerated
|
||||
---
|
||||
|
||||
# Create a proactive conversational agent
|
||||
|
||||
|
||||
Prompt: ```I want to create a proactive conversational agent. It will read from a database, what information slots it needs to fill. It will engage in a conversation with the user. How can I create this using open source software```
|
||||
|
||||
|
||||
You can build a proactive conversational agent using several open-source components. Here's a comprehensive approach:
|
||||
|
||||
## Core Architecture
|
||||
|
||||
**Intent Recognition & NLU**
|
||||
|
||||
- **Rasa Open Source**: Excellent for intent classification, entity extraction, and dialogue management
|
||||
- **Snips NLU**: Lightweight alternative for natural language understanding
|
||||
- **SpaCy**: For custom NLP pipelines and named entity recognition
|
||||
|
||||
**Dialogue Management**
|
||||
|
||||
- **Rasa Core**: Handles conversation flow and context tracking
|
||||
- **Botpress**: Visual dialogue builder with good slot-filling capabilities
|
||||
- **DeepPavlov**: Russian-developed framework with strong conversational AI components
|
||||
|
||||
**Database Integration**
|
||||
|
||||
- **SQLAlchemy**: Python ORM for database operations
|
||||
- **Apache Airflow**: For orchestrating data pipelines and proactive triggers
|
||||
- **Redis**: For session management and temporary slot storage
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
**Slot Management System** Create a configuration-driven approach where your database stores:
|
||||
|
||||
- Required information slots for each conversation type
|
||||
- Validation rules for each slot
|
||||
- Follow-up questions for missing information
|
||||
- Priority ordering for slot collection
|
||||
|
||||
**Proactive Triggers**
|
||||
|
||||
- Use cron jobs or Apache Airflow to monitor your database
|
||||
- Implement webhook endpoints for real-time triggers
|
||||
- Set up event-driven architecture with message queues (Redis/RabbitMQ)
|
||||
|
||||
**Conversation Flow**
|
||||
|
||||
```
|
||||
Database Query → Missing Slots Identification →
|
||||
Conversation Initiation → Slot Filling → Validation →
|
||||
Database Update → Follow-up Actions
|
||||
```
|
||||
|
||||
|
||||
## Sample Workflow
|
||||
|
||||
1. Database trigger identifies incomplete user profiles
|
||||
2. Agent initiates conversation via preferred channel (SMS, email, chat)
|
||||
3. Uses Rasa to manage multi-turn dialogue for slot filling
|
||||
4. Validates collected information against business rules
|
||||
5. Updates database and triggers next actions
|
||||
|
||||
The key is designing your slot configuration schema to be flexible enough to handle different conversation types while maintaining a consistent dialogue management approach. Would you like me to elaborate on any specific component or provide code examples for particular aspects?
|
||||
|
||||
Prompt: `elaborate on designing the slot configuration schema`
|
||||
|
||||
Here's a detailed approach to designing a flexible slot configuration schema that can handle various conversation types and business requirements:
|
||||
|
||||
## Slot Configuration Database Schema
|
||||
|
||||
|
||||
|
||||
This ERD shows the complete database schema for the conversational agent's slot configuration system. Here's a breakdown of the key relationships and design decisions:
|
||||
|
||||
### Core Entity Relationships
|
||||
|
||||
**conversation_flows** serves as the root entity that defines different conversation types (onboarding, surveys, data collection, etc.)
|
||||
|
||||
**slot_definitions** contains the individual data points to collect within each flow, with support for:
|
||||
|
||||
- Priority-based ordering
|
||||
- Conditional dependencies between slots
|
||||
- Type validation (email, phone, date, etc.)
|
||||
|
||||
**slot_validations** allows multiple validation rules per slot with custom error messages
|
||||
|
||||
**slot_questions** enables context-aware question variations for better user experience
|
||||
|
||||
**conversation_sessions** tracks active conversations with users, storing collected data and session state
|
||||
|
||||
**slot_collection_attempts** provides detailed audit trail of user interactions for analytics and debugging
|
||||
|
||||
Let me show you a Python implementation that demonstrates how to work with this schema:
|
||||
|
||||
|
||||
### Key Design Features
|
||||
|
||||
- **Flexibility**: The JSONB fields allow for complex validation rules and context conditions without schema changes
|
||||
- **Scalability**: Session-based architecture supports pause/resume functionality and concurrent conversations
|
||||
- **Auditability**: Complete tracking of user inputs, validation attempts, and conversation flow
|
||||
- **Configuration-Driven**: Non-technical users can modify flows, questions, and validations through database updates
|
||||
|
||||
This schema supports sophisticated conversation flows while maintaining clean separation between configuration and runtime data.
|
||||
|
||||
### Required database population
|
||||
Vendor policy as an example
|
||||
|
||||
### Summary of Required Database Pre-Population
|
||||
|
||||
Before the ISO 27001 vendor management policy conversation can start, the following must be configured in the database:
|
||||
|
||||
#### 1. **Conversation Flow Definition**
|
||||
|
||||
- **Flow name**: `iso27001_vendor_management_policy`
|
||||
- **Description**: Clear purpose statement
|
||||
- **Active status**: Must be set to `true`
|
||||
|
||||
#### 2. **Slot Definitions** (20 information slots needed)
|
||||
|
||||
The system needs to know exactly what information to collect, organized in these categories:
|
||||
|
||||
**Company Basic Information (4 slots)**
|
||||
|
||||
- Company name, industry, size, geographic locations
|
||||
|
||||
**Regulatory Environment (3 slots)**
|
||||
|
||||
- Regulatory requirements, data protection laws, financial regulations
|
||||
|
||||
**Current Vendor Landscape (4 slots)**
|
||||
|
||||
- Critical vendor count, vendor types, cloud services usage, data processing vendors
|
||||
|
||||
**Risk Management Context (3 slots)**
|
||||
|
||||
- Risk appetite, business continuity requirements, data classification levels
|
||||
|
||||
**Organizational Structure (3 slots)**
|
||||
|
||||
- Procurement process owner, IT security team size, existing vendor governance
|
||||
|
||||
**Implementation Preferences (3 slots)**
|
||||
|
||||
- Policy approval authority, implementation timeline, budget constraints
|
||||
|
||||
#### 3. **Validation Rules**
|
||||
|
||||
Each slot must have appropriate validation:
|
||||
|
||||
- **Text fields**: Length limits, character restrictions
|
||||
- **Choice fields**: Predefined option lists
|
||||
- **Number fields**: Range validations
|
||||
- **Boolean fields**: Yes/no validation
|
||||
|
||||
#### 4. **Question Templates**
|
||||
|
||||
Multiple question types per slot:
|
||||
|
||||
- **Initial questions**: First attempt to gather information
|
||||
- **Clarification questions**: When more detail is needed
|
||||
- **Validation error questions**: When input is invalid
|
||||
- **Confirmation questions**: To verify collected information
|
||||
|
||||
#### 5. **Dependencies**
|
||||
|
||||
Some slots depend on others:
|
||||
|
||||
- Financial regulations questions only appear for financial services companies
|
||||
- Follow-up questions based on previous answers
|
||||
|
||||
### Key Design Considerations
|
||||
|
||||
**Priority Ordering**: Questions are asked in logical sequence (company basics → regulatory context → current state → implementation preferences)
|
||||
|
||||
**Conditional Logic**: Some questions only appear based on previous answers (e.g., financial regulations only for financial services companies)
|
||||
|
||||
**Professional Context**: Questions are phrased appropriately for a consultant-client relationship
|
||||
|
||||
**ISO 27001 Specific**: All information collected directly supports creating a compliant vendor management policy
|
||||
|
||||
This configuration enables the agent to conduct a structured, professional consultation that gathers all necessary information while maintaining the context of an ISO 27001 implementation project.
|
||||
## Key Design Principles
|
||||
|
||||
**1. Configuration-Driven Approach** The schema separates business logic from code by storing conversation flows, slot definitions, validations, and questions in the database. This allows non-technical users to modify conversation flows without code changes.
|
||||
|
||||
**2. Hierarchical Dependencies** Slots can depend on other slots with specific values, enabling complex conditional logic (e.g., only ask for phone number if user prefers phone contact).
|
||||
|
||||
**3. Flexible Validation System** Each slot can have multiple validation rules with custom error messages. The JSONB fields allow for complex validation parameters while maintaining type safety.
|
||||
|
||||
**4. Context-Aware Questions** Multiple question variants per slot allow for personalized conversation flows based on context or previous answers.
|
||||
|
||||
**5. Session Management** Robust session tracking allows for conversation pause/resume and handles multi-turn interactions gracefully.
|
||||
|
||||
## Advanced Features You Can Add
|
||||
|
||||
**Multi-Language Support**: Add language_code to question tables
|
||||
**A/B Testing**: Version your flows and track performance
|
||||
**Dynamic Prioritization**: Adjust slot priority based on user behavior
|
||||
**Integration Points**: Add webhook configurations for external system integration
|
||||
**Conversation Analytics**: Track completion rates, drop-off points, and user satisfaction
|
||||
|
||||
This schema provides a solid foundation that can scale from simple forms to complex multi-step conversations with conditional logic and personalization.
|
||||
|
||||
## Technical Stack Recommendation
|
||||
|
||||
**Backend Framework**: FastAPI or Flask for API endpoints
|
||||
**NLU Engine**: Rasa Open Source for robust dialogue management
|
||||
**Database**: PostgreSQL with SQLAlchemy ORM
|
||||
**Message Queue**: Redis for real-time processing
|
||||
**Frontend**: React/Vue.js for any admin interfaces
|
||||
|
||||
https://mica-labs.github.io
|
||||
https://github.com/Mica-labs/MICA/tree/main
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- llm
|
||||
---
|
||||
|
||||
|
||||
[Source](https://www.linkedin.com/posts/mbundgaard_cyber-threat-landscape-analysis-activity-7274406690442149888-Pf-X), retrieved 20-12-24
|
||||
|
||||
Create your own cyber threat analysis GenAI chatbot in 30 minutes.
|
||||
Free of cost and code.
|
||||
|
||||
1) Don't waste your time manually collecting every report from different websites behind forms. Go to [Jacob Wilson](https://www.linkedin.com/in/jacobdjwilson/)'s [github repo](https://github.com/jacobdjwilson/awesome-annual-security-reports/tree/main/) that's updated with all relevant and current reports.
|
||||
2) Don't waste time reading through 20-40 reports that are almost identical. Instead, upload them to [notebooklm.google.com](http://notebooklm.google.com/) and let AI do the heavy lifting.
|
||||
3) Remember to upload/link to your infosec taxonomy. I recommend [VERISframework.org](https://verisframework.org) as it is used by Cyentia Institute and Verizon.
|
||||
4) Don't use any old GPT. Prompt your notebook to get actual references and prevent hallucinations.
|
||||
5) Don't return to the same sources with annotation and manual review. Instead, write and adjust prompts to your specific purposes.
|
||||
|
||||
You now have your very own reliable cyber threat chat bot to help your analyze any problem.
|
||||
|
||||
**Prompt suggestion:**
|
||||
`Context: Doing an annual analysis of the threat landscape surrounding a specific enterprise.`
|
||||
|
||||
`The enterprise is a [region][industry][services] company. It has around [number] employees and annual revenue of [your annual revenue].`
|
||||
|
||||
`Please provide a two-part analysis:`
|
||||
|
||||
1. `A summary of the relevant industry research. The summary must adhere to the [taxonomy] framework. Each section must include examples from the source material and/or statistics such as forecasting or historical changes.`
|
||||
2. `A list of the 5-10 most relevant threat scenarios to be included in a subsequent risk assessment. Provide the scenarios in a table format. The table must include the following columns [column 1], [column 2], [column 3] [etc] and strictly adhere to [taxonomy).`
|
||||
|
||||
For columns I suggest Threat actor, activity and attribute.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
- dev
|
||||
- llm
|
||||
- agent
|
||||
---
|
||||
# Create an interview agent
|
||||
|
||||
We need to create a conversational agent that proactively drives the dialogue, also called a 'mixed-initiative' or 'proactive' conversational agent.
|
||||
|
||||
We need to design prompts/instructions that encourage initiative. Here's an example prompt:
|
||||
```
|
||||
You are a proactive assistant. Start the conversation by greeting the user and asking them about their needs. If their response is unclear, ask follow-up questions to clarify. Guide them step by step through the process, making suggestions and confirming understanding at each stage.
|
||||
```
|
||||
|
||||
|
||||
Implement dialogue management (manage conversation state):
|
||||
|
||||
- In a **stateless** setup, your application manages the conversation history and sends it with each request.
|
||||
- In a **stateful** setup, the platform manages context, and you only send new messages.
|
||||
- For advanced initiative, consider reinforcement learning or preference optimization techniques (such as Action-Based Contrastive Self-Training) to train the model to recognize ambiguity and take action to clarify or drive the conversation forward.
|
||||
|
||||
Incorporate prompts and follow-ups:
|
||||
|
||||
- Use follow-up prompts and context tracking to manage multi-turn flows, refining the conversation at each step and ensuring the bot leads the user toward a goal.
|
||||
|
||||
Use LLMs with strong context retention and multi-turn support.
|
||||
|
||||
Recommended Chat Models:
|
||||
- Qwen: Frequently praised by users for its conversational quality and reliability in chat-based applications. It is considered a strong choice for structured interviews due to its ability to maintain context and handle follow-up questions effectively.
|
||||
- Meta Llama (Llama 3 and variants): Popular for general-purpose chat and conversational AI tasks. Llama models are known for their robust performance and can be fine-tuned or prompted to follow structured interview formats.
|
||||
- Cohere Command R: Cohere’s latest conversational model, optimized for dialogue and tool use, is highlighted for its 2024 update and is suitable for building structured, interactive interview agents.
|
||||
- Mistral (Dolphin and others): Noted by some users as a reliable alternative for chat applications, offering strong conversational abilities and context retention.
|
||||
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[](Cyber%20Security%20Governance%20Principles.pdf) by the Australian Institute of Company Directors and the Cyber Security Cooperative Research Centre, november 2024
|
||||
|
||||
The document outlines five key principles for governing organizational cyber resilience:
|
||||
|
||||
1. Set clear roles and responsibilities.
|
||||
2. Develop, implement, and evolve a comprehensive cyber strategy.
|
||||
3. Embed cyber security in existing risk management practices.
|
||||
4. Promote a culture of cyber resilience.
|
||||
5. Plan for a significant cyber security incident.
|
||||
|
||||
For each principle the document outlines key points and identifies 'red flags' that indicate low quality or non existent governance.
|
||||
|
||||
File diff suppressed because one or more lines are too long
|
|
@ -1,3 +0,0 @@
|
|||
Needed because of the importance, under GDPR, of the reason and the lawful ground the data was originally collected for.
|
||||
|
||||
Related: [AVG Rechtsgronden voor verwerking](AVG%20Rechtsgronden%20voor%20verwerking.md)
|
||||
|
|
@ -1,125 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- iso27DIY
|
||||
- stack
|
||||
- WeWeb
|
||||
- SupaBase
|
||||
- dev
|
||||
- design
|
||||
---
|
||||
# Deciding which functionality goes where
|
||||
|
||||
Here’s a decision framework to help you choose the right approach for each piece of functionality:
|
||||
|
||||
## WeWeb (Frontend Logic)
|
||||
|
||||
**Use when:**
|
||||
|
||||
- UI/UX logic and interactions
|
||||
- Client-side data formatting and presentation
|
||||
- Form validation (basic, user-facing)
|
||||
- Navigation and routing logic
|
||||
- Real-time UI updates from Supabase subscriptions
|
||||
- Simple calculations that don’t need to be secured
|
||||
|
||||
**Examples:** Date formatting, sorting/filtering displays, form field validation, conditional UI rendering
|
||||
|
||||
## SQL Functions + RPC
|
||||
|
||||
**Use when:**
|
||||
|
||||
- Complex data operations involving multiple tables
|
||||
- Business logic that must be consistent and secure
|
||||
- Performance-critical operations (closer to data)
|
||||
- Data validation that can’t be bypassed
|
||||
- Calculations that need to be atomic
|
||||
- Logic that might be reused across different clients
|
||||
|
||||
**Examples:** User permission checks, complex reporting calculations, multi-step data updates, financial calculations
|
||||
|
||||
## Edge Functions
|
||||
|
||||
**Use when:**
|
||||
|
||||
- External API integrations (payments, email, webhooks)
|
||||
- Heavy computational tasks
|
||||
- File processing and transformations
|
||||
- Custom authentication flows
|
||||
- Business logic that needs full programming language capabilities
|
||||
- Third-party service communications
|
||||
|
||||
**Examples:** Stripe payment processing, PDF generation, image resizing, sending emails, complex AI/ML operations
|
||||
|
||||
## Database Triggers
|
||||
|
||||
**Use when:**
|
||||
|
||||
- Automatic responses to data changes
|
||||
- Audit logging and history tracking
|
||||
- Data consistency enforcement
|
||||
- Background maintenance tasks
|
||||
- Cross-table updates that must happen atomically
|
||||
|
||||
**Examples:** Updating timestamps, creating audit logs, maintaining calculated fields, sending notifications on data changes
|
||||
|
||||
## Decision Matrix
|
||||
|
||||
**Performance Priority:**
|
||||
|
||||
- SQL Functions > Database Triggers > Edge Functions > WeWeb
|
||||
|
||||
**Security Requirements:**
|
||||
|
||||
- Database Triggers ≥ SQL Functions > Edge Functions > WeWeb
|
||||
|
||||
**External Integration Needs:**
|
||||
|
||||
- Edge Functions > WeWeb > SQL Functions > Database Triggers
|
||||
|
||||
**Complexity of Logic:**
|
||||
|
||||
- Edge Functions > SQL Functions > WeWeb > Database Triggers
|
||||
|
||||
**Real-time Requirements:**
|
||||
|
||||
- Database Triggers > SQL Functions > WeWeb > Edge Functions
|
||||
|
||||
## Practical Examples
|
||||
|
||||
**User Registration Flow:**
|
||||
|
||||
- WeWeb: Form UI and basic validation
|
||||
- Edge Function: Email verification, external service calls
|
||||
- SQL Function: Create user profile with complex business rules
|
||||
- Database Trigger: Create related records, audit log
|
||||
|
||||
**E-commerce Order Processing:**
|
||||
|
||||
- WeWeb: Shopping cart UI, order summary
|
||||
- SQL Function: Inventory checks, price calculations
|
||||
- Database Trigger: Update inventory, create audit trail
|
||||
- Edge Function: Payment processing, order confirmation emails
|
||||
|
||||
**Reporting Dashboard:**
|
||||
|
||||
- WeWeb: Charts, filters, display logic
|
||||
- SQL Function: Complex data aggregations
|
||||
- Database Trigger: Update materialized views
|
||||
- Edge Function: Export to PDF, email reports
|
||||
|
||||
## General Guidelines
|
||||
|
||||
**Start with the data layer and work outward:**
|
||||
|
||||
1. Database Triggers for automatic data consistency
|
||||
2. SQL Functions for secure business logic
|
||||
3. Edge Functions for external integrations
|
||||
4. WeWeb for user interface and experience
|
||||
|
||||
**Security rule:** Never trust the client - critical business logic should be in SQL Functions or Edge Functions, not WeWeb.
|
||||
|
||||
**Performance rule:** Keep data-heavy operations close to the database (SQL Functions/Triggers).
|
||||
|
||||
**Maintainability rule:** Keep similar logic in the same layer when possible.
|
||||
|
||||
The key is often using multiple approaches together rather than choosing just one - they complement each other in a well-architected application.
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
|
||||
|
||||
|
||||
“An asset is anything within an environment that should be protected. It is anything used in a business process or task. It can be a computer file, a network service, a system resource, a process, a program, a product, an IT infrastructure, a database, a hardware device, furniture, product recipes/ formulas, intellectual property, personnel, software, facilities, and so on.
|
||||
|
||||
If an organization places any value on an item under its control and deems that item important enough to protect, it is labeled an asset for the purposes of risk management and analysis. The loss or disclosure of an asset could result in an overall security compromise, loss of productivity, reduction in profits, additional expenditures, discontinuation of the organization, and numerous intangible consequences.”
|
||||
|
||||
— (ISC)2 CISSP Certified Information Systems Security Professional Official Study Guide by Mike Chapple, James Michael Stewart, et al.
|
||||
https://amzn.eu/6EvlQju, P.64
|
||||
|
||||
|
|
@ -1,203 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
---
|
||||
As suggested by Perplexity AI on June 23, 2025 on the following prompt:
|
||||
|
||||
```markdown
|
||||
Below is a list of challenges for a small company to acquire ISO 27001 certification. Write a design document for an online service that will support this company on it's journey towards certification:
|
||||
|
||||
**Prioritize and Simplify Documentation**
|
||||
- Focus on essential documents such as the Information Security Policy, Risk Treatment Plan, and Statement of Applicability. Use templates and streamline processes to reduce the documentation burden.
|
||||
|
||||
**Leverage External Expertise**
|
||||
- Consider hiring an ISO 27001 consultant or using online tools and platforms designed for small businesses to guide you through the process and provide templates and checklists.
|
||||
|
||||
**Automate Where Possible**
|
||||
- Use software solutions that automate risk assessments, documentation management, and compliance tracking. This can save time and reduce errors.
|
||||
|
||||
**Conduct Regular Self-Assessments**
|
||||
- Schedule periodic reviews of your ISMS to ensure it remains effective and up to date. Treat these as mini-audits, checking against the standard’s requirements.
|
||||
|
||||
**Stay Informed and Trained**
|
||||
- Invest in self-training through online courses, webinars, and resources specific to ISO 27001. This will help you understand the standard and stay current with best practices.
|
||||
|
||||
**Collaborate with Peers or Networks**
|
||||
- Join professional networks or forums where you can share experiences, ask questions, and learn from others facing similar challenges.
|
||||
|
||||
**Use Open Source and Cost-Effective Tools**
|
||||
- Implement open-source or affordable security tools to manage risks and controls within your budget constraints
|
||||
```
|
||||
|
||||
# Design Document: ISO 27001 Certification Support Online Service
|
||||
|
||||
|
||||
## 1. Overview
|
||||
|
||||
This design document outlines an online service tailored for small companies aiming to achieve ISO 27001 certification. The service addresses common challenges such as documentation overload, lack of expertise, limited resources, and the need for ongoing compliance, as identified in the provided list. The solution emphasizes simplicity, automation, collaboration, and cost-effectiveness.
|
||||
|
||||
---
|
||||
|
||||
## 2. Objectives
|
||||
|
||||
- **Simplify and prioritize ISO 27001 documentation**
|
||||
- **Provide expert guidance and resources**
|
||||
- **Automate compliance and documentation workflows**
|
||||
- **Enable regular self-assessment and progress tracking**
|
||||
- **Offer training and knowledge resources**
|
||||
- **Foster peer collaboration**
|
||||
- **Integrate open-source and affordable security tools**
|
||||
|
||||
---
|
||||
|
||||
## 3. Key Features
|
||||
|
||||
### 3.1. Documentation Hub
|
||||
|
||||
- **Template Library:**
|
||||
Pre-built, customizable templates for essential documents (e.g., Information Security Policy, Risk Treatment Plan, Statement of Applicability).
|
||||
- **Guided Documentation Wizard:**
|
||||
Step-by-step forms that guide users through filling out each document, with tooltips and examples.
|
||||
- **Version Control:**
|
||||
Track changes, revisions, and approvals for each document.
|
||||
|
||||
### 3.2. Expert Guidance
|
||||
|
||||
- **Consultant Marketplace:**
|
||||
Access to vetted ISO 27001 consultants for one-off advice or ongoing support.
|
||||
- **Automated Checklists:**
|
||||
Interactive checklists for each stage of the certification process.
|
||||
- **Knowledge Base:**
|
||||
Frequently asked questions, best practices, and troubleshooting guides.
|
||||
|
||||
### 3.3. Automation Tools
|
||||
|
||||
- **Risk Assessment Engine:**
|
||||
Automate risk identification, evaluation, and treatment planning, with pre-populated risk scenarios for small businesses.
|
||||
- **Compliance Tracker:**
|
||||
Dashboard for tracking progress against ISO 27001 controls and requirements.
|
||||
- **Automated Reminders:**
|
||||
Notifications for upcoming reviews, policy renewals, and self-assessments.
|
||||
|
||||
### 3.4. Self-Assessment Module
|
||||
|
||||
- **Mini-Audit Toolkit:**
|
||||
Self-assessment forms based on ISO 27001 requirements, with scoring and action item generation.
|
||||
- **Progress Reports:**
|
||||
Visual dashboards and downloadable reports to monitor readiness for certification.
|
||||
|
||||
### 3.5. Training & Resources
|
||||
|
||||
- **E-Learning Platform:**
|
||||
ISO 27001-specific courses, webinars, and microlearning modules for staff.
|
||||
- **Resource Library:**
|
||||
Curated articles, videos, and external links for ongoing learning.
|
||||
|
||||
### 3.6. Collaboration & Community
|
||||
|
||||
- **Peer Forum:**
|
||||
Secure discussion boards for sharing experiences, challenges, and solutions.
|
||||
- **Group Projects:**
|
||||
Enable teams to collaborate on documentation and risk assessments in real time.
|
||||
- **Mentorship Matching:**
|
||||
Pair users with experienced peers or mentors for guidance.
|
||||
|
||||
### 3.7. Integration with Open Source and Cost-Effective Tools
|
||||
|
||||
- **Tool Directory:**
|
||||
Curated list of recommended open-source and affordable security tools (e.g., password managers, vulnerability scanners).
|
||||
- **API Integrations:**
|
||||
Connect external tools for asset management, incident tracking, and more.
|
||||
|
||||
---
|
||||
|
||||
## 4. User Roles
|
||||
|
||||
- **Admin:**
|
||||
Full access to all features, user management, and settings.
|
||||
- **Team Member:**
|
||||
Access to assigned tasks, documentation, and training.
|
||||
- **Consultant/Advisor:**
|
||||
Limited access for reviewing documents and providing feedback.
|
||||
|
||||
---
|
||||
|
||||
## 5. User Journey Example
|
||||
|
||||
1. **Onboarding:**
|
||||
User answers a few questions about company size, industry, and current security maturity.
|
||||
2. **Documentation Setup:**
|
||||
User selects required documents from the template library and customizes them using the wizard.
|
||||
3. **Risk Assessment:**
|
||||
User completes an automated risk assessment, generating a risk treatment plan.
|
||||
4. **Self-Assessment:**
|
||||
User runs a mini-audit using the self-assessment toolkit and receives a readiness score.
|
||||
5. **Training:**
|
||||
Staff complete relevant e-learning modules.
|
||||
6. **Collaboration:**
|
||||
User joins the forum to ask questions and shares progress in a group project.
|
||||
7. **Expert Review:**
|
||||
User books a session with a consultant to review documentation.
|
||||
8. **Certification Prep:**
|
||||
User tracks progress with the compliance dashboard and prepares for the external audit.
|
||||
|
||||
---
|
||||
|
||||
## 6. Technical Architecture
|
||||
|
||||
- **Frontend:**
|
||||
Responsive web application (React or Angular)
|
||||
- **Backend:**
|
||||
RESTful API (Node.js/Python), secure document storage, user management
|
||||
- **Database:**
|
||||
PostgreSQL or MongoDB for user data, documents, and audit logs
|
||||
- **Integrations:**
|
||||
APIs for external tools and consultant scheduling
|
||||
- **Security:**
|
||||
End-to-end encryption, role-based access control, regular penetration testing
|
||||
|
||||
---
|
||||
|
||||
## 7. Security & Compliance
|
||||
|
||||
- **GDPR-compliant data handling**
|
||||
- **Encrypted storage for sensitive documents**
|
||||
- **Audit logs for all user actions**
|
||||
- **Regular vulnerability assessments**
|
||||
|
||||
---
|
||||
|
||||
## 8. Cost & Licensing
|
||||
|
||||
- **Freemium Model:**
|
||||
Basic features free for small teams; premium features (consultant marketplace, advanced automation) via subscription.
|
||||
- **Open-Source Integrations:**
|
||||
No additional cost for integrating community tools.
|
||||
|
||||
---
|
||||
|
||||
## 9. Success Metrics
|
||||
|
||||
- **Time to complete documentation**
|
||||
- **User satisfaction (NPS)**
|
||||
- **Number of companies achieving certification**
|
||||
- **Engagement in training and community features**
|
||||
|
||||
---
|
||||
|
||||
## 10. Roadmap (First 12 Months)
|
||||
|
||||
1. **MVP Launch:**
|
||||
Documentation hub, risk assessment engine, self-assessment module
|
||||
2. **Phase 2:**
|
||||
Training platform, community forum, consultant marketplace
|
||||
3. **Phase 3:**
|
||||
Advanced automation, open-source tool integrations, mentorship matching
|
||||
|
||||
---
|
||||
|
||||
## 11. Conclusion
|
||||
|
||||
This online service is designed to make ISO 27001 certification accessible, efficient, and affordable for small companies. By combining expert guidance, automation, collaboration, and cost-effective tools, it empowers organizations to achieve and maintain compliance with confidence.
|
||||
|
||||
Sources
|
||||
|
|
@ -1,186 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
- dev
|
||||
- design
|
||||
---
|
||||
|
||||
https://gemini.google.com/app/431233af439fce00
|
||||
|
||||
That's an excellent approach! Designing and planning before coding is crucial for the success of any software product. It helps to clarify requirements, anticipate challenges, and create a solid foundation, ultimately saving time and resources during development and maintenance.
|
||||
|
||||
To help you with this, let's break down the key steps and considerations for designing and planning your software product.
|
||||
|
||||
Here's a comprehensive guide:
|
||||
|
||||
---
|
||||
|
||||
## **Phase 1: Discovery & Research (Understanding the "What" and "Why")**
|
||||
|
||||
This initial phase is about thoroughly understanding the problem you're solving, the audience you're serving, and the context of your product.
|
||||
|
||||
1. **Define the Core Problem/Opportunity:**
|
||||
|
||||
- What specific problem does your software aim to solve?
|
||||
- What opportunity does it address?
|
||||
- Is this a real, pressing problem for your target users?
|
||||
- _Deliverable:_ A clear, concise problem statement.
|
||||
2. **Identify Your Target Audience/Users:**
|
||||
|
||||
- Who will be using your software?
|
||||
- What are their demographics, behaviors, needs, and pain points related to the problem?
|
||||
- Create user personas to represent different segments of your audience.
|
||||
- _Deliverable:_ User personas, user stories (initial draft).
|
||||
3. **Market Research & Competitive Analysis:**
|
||||
|
||||
- Are there existing solutions? What are their strengths and weaknesses?
|
||||
- What makes your solution unique or better? (Unique Selling Proposition - USP)
|
||||
- What is the market size and potential?
|
||||
- Identify direct and indirect competitors.
|
||||
- _Deliverable:_ Competitive analysis report, SWOT analysis.
|
||||
4. **Define Product Vision & Goals:**
|
||||
|
||||
- What is the long-term vision for your product?
|
||||
- What are the high-level goals and objectives? (e.g., increase efficiency by X%, reduce costs by Y%, improve user satisfaction)
|
||||
- How will you measure success? (Key Performance Indicators - KPIs)
|
||||
- _Deliverable:_ Product vision statement, high-level product goals and KPIs.
|
||||
|
||||
---
|
||||
|
||||
## **Phase 2: Requirements Gathering & Specification (Defining the "How")**
|
||||
|
||||
Now that you understand the "why," it's time to define "what" your software will do in detail.
|
||||
|
||||
1. **Functional Requirements:**
|
||||
|
||||
- What specific features and functionalities must the software have?
|
||||
- Describe how the system should behave under specific conditions.
|
||||
- Use cases and user stories are excellent tools here.
|
||||
- **User Stories:** "As a [type of user], I want to [perform an action] so that [I can achieve a goal]."
|
||||
- **Use Cases:** More detailed descriptions of interactions between users and the system.
|
||||
- _Deliverable:_ Detailed list of functional requirements, user stories, use case diagrams/descriptions.
|
||||
2. **Non-Functional Requirements:**
|
||||
|
||||
- These define the quality attributes of the system.
|
||||
- **Performance:** How fast should it be? (e.g., response times, throughput)
|
||||
- **Scalability:** Can it handle increased load?
|
||||
- **Security:** How will data be protected? (e.g., authentication, authorization, encryption)
|
||||
- **Reliability:** How often can it fail? How quickly can it recover?
|
||||
- **Usability:** How easy is it to learn and use?
|
||||
- **Maintainability:** How easy is it to modify and update?
|
||||
- **Compatibility:** What platforms/devices will it support?
|
||||
- _Deliverable:_ Detailed non-functional requirements specification.
|
||||
3. **Data Requirements:**
|
||||
|
||||
- What data will the system store, process, and display?
|
||||
- What are the relationships between different pieces of data?
|
||||
- _Deliverable:_ Data dictionary, entity-relationship diagrams (ERDs - for databases).
|
||||
|
||||
---
|
||||
|
||||
## **Phase 3: Design & Prototyping (Visualizing the Solution)**
|
||||
|
||||
This is where you start translating requirements into a tangible design.
|
||||
|
||||
1. **Information Architecture (IA):**
|
||||
|
||||
- How will information be organized within the software?
|
||||
- Create sitemaps or flowcharts to illustrate the structure and navigation.
|
||||
- _Deliverable:_ Sitemap, user flow diagrams.
|
||||
2. **User Experience (UX) Design:**
|
||||
|
||||
- Focus on how users interact with the product and their overall experience.
|
||||
- **Wireframes:** Low-fidelity, black-and-white layouts to define the basic structure and placement of elements on a page/screen.
|
||||
- **Prototypes:** Interactive (clickable) versions of wireframes or mockups to simulate user flow and test usability.
|
||||
- _Deliverable:_ Wireframes, interactive prototypes.
|
||||
3. **User Interface (UI) Design:**
|
||||
|
||||
- Focus on the visual aesthetics and interactivity of the product.
|
||||
- **Mockups:** High-fidelity, static designs that include colors, typography, images, and visual styling.
|
||||
- **Design System/Style Guide:** Define consistent UI elements, colors, fonts, and guidelines for future development.
|
||||
- _Deliverable:_ Mockups, UI style guide/design system.
|
||||
4. **System Architecture Design:**
|
||||
|
||||
- How will the different components of the software interact?
|
||||
- Choose the appropriate technology stack (programming languages, frameworks, databases, cloud services).
|
||||
- Define the overall structure (e.g., monolithic, microservices, client-server).
|
||||
- Consider scalability, security, and performance implications.
|
||||
- _Deliverable:_ Architecture diagrams (component diagram, deployment diagram), technology stack definition.
|
||||
5. **Database Design (if applicable):**
|
||||
|
||||
- Design the database schema based on your data requirements.
|
||||
- Define tables, fields, relationships, and data types.
|
||||
- _Deliverable:_ Database schema design, ERDs.
|
||||
|
||||
---
|
||||
|
||||
## **Phase 4: Planning & Estimation (Structuring the Development)**
|
||||
|
||||
Now you have a clear picture of what to build; it's time to plan how to build it.
|
||||
|
||||
1. **Development Methodology:**
|
||||
|
||||
- Choose a suitable methodology (e.g., Agile Scrum, Kanban, Waterfall). Agile is often preferred for its flexibility and iterative approach.
|
||||
- _Deliverable:_ Chosen development methodology and rationale.
|
||||
2. **Roadmap & Release Planning:**
|
||||
|
||||
- Outline the high-level plan for product development over time.
|
||||
- Define major releases and their scope.
|
||||
- _Deliverable:_ Product roadmap, release plan.
|
||||
3. **Feature Prioritization:**
|
||||
|
||||
- Not all features are equally important. Prioritize based on user value, business impact, and effort.
|
||||
- Techniques: MoSCoW (Must-have, Should-have, Could-have, Won't-have), Value vs. Effort matrix.
|
||||
- _Deliverable:_ Prioritized feature backlog.
|
||||
4. **Effort Estimation:**
|
||||
|
||||
- Estimate the time and resources required for each feature or development task.
|
||||
- Break down larger tasks into smaller, manageable units.
|
||||
- _Deliverable:_ Effort estimations (e.g., story points in Agile, person-hours), project timeline.
|
||||
5. **Resource Planning:**
|
||||
|
||||
- Identify the team members needed (developers, designers, QA, project manager).
|
||||
- Define roles and responsibilities.
|
||||
- _Deliverable:_ Team structure, roles and responsibilities matrix.
|
||||
6. **Risk Management:**
|
||||
|
||||
- Identify potential risks (technical, market, operational).
|
||||
- Develop mitigation strategies.
|
||||
- _Deliverable:_ Risk register.
|
||||
7. **Testing Strategy:**
|
||||
|
||||
- How will you ensure the quality of the software?
|
||||
- Define types of testing (unit, integration, system, user acceptance testing - UAT).
|
||||
- _Deliverable:_ Test plan.
|
||||
|
||||
---
|
||||
|
||||
## **Key Tools and Techniques to Consider:**
|
||||
|
||||
- **For Requirements & Documentation:** Confluence, Jira, Google Docs, Notion, Microsoft Word
|
||||
- **For User Stories/Use Cases:** Jira, Trello, Asana, Azure DevOps, VersionOne
|
||||
- **For Wireframing & Prototyping:** Figma, Adobe XD, Sketch, Balsamiq, InVision
|
||||
- **For UI Design:** Figma, Adobe XD, Sketch, Photoshop, Illustrator
|
||||
- **For Architecture Diagrams:** draw.io, Lucidchart, Miro, Enterprise Architect
|
||||
- **For Project Management:** Jira, Trello, Asana, Monday.com, Microsoft Project
|
||||
- **For Collaboration:** Slack, Microsoft Teams, Zoom
|
||||
|
||||
---
|
||||
|
||||
## **Before You Start Coding - A Checklist:**
|
||||
|
||||
- [ ] Have you clearly defined the problem you're solving?
|
||||
- [ ] Do you understand your target users well?
|
||||
- [ ] Is your product vision and high-level goals documented?
|
||||
- [ ] Are your functional and non-functional requirements well-defined and prioritized?
|
||||
- [ ] Do you have a clear understanding of the information architecture and user flows?
|
||||
- [ ] Are your UI/UX designs (wireframes, mockups) approved and ready?
|
||||
- [ ] Is your system architecture designed, and has the technology stack been chosen?
|
||||
- [ ] Do you have a development methodology and project plan in place?
|
||||
- [ ] Have you estimated the effort and resources required?
|
||||
- [ ] Have you considered potential risks and mitigation strategies?
|
||||
- [ ] Is your testing strategy outlined?
|
||||
|
||||
---
|
||||
|
||||
By diligently working through these phases, you'll build a strong foundation for your software product, minimize rework, and increase the likelihood of delivering a successful and impactful solution. Good luck!
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
|
||||
CLAUDE DID THIS
|
||||
|
||||
Creating an onboarding agent that takes the lead requires shifting from a reactive assistant model to a proactive interviewer model. Here’s how to approach this:
|
||||
|
||||
**Core Design Principles:**
|
||||
|
||||
Start with a clear script structure where the agent drives the conversation forward. The agent should have predetermined pathways and questions, but with enough flexibility to adapt based on responses. Think of it like a skilled consultant or intake specialist who knows exactly what information they need to gather.
|
||||
|
||||
**Conversation Flow Architecture:**
|
||||
|
||||
Design your agent with a hierarchical question structure. Begin with broad, open-ended questions to understand the customer’s general situation, then progressively narrow down to specific details. For example, start with “Tell me about your current challenges with [your service area]” before diving into technical requirements or budget constraints.
|
||||
|
||||
Build in natural transition phrases that maintain conversational flow while keeping control: “That’s helpful context. Now I’d like to understand…” or “Based on what you’ve shared, my next question is…”
|
||||
|
||||
**Information Gathering Strategy:**
|
||||
|
||||
Map out all the critical information you need for successful onboarding and organize it into logical themes. Create primary questions for each theme, with follow-up questions ready based on different response types. This prevents the agent from getting stuck or losing direction.
|
||||
|
||||
Consider using a mix of question types - open-ended for understanding context and motivations, specific for gathering facts, and clarifying questions to ensure accurate understanding.
|
||||
|
||||
**Maintaining Control While Being Conversational:**
|
||||
|
||||
Program the agent to acknowledge customer responses appropriately, then smoothly redirect to the next needed information. Use phrases like “I understand that’s important to you. Let me ask about…” This validates their input while maintaining the interview structure.
|
||||
|
||||
Build in gentle persistence for critical information. If a customer deflects or gives incomplete answers, the agent should know how to circle back professionally.
|
||||
|
||||
**Technical Implementation Considerations:**
|
||||
|
||||
Create clear state management so the agent knows what information has been gathered and what’s still needed. This allows for natural conversation flow while ensuring nothing is missed.
|
||||
|
||||
Design fallback responses for when customers ask questions or try to take control of the conversation. The agent can briefly address their concern, then guide back to the interview process.
|
||||
|
||||
Would you like me to elaborate on any of these aspects, or do you have specific questions about implementing this approach for your particular service?
|
||||
|
||||
## Resources for learning this design approach
|
||||
|
||||
https://www.cloudskillsboost.google/course_templates/892
|
||||
|
||||
https://academy.cognigy.com/courses/conversation-design-course
|
||||
https://academy.cognigy.com/collections
|
||||
|
||||
https://www.udemy.com/course/design-conversational-ai-experience/
|
||||
|
||||
|
||||
[https://www.perplexity.ai/search/93f1aea8-7da1-48ce-94a8-5874628fe103](https://www.perplexity.ai/search/93f1aea8-7da1-48ce-94a8-5874628fe103)
|
||||
|
||||
|
||||
|
||||
[https://rosenfeldmedia.com/books/conversations-with-things/](https://rosenfeldmedia.com/books/conversations-with-things/)
|
||||
|
|
@ -1,69 +0,0 @@
|
|||
# Detailed comparison between 2017 and 2022
|
||||
|
||||
According to [Mark Bernard](https://www.linkedin.com/posts/markesbernard_the-changes-to-isoiec-27001-isms-are-not-activity-7344467878198329344-nZN7) , 28 juni 2025, "The changes to ISO/IEC 27001 ISMS are not straightforward. Some believe that the total number of controls was reduced; however, the truth is that new controls were added while existing controls were consolidated and streamlined."
|
||||
|
||||
|
||||
|
||||
|
||||
## New ISMS Control Objectives - ISO 27001:2022 CLAUSE 4 TO 10
|
||||
|
||||
| Line # | Clause | Title |
|
||||
| ------ | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 1 | 4.2(c) | Which of these requirements will be addressed through the information security management system |
|
||||
| 2 | 6.1.2(e)2 | Prioritize analysed risks for risk treatment |
|
||||
| 3 | 6.2(d) | Be monitored |
|
||||
| 4 | 6.2(g) | Be available as documented information |
|
||||
| 5 | 6.3 | When the organization determines the need for changes to the information security management system, the changes shall be carried out in a planned manner |
|
||||
| 6 | 9.3.2(c) | Changes in needs and expectations of interested parties that are relevant to the information security management system |
|
||||
|
||||
## Deleted ISMS Control Objectives - ISO 27001:2022 CLAUSE 4 TO 10
|
||||
|
||||
| Line # | Clause | Title |
|
||||
| ------ | ------ | ------------------------------------------------------ |
|
||||
| 1 | 7.4(c) | The processes by which communication shall be affected |
|
||||
|
||||
## New Annex A Control Objectives - ISO 27001:2022
|
||||
|
||||
| Line # | Clause | Title |
|
||||
| ------ | ------ | ---------------------------------------------- |
|
||||
| 1 | 5.7 | Threat intelligence |
|
||||
| 2 | 5.23 | Information security for use of cloud services |
|
||||
| 3 | 5.30 | ICT readiness for business continuity |
|
||||
| 4 | 7.4 | Physical security monitoring |
|
||||
| 5 | 8.9 | Configuration management |
|
||||
| 6 | 8.10 | Information deletion |
|
||||
| 7 | 8.11 | Data masking |
|
||||
| 8 | 8.12 | Data leakage prevention |
|
||||
| 9 | 8.16 | Monitoring activities |
|
||||
| 10 | 8.23 | Web filtering |
|
||||
| 11 | 8.28 | Secure coding |
|
||||
|
||||
## Consolidated Annex A Control Objectives - ISO 27001:2022
|
||||
|
||||
| Line # | New Clause | Old | Redundant | Title |
|
||||
| ------ | ---------- | ------ | ---------------------- | ---------------------------------------------------------------------- |
|
||||
| 1 | 5.1 | 5.1.1 | 5.1.2 | Policies for information security |
|
||||
| 2 | 5.8 | 6.1.5 | 14.1.1 | Information security in project management |
|
||||
| 3 | 5.9 | 8.1.1 | 8.1.2 | Inventory of information and other associated assets |
|
||||
| 4 | 5.10 | 8.1.3 | 8.2.3 | Acceptable use of information and other associated assets |
|
||||
| 5 | 5.14 | 13.2.1 | 13.2.2, 13.2.3 | Information transfer |
|
||||
| 6 | 5.15 | 9.1.1 | 9.1.2 | Access control |
|
||||
| 7 | 5.17 | 9.2.4 | 9.3.1, 9.4.3 | Authentication information |
|
||||
| 8 | 5.18 | 9.2.2 | 9.2.5, 9.2.6 | Access rights |
|
||||
| 9 | 5.22 | 15.2.1 | 15.2.2 | Monitoring, review and change management of supplier services |
|
||||
| 10 | 5.29 | 17.1.1 | 17.121, 17.1.3 | Information security during disruption |
|
||||
| 11 | 5.31 | 18.1.1 | 18.1.5 | Legal, statutory, regulatory and contractual requirements |
|
||||
| 12 | 5.36 | 18.2.2 | 18.2.3 | Compliance with policies, rules and standards for information security |
|
||||
| 13 | 6.8 | 16.1.2 | 16.1.3 | Information security event reporting |
|
||||
| 14 | 7.2 | 11.1.2 | 11.1.6 | Physical entry |
|
||||
| 15 | 7.10 | 8.3.1 | 8.3.2, 8.3.3, 11.2.5 | Storage media |
|
||||
| 16 | 8.1 | 6.2.1 | 11.2.8 | User endpoint devices |
|
||||
| 17 | 8.8 | 12.6.1 | 18.2.3 | Management of technical vulnerabilities |
|
||||
| 18 | 8.15 | 12.4.1 | 12.4.2, 12.4.3 | Logging |
|
||||
| 19 | 8.19 | 12.5.1 | 12.6.2 | Installation of software on operational systems |
|
||||
| 20 | 8.24 | 10.1.1 | 10.1.2 | Use of cryptography |
|
||||
| 21 | 8.25 | 14.1.2 | 14.1.3 | Application security requirements |
|
||||
| 22 | 8.29 | 14.2.8 | 14.2.9 | Security testing in development and acceptance |
|
||||
| 23 | 8.31 | 12.1.4 | 14.2.6 | Seporation of development, test and production environments |
|
||||
| 24 | 8.32 | 12.1.2 | 14.2.2, 14.2.3, 14.2.4 | Change management |
|
||||
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
ISO 27001 seems to have a sort of outdated linear view of building and testing.
|
||||
How do the controls fit in with DevSecOps?
|
||||
|
||||
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)
|
||||
[Red, Blue, and Purple Teams](../Literature%20notes/Red,%20Blue,%20and%20Purple%20Teams.md)
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
See also:
|
||||
- [a-5.30-ICT-readiness-for-business-continuity](../Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md)
|
||||
- [Business Continuity Planning (BCP)](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
|
||||
- [SANS Incident Response step 5 Recovery](../Standards/SANS/SANS%20Incident%20Response%20step%205%20Recovery.md)
|
||||
- [Checklist for auditing Business Continuity and Disaster Recovery](../Literature%20notes/Checklists%20Gerardus%20Blokdyk/Checklist%20for%20auditing%20Business%20Continuity%20and%20Disaster%20Recovery.md)
|
||||
- [CISSP_OSG_Chapter_18](../Standards/CISSP/CISSP_OSG_Chapter_18.md)
|
||||
- [Def_Sec_Handbook_Chapter_6](../Literature%20notes/Def_Sec_Handbook_Chapter_6.md)
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
## Elevator pitch
|
||||
ISO27DIY is a method to implement information security management, and become ISO 27001 compliant, without the need for external consultants or expensive software.
|
||||
The ISO27DIY workshop series is freely available on YouTube, dramatically lowering the barrier for certification for small and medium enterprises to become ISO 27001 certified.
|
||||
Additional resources and support are available on the iso27diy.com website.
|
||||
|
||||
### Key value proposition
|
||||
|
||||
* A method for implementing ISO 27001 in your own organization
|
||||
* Workshop videos freely available on YouTube
|
||||
* No need for external consultants or expensive software
|
||||
|
||||
|
||||
See also [ISO27DIY benefits](ISO27DIY%20benefits.md)
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
```
|
||||
{
|
||||
"firstName": "Jane",
|
||||
"lastName": "Doe",
|
||||
"age": 30,
|
||||
"isStudent": false,
|
||||
"hobbies": ["reading", "hiking", "cooking"],
|
||||
"address": {
|
||||
"street": "123 Main St",
|
||||
"city": "Anytown",
|
||||
"zipCode": "90210"
|
||||
},
|
||||
"contactNumbers": [
|
||||
{"type": "home", "number": "555-1234"},
|
||||
{"type": "work", "number": "555-5678"}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
# Example of ISO 27001 mystique
|
||||
|
||||
ISO 27001 is a framework, and you cannot successfully implement it by treating the text of the standard as a series of instructions to be followed in the order in which they were printed. If you try that, things will become very confusing very quickly.
|
||||
|
||||
For example, the requirement of having an information security policy is first (?) mentioned in [Chapter 5.1](../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md), "Leadership and commitment", where it says that top management must have it established, *together* with information security objectives. Then in [Chapter 5.2](../Standards/ISO27x/OST/27001/EN/c-5.2-Policy.md), 'Policy', it states that these objectives form *part of* the information security policy, referencing forward to [Chapter 6.2](../MoCs/ISO_27001_2022_6.2_MoC%20Information%20security%20objectives%20and%20planning%20to%20achieve%20them.md), "Information security objectives and planning to achieve them", which demands that organizations should set objectives consistent with the policy. Of course there's also a corresponding Control called "Policies for information security" ([5.1](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md)), which explains that there will be an information security policy at the highest level of the organization, including objectives "or the framework for setting objectives", and further "topic-specific policies as needed", which of course need their own objectives.
|
||||
|
||||
Programmers may love this kind of recursiveness when it's in coding exercises.
|
||||
|
||||
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
---
|
||||
|
||||
|
||||
|
||||
- [ISO_27002_2022_5.10_PE Acceptable use of information and other associated assets](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.10_PE%20Acceptable%20use%20of%20information%20and%20other%20associated%20assets.md)
|
||||
- [ISO_27002_2022_5.13_PE Labelling of information](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.13_PE%20Labelling%20of%20information.md)
|
||||
- [ISO_27002_2022_5.32_PE Intellectual property rights](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.32_PE%20Intellectual%20property%20rights.md)
|
||||
- [ISO_27002_2022_5.7_PE Threat intelligence](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.7_PE%20Threat%20intelligence.md)
|
||||
- [ISO_27002_2022_5.22_PE Monitoring, review and change management of supplier services](../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.22_PE%20Monitoring%2C%20review%20and%20change%20management%20of%20supplier%20services.md)
|
||||
- [ISO_27002_2022_5.1_PE Policies for information security](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.1_PE%20Policies%20for%20information%20security.md)
|
||||
- [ISO_27002_2022_5.20_PE Addressing information security within supplier agreements](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.20_PE%20Addressing%20information%20security%20within%20supplier%20agreements.md)
|
||||
- [ISO_27002_2022_5.23_PE Information security for use of cloud services](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.23_PE%20Information%20security%20for%20use%20of%20cloud%20services.md)
|
||||
- [ISO_27002_2022_5.19_PE Information security in supplier relationships](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.19_PE%20Information%20security%20in%20supplier%20relationships.md)
|
||||
- [ISO_27002_2022_5.8_PE Information security in project management](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.8_PE%20Information%20security%20in%20project%20management.md)
|
||||
- [ISO_27002_2022_5.12_PE Classification of information](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.12_PE%20Classification%20of%20information.md)
|
||||
- [ISO_27002_2022_5.24_PE Information security incident management planning and preparation](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.24_PE%20Information%20security%20incident%20management%20planning%20and%20preparation.md)
|
||||
- [ISO_27002_2022_5.27_PE Learning from information security incidents](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.27_PE%20Learning%20from%20information%20security%20incidents.md)
|
||||
- [ISO_27002_2022_5.21_PE Managing information security in the ICT supply chain](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.21_PE%20Managing%20information%20security%20in%20the%20ICT%20supply%20chain.md)
|
||||
- [ISO_27002_2022_5.2_PE Information security roles and responsibilities](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.2_PE%20Information%20security%20roles%20and%20responsibilities.md)
|
||||
- [ISO_27002_2022_8.28_PE Secure coding](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_8.28_PE%20Secure%20coding.md)
|
||||
- [ISO_27002_2022_5.3_PE Segregation of duties](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.3_PE%20Segregation%20of%20duties.md)
|
||||
- [ISO_27002_2022_8.9_PE Configuration management](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_8.9_PE%20Configuration%20management.md)
|
||||
- [ISO_27002_2022_8.26_PE Application security requirements](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_8.26_PE%20Application%20security%20requirements.md)
|
||||
- [ISO 27x Control PE template](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/📒%20Templates/ISO%2027x%20Control%20PE%20template.md)
|
||||
-
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
- [Dropbox](../Literature%20notes/Dropbox%20Supplier%20Security%20Requirements.md)
|
||||
- [Google](https://vsaq-demo.withgoogle.com)
|
||||
|
||||
Related:
|
||||
- [Vendor security MoC](Vendor%20security%20MoC.md)
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
Auditors verschillen
|
||||
Wat de een genoeg vindt, vindt de ander onvoldoende.
|
||||
Maar: je moet het erg bont maken om je certificering te verliezen. Je krijgt de kans te verbeteren/herstellen.
|
||||
|
||||
En cynisch: je kiest je CI zelf, en een CI zal liever niet bekend willen staan als de CI met de laagste succes ratio.
|
||||
Binary file not shown.
|
|
@ -1,16 +0,0 @@
|
|||
This note relates to the [ISO27DIY Business model](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO27DIY%20Business%20model.md)
|
||||
|
||||
Probleem: de GRC software wordt aangekocht om een operationeel probleem van de compliance officer op te lossen.
|
||||
|
||||
De software komt meestal pas later (en wordt pas gevuld als de kennis van wat ISO is en van het proces er al is, als het jargon al is ingesleten)
|
||||
|
||||
Eerst komt de consultant uitleggen hoe ISO werkt en wordt hulp geboden bij Wat je Waar moet documenteren, en Hoe (denk aan de risico-identificatie en de stakeholder-analyse: wat is een in-scope risico, hoe verwoordt je het precies. Wat is een stakeholder, wat is zijn in-scope belang, etc.).
|
||||
Dan ontstaat de documentatie, meestal in Excel en Word documenten.
|
||||
Dan de realisering dat het onhandig is en niet schaalt.
|
||||
Dan wordt software geselecteerd en geïmplementeerd.
|
||||
Pas dan wordt de software daadwerkelijk gebruikt, en meestal door een deskundige staffunctionaris.
|
||||
|
||||
Inmiddels staat het dan zover af van de dagelijkse praktijk op de werkvloer, dat de heilige graal van security by design en in de haarvaten van de organisatie, niet gehaald kan worden.
|
||||
Voor iedere (interne) audit is extra effort nodig om te graven in de operationele documentatie om de audit documentatie naar boven te krijgen.
|
||||
|
||||
Wat nu als je de documentatie kun genereren op het moment dat relevante feiten (identificatie en weging van risico’s, keuze van maatregelen, bewaken van de implementatie, monitoren van de resultaten en bijsturen) plaatsvinden? Door ze voorafgaand aan een SCRUM, Team- of afdelingsoverleg of ontwerpmeeting te agenderen, en ze in de notulen te ‘marken’? Door operationele reports en logs te koppelen naar de ISO-administratie?
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
[Cyber Security Governance Principles](Cyber%20Security%20Governance%20Principles.md)
|
||||
[Data Governance](../📚️%20Literature%20notes/Data%20Governance.md)
|
||||
[Checklist for auditing Data Governance](../Literature%20notes/Checklists%20Gerardus%20Blokdyk/Checklist%20for%20auditing%20Data%20Governance.md)
|
||||
|
|
@ -1,4 +1,6 @@
|
|||
[Create a threat analysis chatbot](Create%20a%20threat%20analysis%20chatbot.md)
|
||||
# Using AI for Threat Modeling
|
||||
|
||||
[Create a threat analysis chatbot](../../Various/Create%20a%20threat%20analysis%20chatbot.md)
|
||||
|
||||
|
||||
[PLOT4AI](https://plot4.ai) (Privacy Library Of Threats 4 Artificial Intelligence): A threat modeling library to help you build responsible AI
|
||||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
# About the connection between threat intelligence, analysis and modeling
|
||||
|
||||
### 🔄 Interplay Overview
|
||||
|
|
@ -1,8 +1,4 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
- type/explainer
|
||||
---
|
||||
# About implementation and proof
|
||||
|
||||
The auditor will require proof of the implementation of the ISMS and all it’s individual controls. Proper implementation means a control is risk-based, there’s a policy describing the why and how of it’s implementation, it’s results are monitored or measured, it’s effectiveness is evaluated, and possible improvements to the implementation of the control are identified.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,4 @@
|
|||
---
|
||||
tags:
|
||||
- iso27001
|
||||
- policy
|
||||
- control
|
||||
- risk
|
||||
---
|
||||
|
||||
# About policies, controls, and risks
|
||||
|
||||
`Within a ISO 27001 compliant ISMS, is it possible to implement a control without having a policy for that control?`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,4 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
- type/explainer
|
||||
---
|
||||
## About the Statement of Applicability
|
||||
# About the Statement of Applicability
|
||||
|
||||
In essence, the Statement of Applicability shows the outcome of the risk treatment process ([6.1.3a](../../Corpus/Standards/MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md)). It is usually presented as a table of Annex A controls, together with a short explanation for the selection *or* exclusion of each, and its implementation status.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
See also:
|
||||
- [Authorization vs Access Control](Authorization%20vs%20Access%20Control.md)
|
||||
- [Identity and Access Management (IAM)](Identity%20and%20Access%20Management%20(IAM).md)
|
||||
- [RBAC Access levels](../Literature%20notes/RBAC%20Access%20levels.md)
|
||||
- [CRUD Matrices](CRUD%20Matrices.md)
|
||||
- [Identity and Access Management (IAM)](../Identity%20and%20Access%20Management%20(IAM).md)
|
||||
- [RBAC Access levels](../../Literature%20notes/RBAC%20Access%20levels.md)
|
||||
- [CRUD Matrices](../Information%20Security/CRUD%20Matrices.md)
|
||||
|
||||
|
||||
Source: [](../Attachments/Certified%20Ethical%20Hacker%20Exam%20Guide%202021.pdf)
|
||||
Source: [](../../Attachments/Certified%20Ethical%20Hacker%20Exam%20Guide%202021.pdf)
|
||||
|
||||
- Mandatory Access Control (MAC):
|
||||
- Every object gets a label
|
||||
13
Corpus/Sparks/ISMS/Access Control.md
Normal file
13
Corpus/Sparks/ISMS/Access Control.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
# Access Control
|
||||
|
||||
While [authorization](../../Standards/ISO27x/Authorization.md) is primarily concerned with establishing the policies and rules that dictate access (i.e. *what* a person or system is allowed to do), **access control** is the _system_ or _process_ that enforces those defined permissions.
|
||||
|
||||
See:
|
||||
- [Gedachten over rechtenstructuren](../Information%20Security/Gedachten%20over%20rechtenstructuren.md)
|
||||
- [Authorization vs Access Control](Authorization%20vs%20Access%20Control.md)
|
||||
- [Access Control Models](Access%20Control%20Models.md)
|
||||
- [ISO 27001 A 9 Access control](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%209%20Access%20control.md)
|
||||
- [a-5.15-Access-control](../../Standards/ISO27x/OST/27002/EN/a-5.15-Access-control.md)
|
||||
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 96 KiB After Width: | Height: | Size: 96 KiB |
104
Corpus/Sparks/ISMS/Assets Ownership and Risk Overview.md
Normal file
104
Corpus/Sparks/ISMS/Assets Ownership and Risk Overview.md
Normal file
|
|
@ -0,0 +1,104 @@
|
|||
# Assets, Ownership, and Risk: Structured Overview
|
||||
|
||||
## 1. Core Concept: What Is an Asset?
|
||||
|
||||
An **information asset** is anything that has value to an organization. It can take many forms:
|
||||
|
||||
- Printed or electronic documents
|
||||
- Intellectual property and proprietary knowledge
|
||||
- Personal data
|
||||
- Knowledge of processes
|
||||
- Physical items
|
||||
- Information systems that process, store, or transmit information
|
||||
|
||||
**Selected definitions:**
|
||||
|
||||
| Source | Definition |
|
||||
| ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| ISO/IEC 27000:2018 | Anything that has value to an organization (e.g. printed documents, electronic documents, intellectual property, personal data, knowledge of processes, physical items). |
|
||||
| NIST SP 800-53 | Information and the information systems that process, store, and transmit that information. |
|
||||
| DAMA-DMBOK | A resource of value that an organization uses to understand, operate, and innovate. |
|
||||
| Gartner IT Glossary | A collection of information that is defined and managed as a standalone entity and is considered of value. |
|
||||
| (ISC)² CISSP Official Study Guide (Chapple, Stewart et al., p.64) | Anything within an environment that should be protected — anything used in a business process or task. If an organization places any value on an item and deems it important enough to protect, it is labeled an asset for purposes of risk management and analysis. |
|
||||
|
||||
**Examples of assets (CISSP):** computer files, network services, system resources, processes, programs, products, IT infrastructure, databases, hardware devices, furniture, product recipes/formulas, intellectual property, personnel, software, facilities.
|
||||
|
||||
**Consequences of asset loss or disclosure:**
|
||||
- Overall security compromise
|
||||
- Loss of productivity
|
||||
- Reduction in profits
|
||||
- Additional expenditures
|
||||
- Discontinuation of the organization
|
||||
- Numerous intangible consequences
|
||||
|
||||
|
||||
## 2. Assets in Relation to Vulnerabilities, Threats, and Risks
|
||||
|
||||
The relationship between the four concepts can be summarized as:
|
||||
|
||||
> A threat exploits an exposed vulnerability to damage an asset, which results in a risk to the organization.
|
||||
|
||||
This relationship is known as the **Operations Security Triple** (assets, vulnerabilities, threats).
|
||||
|
||||
**On risk materialization:**
|
||||
A risk can be seen as a theoretical threat scenario. When a risk "materializes," an anticipated or potential threat has actually taken place — exploiting a vulnerability, affecting an asset, and resulting in actual harm or loss.
|
||||
|
||||
|
||||
## 3. Asset Ownership
|
||||
|
||||
### ISO 27001 Requirements
|
||||
|
||||
ISO 27001 explicitly requires asset ownership in two controls:
|
||||
|
||||
- **A.8.1.2** — Every asset should have an owner.
|
||||
- **A.9.2.5** — Asset owners must periodically evaluate access rights.
|
||||
|
||||
### Determining Ownership: The RUMC Model
|
||||
|
||||
*The following model was shared by Remco Landegge, Security Expert Radboud UMC (2 December 2024). Remove all references to Radboudumc before reusing.*
|
||||
|
||||
When asset or process ownership is unclear, it can be determined by mapping the situation to one of four scenarios:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Situation 1 (B1): Asset/process used within a single organizational unit**
|
||||
|
||||
The head or director of that organizational unit is the owner **(E1)**.
|
||||
|
||||
*Note: for institutes, this applies only to assets/processes needed within their own unit — not to those required for the complete core task.*
|
||||
|
||||
|
||||
**Situation 2 (B2): Asset/process used across multiple departments, or a department and a centre**
|
||||
|
||||
The director of the core task in which the asset/process is used is the owner **(E2)**. The owner operates independently and in a facilitating role, to ensure all stakeholders (across departments and/or centres) are involved in decisions about functionality, security, and service levels.
|
||||
|
||||
|
||||
**Situation 3 (B3): Asset/process used across multiple institutes**
|
||||
|
||||
The directors of the institutes involved jointly determine who the owner is **(E3)**. The owner operates independently and in a facilitating role to ensure stakeholder involvement across institutes.
|
||||
|
||||
|
||||
**Situation 4 (B4): Asset/process spanning (virtually) all parts of the organization, with no owner claimed**
|
||||
|
||||
First, determine whether the asset/process is actually needed. The three institute directors and directors of supporting services jointly decide **(E4)**. If no consensus is reached, the Board of Directors appoints an owner **(E4)**.
|
||||
|
||||
---
|
||||
|
||||
## Notes on Linked Content
|
||||
|
||||
The source files reference the following related notes in the vault:
|
||||
|
||||
- [Vulnerability 1](../Vulnerability%201.md)
|
||||
- [Threat](../../Literature%20notes/Threat.md)
|
||||
- [Risks](../Risks.md)
|
||||
- [Risk ownership](../Risk%20ownership.md)
|
||||
- [Control ownership](Control%20ownership.md)
|
||||
- [Asset lifecycle](../../Literature%20notes/Asset%20lifecycle.md)
|
||||
- [How to develop an Asset Inventory](../How%20to%20develop%20an%20Asset%20Inventory.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -6,7 +6,7 @@ tags:
|
|||
|
||||
# Authorization vs. Access Control
|
||||
|
||||
[Authorization](../Standards/ISO27x/Authorization.md) defines _what_ a user (or system) is allowed to do, [access control ](Access%20Control.md) is the _system_ or _process_ that enforces those defined permissions.
|
||||
[Authorization](../../Standards/ISO27x/Authorization.md) defines _what_ a user (or system) is allowed to do, [access control ](Access%20Control.md) is the _system_ or _process_ that enforces those defined permissions.
|
||||
|
||||
## Authorization
|
||||
|
||||
|
|
@ -23,8 +23,8 @@ tags:
|
|||
- **What it is:** Access control is the **mechanism or system that enforces the authorization policies**. It's the technical implementation that actually grants or denies access to a resource based on the authorized permissions.
|
||||
- **The "How":** It answers the question, "How is the 'what' actually applied and managed?"
|
||||
- **Enforcement:** Access control is the act of putting those policies into practice. It involves:
|
||||
- Checking a user's identity ([Authentication](../Standards/ISO27x/Authentication.md)).
|
||||
- Consulting the pre-defined [Authorization](../Standards/ISO27x/Authorization.md)authorization rules.
|
||||
- Checking a user's identity ([Authentication](../../Standards/ISO27x/Authentication.md)).
|
||||
- Consulting the pre-defined [Authorization](../../Standards/ISO27x/Authorization.md)authorization rules.
|
||||
- Granting or denying access to specific resources (files, applications, data, network segments, physical locations, etc.) or actions (read, write, delete, execute).
|
||||
- **Examples:**
|
||||
- An Access Control List (ACL) on a file system that specifies which users or groups can read, write, or execute a particular file.
|
||||
24
Corpus/Sparks/ISMS/Business Impact Analysis (BIA).md
Normal file
24
Corpus/Sparks/ISMS/Business Impact Analysis (BIA).md
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
# Business Impact Analysis (BIA)
|
||||
|
||||
Business Impact Analysis (BIA) is an activity within the proces of Business Continuity Planning ([BCP](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)).
|
||||
|
||||
The goal of a Business Impact Analysis (BIA) process is
|
||||
|
||||
A Business Impact Analysis (BIA) examines the potential impacts of disruptions, such as financial losses, reputational damage, regulatory penalties, and operational continuity.
|
||||
The outcomes help to prioritize business activities and resources to enable the resumption of product and service delivery after a (major) disruption[^1].
|
||||
|
||||
Guidelines and tooling:
|
||||
- [Guidelines for business impact analysis ISO 22317](../../Standards/ISO27x/ISO%2022317%20Guidelines%20for%20business%20impact%20analysis.md)
|
||||
- [Assessing reputational risks](../../Various/Assessing%20reputational%20risks.md)
|
||||
- [BIA Workshop](../../Standards/ISO27x/Implementation%20Products/BIA%20Workshop.md)
|
||||
- [TLP impact matrix](../../Literature%20notes/Traffic%20Light%20Protocol%20TLP.md)
|
||||
- Afhankelijkheid tussen systemen/voorzieningen?
|
||||
- Resource Breakdown Structure (RBS)
|
||||
- Fishbone Diagram (Ishikawa/Cause and Effect): Useful for identifying root causes of dependencies and resource constraints in processes.
|
||||
|
||||
ISO 27001 Controls:
|
||||
- [5.29:](../../MoCs/ISO_27002_2022_5.29_MoC%20Information%20security%20during%20disruption.md) Information security during disruption
|
||||
- [5.30:](../../MoCs/ISO_27002_2022_5.30_MoC%20ICT%20readiness%20for%20business%20continuity.md) ICT readiness for business continuity
|
||||
- [5.9:](../../MoCs/ISO_27002_2022_5.9_MoC%20Inventory%20of%20information%20and%20other%20associated%20assets.md) Inventory of information and other associated assets – regarding assets marked Critical on the Availability aspect
|
||||
|
||||
[^1]: See [Disaster Recovery Planning](Disaster%20Recovery%20Planning.md)
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Classificatie op basis van risico-oorzaken
|
||||
# Classificatie van risico's
|
||||
|
||||
Risico's kunnen worden ingedeeld in diverse categorieën, die elk een andere bron van gevaar vertegenwoordigen:
|
||||
|
||||
|
|
@ -1,17 +1,8 @@
|
|||
---
|
||||
title: Classifying Integrity
|
||||
source: https://www.perplexity.ai/search/351dee5b-0f9f-419b-bec2-381b6e285401
|
||||
author:
|
||||
- "[[Perplexity AI]]"
|
||||
published:
|
||||
created: 2025-06-10
|
||||
description: What instruments do we have to classify the necessity of integrity of information?
|
||||
tags:
|
||||
- clippings
|
||||
---
|
||||
See also: [Business Impact Analysis (BIA)](Business%20Impact%20Analysis%20(BIA).md), [A 8.2 Information Classification](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2%20Information%20classification.md#ISO%2027001%20A%208.2%20Information%20classification)
|
||||
# Classifying Integrity
|
||||
|
||||
Prompt: `In the field of information security, we identify and implement risk mitigating measures to safeguard the confidentiality, integrity, and availability of information. To establish levels of confidentiality, we use the instrument of data classification to establish levels of availability we can use business impact analysis. What instruments do we have to classify the necessity of integrity of information`
|
||||
See also: [Business Impact Analysis (BIA)](Business%20Impact%20Analysis%20(BIA).md), [A 8.2 Information Classification](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2%20Information%20classification.md#ISO%2027001%20A%208.2%20Information%20classification)
|
||||
|
||||
Prompt to Perplexity AI on 2025-06-10: `In the field of information security, we identify and implement risk mitigating measures to safeguard the confidentiality, integrity, and availability of information. To establish levels of confidentiality, we use the instrument of data classification to establish levels of availability we can use business impact analysis. What instruments do we have to classify the necessity of integrity of information`
|
||||
|
||||
Sources:
|
||||
[dataguard](https://www.dataguard.com/blog/classifying-information/)
|
||||
|
|
@ -1,4 +1,6 @@
|
|||
See also [Risk ownership](Risk%20ownership.md), [Asset ownership](Asset%20ownership.md)
|
||||
# Control ownership
|
||||
|
||||
See also [Risk ownership](../Risk%20ownership.md), [Asset ownership](Asset%20ownership.md)
|
||||
|
||||
Principe:
|
||||
> Control ownership can best be assigned to the individual or team that has both the resources and the skills to effectively implement the control. (And does not have conflicting interests)
|
||||
|
|
@ -1,3 +1,5 @@
|
|||
# Data breach procedure
|
||||
|
||||
Previous work:
|
||||
- Post mortem Ultimaker LinkedIn Learning incident
|
||||
- Pixelpool Data breach procedure
|
||||
|
|
@ -5,4 +7,4 @@ Previous work:
|
|||
|
||||
|
||||
Relevant ISO 27001 clauses/controls:
|
||||
- [ISO 27001 A 16.1 Management of information security incidents and improvements](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2016.1%20Management%20of%20information%20security%20incidents%20and%20improvements.md)
|
||||
- [ISO 27001 A 16.1 Management of information security incidents and improvements](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2016.1%20Management%20of%20information%20security%20incidents%20and%20improvements.md)
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
# Data Classification
|
||||
|
||||
**Definition:**
|
||||
"A *data classification* identifies the value of the data to the organization. Classification labels, the method by which they are assigned, and the required protection associated with the different labels, are identified in a policy."
|
||||
Source: [CISSP_OSG_Chapter_5](../../../Standards/CISSP/CISSP_OSG_Chapter_5.md#Defining%20data%20Classifications)
|
||||
|
||||
Classification criteria should be risk based, for instance on potential damage to the organization, the privacy of individuals, national security, economic interests, or other critical concerns.
|
||||
|
||||
## Examples from SANS forum
|
||||
|
||||
Source: https://sth-community.sans.org/t/y4yt81n
|
||||
Retrieved: 2 september 2024
|
||||
|
||||
|
|
@ -9,10 +19,10 @@ Confidential
|
|||
2. Some risk - Internal
|
||||
3. Significant risk - Confidential
|
||||
|
||||
1. Unrestricted
|
||||
2. Restricted-External
|
||||
3. Restricted-Internal
|
||||
4. Confidential
|
||||
4. Unrestricted
|
||||
5. Restricted-External
|
||||
6. Restricted-Internal
|
||||
7. Confidential
|
||||
|
||||
- Public
|
||||
- Internal
|
||||
|
|
@ -35,8 +45,20 @@ Just before I left the Bank of England, we rebuilt our classification scheme -
|
|||
One of the reasons for the move was that the UK government was looking to change their scheme to a traffic light system also, so we moved to where they were heading.
|
||||
|
||||
|
||||
|
||||
From a user perspective it is complex to figure out a classification. That's why some of our institutions reverse the process and start with the person and what they want to do.
|
||||
Leiden University has a tool picker that is publicly available, to help employees and students pick the correct tool (and indirectly the level of security and privacy that that tool offers).
|
||||
It does not solve the classification labeling problem if you have a single mandatory system in mind, but I can imagine that asking them about what goal they want to achieve makes it easier for employees to see classification as helpful and useful.
|
||||
[https://web.universiteitleiden.nl/assets/toolpicker/?lang=en](https://web.universiteitleiden.nl/assets/toolpicker/?lang=en)
|
||||
[https://web.universiteitleiden.nl/assets/toolpicker/?lang=en](https://web.universiteitleiden.nl/assets/toolpicker/?lang=en)
|
||||
|
||||
|
||||
|
||||
|
||||
See also:
|
||||
[Datatags System](../../../Literature%20notes/Datatags%20System.md)
|
||||
[Def_Sec_Handbook_Chapter_2](../../../Literature%20notes/Def_Sec_Handbook_Chapter_2.md#Information%20classification)
|
||||
[ISO 27002:2022 NL A5.12](../../../Standards/ISO27x/OST/27002/NL/a-5.12-Classificeren-van-informatie.md)
|
||||
[Designing an information management scheme](../../../Literature%20notes/Designing%20an%20information%20management%20scheme.md)
|
||||
[Key Topics for a policy on handling classified information](../../Key%20Topics%20for%20a%20policy%20on%20handling%20classified%20information.md)
|
||||
[Traffic Light Protocol (TLP)](../../../Literature%20notes/Traffic%20Light%20Protocol%20TLP.md)
|
||||
|
||||
|
||||
9
Corpus/Sparks/ISMS/Disaster Recovery Planning.md
Normal file
9
Corpus/Sparks/ISMS/Disaster Recovery Planning.md
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
# Disaster Recovery Planning
|
||||
|
||||
See also:
|
||||
- [a-5.30-ICT-readiness-for-business-continuity](../../Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md)
|
||||
- [Business Continuity Planning (BCP)](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
|
||||
- [SANS Incident Response step 5 Recovery](../../Standards/SANS/SANS%20Incident%20Response%20step%205%20Recovery.md)
|
||||
- [Checklist for auditing Business Continuity and Disaster Recovery](../../Literature%20notes/Checklists%20Gerardus%20Blokdyk/Checklist%20for%20auditing%20Business%20Continuity%20and%20Disaster%20Recovery.md)
|
||||
- [CISSP_OSG_Chapter_18](../../Standards/CISSP/CISSP_OSG_Chapter_18.md)
|
||||
- [Def_Sec_Handbook_Chapter_6](../../Literature%20notes/Def_Sec_Handbook_Chapter_6.md)
|
||||
3
Corpus/Sparks/Incident Response playbooks.md
Normal file
3
Corpus/Sparks/Incident Response playbooks.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
# Incident Response playbooks
|
||||
|
||||
[Repository](https://github.com/certsocietegenerale/IRM/tree/main) of Incident Response playbooks by CERT Societe Generale
|
||||
|
|
@ -1,6 +1,8 @@
|
|||
# CIS Critical Security Controls
|
||||
|
||||
https://www.cisecurity.org/controls
|
||||
|
||||
Cyber attacks exploit bad cuyber hygiene
|
||||
Cyber attacks exploit bad cyber hygiene
|
||||
CIS are security best practices for strengthening your security posture to defend agains top threats
|
||||
|
||||
maps to lots of frameworks
|
||||
|
|
@ -8,7 +10,7 @@ maps to lots of frameworks
|
|||
Safeguards are identified by attack patterns from the MITRE ATT&CK* framework
|
||||
we verified that the CIS Controls are effective at defending against 86% of the ATT&CK (sub-)techniques found in the ATT&CK framework. More importantly, the Controls are highly effective against the top five attack types found in industry threat data.
|
||||
|
||||
|
||||
|
||||
Source: CIS Community Defense Model version 2.0
|
||||
|
||||
|
||||
|
|
@ -29,10 +31,10 @@ IG3 assets contain sensitive information or functions that are subject to regula
|
|||
Safeguards selected for IG3 must abate targeted attacks from a sophisticated adversary and reduce the impact of zero-day attacks.
|
||||
|
||||
|
||||
|
||||
|
||||
Source: CIS Controls v8.1 PDF, pp 8-12
|
||||
|
||||
|
||||
|
||||
List of the CIS Controls in v8, and how many Safeguards in each are applicable to each Implementation Group. [source](https://www.cisecurity.org/controls/implementation-groups)
|
||||
|
||||
See CIS_Controls_Version_8.1_6_24_2024.xlsx for a table that shows all safeguards mapped to the three Implementation Groups.
|
||||
|
|
@ -1,8 +1,4 @@
|
|||
---
|
||||
tags:
|
||||
- infosec
|
||||
- type/explainer
|
||||
---
|
||||
# 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.
|
||||
|
||||
|
|
@ -33,7 +29,7 @@ In the form below, we can see which authorizations each role has for different o
|
|||
| Sales Rep | CRUD | R | RU | R | R |
|
||||
| Stock Manager | - | - | - | R | RU |
|
||||
|
||||
A CRUD matrix is a helpful tool for [Access Control Models](Access%20Control%20Models.md), and several well-known CRUD extensions have been introduced to address specific needs, for example:
|
||||
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.
|
||||
|
|
@ -1,7 +1,5 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
---
|
||||
# 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)
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
# Cracking passwords in 2024
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,10 +1,12 @@
|
|||
# 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)
|
||||
# Customer Managed Keys
|
||||
- [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.
|
||||
|
||||
|
|
@ -1,4 +1,5 @@
|
|||
# Data maturity model NL overheid
|
||||
|
||||
Een data maturity model helpt Nederlandse overheidsorganisaties bij het beoordelen, verbeteren en volwassen maken van hun datamanagementpraktijken. Het model dient als een raamwerk om de huidige status van een organisatie op het gebied van data te beoordelen en verbeterplannen te identificeren.
|
||||
|
||||
### Elaboratie:
|
||||
|
|
@ -1,3 +1,4 @@
|
|||
# Dealing with a reported application vulnerability
|
||||
# Context
|
||||
A vulnerability in a widely used open source library is published.
|
||||
|
||||
|
|
@ -32,16 +33,16 @@ Do an impact analyses and identify a treatment:
|
|||
|
||||
|
||||
## 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.
|
||||
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)
|
||||
- [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 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
|
||||
- [ISO 27001 A 18 Compliance](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md) of systems
|
||||
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