A SOC keretrendszer segít abban a cégvezetésnek, hogy jobban megértsék a független könyvvizsgálók riportjait. Horváth Csaba cikksorozatának harmadik részében a Service Organization Control riportokkal foglalkozik.
A Service Organization Control, azaz SOC keretrendszer célja, hogy a szolgáltató szervezetek és vásárlóik is képesek legyenek megérteni a független könyvvizsgáló (CPA) szolgáltatóról kibocsátható riportjait [10]. A szolgáltató lehet felhőszolgáltató, bérszámfejtést végző, információbiztonsági vagy információs szolgáltatást nyújtó vállalat [10]. A keretrendszeren belül megkülönböztetünk SOC 1 (Type I és Type II-es), SOC 2 (Type I és Type II-es) és SOC 3-as riportokat.

Hagyományok és újítások A SAS 70-et felváltó SOC 1 riport továbbra is a SSAE 16 szabvány irányítása mellett készül. A SAS 70 és SOC 1 közötti fő különbség, hogy az utóbbi tartalmazza a menedzsment állításait (management assertions) és a vizsgálat időkeretét. A Type I riportoknál a menedzsment köteles kiadni egy állítást a rendszerek és kapcsolódó kontrollok megfelelő leírásáról és a kontrollcélok eléréséhez szükséges megfelelőségről. Ezt követően a független könyvvizsgáló (CPA) kiad egy véleményt a korábban megfogalmazott állításokról. Ezze szemben a Type II-es riportok az összes Type I-ben megjelenő kritériumot tartalmazzák, kiegészítve a kontrollok működési hatékonyságáról kiadott menedzsmentállításokkal. Ezek mellett ott van természetesen a CPA véleménye az összes menedzsmentállításról, valamint az általa végzett tesztek leírása és eredménye.

A SSAE16-alapú SOC 1 Type I riport egy adott időpillanatban értékeli a kontrollokat, míg a Type II egy adott időintervallumra, legalább egy 6 hónapot átfogó időszakra koncentrál [3] [8] [9]. A SOC 1-es riportok elsősorban a szolgáltatást igénybe vevő cég pénzügyi menedzsmentjének és revizorainak készülnek (kontrolling, SOX megfelelőségért felelős iroda) [8] [10]. Ezeket akkor érdemes használni, ha egy szervezet a kulcsfolyamatait vagy funkcióit szervezte ki, mert a megfelelő végrehajtás felelőssége ilyen esetben is a szolgáltatást igénybe vevő cég menedzsmentjét terheli [8].

Új technológiához új módszerek A megosztott számítási erőforrások (hálózatok, szerverek, adattárolás, alkalmazások és szolgáltatások) hálózaton keresztül, on-demand módon történő növekvő (felhőalapú) elérése teremtette meg azt az igényt, hogy a független könyvvizsgálók a nem kizárólag pénzügyi kontrollokról is készítsenek jelentést [8]. A felhőalapú szolgáltatások terjedésével a menedzsment számára egyre fontosabbá válnak a szolgáltatók hatékony és biztonságos működésével kapcsolatos kérdések. Amíg nem létezett a SOC, addig ezeket a kérdéseket általában gyakran feltett kérdések (FAQ), rendszer- vagy kontroll-leírások segítségével próbáltak megválaszolni a szolgáltatók. Ezek a módszerek azonban nem garantálták az összes felmerülő kérdésre adott kielégítő választ. Ráadásul az eltérő kritériumrendszerek a szolgáltatók összehasonlíthatóságát is akadályozták. A SOC2 ezeket a problémákat kívánja orvosolni, lévén a SAS 70 és SSAE 16, de a SOC 1 és a SOC 3 riportok sem tudták kellő részletességgel lefedni a kockázatokat [10].


A SOC 2-es riportok lényegében a SOC 1-hez hasonló időkeretet és menedzsmentállításait követik, ám a megfelelőségi és működési kontrollok vizsgálata már az U.S. Public Accounting Oversight’s Board (PCAOB) AT 101 szabvány alapján zajlik. Így a Trust Service Principle-k (biztonság, elérhetőség, feldolgozás integritása, bizalmasság és privacy – TSP) alkotják a SOC 2 alapját [3] [8] [9] [10]. Ezek a TSP-k önállóan vagy több TSP-t kombinálva képesek lefedni a menedzsmenttől elvárt felelősségek körét [10]. Bár nem szükséges minden alapelvben szereplő kritériumot lefedni, arra oda kell figyelni a tervezés során, hogy a le nem fedett kritérium ne veszélyeztesse az alapelv megfelelő értékelését [11].

A SOC 2-n belül különbséget teszünk Type I-es és Type II-es riportok között. Mivel a Type II-es riportok széleskörű információt nyújtanak, így ezeknek kellene lenniük a szerződésekben is megkövetelt riportfajtáknak [9] [10]. Fontos megjegyezni, hogy a SOC2-ben a rendszer leírásánál magának a rendszernek a jelentése bővebb, mint a hardverek és szoftverek összessége. A fogalom itt magában foglalja a szolgáltató vállalatnak a rendszerrel kapcsolatos szabályzatait és procedúráit is, melyek a vásárlók kiszolgálásához szükségesek. Tehát a rendszer alatt a fizikai környezetet, hardverkomponenseket, alkalmazásokat, operációs rendszereket, embereket, procedúrákat és az adatok értjük. Sőt ha kapcsolódik a privacy-hoz is, akkor még bele kell érteni az adatkezelés egész életciklusát (az adatgyűjtéstől, felhasználáson, megőrzésen, kiadáson keresztül a megsemmisítésig) – összhangban az AICPA és CICA által kibocsátott Generally Accepted Privacy Principles-szel (GAAP) [10].

A Trust Service Principle-k A biztonság TSP fő célkitűzése, hogy a rendszer védett legyen az illetéktelen logikai és fizikai hozzáférésekkel szemben. Fő területei az IT biztonsági szabályzat, a biztonságtudatossági képzés, a logikai hozzáférés, a fizikai hozzáférés, a biztonsági monitorozás, a felhasználóazonosítás beállításai, eszközklasszifikáció és -menedzsment, a konfigurációmenedzsment és a változásmenedzsment.

Az elérhetőség a rendszer elérhetőségére koncentrál, melyet a felhasználó és szolgáltató közötti megállapodás rögzít. Ide tartozik például a helyreállítási célidő, az elérhetőségi szabályzat, a mentési és megőrzési szabályzat, a katasztrófahelyreállítási terv és üzletmenet-folytonosság menedzsment.

A sorozatban megjelent cikkek
Módszerek felhőszolgáltatások kockázatértékelésére – 1. rész:
Third Party Assurance (TPA), azaz a harmadik félnek nyújtott bizonyosság problémaköre felhőszolgáltatásoknál
Módszerek felhőszolgáltatások kockázatértékelésére – 2. rész:
áttekintés a leginkább elterjedt TPA szabványokról és a riportok típusairól

A feldolgozás integritása arról ad bizonyosságot, hogy a jóváhagyott tranzakciók időben, hiánytalanul és pontosan kerülnek végrehajtásra. Főbb területei a feldolgozás integritását figyelő szabályzatok, a pontossági ellenőrzések (pl. ciklikus redundancia ellenőrzés), a nyomonkövetés, a számlázás, az időbeliség, a jóváhagyás (pl. funkcionális visszaigazolások) és a bemenetek pontossága.

A bizalmasság során arról szerezhetünk bővebb információt, hogy a rendszer oly módon lett-e megtervezve, hogy megfelelő biztosítékot nyújtson az érzékeny információk kiszivárogtatás ellen. Erről gondoskodnak a bizalmassági szabályzatok, a be- és kimenetek bizalmassága, az adatfeldolgozási és információs beszámolók.

Végül pedig a privacy arról ad bizonyosságot, hogy a rendszer által gyűjtött, felhasznált, mentett és közzétett személyes információk a szolgáltató vállalat privacy szabályzata és az AICPA privacy alapelvei szerint történik. Vizsgálja a privacy szabályzat meglétét, a gyűjtési folyamatot, az adatfelhasználást és -tárolást, az adathozzáférést, az információ kiszolgáltatást és a privacy megfigyelést [3]. Míg az előző négy alapelv specifikus kritériumok mentén épül fel, addig a privacy a tevékenységek sokkal szélesebb spektrumát fedi le. Ezt a TSP-t mindenképpen célszerű lefedni, ha a szolgáltató vállalat üzletmenete során személyes adatokat kezel [11].

SOC 2-es riportok jelentősége és a hozzájuk kapcsolódó felelőség A SOC 2 Type II-es riportoknak elsősorban az olyan erősen szabályozott iparágakban lesz kiemelt jelentőségük, mint az egészségügy és pénzügyi szolgáltatások. Ezeknél ugyanis a TSP-n alapuló információ és bizonyosság rendkívül kritikus [9]. A SOC2-es riportok esetében a menedzsment felelőssége, hogy meghatározza a szükséges TSP-ket, eldöntse a riport típusát, meghatározza a lefedni kívánt periódust. A közreműködő CPA pedig segít meghatározni a konkrét célcsoportot, valamint segít eldönteni, hogy a periódus hossza megfelelő-e a véleménynyilvánításhoz, és hogy a kiválasztott TSP-k képesek-e megfelelni a kitűzött céloknak [10]. A SOC 2-es riportok elsősorban azoknak készülnek, akik részletes képet szeretnének kapni a szolgáltatást nyújtó belső kontrollkörnyezetéről, és a riportok értelmezéséhez megfelelő szakértelemmel rendelkeznek. Ebbe a körbe beletartozik a szolgáltató és a vásárló menedzsmentje, IT-részlege, revizora; valamint a külső szabályozók és üzleti partnerek is [3] [8] [10] [11].

A SOC 3-as riportok A SOC 3-as riportok szintén TSP-ken alapulnak. Ám ezeknek a riportoknak a kiadásához nem szükségesek a menedzsment által meghatározott állítások, nem készül hozzájuk kapcsolódó audit vélemény, és nem különböztetünk meg bennük Type I és Type II riportokat. Tehát a SOC 3 lényegében egy auditálatlan kontrollmegfelelőségi és működési riport, melyben CPA a szolgáltató szervezet TSP-ken alapuló hatékony rendszerkontrolljainak karbantartásáról készít véleményt, melynek végeredményét hozzáférhetővé teszik a publikum számára [3] [8] [10]. A SOC 3-as riportok azok számára készülnek akik nem a részletekkel kívánnak bíbelődni, hanem átfogó képet szeretnének kapni a szolgáltatást nyújtó belső kontrollkörnyezetéről a bizalom megteremtéséhez [8] [10].

A jobb áttekinthetőség érdekében a különböző SOC riportok közötti fő különbségek az alábbi táblázatban is összefoglalásra kerültek.



A SOC keretrendszer különböző típusú riportjainak összehasonlítása


Összefoglalásként A SOC riportokban immáron a felhőszolgáltatások összes kritériumát figyelembe véve és összehasonlítható módon lehet menedzsment állítások formájában információt szolgáltatni a szolgáltatók rendszereink és kontrolljainak leírásáról, a kontrollcélok eléréséhez szükséges megfelelőségről és a kontrollok működési hatékonyságáról. Mindezeket független könyvvizsgálók (CPA-k) véleményezik, és adott esetben a riport tartalmazza az általuk végzett tesztek leírásait és eredményeit is. Összességében tehát a SOC riportok nagyban megkönnyítik a kiszervezési döntés során a szolgáltató választást.

Megjegyzendő, hogy a legnagyobb cloudszolgáltatók – például a Google vagy az Amazon – mind SOC, mind ISO/IEC 27001 tanúsítvánnyal rendelkeznek (lásd az ábrát).


Néhány jelentősebb cloudszolgáltató tanúsítványai
(Forrás: PwC)

A cikksorozat következő és egyben befejező részében először részletesen megvizsgáljuk a kiszervezett szolgáltatásokkal kapcsolatos vezetői felelősség kérdését. Majd pedig néhány példán keresztül további megerősítésre kerül a TPA riportok jelentősége.

Szakirodalom A téma iránt mélyebben érdeklődőknek megadjuk a cikkben hivatkozott szakcikkek pontos adatait.

[1] PwC.(2009), Third Party Assurance – Technology Sector, April 2009, PricewaterhouseCoopers.
[2] PwC.(2009), Third Party Assurance – SaaS Cloud Computing and TPA Services, PricewaterhouseCoopers.
[3] Brizhik, A., Choe V., Taylor, D. (2012), SOC 2 Breakdown, INTERNAL AUDITOR, February 2012.
[4] PwC. (2009), Third Party Assurance – SaaS Cloud Computing, 22nd March 2013.
[5] PwC. (2013), Confidence in the Cloud, www.pwc.co.uk, 22nd March 2013.
[6] AICPA. (2010), Statement on Standards for Attestation Engagements No. 16, Reporting on Controls at a service Organization.
[7] PwC. (2009), The end of SAS70 – what next for Performance Assurance?, PricewaterhouseCoopers.
[8] Rashty, J. (2011), New Guidance for Cloud-Based Service Control Reports, THE CPA JOURNAL, October 2011.
[9] Petersen L. M. (2011), Service organization control reports demisyified, www.cioinsight.com, September/October 2011.
[10] Halterman, C. (2011), Expanding service control reports, www.journalofaccountancy.com, July 2011.
[11] Bell, D., Curran, C., Seale, K. (2012), Building trust and customer confidence with SOC 2 and 3 reports, www.grantthorton.com, 22nd March 2013
[12] SSAE16. (2013), SOC 3 SysTrust/WebTrust | Trust Services Principles and Criteria | What you Need to know, www.ssae16.org
[13] SAS70. (2012), FAQ, www.sas70.com
[14] WebTrust. (2013), Find a Seal: Information on Trust Service Seals, www.webtrust.org
[15] IT Governance Institute. (2008), Aligning Cobit 4.1, ITIL V3 and ISO/IEC 27002 for Business Benefeit, ITGI 2008.
[16] Frost, R. (2012), ISO Survey now available for free download, www.iso.org
[17] ISO27001Security. (2013), FAQ ISMS audit & certification, www.iso27001security.com
[18] Mataracioglu, T., Ozkan, S. (2011), Governing Information Security in Conjunction with COBIT and ISO 27001, International Journal of Network Security & Its Applications, Vol. 3 Issue 4, p111, July 2011.
[19] EuroCloud. (2013), EuroCloud Star Audit Requirements, www.saas-audit.de
[20] EuroCloud. (2013), EuroCloud Star Audit FAQ, www.saas-audit.de

Bug bounty programot hirdetett a legaktívabb hekkercsoport

Nem ismert sérülékenységek felfedezéséért általában az érintett cégek szoktak fizetni biztonsági szakembereknek. Ebben az esetben viszont egy bűnözői csoport ajánlott díjazást azoknak, akik hajlandók velük együttműködni.
 
Éltek már vissza a bankkártyaadataival? Ha nem, akkor azt nagy valószínűséggel egy csalásfelderítő rendszernek köszönheti.

a melléklet támogatója a Balasys

A Világgazdasági Fórum figyelmeztetése szerint jelentős szakadék tátong a C-szintű vezetők és az információbiztonságért felelős részlegek helyzetértékelése között.

A járvány üzleti vezetőt csinált a CIO-kból

Az EU Tanácsa szerint összeegyeztethető a backdoor és a biztonság. Az ötlet alapjaiban hibás. Pfeiffer Szilárd fejlesztő, IT-biztonsági szakértő írása.
Ön sem informatikus, de munkája során az információtechnológia is gyakran befolyásolja döntéseit? Ön is informatikus, de pénzügyi és gazdasági szempontból kell igazolnia a projektek hasznosságát? Mi közérthető módon, üzleti szemmel dolgozzuk fel az infokommunikációs híreket, trendeket, megoldásokat. A Bitport tizenegyedik éve közvetít sikeresen az informatikai piac és a technológiát hasznosító döntéshozók között.
© 2010-2022 Bitport.hu Média Kft. Minden jog fenntartva.