by Scott Muniz | Sep 21, 2020 | Uncategorized
This article is contributed. See the original author and article here.
Onsite gyms. Stocked refrigerators and gourmet cafeterias. Catered morale events and offsite retreats. Hallway conversations and conference room whiteboarding sessions. If workplace facilities and perks help people feel more comfortable, productive, and valued, those investments stop paying off when most people work remotely.
Let’s face it: the sudden global migration from on-premises to work-from-anywhere computing has transformed the device user experience into the entire workplace experience.
Many organizations have understandably deprioritized device user experience in the face of economic pressures and security threats that have strained IT bandwidth in the transition.
What does that look like? Devices that hang or crash, taking 10 or more minutes to reboot. Disruptive remote troubleshooting sessions. Important files getting lost in email – and worse: version control issues – as colleagues adopt digital collaboration tools.
When the device is the only conduit for literally all workplace experiences, there are no free snacks to balance out the inconveniences, disruptions, and frustrations adding up over the course of months.
More likely than not, your organization can relate. Analyst Josh Bersin finds the #1 employee concern is tech for remote work. IDG reports that 44% of organizations say they need new tech to address the new work dynamic. And AppDynamics says that 61% of IT professionals feel more pressure at work than ever.
Accelerating the journey to modern management
As a senior program manager with the Microsoft Managed Desktop customer acceleration team, I help customers modernize endpoint management to delight end users, protect data, and reclaim IT bandwidth for digital transformation..
If you share these goals, I encourage you to check out my session at Microsoft Ignite 2020, Accelerating the journey to modern management, which covers the following:
- How work evolution strains IT bandwidth, security, device user experience, especially in the context of economic uncertainty,
- How modern management is shown to help organizations resolve those issues,
- What Microsoft Managed Desktop does to accelerate the journey to modern management,
- Technical and non-technical considerations that affect deployment timelines, and
- Real Microsoft Managed Desktop customer onboarding journeys ranging from six weeks to six months.
As promised at the end of my session, this docs page will help you get ready for Microsoft Managed Desktop enrollment. It covers prerequisites, readiness tools, app preparation, environment configuration, and other tasks you’ll encounter as you work to modernize.
Additional modernization resources
Wherever you are on your journey to modern device management, you’ll want to check out this guide to Microsoft Endpoint Manager at Ignite.
Here are several additional promising sessions on topics about managing the new workplace:
Everyone can access these virtual sessions, which are available on-demand at your convenience. If you find them useful, please let me know in comments.
And if you’d like to start planning your enterprise journey to Microsoft Managed Desktop, please reach out to your Microsoft account team. My colleagues and I on the customer acceleration team look forward to helping you deliver a secure device experience that helps your people – and your IT organization – feel productive and valued in the work-from-anywhere environment.
How has the evolution of work affected your organization? Which customer deployment story best resembles your situation? Please share your comments below.
by Scott Muniz | Sep 21, 2020 | Uncategorized
This article is contributed. See the original author and article here.
By Caroline Lee & Sebastien Molendijk
Welcome to our third post in the Automation in Cloud App Security blog series. If you are a new reader joining us for the first time, I encourage you to go check out our last two posts (https://aka.ms/MCAS/Auto-Blog & https://aka.ms/MCAS/Auto-Triage). In this series, we showcase various Power Automate flows that help to mitigate advanced customer scenarios we see today in Microsoft Cloud App Security (MCAS).
In today’s post, Seb & I will go over a new Power Automate template that will send alerts to a user’s manager requesting for action. By sending the alert details to the manager, they can make the decision to ignore the alert, disable the user or request an investigation. This helps to take to the load off the Security team by asking the manager to validate the alert instead. Another benefit sending the alert to the user’s manager versus the SOC team is they’re able to verify with the user if the alert is a false or true positive.
This flow can be tweaked for any given policy but for the sake of this post we will focus on the multiple failed login attempts policy. If you’re unfamiliar with how this policy works, check out our built-in anomaly detection policies. We’ll start by gathering a couple of details: the user profile and the manager information for that user. When an alert is triggered for a given user, the flow will send an email to the user’s manager requesting for input. There are a couple of options they can choose from:
- Dismiss Alert: this will dismiss the alert in Cloud App Security
- Disable User: this will disable the user in AzureAD
- Request an investigation: this will send a message to a SOC teams channel with the incident details
By giving the manager the ability to take action, this can help with the volume of alerts that are generated in MCAS; allowing the security teams to focus on ones that are true positives. All of our flow templates can be found in this Github respository: https://github.com/microsoft/Microsoft-Cloud-App-Security/tree/master/Playbooks. Let us know if you all have any feedback after trying this flow out. What other scenarios would you like us to cover? Feel free to comment below!
by Scott Muniz | Sep 21, 2020 | Uncategorized
This article is contributed. See the original author and article here.
Hi everyone, and welcome to the MR Tech Community! I’m Nick from the MR Academy in San Francisco, and when I’m not burying my head in one of my numerous different code projects, I host events and do presentations at the local Microsoft Reactor! Or at least, I used to.
My team stopped doing in-person events towards the start of the year, and that’s turned out to be a pretty cool thing since we got to move many of our events online. It has been really awesome having easier access to amazing speakers that weren’t available in-person, and chatting with developers from all over the world is a really humbling experience as well!
Remember when we used to do things in-person? Hah! Wild. Here’s a few more people from the MR Academy onstage at the reactor: Dan Escudero, Jesse McCulloch, and myself, with Jo Ryall hanging out in the background!
But the one event I loved the most, the MR Workgroup, didn’t translate very well into an online event. Twice a month I used to host a small group of MR developers in the Reactor kitchen, and we’d just hang out and work on projects, share ideas, chat about the latest news, whatever was on our minds at the time! It was one of the highlights of my week, and I miss everyone who used to come out and join us.
So we’ve tried to make this space feel like that workgroup! It’s definitely not 1:1, but I think it’ll come close. So think of this as a place to share, learn socialize, a developer workgroup on the web!
The Mixed Reality team has also been itching for a platform to blog on, so you’ll see some great content from our developers pop up here! We’ve got a cool line-up for this week, from some incredibly talented developers!
Thank you for dropping in and being part of the MR community, and before I sign off here, I’m going to take you on a quick tour of the space!
- Mixed Reality Blog
We’ll be posting content here straight from our devs! We have so much cool tech, and so much great knowledge to share! This will grow into a treasure trove of MR information. Feel like you’ve got a blog post in you too? Send me a note! We’d love to feature learnings from the community too!
- Mixed Reality General
Do you have something to talk about, but can’t find a good spot to say it? May as well pop into General! Everything is great here, and it’s a perfect place to introduce yourself!
- Mixed Reality Showcase
Showcasing your projects, features, or experiments is a great way to get some visibility, feedback, or just a little ego boost from showing off! No need to be humble over here, and if you’re looking for feedback, it’s always great to clarify what type of feedback you’re looking for! Just uh… don’t leak anything secret ;)
- Mixed Reality News
There’s a lot happening in this industry! Share the latest developments and talk shop over here! Doesn’t even have to be Microsoft specific, everyone is welcome here!
- Mixed Reality Feedback and Help
While this Tech Community is a social space, not a technical support channel, sometimes you just need some guidance! Q&A sites are better for answering specific questions, but if you don’t even know what to ask, or need something a little more vague, this is a great spot to drop into! We also love to hear feedback about Microsoft MR tech, and this is a good channel for that too!
- Mixed Reality Events
Do you have an event? Post it here! Does Microsoft have an event? We’ll post it here too! Want to chat about an event? Park your keyboard over here! There’s a lot of fun events happening out there.
So! Make yourselves at home, introduce yourselves and say hi, maybe even share some screenshots of what you’re working on, if you can! I know I’m definitely looking forward to meeting everyone :)
– Nick Klingensmith
by Scott Muniz | Sep 21, 2020 | Uncategorized
This article is contributed. See the original author and article here.
Today excited to announce the general availability of Azure IoT Edge security with enclaves that helps protect sensitive assets and workloads at runtime when deployed to an IoT Edge enclave enabled device.
A major roadblock to edge computing and Internet of Things (IoT) experiences is the risk of exposing sensitive assets and workloads to exfiltration or malicious tampering. Sensitive assets include proprietary algorithms, private data, artificial intelligence models, and real-time computational insights, while sensitive workloads entail edge computing on sensitive assets which in some cases create valuable insights that generate actions to directly control critical infrastructure. While these assets and workloads can be secured in transit and storage using encryption, they become vulnerable at runtime when they are decrypted for execution. The lack of solutions protecting the confidentiality of sensitive assets and workloads has held back IoT solution operators from distributing rich cloud computing experiences to the edge, until now.
Figure 1: Deploying trusted applications (TA) with IoT Edge.
The solution builds on the robust edge compute application deployment mechanism of Azure IoT Edge to encrypted workloads (and data) known as trusted applications or simply TA, to Azure IoT Edge enclave enabled devices for safe and secured execution inside of enclaves. The TA is encrypted from when it leaves the developer build machine to when it lands inside of the devices trusted execution environment (TEE) or enclave where it is decrypted for safe execution.
We previously announced a public preview of this solution in a blog post where we detailed the types of blocking challenges and showed how a true solution requires deep integrations and collaboration with ecosystem partners. These integrations and collaboration are necessary to abstract the complexities away from IoT solution builders so they can focus on respective business transformations. We highlighted one example of the requisite collaboration of ecosystem partners to simplify this experience. We have since maintained focus and now observing dividends such as from this example alone, a solution builder is now able to:
In general, the ability to deploy TA is available now on IoT Edge certified enclave enabled devices built on Arm TrustZone® and Intel® Software Extension Guard (SGX®) technologies. Building on Open Enclave SDK means you only develop once and deploy to both Arm and Intel platforms. Moreover, Open Enclave SDK automatically opens possibilities for rich cloud-edge confidential computing patterns such as:
- Asymmetrical compute workload distribution e.g. train ML models in the cloud rich environment and only inference in resource constrained edge devices.
- Cloud-to-edge end-to-end confidential computing with workloads encrypted everywhere except for TEE at the edge or in the cloud e.g. deploy the same workload in Azure IoT Edge enclave at the edge or Azure Confidential Computing virtual machines in the cloud.
Our commitment to simplifying confidential computing in collaboration with a wide ecosystem of partners is yielding greater maturity to Open Enclave SDK, developer tooling, and availability of commercial off-the-shelf IoT Edge enclave enabled devices. We now offer secure deployments of trusted applications from cloud to edge at scale because of these accomplishments.
What’s Next
Simplifying confidential computing is a massive undertaking anywhere and more so at the edge where collaboration between many ecosystem roles and stakeholders must thrive to succeed. Delivering an end-to-end deployment experiences is a major success milestone but there’s always opportunity for continuous improvements, such as in attestations in which you can check out our progress with Microsoft Azure Attestation.
We now invite you to unleash your rich edge compute experiences with greater confidence:
by Scott Muniz | Sep 21, 2020 | Uncategorized
This article is contributed. See the original author and article here.
Companies building Internet of Things (IoT) solutions today are likely to deploy IoT applications that use unsecured devices, mainly because they cannot verify the security claims from device manufacturers.
Solution builders could create secured devices themselves. They tend not to because they either lack domain expertise, or simply prefer to buy devices off-the-shelf. Device makers, on the other hand, possess the requisite expertise to secure devices but lack the ability to convey details. For example, language constructs such as for conveying computation, storage, and power profiles of an Industrial PC (IPC), are simply not available for security. Device makers therefore see no motivation to invest in securing devices if they can’t claim the value and hence the current stalemate. Our studies and observations show this stalemate exists for two reasons:
- Lack of standards guiding how to holistically engineer and claim device security.
- Lack of standards guiding how to consume and verify device security claims.
Given how IoT globally connects solutions, supply chains, and interests irrespective of company, geography, or governmental affiliations, effectively solving the stalemate requires global openness as well.
We’re happy to announce the Edge Compute Node protection profile (ECN PP), a Common Criteria (ISO 15408) standard that will guide how to engineer, claim, evaluate, and consume security for IoT devices. We build on Common Criteria for transparency, cross-industry practice, global recognition arrangements, and global availability of licensed laboratories. Edge Compute Node protection profile, officially NSCIB-CC-0112146-CR, is in final step of certification.
We created and drove development of ECN PP here at Microsoft but our efforts were immensely amplified by the following partners contributing diverse expertise and experience, and for whom we’re very grateful.
Figure 1: We recognize these collaborators with gratitude for amplifying our efforts with their diverse expertise.
We’re excited by this development and so are our partners:
“ProvenRun’s mission is to help its customers resolve the security challenges linked to the large-scale deployment of connected devices. We are very proud to have contributed our expertise into this mission to enable industry motions that help ensure all IoT deployments are secured-by-design”, Dominique Bolignano, CEO and founder, ProvenRun.
When ready, device makers and solution builders can freely access ECN PP from the Common Criteria portal, and later view list of ECN PP certified devices. We’re excited to see how ECN PP co-development partners are already putting it into use as we illustrate one real example at the end of this article. Device makers of products like Azure IoT Edge can now holistically secure devices, objectively claim security, and be assured of differentiated visibility on Azure device catalog in addition to the Common Criteria portal. We envision other IoT solution providers building custom experiences with ECN PP on respective platforms. For us, ECN PP is only the beginning of an exciting journey in which we invite you to join us in making it our common journey towards a unified goal.
How we see security in IoT
Our vision for security in IoT is a world in which every IoT ecosystem stakeholder choices and actions contributes to overall security of IoT where consumers and benefactors are simply secured by default. To a solution builder as an example, this means building with components that have been certified to deliver all security and compliance requirements for the target solution. We achieve this vision by standardizing a baseline and then evolve this baseline with maturity. Given afore described stalemate between the IoT solution builder and device maker, it stands to reason for the IoT device, and not the security subcomponents, to be the current minimum baseline.
Figure 2: The IoT device as the practical minimum baseline to standardize on security.
Sizing the solution right – device security promise
A major goal in security is to balance efficacy with cost otherwise unintended consequences result. Go cheap and risk efficacy or spend too much and risk security budget cuts. For IoT devices, secured silicon (aka hardware security module or simply HSM) is often the last defense to deliver resistance against tampering from malicious physical access. Secure silicon together with associated engineering and operating costs is also the biggest cost driver. A need therefore arises to appropriately size secure silicon investments for the IoT deployment risk profile. We address this need by providing a useful tool to judge the coverage expected of the secure silicon, a tool we call device security promise, that currently offer standard promise, secure element promise, and secure enclave promise for sizing.
Figure 3: Device security promise for IoT devices.
If you wondered how to assess the IoT deployment risk then you are in luck. The IoT Security Maturity Model by the Industrial Internet Consortium delivers excellent tools and guidance for exactly this purpose. You can also learn more here about the role of secure silicon in securing IoT.
It is worthwhile to note device security promise only conveys the scope of secure silicon isolation. Robustness in protection, for example how much resistance can one expect from the secure silicon against physical and environmental tampering, derives from depth in secure silicon security engineering and qualifiable through standards such as the National Institute of Standards and Technology’s (NIST) Federal Information Processing Standard 140-2 (FIPS 140-2) and Platform Security Architecture certification (PSA Certified™). ECN PP captures and reports compliances to standards addressing robustness for a holistic view of the device security posture. The approach taken by ECN PP is equally important.
Measurable goals over prescriptions
ECN PP defines measurable security goals instead of component prescription. This approach invites and engages unique talents and expertise of device makers in achieving these goals for efficacy while simultaneously garnering product differentiation. We avoid prescriptions to preclude blind compliance with no stake in efficacy, which brings us back to the problem we set out to solve. The result is a modular protection profile that presents a comprehensive security goals grouped under convenient categories and accommodates device security promise customization.
Figure 4: ECN PP modularly structured for device security promise customization
Taking device security certification to the next level with programmatic real-time attestations
ECN PP on its own provides the tools that help enable secured IoT deployments through standards for collaboration and global transparency, but we envision using it to build more. To start with, while Common Criterial portal shall remain authoritative listing for security ECN PP compliant devices, device makers with ECN PP compliant devices certified for Azure will merit product targeted recognition within our IoT device catalog. We’re excited for this ability to recognize our device partner commitment to security. We’re equally excited about our current engagements to build on ECN PP and deliver programmatic real-time device security attestations.
Beyond visibility into overall deployment security posture, programmatic workflows with real-time security attestations will empower solution builders to target workloads only to devices that meet certain security posture for example, they can target workloads with confidential or privacy content only to secure enclave promise devices. Another pleasant upshot are the signals these workflows will generate to device makers for the types of devices in demand based on device security promise.
While this work is just being announced, we already see strong interest and real engagements such as follows:
This is an example of a device maker, Scalys, following ECN guidance to select Arm TrustZone® based NXP Layerscape® LS1012A to build a robust secure enclave promise device, and engaging UL to setup for certification. A solution builder will discover Scalys certified device from Common Criteria portal, and build solution they can later attest the device’s security real-time.
What’s next
We thank all the partners that have joined us already on this journey to secure IoT for all and invite more. Engage now as follows:
- Access Edge Compute Node protection profile, NSCIB-CC-0112146-CR, coming very soon to Common Criterial portal.
- Device makers – engineer device security to ECN PP, engage any Common Criterial licensed lab for certification and attestation setup, and view Common Criterial portal for licensed devices (allow time for engineering and certification of early devices).
- Solution builders – demand ECN PP compliant devices for security assurance.
- Common Criterial licensed labs – contact us to setup for device attestation.
- Technology partners – join us to evolve ECN PP.
Recent Comments