Réponse automatique à incident de sécurité Présentation d’une intégration Checkpoint et Splunk

1. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
Demo – Check Point et Splunk
Ajout d’une access-rule et installation de la policy

2. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
Objectif de la Démo
• Réponse automatique à incident de sécurité
• Short term containment
• Empêcher le poste compromis d’accéder aux machines du Datacenter
• Comment ?
• Depuis une alarme générée dans le SIEM
• Utilisation d’un script Python pour
• Se connecter à la Management Check Point
• Créer l’objet Host correspondant si celui-ci n’existe pas
• Créer une access-rule qui deny le host sur tout type de service
• Publier les changements
• Installer la policy

3. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
Moyens mis en œuvre
• Collecte des logs Windows avec
WEC
• Workstations
• DC
• Member Servers
• SIEM - Utilisation de Splunk
Enterprise
• Centralisation des logs Windows
• Corrélation d’events
• Alerting
• Exécution de scripts custom
• Check Point
• API Management R80.10
• Security Gateway R80.10

4. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
Exemple d’environnement Windows Event Collector
Domain Controlers
Workstations
Member servers
WEC server
Splunk
Indexer
Splunk
Indexer

5. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
Lab Environment

6. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
Workflow
Active Directory
DC
Bruteforce
sur le port
3389
Sharepoint
server
WEC server
WinEventLog:security
eventID 4625
LogonType 10
Events indexés dans
Splunk
Checkpoint
Firewall
Splunk
Splunk Alert
Engine
CKP Management
Block IP
172.20.204.100
Install
policy
1 2
3
4
6
172.20.204.100
sourcetype="wineventlog:security" EventID=4625
(LogonType="3" OR LogonType="10")| stats count
by src_ip dest_ip| where count > 15

7. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
R80.10 Management API - Fonctions utilisées
• Login --> authentification sur l’API
• Show-host --> vérifie l’existence d’un objet dans la policy
• Add-host --> ajout d’un objet dans la policy
• Show-access-rule --> vérifie l’existence d’une access rule dans la policy
• Add-access-rule --> ajout d’une access rule dans la policy
• Publish --> publication des changements effectués
• Install-policy --> installation de la policy
https://sc1.Check Point.com/documents/latest/APIs/index.html#introduction~v1.1%20
https://github.com/Check PointSW/cp_mgmt_api_python_sdk

8. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
Demo – Check Point et Splunk
Enrichissement de data grâce à l’API SandBlast ThreatCloud

9. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
ThreatCloud – Qu’est ce que c’est ?

10. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
Objectif de la Démo
• Enrichissement dynamique de données dans Splunk
• Quoi ?
• Les hash md5 des fichiers récupérés dans les event Sysmon
• Pourquoi ?
• Savoir si ceux-ci sont connus comme étant dangereux par Check Point
• Comment ?
• Grâce à une commande de lookup externe
• Utilisation d’un script Python pour
• Se connecter à l’API ThreatCloud
• Envoyer le hash du fichier
• Récupérer la réponse sous forme de nouveaux champs :
hash_signature et hash_status

11. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
Structure de l’appel
• API_KEY = "TE_API_KEY_RdsptswloiyrZNXYbkQhuXr3maou475XFlKKbhXX"
• headers = { "Authorization": API_KEY, "Content-Type": "application/json" }
• url = "https://te.Check Point.com/tecloud/api/v1/file/query"
• POST json
{
"request": [
{
"md5": "8dfa1440953c3d93daafeae4a5daa326",
"features": [
"av"
]
}
]
}

12. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
Structure de la réponse
{ "response":
{ "status": {
"code": 1001,
"label": "FOUND",
"message": "The requested data has been found."
},
"md5": "da855ff838250f45d528a5a05692f14e",
"features": [
"av"
],
"av": {
"malware_info": {
"signature_name": "Exploit.JS.Pdfka.fma.W.ygrku",
"malware_family": 22,
"malware_type": 104,
"sevirity": 4,
"confidence": 5
},
"status": {
"code": 1001,
"label": "FOUND",
"message": "The requested data has been found"
}
}
}

13. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
Use case
MAJ automatique d’acces rules

14. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
• Contexte
• Entreprise ayant toutes ses boites emails dans O365
• Antispam O365
• Les clients outlooks sont configurés pour envoyer/recevoir directement via
O365
• Les emails sortent directement par O365, aucune SMTP GW on prem
• Projet
• Projet de chiffrement des emails via la GW de chiffrement SMTP Totemomail
installée on premise
• La GW SMTP Totemomail doit être insérée dans le flux de mail : Outlook -->
O365 (cloud) --> Totemomail (on premise) --> O365 --> destinataire
• Les emails passant dans O365 sont chiffrés

15. V O T R E G U I D E E N S É C U R I T É I N F O R M A T I Q U E
• Problématique
• La GW Totemomail doit pouvoir être joignable depuis les serveurs O365
(Internet)
• Nous ne voulons pas exposer la GW Totemomail publiquement sur Internet
--> filtrage de l'accès à cette GW sur les IP des serveurs O365 uniquement
• Solution proposée
• Utilisation de l'API Check Point pour assurer le filtrage des accès à la GW
Totemomail on premise depuis les IP O365 uniquement
• Les IP O365 sont publiées et mises à jour par Microsoft
https://support.content.office.net/en-us/static/O365IPAddresses.xml
• Développement d'un script qui parse la liste d'IP/détecte les changements et
met à jour la politique Check Point