A Worst Case Scenario This week it was revealed that a severe vulnerability in a majority of processors has existed for nearly ten years, affecting millions of computers around the world, including all the major cloud providers who rely on Intel chips in their data centers. Essentially, this flaw grants complete access to protected memory, including secrets like passwords, from any program on the exploited computer. Even from the web. This flaw is so serious that allegations have already been made that Intel’s CEO sold millions of dollars of stock in the company after the flaw was found, but before it was revealed to the public, the idea being that a vulnerability of this magnitude would be enough to substantially hurt Intel on the market, even though it affects some ARM and AMD processors as well.
Microsoft’s enterprise software powers the majority of large environments. Though often hybridized with open source solutions and third party offerings, the core components of Windows Server, Exchange, and SQL Server form the foundation of many organizations’ data centers. Despite their prevalence in the enterprise, Microsoft systems have also carried a perhaps unfair reputation for insecurity, compared to Linux and other enterprise options. But the insecurities exploited in Microsoft software are overwhelmingly caused by misconfigurations and process errors, not flaws in the technology— patches are not applied on a quick and regular cadence; settings are not hardened according to best practices; dangerous defaults are left in place in production; unused modules and services are not disabled and removed. Microsoft has come a long way to bring its out-of-the-box security up to snuff with its famous usability, not to mention introducing command-line and programmatic methods by which to manage their systems. But even now, the careful control necessary to run a secure and reliable data center on any platform can be difficult to maintain all of the time at scale.
Managing complexity in heterogeneous infrastructures is a challenge faced by all enterprise IT departments, even if their environments are relegated to *NIX or Windows. In the case of the latter, UpGuard's new RSoP/GPO scanning capability streamlines remediation and compliance efforts by enabling Windows operators to easily scan and monitor the disparate security configurations of their Active Directory (AD) instances and Windows endpoints.
Polylithic, vendor-neutral, platform agnostic. Microsoft may not exactly come to mind when hearing these descriptors, but it will soon enough—if recent developments are any indication. And despite the software behemoth's DevOps zeitgeist purveyance as of late, open source initiatives have always been alive and well inside Redmond’s hallowed walls.
There’s no right place to start with DevOps, but there are reasons that different people choose to start. There are also ways of communicating that make it more likely to take succeed in your organization. Being aware of the people you are talking to and the processes they work within can make your DevOps experiments more likely to grow into a business-wide culture.
If you’re working with IIS then you know that preventing configuration drift is as important as it is time consuming. In the best case scenario you’re monitoring configs daily to keep development, testing, and deployment running smoothly. In the worst case—well, all-nighters make good war stories but aren’t much fun. A proactive approach is much better. UpGuard automates configuration testing at scale, to find out if your IIS servers are hardened and as expected. We'll look at how UpGuard can help with these five major problems as an example of what we do. Here are the top five critical configuration problems we see on IIS servers and how we fix them.
We've been working with a lot of Windows shops recently and IIS configuration seems to be a big pain point for many enterprises. Other than a brief stint in mainframe purgatory after university, I started life as a .Net developer and these conversations reminded me of my fun with IIS back in the day. In reflecting on this, I realized that the developer/operations interaction around IIS configuration is a near perfect example of the type of conflict that gave birth to the DevOps movement.