The ongoing voyages of the Federation Support Ship [REDACTED]
First Officer’s log, Terrestrial date, 20230116. Officer of the Deck reporting.
The technical team at Starbase 998 was able to complete their review of the [REDACTED]’s systems in good time, giving the ship a clean bill of health and confirming our own team had managed to remediate the problem without leaving any unwanted surprises in the core. It did take a few days, but the captain relayed his appreciation to the specialist team for their efforts.
While we were here, we applied our skills to assisting the station with some of their security system integrations, since that was our specialty. And the issue they were having was a common one. While the station had a fully integrated system when it was built, over the years though, between updates, expansions, and station tenants bringing in their own systems, the integration had gotten a bit messy.
We’ve seen similar situations before. Not as bad as the relative mess we saw on [REDACTED] where vendors from three different cultures were trying to integrate with a 4th, but Starbase’s organic growth presented its own challenges.
In this case, they were managing quite well. Though the station’s local security operations unit was having to either Bodge together integrations for new systems or simply deal with having three or four extra consoles to monitor.
In theory, the station’s computer could handle most of the work. Federation computers of the classes installed in capital ships and star bases were borderline sentient. In fact, there had been cases over the years where Federation starships had to deal with the repercussions of their computer becoming fully self-aware.
But the reality was that local procedures and command decisions kept organic operators in the loop, which is where we could help by better translating the different feeds so they could see them all in one place. Different responsible parties would still have to deal with the issues, but at least now the operations team wasn’t having to spread themselves between multiple consoles just to see what was going on.
With that settled, and the ship given a clean bill of health, we set off for our next destination.
I’d call it natural evolution instead of fragility
What happened
A recent report, examining software projects in light of the push towards the Software Bill of Materials (SBOM), pointed to a greater need to properly vet open-source libraries used in development projects. The report noted that some of the libraries they examined had not been updated in up to six years.
Why it matters
The need to vet open-source libraries, or even commercial libraries for that matter, is very real. Vulnerabilities in old libraries can go hidden for years and then aren’t fixed when they do come to light, because no one’s maintaining the code. But this is a normal facet of code development. Projects fork, change direction, or get superseded by newer libraries all the time. It’s the nature of the business and is more natural evolution that an indication of fragility in the open-source model or a problem inherent to using open-source code.
The challenge is for developers to maintain their code as the old libraries evolve, either moving to a new branch if it forks, or finding a replacement if it’s abandoned. Or, alternatively, taking on the maintenance themselves and giving it back to the community. That’s actually how OSS development is supposed to work.
What they said
“Flaws found in nearly a third of applications on the first scan”.
I, for one, question our new Robot overlords
What happened
An increase in the use of autonomous and semi-autonomous robots in the physical security space parallels the increased use of automation in the information security space. Machine learning and other aspects of artificial intelligence are making robotic systems more effective, extending the capabilities of human operators in much the same way AI techniques have enhanced the efficiency and effectiveness of cybersecurity operations.
Why it matters
There are still ethical questions about the use of robots in the everyday world. While ordering kiosks at fast food restaurants and automatic checkouts at big box stores save the companies money, not many people would rather interact with a machine than a fellow organic. At least once the novelty wears off. Plus there’s the issue of machines taking Human jobs, cost savings that aren’t seen in lower prices, and a range of other ethical questions.
The problem is more complex with robotics for security, where people are not exactly thrilled to be monitored by something that looks like a Dalek. In fact, at least one utility company was forced to take a patrol robot out of service in a major city because of strenuous objections from the local community.
Automation has a vital role to play in the world of Cybersecurity. However, when it comes to using robots for real world security, it seems they’re not quite ready for prime time.
What they said
There are ethical and practical questions when it comes to using robots for security.
That’s what “end of life” means
What happened
Vulnerabilities in several older Cisco small business routers, all of which have reached End–of–Life. Cisco does not plan to provide further updates to these systems, most of which have not been sold new in over six years. Users are advised to replace these devices with newer supported equipment.
Why it matters
Devices like the ones affected by this advisory can be problematic. While large organizations can easily budget for hardware replacement before it becomes a critical issue, a lot of small businesses and individuals don’t have the resources to replace their old kit. That’s why it tends to stay in service as long as it does, and you can still find these things for purchase on the used equipment market.
The problem is that end of life kit, by definition, doesn’t get updated. Sometimes a vendor will do a bit of a resurrection act when the vulnerability is especially bad, is being exploited in the wild, and there are still a lot of affected systems in use. But that’s because they’re being responsible, not because they must. When they announce the end-of-life years before, there’s really no excuse for keeping it in production unless there is some very pressing need.
What they said
This issue got a lot of coverage. We published a blog post you might want to read.
__________________________________________________________________________________________________________________________
Want to get ahead of the stories?
- Join the conversations as they happen with the Vulcan Cyber community Slack channel
- Download the “Cyber risk in 2022: A 360° view
” report - Try Vulcan Enterprise for 30 days