On the behalf of the entire Rietta team, I would like to give a huge shout out to Jason Charnes (@jmcharnes) for hosting the South East Ruby Conf in Nashville, TN this week. I was pleased to meet many members of the Ruby On Rails Link Slack Group.
Each and every talk was fantastic, I’d like to go into depth with a few highlights for anybody that was unable to participate in this conference.
There are many tools out there that help you get a quick idea of possible security issues in your code and dependencies, but how often do you run them? If you’re running a Rails app and have never run brakeman or bundler-audit, I strongly urge you to run these tools immediately. Brakeman finds common insecure coding patterns that might be exploitable in the correct context and bundler-audit checks for known vulnerabilities within your installed gem dependencies.
The premise of this blog post isn’t to teach you to run these tools, but rather to teach you how to implement these tools into your Continuous Integration service. If you’re curious of how to run these tools outside of the test suite, both tool’s READMEs are informative.
Equifax has confirmed that the main vector that lead to the data breach was a remote code execution vulnerability in Apache Struts that had been known for months [1]. Equifax had not yet patched it within the production environment. This is not just a lesson in the importance of patch management but one of defense in depth. The weakness in Equifax’s design was set in motion years before when they failed to design with the assumption that the front-end web server would be compromised.
The attacker was able to obtain the massive trove of private data because the web application was the only gatekeeper. Once the remote code execution vulnerability was exploited, the attacker was able to access data unfettered by additional access controls. Equifax chose to use a typical web application architecture without defense in depth.
Defense in depth has to start as part of the development process. All developers should be aware of the OWASP Top 10 (#3) and their work should be audited against the OWASP Advanced Security Verification Standard (ASVS) [#3] for the level appropriate for the risk faced by an organization in the event of a security breach.
Christoper Rigor has posted a good set of Ruby on Rails Security 17-Item Checklist on Engine Yard’s blog. Check it out.
He did a good job hitting the important ones without being overly verbose.
If you’re looking for a standard to follow, check out the OWASP ASVS.
Your Internet Service Provider has direct access to the type of information on you and your family that the National Security Agency uses for spying.
Your ISP knows when you are at home and when you are not, when your kids are doing their homework. They know or can know what you’re watching on Netflix (even when its encrypted) and YouTube. If any member of your household ever views pornographic content, your ISP knows how much and at what times such content is accessed. They can infer through traffic analysis how many people are living at your home and even know how many iPhone and Android devices that you have. And even though they cannot see into your encrypted search queries on Google, your ISP knows every medical website that you visited to research a condition that you think you have or are looking into a drug that your doctor has prescribed to you.
Dear Honorable Members of the United States Congress:
I work in application security in the cybersecurity field to make software more secure from attack. The cybersecurity threats that face our nation are very important to my wife and me. As Americans, our private data is in great jeopardy because of increased cybersecurity threats. Our infrastructure is prone to being hacked, and major data breaches of both private and government networks are routinely in the news. The best way to prevent these breaches is to increase the use of strong encryption with no backdoors.
The track record of data breaches demonstrates an uncomfortable truth: when sophisticated adversaries want to hack a network, they will ultimately win. Among the few tools known to computer science that can prevent a data breach is strong encryption. This means that there is no backdoor and no backup key. Either the original user needs to enter the password, or the data is un-retrievable.
Earlier this month I had the honor of speaking with information security students at Kennesaw State University in Georgia thanks to Dr. Herbert Mattord. It is a very diverse class with both traditional students and more mature students who are switching careers. Most of the students had little or no professional software development experience so I view these talks as extra critical because infosec professionals play an important role in this by working with developers and thus need to know something about how software is made.
It’s been a few months and I wish I had shared the link with you sooner. Back on August 29, 2016, I was the guest of Joe Gray’s Advanced Persistent Security Podcast’s Intro To App Sec Episode.
We talked about application security and the news. Give it a listen!
Tim Kadlec has written a fantastic blog post that you should read right away at https://snyk.io/blog/mongodb-hack-and-secure-defaults.
It starts with: “If you have a MongoDB installation, now would be the time to verify that it is secure. Since just before Christmas, over 28,000 public MongoDB installs have been hacked. The attackers are holding the hacked data ransom, demanding companies pay using Bitcoins to get their data back. From the looks of it, at least 20 companies have given in and paid the ransom so far. This post explains the hack, how to protect yourself, and what we can learn from it.”
This is a topic that I’ve found to be important in my work with clients. I’ve written about it privately and even Tweeted along these lines. Hats off to Mr. Kadlec for publishing this. One of my friends, Bennie, had found a great analogy for the Mongo situation saying that “as is true in many cases with everything, it is pilot error! The big difference is people are able to ‘fly’ software without giving proof they’ve had ‘flying’ lessons!”
Before Christmas, I posted some new videos up at https://rietta.com/learning/appsec. Namely the first two lessons in a new series of security in software development. Start to learn how developers can help prevent a data breach and the roles of blue, red, and purple teams in software development.
Please let me know your application security questions and I will do my best to answer, possibly by video!
As a fun little experiment, I ran the same CPU benchmark on a few processors that I have around my home office that come from various generations. The Raspberry Pi was predictably beaten by even the nine year old AMD Athlon processor, but considering its from factor and power usage it is a remarkably versatile little system on a chip.