Your company's web applications are the gateway for your customers.
Gone are the days when someone would browse through Amazon, pick an item, call Jeff Bezos directly, give him their credit card details over the phone, and expect their product within 2-4 weeks. Almost everything is done online.
Almost none of your customers will travel to your head office; very few (if any) will ever call your publicly listed phone number; a handful of them will make it as far as emailing you; a small percentage of them will use an online-chat system (if you provide one); but all of your customers will use your web applications.
I personally don't like to use the phrase
hackers, but that's because I prefer the old meaning of the term:
Someone who doesn't use engineering processes when creating code. They "hack around in the code base, removing code blindly, trying to make it work"
But if the shoe fits...
Sure, a lot of hackers these days will launch complicated attacks against your servers - and that's still a legitimate concern. But with services like Azure, AWS, and GCP, it's getting harder for malicious folks to break into your infrastructure.
My previous statement assumes that the infrastructure is set up with security best practises in mind. i.e. no VMs (WebApps or serverless architecture), service principals rather than usernames and passwords, multi-factor authentication, applying the principle of least privilege
There have always been attacks against the client (in this case the Browser), but they are slowly becoming more prevalent. A lot of folks get started in this arena by utilising Google dorking techniques, they then move on to the techniques used by Script Kiddies. These are simple techniques that you can just copy and paste without having to understand what they do.
In fact, it's so easy to do that Troy Hunt had his (then) 3 year old son perform a SQL injection attack, on camera.
These techniques can be pared up with the results of a quick search on Shodan to launch attacks on vulnerable systems.
Have someone within your organisation do frequent searches on Shodan to ensure that you haven't opened any potential gateways into your applications or infrastructure.
If you don't, someone malicious will.
Oh so frequently, we (at RJJ) have seen that security is thrown in as a last minute feature. This can be, and is often, disastrous.
We've seen cases of applications where security is added as an afterthought, yet breaking into the system was child's play (see my earlier comment about how easy it is do use Script Kiddie techniques).
This leads to security teams becoming the nemeses of development teams. But, just as with Dev and Ops, we all need to be working together to ensure that the applications we built are secure from the off. For allegorical proof of this, I'd recommend reading The Phoenix Project.
The most secure applications - just like the most secure buildings - have security baked into their designs from the very beginning. This allows us to include security checks as part of our automated test suite.
you ARE using automated testing, right?
This ensures that no one is able to release a "quick fix, will improve security later" (that's an actual commit message that I've seen in the past, by the way), because it won't get past the automated tests.
But doing this is hard. Which is why "DevSecOps" is now a legitimate career path for folks who want to increase the security of applications. The problem is that there's so much to learn, and almost no time to learn it, right?
I've written about OWASP before. In their own words:
The Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. Our mission is to make software security visible, so that individuals and organizations are able to make informed decisions. OWASP is in a unique position to provide impartial, practical information about AppSec to individuals, corporations, universities, government agencies, and other organizations worldwide. Operating as a community of like-minded professionals, OWASP issues software tools and knowledge-based documentation on application security
Everything that they do (aside from conferences like Global Appsec) is free. Free training materials, free meetups, free software tools, free knowledge sharing.
by "free" I mean "free as in beer, a.k.a: no remuneration required
Not just that, there are conferences and meetups all about application security. There are courses you can take, and there are books that you can buy. You can even try to become a l33t hax0r yourself by using things like Kali Linux
Kali is a distribution of a Linux based operating system which is designed for penetration testers and white-hat hackers
The problem is that learning how to beat the malicious folks requires a tonne of learning. Sure, it's all free information, but there's a lot of it and it can take a lot of effort to learn it. But you can learn it piecemeal.
Imagine if Amazon suffered a massive security breach. Like, lets say that all of orders for a 6 month period for all of their customers were leaked. We're talking names, addresses, credit card numbers, order line items (the stuff that people ordered), everything.
I'm not saying this has happened, I'm just trying to craft an example
Aside from the initial fallout of everyone's data being available to malicious people, and the potential embarrassment some people might have about their shopping habits become public knowledge
seriously, have you ever bought something that would be difficult to explain to a loved one, let alone a friend, stranger, or even your employer?
Aside from all of that, Amazon's reputation would be trashed. They would be dragged through the mud by the media and would have to work exceptionally hard to spin the story in their favour.
Not only that, AWS is an Amazon product. There are millions (if not billions) of people who rely on AWS on a daily basis - even if they don't know it. If Amazon was breached, AWS would be next. Companies like Capital One, BP, GE, Time, and Philips would be hit. Not to mention AWS's killer app: Netflix.
Imagine if your company was successfully attacked, and all of your customer data stolen. Would it survive the PR nightmare?
And that doesn't even touch on things like GDPR, and other sets of regulations that you need to abide by. Imagine if your company had to defend itself against against a GDPR strike. There's no coming back from that, no matter how good your products are services are. You customers would leave.
That's why application security is so important to your company. At least, from a business owner's perspective.