Mainframe computers play a central role in the daily operations of the world’s largest corporations. It dominates the landscape of large-scale business computing in banking, finance, health care, insurance, public utilities, government, and a multitude of other public and private enterprises.  The subject of this article will be how to improve its level of cyber security in order to best meet the requirements of the LPM.

Factors contributing to mainframe use 

The reasons for mainframe use are many but most of them lay beyond one of the following categories. 

• RAS (Reliability, availability, and serviceability): Mainframe design places a high priority on the system always remaining in service. The system has error prevention and detection features, it can recover from a failed component without impacting the rest of the running system and determine why a failure occurred. 
• Security: The mainframe provides secure system for processing large numbers of heterogenous applications that can access critical data and offers an unmatched protection for workload isolation, storage protection, and secured communications. 
• Scalability: Mainframe can run multiple copies of the operating system software as a single entity. 
• Continuing compatibility: Mainframe hosts old applications that evolved or not over the years and more recent applications development. The mainframe provides absolute compatibility across decades of changes and enhancement. When an incompatibility is unavoidable, the designers typically warn users at least a year in advance that software changes might be needed. 
• Evolving architecture: Mainframe has been the leading technology in data and transaction serving for over four decades. Strong combination of past mainframe characteristics and next functionalities designed around the RAS are provided by each new generation. 
• Extensibility: Mainframe component and infrastructure reuse is characteristic of its design (a share-everything architecture). 
• Lower total cost of ownership (TCO). 
• Environmental friendliness: Fewer physical servers running at a near constant energy level can host multiple virtual software servers. This setup allows a company to optimize the utilization of hardware and consolidate physical server infrastructure by hosting servers on a small number of powerful servers. 

Hardware Systems and high availability 

 To introduce mainframe hardware, we will take as example the Z16 generation mainframe systems offer: 

• A high computing capacity (up to 200 processors) ensuring swift processing of tasks and handling of complex computations.  
• A big capacity memory (up to 40 TB) enabling storage and retrieval of vast amounts of data rapidly. 
• A memory cache optimizing performance.
• Data compression capability facilitating efficient storage and transmission of data by reducing its size. 
• Encryption functionalities to secure transactions providing robust security measures to safeguard sensitive information during transactions. 

Despite the continual changes, mainframe computers remain the most stable, secure, and compatible of all computing platforms. From the client-server model of computing in the early 90s to the significant increase of scalability and performance and capacity today the mainframe computers evolved to meet new challenges. 

Growth of the mainframe and its components

Z/16 generation mainframe are multiprocessor servers. Each processor has a small private area of memory that is unique to that processor called Prefix Storage Area (PSA) the processor can access other processor’s PSA through special programming, although this is normally done only for error recovery purposes. 

The mainframe disk drives are accessible through an associated Control Unit that has up to four fiber channel connections to one or more processors (through switch). 

System control and partitioning 

There are many ways to illustrate a mainframe internal structure. The figure bellow illustrates several internal functions of the mainframes. The internal controllers are microprocessors they are usually known as controllers to avoid confusion with mainframe processors. 

System control and partitioning

The mainframe can be partitioned into separated Logical PARtitions (LPARs) where system resources (memory, processors, and I/O devices) can be divided or shared among them under the control of LPAR hypervisor (type 1 hypervisor / native) which comes with the standard Processor Resource/ Systems Manager (PR/SM) feature on all mainframes. Each LPAR support independent operating system (OS) loaded by a separate initial program load (IPL) operation and has its own copy (most of the z/OS system libraries can be shared). 

Today’s machines can be configured with up to 60 LPAR, each one is considered as a distinct server with different OS environments. The system administrator can assign one or more system processors to the exclusive use of an LPAR through system control functions (firmware). 

Logical partition

Clustering 

Most z/OS installations nowadays use one or more of the following clustering technics: 

• Basic Shared DASD (Direct Access Storage Devices): 

A basic shared DASD system is typically used where the operations staff controls which jobs go to which system and ensures that there is no conflict, such as both systems trying to update the same data at the same time. Despite this limitation, a basic shared DASD environment is useful for testing, recovery, and careful load balancing. 

Basic shared DASD 

• CTC rings: 

CTC rings (Chanel To Chanel) function simulate an input/output device that can be used by one System Control Program (SCP) to communicate with another SCP. It provides the data path and synchronization for data transfer. 

z/OS can use the CTC ring to pass control information among all systems in the ring. This information can include usage and locking information for data sets on disks, job queue information, security controls and disk metadata controls. 

Basic sysplex 

The ring aspect is more obvious when more than two systems are involved. 

• Parallel Sysplex: 

A sysplex system is one or more (up to 32 LPARS) z/OS images joined into a cooperative single unit using specialized hardware and software. It uses unique messaging services and can share special file structures contained within couple facility (CF) data sets. 

The Coupling facility (CF) is a logical partition that provides high speed caching, list processing and locking functions for sysplex. It contains one or more mainframe processors and a built-in operating system. 

A Parallel Sysplex is a symmetric sysplex using multisystem data-sharing technology. This is the mainframe’s clustering technology. It allows direct, concurrent read/write access to shared data from all processing servers in the configuration without impacting performance or data integrity. Each LPAR can concurrently cache shared data in the CF processor memory through hardware-assisted, cluster-wide serialization and coherency controls. 

This technic allows requests that are associated with a single workload to: 

• Dynamically be balanced across systems with high performance. 

• Improve availability. 

• Provide a rolling maintenance for systems and applications. 

• Offer a scalable workload. 

• View multiple-system environments as a single logical route. 

• Synchronizing the TOD clocks (Time Of Day clock service) on multiple servers which allows events occurring on different servers to be properly sequenced in time. 

Parallel Sysplex 

Mainframe security 

Mainframe Z system security systems (access control, authentication, access control lists…) are centralized inside one unique service called SAF (System authorization Facility). 

SAF doesn’t require any other security product, but it is generally completed with other security product called ESM (External Security Manager) like TSS and RACF. 

• RACF: 

RACF (Resource Access Facility) is part of a global IBM offer named z/Os Security Server that includes an LDAP server, a z/Os Firewall technology, an Enterprise Identity Mapping component, RACF, … 

RACF provides Discretionary Access Control (DAC) and Role Based Access Control (RBAC) functionality. 

• TSS: 

The mainframe z/OS SAF (System Authorization Facility) can be used to delegate all security tasks to Broadcom TSS (Top Secret Services).  

TSS is an External Security Manager (ESM) developed by Broadcom and it is responsible of managing identification, authentication, and access control for z/OS resources like datasets, TCP/IP stacks, and programs. Each process has an owner (UserID) who starts with no permissions by default, and a TSS security officer must grant access to resources. Application isolation is achieved by carefully managing the permissions given to different resources. Additionally, firewall filtering can be applied to both incoming and outgoing traffic of the mainframe. 

Mainframe compliance with the LPM 

What is the LPM? 

The LPM is a strategic French defence plan whose objective is to ensure the security of operators of vital importance, companies, or organizations, for whom the interruption of one or their vital mission(s) would have an impact on the security of the nation.​ 

It concerns the protection of Information Systems of Vital Importance (SIIV), on which these vitally important missions are based, and Points of Vital Importance (PIV), places hosting sensitive IS. 

It is relatively close to the NIS (Network and Information Security) directive about the security requirements to be applied to its SIIV but integrates new notions and obligations which make it more restrictive. 

Why is the mainframe subject to the LPM? 

Mainframe z/OS (MFRz) is in the heart of the banking activity due to several reasons: 

• Its capability of managing big transaction and compute volumes. 

• It offers a modularity inside a centralized system. 

• Scalability and openness of the system. 

• Interesting costs. 

How can we perform segmentation in the mainframe? 

To ensure isolation of assets inside the mainframe we can identify three possible scenarios (complete isolation, dedicated LPAR and network isolation).  

The following scenarios however does not provide microsegmentation between assets in the same VLAN or sharing the same TCP/IP stack. 

Complete isolation 

A dedicated mainframe instance is dedicated for the SIIV assets. All communications with external asset are filtered through the mainframe firewall. However, this solution has a high material cost with a big operational risk. SIIV asset should be all migrated to this new mainframe instance and the building of this new environment require human resources. 

Complete isolation example 

Dedicated LPAR 

In this isolation scenario an LPAR is dedicated for the SIIV assets. As discussed in the “System control and partitioning” chapter mainframe can be partitioned into separated logical partitions (LPARs) where system resources and each LPAR support independent operating system (OS). 

Isolating all the SIIVs in one LPAR is not feasible because each asset runs on a different OS (Linux, z/OS…). 

LPAR isolation examples 

A dedicated LPAR per SIIV OS can be set to remediate to that. This solution has however some weakness: 

• The SIIV assets share the same physical server with non SIIV assets. 

• Adding resources allocated to these new LPARs will induce an increase of the cost.  

Network isolation 

Assets can be logically partitioned through PR/SM (IBM processor resource / system manager). Using this feature mainframe urbanization can be designed to optimize the use of resources, by dedicating partitions by environment or by type of service. Each partition has its own TCP/IP stack and one or more OSA cards (network cards that can be shared between partitions).  

Mainframes can be connected to different networks, that are accessible through these various TCP/IP stacks. Multiple stacks can run on one mainframe instance allowing one z/OS partition to communicate to multiple networks at the same time and each stack is not necessarily active on each z/OS partition.  

Network isolation example 

• Two assets sharing the same TCP/IP stack can directly communicate with each other without the mainframe firewall filtering (example: communication between “SIIV asset 1” and “SIIV asset 2”). 
• Two assets hosted in different LPAR but sharing the same VLAN can directly communicate with each other without the mainframe firewall filtering (example: communication between “SIIV asset 1” and “SIIV asset 3”). 
• Two assets hosted in different LPAR and different VLAN have their communication filtered by the mainframe firewall (example: communication between “SIIV asset 1” and “Other asset 4”). 
• Any communication with assets outside of the mainframe is filtered by the mainframe firewall. 

This network isolation scenario allows isolation of SIIV from non-SIIV resources inside the mainframe, the optimization of the mainframe is preserved and there is a low operational risk as we don’t move the SIIV resources outside the mainframe. 

Summary of solutions 

Do the segmentation scenarios respond to the architecture security filtering criteria of the LPM? 

The Complete isolation scenario responds fully to the LPM Partitioning and filtering requirement as the mainframe will be dedicated to the SIIVs and the incoming and outcoming flows will be filtered by the mainframe firewall. However as stated above this solution has several disadvantages mostly related to the cost and operational risk of moving all the SIIVs to another physical machines.  

The Dedicated LPAR provides a logical isolation layer. The SIIVs are hosted in dedicated LPARs each one with its dedicated resources inside the mainframe. However this solution can lead to performance issues and high material cost. 

The network isolation scenario provides an extra layer of network isolation relying on TCP/IP stacks however non-SIIV application hosted in the same network as SIIV applications can still directly access it without filtering to remediate that the following conditions must be met: 

• Dedicated SIIV zones must be set in the IS where group application will be hosted. 

• Dedicated TCP/IP stacks must be set in the mainframe to which the SIIVs will be connected. 

In this scenario non-group critical resources communications with SIIVs will be forced to go through the firewall filtering. 

Administration of the mainframe 

 HMC 

IBM z systems hardware monitoring and control services are performed through a dedicated console (HMC: Hardware Management Console) located in operator area and a Support Element console (SE) located inside a CEC (central electronic complex – mainframe “box”) that can only be used by operators. The HMC is a physical computer located in an operator area and is dedicated to the management of the hardware and software of the mainframe. The HMC can’t be used for another purpose. IBM can perform support actions through distant connections RSF (Remote Support Facility) for reporting and patching hardware issues. Access to the OS and application layers can’t be performed through these consoles.  

•  To ensure compliance with the LPM, the HMC access must be protected by a firewall and restricted to a Bastion. 

Administration applications 

IBM z systems embed several applications use to administrate the mainframe, such as TSO (Time Sharing Option), ISPF (Interface System Productivity Facility). These command-line interfaces allow users to run commands, submit batch jobs, manage rights and perform various administrative tasks. Access to those applications is managed through RACF (Resource Access Control Facility) which authenticate users and control the permissions based on assigned roles and access rights. 

To restrict the access to these administrative applications, the following measures must be deployed: 

• Two network interfaces must be configured: one dedicated to mainframe administration, and one dedicated to business.  
• RACF protection must be enabled on those interfaces to restrict the access based on the accounts. To do so, RACF should be configured to check the Terminal class4 and grant access based on its content: 

• • Administrators accounts can only access the administration interface 

• • Business users accounts can only access the business interface 

To ensure compliance with the LPM, the administration interface access must be protected by a firewall and restricted to a Bastion. 

Mainframe segmentation remains a critical component for organizations managing SIIVs. As we have explored, mainframe architecture provides a robust foundation for implementing effective segmentation strategies. 

The isolation solutions we have discussed each offers unique advantages and challenges. Complete isolation using dedicated mainframes is fully compliant with the LPM but at a higher cost, higher operational risk with reduced flexibility. LPAR isolation have a high operational cost and breaks the optimization of the MFRz. Network isolation using TSS or RACF to dedicate TCP/IP stacks offer a more cost-effective, flexible solution with less operational risks but this solution is partially compliant with the LPM as the mainframe is not physically dedicated to the SIIVs. In addition to that the mainframe provides the necessary tools to secure its administration interfaces and to segregate it from the production. 

Choosing between these solutions requires careful consideration of an organization specific needs, security requirements and resource constraint. It is crucial to remember that there is no one-size-fits-all solution. The optimal approach will vary depending on the nature of the SIIV and the organization overall IT infrastructure. 

Cet article Segmentation in mainframe z/OS and LPM est apparu en premier sur RiskInsight.

Historically, the Agile approach is a set of practices used for IT development projects. 

The Manifesto published in 2001 proposes 4 main values to revolutionise the performance of companies:

This emphasis on human interaction between the development team and business teams aims at reducing the time to market of the products developed, as opposed to projects conducted in V-model which, once delivered, may no longer satisfy changing business requirements.

Today, this practice is applied in most companies at all levels. In the latest State of Agile Report, out of more than 4,000 companies surveyed worldwide, 95% declared that they use agile and 65% of them have been practising it for at least 3 years.  In addition to IT, the methodology is also used in marketing, human resources, sales, and finance departments. 52% of the companies surveyed stated that at least half of their company’s departments adopt agile processes and therefore the scalability of such practices should not be ignored.

Beyond a project management method, it is a new philosophy with gamified elements. We no longer speak of meetings but of ceremonies, with new roles appearing such as product owner and scrum master. Using this philosophy, the desire is to create an atmosphere of co-construction and to make maximum use of collective intelligence to improve the company’s performance.

Although the concept of security is present in the manifesto, the integration of such measures into product development is not properly addressed. The method by which security is implemented in V-model projects does not apply to the agile philosophy and thus new ways of implementing security should be identified for it.

What are the trends and challenges of this field?

One of our challenges is to provide our clients with a global view of their problems. Adopting an agile approach requires a change in all levels of the business from security, to quality teams and as such the effect on all levels of the business must be considered.

In terms of organisation, the ISS must reposition itself as a service to the business and thus shift its image from a ‘policeman’ to a support function. The role of Security Champion (a member of the feature team such as a developer) becomes the point of contact for the ISS teams. In doing this a connection can be created with each feature team, thus increasing autonomy over security integration. This is not something that can be achieved overnight, it requires training to highlight cybersecurity issues and share knowledge (particularly the basics of ISS and secure development). In addition to this, a security Guild should be created, bringing together ISS experts, security champions as well as security enthusiasts. This allows members to exchange information on the latest security news, good practices as feedback and lessons learned from the field. This Guild must be set-up in such a way to allow easy communication between members (such as on an internal wiki).

After the security champion receives training from the ISS team, they become the security referent and thus developers can turn to them for questions and advice. Therefore, the role in itself is fairly technical. In adopting an agile approach, the ISS experts will keep their role, but the relationship will change from that of control and audit to support and facilitative. Audits can still be carried out (such as penetration tests) at the request of the feature team or on the initiative of the security experts. Methodological tools must also be available to help the Champions in their tasks and this includes rewriting risks in conversational format. To adapt to the use of User Stories by feature teams, the ISS team could try writing Evil User Stories, which correspond to an action carried out from the point of view of an attacker. For example:

Faced with these risks, there are Security User Stories, proposing remediation solutions for EUS, with ready-to-use acceptance criteria. All this can be integrated into a security baseline (also in backlog format, in a product management tool, such as JIRA for example), proposing a minimum-security base to be integrated into the products.

In addition to organisational support for the teams, technical support must be provided by optimising the continuous integration and deployment chain (CI/CD) with tools aimed at automating security as much as possible, which can be called the Security Stack or Security Pipeline: code review, vulnerability scans, detection of secrets, security of the Infrastructure as Code, etc.).  Particular attention must be paid to its own security, so as not to produce the opposite effect… From a shift-left security perspective, security is integrated into the product by default, right from the start. It therefore adapts its velocity to that of an agile approach and enables a shift from a DevOps logic to that of DevSecOps. 

Another role can be created, that of AppSec Manager. This is part of the ISS team and is an expert in software security as well as an expert in the security stack. Their role is to help the developers to prioritise and remedy the vulnerabilities reported by the Stack. They work in tandem with the Risk Manager/IS expert, who provides them with knowledge of the risks associated with the product, which enables a more detailed analysis of the vulnerabilities to be dealt with as a priority. All this helps to create a culture of security by design.

What do customer expect?

CISO customers expect to be reassured that security in agile mode will not cause them to “lose control” over the proper implementation of security. The model we propose empowers the feature teams, gives them tools, but security retains control by centralising the performance indicators, by having the capacity to carry out random checks/according to predefined criteria, via bug bounty for example or an envelope of pentester days, to be distributed over the various products.

Secondly, as a consultant, I think that clients expect us to share our convictions and very concrete examples of what we have been able to achieve for other clients. To meet this demand, Wavestone’s Cybersecurity and Digital Trust (CDT) practice has created several methodological accelerators based on feedback from the field, ready to be shared and adapted. Being able to carry out the mission in Agile mode was also part of the expectations, favouring co-construction rather than providing fixed and almost finalised deliverables from the first draft. In this gamification perspective, which is very important from an agile approach, we offer original co-construction workshops based on collective intelligence, thanks to our Creadesk asset, which trains consultants and provides them with tools for remote collective work.

Any final advice for our readers?

Implementing a true test & lean approach is crucial. In order to extract the most benefit from using co-constructing tools, we must regularly test and verify them in the field. While anticipating problems is crucial, significant value can be achieved when one we confront the problems as they arise. It allows us to be in direct contact with the business and feature teams, to show them that concrete actions are being implemented. The approach is agile, flexible, and scalable. The accelerators, methodologies and tools proposed evolve during the pilots and become even more relevant for the second wave of pilots, until all the feature teams are integrated.

At the same time, it is important to remember that change management is essential. A real communication plan is needed – building communities of practice/guilds from the beginning of the pilots and identifying early adopters who will be valuable drivers of change within the teams. Agile has a real and rapid impact in everyday life and at all team levels: implementing this change is essential.  

Cet article Agile Security, Emma Barféty interview est apparu en premier sur RiskInsight.

In the past year, I had the chance to work with different organisations in their Cloud transformation, and each of them has provided our team of Wavestone consultants with insights and key lessons on what Cloud-based detection systems can and cannot bring to an organisation.

For this article, bear in mind that we will consider any change of configuration leading to a degradation of the security level as an incident. While it does not perhaps fit the exact, usual definition of a security incident, misconfiguration of a Public Cloud service (where resources and data can be directly accessible through the internet) is too serious of an issue to not raise an immediate alert for the security of the information system.

Embrace the quick wins

When using Public Cloud from the main providers (Amazon Web Services, Microsoft Azure and Google Cloud Platform), it is fairly easy to turn on the native detection features and kickstart a basic, yet effective detection capability. Most platforms will provide a central security platform that enables you to detect misconfiguration in the infrastructure you have deployed, score your compliance level against a given standard and raise some alerts when the most typical incidents will occur (see further). There is virtually no reason to skip this feature, which is sometimes free to enable (either for trial or permanently).

Additionally, logging is virtually a non-issue in your security roadmap. Cloud providers will typically allow you to stream the logs from both your virtual machines (through agents), your PaaS components (via a handful of clicks, or a couple of parameters in your Infrastructure as Code templates) and the management plane of your subscription (activated from scratch). This enables your security team to swiftly understand the ongoing activity on the platform and start building on the logs to get some alerts. Moreover, some Cloud providers SIEM systems (such as Azure Sentinel) have ready-to-be-plugged connectors for appliances and external data sources which will parse the logs and remove some of the heavy lifting required when bringing the logs home to the SIEM.

Take the opportunity to improve security right away

Once you have learned the basics of the native Cloud detection tools, it is time to build your own expertise to be able to rely on your own tools! You can also leverage third-party solutions such as Cloud Security Posture Management (CSPM) solutions and configure it to cover your needs.

As hinted above, the native features from Cloud Providers offer some basics alerts which can go a long way. With AWS Guard Duty, you can detect compromising of AWS EC2 access tokens or abnormal access to S3 buckets, Azure Security Center will notify you when potentially malicious activity is detected on a virtual machine, or when Azure AD accounts are likely to be taken over… If you need to be quickly capable to detect attacks, there is a way to leverage the native, ready-to-be-used alerts available (although some of them might require the premium license after a free trial).

One of the key perks of Cloud detection is that you can right away act upon them with automatic remediation! For example, misconfigurations are a real source of concern for security teams, as the Terabytes of data leaked through accidentally exposed S3 buckets will testify. So why not reconfigure any bucket exposed, unless it has specifically been set in an “Allow List”? Automation will allow you to detect the exposition pattern, launch a serverless function which will fix the misconfiguration and could even notify the resource owner or the security team.

This can be done for misconfiguration, but also for malicious activity: if you detect an EC2 token being stolen from the metadata of an instance, you can temporarily remove its access rights. If you notice logging is being disabled, re-enable it and lock the responsible user accounts. This will drastically improve your time-to-react to security incidents.

Of course, you still need to work on the overall incident management process: both on how to avoid the misconfiguration of services (through training of developers and controls in the CICD channels if existing) and on how to manage them once they occur (the operating model is tackled further below).

Get closer to business and continuous improvement

Moving to Cloud is usually a time where applications and workloads will have to pass again through a security review to ensure the architecture and design are sound and safe. But it is also an opportunity to make security detection more relevant to the application.

To make it count, my advice would be:

• Go through the process of “Service Enablement” for new services: as moving to the cloud allow business and IT teams to use hundreds of new features and components, it is important to bring together architects and security teams to assess the main risks for each new technology, find countermeasures to limit these risks and start thinking about the alerts that will need to be implemented in the SIEM ;
• Build an alert catalog for each typical risk scenario and component, with the logic of the alert already pre-defined and only the business specifics to be customised. The “time to market” for supervision should also drop, as a good share of the components used for cloud operations is common to most applications (virtual machines, databases, serverless applications and functions, decoupling systems);
• Keep up to date with Cloud-related attacks to understand the latest vulnerabilities/attackers paths, and integrate them in your detection systems.

All these applications specifics should sit on top of transversal alerts covering your core Cloud functions (IAM, networking, landing zones, etc.). To help you build this core-detection capability, you can obviously count on our team, but I should also recommend checking on the ever-growing CloudSec community, which continuously share its expertise through open-source tooling (as this consolidated-view will prove) or on live and online platforms (such as the Cloud Security Forum and its first Fwd:CloudSec conference this year).

Not everything is easy though!

Based on everything written above, it might seem effortless to get a solid cloud detect and react proficiency. However, some challenges remain to be tackled.

The first one to come to mind is pricing. Often suggested as a selling point for Move to Cloud programs, accurately estimating how much your provider will charge you for Cloud detections is not as easy as it sounds. Over the years, many CSP security solutions have moved to component-based pricing for IaaS and transaction-based pricing for PaaS components. Log storage and alerting are sometimes even more complex, as some solutions will charge you based on log transit and aggregation, while some solutions will charge you for the number of assessments against alerts you run. Significant work is required to determine a truthful budget, and not go bankrupt.

The second key attention point is to understand what your provider offers and what it does not offer in terms of detection. While most solutions will claim to solve all your problems at once, it is unfortunately far from true. And for each security use case, there needs to be a call on whether you are fine with the free option if it exists, if the premium one is required, or if your security teams can make it on their own. Realistically, you will need to start with the native option, until your security team is mature enough, cloud-wise, to move to a homemade process.

Additionally, and maybe the most significant aspect, you need to design an operating model that will allow you to work with multiple subscriptions, multiple teams/businesses and possibly multiple Cloud Providers. More and more organisations are parallelising operations by picking different CSPs for different use cases, which leads to increased complexity for security teams – as they need to manage incidents on different platforms, with responsibilities divided between DevOps, SecOps and the on-premise teams. This will be especially difficult as some misconfiguration will lead to immediate security risks, and a choice needs to be made on whether the Ops or Security is expected to act. Without a strong division of duties across all providers and teams, there is a fair chance a small misconfiguration will snowball its way into a major data leak.

Finally, remember that monitoring your Cloud applications in the Cloud can also create risks. Besides vendors lock-in, you can lose all security functions along with your applications if everything sits under the same management plane. If the global administration rights of the SIEM tenant are taken over by an attacker, he or she will have all the liberty to affect the underlying resources (meaning erase logs, disable alerts or remove remediation capabilities). It is worth thinking about it before stacking your SIEM and critical applications under the same roof.

In the end, to sum it up:

• Grab the low hanging fruits: your Cloud Provider will help you collect and consolidate the logs easily. There are virtually no technical barriers to not use the logs anymore. In addition to that, enable the basic security features provided by your CSP to detect the most obvious attacks.
• Grow your cloud maturity together with cloud teams: The Cloud movement has pushed the business and IT teams (SecDevOps) to work closer than ever. Embrace this philosophy by better understanding the business needs in terms of security, customise alerts and automate your response to allow your capability to scale.
• Optimise costs and operating models to excel: Virtualisation has made a lot of technical aspects easier for teams, but processes can be hard to adapt. Make sure to carefully design your detection/incident response operating model to ensure all your applications and Cloud Providers are covered. Finally, think about cost optimisation when it comes to log management!

Cet article How to improve your cyber detection by moving to the Cloud est apparu en premier sur RiskInsight.

The Workplace and its Collaboration Tools

It’s great to be able to work from anywhere, any device and having the technology work when you need it. More than a luxury, it’s a necessity in the current intensified remote working situation, or for international organisations with very mobile, distributed, fluid users. While so many changes happen during the crisis, your workplace should support your business reconfiguration through enabling staff, partners, suppliers to work with different applications, different teams, etc.

The word “Workplace” used in this context refers to more than the workstations and collaboration tools. It extends to wider areas such as enterprise architecture, application security & identity and access management. Arguably, we’re talking about the wider IT foundation/digital capabilities, to support and enable business needs – the workplace might just be the tip of the iceberg.

Legacy upon Legacy adds Complexity

On the user side, as soon as you go through multiple use-cases, e.g. accessing a legacy system on premise or a Software as a Service application, you are likely to require multiple accounts and therefore a cumbersome user experience.

On the IT operation side, it is equally a burden to make it work: workstations are still most of the time a physical device bound to a rigid corporate domain; they need to be configured, then shipped to remote staff or external parties, and accounts still need to be provisioned in target environments, with access rights set appropriately. All the above usually being different processes which are repeated for each supplier or partner, leading to as many devices and set ups.

More importantly, how secure is this disorganised and overlapping situation? Having visibility and control on who has access to what, end to end and for all environments, is a challenge because of the siloed use-cases. And as users join and leave, applications evolve, the security level likely decreases by lack of keeping accounts and rights accurate.

In our experience at Wavestone, all these challenges stem from the accumulation of new use-cases and technology, implemented in silo, for their own use or limited group of use-cases. The platform, which was first designed with one primary use, has now altered into a manifold use platform with an ill-fitting model and processes. Many organisations today can be proud to rely on a federated platform and modern access experience for cloud applications on one side – and a different, yet reasonably good, experience on internal applications side. However, often both are not integrated and therefore don’t get the benefits we described in the introduction. We believe this comes from the lack of a truly shared model/architecture to support a modern experience, across all use-cases.

.

Figure 1 – Example of a corporate model in which each entity manages identities and their access separately: duplicating processes

One Model for a streamline experience

For this reason and for the future of user experience, at Wavestone we believe in a model based on Identity Control Tower(s).

An Identity Control Tower is a platform to enforce your access policies. Its purpose is to verify access requests coming from trusted sources of identity and determine if that identity is allowed to access a target digital resource. For the metaphor, a pilot willing to get clearance for take-off will submit their flight plan using a trusted channel, and after its approval and other verification by controllers, the pilot can proceed to take-off. If we were to transpose this metaphor digitally, we would talk about a user: in order for said user to access X platform, (s)he would need to use a corporate process which itself is trusted by an Identity Control Tower. Said user would provide their “access plan” (e.g. session token) to the Identity Control Tower. After the Identity Control Tower has verified the authenticity of the “access plan” against its access policies it will perform other checks of context, such as: time of the request, location of origin of the access, trust level of the device etc, the user can then proceed to access the resources. Should these verifications highlight anything unusual or inconsistent in authenticating the user, additional requests can be made to allow the user in (re-authentication or step up).

The Identity Control Tower is under your control and holds the conditions of access i.e. access policies and accepts users from specific sources thanks to a pre-established trust relationship between organisations.

For instance, in the diagram below, imagine a situation in which a supplier is developing a new service in your cloud environment. Users from the supplier would keep their device and authentication process they use within their corporate environment, while the Identity Control Tower (ICT) would enforce access control to the cloud environment – without having to use and manage a different account and re-authenticate. For environments with very granular privileges like AWS, building a decoupled ICT is maybe not a realistic approach and the ICT is then probably the identity platform from Amazon that is managed by your organisation and linked to the identity provider of the supplier. The Identity Control Tower model is basically an extension of federation, implemented to cover all use-cases.

Figure 2 – Access of a Partner user to a Cloud Provider resource through an Identity Control Tower

In another scenario, as seen in this diagram, let’s consider an applicant applying for a job in your organisation, thanks to a recruitment portal you offer. They would initiate an application in your portal using their government-backed digital identity, and once they provide their consent to access their LinkedIn profile, you could obtain a digital CV. For the applicant, it is as simple as showing their ID and giving a copy of their CV, rather than filling-in registration form(s) asking once again for the same standard identity information and risking a typo in their contact details – or even having to send copies of sensitive documents like their passport.

Figure 3 – An alternative scenario presenting the trust relationship between a government ID platform and the corporate

One Model, Three Key Pillars

Using our knowledge and experience, we believe that this model should be built upon three key pillars: a unique identity across all systems, a common and flexible model to access information and, the establishment of a 360° trust relationship.

A Unique Identity Architecture: this is achieved by following a simple rule: don’t duplicate identity data. The less identity records you create for the same physical person, the more streamline the digital experience will be – as cumbersome steps start to appear when an additional account, device or authentication action is required for the user to access the target resource. The key behind a unique identity data is to try reusing the data from its (authoritative) source instead of duplicating/copying it in your own systems. For instance, the suppliers or partners working with your organisation likely already have professional digital identities for their own IT use – what would be the conditions to leverage them instead of re-creating them?[1] The next two pillars contribute to answering this question.

A Common and Flexible Model: The second pillar is to use a common and flexible model to allow/restrict access to information. To provide flexibility, an attribute-based access control (ABAC) model enables granular rules and is well suited to a risk-based and adaptive approach. To make it work though, it is essential to define the “grammar” of the authorisation model: what are the actual attributes used to provide accesses that make sense at the enterprise level? How do they translate into “privileges”? What are their formats/values? When the Identity Control Tower is provided by a cloud provider (e.g. from a Cloud provider as Azure or AWS), the grammar is often determined by the said service. Furthermore, to make this model as widespread as possible across use-cases, both on the identity source side and on providing access on the target service side, we recommend implementing your platform following market standards to maximise inter-operability (SAML, OpenID Connect, OAuth, FIDO, etc.).

360° Trust Relationship: Finally, the last pillar is to ensure the establishment of a 360° Trust Relationship. In other words, perform due diligence and establish confidence thresholds to accept interconnection (“technical trust”) of identity platforms. The due diligence should extend to all upstream processes leading to feeding the platform with identities, for instance the HR/procurement processes to vet identities, up to the IT on-boarding process itself – because trusting an identity platform is a first step for these identities to access your digital resources, you need to be within tolerance of the risk it comes with. This trust relationship should then be implemented through security level expectations, auditability in contractual clauses, and enforced via the supplier service management governance. With such strong requirements, one organisation must be prepared to temporarily on-board suppliers or partners within the organisation’s own platform, while suppliers or partners remediate their processes and platforms to be compliant.

Two key success factors

In order to implement these three key pillars, Wavestone has identified two key success factors: being sponsored by appropriate level of management and building resilience and privacy by design. A transformation programme to establish this model would have implications and requirements in several of your organisation’s departments (HR, sourcing, legal, IT, risk, security etc.), hence should be sponsored by top-management and driven with a pan-organisation approach.
Additionally, as it should always be, the supporting platform should be designed and built with security, privacy and resilience considerations from the beginning.

Final Thoughts

As you have been able to understand throughout this article, looking at the user experience end to end and across use-cases is key to really streamline digital services. This can be achieved with a pan-organisation shift to enforce a unique identity across all systems, a common and flexible model to access information and, the establishment of a 360° trust relationship with third parties.

To go further in your reflection on the subject and understand the current state of your organisation, think about these questions and try to answer them: picking users from different departments, what does the typical day to day digital experience look like? How long does my organisation take to on-board contractors and third parties? How does my organisation actually give access to its data and resources for external users? How many duplicate identities exist across my IT estate?

[1] A technical entry might still exist within your systems, for reference purposes – but from the user perspective there is no new account, no duplicate, if they don’t have to register a new login, credentials etc.

Cet article Key Enablers in Creating a Seamless and Secure User Experience est apparu en premier sur RiskInsight.

In today’s modern workplace, it is essential for security and compliance teams to know the native capabilities of collaboration and communication platforms. This knowledge will enable them to define a coherent strategy that takes into account data protection needs as well as regulations, the urbanization of the information system and the unavoidable subject of user experience.

For companies  using the highest licensing plan, Microsoft 365 E5, there is no problem: all functionalities are available. For others, the subject is much more complex.

This article is oriented for companies with more than 300 employees. For other organizations (education, associations, small and medium enterprises) the license plans are slightly different, but the information below is still applicable for most of them.

Part 1 of this article is available here.

2/ Appropriating the licensing logic

For those unfamiliar with Microsoft licensing, there are three principles governing the allocation of licenses according to the population concerned:

• An internal user of a service or benefiting indirectly from the product (e.g. dynamic group, classification of a SharePoint site, sharing of Power BI dashboards) must have the required license;
• Most administration roles require the license of the managed service to access the administration portal or associated PowerShell commands;
• External users or guest users do not need a specific license to collaborate on Office 365 content. This is made possible by the free capabilities of Azure AD. However, if a guest user is subject to Azure AD Premium features (P1 or P2), a sufficient number of licenses must be available (1 license purchased for 5 guest users).

Licenses are nominative and are per user and per month.

Please note that the same product may be available with more or less advanced functionalities depending on the level of licenses chosen. A recurrent example concerns the unified audit logs: these logs are kept for 90 days with Office E1 or E3 licenses, whereas with Office E5 licenses the duration is 365 days.

3/ Unlocking the mystery of licensing plans

As a reminder, the Microsoft licensing model consists of the following elements:

• Licensing plan: A plan that defines the services available to the publisher in the tenant. Most of the time, a license plan will be a collaborative bundle (Office 365), a security bundle (EMS) or a package (Microsoft 365);
• License: To be considered as active, and thus be able to connect to the holder, a user must at least have a;
• Service: A service is a Microsoft 365 product, feature or capability that requires a license. This license can come from several different license plans: for example Office 365 E1 provides SharePoint Online Plan 1 while Ofice 365 E3 and E5 provide SharePoint Online Plan 2;
• SKU: In Microsoft language, this term from inventory management refers to the implementation of a license that can be assigned to a user.

Office 365 collaborative bundles: natively included data protection and compliance capabilities

Collaborative licensing plans, also known as Office 365 bundles, are the basis of Microsoft 365 licensing. These plans natively incorporate increasing compliance features. Security options, however, are quite limited and must be purchased independently.

The first plan is Office 365 E1. This plan integrates all office automation services in web mode only. The compliance and security products are the bare minimum of what can be expected from an enterprise SaaS service today: Security Defaults (basic MFA), Audit Logs, Content Search and Retention Tags.

Office 365 E3 adds the thick clients of the Office Suite (now called Microsoft 365 Apps), as well as data protection features (Information Protection for Office 365 and Office DLP), Core eDiscovery and default retention policies. This licensing plan is the preferred licensing plan for standard users in today’s enterprises.

Finally, Office 365 E5 is designed for special office populations with telephony, Power BI Pro and statistics on the use of the Office 365 suite. It also integrates automatic classification (outside machine learning), compliance options for populations subject to regulations (Records Management, Customer Key, Customer Lockbox, Information Barriers, Communications Compliance) and advanced investigation options (Advanced eDiscovery and Data Investigations), as well as Office ATP and Office CAS.

Two important points to note:

• Office DLP and AIP P1 can be purchased as additional licenses for Office E1 users, in order to have data protection features similar to Office E3;
• The Multi-Geo option is an additional license, regardless of the license plan chosen.

Security bundles: additional security features

Introduced in 2014, the EMS security bundle (Enterprise Mobility Suite, then Enterprise Mobility + Security) integrates various security products. These products are designed to control identities, mobile devices and applications accessing Office 365 data.

• EMS E3: Intune, Azure AD P1, AIP 1, Advanced Threat Analytics;
• EMS E5: Azure AD P2, AIP P2, Azure ATP and Microsoft Cloud App Security.

Today, EMS E3 is a must-have for organizations that choose to go with a “Full Microsoft” strategy. Intune and Azure AD P1 provide a consistent strategy for managing access to the Office 365 platform. On the other hand, few organizations have chosen to generalize EMS E5, a bundle rather oriented for sensitive populations or administrators, due to a lack of consistency between the different security products included.

Microsoft 365 packages: a complete but expensive offer

Announced in 2017, Microsoft 365 is now the flagship product of the Redmond-based publisher. This licensing plan combines the functionalities of Office 365, the EMS suite and Windows 10:

• Microsoft 365 E3 = Office 365 E3 + EMS E3 + Windows 10 E3;
• Microsoft 365 E5 = Office 365 E5 + EMS E5 + Windows 10 E5.

Contrary to popular belief, and despite the various name changes introduced in 2020 (Office 365 Groups to Microsoft 365 Groups, Office Pro Plus to Microsoft 365 Apps), the Office 365 brand has not disappeared.

We should note that Microsoft 365 E5 is the only office automation subscription that includes Trainable Classifiers (classification via Machine Learning), Insider Risk Management or Safe Documents (extension of Windows Defender ATP to scan open documents in protected mode).

Microsoft 365 E5 Compliance and Security: A Turning Point in Security and Compliance License Management

Microsoft 365 E5 Compliance and Microsoft 365 Security were introduced in early 2020 to simplify security and compliance licensing by grouping products under consistent licensing plans. This was good news, as the situation between EMS products and legacy compliance products (e.g. Advanced Data Governance and Advanced Data Compliance) had become increasingly complex

Microsoft 365 E5 Compliance combines the full range of information protection, governance and investigation capabilities. Depending on requirements, three sub-bundles can be considered:

• Microsoft 365 E5 Information Protection & Governance: AIP P2, Microsoft Cloud App Security, Advanced Retention Policies, Records Management, Advanced Office DLP and Advanced OME, Customer Key and Trainable Classifiers;
• Microsoft 365 E5 Insider Risk Management: Insider Risk Management, Communications Compliance, Information Barriers, Customer Lockbox and PAM;
• Microsoft 365 E5 eDiscovery & Audit: Advanced eDiscovery, Advanced Auditing and Data Investigations.

Officially presented as extensions to Microsoft 365 E3, the documentation suggests that the licensing requirements would be lower. The Information Protection & Governance extension would “only” require AIP P1 and Plans 2 for Exchange Online and SharePoint Online (i.e. Office 365 E3).

Microsoft 365 E5 Security combines Azure AD P2, the Advanced Threat Protection suite (Azure ATP, Office ATP, Windows Defender ATP) and Cloud App Security. This bundle will be interesting for organizations that are not large enough to manage many security tools (MFA, EDR, AD Monitoring, Mail Gateway, CASB).

Firstline Workers focus

The Office 365 F3 and Microsoft 365 F1 and F3 licensing plans are intended for Firstline Workers:

• Microsoft 365 F1 is a licensing plan that includes EMS E3, Teams and SharePoint (content sharing and consumption only);
• Microsoft 365 F3 combines EMS E3, Windows 10 E3 and Office 365 F3;
• Office 365 F3 is a lighter version of Office 365 E1, with similar functionality (mainly Exchange, SharePoint, OneDrive, Teams and Power Platform) but much more limited storage for OneDrive and Exchange.

Microsoft defines this population as “users without a dedicated terminal, with occasional use.” Concretely, a dedicated terminal is a computer equipment with a screen of more than 10.1 inches, used by an employee for more than 60% of his working time. Examples can be medical populations, salespeople in a store, or workers in a factory.

Therefore, Fx licenses cannot be used to optimize licensing costs for populations with no advanced needs.

4/ Getting the right tools to find relevant information

There is no official roadmap that makes it easy to find one’s way between products and license levels (E1, E3, E5, F1, F3, etc.), and it seems that everything is done to steer companies towards the most expensive licenses. Therefore, it is not surprising to see companies specializing in the very specific Microsoft licensing segment (optimization consulting or management solution publishers).

How to find out what exists (official sources)

For licenses related to compliance and security products, the most comprehensive reference is the documentation “Microsoft 365 Compliance & Security Licensing Guidance“. Unfortunately, this official documentation is not exhaustive. For example, it is missing:

• Products concerned by private or public pre-versions. For example, the new Endpoint DLP requires a Microsoft 365 E5 Compliance or Microsoft 365 E5 Information Protection & Governance license;
• Details about some compliance products. For example, Office DLP is available with an additional license;
• Information related to Azure Active Directory Premium P1 or P2 features and information related to Intune.

Note that a fairly complete table, available in .pdf and .xlsx, provides a cross-reference of use cases and compliance licenses. Beware, this table can be scary!

There is not yet an equivalent official summary for security licenses. Product documentation (e.g. Intune) and licensing information pages (e.g. Azure Active Directory) remain the best sources of information.

Important point: most official sources specify that they do not constitute a sufficient contractual commitment. Only an exchange with the Microsoft TAM will confirm the availability of a specific license and the associated price.

How to find out what exists (unofficial sources)

Apart from the official documentation, I use two rather interesting sources when talking about Microsoft 365 licensing:

• Unofficial mapping of Microsoft 365 products, by Aaron Dinnage (Microsoft): this is the most complete document available on the subject;
• Details and public pricing (in dollars) of the various Microsoft 365 licensing plans, by Dan Chemistruck (Infused Innovation).

How to find out what’s available in the holder

There are three possibilities to master the licenses (unit licenses, bundles, or packages) and products acquired in an Office 365 holder.

The first and simplest is simply to use the information available in the Office 365 or Azure administration portals. However, these portals only offer basic functionalities: no actions for a large number of users, a global dashboard (licenses acquired, used and non-compliant) without granularity by country or entity, etc.

The second option is to acquire a license management or optimization tool (e.g., ManageEngine, QuadroTech, CoreView). This type of solution is more suited to SMBs than large corporations, which prefer the third option because of economies of scale.

The last option is to develop a licensing tool (based on PowerShell scripts and Microsoft Graph APIs) and a dashboard (usually on Power BI). This choice will make it possible not only to overcome the limitations of native tools, but also to delegate the control of licenses to the various IT localities in a decentralized context.

Focus on development: how to find your way among the names

The development itself is not particularly complex. On the other hand, a common problem appears very quickly – the names of the services obtained by PowerShell and Graph API are simply incomprehensible. These names often come from buyouts or internal Microsoft project names (e.g. ADALLOM for MCAS, RIGHTSMANAGEMENT for AIP P1 or SPE_E3 for Microsoft 365 E3).

By experience, it is then essential to keep an up-to-date list of correspondences between the SKU names obtained by scripting and the official names:

–        The official Microsoft list is unfortunately far from being exhaustive and is not regularly updated;

–        Several unofficial lists are maintained and available on the Internet.

5/ Seven tips to define your security and compliance licensing strategy

1. Identify your needs in terms of security (identity, threats, terminals, etc.) and compliance (data protection, regulatory compliance, etc.) for Office 365;
2. Formalize an inventory of all the security and compliance tools related to the Digital Workplace available in the enterprise (including mail gateway, EDR, classification, DLP, etc.);
3. Formalize a roadmap for security and compliance tools, consistent with the modern workplace (rationalization, native security without agents, zero trust);
4. Define a licensing model with different user profiles, in conjunction with the architectural and workplace teams. It can be interesting to favor bundles by considering medium- and long-term needs. The acquisition of unit licenses (or add-on) without global negotiation would be expensive;
5. Anticipate product targeting capabilities. Some products (such as the functionalities of Azure Active Directory or MCAS) are difficult to adapt to a complicated licensing model in an international multi-entity context;
6. Activate what is available on opportunity in the acquired bundles, avoiding duplication with existing tools in order to not interfere with the signals;
7. Keep watch. The functionalities associated with a license may evolve as a result of a development or purchase of a third-party solution. In some instances, although very rare,Microsoft will embed premium features in basic plans. The message center of the administration portal and the Security and Compliance blogs are indispensable here.

To go further, find in this article the different subjects to be dealt with during the preparation of the Microsoft 365 adventure.

Cet article A “SHORT” GUIDE TO THE JUNGLE OF MICROSOFT 365 SECURITY AND COMPLIANCE LICENSING – PART 2 est apparu en premier sur RiskInsight.

What does “Jitsuin Archivist” look like?

The start-up Jitsuin has developed a tool called “Jitsuin Archivist” based on Distributed Ledger Technology (DLT). The purpose of this tool is to know “Who did what to a Thing and When”.

As of today, 5 types of users can interact with the tool: Archivist Administrator, System Administrator, Maintenance Operator, Auditor, Custom (currently in beta version).

Figure 1 – The 5 user roles of “Jitsuin Archivist”

On this tool the user has access to the “Security Twins” of the connected devices. Indeed, after logging in, the user accesses a dashboard through which he has a global view of all the connected devices linked to the tool. He can see relevant statistics related to his IoT deployment, such as the number of critical incidents, the activity of connected objects, etc.

The user can also access the “Manage Assets” page where he will find a map with the location of all the connected objects linked to the tool and a list of them (where he can also see in more detail the events linked to a particular connected device).

Figure 2 – The different views of the tool “Jitsuin Archivist”: 1. dashboard with a global view, 2. all the objects and their location, 3. detailed view of an object, 4. all the actions of the object useful during security audits

The PoC: A House with a digital lock

Wavestone used Jitsuin’s tool to first address the issue of identity and access management in buildings in at the dawn of digital transformation and the to illustrate the usefulness of “Security Twins”.

To do this Wavestone used the lego house “SmartHouse” :

Figure 3 – The “SmartHouse”

Equipped with an RFID card reader, a Raspberry Pi microcontroller and a servomotor, the entrance door of the “SmartHouse” only opens to users who have an authorized access card. All actions related to opening, closing, granting of entry rights, etc. are recorded on “Jitsuin Archivist” (see figure 4).

Figure 4 – The functional diagram of the “SmartHouse”

In order to facilitate the interaction with the digital lock of the “SmartHouse”, a platform allowing the simulation of different operations made by different peopled involved in the life cycle of connected devices has been created using the Django web framework and Bootstrap. This platform allows, among other things, to:

• Send security patches to the connected lock (using Azure IoTHub)
• Assign access rights to the “SmartHouse”
• View the history of access rights requests made and those awaiting validation, etc.

This is what the platform looks like:

Figure 5 – SmartHouse’s management platform

The use of “Jitsuin Archivist” in this PoC is very interesting when regards to security audits of connected devices. Indeed, as “Jitsuin Archivist” is based on Distributed Ledger Technology (DLT), this system can be considered as “secure by design” since an auditor has a technical guarantee on the non-compromise of data (provided that the sending of this data is secure).

Here is the “Auditor View” on “Jitsuin Archivist” where it is possible to see all the information regarding the connected devices linked to the platform and to know who has done what to the connected device:

Figure 6 – The “Auditor View” of “Jitsuin Archivist”

The PoC scenario: WaveHouse rents “SmartHouses” in France …

Here is the general architecture of the PoC:

Figure 7 – The general architecture of the PoC

As one can see, the digital lock (represented by the RFID card reader, the Raspberry Pi microcontroller and the servomotor) interacts with Azure IoTHub as well to facilitate the management of its firmware updates.

The main use cases studied by Wavestone and Jitsuin

The main use cases studied by Wavestone and Jitsuin are explained in the video below:

Conclusion

Wavestone and Jitsuin were able to demonstrate – with the different use cases illustrated above in the video – how to improve the security of connected devices:

• First of all, all of the people involved in the life cycle of the digital lock of the “SmartHouse” had access to its “Security Twin”. Indeed, each of them had access to a decentralized and unchangeable register provided by “Jitsuin Archivist” with all the information regarding the security of the digital lock.
• Then, as mentioned above, this architecture is “secure by design” because as “Jitsuin Archivist” is based on Distributed Ledger Technology (DLT), one has a technical guarantee on the non-compromising of data.
• The “Security Twin” of the digital lock ensured physical security since it had the rights management information, allowing all the people involved to know who had access to the “SmartHouse”.
• Finally, since the “Security Twin” also had firmware information, the different people involved could easily know which connected devices had vulnerabilities and quickly plan the distribution of security patches.

The “Security Twins” would therefore ultimately improve the security of the connected devices, since it would be easy to know which objects are secure and which are not.

Cet article “Security Twins”: A new security & trust guarantee for connected devices (2/2) est apparu en premier sur RiskInsight.

Who hasn’t already felt lost looking for information on Office 365 licensing? In this article, I will help you decipher the existing plans, as well as provide a few tips and reminders on recent announcements from the publisher.

In today’s modern workplace, it is essential for security and compliance teams to know the native capabilities of collaboration and communication platforms. This knowledge will enable them to define a coherent strategy that takes into account data protection needs as well as regulations, the urbanization of the information system and the unavoidable subject of user experience.

For companies  using the highest licensing plan, Microsoft 365 E5, there is no problem: all functionalities are available. For others, the subject is much more complex.

This article is oriented for companies with more than 300 employees. For other organizations (education, associations, small and medium enterprises) the license plans are slightly different, but the information below is still applicable for most of them.

1/ Understand the security and compliance services available

Historically focused on office automation services (with Microsoft Office) and collaboration services (with Exchange and SharePoint on-premise), Microsoft’s offering has evolved strongly by integrating not only codeless application development services (with the Power Platform), but also security and compliance bricks.

These can be grouped into seven categories:

• Security: Identity and Access Management, Endpoint Management and Threat Management;
• Compliance: Information Protection, Governance, Service Control, and Cloud Control.

Identity and access management

Azure Active Directory is the fundamental building block of Microsoft Cloud Services (Office 365, but also Azure IaaS and PaaS). It is not just a simple domain controller of the on-premises identity source in the Cloud; it is also an IAM service in its own right. Several licensing plans are available for Microsoft 365 use, whose main features are listed below:

• Azure Active Directory Basic for Office 365: Single Sign On, Manual Management of Users, Groups and Applications, Endpoint Registration, Security Defaults (basic security policies for users and administrators);
• Azure Active Directory Premium Plan 1 (or AAD P1): Azure MFA, Conditional Access, Proxy Application (exposure of on-premise applications on the Internet), Group Lifecycle (expiration, dynamic groups, classification), Advanced Password Protection (Cloud and on-premise), Integration with a third-party MFA or Identity Governance Solution;
• Azure Active Directory Premium Plan 2 (or AAD P2): Azure AD Identity Protection (assessment of connections and accounts at risk), Risk-based Conditional Access, Azure PIM (Privileged Account Management with Just-in-Time Access), Access Review, Entitlement Management (assignment of predefined rights on collaboration spaces to internal or external users).

Experience has shown that the Azure AD Premium P1 license is now a must for a number of companies. At a minimum, these companies must have the following two features: conditional access and group classification. Azure AD Premium P2 is intended for administrative populations in the first instance.

As a reminder, the functionalities available for adding or modifying objects (groups, users or terminals) vary according to the implementation mode chosen: Identity Federation, Password Hash Sync (PHS) and Pass Through Authentication (PTA).

Terminal management

Intune is the Mobile Device Management (MDM) and Mobile Access Management (MAM) solution offered by Microsoft.

The Intune MDM part is historically a mobile device management solution: deployment of applications or certificates on enrolled devices, hardening of parameters, fleet management, etc.

The Intune MAM part represents the functionalities that control the data within applications via apps protection policies. MAM can be used even in a BYOD context. It is important to note that third-party MDM solutions can be integrated with Intune MAM to control Microsoft 365 Apps (such as Office for iOS or Android), but the license will still be required to use the SDK’s functionalities.

In the context of modern management, the Intune MDM part of Intune is positioned as an Enpoint Unified Management (or UEM) solution to manage all devices (mobile or not) in a unified way. The ultimate goal is to replace the SCCM tool, also known as Configuration Manager, by positioning itself in direct competition with other MDM solutions already in place within companies.

Threat Management

The Microsoft Threat Protection suite brings together all the advanced threat prevention, detection, investigation and response capabilities of the Microsoft 365 environment: messaging, collaboration spaces, endpoints and identities.

Although the various components of the suite have historically been considered less efficient than other “pure players” in their respective segments, they have the undeniable advantage of offering unified management and correlation of indicators. However, this gap has been narrowing over the past two years, with Gartner even recognizing several components of the ATP Advanced Threat Protection (ATP) suite as leaders in their segments by the end of 2019.

There are three components:

• Office ATP: Solution to fight threats related to documents, emails and malicious links. While it is possible to add a third-party email gateway, Office ATP is the only advanced protection option for collaborative spaces (SharePoint, OneDrive and Teams);
• Windows Defender ATP: Redmond publisher’s BDU solution;
• Azure ATP: Detection and investigation solution against identity compromise, through the analysis of signals from the local Active Directory. Microsoft announced in February that it will end support for the legacy solution, Microsoft Advanced Threat Analytics (ATA), by January 2021.

Protection of information

Microsoft has recently grouped all data discovery, classification and protection functionalities under the Microsoft Data Protection Framework: Microsoft Information Protection.

At the base is the engine for identifying sensitive data. Microsoft’s engine is based on two elements:

• Sensitive Information Type (SIT): Predefined regular expressions (e.g. social security number or credit card) combined with keywords, document fingerprints (e.g. patent or form) or keyword dictionaries;
• Information Classifiers: Machine learning algorithms, with predefined or constructed models. Introduced this year and still in pre-version, the classifiers can only be used with Microsoft E5 licenses..

The current trend is to classify Office 365 data (emails, documents and now Power BI) using Azure Information Protection (or AIP). The choice of classification level can be done manually or automatically with the engine presented above. AIP has been gradually integrated into the Office 365 service package, under the name Information Protection for Office 365 (or unified classification). Although less necessary today, AIP uses the new solution as well as the non-Office 365 document coverage and classification bar in office applications.

It is also possible to classify a shared space (SharePoint site, Teams or Groups Office 365), but the classification of data and space is still decorrelated.

The actual protection of information consists of data encryption and restriction of rights (DRM). Microsoft’s proprietary protocol is Azure RMS, or Rights Management. Keys can be managed by Microsoft, in BYOK or Double Key Encryption (DKE) (HYOK equivalent for Unified Labeling presented in July 2020).

Azure RMS can be applied to data manually or by inheriting the classification level. The implementation may have a different name depending on the use case involved, but the mechanisms are identical:

• AIP or RMS for documents;
• Information Rights Management (or IRM) for SharePoint: Data downloaded from a list or library inherits protection consistent with the user’s rights;
• Office Message Encryption (or OME) for electronic messaging.

In addition to the above protection, it is also possible to apply shared space protection to harden access according to the chosen classification level, e.g. restricting endpoints or guest users.

In addition to the mechanisms attached to the data (the protection remains even when sharing or copying), it is possible to control the distribution of data through the following tools:

• Office DLP: control of the distribution of e-mails and documents;
• Communications DLP: instant messaging control;
• Cloud App Security: Extension of Office DLP capabilities to integrated SaaS applications;
• Windows Information Protection: equivalent of Intune MAM for Windows 10, aimed at separating business data from personal data;
• Windows Endpoint DLP: new DLP solution for Windows 10 presented in July 2020.

Finally, a discovery of the information can be made afterwards to locate and correct the level of protection if necessary. Again, a different solution must be used depending on the use case:

• AIP Scanner: search and classification of data on on-premises directories;
• Cloud App Security: search and classification of data on Cloud spaces;
• Windows Defender ATP: search and classification of data on Windows 10;
• eDiscovery: Cloud data search (by hijacking the original functionality).

The SDK Microsoft Information Protection can be used by third-party applications to apply classification or protection to data, or simply consume protected data.

As you can see, there are a number of tools with different names to protect organizations’ data. The important thing to remember is that users will only be directly confronted with classification and protection.

Governance

The year 2020 may be selected as the year of compliance for Office 365. Microsoft has reorganized existing products and introduced new ones to address various HR and regulatory risks. All these products are grouped together in the new Compliance Center, which replaces the equivalent part in the Security & Compliance Center.

The first group of these products is related to information retention. Retention policies (retention, legal registration, deletion, etc.) are defined via retention labels applied to a piece of data or a shared space. Labeling can be done manually, by default on containers (e.g. user mailboxes or SharePoint sites), or automatically, in the same way as privacy labels.

The products related to traceability and audit of the holder are then found. By design, the Unified audit logs can trace the actions of users or administrators. These logs, although very complete, are not exhaustive and are regularly completed. In order to increase the 90-day retention period of the unified logs, last year Microsoft introduced Advanced auditing, which offers a retention period of up to one year and more complete logs (such as all accesses to a mailbox).

In addition to logging, four products offer investigation possibilities:

• Core eDiscovery allows to extract content according to a query (e.g.: messages sent by a user containing this or that information);
• Advanced eDiscovery is an advanced feature to filter the most relevant content and provide visualization possibilities on the results;
• Microsoft Data Investigations,still in pre-version, is a clone of Advanced eDiscovery allowing to trace the context that may have led to a data leak;
• Data Subject Requestwas introduced when the GDPR came into force, in order to identify and export data related to a natural person. Again, this is a clone of Core eDiscovery, which can be searched in this context.

Note that the eDiscovery functionalities of Exchange Online (Hold, search, etc.) will gradually be phased out in favor of those of the Compliance Center.

Finally, Microsoft recently presented a whole range of products to combat internal risks (insider trading, data leakage by users on departure, discrimination, illegitimate access to data, etc.). In concrete terms, these products are designed to implement and automate existing principles in organizations’ existing HR, legal and business policies:

• Insider Risk Management is a feature to raise alerts in case of suspicious actions performed by an internal user (e.g. massive downloads performed by a user on departure, breach of security policy). The product is centered around the following axes: alert, investigation, automatic or manual remediation;
• Information Barriers allows to regulate exchanges (OneDrive, SharePoint and Teams) between internal persons, in order to technically force bans on content exchanges between entities due to regulatory requirements;
• Communications Compliance extends Office DLP’s functionality by enabling alerts when inadequate communication is detected (Teams, Mail or Yammer), such as regulatory non-compliance, non-compliance with an internal policy (e.g. harassment) or exchanges around a specific project;
• Privileged Access Management (PAM) is Azure PIM’s counterpart for operational administrative tasks. In order to perform a task, a person will have to request a privilege elevation for a defined perimeter and time;
• Customer Lockbox : is the name of the internal Microsoft process that allows a support person to access data within an organization. Customer Lockbox adds a validation step by the customer in question. In practice, this product ensures that a Microsoft employee does not inadvertently modify data, but does not protect against government requests. On the latter subject, Microsoft regularly publishes statistics.

Most of these products are still in pre-version. There is still very little feedback from the field on these solutions, which are expected to become more mature.

Control of services

In addition to the products described in the previous chapter, Microsoft provides organizations with two additional tools to comply with local regulations.

First, Customer Key allows an organization to add an overlay of encryption at the application level (Exchange Online, OneDrive, SharePoint Online and Teams), that manages the lifecycle of the keys used. This overlay is in addition to the encryption applied by construction to data at rest on Microsoft servers. However, be careful not to lose the keys, which would lead to a total loss of data.

Secondly, Multi-geo‘s functionalities ensure that data is kept at rest in a given geographical area. The challenge with this functionality is to be able to differentiate between personal and shared spaces according to the target location.

Mastering the Cloud

With Cloud App Security, Microsoft has its Cloud Access Security Broker (CASB): fighting against Shadow IT (using the APIs of supervised solutions or SaaS applications not managed via proxy log analysis), Data Protection, Detection of abnormal behavior and Analysis of SaaS application compliance.

Again, three levels of functionality are available:

• Cloud App Discovery: Accessible with Azure AD P1, this level allows you to take advantage of Shadow IT;
• Office 365 Cloud App Security: Accessible with an Office E5 license, this is an intermediate level allowing you to benefit from degraded functionalities limited to Office 365;
• Microsoft Cloud App Security: Highest level of CASB functionality.

It is important to remember here that Azure AD P1 will be required if one wishes to implement conditional access policies for connected applications (including Office 365).

With the Governance features presented above, Cloud App Security is the least exploited brick today, mainly due to the excessively high level of licensing.

Find the rest of this writing in the article “A short guide to find your way through the jungle of Microsoft 365 security and compliance licenses – Part 2”.

Cet article A “SHORT” GUIDE TO THE JUNGLE OF MICROSOFT 365 SECURITY AND COMPLIANCE LICENSING – PART 1 est apparu en premier sur RiskInsight.