Which applications should you protect first? The question itself is wrong!

If your business is like most enterprises, there may be hundreds of or even thousands of applications in your IT environment. They are most likely written, updated and patched over the last 10 or 20 years. You may not be doing enough security work for those applications. Let's say that there is something that will give you a little relief that everyone we interviewed was in the same boat. The debt of safety will soon be piled up in the midst of the unconscious. At first, not many people can be aware of the security problems of the application, once the security problems, the consequences are sometimes difficult to imagine, rather than sit idly by, as early as possible to seek security solutions, this recommendation love Encryption-Mobile application Security encryption protection, professional encryption technology can completely let you out of worry!

Take a look at some of the worst tactics to tackle this challenge:

First Bad tactic: protect external-facing applications only.

This is one of the most common tactics. With limited resources, your organization's teams focus on external-facing applications. This is definitely one of the worst tactics to adopt. Whether an application is exposed to the Internet is just one of many factors that determine the "inherent risk" of an application. If this is the only factor you need to consider, then a lot of time and effort will be spent on deep security reviews of applications that are less risky for your business. Instead, consider the sensitivity of the data, how critical the business functions are, the number and skills of the user group and the group of attackers, and other risk factors.

The second bad tactic: face one application at a time.

Most methods attempt to handle the security of an application only one application at a time. When you perform a deep security analysis of your application, a lot of time is wasted on small security vulnerabilities that are unlikely to bankrupt your business. Every year, there are more applications and more avenues of attack to consider. So, every year, the security team has to do more and more work. Each time you target an application this approach is not extensible at all. Instead, focus on how to eliminate the most significant vulnerabilities that all of your applications face.

third bad tactic: conduct an annual security test.

Many enterprises use the "once a year" or "once every three years" Application Security test Plan table. This approach requires a complex set of scheduling processes for new applications, legacy applications, cloud applications, and products. Today, new vulnerabilities and attacks are emerging, and this approach poses a high risk. The new code base vulnerability could expose the application completely until the next review is discovered. New security vulnerabilities are often quickly added to hacker tools and become part of a wide range of scanning activities. In addition, the modern software development process is published weekly or daily in code, rather than annually. Safety must be sped up.

Fourth bad tactic: protect only critical applications.

Another possibility is to focus solely on business-critical applications-and if these applications are finished, the business will be paralyzed. It is advisable to consider the actual damage that might be done to the business, but this usually involves only a small batch of applications. In many organizations, application security teams are overwhelmed and understaffed, and their scanning methods are not scalable and cannot handle any more applications. Unfortunately, many of the real-world leaks are initiated from less important applications (such as Sony events) and then spread and spread to more important systems. Even if the "booklet software" website is attacked, it will be a mess and a PR disaster that needs to be cleaned up.

None of the above tactics has a broader strategy that supports rapid application security and is incompatible with modern software development. We need a way to adapt to all of our application portfolios, keep up with the pace of modern software development, and focus first on the biggest risks. The good news is that we can take advantage of the many concepts and technologies of continuous integration and continuous delivery to create a different application security process, fast, accurate, and simple.

the right question: Does your application have a security instrumentation mechanism ?

instrumentation allows you to collect security information directly from your application without scanning, cracking, or any other additional steps. If your application implements instrumentation, they can test themselves and constantly report their status. This radically alters the scale of application security. You don't need to scan all the apps, they will test themselves and keep reporting to you.

Here is an example of proving the allure of instrumentation. For example, the most important security issue you are concerned with is SQL injection, which you have stipulated that developers can only use parameterized queries. It is easy to confirm this with some security instrumentation mechanisms in the database interface. For example, you can implement instrumentation for the MySQL Library and report on the use of non-parameterized queries. Just put this version of Statementimpl on the Classpath (classpath) in front of the actual version.

Although this is a very humble example, but quite convincing. Push this instrumented version to your MySQL library center, and you'll soon have a complete diagram showing all the non-parametric queries in your business. Imagine what you can accomplish with the security instrumentation of your application portfolio.

That's the difference. The instrumented application confirms its security and reports the problem to you. The simplest benefit is the complete application manifest. You can also verify that the third-party library is up-to-date and that there are no known security vulnerabilities. Instrumentation also ensures that the configuration files are properly protected. More sophisticated instrumentation can pinpoint complex security vulnerabilities and almost anything you want to know about your enterprise code base. It also continues to apply to the size of the enterprise.

Trying to find out which applications to protect first will only waste resources. Instead, take the time to build your security instrumentation capabilities. You don't need to scan anything after the next Heartbleed or Shellshock. You just go to the dashboard, search for the affected version, and send an alert to the project owner of the affected application. You can also see when they are fully upgraded.

Which applications should you protect first? The question itself is wrong!