In 2020 alone, Risk Based Security recorded over 3,900 data breaches worldwide. A considerable number, yes, but 48% lower than in 2019. Don’t start celebrating just yet–the report also found that 37 billion records were exposed in 2020, an increase of 141% from the prior year. With risk comes cost–according to an IBM report the average cost of a breach was $3.86 million.
Based on these statistics, one thing is certain: a data breach is a very real and costly threat. As such, an organization will ask how they can reduce their risk of a breach, and which of their current processes put them most at risk. In the first part of this blog series, we will cover the top five risk-prone areas that developers and software engineers should be aware of. In parts two and three, we’ll focus on some of the people-oriented processes putting you at risk of a breach, following up with some actionable tips and recommendations for organizations to protect themselves and their customers’ data.
Back-end Processes that Might be Putting You at Risk
Risk Number One: Outdated, Legacy Systems
Legacy systems are tremendously expensive. In 2019, it was reported that the 10 legacy systems in the federal government that are in the most need of modernization cost $337 million to operate and maintain. Costs aside, legacy systems pose an elevated risk of a data breach due to outdated code and limited qualified personnel to maintain that code, creating a perfect environment for a hacker to find their way in.
Despite the risks, many organizations continue to rely on these outdated systems. The reluctance to update or replace isn’t from nonchalance; this is usually because the systems were created for a specific purpose. Removing them could lead to data loss, or an inability for an organization to execute critical processes. Therefore, rather than replacing their legacy systems, organizations may try to patch known security issues or overlay other solutions, such as firewalls, anti-virus and email encryption systems to reduce vulnerabilities.
Risk Number Two: Loose Data Permissions
Would you give the keys to your house to just anyone in your circle? Probably not, because you understand not everyone should have that kind of access. There is really no reason for your college roommate to have your keys, nor your third cousin. If you wouldn’t give everyone unlimited access to your house, why would you grant every employee access to all the data in your organization?
Just as giving away house keys opens the door to serious problems, playing fast and loose with data permissions is risky, too. This isn’t merely because of the risk of malicious intent by insiders (which accounted for just 2.7% of the data breaches recorded in 2020), but rather the much-higher risk of sensitive data being mishandled internally. It doesn’t matter whether the cause of the accidental breach is a lack of awareness or training, or from employees being stressed or in a rush. Where there is opportunity for a mistake to occur, you will find a higher likelihood of a hack and/or an internal breach.
To sum up: don’t give out the keys to your house unless you want to change your locks (and replace your jewelry and television) after learning that an intruder has already let themselves in.
Risk Number Three: Sloppy Code & Unsecure APIs
As a developer, you are notoriously busy. There is almost always a new product or update to release on a tight timeframe while simultaneously fixing bugs and improving performance. High stress and low bandwidth can lead to errors slipping under your radar. If you aren’t given the time to rigorously test your code, your organization runs the risk of releasing a project with security holes, thus increasing the number of vulnerabilities, and the risk of a data breach.
Take the recent Peloton issue. Although no known data breach has been recorded, the company detected a flaw in their system that allowed anyone to grab members’ public and private profile data. The problem behind the breach? An API that did not authenticate the person requesting the information.
Knowing that big development projects are time-consuming and typically involve features outside of your bandwidth, you might consider using third-party APIs. This option can help to curtail the time and financial burden associated with building a project from scratch, while you benefit from the expertise that the API company brings. (But don’t gamble on your data security–do your diligence and research your vendor and the API you’re planning to use before coding them in.)
In short, it is critical to select APIs that follow proper security measures. APIs that use OAuth or SAML authentication, strong encryption (AES 256, TLS), and those with rate limits all reduce the risk of a breach. Choosing an API that uses a zero-trust model, while unfortunately rather rare, is also another best practice to enhance the security of your project.
Risk Number Four: No Protections for Data in Motion
Most people understand the risks associated with sending an email, including phishing, malware, and ransomware (to name just a few). The topic of inbound email security is frequently discussed; instead of exploring that topic further here, we’ll point you to this great article on CIO.com. Rather, we’ll examine a less-discussed risk–that of sending sensitive information in an outbound email.
When you send an email, that message passes through many systems and network locations. Think of the process as traveling abroad. As a tourist, you would carry your driver’s license, insurance card, credit card, and passport. If you are marked as a tourist, an experienced pick-pocketer can steal these items without anyone being the wiser. But by taking steps to secure your belongings, such as with an RFID wallet clipped to your belt, your chances of theft go down greatly.
Protecting your outbound data is a similar concept. Just as you’d act to secure your documents while traveling, it is equally important to secure any sensitive information sent from your systems. Like a pick-pocket, a capable hacker can intercept email and access sensitive information before you even notice a problem. Taking the proper measures to protect your sensitive data diminishes both the threat and impact of an email interception. For instance, using an email encryption service renders the content in your exchanges useless to hackers, greatly decreasing the chance of a breach. Utilizing options such as secure email, content filters, and customer channels for secure messaging can lower your risk and accelerate your business, which we’ll discuss further in part three of this series.
Risk Number Five: Security as an Afterthought
There’s a saying, “if you fail to plan, you plan to fail.” Perfect examples of this include failure to assess overall risk factors and proactively identifying and addressing software vulnerabilities before they become an issue. Another blueprint for failure is falsely assuming that your organization is not susceptible to a breach. Building your solutions without security as top-of-mind invites hackers in, and you’ll find yourself in a race against the clock to find uninvited guests in your production systems before they gain control of sensitive data.
Make no mistake: it’s not a question of if you’ll suffer a data breach, but rather, a question of when. Being proactive about protecting your systems and data is much (much!) better than being reactive.
You now know of five back-end factors that may be putting your organization at risk of a data breach. Stay tuned for the next part of this series as we examine the people-oriented processes that put your enterprise at risk. In the meantime, learn more about how you can protect your data at rest, in use, and in-motion and follow us on LinkedIn, Twitter, Instagram, or Facebook to gain security insights and be the first to know when we release the next part of this series.