Shulou(Shulou.com)06/01 Report--

Cramming Sec into DevOps is not just a change in technology and tools, but also a change in the way of thinking and internal processes. The key principle to promote DevSecOps is: don't cause trouble.

The successful implementation of DevSecOps has been studied in "Gartner 2017 Research report: ten things that DevSecOps should do well" and "Gartner 2019 Research report: twelve things DevSecOps should do well". The two reports agree that the key challenge and first element of implementing DevSecOps is that "security testing tools and security control processes are well adapted to developers, rather than going in the opposite direction." The prerequisite for a security team to successfully integrate security testing or security controls into DevOps is:

Don't try to change the way programmers and testers work, and don't add extra work to them.

Otherwise, you will destroy the collaboration and agility of DevOps, and you will be doomed to become the target of public criticism and will not be able to land in the end. There are several painful cases in which the author failed because of undermining the collaboration and agility of DevOps.

The Integration Point of Application Security testing in CI/CD Software Development cycle

At present, there are many solutions for WEB application security testing in the market, among which the oldest and most widely used testing tools are SAST and DAST. By running security scanning on the source code (SAST) or public external interface (DAST), many vulnerabilities can be identified and corrected before the application is launched.

However, with the widespread acceptance of DevSecOps, Gartner explicitly advocated replacing SAST and DAST with Interactive Application Security Testing (IAST) in its 2017 research report, which read as follows:

It is feasible to consider interactive application security testing (IAST) instead of traditional static application security testing (SAST) and dynamic application security testing (DAST), and we recommend it. IAST is an improved form based on DAST, and the testing process is more visual, both internal and external. IAST combines the advantages of DAST and SAST to reduce false positives as much as possible while ensuring test code coverage.

Next, the author analyzes why Gartner advocates using IAST to replace SAST and DAST in DevSecOps.

1. SAST cannot be agilely integrated into DevOps because of its inefficiency and high false alarm rate.

First of all, we simply analyze the implementation principle of SAST. The general implementation of SAST scans the source code without running the code, such as lexical analysis, syntax analysis, control flow, data flow analysis and so on, and uses complex inspection rule matching to find and locate defects, and finally generate the results.

Although SAST can be integrated into the developer IDE environment and integrated into DevOps, SAST often needs a long scanning and analysis time, poor real-time performance and high false alarm rate, so it needs to invest a lot of resources of security team to remove these false positives.

In addition, SAST third-party open source components and open source frameworks referenced by applications do not effectively identify known security risks.

In short, the practical application of SAST in a DevSecOps environment is not easy unless you have a very abundant and experienced security team to constantly optimize, develop, and maintain it.

2. DAST can not be integrated into DevOps because of its limited adaptation to scenarios and serious impact on normal business function testing.

DAST is the most widely used security testing tool for WEB applications. Some manufacturers in the market secretly change the concept of DAST and call it IAST. IAST products are a mixture of fish and dragons, and the author is surrounded by the situation that it can not be seamlessly integrated into DevOps because of the choice of such products. In order to avoid trampling again, this article will spend a lot of space on discussing DAST-related technologies.

The principle of DAST is relatively simple, which is generally divided into the following stages: first, DAST uses crawler technology to obtain as many application URL as possible, and then analyzes and extracts external possible input points. Secondly, the input point in each URL is replaced by a different type of vulnerability Payload, which is essentially tampering with the original data message to replay the HTTP/HTTPS message to the WEB application in turn. Finally, the DAST receives the response message of the WEB application to analyze it to determine whether the vulnerability exists.

Due to the inherent defects of crawler technology, DAST faces many challenges. The first to bear the brunt is the problem that the crawler cannot crawl the full URL of the application. For example, when an application has AJAX, Token, CAPTCHA, independent API, etc., or where the execution of the application must rely on the execution of the result logic in the previous step, for example, it cannot be effectively covered in scenarios such as password reset and transaction payment. In order to solve the defects of DAST crawler technology, we usually proxy the traffic when the WEB/APP client accesses the application, such as configuring proxy through browser, * traffic proxy and so on. For the non-encrypted environment, we can also use several compensation schemes, such as switch traffic mirroring, application access log import, and deploying the client on the application server to obtain traffic. After the above remediation, DAST can avoid some defects of crawler technology.

After analyzing the DAST crawler defects, we will analyze the defects in the search input point and the Payload replacement phase.

Nowadays, transactional WEB/APP applications on the Internet must encrypt and sign the data in order to ensure the confidentiality and integrity of the data. however, this is almost a devastating blow to security testing tools such as DAST.

The fundamental reason is that DAST can not know the encryption algorithm and key used by its test application, can not be restored to clear text, and can not get a valid input point only by seeing a pile of garbled ciphertext, let alone replacing Payload. For the scenario where the application only has a signature, even if the DAST obtains a valid input point, tampering with the original message to replace the Payload playback data message will not be accepted or processed by the application.

Then suppose that DAST can seamlessly integrate DevOps into WEB applications that do not use encryption, signature and other scenarios to achieve automated security testing in the DevSecOps testing phase? Ladies and gentlemen, listen to me slowly.

First of all, we assume that DAST has passed a good transformation and no longer uses DAST crawler technology to obtain the URL of WEB applications (some manufacturers call themselves IAST~_~, and pseudo-IAST after the improvement), but solves the problem of obtaining application URL through various traffic collection methods. Then DAST begins the process of tampering with the original message, replacing the value of the input point with Payload, and replaying the data message. However, DAST can not predict in advance what type of security loophole will exist in the input point of URL, so it can only replace all the Payload of different vulnerability types in turn and replay the data message.

What are the consequences of this? The server traffic was magnified 20 times and barely solved by adding resources, but the scanning speed became extremely slow, and we dared not speak angrily. Due to the repeated submission of data due to replay of the data, the automated functional test failed (resulting in dirty data, functional abnormalities, etc.), and the test sister jumped, which was unbearable. A flash in an urgent situation: using delayed detection or timing plan detection function, put the vulnerability detection time after the end of the little sister test, not OK?! As a result, the corners of the mouth rose and smiled and began to configure the test to begin after 12:00 in the evening.

The next morning, I couldn't wait to log in to the DAST (pseudo-IAST) system to check the scan results, and the display and brain went blank. What about the loophole? It turns out that the login session of the application system timed out, some functions require one-time Token, some require SMS authentication, some interfaces can only be accessed by a specific IP, and some need to answer a random question before moving on to the next stage. Oh, these are all inexplicable!

Looking at the form, we can only use the necessary killing skills, and the sword is on the wrong side. Call the R & D department to a meeting, in order to make DAST (pseudo Iast) work properly, propose to let R & D maintain two versions synchronously, and need to add another version in addition to the normal function. This version requires no encryption, no session expiration, no CAPTCHA, no one-time Token, no signature, no... The R & D boss snapped up and was angry: in order to catch up with the progress of the project, you have to add MMP to the project. Do you want us to have 120?

The final outcome can be imagined, the leader stopped the application of DAST (pseudo Iast) in the functional testing phase, the beautiful security testing moved to the left, and the dream of automated security testing which was seamlessly integrated into the DevOps,DevSecOps testing phase was thus shattered. Of course, it can not be said that DAST (pseudo iast) is useless, DAST (pseudo iast) is just not suitable for automated security testing in the DevSecOps test phase or some complex applications of encryption and signing.

3. Passive IAST is the best tool to realize automatic security testing in DevSecOps testing phase.

First let's take a look at Gartner's definition of IAST:

Interactive application security testing (IAST) combines static application security testing (SAST) and dynamic application security testing (DAST). This aims to improve the accuracy of application security testing through the interaction of SAST and DAST technology. IAST integrates the advantages of SAST and DAST into one solution. This method makes it very easy to confirm whether the vulnerability is real and to determine its location in the application code.

Seeing here, we finally understand why the improved DAST is pseudo-IAST. According to the definition of Gartner, IAST needs to combine the technical advantages of both SAST and DAST, and the final detected vulnerability details should be very easy to confirm whether they really exist, and need to locate the code location where there is a security risk.

The details of IAST vulnerabilities include the detailed propagation process of the internal data flow within the application formed by the vulnerability, as well as the location of the code where the vulnerability exists. This is to make it easier for security personnel to confirm the authenticity of the vulnerability, make it easier for developers to understand the cause of the vulnerability, and make it easier for developers to fix the vulnerability on their own.

At present, there are two types of IAST in the market according to different implementation principles, active IAST and passive IAST. What these two types of tools have in common is that they are closely related to the application development language and require the deployment of Agent. Agent hook the underlying functions that may cause security risks.

Active IAST combines the function of DAST, tampering with the original message to replace Payload for data message playback, and real-time monitoring at the underlying function hook point. When listening to Payload entering the function hook point, it is judged that the loophole exists.

The advantage of active IAST is that there are almost no false positives and the detection speed is faster than DAST, but like DAST, there is no way to apply to complex application scenarios such as encryption, signature, one-time Token, and there are also problems such as generating dirty data and destroying functional test results. Therefore, active IAST can not be seamlessly integrated into DevOps to realize automated security testing in DevSecOps testing phase.

Finally, let's take a look at passive IAST. Passive IAST always protects silent monitoring in the process of vulnerability detection and does not replay messages actively. Passive IAST can detect more common vulnerabilities than SAST and DAST, because Agent can view all application code, application runtime control flow, application data flow information, environment configuration information, HTTP requests and responses, frameworks and other components used, back-end connection information, database connections, and so on. So how does passive IAST detect vulnerabilities?

In fact, the main principle of judging vulnerabilities in passive IAST is not complicated: passive IAST believes that external input parameters propagate to a risk function that may cause security vulnerabilities without security filtering, then they will be judged as vulnerabilities, of course, a lot of other logic will be added to the actual commercial products.

Principle

Passive IAST does not care about whether the input parameters passed in by the application are encrypted or not. It naturally supports scenarios with encrypted transmission.

Secondly, we can see that the passive IAST detection process does not need to replay data packets, so it naturally supports complex application scenarios such as signature, one-time Token, SMS verification, biological verification and so on, without affecting the normal business function testing.

Another feature of passive IAST is extremely high detection efficiency, accurate real-time vulnerability detection, and can complete security testing synchronously with functional operations.

Finally, passive IAST can not only solve the problem of general application vulnerability detection, but also manage the risk of open source components introduced by applications, which is particularly important for application development security.

Of course, IAST is not without defects, the main problem of IAST is that WEB applications developed in different languages need different types of Agent, especially the difficulty and investment in developing passive IAST technology are very huge, which is an important reason why there are so few commercial products of passive IAST.

In addition, IAST does not have crawler technology and does not actively replay data packets, so it is impossible to detect WEB applications without Agent, and IAST is not suitable for scenarios that require remote vulnerability scanning.

To sum up.

Passive IAST can be applied to any complex scenarios such as encryption, signature, one-time resources, and the detection process is safe and harmless, so it is the best tool to realize automatic security testing in DevSecOps testing phase.

Finally, let's review the overview of DevSecOps in the Gartner report:

Integrating security into DevOps to deliver DevSecOps requires a change in mindset, process, and technology. Security and risk management leaders must adhere to the collaboration and agility of DevOps so that security testing can be seamlessly integrated in development, thus making 'security' in DevSecOps transparent.

Therefore, in the actual promotion of DevSecOps, we should always adhere to "cooperation, agility and transparency". In addition, it is not only the change of technology and tools, but also the change of way of thinking and internal process can really achieve the expectations.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.