Throughout the public debate over Georgia SB 315, a bad analogy has been repeated by others that a public business or institution’s website server is like an online home. And, because nobody lets strangers just walk into their own home, Georgia should set the expectation that no one, criminal or ethical, should be allowed to come into an organization’s digital “home” without permission. But this analogy does not match reality!

Friday, April 13, 2018

Governor Nathan Deal
Office of the Governor
206 Washington Street
111 State Capitol
Atlanta, Georgia 30334

Dear Governor Deal:

I am writing you today on behalf of my Georgia-based security firm, asking that you veto SB 315. I am a long term Georgia resident, raised in the Atlanta area, and earned a B.S. in Computer Science and an M.S. in Information Security at Georgia Tech. My wife Danielle is a Mercer University alumna, and we are both conservative Christians who voted for you. My interests in computer security started early after I founded AtlantaWebHost.com eighteen years ago and started to see first hand how websites and servers were under continuous attack by malicious hackers. This first hand experience was the catalyst for pursuing a career dedicated to protecting websites and web applications from attackers.

An independent security researcher just uncovered Panera Bread’s negligent exposure of millions of customer records. He notified Panera in a responsible manner and even after 8 months had not fixed the flaw. The underlying problem was specifically serving private data on a public endpoint without strict authentication and access control. This is so basic that beginner API developers should know to avoid it. Moreover, it’s among the OWASP Top 10 (owasp.org), well known ways that databases become compromised through insecure web applications.

The Georgia House of Representatives voted 107 to 63 to approve GA SB 315 (LC 29 8107S) (PDF / legis.ga.gov) on Tuesday, March 27, 2018, on the Senate voted 42 to 7 to accept the House changes in the last hours of the session on Thursday, March 29, 2018. This bill has been specifically crafted to make critical security threat research a crime now heads to Governor Deal’s desk for his signature or veto.

GA SB 315 protects the 94% of the Forbes 2000 public companies that have no way to report a security hole at the expense of the public. They do not need this protection. We need a way to hold them accountable so that they fix their vulnerabilities.

This chilling fact was part of recent US Senate testimony by Katie Moussouris, the security professional responsible for launching Microsoft’s and the US Department of Defense’s first bug bounty programs.

That means only 120 of these companies have a formal program to receive information about and actively fix security flaws that impact the public. The other 1880 will just as soon press criminal charges or civilly sue anyone who dares attempt to bring a security hole to their attention. Many of these companies would rather put their heads in the sand and pretend that they have no issues than to actually fix fundamental security problems with their IT systems. This is why we hear so much about cybersecurity insurance and companies and governments paying ransom to unlock their data rather than actually deploying comprehensive security controls in the first place.

Please contact Governor Nathan Deal and ask that he VETO SB 315! Tell him that our Internet security is too important to jeopardize with an overly broad bill that can be used to put innocent Georgians in jail and destroy the careers of law abiding citizens while doing nothing to hold the companies who put our data at risk accountable.

GA SB 315 (LC 29 8107S) (PDF / legis.ga.gov) just passed the House Judiciary Non-Civil Committee and will be voted on this week. While significantly improved through the committee process, it still creates a dangerously broad definition of Criminal Unauthorized Computer Access that is so sweeping, people will need permission before visiting any website.

This bill was drafted because Georgia law enforcement and the U.S. FBI could not find any law broken by a professional security researcher. This researcher tried to alert Georgia election officials of voter data inappropriately published publicly on the Internet by Kennesaw State University, a contractor for the Georgia Secretary of State’s Office. What he discovered through ordinary Google searching was that voters’ names, addresses, and other private information was indexed by Google and accessible by anyone. After months, he and another researcher discovered that the data was still available on the public Internet and brought it to the attention of the media. Only under the daylight of public attention was the data removed from the Internet in an embarrassing scandal.

The Equifax website borked again, this time to redirect to fake Flash update (arstechnica.com). This is the latest episode in the sad saga of insecurity at the embattled Atlanta-based credit reporting giant. Atlanta is known for a healthy information security ecosystem and the Georgia Institute of Technology and Kennesaw State University both have cybersecurity programs at the undergraduate and graduate level. If Equifax cared to hire security minded people to work in key areas they could.

Certainly more details of this attack will emerge but there is “a strong case that Equifax was working with a third-party ad network or analytics provider that’s responsible for the redirects.” My advice for any website operator is to lay off on the marketing plugins and JavaScript widgets that your SEO team loves so much. Focus on your core technology and remember that attacks on your technology supply chain can lead to significant security incidents for your company.

Patch management is hard when the software being patched is supported by a major corporation with a long support window. It’s even harder when integrating numerous open source projects of various maturity. One lesson from the Equifax data breach is that failure to update your deployed application for months after the upstream project is updated can lead to dire consequences.

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.