Detect Email Security Vulnerability with Registered Encryption™

Log4j and Security (In)Visibility

In the IT security world, there’ve been a lot of sleepless nights recently due to a newly discovered security vulnerability that lets attackers who are not even very technically sophisticated, remotely inject code on a computer and take over control of it. This is due to a mishap in a very popular Apache Java program logging component, now nicknamed “Log4j” (techies can read more here).

The good news for RMail and RSign customers is, neither the RMail nor the RSign platforms (nor the RMail or RSign apps) use this Apache program, so you do not have exposure to Log4j risks simply by use of these RSign eSign and RMail e-security services. But, since the Director of the US Cybersecurity and Infrastructure Security Agency (CISA) Jen Easterly reportedly has called this vulnerability, “…one of the most serious I’ve seen in my entire career, if not the most serious,” we think you ought to ensure your other systems are not exposed.

Perhaps a bigger trend as the world’s systems quietly become more interconnected, is one’s need to trust the security across their tech environment; even though today they have less visibility into these systems’ security or insecurity.

In the case of Log4j, they (the security experts of the world) call this a “zero-day” exploit…the worst. Meaning, this issue has been around for a while, no doubt known by some nefarious cyber-czars, without any visibility to the rest of us. This is an example of Security (In)Visibility. Meaning, it is very challenging to have security visibility into all of the plumbing of all of one’s interconnected systems.

Our Tech Essentials researchers at RPost have discovered other examples of Security (In)Visibility, related to email. We’ve discovered that many mainstream email service providers purport to always transmit messages securely – by TLS for example – but through deep analysis, our research center has seen typically 15% of these supposed secure messages actually being transmitted in plain text.

To create more Security (In)Visibility for common business email users, RPost has released a new capability within its RMail encryption service called Registered Encryption™. Simply put, this makes the level of encryption or fact of non-encryption elegantly easy to see for end users and their IT staff, so that they can make real-time adjustments (if needed) before it’s too late.

The Registered Encryption™ service (click to re-live product webinar) provides the sender visibility around whether a sent email was in fact delivered encrypted from the sender’s desktop to the recipient’s inbox—similar to the RMail Registered Receipt™ worldwide standard for email delivery proof, but now one additionally receives certified proof of fact of encryption, a report of the acceptability of the level of encryption, or truth of actual non-encryption. Registered Encryption™ will not only show you that your message got to the receiver encrypted, but also that it traveled the whole way encrypted (or not).

(Click here to re-live the webinar for the RMail December 16 Webinar to See Registered Encryption™ in Action)

Security (In)Visibility is what some security consultants and regulators have been advocating for some time. Most tech companies now post a “vulnerability disclosure program” to encourage white-glove hacker-types to make security issues visible before they become a problem. In a similar manner, the Registered Encryption™ service provides early warnings of a potential email security vulnerability. The GDPR Euro-regulators even built into the regulations the notion of “proof” or private transmission.

“While we all like to believe email systems work like magic and never fail, this Registered Encryption service is the first time we’re able to visually confirm important messages were transmitted with acceptable levels of security for the situation — and for those regulated by GDPR, it provides the ultimate in audit-ready privacy compliance records like no other,” states Volker Sommerfeld, product director at Frama Communications. “This is spot-on what must have been envisioned when GDPR was drafted,” adds Sommerfeld. GDPR Article 5 Clause 1(f) and 2, and Article 32 Clause 1(a) and 1(d) focus on the requirement to protect personal data during transmission with the ability to demonstrate fact of protection of personal data.

Find More:

Email Encryption

Encrypted Email

Secure Email Services

Secure Large File Transfer

The Registered Encryption™ service can record whether an email that was sent has remained at an acceptable or best level of encryption from the sender’s desktop through to and while inside the recipient’s inbox while the message is at rest; and can prove if needed – with an auditable and authenticatable record – that the sender did transmit specific content in their message end-to-end encrypted.

“This takes the mystique out of encryption and makes it very tangible – for those in insurance, it provides welcome compliance assurance, confidence, and peace-of-mind for business and IT operators,” adds Frank Sentner, CEO of Sentwood Consulting and longtime ACORD insurance tech expert.

You might also like