Contents

  1. Úvod
    1. Motivace a rozsah působnosti
      1. Týká se personálu
      2. Mimo rozsah
    2. Principy
    3. Definice
    4. Dokumenty a Řízení verzí
      1. Dokument Zásady bezpečnosti (Security Policy)
      2. Dokument Příručka bezpečnosti (Security Manual)
      3. Bezpečnostní procedury
  2. FYZICKÁ BEZPEČNOST
    1. Zařízení
      1. Umístění a konstrukce
      2. Napájení
      3. Síťové připojení
      4. Zmírnění katastrofických událostí
      5. Hodnocení
    2. Fyzické aspekty
      1. Počítače
        1. Akvizice
      2. Servis
      3. Média
        1. Zásobení
        2. Uložení [do skladu]
        3. Vyřazení
    3. Fyzický přístup
      1. Oprávnění přístupu
      2. Profily přístupu
      3. Nouzový přístup
      4. Fyzické bezpečnostní kódy a zařízení
  3. LOGICKÁ BEZPEČNOST
    1. Síť
      1. Infrastruktura
        1. Vnější konektivita
        2. Vnitřní konektivita
      2. Provozní konfigurace
        1. Přístup
        2. Výstup
      3. Detekce proniknutí
    2. Operační systém
      1. Šifrování disků
      2. Provozní konfigurace
      3. Opravy
        1. “nouzové” záplatování
    3. Aplikace
    4. Řízení přístupu
      1. Přístup z aplikací
      2. Zvláštní oprávnění
      3. Identifikace
      4. Odebrání přístupu
  4. PROVOZNÍ BEZPEČNOST
    1. Správa systému
      1. Privilegované účty a hesla
        1. Oprávnění uživatelé
        2. Přístup k systémům
        3. Změny
      2. Požadovaná doba odpovědi týmu
      3. Změny procedur správy
      4. Outsourcing
    2. Žurnálování (Logging)
      1. Rozsah záznamů
      2. Přístup a bezpečnost
      3. Automatizované logy
      4. Operační (manuální) logy
    3. Záloha
      1. Typ zálohy
      2. Četnost
      3. Paměť
      4. Expirační doba a opakované použití
      5. Šifrování
      6. Ověření záloh
      7. Správa klíčů
      8. Čtení záloh
    4. Doba uchovávání dat
      1. Údaje o uživatelích
      2. Systémové žurnály (logy)
      3. Hlášení incidentů
  5. ODEZVA NA INCIDENT
    1. Incidenty
    2. Detekce
    3. Okamžitá akce
      1. Závažnost a priorita
      2. Komunikace
      3. Eskalace
    4. Vyšetřování
    5. Odpověď
      1. Proniknutí
      2. Kompromitování operačního systému
      3. Potenciální prozrazení uživatelských dat
      4. Prozrazení kořenového klíče
      5. Kompromitování aplikace
      6. Obnova po prozrazení nebo narušení
    6. Hlášení
  6. OBNOVA PO HAVÁRII
      1. Poznámky
    2. Provozní procesy
      1. Základní procesy
    3. Doby obnovy
    4. Plán
    5. Seznam klíčových osob
  7. VÝVOJ SOFTWARU
    1. Oprávnění
    2. Úkoly
    3. Úložiště
    4. Revize
    5. Test a chyby
    6. Výroba
  8. PODPORA
    1. Oprávnění
    2. Odpovědnosti
      1. Inženýři podpory
      2. Zapnutí rolí
      3. Triage [Třídění]
      4. Vedoucí týmu Podpory
    3. Kanály
    4. Záznamy a žurnály (logy)
    5. Arbitráž
    6. Odkazy
  9. ADMINISTRATIVA
    1. Personální věci
      1. Role a odpovědnosti
      2. Personální úrovně
      3. Postup u nových členů týmu
      4. Procedury ověření
        1. Rozsah
        2. Pokrytí
        3. Dokumentace
        4. Ochrana soukromí pro kritické role
      5. Oprávnění
      6. Bezpečnost
      7. Ukončení působnosti
      8. HR(?) a školení
    2. Správa kořenového klíče
      1. Generování kořenového klíče
      2. Záloha a úschovna (escrow)
      3. Obnova
      4. Odvolání
    3. Právní aspekty
      1. Odpovědnost
      2. Odpověď na (právní) dotaz zevně komunity
    4. Outsourcing
    5. Důvěrnost, utajení
  10. ZDROJE
    1. Kontakty
      1. Kontaktní seznam klíčových osob
    2. Dokumenty
      1. Poskytnout / najít
    3. Související dokumenty

1. Úvod

1.1. Motivace a rozsah působnosti

Tato Příručka bezpečnosti popisuje požadované praktiky a procedury pro bezpečné provozování kritických počítačových systémů CAcert personálem, tak jak jsou identifikovány Zásadami bezpečnosti (Security Policy, SP).

1.1.1. Týká se personálu

Viz SP.

1.1.2. Mimo rozsah

Viz SP.

1.2. Principy

Viz SP.

1.3. Definice

Viz SP.

1.4. Dokumenty a Řízení verzí

1.4.1. Dokument Zásady bezpečnosti (Security Policy)

Tato Příručka bezpečnosti (Security Manual) podléhá řízení Zásadami bezpečnosti (Security Policy, "SP") neboli "Zásadami") pro dosažení shody. Zásady určují, co se musí vykonat. Příručku bezpečnosti je vhodné číst současně se Zásadami, protože každý zde uvedený oddíl závisí na Zásadách.

Myslím, že bychom měli napsat PHP skript ke čtení obou dokumentů a zobrazit jejich odpovídající oddíly vlevo a vpravo...

Zásady bezpečnosti podléhají Konfiguraci-Řídicí specifikaci (CCS) pro účely auditu. SP jsou ZÁSADY (POLICY) závazné pro klíčový personál.

1.4.2. Dokument Příručka bezpečnosti (Security Manual)

Tato Příručka bezpečnosti ("SM" nebo "tato Příručka") je dokument o praktikách. Popisuje prováděcí postupy. Spravuje ji tým vedoucích za použití tohoto wiki k řízení verzí.

Bude revidována, aby souhlasila se Zásadami (SP) a praktiky i procedury zde dokumentované budou revidovány, aby souhlasily jak se Zásadami (SP), tak s Příručkou (SM).

1.4.3. Bezpečnostní procedury

Zásady (SP) opravňují vedoucí týmů k vytváření procedur. Jsou to jednoduché a soudržné komponenty bezpečnostních praktik, zpracované jako oddělené dokumenty tam, kde zařadit je do Příručky bezpečnosti (SM) by bylo příliš nepraktické. Tyto dokumenty mají totéž postavení jako tato Příručka a lze je považovat za logicky začleněné do ní.

Viz oddíl 10.2 - aktuální seznam procedur.

Přídavné praktiky, které jsou určeny stát se procedurami, se během doby, kdy jsou zde vyvíjeny, označí jako PROCEDURE .

2. FYZICKÁ BEZPEČNOST

Tento oddíl je spravován vedoucím týmu přístupu (Access Team). Diskuse

Poznámky k revizi této sekce - následující připomínky nejsou částí Příručky bezpečnosti (SM): 

4.5.1. Ovládání fyzické bezpečnosti

 . Tato část popisuje fyzické ovládání [uspořádání] v obálce [například budově, kde je umístěno] zařízení entity systémů.
 . Mohou zde být například tato témata:

   *  Umístění a konstrukce sídla, například konstrukční
      požadavky na zóny vysoké bezpečnosti a používání uzamčených místností,
      klecí, trezorů a kabin;

   *  Fyzický přístup, tj. mechanismy pro ovládání přístupu z jedné oblasti
      zařízení do jiné, nebo přístup do zón vysoké bezpečnosti,
      např. umístění provozu CA do bezpečného počítačového sálu, monitorovaného
      strážemi nebo bezpečnostními alarmy a požadovaný přesun ze zóny do
      zóny má být realizován pomocí žetonu, biometrických čidel a/nebo
      seznamů povolených přístupů;

   *  Napájení a klimatizace;

   *  Vystavení vodě;

   *  Požární prevence a ochrana;

   *  Úložiště médií, např. požadavek na úložiště záložních
      médií oddělené, fyzicky bezpečné a chráněné před
      poškozením ohněm a vodou;

   *  Odpadové hospodářství;

   *  Záloha mimo sídlo.

2.1. Zařízení

Hostování je zajištěno u fy BIT podle smlouvy s firmou secure-u. Viz §9.4.

2.1.1. Umístění a konstrukce

Zařízení je moderní, pro svůj účel postavené zabezpečené hostitelské centrum v Ede, Nizozemí.

CPS5.1.1 odkazuje sem.

2.1.2. Napájení

Zařízení má (rozšiřitelné) silové připojení 1.2 MW, dvojitou klimatizaci po 0.75 MW (rozšiřitelnou) a dvojitou záloho napájení: UPS a diesel generátory.

CPS5.1.3 odkazuje sem.

2.1.3. Síťové připojení

Zařízení je připojeno na světlovodný okruh [optická vlákna], který zajišťuje dvě geograficky oddělená spojení mezi Ede a Amsterdamem. Jak v Ede, tak v Amsterdamu jsou dva geograficky rozdílné koncové body, též propojené optickými vlákny. Internetový provoz lze v každém místě vést přes Amsterdam Internet Exchange [AMSIX] (http://www.ams-ix.net).

2.1.4. Zmírnění katastrofických událostí

Zařízení je umístěno 9 metrů nad úrovní moře (NAP). Má tyto prostředky pro zmírnění katastrofických událostí:

Je to ono (vše)?

CPS5.1.4 odkazuje sem.

2.1.5. Hodnocení

Datové centrum je strukturálně a elektronicky zabezpečeno na úrovni BORG třídy 4. Klasifikace BORG je řízena Holandským centrem pro prevenci kriminality a pro bezpečnost (Dutch Centre for Criminality Prevention and Security) a je definována v Nationale Beoordelingsrichtlijn BORG 2005 (Národním posouzení BORG 2005 - dostupné pouze v holandštině).

2.2. Fyzické aspekty

2.2.1. Počítače

Seznam inventáře udává prodejce, model a výrobní číslo, kontakt na údržbu, umístění v roštu (racku), zamýšlené použití (určení), název (alias).

Pracovní seznam fyzického inventáře:

Právně závazný Seznamu inventáře je uložen v kanceláři sekretáře secure-u. Pro získání kopie seznamu požádejte Výbor secure-u (vorstand@secure-u.de).

2.2.1.1. Akvizice

Akvizice hardwaru otevírá zvláštní bezpečnostní rizika pro dobře fundované útočníky.

Akvizici mohou provést správci systémů CAcert, ale v okamžiku zahájení služby [uvedení do provozu] se právní vlastnictví hardwaru přenáší na secure-u a řízení fyzického přístupu se přenáší na Inženýry přístupu.

2.2.2. Servis

2.2.3. Média

2.2.3.1. Zásobení

Inženýři přístupu (Access Engineers) udržují inventář paměťových médií. Inventář má obsahovat typ média a jeho kapacitu.

2.2.3.2. Uložení [do skladu]

Hlášení změny stavu má obsahovat: přítomné správce systému (sysadmins), provedené kroky, umístění skladu, atd.

2.2.3.3. Vyřazení

Bezpečné zničení má proběhnout jedním z těchto způsobů, v tomto pořadí podle priority:

  1. znečitelnění fyzickými prostředky, které zničí zápisové plochy a elektroniku, nebo
  2. zničení licencovanou likvidační firmou, nebo
  3. zapečetění a bezpečné uložení u secure-u, dokud platnost dat nevyprší. Rok konce platnosti nechť je označen správcem systémů CAcert.

Podrobně je postup dokumentován v SystemAdministration/Procedures/DriveRetirement.

2.3. Fyzický přístup

CPS5.1.2 odkazuje sem.

2.3.1. Oprávnění přístupu

Oprávnění k fyzickému přístupu se provádí podle popisu v příloze "Appendix B" CAcert-secure-u MoU, aktualizovaný příslušnými komisemi.

2.3.2. Profily přístupu

Fyzický přístup je možný pouze prostřednictvím Inženýrů přístupu (Access Engineers) secure-u. Musí být přítomen aspoň jeden Inženýrů přístupu. U logického přístupu ke kritickým serverům CAcert bude přítomen aspoň jeden Správce systémů.

Inženýři přístupu nepracují s daty. ==== Záznamy o přístupu === Fyzické přístupy jsou zaznamenávány a hlášeny na seznam adresátů správy systémů CAcert (viz §10.1). "Seznamy kontaktů" dokumentovanými v MoU [Memorandum of Understanding - mezi CAcert a secure-u] se rozumějí osoby přihlášené k tomuto seznamu.

Deníky zařízení jsou uloženy u BIT.

2.3.3. Nouzový přístup

V souladu se zásadami nejsou pro nouzový přístup definovány žádné postupy. Je-li získán nebo zpozorován nouzový přístup, zakládá se spor a okolnosti se předloží nezávislému arbitrovi. To lze použít k bezpečnému oprávnění "po činu" přístupu v nouzové situaci.

2.3.4. Fyzické bezpečnostní kódy a zařízení

BIT ovládá přístupový systém na karty, skener očí a zámky roštu. Klíče k zámkům roštu jsou registrovány (není dovoleno je kopírovat).

Zástupci secure-u uvedení na seznamu přístupů mají klíč k roštu. BIT má klíč určitého tvaru. jak je ten BIT klíč ovládán/kontrolován?

3. LOGICKÁ BEZPEČNOST

Tento oddíl je spravován vedoucím týmu správy kritických systémů (Critical System Administration).

3.1. Síť

3.1.1. Infrastruktura

Diagramy jsou umístěny kde???

3.1.1.1. Vnější konektivita

Služby viditelné zvenku:

3.1.1.2. Vnitřní konektivita

Služby viditelné uvnitř:

Nekritické systémy se s kritickými systémy spojují pouze pomocí služeb viditelných zvenku (externích) takto:

3.1.2. Provozní konfigurace

3.1.2.1. Přístup

Všechny porty, na nichž se očekává příchozí provoz, jsou dokumentovány; provoz vedený na jiné porty je blokován. Neočekávaný provoz musí být zaznamenám jako výjimka.

Protokol

Port

Použití

HTTP

TCP/80

hlavní webový server

HTTPS

TCP/443

hlavní webový server, zabezpečený režim

SSH

TCP/22

pouze ze dvou počítačů vnitřní sítě správy (admin); vzdálená údržba systému

3.1.2.2. Výstup

Všechny porty, na něž je zahájen výstupní provoz, jsou dokumentovány; provoz vedený na jiné porty musí být zablokován. Neočekávaný provoz musí být zaznamenám jako výjimka.

Protokol

Port

Použití

DNS

UDP/53 + TCP/53

DNS vyhledávání z hlavní aplikace CAcert

SMTP

TCP/25

odchozí e-maily odeslané hlavní aplikací CAcert

WHOIS

TCP/43

vyhledávání názvů domén, zahájené hlavní aplikací CAcert

HTTP

TCP/80

prohledávání webu, ponejvíce pro aktualizace systému

NTP

UDP/123

synchronizace času se servery času v Internetu

boxbackup

TCP/2201

pouze na backup.intern.cacert.org; pro zálohování on-line

3.1.3. Detekce proniknutí

(iang:) toto je řešeno v DRC-A.5.f. kde se říká: "Příručka bezpečnosti popisuje, jak jsou počítačové systémy konfigurovány a aktualizovány ke své ochraně proti škodícím průnikům, neoprávněnému elektronickému přístupu a "malware" (škodlivým programům) a jak jsou jednotlivci oprávněni provádět tyto úkoly."

skutečný test proniknutí může zahrnovat vniknutí do privátního ethernetu, provedené příslušníky secure-u.

Provoz pro Tunixem spravovanou vnější analýzu provozu firewallu provádí Tunix podle smlouvy se secure-u. Tato služba zajišťuje nepřetržité (24/7) monitorování. viz webové stránky Tunixu.

Přímý provoz do/z kritických serverů CAcert analyzují správci systémů CAcert.

3.2. Operační systém

Preferovaný OS pro server s webovou databází je Debian GNU/Linux, Stabilní vydání (Stable). V určitém okamžiku označí projekt Debian některé novější vydání/verzi operačního systému jako své Stabilní vydání. Předchozí Stabilní vydání získá status Starého stabilního vydání (Oldstable), ale bude ještě rok udržováno bezpečnostními opravami; vznikne-li během toho roku nové Stabilní vydání OS, bude jednoleté období údržby zkráceno.

Správci systémů CAcert potřebují aktualizovat webový/databázový server ze Starého stabilního (Oldstable) vydání Debianu na nové Stabilní (Stable) vydání Debianu, než přestane Debian project Staré stabilní vydání udržovat.
Viz též SystemAdministration/Systems/Webdb.

Podepisující server má také operační systém Debian GNU/Linux, jeho vydání Debian Lenny, což je Stabilní vydání od února 2009 [patrně tedy zastaralý údaj]. Oproti serveru web/db nemá tento server externí spojení a není vystaven navenek [nemá přístup z Internetu]; proto není aktualizován na nová vydání OS, pokud nemá být někdy v budoucnu zcela přebudován.
Viz též SystemAdministration/Systems/Signer.

3.2.1. Šifrování disků

Viz SystemAdministration/Procedures/DiskEncryption.

3.2.2. Provozní konfigurace

Při uvedení do provozu musí být provedena úplná (zašifrovaná) záloha podle SM§4.3. Nejlépe je provést to ihned po spuštění služby.

3.2.3. Opravy

Nové bezpečnostní opravy (záplaty) budou aplikovány co nejdříve po jejich vydání prodejcem. Záplaty uvolní prodejce a aplikují se manuálně. Po aplikaci rozsáhlé záplaty se opět provede úplná (zašifrovaná) záloha příslušného stroje, jako výše. Detaily postupu záplaty/aktualizace operačního systému jsou popsány v SystemAdministration/Procedures/OperatingSystemPatches

3.2.3.1. “nouzové” záplatování

3.3. Aplikace

Primární úkoly pro správu aplikací jsou:

3.4. Řízení přístupu

3.4.1. Přístup z aplikací

Kde je to možné, použijí správci systémů prostředky obecné aplikace a budou navrženy změny tam, kde je lépe provádět časté akce pomocí aplikace.

3.4.2. Zvláštní oprávnění

Seznamy řídicí přístup jsou:

3.4.3. Identifikace

Přístup přes SSH. Přístup je přes SSH na "hop" [asi: vložený] stroj umístěný uvnitř sítě a z něj na kritický server (kritické servery). Identifikační klíče SSH (SSH Authentication keys) jsou na obou strojích nastaveny, se zapnutým blokováním IP# [čísla? adresy?]. K přístupu správců systému k osobním, pojmenovaným účtům (každý správce [sysadmin] má jeden) se nepoužívají hesla. Přímé přihlášení a přístup k účtu root není povoleno. Veřejný klíč SSH každého správce systému, který má takový přístup, je uložen do ~sysadmin/.ssh/authorized_keys na kritickém serveru, privátní SSH klíč musí být utajen (tj. chráněn heslem na privátním systému) každým správcem systému majícím takový přístup. Žurnálové záznamy (logy) přístupu přes SSH se ukládají na kritický server (kritické servery).

Přístup on-line. Přihlášením na normální účet člena týmu podpory.

3.4.4. Odebrání přístupu

Proběhne za těchto okolností:

Přístup osoby k systémům CAcert může být odebrán dočasně. Odebrání se stane trvalým, když Výbor schválí změnu v seznamu přístupů (Access List).

4. PROVOZNÍ BEZPEČNOST

Tento oddíl je spravován vedoucím týmu správy kritických systémů (Critical System Administration).

4.1. Správa systému

Tím, že pravidelnou prohlídku žurnálu (logu) ohledně úkolů provádí jiný správce systémů, je splněn princip čtyř očí.

4.1.1. Privilegované účty a hesla

Přímý přístup účtu "root" přes vzdálená připojení (tj. vzdálené přihlášení roota) je zakázáno. Heslo se nesmí za žádných okolností přenášet nezašifrovaným kanálem. Ostatní privilegované účty (databáze, http server, atd.) musí být také konfigurovány, aby nepovolovaly login.

Preferovanou metodou pro získání přístupu správce (root) je použití utility sudo určenými uživateli, jak pro omezenou sadu příkazů, tak všeobecně. Privilegia sudo se konfigurují pomocí /etc/sudoers a to tak, aby každý přístup správce, tj. přihlášení při vyvolání sudo, vyžadoval individuální heslo.

Přes preferované používání sudo stále trvá i potřeba hesel "roota", aby byl umožněn nouzový přístup do systému z (fyzické) konzole. Takový přístup by neměl záviset na přihlášeních (loginech) jednotlivých správců systémů, avšak znalost hesla "roota" je omezena na členy seznamu konzolových přístupů (Console Access List, viz 3.4.2.).

4.1.1.1. Oprávnění uživatelé

4.1.1.2. Přístup k systémům

Pro přístup k účtům se používá pouze SSH. Všechny pokusy o přístup k účtům budou zaznamenány; neúspěšné pokusy budou označeny k prohlídce.

4.1.1.3. Změny

Je povinností systémových správců generovat hesla privilegovaných účtů. Změněná hesla by měla vyhovovat nejlepším praktikám co do délky a složitosti. Každá změna hesla privilegovaného účtu se zaznamená do žurnálu (Event Log).

Hesla pro privilegované účty musí být změněna při změně oprávněného uživatele nebo při podezření, že je příslušný stroj kompromitován.

Podrobnosti o heslech a související správě tajných informací [např. hesel] a změny jsou uloženy v seznamu Procedury správy hesel (Password Management Procedures).

4.1.2. Požadovaná doba odpovědi týmu

Dostupnost odpovědi na systémové události je nejlepší úsilí.

4.1.3. Změny procedur správy

Všechny změny systémové konfigurace musí být zaznamenávány pomocí RCS. [Remote Control System?]

4.1.4. Outsourcing

[správa vnější firmou] Outsourcovat lze DNS a OCSP. Viz oddíl 9.4.

Toto je prostor houpačky. (???)

4.2. Žurnálování (Logging)

CPS4.2 odkazuje sem.

4.2.1. Rozsah záznamů

Žurnály (logy) se udržují a uchovávají takto:

typ záznamu

minimální doba uchovávání

maximální doba uchovávání

anomální provoz sítě

6 měsíců

12 měsíců

systémové aktivity a události

6 měsíců

12 měsíců

přihlašování (login) a přístup účtu root

6 měsíců

12 měsíců

události aplikací (certifikát, web, e-mail a databáze)

6 měsíců

12 měsíců

požadavky na podpis certifikátu, jak na kryptografický modul (podepisující server), tak na hlavní on-line server

24 měsíců

36 měsíců

změny konfigurace

doba života systému

+12 měsíců

(daniel:) Já bych zřídil [mandate] centrální log server - kompromitovaný [ven do Internetu vystavený?] server, který obsahuje žurnálové záznamy (logy) nepotřebuje tak moc integrity. Doporučuji, aby správci systémů měli pouze read-only přístup na centrální log server. Read-only pohled přístupný jen výboru a správě systému by zlepšil transparentnost.

(wytze:) Také bych to rád viděl takto, ale právě teď to nemohu zřídit [mandate].

Jak kryptografický modul (podepisující server), tak hlavní on-line server musí udržovat žurnálové záznamy (logy) zaslaných požadavků.

4.2.2. Přístup a bezpečnost

Každý záznam bude opatřen časovým razítkem. Logy budou "write only" - jen zápis.

Logy na nepřístupném podepisujícím serveru budou pravidelně extrahovány pro analýzu. Logy kritických on-line serverů budou denně zálohovány.

Přístup k nim je omezen na Správce systémů (Systems Administrators).

Budoucí vývoj: žurnálové záznamy budou odesílány na centrální log server.

4.2.3. Automatizované logy

Automatizované logy budou prohlíženy nejlépe denně.

4.2.4. Operační (manuální) logy

Změny konfigurace musí být logovány pomocí RCS. K logu RCS mají přístup pouze Správci systémů (Systems Administrators).

Všechny přístupy budou logovány (zapsány) do Event Logu [záznamu událostí] včetně krátkého popisu prováděných aktivit.

4.3. Záloha

toto spojit s oddílem 3.2.1 CPS 5.1.6 odkazuje sem.

4.3.1. Typ zálohy

Jsou tři typy záloh:

4.3.2. Četnost

Zálohy se budou provádět:

4.3.3. Paměť

Zálohy pro obnovení z havárie budou ukládány firmou secure-u na bezpečné místo; přístup k médiím musí být řízen. Záložní média lze použít opakovaně, ale musí se na konci své životnosti správně likvidovat (viz oddíl 2.2.3.2).

V současnosti nejsou zálohy pro obnovení po havárii distribuovány pro nedostatek prostředků.

4.3.4. Expirační doba a opakované použití

PROCEDURA: Je třeba napsat zálohovací proceduru včetně:

Za výjimečných podmínek (a) vyšetřování incidentu (oddíl 5) nebo (b) nařízení arbitra, budou příslušné zálohy zkoumány a relevantní údaje v nich mohou být extrahovány a uchovány pro tyto účely. Po ukončení výjimky musí být data smazána.

4.3.5. Šifrování

Zálohy pro obnovu po havárii jsou dvojitě šifrovány použitím šifrovacího systému a veřejného klíče GPG.

4.3.6. Ověření záloh

Záloha pro obnovu po havárii je po svém vytvoření ověřena, než je odeslána do bezpečného úložiště. Ověření musí být zaznamenáno do Event Logu.

U provozních záloh se zvolí soubory a zkontroluje se, zda se dají obnovit.

Kde je procedura obnovy...? Mendel!

4.3.7. Správa klíčů

Zálohu musí provádět aspoň dva.

Papírová dokumentace musí být uložena se zálohou:

Jakmile správci systémů ukončí aktivitu, ke které jsou oprávněni, musí odevzdat své klíče, smazat své kopie, nebo jednat podle pokynů arbitra.

Kopie všech kořenových hesel a záloha klíčů a přidružených hesel se uchovávají v jedné či více zapečetěných obálkách a ukládají se do sejfu jednoho z členů výboru CAcert. Změní-li se jedno nebo více uložených hesel, pak při nejbližší příležitosti uloží tým Správců systému novou zapečetěnou obálku nadřízenému členu systému k uložení do sejfu obsahujícího kopie.

Přidáno pro záznam: Roots/EscrowAndRecovery stanoví: 

Hesla zašifrovaných disků a kořenová hesla přístupu k systémům jsou uložena v zapečetěné obálce u člena výboru Public Officer CAcert Inc. Tento typ klíčů se má měnit periodicky.

    * Jedna bílá obálka (typu Barional A6), zalepená průhlednou páskou, datovaná 26-11-2008, s podpisem Wytze van der Raay (správce kritických systémů), s identifikací 'backup keys' [záložní klíče] a backup@cacert.org. 

Obnova kořenových hesel a klíčů SSH ze zapečetěné obálky závisí na rozhodnutí Výboru (Board). Platnost klíčů je třeba periodicky kontrolovat (s datem změny).

a 

28. listopadu: Kořenové klíče byly uloženy do zapečetěných obálek, zalepených pak bezpečnostní páskou 3Com. Obálky jsou (dočasně) uloženy, dokud nebude dokončeno úložiště na nizozemském notářství, v CAcert Inc. v soukromém sejfu presidenta Teuse Hagena.

Komentáře ke dvěma předchozím citacím:

4.3.8. Čtení záloh

Je-li zkištěn incident, který vyžaduje přístup k zálohám, je zahájen spor s cílem dosáhnout oprávnění. Nouzové akce je pak třeba neprodleně oznámit arbitrovi.

4.4. Doba uchovávání dat

4.4.1. Údaje o uživatelích

Při ukončení účtu jsou uživatelské údaje uchovávány podle směrnice arbitra.

4.4.2. Systémové žurnály (logy)

Viz oddíl 4.2.1 o uchovávání systémových logů.

Výtahy logů potřebné k vyšetření incidentů a pro arbitra budou navíc uloženy s odpovídajícím hlášením o vyšetření incidentu nebo v souboru případu arbitráže. Vyšetřovatel nebo arbitr odpovídá za oznámení začátku vyšetřování a za identifikaci, které logy jsou citlivé a tedy pod jeho kontrolou.

Pro pohodlí vyšetřovatele bude asi třeba logy kopírovat a zabezpečit na jednotce vyčleněné pouze pro vyšetřování.

4.4.3. Hlášení incidentů

Dokončená hlášení o incidentech budou udržována na bezpečném místě po dobu neurčitou. Jsou-li v uloženém hlášení citlivé údaje, musí být uchovávaná elektronická verze hlášení (nebo jakákoli elektronická data přiložená k hlášení) zašifrována.

5. ODEZVA NA INCIDENT

Tento oddíl udržuje ??? Diskuse. CPS 5.7 odkazuje sem.

5.1. Incidenty

Mají několik úrovní:

  1. Tunix firewall 24/7 ovládání a monitorování portů; analýza nezašifrovaného provozu.
  2. Firewall webového serveru ovládání a monitorování portů.
  3. Ovládání aplikací.
  4. Podepisující server.

Všechny tyto úrovně generují log.

5.2. Detekce

V záznamech (logs) musí být hledány anomálie, alespoň jednou týdně; kde je to možné, automatizovaná detekce anomálií by měla co nejdříve upozornit příslušné odpovědné osoby na detekovanou neobvyklou událost. Jedna osoba bude určena jako primární pro sledování logu, bude odpovědná za dosažení takového stupně znalosti logu, který bude dostatečný ke zjištění nových podezřelých anomálií, a za aktualizaci automatických detektorů.

5.3. Okamžitá akce

5.3.1. Závažnost a priorita

Závažnost. Anomální události budou klasifikovány do těchto kategorií závažnosti:

  1. nepřímá závada (narušení programem)
  2. sonda
    1. automatizovaná sonda (všeobecný pokus o detekci některých běžných slabin)
    2. směrovaná sonda (specifický pokus zneužít určitou službu)
  3. proniknutí (úspěšná změna/převzetí ovládání)
    1. využití/zneužití, žádné ztráty
    2. prozrazení/odhalení, možnost ztráty citlivých údajů nebo výdeje certifikátů
    3. průlom, positivní důkaz ztráty dat
  4. odepření služby [Denial of Service, DoS] (úspěšný pokus směrovaný jako zásah do síťové konektivity nebo jiné dostupnosti jedné i více základních služeb)

Priorita. Priorita odpovědi na jakýkoli incident slouží především k zajištění integrity základních služeb a zabezpečení aktivních dat. Kompromitované služby musí být isolovány ihned po detekci prozrazení/kompromitování. Incidenty musí být ukončeny ihned po detekci a za žádných okolností jim nesmí být povoleno pokračovat (ani za účelem vysledování viníka).

5.3.2. Komunikace

Upozornění. Jakmile je událost zjištěna, bude zasláno počáteční hlášení o průniku nebo prozrazení těmto osobám:

Přesný seznam, příjemců kopií hlášení je určen okamžitě úsudkem člena [asi: který to zjistí] a každý obeslaný člen může hlášení šířit dále. Další osoby mohou poskytnout další informace.

Válečná místnost. Vytvořte chatovací místnost (např. IRC nebo skype) pro okamžité podpůrce (např. jiné správce systémů, secure-u, Výbor, arbitra). Zapněte záznam do žurnálu (logging). Jsou-li potřebná různá zaměření, pomůže několik takových místností. Případy odepření služby (DoS) budou obvykle zpracovány hostitelskými a firewallovými entitami, přes secure-u MoU [Memorandum of Understanding], takže s nimi navažte kontakt. Kontakt se secure-u a jeho smluvními agenturami je definován v MoU, včetně e-mailových adres. Zkontrolujte weby, obsahují-li nouzová telefonní čísla smluvních agentur.

5.3.3. Eskalace

V případech proniknutí a horších událostí musí být zřízen oddělený dozor a autorita pro nouzové akce.

Přehled. Neodpovídají-li autority potřebám, zahajte spor a předložte přehled situace arbitrovi. Přehled slouží ke schválení a oprávnění akcí a v extrémní situaci k přímým alternativám. Jsou-li údaje prozrazeny, je nezbytná arbitráž.

Správa. Do komunikační smyčky bude zapojen vedoucí týmu. Není-li k dispozici, nebo rozhodne-li tak vedoucí týmu, zastane tuto funkci Výbor (určený člen Výboru; management je zaměřen na zvládnutí situace rozhodováním podle nadcházejících událostí.

Správa a arbitráž nejsou v rozporu, naopak by měly spolupracovat.

5.4. Vyšetřování

Jakákoli anomální událost (služba/služby neposkytující odpověď, nepředvídané přetížení prostředků, atd.) je co nejdříve zcela vyšetřena. Pokud vyšetření vede k závěru, že mohlo dojít k narušení bezpečnosti, musí být uchován důkaz co možná nejbližší původnímu stavu a jakékoli záznamy žurnálu (logu) týkající se události.

Je třeba zkontrolovat, zda:

5.5. Odpověď

Opravná akce provedená jako odpověď na anomální událost odpovídá klasifikaci závažnosti události. Obvykle pouze události klasifikované jako proniknutí nebo závažnější budou vyžadovat zmírnění [dopadu], které provede tým správy systému.

5.5.1. Proniknutí

Úspěšně sondovaná služba bude vyšetřena ["sonda" je (nepřátelský) prostředek toho průniku]:

5.5.2. Kompromitování operačního systému

[Což pravděpodobně znamená jeho narušení tak, že ho útočník může na dálku ovládat.]
V případě kompromitování [narušení] zneužitím zranitelnosti operačního systému musí být narušený systém isolován vnější sítě a forenzně prozkoumán, se všemi příslušnými archivovanými logy. Když aktivita škodlivého programu logy zničila, je třeba nahlédnout do jejich záloh ke stanovení doby a metody narušení.

Jakmile vyšetřování zjistí směr narušení [kudy proniklo], bude operační systém úplně vymazán a reinstalován z bezchybné referenční zálohy, jakékoli známé zranitelnosti (zejména ty již [útočníkem] využité opraveny záplatami, všechna lokální hesla a páry klíčů změněny a vytvořena nová bezchybná referenční záloha, než může být systém vrácen do provozu služby.

5.5.3. Potenciální prozrazení uživatelských dat

Uživatelská data neexistují jinde než v databázích; je-li podezřelá integrita databáze, musí být ze služby odstraněna, dokud není incident urychleně vyšetřen, provedena příslušná protiopatření a databáze obnovena do bezchybného stavu. Všichni ovlivnění uživatelé musí být zpraveni o narušení a o možnosti, že některé změny mohly být ztraceny [vráceny ke stavu před změnou].

5.5.4. Prozrazení kořenového klíče

Je-li prozrazen kořenový klíč:

  1. Je umístěn off line, včetně svých podkořenů.
  2. Je odvolán
    • v CRL (podkořeny) nebo
    • oznámením prodejcům (pouze kořenový klíč). Viz oddíl 9.2.4.
  3. Je vyvolána procedura pro nový kořenový klíč. Viz oddíl 9.2.1.
  4. Je instalován nový kořenový klíč.
  5. Certifikáty jsou odvolány a Členové instruováni, aby si dali vystavit nové certifikáty

(jako výše, platí totéž i pro podkořen, existuje-li).

5.5.5. Kompromitování aplikace

Pokud je kompromitována aplikace:

  1. Kontaktovat vývojáře aplikace.
  2. Uschovat relevantní logy, kód, soubory, podle rady vývojáře aplikace.
  3. Vytvořit nouzové patche (vývojář).

(Vývojář aplikace může být zároveň jejím prodejcem.)

5.5.6. Obnova po prozrazení nebo narušení

Jakmile je poškození posouzeno a je zjištěno prozrazení nebo narušení, dohodněte se s arbitrem na opravných procedurách.

5.6. Hlášení

Hlášení. Konečné hlášení bude zapsáno na wiki a oznámeno všem poškozeným stranám (správcům systémů, Výboru, vývojářům softwaru, secure-u, obětem z řad uživatelů). Mělo by obsahovat:

Odkazy na hlášení jdou z SecurityManual/IncidentReports/

Utajení. Události by se neměly utajovat, pokud neexistuje jasné a aktuální nebezpečí dalších bezprostředních škod pro uživatele. Jakákoli utajenost by závažně omezila schopnost jiných členů pomoci vyřešit danou záležitost, a obvykle to přinese více škody než užitku. Jakákoli tajná událost musí být předložena arbitrovi. Samotná událost by neměla být utajena, avšak podrobnosti hackerského zásahu mohou být embargovány. Událost by měla být ihned zahájena jako spor za účelem vytvoření přehledu a potvrzení rozhodnutí udržet detaily pod pokličkou.

Odhalení průniků a chyb by mělo být provedeno co nejdříve. Není třeba působit nepříjemně nebo děsit lidi. Je-li třeba, určete pokročilejšího Člena, aby sledoval fóra, čistě pro přípravu zpřístupnění informací.

6. OBNOVA PO HAVÁRII

KDO udržuje tento oddíl?? Diskuse.

TBD

ROZPRACOVÁNO

Dále popsaný proces je navržen dle hledisek CISA.

6.0.1. Poznámky

6.1. Provozní procesy

Provozní procesy udržuje Výbor.

6.1.1. Základní procesy

Obnovení po havárii stanoví základní procesy jako:

  1. kritické systémy
  2. OCSP/CRL servery

6.2. Doby obnovy

Obnovení po havárii stanoví dobu obnovy služeb odvolání na 27 hodin.

6.3. Plán

  1. Avízo klíčovým osobám podle seznamu.
  2. Výbor sestaví a uvědomí potřebný tým
  3. Tým obnovení po havárii (Disaster Recovery) se sejde.
  4. Plánování a odpověď.

6.4. Seznam klíčových osob

Výbor jmenuje důvěryhodný tým klíčových účastníků, včetně:

Všichni členové tohoto týmu obdrží rozpis se všemi potřebnými kontakty na každého člena týmu. Podrobné umístění, správu, distribuci a aktualizaci tohoto rozpisu dokumentuje Procedura seznamu klíčových osob (Key Persons List Procedure).

7. VÝVOJ SOFTWARU

Tento oddíl je udržován vedoucím týmu Hodnocení softwaru (Software Assessment).

Odkazy na jiné dokumenty:

7.1. Oprávnění

Vedoucí týmu vývoje softwaru odpovídá za bezpečnost kódu.

7.2. Úkoly

Primárním úkolem je audit a verifikace kódu, nikoli psaní kódu. Předložit změny kódu ke schválení může v podstatě každý.

Některé přídavné úkoly, je-li dostatek času:

7.3. Úložiště

Integrita centrální verse řídicího systému je klíčová pro integritu aplikací běžících na kritických systémech, takže (počítačový) systém hostící system systém řízení versí musí být spravován pečlivě (avšak v tomto typu systému se nepoužívá šifrování dat).

To je zvláštní. Znamená to, že toto je kritický systém, nebo ne?

7.4. Revize

Tým Hodnocení softwaru (Software Asessment) odpovídá za předávání záplat [tj. zejména oprav chyb], které předložili vývojáři komunity CAcert. Tým Hodnocení softwaru se postará, aby všechny záplaty předané týmu Zaručení kvality (Quality Assurance) sledovaly pravidla kódování CAcert a obsahovaly dostatečné instrukce pro aplikaci na testovém systému. Tým Hodnocení softwaru předá záplaty, předložené vývojáři, týmu Zaručení kvality, který otestuje, zda jsou změny funkční dle požadavků.

7.5. Test a chyby

Nynější testový systém je udržován zde. Systém komunikace o chybách je udržován na https://bugs.cacert.org/.

Účty na obou systémech jsou dostupné na žádost Členům (na úrovni zaručovatele) po kontrole malého stupně.

Malý stupeň kontroly... co to znamená?

7.6. Výroba

Výroba je ROZPRACOVÁNA (work-in-progress):

Po kladné odezvě od týmu Zaručení kvality (Quality Assurance) přesunou hodnotitelé SW (Software Assessors) záplaty do nové revize a připraví build pro správce systémů, aby ti mohli zavést změny do provozního systému.

Dodávka záplaty nebo aktualizace týmu správců systémů je hlavním úkolem a vyžaduje, aby oba týmy byly dostupné po určitou dobu.

8. PODPORA

Tento oddíl je udržován vedoucím týmu Podpory (Support).

8.1. Oprávnění

Výbor jmenuje vedoucího týmu Podpory, aby vedl tým podpory: m20100222.1.

Software pro ukládání informací o Členech (čili web) je zpravidla řízen CCS (Konfigurace-řídicí specifikace, Configuration-Control Specification), viz DRC-A.1.i. Také software pro "komunikaci s odběrateli a s veřejností vůbec" je specifikován tak, že podléhá řízení.

Iang: Nyní (kdy?) provozuje CAcert dva druhy softwaru pro komunikaci s odběrateli a širokou veřejností:

  1. Web, který má své webové uživatelské rozhraní, a databázi e-mailů členů pro formální komunikaci. Tato databáze e-mailů se používá výhradně pod řízením softwaru a pod řízením arbitra, obojí podle CCS.

  2. Skupina serverů "infrastruktury": wiki, mail, blog, lists [seznamy]. Nejsou řízeny auditem, DRC, CCS, ani Zásadami bezpečnosti (Security Policy). Tato skupina obsahuje nástroje podpory schránek (stará) a OTRS na issue.cacert.org (nová).

Oprávnění pro každou akci Inženýra podpory (Support Engineer) poskytuje:

8.2. Odpovědnosti

8.2.1. Inženýři podpory

Inženýři podpory (Support Engineers, "SE") provádějí toto:

8.2.2. Zapnutí rolí

Inženýr podpory (SE) odpovídá za zapnutí rolí, jakmile dostane oprávnění.

Existují tyto role:

  1. umístění

    • umožňuje uživateli měnit databázi umístění
    • provádí se přidanou položkou menu

  2. správa:

    • tato role se rutinně dává Inženýrům podpory (SE).
    • základní přístup k účtům, může vidět více potenciálně soukromých údajů uživatele,
    • ukazuje další menu,
    • pohled do účtů,
    • změny data narození (DoB), jméno/název, heslo
    • odstranit zaručení (ale nemůže změnit body)
    • nastavit příznaky:
      • příznak správce organizace (O-Admin) v účtu
        • umožňuje vytvářet nové účty organizací
        • další menu ke správě Správce organizace (OA)
      • nastavuje příznak pro podepisování kódu
        • umožňuje uživateli vystavovat si certifikáty pro podepisování kódu

        • řízeno CPS 4.2.6 (Přehled postupů certifikace 4.2.6), který stanoví: "Certifikáty pro podpis kódu jsou dostupné pouze zaručovatelům."

        • byla by chyba udělat změnu softwaru, aby to dělal automaticky?
        • nebo, aspoň nyní, aby Podpora praktikovala u všech zaručovatelů nastavení tohoto příznaku.
      • zamyká účet, aby nemohl uživatel zaručovat,
      • zamyká účet, aby se uživatel nemohl přihlásit,
      • zapíná pro uživatele proces zaručení Tverify,
      • nastavuje roli správce (Admin) (to může nastavit kterýkoli správce s rolí Admin)
      • Správce organizace
      • nastavuje příznak TTP

  3. role Tverify

    • povoluje uživateli přidat další body - ???? netestováno
  4. "zrušit účet" jen označí účet jako nepřístupný
    • pro skutečné zrušení/smazání musí zašifrovat data

  5. role propagace

  6. role TTP

    • zeptejte se Roberta, jak role TTP funguje

    • potřebuje 200 "starých bodů"

  7. Zaručovatel organizací (Organisation Assurer, OA)

    • OA vytváří účet organizace
      • příznak Zaručovatele organizace (Org-Assurer) - ???? kontrola názvu
    • Proces:
      • OA přidává domény
      • OA přidává Správce organizací (O-Admins) dané organizace do účtu organizace
      • Podpora posílá e-mail Správcům organizací (O-Admins), ptá se, mají-li nová menu pro tvorbu certifikátů organizace.

  8. role Správce organizace (Organisation Administrator, O-Admin)

    • Kterýkoli Správce organizace (O-Admin) může vydávat certifikáty, jednat za organizaci
    • O-Admin s 50 body zaručení může být označen jako MASTER
    • MASTER může také přidávat nové podsprávce (sub-Admins)

    • chyba, všichni správcové organizací (O-Admins) musí být zaručovatelé, podle Zásad zaručování (AP) nebo Zásad zaručování organizací (OAP).

8.2.3. Triage [Třídění]

Vedoucí týmu podpory jmenuje a řídí tým prvních reagujících osob, známý jako Triage (třídění). Jeho role je přísně omezena na analýzu přicházejících žádostí o podporu a směrovat je na příslušná místa. Namá přístup ke speciálním funkcím.

Členové týmu Triage musí být zaručovatelé a musí souhlasit s prací podle Zásad bezpečnosti (Security Policy) a této příručky, avšak v současnoszi se u nich nevyžaduje ABC (Arbitrated Background-Check, asi: arbitrážní ověření). Viditelná informace a prováděné akce jsou zhruba podobné, jako u zaručovatelů. Triage se považuje za trénink na Inženýra podpory (Support Engineer) a další role v CAcert.

8.2.4. Vedoucí týmu Podpory

Vedoucí týmu Podpory odpovídá za:

8.3. Kanály

Příchozí komunikace nastává na základě těchto metod:

Triage (Třídění) může předat komunikaci ze support@ do těchto kanálů:

Inženýři podpory (SE) nyní udržují polosoukromou místnost v IRC na #se pro všechny členy podpory a privátní seznam adresátů cacert-support-engineer@.

Zmíněné systémy (schránka, OTRS, IRC, seznam adresátů otevřeného fóra pomoci) představují systémy "infrastruktury" udržované na virtuálních strojích (VM) týmem infrastruktury. Tyto systémy nejsou dosud označeny Výborem jako "kritické systémy" a nejsou proto přísně vázány Zásadami bezpečnosti (Security Policy).

Inženýři podpory mají přístup přes webové nástroje podpory, k tomu mají oprávnění podle oddílu 3.4.2. Triage tento přístup nemá.

8.4. Záznamy a žurnály (logy)

Každý návod od arbitra přichází s ŽETONEM [TOKEN].

Všechny kanály podpory spadají pod žurnál.

8.5. Arbitráž

Arbitráž je hlavní odpovědností týmu podpory:

Vedoucí týmu odpovídá za revizi rozhodnutí založit, a rozhodnutí nezaložit.

8.6. Odkazy

9. ADMINISTRATIVA

Tento oddíl je řízen Výborem.

9.1. Personální věci

9.1.1. Role a odpovědnosti

Některé přídavné úkoly rolí:

9.1.2. Personální úrovně

Každý tým má alespoň 3 osoby, raději více. Vedoucí týmu by se měl přímo podílet na náborové kampani. Až se tým rozšíří, podílí se vedoucí týmu méně na vlastní práci týmu a více se věnuje koordinaci a budování týmu.

9.1.3. Postup u nových členů týmu

Obecný postup:

  1. Tým navrhne přibrat někoho.
  2. Tým provede přípravu a interview.
  3. Ověření nového člena se spustí zahájením sporu v arbitráži.
  4. Nařízení a doporučení arbitráže se předloží Výboru ke schválení.
  5. Výbor nového člena schválí.
  6. Tým novou osobu začlení.

9.1.4. Procedury ověření

Ověření nového člena se spustí zahájením sporu, jmenováním osoby angažované jako respondent. Použije se arbitráž jako administrativní krok, což neznamená, že by vznikl "spor" vedený proti oné osobě. Bude zvolen arbitr, který není závislý na osobách, ale je znalý dané oblasti. Manažer případu (Case Manager) poskytne podporu a naplní roli "čtyř očí".

Ověření nového člena je vedeno podle směrnic daných arbitrem. Procedura ověření je proto primárně řízena arbitrem a změny navržené jinou osobou se provedou podle výsledku konsultace.

Procedura ověření (též Arbitrážní ověření, Arbitrated Background Check, ABC) je řízena arbitrem.

9.1.4.1. Rozsah

Vyšetřování prozkoumá:

9.1.4.2. Pokrytí

Interview odhalí, se kterými zásadami ověřovaný souhlasí a zjistí jakékoli výhrady, které by kandidát mohl mít.

9.1.4.3. Dokumentace

Arbitr po vydání nařízení shromáždí a udržuje dokumentaci.

Arbitr musí od kandidáta získat právně závaznou dohodu ohledně platných zásad a procedur pro účely běžného zabezpečení (včetně mlčenlivosti, důvěrnosti, ochrany soukromí a/nebo smluv specifických vzhledem k úkolům). Metoda získání závazné dohody je (v současnosti) věcí arbitra.

Ověření je podporováno týmy, nebo osobou řízenou Výborem.

9.1.4.4. Ochrana soukromí pro kritické role

9.1.5. Oprávnění

9.1.6. Bezpečnost

Záležitosti bezpečnosti budou hlášeny vedoucímu týmu a založeny jako bezpečnostní chyba/selhání. Není-li uspokojivě vyřešena, bude ohlášena Výboru Board nebo bude zahájen spor. Vedoucí týmů nesmí stát v cestě eskalaci a podpoří aktivní pozorování ze strany Členů a eskalace v nejistých záležitostech tak, aby byla získána praxe/praktika. Bez důvěry v eskalaci by členové mohli příliš váhat se ozvat.

9.1.7. Ukončení působnosti

Jsou nutné tyto kroky:

  1. Veřejné klíče SSH dané osoby se zablokují.
  2. Hlavní "tajemství" se změní (například hesla roota, SSH klíče serveru)
  3. Nižší hesla se analyzují na citlivost (například hesla databáze)
  4. Účty, záznam aktivit atd., jsou dána do úschovny (escrow).
  5. Kopie uschovaných kořenových klíčů nebo záloh se zabezpečí.

Vedoucí týmů také zajistí body 1,2 výše, když osoba přenese svou aktivitu (přejde) z jednoho týmu do jiného.

9.1.8. HR(?) a školení

Existují testy technických znalostí týmů. Téměř formální kvalifikace ve věcech bezpečnosti má váhu, není však požadována. Některé role vyžadují širší znalost bezpečnostních praktik.

Poznámka: bude připraveno školení a (CATS) testy pro některé části tohoto procesu.

9.2. Správa kořenového klíče

9.2.1. Generování kořenového klíče

Procedura generování kořenových klíčů je umístěna zde.

9.2.2. Záloha a úschovna (escrow)

Média. Jako úschovna kořenových klíčů budou použity dva USB "disky" (dva spolu slepené - z důvodu spolehlivosti). Bude použito dvojité zašifrování, a to systému souborů a OpenPGP. Hesla musí být generována automaticky a ručně přenesena na papír.

Pod-kořeny: kopii uschová vedoucí týmu Správců systémů. Hesla mají členové týmu. pro účely obnovy po havárii jsou jak podkořeny, tak doprovodná hesla také uschována Výborem, a to stejným způsobem, jako kořen nejvyšší úrovně.

Výbor se má poradit, jak je třeba uschovat kořen nejvyšší úrovně.

Poznámka: stále zbývá vyřešit záležitost CRL, který je třeba vytvořit v rozumné době pomocí kořene nejvyšší úrovně (podepíše CRL pomocí podkořenů.

9.2.3. Obnova

Procedura pro obnovu kořenů ze zálohy a úschovny (výše) bude umístěna zde.

ale není dosud napsána.

9.2.4. Odvolání

Oprávnění k odvolání vydá Výbor nebo arbitr, viz oddíly 5, 6.

Metoda. Kontaktovat každého prodejce a zaznamenat chybu, vyžádat označení kořene jako "nedůvěryhodného" [untrusted] v prodejcově seznamu kořenových certifikátů. Být připraven potvrdit žádost komunikací přes zabezpečený kanál.

Poznámky:

9.3. Právní aspekty

9.3.1. Odpovědnost

Konečnou odpovědnost v právních záležitostech má Výbor.

9.3.2. Odpověď na (právní) dotaz zevně komunity

Nemáte oprávnění odpovídat na dotazy ohledně bezpečnosti nebo právního importu. Arbitrova nařízení vás mohou instruovat a stát se vaším oprávněním jednat. Toto ustanovení je velmi silné a je zde pro vaši vlastní ochranu a ochranu celé komunity Členů.

Může být proti vám použito sociální inženýrství, abyste byli donuceni porušit toto pravidlo. Dejte vědět vedoucímu svého týmu a/nebo důstojníkovi pro bezpečnost o každém požadavku přicházejícím mimo formální kanály, i když je třeba triviální.

Zde pravděpodobně potřebujeme procedury/příručku sociálního inženýrství.

9.4. Outsourcing

Fyzická aktiva a hosting jsou zpravidla poskytována a udržována, jak je stanoveno v Memorandu porozumění mezi CAcert a secure-u z 24. června 2013 a občas doplňováno/upravováno. Ke změnám MoU je nutné schválení oběma Výbory, jak CAcert, tak secure-u. Uvědomte si, že před MoU mezi CAcert a secure-u platilo velmi podobné MoU mezi CAcert a Stichting Oophaga, původně dohodnuté 10. července 2007 a naposledy doplněno 9. června 2009. Všechny tyto dokumenty lze nalézt zde: svn CAcert_Inc/hosting.

MoU stanoví, že odpovědnost za fyzické změny/doplňky (hardwaru), hostování a řízení přístupu k hardwaru má secure-u.

secure-u sestavuje hostingovou smlouvu s BIT, Ede.

9.5. Důvěrnost, utajení

Kritické role CAcert se vzdávají určitého dílu ochrany soukromí, aby zachovaly soukromí ostatních.

10. ZDROJE

10.1. Kontakty

Poznámka: Všechny seznamy adresátů se v současnosti provozují na "infrastruktuře" strojů, které nejsou kritické. Sledujte.

10.1.1. Kontaktní seznam klíčových osob

Procedura pro udržování a distribuci seznamu soukromých kontaktů klíčových osob je dokumentována v SystemAdministration/Procedures/KeyPeopleContacts.

10.2. Dokumenty

  1. Zásady bezpečnosti (Security Policy) jsou pod CCS pro účely auditu.

  2. Memorandum porozumění (MoU) se secure-u je umístěno v https://svn.cacert.org/CAcert/CAcert_Inc/hosting/MoU-CAcert-secure-u-20130624-michael-bernhard-sebastian-werner-sig.pdf

Seznam procedur:

  1. CategoryProcedures
  2. Community/HomePagesMembers/EvaStöwe/KPL_process
  3. Roots/CreationCeremony
  4. SecurityManual
  5. SecurityManual/CZ
  6. Software/Assessment/Documentation/EmergencyPatches
  7. SystemAdministration
  8. SystemAdministration/Procedures/CertificateIssuing
  9. SystemAdministration/Procedures/DNSChanges
  10. SystemAdministration/Procedures/DiskEncryption
  11. SystemAdministration/Procedures/DiskMirroring
  12. SystemAdministration/Procedures/DriveRetirement
  13. SystemAdministration/Procedures/FirewallChanges
  14. SystemAdministration/Procedures/FullBackupRestore
  15. SystemAdministration/Procedures/InfrastructureTeam
  16. SystemAdministration/Procedures/KeyPeopleContacts
  17. SystemAdministration/Procedures/KeysEscrow
  18. SystemAdministration/Procedures/OcspResponder
  19. SystemAdministration/Procedures/OperatingSystemPatches
  20. SystemAdministration/Procedures/PasswordManagement
  21. SystemAdministration/Procedures/SoftwarePatches

10.2.1. Poskytnout / najít

10.3. Související dokumenty

[Český překlad dokumentů zásad, včetně CPS, je umístěn zde.]

SecurityManual/CZ (last edited 2016-11-06 12:07:41 by AlesKastner)