Back
Four Application Security Myths – Debunked
Application Security is a crucial component to all software development today. At least, it should be as cyber security concerns continue to grow at the same furious pace as the number of apps out there. However, here at NetSPI, we talk with a lot of software development teams who haven’t yet adopted a security mindset, thereby placing not only their programs at risk of cyber-attacks, but their entire organizations as well.
If you’re fighting resistance within your organization to incorporate security measures into the software development life cycle (SDLC), this blog post is for you. We’re going to set straight four of the most common myths and misconceptions we hear among those who don’t have robust application security processes in place.
Myth #1 – An application security team is optional
On the contrary – an application security team today is a must. Someone within your organization should own the function. The good news is that you don’t need a big team to manage it. In fact, we’ve seen programs that work really well with small teams – even teams composed of just one person, in some cases.
Another must: enable an application security culture and nurture that culture across the entire organization, paying special attention to key stakeholders who contribute to your application development lifecycle. Some companies foster an application security philosophy with a security champions program, where leaders in the software applications organization are nominated to advocate on behalf of the application security team. The beauty of this approach is that you have team members within your software engineering organization who can accelerate and fix vulnerabilities quickly. In many cases, they can help reduce the number of vulnerabilities your applications have in the first place. The best side-effect of this approach is that you start organically evangelizing a culture of application security within your organization.
Myth #2 – My organization is too small to have an application security team
This belief is especially common among startups. As intimated above, no organization is too small to focus on application security, mainly because it isn’t just about finding vulnerabilities. You can start by creating governance processes that define security measures and that guide implementation of a secure SDLC, such as:
- Introduce technologies at different points during your SDLC to ensure you capture vulnerabilities early, before a hacker or attacker can exploit your software.
- Integrate security concepts into your software by building application security-specific requirements that become part of your software before a single line of code is even written.
- Create security use cases (also known as misuse and abuse cases) and build functional requirements that focus on security concepts. Then, make sure that your developers have access to those requirements and implement the software against them.
- Educate developers on defensive programming techniques to be able to build software that is naturally resilient to attacks.
Myth #3 – Because we love DevOps and we’re an Agile organization, we can’t have an application security team
Organizations that feel this way usually believe that security teams slow things down. However, security doesn’t have to slow you down when you use the right tools and processes at the right times; and a relatively new concept known as DevSecOps can help. DevSecOps is a culture in which security is integrated between the development and operations functions to close the gap between the development, security, and operations teams, three roles which are historically siloed. If these three roles are required to work more collaboratively, a shared responsibility for application security is created, which enables a DevOps and/or an Agile organization to introduce security as a frictionless component of all processes. Ultimately, the objective is to make security-driven decisions and execute security actions at the same scale and speed as development and operations decisions and actions. To succeed with this approach, an organization must adopt a DevSecOps culture.
Myth #4 – Application security teams will slow us down
As mentioned above, application security doesn’t have to be a hinderance. If you’re using best practices and building good quality software, security is an inherent part of that. Most software performs better and is more efficient when it’s developed securely in the first place. When you adopt a security mindset, your SDLC will flow smoothly, enable you to build better software and can even save you money in the long run.
Getting started with application security:
Best practice dictates the introduction of appropriate touchpoints throughout each phase of your process.
Education, for example, is a good first step:
- Educate your product managers and business analyst(s) on common security vulnerabilities and real-world scenarios of how these security vulnerabilities had a severe impact on an organization, so they can help guide security requirements for your software and always be security conscious.
- Educate developers on defensive programming to make sure they implement software that is naturally resilient against vulnerabilities.
- Educate your teams who are involved with testing and deployment to detect vulnerabilities using various techniques like manual penetration testing, adversarial simulations or red teaming activities.
Second, during the planning phase, create security requirements, or benchmark your program, so that you can understand how mature your organization’s SDLC is, from a security perspective, and so that you can take educated steps to evolve and elevate it over time.
Third, in the design phase, construct your software so that it is naturally resilient to attacks. When you’re building use cases, be sure to add misuse and abuse cases. An example of a misuse/abuse case would be when an attacker tries to “brute force” all possible usernames and passwords into those fields in a login page. You can address such a case by making the software automatically lock an account after multiple wrong tries. You should also create a velocity or anti-automation check to prevent an automated tool and scripts from brute-forcing its way into compromising your application.
During the coding phase, you can not only educate your coders on writing secure code, you also can employ techniques like static analysis, manual code review, and composition analysis to identify vulnerabilities early in your SDLC.
In the testing phase, you have the opportunity to leverage manual penetration testing, dynamic scanning, and build risk-based test cases based on the misuse and abuse cases defined earlier.
Lastly, in the deployment phase, test your detection controls, perform adversarial simulations and red teaming activities. Consider manual penetration testing or implement technologies like RASP to offer continuous protection of an application even if a perimeter is breached.
Because in today’s world software is everywhere – from refrigerators and coffeemakers to medical equipment and data farms – application security is becoming ever-more complex and increasingly critical. Every software development organization, no matter how large or small, must focus on application security to protect its products, the end users and, ultimately its own organization.
For more information, watch my presentation at the recent Cyber Security Summit or contact us to learn how you can get started on your own application security journey.
