All Posts in Shadow IT

|In: Shadow IT|Last Updated:

Recently, hackers have targeted Python’s widely used libraries in the Python Package Index (PyPI). These libraries are often only downloaded and installed when a program is run, making it hard to detect or realize that there is a problem.  These libraries also are widely used in a number of program.  In this case, the libraries were downloaded thousands of times, and nobody notice until after significant damage was done.

For commercial software vendors, such a vulnerability would (hopefully) be caught in testing. But for IT managers and shadow IT users that are exploring Open Source tools, enterprise or not? Well, that’s like skating on thin ice with a blowtorch. One wrong download, and you’ve potentially opened the door for cyberattacks—no warning signs or red flags in sight.

I love the open-source software model. I have built a large part of my career on this. But, like everything, there are some challenges, and one of these that is emerging are some new and not so new security threats.

So what might help mitigate some of the risks?

I was inspired by some really smart people in Public Health.  Taking a page from harm reduction approaches used in public health— we could apply similar principles to open source and shadow IT. Instead of saying “No,” what if we tried to adopt a “use safely” approach?

  • Don’t assume safety because it’s free.
    Just because something’s open source doesn’t mean it’s been vetted. To be clear, I think paranoia is probably helpful. Open-source libraries are like free samples—some are great, but others may leave you feeling a bit sick. Remind your teams that due diligence is required especially with open-source software.
  • Harm reduction for shadow IT.
    Shadow IT is here to stay, and rather than play the whack-a-mole game of shutting it down, why not embrace it safely? Encourage teams to innovate and explore new tools, but do it in a controlled way. Use completely segregated sandbox environments to offer a safe place for testing. In harm reduction, safe injection sites minimize risk; in IT, secure environments can do the same.
  • Scan, and realize that scanning probably isn’t enough.
    Insist on using automated scanning tools for every piece of code, and realize that it may not be drilling deep enough into runtime libraries and tools from platforms like PyPI. Just like health officials promote regular testing to prevent the spread of disease, your security team should promote automated scanning tools to ensure no malicious code slips through.
  • Community matters.
    One of the strengths of open source is the community behind it, but this also means there’s no singular authority watching over every package. Get involved in the community where you can. Have your developers contribute and review code. It’s not just about using tools; it’s about being part of a network that looks out for one another. In the public health space, community efforts are critical to harm reduction. The same applies here.
  • Update religiously—Or not. 
    Keeping software and libraries updated is a no-brainer—or is it?  In open-source environments, patches and updates roll out fast. It seems that the hackers in this case managed to commit code to widely used libraries and nobody noticed.   In this case, it probably would have made sense for a developer to wait and see.

We all like learning from other fields—and I think we all have been paying a lot of attention to public health over the last few years.  By applying these harm-reduction lessons to open source, we can balance innovation and security in a way that reduces risk without killing creativity. SAP, Python, or any other platform—it’s all the same story: prevention beats recovery.

Comments

|In: Policies and Procedures|Last Updated:

Including Keep the Joint Running and its predecessors – InfoWorld’s IS Survival Guide and Advice Line – I’ve been sharing thoughts and opinions for more than 26 years.

When I started, I wanted people to read what I had to say and think, “Wow!” Now, I’m gratified if they think, “A column a week for 26 years? Wow!”

Quantity seems to have gradually overtaken excellence as my most crucial KPI.

Meanwhile, I’m more likely to remember having written about a subject than you’re likely to remember having read about it for, I think, obvious reasons. As a result I sometimes obsess about avoiding repetition – that if I’d written about a subject in 1998 you’ll feel cheated if I write about the same subject here in 2023.

Which brings us to this week’s subject: “Shadow IT,” also known as “Rogue IT,” “DYI IT,” and, if you want to encourage Gartner in its perennial game of claiming concept ownership by attaching snappy new names to unoriginal concepts, “Citizen Developer.”

Or, you could use the handle my co-author Dave Kaiser and I introduced in There’s No Such Thing as an IT Project, as a contrast to Shadow IT, namely, “Illuminated IT.”

As with so many ideas in life, illuminated IT comes with trade-offs, making it sadly easy to succumb to confirmation bias when deciding whether to encourage it or try to stamp it out.

The stamp-it-out logic

End-users aren’t trained developers. They might fall short when it comes to application architecture, testing, or security. And if or when something goes wrong, IT will have to pick up the pieces.

Not only that, but when the end-user developer “calls in rich,” IT will be called in to support the mess the end-user developer left behind.

The philately-free logic (okay, it’s a stretch)

DIY development increases IT’s bandwidth – not once, but in two complementary ways.

The first is the obvious one: a DIY developer still counts as a developer. Maybe not an ideal developer, but I’ll bet not all of the developers housed within the IT organization are ideal ones either.

The less obvious one? For the most part, IT development, along with IT “development” (when IT configures and integrates commercial off-the-shelf software), involves a business analyst here and there. DIY IT does not.

Related: No more arguments about whether what IT delivers is what the business needs.

The best of both worlds

Once IT jettisons its protectionist instincts, and once business users jettison their IT-distrust instincts, getting the best of both worlds isn’t particularly complicated:

1. Encourage using what you already have. It isn’t uncommon that an application suite you already license provides the additional functionality the business needs. The formula for success: Inform, train, follow up.

2. Encourage COTS. If some application provider licenses a solution that does what business users need, it reduces the risk of losing support due to the end-user developer finding something else to do.

3. Establish platform standards. Whether it’s Excel, Access, or a “no-code/low-code” cloud-based alternative, setting one of these as the supported and recommended development environment reduces IT’s support burden. Once you’ve established the standard, offer training and support as needed.

4. Inventory. Ask business users to provide three layers of documentation for anything they develop. Layer 1 is the application’s title (“MS Word” is an application title). Layer 2 is the application’s headline (“General-purpose word-processing application” is an application headline. Layer 3 is a no-more-than-three sentence explanation of what the application does. With this inventory, should IT have to swoop in to save the day there’s a good starting point to swoop from.

5. Establish a Mentor Program, aka a Power Users Cool Kids Club. How to do this? See “Mentors are your friends. Be nice to your friends,” which first appeared in InfoWorld September 23, 1996.

Bob’s last word: For far too long, IT’s “best practice” on DIY development has been “We won’t do it for you and won’t let you do it for yourself.

Without a doubt, DIY development comes with some risks attached. But then, DIY prevention comes with risks of its own, namely, that various parts of the business will forgo important opportunities for technology-enabled improvements in effectiveness, all because a focus on what might go wrong blinds decision-makers to what might go right.

Now on CIO.com: “The 7 venial sins of IT management.” What it’s about: Seven mistakes to worry about that probably aren’t on your to-don’t list already.

Comments