Sicurezza delle informazioni e rischi finanziari

Questo è sicuramente correlato alla sicurezza e se le transazioni coinvolte sono fatte per via elettronica, allora è certamente parte della stima del rischio e della determinazione delle misure di sicurezza appropriate che dovrebbero essere prese. La sicurezza delle informazioni non esiste nel vuoto. Dipende da tutti i fattori circostanti, fino alla sicurezza fisica dell'edificio in cui si trovano i computer.

La frode è un tipo di incidente di sicurezza derivante dall'uso improprio del sistema, poiché i sistemi per limitare il rischio di tali incidenti rientrano nei limiti della documentazione sulla sicurezza delle informazioni, anche se è probabile che esista un livello accettabile di rischio finanziario o gestionale .

Anche molte misure tecniche (come controlli di identità e / o credito) possono intervenire per impedire attività fraudolente, quindi la sicurezza delle informazioni deve essere coinvolta in modo specifico nel processo piuttosto che essere introdotta all'ultimo minuto.

Non penso che sia necessario aspettarsi che una persona della sicurezza delle informazioni abbia una conoscenza approfondita di particolari rischi finanziari di frode (ecco perché esiste un dipartimento finanziario) ma è importante capire come i sistemi e le politiche dovrebbero rispondere a quelle minacce documentate in un piano di risposta coerente per l'intera organizzazione.

Sono d'accordo con la risposta precedente. In genere i controlli rientrano in un team di sicurezza delle informazioni o in un gruppo di controllo incentrato sullo sviluppo e sulla manutenzione dei controlli per l'intera organizzazione. I controlli vengono in genere creati (come menzionato) da una combinazione di Finanza e IT, ma dovrebbero essere di proprietà / sviluppati più dalla Finanza poiché comprendono il rischio effettivo quando si considerano tutti i controlli già presenti nell'organizzazione (ad esempio, il dipartimento delle finanze potrebbero già fare riconciliazioni come parte del loro processo di chiusura di mesi .... questo è in realtà un controllo che dovrebbe essere documentato).

Per quanto riguarda le certificazioni, CRISC sarà sicuramente di aiuto. Inoltre, dovresti cercare l'assistenza di un'azienda Big 4, che in genere dispone di risorse specializzate in quest'area.

Infine, ci sono conferenze che si verificano ogni anno per poter assistere alla partecipazione. La Conferenza ISRM Nord America ISACA ha una sessione sulla protezione del sistema SAP. Se SAP è il tuo ERP, dovresti considerare di partecipare alla sessione come parte di questo argomento.

What are the competencies of a Information Security Office related to financial risks?

Con i rischi finanziari in quanto questi rischi si riferiscono alla sicurezza delle informazioni, trovo che attraverso la mia esperienza come revisore IT, il fattore umano è fondamentale. I controlli interni hanno limitazioni e due limitazioni principali sono la collusione e l'override della gestione.

I controlli di sicurezza tecnica (controlli di accesso logico, crittografia ecc.) possono essere progettati e perfettamente funzionanti, ma se due individui con intenzioni malvagie dovessero colludere per causare danni finanziari o cucinare i registri contabili di un sistema finanziario, ciò non importa quanto bene funzionino i controlli tecnici di sicurezza. Allo stesso modo, se l'ambiente di controllo (ad esempio: sintonizzarsi in alto) è debole e la gestione è lassista, qualsiasi sforzo al di sotto della funzione di controllo interno sarà probabilmente infruttuoso.

Quindi, ritengo che una competenza di base di un dipartimento di sicurezza IT nel mitigare i rischi finanziari in quanto tali rischi derivino dall'IT, sta promuovendo un ambiente e controlli che mitigano gli incentivi umani negativi, come ad esempio l'applicazione di compiti SoD così incompatibili (ad es. gestione dei debiti / impostazione dei conti) sono effettuati da almeno 2 persone diverse.

Con la separazione delle funzioni, ci sono diverse aree da considerare in cui il team di sicurezza delle informazioni potrebbe essere utile. I registri finanziari sono i prodotti finali che escono da un sistema di contabilità / ERP. Ci sono determinati ruoli che a causa della loro natura comportano un rischio intrinseco più elevato come amministratori di database . Pertanto disporre di controlli di sicurezza ben progettati attorno alla funzione DBA consente di applicare il principio dell'accesso meno privilegiato sarebbe un modo in cui la sicurezza IT può migliorare l'ambiente dei controlli interni di reporting finanziario.

Affinché le frodi finanziarie abbiano successo, le attività dannose non devono essere facilmente rilevate. Pertanto, l'implementazione di un controllo rigoroso delle modifiche dei dati la revisione periodica di tali registri rappresenterebbe un altro modo in cui la sicurezza IT può contribuire a rafforzare l'ambiente di controllo. Come complemento alla registrazione di sicurezza, potresti anche voler esaminare altri processi come la risposta agli incidenti per rimediare e indagare sulle modifiche non rilevate nella produzione.

Puoi anche collegare asserzioni nei report finanziari al modello di sicurezza della CIA per mappare come le minacce a un principio della CIA minacciano il raggiungimento di un'asserzione finanziaria. Consentitemi di illustrare le affermazioni della dichiarazione di completezza e cutoff e i principi della CIA di Integrity e Availability .

Completeness Assertion in Financial Reporting

Come affermato nel link, l'affermazione di completezza nella rendicontazione finanziaria riguarda se tutte le registrazioni a giornale che avrebbero dovuto essere registrate alla GL sono state registrate. Se i controlli di sicurezza non sono adeguati per proteggere il principio di integrità (es .: vulnerabilità esistente), un agente della minaccia, come un dipendente scontento, può sfruttare tale vulnerabilità, forse per eliminare / alterare i record finanziari, con conseguente errore nell'asserzione di completezza .

Cutoff Assertion in Financial Reporting

L'asserzione di taglio nei rendiconti finanziari riguarda se le transazioni finanziarie sono state contabilizzate alla GL nel periodo di tempo contabile corretto. Se un agente della minaccia come un dipendente insoddisfatto dovesse lanciare un attacco DOS / DDOS contro un'applicazione che elabora dati finanziari, il tempo di inattività potrebbe comportare la mancata elaborazione tempestiva dei dati finanziari, con conseguente errore nell'affermazione del taglio.

Quindi sì, tale richiesta è assolutamente nel campo della sicurezza delle informazioni .