Keeping up with the Standards

hard on cold steel facts

In some ways security is really hard. Ever-evolving threat scenarios arise accompanied by new attacks regularly.

But in other ways, security really isn't that hard.

Caroline recently mentioned some corporate slogan which stated it was "made for laws not for standards." I'm sure there are multiple interpretations of that statement, but from my perspective, who cares about the laws, just give me the standards.

If the laws contradict the standards, I'll opt for the higher bar, which is probably the standard when it comes to security.

More broadly from another angle, laws aren't going to protect against any adversary that flouts legality. And find me an adversary that follows laws, and I'll point out a fool.

What exactly are standards? In the most basic sense, standards are agreed upon protocols and practices. Certain standards guide technology decision making, or at least they should.

Standards are also about doing the basics correctly. When we’ve discussed the “why another massive data breach?” question on some vCISO panels, it often comes back to companies not doing the basics correctly.

Stop thinking about fantasical non-existent solutions, and get back to basics.

Many standards organizations are likely familiar to readers of this blog. NIST (National Institute of Standards and Technology) and ISO (International Organization for Standardization) are two, then there are other like the IETF (Internet Engineering Task Force) and there's POSIX, which is the OpenGroup's Unix standards. Not to mention the IANA, W3C. . . but I’ll stop there.

Some standards are supposed to create more secure and efficient systems which allow the heterogeneity of the world to interoperate. How can an email from one person using one email server transmit email to another email server and ultimately another person? Quite simply, standards provide the parameters.

If there was no agreement on how these disparate systems talk to each other, email couldn't be read or delivered.

Needless to say, all is not perfect in standards land. There are contradictory standards. And like standards in any industry or field, standards tend to be distorted by corporate rivalries and shenanigans.

Any reader out there old enough to remember Microsoft proposing ActiveX as an IETF standard?

But if standards can be messy, to misparaphrase Albert Einstein, they remain the most precious thing we have.

The IETF's Requests for Comments is the basis for internet standards. They have defined things like email communications with SMTP in RFC878, and how an email program talks to an email server with IMAP.

Want to know why your local IP address is a 192.168.X.X address at home and on the coffee shop's wifi? And, for a more historical reference, even in that place we once called "the office"? It's because RFC1918 declares that those IP addresses, along with 10.X.X.X and 172.16.X.X addresses, are designated for private networks not on the public internet.

One of the other problems with standards is they are often ignored by people who really should know better. I appreciate most people don't read RFCs, but most people in technology really should.

The clearest case in point is RFC8996.

Ever notice security questionnaires asking about "encryption in transit"? Then RFC8996 is a great place to start.

Never touched a security questionnaire? Fine. But if by remote chance you visited a web site in the past year or two, you might have noticed a little lock in the URL bar indicating that a site provide HTTPS access. There's RFC2818 behind that little lock, among many other RFCs.

But a lot of "encryption in transit" seems to miss the basic directives of RFC8996, and the dozens of previous RFCs that it forms the windy route from previous relevant standards.

Consider web sites and HTTPS. Behind HTTPS relies on a protocol called TLS, formerly known as SSL.

It's a bad idea to allow old protocols to encrypt HTTPS communications with TLSv1 and TLSv1.1. No, it's usually an outright idiotic idea. Those are protocols that should be eliminated from usage for any "encryption in transit" purposes. Only TLSv1.2 and TLS1.3 should be used as RFC8996 makes explicitly clear.

Yet it's not hard to find sites that still allow those deprecated versions of TLS.

Some might justify continuing to support older versions of TLS to allow ancient Android and Windows systems to access a web site or other internet service.

Well, that's the reasoning, at least. If web site clients are logging into the site, or downloading anything though, it’s not a bright idea.

What's really outright scary is the number of firms in privacy and security that continue to support these dead protocols.

Most humorously, the main TLS/SSL implementation is OpenSSL, which has a web site at OpenSSL.org.

At ClearOPS we track TLS versions enabled by internet domains, and through the Service Provider Reports on December 13, 2021, OpenSSL.org allowed TLSv1 through TLSv1.2. That means two ancient versions of TLS (v1 and v1.1) were still enabled, and the most current version TLSv1.3 wasn't supported. Fortunately, OpenSSL.org finally joined the modern era and only allows TLSv1.2 and TLSv1.3.

Certainly, if anyone has the pixie dust to continue running those old protocols safely, one might argue it's probably the OpenSSL project. But looking at their security track record, it's hard to swallow that pill.

The conclusion from the webinars remains. Doing the basics right, as directed by standards, is the most important first step in mitigating past attacks in addition to preempting the unknown future ones.

Of course, "doing things right" as per standards is sometimes made harder by service providers like web hosting companies, but that's another story for another blog post.

About the author: George is a co-founder and CTO of ClearOPS. By trade, George is a systems administrator out of BSD Unix land, with long-time involvement in privacy-enhancing technologies. By nature, he thrives on creating unorthodox solutions to ordinary problems.

About ClearOPS: Do you have clients that ask you to respond to their security questionnaires? Are you thinking about a SOC2 to get rid of them? A SOC2 takes 6 months so what are you going to do in the meantime? You are going to use ClearOPS. ClearOPS now offers hosted security pages. Providing you with even more proof for your customers that you “take their privacy and security seriously.” Inquiries: [email protected]