Pretty much all the headaches at MSPs stem from cybersecurity Managed Service Partners (MSPs) say cybersecurity dwarfs all other main concerns about staying competitive in today's market. Adding to the already notoriously strained existence of an MSP is work that even folk in the infosec industry struggle to keep up with, and leaves those looking after client systems and IT struggling to …
I'd hope their employers don't expect them to sign on with their private email addresses as IDs which is what is likely to be harvested along with the password. Also require a minimum password complexity greater than what they'd use elsewhere.
Also an easily guessed users ID such as initial and name is not good for more than one reason http://www.bloodwolf.org/~rulnak/jdr/jokes/Dilbert/Dilbert_pictures/dilbert_BrendaUtthead.gif
I would like for every person who thought that email addresses make for good user IDs to have just one face, so that I could slap them all at once.
Some ten years ago I had to get rid of my primary email address. It was a nightmare. Some services contemplate the notion that a user may need to change email address. Many don't.
Some services I just had to shut down and restart with the new email. One service that was too critical to do that, I spent days with customer support, and it still sometimes exhibits signs of login-related borkage to this day.
If I had a dollar for all of the excel spreadsheets of passwords I have seen exposed publicly. A simple google search for "passwords filetype:xls" or "passwords filetype:txt". I see less exposed than I did a few years ago. Not sure if that can be attributed to better security or poor results.
As an architect I find it pretty hard a) to achieve and b) to keep a solution simple over time - even if this strategy is very successful in terms of factual security achieved.
Components that are not active, cannot be attacked - components that are not even installed are even better.
Simple components with fewer bugs are harder to attack than large, complex components with may bugs.
Simple components are easier to fully understand and defend for your own staff.
So solving this "Level Zero Challenge" will help in resolving important aspects of challenges 1-3 from the article.
However, selecting the fewest, most simple, most stripped-down components for a given task often frustrates developers, as it means they often cannot use whatever code they are used to or example code they found on the Internet (often promoting certain products) to solve a problem.
It also frustrates customers as well, as not grabbing the next-best, halfway fitting COTS-product/library and "add it to the mix" will result in longer development time for new features and potentially higher inital cost.
And arguing with security still often is an uphill battle against cost and features...
M$ used to provide detailed server hardening guides. Then they moved to instead providing scripts that could be run blind. Now we have auto-update. So as the threat landscape has become more severe we've been granted progressively less control over our attack surface. This doesn't seem the ideal way to go.
Funnily enough, just yesterday I gave to my wife the one remaining clutch pencil in the top left drawer of my desk.
With that pencil, and several others very like it, in the 20th century I and the staff of my drawing office produced thousands of engineering drawings and documents.
Those documents are still safe in the cabinets and on the shelves in my office, still completely unaffected by any and all network-borne attacks.
True in the sense that components, that are not active (e.g. services that are not started or modules that are not loaded) can still be exploited as part of a local attack path for example to elevate access after any initial successful attack makes these components available to an attacker.
However, as installed, but inactive components they do not create any additional remotely exploitable attack surface on their own, which was what I meant.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
