As part of their professional activities, pentesters, developers, and security specialists have to deal with such processes as Vulnerability Management (VM), (Secure) Software Development LifeCycle (S-SDLC).
These phrases cover different sets of practices and tools used, which are intertwined, although their consumers are different.<\/p>\n\n\n\n
Technological progress has not yet reached the point of replacing a person with one tool for analyzing the security of infrastructure and software.
It is interesting to understand why this is so and what problems one has to face.<\/p>\n\n\n\n
For our company, this is not only a subject of research and consulting task, but also the task that our product solves:\u00a0Deteact Application Security Platform\u00a0.<\/p>\n\n\n\n
The Vulnerability Management process is designed to continuously monitor infrastructure security and patch management.
The Secure SDLC (“Secure Development Cycle”) process is designed to maintain the security of an application during development and operation.<\/p>\n\n\n\n
A similar part of these processes is the Vulnerability Assessment process – vulnerability assessment, vulnerability scanning.
The main difference between VM and SDLC scans is that in the former, the goal is to detect known vulnerabilities in third-party software or configuration. For example, an outdated version of Windows or the default SNMP community string.
In the second case, the goal is to detect vulnerabilities not only in third-party components (dependencies), but primarily in the code of a new product.<\/p>\n\n\n\n
This creates differences in tools and approaches. In my opinion, the task of searching for new vulnerabilities in an application is much more interesting, since it is not limited to version fingerprinting, banner collection, brute-forcing passwords, etc.
For high-quality automated scanning of application vulnerabilities, algorithms are required that take into account the semantics of the application, its purpose, and specific threats.<\/p>\n\n\n\n
The infrastructure scanner can often be replaced with a timer: the point is that, purely statistically, you can consider your infrastructure vulnerable if you haven’t updated it for, say, a month.<\/p>\n\n\n\n
Scanning, as well as security analysis, can be performed both with a black box and with a white box.<\/p>\n\n\n\n
During blackbox scanning, the tool must be able to work with the service through the same interfaces through which users work with it.<\/p>\n\n\n\n
Infrastructure scanners (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) look for open network ports, collect banners, identify installed software versions, and search their knowledge base for information on vulnerabilities in those versions. They also try to detect configuration errors such as default passwords or public data access, weak SSL ciphers, etc.<\/p>\n\n\n\n
Web application scanners (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) can also detect known components and their versions (for example, CMS, frameworks, JS libraries). The main steps of a scanner are crawling and fuzzing.
During crawling, the scanner collects information about existing application interfaces, HTTP parameters. During fuzzing, mutated or generated data is substituted into all detected parameters in order to provoke an error and detect a vulnerability.<\/p>\n\n\n\n
These application scanners are classified as DAST and IAST – Dynamic and Interactive Application Security Testing, respectively.<\/p>\n\n\n\n
There are more differences in whitebox scanning.
As part of the VM process, scanners (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) are often given access to systems by performing an authenticated scan. Thus, the scanner can download installed package versions and configuration parameters directly from the system, without guessing them from the banners of network services.
The scan is more accurate and complete.<\/p>\n\n\n\n
If we talk about whitebox scanning (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) of applications, then we are usually talking about static code analysis and using the corresponding tools of the SAST class – Static Application Security Testing.<\/p>\n\n\n\n
There are many problems with scanning! I have to deal with most of them personally as part of providing a service for building scanning processes and secure development, as well as when carrying out work on security analysis.<\/p>\n\n\n\n
I will single out 3 main groups of problems, which are confirmed by conversations with engineers and heads of information security services in various companies.<\/p>\n\n\n\n
How to be?
I will talk in more detail about examples and how to deal with many of the listed problems in the following parts, but for now I will indicate the main directions in which you can work:<\/p>\n\n\n\n
Stay tuned and let’s disrupt the vulnerability scanning!<\/p>\n","protected":false},"excerpt":{"rendered":"
As part of their professional activities, pentesters, developers, and security specialists have to deal with such processes as Vulnerability Management (VM), (Secure) Software Development LifeCycle (S-SDLC).These phrases cover different sets of practices and tools used, which are intertwined, although their consumers are different. Technological progress has not yet reached the point of replacing a person…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"yoast_head":"\n