I wasn't expecting much of this, but (apart from the irritating graphics
and spurious code), I was quite impressed. Good interviews with some
seriously smart people, and well edited together into an interesting story.

On Tuesday, January 17, 2017 at 10:34:38 PM UTC, newshound wrote:
I wasn't expecting much of this, but (apart from the irritating graphics
and spurious code), I was quite impressed. Good interviews with some
seriously smart people, and well edited together into an interesting story.

A bit OT for d-i-y but we did got a plug for the Mossad history book: "Spies Against Armageddon".
That the Iranians could open a sluice gate on an American dam (albeit they chose just a little one) was a tad worrying.

rusty

Yes it was good in that it could actually hold up as a radio documentary in
my view. I enjoyed it with no vision.

It is now rather more obvious why relations between use and Israel are a bit
strained for some years. Not only did they try to force the US into getting
involved with military action, when they used the hack, they changed it
without anyone telling the other parties. Talk about shooting ones self in
the foot!

In any case paranoia seems to be being substituted for facts in the Iran
situation. They are not stupid, and although they may have the ability to
build nuclear weapons, actually using them would be counter productive as
the rest of the world would obliterate them if they did in anything other
than a defensive scenario by which point we would all be doomed in any case.

I'd be more worried about what non state organisations have and what North
Korea does myself.
Brian

--
----- -
This newsgroup posting comes to you directly from...
The Sofa of Brian Gaff...

Blind user, so no pictures please!
"newshound" wrote in message
...
I wasn't expecting much of this, but (apart from the irritating graphics
and spurious code), I was quite impressed. Good interviews with some
seriously smart people, and well edited together into an interesting story.

En el artículo ,
newshound escribió:

I wasn't expecting much of this, but (apart from the irritating graphics
and spurious code), I was quite impressed. Good interviews with some
seriously smart people, and well edited together into an interesting story.

It's been available since last February, so I'm not sure why the BBC is
passing it off as their own and saying "first shown 16 jan 2017"

https://en.wikipedia.org/wiki/Zero_Days

http://www.imdb.com/title/tt5446858/

but yes, a good documentary save for the annoying CGI.

--
(\_/)
(='.'=) systemd: the Linux version of Windows 10
(")_(")

"Mike Tomlinson" wrote in message
news
En el artículo ,
newshound escribió:

I wasn't expecting much of this, but (apart from the irritating graphics
and spurious code), I was quite impressed. Good interviews with some
seriously smart people, and well edited together into an interesting
story.

It's been available since last February, so I'm not sure why the BBC is
passing it off as their own and saying "first shown 16 jan 2017"

In what way are the BBC passing if off as their own?

It clearly says in the credits who produced it

tim

En el artículo , tim...
escribió:

In what way are the BBC passing if off as their own?

It's "BBC branded" on the relevant iPlayer webpage, and touted as part
of the BBC's own Storyville series. Not one mention that it's not a BBC
production, much less that it was first produced a year ago.

They're even offering to sell it on the BBC Store for a fiver!

It clearly says in the credits who produced it

who reads the credits?

--
(\_/)
(='.'=) systemd: the Linux version of Windows 10
(")_(")

On Thursday, 19 January 2017 11:04:10 UTC, Mike Tomlinson wrote:
En el artÃ*culo , tim...
escribió:

In what way are the BBC passing if off as their own?

It's "BBC branded" on the relevant iPlayer webpage, and touted as part
of the BBC's own Storyville series. Not one mention that it's not a BBC
production, much less that it was first produced a year ago.

They're even offering to sell it on the BBC Store for a fiver!

It clearly says in the credits who produced it

who reads the credits?

Those that want to kn ow who made it or contributed to the making of it.

"Mike Tomlinson" wrote in message
...
En el artículo , tim...
escribió:

In what way are the BBC passing if off as their own?

It's "BBC branded" on the relevant iPlayer webpage, and touted as part
of the BBC's own Storyville series.

Um,

" BBC Four - Storyville Series - showcasing the best in international
documentaries."

The raison d'etre of the branding is that it specifically isn't a program
made by the BBC.

tim

newshound used his keyboard to write :
I wasn't expecting much of this, but (apart from the irritating graphics and
spurious code), I was quite impressed. Good interviews with some seriously
smart people, and well edited together into an interesting story.

If you Google 9500h and PLC, there is a lot more on the subject to be
found..

On 1/19/2017 1:06 PM, Harry Bloomfield wrote:
newshound used his keyboard to write :
I wasn't expecting much of this, but (apart from the irritating
graphics and spurious code), I was quite impressed. Good interviews
with some seriously smart people, and well edited together into an
interesting story.

If you Google 9500h and PLC, there is a lot more on the subject to be
found..

This is the first paragraph of the first link which google gives me:

"We first mentioned that W32.Stuxnet targets industrial control systems
(ICSs) -- such as those used in pipelines or nuclear power plants -- 2
months ago in our blog here and gave some more technical details here."

As it can't resist mentioning nuclear power plants, can I throw in a
little of what I know about their control systems?

The first two generations of UK commercial nuclear plant (Magnox and
AGR) pre-dated even 8 bit microprocessors, so their original control
systems of course had no such vulnerabilities.

The UK nuclear industry is very conservative, so the C&I guys have
always been cautious about PLCs and the like, but even without that the
UK regulator (ONR, formerly NII) has always been very concerned about
replacing traditional electromechanical systems with anything which
suggests "computers" for at least two decades, from my personal and
direct experience. The original concern related to the untestability of
anything a bit complicated, the possibility that there *might* be some
unique combination of inputs or circumstances where code would fail.
Later, of course, vulnerabilities to "hacking" became another concern.

As time has moved on, it has become impossible to boycott computers
completely, for example "paper" chart recorders became more or less
obsolete and were replaced with scrolling display types which rely on
PLCs or similar. I was involved with one project which needed to have a
high integrity winch, the sort of thing which these days will have all
sorts of current, torque, and speed sensors, coupled to limit switches
and brakes by some sort of PLC. The main design contractor offered a
clever electromechanical system at least 30 years old, which they had
used a lot (I suspect in sensitive military as well as civil systems),
and the regulator was very happy with that. Our problem was that it had
no CE marking, and with design concepts and details lost in the mists of
time we were told there was no way of achieving it. I don't know how
that was resolved, but this was the system which was used.

But the key safety systems in nuclear power plant are still
electromechanical. Obviously, it is possible that malicious code could
get onto the site, but it could not make a reactor blow up or a turbine
overspeed: at worst, systems would go into a controlled shut-down or trip.

\rant

On 20/01/2017 09:41, Tim Streater wrote:

AISB, systems which are not connected to the Internet will not be
vulnerable to hacking. You need to avoid Windows too.


Any computer not networked is impossible to remote hack by any other
method than using the human operator.

Its far more likely that an operator that thinks his system is
invulnerable will be hackable than a windows user that thinks he is
vulnerable.

You can also load a large, variable, and therefore unknown to the
hacker, set of anti hacking tools on some OSes and that makes it far
more difficult to hack than something you know all about.

On 20/01/17 10:17, Tim Streater wrote:
In article . com,
dennis@home wrote:

On 20/01/2017 09:41, Tim Streater wrote:

AISB, systems which are not connected to the Internet will not be
vulnerable to hacking. You need to avoid Windows too.

Any computer not networked is impossible to remote hack by any other
method than using the human operator.

Quite so. Which raises the question. If bad guys wanted to hack such an
isolated system, say a network of machines running a power station or
dam, what methods are available to them apart from suborning an
operator?


physically getting a connection to the network is possible. Basically
plugging in say a wifi hotspot or a 4G phone-as-router...

However its unlikely most of these power stations even have networks,
for control, they are that old...

IIRC theres one running on a PDP11 still.


--
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

On 20/01/2017 11:08, The Natural Philosopher wrote:
On 20/01/17 10:17, Tim Streater wrote:
In article . com,
dennis@home wrote:

On 20/01/2017 09:41, Tim Streater wrote:

AISB, systems which are not connected to the Internet will not be
vulnerable to hacking. You need to avoid Windows too.

Any computer not networked is impossible to remote hack by any other
method than using the human operator.

You can hack a computer from any attached terminal on the site.

Quite so. Which raises the question. If bad guys wanted to hack such an
isolated system, say a network of machines running a power station or
dam, what methods are available to them apart from suborning an
operator?


physically getting a connection to the network is possible. Basically
plugging in say a wifi hotspot or a 4G phone-as-router...

One common trick is discarding USB memory sticks where target plant
operatives are likely to find them or using visiting maintenance
engineers at other less secure sites as intermediate vectors.

This seemed to be how the original Stuxnet was intended to be done until
the Israeli's made it into a profligate self replicating worm.

Humans are invariably the weakest point. Guessable passwords or
passwords on postits attached to the console being all too common!

--
Regards,
Martin Brown

On 18/01/2017 07:52, Brian Gaff wrote:
Yes it was good in that it could actually hold up as a radio documentary in
my view. I enjoyed it with no vision.

It is now rather more obvious why relations between use and Israel are a bit
strained for some years. Not only did they try to force the US into getting
involved with military action, when they used the hack, they changed it
without anyone telling the other parties. Talk about shooting ones self in
the foot!

It was the way they used multiple (valuable) zero day exploits in the
same virtually error free code that effectively signed it. Releasing it
into the wild with such a profligate propagation mechanism was bound to
result in it attracting the attention of the AV community. Now that it
is out there similar variations on that theme become easier to do. It
isn't possible to put the genie back in the bottle once its been used.

Our own infrastructure has been put at risk. I liked their demo blowing
up a balloon for 5s with and without the malign influence of Stuxnet.

In any case paranoia seems to be being substituted for facts in the Iran
situation. They are not stupid, and although they may have the ability to
build nuclear weapons, actually using them would be counter productive as
the rest of the world would obliterate them if they did in anything other
than a defensive scenario by which point we would all be doomed in any case.

Just because you are paranoid doesn't mean they are not all out to get
you.

I'd be more worried about what non state organisations have and what North
Korea does myself.
Brian

I think a nuclear capable North Korea is a very serious problem.
It may be that in the end China has to sort them out.

--
Regards,
Martin Brown

On Fri, 20 Jan 2017 11:51:53 +0000, Martin Brown wrote:

One common trick is discarding USB memory sticks where target
plant operatives are likely to find them or using visiting
maintenance engineers at other less secure sites as intermediate
vectors.

One stand-out from the programme was the point that the 'air-gap'
idea was regarded as a bad joke by the security experts.

On 20/01/2017 12:44, mechanic wrote:
On Fri, 20 Jan 2017 11:51:53 +0000, Martin Brown wrote:

One common trick is discarding USB memory sticks where target
plant operatives are likely to find them or using visiting
maintenance engineers at other less secure sites as intermediate
vectors.

One stand-out from the programme was the point that the 'air-gap'
idea was regarded as a bad joke by the security experts.


Air gaps work provided there is a guard maintaining the air gap.
You get shot if you try to access a really secret computer by crossing
the air gap.

On 20/01/2017 11:43, Huge wrote:
On 2017-01-20, Tim Streater wrote:
In article . com,
dennis@home wrote:

On 20/01/2017 09:41, Tim Streater wrote:

AISB, systems which are not connected to the Internet will not be
vulnerable to hacking. You need to avoid Windows too.

Any computer not networked is impossible to remote hack by any other
method than using the human operator.

Quite so.

Hopefully, neither of you work in IT Security.


Nobody has hacked a computer I worked on even though they are publicly
accessible and have been for a couple of decades now.

Even the customer had to ask us to recover some data they accidentally
lost as it was encrypted and they didn't have the key.

On 1/20/2017 9:41 AM, Tim Streater wrote:
In article ,
newshound wrote:

On 1/19/2017 1:06 PM, Harry Bloomfield wrote:
newshound used his keyboard to write :
I wasn't expecting much of this, but (apart from the irritating
graphics and spurious code), I was quite impressed. Good interviews
with some seriously smart people, and well edited together into an
interesting story.

If you Google 9500h and PLC, there is a lot more on the subject to be
found..

This is the first paragraph of the first link which google gives me:

"We first mentioned that W32.Stuxnet targets industrial control
systems (ICSs) -- such as those used in pipelines or nuclear power
plants -- 2 months ago in our blog here and gave some more technical
details here."

As it can't resist mentioning nuclear power plants, can I throw in a
little of what I know about their control systems?

direct experience. The original concern related to the untestability
of anything a bit complicated, the possibility that there *might* be
some unique combination of inputs or circumstances where code would
fail. Later, of course, vulnerabilities to "hacking" became another
concern.

AISB, systems which are not connected to the Internet will not be
vulnerable to hacking. You need to avoid Windows too.

Watch the program to see how it is done. As they explained, an "air-gap"
is a good line of defence provided you have very tight control of
anything which might go across it.

You need to be able to modify the code in PLCs (for example if you
decide to change limits from the current preset range), and it is wise
to be able to update firmware (for example to patch vulnerabilities).

This is traditionally done from a windows PC, running code which talks
to the PLC. The Stuxnet hack was *very* clever. Someone sneaked the worm
on to PCs inside the facility. Then it went and looked for the PLC
editing program, and hacked that. Then, when anyone went to modify a
PLC, it hacked the PLC firmware, taking great care all along not to be
detected. When the PLC was back in service, nothing happened for 13
days, except that the rogue code was recording the parameters displayed
on the operators console. After 13 days, it started playing back this
"good" data and throwing away the actual data so the operator couldn't
see anything wrong, then it wound up or down the speed of the
centrifuges, which caused them to break. It knew enough about which PLCs
were running centrifuges not to reveal itself by attacking any other
PLCs of the same type.

And this is why we don't have PLCs in the final parts of the protection
circuits for nuclear power plants, and also things like steam turbines
and generators which can't tolerate significant overspeed. In the
generating industry, we still remember Uskmouth in 1956. (Lecture on
turbine overspeed protection available on request).

On 1/20/2017 2:13 PM, dennis@home wrote:
On 20/01/2017 12:44, mechanic wrote:
On Fri, 20 Jan 2017 11:51:53 +0000, Martin Brown wrote:

One common trick is discarding USB memory sticks where target
plant operatives are likely to find them or using visiting
maintenance engineers at other less secure sites as intermediate
vectors.

One stand-out from the programme was the point that the 'air-gap'
idea was regarded as a bad joke by the security experts.


Air gaps work provided there is a guard maintaining the air gap.
You get shot if you try to access a really secret computer by crossing
the air gap.

I have worked on such systems (if I told you where I would have to shoot
you).

:-)

But only using MS Word. And I had no access to USB sockets, or floppy or
optical drives. And these networks were not controlling *any* hardware.

On 1/20/2017 12:04 PM, Martin Brown wrote:
On 18/01/2017 07:52, Brian Gaff wrote:
Yes it was good in that it could actually hold up as a radio
documentary in
my view. I enjoyed it with no vision.

It is now rather more obvious why relations between use and Israel are
a bit
strained for some years. Not only did they try to force the US into
getting
involved with military action, when they used the hack, they changed it
without anyone telling the other parties. Talk about shooting ones
self in
the foot!

It was the way they used multiple (valuable) zero day exploits in the
same virtually error free code that effectively signed it. Releasing it
into the wild with such a profligate propagation mechanism was bound to
result in it attracting the attention of the AV community. Now that it
is out there similar variations on that theme become easier to do. It
isn't possible to put the genie back in the bottle once its been used.

This is true. On the other hand, Siemens and other PLC manufacturers now
know what is possible, and can try to engineer protection.

And Stuxnet provides lots of types of signature for the AV community to
look for.

Rootkits are of course very insidious.

Our own infrastructure has been put at risk.

But *not* AGRs. I don't know enough about the "guts" of Sizewell B to
make the same statement, but I would be very surprised if their
protection was vulnerable to hacking. I don't doubt that you could trip
a reactor, perhaps even cause a small release of radioactivity by
interfering with fans or dampers, but not cause a significant release.

On 20/01/2017 14:54, newshound wrote:
On 1/20/2017 2:13 PM, dennis@home wrote:
On 20/01/2017 12:44, mechanic wrote:
On Fri, 20 Jan 2017 11:51:53 +0000, Martin Brown wrote:

One common trick is discarding USB memory sticks where target
plant operatives are likely to find them or using visiting
maintenance engineers at other less secure sites as intermediate
vectors.

One stand-out from the programme was the point that the 'air-gap'
idea was regarded as a bad joke by the security experts.


Air gaps work provided there is a guard maintaining the air gap.
You get shot if you try to access a really secret computer by crossing
the air gap.

I have worked on such systems (if I told you where I would have to shoot
you).

:-)

But only using MS Word. And I had no access to USB sockets, or floppy or
optical drives. And these networks were not controlling *any* hardware.

Its funny how many people think they now about computer security without
any idea of access control.

On 20/01/2017 12:44, mechanic wrote:
On Fri, 20 Jan 2017 11:51:53 +0000, Martin Brown wrote:

One common trick is discarding USB memory sticks where target
plant operatives are likely to find them or using visiting
maintenance engineers at other less secure sites as intermediate
vectors.

One stand-out from the programme was the point that the 'air-gap'
idea was regarded as a bad joke by the security experts.

It works but only if you can lock down the hardware well enough.
It only takes one tiny chink in the armour and you are stuffed.

--
Regards,
Martin Brown

On 20/01/2017 17:54, Martin Brown wrote:
On 20/01/2017 12:44, mechanic wrote:
On Fri, 20 Jan 2017 11:51:53 +0000, Martin Brown wrote:

One common trick is discarding USB memory sticks where target
plant operatives are likely to find them or using visiting
maintenance engineers at other less secure sites as intermediate
vectors.

One stand-out from the programme was the point that the 'air-gap'
idea was regarded as a bad joke by the security experts.

It works but only if you can lock down the hardware well enough.
It only takes one tiny chink in the armour and you are stuffed.


Air gaps are another layer of security not the only security.
If you have unattended access to a machine or network they have lost and
you can hack it! Its just a matter of time.

Time being key, there isn't much point in hacking something if the data
is out of date by the time you manage it. This is the basis of
encryption, not that it can't be broken but that its not worth expending
the time.

On Fri, 20 Jan 2017 14:13:02 +0000,
lid wrote:

On 20/01/2017 12:44, mechanic wrote:

One stand-out from the programme was the point that the 'air-gap'
idea was regarded as a bad joke by the security experts.


Air gaps work provided there is a guard maintaining the air gap.
You get shot if you try to access a really secret computer by crossing
the air gap.

The point made in the prog. was that software
updates/installs/logfile downloads bridge the gap. Don't rely on it.

On Fri, 20 Jan 2017 14:23:19 +0000, dennis@home wrote:

On 20/01/2017 11:43, Huge wrote:
On 2017-01-20, Tim Streater wrote:
In article . com,
dennis@home wrote:

On 20/01/2017 09:41, Tim Streater wrote:

AISB, systems which are not connected to the Internet will not be
vulnerable to hacking. You need to avoid Windows too.

Any computer not networked is impossible to remote hack by any other
method than using the human operator.

Quite so.

Hopefully, neither of you work in IT Security.


Nobody has hacked a computer I worked on even though they are publicly
accessible and have been for a couple of decades now.

And you know that precisely how?

On Thu, 19 Jan 2017 11:03:17 +0000, Mike Tomlinson wrote:

snip

It clearly says in the credits who produced it

who reads the credits?


Sensible people : ie obviously not you.

People who understand that Storyville is not about BBC productions at all:

"Storyville is a documentary strand presented by the BBC showcasing the best in
international documentaries."

Understand now : or do you want words of one syllable?

You need to stick to the Daily Mail: is that where you got your hate of the BBC
from?

In article ,
Mike Tomlinson wrote:
En el artículo , tim...
escribió:

In what way are the BBC passing if off as their own?

It's "BBC branded" on the relevant iPlayer webpage, and touted as part
of the BBC's own Storyville series. Not one mention that it's not a BBC
production, much less that it was first produced a year ago.

They're even offering to sell it on the BBC Store for a fiver!

It clearly says in the credits who produced it

who reads the credits?

Anyone who wants to know who actually made the programme. Surely you
understand that the BBC was forced by a Tory government to allow
programmes from independents that they would previously have made 'in
house'?

--
*If we weren't meant to eat animals, why are they made of meat?

Dave Plowman London SW
To e-mail, change noise into sound.

In article ,
Judith wrote:
On Thu, 19 Jan 2017 11:03:17 +0000, Mike Tomlinson wrote:

snip

It clearly says in the credits who produced it

who reads the credits?


Sensible people : ie obviously not you.

People who understand that Storyville is not about BBC productions at
all:

"Storyville is a documentary strand presented by the BBC showcasing the
best in international documentaries."

Understand now : or do you want words of one syllable?

You need to stick to the Daily Mail: is that where you got your hate of
the BBC from?

Yup. Time we went back to proper BBC productions as of yesteryear. Like
Dallas.

--
*Since light travels faster than sound, some people appear bright until you hear them speak.

Dave Plowman London SW
To e-mail, change noise into sound.

On 20/01/2017 22:52, trigger wrote:
On Fri, 20 Jan 2017 14:23:19 +0000, dennis@home wrote:

On 20/01/2017 11:43, Huge wrote:
On 2017-01-20, Tim Streater wrote:
In article . com,
dennis@home wrote:

On 20/01/2017 09:41, Tim Streater wrote:

AISB, systems which are not connected to the Internet will not be
vulnerable to hacking. You need to avoid Windows too.

Any computer not networked is impossible to remote hack by any other
method than using the human operator.

Quite so.

Hopefully, neither of you work in IT Security.


Nobody has hacked a computer I worked on even though they are publicly
accessible and have been for a couple of decades now.

And you know that precisely how?


Audit trails and others.

On Fri, 20 Jan 2017 17:54:22 +0000, Martin Brown
wrote:


It works but only if you can lock down the hardware well enough.
It only takes one tiny chink in the armour and you are stuffed.

"China has denied involvement ..."

"newshound" wrote in message
o.uk...
On 1/20/2017 9:41 AM, Tim Streater wrote:
In article ,
newshound wrote:

On 1/19/2017 1:06 PM, Harry Bloomfield wrote:
newshound used his keyboard to write :
I wasn't expecting much of this, but (apart from the irritating
graphics and spurious code), I was quite impressed. Good interviews
with some seriously smart people, and well edited together into an
interesting story.

If you Google 9500h and PLC, there is a lot more on the subject to be
found..

This is the first paragraph of the first link which google gives me:

"We first mentioned that W32.Stuxnet targets industrial control
systems (ICSs) -- such as those used in pipelines or nuclear power
plants -- 2 months ago in our blog here and gave some more technical
details here."

As it can't resist mentioning nuclear power plants, can I throw in a
little of what I know about their control systems?

direct experience. The original concern related to the untestability
of anything a bit complicated, the possibility that there *might* be
some unique combination of inputs or circumstances where code would
fail. Later, of course, vulnerabilities to "hacking" became another
concern.

AISB, systems which are not connected to the Internet will not be
vulnerable to hacking. You need to avoid Windows too.

Watch the program to see how it is done. As they explained, an "air-gap"
is a good line of defence provided you have very tight control of anything
which might go across it.

You need to be able to modify the code in PLCs (for example if you decide
to change limits from the current preset range), and it is wise to be able
to update firmware (for example to patch vulnerabilities).

um, no

if the device isn't networked, there will be no vulnerabilities than need to
be patched

except that is, this process of patching

presumably this patching is there for other reasons, but don't know enough
about PLCs to know what that would be


tim

"Huge" wrote in message
...
On 2017-01-21, tim... wrote:


"newshound" wrote in message
o.uk...

[36 lines snipped]

You need to be able to modify the code in PLCs (for example if you
decide
to change limits from the current preset range), and it is wise to be
able
to update firmware (for example to patch vulnerabilities).

um, no

if the device isn't networked, there will be no vulnerabilities than need
to
be patched

except that is, this process of patching

presumably this patching is there for other reasons, but don't know
enough
about PLCs to know what that would be

All software has bugs.

but back in the day you used to try and make sure that you found them all
before releasing the product

Firmware may need to be updated to maintain manufacturer support, even
without explicit bugs.

not on any firmware I ever worked on (in 35 years)

It went out the door embedded inside the product and was never touched again

I appreciate that times have changed and that companies now rely upon making
products software updatable (on the, usually, fictional excuse of being able
to add features) so that they can ship before it is fully debugged

but I think that these products in Iran predated that trend BICBW

(though as they were updateable, there must be a reason, but I still don't
believe we have hit on it)

tim

On 1/21/2017 6:37 PM, tim... wrote:


"Huge" wrote in message
...
On 2017-01-21, tim... wrote:


"newshound" wrote in message
o.uk...

[36 lines snipped]

You need to be able to modify the code in PLCs (for example if you
decide
to change limits from the current preset range), and it is wise to
be able
to update firmware (for example to patch vulnerabilities).

um, no

if the device isn't networked, there will be no vulnerabilities than
need to
be patched

except that is, this process of patching

presumably this patching is there for other reasons, but don't know
enough
about PLCs to know what that would be

All software has bugs.

but back in the day you used to try and make sure that you found them
all before releasing the product

Firmware may need to be updated to maintain manufacturer support, even
without explicit bugs.

not on any firmware I ever worked on (in 35 years)

It went out the door embedded inside the product and was never touched
again

I appreciate that times have changed and that companies now rely upon
making products software updatable (on the, usually, fictional excuse of
being able to add features) so that they can ship before it is fully
debugged

but I think that these products in Iran predated that trend BICBW

(though as they were updateable, there must be a reason, but I still
don't believe we have hit on it)

tim



It used to be expensive to make stuff updatable, now it is easy. Cameras
can be updated either to change/improve functionality, or to cope with
new lenses.

I'm not familiar with Siemens PLCs, but these certainly were updatable.
And whether these ones were or not, I believe many PLCs are networkable.

On 21/01/2017 18:37, tim... wrote:
"Huge" wrote in message
...
snip
All software has bugs.

but back in the day you used to try and make sure that you found them
all before releasing the product

I've been writing software so long it's getting embarrassing (some of my
colleagues weren't even born) and this has always been true: You try to
find the bugs before you ship the product.

Equally true: You never find them all.

Firmware may need to be updated to maintain manufacturer support, even
without explicit bugs.

not on any firmware I ever worked on (in 35 years)

It went out the door embedded inside the product and was never touched
again

Which merely means that the only chance for it to get infected with
malware was before you shipped it.

OTOH there was a lot less malware around last time I shipped anything
with ROMS we didn't intend to update.

snip

Andy

"Huge" wrote in message
...
On 2017-01-21, tim... wrote:


"Huge" wrote in message
...
On 2017-01-21, tim... wrote:


"newshound" wrote in message
o.uk...

[36 lines snipped]

You need to be able to modify the code in PLCs (for example if you
decide
to change limits from the current preset range), and it is wise to be
able
to update firmware (for example to patch vulnerabilities).

um, no

if the device isn't networked, there will be no vulnerabilities than
need
to
be patched

except that is, this process of patching

presumably this patching is there for other reasons, but don't know
enough
about PLCs to know what that would be

All software has bugs.

but back in the day you used to try and make sure that you found them all
before releasing the product

Good luck with that.

well of course things were shipped with bugs in

the market lived with them

(or the company went bust!)

Firmware may need to be updated to maintain manufacturer support, even
without explicit bugs.

not on any firmware I ever worked on (in 35 years)

You already admitted you don't know anything about PLCs.

You stated Firmware (needs to be updated), with no qualification

it is not only PLCs that have firmware

in fact I would go so far as to say that PLCs are a tiny minority of item
with firmware

I am therefore perfectly entitled to assume we are talking about generic
firmware

It went out the door embedded inside the product and was never touched
again

PLCs are not "embedded inside the product".

but the firmware is embedded inside the PLC, that's the point

Especially given that with the
ones I worked with the "product" was a biscuit or crisp factory.

which is significant how?

tim

"Vir Campestris" wrote in message
o.uk...
On 21/01/2017 18:37, tim... wrote:
"Huge" wrote in message
...
snip
All software has bugs.

but back in the day you used to try and make sure that you found them
all before releasing the product

I've been writing software so long it's getting embarrassing (some of my
colleagues weren't even born) and this has always been true: You try to
find the bugs before you ship the product.

Equally true: You never find them all.

Firmware may need to be updated to maintain manufacturer support, even
without explicit bugs.

not on any firmware I ever worked on (in 35 years)

It went out the door embedded inside the product and was never touched
again

Which merely means that the only chance for it to get infected with
malware was before you shipped it.

I'm not sure what you mean by "merely" .

Surely the point of this infection (under discussion) is that it can work
without you having to break through the physical security systems of the
victim.

tim

"Huge" wrote in message
...
On 2017-01-22, Vir Campestris wrote:
On 21/01/2017 18:37, tim... wrote:
"Huge" wrote in message
...
snip
All software has bugs.

but back in the day you used to try and make sure that you found them
all before releasing the product

I've been writing software so long it's getting embarrassing (some of my
colleagues weren't even born) and this has always been true: You try to
find the bugs before you ship the product.

Equally true: You never find them all.

Firmware may need to be updated to maintain manufacturer support, even
without explicit bugs.

not on any firmware I ever worked on (in 35 years)

It went out the door embedded inside the product and was never touched
again

Which merely means that the only chance for it to get infected with
malware was before you shipped it.

OTOH there was a lot less malware around last time I shipped anything
with ROMS we didn't intend to update.

Diss man he speek de troof.

surely this is a chicken and egg argument

There was no malware because it could not have been effective

tim

En el artículo , mechanic
escribió:

The point made in the prog. was that software
updates/installs/logfile downloads bridge the gap. Don't rely on it.

And random USB keys "accidentally" dropped near the location, à la Mr.
Robot.

--
(\_/)
(='.'=) systemd: the Linux version of Windows 10
(")_(")

En el artículo , trigger
escribió:

And you know that precisely how?

Security through obscurity, innit.

--
(\_/)
(='.'=) systemd: the Linux version of Windows 10
(")_(")

En el artículo ,
newshound escribió:

And this is why we don't have PLCs in the final parts of the protection
circuits for nuclear power plants

Yet?

, and also things like steam turbines
and generators which can't tolerate significant overspeed

Interestingly, one of EDF's UK nukes has just had repairs to the turbine
overspeed protection. it's back in service now, so I'm not sure which
one. May have been Hunterston B.

Also found this while searching:

"Events reported to ONR by EDF Energy (01 Apr 2012 to 19 Jan 2016)"

https://www.edfenergy.com/file/1914279/download

All unrated, or level 0/1 (not significant). Good to know.

--
(\_/)
(='.'=) systemd: the Linux version of Windows 10
(")_(")