The Internet of Things: Utility vs. Privacy

The more utility we have’ from new technology, ‘the more prepared we are to give up privacy’ – Robert Scoble (blogger)

I previously raised the subject of how the Internet of Things feels and its creepiness. Why does unconsented data collection feel wrong? Well, it probably goes against our preconceptions of our right to privacy.

From smartphones and wearables to predictive searches and suggestions, the Internet of Things (IoT) makes many promises: to seamlessly connect us more than ever before, to ease our transitions from one experience to the next, to make sure we have what we need when we need it (and only then, fading into the background when it’s no longer necessary). And to do this, IoT devices and experiences need to learn about us, our likes and dislikes, our daily patterns, etc.

And that’s when some feel things start getting a little creepy. These devices – and the companies they’re a part of – can start to seem invasive. To be effective, IoT needs behavioral data to figure out what we’re going to want next. And anytime that anyone or anything knows that much information about us, there’s a risk of it being too much.

Posted in Internet of Things | Tagged , , , , , | Leave a comment

Digital Transformation: it takes way more than simply Digitalisation

The misunderstanding of nomenclature

It’s a mistake to think that organizations in Switzerland and Europe are really ready for profound digital transformation in a broad way. There are still far too many gaps with regard to the digitisation (and automation) of existing processes and the digitisation (transcription) of data from paper media. Worse: what is sometimes called digital transformation is sometimes “just” digitisation (turning paper into electronic information, into processes). The majority of C-level managers responding to the 2014 Digital Transformation survey by KPMG still equated “Digital Transformation” with simply the digitalisation and automation of business processes. Putting that aside, you still need to introduce digitisation in order to optimise your business in a digital transformation context but, and I do not apologise to keep emphasising this, digitisation does not equal digital transformation. What matters is the strategic and prioritised interconnection of data sources and the actions you take to achieve business goals through digitisation and combining data.

A common language

To make sure we speak the same language it is important to emphasize that digital transformation is not just about:

  • becoming active on social media platforms;
  • interacting with customers in a purely digital manner, via mobile apps, chat rooms, e-mail, or websites;
  • preparing for or (much worse) reacting to disruptive actions in your or your customers’ market(s);
  • transforming paper forms into digital media, nor the digitisation of information (flows) and business processes, which is simply a condicio sine qua non; or,
  • a time-boxed project: it must continue to live and evolve within the organisation.

A digital transformation of your business is a cultural transformation of how you treat your people: your workforce, your customers, and your suppliers; and how you develop, evolve, and integrate your products and services.

Business cultural change

It is simply a matter of time before there is no material distinction between offline and online, or physical and digital business. It is therefore important to take a pro-active stance and prepare and guide your business through a digital transformation. Be prepared to face disruption from competitors and unknown start-ups: it may take just a small nibble out of your current services to destabilise your whole product offering. Analyse your weaknesses and mitigate them; identify your strengths and build on them; focus on digital growth rather than introducing efficiencies that simply leave you treading water.

eGovernment – cultural change in the slow lane

There are many digitization efforts that still need to be realised in many areas of business and society. We all know and feel it, whether it’s in our daily experiences as “business people” or in the often totally unnecessary administrative tasks in regards to our government-related or finance-related transactions and interactions with business. We see it whenever we’re still forced to use paper, the phone, or other archaic channels.

A glaring deficiency in Switzerland is the lack of a common eGovernment platform: even though many forms can be downloaded from all levels of government websites, the majority must be printed out, physically signed, and returned by post or in person to the appropriate department – probably to be scanned or transcribed into an internal digital document management system. This is, no doubt, because of the distributed system of government, with the various layers devotedly (stubbornly?) independent of each other, both vertically and horizontally. The Digital Transformation of government must be a centralised proposition, which in Switzerland will neither be easy nor quick due to its consensus-oriented culture.

Posted in Digital Transformation, Digitalization | Tagged , | Leave a comment

M2M and IoT: what’s the difference?

M2M (Machine-to-Machine) and IoT (Internet of Things) are two related terms that are commonly bandied around but, because of their main similarities, are hard to distinguish. In some respects, it depends on who is using a particular term: the product developer, the end user, or the network provider.

M2M was around before IoT, and so has more traction and history in the (industrial) business world. An early form is SCADA (Supervisory Control And Data Acquisition). It mostly refers to the communication between devices and a central system that monitors and controls those devices, the data being silo-ed and private. The communication happens independent of human interaction. Examples might be the control system of a water and sewage plant, a power station, or a paper mill. SCADA systems may be distributed and controlled by a central intelligence, such as for a national electrical power grid. Human interaction is limited to a few buttons and status lights, perhaps an alarm siren, and a few PC screens. The application has a single dimension – each device answers to just one application.

IoT is similar to M2M, but connectivity also takes place autonomously between devices and between devices and distributed intelligent systems. In truly open IoT implementations, data values are no longer silo-ed within a single application: data is provided though APIs to enable other applications access. Examples abound in Smart City environments, where air quality sensors, traffic monitoring loops and parking bay states are provided to the public for further analysis. The plethora of prospective applications cause the IoT to take on a multi-dimensional context. [In reality, though, the current state of much of the data produced by IoT devices is still silo-ed due to the use of proprietary control systems that protect a commercial advantage – this could be described as the Intranet(s) of Things: smart lighting manufacturers still need to provide their own smart phone app to control their own product line, or third-party hubs need to implement and support all of those protocols to enable a single app to be used.]

So, the key difference between M2M and IoT is how centralised or decentralised the intelligence of the system is, and therefore the number of dimensions. Are the devices deployed to support a centralised system (M2M) or does the decentralised intelligence take advantage of a diversity of devices (IoT). In IoT, event processing becomes more complex, as events from one given area may trigger actions on different areas to the originating one – this may be controlled using IFTTT (IF This Then That) “applets”. Event management becomes more complex as there may be a combination of events from different devices or elements that combined together, using co-location of functional relationships, to trigger a given action: data sources such as a room thermostat, sun sensor, and a rain radar feed combine together to control window blinds and ventilation systems; a rain sensor at the destination of your journey may signal your connected umbrella to remind you to take it with you as you leave home. The rise of “edge computing” for IoT applications pushes the intelligence further away from a central system and down towards to where the data originates.

Perhaps one of the best ways to consider what is M2M and what is IoT is from where the impetus originates. If the impetus is for a single application or closed set of related applications for many devices, it is an M2M (or Intranet of Things) implementation. If the devices provide data to all-comers, whether directly or through a portal, it is probably an IoT implementation.

Posted in Internet of Things | Tagged , , , | Leave a comment

LBS and IoT: not just what but where

Location-Based Services

LBS, Location-Based Services, are most-widely known in association with mobile devices (e.g. smart phones) with a built-in GNSS [Global Navigation Satellite System1] receiver, picking up signals from earth satellites, or correlating and trilaterating signal strengths of known WiFi or mobile telephone networks, especially useful when inside a building where satellite signals do not penetrate.

Once an absolute location has been recorded, relative positioning can take over. Technology such as wheel rotation counters and magnetic bearings can be used to deduce location over time. In modern smart phones, MEMS sensors can detect acceleration and orientation, allowing navigation to continue in low-signal environments, such as through urban canyons.

Public

LBS were initiated by the FCC in 1996 as the E911 mandate, and in Europe in 2002 under the E112 mandate. The aim was to improve the location information of a mobile caller to an emergency number to allow for quicker and more-accurate response to the location.

Since then, based on the technology of emergency response LBS, commercial services have sprung up surrounding navigation and location: public transportation, people and asset tracking, travel and tourism, local search, social networking, fitness, mobile advertising.

Commercial

Many people have LBS activated on their mobile phones throughout the day, allowing companies like Google to push “useful” location-based information to them based on their and others’ locations. Consider being informed of a traffic conditions ahead by Google Maps that was deduced by the location and slow speed of other Google “informants” caught up in the traffic. Other applications include tailored fitness apps (MapMyWalk, MapMyRun, etc.), whether for cycling, running or walking. Or Foursquare, billed as a concierge that will suggest to you and your friends the best places to go for entertainment and dining in your (immediate) area.

LBS for IoT

But nowadays, not only mobile phones are mobile: IoT devices are also mobile and will need their own location-based services to allow them to properly interact with their environment. These devices could be sewn into our clothing and connect to a Body-Area Network (BAN) or Personal-Area Network (PAN), which eventually connects to our phones, and out to the Internet. Applications include health monitoring or fitness, but could include pay-as-you-go car (or sky-diving) insurance! In the future, we may not actually own our IoT devices, as they will be shared, like public bicycles in London, and so their location information is necessary to be able to track them and who is riding them at the time.

The geographic location information can be any type of data, so long as it involves and incorporates some form of location. To aid in series measurements, a time axis may also be incorporated into the data record.

Scattered, Drifting, and Embedded

Motes (Specs, or SmartDust) are an early form of ZigBee-connected sensor that are deployed by aerial drop on to a battelfield to detect enemy movements: pressure sensors (gunfire and movement), light sensors (shadows and lamps), sounds, etc.

Environmental buoys and water-column sensors can track spills or monitor water quality as they drift. Scattering motes at spill sites can enable the spill to be categorised as cleaned up when no motes are found at the site, as well as allow the spill to be monitored in real-time during clean-up.

Motes can also be embedded in concrete during a pour and allow the structure (road, bridge, building) to be monitored throughout its life. With the advent of contactless power supply, motes can be activated during a sweep of the structure and return their measurements.

Stationary

IoT devices may still be connected to a LBS but as a stationary node: a beacon. Apple and Google have introduced the iBeacon and Eddystone beacon protocols, respectively. Beacons simply broadcast a regular BLE (BlueTooth Low Energy) signal that can “anchor” a mobile device to a location, even for a split second, allowing location-specific information to be associated with the mobile device ephemerally.

Consider a coffee shop that pings special offers to phones running their loyalty app: as a mobile device travels past, it can advertise a special offer. By spreading beacons around a block or shopping mall it could help guide prospective patrons to the shop.

Legal and Ethical Issues

As data on our movements are collected, behaviour patterns can be analysed and also altered: we drive down routes unknown to us based on the suggestion of our GPS navigation unit; we stop at a coffee shop based on some mobile advertising; we allow our washing machine to pause when we are out of the house when there is a high load on the power network.

From a legal point of view, data generated through location-aware mobile and IoT devices is regarded as a new, distinct class of data that requires increased protection and special procedures to collect, analyse and act upon. The EU Directive on Privacy and Electronic Communications ensures that location data can only be used with the permission of the user, but what of IoT devices that simply know a mobile device has passed by its location (again, three times since last week and always at 12:30)?

Location (and time) is a context attributed to a piece of data and can be attributed a meaning. The locale could be very sensitive: what if the IoT device was located in the toilets of a club catering to a particular sexual persuasion and it noted your mobile device lingered there for more than 10 minutes; what if the IoT device detected your mobile device visiting the headquarters of a competing employer; what if the IoT device detected your mobile phone at a prison or law courts when you had called in sick?

As a consequence of the context, one can uncover knowledge from the bits of information and piece together a profile about the mobile user’s beliefs, preferences, convictions, and behaviour. Of course, it is unlikely that it would be the same commercial organisation detecting users in various contexts, but commercial users tend to sell-on their data for a profit, and it is then that data may not be fully anonymised or normalised before it is analysed.


1 Global Navigation Satellite Systems include: United States’ NAVSTAR Global Positioning System, Russia’s GLONASS, China’s Compass (BeiDou), and the EU’s Galileo. Additionally, position Satellite-Based Augmentation System (SBAS) correction services broadcast from geosynchronous or quasi-synchronous satellites are available: US WAAS, EU’s EGNOS, India’s GAGAN, and Japan’s MSAS.

Posted in Cloud, Internet of Things, Mobile | Tagged , , , , | Leave a comment

Wie installiere ich Cloud Foundry lokal?

IT-Unternehmen stehen immer vor der selben Herausforderung: bestimmte Services möglichst schnell und in hoher Qualität ihren Kunden zur Verfügung zu stellen. Durch iterative Entwicklungsprozesse, die allen agilen Methoden gemein sind, werden in der Regel immer häufiger IT-Artefakte dem Kunden ausgeliefert.

Dazu müssen die IT-Architekturen allerdings erst so umgesetzt werden, dass einzelne Teile einer Applikation flexibel ausgetauscht und unabhängig voneinander ausgeliefert werden können. Es ist also wünschenswert, wenn man Anwendungen wie Lego-Bausteine ständig reorganisieren und mit neuen Bausteinen bestücken könnte.

Eine “Platform as a Service” (PaaS) kann Softwareentwicklern helfen, Applikationen in der Cloud zu betreiben, ohne dass sie sich dabei um die Infrastruktur Gedanken machen müssen. Durch eine PaaS werden IT-Umgebungen standardisiert und deren Komplexität deutlich reduziert, indem Softwareentwickler nicht mehr die darunterlegende Infrastruktur wie Netzwerk, Server, Betriebssystem oder Datenbanken verwalten müssen, da dies die PaaS automatisch übernimmt.

Mit Cloud Foundry (CF) erhält jeder die Möglichkeit  eine PaaS selbst auszuprobieren. Ziel dieses Posts ist eine Anleitung um sich CF auf dem lokalen Rechner zu installieren. CF wird dabei auf einer VM (Virtualbox) installiert, um so eine Test-App vom lokalen Rechner mit dem CF CLI nach CF in die VM zu pushen.

Jetzt aber los!

Tools und Abhängigkeiten installieren

Neueste Versionen installieren bzw. updaten:

Ruby (https://www.ruby-lang.org/en/)

$ ruby -v
ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin15]
# (BOSH CLI benötigt Ruby 2+)

Vagrant (https://www.vagrantup.com/)

$ vagrant -v
Vagrant 1.9.0

VirtualBox (https://www.virtualbox.org/)

$ VBoxManage --version
5.1.10r…

BOSH-Lite installieren

Für die lokale Infrastruktur werden wir BOSH-Lite installieren. BOSH ist ein Projekt, das Release-Engineering, Deployment und Lifecycle-Management von kleinen und großen Cloud-Applikationen vereint. BOSH-Lite ist eine pre-build Vagant Box die den Director enthält. Durch eine Containerisierung können so unterschiedliche VMs emuliert werden. In unserem Fall verwenden wir Virtualbox. Unterhalb in der Abb. sind die BOSH Komponenten visualisiert. (http://bosh.io/docs/about.html)

Quelle: bosh.io

Quelle: bosh.io

Der Director ist die zentrale Orchestrierungs-Komponente in BOSH. Der Director steuert die VM-Erstellung und das Deployment, sowie andere Software- und Service-Lifecycle-Abläufe. Um mit dem BOSH Director interagieren zu können müssen wir allerdings zuerst das BOSH CLI installieren.

$ gem install bosh_cli --no-ri --no-rdoc

Für die weitere Installation habe ich in meinem Homeverzeichnis ein /workspace Verzeichnis angelegt in dem ich alle CF Projekte ablege.
Als nächstes klonen wir aus dem Github das BOSH-Lite Repository in unser workspace Verzeichnis.

$ cd ~/workspace
$ git clone https://github.com/cloudfoundry/bosh-lite
$ cd bosh-lite

Danach starten wir Vagrant aus dem Root-Verzeichnis des geklonten Repositories, in dem sich das Vagrantfile befindet. Bei dem Befehl vagrant up werden die neuesten BOSH-LITE Komponenten aus der Vagant Cloud automatisch heruntergeladen.

$ vagrant up --provider=virtualbox

Falls der Rechner neu gestartet oder in den Ruhezustand versetzt werden muss, sollte die VM mit dem Befehl vagrant suspend pausiert und mit vagrant resume wieder gestartet werden.

Befindet man sich hinter einem Proxy, muss man beide IP Adressen der privaten VMs ausschliessen (optionaler Schritt):

$ export no_proxy=xip.io,192.168.50.4

Um sicherzustellen dass die BOSH CLI auch auf unserem installieren BOSH Director kommunizieren kann, müssen wir BOSH die IP Adresse (die IP Adresse 192.168.50.4 ist eine Default IP die beim hochfahren des Vagrant Containers in der Virtualbox erstellt wird) mit dem Befehl bosh target übergeben. Die default Benutzerdaten sind admin/admin.

$ bosh target 192.168.50.4 lite

Target set to 'Bosh Lite Director'
Your username: admin
Enter password: *****
Logged in as 'admin'

Wir fügen noch die Route Einträge in die lokale Routing Tabelle hinzu. Somit erhalten wir einen direkten Zugriff auf den Warden Container, auch wenn die Internetverbindung resettet wird.

$ bin/add-route

Jetzt können wir die BOSH Stemcell hochladen. Eine Stemcell ist ein vor konfiguriertes System-Images das ein OS und Hilfsprogramme beinhaltet. Eine Liste von BOSH Stemcells kann man hier finden (https://www.bosh.io/stemcells). Da unser Vagrant Container ein Ubuntu OS provisioniert verwenden wir die Bosh Warden – Ubuntu trusty stemcell:

$ bosh upload stemcell bosh-warden-boshlite-ubuntu-trusty-go_agent —skip-if-exists

Um den Upload zu überprüfen kann man sich eine Liste der installierten Stemcells durch den Bosh CLI anzeigen lassen:

$ bosh stemcells

CF Installieren

Nun sind wir bereit CF zu deployen.
Dies kann mit einem Deployment-Script durchgeführt werden:

$ ~/workspace/bosh-lite/bin/provision_cf

(Diese Methode hat zum Zeitpunkt, als der Blogpost erstellt wurde, nicht funktioniert. Beim Hochladen der “bosh-warden-ubuntu” Stemcell ist der Upload bei 96% stehengeblieben und das Script wurde nicht weiter ausgeführt.)

Es ist aber möglich die Installation auch manuell auszuführen. Dazu holen wir uns das CF Project aus Github indem wir es auf den Rechner klonen.

$ cd ~/workspace
$ git clone https://github.com/cloudfoundry/cf-release.git

Um sicherzugehen das alle Module und Submodule auf dem neuesten Stand sind müssen wir für das Projekt einen Update vornehmen (dies könnte etwas länger dauern).

$ cd ~/workspace/cf-release
$ ./scripts/update

Nach dem klonen bzw. updaten des CF Projekts müssen wir noch zwei Scripts installieren die in der CF Version enthalten sind und beim erstellen des Deployment-Manifest benötigt werden.

Bundler installieren (http://bundler.io/). Bundler ist ein Ruby gem Management Tool.

$ gem install bundler

Wir überprüfen ob Bundler korrekt installiert ist und rufen die Version auf:

$ bundler -v
Bundler version 1.13.6

Spiff installieren (https://github.com/cloudfoundry-incubator/spiff). Spiff ist ein Tool mit dem YAML Dateien zusammengefügt werden können. Abhängig vom Betriebssystem Spiff einfach herunterladen und auf den Rechner entpacken. In unserem Fall ist es das Home Verzeichnis.

$ cd ~
$ mkdir bin
$ mv ~/Downloads/spiff ~/bin

Spiff muss in der Konsole verfügbar sein. Dazu fügen wir Spiff als $PATH. z.B. der .bash_profile hinzu.

export PATH="$PATH:$HOME/bin"

Durch denn Versions-Befehl kann man die Korrektheit der Installation überprüfen:

$ spiff -v
spiff version 1.0.7

Nun sind wir bereit die Deployment Manifest Datei zu generieren. Die Manifest Datei ist eine YAML Datei in der die einzelnen Komponenten und Eigenschaften des Deployments definiert sind. Wird ein neues Deployment mit dem CLI eingeleitet, erhält der Director eine Version des Deployment Manifests und erstellt anhand dessen ein neues Deployment.

$ cd ~/workspace/cf-release
$ ./scripts/generate-bosh-lite-dev-manifest

Das generierte Manifest wird automatisch hier abgelegt:

$ ls -la ~/workspace/bosh-lite/deployments/cf.yml

Damit wir CF mit BOSH deployen können müssen wir CF nach BOSH hochladen. Dies geschieht wieder durch eine YAML Datei, welche eine Representation des CF Releases darstellt. Das neueste Release von CF ist 248.

$ ls -la ~/workspace/cf-release/releases/
$ bosh upload release cf-248.yml

Zeit zum deployen.
Dazu sagen wir BOSH wo sich die Deployment Datei befindet.

$ cd ~/workspace/bosh-lite/deployments/cf.yml
$ bosh deployment cf.yml

Wir überprüfen das Deployment mit dem Befehl bosh vms.

$ bosh vms

Dieser Befehl bietet einen Überblick über die virtuellen Maschinen, die BOSH als Teil des aktuellen Deployments verwaltet. Der Zustand jeder VM sollte als laufend angezeigt werden.

CF CLI installieren

Der CF CLI ist der offizielle Command Line Client für Cloud Foundry. Ein Tool mit dem Applikationen verwaltet und nach CF deployed werden können.

Mac OS X
Die einfachste Variante sich CF CLI auf dem MAC OS X System zu installieren ist mit dem Homebrew Paketmanager. (http://brew.sh/index_de.html).

$ brew tap cloudfoundry/tap
$ brew install cf-cli

Debian und Ubuntu

$ wget -q -O - https://packages.cloudfoundry.org/debian/cli.cloudfoundry.org.key | sudo apt-key add -
$ echo "deb http://packages.cloudfoundry.org/debian stable main" | sudo tee /etc/apt/sources.list.d/cloudfoundry-cli.list
$ sudo apt-get update
$ sudo apt-get install cf-cli

Enterprise Linux und Fedora

$ sudo wget -O /etc/yum.repos.d/cloudfoundry-cli.repo https://packages.cloudfoundry.org/fedora/cloudfoundry-cli.repo
$ sudo yum install cf-cli

 Installer für Windows:

https://cli.run.pivotal.io/stable?release=windows64&source=github

CF CLI sollte bei der Frage nach der Version so einen ähnlichen Output liefern.

$ cf -v
cf version 6.22.2+a95e24c-2016-10-27

Wenn man möchte kann man die Sprache im CF-CLI wählen, z.B.:

$ cf config --locale de-DE

CF Konfigurieren

Zuerst loggen wir uns in CF ein. Die default Zugangsdaten sind admin/admin.

$ cf login api --skip-ssl-validation api.bosh-lite.com

Um unsere Test-App pushen zu können müssen wir zunächst eine Organisation und einen Space erstellen.

$ cf create-org bbv
$ cf create-space development

Man kann alles mit dem Admin Account testen, es ist jedoch ratsam einen eigenen Benutzer zu erstellen.

$ cf create-user USERNAME PASSWORD

Dem erstellten Benutzer weisen wir eine Organisation und die Role Orgmanager zu.

$ cf set-org-role USERNAME bbv OrgManager

Ausserdem weisen wir dem erstellten Benutzer auch einen Space und die RoleSpaceDeveloper zu

$ cf set-space-role USERNAME bbv development SpaceDeveloper

Zuletzt verknüpfen wir die gegenwärtige Login mit der Organisation und dem Space.

$ cf target -o "bbv" -s "development"

API-Endpunkt: https://api.bosh-lite.com (API-Version: 2.65.0)
Benutzer: USERNAME
Organisation: bbv
Bereich:development

Test-App pushen

Nun sind wir bereit unsere erste Applikation nach CF zu pushen. Unsere Test-App ist eine PHP Anwendung in Form von einer PHP-Info Seite. Dazu erstellen wir in unserem workspace Verzeichnis ein Projekt-Ordner test-app/ und legen eine index.php Datei an in der wir dieses Codesnippet einfügen:

<?php phpinfo(); ?>

Zum deployen der Applikation wechseln wir ins Projektverzeichnis und führen  cf push aus wobei Deployment der “App”

$ cd ../test-php
$ cf push testApp

Dem Console-Log ist zu entnehmen, dass erst die Route und das Bindung erstellt wird. Anschliessend wird die App hochgeladen. Beim starten der Applikation wird die Umgebung aufgebaut. Dabei wird das PHP Buildpack heruntergeladen, welches aus einem HTTP Buildpack (HTTPD 2.4.23) und einem PHP Buildpack (PHP 5.5.38) zusammensetzt ist. CF erkennt somit eigenständig das Buildpack und baut die Deployment Umgebung automatisch zusammen. Natürlich kann man explizite Buildpacks beim pushen nach CF angeben. Am Ende wird die Applikation hochgefahren und der Status angezeigt. Schön ist, dass im Status die URL zu sehen ist die der Router von CF für die Applikation zur Verfügung stellt und mit der man unsere Applikation aufrufen kann (testApp.bosh-lite.com).

Eine Liste der Applikationen die in CF hochgeladen sind kann man mit diesem Befehl erfragen:

$ cf apps

Fazit

Mit dieser Umgebung kann man nun beginnen Cloud Foundry kennenzulernen. Ein weiterer Schritt wäre einen Service zu provisionieren und an eine Applikation anzubinden. CF stellt einige Services zur Verfügung z.B. die MySQL Datenbank. Auf den Community Seiten von Cloud Foundry sind Dokumentationen  von CF CLI (https://docs.cloudfoundry.org/cf-cli/) und BOSH (https://bosh.cloudfoundry.org/docs) zu finden.

Weiterführende Links:

Cloud Foundry – https://www.cloudfoundry.org/
Cloud Foundry Documentation – http://docs.cloudfoundry.org/
Cloud Foundry Service – http://docs.cloudfoundry.org/services/

Posted in Cloud, Cloud Computing, Java, Linux | Tagged , , , , , , , | Leave a comment

What must owners do when they on-sell an IoT-enabled product?

Managing Transfer of Ownership

Many products change their ownership at some point in their lifetime, and this should also be considered for IoT-enabled devices. IoT-enabled devices also inhabit a virtual dimension that needs to be either preserved, transferred, or deleted, or a combination of all three.

Preserve

Certain data may not be of a personal nature to the owner, being solely attributed to the physical device: the number of times a motor was switched on and for how long; the minimum and maximum temperatures reached in operation or storage, etc. This data accompanies the product and should be preserved. It may be useful for preventative maintenance, to learn how devices are used “for real”, or for warranty issues.

Transfer

Certain data is determined to be associated with a person or a place or a role, and the relationship between the data and the individual product is ephemeral, transitive, or temporary.

If a smart fridge is on-sold, the personal shopping list would stay with the current owner, ready to be transferred to the new model. If the new model is from a different product line, or even from different manufacturer, a method should be provided to the owner to easily access and transfer the information to the new device.

If the smart fridge is taken with the owner to a new apartment, the location of the next supermarket would need to be updated, but the personal preferences of the owner would not need to be changed. Unless, of course, the new supermarket is a different chain with a different API for their eShopping app.

If the owner of the smart fridge starts a family, the role of the fridge may change to not just being used by one person or two, but a whole family over time, each with their different needs. Who is the administrator? What rights does each person have?

Or a combination: the owner sells their own smart fridge when they move in with their new partner to a new apartment, and its fridge (which is owned by the apartment landlord) needs to retrieve both of their existing shopping preferences, for a new location, and accept the new role of being a non-personal asset.

Delete

Locally-stored peronal data should be deleted from the IoT-enabled device when ownership or the user changes, or when the device breaks or is damaged. But how does the (ex-)owner go about this, and how can that data be retrieved at a later date, if required, perhaps for use in a replacement device or simply for the sake of transparency.

Security

To preserve the security of the device and data throughout its life-cycle, manufacturers
should:

  • Identify all data collected and used by the device
    • This will ensure transparency, especially with third-party data usage
  • Provide a secure method to transfer ownership of the device to another user
    • This will allow both the old and new users to verify that the transfer of ownership has succeeded and that any sensitive data will be handled appropriately after handover.
  • Be clear which system components (devices, data, network, etc.) are owned by the user
    • Owners, tenants, retailers and manufacturers can clearly identify what their responsibilities are for ownership transfer. This will minimise the risk of security issues arising through misunderstandings of responsibilities.
  • Ensure that change of ownership does not impact security updates
    • Critical security updates must continue to be supplied, regardless of who now owns the device
Posted in Internet of Things | Tagged , , | Leave a comment

The Internet of Things: elements of delivery

What elements of an Internet of Things solution do we need to deliver (develop) to be successful?

Hardware: the Thing(s)

To develop an IoT solution we need the Things! The physical technology, the actuators and the sensors, embedded in the object that provides its functionality. The Things may be provided by a third-party, such as an open government entity that provides free access to traffic detection road loops via an open API, or a partnering manufacturing company that provides the hardware whereas we provide the service software, or we may be producing a sub-component (as an OEM) or a complete product.

Connectivity (the Internet bit)

Without the connectivity, the Things will not be a part of the Internet of Things. The protocol(s) being used are also important to choose correctly: is the Thing always connected, sometimes connected, or only rarely connected? Does the Thing only provide data, and what is the update rate, latency requirements, and complexity of the data being provided? Does the Thing do something – is it an actuator, dependent on incoming commands to fulfill its function? Not only the Thing (the end-point) need to be considered, but also the equipment along the connection path: concentrators, switches, routers, gateways, etc.., power budgets, latencies, path redundancy, etc.

Integration and interoperability (Internet or Intranet of Things)

How are the data and functionality of the Things shared or accessed with other Things and services? Is third-party access to the Thing supported or must it be marshalled through an API or cloud service, or maybe it is a private network, i.e. part of an Intranet of Things?

Data and content

Is the raw data available to your services, or is it anonymised, aggregated, or filtered through some Edge Computing? Will data be shared with third-parties? How does the data become useful, in the form of information visualised on dashboards, provided over a managed API, used in IFTTT applets, or shared with own- and third-party mobile apps?

Services and transactions

A Thing that produces data or accepts commands is a bit useless without some services. Usually presented as some form of Cloud service, a company’s ability to deliver service interactions and/or enact transactions by interacting with the device sets it aside from being a pure product-centric business. The suite of Things it produces should interact between themselves, as well as with third-party products, both physical and data.

Security

The IoT solution is not simply concerned with the security of the Things but also the services and data centres. The Things should be secure and not easily (if at all) hackable. Is this down to reliable hardware security, network security, choice of a reliable and secure software stack and foundation? Security must also allow remote and secure updates to be available.

Identity and privacy

The Thing will need to have a unique identity (classically its IPv6 address!), but may also be associated with one or more real-world users and owners. It will have its own avatar in the virtual world and may have the ability to recognise the avatars of nearby Things and users, even if they are not directly interacting with the Things (think BTLE beacons). The Things may have the ability to associate interactions with their unique profiles, preferences, protections, and individual context.

Updates and configurability

Until now, a product was more likely than not to be shipped with a particular version of software that would never be upgraded in its lifetime. Instead of purchasing upgraded functionality, the user would discard the old device and purchase a new one. The IoT has allowed manufacturers to offer their end users a new form of product: one that can be upgraded with the latest features (provided the hardware was compatible). Tesla allows their car owners to receive upgraded software and packages, without needing to wait for the next service or having to go to the workshop; it may be a new version of navigation software, autodrive software, or an extra 20 horsepower to the electric motors. Software will be used to deliver new features and extend existing capabilities to the device’s experience, security, mobile app, or power consumption.

Posted in Architecture, Internet of Things | Tagged , | Leave a comment

Securing the Internet of Things – Fundamentals

The technology of security is ever-changing but the following tenets have emerged to guide your choices:

  • Implement “security by design.” Rather than bolting-on security as an afterthought, build it into your products or services at the outset of your planning process. This is requirement #1! And test, test, test!
  • Encourage a culture of security at your company. Securing connected devices is difficult enough when you’re actually trying; it’s virtually impossible when you’re not trying at all. The culture should pervade from the top, the C-level in your company, so designate a senior executive who will be responsible for product security (e.g Chief Security Officer). Train your staff to recognize vulnerabilities and reward them when they are uncovered, regardless of how close to launch you are. If you work with service providers, component suppliers, and third-party developers, clearly articulate in your contracts the high standards you demand from them.
  • Avoid using default passwords as they quickly become widely known (this is what enabled the Mirai botnet to infect so many devices). Don’t use them unless you force the consumers to change the default during set-up – never use them if the consumer has no way of changing them.
Posted in Internet of Things, Requirement, Spezifikationen, Testing | Tagged , , | Leave a comment

Securing the Internet of Things – so many dimensions

Like the Internet of Things itself, ‘security’ has many dimensions. A common issue in German-speaking regions is that “Sicherheit” means both security and safety, but this is perhaps fortuitous in the context of IoT. Consider that to secure any one element of the following list is by no means an answer to secure the greater whole or system, although it is a step in the right direction – all items must be verified:

  • Data security – of utmost concern to individuals. Given the power of graphical databases to infer connections between otherwise unconnected data points and to extrapolate behaviour and preferences, perhaps incorrectly, is of concern when such data is used to inform business and political interactions and between individuals in the real world.
  • Device security – as shown by too-quick to market solutions that are inherently open to attack and abuse, devices must adhere to strict criteria and testing regimes and standards. A single manufacturer can undermine the faith individuals have in any IoT device.
  • Infrastructure security – the IoT end points are not the only level to be open to attack. Malicious infection of cloud services that collect data from and inform IoT devices of their next actions could cause considerable jeopardy in society’s infrastructure, far beyond just the Internet: power, water, fuel lifelines come to mind.
  • Environmental security – as above, if industrial infrastructure succumbed to an attack, the  environment is in jeopardy.
  • Network security – the Mirai botnet demonstrated a sustained DDoS attack can take down access to network services that society is more dependent on.
  • Software security – DVD encryption was undermined by a single manufacturer’s cavalier attitude to software security: suddenly the private key became public and years of work was undone.
  • Identity security – spoofing, not just of individuals, but of individual IoT end nodes should be protected against.
  • Consumer safety – interacting with a Smart Fridge should be as safe as interacting with a dumb fridge! Consumers and end users should not be concerned for their safety, nor the safety of their data and interactions that could be used for nefarious purposes.

This list will grow as technology evolves and as the IoT pervades itself into all niches of our lives and society. As demonstrated in the recent Mirai botnet DDoS attacks on Internet infrastructure, there is no silver bullet protection against cyber or IoT-related threats. The infected devices and those open to infection could be perceived as more than just a viral vector but more a form of cancer: as with the human body, we can never fully guarantee prevention from illness; the best we can do is make efforts to, at best, build immunity against threats, or, at worst, methods to warn of impending attack or infection. Collaboration in how to secure each of these elements properly and holistically, in ways that drive trust, adoption, and ethical innovation, is of central value to industry.

Posted in Internet of Things, Security | Tagged , | Leave a comment

Securing the Internet of Things – botnets on the rise

At the end of October 2016 we witnessed a truly sobering DDoS (distributed denial of service) attack on some of the DNS (Domain Name System) servers that allow browsers to interpret web URLs and translate then into IP addresses. Not once, but twice did a wave of requests, approaching many Terabytes per second, overwhelm the Dyn DNS servers in the US. This is not typical of DDoS attacks (which usually target a specific web site) and its effect were widespread, as traffic management systems and domain name services were taken down, causing Twitter, Reddit and others to remain inaccessible for many hours, even though they themselves were not directly targeted.

Recently, Post Office and Kcom broadband services, both in the UK, and Deutsche Telekom, have been hit by a hack targeting Zyxel routing hardware (specifically the AMG1302-T10B wireless router, sold under the name Speedport). Unlike the October DDoS attack that infected hardware that went on to attack other parts of the Internet infrastructure, this attack targeted the routing hardware directly, causing it to crash and disconnect the user. There have also been attacks on Russian banks and other smaller targets.

But this was just the latest of the attacks the Mirai botnet has unleashed. In what may have been a warm-up, it has been used in previous major DDoS attacks on individual sites and was therefore known to security experts. Their reaction to the 21st October attacks: a shrug and a nod – and a quiet “told you so”.

Unlike previous large-scale attacks, the botnets were not infected PCs but rather more than 500’000 infected Internet of Things (IoT) devices: mainly routers, CCTV cameras, and Digital Video Recorders (DVRs). They were targeted by the perpetrators simply because they were easy to gain access to and easy to corrupt. There may be 5 million routers currently in use that the Mirai virus, or variant, could potentially infect.

One weakness of the attack is that if an infected device is simply power-cycled, the Mirai infection will be erased. However, the vulnerability remains and the device is still open for re-infection. And to make re-infection simply a matter of time, the creator of the virus has published the source code and copycat attacks are very likely.

What’s worrying is that the issue surrounding IoT-device vulnerability is not unknown. There have been some spectacular demonstrations of cars being hacked whilst out on the road, of smart fridges being used as bots, and the myriad of smart home and smart lighting devices that have been unleashed to the public with little heed to security as time-to-market was paramount to the producers. Security costs money and these devices are sold at very low margins.

As recently as June 2016, the Federal Trade Commission (FTC) in the United States communicated with the Department of Commerce (DoC) a list of concerns surrounding security and privacy issues in connected and embedded devices, saying that while many IoT devices have tangible benefits to consumers, “these devices also create new opportunities for unauthorized persons to exploit vulnerabilities“.

One of the gravest concerns was the inability or impracticality for these devices to be upgraded should a security flaw be found. In most cases, an upgrade would require a product recall and physical replacement – but how many consumers would give up their Internet router for a few weeks, or be prepared to configure a new one when it arrived? How many would risk losing their recorded TV programs? How many would not want their security cameras to be taken down?

Many of the devices infected by Mirai have components manufactured by XiongMai Technologies and Dahua, IP camera manufacturers from China. The devices have hardcoded telnet or SSH credentials that cannot be changed, so providing the easiest infection vector. The manufacturers have responded by recalling their products but, given the consumer objections mentioned above, many of the already-sold products will remain connected and infected: their action will only lead to taking unsold, vulnerable stock off shelves.

Normal (PC) botnets can usually be patched and devices disinfected, but disinfecting and patching compromised IoT devices is much more complicated. Many of these devices are hard to get to (e.g. CCTV cameras up high on a building), or the patches require a factory reset (e.g. leading to losing DVR recordings valuable to the customer), and their owners are reticent to patch them even when vendors make fixes available, which is rare. The devices usually continue to function even when infected, so the customer does not see returning or patching the devices as a priority. They are also cheap and seen as disposable by the manufacturer, so developing and distributing a patch to an old model is not cost-effective. The longevity of even the cheapest device means it will remain infected and a host for many years to come. And building security into them during the design process isn’t high on the list either, obviously.

There’s currently little to no incentive for vendors to dig deep on this issue, especially without any pressure from regulators or users. Consumers want a cheap solution and if it works, even if infected, they perceive security as someone else’s problem! Whereas quality brand names may offer a secure device, many (the majority of?) consumers would chose a no-name box so long as it works, lasts, and is cheap. As cheap, non-branded (OEM) devices, there is no brand image to protect, so the manufacturer is not self-incentivised. Securing connected devices is difficult enough when you’re actually trying; it’s virtually impossible when you’re not trying at all.

As a Swiss manufacturer, your customers value the quality you build-in to your IoT products. Security must be the number 1 requirement, designed and built-in from day one, continually tested and probed. Adding security later on in the development cycle will lead to increased costs and timelines, and perhaps reduction of features to enable security to be shoehorned into an existing product. A product recall can be disastrous to a brand (see Samsung and their Note 7), so be pre-emptive and never let yourself be seduced to go down that path.

 

Posted in Internet of Things | Tagged , , , , | Leave a comment