Security is a feature. Choose it!
Nearly every modern organization, large or small, has a significant amount of IT infrastructure reliant on 3rd parties. For the purpose of this post, 3rd parties includes anything you think of as "the cloud" (e.g. not my servers) or any service that you don't fully control on your hardware. Web hosting, email, social media, and file storage are all examples of services commonly outsourced.
I wrote previously about the responsibilities associated with managing data securely. A solid cybersecurity posture should require evaluating 3rd parties for proper security practices. This post provides a loose framework for evaluating a 3rd party's overall cybersecurity posture. This evaluation can then be used in your ongoing decision making to pick new vendors and reevaluate existing vendors. This post does not go in depth to any specific technology or vendor specific details, instead I intend to focus more on the culture of security.
Security as a feature
Security as a feature in this model has 3 overarching components:
- Problem solving
- Learn from mistakes
The quality of cybersecurity is an aggregate of these three components. An organization with good security practices is well prepared, knows how to react when something goes wrong, and they learn from their mistakes.
Plan for the worst, hope for the best.
The reality is, until more organizations make cybersecurity a higher priority, the never-ending stream of data breaches will continue.
Preparation for security
Preparation is the foundation for all security. You have to know what you have, how much protection it needs, and what are potential vulnerabilities to patch, and events to monitor for?
The following is an incomplete list of ways you can prepare for security. These help you plan for the worst.
- Procedures: How to implement and test security controls
- Best practices: Proper password handling, Defense-in-Depth, Monitoring
When evaluating potential vendors you can typically find their policies through their website footer or other site navigation. These documents can be quite tedious to read, but they can provide an indication of how they do handle their security. Spend some time on your search-engine of choice looking for reviews of the company. It isn't unusual to not find anything positive or negative about a company's security.
How well a vendor responds when something does go wrong is closely tied to how well they have prepared for things to go wrong. If the vendor responds with a tangible and reasonable time-line and appropriate response, that's a great start. If they follow through and resolve to satisfaction, they deserve some credit for their recovery.
One of the things to look for here is if they try to sweep problems under the rug and not disclose what happened. Don't get me wrong, there will be details that cannot or should not be shared publicly. That is fine, but obscuring those details is a very different approach than trying to hide it even happened.
Another warning sign is when customer support attempts to deflect blame, downplay the severity, or flat-out ignore the existence of a problem. Unfortunately, this happens all too often. If you want to follow a regular stream of this type of event, follow Troy Hunt's twitter for a while.
This is a component that is difficult to rank until something bad happens. When that does, this component should be revisited and determine how they did.
Learn from mistakes
When things don't go right, there is always something to learn. This is often handled in a postmortem report that examines the cause, impact, and next steps (e.g. back to preparation). This is all about learning, improving and being more prepared for next time. GitLab has a great example of a postmorterm report detailing a very public outage. This is an example of what it looks like when it's done the right way.
After a minor incident earlier this year I wrote about my plans to reduce future risk with two improvements:
"We are currently working on moving our domains to a new domain registrar ... We are working on improvements to our automated monitoring and reporting systems to report this type of error more quickly."
As of July 2018, we are making progress with two domains moved from Domain.com to our new domain registrar, Hover.com. The remainder of our existing domains will be migrated over the next few months. The goal is to be more secure tomorrow than we are today.
With security as a feature in mind, let's apply this to the typical infrastructure for a simple website. The following diagram illustrates generic components you can expect to find powering a modern website. Visitors to your website receive your content from a web application (WordPress, Joomla, Flask, etc), often linked to a relational database (PostgreSQL, MS SQL, MySQL). The web app and database require some sort of hosting, AWS EC2, Digital Ocean droplets, Azure, etc.
It isn't uncommon for each of the boxes represented in the above diagram to be a distinct vendor. Some vendors may cover two or three of the boxes, but rarely would I even recommend choosing to put all your eggs in one basket.
Bad security, bad response
Troy Hunt wrote a post titled Security insanity: how we keep failing at the basics two years ago now. I'm certain I used that post as a reference for my coursework for my cybersecurity specialization more than once! Unfortunately, we continue to see terrible security practices being defended by companies with "because security" as their main justification.
A recent thread on Twitter caught my attention when a user called out BlueHost for apparently storing passwords in plain text.
I really need to question @bluehost's security model when I get this for verifying access to an account. Are you seriously saving customer's passwords unhashed for support to see? Even part of the password? pic.twitter.com/dCsujl6uGc— Michael Gillespie (@demonslay335) 31 May 2018
Their response in that thread is a shining example of the "because security" defense mechanism at work.
"... I'm sure you understand that we cannot disclose how our backend systems work...."
What's so bad?
First, let's get this notice out of the way...
If you have used your BlueHost account password on any other website or service, you should change your password on those other services immediately.
Am I overreacting? Let's explore the scenarios. There are three likely options with the very limited information we have so far.
- Your entire password is stored in plain text
- The last 4 characters of your password are stored in plain text
- They hash just the last 4 characters separately from the full password
Passwords stored in plain text
Storing the password in plain text would be an example of the worst type of security for passwords. Let's pretend we know for sure they aren't doing this.
Last four characters in plain text
The next worst scenario is that they're only storing the last 4 characters of your password in plain text.
To explore the impact of having 4 characters of your password revealed we should refer to BlueHost's password policy, specifically related to password length and complexity.
A side note: This little gem stuck out to me and I have to address this:
- A minimum strength rating of "Meh" or higher
This is just plan bad. "Meh" or higher"?? It's 2018, this is not what we need to be training people to use for their passwords. Especially a password that provides access and control to an important part of your website's infrastructure.
Ok, back to the main password requirements:
- At least eight characters
- At least one capital letter
- At least one lowercase letter
- At least one number
- At least one special character
If the last 4 characters are in plain-text then they have 50% of your 8-character minimum. Knowing that there's a capital, lowercase, number and special digit, common password schemes are prevalent and reverse engineering the other 50% of the password is trivial. Not to mention that NIST released new rules two years ago that should have indicated to BlueHost they need to update their policy to not include the requirements of character types (upper/lower/special/number)
Best case scenario
The best case scenario I can conjure is they're using a properly secure one-way hashing algorithm intended for use with passwords to hash the last 4 characters of your password. In this scenario, if the database is breached and these hashed 4 characters are leaked. This could give the bad guy a much softer target to brute force attacks, solve half that problem exponentially quicker, then use that to solve the full problem.
Even the best case scenario is far from good.
Myth: Obscurity keeps your password more secure
When it comes to password hashing and storage, the only reason a vendor doesn't want to share what they use is because they're ashamed, or don't know. If they don't know, know is a perfect time to find out. If they're ashamed, now is the perfect time to plan that upgrade ASAP.
All RustProof Labs developed systems with passwords use
cost=12to hash user passwords before use or storage. If you have questions or concerns about this please contact us
See, that wasn't painful at all! An attacker gains no helpful knowledge from that piece of information. If you feel our choice negatively impacts you, we have provided you with an easy way to establish contact and raise your concern.
As I said before, the goal is to be more secure tomorrow than we are today. It starts with preparation and continuing to be prepared. When something goes awry (highly likely), respond with concern, honesty, respect and as much transparency as is possible.
Security is a feature that should be considered throughout an organization's IT infrastructure. Throughout this post I outlined a very open ended framework for evaluating security. We have a wide variety of connected services available to us, and that makes it easy to adopt new IT infrastructure with little planning or thought. It is our responsibility to evaluate and ensure the security of the choices we make.
Published July 11, 2018
Last Updated September 11, 2018