Attacks on applications are increasing. As the gatekeepers of the digital currency known as data worth real currency on the dark web, that should be no surprise. The surprise is the rate at which application security attacks are increasing.
In a recent blog post, cloud-based provider CloudFlare reported it had seen "OSI layer 7 attacks that usually appear at a rate of around 160 per day are now sprouting at rates of up to 1,000 a day."
The application layer (OSI layer 7) encompasses everything from protocols, to platforms, to code. All contribute to the overall risk of running an application, and all are critical to protecting against a growing array of attack vectors targeting applications.
When the virtually inevitable attack on an application succeeds, someone winds up shouldering the blame. Those shoulders almost always belong to someone in IT and not app development – even if the app is less than secure.
The reason an app is likely to fall victim to attackers varies, but one of the most probable causes is a lack of attention to security during development. An Arxan/IBM study conducted amongst IoT and mobile developers reported 44 percent admitting they deliberately skip security due to pressure from the business to get apps to market. And then security professionals – who are not application experts – are suddenly tasked with securing that app in production with just as much pressure to move quickly.
Time is of the essence, you see, and security -- good security -- takes time.
The best way to address the issue of time is to use the time we have more efficiently so that we don’t significantly impede the development and deployment timelines. To accomplish this, we first recognize that security experts know security and developers know apps. Correctly leveraging their expertise expands the breadth of attacks we can expect to be addressed before the app hits the market.
We do that in two ways: first, by aligning expectations of security ops and developers, and second, by shifting security left into the development pipeline.
Align expectations
Identity-based attacks are a growing problem for applications. The new world order is digital, and apps are its currency, which means everyone wants us to identify ourselves with credentials. Attacks like credential stuffing and brute force attempts to slip past security are common, and not always identifiable from the developer’s perspective. Security ops increasingly look to identity-federation for multi-cloud apps and application access control services to remediate identity-based threats.
Organizations should provide guidance on unifying internal services that can detect and defend against identity-based attacks. Reuse of secure, defensive services can reduce development and deployment time by eliminating the tendency to reinvent (insecure) wheels.
To encourage developers to leverage those identity-based services, make sure they play well with their applications and expectations. If you implement an application access control service that doesn’t share the information developers need to make their application work, they aren’t going to use it. If they’re expecting a JWT (JSON Web Token) and you send them a SAML assertion, well, they’re going to go around you. Align security and enterprise architecture to ensure security services aren’t putting in roadblocks that force developers to roll their own or go around you.
Shift security left
I know this is beginning to (if it doesn’t already) sound like another buzzword bingo entry, but the fact is that some security needs to shift left into the development lifecycle. That is for the benefit of both security ops and developers.
Web application firewalls are great for detecting and preventing a wide variety of attacks and defending against infiltrative bots. But they aren’t easy to configure. Security pros often lack the depth of intimate application-specific knowledge necessary to craft accurate, successful policies. Developers lack the time and inclination. After all, it’s rarely the developer who bears the brunt of the blame when an attack succeeds.
To encourage developers to participate, security pros should seek out web application firewall services that support a per-application deployment model. This means a WAF dedicated to the app, to keep the complexity of the configuration down.
It should be software to support both public-cloud and on-premises deployments and provide policy portability. That is, you should be able to deploy the WAF with a basic policy (reject bad bots, sanitize protocols, etc.) in learn mode in development and test environments. That means as the app is being developed and put through its paces, the WAF learns about URIs and identifies user input. The developer only needs to develop and test as normal, so long as requests and responses are passed through the WAF.
That policy can then move with the app into production, where security ops can polish it up. By not forcing security ops to craft the policy from scratch and not requiring developers to learn how to operate a WAF, both sides of the equation benefit from the collaboration. The inclusion of a WAF better secures apps, and neither security ops or developers have been saddled with the entire responsibility for securing the app.
A shared responsibility model can encourage both sides to join forces. The key to delivering a safer app to market faster is to work smarter -- together.
