In any given week, security researchers discover caches of data on cloud servers that are completely open to the public, usually containing the most sensitive information about a company’s customers. Leaks were found earlier this summer that revealed data coming from Avon as well as from Ancestry.com. This latter leak wasn’t the first breach for Ancestry — it had an earlier 2017 leak here. The problem is simple to describe and appears — at least at first glance — simple to fix. When you initially set up your online storage, you are asked who has access and what rights are accorded to each user. However, developers have hundreds if not thousands of containers to keep track of, and sometimes they forget to lock all of them down.

In my blog for Network Solutions, I discuss how to find these unsecured containers and how to prevent these leaks from happening.

Zulfikar Ramzan mentions in his blog post from last month, “Next year, CISOs will have to grapple with the consequences of the decisions they made (or were forced to make) in 2020. One of their first orders of business will be to ‘un-cut’ the corners they took in the spring to stand up remote work.” Nowhere is this more the case than with dealing with their technical infosec debt, a term coined by Ward Cunningham decades ago.

This is a term that has taken on a greater sense of urgency thanks to the continued pandemic. (See this cartoon for a more humorous illustration.) It is basically a fancy term for taking the easy route, for cutting corners and saving time by not really looking at the longer-term consequences of certain decisions that make your IT infrastructure inherently insecure. It reflects the implied costs of reworking the code in your program due to taking these shortcuts, shortcuts that eventually will catch up with you and have major security implications in the future.

Security trainer and consultant Tanya Janca puts it this way: “Technical debt is a decision. It is a decision to put upgrading, fixing, and improving last. Technical debt is security debt, and you need to make it a personal priority to prevent it.” By choosing the most expedient route, she says IT managers accumulate lots of debt. Examples abound, including “not patching or upgrading endpoints and servers as soon as these are available, using outdated programming and development frameworks or code sources, or being slow to react to specific changes that are needed in your home-grown apps,” she says in her latest book, Alice and Bob Learn Application Security. The focus of the book is on building more secure apps, and technical debt just gets a small mention – but the book (and an accompanying series of online classes available on her website) are an excellent resource for those new to app security.

Technical debt thrives in massive bureaucracies, where buying paper clips require five signatures, or so it seems. If your enterprise makes it difficult for your developers to get the right tools and software frameworks to do their jobs, they will take the easier (and less secure) path. Debt will accumulate if the normal software development cycle is measured in months rather than minutes. Look at the major breaches of the past few years – if the technical debt at Equifax, Uber and Target had “been better understood, then perhaps it could have been appropriately managed and brand reputation could have been maintained and financial losses avoided,” said Jane Frankland, a security executive writing in 2019.

Granted, the pandemic has forced the hand of many IT organizations that can barely keep the wheels turning, let alone have more longer-term plans to keep things as secure as possible. Which comes back to Ramzan’s post.

If you want to pay down your technical debt, here are some suggestions to get started. First, examine your collaboration between your development and security teams. The more they can share best practices, the more secure your apps will become. Second, try to avoid making lots of last-minute changes to your apps, but try to consider security before a single line of code is written. One way to be more deliberate is to have a set of test suites to root out any bugs or missteps. Look at your security issues holistically, not sequentially, as Frankland suggests. (She has lots of other suggestions on her blog too at the link above.)  Create a solid code documentation culture, which avoids making quick and dirty development decisions without considering the security implications. Finally, Cunningham himself had these words of wisdom: “Don’t let the debt build up. Everyone knows the list will never be addressed. Remove cruft as you go. Build simplicity and clarity in from the beginning.”

Janca writes in her book, “When organizations spend most of their time just trying to keep the lights on, constantly fighting fires, technical debt will most certainly result in security problems as well.”

Microsoft has found that various browsers are being targeted with ad-injection malware called Adrozek. At the attack’s peak in August, the malware was observed on more than 30,000 devices every day, according to the researchers. The adware, as it is called, substitutes phony search results that when clicked will infect your computer.

You can read my analysis of the malware and what you can to prevent it in my latest blog post for Avast here.

A large portion of security professionals think that their job is to prevent bad actors from gaining access to trusted resources. Yes, in isolation that is a true statement. But the implications of that position hide what is really supposed to happen. Instead, it is the job of infosec pros to ensure only appropriate actors can access trusted resources. One way this is accomplished is through what is called Security Chaos Engineering, which tests security resilience before some attack happens. It is an evolution of the pioneering work that was first done at Netflix many years ago. Now there are a number of similar products and related practitioners in this field.

The concept is simple to explain, but exceedingly hard to implement. One reason why this type of engineering mindset is needed has to do with the way that breaches are understood by corporate workers. Too often we don’t think about our IT infrastructure holistically, and when a breach happens we try to just plug the hole and move on. How many post-breach memos have you read where the author says, “we are taking steps to ensure this never happens again?” Technically that is the right approach: the next breach will happen somewhere else in our network, caused by some other “hole.” Another reason is that the average software stack has gotten so complex and distributed that it’s hard to comprehend and defend. It isn’t a matter of if you will have a breach, but when and how and what part of your systems will be compromised.

Adopting chaos engineering means that you look for potential points of failure across all of your IT systems. Part of this should be inherent in any lifecycle governance of your systems. But part is also being clever about how you test your systems. If you think you have this covered with penetration testing, you need to think again. The usual pen test engagement is a single moment in time when a SWAT team inhabits a conference room (perhaps now they do this virtually) and tries their mettle against your security defenses. Chaos engineering is a continuous practice, whereby your team is continuously testing your systems and software. Sadly, the old methods don’t work anymore. For example, just because you bought a firewall several years ago and have spent time defining a rule set doesn’t mean these rules are relevant or effective today. Your systems might be completely different and no longer protected. And these days, with rising cases of ransomware and data exfiltration, you want to catch these attacks before they do real damage.

Netflix was one of the first places to make overall chaos engineering popular several years ago with a tool they called Chaos Monkey. It was designed to test the company’s Amazon Web Services infrastructure by constantly – and randomly – shutting down various production servers. This always-on feature is important, because no single event will do enough damage or provide enough insight to harden your systems or find the weakest points in your infrastructure. Now that we live in the era of complex security events that leverage multiple malware techniques which are part of a coordinated campaign, we need to design and test for more sophisticated and longer-lasting attacks. We need better tools and that is where Security Chaos Engineering can help. In addition to the open source tools that came from Netflix, there are commercial products such as Verodin/Mandian’s Security Validation, SafeBreach’s Breach and Attack Simulation, and AttackIQ’s Security Optimization Platform, just to name a few of them.

Customers who have used these tools suggest the following best practices:

• Have an action plan: don’t change more than one variable at a time
• Define the rules of engagement (including the scaling up of your systems) so you maintain control when things go south
• Know your “blast radius” and the disruptive implications of your tests
• Use a tool that integrates with your SIEM logs (for example, SafeBreach can work with RSA’s NetWitness Platform)

This last item bears further explanation. A SIEM log can easily be overlooked, especially if you are hunting for a single entry in a massive dataset. Security Chaos Engineering tools can automatically find these entries and advise you about their implications – such as changing a too-loosely-defined software access roles policy, for example.

If you haven’t yet examined any of these chaos engineering tools – both for general systems analysis and for security-related issues – now might be the time to take a closer look. It is time for every security team to change their mindset from patching as a result of a security event to becoming more proactive in anticipating future attacks.

It is a bit risky writing about the year’s trends and predictions this time around. Certainly, the Covid pandemic has dominated our lives during the past year and thrown many of our predictions out the window. But re-reading my RSA blog post from a year ago, there are still these two themes which are very much at the forefront.

• Better authentication. In the past year, we saw Apple wholeheartedly embrace FIDO and new implementations that extend its features to web-based authentication. Both will go a long way towards implementing this standard. And support for multi-factor authentication continues to improve too, although it still is far from universal. Only 10% of enterprise users use any form of multi-factor authentication for any of their application logins. Given the popularity of smartphones, installing an authentication app on your phone is the easiest form of protection you can get. But wait, there is more bad news: less than 20% of companies in most industries are protected with email authentication tools such as DMARC and SPF. Sadly, most state and local government domains remain unprotected with these technologies.
• Ransomware continues to rise. Various reports (such as this one) show a rise in the number and severity of these attacks, with new exploits and variants being seen every week. Some ransomware is designed specifically to target machine learning data, so that models will report bad results and poison automated security solutions.

But let’s look forward, not backward, and certainly we should discuss where we go with Covid. Now that everyone is working from elsewhere, endpoints are being shared across families, making them more vulnerable to exploits. Google has seen 1M daily phishing attempts across its email infrastructure. And there are tons of phishing lures with Covid-related subject lines, or messages that offer free testing or deals on travel. The virus also demonstrated why business continuity and better risk management decision-making is essential.  Security awareness training now starts with the home, and if you are sharing your networks with your family, they need to be trained as well.

RSA’s Anti-fraud group has also found an increase in QR code fraud. These codes became more popular this year to try to promote contactless retail shopping or dining experiences. The bad guys quickly picked up on this trend. They trick users into downloading malicious programs or to use QR codes for a new type of phishing attack that bring users to a malicious copycat website. The above link has a bunch of handy suggestions to discern whether your QR code will bring you to potential malware-infested sites and other tips on how to be more aware of malicious codes.

What does the future hold? We should expect more high-profile victims in 2021. In 2020, Twitter, Zoom, Marriot and Nintendo were the top victims of various social engineering and credential stuffing attacks. None of these were technically sophisticated – the Marriott attack, for example, was successful because it managed to compromise just two employees’ accounts. Better authentication and more security awareness training could have prevented this.

A second issue is that of deep fake videos. What began as innocent and simple photo editing software has evolved into an entire industry that is designed to pollute the online ecosystem of video information. The past couple of years has seen advances in more sophisticated image alteration and using AI tools to create these deep fakes. I also see improvements to that will be harder for recipients to discern, and fakes that will quickly spread across social networks.

The hacker’s forum called OGUsers has ironically been a tempting target for criminals, with a series of at least three successful hacking attempts in the past couple of years: Once in May 2019, a second time in March 2020, and a third time just last week. In my post for Avast’s blog, I talk about how this forum came to be and its involvement in a series of earlier hacks that it originated as well as more specifics on the three attempts. And a few suggestions on what you can do to prevent your account data from being compromised.