Tag: hardware management

  • BYOPC Solves Endpoint Provisioning Challenges

    BYOPC Solves Endpoint Provisioning Challenges

    For many cloud-first companies, workstation imaging isn’t “a thing.” The notion that an IT organization might need several days – or even weeks – to onboard a new employee by provisioning an imaged laptop with correct security policies and only approved applications on it is absurd. The constraints of operating in an admin-centric model for IT service delivery would completely erode the agility that cloud native engenders.

    But let’s say your company was born before the cloud era. Or, suppose your company operates in a highly regulated industry, like financial services or health care, for example. For your company, workstation provisioning may still be a very real thing, and it may be weighing you down. That’s why a bring-your-own-PC (BYOPC) policy could be the answer.

    Now, take that basic provisioning problem and multiply it by a few orders of magnitude. That’s what happened to many companies in the crush to support remote workers in response to COVID-19. Most weren’t ready for the scale of the problem, and some had no means to enable secure remote work for their privileged users. So, when it came time to pivot to a remote-first stance, many IT organizations were unprepared, unprotected and overwhelmed. Between budgeting, acquiring endpoints and the provisioning of those devices, many companies incurred enormous opportunity and financial costs.

    But what if that didn’t have to be the case? What if, instead, there was an option to enable every new employee or newly remote worker instantaneously? What if the company didn’t have to bear the capital expense of purchasing new laptops for each employee? And what if the company didn’t have to carry the operating expense of having an army of IT admins whose job requirements are little more than commissioning and decommissioning workstations as new hires come on, as existing employees pivot from working in-office to working at home, and as others leave the organization?

    Scaling and Simplifying Enterprise Endpoint Provisioning

    Companies can unburden themselves by instituting a bring-your-own-PC (BYOPC) policy. BYOPC allows companies to scale back on investments in new laptops while allowing them to scale up their support for remote work. BYOPC provides employees the freedom to work how and from wherever they want, on whatever endpoint makes them most comfortable. Allowing employees to use their laptop of choice also offers the side benefit of helping to maximize worker productivity.

    At the same time, BYOPC helps companies to reap significant capex and opex savings. Permitting employees to use non-corporate devices reduces demand on IT admins’ time while also avoiding cost attributed to the purchase and maintenance of corporate endpoints. BYOPC, then, is a rare win-win for employees and the IT organizations that must support worker productivity, as long as the IT organization can effectively operationalize it.

    Gartner recognizes that BYOPC is on the rise, saying that companies need to “… support BYOPC practice, as it will be necessary for a long-term work-from-home strategy.” Further, our own research bears this out: in a survey we conducted recently in conjunction with Team8, we found that more than three out of four companies (78%) allow employees to access corporate networks or applications from a non-corporate device.

    Pairing BYOPC with a New Model for Endpoint Security

    Of course, a company can’t simply institute or dramatically scale a BYOPC policy without deploying or commensurately expanding a robust endpoint security policy. And this is where things get interesting: according to Forrester, spending on endpoint security had been rising, year-over-year, even before COVID-19 pushed so many companies to expand their remote access policies. During 2020, that investment has soared. However, we also know that 70% of security breaches start at the endpoint. So, it’s reasonable to conclude that something in the endpoint security ecosystem has to change, regardless of whether companies institute BYOPC or stick with traditional provisioning of corporate-managed devices to provide secure remote access.

    Companies have traditionally relied on a variety of isolated workspace approaches to provide corporate security while permitting workers to download questionable applications or visit dubious websites. Think app sandboxing or legacy remote access solutions like virtual desktop infrastructure (VDI) or desktop-as-a-service (DaaS). VDI and DaaS separate desktop images and applications from the user’s device. The images and applications reside on servers that are usually positioned in the cloud.

    Authorized users access VDI or DaaS resources from thin clients, corporate-managed laptops or user-owned devices, leaving no corporate assets vulnerable on the endpoint. With app sandboxes, threats that come in from the sandboxed application are contained within the sandbox, preventing malware from affecting the operating system (OS).

    These isolation methods have provided some level of protection, but each has shortcomings that experienced bad actors are able to exploit. Likewise, browser isolation is yet another strategy that works well within its confines – blocking malicious web content – but browser isolation also leaves other vectors completely exposed. Given that each of these isolation methods has significant gaps that leave corporate assets vulnerable to attack, the isolated workspaces market has been ripe for disruption.

    That disruption has come in the form of OS-based isolation. OS-based isolation allows an end user to have multiple operating systems on a single endpoint, allowing unrestricted access to the internet, email and non-privileged information via an unlocked OS while reserving a second, privileged OS for accessing only high-value corporate assets, including sensitive data and other systems.

    This privileged OS restricts internet access, prevents the user from installing or running unsanctioned applications, and rejects all peripherals. Corporate data is encapsulated on the same endpoint in the isolated environment and cannot be exfiltrated.

    From an enterprise perspective, key attributes of an enterprise-grade OS isolation solution must include purpose-built tools to centrally manage isolated environments remotely, supported by a robust and fine-grained set of networking, clipboard and data security policies such as access control, application management and insights across the entire workforce. With OS-based isolation, breaches may still happen in the non-corporate environment, but there’s no possibility of exfiltration of malicious code, meaning the corporate environment remains protected.

    There were days when every employer provided its workers with company-managed mobile devices. In many cases, those days are long gone. It may still take a while before the expectation of working on a company-provided laptop becomes nothing more than a memory, too. But the time is right to give workers the freedom to use an endpoint of their choice without opening up the company to security threats. Doing so will make workers happy, relieve the budget pressures on IT, and still allow security teams to sleep at night. That’s what we call a win-win-win trifecta.

  • Infrastructure-Testing Dominoes

    Infrastructure-Testing Dominoes

    Understanding the artifacts of a given technology component is critical to an enterprise-class DevOps service offering. Second-most critical is understanding the dependencies between given components. Testing helps illuminate those dependencies.

    For example, let’s assume I have a server running the previous version of the Windows operating system (OS) that I now want to upgrade to the latest version. The previous deployment package of this version of the OS would be an artifact. It should also include all of the test automation I run to validate that version of the OS is working after I install it. The artifact also might include configuration files I deploy when I install that version of the OS on this type of server in this class of environment. Having these bits of automation bundled together allows me to do a successful install of my OS (assuming no hardware errors) on perhaps many servers.

    As I create a new artifact for the latest Windows OS, I keep in mind all the things I had in my last version. I might include a newer config file and perhaps a set of tests (albeit new ones) to make sure it is working when I am done. Bundling all these bits gives me a new Windows OS artifact or package that I can use over and over on this kind of server in this class of environment. The idea is that I am creating a single kind of artifact or package to cover this kind of technology—in this case the latest version of the Windows OS operating system. All my artifacts should be version-controlled. So when I’m done I have an artifact for the previous Windows OS and one for the latest version. Each artifact version has embedded or included testing (pointers to, or discreet automation) to verify the validity of the install, and perhaps a little more to prove the OS works.

    Within my DevOps tooling, I likely have some sort of artifact management system. It may not be as formal as a full-on configuration management database (CMDB) system, but whichever tool I use will have some sort of database to manage my artifacts or packages by version. How long I retain these artifacts will be defined in my retention policies, but likely I will retain every version in use at my company today. This is step one, and it forms the foundation for my next effort in cataloging the dependencies that exist between artifacts.

    Enter the Spider’s Web

    Under the scenario I have described, when I deploy either the previous OS or the latest one, I would run a series of tests specific to that version to ensure the OS is working properly. As an infrastructure engineer, I tend to think my job is done at this point. But it isn’t. To truly validate that my OS is working, I really need to know what is running on the server I just deployed to. If my server was bare or new, then I am really done. But if my server has middleware running on it, then the job is not finished until I re-deploy the right version of the middleware on top of my new OS and verify it is still working properly.

    To pull this off, I will need a catalog of the technologies that depend on each other. The OS example is kind of simple, because it lives at the bottom of the stack where a server is concerned. But on top of the OS might reside a middleware platform (perhaps messaging or a database). On top of the middleware might reside an application or perhaps several applications, depending on the horsepower of the server in question. Upgrading the OS component implies I am redeploying the middleware layer and then the application layer on top of that.

    Enter full-stack engineering. It takes an application-centric view of the world, but this implies a single application-centric view. It looks at one app from top to bottom and treats the entire stack as a single version-controlled artifact. But if you have legacy environments that run multiple applications on the same physical box, perhaps on the same virtual instance, you have the makings of a spider web of dependencies. There are no full-stack solutions (to my knowledge) that have figured out how to incorporate multiple applications at the top of the same stack, varying middleware in the middle and “n” number of virtual instances that ride on one OS on one physical box. Instead, each piece of the technology tends to be treated separately. Thus the need for some sort of catalog that tracks the interdependencies between them all.

    Starting the Domino Testing

    So once I have discreet testing that is version-controlled (or associated with) each type of technology component, I will have to re-execute those tests if anything “under” me undergoes a change. For example, if the version of my WebSphere is upgraded, beyond just the core WebSphere testing that occurs, I really should execute the tests associated with each application to ensure “that app” is still working after the upgrade. You could apply this premise to a database layer (say, upgrading the current version of Oracle, as an example). To really know if the database upgrade was successful, you should run the testing of each dependent app and ensure “that app” still works after the upgrade. The results are likely to be surprising.

    To execute this kind of domino testing, even if you have the web of dependencies defined and the artifacts or packages managed, you can take one of two approaches: redeploy everything, although this method may not actually kick off tests if it detects the versions did not change from the last deployment (smart overwrite), or set up discreet testing jobs within your release orchestration software to execute the entire web of dependencies and track the results. In either case, you are going to need human oversight on whether it is better to keep the new version or roll back to the old one. Only a human can prioritize the impact of what might seem small or catastrophic (based on a human perspective) of a given app or series of apps.

    Impact to the Bottom Line

    True quality can be assessed only through testing. Part of breaking down silo-thinking is taking a holistic view of the technology your organization supports. Just because the OS support engineer’s testing passes does not mean the upgrade was a success. For an upgrade to be a success, the tests of everyone else who relies on that technology underpinning must pass to prove it worked. The entire team needs validation when the underlying infrastructure undergoes change. The dominoes of tests must pass from end to end. Only then can true quality or true success be measured.

    Of course, most engineers are reluctant to have “app software” guys influence whether they did their own jobs right. After all, most software quality problems are in the code, not due to infrastructure errors. However, if the applications upon which your business relies cannot work, no matter what the reason, after an infrastructure upgrade, it is a problem for the entire business, not just the software guys. To tear down the silos, we need to look at impacting events for change across boundaries and drive toward overall results, not just departmental ones. When this occurs, the cost of quality is significantly reduced.

    To continue the conversation, feel free to contact me.