Looking for some idea on security related to medical devices.. like there can be OEM(s) who manufacture the devices or can be hospitals buying it out from different vendors for setting up their infrastructure. How do we really identify whether a device is IoT enabled and security assesment needs to be done. Like example, if we look at Johnson & Johnson or Baxter .. they build medical devices but how do we know it's an IoT and related security to be addressed. Any kind of information and guidance would be of great help. Thanks :)
I would take a look at alibaba as many companies source china for manufacturing. Typically knock offs will occur(or its just plain OEM'ed from china) and will prob show up on places like alibaba. Within the listings of alibaba you can see if they list or you can email the supplier and ask if they use dhawa, hisilicon or any of the other IoT boards in their product.
Related
This is a different question but what I am trying to do is avoid PCI compliance on my end and transfer that issue over to the customer. This will deal with the transfer of credit card numbers. I am wondering how you can create an application like a website but make is so a customer can download it to their computer to use it.
The application would be connected to a API where the credit card data would be given to a credit card processor. Is this possible to do? Can I avoid using a server of my own? If so what suggestions might you make? Can it be done using react? Node? do I have to use Python? Hope this is enough information to understand.
Tim,
If I am understanding your question correctly, you goal is to provide credit-card acceptance as a function to your customer and avoid PCI compliance. If your website includes a redirect or iframe to a processor, then your customer would need to complete an SAQ-A or SAQ-A EP for their compliance.
If you are a maintaining these sites, especially if you have remote access, then you are service provider and would need to complete the relevant sections of SAQ-D. If you build the website and leave it up to your customer after that, you have no obligations under the PCI DSS.
I attached a link to the PCI SSC's website for your reference.
Best of luck
I have a number of required business cases for HoloLens that require the device to understand a general geolocation, such as the current wearer longitude and latitude within 10 meters or so, as well as sending location information to and from an endpoint during various processes. Users WILL have a mobile device with geolocation capabilities that could assist in the process if necessary, and could also be used as a WiFi hotspot.
Is this a reasonable and reliable use case for HoloLens? Can apps be created that use geolocation and maintain connectivity during an experience, either on their own or with real-time communication to and from a mobile device that has these capabilities?
Yes - definitely is a realistic scenario. I've done some integration between a blue-tooth GPS and the Hololens. Let me know the particular device you're looking at and I'll see if I can get it working with the Hololens. //Lance Larsen (Microsoft MVP) - www.lancelarsen.com
I have a couple of questions concerning BLE beacons:
1) Are beacons based on nRF51822 chip the best solution? Or are there any other chips better than nRF51822? I want to take up BLE beacon development and struggling to find the right hardware for these needs. As a novice developer I want the beacon to be as cheap as possible in order not to waste money in case of a failure.
2) Is it possible to buy pure Eddystone beacon (not iBeacon)? The reason for choosing Eddystone is that Eddystone is capable of broadcasting URLs that are essential for me.
The second question stems from my failed attempts to find a pure Eddystone beacon on Chinese electronics sites like alibaba.com or aliexpress.com where the only firmware available is iBeacon. But iBeacon is not an option because it can't broadcast URL the way Eddystone does.
Apart from the above questions It would be great if someone wrote a quick guide for taking up BLE development with Eddystone and covered basic topics like: chip to use, beacon model, best website to buy beacons at, etc.
Thanks in advance,
Pavel
1) I've worked with Estimote beacons and Chinese beacons from Amazon and in my opinion, they do not differ in terms of accuracy too much. Especially for prototyping, I'd buy cheaper ones to test if your use case can be satisfied with BLE beacons. If it is too inaccurate with Chinese beacons, chances are that it won't work with more expensive ones either.
2) Why do you need the URL broadcast? If the app is going to use the url, it would have to be connected to the internet. Therefore, you can just query the beacon's IDs to a web service to get back an URL and use that. Personally, I think this is a better approach as you can configure the web service from anywhere to change the url for beacons where as if you want to change the URL of the Eddystone, you have to go to the beacon to configure it.
The nRF51822 is a common implementation, is flexible, well understood and can be very inexpensive. Be aware though that development costs, add on circuitry for power and/or peripherals, and packaging can easily eclipse the Bluetooth chip when you get to production cost savings.
If you want to buy an off the shelf beacon, most models supporting Eddystone also support iBeacon, simply because supporting both adds no additional hardware cost. Newer Radius Networks and Estimote beacons all support both. And, yes, cheaper generic Chinese suppliers often have bulk manufactured inventory from before Eddystone existed at only support iBeacon.
Is there a protocol which point-of-sale machine use to talk to a credit card machine? What is the recommended software/hardware platform to prototype a point of sale system?
There are several protocols available, here are some of then: First there is OPI, Open Payment Initiative, specified by Wincor Nixdorf. It is in wide use. Then there is the german ZVT protocol or the Swiss VEZ protocol. It really depends in which region you plan to use it, the protocols I listed definitel are in widespread use in Europe.
It would be easier to get the sdk of your payment gateway and integrate it into you software. I have hooked ip VeriFone, Clover and Priority machines. Each vendor has multiple APIs in different languages.
I'm doing a grad-school software engineering project and I'm looking for the protocol that governs communications between ATMs and bank networks.
I've been googling for quite a while now, and though I'm finding all sorts of interesting information about ATMs, I'm surprised to find that there seems to be no industry standard for high-level communications.
I'm not talking about 3DES or low-level transmission protocols, but something along the lines of an Interface Control Document; something that governs the sequence of events for various transactions: verify credentials, withdrawal, check balance, etc.
Any ideas? Does anything like this even exist?
I can't believe that after all this time the banks and ATM manufacturers are still just making this up as they go.
A shorter question: if I wanted to go into the ATM software manufacturing business, where would I start looking for standards?
Well, there are lots of interbank networks. I would guess that each of them communicate differently. The stickers on the ATM (Cirrus, STAR, Pulse, etc...) identify which network the machine participates in. I do believe, though, that the "structure" of the message is dictated by an ISO standard. Cirrus is a Mastercard owned network and PLUS is a Visa owned network... I'd scour their sites to see if they publish any API details.
Edit, by request:
Have a look at the following ISOs 15022, 20022, 9362 and 4217 -- http://en.wikipedia.org/wiki/Category:Financial_routing_standards
ISO 8583 is dominant.
Also, take a look at EMV.
The ATM to bank link can be proprietary or standard. It is only upstream where inter-organisation wire level interoperability is needed, that standards become always necessary.
ISO 15022 definitely doesn't cover ATM to bank. So far, it covers further upstream. And is now superseded by ISO 20022 - "originally named ISO 15022 2nd edition".
ISO 20022 covers the total scope of financial services, and acts as a super forum for ISO financial services protocols.
There are two basic protocols, ISO8563 and IFX (a financial XML subset) but many banks us protocols supplied by the vendor, because these include Device driver protocols that drive the ATM 'States', There is also a reporting protocol where the ATM reports its cash and usage statii.