All Posts in Policies and Procedures

|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: Office Politics|Last Updated:

Projects have Stakeholders, according to  the founder of this column.  Stakeholders may be on board with the project, ambivalent, or even detractors, but they are still stakeholders.  We serve them and the project better when we ensure that we are keeping them informed, and addressing their need to not be surprised.  One key technique to keep Stakeholders apprised of a project is through a Steering Committee meeting, probably scheduled about once per month.

It seems like there are many approaches for how to best organize and operate a Steering Committee.  In the spirit of this column and community, we want to propose a  “Bare Bones SteerCO, what you can’t not do. ”  The problem is that Greg and Bob don’t see eye to eye on this yet–.

Greg Says

Let’s start with the belief that a SteerCO meeting is not the place for surprises, debates or design.

The purpose is to keep your stakeholders informed and involved, and as aligned as they can be towards solving the business improvement project at hand.  It is an informational meeting only.  Serious discussions deserve their own time and space, involving the appropriate stakeholders.

There is a corollary here—If we don’t want this meeting to devolve, we need to elevate our preparation, and make sure that we have informed all parties effectively.  Make sure that everyone attending has necessary and relevant information and decisions/options well ahead of time, so that “Surprises” are avoided.

Bob Says

I’m not a big fan of informational meetings, Greg. I’m not even a small fan. Depending on what’s being steered, the group’s members are important people. Steering Committees/Councils are the final escalation point for resolving project issues, which means its members should have enough authority and political capital to resolve issues that reach them.

Greg Says

So, If steering committee meetings are for escalation of issues,  does this mean:

– They are scheduled regularly, or only as needed to solve a problem?

Bob Says

I think we need to rewind. Before we can talk about how often a SteerCo should meet, or what its agenda should be, we need to talk about the process of chartering, staffing, and launching it.

That means determining such matters as: Purpose, vision, key messages; guiding principles; council roles and membership; SC staff support; and more (this is a conversation, not a PowerPoint!). And, for each of these, the SC, as it forms, should establish the cadence for each SC element. It’s those cadences that should determine the SC’s meeting schedule.

Greg Says

Then Is there is a gatekeeper (probably the project sponsor), who decides what the agenda is, and when to convene them?

Bob Says

Absolutely, although as a fine distinction these should be decided by the project sponsor wearing their SteerCO Chair hat and guided by a charter.

Greg Says

I hear your concerns about informational meetings– and to some degree, I agree. At best, I think they are a necessary evil.

Perhaps it is the PTSD from some poorly run Steering Committee meetings coming out, but I think problem solving meetings should be chartered separately, with the specific mission of solving a problem as the outcome of the time invested.

Bob Says

I think this aspect of things isn’t all that hard to solve. Just build “Status Update” and “Project Issues” into the overall agenda but don’t let them dominate it.

Greg Says

How about this?  Could a compressed informational “SteerCO” meeting be delivered as a pre-recorded video from the PMs to the Council of the company?  This would allow leaders to stay informed, but asynchronously, as they have time.

Bob Says.

Well, first of all you caused me to imagine the PM doing a tap dance while tap-dancing through any hard questions the SC might need to know about. Thanks a bunch!

But second … to be effective at steering whatever they’re steering, SC members will need to interact directly with the PM.

And third, I’m thinking that if the PM reports status via pre-recorded video, they’ll start thinking in terms of production value and not just substance.

That’s when it all falls apart, as the PM organizes the project team into a barbershop quartet, and other company PMs vie for winning the Best Project Status Video award. Back to you!

Greg Says

If we are going to get the time of these very valuable and busy people,  I think we need to promise to make the most of their time.   May I propose a Minimum Viable Agenda that I believe we can give our readers for the Bare Bones SteerCO?

o   The project charter and goals.  This is an important reminder—We need to remind ourselves why we are doing this project, and what benefits we are investing in.

o   Any changes to roles or responsibilities in the team.

o   A simple “green/amber/red” stoplight chart on budget, schedule and scope.  This is what most people think a SteerCO meeting is, and this information should be conveyed as simply and visually as possible.

o   Any comparison or chart about “Where we think we are” vs “Where we think we should be.”  This is another case of simple and visual communication works wonders.

o   Upcoming milestones, and who has responsibilities for some part of the accomplishment.

o   Risks, issues, disagreements, and key decisions- Ideally, these are pre briefed, and use something like a decision paper format, so that the Council understands the issues, options, and different opinions before the meeting, and they are prepared for the discussion.

Bob Says

Yes to the MVA. My opinion is that your proposed one isn’t sufficiently Minimal.

The project charter should include cadences for such things as reviewing the project charter, vision, goals, and so on. So they’ll be in some SteerCO meetings and not others. My opinion is that each SC meeting should include:

  • Project status
    • Current: Green/yellow/red; explanation
    • Look-ahead: Potential changes to schedule, scope, and budget
  • Issues update:
    • Status of past issues
    • Impending issues
    • Cadence-driven issues
    • For each issue, support needed from the SC
  • The buzz: What SC members are hearing from the rest of the company about the project.

That’s about all I have on the subject, unless I haul out my PowerPoint deck on the subject and apply Springer’s Law to it (Springer’s Law asks “Why use a picture when a thousand words will do”?).

So I’ll leave the last word to you.

Greg Says

I hope our readers will weigh in with some ideas about what they have found to be the most effective way to plan and manage this meeting.  I feel like we have just scratched the surface of this topic.

Comments