Category: Security Services

UpTime Sciences specializes in Managed Security Services including: 24×7 Security Information Event Monitoring (SIEM), 24×7 Security Information Alerting, 24×7 Security Event Remediation, 24×7 Live Analysis & Alerting, Printer Management, Security Consultation, IT Compliance Preparation and Response (PCI, HIPPA, SOX, NERC, ISO, GLBA, GPG13), Vulnerability Scanning, Threat Detection, Intrusion Detection (Network-based/Host-based), Automated Asset Discovery, Behavioral Monitoring, Active/Passive Network Scanning, Virus Cleanup

On Being Special

Dear Securitarians,

You are all special.  And I do mean special.  Each and every one of you is a valued member of a small and very important community, a community of talented and trusted people with access to a lot of valuable client resources.  As employees of a Managed Service Provider, you have a level of access and trust that is difficult to come by.  It takes years of building strong relationships, by performing services above and beyond the call of duty, and maintaining open and honest communications with our clients.  Because of this high degree of trust, our clients give us great access to all of their data, and it is that privilege, the ability to access everything in a lot of places, that makes us a hot target.

Starting back in 2006, China decided that breaking into firms, one at a time, to steal intellectual secrets and other valuable data, took too much time.  Each system had to be probed, tested, researched and then tried again before some vulnerability could be found and the goods could be extracted.  They decided to save time by focusing on Managed Service Providers (MSPs), since MSPs have access to *lots* of valuable systems and have administrative rights to boot.  Breaking into an MSP and stealing the credentials to all of the MSP clients saves a bucket load of time.

The Chinese hacking group named APT10 developed a campaign that used a sophisticated set of tricks against MSPs in dozens of countries.  Malware downloaded by APT10 victims posed as legitimate software to fool AV systems.  They also leveraged Dynamic DNS in conjunction with hundreds of IP addresses and over 1,300 unique domain names to avoid Command and Control (C&C) addresses being blacklisted.  This campaign has gone on for years, and continues to this day, as seen in the recent Cloud/Island Hopper attacks.   And other groups beyond APT10 have dogpiled on. 

Back in February, a very good security friend of ours (Tim!) sent me a link to a very bad story where an MSP was hacked due to a vulnerability in their RMM tool (Kaseya).    More recent attacks by unknown assailants have been via drive-by downloads,  and via a Webroot Management Console.  Other attackers have shifted just slightly to attacking and compromising software providers, as seen last week when hundreds of dentist offices in the US were hit by ransomware.

With the increasing complexity of firewalls and intrusion defense tools, Social Engineering attacks have become the more common and easier way to gain entry into a target, even against MSPs.  Because of this, Social Engineering attacks continue to rise.  A Q1 2019 Proofpoint survey of 7,000 IT professionals details the extent of social engineering attacks:

  • 83% of survey respondents said they experienced e-mail phishing attacks in 2018
  • 64% of InfoSec professionals experienced e-mail spear phishing in 2018
  • 49% of respondents who said they experienced vishing (phone calls) and smishing (SMS text messages) attacks

The numbers for e-mail phishing and spear phishing attacks are not terribly surprising, and while the number of attacks is high, they have been going up for a long time.  However, as the adoption of mobile devices for work duty has also continued to rise, the shifting of Social Engineering attacks towards mobile devices via vishing and smishing becomes much more important and to which we should pay attention.  Mobile devices do not always display all of the visual cues, such as hover display, that you get on a desktop or laptop system, so busy workers often trust the content on their phones far more than they should.

Since we are doing more and more work on our mobile devices and since more attacks are coming at us through them, we must be ever vigilant to protect our clients when we are out and about.  Verify sensitive and unexpected requests with a follow-up phone call before launching into the work.  This is not a bother for the client.  Calling a client to verify that the request is real, and to codify details, tells the client that you take the security of their data seriously.

Comments? Questions? Grave concerns?  Please holler.

Hal

How to Get That Old Laptop Back On The Domain

 

 

 

Occasionally, an old machine dies.  It is always a surprise to the client that a six year old laptop running Windows 7 can die, but, sadly, as we technigenarians know it, tragedy can strike the computer world at any time.  The fatal flaws in SSL 3.  Speculative-execution vulnerabilities in every modern processor.  The soap opera that is Java.  We have seen behind technology’s shimmery curtain and it is ugly backstage. 

 

Clients, though, expect their soft and hard gear to last sometime beyond forever, so they save their Office95 licenses, their replaced Pentium workstations, their 12 pound laptops.  Then, when one of their Old Production Machines topples over, what do they do?  They dig out the Even Older Production Machine that has been sitting in a closet for a year, plug it in and naively expect it to just hop up and go.  Never mind that it will take three hours just to finish running Windows updates.  Ignore the time required for updating 3PAs (Third-Party Apps), ’cause Flash hasn’t changed much, right? 

 

But, what about getting WOR-CREAKY back on the Domain again?  Since it has been way more than 30 days (the policy default), the machine password has aged out and it will not reconnect to the domain and allow current domain credentials to login without some help.  Wouldn’t it be nice to not have to go through the usual join-to-workgroup-reboot-join-to-domain-reboot? Enter one handy PowerShell command – Reset-ComputerMachinePassword.

 

The Reset-ComputerMachinePassword is run from ol’ CREAKY through an Administrative PowerShell session.  This means being logged onto the machine using a local Administrator account.  If you are using some sort of Remote Machine Management tool that gives you admin rights to run commands then you can use that. If not, then you will have to use a local admin user that has already been setup on the machine before it was mothballed. If that is the case, you will have to do some sort of password recovery on the machine. You will have to look elsewhere to get that done.

 

Once you have logged in and started PowerShell as Administrator, run the command with a couple of parameters.  Reset the password for the local computer by noting a specific domain controller:

 

Reset-ComputerMachinePassword -Server “DC01” -Credential CLIENTDOMAIN\JoeBobUser

 

That’s it.  If you can think of something to add, please let us know.

 

References:

 

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age

 

https://techcommunity.microsoft.com/t5/Ask-the-Directory-Services-Team/Machine-Account-Password-Process/ba-p/396026

 

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/reset-computermachinepassword?view=powershell-5.1

Always Keep Them Guessing

I’m going to start our columnist-reader conversation simply, with a short but important tech practice: Password management.

Yeah, I know, that’s downright riveting. Yawn at your peril, because it’s fundamentally important to online health, safety, and sanity. My guess is, most of you haven’t stayed on top of it.

Believe it or not, even tech industry pros don’t. We all should.

Here’s a cautionary tale: In December of 2018, cyber security expert Troy Hunt found 770 million email addresses and passwords posted to a known hacker website. Worse, many of those addresses and passwords had also been involved in a separate data breach. That means that people had been hacked, knew it, and still had not changed their passwords. Duh.

First, I can’t fault anyone for making this kind of mistake, because I have. Yes, embarrassing, but true. I have been a small-business owner in the tech sector, worked for two of the largest communications companies, and currently work for a leading IT and cyber security firm. I should know better than to neglect password management, but I have.

But lucky for us, for every problem there is a solution. Well, at least this one.

Problem – Repeat passwords
We need passwords for everything, for banking, social media, medical records, to sign into devices. The more complicated they are, the harder it is to remember more than one, so some people default to using a repeat password across accounts, which is one of the worst possible mistakes to make. It’s too predictable.

There is a routine practice called “credential stuffing” where email addresses and known passwords are plugged in all over the place to see where they gain access. Our email addresses are widely known, of course, so that’s already half the equation solved. One repeated password, and you’ve just handed over the rest.

Solution – Different passwords, changed often
Simple enough. Never use the same password for more than one service, and change your passwords often. I advise setting a schedule for password changes the same way you remind yourself to change the batteries in your smoke detectors at the change of the seasons.

Problem – 17jK_7f#3b@92-!!!!
It is recommended that passwords be at least eight characters long, longer if possible. You will need to use capital letters, numbers and symbols. But each service has its own set of rules as to which characters are acceptable. This can make you want to pull out your hair.

Solution – Make sense of it
Stay away from commonplace words, because those are just too easy to figure out. So, use the numbers/symbols in place of letter. Turn the nonsense into something that makes sense. I recommend writing out a sentence and then breaking it. Come up with a phrase, say, “I like pasta.” Next, make replacements, and you get: !L1k3P@$t@. The longer and more abstract the phrase, the better.

Problem – Too many passwords
Longer, abstract passwords, changing often creates a strain on memory, and keeping paper lists isn’t a good idea.

Solution – Password managers
Store your newly created passwords in a password manager, organized and readily available. If you’re like me, your phone is never out of reach, so I recommend using an app. There are many low-cost and free options in the market. (I recommend: Sophos Mobile Security, Keeper, 1Password.) Managers give you the ability to store many passwords, and some will even prompt you to change them every 30, 60 or 90 days.

Problem – You’ve been breached
There’s little worse than getting an alert from your bank about a suspicious transaction or hearing national news about a system-wide breach. If it hasn’t happened to you yet, chances are it will.

Solution – Report it, change your security factors

If you think one or more of your accounts has been subject to a breach, I recommend immediately making the password changes above.

Next, notify the Oregon Department of Justice Consumer Protection division (www.justice.oregon.gov) and make a formal report. You can also see if your account is listed in a past or recent breach by checking the Troy Hunt online resources at www.haveibeenpwned.com.

I look forward to continuing the conversation, but for now, be careful what you click on!

Jared Swezey is Chief Technology Officer at UpTime Sciences, and advocate for technology education. He lives in Eugene.

This article first appeared in the July 2 2019 Blue Chip section of the Register Guard.

Security Tidbits: Domain 2 – Asset Security Close to Home

O  ButI used to listen to the Prairie Home Companion radio show on Saturday mornings, while tinkering in the garage.  There was always the part of the show that started, “It’s been a quiet week at Lake Woebegon…” and then the stories of the inhabitants would follow, usually funny, often poignant, never truly sad.  Not like in our little security world, where the stories are usually sad, often aggravating, and almost never funny.  But sometimes it *is* unnervingly quiet.  With that in mind I have decided to give our little bit of the security universe a fictitious name just so that I can start off a Security Tidbits with the phrase, “It’s been a quiet week at ‘Make Foebegone’…”.  And so now I have, and yes I know it hurts a little to read it.

It’s been a quiet week at Make Foebegone, except for those responsible in Domain 2 of the Certified Information Systems Security Professional (CISSP) security domains.  Networks were created and secured, e-mail systems were migrated upward to cloudy providers and QuickBooks was fixed once again in the ritual dance of ‘why-did-they-do this?’ and ‘ok-try-it-now’.  But in one little cubicle, right here in our organization, sensitive data was leaked and, most embarrassingly, leaked by me.  The leaked data didn’t go far and was caught before it fell into the hands of Bad Actors, but leaked it was, right in the middle of my studying Domain 2.  I expect to be teased about this for a while and classified in many embarrassing ways.  You’ll get that joke in a minute, right after I tell you more about Domain 2: Asset Security.

Domain 2:  Asset Security

An asset can be anything critical to the operation of an organization.  Assets can be physical objects such as servers, switches, firewalls, etc.  They can be mobile devices, like your phones and tablets, or stationary objects, like your boss right after lunch.  An asset can also be digital such as software, or electronic data, which is where Domain 2 of the CISSP model concerns itself.  The CISSP breaks down the security landscape/ecosphere into eight ‘domains’ and as I study for my CISSP certification I think of all things computerish in terms of these eight areas:

  • Domain 1: Security and Risk Management
  • Domain 2: Asset Security
  • Domain 3: Security Architecture and Engineering
  • Domain 4: Communications and Network Security
  • Domain 5: Identity and Access Management
  • Domain 6: Security Assessment and Testing
  • Domain 7: Security Operations
  • Domain 8: Software Development Security

There is much written about Asset Security, because assets are the things of value that we rely upon to make our businesses work.  Because they are so important, there are quite a few competing standards and control frameworks for how to manage asset security such as PCI-DSS, OCTAVE, ISO27001-2, COBIT, NIST, and others.  All of these frameworks start with classifying software and data assets based on how important they are to the organization.  This is vital because securing data takes time and effort, and while it makes sense to encrypt and restrict access to highly sensitive payroll data on a server, you might get an earful for applying the same level of expensive security to the downloaded Ren and Stimpy videos on an engineer’s workstation.

To help folks decide what assets get the most effort, asset control frameworks specify using a data classification structure.  The framework descriptions tell you this is important, but they can be a bit vague on specific guidelines.  They basically kick the can to you, stating that it’s best you make up your own classifications based on your own criteria.  While that kind of makes sense, it’s also not at all helpful.  Where do you start?  Sometimes it  doesn’t really click in your head until you see an example.  Here is a familiar one taken from ‘Executive Order 12356 – National Security Information’ and used by our own Homeland Security:

  • Top Secret – Applied to information, the unauthorized disclosure could be expected to cause exceptionally grave damage to national security
  • Secret – Applied to information, the unauthorized disclosure could be expected to cause serious damage to national security
  • Confidential – Applied to information, the unauthorized disclosure could be expected to cause damage to national security
  • Unclassified – Data not sensitive
  • SBU – Sensitive But Unclassified – Data that is not a matter of national security such as health records of enlisted personnel
  • FOUO – For Official Use Only

The idea is to look at characteristics of your data and come up with some sort of pain factor, how much it will hurt the organization, based on these characteristics if something happens to that information.  You gather these characteristics by simply asking questions about your data:

  • Does it have value?
  • Does it fall into a specific category?  How important is that category?
  • Is there an identified owner? (and how important is *that* person?)
  • Is it useful?
  • What will it cost to re-acquire or re-create?
  • Are there repercussions for not being able to produce it on request?  Compliance issues?
  • Is there a risk of losing it?  How big is that risk?
  • What if somebody tampers with it?
  • What happens if is not accurate?

How Much Pain Would You Like?

These are examples and you will want to roll your own, but you start to get the idea.  You may even want to start with what do you *have* to do to meet compliance standards.  Once you have answers to these questions, you weight your classifications to come up with a degree of importance.  There are many different ways to value data and you can find some of them here, here and here.  Valuing data can be its own discipline, however, and it really boils down to, “How much of a pain will it be if something happens to *this* piece of data?”

Once you classify your data, you write up rules and processes for how it is to be handled and secured based on those classifications, then you implement those rules and processes using tools adequate for the job.  I used to do it the other way around.  I would focus on the strength and capabilities of the security tools in use and design processes and policies around what the tool could do.  Now, I believe that the slick expensive tool that can be used to secure lots of things is less important than designing proper policies about how data should be handled.  If an old, simple, yet harder to manage tool is the better way to implement a policy than to use the slick tool, then I stick to the policy and implement using the harder tool.  And then I get quietly cursed by the operations folks for making things too hard.  Security <> Popularity.

 Oh.  So *That’s* How It Works

Of course, to do this well you have to understand how your tools secure your data, be the tool be of the slick or the simple variety.  My little faux pas here at Make Foebegone happened because I did not understand how an unsophisticated tool works; my screen saver .

Figure 1 – Corporatey Screen Saver

I had taken a picture of some settings on a client device and downloaded it from my camera to a temporary folder on my workstation called ‘Pics’ as an interim step before putting it in secure storage.  The picture included some credential info for the device.  We make it a rule to secure our workstations from access and prying eyes when we leave them unattended, even for a minute.  On top of that, we have a Group Policy Object (GPO) that locks the workstation and kicks off the screen saver if idle for more than a few minutes, even if we are sitting right in front of it.  We have a good password policy, we control traffic through the work area, and we have visible cameras and warning signs to dissuade interlopers, so there is a reasonable level of security for any client information that we might have on any machine.  I left the picture in the temp folder on my workstation because I felt that my workstation was reasonably secure given the importance of the asset.

While the GPO specifies to use the screen saver to lock our workstations, we all have the latitude to choose what gets displayed.  When I set my screen saver up I told it to use images from the Pictures folder, the default, and then used File Explorer to empty the Pictures folder except for one corporate image with our logo in it.  But when is the ‘Pictures’ folder not the ‘Pictures’ folder?  When it is a Library called ‘Pictures’.

I had chosen to use the default Windows 10 setting using the ‘Pictures’ folder thinking it was just the one folder, but nooooooo.  Windows 10 chose the Library called Pictures which also “contained” a Quick Access link to the ‘Pics’ folder where I had my client screenshot.  This is one of those instances where Windows tries to help you across the street, but ends up breaking your ankle.

So, when my screen saver kicked in it showed my one chosen photo and then cycled through all of the “sub-folders” in the Library for other images.  I walked into work this morning only to be told, first thing, that I was a leaker.  Mr. Leaky L. Leakovitch.  Leakerific Leaker Extraordinaire.  My screen saver had been flashing my client credentials on a continual loop to any passing visitor.  Granted I did not create my temporary folder until after setting up the screen saver, and there were other images in the folder ‘Pics’ so it’s not like the image was continually visible, but it got noticed and now I have to hang my head in shame for a while.

My Asset Security procedures failed because I did not fully understand how the security tools that we employed actually worked, and I did not clean up after working with my image.  Also, our policy for handling downloaded client data was not strict enough.  After moving the sensitive image to our centralized secure storage I should have deleted it from my workstation.  If we had a stricter policy I could have avoided my security tool (screen saver) quirkiness and my tool-knowledge gap.

I knew the data was sensitive and thought we had adequate tools in place to secure it, and they do when used properly, so this brings up a few general things to think about:

  1. Really take a look at your policies and revise/create them to cover data in-motion, in-use and at-rest.  *Then* consider what your tools can do and either change how your tools operate in order to meet the policy, or use a tool that does.
  2. All Asset Security tools should be tested against the policies, not against what they are supposed to be able to do.
  3. Security should be continually reviewed, and not just by the same people.  It helps to have someone review your work (or simply walk by your desk).
  4. Shortening ‘in-motion’ time (the time it takes to transfer data from place to place) is important, and copies of data are just as important as the originals.  Secure those copies to the same level as the original data is secured, no matter where or when it is.

FYI  – Some well-known and used Standards and Control Frameworks for Asset Security that you might recognize:

  • PCI-DSS – Payment Card Industry Data Security Standards
  • OCTAVE – Operationally Critical Threat, Asset and Vulnerability Evaluation
  • ISO 17799 and the ISO 27000 Series
  • COBIT – COntrol OBjectives for Information and related Technology
  • NIST – National Institute of Standards and Technology
  • ITIL – Information Technology Infrastructure Library

 

 

 

 

Security Tidbits: Securing the IoT with Azure Sphere

Dear Securitarians,

This has been a difficult time for Domain 2 of the Certified Information Systems Security Professional (CISSP) security domains, Asset Security.  First it was Dasan GPON fiber modems being pwned and pwned again by rival botnets.  Then the VPNFilter botnet had its’ way with popular consumer-grade routers and even though authorities managed to foil that particular group, things got so bad that the FBI turned into a paraphrase of “The IT Crowd” asking, “Have you tried turning the Internet off and on again?”.

In the past, I kvetched about IoT security being the bane of our future, but Bad Actors seem to have plenty of low hanging fruit in the things-we-thought-had-some-security-already department to bother with sensors, valves and lightbulbs.  Why get complicated with breaking IoT to your botnet when there is so much more processing power in consumer-grade world?  Despite that, I am still looking forward with trepidation to the day when the hacking of the IoT really takes off and so I’m looking for ways to make things not-so-bad.

Domain 2: Asset Security and Domain 8: Software and Development Security

Sometimes new developments address multiple security domains.  Microsoft’s new Azure Sphere does just that.  Azure Sphere is a three part initiative from Microsoft aimed at doing to the IoT market what Windows did for the desktop; become the de facto platform.  Azure Sphere combines a new class of microcontroller, a new OS, and new cloud services; all three parts touting security as their centerpiece.

Competition has already been heating up the IoT security space with Amazon launching their IoT operating system a:FreeRTOS last year.  Amazon’s goal is to tie an IoT OS to all of the cloud innovations that they already own, making IoT management possible on an enterprise scale. Amazon has half a dozen hardware manufacturers committed to supporting a:FreeRTOS and the fact that FreeRTOS, the OS used for Amazon’s branded version, is an open-source heavyweight in embedded operating systems makes this a strong offering, from a marketing perspective.

Google has not been idle either, developing the Google Cloud IoT and pushing the Android Things platform, starting far back in 2016, as the chosen OS for IoT devices.  Adding to Google’s software offerings, hardware vendors NXP, Qualcomm and MediaTek have their own System on Module (SoM) architecture solutions in production to work with Google’s Smart IoT vision.  Google seems to cover all three areas of IoT for hardware, cloud management and OS.  Android is a universal front end from which developers can work and is currently the world’s largest app platform.  Coupling the Android platform with an earlier start in the field and Google’s advantage in the IoT world is enormous.

‘Smart’ devices, with their wealth of applications running on Operating Systems like iOS, Android and various forms of Linux, are what consumers think of when we talk about IoT.  Yet, the IoT ecosphere is immense and is exploding ever faster and farther every year.  In addition to ‘smart’ things, the IoT also encompasses things that are so very small and basic that they have been simply dubbed ‘connected’.  These are the devices that bring the installed IoT numbers into the billions.  It is the connected devices that are piling up the yearly IoT increase into the ten digit range and have been thrown into the field with only a nod to security.  It is down here, at the not-quite-smart end, that Microsoft has decided to setup base camp with Azure Sphere, starting at the very foundation of small computing and building in security from the dirt up.

The Guiding Principles

Azure Sphere starts with a set of core principles that Microsoft refers to as the Seven Properties of Highly Secure Devices.

Property Description Implemented In
Hardware-based Root of Trust Unforgeable cryptographic keys generated and protected by hardware. Physical countermeasures resist side-channel attacks.  The device has a unique, unforgeable identity that is inseparable from the hardware. Azure Sphere Certified MCUs
Small Trusted Computing Base Private keys stored in a hardware-protected vault, inaccessible to software. Division of software into self-protecting layers.  Most of the software used on the device is outside the trusted computing base. Azure Sphere Certified MCUs
Defense in Depth Multiple mitigations applied against each threat. Countermeasures mitigate the consequences of a successful attack on any one vector.  The device is still protected if the security of one layer of device software is breached. Azure Sphere OS
Compartmentalization Hardware-enforced barriers between software components prevent a breach in one from propagating to others.  A failure in one device component does not require a reboot of the entire device to return to operation. Azure Sphere OS
Certificate-based Authentication Signed certificate, proven by unforgeable cryptographic key, proves the device identity and authenticity.  The device uses certificates instead of passwords for authentication. Azure Sphere Security Service
Renewable Security Renewal brings the device forward to a secure state and revokes compromised assets for known vulnerabilities or security breaches.  The device software is updated automatically. Azure Sphere Security Service
Failure Reporting A software failure, such as a buffer overrun induced by an attacker probing security, is reported to cloud-based failure analysis system.  The device reports failures to its manufacturer. Azure Sphere Security Service

These seven principles provide a template that hardware and software manufacturers are using to create devices that are difficult to attack, or disable.  The principles are implemented in three parts; Azure Sphere Certified Microcontrollers; Azure Sphere OS; and the Azure Sphere Security Service.  Each part addresses multiple layers of security and forms an ecosystem that starts at the hardware level and goes up to the cloud.  Here is a bit about each one.

Azure Sphere Certified MCUs

At the hardware level is the microcontroller, or MCU.  These MCUs are very much like the processor you find in many smart devices, like your phone, but more compact and with some additional differences.  Each MCU has I/O circuits, a Cortex-M core for real-time processing, a Cortex-A processor for running applications, and has connectivity built into the chip itself.  MCUs have been around for a few years with each generation being smaller.  The first wave of Azure Sphere approved MCU chips rides the next wave of smallness and will have WiFi as the built-in connectivity.  Later MCUs will have Ethernet, or both Ethernet and WiFi built-in.

So far this sounds like any other system on a module compressed into one chip, impressive but evolutionary not revolutionary.  Microsoft then adds in the security magic.  Each MCU incorporates an IP block, a silicon library given by Microsoft to the chip manufacturer that is built into the chip.  This is what makes each MCU a unique device, similar to the MAC address on an Ethernet controller, but unspoofable (so they say).  Adding some form of unique asset identity at the hardware layer sets the security foundation for everything that is piled on top of it.

Adding to security, the MCU also has a set of firewalls, built into the chip using Microsoft’s Pluton security subsystem, so breaking into one area of the chip means you can go no further.  Here’s a blurry screenshot from Azure Sphere: Build 2018 that is somewhat helpful:

The IP Block, Pluton security subsystem and security architecture are licensed by Microsoft to the manufacturer royalty free in order to induce adoption.

The first Azure Sphere chip, the MediaTek MT3620, will come to market in volume this year.  Followed by others, such as (as of 2018-06-01):

  • ARM
  • Hilscher
  • LitePoint
  • LongSys
  • MediaTek
  • Nordic
  • Nuvoton
  • NXP
  • Qualcomm
  • Seeed Studio
  • Silicon Labs
  • STMicroelectronics
  • Toshiba
  • VeriSilicon

Azure Sphere OS

This is where Microsoft will start to make its money.  There are four software layers, on top of the hardware; the Security Monitor, the HLOS Kernel, the On-Chip Cloud Services and then come the application containers, one for each application.

  • Security Monitor – like a hypervisor, monitors security
  • HLOS Kernel – a custom Linux kernel, yep Linux.  Manufacturers can submit changes for addition to kernel so in that respect it is ‘open’.
  • On-Chip Cloud Security Services – provides updates for OS and apps
  • Containers – a real-time I/O sandbox for the Cortex-M, and one sandbox for each application running in the Cortex-A processor

No word on the cost of the OS, but if we go by Microsoft’s current byzantine licensing models it will require an advanced degree to figure out.

Azure Sphere Security Service

There are no passwords on a Azure Sphere device. All communication, authentication and permissions is provided by security certificates.  This includes device-to-device and device-to-cloud communication.  The Security Service does the following:

  • Detects failures and reports them
  • Does behavior monitoring on the device for anomalous behaviors
  • Manages software updates to OS and apps

Managing security certificates looks to also be done through the Azure Sphere Security Service.  No details on that yet, but there will be a charge of some sort I am sure.  Visual Studio is what developers will use to create software that runs on Azure Sphere, leveraging a large pool of development software and skilled programmer folksies.

More Cloudy Microsoft Stuff

To pad it all out, Microsoft also has come out with a collection of cloud services that make managing bee-lee-ons of IoT devices a click-breeze;   Azure IoT Central for overall management of devices, Azure IoT Hub for connecting to and provisioning devices and Azure IoT Edge for analytics.  There are costs for all of these.

Some of the references used here:

The Wrap

Azure Sphere should be named Azure Ecosphere.  You go all in or you pick another playground.  From chip to OS to cloud, it is all Microsoft, there is little mix and match.  If this makes you nervous, by all means look at one of the other biggies, or puzzle together your own security whole cloth solution for IoT.  But remember that IP block?  The one buried in the chip itself?  That is the foundation for asset identity, upon which all else depends, and no one else is doing that yet for IoT devices.  Remember up at the top of this very long-winded post about the “Hardware-based Root of Trust”?  That’s what is required to build something more secure for IoT devices and that is where Azure Sphere shines.  We shall see how many are lured by the shininess.