• About Me Card

Max Hemingway

~ Musings as I work through life, career and everything.

Max Hemingway

Category Archives: Architecture

8 Free “For Dummies” books you should read in 2016

12 Tuesday Jan 2016

Posted by Max Hemingway in Architecture, Cloud, Development, DevOps/OpsDev, Enterprise Architecture, Innovation, Programming, Security

≈ Leave a comment

Tags

Architecture, Development, DevOps, Knowledge, OpsDev, Productivity, Programming, Security, Tools

There has been a lot of the free smaller versions of the “For Dummies” books published recently. These are normally sponsored by a company to help promote a way of thinking/product/etc, however they do contain useful overviews and information on the subject that they are presenting on.

Here are my top 8 of these which should be on your reading list for the start of 2016. All are downloadable in PDF format*.

Agile for Dummies

API for Dummies

DevOps for Dummies

Micro-segmentation for Dummies

Next Generation Endpoint Security for Dummies

Software Defined Data Centres for Dummies

Software Defined Networking for Dummies

Software Defined Storage for Dummies

*You may need to sign up to receive some of these books.

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Email
  • Pinterest

Like this:

Like Loading...

Manual tasks of today should be the Automated tasks of tomorrow

11 Monday Jan 2016

Posted by Max Hemingway in Architecture, Development, DevOps/OpsDev, Innovation, Open Source, Productivity, Programming, Tools

≈ 10 Comments

Tags

Architecture, Development, DevOps, Open Source, Productivity, Tools

“Manual tasks of today should be the Automated tasks of tomorrow”.

CogsThere are lots of Automation tools available to people and businesses today to automate tasks that are carried out in a manual way. The pace at which this is happening is varying based on Habits and Patterns that we use on a daily basis. Also because change is involved which sometimes causes its own set of anxieties and issues.

Back in 2012 Bruno Oliveir published a graph on G+ on Geeks and repetitive tasks, which, shows a view of time vs task and how as geek vs non geek might approach automation.

geeks-vs-nongeeks-repetitive-tasks

An alternative view was published by Jon Udell in 2012 – Another way to think about geeks and repetitive tasks which shows an alternative view adding in more steps to show repetition.

alternate-view-of-automation

xkcd has an interesting view on the subject that does ring true in some cases where something does not exist and needs to be created in order to Automate.

automation

You need to be careful that in spending lots of time in trying to automate a task, that you don’t may spend more time in developing automation than could have been spent actually doing the task.

To get over this an element that is missing from these graphs is reuse and blueprints/patterns. The chances are that someone else has had a go at doing what your about to automate so there may be something to reuse rather than developing something yourself.

There are lots of tools and code repositories available today with more being developed. It will depend upon what you are automating as what to use.

Some of the tools available include;

  • Chef
  • Docker
  • Github
  • Jenkins
  • Jira
  • Powershell
  • Puppet

There are too many to list – lots of others available.

Using an Agile approach as well may reduce the length of the task size line on the graph as you do not need to boil the ocean to automate. Break up tasks into their components and you may find it easier to automate.

These tools are also bringing the geek and non geek lines together as Application’s and API’s make it easier for automation to be implemented. The plot of the graph changes into a repeatable process and in effect becomes a loop for both the geeks and non geeks.

Automate

So what will you automate today?

 

 

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Email
  • Pinterest

Like this:

Like Loading...

An A-Z Guide to being an Architect

07 Thursday Jan 2016

Posted by Max Hemingway in Architecture, Big Data, Cloud, Development, DevOps/OpsDev, Enterprise Architecture, Governance, Innovation, IoT, Open Source, Productivity, Programming, Security, Social Media, Tools

≈ Leave a comment

Tags

Architecture, Cloud, CPD, Data, Development, DevOps, Innovation, IoT, Knowledge, learning, Open Source, OpsDev, Productivity, Programming, Social Media

Back in 2008 Microsoft published An A-Z Guide to ABCBeing an Architect in their Architecture Journals.

Here is my take on an updated A to Z Guide to being an Architect. A couple of these may be similar.

A – Architect

Having the right level of skills as an Architect or engaging an Architect with the right level of skills will depend on the work needing to be undertaken. There are several types of Architect with some specialising in certain areas and others being multi domain skilled. The list below covers some of the different types of Architect- this is not an exhaustive list:

  • Enterprise Architect
  • Information Architect
  • Solutions Architect
  • Software Architect
  • Systems Architect

B – Blueprints

Following Blueprints and Patterns either published by vendors (such as the Microsoft Blueprints) or developed internally around your products and services will ensure repeat-ability and cost control around the design process.

Some examples showing different pattern types can be found at Architecture Patterns

C – Contextual Web Era

The up and coming 4th Platform area is the Contextual Web Era

  • 1st Platform – Mainframe Era
  • 2nd Platform – Client Server Era
  • 3rd Platform – Cloud Era
  • 4th Platform – Contextual Web Era

This is an up and coming era with lots of new innovation and developments. Keeping up with developments is key going forward for any architect to understand designs/solutions, art of the possible now and future, innovation and for developing roadmaps for solutions.

D – DevOps

To quote Wikipedia – “DevOps (a clipped compound of “development” and “operations”) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes”. Having knowledge of DevOps, OpsDev and Agile assist with Architecting a solution for a business understanding their practices and modes of interacting with technology to meet business requirements. A Good book on the subject of DevOps is “The Phoenix Project” by Gene Kim.

E – Enterprise Architecture

EA (Enterprise Architecture) is a blueprint that defines how a business can meet its objectives and strategy. This is achieved by conducting analysis, design, planning, recommendations and implementations through an Enterprise Architecture Framework

Enterprise Architecture Wikibook

F – Four Two Zero One Zero

42010 is the ISO Standard that most frameworks adhere to. Working to a Framework brings structure to your designs and life cycles.

There are a number of frame works available such as:

  • DoDAF
  • MoDAF
  • TOGAF
  • Zachman
  • Other Frameworks are available

Enterprise Architecture Wikipedia Book

G – Governance

Governance is an important part of architecture as it

  • Ensures Conformance
  • Controls Variance
  • Maintains Vitality
  • Enables Communication
  • Sets Direction
  • Issue Resolution
  • Provides Guidance and Prioritisation
  • Promotes Best Practise
  • Minimises Risk
  • Protects IT environments from tactical IT changes, project solutions, and strategic proposals that are not in an organisations global best interest
  • Controlling Technical Diversity, Over-Engineering and Unnecessary Complexity
  • Ensures projects can proceed quickly & efficiently
  • Control over IT spend
  • Quality Standards
  • Efficient and optimal use of resources and increase the effectiveness of IT processes

H – Hands On

It is important to be current and understand the technologies you are architecting. There are lots of options available to get your hands dirty using technology from using Cloud Servers to virtual machines on your compute device. There are other computing devices such as the Raspberry PI that provide a cheap alternative to standing up small farms to learn on.

I – IoT

IoT (Internet of Things) is where physical things are connected by the internet using embedded sensors, software, networks and electronics. This allows the items to be managed, controlled and reported on. My blog posts on IoT Device Security Considerations and Security Layers goes into more detail on this subject.

J – Juxtaposition

Juxtaposition is something an architect should be doing to compare things/items/artefacts etc.
noun;
1. an act or instance of placing close together or side by side, especially for comparison or contrast.
2.the state of being close together or side by side.

Source:http://dictionary.reference.com/browse/juxtaposition

K – Knowledge

I would class Skills with Knowledge. It is important as an Architect to ensure that your skills/knowledge are up to date and where you are unsure of a technology, you have a plan to address and skill up. Build a good CPD (Continuing Professional Development) plan and work towards completing it.

L – Language

With the move to cloud it is important to ensure your scripting skills are up to date as most cloud platforms use scripting to assist with the deployment of environments. This is also true of other DevOps/OpsDev applications. If you are unsure on what to learn this guide may help you – Learn a Programming Language – But which one?

M -Micro Segmentation

Micro Segmentation allows a business to use Networks, Compute and Storage to automate and deliver complex solutions by carving up and using the infrastructure. This segments part of the infrastructures to specific functions/tasks. It can also be used in a security context to segment networks, firewalls, compute and storage to increase security and reduce cyber attacks.  VMware have produced a book “Micro Segmentation for Dummies” that can be downloaded from here.

N – Next Generation

Next Generation refers to the next stage or development to something such as a new release of hardware or software. Next Generation is becoming a common term now to define products and artefacts, an example being Next Generation Firewalls.

O – Open Source

Open Source has been available for a long time with software such a Linux, however there is a bigger shift towards using Open Source and acceptance by businesses. Some examples of Open Source that is now mainstream within business include;

  • Ansible
  • Chef
  • Docker
  • Puppet

P – Performance

Performance can cover people as well as solutions / systems. Performance metrics should be set out at the inception of an engagement then monitored and reported on. This will be a factor in driving Continuous Improvement going forward as well as forecasting / planning for future upgrades and expansion.

Q – Quality

Quality is a huge subject and has a lot if standards governing it and how it affects all aspects of business and architecture. Knowing which standards and how they affect a solution will assist in the whole architecture lifecycle. There are also a number of tools available to help you;

  • Architecture Frameworks
  • ITIL
  • Six Sigma

There is also a level of pride and satisfaction in producing a quality solution and system achieving the objectives and requirements set out by the business.

R- Roadmap

Any architecture/solution should have a roadmap to set out its future. Roadmaps should include items such as:

  • Current state
  • Future state
  • Innovation
  • Upgrades / Releases
  • New Features / Functions
  • End of Life / Replacement

S – SMAC

SMAC stands for Social, Mobile, Analytics, Cloud. SMAC is an acronym that covers the areas and concepts when these four technologies are brought together to drive innovation in business. A good description of SMAC written by a colleague can be found here Acronyms SMAC.

T – Transformation

The majority, if not all systems will undergo a form of transformation. This may be in the form of a simple upgrade or to a complex redesign and migration to something else.

U – UX

UX (User eXperience) affects how people interact with your architecture / design and how they feel about it (emotions and attitudes). With the boom in apps and the nearing Contextual Web Era, UX is one of the most important factors to getting an architecture used. If your users don’t like the system they may find something else to use that they like.

V – Vision

Understanding the vision of your customer and their business is the driving factor for any architecture.

On working with your customer you should look to become a Trusted Advisor and also with your colleagues. A great book on the subject is The Trusted Advisor by David Maister. The book covers 3 main areas which discusses perspectives on trust, the structure of trust building and putting trust to work.

W – WWW

The internet is a key delivery mechanism for systems. Knowing how this works and key components to the internet should be understood such as:

  • IPV4 – IPV6
  • DNS
  • Routing
  • Connectivity
  • Security

X – X86

X86 – is a standard that every knows as its one of the most common platform types available.

Y – Year

Year is for the longevity of the solution you are designing. How many years are your expecting it to last What are the Business Requirements, statutory obligations, depreciation etc that need to be planned in. Consider things like End of Life, Maintenance and Upgrades on hardware and software from a solution point of view.

Z – Zero Defects

The best solution is the one with zero defects, but reaching this goal can be a challenge and can also consume a lot of expense. The best way to ensure Zero Defects is to use:

  • Best Practice
  • Reference Architectures
  • Blueprints/Patterns
  • Checklists
  • Reuse
  • Lessons Learnt

This is my current A to Z and some of the entries may be different in your version so “What is in your A to Z of being an Architect?”

I will look to write some further blog posts on the areas listed in this A to Z

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Email
  • Pinterest

Like this:

Like Loading...

IoT Device Security Considerations and Security Layers – User Interface

11 Wednesday Nov 2015

Posted by Max Hemingway in Architecture, IoT, Programming, Security

≈ 4 Comments

Tags

Architecture, IoT, Programming, Security

ThingsThe next area in my series on IoT Device Security Considerations and Security Layers is the User Interface.

Many IoT solutions may just have a standard Web interface to a back end system where IoT Devices and Sensors can be controlled. There is already a lot of documentation on good practices for the Web front end.

In some cases the User Interface may be on the IoT device or not delivered over a Web interface. In these cases many of the good practices for Web front ends can still be applied.

Here are a few of the main considerations:

User Interface

User experience is key to any system, however security is as well. When designing your User Interface you should consider the functionality needed to what the user requirements are, keeping the design slick reduces options for hackers to exploit.

Following good code practices and testing will help in this area.

Identification and Authentication

Most applications these days requires a form of log on and password to links into another system for identification such as AD, LDAP or SSO (Single Sign On).

Ensuring that a strong password policy is in place with rules such as:

  • At least 8 characters long
  • Includes alphanumeric characters
  • Different from previous password
  • No complete words
  • At least 1 upper case character
  • At least 1 lower case character
  • At least 1 number
  • At least 1 special character

Some of these rules will depend if you are authenticating against an existing directory system and its current policies. you should consider changing them if they are not secure.

This in turn allows for the authentication of users against other methods such as a 2 factor.

User Interface

Error Messages

Firstly ensuring that the application and interface have good error handling to reduce the number of messages that the user sees should something unexpected happen.

Secondly having simple well defined error messages reduces exposure of what systems you are running or the type of code that can appear in some errors.

Some further reading:

  • Guide to Authentication
  • Authentication cheat sheet
  • Basic Security Practices for Web Applications

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Email
  • Pinterest

Like this:

Like Loading...

IoT Device Security Considerations and Security Layers – Device/Application API’s

09 Monday Nov 2015

Posted by Max Hemingway in Architecture, IoT, Programming, Security

≈ 4 Comments

Tags

Architecture, IoT, Programming, Security

ThingsFurthering my series on “IoT Device Security Considerations and Security Layers” next in the stack is the Device/Application API’s.

API’s (Application Programming Interface) provide a capability to easily interact with a system. This could be an API to an IoT Sensor that a server application could use to get information from through using a set of common libraries and functions.

IoT API

APIs often come in the form of a library that includes specifications for routines, data structures, object classes, and variables. In other cases, notably SOAP and REST services, an API is simply a specification of remote calls exposed to the API consumers.
-Wikipedia

There are a number of steps you can take to secure your API’s:

Standards

Follow any standards/security standards available for the systems you are working with. As discussed in previous blog posts standards for the IoT is one area that is still being defined.

Libraries

Installing only the API’s/libraries you need for your application/IoT Device/IoT Sensor (or un-installing any unused API’s/libraries) 

Secure Messaging

Where feasible using Secure Messaging using a level of authentication ensures that the API is communicating and operating with the right system. This ensures that the IoT Device/Sensor can only interface with the correct system and not accept any rogue requests.

Error Handling

An API should be able to understand what to do when it detects an error condition and what to do when it cant. This is important so false instructions/data cannot be sent to the API to make it fail and then be open to attack.

Patching

Using the most up to date version of the API’s/libraries will ensure any bugs or issues have been removed reducing any exposure to attacks that hit known issues. employing a regular patching capability where possible maintains a level of security. It may not be possible to update IoT Devices/Sensors that are embedded, however any server side API’s/libraries should be up to date. This will however increase compatibility testing with the IoT Devices/Sensors to ensure the interfaces still work.

Further Reading

OWASP REST Security Cheat Sheet

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Email
  • Pinterest

Like this:

Like Loading...

IoT Device Security Considerations and Security Layers – Operating System

21 Wednesday Oct 2015

Posted by Max Hemingway in Architecture, IoT, Security

≈ 4 Comments

Tags

Architecture, IoT, Security

ThingsAnother post in the series on “IoT Device Security Considerations and Security Layers“, this time looking at Operating Systems.

There are many Operating Systems available for use on IoT devices and there are more being developed all the time. These range from specific Operating Systems targeted at a specific IoT Chip set to ones that can be used across a number of devices. Some of the names in this field are well known by every day consumers and some not so well known but are strong in this area.

IoT Operating Systems

At this time there are not many standards agreed across the industry, but more group specific depending upon which platform you are developing on. The main standards that exist are around networking and connectivity. Groups and Communities currently discussing and creating IoT Standards). Some of these are around security and securing the IoT devices.

There are a number of standard practices that you can carry out to help secure your IoT device at the Operating System level:

Right Operating System

Choosing the right Operating System is key to ensuring your IoT Device will function as you require it to and support the applications you are using. You should look to only install the Operating Systems elements that are needed to reduce any future Security Issues through none used modules. Streamlining (or removing none used modules) also reduces the amount of space needed on the IoT device.

Upgrades

Upgrading to latest versions of the Operating System at regular intervals will ensure that you have the latest software and that additional space is not taken up with old patching files. This also ensures any known security holes in the Operating System are protected. This also has the added benefit of keeping up with any new features introduced into the Operating System.

Patching

Patching of both the hardware BIOS and Operating System should be considered. Ensuring that the BIOS is at the latest level makes any patching more effective as the Operating System and patches are normally created and tested on the latest hardware and releases.

Regular patching needs to be carried out in order to fix any known exploits or Security holes in the Operating System/ Some latest Operating Systems patch automatically at a regular interval which when configured allow this task to just be a monitored one to ensure devices are being updated.

Access

Only allowing the users or systems that need access to the device and removing all other accounts and access rights will secure the device. The levels of access control, user id’s and passwords will be dependent on the Operating System used. These can range from local settings to a centralised control such as Active Directory.

Below are some links to Operating Systems and their supported hardware platforms.

Brillo

  • https://developers.google.com/brillo/?hl=en

Contiki

  • http://www.contiki-os.org/
  • http://www.contiki-os.org/hardware.html

FreeRTOS

  • http://www.freertos.org/
  • http://www.freertos.org/RTOS_ports.html

Linux

http://www.linux.org/

mbedOS

  • https://www.mbed.com/en/development/software/mbed-os/

Microsoft

  • http://www.microsoft.com/en-gb/server-cloud/internet-of-things/overview.aspx

OpenWSN

  • https://openwsn.atlassian.net/wiki/pages/viewpage.action?pageId=688187
  • https://openwsn.atlassian.net/wiki/display/OW/Hardware

Riot

  • http://www.riot-os.org/
  • http://www.riot-os.org/#usage

Tiny OS

  • http://www.tinyos.net/
  • http://tinyos.stanford.edu/tinyos-wiki/index.php/FAQ

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Email
  • Pinterest

Like this:

Like Loading...

IoT Device Security Considerations and Security Layers – Sensor/Instruments

12 Monday Oct 2015

Posted by Max Hemingway in Architecture, IoT, Security

≈ 4 Comments

Tags

Architecture, IoT, Security

ThingsNext in the blog series “IoT Device Security Considerations and Security Layers” is Sensors and Instruments.

There are many different sensor types ranging from the consumer available to those used in industry and specialised, e.g:

  • Barometric Pressure sensor
  • Temperature sensor
  • Altitude sensor
  • Colour sensor
  • Accelerometer sensor
  • Compass sensor
  • Humidity sensor
  • Proximity sensor
  • Motion sensor
  • Light sensor
  • Roation sensor
  • Water sensor
  • Heat sensor

Sensors will typically be connected hard wired or remote.

IoT Sensors by Max Hemingway

Security for Wired sensors will be inherently secure as the connectivity is over a physical wire.

Where there is wireless connectivity the type of wireless used should be considered with security in mind. This is called a WSN (Wireless Sensor Network)

The list of considerations could be listed as:

  • Wireless Protocol
  • Authentication
  • Encryption
  • Pairing
  • Signal strengths and limitations
  • Certificates

Some good white papers that cover WSN’s and security considerations are:

  • Internet of Things: Wireless Sensor Networks
  • Wireless Sensor Networks and the Internet of Things: Do We Need a Complete Integration?

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Email
  • Pinterest

Like this:

Like Loading...

IoT Device Security Considerations and Security Layers – Storage/Data

08 Thursday Oct 2015

Posted by Max Hemingway in Architecture, IoT, Security

≈ 4 Comments

Tags

Architecture, IoT, Security

ThingsThe next layer to cover in my blog series on IoT Device Security Considerations and Security Layers is that of Storage and Data.

Breaking IoT down to a basic form there will be two main sorts of IoT devices:

  • Those with local data storage on the IoT Device
  • and those without

That’s not to say that there would be a local storage system nearby such as sensors in a car having an on-board storage system for data that is then sent to a central system somewhere.

Either way, the future data economy will be huge. The IoT is predicted to create masses of data. Cisco have predicted this growing to 403 zettabytes a year by 2018.

Internet of Everything (IoE) Potential Impact on Cloud

●   Globally, the data created by IoE devices will reach 403 ZB per year (33.6 ZB per month) by 2018, up from 113.4 ZB per year (9.4 ZB per month) in 2013.

●   Globally, the data created by IoE devices will be 277 times higher than the amount of data being transmitted to data centers from end-user devices and 47 times higher than total data center traffic by 2018.

(Source Cisco)

That’s a lot of data to secure!

When looking at Storage and Data security the main consideration on securing data should be around data relevancy and what should actually be stored. This can be done locally at the IoT device with the programme/application collecting data at specific intervals or back at a collection system that applies policies to the data and filters out the relevant data, deleting the rest (Both could be done).

IoT Data by Max Hemingway

(Click diagram for a larger version)

Defining a Data Life Cycle is a key part to IoT Data Security.

Security of data on the device will depend upon the local security designed. There may be nothing stopping a sensor physically being stolen or tampered with, however electronically and through software other measures can be taken.

Storing data on a centralised solution and applying a level of security around that would provide a more secure environment as data transmitted could be encrypted through the network elements used.  Back end solutions will probably use standard solutions available today with well defined security standards and options available to secure data.

Where data is stored locally on the IoT device adding things like encryption at rest to data on a device may be necessary in some cases, but the flip side is an impact to the responsiveness of the device and data retrieval. This also adds to the complexity of the device and ultimately cost.

Personal security may also factor into the IoT Device solution, such as a wearable device on the wrist to record fitness data. As it is worn and secured onto the consumers wrist it may be classed as secure until the consumer went to a data point to upload their latest statistical data and analyse the results. Data is stored locally in this use case and then uploaded to a central point afterwards.

To summarise a list of considerations:

  • Local or Central Storage
  • Data Life Cycle
  • Data relevancy
  • Data retention policies
  • Encryption
  • Back end system data security
  • Security by use (ie. wearables)

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Email
  • Pinterest

Like this:

Like Loading...

IoT Device Security Considerations and Security Layers – Chipset

07 Wednesday Oct 2015

Posted by Max Hemingway in Architecture, IoT, Security

≈ 4 Comments

Tags

Architecture, IoT, Security

ThingsContinuing the theme of IoT Security as first discussed in my post IoT Device Security Considerations and Security Layers, the next layer to look at is the Chipset.

There are lots of different chipsets available that can be used for IoT devices such as ARM, Intel, TI, etc. There are also lots of development platforms utilising these and other chipsets such as Raspberry Pi, Beagle, MinnowBoard MAX, Contiki, TinyOS, Nano-RK, Launchpad etc that consume these chipsets.

Chipset manufacturers have already recognised the importance of having a good security layer and security features within and supported by the chipsets manufactured for the IoT.

To build on this capability some manufactures are buying security solutions to complement and enhance, whilst others are creating.

  • ARM Expands IoT Security Capability with Acquisition of Sansa Security
  • Intel working with McAfee

These developments by Chipset manufacturers means that IoT Security is high on their agenda and provides the industry and consumer with a large amount of choice on additional security features based on chip and that can work with the chip in form of software.

As the IoT develops so will the security enhancements and capabilities of these devices.

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Email
  • Pinterest

Like this:

Like Loading...

IoT Device Security Considerations and Security Layers – Power Source

06 Tuesday Oct 2015

Posted by Max Hemingway in Architecture, IoT, Security

≈ 4 Comments

Tags

Architecture, IoT, Security

ThingsFollowing on from my post on IoT Device Security Considerations and Security Layers the subject of this blog post is to look at the Power Source layer.

Power Sources for IoT Devices will differ depending upon the type of IoT Device being used or designed and its use, however they will fall into 3 main source of power.

  • Mains
  • Battery
  • Wireless

So how secure is a power source? There have been demonstrations on how data can be hacked through power outlets (How to use electrical outlets and cheap lasers to steal data) which have concentrated on using the fluctuations and noise in the power supply to work out what is being typed. This would effect both mains and wireless connections as these could be monitored in some way.  Battery presents a more secure method of providing a power supply.

At present any breaches using a power source are few and far between, however as the IoT connected world continues to evolve, perhaps this is one area that more security considerations are needed.

Not all IoT Devices will need mains power as there is a huge drive for wearables and mobile. The mains power would be aimed more at IoT devices within a business (such as plant machinery sensors) or a home system (turning on power or heating).

Mains also provides a medium to connect IoT devices such as Smart Meters or a Home Network over the mains using Ethernet to Power converters. IoT devices may well utilise this as a method to communicate back to a local hub, then off to a central hub via normal network connectivity.

There are already standards/rules for smart meters set out to protect devices and consumers around:

  • Data Access and Privacy
  • Security

(Smart meters and how they work)

Battery IoT Devices tend to be self contained for power and apart from a future change of the battery when its power expires connectivity and networking tend to be through the front end.

As the IoT advances there will be advancements in the protection for devices and in the rules that govern them. Not all devices will be equal with the same power needs, but one thing is constant. They all need power to operate in one form or another.

Some useful links:

  • IEEE IoT Standards
  • Groups and Communities currently discussing and creating IoT Standards

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Email
  • Pinterest

Like this:

Like Loading...
← Older posts

Technology Couch Podcast

Technology Couch Podcast

Topical discussions with different guests on Technology

Chat and views on latest Technology trends, news and what is currently hot in the industry

Max Hemingway

  • Listen on Apple Podcasts
  • Podcast RSS Feed

RSS Feed

RSS Feed RSS - Posts

Currently Reading

@HemingwayReads

Other Publications I contribute to

https://sparrowhawkbushcraft.com/

Recent Posts

  • My Virtual Selfie – Avatars and Identity Security
  • Air Launching Satellites into Space – UK First
  • Our Acceptance of Modern Technologies
  • Pen based Productivity Tools – The Chronodex 2023
  • Top 10 Tech Podcasts for 2023

Categories

  • 21st Century Human
  • 3D Printing
  • Applications
  • Architecture
  • Arduino
  • Automation
  • BCS
  • Big Data
  • Certification
  • Cloud
  • Cobotics
  • Connected Home
  • Data
  • Data Fellowship
  • Data Science
  • Development
  • DevOps/OpsDev
  • Digital
  • DigitalFit
  • Drone
  • Enterprise Architecture
  • F-TAG
  • Governance
  • Health
  • Innovation
  • IoT
  • Machine Learning
  • Micro:Bit
  • Mindset
  • Mobiles
  • Networks
  • Open Source
  • Podcasts
  • Productivity
  • Programming
  • Quantum
  • Raspberry Pi
  • Robotics
  • Scouting
  • Scouts
  • Security
  • Smart Home
  • Social Media
  • Space
  • STEM
  • Tools
  • Uncategorized
  • Wearable Tech
  • Windows
  • xR

Archives

Reading Shelf

Archives

Recent Posts

  • My Virtual Selfie – Avatars and Identity Security
  • Air Launching Satellites into Space – UK First
  • Our Acceptance of Modern Technologies
  • Pen based Productivity Tools – The Chronodex 2023
  • Top 10 Tech Podcasts for 2023

Top Posts & Pages

  • Data Fellowship - BCS Level 4 Certificate in Data Analysis Tools
  • A formula for Innovation
  • Have you tried R yet?
  • Personal Knowledge Management System
  • The Nature and Cycle of CPD
  • Data Fellowship - BCS Level 4 Diploma in Data Analysis Concepts
  • My Virtual Selfie - Avatars and Identity Security

Category Cloud

21st Century Human Architecture Automation Big Data Cloud Cobotics Data Data Science Development DevOps/OpsDev Digital DigitalFit Enterprise Architecture Governance Innovation IoT Machine Learning Mindset Open Source Podcasts Productivity Programming Raspberry Pi Robotics Security Social Media STEM Tools Uncategorized Wearable Tech

Tags

# 3D Printing 21st Century Human Applications Architecture Automation BCS Big Data Blockchain Certification Cloud Cobot Cobotics Coding Communication Connected Home Continuous Delivery CPD Data Data Fellowship Data Science Delivery Development DevOps Digital DigitalFit Digital Human Docker Drone Email Encryption Enterprise Architecture Framework GTD Hashtag Infographic Information Theory Innovation IoT Journal Knowledge learning Machine Learning Micro:Bit MicroLearning Mindset Mixed Reality Networks Open Source OpsDev PKMS Podcasts Productivity Programming Proving It R RaspberryPI Robot Robotics Scouts Security Smart Home Social Media Standards Statistical Inference STEM Technology Couch Podcast Thinking Tools Training Visualisation Voice Wearable Tech Windows xR

License

Creative Commons Licence
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Meta

  • Register
  • Log in
  • Entries feed
  • Comments feed
  • WordPress.com

Blog at WordPress.com.

  • Follow Following
    • Max Hemingway
    • Join 71 other followers
    • Already have a WordPress.com account? Log in now.
    • Max Hemingway
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...
 

    %d bloggers like this: