A Lesson Learned in Secure Coding

Tyler Throckmorton

Software Developer, Healthcare Leader, Golf Enthusiast, Foodie

It’s Saturday morning. You just woke up from a very long night of drinking with friends after celebrating a major milestone in your life. The first thing you notice is the massive hangover, but this is quickly overshadowed by the hundreds of texts and missed calls on your phone. You check it and it was the bank giving you withdrawal notifications, ACH transfer notifications, and fraud alerts. You login to your bank account and you now have $10 to your name.

This is a worst-case, horrible scenario that no one should ever have to go through. Yet, it’s not that far-fetched of a scenario to imagine. If you’ve read my previous installments, you know that Software Development is an art no different than a painter painting their masterpiece or a professional golfer winning the Masters. If we look at the tour, Tiger Woods did just wake up one morning and start playing golf. Many of these people may have exceptional skills that makes them better at the sport than you or I, but they still had to go practice every day and hone their craft. Software Development is no different. It’s a skill that must be learned and fostered to improve.

Let’s return to our recurring example – our telecommunications system and CRM integration. Now let’s add in our bank analogy from earlier. How might’ve this happened? How could someone have gotten access to my bank account and stolen all my money? I’ve done everything right – I don’t share my account with anyone, I use a long and secure password, and I’ve got multi-factor authentication (MFA) enabled on my account. How could someone have gotten in and done this? Was I hacked? Did someone steal my debit card last night while we were out? Did I fall for a scam? All of these are possibilities and extremely likely scenarios, but it’s not what happened this time. This time, you did nothing wrong and there was nothing you could have done to prevent this.

Your bank, just like any other company, uses a complex system integrated between many different departments, solutions, and products. They’ve recently gone through a project to integrate their telecommunications system with their CRM so their call center can be more efficient. In doing so, they created another way to access your bank account. All that was required was access to this new system. In this day and age of how interconnected our systems are, and how quickly companies and businesses want to see innovative solutions and products reach the market, vulnerabilities happen. Software Developers have adapted to the speed requested by re-using existing code and libraries created by other developers. In the case of some of the biggest vulnerabilities that have come to light in the past several years, this is where some of the largest problems come from. This is called a Supply Chain Attack. Rather than attempting to find a fault or problem in the company themselves, they find a problem in the code written by someone else that they happen to use. Probably the most notable and memorable of these problems is Log4J. This was logging software used industry-wide where a vulnerability was discovered that then affected every software that utilized it. Another notable example is Solarwinds Orion when their software affected pushed a malicious software update that ended up affecting Fortune 500s and government entities for weeks.

I’ve talked enough now about what went wrong. How do we fix it? First, software developers really need to understand the code that they’re writing and how it works. What does the code do when it executes. Think back to math class in grade school, you got the correct answer to 2+2 but now you’re being asked to show your work. How did you get that 2+2 = 4? Getting the right answer, or in our case, the right outcome is good but that doesn’t work in secure coding. Knowing how you got to the outcome or answer is just as important as what the answer is. If you don’t know how you got there, you don’t know what could have happened or gone wrong along the way.

Second, software developers have to learn new skills. Companies are cropping up all over the place to check your code for vulnerabilities or deficiencies. This are great tools to use to help secure your work, but they’re nothing new. Anything that a developer writes should be pushed through Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). These mechanisms do two different things and are very important to the process. SAST compares your code against known vulnerabilities to tell you what needs fixed or changed to improve or secure your code better. This is great but realize that it does it only against what is known. DAST takes it to the next step and simulates attacks against your website to attempt to find ways that an attacker might break into the system. It’s this practical testing that separates itself and makes it that much more important to do.

Lastly, this is often the easiest step to do, but the step that is often what leads to breaches. Companies need to keep their systems up-to-date with patches and version upgrades. This is easier said than done, but it is the most important step. We’ve established that vulnerabilities are discovered all the time. This is partly the reason that many of these upgrades and patches are delivered, to fix these vulnerabilities found in the products being used. However, despite the risk of not patching, there’s risk in patching just the same. What if this patch or upgrade breaks a system or process important to how the business operates? This question is what often leads companies to delay patching to allow time to test and validate that it works within their company and environment. However, this delay can sometimes lead to a breach within the system. It’s a delicate balance, but an important balance and process nonetheless.

Despite all of the steps I’ve outlined to create a secure coding environment and improve our posture to protect customers. Many in IT and Cybersecurity ask a different question. It’s not “Are we doing enough?” or “Will we get breached?”. The question asked is “When will we get breached?” Just like how we’re working day in and day out to secure our systems. The bad actors are working just as hard on the other side to find new ways that we haven’t discovered yet. If history has shown us anything, it’s that it’s often much easier to attack than it is to defend. And while it may be expensive to invest in the correct tools and resources to protect our systems and make our customers more secure. It’s better than the alternative. Nobody wants to be the person that wakes up to an empty bank account after a night celebrating.