Vulchain Scanner: 5 basic principles. New Year holidays in Russia lasts 10 days this year! Isn’t it an excellent opportunity to start a new project? So, I decided to make my own active network vulnerability scanner – Vulchain.
Why? Well, first of all, it’s fun. You can make the architecture from scratch, see the difficulties invisible from the user side and try something new in software development as well.
Basic principles of the project. This is not a dogma, but rather a general direction.
- Data layers. I would like to have this independent sets of data:
- Raw data collections
- Software versions detected from the raw data
- Vulnerabilities detected from the software versions
- Exploitability assessment data for the detected vulnerabilities
- Modularity. Most of functionality will be performed by the independent modules which read some data from one data level, and create some data on other data level.
- Transparency. Data is stored constantly on the all levels. You can easily figure out how the data was processed, track the errors and modify modules.
- Neutrality. All modules are independent and easily replaceable. For example:
- You can use Nmap or other port scanner to detect services. You can refuse active scanning completely and collect data from local agents or from your cmdb.
- You can use the Vulners Burp API and Linux Audit API to detect software vulnerabilities, use can use some other service or you can write your local detection scripts using NVD or Vulners Collections (see also “Vulnerability Assessment without Vulnerability Scanner“).
- Rationality. If it is possible to use some security utility, service or product, we will integrate with them, rather than writing our own analogue. We spend resources only on what will give us the maximum profit at a minimum of costs. 😉
