Re: What's the problem....
My reference was Australian regulations. The point is that these regulations are widely accepted as a 'good thing' for a good reason.
189 posts • joined 22 Dec 2007
Smart heaters? Smart ovens?
Botnets created from rooted routers to take down critical infrastructure.
My point is that we actually have reached the point where insecure devices can cause harm and destruction and we need to start thinking about that because there are billions of them out there.
Now electrical equipment that is plugged into the electrical grid are expected to be safe. There are regulations in place that attempt to protect consumers, and the grid, from unsafe equipment. The electricity grid has safeguards built into it to minimise the impact of unsafe equipment. I don't think anybody thinks this is a bad thing.
So why such strong objections for equipment plugging into the RF grid which, I think, lacks the kind of safeguards that apply to the electricity grid.
We know that all the gadgets being plugged in are completely fucked. They are full of bugs and are actually dangerous when you consider how they can be exploited. So this legislation is basically saying you need to be compliant before you get on the grid...just like electrical equipment, just like cars before they get on the road, just like aircraft before they carry passengers,..... I don't hear objections in these cases.
Is this really so bad?
Cue down votes.
The last link given in the Reg piece goes to a neat piece of research that used adversarial examples thrown at an image recognition application to conclude that it triggered on texture rather than shape.
This highlights the real problem...they do stuff but we don't know how and as a result have no idea how they will behave if the input goes off-piste. So, dressing a wolf in sheep's clothing actually works with the current technology.
Probably similar timeframe - VAX 11/780s in late 1970s. Kill switch next to a phone on the wall... Engineer makes call on phone, leans against wall,.... lights out!
Same installation. Telecomms 'electricians' removing a cabinet. Not sure if power is off. Large screwdriver between active and earth shows, momentarily, that power WAS on, lights out once again.
Some air-conditioning fun from same location if On-Call is interested in that sort of thing.
As far as I understand it they segment the network so that if Internet access is required for work purposes then you (the employee) have internet access. if Internet access is not required for work purposes then no access. This includes email. Devices with Internet access do not have access to the protected segment.
There are many roles that do not require Internet access in an organisation. Technical roles are often considered an exception but there are ways that this can be minimised.
Indeed, and the western world should probably follow Singapore in removing Internet access from most public service accounts. They committed to this in mid 2016. See this commentary related to this incident:
Interestingly there is an opinion from Marsh LLC, part of Marsh and McLennan who are in the same business as Zurich and about the same size as Zurich, that is was NOT Cyber War.
I would have thought that contributory negligence - failure to patch - would have been the tack used by the insurance companies.
Actually it shows that people do not think the investment companies make in developing ground breaking technologies and turning them into a successful market should be returned to those companies along with a profit. This enables them to pay the researchers and continue their research and so continue to employ and pay researchers.
So Qualcomm owns the patents, there seems to be no dispute about that. Ownership of the patents provides control over the use of the technology. Qualcomm exercises those rights to maximise it's revenue, as you would, and then has to defend itself in civil court because it holds some really good patents.
Does this sort of shit happen in other domains, Pharmaceuticals for instance?
I read somewhere that taking a dump in an Apollo capsule involved the use of a carefully positioned plastic bag on the part of the dumpee. The remaining two crew got as far away as they could during the process. If you have seen one of these capsules you soon realise that 'as far away as you can' is a pretty meaningless concept in these circumstances.
...just imagine how much innovation will be done one these platforms...
How is 'innovation' quantified? Innovations per second? A metric fuck-ton of innovation? And is there a one-to-one correspondence between 'innovation' and 'disruption', we need to measure the inevitable 'disruption' as well.
Can the El Reg Units desk help out here?
How easy is it to hack a fax machine anyway?
Not that hard apparently. There was a lot of press about it in August of this year. A lot of them come bundled with MultiFunction Devices and you have to tweak a few configuration options to stop them being used as a path into the internal network. This has been the case for quite a few years now.
I've run security at a utility subject to the sort of controls described here. You have to get your proposed budget through your management plus the external body controlling prices. In my case this was an exercise you performed every 5 years, you were bidding for 5 years money, so a lot of educated guessing was involved in the guise of 'strategic planning'. Note that the submission to the external authority includes everything the utility does so the security budget is at best a single line somewhere with external material to justify it. My modest budget was still cut internally due to overall limits on opex rather than capex. Another (more critical) utility subject to the same process had their security budget savaged by the regulator.
I found the main problem was head count. For the size of the team we had enough money to run all the projects we could handle and we could get contractors in for project work. Getting a head count increase was a different matter entirely.
Let's look at some of the things the 'top professional team' will do.
* Originate emails from compromised accounts. The sender information is completely valid and if the address book and Inbox/Outbox are used to select recipients they are used to receiving emails from the compromised sender. Going a step further, they may be used to receiving emails with links from the trusted (but compromised) sender.
* Use a valid domain where the domain owner has not implemented any countermeasures such as SPF or DMARC. A major bank had such a domain, it was regularly used for phishing attacks, they never used the domain for customer emails but the customers didn't know that.
* Use non-standard email headers to trick the email client into presenting an external email exactly as if it had been sent internally. The displayed From address is a valid internal address, all adornments applied to internal emails are present, visually perfect.
* Time emails so that they get into the recipients Inbox at the start of local business hours. They get actioned quickly when the user starts work. Volume sent is small to make them harder to detect, 10 or 12 is enough.
* Use information gleaned from the Internet to make the Subject and content more convincing. An online job add was used to provide context in one case, anything out there will be used against you.
This is just a small sample. The top teams are highly skilled and they will take care in their targeted attacks. Your walls don't really exist. The recipients, the users, are way out of their depth.
Your office soccer team (imagine you have one, any other team sport will do) gets a game against a top professional team. They get thrashed. Management decides awareness of the rules will help and the whole office gets training. There is a rematch with the office team. They get thrashed. The office team is taken to one side and given two days intensive awareness of the rules and tactics before another match. They get thrashed.
So it is with security.
The security industry has realised that the People side of the process hasn't really been fully milked yet and the technology snake oil is starting to wear thin. So this is where the new focus is.
The office team will never beat the professionals. You have to change the rules to do that. But organisations don't have the balls to change the rules. Restrict Internet access for example, only allow business emails, segregate areas of the business that need unfiltered interactions,... All technically possible. Then look explicitly at how Process and Technology failures can impact you and implement countermeasures.
Don't put the weakest link on the front line.
@ Dave Pickles
When Win NT was first released we were doing side by side comparisons with VMS and two things that Cutler didn't bring over were puzzling. First up Logical Names which gave you a level of indirection for practically everything along with protected name spaces. Then there was the big omission of Installed Images that allowed privileges to be assigned to trusted pieces of code (amongst other things, sharing, fast startup etc as well) removing the need for users to have privileges. Both were probably out of place in a PC operating system.
Once upon a time....there was this sudden push to go 'Agile'. This was OK but having spent a bit of time in the process improvement space I started asking some questions. These were along the lines of 'what is wrong with the current methodology', where is it failing; 'what do we want to keep from the current methodology', where is it working; and 'how do we measure success'. After a lot of ducking and weaving it came down to 'HR think we will not be able to recruit young people unless we are 'doing Agile'. And DevOps is different because...
The Reg piece suggests that the appropriate authorities were notified and that they made the determination that there was not a real risk of serious harm to the CBA customers involved.
Note that it is not there is a distinction between 'harm' and 'serious harm' that was made deliberately to minimise the number of breaches that needed to be reported.
The explanatory memorandum that accompanies the legislation makes quite interesting reading in this context.
Almost certainly not the software although the software migration could be non trivial if the code relied on long deprecated low level run time functions.
The other factor to consider with the hardware is not just reading the stuff but being able to write it to something your more modern hardware can handle.
With just in time manufacturing you could get quite specific. And if you stuffed something in the BIOS then infecting everything is no big deal. Compromise the machines you are potentially interested in at source. You just need a listening device not another machine in the same room and you can build that into the wall.
Biting the hand that feeds IT © 1998–2019