Part 1: Cyber Terms and Conditions to Consider When Purchasing

I think most of us can agree that governmental procurement processes are very different than those of the private sector. Fundamentally, this is because government needs to be fair and transparent in how we procure services and goods. Why? Because we are ultimately funded by public monies – taxpayers. The reason I bring this all up is because we should take a similar procurement posture when it comes to information security. Our jobs should be to ensure that the goods and services we procure meet minimum cybersecurity/data requirements.

The best example of this are third-party cloud services. The National Association of State Chief Information Officers’ (NASCIO) 2019 state CIO survey showed 34% of IT leaders had a cloud migration strategy in place and 51% had a strategy in development. That, coupled with the overwhelming feedback that COVID-19 has accelerated the adoption of cloud services by all government agencies highlights its impact.

Ask any CIO, regardless of sector, and I suspect 99% of them will say companies were already going the way of the cloud. Recent events have only sped up this transition. I have participated in a number of panels on this topic and quite a few of them are already 100% in the cloud. However, government still lags in this area and I suspect your agency’s procurement terms and conditions lag as well.

So take a look at what your organization’s Ts and Cs are and see how out of date they are. While not intended to be an exhaustive list, here are some things you might want to look at.

Source Code Escrow

So this one is an oldie but goody. Many of us have this requirement that basically says if the third party whose software you use, goes out of business, then you can procure the source code so that you can maintain the application. This concept makes a lot of sense from an infosec perspective. As protocols and applications go out of support or if vulnerabilities are detected, you can make update the app to address these issues. Obviously organizations that enter into these sorts of agreements pay a premium to maintain the right to the source code. Also, how often do software companies go out of business (assuming you’re not buying software from someone working in their parent’s basement)? More likely the scenario is a company gets bought/sold and you have a new vendor to work with. In my more than 25 years of IT experience, I have only seen a source code escrow agreement leveraged twice. For a more detailed explanation of source code/software escrow, check out Escrowtech.

The issue is the move to cloud services. I have never seen a cloud provider offer to put their code in escrow. The truth is this still happens but it certainly is less common than on-premise installations of software. There could be a number of reasons for this but the more obvious reason is software as a service (SaaS) escrow agreements tends to be complicated. In addition to the base code, there are other elements needed to reproduce the service in its entirety:

• hardware configurations/design docs
• any third-party connector and products needed to deliver said software
• data source that feeds the SaaS solution

So, your agency will need to decide how important putting cloud source code in escrow is. What a lot of organizations opt for in lieu of escrow is the ability to download data stored by the third party. That way, you can at least run reports and query data until an alternative solution is found.

Data Ownership

I believe this is one that most government agencies have a handle on. If this isn’t in your Ts and Cs, add it immediately. Any data generated or stored in the cloud service you’re using (check this link by bigcommerce.com for examples of different cloud services), unless expressly owned by someone else (e.g. you are paying for use of the data in question, like through a subscription, etc.) belongs to your agency.

While you might be able to put security controls/permissions around certain data types, it becomes less of an issue if you don’t own the data. Don’t let ownership of your organization’s data slip through its hands.

Data Usage

This one is somewhat related to data ownership but not thought of by most organizations. The gist is this: data generated by the customer typically belongs to the customer, but who can use the data? If you think that your organization is the only one interested, you’d be surprised.

In a previous role, I was helping my facilities management department negotiate use of a HVAC vendor’s SaaS subscription. During the course of the negotiations, they explained how customers could input information about different HVAC systems into their cloud service, i.e. their competitors. They would then use customer data to help refine their operational data models so that they could more accurately identify normal system operating parameters. Essentially, they were using customer data, which the customer owned, to improve their data models, which in turn improved their SaaS solution. Maybe for most, this isn’t a big deal – are most government agencies worried about HVAC competition? Hard to say. Some orgs might want to be notified in instances like this. What if instead of HVAC systems we’re talking about personally identifiable information about your residents? Even if it was anonymized, perhaps this is less acceptable.

This use case tends to be an information security issue as this goes to the heart of data privacy. Unless your org has a chief privacy officer, this tends to land in infosec’s lap. At the end of the day, you need to decide how important it is for you to understand how your data is being used and by whom. Some agencies might not care but I posit that, given the increased scrutiny over public data use and privacy, we should all start caring a bit more.

Well, as usual, this blog post is running long and there is a lot more to cover (hard to believe I know)! You can read part 2 here.

Interested in becoming a Featured Contributor? Email topics you’re interested in covering for GovLoop to [email protected]. And to read more from our Winter 2021 Cohort, here is a full list of every Featured Contributor during this cohort.

Lester Godsey is the Chief Information Security and Privacy Officer for Maricopa County, Arizona, which is the fourth most populous county in the United States. With over 25 years of higher education and local government IT experience, Lester has spoken at local, state and national conferences on topics ranging from telecommunications to project management to cybersecurity and data. His current areas of professional interest center around IoT (Internet of Things) technology and data management and the juxtaposition of these disciplines with cybersecurity. You can follow Lester on LinkedIn.