Following the latest Build 2016 conference Microsoft have new released a number of resources and videos on Channel 9, providing 49 pages of videos and presentations.
Lots of learning available.
Following the latest Build 2016 conference Microsoft have new released a number of resources and videos on Channel 9, providing 49 pages of videos and presentations.
Lots of learning available.
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*.
*You may need to sign up to receive some of these books.
“Manual tasks of today should be the Automated tasks of tomorrow”.
There 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.
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.
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.
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;
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.
So what will you automate today?
Back in 2008 Microsoft published An A-Z Guide to Being 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:
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
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
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:
G – Governance
Governance is an important part of architecture as it
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
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;
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;
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.
Any architecture/solution should have a roadmap to set out its future. Roadmaps should include items such as:
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:
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:
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
The 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 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:
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.
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:
Furthering 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.
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.
There are a number of steps you can take to secure your API’s:
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.
Installing only the API’s/libraries you need for your application/IoT Device/IoT Sensor (or un-installing any unused API’s/libraries)
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.
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.
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.
Another 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.
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.
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 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.
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.
Next 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:
Sensors will typically be connected hard wired or remote.
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:
Some good white papers that cover WSN’s and security considerations are:
The 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:
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.
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).
(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:
Continuing 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.
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.