Information Technology

Muurman said
Image: Joakim Honkasalo
The Finnish Parliament said on Monday that hackers gained entry to its internal IT system and accessed email accounts for some members of Parliament (MPs).

Special feature

Cyberwar and the Future of Cybersecurity
Today’s security threats have expanded in scope and seriousness. There can now be millions — or even billions — of dollars at risk when information security isn’t handled properly.
Read More

Government officials said the attack took place in the fall of 2020 and was discovered this month by the Parliament’s IT staff. The matter is currently being investigated by the Finnish Central Criminal Police (KRP).
In an official statement, KRP Commissioner Tero Muurman said the attack did not cause any damage to the Parliament’s internal IT system but was not an accidental intrusion either.
Muurman said the Parliament security breach is currently being investigated as a “suspected espionage” incident.
“At this stage, one alternative is that unknown factors have been able to obtain information through the hacking, either for the benefit of a foreign state or to harm Finland,” Muurman said.
“The theft has affected more than one person, but unfortunately, we cannot tell the exact number without jeopardizing the ongoing preliminary investigation.

“This case is exceptional in Finland, serious due to the quality of the target and unfortunate for the victims,” the official added.
The KRP also said that “international cooperation has taken place in the investigation,” but did not provide additional details.
Norway disclosed a similar incident this fall
But while government officials didn’t mention it, the incident is eerily similar to a similar hack disclosed in a neighboring Scandinavian country.
Earlier this fall, Norway’s Parliament disclosed a similar breach of its internal email system, with hackers accessing some officials’ email accounts.
This month, after a months-long investigation, the Norwegian police secret service (PST) attributed the intrusion to APT28, a group of hackers linked to Russia’s military intelligence service, the GRU.
A recent Microsoft report highlighted a recent trend in APT28 tactics towards targeting email accounts with credential stuffing and brute-force attacks. More

Image: T.H. Chia
A group of mysterious hackers has carried out a clever supply chain attack against Vietnamese private companies and government agencies by inserting malware inside an official government software toolkit.

Special feature

Cyberwar and the Future of Cybersecurity
Today’s security threats have expanded in scope and seriousness. There can now be millions — or even billions — of dollars at risk when information security isn’t handled properly.
Read More

The attack, discovered by security firm ESET and detailed in a report named “Operation SignSight,” targeted the Vietnam Government Certification Authority (VGCA), the government organization that issues digital certificates that can be used to electronically sign official documents.
Any Vietnamese citizen, private company, and even other government agency that wants to submit files to the Vietnamese government must sign their documents with a VGCA-compatible digital certificate.
The VGCA doesn’t only issue these digital certificates but also provides ready-made and user-friendly “client apps” that citizens, private companies, and government workers can install on their computers and automate the process of signing a document.
But ESET says that sometime this year, hackers broke into the agency’s website, located at ca.gov.vn, and inserted malware inside two of the VGCA client apps offered for download on the site.
The two files were 32-bit (gca01-client-v2-x32-8.3.msi) and 64-bit (gca01-client-v2-x64-8.3.msi) client apps for Windows users.
ESET says that between July 23 and August 5, this year, the two files contained a backdoor trojan named PhantomNet, also known as Smanager.

The malware wasn’t very complex but was merely a wireframe for more potent plugins, researchers said.
Known plugins included the functionality to retrieve proxy settings in order to bypass corporate firewalls and the ability to download and run other (malicious) apps.
The security firm believes the backdoor was used for reconnaissance prior to a more complex attack against selected targets.
ESET researchers said they notified the VGCA earlier this month but that the agency had already known of the attack prior to its contact.
On the day ESET published its report, the VGCA also formally admitted to the security breach and published a tutorial on how users could remove the malware from their systems.
PantomNet victims also discovered in the Philippines
ESET said that it also found victims infected with the PhantomNet backdoor in the Philippines but was unable to say how these users got infected. Another delivery mechanism is suspected.
The Slovak security firm didn’t formally attribute the attack to any particular group, but previous reports linked the PhatomNet (Smanager) malware to Chinese state-sponsored cyber-espionage activities.
The VGCA incident marks the fifth major supply chain attack this year after the likes of:
SolarWinds – Russian hackers compromised the update mechanism of the SolarWinds Orion app and infected the internal networks of thousands of companies across the glove with the Sunburst malware.
Able Desktop – Chinese hackers have compromised the update mechanism of a chat app used by hundreds of Mongolian government agencies.
GoldenSpy – A Chinese bank had been forcing foreign companies activating in China to install a backdoored tax software toolkit.
Wizvera VeraPort – North Korean hackers compromised the Wizvera VeraPort system to deliver malware to South Korean users. More

Image: ZDNet
Russian cryptocurrency exchange Livecoin posted on message on its official website on Christmas Eve claiming it was hacked and lost control of some of its servers, warning customers to stop using its services.
According to posts on social media, the attack seems to have happened on the night between December 23 and December 24.
Hackers appear to have taken control of the Livecoin infrastructure and then proceeded to modify the exchange rates to gigantic and unrealistic values.
Before Livecoin admins managed to gain back access to some of their systems during late December 24, the Bitcoin exchange rate had ballooned from the regular $23,000/BTC to more than $450,000/BTC, Ether grew from $600/ETH to $15,000, and Ripple price increased from $0.27/XRP to more than $17/XRP.

Once the exchange rates were modified, the mysterious attackers began cashing out accounts, generating gigantic profits.
In the message posted on its website, Livecoin admins described the incident as a “carefully planned attack, which has been prepared, as we assume, over the last few months.”
“We lost control of all of our servers, backend and nodes. Thus, we were not able to stop our service in time. Our news channels were compromised as well,” the company said.

“At the moment, we partially control frontend, and so we’re able to place this announcement,” it added.
While the main web-based exchange portal si down, Livecoin is now urging users to stop depositing funds and making transactions through other interfaces like the site’s API and mobile apps.
As it happens with most cryptocurrency hacks, several users have cried foul play and are now claiming the entire hack was an inside job.
Livecoin said it notified local law enforcement.
According to CoinMarketCap, Livecoin is ranked as the 173rd cryptocurrency exchange on the internet, with roughly $16 million in daily transactions. The site has been active since March 2014. More

Images: Citrix // Composition: ZDNet
Threat actors have discovered a way to bounce and amplify junk web traffic against Citrix ADC networking equipment to launch DDoS attacks.

While details about the attackers are still unknown, victims of these Citrix-based DDoS attacks have mostly included online gaming services, such as Steam and Xbox, sources have told ZDNet earlier today.
The first of these attacks have been detected last week and documented by German IT systems administrator Marco Hofmann.
Hofmann tracked the issue to the DTLS interface on Citrix ADC devices.
DTLS, or Datagram Transport Layer Security, is a more version of the TLS protocol implemented on the stream-friendly UDP transfer protocol, rather than the more reliable TCP.
Just like all UDP-based protocols, DTLS is spoofable and can be used as a DDoS amplification vector.
What this means is that attackers can send small DTLS packets to the DTLS-capable device and have the result returned in a many times larger packet to a spoofed IP address (the DDoS attack victim).

How many times the original packet is enlarged determines the amplification factor of a specific protocol. For past DTLS-based DDoS attacks, the amplification factor was usually 4 or 5 times the original packet.
But, on Monday, Hofmann reported that the DTLS implementation on Citrix ADC devices appears to be yielding a whopping 35, making it one of the most potent DDoS amplification vectors.
Citrix confirms issue
Earlier today, after several reports, Citrix has also confirmed the issue and promised to release a fix after the winter holidays, in mid-January 2020.
The company said it’s seen the DDoS attack vector being abused against “a small number of customers around the world.”
The issue is considered dangerous for IT administrators, for costs and uptime-related issues rather than the security of their devices.
As attackers abuse a Citrix ADC device, they might end up exhausting its upstream bandwidth, creating additional costs and blocking legitimate activity from the ADC.
Until Citrix readies officials mitigations, two temporary fixes have emerged.
The first is to disable the Citrix ADC DTLS interface if not used. 

Citrix ADCIf you are impacted by this attack you can disable DTLS to stop it. Disabling the DTLS protocol will lead to limited performance degradation, a short freeze and to a fallback.Run following CLI command on Citrix ADC: set vpn vserver  -dtls OFF https://t.co/Tpdnp8k9y3
— Thorsten E. (@endi24) December 24, 2020

If the DTLS interface is needed, forcing the device to authenticate incoming DTLS connections is recommended, although it may degrade the device’s performance as a result.

If you are making use of Citrix ADC and have enabled DTLS/EDT (UDP via port 443) you might need to run this command: “set ssl dtlsProfile nsdtls_default_profile -helloVerifyRequest ENABLED”. This will prevent you from future UDP amplification attacks. #NetScaler #CitrixADC
— Anton van Pelt (@AntonvanPelt) December 21, 2020

Actually the vast majority of deploys will become unstable with that. To be safe until January, better block UDP.
— Thorsten Rood (@ThorstenRood) December 22, 2020 More

Over the past few weeks, I have tried out Ubuntu, Manjaro, openSUSE and the latest Raspberry Pi OS release on the Raspberry Pi 4. I am going to complete this series with a look at Kali Linux, one of my favorite specialist Linux distributions. Kali is specifically made for security analysis and penetration testing, and is preloaded and configured for that purpose. The combination of the inexpensive and portable Raspberry Pi hardware and the Kali Linux distribution has seemed extremely promising to me for several years now, but so far it hasn’t really fulfilled my expectations. Hopefully the more powerful Raspberry Pi 4 and the more mature Kali Linux 2020.4 will remedy that.

Kali Linux for the Raspberry Pi can be downloaded from the Offensive Security ARM Images web page (not the main Kali Downloads page, although there is a link to the correct page there). There are four download images there:
A 32-bit image which will run on all versions of the Pi 2, 3, 4 and 400
A 64-bit image which will run on the Pi 2v1.2, 3, 4 and 400
An image specifically for the Pi Zero and Zero W
An image labelled ‘Kali Linux RPi’
These are all xz compressed images each about 2GB, which can be expanded and copied to a microSD card with this command:
    xzcat kali-linux-2020.4-rpi4-nexmon.img.xz | dd bs=4M of=/dev/sdX iflag=fullblock oflag=direct status=progress
As always, carefully replace /dev/sdX with the actual device name for your SD card device.
Image: J.A. Watson
These images uncompress to about 9GB, so you will need at least a 16GB microSD card, and if you are going to do any serious work with it you will almost certainly need an even larger card.  
Keep in mind that the image will be written to the card with an 8.5GB root filesystem, and that will be expanded to fill the free space on the SD card during the first boot. So if you want to have a separate home or work partition, you should set that up on the SD card (using gparted or some such partition manager) before booting the first time.

Unlike most other Raspberry Pi Linux distributions, there is no “initial setup/configuration” dialog during the first boot, it just comes right up to the login screen. The default credentials are kali/kali, so once you login with that the all-important first step is to change the password (duh).

Kali Linux 2020.4 on a Raspberry Pi 4.
Image: J.A. Watson
Because there is no first-boot configuration script, there are a few other things which need to be done manually. None of these are terribly difficult or complex, but they go beyond what is normally necessary for a “user-friendly” (hand-holding) distribution. If you are advanced enough to use Kali (or attempt to use Kali), you should be used to this, or get used to this. If you are just starting out with Kali, I would strongly suggest getting the book Kali Linux Revealed, which can be downloaded from the given link, or if you are a truly dedicated geek like me, purchased in paperback.

Image: J.A. Watson
First, I verified that the root filesystem had been extended to fill the free space (see screen shot at right), then I copied the contents of /home to the new filesystem, and added a line to /etc/fstab to mount it on boot.
If the desktop wallpaper is not filling the entire display (there is a black band around the edge), go to the file /boot/config.txt and uncomment the line that says
    disable_overscan=1
Then reboot, and the image should fill the screen.
If you are using anything other than a US Ascii keyboard, the layout has to be changed. There are two ways to do this: for the GUI-desktop only, go to the desktop menu Settings / Keyboard / Layout, un-check “Use system defaults” and then choose the correct layout in the box at the bottom of the window. To make the change system-wide, including the text-only virtual consoles, edit the file /etc/default/keyboard, and change the value for XKBLAYOUT to the correct value (for example, “de” for German, or “ch” for Swiss German). This change only takes effect after a reboot.
The other thing that I find worthwhile to manually configure is the local timezone. This defaults to UTC, which certainly isn’t correct for Switzerland. I don’t see a way to change this in any of the Settings menu items or the Settings Manager utility, so I just used the command line to change it:
    sudo datetimectl set-timezone Europe/Zurich
The value you give has to correspond to an entry in /usr/share/zoneinfo.
After getting this bit of configuration done, I took a closer look at the desktop and applications installed. This is an XFCE (4.14) desktop, with the menus extensively customized for the Kali distribution. The main menu contains the most useful security and penetration testing tools, and the “traditional” xfce menu has been moved to the “Usual Applications” sub-menu.
The default web browser is Firefox ESR, and my first impression is that it starts very quickly for a Raspberry Pi system – even for a Pi 4, in fact. Again, it has been customized for Kali, with a bookmark toolbar containing a useful group of items. I actually used Firefox on the Pi 4 to write portions of this post, and the performance was very good, with none of the lagging or difficulty that I have experienced on earlier Raspberry Pi / Browser combinations. The only problem I ran into here was that audio doesn’t seem to work, which I had already come across with openSUSE on the Pi 4, so I assume this is a more general problem that is likely to be fixed in a future release.
The default terminal emulator in the Favorites section is QTerminal, which is typical for an xfce distribution; but looking in the Usual Applications / System list, I see that the QTerminal drop-down is there, which I prefer so that there is always a terminal available on the F12 key, and UXTerm and XTerm are also included.
A quick check with uname -a shows that the Linux kernel is 4.19.118, and the 32-bit architecture is identified with armv7l.
SEE: An IT pro’s guide to robotic process automation (free PDF) (TechRepublic)
With the 32-bit version working very well, I decided to move on to the 64-bit version. Download, copy to microSD and initial boot were all identical to the 32-bit process. The difference in architecture can be confirmed with uname -a, which says aarch64 this time.
I went through the same checks and tests as I had done for the 32-bit version, with mostly the same results – but two significant surprises. First, keyboard layout configuration is inconsistent. Simply changing the system default in /etc/default/keyboard does not produce the correct layout in the desktop GUI; going to Settings / Keyboard and changing the layout there works, but only until the next reboot; but adding the desired layout twice in the Keyboard Settings causes the setting to be retained across reboots. I know that sounds weird, but I have tried this several times, in several different ways, and it is always like this – and only on the 64-bit version. Very weird.
The second difference, and the much more pleasant one, is that audio works in Firefox! Again, I have tried this several ways, and bounced back and forth between the 32-bit and 64-bit versions, and it is consistent – no audio in the 32-bit version, but it works in the 64-bit version.
With testing done on the Raspberry Pi 4, I moved on to the Pi 400. I took the microSD card with the 64-bit distribution and put it in the Pi 400, and it booted right up. That’s already good news, because at least one of the other Linux distributions I have tested didn’t boot in the 400.
Running through the same few tests as I had done on the Pi 4, everything seemed to be OK, including audio working in Firefox.  When I checked the configuration, I found two differences. The first was puzzling, but not particularly serious – the keyboard layout is correct, with none of the quirks that I struggled with on the Raspberry Pi 4. I have no explanation for this, but as long as it works, I don’t particularly care.

Image: J.A. Watson

×
screenshot-2020-12-23-14-00-17.png

Second, and much more serious, the wireless networking adapter is not detected on the Raspberry Pi 400. This worked perfectly on the Pi 4, but it simply doesn’t show up on the Pi 400. There is no wireless adapter or wireless networks shown in the drop-down from the Network Manager applet, there is no wireless adapter shown in the ip address output, there is no wireless device shown in the rfkill output, and there is no wireless adapter shown in the lshw output. (Interesting note: lshw is not installed by default, but it can easily be installed on the 64-bit version with sudo apt install lshw, but not on the 32-bit version – apparently it isn’t in the 32-bit repositories but it is in the 64-bit repositories.) I spent quite a lot of time trying to figure this out, with no success: apparently there is some sort of hardware difference between the Pi 4 and the Pi 400, but I can’t figure out what.
Shutting down and switching from the 64-bit card to the 32-bit card produced results that were consistent with what I have seen so far – it boots and runs, performance is good overall, but Wi-Fi doesn’t work, and there is no audio output.
The results from these tests on the Raspberry Pi 4 and 400 were good (well, except for the Pi 400 Wi-Fi), and the Kali download page says that these images should work on the Pi 3, so I decided to give that a try too. Both the 64-bit and 32-bit version boot and run on any Raspberry Pi 3, and the performance is, at least initially, not bad. It is noticeably slower than the Pi 4, of course, but that is to be expected. The problem comes when you start to run applications – even trying to do something fairly trivial such as display a web page, the system bogs down dramatically, and if you load it a bit more, it simply stops. I strongly suspect the problem is that these Raspberry Pi models have only 1GB of memory, and this problem is compounded by the fact that Kali doesn’t allocate any kind of swap space, so once the system starts to run out of memory, well, you’re basically screwed.
I also tried the Raspberry Pi 2, just for completeness. It booted and ran, but obviously had the same limitations and problems that the Raspberry Pi 3 had, because of the 1GB of memory. As expected, the Pi 2v1.2 ran with both the 64-bit and 32-bit versions, and the performance actually wasn’t noticeably worse than the Pi 3; the Pi 2v1.1 would only boot the 32-bit version, but even at that the performance again was comparable to the Pi 3.
The last member of the Raspberry Pi family to test is the Pi ZeroW. This requires a different Kali image than the others, but it is about the same size, 2GB download and 9GB installed, so again, it requires at least a 16GB microSD card. This might be a bit more of a problem with the Pi Zero, simply because it is old enough and small enough that a lot of them are currently running with 8GB cards.
I used a 32GB card, and the initial boot process took a very, very long time processing the expansion of the root filesystem. It did eventually come up to the login screen (after something like 5 minutes), it was obviously still terribly overloaded, because it took an extremely long time to even register the keyboard input of the login name and password, and after getting through that, it took several more minutes for the desktop display to come up and be ready for use.
SEE: Raspberry Pi 400: Its designer reveals more about the faster Pi 4 in the $70 PC’s keyboard
I didn’t want to be unfair to the Pi Zero, so I shut it down and powered off, and then booted it back up so I could time the boot without the process of expanding the root filesystem. On the Raspberry Pi 4, it takes approximately 30 seconds from power on to the login screen, but on the Pi ZeroW that took about 3.5 minutes. That’s not promising. It took another 5 minutes after entering the login info before the desktop finally came up and was useable. For me, this is very firmly in the “I can’t use anything this slow” category.
I was curious as to why and how the performance could be this bad, so I spent some time investigating. As best as I can tell, the primary problem is the simplest and most obvious one – the CPU is simply overloaded. Although it shows a very low CPU load when the system is idle (which it should, this means the system is not overloaded by the operating system itself), trying to run any application at all causes the CPU use to instantly peg at 100% and stay there. For example, the web browser included in this version of Kali is Midori (obviously because it is much lighter weight than Firefox), and trying to simply display the Kali Linux home page took more than three minutes, with the CPU statistics constantly showing 90%+ user time and 0% idle time.
The secondary performance problem is that the Pi ZeroW only had 512MB of memory, and this is simply not enough. Memory use statistics show that there is 10MB or less free memory even when the system is completely idle. Oh, and one other point about this, for the hard-core geeks who might be reading. The default configuration didn’t have any swap space at all, neither in a partition nor a swap file. I added a 2GB swap partition and activated it, and although that didn’t make a noticeable difference in performance, I did see that when I was running the browser it started to use 150MB or so of the swap area. When I then disable the swap, it took a minute or so to do that, and then the memory use statistics were right back to 280MB used and 145MB allocated for buffers and cache, with only 5MB free.
So, to get to the bottom line. Kali Linux on the Raspberry Pi 4 and Raspberry Pi 400, with 4GB (or more) of memory, is a pleasure. It’s easy to install, it runs very well, and response time is good. There are a couple of minor glitches with sound and wireless networking, but those are very likely to be worked out before long. This system is really what I have been wanting/expecting since the first time I heard about a Kali Linux port to the Raspberry Pi family several years ago. Unfortunately, though, on systems with only 1GB of memory the situation is completely different – and that includes the Pi 4, 3 and 2. It boots and runs, but it is far too easy to slow to a crawl, or actually stop, by running applications that need too much memory. Finally, the Pi Zero/ZeroW family, with only 512MB of memory is, for me, unusable.

Open Source More

Ransomware is one of the biggest threats facing businesses. An organisation that falls victim to a ransomware attack – which sees cyber criminals use malware to encrypt the network, rendering it inoperable – will quickly find itself unable to do business at all.
Cyber criminals lock down networks like this for one simple reason: it’s the quickest and easiest way to make money from a compromised organisation and they’re unlikely to get caught.

More on privacy

The attackers demand a ransom payment in exchange for the decryption key for the files – and throughout 2020 the extortion demands have risen, with ransomware gangs now regularly demanding millions of dollars in bitcoin from victims.
SEE: A winning strategy for cybersecurity (ZDNet special report) | Download the report as a PDF (TechRepublic)  
The unfortunate reality is that ransomware continues to be successful because a significant number of victims give in to extortion demands of the criminals by paying the ransom. While the police and cybersecurity companies say organisations shouldn’t pay criminals, many feel as if it’s the quickest and easiest way to restore their network and prevent long-term economic damage – although it still creates plenty of ongoing problems.
And ransomware gangs have increasingly added a new tactic in an attempt to force victims to pay up; they threaten to leak stolen data from the victim, meaning that sensitive corporate data or personal information of customers and clients ends up being made available to other criminals.
“From a financially motivated criminal’s perspective, ransomware remains the most lucrative type of cyberattack, especially when the victims are high-value enterprises. In late 2020, cyber criminals are intensifying their attacks to maximise their financial gains and increase the odds of getting paid,” says Anna Chung, cybersecurity threat research analyst for Unit 42 at Palo Alto Networks.

Ransomware attacks have become more powerful and lucrative than ever before – to such an extent that advanced cyber-criminal groups have switched to using it over their traditional forms of crime – and it’s very likely that they’re just going to become even more potent in 2021. 
For example, what if ransomware gangs could hit many different organisations at once in a coordinated attack? This would offer an opportunity to illicitly make a large amount of money in a very short amount of time – and one way malicious hackers could attempt to do this is by compromising cloud services with ransomware.
“The next thing we’re going to see is probably more of a focus on cloud. Because everyone is moving to cloud, COVID-19 has accelerated many organisations cloud deployments, so most organisations have data stored in the cloud,” says Andrew Rose, resident CISO at Proofpoint.
We saw a taster of the extent of the widespread disruption that can be caused when cyber criminals targeted smartwatch and wearable manufacturer Garmin with ransomware. The attack left users around the world without access to its services for days.
If criminals could gain access to cloud services used by multiple organisations and encrypt those it would cause widespread disruption to many organisations at once. And it’s entirely possible that in this scenario ransomware gangs would demand tens of millions of dollars in extortion fees due to what’s at stake.
The destructive nature of ransomware could also see it exploited by hacking operations that aren’t purely motivated by money.
The first example of this was in 2017 when NotPetya took down networks of organisations around the world and cost billions in damages. While the attack was designed to look like ransomware, in reality the malware was designed for pure destruction as there wasn’t even a way of paying the ransom demand.
NotPetya was attributed to the Russian military and it’s likely that the idea of using ransomware as a purely destructive cyberattack hasn’t gone unnoticed by other nation states. For a government or military force that doesn’t want it’s enemy to know who is behind a destructive malware attack, posing as cyber criminals could become a useful means of subterfuge.
“We’ve already seen a precedent that’s been set by nation-state actors who have used this, but what if they take it to the next step? The destructive capabilities of ransomware are certainly appealing to malicious espionage actors and they may use it to cause disruption,” says Sandra Joyce, senior vice president and head of global intelligence at FireEye.
“So as we continue to see ransomware in the criminal underground continue to rise, we need to be mindful of the fact that nation states are watching and could take this on as their weapon of choice,” she adds.
Ransomware will continue to be a major threat, but businesses can help protect themselves from it by applying a small number of relatively simple cybersecurity practices.
Organisations should should ensure they have a well-managed plan around applying cybersecurity patches and other updates. These patches are often released because software companies have become aware of known vulnerabilities in their product, which cyber criminals could be exploiting – by applying the patch in a swift and timely manner, it prevents malicious hackers using these as means of breaking into the network.
SEE: Cybersecurity: Let’s get tactical (ZDNet/TechRepublic special feature) | Download the free PDF version (TechRepublic)    
One of the other methods cyber criminals use to gain entry to networks is taking advantage of weak passwords, either buy buying them on dark web forums or simply guessing common or default passwords.
To prevent this, organisations should encourage employees to use more complex passwords and accounts should have the additional security of multi-factor authentication, so if an intruder does manage to crack login credentials to gain access to a network, it’s harder for them to move around it.
Businesses should also make sure they’re prepared for what could happen should they end up falling victim to a ransomware attack. Regularly creating backups of the network and storing them offline means that if the worst happens and ransomware encrypts the network, it’s possible to restore it from a relatively recent point – and without giving into the demands of cyber criminals.
Because ultimately, if hacking gangs stop making money from ransomware, they won’t be interested in conducting campaigns any more.
MORE ON CYBERSECURITY More

The Communications Alliance has asked the government to avoid duplication when introducing new obligations to telco providers under the Telecommunications Sector Security Reforms (TSSR).
Under the TSSR, all carriers and nominated carriage service providers (C/NCSPs) are required to notify the Communications Access Coordinator (CAC) of proposed changes to their telecommunications systems or services if they become aware of any proposed changes that are likely to have a “material adverse effect” on their capacity to comply with security obligations.
As it currently stands under TSSR obligations, telcos need to “do their best” to protect infrastructure.
In its submission [PDF] to the Parliamentary Joint Committee on Intelligence and Security (PJCIS) and its review of the TSSR, Comms Alliance has asked for the repeal of the TSSR notification obligation or exemption from this obligation for entities subject to the positive security obligation (PSO) under the nation’s newly introduced critical infrastructure Bill.
Read more: Tech industry concerns put aside as Critical Infrastructure Bill enters Parliament
The PSO contained in the Security of Critical Infrastructure Act (SoCI Act) is intended to result in the same outcome as the TSSR, Comms Alliance argued. It said imposition of the PSO on entities already subject to the TSSR’s security and notification obligations will result in duplication of regulatory regimes that have the same intended outcome.
“We, therefore, recommend either repeal of the TSSR notification obligation or exemption from this obligation for entities subject to this PSO,” it wrote.

“The review of the TSSR must have regard to the evolving horizontal regulations such as the SoCI Act and ensure that the rules of those regulations avoid overlap, redundancy, or even inconsistencies with existing sector-specific regulations.
“Service providers which are already subject to cybersecurity requirements in sector-specific legislation must remain excluded from the scope of the horizontal requirements or see a removal of sector-specific regulation where those would create duplication.”
The industry body said this exclusion is necessary to ensure legal clarity, certainty, and proportionality of obligations.
“We argue that, in effect, this makes the TSSR notification requirements redundant as assessment of the risks of proposed changes would necessarily form part of a broader, annually endorsed and reported risk management plan,” it continued.
“Subjecting entities to the TSSR notification requirements (and subsequent risk mitigation if deemed necessary) as well as the PSO of the revised SoCI Act would result in a substantial amount of duplication and inefficiencies — the opposite of government’s stated aim.”
It also said maintaining both sets of obligations would create duplicative efforts for the CAC/Critical Infrastructure Centre.
“We believe that there should only be one authority designated for CSPs in the security space. Currently, the legislative and regulatory environment around security, cybersecurity, and data protection is rather crowded,” the submission added.
Instead, Comms Alliance has thrown its support behind a “high-level principles-based approach to ensuring security”. It said such an approach allows CSPs the necessary flexibility to implement measures as appropriate for their business while being able to rapidly adapt to technological change.
“This approach is also more likely to avoid duplication or inconsistencies with existing (or future) international standards and best practice, and provides the necessary flexibility for globally operating organisations to comply with a more limited set of security specifications, thereby contributing to increased operational efficiency and legal certainty,” it said.
On two-way threat sharing, Comms Alliance said communications-specific threat information has not been shared with its members.
“Consequently, our members have borne substantial costs to implement the Reforms — and government decisions that were taken as a result of the Reforms — without having had the promised benefit of additional risk and threat information to guide investment decisions,” it wrote.
“This is regrettable and ought to be remedied with urgency, particularly in light of the additional layer of security regulation that the revised SoCI Act (even in its ‘lightest version’) is likely to represent for our sector.”
Comms Alliance added the communications sector has already incurred substantial costs in the course of the implementation of the TSSR and that it continues to bear high regulatory expenses for ongoing compliance with the various security-related legislative and regulatory requirements.
“Against this background and noting the additional costs that are likely to result from the requirements of the revised SoCI Act, we encourage the committee to consider cost recovery options for telecommunications providers covered under these extensive security regimes,” it said. “We deem it important that the critical infrastructure reforms and the TSSR preserve the principle of cost recovery, which is well established under the Telco Act.”
HERE’S MORE More

Image: Martin Abegglen (Flickr/CC2.0)The US Department of Homeland Security has published a “business advisory” today warning US companies against using hardware equipment and digital services created or linked to Chinese companies.

The DHS said that Chinese products could contain backdoors, bugdoors, or hidden data collection mechanisms that could be used by Chinese authorities to collect data from western companies and forward the information to local competitors to further China’s economic goals to the detriment of other countries.
All equipment and services remotely linked to Chinese companies should be considered a cyber-security and business risk, the agency said.
The DHS argues that Chinese national security laws allow the government to coerce any local company and citizen to alter products and engage in espionage or intellectual property theft.
The DHS described this practice as “PRC [People’s Republic of China] government-sponsored data theft.”
“For too long, US networks and data have been exposed to cyber threats based in China which are using that data to give Chinese firms an unfair competitive advantage in the global marketplace,” said Acting Secretary of Homeland Security Chad F. Wolf.
“Practices that give the PRC government unauthorized access to sensitive data – both personal and proprietary – puts the US economy and businesses at direct risk for exploitation. We urge businesses to exercise caution before entering into any agreement with a PRC-linked firm.”

In a separate speech on Monday, Wolf also described China as “a clear and present danger” to US democracy.
The DHS published its advisory less than a month before a change in administration, with President Biden expected to name his own DHS chief next month.
Under the Trump administration, US officials have focused on cracking down on Chinese theft from US companies.
In a July 2020 interview with Fox News, FBI Director Christopher Wray said that half of the FBI’s almost 5,000 counter-intelligence cases were related to Chinese theft of US technology.
Through its new advisory, the DHS warns US businesses that Chinese theft can sometimes occur not only through business partnerships and insider threats but also through backdoored equipment and digital services.
“Any person or entity that chooses to procure data services and equipment from PRC-linked firms, or store data on software or equipment developed by such firms, should be aware of the economic, reputational, and, in certain instances, legal, risks associated with doing business with these firms,” the DHS said in a press release today. More