Getting your application security program off the ground
IT and security professionals are increasingly concerned about attackers compromising their mission-critical applications. According to a recent Ponemon study, the reasons for that are many: more funds go towards protecting networks, security is not adequately emphasized during the development of new applications and often outright ignored, many are unable to quickly detect vulnerabilities and threats and to quickly perform patches on applications in production.
“Application security was traditionally very low on CISOs’ priority list but, as the attacks targeting applications increase in frequency, it’s getting more attention,” Eugene Dzihanau, Senior Director of Technology Solutions at EPAM Systems, told Help Net Security.
“The application layer is quickly becoming more exposed to the outside world, drastically increasing the attack surface. Applications are deployed on the public cloud, mobile phones and IoT devices. Also, applications process a lot more data than before, making them a more frequent target of an attack.”
In addition to that, modern applications and tech stacks are evolving and becoming increasingly complex – applications are integrating more external dependencies and are becoming very interconnected through API calls. The increased complexity significantly increase the chance of security issues.
Like water, attackers are always trying to find a path of least resistance. It should not be surprising that instead of trying to get through sophisticated defenses on the infrastructure side, they explore vulnerabilities in web, mobile applications and web services.
Let’s take as an example an API exposed to the internet and a mobile application that calls it to show the user their investment portfolio positions. A potential attacker could exploit a vulnerability by executing an API call with a specially crafted parameters/payload, and this may lead to an injection attack and result in the attacker obtaining sensitive data (e.g., financial information) or executing unauthorized actions (e.g., transferring money to a bank account controlled by the attacker).
In many cases, Dzihanau notes, such actions would be difficult to distinguish from typical application usage.
But that’s just one example – there are many types of application vulnerabilities and related exploit scenarios (as delineated in the OWASP Top 10 Web Application Risks and the SANS Top 25 Most Dangerous Software Errors).
Dzihanau, who has spent two decades as a full-stack software developer with a special interest in engineering excellence, non-functional requirements and security, and the last five years shifting his focus on the security aspects, says that organizations are starting to understand that just doing SAST and DAST is not enough.
“SAST scan results are massive, with very little insight into prioritizing fixes for critical or exploitable vulnerabilities. DAST rarely brings desired results without additional steps; the out of the box crawlers can rarely traverse the modern web applications,” he explained.
“This leaves glaring gaps in the security of deployment pipelines, security defects on the architecture level and third party/open source dependencies checks.”
He also notes that separating the application security domain is not advisable – it’s best to look at application and cloud infrastructure security together and holistically (modern microservice and serverless architectures are good examples).
“Many organizations have implemented some automation scanning and gained visibility into the number of vulnerabilities in their portfolio by now. That led to the realization that the most ‘exciting’ part is remediation and mitigation activities,” he added.
“Unfortunately, automation is not everything, and developers need to obtain the necessary knowledge and make security part of their day-to-day work. Security aspects need to be addressed not only during testing but continuously in design development and deployment too. While terms security by design and shift-left are well known, organizations only start to realize now what changes and implications this brings to the development process.”
Setting up a successful application security program
Application security is difficult to get right, but Dzihanau offers some tips for pulling it off.
First and foremost, without a big push from the top of the organization, it’s very unlikely the effort will succeed as it affects the whole enterprise. Strong executive support is, therefore, a must-have.
Next: the program cannot be driven only by the security team or executed in silo mode.
“The traditional way of finding vulnerabilities by the security team and fixing it by the development team will not work. The feedback cycle needs to be very quick and collaboration close,” he explained.
“Let’s take a continuous delivery approach as an example. It significantly shortens the time between introduction of a change and release to production, but security people need to understand the application development and the other way around. Hybrid skills are essential, and security quality gates are crucial for success.”
A question that also needs to be answered early is how much time are development team members allowed to spend on learning about security and fixing security issues?
“Instead of tracking the number of vulnerabilities closely, people should be focused on changing behaviors. It takes a very significant effort to get a developer to fix a vulnerability. Fixing (or, even better, not introducing in the first place) starts to go so much easier once application teams do it continuously,” he added.
And finally, those within an organization who are in charge of applications security must work with this thought in mind: this is a long journey and it is best to start with achievable targets.
“Too many times security teams insist on fixing all vulnerabilities regardless of priority or understanding how much legacy code is involved, and and almost all organizations set the bar way too high.”