I published the following diary on isc.sans.org: “Comment your Packet Captures!“: When you are investigating a security incident, a key element is to take notes and to document as much as possible. There is no “best” way to take notes, some people use electronic solutions while others are using good
I published the following diary on isc.sans.org: “Using Bad Material for the Good“: There is a huge amount of information shared online by attackers. Once again, pastebin.com is a nice place to start hunting. As this material is available for free, why not use it for the good? Attackers (with
Based on my previous ISC SANS Diary, I updated the STIX feed to answer the requests made by some readers. The feed is now available in two formats: STIX 1.2 (XML) (link) STIX 2.0 (JSON) (link) There are updated every 2 hours. Enjoy!
I published the following diary on isc.sans.org: “Bots Searching for Keys & Config Files“. If you don’t know our “404” project, I would definitively recommend having a look at it! The idea is to track HTTP 404 errors returned by your web servers. I like to compare the value of 404 errors
I published the following diary on isc.sans.org: “DNS Query Length… Because Size Does Matter“. In many cases, DNS remains a goldmine to detect potentially malicious activity. DNS can be used in multiple ways to bypass security controls. DNS tunnelling is a common way to establish connections with remote systems. It is
I published the following diary on isc.sans.org: “Pro & Con of Outsourcing your SOC“. I’m involved in a project to deploy a SIEM (“Security Information &Event Management“) / SOC (“Security Operation Center“) for a customer. The current approach is to outsource the services to an external company also called a
I published the following diary on isc.sans.org: “Retro Hunting!“. For a while, one of the security trends is to integrate information from 3rd-party feeds to improve the detection of suspicious activities. By collecting indicators of compromize, other tools may correlate them with their own data and generate alerts on specific conditions.
Getting useful info from log file should be piece of cake …if the file is properly formatted! Usually, one event is written on a single line with useful info delimited by a separator or extractable using regular expressions. But it’s not always the case, welcome to the log hell…
Keeping an eye on logs is boring… but mandatory! Hopefully, sometimes it can reveal funny stuffs! It looks like people at the CCC are having some fun too while their annual conference is ongoing… Here is what I got in my Apache logs this morning: 22.214.171.124 – – [30/Dec/2015:06:51:22 +0100]
Tracking users with privileged access is a critical task in your security policy (SANS Critical Security Control #12). If the key point is to restrict the number of “power users” to the lowest, it’s not always easy. Most of them will argue that they need administrator rights “to be able to