Category: Cyber Security

OpenSSL has classified an upcoming issue as critical severity as it affects common configurations and can be exploited. So far (it’s October 31st right now as I type this blog post), they are not saying anything else.

It is mostly a Linux package, so here is what you should do tomorrow:

• Ubuntu/Debian users should run “apt update” and “apt upgrade,” 
• Redhat/Amazon/Fedora/Suse users should run “yum update,” 
• Alpine users should run “apk update” and “apk upgrade.”
• Any Docker containers running on base images based on any of the above obviously need to be re-imaged!
• Typically updates do not require machine restarts, but personally, I would still reboot.

Also, after upgrading, everyone should then type “openssl version” on their machines to verify whether they even have it installed and are running a vulnerable version.

For example, on my machine right now (Ubuntu 22.04 – October 31st – 1 day before the security release):

$ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

Yikes! I’m vulnerable!

But seeing as it’s still Monday, October 31st, there is not much I can else I can do at this point.

Note: Only versions 3.x before 3.0.7 are vulnerable. They have never released any 2.x versions, and versions that start with 1.x are not vulnerable to this bug.

(For now, let’s pray it’s a runtime weakness in OpenSSL, and not a weakness in private keys generated by it since a weakness in generated keys would be a huge headache to deal with – I don’t think keys even retain which version of OpenSSL they were generated by!)

Forthcoming Releases

Find more here.

More updates after the release on Nov 1st:

• OpenSSL team’s blog post about why they downgraded the vulnerability from CRITICAL to just HIGH.
• AWS Distinguished Engineer Colm MacCárthaigh shows in deep technical detail exactly how the bug works (and how very difficult it would be to exploit).
•  Cybersecurity and Infrastructure Security Agency (CISA) also warn about the vulnerability and encourages users and administrators to review and update to the new version.

In June of 2022, the Canadian House of Commons introduced its first reading of Bill C-26, an initiative addressing cyber security within Canada’s infrastructure. This bill is not a very controversial document, and if it passes, it will bring about a few significant changes to cyber security standards in Canada.

We don’t know when (or if) C-26 will become law. But because it is keeping with trends in third-party liability law, it’s wise for software companies (and companies involved in Canadian infrastructure) to take note of the bill’s implications.

Bill C-26 deals with an emerging issue in cyber security law—third-party liability. For an overview of this issue and why it’s important, read our Executive’s Guide to Third-party Liability in Cyber Security Law.

A quick overview of Bill C-26

This bill aims to make Canadian infrastructure more secure in two major ways.

First, C-26 would keep Huawei technologies outside of Canadian telecommunications systems by amending the Telecommunications Act. While other nations have built Huawei technology into their 5G networks, Canadian legislators want to protect their network (and their data) from being accessible to the Chinese tech giant. 

Second, C-26 would raise cyber security standards for companies that operate vital systems by enacting the Critical Cyber Systems Protection Act (CCSPA). 

The CCSPA designates some operators as critical cyber systems (CCSs). The act defines a CCS as a system that “if its confidentiality, integrity, or availability were compromised, could affect the continuity or security of a vital service or vital system.” If the CCSPA is enacted, organizations responsible for critical cyber systems would be required to do the following:

1. Establish a cybersecurity program within 90 days of becoming a designated operator
2. Mitigate against third-party and supply-chain risks
3. Immediately report cybersecurity incidents related to any CCS
4. Comply with any direction from the Governor in Council with regard to securing CCSs
5. Adhere to new rules regarding the disclosure and use of information

This act applies to designated operators: individuals, partnerships, and unincorporated organizations that belong to at least one of the following classes:

• Telecommunications services
• Interprovincial or international pipeline and power line systems
• Nuclear energy systems
• Transportation systems that are within the legislative authority of Parliament
• Banking systems
• Clearing and settlement systems

Many companies that would become designated operators under this bill are already doing most of the things this bill would enforce. However, if this bill obtains royal assent, a few major changes will take place.

Three major changes to cybersecurity under the CCSPA

If Bill C-26 becomes law as it stands, then we can expect three things to change: incident reporting, supply chain regulations, and the degree of direct control the government will have on enforcing cybersecurity measures.

1. Security incidents will become more transparent 

The CCSPA will require any designated operator to immediately report any security incident that affects a CCS. The procedure and detail of such reports are yet to be determined.

The goal is to tighten the response loop when vulnerabilities and breaches are discovered. By requiring organizations to report incidents immediately, Canadian legislators hope to keep the public and private sectors unified in their responses to cyber threats.

2. Supply-chain security will be regulated

The supply chain has always been an effective way to breach large entities. Just like it’s easier to climb into a wooden horse than it is to directly climb the walls of Troy, it’s easier to breach a small software contributor than it is to directly breach an enterprise application. 

This is why the CCSPA would formally increase security around designated operators’ software supply chains. Under this act, companies who operate critical cyber systems would need to immediately take “reasonable action” as soon as any threat or risk related to their third-party suppliers is discovered—including actions prescribed by regulators.

3. The government will compel companies to take security actions

This act wouldn’t simply change the status quo regarding responses to third-party vulnerabilities—it would also give Governors in Council the authority to direct any single designated operator (or class of designated operators) to take new cybersecurity measures. This may be in response to a known threat, or it may be preemptive.

How to prepare for C-26

If you operate in a vital class designated by C-26, or if you plan to sell software services to organizations that will become designated operators under C-26, it would be wise to start preparing for the CCSPA now. (And even if you don’t sell into these industries, keeping your systems secure is both smart and responsible.)

Talk (and listen) to the regulators

Specific requirements will be determined by regulating authorities, and discussions have already begun. Talk to the regulators who oversee the designated class you do business in—this will be your best source of information.

This is also your chance to bring ideas and concerns to regulators. The rules will depend on how diligent and well-informed the regulators of each sector are when the bill goes into effect—so if there are security measures you’ve found particularly effective, there are threats and vulnerabilities you find especially concerning, or there are proposed cybersecurity measures that could negatively impact other aspects of your business, now is a good time to make those known.

Future designated operators: begin analyzing your vendors’ software.

If you do business in one of the classes C-26 designated, you will need to take reasonable steps to protect your software supply chain from threats. A wise place to start is by asking your vendors for their software bills of materials (SBOMs). This will give you a full view of what code libraries your vendors used to make the software your critical cyber systems rely on.

Beyond obtaining your vendors’ SBOMs, now is a good time to analyze your vendors for vulnerabilities. You can do this easily with a software composition analysis tool like MergeBase, which allows you to analyze other organizations’ code for vulnerabilities, even if you don’t have direct access to that code.

Vendors to future designated operators: prepare your supply chain security documentation.

In order to continue doing business with designated operators, your software supply chain must be compliant with regulatory standards. You can expect your designated-operator clients to begin asking you for your software bill of materials.

This applies to you even if you’re not a Canadian company.

Therefore, you can take three actions to prepare for this bill to go into effect:

1. Assemble your software bill of materials. Compile a list of any third-party code you are using in your product, as well as any other third parties who have access to the code you sell.
2. Ask your suppliers for their software bill of materials. This will help you get a comprehensive view of all the contributors to your final product.
3. Analyze your entire supply chain for vulnerabilities. You can use an advanced software composition analysis tool like MergeBase to find and patch vulnerabilities in your own code as well as your suppliers’ code—and their suppliers’ code too.

Having your house in order will put you in the most prepared position when (or if) the CCSPA goes into effect.

All software companies: expect trickle-up cybersecurity standards to increase.

Even if you don’t do business with a designated operator, there’s a chance that one of your customers or partners does. If this is the case, it’s possible that they will pass their new cybersecurity standards on to their suppliers and partners.

Now is a good time to check if you’re part of a future designated operator’s supply chain. If you are, consider preparing your own SBOM. At the very least, make a plan for what to do if one of your customers or partners begins raising cybersecurity standards for you.

Pro-tip: You can use MergeBase to generate your own SBOM or the SBOM of any other software. Our customers tell us that our reports are more thorough and accurate than most in-house SBOMs—book a demo if you’d like to see how it works!

Mitigate third-party and supply chain risks with a software composition analysis (SCA) platform

Cybersecurity measures will only increase in the future. One way to prepare for legislation like the CCSPA is to implement our advanced SCA platform. 

MergeBase allows you to analyze code for vulnerabilities as it’s being written, and it lets you check for third-party vulnerabilities in both your test environment and your live product. It also gives you the opportunity to automatically patch vulnerabilities in your software supply chain, which keeps you, your customers, and your users more safe from cyber-attacks than they otherwise would be.

If you want to raise your own cybersecurity standards ahead of C-26, schedule a MergeBase demo today. Our team will show you how you can begin protecting yourself from supply-chain risks now.

Introduction

Ant was Java’s original build system. Ant was developed internally at Sun Microsystems around 2000 to help build the original Tomcat JSP server. I vaguely recall learning many years ago that James Duncan Davidson and Jason Hunter (now of JDOM fame) were the main culprits behind Ant. Of course, we’re now in 2022, and Ant has long since been replaced with Maven. But from 2000 to 2010, Ant was very popular. Even today, many projects, especially internal corporate Java projects, still use Ant. Why fix something when it’s not broken, right? Unfortunately, important application security tools for SBOM generation and known-vulnerability scanning currently don’t work with Ant. But MergeBase does!

Scanning Ant-Based Java Projects With MergeBase

Unlike Maven, Ant does not include any built-in dependency resolving and downloading.  With Ant-based projects, developers are their own when it comes to specifying and retrieving important re-usable libraries required to build and deploy their software systems. Because it’s up to developers, there’s a huge mishmash of approaches and traditions across the Ant universe – it’s a total free-for-all! (Maven was designed from the ground-up mainly to solve this pain and chaos).  Nonetheless, there is one constant we can count on:  when Ant is finished building a software system, the end-result will be a deployable runnable Java software artifact, including all of its required libraries.  MergeBase leverages this fact to achieve a reliable “post-build” known-vulnerability SCA scanning solution for Ant projects.

MergeBase uses a powerful signature-based matching algorithm to accurately identify Java dependencies. Unlike binary fingerprints (like SHA-2 or MD5), our matching algorithm is stable in the face of typical library permutations (e.g., cryptographically signed vs. unsigned libraries, compiler variations, and even different timestamps in zip-file metadata). Our matching algorithm is also able to find versions “between” versions – for example if your developer decided to grab a pre-release version of Apache Commons HttpClient 3.0 directly from “trunk” and threw that into your Ant lib directory, MergeBase’s library-identification logic can handle that.

Competing Scanners vs. Ant

Most competing scanners are not able to scan Ant-based Java projects. They exit with error messages like these:

• “Could not detect supported target files”
• “Detected supported file(s) in ‘.’, but there was a problem generating a dep-graph.”
• “No dependencies were identified”

This is because existing commercial scanners probe projects build scripts for dependency coordinates. Of course, MergeBase is happy to operate in this mode as well when it’s available, but we also offer a pure “files-on-disk” mode of scanning. Philosophically, we believe a “files-on-disk” scan mode is critical because that gives you the ground-truth: the actual libraries included in your application’s deployment! Of course, your Maven pom.xml scripts and NPM project.json files and yarn.lock files say useful, interesting things about your system’s dependency graphs, but there’s nothing stopping post-build processes from further adjusting the deployment context by deleting, transforming, copying, or even downloading additional dependencies outside of normal build processes.

Turns out our “files-on-disk” philosophy is also perfect for Ant-based Java projects. When an Ant-based application is finished building, all of its dependencies will be packaged up for deployment. A powerful signature-based scanner like MergeBase can then figure out exactly which Maven-coordinates correspond to each of these files.

Of course, Ant projects don’t use Maven-coordinates, but the industry has now standardised around these (e.g., see: PURLs). Known-vulnerability reports and SBOM exports are expected to refer to Maven-Central dependency coordinates. Fortunately, MergeBase is able to accurately map the random Jar files sitting across various “lib/” directories in an Ant-based Java project back to Maven-coordinates. Thanks to these Maven-coordinates, MergeBase can then determine the known-vulnerabilities in your libraries that you need to be aware of, as well as giving you any SBOM reports (in CycloneDX or SPDX formats) you might also need to comply with current software engineering standards.

Using MergeBase To Scan Ant Projects

In this section, we’ll show you explicitly how you can use MergeBase to scan Ant-based Java projects.

First, make sure your Ant project successfully builds! Once your Ant build completes, you can now run MergeBase. When scanning Ant projects, we recommend using MergeBase’s “–binary” and “–all” flags. This way, even zips inside zips and jars inside wars will be examined.

MergeBase Scan Example:

$ java -jar mergebase.jar --name=myProject --group=myGroup --binary –all <project-dir>

Running recursive binary scan. This could take some time especially if *.dll/*.exe files are detected.
Scanning - completed
Saving application profile (1 kb) to https://demo.mergebase.com

Vulnerable Files Overview
=========================

VIOLATION (2)
-----
CVE-2016-1000343, CVE-2016-1000342, 2 more... libs.zip!/bcprov-ext-jdk15on-151.jar (org.bouncycastle/bcprov-ext-jdk15on@1.51)
CVE-2022-23307, CVE-2022-23305, 4 more... lib.zip!/log4j-1.2.13.jar (log4j/log4j@1.2.13)

WARNING (4)
-----
CVE-2020-26939, CVE-2020-15522, 7 more... libs.zip!/bcprov-ext-jdk15on-151.jar (org.bouncycastle/bcprov-ext-jdk15on@1.51)
CVE-2020-13956, CVE-2012-6153, CVE-2012-5783 libs.zip!/commons-httpclient-3.0.jar (commons-httpclient/commons-httpclient@3.0)
CVE-2020-15250 libs.zip!/junit4-4.11.jar (junit/junit@4.11)
CVE-2020-9488 libs.zip!/log4j-1.2.13.jar (log4j/log4j@1.2.13)

Creating an SBOM Report

Simply add the “–sbom” flag to the “java -jar mergebase.jar” command above. Alternatively, you can also download the SBOM report directly from your MergeBase dashboard. All MergeBase scans are also stored in your MergeBase dashboard to help keep you up-to-date in case any new vulnerabilities are discovered in between scans.

A Quick Scanner Bake-Off

We have put together a small buildable Ant-based Java project for anyone who would like to play with competing scanners. You can download this project here. It’s an old Apache-2.0 licensed Java open-source project I created in 2006!

https://mergebase.com/ssl/not-yet-commons-ssl-0.3.17.zip

To build it, run the following steps:

1. Download it and unzip it.
2. cd ./not-yet-commons-ssl-0.3.17
3. ant clean
4. ant all

Scanning It With MergeBase:

Take a free MergeBase trial, and then download the “mergebase.jar” CLT. Run the following command in the “./not-yet-commons-ssl-0.3.17/” directory (after building it first!):

$ java -jar mergebase.jar –binary –all .

The resulting output is the same as above (24 vulnerabilities found circa September 2022). Of course, that will change as more vulnerabilities are discovered with each passing year!

Snyk?  “There was a problem”

Snyk does not appear able to scan this project:

$ snyk test --scan-all-unmanaged .

Failed to get maven dependency for './not-yet-commons-ssl-0.3.17.jar'. No package found querying 'https://search.maven.org/solrsearch/select' for sha1 hash '4858e51d5290a3640f706ed0c7db8eda5c646899'.
Detected supported file(s) in '.', but there was a problem generating a dep-graph. No Maven artifacts found when searching https://search.maven.org/solrsearch/select

Mend (a.k.a. WhiteSource)?  “No dependencies were identified”

Mend also does not seem to be able to scan this:

$ ws scan –extended .

Initializing:
File system scan is not allowed, only package manager dependencies resolution is performed
Scanning: /opt/automated-benchmark/ssl/not-yet-commons-ssl-0.3.17 [...../]
Retrieving: Security vulnerabilities and compliance information [...../]
No dependencies were identified

Conclusion

Many important Java systems are still built using Ant, but unfortunately, most application security tools are not able to understand and scan such systems.  MergeBase, however, uses a powerful signature-matching algorithm that works wonderfully well with Ant-based Java projects!

p.s.  We published our matching algorithm in a peer-reviewed software engineering journal in 2013 if you would like to implement it yourself (it is not patent protected). Look for “Software Bertillonage, Determining the provenance of software development artifacts” by Davies et al. in Springer’s Journal of Empirical Software Engineering, 2013.  As an author, I’m allowed to send free full-text copies of this journal article to anyone who would like to see it. You can email me at: julius@mergebase.com.

p.p.s. Speaking of provenance, I bet you didn’t know Davies was my maiden name!  😉 

As cybercrime becomes more sophisticated, governments have begun introducing initiatives to hold regulated industries accountable for their data security. This includes initiatives involving third-party liability, where software companies are held responsible for vulnerabilities that come from external sources.

This is an important issue for both software providers and regulated companies using third-party software. Here, you’ll get an overview of what third-party liability is, why it matters, and what you can do to prepare for third-party liability laws.

What is third-party liability in software?

Third-party liability refers to a company’s responsibility to keep their data, and their users’ data secure from any vulnerabilities—including vulnerabilities introduced by code from third parties. 

Most software companies incorporate libraries from third-party sources in their offerings. If one of these third-party libraries becomes vulnerable to cybersecurity threats at any time, the company is still liable for any breaches of their own data.

Key terms to know when discussing third-party liability

If your company is discussing cybersecurity, odds are good that third-party liability will come up. The following terms are often used in conversations about this matter:

Third-party vulnerabilities: these are the specific vulnerabilities introduced by third-party code. 

Software supply chain: this refers to all the elements that go into creating and delivering your software product. This can include hardware, open- and closed-source code, operating systems, consultants, and testing tools. It’s everything that touches your application as it’s being made, and everything that touches those things, and everything that touches those things, and so on.

Software bill of materials (SBOM): this refers to the full list of libraries that make up a software system, including code from vendors and open-source libraries. This terminology is more often used in discussions of cyber security policy and legislation. 

The regulatory gap: how third-party liability became so important

Third-party liability became an important issue due to the extreme regulatory gap between software companies and industries that play an established, essential role in societies’ infrastructure. 

The world came to rely on (unregulated) tech companies

In the 1990s, industries like finance, transportation, energy, and healthcare had already cemented themselves into the infrastructure of society. These industries were vital to the average citizen’s daily life as well as economies as a whole; therefore, governing bodies heavily regulated them. 

This regulation prevented any one regulated company from growing to the point of global scale. (For example, there is no worldwide consumer bank.) This meant that innovations happened on a smaller scale, and regulators were, for the most part, able to keep in step with those innovations.

However, the internet and ubiquitous use of personal computers (and later smartphones and other smart devices) led to increasing global demand for software services. When the tech industry began, software applications were not regulated. Tech companies multiplied and innovated, and the capabilities of software increased exponentially.

In a matter of decades, software applications have become a crucial part of everyday life worldwide. Consumers relied on large tech companies for commerce, navigation, and communication—but so did small and mid-size businesses, enterprise corporations, and even government entities.

Innovation relied on third-party code

As software capabilities expanded, more and more tech companies began building applications on code libraries written by outside sources. This was essential to economic survival. In order to innovate efficiently and competitively, tech companies couldn’t start from scratch. Today, most commercial software applications are built on a mix of proprietary in-house code and third-party libraries—much of which is open-source.

These third-party providers were also unregulated. An ecommerce marketplace in Spain could license a transaction processing system from a US fintech startup, which might include code libraries produced by companies in Mexico, Norway, Singapore, and Germany—or even open-source code with no single identifiable author. (And each contributing company could have built their code on even more third-party libraries.) 

Since none of these companies were regulated, any cyber security standards were either set by the buyers or self-imposed.

This became especially problematic when highly regulated corporations and government entities began using unregulated applications.

Third-party code became an easy target for cybercriminals

A system is only as secure as its weakest component. Breaching an enterprise application is difficult, and malevolent hackers soon realized that it was much easier to breach a large entity’s data by simply targeting code produced by smaller players. Hacking a third-party software supplier created a “back door” to the supplier’s customers, clients, and partners.

This was a known issue in the software community for a long time, but in 2021, it became a matter of national security in the United States.

In 2020, presumed Russian hackers gained access to an IT monitoring system created by SolarWinds. SolarWinds was a third-party supplier to large companies, including Microsoft, Cisco, and Intel, as well as US federal departments, including Homeland Security, State, and Treasury. Through SolarWinds, the hackers gained access to more than 18,000 organizations’ data—and the breach wasn’t discovered until the spring of 2021.

This was not an isolated incident. Third-party software supply chain attacks have been increasing exponentially in the past few years—and it’s leading governments to make laws regarding third-party liability.

Third-party liability in cyber security law

Because of the growing threat of third-party attacks, governments have begun forming policies to hold companies accountable for the security of their applications—including the security of their third-party suppliers.

Third-party liability policy can be thought of as a spectrum across two general approaches, the prescriptive approach and the principled approach.

The prescriptive approach: focus on the rules

Governments taking a prescriptive approach to software supply chain security (like the United States) set compliance standards for key industries. Regulated companies and government entities are required to hold all vendors to a known set of security standards. Procedures are likewise set in place for when these standards are breached.

The advantage of this approach is that both regulated customers and their vendors know if they are compliant and what to do if suddenly they’re not (i.e., they’ve been hacked). This makes it easier for vendors to become compliant and easier for customers to determine which vendors are eligible for consideration.

However, this approach has a major disadvantage: reality moves faster than regulations. The measures a government prescribes can become obsolete, and changing regulatory standards takes time. This lag effect can burden industries with (expensive) outdated compliance standards that don’t actually protect them from threats. 

The principled approach: focus on the results

Governments taking a principled approach (like Germany) instead leave compliance standards up to the software companies—but penalize them heavily for any breaches. Regulated companies and government agencies are held to the standard of perfection: if you’re hacked, it’s because you weren’t secure enough.

The disadvantage with this approach is that there is no clear-cut compliance standard (aside from being unbreachable). This makes it more difficult for regulated customers to source innovative vendors. Likewise, vendors lack clear security standards to meet in order to know if they are eligible, let alone a competitive solution.

On the other hand, this approach has the advantage of incentivising both third-party vendors and regulated entities to innovate at the speed of malevolent hackers. By raising the stakes of failure, principled policies encourage regulated entities to make absolutely sure that their suppliers and their suppliers’ suppliers are secure.

How to prepare for third-party liability laws

As governments begin exploring cyber security policies, software vendors and regulated clients need to invest in tools and practices that will keep them compliant. And even if you’re not operating in a regulated space, protecting yourself (and your users, customers, and partners) from third-party vulnerabilities is a smart idea.

How to prepare as a vendor

If you create software, you need to ensure that both your own code and your third-party code are vulnerability-free. You can do this with a software composition analysis (SCA) solution like MergeBase. An SCA solution analyzes every library that touches your final product and alerts you of any vulnerabilities.

In addition, you should begin the practice of preparing your software bill of materials for every contract. Future contracts in regulated spaces will depend on your ability to provide up-to-date information about where your code comes from, so it’s wise to begin preparing for this now.

How to prepare as a regulated client

If you are in a regulated industry, third-party liability laws will put the onus on you to ensure that your vendors are using proper data security. In order to protect yourself and your stakeholders, you will need to do two things:

1. Obtain a software bill of materials from every vendor. You need to know exactly what code is being used for each contract. This is not always easy to do. Your vendors may not have a one-size-fits-all SBOM for every contract—and they may not have internally prepared their SBOMs for external viewing.
2. Analyze every vendor’s SBOM. In addition to obtaining the vendors’ SBOMs, you need to analyze them for vulnerabilities yourself. (This is especially key if you are operating under laws that take the principled approach discussed earlier.) 

Both of these can be very difficult to do because they involve inspecting another organization’s code. This is why using an advanced SCA suite like MergeBase is a good idea. MergeBase allows you to analyze anyone’s SBOM for vulnerabilities, even if you do not have direct access to their code. (You can even use MergeBase to verify the SBOMs your vendors give you—we have a reputation for generating SBOMs that are even more thorough and accurate than those a vendor creates in-house.)

It’s a reliable way to know exactly how secure a vendor is.

Don’t let third-party liability catch you off guard

Third-party liability laws are coming, and whether you’re a software producer or customer, the best thing to do now is prepared. MergeBase gives you the ability to find vulnerabilities in your own code as well as code from suppliers and vendors—which helps protect you from third-party liabilities.

If you want to prepare for third-party liability laws, we would love to show you how MergeBase can help. Book a demo with us today and see how you can protect yourself, your code, and your customers.

How paranoid about application security is enough?

I was asked to secure my company’s software application at a previous job. I dutifully headed off to do some online research. Five hours of googling later, I realized that the concept of an “application secure” was in fact, ephemeral. A growing unease started to grow inside me. Is anything, anywhere safe?

Am I the only one that feels this way? Am I going crazy? I dig even deeper down the rabbit hole. Apparently, psychology has been studying this phenomenon for the past few decades, and while a small corner of my mind feels relieved to find out that I am not alone, another louder part of my mind worries about the fact that psychology is looking at it… is it really that prevalent? 

One quote in a Frontiers paper sticks in my craw: “On balance, the weight of the evidence points to an excessive level of fear regarding information technology within society, in that the level of fear seems to be out of proportion to the actual risks.” This can’t be true, every month brings out reports of more vulnerabilities, more data breaches, more people getting defrauded, of more people getting their identities stolen.

Not so confident of academia’s understanding of the ‘real’ world, I do a quick Google search using the words “security” &  “paranoia”. Immediately I find my feelings echoed on Reddit with the following post*: “So is it just me or the more you learn about cyber security, the more paranoid you are about every little action you do?” The answer provided does not make me feel better: “You learn how to accept risk. The only completely secure computer is powered off at the bottom of a line shaft broken into inoperable pieces.”

So, which is it? Are my “fears out of proportion”, or is security only achievable at the bottom of an abandoned mining shaft?

Is anything, anywhere safe?

Only a small portion of a single course (of 40 total!) from my Computer Science degree actually addressed security in a formal way. It was in this course, Computer Networking, where I met Alice & Bob innocently trying to communicate unaware of the villainous Charlie sneaking around in the middle hacking into their messages. 

There I learned how to use WireShark and started sniffing packets at the local coffee shop. This sharpened my desire to pay attention in class and I diligently studied the “known knowns” of the industry, cognitively arming myself to move around with more environmental awareness in the digital space. 

I started checking for security vulnerabilities on my own sensitive applications with 2FA (2-factor authentication) and preach this as the way to all I know because it is surely infallible. Right? Wrong. 

I read that the 2FA SMS and OTP implementations such as Google Authenticator are often breached* by middling Charlie, and my security blanket once again becomes damp. (FIDO implementations such as Yubikeys are not vulnerable to this).

My research reveals that it is impossible to really anticipate all of the attack vectors, all of the potentially penetrable planes of any process. The monitoring systems that I had once trusted to keep my company’s system safe all of a sudden become the opposite of that*. Facebook Careers can be hacked using Word documents*.  Even harmless wee CSS becomes an affordance upon which one can inject malicious js scripts*.

What really feeds my anxiety beast, though, is the fact that there are still so many dangers lurking in the shadows that I haven’t even conceived of yet. The SolarWinds attack was so effective because internal build processes behind firewalls were presumed safe. Very few ever imagined CSS could be a target either. 

As a digital nomad, it reminds me of when I land in a new city, when I am still unaware of the “bad” areas, of its particular flavour of crime. Are pickpockets rampant here; are the kebabs actually chicken? I remember that time a random woman threw a cat at me, and how her kid ran off with my bag as I was shaking it off. I had never really anticipated getting ripped off in that particular way; had never conceived of it being something to be careful of.

What gave me hope, the only spark of light in all of this darkness was the fact that my boss had decided to take security seriously. She had convinced the money people that even though the process of securing a system can be both time & money-consuming in the short run, it ends up being both time & cost-reducing in the long run. She explained how with practice we could learn to anticipate obvious attacks and with creativity, we could start anticipating some not-so-obvious attacks.

What did I do after I embraced my paranoia and decided to build secure applications?

I came across Jack Rhysider’s list of 20 things he learned as a network security engineer. Reading it I see a pattern of measured precautions, little building blocks to feel prepared, to involve a team, to stay on top of matters without panicking. 

I learn that I am not alone in my world of AppSec worries and that this space is rich with interesting, knowledgeable, and appropriately paranoid people. Spend any time trawling through Reddit, lurking within Twitter, and you will find people who are already on the ground running.

Poking my head out of the rabbit hole, I decide once and for all to embrace my paranoia, to make it work for me. I figure that the only way to win this battle, to create a proper offensive, is to think about it as much as attackers do and that my (un-panicked) paranoia will help me do exactly that.

Want to keep your application secure?

Start a free trial today and find out what we can do to help you to assuage your paranoia.

The log4j vulnerability was announced on December 10, 2021, and ranks as one of the worst in history. How to secure log4j? The best resolution is to upgrade to a secure version. However, sometimes that is not possible, or at least it takes time. In these scenarios, runtime protection for log4j or other vulnerabilities can be a lifesaver.

In organizations that have hundreds or thousands of applications, it can take days or even weeks of an all-out effort to upgrade these applications. Or it could be that the vulnerable applications are supplied by a vendor, and the vendor does not have a fix immediately available. The runtime protection can be applied with a few clicks of a mouse and save you a lot of time. This video below walks you through how that works.

How to secure log4j instantly at runtime?

In this video, Julius Musseau and Delan Elliott show how:

• How to access a vulnerable library can be controlled
• Either for the full library or surgically for just the method(s) that is at the root of the vulnerability.
• This enables the organization to respond instantly to new vulnerabilities.
• It applies to vulnerabilities such as CVE-2021-44228, and CVE-2021-45046
• But can be applied to any Java-based vulnerability.

If you are looking to secure log4j or other libraries, contact us, or try out MergeBase for free.