Application Security Is Taking Center Stage
Have you ever opened your refrigerator and discovered that package of “leftovers” in there that you had forgotten about? Maybe it was a Styrofoam box holding the remnants of a great meal from your favorite restaurant. Or perhaps you had enjoyed a wonderful home-cooked meal with your family but there was just too much food for that sitting, so you put the remains into plastic containers and stored them.
And then you promptly forgot about it.
Then you let a few weeks go by, maybe you went grocery shopping in the interim and restocked, pushing that container even further back in the refrigerator. And finally came the day when you noticed it again, only this time there were a few key changes right? Changes like mold everywhere and a distinct new aroma. And so, you end up kicking yourself for forgetting about it and then throwing out everything in the container, and maybe even the container itself.
And for a lot of organizations, this is exactly how they treat their applications.
The 2019 State of Cybersecurity study from HCL found that while 60% of Information Security professionals expect a cyberattack to happen to them this year, but the same survey reported that only 34% of them are confident in their organizations cybersecurity team to handle it. Why is that the case? There are many: an ever-increasing threat landscape and an increase in the number of attack vectors surely contributes, but a big reason is that applications are vulnerable when released. Pressure to meet deadlines and release dates causes development tradeoffs that impact testing schedules, and for many, even with the best of intentions, it is very likely that an application developed today will contain vulnerabilities in it that will leave it open to attack. Veracode’s 2018 State of Software Security reportfound that 85% of all applications have at least one vulnerability in them. And when you factor in the increasing use of open source software, this just increases the risk for vulnerabilities. In fact, according to the State of Open Source Vulnerability Management report from Whitesource, reported vulnerabilities from open source components rose by over 52% in 2017 alone.
When it comes to Cybersecurity, many companies I have seen focus most of their efforts on securing the perimeter, or what I would call the “outside”. It involves things like threat detection, network protection, identity and access control, endpoint management and many other things like these. All of these are meant to keep good stuff in and bad stuff out. And if you think about the food analogy from earlier, this is a similar idea to putting the good leftover food into a container and storing it in the refrigerator. We have a “secure” environment that is specifically designed to keep food cold so that it can be safely consumed later. So, then why did the food go bad?
Simple. Because of what was already in it when we stored it.
It’s likely that with our food, we thought about what type of container to use and we chose one that would be appropriate for our refrigerator. We probably even considered where inside to place it; whether in a humidity-controlled bin, on the inside of the door or strategically on a particular shelf. It would be safe to assume that; at no point did we consider placing it in a spot where it would spoil. Yet, even inside that sealed container, in the cold environment of the refrigerator, there is enough air and moisture to allow for the growth of microorganisms to occur. We want to, and should, take full advantage of sealed containers and refrigeration, but all those things are doing is really just slowing the process down. The problem here isn’t the device we used or the container we chose, it is what’s inside what we stored. And given enough time, those microorganisms result in mold, making something that was great into something unusable.
Now think about your software applications.
They are built. They are packaged into containers and those containers get delivered into environments that were specifically designed to hold them. And all is great — until the vulnerability that no one realized was in the application gets exploited and now the organization is at risk. And so today, more than ever, application security is paramount to business success.
If all that isn’t enough to convince you of the need for a comprehensive application security program, then consider these additional facts. A 2019 report from Forrester ( obtained from SecurityBoulevard.com) stated that the top two ways successful breaches were carried out were through web applications (36%) and software vulnerabilities (35%). These were also the same top two issues in the 2018 report. So, what does that mean? It means hackers and cybercriminals are most often looking to exploit existing weaknesses in the application layer, and the truth is that they are usually not hard to find. It means we can make extensive use of container technologies and we can have great networks, monitoring, alerts, endpoint management technique and threat detection models — but if we don’t secure the applications themselves we leave ourselves open and exposed.
So how do we secure not only the “outside” but the “inside” too? At a high level, organizations need to make security part of the overall quality conversation — just like functional testing, performance testing, regression testing, etc. Today many build applications focused mainly on how they will perform and how they will be used. Hours are spent designing and implementing innovative capabilities to differentiate from competitors. There is intense focus on the user experience, looking for ways to simplify and enhance it. No one wants to make insecure apps, but how much time is spent really thinking about security? There is a great movement in today to incorporate security into DevOps initiatives, affectionately referred to as DevSecOps, but much of the conversation is around incorporating running security scans at key stages of a continuous delivery pipeline. This is a great starting point, but are we taking it the step further to build security elements into our design elements, user stories, hill statements, and so on? Do we consider the myriad ways someone could intentionally try to do the wrongthing with our application? Are we leveraging things like the MITRE ATT&CK matrices or OWASP Foundation as part of our development practices? Do we develop new intentional security tests to cover new changes as code is being written?
The bottom line is that companies can no longer simply run scans using the same set of policies and tests from previous releases and assume that is enough to be secure. In the additional blogs in this series we will explore details and aspects of a comprehensive application security program so stay tuned.
Originally published at https://medium.com on July 23, 2019. Photo courtesy of Flickr @ https://www.flickr.com/photos/alancleaver/3405608142
