Hello From A Security Researcher

[matthew.brough]

lol

[james.wilson]

I think a lot of installers including myself would be interested in your findings. We as installers normally cant do these tests as i for example fo not have the knowledge. However i would not knowingly install equipment with a known issue or a refusal to fix.

but as said grade 2 is designed for low risk sites. Currently defeating one is a skill usually reserved for high risk sites where no-one should be fitted grade 2 anything.

[Joe Harris]

JW is absolutely spot on - I think CG was making the point though that even the likely felons targeting G2 risk might be able to download a smartphone app in future that allows them to disable some systems.  In that scenario would you be demanding fixes from manufacturers?  If so why wait until then.

 

Currently it requires some specialist knowledge, however the same specialists (including those not discussing the issue directly with industry) don't have to teach someone else how to do it - they can create a very, very simple to use device that will achieve the same.

 

As many here have already said - most scroats wouldn't even bother going to a small effort and would just try and barge in regardless but it is none the less a valid line of enquiry and a valid point about industries attitude to the research.

 

It is a good thing. 

[cybergibbons]

Adrian - I'd really like to hear your thoughts in a few of the things raised in this thread. I'm still open for discussion, as are a lot of the other users here.

Just a recap:

1. I don't think the current standards allow any differentiation between a good grade 2 alarm (e.g. the Texecom Ricochet, which has a number of features only required for grade 3 alarms) and a bad one (not naming names, but a recent report on one showed that it met the standard but was a long way behind more modern panels). I don't think installers, consumers, or insurers have the ability to tell what is marketing fluff and what isn't.

2. Without independent audits of this functionality, it's perfectly possible for an alarm to meet a spec on paper, but not in reality. Will the new standards address this?

3. You represent a large number of manufacturers - is there any take on the process of vulnerability reporting and disclosure?

4. You implied reverse engineering an alarm protocol could result in court action. What would this be under?

[norman]

Why not?

self explanatory really, you want security manufacturers to publish flaws in their kit prior to fix...?

[cybergibbons]

self explanatory really, you want security manufacturers to publish flaws in their kit prior to fix...?

Nearly everyone in this thread has told me that the risk grading and attackers would never exploit these vulnerabilities. What's the harm in publishing them?

[james.wilson]

I don't agree that they should be published before fixed but there are other implications to consider

1 acceptable time from report to fix.

2 time period after fix is available before published

3 i can see the benefit for new systems but what about older ones. It would be possible to update those on service contracts but what about those without.

4 who would police this.

[matthew.brough]

I don't agree that they should be published before fixed but there are other implications to consider

1 acceptable time from report to fix.

2 time period after fix is available before published

3 i can see the benefit for new systems but what about older ones. It would be possible to update those on service contracts but what about those without.

4 who would police this.

What surprised me on my trip last week was even a critical bug can take over 6 months to fix so wouldn't be keen on any prompt publication.

Who would police it, the inspectorates could like they do everything else

[cybergibbons]

I don't agree that they should be published before fixed but there are other implications to consider

Neither do I necessarily - but I think the different paths need more thought. I don't think it's as obvious as it being self-explanatory.

 

1 acceptable time from report to fix.

2 time period after fix is available before published

3 i can see the benefit for new systems but what about older ones. It would be possible to update those on service contracts but what about those without.

4 who would police this.

All important considerations. The length of time is a hard one. Generally it is handled on an ad-hoc basis in IT - take the recent PostgreSQL exploit - they closed access to all their code repositories whilst they fixed it as they thought the impact of it leaking and becoming a 0 day was just too big. But it's comparatively easy to upgrade a database server - or protect it using another method like a firewall. Other less serious issues just get left and are used as examples of things not to do in later version.

Point 3 is one of my concerns. I don't have a single alarm system here that would easily allow the detectors to have their firmware updated. Some would allow it, but require them to be take apart and connected to a programmer. Yet I have a network of wireless sensor nodes that all over-the-air firmware updates. It's reliable and easy.

So the current standards and expectations are that the detectors will never get updated, and most of the panels require engineer visits to update. It makes patching problems really quite hard. Is this an issue with wireless sensors? Probably not. Is it an issue with alarms starting to become connected to the public internet? Probably.

Point 4. I don't know who would police it. It's done by the community with IT security equipment. If things aren't fixed, they do get hacked. If they get hacked, people think less of the product. Next time a purchasing decision is made, that vendor isn't considered.

 

What surprised me on my trip last week was even a critical bug can take over 6 months to fix so wouldn't be keen on any prompt publication.

Who would police it, the inspectorates could like they do everything else

Embedded security systems are hard. They absolutely NEED to work. You don't want to fix a minor bug and in turn cripple the system. There are ways of avoiding these issues though - the wireless sensor node network I use has two firmwares. If the new one fails, it falls back to the old one.

I have been mildly surprised at some of the engineering practices used in alarms. Microprocessors have things called watchdog timers that reset the processor if they are not continually pinged (simplification). These are not used in all alarm systems by any means - if I can crash a panel like this, it will not reset itself. Yet my washing machine, boiler, and car will always make heavy use of watchdog timers. I don't know why this is.

Inspectorates. Now that's something that I've not been able to get any handle on by reading.

[matthew.brough]

You make quite a valid point re updating.

The panels we use would mean a physical chip change for a firmware upgrade, most panels need a flasher but no remote upgrading. The signalling kit we use can all be done remotely very easily without any disruption, even over GPRS.

You have to remember though, the security industry isn't the it industry. We still think the fact we can talk to a panel remotely via a modem is still considered by many as hi tec.