top of page

This month the S.D.N.Y. dismissed much of the SEC's fraud suit against the software developer SolarWinds Corp. The SAML certificate [which exchanges authentication and authorization data between parties] for SolarWinds' information technology infrastructure platform, Orion, was compromised and malicious actors were able to gain access to the networks of government agencies that used Orion.


The SEC had alleged that SolarWinds failed to disclose information about the SUNBURST cyberattack in 2020 quickly enough. In his decision, Op. & Order, SEC v. SolarWinds Corp., No. 1:23-cv-09518-PAE (S.D.N.Y. July 18, 2024), ECF No. 125, Judge Paul Engelmayer, sustained a claim of fraud based on the SolarWinds Security Statement, but dismissed claims of fraud based on other filings.


In discussing whether or not cybersecurity risk disclosures made in a SolarWinds' SEC filings about its Orion platform used for IT infrastructure were adequate, the Court considered whether or not two previous incidents in which attacks allowed its platform to contact unauthorized external websites meant that it had been subject to a systematic attack. The two incidents were different in that in one Orion was exploited to send data about the network it was installed on, and in the other Orion was used to download malware. Because SolarWinds could not find the root cause of the attacks, and could not be certain that they were associated with one another, it was not required to update its cybersecurity risk disclosure.


To the extent the SEC, in terming the disclosure generic, means to fault Solar Winds for not spelling out these risks in greater detail, the case law does not require more, for example, that the company set out in substantially more specific terms scenarios under which its cybersecurity measures could prove inadequate. As decisions in this District have recognized, the anti-fraud laws do not require cautions to be articulated with maximum specificity. Indeed, these decisions have recognized policy reasons not to require as a matter of law that disclosures be made at the level of specificity known to the issuer. Spelling out a risk with maximal specificity may backfire in various ways, including by arming malevolent actors with information to exploit, or by misleading investors based on the formulation of the disclosure or the disclosure of other risks at a lesser level of specificity.


Id. at 73. (emphasis added).


The Court also rejected the SEC's claim on SolarWinds' post-SUNBURST disclosures. "As to post-SUNBURST disclosures, the Court dismisses all claims. These do not plausibly plead actionable deficiencies in the company's reporting of the cybersecurity hack. They impermissibly rely on hindsight and speculation." Id. at 3. Judge Engelmayer found unpersuasive the SEC's allegation that the failure to state in a Form 8-K filing (made days after the discovery of the SUNBURST breach) that malicious code had been used in the two prior attacks made the filing materially misleading.



HIPS software, Host-based Intrusion Prevention System, checks a server, computer, or workstation for events occurring on that host which indicate there is a cybersecurity threat. One of the features of a HIPS program is that it monitors files for changes in content. It's not a firewall, looking for intrusions into the host, but a system that checks for changes within. It will also keep track of which programs installed on the host have been verified, and block them from taking restricted actions. HIPS differs from anti-virus software which checks for known viruses. It is not limited by only being able to check for malware that has been identified, but it will look for attacks following known patterns.


HIPS should flag cases in which interprocess communications (IPC) - data exchanged between programs - becomes a means by which a trusted program becomes infected with malware. HIPS will monitor protocols, such as HTTP or TCP, for deviations from their normal content. It will also watch for when something alters registry keys, installs drivers, or terminates other applications.


A system which detects threats that have already occurred is a host-based intrusion detection system - HIDS.






A European cyber security company, With Secure, recently posted its findings on a flaw in the encryption method used in the local installation version of Microsoft Office 365.















Office Message Encryption (OME) works with Electronic Codebook (ECB). A party attempting to decrypt Office encrypted messages (which are sent as email attachments), may be able to determine the content by detecting where certain blocks of text, such as confidentiality footers or headings, repeat in multiple messages. The structure will be apparent even to a party that doesn't have the key for the encrypted text. ECB will encrypt repeating blocks of text in the same way. As stated in NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation, "in the ECB mode, under a given key, any given plaintext block always gets encrypted to the same ciphertext block. "


Unlike a more secure encryption method like Cipher Block Chaining (CBC) ECB does not use an initialization vector, a random factor which prevents blocks of identical plaintext (unencrypted text) from having the same encryption. This diagram on the Sophos cyber security blog, demonstrates the problem with ECB:



With Secure's post points out that a 2021 Microsoft FIPS (Federal Information Processing Standard) Compliance post [made to comply with the Information Technology Management Reform Act of 1996's encryption requirements] states that, "Legacy versions of Office (2010) require AES 128 ECB, and Office docs are still protected in this manner by Office apps.".


So apparently in order to avoid trouble with users running older versions of MS Office being unable to decrypt messages encrypted with CBC or another encryption method, Microsoft will continue to use the weaker ECB method.




Sean O'Shea has more than 20 years of experience in the litigation support field with major law firms in New York and San Francisco.   He is an ACEDS Certified eDiscovery Specialist and a Relativity Certified Administrator.

The views expressed in this blog are those of the owner and do not reflect the views or opinions of the owner’s employer.

If you have a question or comment about this blog, please make a submission using the form to the right. 

Your details were sent successfully!

© 2015 by Sean O'Shea . Proudly created with Wix.com

bottom of page