Why is application security so hard?

In short, you don’t know what you don’t know.

 

You have to see the future

There are many reasons that application security is hard. It can be time consuming, costly, and laborious, but the hardest part is you just don’t know how you’ll be attacked. Nobody does.

The reason is that attackers aren’t going to hit your strong points. They aren’t going to try to meet your protections head on. They’re going to look for gaps. Any good strategy puts up the necessary safeguards, sure. But it must afford itself the ability to change on the fly to react to attacks and mitigate the most possible disaster. 

How hard can application security really be to forecast? Well let’s talk about an example that everyone can easily visualize. Application security is no different than regular security. Let’s talk about trying to secure a bank. Think of all the ways that banks are secured today. All the security measures are based on past exploits. 

A bank vault was robbed because the bandits dug a hole into the vault. Well let’s add a reinforced concrete floor. Another set of robbers blew up the vault. Time to use blast proof vaults. This time the robbers brought in guns and forced the employees to open the vault. Add armed guards and an easy-to-access panic button next to every employee. Another time the thief got away with the money. Well blue exploding ink and recording all of the serial numbers in the vault will help us identify the perpetrator and lost money. Another time the bank teller or bank manager were in on the job. Let’s run our employees through background checks, have strict permissioning for parts of the bank they can access, and overlapping requirements for code access. A band of Minicooper-driving thieves robbed the money, while in transit? Let’s make sure that we use armored vehicles on roads without tunnels underneath. The list goes on and on. Every protection is a reaction to a past exploit. Application security is no different. 

We can try to protect against all of the past examples of fraud, but it is just as important to think about how your strategy will react, if a novel breach occurs in the future. You have to think about application security through the lens of the future, not the past. This is what makes application security so hard. 

There are many components to developing a great application security strategy. Right now, you have to start with an exhaustive search. Find the best reinforced floor, best blast doors, best guards, best vehicles, best bank tellers, and best everything. It’s exhausting and unnecessarily time consuming, since we know the future exploits will focus on places that we did not. 

Another issue with ‘best’ is that it doesn’t last. There’s always something incrementally better that comes up. You’re going to have to reintegrate new solutions over and over. You can’t keep ripping out the reinforced floors to swap in better reinforced floors, so you’ll just hope that the next thief doesn’t notice. 

To bring it back to applications, think about Captcha. When it first came out, it was unbeatable. Shortly after, human farms got involved. By human farms, I mean outsourced captcha solvers that helped criminals exploit a system. Now, the iterations or reinforcements have arrived. Think proof of work. Next proof of storage. The problem space is evolving, and the solutions have to evolve with it. With every evolution, you have to reintegrate a new solution. But you’re not just an anti-thief company, you’re a bank. There’s good patrons to think about. You can’t force every customer through a strip search every time they enter your bank. You’d quickly lose more customers and money, than you ever would’ve in a heist.

This juggling of preventing the bad of the future with ensuring the good of the present further complicates things. Well-resourced companies like FAANG are finding a middle ground through smart application security measures. In other words, they’re only showing security measures when they’re necessary. Startups just don’t have the time or people resources to deliver that kind of personalization at scale. Especially not when they’re in all-out growth mode.  



You have to know your limits

You have to be aware of the limits of application security (limits in individual and team understanding). If I have promotion abuse, is that an application security issue? Is that a marketing issue for making a weak promotion? Is it a developer issue since they didn’t see around the abuse corners? Who should be responsible for it? 

Due to the many ways that fraud presents itself, it can make its way into the dark corners of the business. Parts of the business where no one is looking or where there’s too much overlap and limited ownership. To bring it back to the bank analogy, it’s almost like bank robbers who travel across state or county lines to take advantage of overlapping jurisdiction or poor interdepartmental communication. 

Application security should take a lesson from physical bank security. It is important to have clear ownership of all the various parts of application security, but also task a person or a team with the holistic evaluation of fraud. This ensures that there’s always someone to react and even think a step ahead. 

 

Eating fraud can seem appealing

Unfortunately, many businesses will just put up with fraud. 

We got burned, and we’re just going to keep getting burned. They view a fraud spike as a point in time, and think that it’s a stomachable amount to lose. The unfortunate reality of fraud is that if spikes are allowed to thrive, then they’ll repeat. They won’t repeat at the same amount, but will often grow at an increasing rate until the loss is far from stomachable, yet a solution is far from being implemented. This form of short term thinking can lead a company to go under. Not only from revenue loss, but from a degradation in the quality of service. Once a user churns, they can be tough to get back. 



Thinking we’re definitely secure. 

Who can call themselves a security expert? Is it an engineer with a PhD in cryptography? Is it a CISO with 30+ years of experience? There are many facets to security and it’s hard for any one person to understand it all. Whoever your organization has will have their strengths and weaknesses, and then you’ll ask them - how much is good enough? Is it secure? Is our product secured against fraudsters and abuse? 

Their answer might very well be…sure. There’s no way to tell, since everything in the moment is fine. Until you’re attacked. Now, you’re forced to remediate. Once the fraud spike subsides, you’re asked again - is it secure? Sure…

 

How do you know who to trust?

Let’s look at a different aspect of application security - content moderation. If your platform allows for users to interact with other users, then it might very well allow users to abuse other users. That’s an issue. The hard part is solving those issues quickly and without implementing draconian policies. You can easily throw out all the bad users, but you’d be throwing the baby out with the bathwater.  

A good example here is Youtube. They implemented a process copy strike, where copyright owners are able to report a video for misusing their copyright. The trouble is that creator who have been wrongfully accused of misusing copyrights have no method for making an appeal. After a creator or creator’s video gets enough strikes, they get banned. This system started off as a way to make sure users weren’t abusing the system, but ended up allowing a new class of users to abuse a different set of users. Certain users who wanted a Youtuber removed would just issue copyright strikes en-masse and get the Youtuber, in question, banned. The lesson here is that even in solutions to problems, startups need to constantly tune their solutions to make sure that they don’t become sources of new problems down the line. Otherwise, your solutions can almost do more harm than the good that they set out to do. 

If you have any questions about why application security is so hard, then feel free to chat us or contact us at hello@dodgeballhq.com