Introduction

La dépendance accrue vis-à-vis des actifs des systèmes d'information pour

l'exécution des fonctions critiques d'une organisation a renforcé la nécessité
d'utiliser les audits des systèmes d'information comme contrôle pour garantir la
confidentialité, l'intégrité et la disponibilité des ressources des systèmes
d'information.
Les principaux problèmes auxquels un auditeur de systèmes d'information est
confronté sont le biais technologique apparent du sujet, l'absence d'approche
d'audit normalisée et le manque de disponibilité de listes de contrôle normalisées.

QUESTIONS IMPORTANTES DE SÉCURITÉ DANS LES BANQUES

Les problèmes de sécurité importants impliqués dans un audit des systèmes
d'information d'une banque, ainsi que d'autres organisations, sont les suivants :

Gestion des accès utilisateurs

L'auditeur doit vérifier les deux points suivants :
1. L'existence de procédures formelles contrôlant l'attribution des droits d'accès
aux utilisateurs individuels.
2. Les procédures doivent couvrir tout le cycle de vie de l'accès des utilisateurs, de
l'enregistrement de nouveaux utilisateurs à la désinscription.

Enregistrement de l'utilisateur
L'auditeur des systèmes d'information doit confirmer si le processus et la politique
d'enregistrement des utilisateurs comprennent les 10 domaines suivants :
1. Utilisation d'identifiants d'utilisateur uniques afin qu'un utilisateur puisse être
identifié à partir de l'identifiant utilisé pour accéder aux ressources du système
d'information.
2. Les identifiants de groupe ne doivent être attribués que lorsque la nature du
travail à effectuer l'exige. Les ID de groupe sont utilisés par plusieurs personnes et
sont généralement attribués lorsque l'utilisateur récupère principalement des
informations et n'en saisit aucune. Un exemple d'un tel profil est celui d'un
auditeur. Le coût des licences individuelles peut également motiver l'audité à
attribuer des ID de groupe afin qu'au lieu d'un seul utilisateur accédant à la
ressource, plusieurs utilisateurs puissent y accéder avec le même ID. Les ID
utilisateur définis par le système obligent souvent une organisation à les utiliser
comme ID de groupe. Par exemple, si l'ID d'administrateur système défini par le
système est «admin», toutes les personnes qui doivent utiliser les fonctionnalités
administratives de l'application seront obligées d'utiliser le même ID.

12
3. Le propriétaire de l'actif doit autoriser des utilisateurs spécifiques à utiliser
l'actif.
4. Le niveau d'accès accordé est conforme aux exigences fonctionnelles de
l'utilisateur et est aligné sur la politique de sécurité du système d'information de
l'audité.
5. Les utilisateurs doivent signer une déclaration contenant leurs droits d'accès
respectifs et accepter les conditions d'utilisation.
6. Aucune ressource système n'est rendue accessible à quiconque avant la fin de la
procédure d'autorisation.
7. Toutes les autorisations d'accès accordées sont documentées.
8. Les droits d'accès sont supprimés dès que l'utilisateur n'a plus besoin d'un tel
accès et en particulier lorsque l'utilisateur a quitté l'organisation.
9. Les ID utilisateur et les comptes redondants sont identifiés périodiquement et
supprimés. Ces ID utilisateur redondants ne sont pas réémis aux autres utilisateurs
avant l'expiration d'un délai spécifique. Dans les cas d'identifiants génériques, cela
peut ne pas être possible et des précautions supplémentaires doivent être prises
pour réinitialiser le mot de passe utilisé par l'utilisateur précédent.
10. Les contrats de travail et les contrats de prestataires de services précisent que
la violation des droits d'accès entraînera des procédures pénales.

Authentification des utilisateurs

Tous les utilisateurs, quel que soit leur profil fonctionnel, doivent avoir un
identifiant unique (ID utilisateur) afin que les activités puissent ensuite être
retracées, documentées et utilisées comme preuve légale, si nécessaire. La seule
exception à cette règle est l'utilisation d'un ID générique et d'un ID de groupe
lorsque des contrôles supplémentaires doivent être établis pour identifier les
personnes utilisant l'actif.
L'identification des utilisateurs individuels de l'actif informationnel peut être
facilitée en adoptant la procédure suivante fondée sur les meilleures pratiques:
1. Attribution d'identifiants d'utilisateur uniques à chaque utilisateur individuel de
l'actif des systèmes d'information.
2. Tenir le cessionnaire d'un ID utilisateur responsable de tous les actes, ou de
l'absence de ceux-ci, accomplis sous l'ID utilisateur, sauf si le vol d'identité a été
signalé et établi.
3. Établissement d'une piste d'audit de toutes les activités effectuées par n'importe
quel ID utilisateur.

Système de gestion des mots de passe

L'auditeur des systèmes d'information doit vérifier si le système de gestion des mots
de passe a mis en œuvre, entre autres, les 12 bonnes pratiques suivantes :

12
1. Utilisation de mots de passe individuels pour maintenir la responsabilité, sauf si
l'accès de groupe est accordé à certaines ressources.
2. Les utilisateurs doivent pouvoir définir et modifier leur propre mot de passe et
le processus doit inclure une procédure de confirmation pour contrôler les erreurs
de saisie.
3. Définition et application d'une force minimale pour les mots de passe proposés
par les utilisateurs, y compris les éléments suivants :
A. Utilisation d'un nombre minimum de caractères.
B. Application d'une combinaison de caractères alphabétiques, numériques
et spéciaux.
C. Interdiction d'utiliser un identifiant d'utilisateur, un nom d'utilisateur ou
des informations similaires dans le cadre du mot de passe.
D. Informer les utilisateurs des dangers liés à l'utilisation d'un mot de passe
pouvant être lié à l'utilisateur, tel que la date de naissance ou le numéro de
téléphone.
D. Décourager l'écriture des mots de passe et les stocker dans un endroit
accessible au public.
4. Partout où un mot de passe est temporaire accordé, les utilisateurs doivent être
obligés de le changer à la première connexion.
5. Appliquer le changement des mots de passe à l'expiration d'une certaine période,
que le mot de passe ait été ou non utilisé.
6. Une période de temps définie ou un nombre d'instances pour conserver
l'historique d'un mot de passe, qui ne peut pas être réutilisé pendant une période
définie.
7. Fournir un mot de passe de détresse pour les opérations sensibles, qui peut être
utilisé pour alerter les administrateurs système, les autres membres du personnel
et les forces de l'ordre lorsque l'accès est sous la contrainte.
8. Les mots de passe sont masqués à l'écran lorsqu'ils sont saisis, quels que soient
les appareils utilisés.
9. Les fichiers de mot de passe ne sont pas stockés avec les données du système
d'application.
10. Les mots de passe sont transmis et stockés sous une forme cryptée.
11. Le mot de passe par défaut fourni par le fournisseur ou l'agence d'exécution est
modifié immédiatement après l'installation du matériel / logiciel.
12. Le partage de mots de passe est défini comme un manquement à une conduite
acceptable entraînant des actions disciplinaires et judiciaires.

Limitation des tentatives de connexion

12
L'auditeur des systèmes d'information doit vérifier si les deux meilleures pratiques
suivantes sont prises en compte pour les tentatives de connexion non autorisées :
1. Suspension des ID utilisateur après un nombre défini de tentatives de connexion
infructueuses. Dans le cas d'un système sensible, le nombre de tentatives peut être
cumulatif sur plusieurs jours et remis à zéro uniquement si une connexion réussie a
lieu. Une application courante de ce contrôle est dans le système d'accès
utilisateur pour les services bancaires par Internet. Dans certains cas, la suspension
est automatiquement levée à la fin de la journée, par exemple, le code PIN d'une
carte bancaire.
2. Définition d'un délai maximal d'inactivité et de fin de session si le délai spécifié
est dépassé. Une application commune se trouve aux guichets automatiques
bancaires, qui annulent la connexion si aucune activité n'est observée pendant une
période donnée. La plupart des sites sécurisés mettent fin à la session après une
inactivité sur une période définie.

Terminaux sans surveillance

L'auditeur doit vérifier si des mesures appropriées, y compris les six suivantes, ont
été mises en œuvre pour empêcher l'utilisation non autorisée d'un terminal sans
surveillance connecté au système :
1. Déconnexion forcée après une période d'inactivité définie, qui nécessitera une
nouvelle authentification de l'utilisateur avant que le travail puisse reprendre sur le
terminal.
2. Arrêt obligatoire du terminal après une certaine heure de la journée ou une
période d'inactivité.
3. Éduquer tous les utilisateurs, internes et externes, sur les exigences et les
procédures de sécurité à observer pour protéger les terminaux sans surveillance.
Les utilisateurs doivent également être informés de leurs responsabilités dans la
mise en œuvre de cette protection.
4. Toutes les sessions actives doivent être terminées une fois que l'utilisateur a
indiqué la fin de sa fonction. Dans le cas de fonctions impliquant un traitement sur
une longue période de temps où la session ne peut pas être terminée malgré
l'absence d'interface utilisateur, le système doit être sécurisé par un mécanisme de
verrouillage approprié, y compris un économiseur d'écran protégé par mot de
passe.
5. Lorsqu'un terminal termine une session avec le serveur, la session doit être
terminée même lorsque le terminal est éteint sans se déconnecter.
6. Les terminaux situés dans des endroits sensibles ou impliqués dans des fonctions
sensibles devraient s'arrêter automatiquement après une période d'inactivité
définie. Cette fonction doit effacer séquentiellement l'écran du terminal, fermer
l'application et déconnecter les sessions réseau après la période d'inactivité
définie.

12
Restriction d'accès à l'information
Les restrictions d'accès aux informations peuvent être appliquées en concevant des
contrôles qui résolvent divers problèmes, dont les quatre suivants :
1. Les applications utilisées doivent fournir des privilèges d'accès basés sur les
menus aux utilisateurs de l'application en fonction des besoins et restreindre l'accès
à des éléments de menu limités pour un utilisateur spécifique.
2. La documentation utilisateur peut être adaptée pour s'adapter à différents
profils de groupes d'utilisateurs et elle peut inclure, en cas de besoin, des
informations sur la manière d'accéder aux fonctions du système d'application. Ainsi,
les utilisateurs ne seraient pas informés des diverses fonctionnalités offertes par
l'application qui ne sont pas pertinentes pour eux.
3. Les droits d'accès des utilisateurs peuvent être classés et contrôlés pour garantir
que les droits de lecture, d'écriture, de suppression et d'exécution sont appréciés
par des utilisateurs ou groupes d'utilisateurs spécifiés.
4. Les résultats des systèmes d'application contenant des informations sensibles
devraient contenir des informations pertinentes pour l'utilisation spécifique. En
outre, ces informations devraient également être envoyées uniquement aux
terminaux et emplacements autorisés.

Utilisation des utilitaires systèmes

Le personnel de support système utilise des programmes utilitaires système qui
sont généralement capables de remplacer divers contrôles système et applicatifs.
Bien que ces utilitaires remplissent des fonctions utiles pour maintenir des services
ininterrompus, la nature intrusive de ces outils peut compromettre la sécurité du
système et cette capacité peut être abusée. Un auditeur des systèmes
d'information doit confirmer que l'utilisation des utilitaires système est limitée et
suit un système d'autorisation strict. Les huit contrôles suivants peuvent s'avérer
utiles à cet égard:
1. Existence et strict respect de procédures d'authentification rigides pour
l'acquisition, l'installation et l'utilisation des utilitaires système.
2. Séparation claire des autorisations et de l'accès aux utilitaires système et aux
logiciels d'application.
3. Restriction de l'utilisation des utilitaires système à un groupe fermé comprenant
le moins possible d'utilisateurs fiables et compétents.
4. Exigence d'un processus d'autorisation restrictif et progressif pour l'utilisation ad
hoc de ces utilitaires.
5. Disponibilité limitée en termes d'accès et d'installation des utilitaires système.
6. Journalisation détaillée de toutes les activités effectuées à l'aide des utilitaires
système.

12
7. Exigence de sauvegarde obligatoire avant l'utilisation des utilitaires système
critiques qui peuvent rendre les ressources système indisponibles.
8. Suppression obligatoire de tous les utilitaires inutiles des systèmes d'information,
y compris la désinstallation immédiate après l'achèvement du service.

Limitation du temps de connexion

L'auditeur des systèmes d'information doit évaluer les restrictions de temps de
connexion imposées pour assurer une plus grande sécurité des applications
sensibles et à haut risque. La restriction de temps peut être imposée de deux
manières :
1. Restrictions de temps de connexion : Ce contrôle limite la connexion à une
heure particulière de la journée. Par exemple, le serveur pour un transfert
électronique de fonds doit refuser la connexion les jours fériés.
2. Restrictions de temps d'utilisation : ce contrôle force l'utilisateur à terminer la
fonction dans un délai spécifié. Le système met fin à la connexion à l'expiration du
délai et l'utilisateur doit relancer l'ensemble du processus, ce qui peut inclure une
nouvelle connexion. Une utilisation courante de ce contrôle est sur les sites de
commerce électronique. Il est également recommandé d'avertir l'utilisateur du
temps restant pour terminer la transaction.
L'application du contrôle de la limitation du temps de connexion réduit la fenêtre
d'opportunité pour les accès non autorisés et libère également les ressources
système pour des utilisations critiques et autres.

Avertissement
Un avis d'avertissement joue un rôle majeur dans l'éducation d'un utilisateur aux
conséquences de ses actions et réduit la possibilité d'une conduite erronée par un
utilisateur de bonne foi. Ceci est réalisé en affichant un écran d'avertissement,
avant de terminer la connexion ainsi qu'avant de commettre une action, qui
informe l'utilisateur de l'accès non autorisé ou des implications potentiellement
nuisibles de sa conduite. Une fois que l'utilisateur choisit d'agir après avoir été
correctement averti, de telles actions peuvent être interprétées comme de
mauvaise foi et même illégales. Ce contrôle, en plus de réduire les erreurs
innocentes, facilite également l'application des dispositions internes ou statutaires.
La majorité de ces avertissements sont générés par le système d'exploitation ou des
applications spécifiques. Par exemple, un navigateur Web peut avertir l'utilisateur
lorsque l'utilisateur passe d'un site sécurisé à un site non sécurisé qui ne fournit
aucune fonction de cryptage. Si l'utilisateur n'est pas autorisé à transmettre des
informations en utilisant un réseau non crypté, l'avertissement informera
l'utilisateur d'une telle violation.
En cas de traitement de transaction, l'écran d'avertissement rappelle à l'utilisateur
la transaction qu'il s'apprête à effectuer. De plus, une fois que l'utilisateur a revu
l'avertissement et a terminé la transaction, l'utilisateur ne peut pas nier avoir
connaissance de l'implication de la transaction.

12
Utilisateurs externes
L'étendue du contrôle mis en œuvre pour permettre l'accès à un réseau interne par
un utilisateur externe doit être plus robuste que les mesures mises en œuvre pour
un utilisateur interne. Toutes les demandes d'accès externes doivent être obligées
de passer par un pare-feu ou un système de prévention et de détection des
intrusions avant de pouvoir commencer le processus de vérification d'accès. Il peut
même être nécessaire de disposer d'un système de vérification d'identité
secondaire pour accéder aux ressources sensibles au sein du réseau. L'auditeur des
systèmes d'information doit examiner le cadre de sécurité d'accès pour pouvoir
juger de la vulnérabilité du système aux accès non autorisés de l'extérieur. Par
exemple, la plupart des sites bancaires sur Internet exigent que l'utilisateur
connecté fournisse un «mot de passe de transaction» pour pouvoir effectuer toute
transaction financière. Ceci s'ajoute à la connexion initiale nécessaire pour accéder
au menu de transaction.

Des pistes de vérification

Les pistes d'audit sont des enregistrements documentés des activités effectuées par
un utilisateur. Un tel dossier aide à restructurer un événement et à établir la
responsabilité. Les pistes d'audit peuvent être basées sur le système ou non. Par
exemple, les informations de connexion de l'utilisateur fourniront une piste d'audit
basée sur le système, tandis qu'une passe de porte fournira une piste d'audit
physique d'un accès. La qualité d'une piste d'audit, en particulier en termes
d'intégrité, est essentielle pour qu'elle soit admise comme preuve.

Journalisation des défauts

L'auditeur des systèmes d'information doit être assuré que tous les défauts sont
signalés et que les actions correspondantes sont prises. Les actions peuvent être de
nature corrective ou d'enquête. Tous les défauts signalés par les utilisateurs, qu'ils
résultent de défaillances du système ou d'une formation inappropriée, doivent être
enregistrés. L'audité doit avoir une politique établie pour la gestion des défauts
signalés, qui peut inclure les quatre procédures suivantes :
1. Un objectif de temps de rotation du service défini dans lequel des défauts
spécifiques doivent être traités et résolus.
2. Examen régulier des journaux de pannes pour déterminer si un rapport de panne
reste non résolu.
3. Système formel, et de préférence automatisé, d'escalade des pannes non
résolues après l'expiration du temps de rotation du service concerné.
4. Un audit des mesures correctives pour s'assurer que la solution n'a pas été
obtenue en compromettant les contrôles et, chaque fois qu'un tel compromis est
observé, que le processus de résolution a été dûment autorisé. Par exemple, le
déclenchement de l'alimentation résultant d'un système de stabilisation de
puissance défectueux peut être résolu en permettant une connexion directe avec
une source d'alimentation externe.

12
Journalisation et examen des événements
Un examen régulier des différents journaux système est essentiel pour développer
une meilleure compréhension des menaces de sécurité auxquelles sont confrontés
les systèmes d'information. Cela devrait inclure des exemples de tentatives de
compromis réussies et infructueuses. Un problème pratique majeur lié à l'examen
des journaux d'audit est le volume impliqué qui rend la recherche difficile. Cela
peut être contré en créant une copie du journal d'audit, puis en utilisant des outils
d'audit ou même des outils d'exploration de données pour rechercher des contenus
spécifiques. Il est important de créer une copie pour conserver l'intégrité des
fichiers journaux d'origine.
L'auditeur doit vérifier l'existence d'un plan documenté, qui définira, entre autres,
les sept éléments suivants :
1. Volumes d’informations à consigner
2. Exigence de chiffrement des fichiers journaux
3. Rotation des fichiers journaux
4. Exigence de conservation des fichiers journaux
5. Normes d'élimination des fichiers journaux
6. Sauvegarde des fichiers journaux
7. Sécurité des fichiers journaux pour empêcher toute altération éventuelle, y
compris la modification et la fabrication
Il est essentiel d'assurer la séparation des tâches tout en attribuant la
responsabilité de la revue des journaux afin que les responsables de la revue des
journaux soient différents de ceux dont les activités sont surveillées et
enregistrées.

MISE EN ŒUVRE D'UN AUDIT DES SYSTÈMES D'INFORMATION

DANS UNE AGENCE DE BANQUE

12
La procédure suivante détaille le déroulement de l'audit des systèmes d'information
dans une agence bancaire. On peut observer que l’essence du processus s’applique
également à l’audit d’une institution non bancaire.

1. Début de l’audit :
A. L'équipe d'audit des systèmes d'information se présente au directeur d'agence ou
au responsable fonctionnel dans le cas d'organisations non bancaires.
B. L'auditeur peut être tenu de fournir une pièce d'identité.
C. L'auditeur entreprend une discussion préliminaire sur l'informatisation en
succursale et la sensibilisation du personnel aux ordinateurs et à leur utilisation.
D. L'auditeur doit spécifiquement s'enquérir de l'existence d'un processus mixte
dans lequel une partie du processus est réalisée manuellement et le reste utilise
des systèmes d'information.

2. Examen des opérations de démarrage :

A. L'auditeur observe les procédures de démarrage. Si des messages d'erreur, tels
qu'une erreur de somme de contrôle ou des erreurs système, se produisent, une
note en est faite pour le rapport.
B. L'auditeur observe ensuite le processus de lancement de l'application du chef de
caisse et de la distribution des espèces sur le système à d'autres caissiers.
C. L'auditeur fait un premier aperçu de la salle des serveurs. L'environnement, la
présence d'actifs de systèmes d'information indépendants, les preuves d'utilisation
de la salle des serveurs à des fins diverses, le câblage et le câblage, etc., sont
observés.

3. Aperçu général :
A. L'auditeur ferait un aperçu des activités de la succursale afin d'identifier les
principaux domaines d'intérêt. Cela comprendrait les éléments suivants :
i. Taille de la succursale en termes d'actifs des systèmes d'information, de détails
de la succursale et de code d'identification.
ii. Situation commerciale - montant des dépôts et avances. Dans le cas
d'organisations non bancaires, cela comprendra des informations sur le chiffre
d'affaires, les bénéfices, etc.
iii. Nombre de membres du personnel, alphabétisés en informatique et autres.
b. L'auditeur observe par la suite diverses opérations, le nombre d'ordinateurs, la
disponibilité du personnel qualifié nécessaire, la maintenance des actifs
informatiques, etc.
c. L'auditeur détermine visuellement s'il existe des actifs du système d'information
excédentaires ou inutilisés. Il y a souvent des cas où les actifs du système
d'information ont été livrés à la succursale mais n'ont pas été mis en service. Les

12
détails d'un tel événement doivent être enregistrés car ils représentent un
investissement sous-utilisé.

4. Vue d'ensemble des enregistrements :

L'auditeur des systèmes d'information donne une vue d'ensemble des éléments
suivants :
A. Liste de tous les livres, registres et journaux tenus à jour dans la succursale
B. Registre des immobilisations relatives aux actifs informatiques
C. Rapports de fin de journée de la veille
D. Rapport d'audit précédent
E. Rapport d'inspection par les agences indépendantes et réglementaires
F. Enregistrer les enregistrements attestant les activités de maintenance
G. Registre contenant les numéros de téléphone d'urgence

5. Environnement physique :
Les facteurs environnementaux que l'auditeur des systèmes d'information doit
examiner et faire rapport sont les suivants :
A. Système de conditionnement d'air
B. Système d'alimentation électrique, système d'alimentation sans coupure,
générateurs, enregistrement des tests des lignes électriques
C. Sécurité physique pour empêcher tout accès non autorisé
D. Contrôles spécifiques à l'accès à la salle des serveurs
E. Qualité de l’environnement : humidité, poussière, etc.
F. Présence de produits alimentaires, de fumée, d'eau, etc. dans la zone de travail
G. Présence et état de fonctionnement du système de protection incendie et des
extincteurs
H. Espace global et environnement de travail présents

6. Audit matériel :
L'auditeur des systèmes d'information doit se pencher sur les détails des
installations matérielles sur le site de l'audité. Les activités que l'auditeur
effectuerait sont les suivantes :
a. L'audit matériel débute par une vue d'ensemble du matériel présent dans
l'agence et de son inscription correspondante dans le registre des immobilisations
des actifs du système d'information.

12
b. La satisfaction des utilisateurs, la rapidité du service du fournisseur et le respect
par le fournisseur des termes des contrats de maintenance sont vérifiés.
c. Un aperçu de la configuration matérielle sera fait pour identifier l'âge et l'état
d'obsolescence du matériel. La conversation avec les utilisateurs fournit également
des preuves corroborantes de l'efficacité des actifs du système.
d. L'auditeur des systèmes d'information passerait en revue les détails des dossiers
de réparation et d'entretien pour identifier les problèmes récurrents et non
résolus.
e. Une évaluation des services publics présents doit être faite pour évaluer leur
pertinence.
F. Le respect des conditions du contrat d'assurance sera vérifié et l'adéquation de
la couverture d'assurance sera vérifiée.
g. La procédure de présence, d'utilisation et d'autorisation d'accès aux manuels du
matériel est revue.
h. Le rapport sur l'audit du matériel porterait sur les aspects suivants :
i. Environnement physique
ii. Périphériques et supports de stockage
iii. Serveur client
iv. Appareils d'authentification
v. Entretien
vi. Gestion des problèmes
vii. La gestion du changement
viii. Gestion de la sécurité
ix. Classification et contrôle des actifs

7. Audit logiciel :
Les différents aspects qu'un auditeur des systèmes d'information doit couvrir sont
les suivants :
a. La satisfaction des utilisateurs, la rapidité du service du fournisseur et le respect
par le fournisseur des conditions des contrats de maintenance logicielle doivent
être examinés.
b. L'application des dernières mises à jour de tous les logiciels de la succursale doit
être vérifiée.
c. Les procédures de maintenance préventive, détective et corrective des logiciels
doivent être vérifiées.

12
d. La sécurité, l'utilisation et l'autorisation des manuels de logiciels doivent être
vérifiées.
e. Vérifiez si tous les logiciels sont sous licence.
F. Vérifiez si le logiciel antivirus est régulièrement mis à jour et si les rapports
d'attaques virales sont examinés.
g. Les privilèges d'accès des utilisateurs et leurs limitations doivent être examinés.
h. Le rapport sur l'audit logiciel peut inclure les aspects suivants :
i. Antivirus
ii. Classification et contrôle des actifs
iii. La gestion du changement
iv. Logiciel de communication
v. Protection des fichiers et des répertoires
vi. Entretien
vii. Système opérateur
viii. Implémentation du logiciel de package
ix. Paramétrage
X. Gestion des problèmes
xi. Gestion de la sécurité
xii. Licence de logiciel
xiii. Conversion et réconciliation du système
xiv. Contrôle du logiciel système
xv. Transaction en cours
xvi. Programme utilitaire

8. Audit du réseau et des communications :

l'objectif d'un audit du réseau est de s'assurer que l'intégrité du réseau est
maintenue, que seuls les utilisateurs autorisés ont accès aux ressources du
système, que le réseau fonctionne de manière efficace et efficiente, que la
sécurité du réseau est assurée et que le réseau reste disponible pour les
utilisateurs autorisés. Les domaines suivants sont examinés en fonction de leur
impact sur la confidentialité globale, l'intégrité et la disponibilité des actifs du
réseau lors de la réalisation de l'audit du réseau :
a. Logiciel de communication
b. Communication de données

12
c. Transfert électronique de fonds
d. La sécurité sur Internet
e. Réseau local
F. Entretien
g. La gestion du changement
h. Gestion des problèmes
i. Gestion de la sécurité
j. Réseau sans fil

9. Sensibilisation du personnel :
Le personnel fait partie intégrante des systèmes informatiques. L'auditeur des
systèmes d'information doit commenter les domaines suivants :
a. Adéquation de la formation
b. Conscience des problèmes de sécurité, en particulier les suivants :
i. Secret des mots de passe
ii. Responsabilité en cas d'urgence
iii. Authentification des rapports
iv. Prévention contre les menaces réseau
c. Sensibilisation aux questions juridiques applicables avec une attention
particulière à la violation pénale de la loi

10. Maintenance des mots de passe :

La maintenance des mots de passe est au cœur de la sécurité d'accès. L'auditeur
des systèmes d'information doit résoudre les problèmes suivants lors de
l'établissement de rapports sur la gestion des mots de passe :
a. Longueur minimale des mots de passe
b. Secret des mots de passe
c. Changement périodique forcé des mots de passe
d. Les mots de passe actifs du personnel ne sont plus présents

11. Environnement logique :

les paramètres définis dans le système doivent être revus par l'auditeur des
systèmes d'information pour garantir le bon fonctionnement des programmes
d'application. L'auditeur doit vérifier son processus de mise à jour et si la
méthodologie d'autorisation du fabricant-vérificateur est suivie lors de la mise à
jour des paramètres.

12
a. L'auditeur peut vérifier si les instructions des circulaires et les directives
internes ont été mises à jour dans le système en temps opportun et correctement.
b. L'auditeur peut effectuer un test de paramètres, tels que les taux d'intérêt sur
les dépôts, les taux d'intérêt anticipés et les taux d'intérêt pénaux.
c. Les paramètres tels que les niveaux d'autorisation, les niveaux de privilège et les
paramètres liés au système doivent être vérifiés.
12. Accès au serveur : l'auditeur des systèmes d'information doit être assuré que
l'accès aux serveurs est correctement protégé. L'auditeur peut examiner les
éléments suivants pour vérifier la même chose :
a. L'auditeur doit examiner la liste des personnes autorisées à accéder à la salle
des serveurs. La méthodologie de contrôle d'accès à la salle des serveurs est à
vérifier. Cela peut inclure un nombre limité de membres du personnel accédant à
la salle des serveurs, la clé étant maintenue par deux personnes, et ainsi de suite.
b. L'utilisation d'un langage de requête structuré (SQL) ou d'outils similaires pour
l'accès direct à la base de données en contournant le logiciel d'application doit être
limitée et contrôlée. L'auditeur des systèmes d'information doit vérifier les
enregistrements de cet accès direct, y compris l'utilisation de SQL et d'autres
techniques pour déterminer le niveau de contrôle de l'accès direct à la base de
données.
c. L'auditeur peut vérifier l'enregistrement de toutes les activités réalisées sur le
serveur et si une autorisation écrite pour chacune de ces activités a été obtenue.
d. Un enregistrement d'occurrence d'erreurs de base de données doit être examiné
par l'auditeur avec un accent particulier sur l'analyse des causes et des effets des
erreurs.

13. Réparation et maintenance :

L'auditeur des systèmes d'information doit vérifier les enregistrements et les
documents et déterminer le processus pour :
a. Identification du personnel de maintenance
b. Déclaration du vendeur de fidélité et de secret
c. Accès de diagnostic autorisé au personnel de maintenance
d. Déclaration par le vendeur des activités réalisées par le vendeur
e. Enregistrement de la suppression des actifs informationnels

14. Programmes et dossiers non autorisés :

L’auditeur des systèmes d'information doit vérifier s'il existe des dossiers
(répertoires) le système qui n’est pas autorisés. L'auditeur doit également
rechercher si l'un des éléments suivants est installé dans le système et, le cas
échéant, si l'autorisation a été obtenue.

12
a. Outils de craquage de mots de passe
b. Programmes utilitaires
c. Jeux
d. Dossiers personnels
e. Autres programmes ou données en dehors de ceux appartenant aux systèmes
d'exploitation et d'application autorisés

15. Rapports de fin de journée :

L'auditeur des systèmes d'information doit accorder une attention particulière aux
rapports générés en fin de journée.
L'auditeur doit obtenir et examiner spécifiquement les éléments suivants :
a. Liste des rapports à générer
b. S'il y a une erreur dans la génération du rapport
c. Messages d'erreur pendant le processus de fin de journée
d. Rapports pour
i. Des pistes de vérification
ii. Journaux d'activité
iii. Des exceptions
iv. Échec des tentatives de connexion

16. Sauvegarde :
Au cours de l'audit, l'auditeur des systèmes d'information doit revoir la procédure
de sauvegarde dans la pratique en se référant particulièrement aux points
suivants :
a. Procédure de sauvegarde
b. Test périodique des médias
c. Test périodique de récupération à partir d'une sauvegarde
d. Stockage de sauvegarde
e. Zones sélectionnées pour la sauvegarde

17. Plan d’urgence :

Ce contrôle critique nécessite une revue approfondie par l'auditeur des systèmes
d'information. L'examen comprendra les éléments suivants :

12
a. Présence du plan
b. Connaissance du plan
c. Test du plan et des résultats
d. Tests correctifs réalisés au vu des résultats des tests du plan
e. Disponibilité immédiate des numéros d'urgence
F. Liste du personnel à contacter en cas d'urgence
g. Enregistrement des pannes, des temps d'arrêt et de la maintenance
h. Présence de dispositions de secours adéquates pour les actifs critiques

CONSIDÉRATIONS SPÉCIALES DANS UN SYSTÈME

BANCAIRE DE BASE

Le système bancaire de base est un environnement qui utilise une architecture

client-serveur, avec un serveur distant et des succursales clientes. Le serveur
distant est souvent appelé centre de données, tandis que les clients sont situés
dans divers points de service, y compris les succursales. Une architecture similaire
se trouve dans la plupart des organisations non bancaires avec des opérations
multi-sites. L'auditeur des systèmes d'information peut se concentrer sur les
domaines suivants.

Contrôles de migration
Si la succursale a migré vers un système bancaire central, il est essentiel de
garantir la cohérence et l'intégrité des données qui ont été migrées. Divers
contrôles de validation peuvent être effectués à cette fin, y compris la vérification
des paramètres liés au système et à l'application, la vérification des données de
base, la cartographie des comptes clients, en particulier leur liaison avec les
tableaux appropriés, les codes de programme, les sous-titres du grand livre, etc.

Contrôles de fin de journée

Le traitement de fin de journée est un processus crucial dans l'environnement du
système bancaire central. Les processus de fin de journée impliquent diverses
questions opérationnelles telles que le calcul des intérêts, l'exécution des
instructions permanentes, les transactions interbranches, le rapprochement
interbranches, etc. Le processus, entre autres activités, identifie les problèmes
critiques, tels que les transactions incomplètes avec un tronçon affiché, les
espèces non équilibrées, les retraits aux guichets automatiques non rapprochés
avec le titulaire de compte d'une autre banque et des problèmes similaires. Le
processus de fin de journée ne sera pas terminé tant que tous les processus définis
par la banque n'auront pas été correctement exécutés.

12
Dans le cadre du système bancaire central, la procédure de fin de journée est
essentiellement gérée de manière centralisée au centre de données. Au cours du
processus de fin de journée, la banque peut déterminer si des transactions sont
restées non autorisées. Différents rapports de contrôle sont générés à la fin de la
journée pour garantir l'intégrité des transactions et fournir des informations de
non-respect des contrôles spécifiés tels que la connexion, le système
d'autorisations, les exceptions et les anomalies. Certains des rapports générés qui
doivent être examinés par l'auditeur des systèmes d'information comprennent les
quatre suivants :
1. Rapport exceptionnel contenant :
a. Comptes dont le solde est passé du débit au crédit et vice-versa
b. Suppression des enregistrements de maturité
c. Réactivation des comptes inactifs
d. Retrait autorisé au-delà de la limite
e. Débit sur les comptes liés aux revenus
f. Factures en souffrance et factures retournées
g. Retrait autorisé contre collecte en compensation
h. Solde débiteur des comptes de dépôt
i. Solde créditeur des comptes de prêt
j. Découvert temporaire au-delà de la limite de sanction
k. Instruction permanente non exécutée ou non honorée dans la journée
2. Liste des utilisateurs
3. Accéder aux journaux
4. Liste des inscriptions rejetées ou annulées

Contrôle des exécutions périodiques / en masse (transactions

générées par le système)
Dans le cadre du système bancaire central, le centre de données exécute souvent
diverses transactions relatives à un groupe de clients. Les succursales ou autres
canaux de service vérifient les rapports sur ces transactions pour s'assurer de leur
exhaustivité et de leur exactitude. Voici quelques exemples de telles transactions :
1. Demande d'intérêt
2. Application des frais de service
3. Modifications des paramètres mondiaux tels que le taux d'intérêt
4. Équilibrage et rapprochement des comptes généraux et subsidiaires

12
5. Identification des comptes de prêt qui ne servent pas à rembourser les intérêts
ou à rembourser le principal et à les classer selon la norme interne ou statutaire.
Le traitement centralisé est principalement un processus automatisé, mais pendant
un cycle de traitement, certains des processus restent non exécutés ou sont
exécutés par erreur. Par exemple, il peut y avoir une demande incorrecte ou une
non-application d'intérêt pendant le traitement d'une demande d'intérêt pour les
cinq raisons suivantes :
1. Le taux d'intérêt n'est pas correctement associé au produit. Par exemple, le taux
d'intérêt d'un prêt personnel est à tort lié au taux d'intérêt d'un prêt au logement.
2. L'indicateur de collecte des intérêts est conservé comme «N» au lieu de «Y», ce
qui entraîne une non-application d'intérêt.
3. La date de la prochaine demande d'intérêt est la même que la date d'application
de l'intérêt.
4. Le compte n'a pas été confirmé bien qu'une transaction ait commencé sur le
même.
5. Le compte a été marqué à tort comme étant en souffrance ou non performant,
entraînant la non-application des intérêts.

Contrôle des transactions inter-SOL

Dans un environnement de système bancaire central, chaque entité comptable, qui
est généralement une succursale, est désignée par un point de service (SOL) ou un
cadre. Les transactions automatisées sont initiées par le SOL audité pour un autre
SOL et également par un autre SOL pour le SOL audité. Ces transactions doivent
être rapprochées de manière centralisée au centre de données pendant le
processus de fin de journée. Les entrées qui ne sont pas rapprochées
automatiquement sont des sujets de préoccupation et doivent être examinées pour
déterminer si l'erreur a été causée par une erreur d'entrée ou était une erreur de
conception du système ou une erreur de traitement.

Contrôle des transactions proxy / parking

Dans le cours normal des activités bancaires et dans le respect du protocole du
Créateur-vérificateur (maker-checker), certaines transactions peuvent ne pas être
vérifiées et autorisées à être affichées et ne pas être postées bien qu'elles aient
été saisies. Dans le même temps, les banques doivent exécuter le processus de fin
de journée, ce qui n'est pas autorisé en présence de telles entrées en suspens. Pour
contourner ce problème, ces transactions sont publiées dans un compte appelé
compte proxy ou compte de stationnement. Si le vérificateur des systèmes
d'information constate qu'un grand nombre de ces écritures en suspens sont
comptabilisées dans le compte de stationnement, il doit enquêter sur la question
pour en déterminer la raison.
Ces transactions sont généralement de deux types :

12
1. Généré par le système : Cela comprend les transactions exécutées au cours de
diverses exécutions du système. L'exécution des instructions permanentes au
centre de données le dernier jour du mois pour clôturer le SOL est un exemple
courant de telles transactions. Si le numéro de compte du titulaire du compte a
changé pour quelque raison que ce soit, cette transaction peut ne pas être
enregistrée sur le compte concerné et restera dans le statut «saisi» et sera publiée
dans le compte proxy.
2. Générées par l'utilisateur : Ces transactions sont initiées par l'utilisateur, mais
en raison d'une saisie erronée ou d'un traitement incomplet, elles ne sont pas
enregistrées sur le compte désigné. Ces transactions sont également conservées
dans un compte proxy ou de parking. Par exemple, si un chèque a été déposé en
faveur d'un compte et qu'un numéro de compte erroné a été fourni, la transaction
sera parquée dans le compte de stationnement.

Cartographie des comptes

Le mappage fait référence à la liaison des comptes avec divers codes de schéma,
tableaux, sous-titres du grand livre, etc. Il détermine comment le système exécute
les transactions basées sur des paramètres pour ces comptes. Par exemple, un
compte de prêt automobile doit être lié au maître de crédit automobile pour
l'application du taux d'intérêt pertinent. Un mappage incorrect compromettrait
l'intégrité des données, entraînerait des rapports trompeurs et pourrait entraîner
de graves complications juridiques. L'auditeur des systèmes d'information doit
vérifier ces transactions sur les comptes clients sélectionnés sur une base de test
pour s'assurer que la cartographie est effectuée correctement. Les auditeurs
devront également vérifier que les paramètres globaux des fichiers liés sont
correctement saisis.

Examen du contrôle des applications

Les domaines qu'un auditeur des systèmes d'information doit vérifier sont les sept
suivants :
1. Maintenance du profil utilisateur : Le module de maintenance du profil
utilisateur est utilisé pour créer, modifier et supprimer des utilisateurs. L'auditeur
des systèmes d'information doit vérifier que seuls les utilisateurs autorisés sont
actifs. Les utilisateurs qui ont quitté la succursale ou qui ont été résiliés ne doivent
pas avoir d'identifiant d'utilisateur dans le système. Les données archivées doivent
vérifier que ces ID utilisateur ont été supprimés. Si un utilisateur est
temporairement absent, l'ID utilisateur doit être marqué comme inactif. L'auditeur
des systèmes d'information doit vérifier si l'accès des utilisateurs aux menus et
leurs permissions sont proportionnels au travail assigné aux utilisateurs. Les
paramètres d'autorité et de responsabilité du système doivent également être
vérifiés.
2. Maintenance de l'ID utilisateur : chaque ID utilisateur doit se voir attribuer un
profil utilisateur standard qui définit les droits d'accès aux données et les privilèges
de l'utilisateur. Le profil peut définir l'accès aux menus, accorder le pouvoir de

12
contourner les exceptions, autoriser les transactions à publier, etc. Différents
profils d'utilisateurs standard, également appelés classes de travail, peuvent être
définis dans le système pour diverses fonctions d'exploitation, telles que l'opérateur
système, le caissier, le superviseur, le coffre-fort, le responsable de la succursale,
l'administrateur de la base de données, l'auditeur financier, les systèmes
d'information auditeur, administrateur, etc. L'auditeur des systèmes d'information
doit vérifier l'adéquation de la conception et de la mise en œuvre du système de
maintenance de l'ID utilisateur.
3. Gestion des mots de passe : Le mot de passe doit avoir une longueur minimale
selon les normes prescrites et être changé périodiquement. L'auditeur des systèmes
d'information peut effectuer des tests de vérification et revoir l'historique des
modifications de mot de passe pour déterminer si la politique est suivie.
4. Tentatives de connexion : généralement après un nombre spécifié de
tentatives de connexion au cours desquelles l'utilisateur ne parvient pas à fournir le
mot de passe correct, le système verrouille la personne. L'ID utilisateur doit être
libéré ou déverrouillé par l'administrateur. Ce processus de verrouillage et de
déverrouillage doit laisser une piste d'audit qui doit être revue par l'auditeur des
systèmes d'information.
5. Journaux d'accès et revues : Les journaux d'accès générés par le système
doivent être revus quotidiennement par une personne autorisée de la succursale
pour s'assurer qu'aucun accès non autorisé n'a été effectué. L'auditeur des systèmes
d'information doit vérifier que l'examen est effectué uniquement par la personne
autorisée.
6. Détection et protection des virus : le programme antivirus de chaque machine
doit être activé et mis à jour. L'auditeur des systèmes d'information doit vérifier la
dernière date de mise à jour et le rapport archivé de confinement des virus
présents dans les archives antivirus.

7. Interfaçage de modules: un système bancaire de base est souvent interfacé

avec divers modules d’applications tierces, par exemple un module d’activité
gouvernementale, un module de relation client, un module de pré-sanction et de
post-sanction de prêt, un module de lutte contre le blanchiment d’argent, un
module de connaissance du client module de transfert électronique de fonds,
module de banque mobile, module de banque en ligne, module de gestion de point
de vente, etc. L'auditeur des systèmes d'information doit vérifier ces interfaces et
évaluer leur mise en œuvre de la sécurité pour s'assurer qu'elles ne compromettent
pas le cadre de sécurité du système hôte.

12
Administration de la base de données et du système
Les aspects de l'administration des bases de données et des systèmes qu'un
auditeur des systèmes d'information doit vérifier comprennent les 10 suivants :
1. Administrateur de base de données et administrateur système :
L'administrateur système ne doit pas avoir accès aux données. Par conséquent,
dans un système bancaire de base, l'administration du système et la fonction
d'administration de la base de données doivent être assurées par deux personnes
distinctes. L'administrateur système et l'administrateur de la base de données
doivent être changés à intervalles réguliers. L'auditeur des systèmes d'information
doit revoir l'arrangement et commenter toute violation.
2. Séparation des tâches : Dans un système informatisé, il est généralement
inapproprié qu'une seule personne effectue plusieurs étapes menant à l'achèvement
d'une seule fonction, y compris celle de création et de contrôle. Habituellement,
ces fonctions sont exécutées par différentes personnes dans un système manuel et
sont communément appelées «fonctions non compatibles». La possibilité pour une
seule personne de pouvoir exécuter toutes les étapes d'une fonction conduit
souvent à une sérieuse compromission du principe de base de la séparation des
tâches. Le principe de séparation des tâches garantit la non-exécution de fonctions
incompatibles par un seul individu. Il est nécessaire de garantir qu'aucun utilisateur
d'un système sensible ne puisse effectuer toutes les parties d'une transaction.
L'auditeur des systèmes d'information doit vérifier que les «fonctions non
compatibles» ne sont pas exécutées par une seule personne.
3. Accès aux comptes de super-utilisateurs : ces comptes ont des privilèges plus
élevés. Ils ont généralement des privilèges d'autorisation, des privilèges pour
effectuer des transactions exceptionnelles, etc. L'accès à ces profils d'utilisateurs
devrait être restreint et les pistes d'audit de leur utilisation devraient être
conservées en détail. L'auditeur des systèmes d'information doit confirmer qu'il n'y
a pas eu d'exceptions à ce contrôle critique.
4. Utilisation des mots de passe : les mots de passe devraient idéalement être
stockés sous une forme cryptée, bien que souvent ce ne soit pas le cas en raison du
niveau de technologie utilisé. Les mots de passe devraient être obligatoires pour
tous les systèmes d'exploitation et d'application, à l'exception de l'application
bancaire de base. Les mots de passe du logiciel système doivent être régulièrement
modifiés. L'auditeur des systèmes d'information doit vérifier si la procédure de
maintenance des mots de passe est conforme à la politique de mot de passe
acceptée.
5. Modification des niveaux de privilège : l'auditeur des systèmes d'information
doit vérifier le processus de modification des niveaux de privilège. Un utilisateur
avec un niveau de privilège inférieur ne doit pas être autorisé à modifier le niveau
de privilège d'un utilisateur avec un niveau de privilège plus élevé.
6. Gestion des problèmes : l'auditeur des systèmes d'information doit se référer au
registre des problèmes pour comprendre les problèmes récurrents liés au système.

12
Les problèmes de base de données qui se sont produits peuvent être un signe
avant-coureur de compromissions de l'intégrité des données.
7. Gestion du changement : l'auditeur des systèmes d'information doit vérifier les
mesures de sécurité adoptées lors de la migration d'un système à un autre ainsi que
les problèmes d'intégrité et de cohérence des données découlant de cette
migration. En cas d'insuffisance ou d'inefficacité des procédures constatées, un
audit de migration indépendant peut être recommandé par l'auditeur des systèmes
d'information.
8. Accès aux journaux de la base de données : L'accès aux journaux de la base de
données doit être restreint. L'utilisateur ne doit pas pouvoir modifier les entrées
des journaux de la base de données. L'utilisation de programmes d'accès direct à la
base de données tels que SQL doit être restreinte. L'accès direct à la base de
données doit être consigné avec les raisons d'utilisation et les détails des
commandes utilisées. L'auditeur des systèmes d'information doit vérifier l'efficacité
de ces contrôles et commenter ceux-ci dans le rapport d'audit.
9. Cryptage des données : l'auditeur des systèmes d'information doit vérifier si des
méthodologies de cryptage standard sont utilisées. L'utilisation peut être à deux
niveaux :
a. Niveau VPN : les données doivent être cryptées lors de leur transfert sur le
réseau.
b. Niveau de stockage : les données stockées dans la base de données doivent être
cryptées.
10. Test de sauvegarde et restauration périodique : Le système et la base de
données doivent être périodiquement sauvegardés. L'auditeur doit vérifier le
processus de sauvegarde, le stockage de la sauvegarde et si les supports de
stockage sont périodiquement testés pour la restauration.

Pare-feu
Les principaux aspects des pare-feu qu'un auditeur des systèmes d'information doit
vérifier comprennent les 13 suivants :
1. Estimation du niveau de bande passante : Le système peut devenir très lent à
moins que la disponibilité de la bande passante ne soit calculée en tenant compte
de l'installation d'un pare-feu. Si l'auditeur des systèmes d'information constate une
telle situation, un commentaire doit être inclus dans le rapport d'audit.
2. Emplacement des pare-feu : l'auditeur des systèmes d'information doit vérifier
l'emplacement des pare-feu en examinant le schéma du réseau. La présence d'un
pare-feu est un impératif pour tous les points d'interaction du système interne avec
l'environnement externe.
3. Présence de serveur proxy : Pour protéger la base de données principale des
attaques, les banques peuvent utiliser un serveur proxy. Idéalement, l'utilisateur
doit d'abord être authentifié sur le serveur proxy avant de pouvoir accéder à la

12
base de données. Le serveur proxy doit également avoir un pare-feu installé. Le
L'auditeur des systèmes d'information doit vérifier la procédure en place et
commenter tout écart.
4. Restriction des services réseau : l'auditeur des systèmes d'information doit
vérifier si les autorisations fournies pour les services réseau sont conformes au
politique réseau. Ces restrictions, entre autres, peuvent inclure les éléments
suivants :
a. Le serveur peut ne pas être autorisé à lancer une connexion réseau, mais
uniquement recevoir et répondre aux demandes de connexion.
b. L'accès au port 80 (et / ou au port 443 pour SSL) avec un attribut spécifique peut
être autorisé, toutes les autres demandes étant refusées.
5. Restrictions de port : l'auditeur des systèmes d'information peut demander une
impression des autorisations définies dans le pare-feu et vérifier les restrictions de
port et leur conformité aux autorisations autorisées dans la stratégie réseau.
6. Connexion Internet : l'auditeur des systèmes d'information doit vérifier
qu'aucune machine n'est connectée directement à un modem USB commuté. Toutes
les connexions Internet doivent être acheminées via le pare-feu.
7. Système de noms de domaine: l'auditeur des systèmes d'information doit
vérifier que des serveurs DNS (Domain Name System) internes et externes séparés
sont utilisés et configurés pour «masquer» les noms d'hôte internes avant qu'ils ne
soient transmis sur le réseau. L'auditeur doit également vérifier les contrôles
supplémentaires appliqués dans les cas où un tel masquage n'est pas effectué.
8. Adresse IP : L'auditeur des systèmes d'information doit vérifier que toutes les
adresses IP internes sont masquées à l'internaute par des techniques telles que la
traduction d'adresses réseau (NAT), qui remplace l'adresse IP interne par une
adresse IP de substitution.
9. Gestion des mots de passe du routeur : les mots de passe du routeur doivent
être modifiés à intervalles réguliers. L'auditeur des systèmes d'information doit
vérifier le système de gestion des mots de passe du routeur et les preuves des
changements périodiques.
10. Journalisation et examen des journaux : l'auditeur des systèmes d'information
doit vérifier si les journaux du pare-feu sont conservés et revus régulièrement.
11. Zone démilitarisée : L'auditeur des systèmes d'information doit vérifier si les
serveurs d'application et de base de données sont maintenus séparés du serveur
Web dans la zone démilitarisée. Un pare-feu doit être placé avant la DMZ.
12. Mise à jour des correctifs pour le pare-feu : Le programme de pare-feu doit
être mis à jour avec les derniers correctifs et l'auditeur des systèmes d'information
doit examiner le dernier correctif implémenté et vérifier s'il s'agit du dernier
correctif publié.

12
13. Fonctionnement du pare-feu dans le site de sauvegarde : les pare-feu
doivent être présents non seulement sur le serveur principal mais également sur le
serveur de reprise après sinistre. L'auditeur des systèmes d'information doit vérifier
la présence et la configuration du pare-feu sur le serveur de reprise après sinistre.
Bande passante

La bande passante représente essentiellement le taux de transfert de données. Il s'agit d'une

mesure de données qui peuvent être transportées d'un point à un autre dans un temps donné,
généralement exprimées en secondes. L'unité de base de mesure de la bande passante est le
nombre de bits par seconde (bps). Cependant, l'expression la plus courante utilisée maintenant est
mégabits par seconde, ou mbps. Sur l'ensemble du réseau, lorsque les données sont transmises,
elles peuvent avoir différentes bandes passantes dans différents segments de réseau.

Réseau privé virtuel

Lors de l'établissement d'une connexion entre deux ordinateurs sur un grand réseau, le même
réseau est partagé simultanément par d'autres ordinateurs. Un réseau privé virtuel (VPN) assure la
sécurité pour garantir que le trafic réseau entre les deux ordinateurs reste isolé des autres
ordinateurs utilisant le même réseau. La connexion via VPN émule une connexion directe avec le
serveur, comme ce serait le cas dans une liaison point à point. Essentiellement, VPN est un réseau
privé qui utilise un réseau public pour établir la connectivité. La sécurité est assurée par le
cryptage des données transmises.

Serveur proxy

Un serveur proxy est positionné entre un ordinateur client et le serveur principal. Le serveur proxy
gère les requêtes du client et les transmet au serveur principal après avoir évalué les requêtes en
termes de sécurité et de fonctionnalité. Les serveurs proxy peuvent être utilisés pour filtrer les
demandes, par exemple en empêchant les employés d'accéder à un site Web spécifique. Il peut
également être utilisé pour améliorer les performances; par exemple, si un client demande les
mêmes informations que celles qui viennent d'être traitées par le serveur proxy, le serveur proxy,
au lieu de les transmettre au serveur principal, répondra à la demande par lui-même.

Serveur de noms de domaine

Les ressources d'un réseau sont identifiées grâce à l'adresse IP. Cependant, comme les adresses IP
sont difficiles à mémoriser, elles reçoivent souvent un nom alphabétique, qui est plus facile à
retenir. Par exemple, wiley.com est plus facile à retenir qu'un ensemble de 12 chiffres. Un serveur
de noms de domaine (DNS) est essentiellement un service qui traduit ces noms de domaine en
adresses IP. Le système DNS est un grand réseau en soi. Si un DNS particulier n'a pas connaissance
de l'adresse IP équivalente à un nom de domaine, il demande un autre DNS sur le réseau. Ce
processus se poursuit jusqu'à ce que l'adresse IP soit trouvée. Si le service DNS est arrêté, tous les
accès basés sur le nom de domaine cesseront de fonctionner.

Translation d'adresses réseau

La translation d'adresses réseau (NAT) est un système dans lequel les ressources résidant sur un
réseau privé local utilisent une seule adresse IP pour se connecter au réseau public. La traduction
des adresses IP des différentes ressources du réseau local est effectuée par le routeur. Par
conséquent, une seule adresse IP est requise pour représenter un groupe de ressources sur un
réseau privé local. Dès réception d'une communication entrante, le routeur l'envoie aux ressources
individuelles résidant à l'intérieur du réseau privé. Le VPN fonctionne un peu comme un standard
téléphonique où tous les utilisateurs internes accèdent à la même ligne externe à partir de
plusieurs postes internes. Ainsi, NAT réduit la demande d'adresses IP publiques individuelles pour
chaque ressource utilisée dans le réseau privé.

Zone démilitarisée

12
La zone démilitarisée (DMZ) est un petit réseau fonctionnant comme une zone neutre entre un
réseau privé et un réseau public. DMZ empêche l'accès direct au réseau privé depuis le monde
extérieur. Le plus souvent, ce réseau reçoit des demandes à la fois du réseau privé et des
ordinateurs du réseau public. Par la suite, l'hôte DMZ lance des sessions pour les demandes sur le
réseau public. Habituellement, l'hôte DMZ n'initie pas de session dans le réseau privé mais
transmet les paquets de données qui ont été demandés. Une DMZ peut être un réseau physique ou
logique.

Centre de support
Les banques gèrent et exploitent un service d'assistance 24h / 24 et 7j / 7, soit par
elles-mêmes, soit par le biais d'agences externalisées. Ces services d'assistance
sont un point de contact unique pour les utilisateurs des ressources système pour
toutes leurs requêtes opérationnelles. Les services d'assistance sont généralement
connectés aux réseaux de toutes les succursales, en utilisant une combinaison
d'assistance vocale, une page Web dédiée au service d'assistance et une application
de journalisation des problèmes d'assistance.
La majorité des problèmes survenant dans un système bancaire central liés au
matériel, aux logiciels, au réseau, etc., sont résolus via le service d'assistance. La
situation est similaire dans les organisations non bancaires. Le logiciel d'assistance
analyse les profils des problèmes et génère automatiquement une liste des
problèmes fréquemment rencontrés et un historique de résolution. La revue de ces
réponses par l'auditeur des systèmes d'information leur permettrait d'identifier les
problèmes récurrents et l'efficacité du processus de résolution. L'analyse du journal
du support technique est extrêmement utile pour définir le profil de vulnérabilité
de l'audité.

Sécurité des informations

Dans un environnement de système bancaire central, l'auditeur des systèmes
d'information doit vérifier les quatre procédures suivantes :
1. Respect de la politique de sécurité de l'audité.
2. Si tous les programmes utilisés sont mis à jour avec les derniers correctifs de
sécurité.
3. Si la succursale bancaire adhère à la politique de confidentialité de la banque et
garantit la confidentialité des informations sur les clients.
4. En cas de services externalisés, si le fournisseur respecte la politique de sécurité
de l'information de la banque. Il peut également être nécessaire de procéder à un
audit des systèmes d'information de l'agence d'externalisation pour vérifier ce fait.

Journaux d'activité
L'auditeur des systèmes d'information devrait avoir une vue d'ensemble de la
procédure de vérification et de la périodicité de vérification des journaux par la
banque. Il convient de s'assurer que les journaux contiennent des détails adéquats,

12
tels que le temps d'accès, les activités effectuées et les ID utilisateur. Ces journaux
peuvent inclure, entre autres, les cinq éléments suivants :
1. Journaux du système d'exploitation
2. Journaux du pare-feu
3. Journaux du système d'application
4. Journaux SQL
5. Journal d'accès au terminal ATM

Écart par rapport aux modèles normaux

L'auditeur des systèmes d'information doit vérifier les sept éléments suivants dans
le système pour détecter tout modèle anormal :
1. Synchronisation de l'horloge du terminal et du serveur.
2. Échec et succès des événements de connexion et de déconnexion.
3. Enregistrement du redémarrage, de l'arrêt et de l'accès au système.
4. Enregistrement de l'évolution du profil de sécurité du système.
5. Modifications du profil de gestion des utilisateurs et des groupes.
6. Succès et échec de l'obtention de l'accès au fichier et à d'autres actifs
d'information.
7. Écart par rapport aux modèles d'utilisation «normaux», notamment les suivants :
a. Charge système inhabituelle à des moments précis.
b. Nombre de processus exécutés consécutivement.
c. Utilisation de la puissance de traitement et du réseau.
d. Ratio inhabituel de connexions échouées aux demandes de connexion.
e. Fréquence inhabituelle des demandes traitées par le pare-feu, y compris le
nombre de succès et de refus.
f. Tentatives d'accès multiples depuis le même compte utilisateur ou plusieurs
comptes utilisateurs depuis un terminal.
g. Demande d'accès ou activité sur des ports inhabituels, ce qui peut également
indiquer des attaques de virus.

Les pratiques du management

L'auditeur des systèmes d'information doit vérifier le processus de gouvernance des
systèmes d'information. Les domaines importants qui méritent l'attention de la
direction et des auditeurs comprennent les six suivants :

12
1. Système de mesure de l'utilisation des ressources physiques et de l'utilisation de
la bande passante des communications.
2. Arrangement pour acquérir des informations sur les nouvelles vulnérabilités de
sécurité.
3. Méthodologie de journalisation et de reporting des événements pour les
procédures de changement.
4. Évaluation de l'impact des changements sur la sécurité du système.
5. Lorsque le logiciel est acheté à l'extérieur, si le code source est détenu sur un
compte séquestre ou si des mesures appropriées ont été prises pour assurer la
continuité des activités en cas de cessation d'activité ou de soutien par l'agence
externe.
6. Si des rapports de synthèse adéquats sont mis à la disposition de la direction
pour permettre le suivi des éléments suivants :
a. Volume de transaction
b. Journaux des problèmes système
c. Des exceptions
d. Transactions non rapprochées
e. Autres problèmes clients ou opérationnels

Les activités opérationnelles

Les domaines opérationnels sur lesquels l'auditeur des systèmes d'information se
concentrerait comprennent les 13 suivants :
1. Si un seul utilisateur possède plusieurs ID utilisateur.
2. Si l'invite de commande est disponible pour les utilisateurs.
3. La procédure d'émission d'un nouveau mot de passe aux clients qui déclarent
avoir oublié leur mot de passe.
4. Les normes de restrictions sur l'utilisation d'ordinateurs portables individuels ou
d'autres appareils informatiques mobiles dans le système.
5. Présence de manuels d'exploitation / cartes de bureau pour les opérateurs.
6. Système d'autorisation pour le traitement par lots.
7. Liste des fichiers autorisés à être présents chez l'utilisateur.
8. Présence d'une liste de tables serveur autorisées.
9. Présence d'un schéma de réseau.
10. Présence de points d'accès supplémentaires - adresses IP statiques et
dynamiques.

12
11. Si les comptes invités ont été désactivés.
12. Si l'espace du serveur est adéquat.
13. Si un centre de reprise après sinistre robuste est présent.

Méthodologie

La méthodologie SecGrade est basée sur des listes de contrôle. L'auditeur des
systèmes d'information est tenu d'utiliser la liste de contrôle fournie au chapitre 12
de ce livre pour réaliser un audit des systèmes d'information et vérifier les réponses
de l'audité en effectuant des tests de corroboration.
La méthodologie s'articule autour de l'identification des contrôles nécessaires pour
gérer la majorité des risques auxquels sont confrontés les actifs et processus du
système d'information. L'objectif de l'entité auditée est de se protéger des risques
en mettant en place des contrôles. Les listes de contrôle sont conçues pour
identifier l'existence de tels contrôles et pour tester les performances de ces
contrôles. Une fois convaincu de l'existence et de la performance de chaque
contrôle, l'auditeur des systèmes d'information peut considérer le contrôle comme
efficace et répondre en conséquence à la question de la check-list.
Les questions des listes de contrôle sont conçues pour obtenir une réponse
objective : Oui ou Non. L'existence d'un contrôle mérite une réponse «Oui» et
attribue une note de risque de 0 (zéro) à l'audité, tandis qu'une réponse «Non»
attribue un minimum de 1 (une) note de risque pour l'audité. Des scores de risque
plus élevés sont attribués dans des cas spécifiques. Plus le score est élevé, plus les
systèmes d'information de l'audité sont risqués.

DOMAINES
Actuellement, les domaines et domaines d'application spéciaux suivants sont
couverts par la méthodologie ISecGrade. Ces listes de contrôle sont basées sur
divers contrôles des meilleures pratiques applicables aux domaines ou aux
applications. Les listes de contrôle d'audit d'ISecGrade se concentrent
principalement sur six aspects critiques des systèmes d'information et aident
l'auditeur à se forger une opinion sur la classification des risques, qui est la
septième étape. Ces sept étapes sont les suivantes :
1. Planification : elle couvre les contrôles de haut niveau que l'audité doit mettre
en place pour garantir un cadre de gouvernance adéquat pour les actifs des
systèmes d'information.
2. Essais de contrôle général : ce sont les facteurs «d'hygiène». Ces contrôles sont
applicables sur les systèmes d'information de l'audité, quels que soient la nature et
le type de contrôles matériels et applicatifs utilisés par eux.

12
3. Audit matériel : ces contrôles se concentrent sur la gestion, l'efficacité et
l'efficience du matériel.
4. Audit logiciel : il s'agit essentiellement de contrôles applicatifs qui devraient
généralement être présents dans tout logiciel.
5. Audit du réseau et de la communication : il comprend des listes de contrôle
pour la dorsale de connectivité de l'audité.
6. Examen de la conformité juridique : ces contrôles garantissent que l'audité est
respect des dispositions légales pertinentes.
7. Évaluation des risques informatiques : dans cette section, nous arrivons à un
score de risque composite grâce à un test des contrôles identifiés dans les listes de
contrôle. Il convient de noter que tous les contrôles peuvent ne pas s'appliquer à
toutes les entités. L'auditeur doit utiliser uniquement les questions de contrôle
pertinentes pour l'audité.

Les domaines couverts par ISecGrade sont les suivants :

Contrôle d'accès Access control
Antivirus Antivirus
Développement d'applications Application development
Classification et contrôle des actifs Asset classification and control
Plan d'audit Audit plan
Dispositifs d'authentification Authentication devices
Stratégie d'entreprise Business strategy
Gestion du changement Change management
Serveur client Client-server
Logiciels / appareils de communication Communication software/devices
Communication de données Data communication
Plan de reprise après sinistre Disaster recovery plan
Transfert électronique de fonds Electronic funds transfer
Protection des fichiers et des répertoires File and directory protection
Ressources humaines, fiche de poste, ressources et Human resources, job definition, resourcing and
formation training
Mise en place de la politique de sécurité des Implementation of information systems security
systèmes d'information policy
La sécurité sur Internet Internet security
Politique de sécurité des systèmes d'information Information systems security policy
Conformité légale Legal compliance
Réseau local Local area network
Stratégie informatique à long terme Long-term IT strategy
Entretien Maintenance
Système de contrôle de gestion Management control system
Système opérateur Operating system
Implémentation de logiciels packagés Packaged software implementation
Paramètres des paramètres Parameter settings
Périphériques et supports de stockage Peripheral devices and storage media

12
Audit de contrôle d'accès physique Physical access control audit
Environnement physique Physical environment
Gestion des problèmes Problem management
Gestion de la sécurité Security management
Séparation des tâches Segregation of duties
Plans informatiques à courte portée Short-range IT plans
Licence logicielle Software license
Conversion et réconciliation du système System conversion and reconciliation
Contrôles du logiciel système System software controls
Examen des services tiers et des fournisseurs Third-party and vendor services review
Transaction en cours Transaction processing
Programme utilitaire Utility program
Réseau sans fil Wireless network

L'audit des systèmes d'information doit commencer avec l'achèvement de la liste de

contrôle du plan d'audit. La liste de contrôle du plan d'audit est un document
important qui sera nécessaire pour justifier la qualité du travail et pour
l'attribution d'un certificat ISecGrade.

STRUCTURE DE CLASSEMENT
Chaque liste de contrôle sous ISecGrade a trois réponses possibles : Non Applicable,
Oui ou Non. Comme décrit précédemment, dans le cas où le contrôle est «Non
Applicable», l'auditeur ISecGrade exclura la question du périmètre de l'audit. Les
réponses «oui» sont reconnues par l'attribution d'un score de risque 0, tandis que
les réponses «non» entraînent l'attribution d'au moins un score de risque de 1.
L'adopté d'ISecGrade peut attribuer différentes notes de risque plus élevées
reflétant l'importance relative du contrôle dans l'entité auditée. Comme reconnu
précédemment, tous les contrôles répertoriés dans une liste de contrôle ainsi que
toutes les listes de contrôle peuvent ne pas être applicables à tous les audités.
Une fois l'audit ISecGrade terminé, l'auditeur de conformité ISecGrade calculera le
score de risque total obtenu par l'audité par rapport à chaque liste de contrôle et
comparera le score de risque total obtenu avec le score maximum possible, qui
exclut les contrôles «Sans objet». L'auditeur exprimera le score de risque total
obtenu en pourcentage du score maximum total possible. Cette étape sera répétée
pour toutes les listes de contrôle. L'auditeur doit noter que la non-applicabilité d'un
contrôle doit être vérifiée, en tenant compte de l'application utilisée et des
processus adoptés par l'audité. Une justification appropriée doit être documentée
avant de classer un contrôle comme «sans objet».
Enfin, l'auditeur fera un résumé de toutes les listes de contrôle et arrivera au grand
total des notes de risque attribuées à l'audité par rapport au total général des
notes maximales possibles. Le score total sera exprimé en pourcentage du score
total maximum possible. Ce pourcentage final est le score ISecGrade obtenu par
l'audité.

12
La notation standard des risques de l'audité peut être effectuée en utilisant un
différentiel de 20% de la manière suivante :
Score de risque jusqu'à 20%: hautement sécurisé
Score de risque supérieur à 20% et jusqu'à 40%: Sécurisé
Score de risque supérieur à 40% et jusqu'à 60%: sûr
Score de risque supérieur à 60% et jusqu'à 80%: Risque
Score de risque supérieur à 80%: très risqué

12