In this example, we will assume that you are a coffee machine manufacturer. Your current project is to build a connected coffee machine for your corporate customers. You have identified multiple use cases for this IoT machine. For instance, it automatically orders new coffee capsules when the stock falls below a certain threshold. A second option would be that the coffee machine, sends automatic alerts to your servers when maintenance management such as cleaning, repairs, etc. is needed. Finally, it offers your clients functionalities for monitoring consumption.

How can you choose the right network for your needs? What questions should you ask yourself? How do you make a good choice while considering the overall security of your system?

First Step – Define your business requirements and perform a risk analysis

First, you must identify the requirements for your IoT network which are twofold: business and security requirements. We characterize these requirements with levels 0 to 3, 0 being the lowest and 3 being the highest level.

For the business requirements, you must answer questions such as:

1. How far should the object’s signal reach?
2. How much bandwidth do you need?
3. What is the autonomy of your object?

In our example, we assume that your connected coffee machines will be distributed to corporate customers operating over a large geographical area (i.e. over 100 km radius). Therefore, you will need a wide coverage to enable your customers’ widespread machines to communicate with your Information System.

Two business cases are outlined here: If your customer agrees to connect your machine to its existing local network, you will then only need a short-range wireless network between the machine and the internet router. If they refuse to do so, you will then need to set up a long-range network as you will deploy your service and machines over a wide area.

For the bandwidth, a small/short amount will be needed as it solely requires to be able to send small data packages a few times a day at most (capsule orders, alerts, general status, …).

In regard to energy consumption, a coffee machine is traditionally connected to a power supply to perform its tasks; henceforth, power does not constitute an issue in terms of IOT, i.e. the object autonomy is therefore not constraint. There is no energy consumption requirement per se as it is already covered by the coffee machine’s connection to the power grid.

We summarize the levels for business requirements as follows:

• Range (R) = 3 or 1
• Bandwidth (B) = 1
• Energy consumption (E) = 0

Having defined your business requirements, a risk analysis must be conducted to formulate the security requirements of your project for availability, integrity, confidentiality, and traceability purposes.

A loss of availability would occur in the event of a dysfunction on the connected coffee machine that would render it unusable for a customer. A loss of access to the network or unavailability of backend servers should never result in the machine being unavailable: it must remain working off-network. However, if a dysfunction of the machine occurs, we assume that you would want it to be reported back as quickly as possible through the network in order for maintenance actions to be triggered.

How long can this last? The answer would be several hours rather than several days, as we wouldn’t want to deprive employees from their coffee breaks! Therefore, 4 to 24 hours is an acceptable window of unavailability which can be translated into an availability requirement level of 2.

A loss of integrity would result in data corruption. For example, a potential excess order of coffee capsules may occur by altering the messages sent by the coffee machine or by replacing the same order multiple times. In both cases, this would result in a financial loss for your client. Data on the network needs to be communicated rigorously and exactly. Hence, we can conclude this is a requirement level of 3.

A loss of confidentiality would result in data being divulged; orders quantities are rather sensitive data that shouldn’t be shared with external parties. It needs to be ensured that data is communicated securely on the network and is not accessible by externals parties.  Hence, we conclude that confidentiality has a requirement level of 2.

For traceability, and for simplification reasons, we choose to leave this aspect aside assuming that it is already accounted for by the study of the first 3 criteria.

In a nutshell, risk analysis concludes to the following security requirements:

• Availability (A) = 2
• Integrity (I) = 3
• Confidentiality (C) = 2

For more details about risk analysis methodology for smart objects, you can refer to this article.

At the end of this analysis, you obtain for both of your business cases a radar chart of your requirements.

Business case 1: your customer connects your coffee machine to its local network

Business case 2: your customer does not connect your coffee machine to its local network

Though not discussed in this article, financial aspects are also important and depend on various factors such as the network operator pricing model. Same goes for geographic constraints as some networks may not be available on some regions.

Eventually, the ease of configuration of the network may be included in your business requirements, especially if your connected object targets a B2C audience.

Second step – Choose your IoT Network

Building on business and security requirements, we developed a methodology to choose the right network that will be optimal to meet your business and security needs: range, bandwidth, energy consumption, availability, integrity, confidentiality.

The three business requirements are mandatory, the network you choose must fulfil them, otherwise, it will be eliminated.

For security requirements, the assessment requires pre-emptive analysis. Between two networks that cover the same business requirements, you should choose the one that offers the best level of security with the minimum cost.

If a network doesn’t cover one of the security requirements, you will have to implement some additional security feature as a part of your project backlog, consequently raising your costs.

You should also be vigilant that the additional implementation doesn’t impact the system’s performance. For instance, if you implement data encryption at the application layer, increasing processing times would negatively impact your maximum data rate or could be constrained by the hardware capabilities of the device, with a potential financial impact in case of a hardware upgrade. Consequently, one of your business requirements may no longer be met.

In case high availability is required (A=3), you ought to choose a robust network by design that will meet your real-time needs.

In fact, spread spectrum (like Bluetooth or ZigBee) or frequency hopping modulated protocols (like Sigfox or Bluetooth) are more resistant to radio jamming or radio interferences.

These types of networks are particularly recommended when availability is an important requirement, such as on an industrial production line.

Moreover, mesh protocols are known to be more reliable and scalable than point to point protocols. However, for them to achieve efficiency, they need to be used in a context where multiple connected devices are linked together. Mesh protocols like WirelessHART can also guarantee real-time communications. Their usage is especially adapted to an industrial context.

A simple methodology to choose the right network is to confront your business requirements to the network’s business and security offerings.

In the following radar charts, we present different types of IoT networks providing different levels of business and security offerings, and we compare each one of them to our business requirements.

Business case 1: your customer connects your coffee machine to its local network

Business case 2: your customer does not connect your coffee machine to its local network

Let’s apply the previous methodology to your connected coffee machine. First, we use our previous radar charts to see which networks comply with our business requirements.

Business case 1: your customer connects your coffee machine to its local network

For your first business case, Bluetooth and Wi-Fi are two viable short-range options if your customer connects the machine to its local network. On the one hand, Bluetooth meets all the security requirements, but it is less straightforward to implement compared to Wi-Fi. On the other hand, Wi-Fi meets all of them except for availability but that is something we can work out with SLA agreements.

Business case 2: your customer does not connect your coffee machine to its local network

For your second business case, Zigbee, BLE and Wi-Fi are clearly out of the equation because they do not meet the range requirements. However, LoRa, LTE-M and Sigfox are still in the mix.

We use the radar charts again, this time to assess these three candidate’s compliance with the security requirements.

Sigfox does not meet one of your security requirements (confidentiality) whereas LoRa complies with all security requirements. LTE-M is the best offering as it meets all your requirements, but it is also the most expensive. We conclude that LoRa is a relatively good candidate.

In conclusion, we have one good candidate: LoRa which will require the deployment of a new network and an alternative using a pre-existing Wi-Fi network. It should be noted that you may refuse to connect to the Wi-Fi network on company premises for security reasons.

We will undertake a new scenario in a next article: a customer company buys the machine and discusses what payment options to use.

Cet article Connecting your connected coffee machine: yes, but how? est apparu en premier sur RiskInsight.

This reflection should cover the main risks of data leakage and access to data by administrators, Microsoft and third parties or applications.

A new governance model imposed by Microsoft

Office 365 is a SaaS communication and collaboration solution. As such, the platform is constantly evolving, unlike the historical “on-premise” solutions: new features or settings appear and are modified, while others disappear (e.g. retirement of Skype for Business planned for 2021, July 31^st and the end of legacy authentication support for Exchange Online planned for 2020). This continuous delivery pace is imposed by Microsoft, without control. Hence, a completely new governance model is required.

Changes integration can no longer be done in project mode. It must follow an established process. In this model, the workplace and security teams must work hand in hand and must be represented in all project and architecture committees, starting from the very beginning of the platform use cases design. These teams will also have a common responsibility to ensure the platform efficiency and regulatory compliance.

The security team sees its perimeter evolving: it no longer has control over security tools and can, or even must, play a business enabler role to support the migration to the cloud by proposing new uses (e.g. opening a controlled external file exchange service). An appropriate organization must be put in place. We could even consider having a Security Officer dedicated to the platform very close to the business, with the role of advising projects, ensuring the platform configuration and monitoring security alerts.

Another topic to be addressed is the delegated administration.  Even though it is not a rare situation, it is not possible to have nearly 20 General Administrators for an O365 tenant. Indeed, a Global Admin has control over Office 365 services, but also Intune, Azure, AAD, etc. A delegated administration solution must be considered for user accounts and objects, through the implementation of an interface or a connector based on PowerShell or Graph API. This process should allow the company to manage all objects while considering business logic. To define this new governance model, the following security pillars must be articulated:

• Identity management ;
• Mastery of services and uses ;
• Control of compliance to company policies.

Identity management at the core of the model

In a solution designed to enable internal or external collaboration, with an ATAWAD use (Any Time, Any Where, Any Device), identity management (and therefore authentication) is the core of platform management.  As with any project, the definition phase of who can access what, when and where is fundamental.

On Office 365, there are three types of users, each with different privilege levels: administrators, internal users and guests (external users invited to collaborate on a file or within an O365 Group or SharePoint site).

For each of these account types, implementing the defined security measures will be challenging. In addition to the unavoidable multi-factor authentication (highlighted by the data leak that affected Deloitte in 2017), there are also other essential issues, such as administrator access control (personalized or predefined roles, permanent or occasional access, etc.) and guest users lifecycle management (nothing being clearly defined by default). The cost of Azure AD Premium licenses or a third-party tool will be a major element of the discussion.

Also note that Office 365 allows external applications to communicate with its APIs. The external application can then act on behalf of a user with its own rights or of an administrator with higher privileges. These applications can come from different application stores (such as AppSource or AAD) or be developed locally. The management of permissions granted to these applications must be highly considered by companies. Indeed, through APIs, it is very easy to imagine a massive data leak in case of a user dupe (e.g. an application requiring unnecessary permissions, such as email access).

An essential but neglected control of services and uses

Once access to Office 365 is under control, the next topic is to manage its use. It is not uncommon to observe that some services, not prioritized during migration to the Cloud (Power BI, Teams, Flow, API access, etc.) are left accessible with their default configuration. The two reasons are generally a focus on adoption and a lack of time devoted to these non-priority services. In addition to setting up the service, it is also essential to define precise rules around uses to clarify who can do what and when (e.g. managing SharePoint authorizations, creating Groups). The best solution consists in implementing technical measures (general settings or configuration via PowerShell) congruent with the defined policy.

However, the lack of security of these services leaves the door open to potential data leaks: automatic transfer to the outside, exposure on the Internet or loss of the data control. As written above, governance must take security into account when designing future uses. Services must be analyzed and tested on small populations. Indeed, it will always be easier to open a feature than to restrict an already widespread use. In that case, it will be necessary to carry out an impact analysis, to tinker with a workaround solution and to raise users’ awareness widely. However, these actions may require significant investment and could be avoided.

The management of the service should not end with user adoption. Security and Workplace teams will be responsible for following Office 365 evolution (Evergreen program, setting up a watch, monitoring Microsoft blogs, etc.) in order to assess new opportunities and threats.

The control of the compliance with company policies

The implementation of the company security policies is the last pillar and includes the implementation of security tools: information protection, anti-malware, supervision and alerting.

Concerning Office 365 security, we can differentiate 3 levels of maturity. The resources put in place will depend on the expertise available (resources being limited on the market) and the budget (depending in particular on the strategy of the Microsoft licensing management company):

• Level 1 – Control of identities, services and use of the Security and Compliance Center: the company implements native Security Center and Compliance Center security solutions (including Office DLP, Exchange Online Protection, eDiscovery) accessible with basic licenses;
• Level 2 – Development of “in-house tools”: the company creates a set of simple scripts or dashboards, using Graph API, Security Graph API and PowerShell, to implement controls and security measures adapted to its context (e.g. life cycle management of guest users);
• Level 3 – Use of advanced security tools: the company implements additional solutions to strengthen the level of security: tools to fight data leaks, analyze malware on emails, review rights, detect abnormal behavior or even harden the use of the platform according to the context.

Mastering Office 365 services, their uses and native security features is essential, and must precede any consideration of adding an additional security tool, which would not cover existing vulnerabilities and would only add complexity.

Sample of controls included in the Wavestone Office 365 Audit Methodology

Conclusion

Office 365 is an interesting case of opening business applications on the Internet through the Cloud. This evolution requires adapting the company historical security model, towards the airport model following the Cloud adoption.

However, Office 365 security must not omit the security of the on-premise bricks necessary for the platform operation, as it is generally the case for the authentication that is carried out by ADFS.

Cet article A secure Office 365, a rare gem? est apparu en premier sur RiskInsight.

Big data : un intérêt qui ne faiblit pas

Depuis 2012, l’intérêt pour le Big data ne cesse de croître (cf. courbe google trends). Pourtant, faute de disposer d’une définition tangible, la pertinence des usages de cette expression reste, aujourd’hui encore, sujette à interprétation.

Prenons un échantillon de définitions produites par les voix les plus influentes du domaine IT (Gartner, Forrester, IBM etc.). Derrière le Big data, une multitude de sujets : il peut s’agir, selon les analystes,  1) des données  (d’un genre caractéristique), 2) d’un phénomène ou encore 3) d’un ensemble de techniques ou technologies. Il en ressort cependant un champ lexical qui fait assez largement consensus et s’est imposé sur la plupart des slidewares (avec aussi des contradicteurs).

« Petite » analyse lexicale du « Big » data

3 V. Volume, Variété, Vélocité. Vision du Gartner de 2001 : chacune de ces caractéristiques constituent un défi pour les entreprises qui souhaitent les exploiter ; leur combinaison accentue d’autant la difficulté que représente le traitement des données. Le Big data n’est pas que l’explosion des volumes. C’est aussi la richesse des formats et le temps réel. Ce qui pose question et qui est rarement explicité, c’est la mesure de chacune de ces trois dimensions. Le volume se mesure-t-il en téra- ou en pétabytes ? Où se situent les niveaux d’acceptabilité qui permettent de déterminer qu’une situation ou un cas d’usage relève du Big data ? Le Big data d’aujourd’hui sera-t-il celui de demain ? Car avec la croissance des données et les avancées technologiques, le curseur ne cessera sans doute pas de se déplacer…

4V = 3V+Valeur. Certains ont noté un glissement de l’acception Big data de 3 à 4 V : des caractéristiques de nature technique à celle de « valeur ». Que peut-on tirer des données ? C’est en fait la question essentielle : celle de « l’opportunité à saisir » ou du « besoin à combler ». Une autre question apparaît avec les fournisseurs de données : quel est le prix des données ?

Technologie accessible. Il n’y a pas de définition technologique du Big data au sens où aucune technologie n’est liée de manière exclusive et catégorique au concept. Tout comme les web services n’étaient pas la SOA, le Big data n’est pas Hadoop*, même si Hadoop est la valeur sure d’un marché en plein essor et encore peu lisible. Certes, l’envolée du Big data doit beaucoup à l’« accessibilité »  d’Hadoop et du noSQL. Mais le coût et le ROI de ces solutions sont-ils à la hauteur des promesses ?

Acquisition, visualisation etc. Le Big data n’est pas que stockage et analyse de données. Il faut  développer son gisement pour trouver la bonne information. L’information produite doit être comprise, retenue, travaillée et des techniques d’analyse visuelle sont aujourd’hui mises en avant.  Enfin, pour les questions de fiabilité et de sécurité, des évidences en gestion des données, des solutions se positionnent.

Décision. Le Big data bouscule le décisionnel. Les cas d’usage Big data sont quasiment exclusivement analytiques. Les technologies dont nous parlions ne sont d’ailleurs pas construites pour supporter des processus transactionnels qui restent en périphérie de la « révolution » à la source des données.

Un Big data à ma sauce

Le Big data est une véritable problématique, soit littéralement un faisceau de questions. Si l’exercice de définition va se poursuivre, il serait salvateur de l’évacuer rapidement. Mieux vaut se concentrer sur les défis techniques et organisationnels du traitement des données et la recherche de nouveaux leviers de performance.

Forrester propose pour ce faire une approche pragmatique « Calculer son « Big Data score », qui vise à s’auto-évaluer sur sa capacité à stocker, traiter, requêter ses données selon chacune des 3 dimensions. Big data ne veut pas dire la même chose pour Google et pour moi. Il faut revenir à des enjeux réalistes : ai-je exploré les opportunités d’utilisation des données « à ma disposition » ? Suis-je capable de « passer à l’échelle » efficacement (délai, coût) si une opportunité se présente ?
Et, à quelle échelle : *10, *100, *1000 ? Que font mes concurrents ?

Alors : in or out ?

*Hadoop comme nombre de bases de données noSQL est distribué en open source. Le déploiement d’Hadoop n’exige pas d’infrastructure réseau et/ou serveurs haut de gamme.

Cet article Big data : tour d’horizon 2013 ! est apparu en premier sur RiskInsight.