Securing apps is a major challenge and achievement for any organization. For an app to be secure, it should not only be developed securely, but security needs to be integrated through the entire lifecycle.Keeping this in mind, I've created a list of 10 questions you need to ask yourself about your application's security situation. This is a simple 'Yes' or 'No' test. The idea is that you go over this checklist and make mental answers of 'Yes' or 'No' as you go along.If you find that your scores are below 7, then you need to fix some of the deficient items in your application security processes/practices. If your score is 8 and above, then you can be sure you are in decent shape, with some room for improvement. Similarly, if you are at 2 or 3, then your application security practices need serious intervention. So, without further ado, let’s get into it.
The term 'Threat Modelling' is bandied about rather loosely these days, but the core concept of it is pretty simple. It's essentially a process where you identify and understand the security threats to your app and devise a strategy to mitigate these threats.The thing about threat modelling is that it's not a one-size-fits-all solution. Your threat model won't fit someone else's, because your applications aren't the same. By developing a risk-based system of threat mitigation specific to your app, you can accelerate the pace at which you fix vulnerabilities, and reduce the friction between your security and development teams.
One of the biggest mistakes product engineering teams make with security is not testing for multiple types of vulnerability. Sure, you might thoroughly check your code for bugs, or run regular penetration tests. But what about dynamic vulnerabilities? What about security flaws in your open-source libraries.When it comes to appsec, you need to address security in architecture, design, and open source and third-party components. Otherwise you risk missing a large number of vulnerabilities in your software.
The concept of Continuous Integration/Continuous Delivery (CI/CD) is all about 'shifting security left'. That means implementing security in the DevOps process as early as possible. For every new build or release of the app, security is built into the development pipeline.New releases of the application are deployed in a secure state, ensuring that even the smallest updates don't introduce unprecedented vulnerabilities to the software.
We've seen several companies put their application through an automated appsec vulnerability scanner and to go production after the scanner has thrown a clean report. This is not nearly enough. As apps grow more complex in size and architecture, a single avenue of security testing becomes untenable.A skilled penetration tester can find way more issues than an automated vulnerability scanner can. If you're only using an application security vulnerability scanner, you should seriously consider a hybrid application security test (penetration test).
Penetration Tests are extremely useful. However, security code reviews are essential to securing applications. Security Code Reviews could be peer-reviewed, with a static/dynamic code review, or expert reviewed. Either way, the important thing is that risky code is being evaluated and red-flagged for developers to fix.
As important as it is to test your applications for every new release, it's equally crucial to understand how your security flaws develop or change over time. Did you have more bugs in your source code last month? Maybe now you have more DAST vulnerabilities than before.It's important to track the health of your apps constantly, monitoring what you're doing right with security and what's not going according to plan. This will let you modify your development or security strategies on the fly. The result? Consistently more secure applications for every release.
You might be running vulnerability scans on a clockwork schedule, your dev team remediating vulnerabilities like a well-oiled machine. But not all vulnerabilities are created equal. We've seen companies that neglected to delete old, unused libraries from their platform over months or even years of development.Even if these libraries don't pose a security risk, they're still picked up by scan tools, and could be reported as vulnerabilities. If you don't want to end up like this financial services company that thought they had over 700 new vulnerabilities, find out which libraries you're not using and get rid of them!
It can seem next to impossible for your security team to handle the sheer volume of new vulnerabilities generated by automated tool scans. From organising security flaws and prioritising them, to managing false positives, it can get all get overwhelming way too quickly.
Fortunately, there's a solution to this. Application vulnerability correlation (AVC) platforms will aggregate scan results from your tools, organise them according to category, CVE number and severity level, and identify false positives for you. And they do all of this automatically, significantly reducing the workload on security professionals.
Check it out: Automatically correlate your vulnerabilities with Orchestron
It's not only important for your developers and architects to be aware of application security concepts and practices, they need to be trained periodically on them, too. Application Security is constantly evolving, with newer attacks and vulnerabilities being identified by researchers and blackhats all over the world. Your developers and architects have to be formally trained on the latest appsec techniques and strategies, either workshop-style or through a series of training capsules.
One of the worst things that can happen to your company is to have management that does not understand/appreciate the impact of application security breaches. Application Security and Information Security are top-down practices that begin in the boardroom. Management that is not aware or concerned with application security results in a company that would probably end up being a breach statistic.
