Vítejte na blog.vyvojar.cz Přihlásit | Registrovat | Pomoc

DS5 Zabezpečení systémové bezpečnosti

Článek ze série COBIT
DS5.1 Management IT bezpečnosti

Spravuj IT zabezpečení na nejvyšší odpovídající organizační úrovni, tak aby řízení bezpečnostních opatření bylo v souladu s obchodními požadavky.

DS5.2 IT Plán bezpečnosti

Využij požadavky business informací, IT konfiguraci, akční plány rizikových informací a kulturu bezpečnosti informací pro celkový IT bezpečnostní plán. Plán bude implementován z bezpečnostních politik a postupů spolu s příslušnými investicemi do služeb, personálu, software a hardware. Bezpečnostní politiky a postupy musí být sděleny zúčastněným stranám a uživatelům.

DS5.3 Správa totožností

Všichni uživatelé (interní, externí a dočasné) a jejich činnosti v IT systémech (obchodní aplikace, provoz systému, vývoj a údržba) by měly být jednoznačně identifikovatelné. Přístupová práva uživatelů do systémů a dat by měly být v souladu s definovanými a dokumentovanými obchodními potřebami a pracovními požadavky. Přístupová práva uživatelů musí být nastavována na žádost správy uživatelů, po schválení vlastníkem systému a musí být nastavena odpovědnou bezpečnostní osobou. Uživatelské identity a přístupová práva musí být vedeny v centrální evidenci. Musí být nasazeny nákladově efektivní technická a procesní opatření. Tyto opatření musí být udržována aktuální z důvodu identifikaci uživatele, implementace ověřování a dodržování přístupových práv.

DS5.4 Správa uživatelských účtů

Ujisti se, že vytvoření, nastavení, opravy, pozastavení, změna a ukončení uživatelských účtů a souvisejících uživatelských oprávnění jsou řešeny správou uživatelských účtů. Je zohledněna linie schvalovacího řízení datových nebo systémových vlastníků poskytujících přístupová práva. Tyto postupy by měly platit pro všechny uživatele, včetně správců (privilegovaných uživatelů), interní a externí uživatele, pro normální a nouzové případy. Ujisti se, že práva a povinnosti související s přístupem k informacím a podnikovým systémům jsou smluvně uspořádána pro všechny typy uživatelů. Provádějte pravidelné přezkoumání všech účtů a souvisejících privilegií.

DS5.5 Testování bezpečnosti, dohled a monitoring

Ujisti se, že je aktivně sledována a testována implementace bezpečnosti IT. IT bezpečnost by měla být pravidelně re-akreditována, tak aby byla zajištěná správná schválená úroveň zabezpečení. Logování a sledování funkcí umožňuje včasné odhalení neobvyklých nebo abnormálních činností, které může být potřebné řešit. Přístup k logování informací musí být v souladu s business požadavky z hlediska přístupových práv a požadavků na uchovávání.

DS5.6 Definice bezpečnostních totožností

Ujisti se, že vlastnosti potenciálních bezpečnostních incidentů jsou jasně vymezeny a sděleny tak, že bezpečnostní incidenty mohou být řádně vyřešeny podle události nebo procesem správy problémů. Charakteristika musí obsahovat popis toho, co je považováno za bezpečnostní incident a jeho stupeň dopadu. Omezený počet úrovní dopadů musí být definován pro každý nutný konkrétní krok a lidé, kteří musí být informování, musí být správně identifikováni.

DS5.7 Ochrana bezpečnostní technologie

Ujisti se, že důležité bezpečnostní technologie jsou odolné proti neoprávněnému zásahu a bezpečnostní dokumentace není zbytečně zveřejněna, tj. udržuje nízký profil. Nicméně nevytvářej závislost zabezpečení systémů na tajemstvích v bezpečnostních specifikacích.

DS5.8 Správa šifrovacích klíčů

Zajisti, aby byly k dispozici zásady a postupy pro generování, změny, zrušení, zničení, distribuci, certifikace, skladování, uvedení, používání a archivaci kryptografických klíčů. Tak aby byla zajištěna ochrana klíče před neoprávněným zveřejněním a modifikacemi.

DS5.9 Prevence, detekce a korekce škodlivého software

Zajisti, aby byly k dispozici preventivní, detektivní a nápravná opatření (zejména aktuální bezpečnostní záplaty a antivirus) v rámci organizace pro ochranu informačních systémů a technologií před malwarem (viry, červy, spyware, spam, interně vyvinuté podvodné software atd.).

DS5.10 Bezpečnost sítě

Ujisti se, že jsou používány bezpečnostní techniky a související postupy pro řízení (např. firewally , bezpečnostní zařízení, segmentaci sítě a detekce narušení) a pro autorizaci přístupu a toky řídicích informací z/do sítě.

DS5.11 Výměna citlivých dat

Ujisti se, že citlivé transakční data jsou distribuována jen přes důvěryhodné cesty nebo média s kontrolami tak, abyste poskytli pravost obsahu, doklad o vydání, doklad o převzetí a nepopiratelnost původu.

Článek ze série COBIT

Posted by dotnet | 0 Comments

DS4 Zajištění kontinuity služeb

Článek ze série COBIT

DS4.1 IT Continuity Framework

Vytvoř Framework pro IT kontinuitu podpory firemního nepřetržitého provozu konzistentním procesem. Cílem Frameworku je pomáhat určovat požadované odolnosti infrastruktury a řídit vývoj zotavení po havárii a IT pohotovostní plány. Framework by měl řešit organizační strukturu pro řízení kontinuity, pro pokrytí rolí, úkolů a povinností interních a externích poskytovatelů služeb, jejich řízení a jejich zákazníky, zdokumentované pravidla a struktury, testování a spouštění obnovení po zhroucení a IT pohotovostní plány. Plán by měl také řešit položky, jako je identifikace kritických zdrojů, monitorování a podávání zpráv o dostupnosti kritických zdrojů, alternativních postupů, a zásady zálohování a obnovení.

DS4.2 IT Continuity Plans

Rozvíjej IT plány kontinuity na základě Frameworku určeného ke snížení dopadů závažného narušení klíčových podnikových funkcí a procesů. Tyto plány by měly zohlednit požadavky na odolnost, alternativní zpracování a využití schopností všech kritických IT služeb. Měly by také zahrnovat pokyny pro používání rolí a povinností, postupy, komunikační procesy a přístup k testům.

DS4.3 Kritické IT zdroje

Zaměř pozornost na položky uvedené jako nejkritičtější v IT kontinuity plánu pro vybudování odolnosti a stanovení priorit pro záchranné situace. Vyhni se rozptylujícím méně důležitým položkám a zajistěte reakci a obnovu v souladu s prioritní potřeby podniku, a zároveň zajistěte, aby náklady byly na přijatelné úrovni a byly v souladu s regulačními a smluvními požadavky. Zvaž požadavky na odolnost, reakce, obnovu na různých úrovních, např. jednou až čtyři hodiny, čtyři až 24 hodin, více než 24 hodin a kritické business provozní období.

DS4.4 Správa IT kontinuitního plánu

Přesvědč IT management, aby definoval a realizovat postupy pro kontrolu změn, aby byl plán IT kontinuity aktualizován a stále reflektoval aktuální obchodní požadavky. Je nezbytné, aby změny v postupech a povinností být sděleny jasně a včas.

DS4.5 Testování plánu IT kontinuity

Testuj pravidelně IT plán kontinuity s cílem zajistit to, aby mohl být IT systém navrácen, nedostatky byly adresovány a aby byl plán i nadále relevantní. Toto vyžaduje pečlivou přípravu, dokumentaci, reportování výsledku testů a samozřejmě úpravu akčního plánu podle výsledků. Zvaž, do jaké míru je nutné testování obnovy jednotlivých aplikací pro E2E integrované testovací scénáře a integrované dodavatelské testování.

DS4.6 Školení IT plánu kontinuity

Zajisti, aby všechny zúčastněné strany dostávaly pravidelné školení týkající se postupů a jejich role a odpovědnosti byly jasně stanoveny pro případy nehody nebo katastrofy. Ověř, a posil odbornou přípravu v souladu s výsledkem pohotovostních zkoušek.

DS4.7 Distribuce IT plánu kontinuity

Stanov a definuj řízení distribuční strategie proto, aby zajistily správnou a bezpečnou distribuci plánů a aby byly vždy a všude k dispozici pro patřičné oprávněné zúčastněné strany. Pozornost věnuj tomu, aby plány byly přístupné v rámci všech scénářů katastrof.

DS4.8 IT obnovení a pokračování služeb

Naplánuj akce, které mají být provedeny v období, kdy se zotavuje a obnovuje služba. To může zahrnovat aktivaci záložních míst, zahájení alternativního zpracování, zákazníky, komunikaci na zainteresované strany, obnovení řízení, apod. Zajisti, aby firma chápala doby obnovení a nezbytné investice do technologií pro podporu oživení business a všechny potřeby pro obnovení.

DS4.9 Vnější záložní úložiště

Uchovej mimo vaši lokalitu všechny kritické zálohovací média, dokumentace a další IT zdroje potřebné k plánu obnovy a obchodní kontinuity. Obsah ukládání záloh musí být určen, ve spolupráci vlastníků podnikových procesů a IT personálu. Vedení offsite skladu by měla reagovat na klasifikaci politik dat a praxi práce s podnikovými paměťovými médii. IT management musí zajistit, aby opatření mimo pracoviště byly pravidelně přehodnoceny (nejméně jednou ročně), dále jejich obsah, ochranu prostředí a bezpečnosti. Zajisti kompatibilní hardware a software pro obnovení archivovaných dat a pravidelně testuj a aktualizuj archivovaná data.

DS4.10 Revize po obnovení

Po úspěšném obnovení IT zjisti, zda vedení zavedlo postupy pro posouzení způsobilosti plánu a aktualizujte patřičně plán.

Článek ze série COBIT

Posted by dotnet | 0 Comments

DS3 Správa výkonu a kapacit

Článek ze série COBIT
DS3.1 Plánování výkonu a kapacity

Zaveď proces plánování k přezkumu výkonu a kapacity IT zdrojů tak, aby bylo zajištěno, že náklady, kapacity a výkon jsou k dispozici pro dodání dohodnuté zátěže, stanovené na základě dohod o úrovni služeb. Využij odpovídajícím modelovacími technikami kapacitu a plány výkonnosti k výrobě modelu současného a očekávaný výkonu, kapacity a propustnosti IT zdrojů.

DS3.2 Aktuální kapacita a výkonnost

Zkontroluj aktuální výkonnost a kapacitu IT zdrojů tak, abyste zjistily existenci dostatečné kapacity a výkonnosti, která bude dodána podle dohody o úrovni poskytovaných služeb.

DS3.3 Budoucí kapacita a výkon

Prováděj v pravidelných intervalech prognózy výkonu a kapacity IT zdrojů tak, aby se minimalizovalo riziko přerušení služby z důvodu nedostatečné kapacity nebo snížení výkonu. Také identifikuj nadbytečné kapacity pro případné využití. Identifikuj trendy pracovního vytížení a urči prognózu pro vstup do plánů výkonu a kapacit.

DS3.4 IT Dostupnost zdrojů

Poskytni požadovanou kapacitu a výkon, které zohlední aspekty, jako je běžné zatížení a události, požadavky na úložiště a IT životní cykly. Musí být přijato zaopatření pro případ, že výkon a kapacita nejsou na požadované úrovni, například: stanovení priorit úkolů, mechanismy tolerance poruch a postup pro přidělování zdrojů. Management by měl zajistit, aby pohotovostní plány řádně adresovali dostupnost, kapacitu a výkon jednotlivých IT zdrojů.

DS3.5 Monitoring a reporting

Průběžně sleduj výkon a kapacitu IT zdrojů. Shromážděné údaje použij k dvěma účelům:

• Zachování a vyladění aktuální výkonnosti v oblasti IT, jako je odolnost a události, současných a plánovaných množství práce, skladování plánů a získávání zdrojů

• Reporting dostupnosti služeb pro business, jak vyžaduje SLA. Dodávat reporty výjimek s doporučeními pro nápravné opatření.

Článek ze série COBIT

Posted by dotnet | 0 Comments

DS2 Správa služeb třetích stran

Článek ze série COBIT
DS2.1 Identifikuj všechny vztahy dodavatelů

Identifikuj všechny dodavatelské služby a roztřiď je podle typu dodavatele, významu a kritičnosti. Udržuj formální dokumentaci technických a organizačních vztahů, které pokrývají role a povinnosti, cíle, očekávané přínosy a pověřené zástupce těchto dodavatelů.

DS2.2 Správa vztahů s dodavateli

Formalizuj vztah s dodavateli pro řízení procesů každého dodavatele. Tyto vztahy musí zajistit spolupráci při řešení zákaznických a dodavatelských problémů. Navíc musí sloužit pro zajištění kvality vztahů založených na důvěře a transparentnosti (např. na základě dohod o úrovni poskytovaných služeb).

DS2.3 Správa dodavatelských rizik

Identifikuj a trvale zmírňuj rizika týkající se schopnosti dodavatele pokračovat v efektivním poskytování služeb v oblasti bezpečnosti. Zajisti smlouvy v souladu s univerzálními business normami v souladu s právními a správními předpisy. Řízení rizik by mělo zvažovat utajení informací (NDAS), smlouvy třetích stran, životaschopnost dodavatele, posuzování shody s bezpečnostními požadavky, alternativní dodavatele, penále, odměny apod.

DS2.4 Monitoring výkonnosti dodavatele

Stanov trvalý postup pro sledování poskytování služeb, aby dodavatel splňoval aktuální obchodní požadavky a aby dodržoval smluvní dohody a dohody o úrovni poskytovaných služeb. Navíc ověř, že je jejich výkon konkurenceschopný s alternativními dodavateli a podmínkami na trhu.

Článek ze série COBIT

Posted by dotnet | 0 Comments

DS1 Definice a správa servisního stupně

Článek ze série COBIT

DS1.1 Framework správy servisních stupňů

Definuj Framework, který poskytuje formalizovaný Service Level Management proces mezi zákazníkem a poskytovatelem služeb. Framework bude sloužit pro správu trvajícího sbližování obchodních požadavků a priorit, usnadní vzájemné porozumění mezi zákazníkem a poskytovatelem. Tento Framework musí zahrnovat procesy pro vytváření požadavků na servis, servisní definice, dohody o úrovni služeb (SLA), provozní stupeň dohod (OLAS) a zdroje financování. Tyto atributy budou uspořádány v katalogu služeb. Framework definuje organizační strukturu pro řízení úrovně služeb, která bude zahrnovat postavení, úkoly a povinnosti interních a externích poskytovatelů služeb a jejich zákazníky.

DS1.2 Definice služeb

Je základní definice IT služby charakterizovaná popisem služby a business požadavky, které jsou organizovány a uloženy centrálně ve formě katalogu služeb / portfolia.

DS1.3 Dohody o úrovni služeb

Definuj a dohodni úroveň poskytovaných služeb pro všechny kritické oblasti IT služeb na základě požadavků zákazníka a možností IT. Toto zahrnuje závazky vůči zákazníkům, požadavky na servisní podporu, kvantitativní a kvalitativní metriky pro měření služeb, podepsané zúčastněnými stranami, financování, obchodní vztahy, role a povinnosti, včetně dohledu nad SLA. Položky, na které je potřebné dohlédnout: dostupnost, spolehlivost, výkon, kapacita pro růst, úroveň podpory, plánování kontinuity, bezpečnosti a omezení.

DS1.4 Provozní úroveň dohod

Ujistěte se, že dohody o provozní úrovni optimálně vysvětlují, jak budou služby technicky doručeny na podporu SLA. OLAs specifikuje technické procesy z hlediska významu pro poskytovatele a může podporovat několik SLA.

DS1.5 Monitoring a reporting Monitoring dosažených výsledků služeb

Průběžně sleduj stanovená kritéria služeb úrovně výkonu. Zprávy musí být k dispozici ve formátu smysluplném pro zúčastněné strany, tak aby dosáhly patřičné úrovně služeb. Monitorovací statistiky musí být analyzovány a musí být schopny identifikovat negativní a pozitivní trendy pro jednotlivé služby, stejně jako pro kompletní služby.

DS1.6 Kontrola stupně servisních dohod a smluv

Pravidelně přezkoumávej dohody o úrovni služeb a podpůrné smlouvy s interními a externími poskytovateli služeb, abys zajistil, že jsou efektivní, aktuální, a že změny v požadavcích byly vyčísleny.

Článek ze série COBIT

Posted by dotnet | 0 Comments

AI7 Instalace a akreditace řešení a změny

Článek ze série COBIT
AI7.1 Školení

Vyškol pracovníky příslušného oddělení a provozu tak, aby fungovaly v souladu s definovanými školeními a implementačním plánem a souvisejícími materiály, jako součást každého rozvoje informačních systémů, implementace a úprav projektu.

AI7.2 Testovací plán

Vytvoř testovací plán a získej potvrzení od příslušných účastníků. Testovací plán musí být založen na celo-podnikových normách, vymezovat úkoly, odpovědnosti a kritéria úspěchu. Plán musí zvážit přípravu testů (včetně zařízení prostředí), potřebná školení, instalace nebo aktualizace definovaných testovacích prostředí, plánování / předvádění / dokumentaci / udržování testovacích případů, opravu chyb a formální schválení. Na základě posouzení rizika selhání systému a pádů musí plán zahrnovat požadavky na výkon, stres, použitelnost, pilot a testování zabezpečení.

AI7.3 Plán implementace

Vytvoř plán implementace a získej potvrzení od příslušných stran. Plán musí definovat nasazení, sestavení release balíčků, postupy instalací a zveřejnění, vyřízení mimořádných událostí, distribuce kontroly (včetně nástrojů), úložiště software, revizi releasů a dokumentaci změn. Plán by měl také zahrnovat nouzová / blackout opatření.

AI7.4 Testovací prostředí

Vytvoř samostatné testovací prostředí pro testování. Toto prostředí by mělo odrážet budoucí provozní prostředí (např. stejná bezpečnost, vnitřní kontroly a pracovní zátěže), které umožní řádné testování. Postupy by měly zajišťovat to, že údaje uvedené v testovacím prostředí jsou reprezentací dat, které budou pravděpodobně využity v produkčním prostředí. Vytvoř odpovídající opatření k zamezení úniku citlivých údajů v průběhu testů. Dokumentace výsledků testů musí být zaznamenána a archivována.

AI7.5 Konverze dat a systémů

Ujisti se, že vývojové metody společnosti poskytují, pro všechen vývoj a úpravy projektů, všechny potřebné prvky, jako hardware, software, transakční data, master soubory, zálohování a archivy, rozhraní s jinými systémy, postupy, systém dokumentace apod., a jsou konvertovány od starého systému k novému podle předem stanoveného plánu. Vytvořte a udržujte audity pro postup pre- a post- konverzních výsledků. Podrobné ověření zahájení používání nového procesu nového systému by měly být provedeny vlastníkem za účelem potvrzení úspěšného přechodu na novou funkčnost.

AI7.6 Testování a změny

Ujisti se, že změny jsou testovány v souladu s definovaným akceptačním plánem, jsou kontrolovány dopady, zdroje. Což zahrnuje i nastavení výkonu v samostatném testovacím prostředí a otestování nezávislou testovací skupinou před použitím v běžném provozním prostředí. Paralelní nebo pilotní testování by měly být také součást plánu. Před nasazením testuje bezpečnost, tak aby byla ověřena účinnost zabezpečení. Dále by měly být, před propagací změn do výroby, vyvinuty a otestovány záložní / blackout plány.

AI7.7 Finální akceptační testy

Ujisti se, že existují procedury pro formální hodnocení a schválení výsledků testů vedením ovlivněného oddělení a IT funkce, a to v rámci konečného přijetí nebo zajištění kvality testování nových nebo změněných informačních systémů. Zkoušky by měly zahrnovat všechny složky informačního systému (např. aplikační software, zařízení, technologii a uživatelské postupy) a měly by zajistit, aby byly požadavky bezpečnosti informací splněny všemi komponentami. Testovací data by měla být uložena pro účely auditů a pro budoucí testování.

AI7.8 Propagace do produkce

Implementuj formální postupy pro řízení předání systému, od vývoje až po testování operací v souladu s implementačním plánem. Management by měl vyžadovat, aby vlastník systému povolil (před ukončením starého systému) nový systém, před tím než je přesunut do produkce. Měl by potvrdit, že je nový systém úspěšně provozován ve všech denních, měsíčních, čtvrtletních a ročních cyklech.

AI7.9 Nasazení software

Ujisti se, že se nasazení nové verze softwaru řídí formálními postupy, které zajišťují výstupy, balíčky, regresní testování, distribuci, předání, sledování stavu, záložní procedury a uživatelských notifikace.

AI7.10 Distribuce systému

Zaveď kontrolní postupy s cílem zajistit včasné a správné distribuce a aktualizace schválených konfiguračních položek. Jedná se o kontrolu integrity, rozdělení povinností mezi ty, kteří sestavují, testují a provozují produkt. Také uchovej dostatečný auditní záznam o všech akcích.

AI7.11 Záznam a sledování změn

Zautomatizuj systém pro monitorování změn v aplikačních systémech pro podporu záznamu a sledování změn provedených aplikací, postupů, procesů, parametrů systémů a služeb, a podpůrné platformy.

AI7.12 Post-implementační revize

Zaveď postupy v souladu s rozvojem podniku, které vytvoří přezkum informačního systému, tak aby vyhodnotili reportem to, zda jsou změny splněny podle požadavku zákazníků a že dodává předpokládané výhody co nejhospodárnějším způsobem.

Článek ze série COBIT

Posted by dotnet | 0 Comments

AI6 Správa změn

Článek ze série COBIT
AI6.1 Standardy a procesy změny

Nastav formální postupy řízení změn pro práci standardizovaným způsobem u všech požadavků (včetně údržby a záplaty) na změny v aplikacích, postupech, procesech, systémech, parametrech služeb a platforem.

AI6.2 Posouzení dopadů, prioritizace a autorizace

Ujisti se, že všechny žádosti o změny budou posuzovány strukturovaným způsobem z hlediska dopadů na provozní systém a jeho funkčnost. Toto hodnocení by mělo zahrnovat kategorizaci priorit a změn. Před migrací do produkce musí být změny schváleny příslušnými zainteresovanými stranami.

AI6.3 Nouzové změny

Stanov postup pro definici, vyvolání, posuzování a povolování nouzových změn, které se dotýkají zavedeného procesu. Dokumentace a testování musí být ihned provedena, případně po provedení mimořádné změny.

AI6.4 Změna stavu sledování a reportů

Zřiď sledovací a vykazování systém pro uchování změn žadatelů a pro informovanost příslušných zúčastněných stran o stavu změn aplikace, postupů, procesů, systémů a služeb, parametrů a základní platformy.

AI6.5 Uzavření změna a dokumentace

Vždy, když jsou prováděny změny systému, aktualizujte odpovídajícím způsobem související systém a uživatelskou dokumentaci a postupy. Zaveďte proces kontroly pro kontrolu a zajištění úplného provedení změn.

Článek ze série COBIT

Posted by dotnet | 0 Comments

AI5 Získání IT zdrojů

Článek ze série COBIT
AI5.1 Kontrola získávání

Vytvoř a dodržuj množinu postupů a standardů, které je v souladu s procesem organizace zadávání veřejných zakázek a akviziční strategie tak, aby bylo zajištěno, že pořízení IT infrastruktury, zařízení, hardware, software a služeb splňuje požadavky businessu.

AI5.2 Správa smluv dodavatelů

Stanov postup pro všechny dodavatele pro zřizování, změny a ukončení smlouvy. Postup by měl zahrnovat minimálně tyto závazky: právní, finanční, organizační, dokumentární, výkonnostní, zabezpečení duševního vlastnictví, zánik povinnosti (včetně sankčních ustanovení). Všechny smlouvy a smluvní změny by měly být přezkoumány právními poradci.

AI5.3 Výběr dodavatele

Na základě spravedlivého a formálního postupu vyber dodavatele pro zajištění životaschopného nejvhodnějšího řešení na základě požadavků, které byly vypracovány a na základě informací od potenciálních dodavatelů a uzavřené mezi zákazníkem a dodavatelem (dodavateli).

AI5.4 Pořízení software

Ujisti se, že zájmy organizace jsou chráněny ve všech smluvních dohodách. Což zahrnuje vynucení práva a povinnosti všech zúčastněných stran ve smluvních podmínkách pro získání softwaru týkajícího se dodávky a navazujícího užívání softwaru. Tato práva a povinnosti mohou zahrnovat vlastnictví a licencování duševního vlastnictví, údržby, záruky rozhodčím řízení aktualizaci podmínek a vhodnosti pro daný účel, včetně bezpečnosti, svěřenectví a přístupových práv.

AI5.5 Pořízení zdrojů pro vývoj

Ujisti se, že zájmy organizace jsou chráněny ve všech smluvních dohodách. Což zahrnuje vynucení práva a povinnosti všech zúčastněných stran ve smluvních podmínkách pro získání zdrojů pro rozvoj. Tato práva a povinnosti mohou zahrnovat vlastnictví a licencování duševního vlastnictví, účel, včetně vývoje metodik, jazyků, testování, procesy řízení kvality, včetně požadovaných výkonnostních kritérií, přezkoumání výkonu a mohou být použity jako základ pro platbu, záruky, rozhodčí řízení, řízení lidských zdrojů a dodržování firemní politiky.

AI5.6 Pořízení infrastruktury, zařízení a souvisejících služeb

Zaveď a prosazuj práva a povinnosti všech zúčastněných stran ve smluvních podmínkách, včetně akceptačních kritérií, pro pořízení zařízení infrastruktury a souvisejících služeb. Tato práva a povinnosti mohou zahrnovat úroveň služeb, údržbu, kontroly přístupu, zabezpečení, výkon přezkoumání tak aby tvořily základ pro platbu a rozhodčí řízení.

Článek ze série COBIT

Posted by dotnet | 0 Comments

AI4 Zahájení provozu a používání

Článek ze série COBIT

AI4.1 Plánování provozního prostředí

Vypracujte plán na identifikaci a dokumentaci veškerých technických aspektů, provozní schopnosti a požadované úrovně služeb tak, aby všechny zúčastněné strany mohli přijmout včasnou odpovědnost za řízení výroby, uživatelské a provozní procedury jako důsledek zavedení nebo zdokonalení automatizovaných systémů nebo infrastruktury.

AI4.2 Přenos znalostí na business management

Přenes znalosti na business management tak, aby mohli převzít vlastnictví systému a dat, odpovědnost za poskytování služeb a kvalitu, vnitřní kontrolu a procesy provozu aplikací. Přenesení znalostí by mělo zahrnovat postup schválení, správu oprávnění, rozdělení odpovědností, automatizovanou business kontrolu, zálohování, obnovení, fyzickou bezpečnost a archivaci zdrojových dokumentů.

AI4.3 Přenos znalostí na koncové uživatele

Přenes znalostí a dovedností tak, aby koncoví uživatelé efektivně a účinně využívali aplikační systémy pro podporu business procesů. Předávání znalostí by měla zahrnovat vytvoření tréninkového plánu pro řešení počátečních a průběžných školení, rozvoj dovedností, dále školicí materiály, uživatelské manuály, manuály pracovních postupů, online nápovědu, servis desk podporu, identifikace klíčových uživatelů a hodnocení.

AI4.4 Přenos znalosti na provoz a podpůrný personál

Předej znalosti a dovednosti pracovníkům technického provozu pro vytvoření provozu a umožní efektivně a účinně realizovat, podporovat a udržovat aplikační systémy a související infrastruktury v závislosti na požadované úrovni služeb. Předávání znalostí by měla zahrnovat počáteční a průběžný výcvik a rozvoj dovedností, školicí materiály a příručky a manuály pracovních postupů a scénářů servisu.

Článek ze série COBIT

Posted by dotnet | 0 Comments

AI3 Pořízení a správa technologické infrastruktury

Článek ze série COBIT

AI3.1 Plán na pořizování technologické infrastruktury

Vypracuj plán na pořízení, implementaci a údržbu technologické infrastruktury, která splňuje stanovené business funkční a technické požadavky a je v souladu s firemním směřováním technologií. Plán by měl zvážit budoucí flexibilitu pro přidávání technologie, kapacity přechodných nákladů, technických rizik a životnost investice pro vylepšování technologií. Posuďte náklady a složitost, komerční životaschopnost dodavatele a produktu vždy když přidáváte nové technické možnosti.

AI3.2 Ochrana a dostupnost zdrojů infrastruktury

Proveďte vnitřní kontrolu, zabezpečte a ověřte opatření během konfigurace, integrace a údržby hardware a software pro ochranu zdrojů infrastruktury a zajistěte dostupnost a integritu. Odpovědnosti za používání citlivých komponent infrastruktury by měly být jasně definovány a pochopeny těmi, kteří vyvíjí a integrují komponenty infrastruktury. Jejich používání by mělo být sledováno a vyhodnocováno.

AI3.3 Údržba infrastruktury

Vypracuj strategii a plán pro údržbu infrastruktury a ujisti se, že změny jsou řízeny v souladu s firemním procesem řízení změn. Strategie by měla obsahovat pravidelné kontroly proti business potřebám, správu záplat, strategii aktualizací, rizika, hodnocení zranitelnosti a bezpečnostní požadavky.

AI3.4 Realizace testovacího prostředí

Vytvoř vývojové a testovací prostředí s cílem podpořit účinné a efektivní realizace, testování integrace aplikací a infrastruktury v brzkých fázích procesu pořízení a vývoje. Zvažte funkčnost, konfiguraci hardwaru a softwaru, integraci, testování výkonu, migrace mezi prostředím, kontrolu verzí, testovací data a nástroje, zabezpečení.

Článek ze série COBIT

Posted by dotnet | 0 Comments

AI2 Pořízení a údržba aplikačního software

Článek ze série COBIT

AI2.1 High-level Design

Přetvoř obchodní požadavky na high-level design specifikaci pro vývoj softwaru, přičemž vezmi v úvahu technologické směry organizace a informační architekturu. Schval u businessu návrh specifikace pro ujištění, že high-level design odpovídá požadavkům.

AI2.2 Detailní design

Připrav detailní design a technické požadavky softwarové aplikace. Definuj akceptační kritéria pro přijetí těchto požadavků. Měj požadavky schváleny, abys zajistil, že odpovídají high-level designu. Položky, které je třeba vzít v úvahu: vstupní požadavky, dokumentace, definice rozhraní, uživatelské rozhraní, sběr zdrojových dat, programová specifikace, definice požadavků na soubory, zpracování požadavků, výstup požadavků, řízení a ověřitelnost, bezpečnost, dostupnost, a testování. Prováděj opětovné vyhodnocení za předpokladu, že během vývoje nebo provozu nastanou významné technické nebo logické nesrovnalosti.

AI2.3 Kontrola aplikace a auditovatelnost

Ujisti se, že business kontroly jsou řádně přeneseny do kontroly aplikací tak, že zpracování je přesné, úplné, včasné, schválené a kontrolovatelné. Skutečnosti, které je nutné vzít v úvahu: povolovací mechanismy, informační integrita, řízení přístupu, zálohování a design auditů.

AI2.4 Bezpečnost aplikace a dostupnost

Adresuj požadavky na zabezpečení aplikací a dostupnost jako odpověď na zjištění rizika, v souladu s klasifikací dat a firemní informační bezpečnostní architekturou. Problémy, které je třeba vzít v úvahu: přístupová práva, správu oprávnění, ochrana citlivých informací ve všech fázích, ověřování a integrita transakcí a automatické zotavení.

AI2.5 Konfigurace a implementace pořízeného Aplikačního software

Přizpůsob a implementuj nakoupené automatické funkce za pomocí konfigurace a testování. Problémy, které je třeba vzít v úvahu: validace vůči smluvním podmínkám, firemní informační architektura, existující aplikace, interoperabilita se stávajícími aplikacemi a databázovými systémy, efektivita výkonu systému, dokumentace a uživatelské manuály, integrace a plány systémových testů.

AI2.6 Důležité upgrade do existujících systémů

Pro zavedení změn vytvoř podobný proces jako pro vývoj nových systémů. Hlavně v případě významných změn stávajících systémů, které vedou k změně v současné technologii nebo funkci. Problémy, které je třeba vzít v úvahu: analýza dopadů, důvod nákladů a správu požadavků.

AI2.7 Vývoj aplikačního software

Ujisti se, že nová funkce je vytvořena v souladu s design specifikacemi, vývojem, standardy a požadavky na kvalitu. Schval a podepiš každou klíčovou etapu procesu vývoje aplikačního softwaru po úspěšném dokončení funkčnosti, vyhodnoť výkon a kvalitu. Problémy, které je třeba vzít v úvahu: schválení specifikace, návrhu splňující business funkční a technické požadavky, schvalování požadavků na změny, potvrzení, že aplikační software je kompatibilní s produkcí a je připravený pro migraci. Kromě toho zajisti, aby všechny právní a smluvní aspekty byly identifikovány a řešeny pro aplikační software vyvinutý třetími stranami.

AI2.8 Zajištění kvality software

Vyviň a vykonávej plán pro zajištění kvality softwaru pro zajištění kvality uvedené v definici požadavků a firemní politice kvality a procesů. Problémy, které je třeba vzít v úvahu v plánu kvality: specifikace kritérií kvality, validace a ověřování procesů, včetně kontroly průchodnosti a testování.

AI2.9 Management aplikačních požadavků

Ujisti se, že při návrhu, vývoji a realizaci je stav jednotlivých požadavků (včetně všech odmítnutých požadavků) sledován a změny požadavků jsou schváleny prostřednictvím zavedeného procesu řízení změn.

AI2.10 Údržba aplikačního software

Vypracuj strategii a plán údržby a nasazení softwarových aplikací. Problémy, které je třeba vzít v úvahu: plánování a řízení nasazení, plánování zdrojů, oprava chyb, náprava selhání, drobných vylepšení, údržbu dokumentace, nouzové změny, vzájemné závislosti s dalšími aplikacemi a infrastrukturou, aktualizace strategie, smluvní podmínky jako jsou podpora problémů, aktualizace, pravidelná revize vůči business potřebám, rizika a bezpečnostní požadavky.

Článek ze série COBIT

Posted by dotnet | 0 Comments

AI1 Identifikace automatického řešení

Článek ze série COBIT
AI1.1 Definice a údržba funkčních Business a Technických požadavků

Identifikuj, stanov priority, upřesni a dohodni business funkční a technické požadavky pokrývající celý scope všech iniciativ jež jsou zapotřebí k dosažení očekávaných výstupů z IT investičního programu. Definuj kritéria pro přijetí těchto požadavků. Tyto iniciativy by měly obsahovat veškeré požadované změny vůči firemnímu businessu, podnikovým procesům, dovednostem zdrojů a jejich kompetencí, organizační struktuře a novým technologiím. U požadavků zohledni funkční potřeby, jako je podnikový technologický směr, výkon, cena, spolehlivost, kompatibilita, ověřitelnost, bezpečnost, dostupnost a kontinuita, ergonomie, použitelnost, bezpečnost a právní předpisy. Stanov postupy pro zajištění a správu integrity, přesnosti a aktuálnosti business požadavků tak, aby vytvořili základ pro kontrolu aktuálního systému, akvizic a rozvoje. Tyto požadavky by měly být ve vlastnictví business sponzora.

AI1.2 Reporting analýzy rizik

Identifikuj, zdokumentuj a analyzuj rizika spojená s business procesy, tak aby tvořili součást firemního procesu vývoje požadavků. Rizika by měla zahrnovat hrozby integrity dat, bezpečnosti, dostupnosti, soukromí a souladů s právními předpisy. Identifikuj požadované vnitřní kontrolní měření a auditorské postupy tak, aby tvořili součást těchto požadavků.

AI1.3 Studie proveditelnost a formulace alternativních směrů akcí

Vypracuj studii proveditelnosti, která prozkoumá možnost implementace požadavků. Postup by měl identifikovat alternativní možnosti pro software, hardware, služby a dovednosti, které splňují stanovené funkční business a technické požadavky. Vyhodnoť technologickou a ekonomickou proveditelnost (potenciální analýza nákladů a přínosů) každého z identifikovaných směrů činností v rámci IT investičního programu. Studii proveditelnosti můžete realizovat i v několika iteracích, při vyhodnocení účinků faktorů, jako jsou změny podnikových procesů, technologie a dovedností. Business management, podporovaný IT funkcemi, by měl vyhodnotit proveditelnost a alternativní postupy a dát doporučení business sponzorovi.

AI1.4 Požadavky, rozhodná proveditelnosti a schválení

Business sponzor schvaluje a podepisuje business a technické požadavky, studie proveditelnosti na předem určených klíčových fázích. Každé ukončení musí následovat přezkum kvality. Business sponzor musí mít konečné slovo při volbě způsobu řešení a u přístupu k akvizici.

Článek ze série COBIT

Posted by dotnet | 0 Comments

PO10 Správa projektů

Článek ze série COBIT
PO10.1 Framework managementu programu

Udržuj program projektů, které souvisejí s portfoliem IT investičních programů. Projekty identifikujte, definujte, hodnoťte, stanovte priority, vybírejte, zahajte, řiďte a kontrolujte. Ujistěte se, že projekty podporují cíle programu. Koordinujte činnosti a vzájemné závislosti na více projektech, spravujte přínos všech projektů v rámci programu tak, abyste zajistily očekávané výsledky. Řešte požadavky na zdroje a konflikty.

PO10.2 Framework projektového managementu

Vytvoř a udržuj Framework projektového managementu, který musí definovat rozsah a hranice řízení projektů, stejně jako metodik, které budou přijaty a aplikovány na každý provedený projekt. Tyto metody by měly zahrnovat minimálně zahájení, plánování, provádění, řízení a vyhodnocené projektu. Stejně tak by měli obsahovat kontrolní milníky a schvalování. Framework a podpůrné metody by měly být integrovány s řízením portfolia podniku a řízením programu procesů.

PO10.3 Přístup projektového managementu

Definuj přístup k projektovému managementu pro řízení úměrný velikosti, složitosti a regulačním požadavkům jednotlivých projektů. Struktura projektového řízení by měla obsahovat role, odpovědnosti a finanční odpovědnosti z programu zadavatele, sponzory projektu, řízení, projektovou kancelář, projektového manažera a mechanismy, za pomocí kterých jsou tyto povinnosti plněny (jako je podávání zpráv a hodnocení stavu). Ujistěte se, že všechny IT projekty mají sponzory s dostatečnou pravomocí, tak aby byly vlastníky provádění projektu v rámci celkové strategie programu.

PO10.4 Závazek zúčastněných stran

V definici projektu získej příslib závazku a spolupráce od všech zúčastněných, zainteresovaných stran. Příslib musí být platný pro provedení projektu a v rámci kontextu celého IT investičního programu.

PO10.5 Prohlášení projektového rozsahu

Vymez a zdokumentuj povahu a rozsah projektu pro potvrzení od zúčastněných stran a pro obecné chápání rozsahu projektu a souvislostí s dalšími projekty v rámci celkového IT investičního programu. Definice by měla být před zahájením projektu formálně schválena programem a projektovým sponzorem.

PO10.6 Inicializace fáze projektu

Ujisti se, že zahájení hlavních fází projektu je formálně schváleno a komunikováno všem zúčastněným stranám. Zahájení projektu by měla být založeno na rozhodnutí vedení programu. Schválení dalších fází by mělo být založeno na schválených výsledcích výstupů z předchozí fáze a na základě schválení aktualizovaného business case z poslední hlavní revize programu. V případě navazujících fází projektu by měl být programem a projektovým sponzorem ustanoven kontrolní bod pro potvrzení pokroku projektu.

PO10.7 Integrovaný projektový plán

Vytvoř formální, schválený, integrovaný plán projektu (zahrnující business a zdroje informačních systémů) pro řízení realizace projektu a kontrolu projektu po celou dobu životního cyklu projektu. Činnosti a vzájemné závislosti na ostatních projektech v rámci programu by měly být pochopeny a zdokumentovány. Plán projektu by měla být zachována po celou dobu životního cyklu projektu. Plán projektu a jeho změny by měl být schválen v souladu s programem a Frameworkem řízení projektu.

PO10.8 Projektové zdroje

Definuj odpovědnosti, vzájemné vztahy, autority a výkonnostní kritéria členů projektového týmu a urči základ pro získání a přiřazení příslušného zaměstnance nebo kontraktora na projekt. Nákup produktů a služeb potřebných pro každý projekt by měl být plánován a spravován tak, aby se splnil cíle projektu s využitím praktik zadávání veřejných zakázek organizace.

PO10.9 Projektový management rizik

Eliminuj nebo minimalizuj specifická rizika spojená s jednotlivými projekty prostřednictvím systematického procesu plánování, identifikace, analýzy, reakcí, sledování a kontroly oblasti, nebo událostí, které mají potenciál způsobit nežádoucí stavy. Rizika řízení projektu a projektové dodávky by měla být identifikovány a centrálně zaznamenány.

PO10.10 Projektový plán kvality

Připrav plán řízení kvality popisující systém kvality projektu a přístup k její implementaci. Plán by měl být formálně přezkoumán a odsouhlasen všemi dotčenými stranami a pak začleněna do plánu projektu.

PO10.11 Kontrola změn projektu

Zaveď systém řízení změn pro každý projekt tak, aby byly všechny změny v projektu (např. náklady, harmonogram, rozsah a kvalita) odpovídajícím způsobem přezkoumány, schváleny a začleněny do plánu projektu v souladu s programem a Frameworkem projektového řízení.

PO10.12 Projektové plánování ověřovacích metod

Při plánování projektu identifikuj kontroly potřebné pro podporu akreditace nových nebo modifikovaných systémů a zahrň je do plánu projektu. Úkoly by měly poskytnout záruku vnitřních kontrol a bezpečnostních prvků splňujících stanovené požadavky.

PO10.13 Měření, reporting a monitoring projektového výkonu

Měř výkonnost projektu vůči klíčovým projektovým kritériím (např. rozsah, program, kvalita, náklady a riziko), identifikuj případné odchylky od plánu, zvaž jejich dopad na projekt a na celkový program. Klíčovým stranám reportuj výsledky, doporuč, implementuj a monitoruj nápravné akce, v případě potřeby v souladu s programem a Frameworkem projektového řízení.

PO10.14 Ukončení projektu

Požaduj, aby na konci každého projektu byli všichni účastníci projektu informování, zda byl projekt dodán s plánovanými výsledky a zisky. Identifikuj a komunikuj veškeré zbývající činnosti potřebné pro dosažení plánovaných výsledků projektu, výhody programu, identifikuj a zdokumentuj zkušenosti získané během projektu jako podklad pro budoucí projekty a programy.

Článek ze série COBIT

Posted by dotnet | 1 Comments

PO9 Posuzování a správa IT rizik

Článek ze série COBIT
PO9.1 IT a Business risk management uspořádání

Integruj IT vedení, řízení rizik a kontrolní Framework organizace (podniku) s Frameworkem pro řízení rizik. Tento postup povede k sblížení rizik organizace se stupněm jejich tolerance.

PO9.2 Stanovení kontextu rizik

Zřiď kontext, ve kterém se nachází Framework vyhodnocení rizik, pro použití zajištění odpovídajících výsledků. Včetně zahrnutí vnitřní a vnějších kontextů všech vyhodnocení rizik s cílem vyhodnocení a kritérií, podle kterých se hodnotí rizika.

PO9.3 Identifikace událostí

Identifikuj všechny události (hrozby a zranitelnosti) s možným dopadem na cíle nebo provoz podniku, včetně business, regulačních, právních, technologických, partnerských, lidských a provozních aspektů. Urči povahu dopadu: pozitivní, negativní nebo obojí, a spravuj tyto informace.

PO9.4 Vyhodnocení rizika

Opakovaně posuzuj pravděpodobnost a dopad všech zjištěných rizik, pomocí kvalitativních i kvantitativních metod. Pravděpodobnosti dopadu spojené s vlastním a zbytkovým rizikem, by měli být stanoveny individuálně podle jednotlivých kategorií a na základě portfolia.

PO9.5 Reakce na rizika

Identifikuj vlastníka rizika a ovlivněné vlastníky procesů. Zaveďte a udržujete řešení pro rizika pro zajištění toho, aby pravidelné efektivní kontroly a bezpečnostní opatření vedli k jejich zmírnění. Reakce na rizika by měly obsahovat strategie rizik, jako je vyhýbání, redukce, sdílení nebo přijetí. Při vývoji reakce zvažte náklady a přínosy. Vytvořte reakce, které omezují zbytkové riziko v rámci definovaných tolerancí jednotlivých úrovní rizika.

PO9.6 Správa a monitoring akčního plánu rizik
Na všech úrovních prioritizuj a plánuj kontrolní činnosti za účelem vývoje reakcí na rizika označené jako kritické, včetně identifikace nákladů, přínosů a odpovědnosti za vykonání. Usiluj o schválení doporučených opatření a přijetí případných rizik a zajisti to, aby byly potvrzené akce ve vlastnictví dotčeného vlastníka procesu. Sleduj plnění plánů, a reportuj případné odchylky vrcholovému managementu.

Článek ze série COBIT

Posted by dotnet | 0 Comments

PO8 Management kvality

Článek ze série COBIT
PO8.1 Systém managementu kvality

Vytvoř a udržuj QMS, který bude poskytovat standardní, formální a nepřetržitý přístup k řízení kvality. Zavedený přístup musí být v souladu s business požadavky. QMS musí umět identifikovat kvalitativní požadavky, kritéria, politiky, klíčové IT procesy a jejich sekvence a interakce. Dále musí obsahovat metody pro stanovení, zjišťování, nápravu a prevenci odchylek od stanovených požadavků. QMS by měl definovat organizační strukturu pro řízení kvality, pokrývající role, úkoly a povinnosti. Všechny klíčové oblasti musí rozvíjet své plány kvality v souladu s kritérii, postupy a evidencí kvality dat. Monitoruj a efektivně měř přijímání QMS a zlepšuj proces, pokud je to třeba.

PO8.2 IT Standardy a praktiky kvalit

Identifikuj a udržuj standardy, postupy a praktiky klíčových IT procesů pro kvalitní běh organizace, tyto podklady budou sloužit jako základ pro plnění záměrů QMS. Použij trhem ověřené postupy jako podklad pro zlepšení a přizpůsobení kvality v organizaci.

PO8.3 Standardy vývoje a nákupu

Vytvoř a udržuj normy pro všechny oblasti vývoje a nákup, které se dotýkají životního cyklu dodání produktů. Zajisti formální ukončení u klíčových milníků na základě dohodnutých výstupních kritérií. Oblasti, které je nutné prověřovat: software normy kódování, jmenné konvence, formáty souborů, schémat a datových standardů, design manuál, standardy uživatelského rozhraní, interoperabilitu, výkon systému, škálovatelnost, výkonnost, standardy pro vývoj a testování, validace proti požadavkům, testovací plány, unit testy, regresní testy a testování integrace.

PO8.4 Zaměření na zákazníka

Ujisti se, že řízení kvality se zaměřuje na zákazníka, popisováním jejich požadavků a jejich přiblížením k IT standardům a postupům. Musí být definovány role a odpovědnosti týkající se řešení konfliktů mezi uživatelem / zákazníkem a IT organizací.

PO8.5 Trvalé vylepšení

Pravidelně komunikuj a spravuj plán pro kvalitu jako celek, který podpoří trvalé zlepšování.

PO8.6 Měření kvality, monitoring a revize
Definuj, plánuj a implementuj měření pro nepřetržité sledování souladů s QMS. Stejně tak sleduj jakou hodnotu QMS poskytuje. Majitel procesu by měl použít měření, sledování a záznam informací tak, aby v případě odchylky přijal vhodná nápravná a preventivní opatření.

Článek ze série COBIT

Posted by dotnet | 0 Comments
 
Vyvojar.cz na prodej!