This month’s roundup discusses two cases hinting at likely trends that government agencies will face when it comes to cyberattacks. As a company that aims to protect governments and private organizations from cyberattacks, we have provided links to full articles that discuss the products and services we offer that beef up any organization’s cybersecurity. Lastly, we also discuss two service updates that we offer to our clients. Read on!
New Mexico county becomes first local government ransomware victim this January
Last January 5, Bernalillo County, the largest county in New Mexico, was forced to shut down most of its government buildings in response to a ransomware attack.
Many of the county government’s computer systems were disconnected from the internet in order to protect records and other sensitive files. Also offline were the county’s websites.
By January 14, residents continued to receive non-service when it came to processing real estate transactions, voter registration, or marriage licenses.
According to a news report, “the County also filed an emergency notice in federal court that it was unable to comply with terms of a settlement involving conditions at the County jail because the ransomware attack knocked out access to the jail’s security cameras.” The failure to meet the terms put the jail facility in a lockdown status and greatly reduced certain privileges of the inmates including free time spent outside and telephone access.
The cyber attack also affected court systems forcing the employees to work out back up plans that could temporarily enable criminal proceedings.
As of the end of January, Bernalillo has still not fully recovered from this incident.
Unless government agencies take serious steps to improve their cybersecurity, they will continue to be at risk of debilitating attacks. In 2020, 113 ransomware attacks were known to have been executed against local governments. In 2021, 76 municipalities also admitted to having received the same attack.
SSL.com’s Takeaway: Government agencies will continue to be a target by cybercriminals this 2022. If you are part of a government agency, the best method for protecting your website, data, and transactions is to acquire tried and tested PKI services from professionals. Head over to this article to read how we help governments strengthen their cybersecurity through PKI.
Department of Defense called upon to secure their Internet of Battlefield Things (IOBT)
The Department of Defense (DOD) has been continually developing what is referred to as the “Internet of Battlefield Things” (IOBT). These are networks of a wide array of military equipment that are linked to smart technology. These include battlefield sensors, radios, and weapons.
While IOBT increases the military’s capabilities, it also predisposes them to a lot of cybersecurity issues. As more internet-connected devices are added to the IOBT, the entry points for hackers to compromise the network also increases. When classified information and technologies are stolen by hackers, this can be a life or death situation. For instance, in 2018, it was revealed that fitness trackers worn by military personnel could be penetrated and leak the movement of troops wearing them.
The Department of Defense responded to the increasing concern with IOBT by creating the Comply to Connect (C2C) system. As explained by Daniel Goure of think tank Lexington Institute, C2C includes four functions, which are: “1) identifying and validating new devices that are connected to a network; 2) evaluating their compliance with DoD security policies; 3) conducting continuous monitoring of these devices, and; 4) automatically addressing device issues, thereby reducing the need for maintaining cyber hygiene on cybersecurity administrators.”
Apparently, DoD has been twice mandated by the U.S. Congress to strongly implement C2C. So far, only the U.S. Navy, U.S. Marine Corps, and several DoD elements have complied with the order, with most of the department’s sub-branches lagging behind.
The continuous growth in Public Key Infrastructure (PKI) technology in the private sector presents an urgent opportunity for DoD to partner with industry experts when it comes to securing their IOBT. This partnership will enable the DoD to safely perform its duties while being able to adapt to evolving military needs.
SSL.com’s Takeaway: SSL.com is an ally of the government when it comes to cybersecurity. Read this article to find out how we help government agencies protect their IoT systems through Public Key Infrastructure (PKI) technology.
SSL.com announces support for TLS Delegated Credentials
We at SSL.com are announcing that we support the use of delegated credentials for all clients. Issuance of delegated credential capable certificates can be done through the use of APIs for automation using the ACME protocol. Since SSL.com utilizes ECDSA to implement the PKI offered to clients, delegated credentials issued by our clients are not vulnerable to signature forgery attacks.
Delegated Credentials are digitally signed data structures consisting of two parts: a validity interval and a public key (along with its associated signature algorithm). They serve as a “power of attorney” for the servers indicating that they are authorized to terminate the TLS connection.
Delegated Credentials are designed with the purpose of increasing security. Hence, they possess certain traits, as defined in the IEFT draft. These traits include the following:
- The maximum validity period of a delegated credential is seven (7) days to minimize the exposure if the private key is compromised.
- The delegated credentials are cryptographically bound to the end-entity certificate. Specifically, the private key of the end-entity certificate is used to compute the signature of the DC via an algorithm specified by the credential.
- Delegated credentials are issued by the client, which is much easier than creating a certificate signed by a CA. Client-issued certificates are also helpful in keeping the service working even if the CA has a downtime.
- Delegated credentials have short periods of validity by definition. When setting the lifetime of delegated credentials, servers need to take under consideration the client clock skew to avoid the rejection of certificates.
- There is no revocation mechanism for delegated credentials. They are rendered invalid once the validity period expires.
- Delegated credentials are designed to be used in TLS 1.3 or later. There is a known vulnerability when TLS 1.2 servers support RSA key exchange, allowing the forging of an RSA signature over an arbitrary message.
- Organizations can use existing automated issuance APIs like ACME for delivering delegated credentials.
- Delegated credentials cannot be re-used in multiple contexts.
Read more on the topic of TLS delegated credentials by clicking this link to our full article.
SSL.com fully launches eSigner CKA
This January, SSL.com has released eSigner CKA – a Microsoft Crypto Next Generation (CNG) plugin that allows Windows tools such certutil.exe and signtool.exe to use the eSigner CSC for code signing operations. There are five identified advantages for software developers and publishers when using eSigner CKA.
- Acts like a virtual USB token – Only digital certificates that are trusted by Windows show up on the Certificate Store. Because eSigner CKA is a program developed by SSL.com (a PKI company recognized by Windows as a Certificate Authority), trust is also provided to it because it is able to successfully load the EVCS certificate on the User Certificate Store without any issues.
- Can be used directly on Windows SignTool – EV Code signing with eSigner CKA is so convenient that you literally just have to open up SignTool and input the command line. If you’re more comfortable with receiving one-time passwords on your mobile phone and using an authenticator app, you can choose manual mode. If you want to sign code to your software at a faster pace but still receive the same high level of security and if you want to be in control of your private key for signing, you can opt for automated mode.
- Simple and Clean User Interface – eSigner CKA’s user-friendly platform saves software companies a lot of precious time and allows them to focus on actual development work. Install the program, select your signing mode, input your login credentials, and sign your code. All these steps are laid out for you on straightforward window screens. Quick installation and even quicker execution.
- No Lost Tokens – eSigner CKA solves the limitation with using physical tokens in signing code. With this program, you don’t need separate USB tokens to successfully perform EVCS. eSigner CKA is itself the “token”. Once you have installed it, you just have to fetch your EV Code Signing certificate from the Certificate store and you’re good to sign. This means that you don’t have to worry about misplacing your hardware token or getting locked out because of forgetting your password and consuming your remaining token password retries.
- Supports EV code signing in CI/CD environments – eSigner CKA can be used remotely at any place, any time. This program enhances the security of the DevOps pipeline by ensuring that the software components being shared by engineers, who are working at different schedules and locations, are authenticated with an SSL.com EVCS certificate. Hackers are therefore prevented from compromising your software build process because a malicious file that they attempt to inject will be identified as not having been securely signed.
Download eSigner CKA by clicking here: eSigner CKA (Cloud Key Adapter)
Get your SSL.com EVCS certificates here.
And click this guide on how to install and use eSigner CKA.
