Circum Cyberes: 1(3)

By Ravi Nayyar

Quad Senior Cyber Group Meets in New Delhi

The Quad is a diplomatic partnership involving Australia, India, Japan and the United States.

The Quad Senior Cyber Group (‘the QSCG’) — established at the Quad Leaders’ Summit in September 2021 and first meeting in Sydney in March 2022 — met in New Delhi this week. The QSCG comprises four Principals, one official from each government who deals with cyber policy. Australia’s rep was the Home Affairs Secretary, Michael Pezzullo AO.

Per the Australian readout, the Principals, among other things:

addressed implementation of important cyber initiatives, including: driving more secure software services; establishing common cyber security requirements to boost resilience of Quad critical infrastructure assets; and greater community cyber security awareness to counter threats posed by ransomware criminals.

They also covered CTI sharing, risks to cyber supply chains, as well as alignment of baseline software security requirements to drive improvements in the overall software development ecosystem. This makes sense, considering the remit of the Quad Cybersecurity Partnership — two of its pillars are CNI protection and supply chain resilience and security, and the four governments seek to raise software security by coordinating their national procurement standards.

What I find interesting is that our Home Affairs Secretary, Michael Pezzullo AO, is our Quad Principal. Sure, he’s been our rep at Quad Senior Cyber Group/International Counter Ransomware Initiative meetings, but I find it interesting that neither of the chiefs of the Cyber and Critical Technology Coordination Centre, the Cyber and Infrastructure Centre (both within the Department of Home Affairs), nor the Cyber Affairs and Critical Technology Branch of the Department of Foreign Affairs and Trade (the Ambassadorship for Cyber Affairs and Critical Technology recently became vacant) is our Principal.

What I also found weird was that the Indian readout of the meeting says the United States’ Deputy National Security Advisor for Cyber and Emerging Technology, Anne Neuberger, was one of the Principals and attended the meeting. Except neither could I find her in both family photos from the meeting, nor was she mentioned in the tweet on the meeting by the US Embassy in New Delhi.

[Cue contemplative music.]

APRA Warns Companies to Lift Their Game on Cyber Security

The Chair of the Australian Prudential Regulation Authority (‘APRA’), John Lonsdale, has warned his regulated population that APRA’s prudential standard, CPS 234: Information Security, ‘will be “rigorously applied”’ following a bunch of big data breaches last year.

APRA is quite busy with a bunch of ‘supervisory work’ concerning cyber resilience of regulated entities, having ordered a bunch of them to commission independent audits of their controls. One of these audits include one pending by Deloitte into Medibank Private which suffered a serious data breach last year.

The Chair made his agency’s intent quite clear:

Where we have problems at the entity level we expect remediation to happen and we expect it swiftly. You need to have very sound operational risk and cyber resilience in place and importantly where there is a problem being able to make sure the critical functions still operate.

This is linked with APRA’s Supervision Priorities for 2023, in which the regulator has stated its planning to have ‘a particular focus on heightened cyber risk’ and making ‘improving cyber resilience… a key cross-industry supervision priority’. As the Chair foreshadowed, APRA has committed to ‘exercise heightened supervision and rigorously pursue breaches of the [Prudential] standard [CPS 234]’, require regulated entities with shortcomings to lift their game swiftly and ‘assess board effectiveness regarding cyber resilience’ at certain regulated entities.

Given that APRA expects to receive the independent audits of most regulated entities’ compliance with CPS 234 this year, 2023 ought to be fun.

Also, note that APRA flagged last year that it expects Medibank Private to ‘ensure there is appropriate consequence management, including impacts to executive remuneration where appropriate’. In this vein, will we see more enforcement of the Banking Executive Accountability Regime (enshrined by Banking Act 1959 (Cth) pt IIAA) by APRA against authorised deposit-taking institutions (like Australian banks), their directors and senior executives with respect to major breaches of cyber resilience at ADIs; something foreshadowed by Australian legal scholars in 2018?

(Ransomware Attack at ION Markets Adversely Affects Functioning of Derivatives Markets)

Reporting in the Financial Times, Reuters and The Record points to ION Markets, a software vendor for financial markets firms, having suffered a ransomware attack with the LockBit variant on 31 January. The firm said that one of its divisions, ION Cleared Derivatives, was affected and that the breach was ‘contained to a specific environment, all the affected servers are disconnected, and remediation of services is ongoing’. The American derivatives regulator, the Commodity Futures Trading Commission, the UK’s Financial Conduct Authority and Prudential Regulation Authority, the FBI as well as the Futures Industry Association are working with the derivatives industry and other stakeholders to resolve the breach and its impacts.

Given the importance of ION Markets as a vendor, the attack reportedly stymied ‘post-trade processes, including trade matching, and keeping track of risk and margin requirements’, forcing some traders to resort to ‘manually finish steps [that are usually automated] such as checking margin requirements and completing end of day reports. One of Reuters’ sources on the story indicated that the breach itself could take about a week to be resolved.

The firm’s having been targeted has also made month-end data reporting for some market participants a challenge. CME Group and Intercontinental Exchange, the two largest US exchange groups, warned that, with many of their members facing the downstream consequences of the attack, the ‘timing and accuracy of some of their published data’ could be affected. Italy’s largest bank was also not having a good time, reported to tell clients that it was not able to handle orders because its brokerage and clearing operations on exchange-traded derivatives had been ‘severely hampered’ by the breach.

This incident underlines the ‘digital dependencies’ (to borrow the OECD Council’s language) of financial markets and indeed CNI, given that the financial sector is a CNI sector. And thus, the need to cyber resilience the security of the technology ecosystem which services regulated market participants operate in, rather than just that of the latter.

Indeed, given the significance of ION Markets to the cyber supply chains of so many derivatives trading firms, this attack reinforces the need to approach the cyber resilience of the financial sector and CNI generally in a holistic fashion. For instance, by mapping out cyber supply chains and identifying critical vendors and service providers (especially those enjoying high market share) for regulated entities.

Of course, I am not privy to the planning and incident response procedures of derivatives market participants and regulators in any jurisdiction, but the ION Markets breach does not paint a pretty picture. ION Markets is a well-known vendor for the industry and yet the downstream consequences of a ransomware attack against its systems are this severe. Especially in 2023.

What happened to planning and running tabletop exercises to see how stakeholders can move swiftly to ensure the operational resilience of CNI?

I especially ask because (systemic) risks to financial markets though their critical technology vendors and service providers is something which regulators in advanced economies themselves have been warning about of late. For example:

• US banking regulators (the OCC, FDIC and Board of Governors of the Federal Reserve) enacted a rule requiring bank service providers (including technology vendors) to tell their customer banks that they’re suffered a breach of cyber resilience which has or is reasonably likely to seriously affect their provision of certain services to the banks;
• the European Systemic Risk Board (‘ESRB’) argued in favour of the creation of a ‘pan-European systemic cyber incident coordination framework’, which should expressly deal with risks invited by ‘the excessive concentration of ICT providers and their products and limiting the lack of ICT substitutability’. Note that most members of the ESRB regarded ‘insufficient industry oversight of third-party suppliers and the supply chain’ as a high-priority issue they need to resolve;
• HM Treasury proposed a regime for the regulation of ‘critical third parties’ that provide ‘material services’ to UK banks; and
• APRA consulted on a new prudential standard for operational resilience, which would include obligations for its regulated entities to manage risk from their ‘material service providers’, that is, third parties on whom they depend ‘to undertake a critical operation or that could expose [them]… to material operational risk’. Such service providers were proposed to include those providing ‘core technology services’.

Neither is this a new problem, nor are concerns from regulators new.

And yet here we are. Still.

CISA Establishes New Office to ‘Operationalize’ Supply Chain Security

The United States’ Cybersecurity and Infrastructure Security Agency (‘CISA’) has created a project management office focused on cyber supply chain risk management (‘C-SCRM’), which sits within CISA’s cybersecurity division and is led by Shon Lyublanovits, a former General Services Administration official. The office will aid C-SCRM by the USG and industry.

Ms Lyublanovits said that the agency will run new SCRM training later this year and is going to be running roundtables on C-SCRM, catering to the USG, industry and SLTT government stakeholders.

My response to this news: ABOUT TIME.

After all, in 2021 (per 41 CFR § 201–1.102(a)(4)), CISA became a member of the Federal Acquisition Security Council (‘FASC’), a body established in 2018 under 41 USC § 1322(a) and tasked by 41 USC § 1323 to, for instance: get NIST to develop a C-SCRM framework for the USG; ‘identifying or developing criteria’ governing interagency sharing of information on C-SCRM; and engaging with industry. In 2021, the FASC tapped CISA to be its ‘information sharing agency’ to handle said interagency information sharing as well as help run a FASC SCRM Task Force, per 41 CFR § 201–1.200. One also presumes that the new office at CISA would feed into the ICT SCRM Task Force, sponsored by the agency’s National Risk Management Center and drawing members from government, and the IT and communications sectors. So, it’s curious what the USG was waiting all these years (quite literally) before setting up the office.

The need for such an office is also enlivened by scathing assessments from the US Government Accountability Office on the state of cyber governance, including C-SCRM, in the USG (eg 1, 2, 3, 4, 5, 6) as well as the ability of CISA to do its job. The USG has plenty of work to do when it comes to its own C-SCRM.

The establishment of the office — particularly its being slated to work with industry — also makes sense because of action by the USG and Congress under the Trump and Biden Administrations to better prosecute national cyber supply chain risk.

There was:

• President Trump’s Executive Order 13873, which created a national-security screening mechanism for any transactions that, to simplify, involve ICT developed, built or marketed by persons subject to the jurisdiction or control of a foreign adversary and that threaten US national security. Said screening mechanism was operationalised in 2021 by the enactment of 15 CFR § 7. Note also that President Biden extended the national emergency declared by President Trump in this executive order with respect to ICTS supply chain risks until 12 May 2023;
• President Trump’s Executive Order 13913, which established the Committee for the Assessment of Foreign Participation in the United States Telecommunications Services Sector, a body primarily to help the Federal Communications Commission (‘FCC’) screen applications for participation in the sector on national security grounds and whose role was enshrined in federal law in 2020 by 47 CFR § 1.40002(b)(1);
• President Biden’s Executive Order 14017, under which the Departments of Homeland Security (which houses CISA) and Commerce produced an ‘Assessment of Critical Supply Chains Supporting the U.S. Information and Communications Technology Industry’;
• President Biden’s Executive Order 14028 (the big cybersecurity executive order), section 4 of which was devoted to uplifting the hygiene of software supply chains servicing the USG, under which the White House Office of Management and Budget handed down Memorandum No M-22–18 for USG agencies’ software SCRM, and NIST provided guidance on how to secure ‘critical software’ (as defined by NIST);
• the enactment of the Secure and Trusted Communications Networks Act of 2019 (codified at 47 USC §§ 1601–9), under which the FCC designated Huawei and ZTE as national security threats and thus producers of covered equipment per 47 USC § 1601. Which led to the FCC: banning the use of Universal Service Fund (‘USF’) money to purchase said companies’ gear, per 15 USC § 1602 and 47 CFR § 54.9(a); requiring the removal of their gear by US telcos receiving USF money, per 47 CFR § 54.11(a); and making said removal, where the telco has at most ten million customers, eligible for federal funding under the Secure and Trusted Communications Networks Reimbursement Program, per 47 USC § 1603 and 47 CFR §§ 1.5000, 54.9(d); and
• the enactment of the Secure Equipment Act of 2021 (codified as a statutory note to 47 USC § 1601), under which the FCC updated its equipment authorisation program (contained in 47 CFR §§ 2.901–2.1093, pending the update of the Code of Federal Regulations) in November 2022 to ban the authorisation, import and marketing of covered equipment (including comms gear produced by Huawei, ZTE, Hytera, Hikvision and Dahua) in the US.

And note that the threat environment for software supply chains in particular isn’t showing any signs of calming down.

Making the effective running of this new C-SCRM office at CISA even more critical to US national security.

And as part of that, there is a need for the USG to hold suppliers that drop the ball in terms of their own and their products’ hygiene to account. One mustn’t forget that the FASC has the power to recommend to the Secretaries of Homeland Security and Defense, and/or the Director of National Intelligence to bar the USG from procuring certain products on, for instance, cyber hygiene grounds, per 41 CFR §§ 201–1.300–201–1.304. There’s also the Department of Justice’s (‘DoJ’) Civil Cyber-Fraud Initiative, under which the DoJ and whistleblowers will use the False Claims Act to nail USG contractors and recipients of federal grant recipients who ‘knowingly provid[e]… deficient cybersecurity products or services, knowingly misrepresent… their cybersecurity practices or protocols, or knowingly violat[e]… obligations to monitor and report cybersecurity incidents and breaches’. Indeed, the DoJ has acted under this initiative against a medical services contractor while a whistleblower sued a propulsion and power systems contractor, with both cases resulting in a settlement.

Devil’s advocate: are more coordination and/or guidance really the best way to drive C-SCRM, as opposed to simply shaping incentives by imposing meaningful legal penalties on vendors — including executive liability (depending on the authorities available to the USG) — that drop the ball and make their directors worry about being voted out at the next AGM or worse?

Stop Passing the Buck on Cybersecurity: Why Companies Must Build Safety Into Tech Products

The CISA Director, Jen Easterly, and CISA Executive Assistant Director for Cybersecurity, Eric Goldstein, have written an essay in the official magazine of the Council on Foreign Relations. In essence, they’ve issued a clarion call for hardware and software to be built with security by design and by default, and for the companies building and marketing these products to lift their game, including with respect to their own cyber resilience.

Director Easterly and EAD Goldstein call for a ‘a new model, one they [Americans] can trust to ensure the safety and integrity of the technology that they use’, under which Boards and CEOs take the initiative and work with their fellow technology vendors to clean up the technology ecosystem. This is envisioned to require a ‘culture shift’, ‘a recognition that a cyberthreat to one organization is a threat to all organizations’.

The authors point to the role of government as ‘convinc[ing]’ vendors to shift their thinking thus, providing a list of (potential) policy initiatives. These initiatives include ‘defining’ criteria for security by default and design, naming and shaming vendors and the USG’s having already enacted software security requirements in procurement standards.

That all said, I sighed loudly on reading the piece.

Firstly, the talking points regarding the need to clean up technological ecosystems from the ground up and for companies to pull their weight are hardly new, given the European Commission’s impact assessment attached to the proposal for the EU’s Cyber Resilience Act, the Strategic Intent Statement from the Office for the National Cyber Director, and an op-ed (also in Foreign Affairs) by the National Cyber Director and Assistant National Cyber Director for Strategy & Research.

Secondly, I was disappointed that the authors did not suggest that the USG is going down the black-letter law route when it comes to cleaning up technological ecosystems and making secure-by-default and -design a reality. Yes, I understand the fraught politics of cyber regulation in the USA, that CISA is not a regulator, and the USG’s competing priorities (such as helping Ukraine defend itself), but the article seemed very aspirational and embarrassed to suggest that the USG will drop the hammer. This is seen in the word choices (all my emphasis): ‘[the USG] advocating for development and voluntary adoption of labels’; and ‘advocating that cybersecurity be considered a CEO-level business risk’. This is language of low modality. Not suggestive of the USG realising that it has, for existence, consumer law authorities that could be enforced against vendors or that it needs to say something like, ‘We are coming after you with new law’.

This is even more curious because it’s 2023 — we have already had NotPetya, SolarWinds, Microsoft Exchange, Kaseya, and heavens know how many vulnerabilities in software controlling, or otherwise deployed in, OT environments.

The time for hope without robust action has long passed.

I point out, however, that the USA’s forthcoming national cyber security strategy was reported this year as slated to go down the black-letter law route. But then again, we see the Director and EAD Cybersecurity of CISA write that the role of governments includes ‘ensuring that regulatory frameworks encourage companies to comply’ (my emphasis), whatever this means.

Thirdly, I furrowed my brow while reading the paragraphs on how companies, including vendors, should do cyber governance. The bit about the ‘new model’ requiring Boards and CEOs to own cyber governance as a ‘core business risk’ was bemusing because, well, how is this ‘new’? One need only review literature from the USG, especially the US Securities and Exchange Commission (‘SEC’) and banking regulators like the FDIC. Corporate governance is the management of risks to the interests of shareholders, including cyber risks. Therefore, the framework — the ‘model’ — for how companies should do cyber governance is already there.

I am not saying corporate law — the legal foundation of corporate and cyber governance — has been enforced as robustly as it should have been by the SEC against US companies who drop the ball, but I was certainly surprised that the SEC didn’t even get a mention in the essay. Especially when the authors point to shareholders, not specifically corporate regulators, as enforcers of this model by making company directors personally accountable for cyber governance. Yes, shareholders can file class action lawsuits against companies for dropping the ball or just simply vote out directors at company AGMs. But they are not the primary enforcer of corporate law: the state, through the corporate regulator, is.

Indeed, the state is seeking to build on that with the SEC’s proposed rules for the disclosure of cyber governance controls and procedures, as well as breaches of cyber resilience.

That all said, the fact that Director Easterly and EAD Goldstein call for a ‘cultural shift’ where companies care about cyber resilience as a core issue is an indictment of extant corporate law frameworks and the quality of their enforcement by regulators like the SEC when it comes to shaping decision-making in industry.

Fourthly, and flowing from my corporate law point, I was disappointed by the authors calling for a ‘cultural shift’ where companies work together to uplift the hygiene of technology ecosystems because they go all The Three Musketeers (‘all for one and one for all’). While I am not familiar with the nuances of US corporate law, I reckon such beseeching from the USG, as opposed to a black-letter law requirement, will achieve little, given that corporate law requires companies’ directors to prioritise the interests of their shareholders, not the community at large. The authors also bemoan that companies ‘often neglect to report cyber-intrusions to the government for fear of regulatory liability and reputational damage’ and how ‘this is a race to the bottom’, except that it is quite reasonable for a company, from a corporate law standpoint and in the absence of a legal obligation to report pwnage, to keep quiet and call in the lawyers.

I am reminded of how Colonial Pipeline was the subject of ignorant criticism for making a perfectly sound business decision to shut down the relevant pipeline because it could not bill customers, given the absence of a legal obligation for it to keep the petrol flowing when the actual OT network was not compromised.

Invoking Tri-Musketeerian ethics in such circumstances can be argued to make Sisyphus look like he’s on holiday. Instead, the piece should have talked more about CISA working, for instance, with the SEC on making US corporate law treatment of cyber governance more robust.

Yes, I get it: the politics of cyber law in the United States are fraught to the extent that the enactment of basic breach reporting requirements for CNI by Congress last year (codified at 6 USC §§ 681–681g, but yet to enter into force) was celebrated as a big win for the Biden Administration.

But come on, the USG, combined with Congress, is the state.

In this way, the title is quite accurate.

The state should ‘stop passing the buck on cybersecurity’.

CISA Prioritizing Effort to Strengthen Corporate Cybersecurity

Following on from the corporate governance angle in the previous story, CISA has made ‘cajoling’ industry into having decent cyber governance by industry a ‘top priority’. The agency’s chief of staff, Kiersten Todt, told Politico that industry must ‘embrace the idea of “corporate cyber responsibility”’, with the agency ‘exploring and examining and researching what makes the most sense to be able to put it in a straightforward, accessible way’.

Though, and you guessed correctly, this is not about regulation. Rather, more of the same voluntary public-private collaboration gear (the effort will feature the Internet Security Alliance and the National Association of Corporate Directors).

Ms Todt also pointed to the ‘Shields Up’ campaign for heightened vigilance following the invasion of Ukraine as ‘a “catalyst” for boards to invest more in cybersecurity’ with industry not wanting to lower their own vigilance. Okay.

If I can reiterate my commentary on the previous story, what does this all mean?

It comes across as Einstein’s definition of insanity. Yes, CISA is not a regulator. So, precisely for that reason, what value does yet another episode of ‘working together’ to develop voluntary guidelines on cyber governance by companies — despite all the literature out there from actual regulators plus NIST — provide?

Good thing that the CISA chief of staff said that the agency could work with other agencies in this mission, like how the Australian Cyber Security Centre works with the Australian Securities and Investments Commission (though she doesn’t specifically mention the SEC). But then again, what value would CISA provide here?

Again, Sisyphus would feel he’s on a tropical retreat.

In any case, I would like to know how CISA is not stretching itself too thin when it comes to cybersecurity mission, given findings from the US GAO about CISA’s slow progress in performing its organisational transformation and the issues it already has in communicating, coordinating with and helping (regional) stakeholders (see here, here, here and here). Last year, CISA was already a year late in submitting its organisational planning and budgeting document known as a ‘force structure assessment’ to Congress for the latter to evaluate its budgeting needs. Perhaps Congress’s waning confidence in CISA’s ability to manage its priorities and meet deadlines effectively was the genesis of section 302(b) of the Consolidated Appropriations Act, 2023.

Which will reduce CISA’s ‘operations and support’ funding by US$50,000 for every day Director CISA fails to provide the House and Senate Committees on Appropriations with quarterly budget and staffing briefings.

After AIIMS Ransomware Attack, Modi Govt’s Building a Task Force to Fight Cyber Espionage

The Indian government is establishing a National Counter Ransomware Taskforce (‘NCRT’) in response to the deteriorating threat environment, as discussed at a conference of state and Union Territory police chiefs which was attended by the Indian Prime Minister and Minister of Home Affairs.

The threat environment was manifest, for instance, in the ransomware attack against the New Delhi branch of the All India Institute of Medical Sciences — a major Indian hospital — in late 2022. Per The Print’s source, the government has the espionage, terrorism and ransomware dimensions also in mind.

The NCRT was put forward as part of a suggested ‘three-fold security measure’, which could also include building an integrated national task force and drafting ‘National Information Security Policy Guidelines’.

The Indian government has multiple irons in the fire, apparently. It reportedly plans to run ‘regular conferences’ of government CISOs and Secretaries for Home Affairs of Indian state governments, as well as schedule cyber resilience audits of government departments. It has established a committee featuring three chiefs of state police, the Directors-General of the National Critical Information Infrastructure Protection Centre — which sits within India’s Sigint agency, the National Technical Research Organisation — and CERT-In, and officers from the Intelligence Bureau (India’s counterespionage service) and the Indian Cyber Crime Coordination Centre (which sits within the Ministry of Home Affairs). Reform of cybercrime offences is also on the cards, alongside existing Union-state counter-cybercrime cooperation.

My response to this news: ABOUT TIME.

These are seemingly standard fora for interagency and federal coordination on cyber resilience and cybercrime prevention.

The last eight or so years have witnessed the utterly extraordinary growth of India’s digital economy as well as Indians’ Internet connectivity. Which makes India a prized target for cyber threat actors, whether motivated by money or the desire to disrupt India’s CNI for geopolitical ends.

This is combined with India’s participating in international fora concerning cyber resilience. It was part of the UN Group of Governmental Experts on ‘Advancing Responsible State Behaviour in Cyberspace in the Context of International Security’ which, in its 2021 report, specifically warned about the ‘increasingly serious’ targeting of CNI and reinforced ‘the commitment of all States to protect [their CNI]’. India also co-leads (with Lithuania) the resilience working group of the International Counter Ransomware Initiative. India works with Australia, Japan and the United States on CNI cyber resilience through the Quad Cybersecurity Partnership. The Quad countries’ Foreign Ministers signed a joint statement on cooperation against ransomware in September 2022, which signalled their ‘collective will’ to counter the ransomware threat to CNI in the Indo-Pacific. Under India’s Presidency of the G20, CERT-In ran the G20 Cyber Security Exercise and Drill earlier this week, which saw participation by over twelve countries.

So again, what took the Indian government this long?

Either way, one should note that it is great to create institutional structures to deal with policy issues, but it is quite another for them to produce meaningful results. Especially when the clock is not merely ticking but thundering from a variety of directions.

Given the sheer amount of targeting of Indian networks, our Indian cousins need to also create a culture of cyber resilience, something I flagged last week.

That would be something which genuinely shifts the needle left of boom (to mix metaphors), perhaps even moreso than the above new initiatives. After all, you can share all the best practice and intelligence you want, but your national cyber resilience is fundamentally a human problem, namely human frailty behind a computer.

Action Needed for GitHub Desktop and Atom Users

GitHub has reported unauthorised access in early December 2022 to code repositories used in the planning and development of the applications, GitHub Desktop and Atom. Among exfiltrated data were some encrypted code-signing certificates for those applications, though GitHub said that it lacked evidence of their malicious use, which suggests that the attacker has not cracked the encryption. Nonetheless, GitHub revoked those certificates, which will cause some versions of GitHub Desktop for Mac and Atom to stop working, requiring users to update to the latest version of GitHub Desktop. The firm also said that it ‘found no impact to GitHub.com or any of our other offerings outside of the specific certificates’ and did not detect any unauthorised changes to the repositories’ code.

Well, good on GitHub for being risk-averse, given that, if the attackers could crack the password for the certs, they could use them to sign their own malicious applications and thus make them appear as created by GitHub. This is why it makes perfect sense for attackers generally to go after certificates — especially from a big-name organisation — in a type of software supply chain attack which exploits vulnerabilities in the code-signing process.

Folks, software SCRM is perhaps your most critical risk management activity, whether or not you’re a technology company. Because you depend on software to survive as a business. And, though GitHub acted quickly here, you cannot ignore that attackers are looking at software supply chains; in the present case, they would have looked at GitHub’s prominence in global software supply chains from its hosting over 373 million code repositories written by over 100 million developers. The original targets here were repositories for code used in developing two GitHub apps used by tons and tons of developers around the world.

Also, just flagging that, yet again, we have a case of a machine in a large tech platform (earlier on it was CircleCI via a stolen session cookie) getting initially compromised via stolen authentication data (here, a stolen Personal Access Token). So good on GitHub for detecting the breach quickly and revoking the stolen creds the very next day. One’s gotta assume one will be popped, so one should invest in one’s EDR, as GitHub clearly has (seemingly unlike CircleCI — see our first edition).

Internet Crawls as Four Undersea Cables Need Repairs

Vietnam’s internet connectivity has been severely affected by its being left with only one of the five submarine communications cables linking it to the rest of the world being fully operational. The other four are cut. For instance, a Vietnamese ISP reporting that the Tata-TGN Intra Asia cable has stopped carrying data traffic from Vietnam to Singapore following a cut about 130 km from a cable landing station in Singapore. The one okay cable connecting Vietnam is the SeaMeWe-3.

Folks, 99% of the world’s comms are carried by hundreds of submarine communications cables. They are CNI for the countries where they land. Our increasingly interconnected digital economies depend on the operational resilience of these cables. Our national security, our economic resilience, are tied to these cables because we cannot effectively communicate or trade with other countries without these cables (satellites can carry a far smaller amount of traffic, that too, at a higher cost). So, when these cables are cut, the consequences can be quite serious.

Of course, cuts can be acts of sabotage, eg, by state actors (we cut the Saigon-Singapore and Saigon-Hong Kong cables in WWII to facilitate an Allied op to retake Singapore from the Japanese) or simply scavenging. But more frequently (based on public reporting at least), the cuts have perfectly non-malicious reasons. Like undersea earthquakes, rockslides, typhoons, volcanic eruptions, human error during repairs or navigation by merchant vessels.

I go through the threat environment for submarine communications cables in detail in the first instalment of my three-part series on submarine communications cables in the Indo-Pacific region.

Back to the present case, we don’t know what precisely caused the break. The key is for the owners and operators of the cables, telcos and other service providers connected to the cables where they land, and telecom regulators to have decent plans in place, and work together in responding to, and resolving, these cuts. And ensuring the availability of telecom services in their jurisdictions.

After all, these services are essential in today’s digitally connected day and age.

Especially in Southeast Asia, home to thriving, growing digital economies.

US Halts Provision of Licences for Export to Huawei

I’ll let the story do the talking:

The Biden administration has stopped providing US companies with licences to export to Huawei as it moves towards imposing a total ban on the sale of American technology to the Chinese telecom equipment giant.

According to the FT’s sources, the Department of Commerce has signalled that companies shouldn’t bother applying for licences, with Alan Estevez — Under Secretary of Commerce for Industry and Security (in charge of the Bureau of Industry and Security, which runs the US’s export controls regime) — reviewing the department’s policy on China and whether the US should tighten the screws even further, so to say.

This is great because it eliminates loopholes when it comes to the flow of US technology to Huawei and thus makes it harder for the firm to make products and deliver services that can be used to threaten the national security interests of the US and its allies (including FVEY allies like us; concerns that drove the FCC to designate it as a national security threat and its gear as covered equipment, as I flagged above).

This apparent action by the Commerce Department exploits the fact that Chinese technology ecosystems are dependent on US inputs (here’s a great lay of the land). Why else did the Chinese President himself urge his people to go for technological self-sufficiency just last year? Why else was the reported trilateral agreement between the Yanks, Dutch and Japanese to curb export to China of some types of equipment used to manufacture semiconductors such a big deal? Why else were the Yanks’ expansion of their own export controls for ‘certain advanced computing and semiconductor manufacturing items… [and] end use’ late last year and in January 2023 in relation to Chinese and Macau entities, respectively, such a big deal?

Trump laid the groundwork with policies including Executive Order 13873. Biden is continuing the broad thrust of Trump’s policies with the above and further export controls targeted at China, though Biden’s action can be viewed as even more comprehensive, and brings US allies and partners along for the ride to a greater extent.

But yes, the latest reported action by the Biden Administration ends the practice under Trump of granting licences ‘to some companies for products that were not related to high-speed 5G telecom networks’. Really tightening the screws.

Technology’s a realm of statecraft, folks.

And, to quote Shakespeare’s Henry V:

The game’s afoot:

Follow your spirit, and upon this charge

Cry ‘God for Harry, England, and Saint George!’

Pro-Russian Hacktivist Group ‘KillNet’ Threat to HPH Sector

The Health Sector Cybersecurity Coordination Center, sitting within the US Department of Health and Human Services, is out with an Analyst Note on the threat from KillNet to the US healthcare sector. The group is reported as ‘actively targeting the health and public health sector’.

It is notorious for using DDoS attacks and, being pro-Russian, it has previously targeted jurisdictions backing Ukraine, especially NATO members, since the Ukraine War started. The attacks that have received a lot of publicity include those against websites (like those of the European Parliament, several US airports and multiple US state governments) and do not tend to be catastrophic like ransomware attacks against actual CNI assets. That said, Killnet’s attacks ‘can cause service outages lasting several hours or even days’. For these reasons and the US’s providing lethal and non-lethal aid to Ukraine, it makes sense that Killnet is turning its gaze to US CNI, including the healthcare sector.

It’s already obvious why the targeting of healthcare is a major issue. Especially targeting of the availability of healthcare services.

But, amidst all this, one mustn’t forget that malicious actors do seek to generate cognitive effects. The Russian state itself treats, as a matter of doctrine, cyber operations as one cog in broader manipulation of opponents’ networks and their psychology. There is also academic literature on how acts of cyber terrorism can induce very similar psychological effects to acts of conventional kinetic terrorism.

In this regard, folks should not be dismissive of the threat from DDoS attacks, even if the attacks tend not to be as severe as ransomware attacks. After all, DDoS attacks can spread panic, eg, when they can take down trusted sources of information about essential services, like hospital or airport websites. This exploits the ignorance of most of civil society as to the distinction between targeting of the actual availability of an essential service (eg OT at a power station) versus that of a public website (eg the investor relations site of the power company). This is what clever threat actors would want to leverage. Even if there is no crisis in terms of the availability of essential services, fear borne from ignorance is a powerful button to press, pardon the pun.

Oracle Cerner EHR System at VA, DOD and Coast Guard Hit with Network Issues

The Oracle Cerner electronic health record (‘EHR’) system deployed at hospitals operated by the US Departments of Veterans Affairs, Defense and the Coast Guard slowed to a crawl this week. Folks at the Pentagon made certain ‘changes’, which had resulted in the unintentional interruption of ‘services that provide connectivity to the network’.

Unfortunately, degraded service in this EHR system is hardly new, with the outlet, FedScoop, revealing ‘nearly 500 incidents when the system was partly or completely unusable between Sept. 8, 2020, and June 10, 2022’. There has also been bipartisan criticism of the cost, transparency and reliability of the rollout of the system.

As a general point, the complexity of modern IT is not ideal, especially when it — like an EHR system — underpins critical services like healthcare delivery. So even when an authorised change is made to, say, a configuration, there can be serious negative externalities for multiple stakeholders if system operators have not looked before they leapt, so to say.

The present case is indeed a case study of the operational risks invited by the digitalisation of healthcare delivery for all stakeholders, especially doctors and patients. Not ideal when the availability of healthcare services, enabled by said digitalisation, is utterly critical. Just look at what happened to hospitals in USA when Nuance’s transcription service — used by doctors to dictate changes in patient files — was knocked out of commission by the NotPetya attack.

Back to the present case, my takeaways: understand your systems; catalogue normal system behaviours; have decent change management and BCP in place; and test the latter out in exercises.

Especially when you are a hospital operator dealing with something as critical as your EHR system.

OpenEMR — Remote Code Execution in Your Healthcare System

Let’s talk about a species of OSS plugging into EHR.

A researcher from cyber resilience firm, Sonar, found three bugs in OpenEMR, ‘the most popular open source electronic health records and medical practice management solution’. When chained together, these enable attackers to get remote code exec on any box running a version of OpenEMR lower than 7.0.0. Not ideal considering the networks those boxes are deployed in.

Sonar reported the bugs to the OpenEMR maintainers and six days later, they released a patch.

Yes, this is a case study on how (so much of) modern computing is built on OSS and makes one sit up, given the worldwide usage of OpenEMR in healthcare networks. Oh, and reminds one of the need to identify and mitigate risks stemming from one’s OSS dependencies, especially if one operates in a CNI sector.

But this is also a case study on the OSS community rallying to fix major issues, just like Log4Shell was. Look at the sheer speed by which the OpenEMR maintainers moved to bring out a patch here.

The commitment to swiftly fix issues with the project echoes findings from a survey by the Linux Foundation and the Laboratory for Innovation Science at Harvard University of hundreds of contributors to OSS in 2020. The respondents’ top three motivations for contributing to OSS were all non-monetary: the contributor using the code themselves and thus needing the relevant feature/fix; an enjoyment of developing their skills; and ‘fulfill[ing] a need for creative, challenging, and/or enjoyable work’. Being paid to contribute was most likely to feature in the bottom three motivations, though it should be noted that most of the respondents had full-time jobs.

Something to smile about?

Amusing Stuff from the Internet

Let’s end on a funny note.

Thanks for reading, folks!