0TD02S_Informasjonssikkerhet_K11 - itnett/FTD02H-N GitHub Wiki
Kapittel 11: Innebygd Informasjonssikkerhet
Introduksjon
Innebygd informasjonssikkerhet handler om å integrere sikkerhetstiltak og beste praksis i alle faser av systemutvikling og drift. Dette kapittelet dekker de grunnleggende prinsippene for innebygd informasjonssikkerhet, risikoanalyse, og hvordan man implementerer effektive sikkerhetstiltak.
Læringsmål
- Forstå prinsippene for innebygd informasjonssikkerhet.
- Lære å gjennomføre risikoanalyse for datasystemer.
- Implementere sikkerhetstiltak basert på identifisert risiko.
Ressurser og Verktøy
- Python: Brukes for å utvikle applikasjoner for risikoanalyse og implementering av sikkerhetstiltak.
- Diagrammer og Visualiseringer: For å illustrere systemstrukturer og sikkerhetstiltak.
- Lenker til GDPR og andre relevante lover: GDPR full text
Oppbygning av Leksjonen
-
Introduksjon til Innebygd Informasjonssikkerhet
- Definisjon og betydning.
- Prinsipper for innebygd sikkerhet.
- Hvorfor det er kritisk for moderne IT-systemer.
-
Risikoanalyse
- Identifisering av risiko.
- Vurdering av sannsynlighet og konsekvens.
- Verktøy og metoder for risikoanalyse.
-
Implementering av Sikkerhetstiltak
- Tekniske tiltak: kryptering, autentisering, logging.
- Organisatoriske tiltak: opplæring, tilgangskontroll.
- Kontinuerlig overvåkning og evaluering.
Risikoanalyse Verktøy i Python
Her er et eksempel på et verktøy skrevet i Python for å utføre risikoanalyse:
import json
class DPIATool:
def __init__(self, project_name, owner, date):
self.project_name = project_name
self.owner = owner
self.date = date
self.project_description = {}
self.necessity_and_proportionality = {}
self.risk_analysis = []
self.security_measures = []
self.conclusion = {}
def add_project_description(self, purpose, database_type, structure, normalization, personal_data):
self.project_description = {
"Purpose": purpose,
"Database Type": database_type,
"Structure": structure,
"Normalization": normalization,
"Personal Data": personal_data
}
def add_necessity_and_proportionality(self, necessity_assessment, proportionality_assessment):
self.necessity_and_proportionality = {
"Necessity Assessment": necessity_assessment,
"Proportionality Assessment": proportionality_assessment
}
def add_risk(self, risk, likelihood, impact, risk_level):
self.risk_analysis.append({
"Risk": risk,
"Likelihood": likelihood,
"Impact": impact,
"Risk Level": risk_level
})
def add_security_measure(self, measure, description):
self.security_measures.append({
"Measure": measure,
"Description": description
})
def set_conclusion(self, overall_risk_level, decision, monitoring_plan):
self.conclusion = {
"Overall Risk Level": overall_risk_level,
"Decision": decision,
"Monitoring Plan": monitoring_plan
}
def generate_report(self):
report = {
"Project Name": self.project_name,
"Owner": self.owner,
"Date": self.date,
"Project Description": self.project_description,
"Necessity and Proportionality": self.necessity_and_proportionality,
"Risk Analysis": self.risk_analysis,
"Security Measures": self.security_measures,
"Conclusion": self.conclusion
}
return json.dumps(report, indent=4)
# Eksempel på bruk
dpia_tool = DPIATool("Database Security Project", "John Doe", "01/07/2024")
dpia_tool.add_project_description(
"To secure personal data in our customer database",
"PostgreSQL",
"ER Diagram",
"3NF",
"Names, Addresses, Social Security Numbers"
)
dpia_tool.add_necessity_and_proportionality(
"Essential for business operations",
"Data is minimized and anonymized where possible"
)
dpia_tool.add_risk("SQL Injection", "Medium", "High", "High")
dpia_tool.add_security_measure("SQL Injection Prevention", "Use prepared statements and parameterized queries")
report = dpia_tool.generate_report()
print(report)
Visualiseringer
ER-diagram
ER-diagrammet viser strukturen av databasen og relasjonene mellom tabellene. Her er et eksempel på hvordan et ER-diagram kan se ut:
+-----------------+ +------------------+
| Customers | | Orders |
+-----------------+ +------------------+
| CustomerID (PK) |<------| CustomerID (FK) |
| Name | | OrderID (PK) |
| Address | | OrderDate |
| ... | | ... |
+-----------------+ +------------------+
Risikodiagram
Et risikodiagram kan illustrere risikoens sannsynlighet mot dens potensielle konsekvens. For eksempel:
+-------------------+
| Impact |
+-------------------+
High +---| X |
| | |
| | |
Medium+---| |
| | |
| | |
Low +---| |
| | |
+---|---+---+---+---+---+
Low Medium High
Likelihood
Oppgaver
-
Beskriv behovet og proporsjonaliteten for et gitt prosjekt.
- Identifiser og forklar nødvendigheten av å lagre spesifikke personopplysninger.
- Diskuter hvordan dataene kan minimeres eller anonymiseres.
-
Utfør en risikoanalyse.
- Identifiser mulige risikoer for et datasystem.
- Vurder sannsynlighet og konsekvens for hver risiko.
- Anbefal passende sikkerhetstiltak.
-
Implementer sikkerhetstiltak i et prosjekt.
- Velg relevante tekniske og organisatoriske tiltak basert på risikoanalysen.
- Utvikle en plan for kontinuerlig overvåkning og evaluering.
Rapportering
Rapporter resultatene av risikoanalysen og implementerte sikkerhetstiltak ved å bruke verktøyet ovenfor. Generer en JSON-rapport som kan deles med interessenter og brukes som dokumentasjon.
Konklusjon
Dette kapittelet har dekket de grunnleggende prinsippene for innebygd informasjonssikkerhet, risikoanalyse og implementering av sikkerhetstiltak. Ved å bruke verktøy som Python og visualiseringer kan vi bedre forstå og håndtere risikoene knyttet til personopplysninger i datasystemer.
Tillegg til Kapittel 11: Innebygd Informasjonssikkerhet
Utføre en Postmortem på Bedriftens Sikkerhetsbrudd
Introduksjon: Når et datasystem blir kompromittert, er det viktig å utføre en grundig analyse for å forstå hvordan bruddet skjedde og hvilke tiltak som kan iverksettes for å forhindre fremtidige angrep. Dette er kjent som en postmortem-analyse.
Bedriftens Sikkerhetsbrudd: En virksomhet opplevde et sikkerhetsbrudd på deres markedsføringsside. En FTP-server ble lagt til etter at systemet var oppe og gikk, men denne ble aldri sikret riktig og var åpen for internett. Angripere kunne laste opp en fil til denne FTP-serveren, som deretter ble sendt til webserveren. Angriperen navigerte til filen gjennom nettleseren og tok kontroll over serveren, noe som tillot dem å hente data fra databasen.
Viktige Lærdommer:
-
Oppdatering av Modell:
- Sørg for at systemmodellen alltid er oppdatert med alle endringer.
- Enhver endring, selv mindre, må vurderes av sikkerhetsteamet.
-
Sikkerhetsvurdering:
- All ny funksjonalitet og komponenter, som FTP-serveren i dette tilfellet, må vurderes og sikres.
- Hvis komponenter ikke lenger er nødvendige, bør de fjernes for å redusere angrepsflaten.
-
Threat Modeling:
- Implementering av threat modeling ville ha identifisert sikkerhetshullene og forhindret bruddet.
Introduksjon av Threat Modeling til Organisasjonen
Trinn for Implementering:
-
Deltakere:
- Identifiser hvem som bør delta i threat modeling-møter (arkitekter, QA-testere, produktansvarlige, forretningsanalytikere, etc.).
-
Oppgaver:
- Definer hvilke oppgaver deltakerne skal utføre under threat modeling.
- Klargjør hvilke suksesskriterier som gjelder for øvelsen.
-
Forberedelse:
- Sørg for at all nødvendig dokumentasjon, diagrammer og krav er klare før møtet.
- Sørg for at deltakerne er tilstrekkelig trent.
-
Leveranser:
- Definer hva som skal være resultatene fra threat modeling (sikkerhetskrav, identifiserte trusler, bugs).
Integrering med Utviklingsmetodikker:
-
Waterfall:
- Utfør threat modeling i krav-, design- og testfaser.
- Bruk gates for å sikre at threat modeling er fullført før neste fase.
-
Agile:
- Utfør threat modeling på spesifikke funksjonaliteter i iterative sykluser.
- Bruk resultater fra threat modeling til å lage sikkerhetskontroller og tester.
Effektive Threat Modeling Møter:
- Diagrams: Lag detaljerte modeller av systemet.
- Security Requirements: Identifiser og dokumenter nødvendige sikkerhetskontroller.
- Bugs: Identifiser bugs som må fikses for å forbedre sikkerheten.
Overvinne Innvendinger:
- Verdi: Demonstrer ROI ved å vise hvordan threat modeling kan forhindre alvorlige sikkerhetsbrudd.
- Ressurser: Sørg for at deltakerne vet hvor mye tid som kreves og hvilke leveranser som forventes.
- Tidsplan: Forstå organisasjonens nåværende tilstand og planlegg introduksjonen av threat modeling når det er mest hensiktsmessig.
Oppsummering
- Hold modellene oppdaterte.
- Integrer threat modeling i både waterfall- og agile-metodikker.
- Sørg for effektive møter med klare leveranser.
- Vær forberedt på å håndtere innvendinger om verdien, ressursene og tidsplanen for threat modeling.
Visualisering og ER-diagram
ER-diagram og andre relevante visualiseringer kan hjelpe til med å forstå systemstrukturen og identifisere potensielle sikkerhetstrusler. Her er et eksempel på et enkelt ER-diagram for et markedsføringssystem:
```mermaid
erDiagram
CUSTOMER {
int id
string name
string email
}
ORDER {
int id
date order_date
float amount
}
CUSTOMER ||--o{ ORDER: places
ORDER }|..|{ PRODUCT: contains
PRODUCT {
int id
string name
float price
}
### Ressurser og Verktøy
- **OWASP Threat Dragon:** Et gratis verktøy for å lage threat models.
- **Microsoft Threat Modeling Tool:** Et verktøy for å hjelpe til med å finne sikkerhetstrusler i designfasen.
- **CIS Controls:** Veiledning for å sikre systemer og nettverk mot de fleste angrep.
### Eksempel Kode for å Håndtere SQL-injeksjon
For å forhindre SQL-injeksjon, bruk parameteriserte spørringer:
```python
import sqlite3
def safe_query(user_input):
conn = sqlite3.connect('example.db')
cursor = conn.cursor()
cursor.execute("SELECT * FROM users WHERE username=?", (user_input,))
results = cursor.fetchall()
conn.close()
return results
Løse Oppgavene
For å løse oppgavene i kapittel 11, bør studentene først forstå teorien bak innebygd informasjonssikkerhet, utføre praktiske øvelser med verktøyene nevnt ovenfor, og til slutt diskutere sine funn og forslag til forbedringer.
Dette tillegget gir en strukturert tilnærming til å forstå og implementere innebygd informasjonssikkerhet, inkludert threat modeling, i en organisasjon.
Dyp Innføring i OWASP Top 10
OWASP Top 10 er en liste over de 10 mest risikable sårbarhetskategoriene for webapplikasjoner. Listen er basert på hvor ofte sårbarhetene forekommer og hvilken innvirkning utnyttelse av disse har. OWASP står for Open Worldwide Application Security Project, og listen er en uvurderlig ressurs for å forhindre introduksjon av disse sårbarhetene i ditt system.
OWASP Top 10 Risikokategorier
- Injeksjon
- Brutt tilgangskontroll
- Feil konfigurering av sikkerhet
- Utilstrekkelig logging og overvåking
- Sårbare og utdaterte komponenter
- Kryss-skriptangrep (XSS)
- Usikker desig
- API-relaterte sårbarheter
- Mangler i brukerautentisering
- Ubeskyttet transport av data
OWASP Top 10 og CWEs
Hver kategori i OWASP Top 10 inneholder flere spesifikke svakheter, kjent som Common Weakness Enumerations (CWEs). For eksempel, kategorien "Brutt tilgangskontroll" inneholder 34 CWEs som relativ sti-traversering, Cross-Site Request Forgery (CSRF), og tvungen browsing.
Beregning av Risikonivå
For å forstå risikonivået bruker OWASP flere faktorer som inkluderer gjennomsnittlig vektet utnyttbarhet og gjennomsnittlig vektet påvirkningsscore, basert på Common Vulnerability Scoring System (CVSS). CVSS vurderer sårbarhetene basert på:
- Utnyttbarhet: Angrepsvektor, angrepskompleksitet, nødvendig tilgangsnivå, og nødvendig brukerinteraksjon.
- Innvirkning: Konfidensialitet, integritet og tilgjengelighet av applikasjonen.
Insecure Design
En nyere kategori i OWASP Top 10 er "Usikker desig," som fokuserer på design- og arkitekturfeil som fører til sårbarheter. Forebyggende tiltak inkluderer å etablere en sikker utviklingslivssyklus, lage en bibliotek av sikre designmønstre, og bruke threat modeling i arbeidsflyten.
Eksempel på Sårbarhet: Brutt Tilgangskontroll
Scenario: En applikasjon henter data fra databasen uten å validere brukerinput. Angripere kan endre URL-parameteret for å få tilgang til data som ikke tilhører dem, noe som kompromitterer dataens konfidensialitet.
Forebygging: Implementer prinsippet om minst privilegium og nekt som standard. Kontroller tilgang til alle aspekter av applikasjonen, inkludert eksterne komponenter.
Bruk av Verktøy og Ressurser
- OWASP Mutillidae: En sårbar webapplikasjon for å lære og teste sikkerhetsferdigheter.
- Burp Suite: Et verktøy for å analysere og finne sårbarheter i nettsider.
- OWASP Cheat Sheets: Referansemateriale for beste praksis innen webapplikasjonssikkerhet.
Anbefalinger
- Hold modellene oppdatert: Sørg for at sikkerhetsmodellen alltid reflekterer endringer i applikasjonen.
- Integrer sikkerhet tidlig: Inkluder sikkerhet i designfasen for å redusere risikoen for sårbarheter.
- Effektive møter: Sørg for at threat modeling møter er godt strukturert og inkluderer en mangfoldig gruppe av deltakere.
- Håndter innvendinger: Forbered deg på å møte innvendinger mot implementering av threat modeling, og ha klare argumenter for verdien og nødvendigheten av det.
Læringsressurser
- OWASP Nettside: For dypere forståelse og ressurser innen sikkerhetspraksis.
- Pluralsight-kurs: Veiledning og praksis for bedre forståelse av sikkerhetspraksis.
- Sikkerhetsnyheter og blogger: Hold deg oppdatert på nye og fremvoksende trusler.
Ved å implementere og forstå OWASP Top 10, kan du betydelig redusere risikoen for sårbarheter i dine webapplikasjoner og styrke den generelle sikkerheten i ditt system.
Integrasjon av Sikkerhet i DevOps
Innledning til DevSecOps
DevSecOps, eller DevOps med "Sec" for sikkerhet, innebærer å integrere sikkerhet i alle stadier av DevOps-prosessen. Målet er å balansere hurtighet og automatisering med robust sikkerhet. Dette kurset gir innsikt i hva DevSecOps er, hvorfor det er viktig, og hvordan det implementeres effektivt.
Identifisering av Problemet
Automatisering forbedrer hastighet og nøyaktighet, men kan overse viktige sikkerhetsaspekter som hardkodede autentiseringsopplysninger og sårbarheter i åpen kildekode. Tradisjonelle IT-angrepsmetoder som DDoS, phishing, og malware er velkjente, men utviklingsprosesser krever fokus på sårbarheter på kode- og rørledningsnivå, som forsyningskjedeangrep.
Forsyningskjedeangrep: Et forsyningskjedeangrep innebærer utnyttelse av tredjeparts programvaremoduler eller avhengigheter som brukes i applikasjonsutvikling. Eksemplet med SolarWinds-innbruddet i 2020 viser risikoen forbundet med slike angrep. Angripere fikk tilgang til SolarWinds' byggesystem og distribuerte skadelige oppdateringer til kundene, inkludert sensitive myndighetsorganer.
DevSecOps: Hvordan Det Hjelper
DevSecOps-prinsippet om å "shift left" innebærer å inkludere sikkerhetstesting tidlig i utviklingsprosessen, ikke bare som en siste sjekk før distribusjon. Automatisert testing bør integreres i hele DevOps-prosessen, noe som kan spare tid, energi og kostnader, og samtidig lette overholdelsen av regulatoriske rammeverk som GDPR og HIPAA.
DevSecOps Manifesto
DevSecOps Manifesto setter prioriteringer for sikkerhetsarbeid:
- Engasjement og samarbeid: Sikkerhetsadministratorer bør søke løsninger i stedet for å avvise forslag.
- Data- og forskningsbaserte beslutninger: Utforsk alternativer og bruk gode data.
- Nedbryting av siloer: Integrer sikkerhets- og utviklingsteam for å finne felles løsninger.
- Sikre API-er: Bruk autentiseringsprotokoller for å gi utviklere tilgang uten å øke trusselmiljøet.
- Tilpasning til forretningsbehov: Sikkerhetsvalg bør være fleksible og tilpasset endrede behov.
- Proaktiv testing: Utfør regelmessige simuleringer av angrep (red team/blue team) for å være forberedt.
- Kontinuerlig overvåking og deling: Oppdater sikkerhetsnyheter og del funn med teamet.
- Reell samsvar: Forstå hvorfor visse tilstander og profiler er farlige, ikke bare kryss av i sjekkbokser.
Implementering av DevSecOps
For å gjøre DevSecOps effektivt, kreves kulturell tilpasning og buy-in fra hele organisasjonen. DevSecOps fungerer best i miljøer som allerede bruker agile og DevOps-praksiser. Sikkerhetspraksis bør inkluderes i arbeidet til hvert team og integreres i hele utviklingsrørledningen.
Ressurser og Verktøy
- OWASP: Gir omfattende ressurser og verktøy for å forstå og implementere sikkerhetspraksis.
- Pluralsight-kurs: Tilbyr veiledning og praksis for bedre forståelse av DevSecOps.
- Burp Suite: Et verktøy for å analysere og finne sårbarheter i nettsider.
- Automatiserte Sikkerhetsskannere: Integrer verktøy som Snyk, SonarQube, og Fortify for kontinuerlig skanning av kode.
Oppsummering
DevSecOps integrerer sikkerhet i alle faser av DevOps for å balansere hastighet og sikkerhet. Ved å implementere DevSecOps-prinsipper og best practices, kan organisasjoner redusere risikoen for sårbarheter og styrke den generelle sikkerheten i utviklingsprosessen.