By Jayant Shukla, CTO, and Co-Founder, K2 Cyber Security
Over the past several years, two industry buzz terms have really started to gain traction. SASE (Secure Access Service Edge) was a hot topic at this year’s RSA in San Francisco and Zero Trust has been around a bit longer. As cyber-attacks continue to increase and organizations continue to move to the cloud, both SASE and Zero Trust frameworks offer a way to give organizations additional security to their applications and data. Both frameworks focus on making sure that only verified and authenticated users should have access to assets in the cloud, and conversely, making sure unauthorized and unrecognized users have essentially zero access. However, SASE and Zero Trust are not a panacea for every network and application security need.
Where SASE and Zero Trust Work
SASE and Zero Trust are ideal for applications that have migrated to the cloud, where the organization knows who the users will be and can identify and authenticate them. These applications are typically restricted to employees, third-party contractors, and employees of partner organizations. These applications and their associated data have the benefit of being able to identify who the users are and use these new frameworks to make sure only these identified users have access to the applications.
Where SASE and Zero Trust Miss the Mark
While SASE and Zero Trust work well for applications where it’s easy to identify valid users, these frameworks fail to address two specific areas of concern. First, there are many applications and workloads that must be left open and available to everyone on the internet. Retail and real estate are two prime examples. How many of us browse and comparison shop before we make an online purchase?
What would happen if we had to sign in and be authenticated just to take a look around? Likewise, most new house hunters take multiple virtual tours, usually anonymously, before they decide to take the next step with an agent. Validation and authorization typically are not possible for these open applications. Security needs to be addressed through a different approach than zero trusts.
Open and freely accessible applications and workloads need higher levels of protection than those that already have been secured through layers of identity access security, especially as vulnerabilities can exist in any application or workload. It is especially important that these web applications are protected during runtime when the applications are most targeted by cybercriminals. Static testing tools may miss vulnerabilities that only exist with the interaction of components during runtime.
Even Valid Users Pose a Risk
In addition to the requirement for protection for open systems where identity is not possible, even authenticated users can pose risks. For the typical website, it doesn’t take much for a cybercriminal to register an account on a site, or for cybercriminals to purchase credentials on the dark web and use valid credentials to attempt to hack a website. The security in place needs to monitor the activity of the web application and its activity on the webserver, regardless of whether the end-user has been identified, authenticated, or authorized.
The real issue here is that no matter how much security you implement to regulate access based on identity, there will always be parts of the typical web application that are exposed to the entire world. And with no guarantee that you found all the vulnerabilities in your proprietary code during the development and QA cycle, or in the 3rd party and open source code you’re using in your application, organizations need a defense-in-depth solution that includes effective advanced runtime security to protect the organization’s assets in the cloud.
Web Application Firewalls Alone are not Enough
There is sometimes a mistaken belief that having perimeter security, like a Web Application Firewall (WAF) is sufficient for protecting a web application. Perimeter security may protect inbound and outbound traffic to the application, but it does not monitor the activity happening directly on the web application server itself or between application servers sitting behind the WAF. If a WAF misses an attack (like in the Capital One or Equifax attacks), then there’s no way for the WAF to prevent any further damage on application servers behind the WAF, or to see the damage the cybercriminal is causing on the application server itself.
NIST Recognizes the Need for Application Security
Application security on the application server (also known as Runtime Application Self-Protection or RASP) is now recognized as a requirement by NIST (National Institute of Standards and Technologies) for web application security as part of their recommended application security standards framework SP 800-53 in the latest draft revision. As part of the same updates, NIST also added a requirement for IAST (Interactive Application Security Testing) as part of the same application security framework. It is a significant change to see NIST acknowledge these deficits to application security in the NIST application security framework.
With reports like the annual Verizon Data Breach Incident Report continuing to highlight web application vulnerabilities as the top reason for breaches, RASP as a requirement is needed more than ever. NIST’s new guidance underscores that it is more important than ever for organizations to have a runtime security solution that validates the application execution and alerts to attacks in real-time during the actual runtime of the application.
DevSecOps also Needs Security Framework Attention
Another area in which both SASE and Zero Trust fail to fully address an organization’s security requirements is DevSecOps, the move to implement and test security earlier during the development of the application before it goes live. The enormous pressure to bring applications to market as quickly as possible creates tension between the security teams charged with protecting the organization’s infrastructure and the application development team. Security needs to be a significant part of the framework during development, as well as in production.
Finding and remediating application security vulnerabilities before the application goes to production can help prevent breaches, and also help cut down on the lengthier and costlier remediation times that seem inevitable once an application has already gone to production. We have already seen during this COVID-19 pandemic that many organizations are moving their applications more quickly to the cloud, and one by-product of this acceleration is often missed opportunities to test for vulnerabilities and security issues in the application code during development.
Adding Security Focus During Development
There are several other specific security areas an organization should remember to focus on during the development process in addition to the basic requirements of SAST, DAST, and IAST scanning and the guidelines for coding with security in mind.
- Developers need to remember to look at data security holistically, meaning they need to remember to look at the bigger picture, keeping in mind all the components that touch the data and how they interact, and whether there are security risks in the way they hand off data from one part of the application to another.
- Organizations also need to look at the security of their APIs, as it is another way that data can be accessed.
- For those applications that are protected by identity and access, make sure strong authorization and authentication methods are incorporated securely
- The most important reminder, incorporate vulnerability and penetration testing throughout the development lifecycle.
Security is more than just SASE or Zero Trust
Even if you’ve decided to embrace SASE or Zero Trust as your security framework, be sure to recognize the limitations of these frameworks. Organizations need to make sure they have security incorporated throughout the application lifecycle in both development and in production.
Security needs to be implemented for applications in different layers, including directly on the application server to ensure you are protecting your most valuable assets in the cloud, regardless of whether these applications are protected by identity and access management tools that provide a zero-trust framework.
Finally, the updated NIST guidelines are a great reminder to look at the latest technologies for application security, both RASP and IAST, and consider adding these to your organization’s application security framework.
About the Author
Jayant Shukla is the CTO and Co-Founder of K2 Cyber Security. Jayant is passionate about developing the next generation tools and technologies for securing modern computing infrastructure and breaking the perpetual catchup game resulting from advanced attacks and zero-day exploits. Prior to K2, Jayant was the founder of Trlokom, where he pioneered the protection of applications using sandboxes and developed SpyWALL, the first commercial sandbox for the web browser. At Trlokom he also built the first solution for end-to-end secure communications between clients through multiple gateways and network address translation. Jayant holds a BS from IIT Mumbai and MS/PhD from Carnegie Mellon University.
