A few years ago, my girlfriend and I went to a local rib joint for dinner. This restaurant is consistently rated as one of the best rib places in the region and has won award after award for their truly excellent food. Their walls are littered with autographs of famous people who have dined there and loved the food, including known food critics.
A couple, obviously on a date, sits down next to us and it becomes apparent that the woman is new to the awesomeness of this place. The woman says, “I hear this place is amazing,” to which her date replies, “Yeah, but the ice cream sucks.”
This has stuck with me since the night it happened. It’s like entering the Sistine Chapel knowing you’re going to see a masterpiece on the ceiling and thinking the drapes covering the windows are hideous. This pessimism may not be the right attitude for a five-star meal, but it is absolutely correct for IT security.
Too often we see truly excellent apps, tools and websites that are beautifully designed and easy to use become littered with security holes and privacy concerns that force us to recommend avoidance to our customers and clients.
Security Flaw: Engineers ≠ Designers
What many do not understand is the IT world is highly specialized. Often IT personnel can’t see the forest for the trees when developing ideas and products. If you’ve ever had a job where the database was very comprehensive but you essentially need a degree in engineering to figure out how to input something simple, then you understand exactly what I’m talking about.
An engineer is not a designer and he or she, when designing, will usually fail to understand the importance of workflow and aesthetics for the users. Conversely, a designer will design a slick interface, but inevitably something is missed in terms of data and analytics or even query performance. Finding someone who excels at both is rare. The best development has a team that is robust enough to let the engineers be engineers and designers be designers.
Too often we see breaches and hacks happen because neither an engineer nor a designer is a security expert. Sure they can perform some of the basics regarding securing their product, but it’s the equivalent of having an engineer design the interface. Things are missed.
When Amazing Apps and Sites Lack Security
Consider the following examples of brilliant ideas and products that are wonderful to use but not fully secured. It’s not that security was an afterthought in these products, rather, it’s that these products were not designed with total security in mind.
Example 1: Container Systems
Don’t get me wrong; I absolutely love containerization. It has taken the infrastructure and development world by storm and rightfully so. Containerization is the future of large-scale infrastructure design and easy deployment. It’s fast, flexible and easily scalable.
Unfortunately, its security is lacking. Container systems utilize the operating system’s (usually Linux) ability to create isolated environments. Each container can essentially have its own stack above the shared engine, making it very efficient in terms of using resources but can also create privilege issues depending on how the containers are deployed. Also, because containers can be handled and deployed independently, it’s possible to have containers at different patch levels within the same system leading to gaps in the security.
The leaders in containerization acknowledge the critical issues and are working towards fixing them, but we’re not fully there yet. Most companies, when seeking to enhance security for their container systems are actually wrapping the system in a hypervisor which negates some of the performance benefits of migrating to containers. The problem we have here is that containerization is expanding rapidly, but the integrated security isn’t fully there yet.
Make Your Business More Secure
Example 2: Snapchat
If you haven’t heard about the lawsuits against Snapchat, you’re about to. To the uninitiated, Snapchat is an incredibly popular picture and video messaging system used very heavily by teenagers and young adults. In fact, if you have anyone under 25 in your life, odds are they’re using or have used Snapchat. It’s well-designed and easy to use with fun features, which is, in part, why it exploded in the last few years since its creation in 2011.
The problem is that Snapchat has been consistently vulnerable to breach and attack, in part due to how its architecture was constructed. Gibson Security published a list of vulnerabilities within the Snapchat system in 2013 stating that Snapchat was essentially hacker bait. Sure enough, a few months later Snapchat was breached, and roughly 4.6 million Snapchat users had their usernames and phone numbers dumped into the internet. A known vulnerability that Gibson had discovered was claimed to be the culprit.
The US Federal Trade Commission entered the fray and, despite their pleasant sounding name, these guys mean business. In 2014, they announced a lawsuit against Snapchat for misrepresenting their privacy and security policies. Snapchat’s public claim, and one of the big appeals of its app, is that anything you send will self-destruct after several seconds.
In other words, go ahead and send something risqué because the receiver can’t keep it. Teenagers, being teenagers, loved this feature. Unfortunately, as a few were about to find out, Snapchat’s claim was not exactly honest or accurate. Had Snapchat been developed and tested with security in mind, a situation like this arising would be vastly mitigated. Essentially, we’re looking at a scenario where developers most likely took it upon themselves to believe they were app security experts, and here we are.
Example 3: WordPress
I like WordPress. I really do! It’s a great platform for publishing and blogging with an excellent array of plugins and options that make it easy to maintain your content. Which is why it kills to me say that WordPress security needs some real work.
I will be honest here, though, WordPress is a major target for hackers. There are a ton of hacking and probing utilities out there for attacking WordPress-based sites. We actually use them to show our clients vulnerabilities in their own WordPress configurations.
In fact, when I’m giving live hacking demonstrations about vulnerabilities, one of the easiest examples I always give is how to scan a WordPress site for vulnerabilities and then attack it. Compounding this issue is that web designers are typically not security experts, so the basic security options available in WordPress, such as incorrect password delays and IP whitelisting for the control panels, are not used on a great many websites.
WordPress sites are not usually updated with any real frequency which is a serious problem because WordPress vulnerabilities are constantly being published. We have had to disinfect and recover more than a few WordPress sites in the past few years and unfortunately this is not a trend we see slowing down.
Please do not think that WordPress is alone in having vulnerabilities. To be fair, WordPress developers are constantly patching their products in an attempt to try and keep ahead of the hackers, which is an uphill battle. Other publishing platforms are also targets and we’ve had our fair share of restorations on other systems as well. WordPress is simply the largest and as a result, like Microsoft Windows, the core of their product is constantly under attack.
These are but three examples of countless others out there that have the inherent flaw of not being designed or implemented with a “Security First” mindset. The good news here is that with all of the bad news about breaches, the IT world has recognized this issue and security is finally starting to become an equal partner to design and function. Go to any IT developer conference and at least 30% of the conference is now related to securing the products in development. This trend has taken some time and it’s definitely headed in the right direction.
Now, How Do We Make the Ice Cream Better?
Here’s how we fix this problem in the future (some of these are more corporate-centric but very valid nevertheless):
1. As I mentioned above, developers need to integrate security from the start. As the app is being developed, it needs to be continuously security tested and attacked. Once it leaves beta and goes live, it will be attacked relentlessly from all over the world. The better the security testing and analysis in production, the smaller the surface area for attack when it’s live.
2. Hire security companies or experts to focus development and production of applications towards security. For example, as a result of vulnerabilities in containerization, security companies have sprung up to secure existing container systems and offer their products to help ensure that corporate infrastructure is properly locked down.
Twistlock is a perfect example of this. Though not a developer of containerization systems, they have developed a container security system that will protect Docker Container Systems from development to production.
They have filled the gap more effectively than Docker has. Twistlock is on the cutting edge and leading by example here. Twistlock did not pay me for this plug. They’re simply the best out there at this right now, so I’m following their work rather closely as well as some other companies in this space.
3. Once the product is live, it should be accompanied with instructions and guides on how to properly lockdown the application. Many companies do provide the steps for lockdown, but it’s buried in the documentation and usually placed way after the interface guide. I would recommend that before the application is deployed or accessed, first things first: lock it down and secure it! Going live with an unsecured application is a surefire way for breach.
4. The company should decide if an app or application is actually needed. I can’t see many uses for Snapchat at the corporate level though I’m sure SOX financial auditors would love the document destruction part of it. Only those accepted apps should be allowed into the network, hopefully running in a Zero Trust configuration with Application Whitelisting (see my previous article, Tech Imitates Life, for more on this).
5. If you’re developing an app or product, actually make it do what you claim! If you say it’s secure, then tell the public why it is. In transit SSL encryption is no longer good enough. Disclose the steps you took to secure your product and prove you have a continuing commitment to its safety and security.
6. Educate yourself on the apps, applications and websites you use. If I find a website I’m interested in but do not know its origin, I will take 30 seconds of my life to run it through an online malware scanner to ensure I’m safe. There are some free plugins that will help you with this, or free web filters like OpenDNS, and site scanners like Sucuri that will instantly check sites.
Try using these methods for assessing the site and app security, whether you’re building them or just using them. When the engineers and designers have security at the forefront, we get better products that we can feel safe with while using. Users should have confidence in their app’s security and it’s the development team’s job to make sure that happens.
Good luck and hopefully your ice cream won’t suck so much now.
LOCK DOWN YOUR NETWORK
FREE PENETRATION TESTING COURSE
- Social engineering
- Port scanning
- SQL injecting
- Anti-virus evading
- Client side attacking