SANS Difference Makers Awards; Holiday Hack Challenge; SEC Breach Notification Clarification; Google Chrome Phasing Out Third-Party Cookies

The requirement is disclosure which focuses on the material impacts of a material cybersecurity incident without revealing weaknesses or trade secrets. The four-day reporting window was selected to be consistent with other 8-K reporting requirements and is intended to allow a business time to determine materiality of an incident. The blog lays out other options you have, including peer notification, delay options and interaction with DOJ.

As we see more focus by governments and regulators on cybersecurity, we will see greater focus being placed on those in regulated industries responsible for cybersecurity. This I believe will be a long overdue catalyst that makes the cybersecurity profession more accountable and will lead to the professionalization of security roles similar to that in other business fields and for senior officers in organizations. Professionalizing cybersecurity roles will not only result in individuals having greater responsibility and accountability, but should also put in place structures to allow for better training and professional insurance for those taking on senior cybersecurity roles.

Now that the rules are in effect, only time will tell whether the changes have the desired cybersecurity effect envisioned for the industry. Disclosing cybersecurity incidents in a timely manner is the responsible thing to do. The rationale for settling on four days to notify, after determining materiality, is compelling. Further the rationale for requiring an annual cybersecurity risk management disclosure is also reasonable. I, for one, believe the SEC got it about right.

Only experience and precedent will really "clarify" this rule; err on the safe side. However, the "materiality" part of the rule is not new.

Since Google has such a large share of both the browser market and online ad revenue (big reasons why Google has taken so long compared to Apple Safari and Mozilla Firefox to make this move), anything it does in the name of privacy has to looked at closely for any competitive issues it might cause. Consumers are voting for better control over their privacy in their usage and buying patterns – market forces don’t work quickly but they are at work here.

The privacy sandbox initiative has been years in the making and should be welcomed by users as a means to protect their right to privacy. The phased approach, starting with only one percent of chrome users provides a sufficient sample from which to adjust in later phases of the initiative. The change is long overdue.

The EU’s ePrivacy Directive (due to be replaced by the EU ePrivacy Regulations, and the EU’s General Data Protection Regulation (GDPR) have shone a bright light on how companies hoover up as much personal data about us when visiting their websites as they can. It is welcoming to see Google taking a technically focused step in protecting the privacy rights of individuals.

This is part of Google's overall project to enhance user privacy online. Users participating in Google's new tracking protection will be selected randomly. If selected, you'll get a pop-up letting you know. If a site doesn't work without those third-party cookies and Chrome detects you're having trouble with a site (e.g. multiple reloads) you'll be prompted to temporarily re-enable the cookies for that site. There is also an option to re-enable third-party cookies for a site by clicking on the eye-icon.

Let’s see how long it takes for someone to figure out how to circumvent these protections. I will not say this isn’t a good thing, but there always seems to be some workaround. For example, to support first-party and third-party cookies, there is a new option in the Set-Cookie header for CHIPS. Could this be used? Let’s see where this goes.

The time is long past for the government to be “urging” this. As the CISA alert itself highlights “the guidance for vendors to use alternatives to default passwords is not new. CISA and others in the cybersecurity community have been issuing similar warnings for years, but the harm imposed on customers continues.” Procurement guidance should be issued that all software and firmware procurements include a clause requiring no hard coded passwords are incorporated in the box.

This is a decade old problem. I don't think yet another government agency decreeing to stop doing so will make a significant impact, unless they have the authority to prevent government agencies from purchasing these product. But on the other hand, any ban on vendors using default passwords would likely stop most IT purchases.

While a nice thought, the only way vendors will make this change is if they have to. Most likely we will have to look to the EU to make security features like this standard through regulation.

While we've been pushing suppliers for decades to cease using default and hard-coded passwords, it’s not clear if CISA carries sufficient weight to move the bar; what is really needed is directives to disallow procurement of software and hardware with hard-coded credentials, so that any provided credentials can be changed.

Stop using default passwords? This is something that many manufacturers seem to struggle with. The next step will be “stop using generators of default passwords that can guess what the randomly created default password is…” One step at a time, right?

The alert serves as a good reminder to vendors that manufacturing processes need to change with changes in adversary tactics, techniques, and procedures (TTPs). In this case, default passwords shipped with the product. Software exists today that requires users to create a password as part of the set-up process; integrate that into your manufacturing process.

Not only was his account not disabled in a timely fashion, but he was hired at another school in a similar role prior to the discovery of his actions. The court is requiring him to disclose his guilty plea to his current employer. Make sure that you are disabling accounts immediately for terminated or separated employees. You may have to do some footwork to ensure you're inserted properly in the termination workflow. Consider locking accounts for those on extended leave to prevent abuse.

Another example of HR and IT staffs not coordinating in advance of an employee’s termination. Ideally, the IT department locks out the employee account within minutes of formal notification of termination.

Controls are a thing, but only a few systems support a 2-party requirement for destructive actions. These stories (this being the second this year easily) would help that concept out.

If we can get them off the payroll, and we always manage that, we need to be able to withdraw their other privileges.

The Play group leverages valid accounts and weaknesses in FortiOS (CVE-2018-13379 and CVE-2020-12812), Microsoft Exchange (CVE-2022-41040 and CVE-2022-41082 - ProxyNotShell) as well as public facing services such as VPN and RDP. What jumps out here is that they are leveraging old unpatched weaknesses as well as single-factor authentication. Where you have to have passwords, make sure that you're using long strong passwords, turn off password hints, and prevent reuse. Better still, make sure that you require MFA on all external facing services. Lastly, make sure that you're not only keeping all externally facing services rigorously updated, but also that you don't have any unexpected or unauthorized services which could provide access to your network.

As in healthcare when it comes to ransomware, “prevention is better than the cure.” I strongly recommend you read this advisory and implement the recommendations within it.

MongoDB’s handling of and communication around this incident has been first rate, great example to follow: Particularly this line after they said it looked like they had fallen prey to a phishing attack. “In regards to our previous guidance, here are instructions on how to enable phishing-resistant MFA on MongoDB’s native cloud authentication service:” https://www.mongodb.com/docs/atlas/security-multi-factor-authentication/

The disclosure message is somewhat confusing. The threat actors obtained access to some of their corporate systems, not the MongoDB environment as a result of a successful phishing attack. The attackers leveraged the Mullvad VPN to obfuscate their originating addresses. Even so, MongoDB is offering the IOC's for others to examine for malicious activity. Additionally, they are suggesting you implement phishing resistant MFA for the Mongo Cloud authentication service or switch to your IDP for federated authentication.

If you don't need the SQL database integration, disable it. If you do need it, apply the hotfix and make sure you've got a WAF in front of your environment. The fix, in essence, is to use parametrized SQL queries to avoid SQL injection. They further suggest using a modern secure web API rather than using direct SQL queries.

Another time this year 3CX is in the news. This time, however, it's not a supply chain attack. It's just a vulnerability. Still waiting to find out how this impacts customers. I hope these systems are not readily connectable to the standard data network, but more often than not, they are.

This breach is specific to Delta Dental of California which learned of a compromise on June 1st and determined within five days their data had been accessed/stolen from May 27-30th. A lengthier investigation to determine the exact impact completed November 27th, which resulted in the identification of the larger set of affected users. Delta Dental of California is offering 24 months of credit monitoring and identity theft protection to impacted patients and now has the dubious title of having the third largest MOVEit data breach.

While reporting late, Delta Dental was breached early, before many of us had even heard of the MOVEit vulnerability. The lesson for the rest of us must be obvious: security professionals, be certain that you have warned an executive with authority to fix this vulnerability and that you have documented that warning.