August 2018: Screen lock "force"

Monday, July 30, 2018 2:41 PM: A&S IT sent a message  about a scheduled change for August 8th that they created, and had nothing to do with CIT.

This is the first time a change was going to be forced simply because a computer had software for us to report back its state.

Although this change was consequential, it was going to happen without the usual technical due-diligence to ensure:

1. It did what it was expected to do.
2. It did not do what it was not expected to.

Although this change was consequential, it was going to happen with the usual "governance" and deliberation to ensure:

1. The extent of the problem the change was meant to address.
2. The measure by which the expected change to the systems occurred.

Oliver's request to A&S IT

We request that software installed on computers to provide connectivity to central computer inventory and management tools continue to make no changes by default to any system on which the client is installed.

• Retaining this standard of practice, which has been in place for years and is enabled by CIT's provisioning of these central services, will increase the number of the college's computer assets in the Chemistry Department made visible to management and audit.
• Increasing the number of assets made visible, concurrent with investments being made to improve reporting within these centralized tools such as putting data into Remedy Asset Management, will also increase the accountability of the configuration these same assets. This can help target our technical and social efforts to further improve our security posture without compromising required functions or trust in centrally-provided tools.
• By compelling IT support providers to opt-in to affecting changes to systems under their management, it will continue to promote a culture of engagement and accountability on when these powerful centralized tools are most effectively brought to bear on identified problems, increasing their effectiveness.

If this long-standing practice were to change, it cannot be done quickly. (8 days, with almost no processing or communication, was recently presumed.) A change will force us in Chemistry to remove the client from many of our systems to better protect ... (flesh out consequences...). Making "forced" changes to computers by default, simply because they are running software to increase their visibility, is neither balanced nor necessary. This is especially true given that these are centrally provisioned tools feeding into central inventory systems, an for which we are not provided viable alternatives.

Additional details

The two management tools used at Cornell are each focused primarily on one of two supported computer operating systems (OS):

• Microsoft's Configuration Management (CM), for Microsoft Windows.
  • Chemistry uses CM on xx number of computers, which is yy % of the College's computers using CM.
• Jamf's Jamf Pro, for Apple MacOS.
  • Chemistry uses Jamf Pro on xx number of computers, which is yy % of the College's computers using Jamf Pro.

Just having the client installed, even when not doing anything to a computer, provides us (IT professionals, A&S management, and CU Audit) valuable, trustworthy visibility to computers with the clients. Information includes the last time a computer has reported into the central console (implies whether asset is active), the computer's configuration (for example, our screen lock-related settings and if the OS current), software (and their versions) installed.

The client is the ONLY method the university provides and makes investments in to get data automatically into Remedy. Remedy has Cornell-specific fields to help ensure compliance to university policies. Thus we should be promoting the use of these clients. And not do anything to impede their use, such as making changes automatically to systems just because they have the reporting client installed.

CIT provides these tools. CIT, by default, makes no changes to any system on which the client is installed. Arts and Sciences IT should do the same and compel the local IT support providers to "own" changes made to their systems, while facilitating installation of the client on all possible university-owned computer assets.

Chemistry IT has been using these powerful central computer inventory and management tools for many years (8?). Indeed, when we add a Windows computer to AD, we have it automatically install the CM client. Always. Not only do these clients provide central visibility of our computers and their "state", but they also afford us other advantages. These advantages include:

• Enable logging in with NetID.
  • This means our department does not have to manage log-in accounts, such as password resets.
  • Using this technology also provides automatically credentialing to central services such as SFS and policy-based mounting, etc., etc.
• Enable logging in with AD accounts (number of these easy to get? It's many!)
  • Centrally-managed passwords provide for one location to update passwords on many systems at once.  distributed among different computer making their management untenable
• Enable easy access via Active Directory.
• Enrolling all our Administrative computers, and many others, to central patching and other "standards" not appropriate to many research systems we also manage.
  
  

Of course central computer inventory and management tools can also be used to make changes to computers on which the client is installed.However, these capabilities must be made optional for any given computer and groups make these desired changes easy to apply to many computers at a time.

Oliver's further takes, FWIW

Question

• Was action taken out of ignorance (didn't understand meaning of action, nor it's consequences), irresponsibility (knew potential to harm trust and compromise fidelity of infrastructure but went ahead anyway), or some other reason?

IT professionals should keep some things in mind

Mass-affect technology must be respected.

• Take care what you do for one computer. Take super-deep care what you do for hundreds of computers.

Enable us to use our technology to serve our users by letting us do things for them. Not do things to them.

Enable us to use our technology to better see what we have to see what must change and prioritize areas of concern.

Don't be compelled to use only the tools you have if they don't get you the desired state.

• Be willing to walk away from unacceptable results, regardless of the pressures.

When existing, proven, active technical vetting processes exist, use them or be clear you did not and why.

Just because you can do something doesn't mean you should do something.

• As a corollary, just because a tool appears to do something doesn't mean it does what you hope it will. Especially if you don't ask the right questions when testing it.

Action was presumptive. The change had not followed expected process to reduce chance of technical error and what the change led to the desired outcomes.

Action was arrogant and paternalistic. The change came across as "we know what is good for you and this is good for you; we know better than you. Accept it."

In this case, at least on the Mac side, this approach led to an irresponsible "force". The decision-makers seemed to be disregarding the risks associated with using a powerful tool in a new way which was clearly not technically well understood. ((a configuration change, not a software package deployment)

Oliver's poem inspired by this announcement, August 2, 2018

Watch the do-do

See, before you DO.

Don't DO unless you do due process.

See what you DID.

If you do not do this, you will likely step in DO-DO.

And that stinks for everyone.