One of the most impactful blog posts I’ve seen is Aaron Margosis’ brilliant Sticking With Well Known and Proven Solutions . The philosophy here is spot on, and something we try to echo within Windows. Yes, we have thousands of management configurations available to ensure that you have the ability to tune to your specific needs. But no, you shouldn’t have to turn all of them every single time just to get a functional system! In fact, the more knobs you turn, the more you wander into the unknown. Now, turning knobs isn’t always bad. Some organizations will always have a need for a bespoke, hyper-customized configuration. To use a metaphor, if you hand me a BMW M4, I’m probably going to take it as you give it to me, and at most toss one of those pine tree air fresheners in there. If you asked me to re-tune the turbo chargers, the chances that it will even start after I finish are pretty close to zero. But if you hand it to Christian von Koenigsegg , he’s probably going to pull a few hundred kg of weight out of it, re-tune the engine, and transform it into something that can produce epic track outcomes. (Assuming he wasn’t working on his own cars, that is – this is a hypothetical after all.) Similarly, some people will benefit from customization, but most actually end up increasing risk rather than removing it. (Fun fact: at one point, 30% of our support cases for the browser did not reproduce in a vanilla configuration, but required setting up the policies in the customer’s bespoke way, and then determining which policy was incompatible.) We’ve been really focused on shipping an out-of-the-box configuration that makes sense, but we should keep in mind the optimization that we’re going to target. For all consumers, Microsoft is effectively their IT Administrator. If we don’t ship it the right way, then that’s a problem for us. For an organization who has an IT Admin, they have somebody else serving in that role, so when forced to choose, it’ll be for the majority case, or the case where there is no IT Admin. Now that can lead to some questions we have to ask in order to get user consent – while at scale an organization’s IT Admin can consent on everyone’s behalf. So, understanding that trade-off, we’ve published the Windows Security Baselines , which is targeted (and deployable) to organizations that care deeply about security and want to start with the most secure configuration. These baselines are used on hundreds of thousands of devices, and are well known – which means that we can focus our testing on this configuration, and you can rely on the fact that loads of other customers have already seen the effect of this configuration on their software. But, there’s one thing that we’ve been thinking on… Is there only one configuration? Or is there a potential taxonomy of multiple configurations? Because having one security baseline implies that all devices should be protected in exactly the same way – and we’re thinking – that may not always be true. So, that got us wondering – what are the potential device categories and configurations you might need to support? BYOD – not everyone allows BYOD, but if you’re going to let someone work using their home computer, you probably want to enforce some security standards, but if you were to, say, apply application whitelisting and not allow them to play Call of Duty on their home desktop just because they want to check their email, then you’re probably going to end up with some grumpy users. Standard Security – One of the bits of feedback I’ve gotten is that, while the security baseline is great for organizations that have a consistent need for everyone to be super secure, there are some scenarios where the information on an endpoint isn’t that valuable (and lateral traversal has already been mitigated) – so is there a stepping stone configuration that doesn’t take months to stand up and test, but focusses on configuring for the configurations that are low risk and/or high impact? High Security – This is what the security baseline provides today Developer – This is a configuration I’ve seen bifurcated – some people want to be more permissive on developer desktop (granting things like admin rights), while others want to be less permissive. Given the recent prevalence of supply chain attacks, I think it’s smart to invest in the less permissive developer desktop, but the cadence of change and needs of the audience probably merits a custom approach. Administrator – We’ve been talking about this one for years, and the Securing Privileged Access roadmap talks about the value of hardened workstations extensively – and it’s something the Windows Server team is investigating and demonstrated at Ignite last year. Do you have a taxonomy? What are you using to define your device categories? One guiding principle in my conversations has been that we should be looking at having a very small number of configurations for which we provide prescriptive guidance. If we end up with thousands, we’re not much better off than when we have the individual knobs! Instead, we want to get close enough for most users and most device scenarios, understanding that some organizations will always need to deviate from the guidance and we need to provide rich support for that without requiring that every single organization therefore has to.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.