Posts by Mike 137 3851 publicly visible posts • joined 10 Sep 2009
The fundamental problem is lack of robustness at the victim end. Ransomware (like any other attack that typically starts at the workstation) only gets to affect a corporation because it can spread internally. There are many controls that can in principle contribute to restricting its spread, but they're just not usually implemented.
Most corporate networks are wide open: a hard-ish shell full of holes surrounding an ultra- soft centre.
The entire problem with electronic transactions is the number of unknown parties that are inescapably party to them. Each of these has a cumulative profile of every person's transactions in some way or other. For example, I assiduously avoid "loyalty" cards, but recently noticed at the foot of my supermarket receipt the statement "account on file" followed by "registration details" and a token, so all my transactions are apparently tracked anyway. And of course my card provider knows the lot, across all vendors.
Long live cash!
Languages are apparently proliferating without bounds and each has its vociferous advocates, but is anyone assessing the quality the actual executables they deliver? That seems to have been overlooked in the scramble to make "development" more "user friendly".
Unfortunately, these Backblaze reports are not at all objective. The results reflect only their own experience and can't safely be extrapolated to drive reliability in general. This has been pointed out several times since their first report was published, and they don't seem to have improved their method. They therefore smack rather more of PR than of real attempts to inform.
The Backblaze method is subject to too many uncontrolled (and indeed unidentified) variables. The only reliable way to generate universally applicable (but even then only statistically valid) results would be to buy large standard size batches of identical hard drives from multiple vendors and run them side by side to exhaustion under identical activity. This would of course be very expensive and time consuming, but it would yield results that the pubic could rely on with reasonable confidence.
El Reg: "Pegasus Mail is said to be affected though it doesn't have a designated CVE – it may be that one of the unidentified CVEs applies here."
The paper: "Similar attacks were found in 2000 for Pegasus... " ref: CVE-2000-0930 (Pegasus Mail 3.12)"
There are no subsequent reports. Pegasus is now at V4.73 (2018) and uses entirely different transport security mechanisms.
Pegasus is, and always has been, generally very robust and bug free, so don't take the Reg's negative implication as gospel.
"Securus claimed the recordings were the result of a software glitch, rather than an intentional act..."
Meaning "Our software is crap so we're not liable"
Similarly:
"We take your privacy seriously"
"it was a sophisticated attack"
"there's no evidence of the data being abused"
"I'm sorry you feel like that"
These and many more amount to the same real declaration, which is:
"we don't give a toss, but we'll say whatever it takes to make you shut up and go away"
This is an almost universal malaise of the current ethical monoculture, based on the assumption that the prime duty is to avoid admitting responsibility for anything at all.
"... allow the driver to fully delegate their driving to the vehicle itself – although they must be ready to take over when prompted"
They never will be ready. Task switching (e.g. from dozily looking at the landscape or texting your mates to taking control of the car) takes many times as long as the reaction time of an attentive person concentrating on one thing at a time. You have to add that to the normal reaction time, so running into the side of a lorry blocking the highway is perfectly explained. As this is "lane keeping", which normally requires attention on busy high speed roads, there's going to be a huge rise in side swipes, and these can be fatal on freeways.
The equivalent technology on planes (heading and altitude maintenance) works well because there's vastly more latitude in the air than on the freeway. Aloft, you have a minimum of several tens of seconds (typically much more) in which to react. On the freeway you have maybe five seconds (often much less).
"...exam docs contained up-to-date material intended to help candidates pass tests rather than learn and understand the course content."
Isn't this the norm? In two decades of involvement in commercial technical training I've practically never encountered any other approach. Quite apart from crib sheets, what on earth can you really learn by attending a one week powerpoint presentation followed immediately by a multiple choice memory test?
"The entire mobile phone industry [...] puts buyers on an upgrade treadmill that requires roughly biennial purchases"
I still use a 12 year old IP65 feature phone with real buttons. The battery is a little tired now, but the phone still works fine. The modern equivalent is half a grand, so I'll be seeking out a replacement battery.
'Decoded's Brown told The Register: "The court is clear that, in themselves, the SCCs remain valid."'
Despite this? The SCCs were created so long ago that they are apparently not fully compliant with the GDPR. That means that as well as including them in processing contracts you have to add additional clauses to cover the omissions.
This has been the norm for decades now. As a consultant I have rarely found any serious attempts at continuous management of security. "Policies" are written but not verified for efficacy or followed, and ISO 27001 certification is often obtained on the basis of an ISMS that exists only on paper or as electrons somewhere. Most corporate cyber security consists of a mission statement and pure luck so far.
"Stop paying and your switch/router goes dumb"
or your firewall stops working (let's just hope it blocks all rather than opening wide).
As so many subscription services are constantly showing, they make running a business fragile. The only beneficiaries are the vendors, who get a constant revenue stream. Furthermore, as "upgrades" (both hardware and software) become an automatic part of the deal, there's even less incentive to get them right as they can be swapped out instead of fixed if proved faulty. So we progress another step towards infrastructure collapse in the name of profit (for some).
I remember when both Cisco and Netgear provided rock solid technologies. Not any more.
Excel doesn't actually change e.g. 'DEC1' to '01-Dec' when your enter it. That's just what it shows the user. It actually modifies the data into the internal clock tick representation of the date (in this case the number 44166). Because of this, if you reformat the cells to "general" and back to "date", it now reads "01/12/2020", which is even further from your original entered data, but is still 44166 internally..
This has always been the default behaviour for anything that looks remotely like a date. It can only be overridden by opening Excel and then importing the data. At that point you get to specify how it's to be interpreted. We had this problem once when analysing a c. 10,000 entry password dump - almost half the passwords were corrupted by Excel.
Lack of attention to detail, which is unforgivable in a pen tester. One time when selecting a pen testing service for a client, I failed an otherwise perfectly respectable service because their technical representative answered a critical question incorrectly. The question was "what is your first step on receiving the list of IP addresses to be tested against?" I forget his exact answer, but it wasn't "check that they're all really yours".
Apparently no mention of improving software development standards though. I would have thought that reducing the prevalence of exploitable bugs might be a better long term strategy than simply expanding the base of folks approved for find them when it's rather late in the day.
It seems that we have been brainwashed into accepting that software is fundamentally broken and needs constant fixing to be "secure". How about trying to get it right instead? Particularly in domains such as voting, flight and medicine, that seems to me somewhat desirable.
Probably trying to keep the commercial ball rolling by producing new stuff. However the one thing they've never done yet is produce adequate documentation. This might be partly explained by the declared approach to designing this keyboard - reverse engineer someone else's kit and then proceed by trial and error. This is not robust engineering practice.
Actually, it's not any kind of loss to the taxpayer (at least not directly). The ICO is not funded from taxation (to avoid any suggestion of conflict of interest if it takes action against a government entity). Nor is it funded by fines (to avoid any suggestion of vested interest). It's funded from the registration fees, which, although not proportional, are scaled in accordance with the size of the registrant organisation.
Given this position, going after large companies has clearly nothing to do with revenue for the ICO, but it may be good for raising its profile, and that could well be necessary if the ICO wants to remain recognised by the EU. That in turn could at least unofficially affect whether or not the UK gets its adequacy decision swiftly (or indeed at all).
The UK Information Commissioner has publicly declared that the ICO will concentrate on going after the big offenders and aiming for large fines. This is clearly good for raising the profile of the ICO, but it has the following disadvantages:
[1] it preferentially selects those best equipped to challenge any action against them
[2] it consumes resources on a few cases that might otherwise be applied to dealing with large numbers of meritorious complaints
[3] it does not deter the majority of offenders as they consider themselves under the radar.
Only by pursuing a reasonable percentage of the majority-scale abuses will the legislation ultimately be made to stick. For example, I've been conducting research into the quality of privacy notices since May 2018, and out of hundreds I've only found literally a couple that actually comply with the requirements of the GDPR. Somewhat surprisingly, the ICO's own template privacy notice for SMBs doesn't. It requires all the statutory information, but presents it in a manner that prevents the exercise of data subject rights in respect of specific purposes and processing. This is not trivial. The privacy notice is the primary basis on which a data subject must initially rely to exercise their statutory rights. If it prevents them doing so, that is itself an offence under the principles of transparency and accountability (inter alia Articles 5 and 12).
"so why aren't people doing it?"
In my experience, because once the "cloud" is adopted, the internal folks who previously managed security are typically "let go".
One of my clients a while back actually TUPE'd its entire IT staff to the cloud provider they'd contracted with, expecting to get the same level of attention from them as when they worked exclusively for that client. Of course, my client was just another contract among many under the new arrangement.
I had the unenviable job of trying to sort the mess out, and the only way would have been to engage an on-premise tactical IT security management team to oversee the outsource. However that thwarted the purpose, which was to minimise the IT overhead on the balance sheet.
You get no more security than you deserve.
Yes AC, that's the message. But centuries of experience have shown that giving people false confidence in the face of a real threat doesn't mitigate that threat. It may even exacerbate it.
At least as late as the 1960s, high court judges carried a posy of flowers into Court. This originated in the 18th century from the mistaken idea that the scent protected against "gaol fever". It didn't. Neither did the amulets people wore protect against the great plague in the 14th century. Both gave them confidence but they died just the same.
"...many spectacle-wearers steam up ..." just shows how ineffectual arbitrarily designed and fitted cloth masks are. The air (and therefore potentially the virus) is not being filtered through the mask, it's rushing in and out round the edges without being filtered.
There are numerous objective studies that show the type and the fit of a mask are crucial to whether it works or is just a complete waste of time. However the public are told not to use the types that do work, but instead to use the types that don't. This is not based on science - it's based on a desire to demonstrate to the public that the powers that be "take COVID seriously" in the face of a problem that nobody can in reality be entirely in control off. It might be better to admit that openly.
Open. This is inevitable, so open shared infrastructures should not be used where their openness can lead to hazard. I would have thought this was blindingly obvious. Not for nothing was frequency hopping point to point radio invented and widely used for secure communications before the "smart phone" took over the planet.
Apparently only hard violence is acceptable.
It's worse than that. MS mail clients don't even generate plain text parts for HTML emails properly. It obviously uses the HTML as the source and incompetently strips out the HTML tags. Incompetently because it ignores line ends that immediately follow HTML tags, leaving them in place. Consequently the plain text part includes masses of vertical white space, making it very hard to read and impossible to print without copying to an editor and reformatting.
Looks like they just do a linear search, deleting everything between '<' and '>' inclusive, but this is such a simple problem to solve: just check whether there's a CR/LF (or whatever alternative line end) immediately following the '>' tag close and if so delete that too. Might have to allow for white space between the two, but that's not hard either. They obviously haven't heard of regex (or at least they're not very good at it).
"It is completely predictable that the Russian Intelligence Services are targeting those working to combat the coronavirus pandemic,"
The Russians have been messing with our (and many other nations') social, scientific, economic and political life for over 200 years. We should expect that as it's part of the culture.
"... never sought my consent to share my details [...], which is a GDPR violation"
Not necessarily. Data sharing may be performed on several alternative lawful bases, of which consent is only on unless the data falls into the Article 9 sensitive categories. Consent would only apply if that were the lawful basis declared by the data controller as being relied on for the specific purpose.
Of all the lawful bases, consent has received the lion's share of press, and therefore public, attention, resulting in a common but mistaken assumption that it is mandatory in all cases. Indeed if another lawful basis is legitimately relied on, consent can not be invoked, as only one lawful basis can be relied on for each specific purpose.
Actually it's a myth that cockroaches can survive nuclear radiation. They're protein based just like other organisms and the proteins get scrambled just like eggs. What is true is that any cockroaches that succeed in surviving (by e.g. being protected in basements &c.) will swiftly take over as [a] they're scavengers and there'll be a lot to scavenge and [b] they breed "like flies".
"While there was code preventing the printer head from exceeding 261°C (501.8°F), Coalfire claimed it was able to bypass it"
Relying on a software controlled thermostat alone seems fragile. When I was designing and building high temperature equipment, we always built in at least one bimetallic thermal cut-out so everything would shut down before anything caught fire. They cost no more than a couple of dollars in one-off quantities (much less in bulk). Obviously the makers didn't think of this.
"... If it's likely that there will be a risk then you must notify the ICO ..."
What a muddle! Of course there's always a risk - the real question is what the level of risk is. And of course likelihood is one of the two parameters of risk - the other being consequence, so "likelihood of risk" is both specious and tautological.
Official guidance should be neither, so why does the guidance not say something like "if there is a high likelihood of significant harm to the rights and freedoms of data subjects..."?
Maybe because the use of the term "risk" in the vernacular has always been utterly sloppy and even risk professionals in general don't seem to use a consistent definition of it. It's about time we did.
I remember a public presentation by a well known data protection consultant, who said "your privacy policy is PR". And so it seems for almost every Europe relevant privacy policy we've examined in the course of a couple of years of research. Less than 0.5% have been even broadly compliant with the GDPR and literally only a couple have essentially been fully compliant.
Making it part of normal induction probably wouldn't help that much as normal induction is generally a perfunctory exercise run from a checklist. One time training won't stick either. Unless the entire corporate culture is security aware, nothing will really help. A lax culture breeds lax habits, and most corporate cultures I've encountered in a couple of decades of risk consulting are lax. Even "standards compliance" is rarely more than a paper exercise to satisfy periodic audit.
Just for example, "don't click on links" doesn't work where the Board regularly circulate emails containing links to documents "all staff must familiarise themselves with". Expecting a busy non-technical staffer to be able to distinguish between a genuine email from the CEO and a bogus one is pie in the sky.
However it shouldn't be possible for malicious code run at a user's workstation to spread throughout the infrastructure. Setting up and managing your infrastructure so it contains breaches locally rather than letting them spread globally is not beyond the realms of possibility. But this is rarely done, witness Equifax among many others. The fundamental problem is not expert adversaries, but inadequate defenders.
A well known international standards organisation does this all the time, and I'm certain that they're not using a manual process. The big problem seems in general to be that marketing and "communications" folks don't get (probably don't ask for) technical support for mass mailings, they just treat them the same as internal communications because nobody gets training in using email clients so they don't know what they're actually doing technically, or its implications.
It's a weird notion that an algorithm is something [a] conceptually new, [b] necessarily complicated, and [c] impossible to explain.
Every single piece of code ever written is a realisation of some algorithm (even Turing's machine). The fundamental question is whether the algorithm is understandable. if not, it's a bad one. Implementing things you don't understand is dangerous.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
