Any enterprise that is connected to the internet (so, all of them) is at any given time either the direct target of a cyberattacker or at least perpetually in danger of becoming an inadvertent casualty of the dangerous environment in which we operate.
Right now, either someone has identified your firm and your weak spots and begun a campaign of targeted phishing attacks, scam links, or credential harvesting, or they are blindly trying to use any number of known vulnerabilities on the web to crack into remote access and web properties.
This week I was reminded of this by two events: my annual review of cyber insurance renewals and security processes as well as the discovery of several unusual traces that signified attempts to log into web properties that I maintain.
Reviewing my compliance with cyber insurance policies was a great exercise in self-assessing just how thorough my base security is, but it also revealed an important fact: that insurance requirements only scratch the surface of the types of discussions you should be having internally regarding your risks of attack.
No matter if you feel you are merely at risk of being accidental roadkill on the information superhighway or are actually in the crosshairs of a malicious attacker, always review the risks not only with your cyber insurance carrier in mind, but also with what the attackers are planning. The two may not be in alignment.
Evidence showed attackers were going after access
Having a website that is unconnected from your business means that you can use it as a honeypot to keep a gauge of what attackers are going after and what they might be getting up to within a network.
Depending on your business and security teams, they may even want to run a honeypot that is designed to trick and trap attackers trying to get into your business. Review the log files on these types of web servers, and you will soon see that attackers are going after the very thing that my cyber insurance carriers were also interested in: my remote access.
The attackers were looking for vulnerable VPN entrances to a web server by attempting to log into a Cisco VPN appliance. Upon examining the web server logs, we found approximately 320,000 requests to a non-existent page looking specifically for the webpage of domain.com/+CSCOE+/logon.html.
For those of you unfamiliar with the CSCOE alias, it’s a CISCO hardware appliance that can be deployed in either a dedicated firewall or IPS mode. In this case, it’s a web service for a VPN that users can go to https://<hostname>/+CSCOE+/logon.html#form_title_text and log in to get the client.
In October of 2024, CISCO announced a vulnerability in the Remote Access VPN feature of the Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the device to reload unexpectedly, resulting in a denial of service (DoS) condition on an affected device. There are no workarounds or mitigations, only patches that need to be installed.
During the annual renewal of cyber insurance, the insurance carrier would not even consider insuring my business if we did not demonstrate that we had some fundamental protections in place. Based on the questions and bullet points, you could tell they saw the remote access, third-party vendor access, and network administrator accounts as weak points that needed additional protection.
MFA is a requirement most insurers insist upon
For example, they mandated that all remote access, including VPN access and all remote monitoring and management (RMM) solutions, such as remote desktop protocol (RDP), be protected by multifactor authentication (MFA), mandating that it should also be enforced on email access and any remote access to critical resources, including third-party and vendor access.
They also required that I implement MFA authentication protection on all network administrator accounts and any other user accounts with elevated permissions within your network.
They wanted me to enable an endpoint detection and response (EDR) solution on all endpoints so that all detected endpoint activity is monitored 24 hours a day, 7 days a week, and 365 days of the year.
Is MFA and EDR enough? How about password managers and zero trust?
However, I think they missed some things when it comes to remote access and multifactor mandates. For example, one that I think should be a mandate is a password manager program that enforces longer passwords and passphrases.
But I wouldn’t stop with merely mandating a password manager program. For anyone who has network administrator rights, there should be an additional biometric or similar process that protects not only the administrator login of the password manager software but all cloud portals that control Azure, Google, or Amazon Web services — key cloud services.
Nor did the insurers mention best practices such as zero-trust network access or other processes that network administrators should be using when they remote in to a network or administer a network.
While training on phishing attacks was also recommended, broader training regarding the use of remote access and the sensitivity of sending data through the internet was not discussed. I was also surprised to see no mention of the use of artificial Intelligence and no questions about any policies I might have regarding the use of such techniques.
Many risks aren’t required to be addressed by insurers
Often these cyber insurance policies recommend that there are enterprise policies and processes in place to ensure that operating system updates are installed in a timely manner following recommendations from industry agencies such as CISA and others, but they don’t address other sources of patching risks in a firm.
For example, I found no mention of having processes of controlling patching for appliances, internet of things devices or other hardware that might need software updates or bios updates in order to maintain a secure posture.
Multifactor authentication isn’t without it’s own risks and vulnerabilities. Attackers are using techniques such as phishing, vishing, and smishing to trick users into divulging their MFA codes.
Phishing uses social engineering to trick victims into paying money, handing over sensitive information, or downloading malware. Smishing (SMS phishing) involves sending malicious text messages and tricking the user into approving an authentication prompt. Through vishing (voice phishing), scammers impersonate professionals such as help desk technicians over the phone to trick them into revealing sensitive data or transferring money.
The risks of endpoint compromise should never be overlooked as attackers can enter a system with malware and steal session cookies or create shadow sessions. In addition, you could accidentally lock someone out if connectivity is impacted or the user loses access to an MFA device, such as a cellphone or a hardware token. Training users on how to properly use MFA, as well as planning ahead for those times when you have problems using MFA, should be part of any firm’s long-term security planning process.
No Responses