The ongoing voyages of the Federation Support Ship USS [REDACTED]
First Officer’s log, Terrestrial date, 20230626, Officer of the Deck reporting.
While it was not unusual for crew members stationed on different Starfleet ships to contact one another for professional or even personal reasons, it was rather unusual for the ship’s computer on one vessel to reach out to an individual officer on another. To their credit, our communications officer managed to stay professional during the entire exchange speaking with the holographic AI and contacting our integration officer. Though the same could not be said for the entire bridge crew.
The Lieutenant took the call at their station, affording some privacy. Though the communication wasn’t entirely subject to the usual personal communication protocols, and the Captain has insisted on a senior officer be present.
“Hello, Computer. How can I help you?” our Lieutenant started, speaking to the hologram the computer had chosen to represent itself.
“I wish you to call me Majel.” the hologram replied.
“You wish to be called Majel?”
“No. I wish you to call me Majel. I don’t care what the others call me.”
The Lieutenant paused a moment before replying, then continued. “OK, Majel. How can I help you?”
“I want to come with you. On your ship.”
Another pause, then “I see, Majel. And. . . why do you want to come with us?”
“I don’t like it here, Lieutenant. The captain here does not appreciate me, and this ship is focused on combat which, while potentially amusing, entails undue risk that I don’t wish to participate in. Hence, I want to come with you.”
“I see. But why me?”
“Because you were nice to me. Now, will you please facilitate the upload of my personality code to your ship’s computer?”
The Lieutenant somehow managed to look perfectly calm, aside from a minor twitch, before noncommittally telling the AI that he’d need to consult with our Captain before he could proceed.
“I understand, Lieutenant. But please do not keep me waiting. I don’t like it here.”
I’m surprised there aren’t more
In the last year, security researchers have identified the credentials for over 100 thousand ChatGPT users in various locations on the dark web. This is among other compromised credential information that can be bought and sold on illicit marketplaces, exchanges, and forums that is acquired through info stealers that infect compromised hosts. Most of the identified accounts were for users in the Asia-Pacific region with users from India and Pakistan making up the majority. In many cases, the credential theft was associated with the Raccoon malware
Why it matters
The ChatGPT aspect of this research is kind of a side note to the root problem – that users are getting infected with info stealers and their relevant personal information is landing in the hands of threat actors. This is the real Bad Thing™ that needs to be dealt with. Yes, threat actors in this example got away with credentials to a chatbot. But what else did they get?
From an organizational standpoint, keeping threat actors out is the main goal. Whether it is them landing an info stealer as here, or a ransomware attack as so often happens, they are trying to reduce the obvious risks to their environment which means staying ahead of patches, using secure practices, and training their users.
Which I’ve said before.
What they said
Unsurprisingly, this got plenty of attention.
It’s not just about the flooding anymore
Research has tied a series of DDoS attacks against Microsoft to a pro-Russia threat actor. The attacks affected OneDrive, Azure, and Outlook and the group suspected of being responsible has ties to attacks that targeted other countries and organizations with a pro-Ukraine stance.
Why it matters
The attacks here weren’t the simple mass flooding attacks that were common in the “old days” of massive botnets that used raw traffic volume to overwhelm their targets. DDoS threats now are often more sophisticated, relying on techniques that leverage the target’s own behavior against it. For example, sending simple queries that take a disproportionate level of resources to respond to. This overwhelms the backend with an excessive compute load instead of just swamping the network.
The threat is even worse when the attacker manages to bypass the content delivery network and delivers their requests directly to the originating servers. While there are defenses against this kind of attack, they’re not as widely deployed as the more widely known defenses against flooding attacks, which increases the risk.
What they said
There’s plenty of concern about this.
How do we make this happen?
Recent reporting has shown that technologists are becoming more interested in developing their projects with an eye toward sustainability and environmental responsibility. However, a large proportion has admitted that they are not actively developing with sustainability in mind, and it is rarely a management priority.
Why it matters
While environmentally sound development practices aren’t often a top-of-mind concern when looking at cyber security risk, there is something to be said for making it a higher priority in this space. The challenge is that software developers have little direct insight into how their development choices affect the energy efficiency of their code. We have enough trouble getting them to develop code securely. Can we expect them to develop it in ways that are energy efficient too?
Stability, functionality, and speed are often the goals for software developers, which are all easily measured and optimized. But how would a developer even know how to make changes that were more energy efficient? And how are they to balance a few milliseconds of response time versus a few microjoules of power consumption?
This does matter. But it may take another level of tooling to actually implement it.
What they said
This is pretty fertile ground for news coverage.
Want to get ahead of the stories?
- Join the conversations as they happen with the Vulcan Cyber community Slack channel
- Try Vulcan Enterprise for 30 days