Applications are everywhere: From public websites to internal systems, from mobile apps to admin interfaces. The sheer number of software applications that automate processes in our everyday life and work is overwhelming, and failing to follow application security best practices can have serious ramifications. In enterprises, the problem is even larger, as applications that are either internally developed or purchased from third-party providers support critical business decisions and flows. To make matters more complex, maintaining third-party software security is more challenging than internally-developed software, because there is a limited ability to assess and affect the security posture of third-party software.
A Real-World Example of an Application Security-Related Cyberattack
Recently a client was the victim of a severe brute force attack. Although the client performed a penetration test that revealed security issues, no mitigation was performed to secure the publicly accessible interface. Consequently, an attacker issued millions of login requests and was able to discover valid usernames and credentials.
The result was the identity theft of several clients’ users, the loss of tens of thousands of dollars that were stolen from these accounts, emergency testing and deployment of security measures to stop the attack, and a general mess that really shook up the company, its clients, employees, and reputation. If proper mitigation steps had been implemented to fix the security issues and if application security best practices had been followed, none of this would have happened.
Preventive Measures and Mitigating Actions
The organization was forced to deploy mitigations and preventive measures to stop the attack in real time. They included:
1. Anti-bot throttling
This involves applying an anti-bot throttling mechanism to protect interfaces from automated attacks. It includes both a generic throttling for the entire interface and a stricter restriction (for example, using a CAPTCHA mechanism) for more sensitive actions, such as login operations. The attacked organization did have some kind of throttling mechanism that was restricting IP addresses, but it was incomplete; therefore, the attacker was able to jump between different IP addresses.
2. Strong password policy
It is important to enforce a strong password policy that includes minimal length and complexity. Currently, it is recommended that passwords be at least 12 characters for regular users and 16 characters for administrative users. In addition, passwords should contain characters from all four of the following categories: uppercase, lowercase, digits, and special characters. Another option as an alternative for password complexity is to create and enforce a password deny list that contains common passwords and variations of them. The attacked organization was not enforcing a robust password policy, forcing them to deploy an improved one in real time for all their clients as part of the login process. Inactive users were disabled.
3. Multi-Factor Authentication (MFA)/strong authentication
Implementing MFA adds an extra layer of security by requiring multiple forms of authentication, thereby reducing the likelihood of unauthorized access, even if login credentials are compromised. The attacked organization was forced to deploy MFA and apply it to all users as part of the login process in real time.
4. Concealed user existence
The system should not reveal any information about the existence of a user. Whenever possible (login interfaces, password reset), the system should return the same response, whether the user exists or not. Whenever a different response needs to be returned (a public registration mechanism, for example), apply a strict anti-bot throttling mechanism such as a CAPTCHA, in addition to the general API anti-bot mechanism. The attacked organization was not following this best practice, allowing the attacker to first build a list of valid usernames and then focus on these users’ credentials – greatly increasing the effectiveness of the brute force attack.
General Application Security Best Practices
To avoid similar scenarios, organizations should invest in application security posture. Here are some of the best practices:
1. Follow Secure Software Development Lifecycle (Secure-SDLC) best practices
Organizations should integrate security into their software development lifecycle processes and follow SDL/Secure-SDLC best practices. This should include performing threat modeling for sensitive systems, as well as the definition of security requirements, metrics, compliance, and goals both for specific systems and for the entire organization.
2. Integrate automated tools
Organizations should integrate automated security tools into their development and CI/CD pipeline. This includes dynamic scanning tools (DAST), static code analysis tools (SAST), known vulnerability and dependency scanners (SCA, container scanners, cloud scanners), and more. Ideally, when a serious finding is found, this should generate an alert and block deployment to production.
3. Perform regular penetration tests
Conduct a penetration test at least once a year and follow mitigation steps to ensure findings are fixed.
4. Define an SLA for security-related issues
Set a service-level agreement with the development, IT, and DevOps teams that would define the maximum time it would take to fix a security issue, depending on its severity. For example, critical issues should be fixed immediately, high-severity issues should be fixed in the current sprint, and medium and low issues can be treated and prioritized as regular bugs.
5. Education and training
Providing comprehensive cybersecurity training to employees is paramount. Specifically, it is crucial to provide dedicated application security training for developers to familiarize them with application-related cyberattacks, their implications, and mitigations. Application security is primarily the developers’ responsibility.
6. Integrate security into the design process
Ensure ongoing security-related design reviews are being done as soon as possible in the software development lifecycle, to fix and prevent design issues before their code is implemented.
7. Establish and practice a standard incident response process
Make sure a proper incident response policy is in place that includes all roles and contacts in case of an incident. Validate that incidents are identified, preferably automatically. Perform an incident response drill to make sure all requirements are properly set and met.
Conclusion
Application security is often overlooked. This story is an example of the ramifications of focusing on an application’s functionality and rushing to develop the next feature, rather than applying security measures, fixing previously discovered security issues, and ultimately investing in security as an integral part of the software development process. Following application security best practices can save organizations a lot of time, money, and effort and reduce the risk of future application-related cybersecurity incidents.
Want to learn more about how CYE can help protect your organization from cyberattacks? Schedule a demo today.
