4 Tips to Kickstart Your Application Security Effort
In this article, we discuss four easy to implement strategies your company can use to get started using DevSecOps methods to create web apps.
Join the DZone community and get the full member experience.Join For Free
Securing web applications is not an easy task; especially when the application is constantly changing and business-critical. Identifying where to start could be overwhelming, especially if you’re just dipping your toes in web application security. Here are four tips to help you get started.
1. Know Your Target
This is one of the most important, yet overlooked, aspects of information security. In order to adequately defend an application from attacks, you need to understand it properly and ask the right questions. What technologies and frameworks does it rely on? What security precautions, if any, are being taken? Is it a legacy application, and if so, are there any special precautions to take?
Even with spotless code, your application still depends on code and software developed by others. Therefore, whilst you’re getting to know your application, you also need to know your dependencies as well as you possibly can. Just because a third-party wrote that code does not mean you do not need to worry about vulnerabilities in that code. On the contrary, it should be assumed to carry some inherent level of risk. Even if no known vulnerabilities exist in dependencies your application uses, you still need to assume the worst and always practice defense-in-depth.
Properly understanding an application allows you to identify possible weak spots and also helps you narrow down your scope during testing, as well as knowing what vulnerabilities, bad coding practices, and patches you need to watch out for.
Bear in mind that understanding a target is the first step in an attack. The more an attacker knows about your target, the better the chances of an attacker being able to abuse a software bug or a misconfiguration. Knowing about, and fixing, that bug or misconfiguration before an attacker exploits it is the aim of the game.
2. Don’t Wait Until Your App Is in Production
No one wants to fix bugs in production – especially security bugs. Fixing bugs in production is not only more costly to fix, but it hurts your application’s risk exposure.
Investing in security training and security testing allows you to build security in as opposed to bolting it on. Adopting the strategy of integrating security testing as part of your process of shipping new code to production, not only allows you to greatly avoid risks, but it also has the benefit of reducing the high costs associated with fixing vulnerabilities in your production environment.
Furthermore, by catching vulnerabilities before they hit your production environment, developers, system administrators, the QA team, and everyone in between can easily learn from mistakes. Learning from mistakes in a safe environment makes it more likely for everyone involved to avoid introducing and spotting similar bugs in the future.
3. Automate Testing
Aiming to prevent security vulnerabilities from ever making their way into your application is a very important step in the right direction towards reducing your web application’s risk surface. However, preventive measures alone are not going to provide you with enough evidence to back up your efforts.
Let’s be realistic, even the best and brightest security conscious developers, system administrators, and QA engineers miss a beat now and then, it’s part of being human. You need to backup your application security efforts with frequent testing.
Testing for vulnerabilities manually, generally, will result in a thorough test, however, it’s also very difficult to manually pen-test an application at the speed at which new code gets deployed. Moreover, manual testing can get very expensive very quickly, and is not very scalable, especially when you consider the global skills shortage in information security at the moment.
Automated web application security testing tools help organizations test for vulnerabilities against an ever-growing threat surface very quickly. This means that by automating the majority of your security testing, new code can be tested in the fraction of the time it would have taken a skilled penetration tester to find the same vulnerabilities. This in no way abolishes the need for human pen-testers and security specialists, on the contrary, automation allows pen-testers, and crowd-sourced bug hunters to focus on hard-to-find bugs that require human intelligence and intuition to discover.
4. Prioritize Remediation
Finding security vulnerabilities without fixing them obviously achieves nothing. Remediation, however, is more than just about fixing a vulnerability, it is about how quickly, how effectively, and in which order vulnerabilities are fixed.
First and foremost, once an alert is raised about a vulnerability lurking in your application it’s important to ask yourself if it poses a risk, and what level of risk it poses. Some vulnerability alerts may be accepted as a business risk – this tends to happen on some ‘informational’ and ‘low-severity’ alerts for instance.
Once a reported alert is accepted as a vulnerability that you should fix, before a fix can take place, you need to confirm that vulnerability report and also prioritize the risk associated with that vulnerability.
This risk factor can be derived from several data points, namely, the severity of the vulnerability, the consequence should the vulnerability be abused, and threats the application faces. Therefore, a Stored Cross-site Scripting (XSS) vulnerability in the authenticated area of a business-critical application hosting sensitive information may pose a greater risk than a Blind SQL Injection vulnerability in an internal application that does not store sensitive data.
Prioritizing which vulnerabilities should be fixed first, is therefore crucial to mitigating risk. It’s also important to ensure that a vulnerability is fixed within a specified time frame that is dependent on the vulnerability risk exposure.
Published at DZone with permission of Ian Muscat, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.