Grappling with Application security is complicated. This is not new. Ask anyone in the world of application delivery or security and they will say that application security continues to be a serious challenge. The stack is getting more complex. Now apart from web and mobile, there is an added context of IoT applications that bring unique complexities and constraints with them.
Based on our own efforts in penetration testing and security research, I see the following changes that I believe have either become or fast becoming game changers in application delivery, and therefore in application security.
Containers
Anyone in tech today has probably heard of containers, more specifically of Docker, which has become the face of this technology paradigm. Docker has provided a powerful way of packaging applications that can be deployed across a variety of environments by just invoking simple commands. Application teams routinely containerize their apps with the stack in a bunch of docker containers and create staging, test or even production environments in a jiffy. Although Docker does not recommend it's apps being run in production, Developers and DevOps folks have started to throw everything and the kitchen sink in a Bunch of Docker containers and run apps in production. I personally find myself deploying build and test environments in Docker with extreme regularity. Containers are what VMs were about 5-7 years ago. However just like any other technology, containers come with their own set of security risks. Docker got famous due to network effects. A developer could bake a docker container and upload the container's Dockerfile and artefacts into Docker's registry. Making it a "App Store" for containers. However, Docker learned the hard way that wherever there are app marketplaces or their equivalents, there's likely to be serious security flaws lurking in the background. Over the last year and this year, security researchers and assessors have identified critical and high severity security flaws in Docker containers in the Docker registry. Including several gut-wrenching security issues like Shellshock and Heartbleed to name a few. While Docker has taken some swift steps to eliminate security flaws, especially through audit processes in the registry, I am sure that security flaws would be rampant in containers, especially given the complex dynamics of the modern software supply chain and dependencies.
But I don't see the interest or inclination to use containers to wane in the near future. This tech is extremely convenient and it's going places. Might as well figure out ways to secure it in your environment. One way that I can think of, of the top of my head is Lynis. Lynis is a great tool for performing security hardening checks against Linux environments. Recently they have added security checks for docker containers as well. I have used Lynis for docker and I find it works pretty well.
Queues, Brokers and Signals
Technologies in this space are not particularly new. Message Queuing and message brokers have been a part of enterprise apps for a while now. But I am seeing an unprecedented adoption of queuing technologies today. I think that is primarily due to the fact that the stack today has gotten incredibly complicated and for all the moving parts to work, you need message queues, distributed signalling systems that can multi-task and deliver much-needed performance benefits for distributed systems.
All you have to do is just explore some talks in tech conferences and see some of their application deployment diagrams or "how they scale" their apps, and you'll see a bevy of queuing systems like RabbitMQ, Kafka, or Amazon's implementation of these technologies. However, I find that security is not considered very deeply here. People seem to wantonly ignore security configuration for queuing systems as they don't understand the inner workings of these systems very well. In addition, the installation candidates for most of these systems have a "default insecure" configuration that can be very dangerous when deployed by groups that aren't clued in on their security requirements.
Document Stores
I sometimes I sound like a broken record here. Document Stores and Search databases have been around for some time now. But I see two diverse issues here. One is the fact that these databases have become adopted heavily in most application stacks these days, either for search/analytics/etc, I have seen everyone from hot tech startups to stodgy old enterprises getting serious play from Document databases.
However, one thing has remained consistent: the security of these databases. I think it was 2 months ago that Mongo made a statement saying that some users were just incorrigible when it comes to security and there's very little they can do about it, especially since they have provided all the necessary configuration parameters to secure MongoDB databases. This year, several breaches including the Mexican elector databases of over 93 million voters was exposed. In addition, the MacKeeper breach and the dozens of other breaches owing to insecure MongoDB servers is staggering. Shoran’s founder John Matherly stated that around 600TB of exposed MongoDB data is out on the internet. Data that is easy pickings for even a script kiddie. And this isn't just restricted to Mongo. I see similar trends with Elasticsearch, Solr, Cassandra, couch and other document DB tech.
Document DBs are great and I find myself using them more and more for our own projects, but I also find that security is a gaping hole unless you are really worried about it.
