Cybersecurity & CEI

Note:  The following is a very nerdy post about computers!

So unless you’ve been under a rock for the past month or so, GSUSA recently released 42 new badges, including cybersecurity ones for Cadettes, Seniors, and Ambassadors!  In a previous life, I used to be in the IT field, so I was very interested to see how these badges were presented to older girls.  So I logged into the infamous VTK to check out the Senior Cybersecurity Basics activity plan.

One of the first activities is to learn about the ten principles of cybersecurity according to the GenCyber program.  I won’t go through all of them at this point, but you can take a look at the cards with the principles and terms spelled out.   I’m going to refer back to some of them later on.

So you may be wondering where I’m going with this instead of talking about our Yellowstone trip, because who really wants to learn cybersecurity terms versus reading about our awesome adventures in the land of geysers (it’s coming later, I promise)?  Well, last week, the Western Ohio council accidentally sent an email out to troop cookie managers all over the country notifying them about a missing agreement form.  Confusion ensued.  Something very similar happened a year or so ago but with a different council accidentally blasting volunteers everywhere about something neat going on at their council, and everybody wished they lived there.  Sad face.

Another note:  If I’m incorrect about any of the following, please let me know.

So what’s going on here?  GSUSA rolled out something called CEI a few years ago, which is short for Customer Engagement Initiative.  Every council is now using CEI with the exception of the Farthest North and Middle Tennessee councils who use Council AlignMENT, a system designed by Middle Tennessee.  Before CEI, councils maintained their own member rosters and other records.  The membership data was uploaded to GSUSA who used it for their own purposes, whatever that entailed.  But part of the Core Business Strategy formulated in 2004 was a vision of an all encompassing IT system that all councils would fall under.  GSUSA started building it in 2012.  It uses the customer relationship management (CRM) system Salesforce as its basis.  But for our purposes going forward, let’s just refer to it as the Big Mega GSUSA Database.  When councils transitioned to CEI, all of the data they used to store and maintain on their own like member records got dumped into this Big Mega GSUSA Database.

Yet another note:  A lot of the following is conjecture based on my past work experience and what I’ve picked up along the way as someone using parts of CEI as a volunteer, so again, correct me if I’m wrong.

Loaded on top of this Big Mega GSUSA Database are applications such as Volunteer Toolkit, MyGS, and whatever councils use to log their problem tickets and update records and what not.  They also use it to send emails, such as the one Western Ohio did the other day.  All of these applications pull in most if not all of their information from the Big Mega GSUSA Database.

What happened with these mass emails is inexcusable.  And I’m not laying the blame on Western Ohio at all.   I’m laying it on the developer of this council application piece and on GSUSA’s project management for not fixing it the first time it happened.

Doing a search in a database is much like doing one on the internet, except that you’re looking up data in something called fields.  Fields can be used to categorize items within the database.  For example, within the Big Mega Database of GSUSA, if you’re a co-leader of a troop, the Position field in your record says “Co-Leader.”  You’re also assigned a role if you’re something in addition to being a co-leader.  One of the roles is Troop Product Sale Manager – Cookies.  To sort or to pull out specific information from the database, you use something called criteria (aka search terms).  In other words, if you wanted to view all of the co-leaders who live in Greenville, SC, you’d use “Greenville” in the City field, “SC” in the State field, and “Co-Leader” in the Position field as the criteria.  And voilà!  There’s your list.  I’m sure this is as clear as mud, and I also realize I am simplifying the Big Mega GSUSA Database’s structure and the applications that run on top of it.  I won’t try to explain how relational databases work because then it would REALLY get confusing.

So back to Western Ohio.   I don’t know their specific staff titles, but let’s just say the equivalent of some kind of product sales director wanted to send an email to all of the co-leaders in their council who had “Troop Product Sale Manager – Cookies” in the Role field, but only those who hadn’t completed their Troop Cookie Manager Agreement Form.  Most likely there is a field in the Big Mega GSUSA Database that notes whether a co-leader has turned in this form or not.  So in addition to that field, the Western Ohio product sales director used the criteria “Co-Leader” in the Position field AND “Troop Product Sale Manager – Cookies” in the Role field to send this email.  From what I picked up within a Facebook group, council staff also have to input their numerical council code as a criteria.  It would stand to reason that this code is one of the fields in the Big Mega GSUSA Database.

But when pulling this set of co-leaders for the email, I also read where the staff member accidentally left out the council code.  So the search results included members from EVERY council who happened to match the rest of the criteria, and the email in turn went out to ALL of them, not just the ones from the Western Ohio council.  As I mentioned before, something similar happened last year but in another council.  Oops.

Why am I bringing this up?   There are a couple of reasons.  First, it just bugs me as a former IT professional that something like this would happen in the first place.  Simplicity is a principle of cybersecurity, and adding in extra tasks such as council staff having to input their council code as an additional criteria shouldn’t be necessary and leads to oopsies like what happened last week.  The developer of this application should have designed it so that when a staff member from a certain council logs in, the application loads the staff member’s corresponding council code based on their username, and any search results done against the Big Mega GSUSA Database would automatically filter data ONLY from their council.  There’s no reason why someone like a product sales director in Western Ohio needs the ability to email members from other councils.  The first time it happened last year, okay – mistakes happen – but it should have been fixed at that point.

What’s the big deal about this, you ask?  It’s just an email!  Well, I’m sure it was a big deal to the Western Ohio council who had to field all of the return emails from volunteers asking what the heck?  Why are you sending this to me?  And other councils probably had to deal with their own confused volunteers.  And then everybody had to figure out what happened and send out a follow-up “Oops, sorry!” email.  This took time and energy and caused major disruptions to the normal work day (if there is such a thing as a normal work day in a council).  This is also a violation of the cybersecurity principle Data Hiding, which means you hide information from users who don’t need to have access to it.  And Domain Separation, which keeps things separated based on categorization.

Second, some concerns were raised about the privacy of members’ data in the Big Mega GSUSA Database.  Can anyone with a username to certain applications that use the Big Mega GSUSA Database access member data from other councils?  I don’t know the answer to that, but I’ve heard they can.  In what capacity, I don’t know.  Could this be a violation of the Least Privilege cybersecurity principle which states that users should only have access to as little data as needed depending on what their job requires?

Or is the fact that councils other than your own can access member data a privacy concern ?  Well, I did some digging, and first I went to Ye Olde Blue Book of Basic Documents as I always do.  In the Policies section under Security of Girl Scout Membership Data and Restricted Use of Membership and Mailing Lists, it states, “The release and distribution of any Girl Scout membership list to a Girl Scout council or non–Girl Scout entity, or the release of any data or information on Girl Scout members, is prohibited except upon approval by the Girl Scouts of the United States of America.”  Unless GSUSA has restricted councils to their own specific data in the Big Mega GSUSA Database, and I doubt they have, then this doesn’t cover the privacy question.  Also in GSUSA’s Privacy Policy, they state, “We do not sell Personal Data or other information you provide to us online with third parties. We may share Personal Data with the following categories of third parties: (i) with Girl Scout Councils; (ii) when the person submitting the information authorizes us to share it; (iii) when sharing the information is with a service provider in furtherance of our operations or the operation of the site, for instance, to process a purchase or other transaction you make; (iv) to facilitate participation in Girl Scouts of the USA programs, promotions, and services, or to engage in Girl Scouts fund raising, marketing communications and promotions; (v) to comply with legal processes such as a subpoena or court order or to otherwise protect your or our legal rights; or (vi) for other purposes for which you provided the information. ”  So this doesn’t restrict them either.

Is this even a problem, really?  Maybe not, but even outside of Girl Scouts, you should be aware of where your personal information is stored and who is using it.  That’s not a principle of cybersecurity per se, but it’s a good idea for you to know in general.  So in turn, you should know that because of CEI, councils no longer own their own data and that it’s being centrally housed in the Big Mega GSUSA Database.  That means things such as your member data, VTK plans, your troop’s finances, and training records are all being recorded in one place unless you’re in the Farthest North or Middle Tennessee councils.  GSUSA does have those councils’ member lists, but their other information is controlled locally.

So taking this a step further – if GSUSA is now controlling this information and councils are basically just data entry and administrators of said data, will there be a point where councils really aren’t necessary except for local logistical matters?  With the way it’s set up, it’s very possible that someone in another part of the country could take care of your issues via the online help desk application that’s already built into CEI.  There are benefits for councils on CEI such as analysis reports and a consistent IT system, but could they soon be regulated to just regional offshoots of GSUSA and the charter system goes away?  If that is the case, then the entire federation system of governance that our organization is based upon and has used for 100+ years will change.  How will this impact us as volunteers down the road?  Will we be seen as nothing more than just customers of a product that’s part of a big national chain and our voice goes away?

But back to the issue with the email blast.  Come on – SOMEBODY on the developer or GSUSA project management side needs to make that simple fix within the application.  How much are we paying these guys?