Summary: In Sirius ‘Open Source’, neither Open Source nor security got taken seriously enough. Siriusly! And one cannot point this out to managers as this infuriates them (it harms a false perception they’ve long cultivated).

TODAY we turn our attention to bad security practices, including poor privacy and unbridled outsourcing of Sirius. There will be numerous parts about these aspects and we’ll provide some examples in the future when dealing with proprietary software, introduced by the company itself while tearing down its very own Free software-based infrastructure (which had been put there when the company still had geeks in the office; heck, the company used to have an actual office!).

Suffice to say, patching is part of the work, including patching one’s own machine. Anything else would be irrational (like blasting people over “commuting” time) because security starts in one’s own domain. And yet, I was being told off by the company’s founder for patching my PCs while I was on shift despite the fact that there are several such machines (if one encounters an error, then one can rely on another machine) and this is about actual security.

It took me a while to find E-mail regarding this, as it dates back nearly 4 years. My redacted response below:

I have just caught up with E-mail (resting and other things since 9am).
Sorry for the delay in responding.

Roy,

I have read your shift’s handover notes where I find this from you:

“Quiet shift, so I took the time to update my whole system. Something broke nagstamon for me, briefly, but I managed to fix it. In the meantime I used the Nagios/Icinga Web interface.”

I use 3 laptops in parallel to do my job, so this was one in three and Nagios remains accessible regardless. nagstamon is an alternative to it (sound alerts) and I wanted to bring it up to date for security reasons. As I do often, to avoid breaches.

This is *absolutely unacceptable*.

If I cannot observe systems that are monitored and supported, it’s not “unacceptable”. It’s still very much necessary. But still, looking back, there are many serious (Sirius) issues that were shared in the report below (more to come in the next parts).

Acronyms Lingo

Speaking of “GDPR” or “ISO” without even grasping the meaning behind laws and regulations is “cheap talk”. Without comprehension of the issues, this boils down to ‘name-dropping’ (like “GDPR” or “ISO”). Currently, the company would gladly take technical advice from people who openly admit they don’t care about privacy. So instead Sirius falls back onto formalities and processes rather than any real grasp of the underlying issues. Sirius track record will be demonstrable based on recommendations from past clients; with or from at least two clients we might only get an alarming reminder that their systems suffered a security breach while we supported them. The clients’ names are, as usual, omitted here, but this is very well documented. There may have been more security incidents that were hidden or concealed both from clients and from Sirius staff. Considering the atmosphere of secrecy and hostility towards inquisitive staff, it seems likely more incidents occurred but weren’t reported at all (or reported very selectively).

Speaking of formalities and processes rather than actual substance, the company Sirius was pursing ISO certification only amid some issues with NHS and its highly sensitive medical data — including several incidents staff witnessed where people’s (patients’) privacy was accidentally compromised, either by Sirius or by the client (personally identifiable data divulged). To make matters worse, many times data was not being shredded like it was supposed to and the client complained. If better leadership was in place, this would not have happened, jeopardising the credibility of staff.

Account Management Practices and Data Sovereignty

With quite a lot of clients, and several can be vividly recalled, Sirius failed to remove access credentials (or accounts) for staff that had already left Sirius. ‘Low level’ staff cannot access systems at a level of user management, so this was demonstrably a ‘high level’ failure. Sometimes clients complained about such gross incompetence (if clients could even figure out who still works for Sirius; remember that Sirius misled them, as shall be noted again later) and potential security breach by former and possibly disgruntled Sirius staff, but nobody (as far as we know) was being held accountable. The aforementioned sections noted that accountability only ever works in this hypocritical and vertically-inconsistent fashion. Double standards became the new company standard, enshrined covertly but not formally. Managers never offered the courtesy of taking full responsibility. Too much pride to acknowledge mistake and lapses.

As the above shows, there are endemic problems caused by mismanagement or a lack of charismatic-yet-humble leadership (maladministration), maybe even a lack of staff that possesses ample experience managing a team of more than one person. These are very essential skills which mandate suitable recruitment. It may not be cheap, but it is vital.

Sirius has user credentials scattered all over the place, not all in OpenLDAP as done in the past (when more competent people managed the company’s infrastructure). This will, inevitably, result in epic blunders. That keeps happening. Again and again. In fact, user credentials management at Sirius has been partly outsourced to third parties — a taboo subject. No more GOsa, go USA (most data and authentication sent across the Atlantic).

The motivations seem petty, e.g. sharing accounts to save money despite clear security requirements that exist to explicitly not do this. Is ISO being treated as merely a box-ticking exercise, not followed up by any potent audits? If so, are we entitled to brag about some ISO compliance? Any time Roy attempted to bring up the subject the management became paranoid and threatening. This sort of resistance to ethical and moral objection would be strongly discouraged in companies capable of self-appraisal.

A colleague once mentioned in an E-mail that some colleagues may have needed to share an account with another person, all in the name of saving money. This kept happening for years despite such ISO requirements supposedly being fully in force. Account sharing was sometimes imperative, as individual accounts did not exist. In other words, all colleagues use the same username for some tasks; sometimes this was only belatedly addressed, partially and virtually post hoc.

Password management in the company has long been a painful affair. From non-secure connections to a lack of VPN for access to passwords the company moved to outsourcing. This was a case of “bad optics”, pragmatic issues aside. Sirius could self-host similar software that was Free and Open Source software, but the company had a mindset of outsourcing almost everything to proprietary offerings from another country. As noted separately, Roy raised alarm over this several times, noting or pointing out actual data breaches of a very large scale, but no action was subsequently taken. The assurances were empty and arguably arrogant — a refusal to listen to vigilant security experts who extensively covered those issues for decades. Asking a company itself whether it suffered a security breach and what the severity truly is like asking an American president what happened in the Oval Room.

The Manchester experience, going ‘online’ for ‘apps’ (so-called ‘self-service’) because who need services anyway?

With “mom” at Manchester Town Hall

IRST time? My bad. Second? Your fault. Unlike the old saying, “fool me once, shame on you…” (twice… me)

What’s all this commotion about? Is it about privacy? Accessibility? Adherence to law? Or all the above?

Right about now many rules and laws are flouted and violated. In the name of “emergency”… a public health crisis. Perfect justification?

Courts have apparently decided that the equivalent of a telephone call is “trial”; governments are waging an accelerated war on cash, as well. I often wonder if here in Britain we changed the coins (rendering old ones worthless and obsolete) to artificially reduce the money supply; it would be helpful to know how many “old coins” there are compared to “new ones”. The thinking is, maybe they try to impose financial surveillance by “going digital” with scarcity of physical money added to the mix… or removed from circulation.

What’s wrong with digital payments? Apparently a lot of people don’t know or never really thought about it, even in this age of so-called ‘surveillance capitalism’ and mass surveillance without warrant, let alone suspicion or probable cause.

Many who reject digital payments (or “smart” or “touchless” or whatever buzzwords they make up next year) are being framed/painted and sometimes ridiculed as Luddites. That’s kind of funny considering the fact that it’s usually the most technical people who reject technology in payments (so-called ‘novelty’ like “swiping cards” that are little but a piece of plastic with a primitive, cheap chip glued to them). All that insecure chipping and pinning is hardly novel; it’s decades-old ‘technology’ (same for so-called ‘smart’ meters and ‘self-service’ checkout; it could be done decades ago, including the touchscreens, in effect an erosion of customer services or outsourcing of the work to customers).

In reality, it’s the ‘non-techs’ who swallow it all, thinking they’ll seem “techy” for swiping and paying $2,000 for a so-called ‘phone’, compensating for their lack of understanding of where all that data goes and how it’s (mis)used.

The deterioration of our lives is now driven by technology; we were promised technology would make things easier (like doing our laundry, shortening the working days/hours etc.) but in practice people work harder and for longer hours than ever before. People are even being contacted by their bosses well outside working hours. Is this progress?

This brings me to the latest rant. On December 10^th 2020 my wife and I went to Manchester Town Hall (temporarily housed partially in Heron House across the road, below GCHQ, as he main building undergoes renovation/overhaul). We went to their office, as explained in the official site, at the specified time with all the documents and a laptop (as required for communication and exchange of details), only to be told the service is not available due to COVID but can instead be done at the Post Office.

Alright then…

So we went to the Post Office, only to be told they don’t do any of that and at least two people had been similarly misdirected earlier in the same day!

What on Earth is going on? ‘Ping-pong’ with people?

So we went back to Town Hall, only to face a different person, who barely even apologised for the misdirection and used “COVID” as a catch-all excuse, instead suggesting contacting the Home Office or urging us to use some Android “app” (which is out of the question).

What if we were disabled or blind? What about options that are paper-based?

This is a terrible regression which actually predates (in part) the pandemic. An “app-only” government would be a travesty for many reasons; like rendering you a non-citizen for refusing to carry around a so-called ‘phone’ that tracks your movement more closely than RFID.

Is COVID a valid excuse here? Hardly. Because apparently, according to information we received from a representative at the Town Hall, this has gone on since March and there’s no projected date or resumption. According to our solicitor, the whole “app” thing was already pushed well before March. They literally want people to take selfies of themselves and then send that to the Home Office, then send sensitive documents over ‘phones’ with back doors.

This isn’t the future; this is not “innovation” but degradation of services spun as “smart” and convenient.

Nothing is as convenient as an informed person interacting with you, dealing with the papers for you, checking the authenticity and ensuring everything is done properly right there on the spot.

I am not a lawyer, I don’t know the pertinent laws and sections, but I know enough to say that the government cannot demand people do those sorts of things with “apps” or digital devices. There must be a fallback. Leaving people ‘hanging’ for almost a year citing “health and safety” cannot be excused because of the COVID-19 pandemic; for several months during summer people could go to pubs and restaurants, so surely Town Hall could facilitate face-to-face (with masks on) meetings.

I will carry on chasing Town Hall next year and will report again.

am an early adopter of Detexian, a service which I increasingly rely on for security. My wife and I run a small media entity which attracts about 5 million hits a week. The sites are TuxMachines.org and TechRights.org. One of the sites is modest and non-confrontational, whereas the other one (the latter) is more controversial because it is critical of activities such as bribery, illegal surveillance, and all sorts of corruption. There are certainly people and organisations that are willing to spy on and undermine the site. Some of those who get criticised are large technology companies and institutions they work with.

We cannot keep up with logs because we are a small team and we cannot properly analyse these for security threats. It is just infeasible. For analysis of logs we also require a service which is isolated from surveillance-intensive hosts such as Amazon. We moreover operate on a very small budget as the sites are public services rather than for-profit.

We now rely on Detexian to inspect the traffic and generate concise reports. Detexian helps to avert disaster or alert about troubling patterns in activity before disaster strikes or flaws are found/exploited. TuxMachines.org and TechRights.org are not young sites. They have been around for nearly a decade and a half; over the years we have suffered more DDOS attacks than we can remember and there were also intrusion attempts (none were successful). Some attacks managed to cause damage, but it was always repairable. Recently, Detexian alerted us about SQL injection attempts and made recommendations.

We shall continue to rely on Detexian in the foreseeable future and are happy to pay for the service knowing that someone “has got our back” and is providing informed advice on how to guard the sites.

hen oil rigs/platforms sink (recall this incident) a lot of people die. When gas pipes explode a lot of people can die as well. In the case of BP, Microsoft Windows was at least partly to blame for the incident (I wrote about this many times at Techrights) and the above, just (re)published by Wikileaks, makes one wonder where the US derives its moral high ground from. This shows the importance of using software one can truly control and always trust, such as Free/Libre software.

And SUSE has not yet said anything about it (to publicly acknowledge this), it seems to have restored from backup or removed the defacement

Click to zoom

y experience patching Drupal sites is years old and my general ‘policy’ (habit) is to not upgrade unless or until there is a severe security issue. It’s the same with WordPress, which I’ve been patching in several sites for over a decade. Issues like role escalation are not serious if you trust fellow users (authors) or if you are the sole user. In the case of some agencies that use Drupal, it might be safe to say that the risk introduced by change to code outweighs the safety because as far as one can tell, visitors of such sites do not even register for a username. All users are generally quite trusted and they work closely (one must have checked the complete list to be absolutely sure). There is also ‘paper trail’ of who does what, so if one was to exploit a bug internally, e.g. to do something s/he is not authorised to do, it would be recorded, which in itself acts as a deterrent.

If the security issue is trivial to fix with a trivial patch, then I typically apply it manually. When the SQL injection bug surfaced some months back that’s what many people did for the most part. For larger releases (not bug fixes) the same applies, until there is no other alternative. What one needs to worry more about are module updates, especially those that are security updates. One should make a list of all modules used and keep track of news or new releases (watching general FOSS news is usually not enough until it’s too late). Thankfully, detailed information on what the flaws are becomes available, along with associated risks both for core and additional/peripheral modules.

Then there’s testing, which I guess one needs to do for any changes that are made, assuming time permits this. The last major Drupal flaw had a 7-hour window between publication and exploitation in vast numbers (maybe millions). It means one cannot always follow the formal procedure of testing, albeit testing in an ad hoc way or minimising the risk by applying a patch ought to work well. This leads me to suggesting that developers don’t need to have one uniform workflow/process for changing Drupal but a multi-faceted one. Proposal:

If the flaw is

1. severe
2. not back-end (i.e. not related to role management)

consider the complexity of the patch and test immediately on an existing copy of the site, then deploy on ‘live’.

If the patch is a core patch, no alternatives exist. If the patch is to be applied to a module, study the effect of disabling the module (assuming no dependents), consider temporarily keeping it out of reach (public site/s).

For less severe flaws:

1) merge into git on a dedicated branch
2) test on a local vagrant installation
3) schedule for deployment to “development” for testing
4) schedule for deployment to “staging”
5) run regressions (one needs to define these)
6) Client to do any required acceptance testing
7) schedule for deployment to production.

Suffice to say, the changes should not only be made through git (not directly) but a database dump too (or snapshot) should be taken, both for quick fixes and for longer testing purposes because even if changes are revoked (git rollback) the database can be left in a sub-par/inadequate state.

Regressions of interest for Drupal are not just site-specific. There are some nice templates for these and one needs to consider which modules to use in the site. Intuition and general familiarity with the CMS loop/hooks help one predict what impact a change would have on modules, if any. Drupal has good documentation of functions (by names), so these too can be studied before changes are made. To avoid some modules ‘silently’ breaking, following any change to core (or even modules) one may need to go through a list of tests. specified in advance, that help verify no module spits out PHP errors or behaves oddly. It is common to test critical pages first, e.g. finding an authority, research reports, etc. Sometimes it should be possible to also automate the testing by basically making local snapshot of pages of interest and then diff‘ing them after changes are made, using sophisticated tools like Versionista or a manual side-by-side comparison by a human operator. There are browser extensions that further facilitate this, but caching such as Cloudflare, varnish cache etc. can impede this process (even though changes to underlying code may invoke an override, at least for varnish).

Regressions are nice, but in many cases developers don’t have time to run them and a simpler set of manual checks can help gain confidence that changes made have no detrimental effects.

I cannot recall ever having major issues patching (as opposed to upgrading) the core or WordPress and Drupal and I have done this hundreds of times. The quality of testing when it comes to core (not external/additional) is quite high, but another worthy step is, before making any changes, look around forums to see what experience other people have had. There were cases where patches were problematic and this quickly became public knowledge; sometimes workarounds or patches for the patches are circulated within hours.

Background reading

• Behat testing
• Regression testing

ITHOUT a doubt, there are circumstances where evidence extracted from CCTV is valuable. For instance, if there is a street/pub brawl, one can use footage to verify or falsify eyewitness accounts or the story told by those involved in a brawl.

For the most part, however, CCTV fails to justify its great cost, not just monetary cost but also the cost to our civil liberties. Today I got a good reminder of that.

Having spent nearly an hour speaking to security personnel and the local police, I found that CCTV did, in fact, capture the stealing of my hybrid bike (retails at around £500) roughly two hours ago. This was captured because I only ever park and chain my bike to solid objects like designated bike rails in front of cameras and in the presence of many people.

Not only did several cameras capture good footage of my bike being stolen but also the store manager (the store I was in for just 10 minutes) was at the parking lot witnessing the crime. Was that enough to prevent the crime? No. To capture the perpetrator? No. To return the stolen bike? No.

The perpetrator wore a hoodie, so it is hard to identify him (the footage only identifies him as a black man in his mid-twenties, to quote security personell who investigated it). It is too early to assume that the bike won’t be returned and the perpetrator caught, but the matter of fact is, CCTV, as I long argued (for many years), does not help prevention and rarely helps identification.

If the perpetrator is very naive, in which case he or she is removed from the scene early on, then it might work, but the hard cases cannot be resolved by CCTV. All that can be achieved is the confirmation that a certain crime occurred and in cases where an insurance agency is involved, it may help prevent insurance/benefit fraud. My bike was not insured. I don’t know any people who buy bike insurance.

Surveillance tools which are run and owned by the state (or law-enforcement agencies), as in CCTV, are not there to protect and arguably they do not serve as a deterrent either. They are probably not worth the investment. More people need to be on the ground, creating more jobs and adding to real security, not sci-fi pseudo-futuristic security theatre.