Re: Planning for future of IT career

[Ruth Ginzberg <rginzberg () UWSA EDU>]

As an Information Security person who is currently working full time in I.T. procurement, I would like to second what 
Joe said.

There is a desperate need for Information Security Professionals who are able to read, review, redline, negotiate, and 
write contract language.

I know that (ISC)2 is planning on partnering with the Cloud Security Alliance to come up with a new CISSP sub-specialty 
that will (presumably) include CCSK components. I hope it will also include some of these skills as well.

When an organization's Information Security depends not on firewalls and defense perimeters, but on the language in its 
contracts, there is a desperate need for I.T. professionals with hard core information security backgrounds who are 
able to read, write and negotiate contract language. The usual divisions of labor (Legal Counsel reviews the legal 
aspects of a contract and Procurement reviews the business aspects of the contract) completely miss the Information 
Security provisions that also need to be a part of cloud contracts.

Here is an example:

There was a recent NetworkWorld article about contract language. The article noted that:


A strict requirement of service architecture isn't the only aspect of the SLAs [Gartner Analyst Lydia] Leong takes 
issue with. They're unnecessarily complex, calling them "word salads," and limited in scope. For example, both AWS and 
HP SLAs cover virtual machine instances, not block storage services, which are popular features used by enterprise 
customers. AWS's most recent outage impacted its Elastic Block Storage (EBS) service specifically, which is not covered 
by the SLA. "If the storage isn't available, it doesn't matter if the virtual machine is happily up and running — it 
can't do anything useful," Leong writes.
This is not something that most procurement specialists or attorneys (individuals most likely to be reviewing 
procurement contracts) are likely to catch in a contract review. You actually need to have technical expertise in 
network security and architecture in order to be able to read an SLA containing these "word salads" (love the term) and 
determine that it isn't giving you anything worth having. Yet finding people with that level of technical expertise AND 
the ability (and time, and appropriate job description) to read and review these kinds of contracts is extremely 
difficult. Basic knowledge is also needed in I.T. Risk Management, so that the person reviewing these kinds of Ts & Cs 
at least knows enough to Red Flag Ts & Cs that pose significant financial risk to the institution other than contract 
pricing.







Ruth Ginzberg, CISSP, CTPS

Sr. I.T. Procurement Specialist
University of Wisconsin System

rginzberg () uwsa edu
608-890-3961
Disclaimer: My views, not necessarily those of my employer. ----- Original Message -----

From: "Joe St Sauver" <joe () OREGON UOREGON EDU>
To: SECURITY () LISTSERV EDUCAUSE EDU
Sent: Thursday, February 20, 2014 8:33:16 PM
Subject: Re: [SECURITY] Planning for future of IT career

Hi,

Bob asked:

#I have been noticing an ongoing trend of schools much larger than
#ours going "cloud only". Being a smaller school with only a
#couple IT workers, I am hoping to get some insight on the future
#of IT careers from those in larger environments.
#
#Question: As things go more to the "cloud", what type of skills
#for IT professionals do you envision will be in most demand?

I think it depends in part on the sort of cloud deployment model
you've got in mind. If you're think about cloud-based applications,
I'd suggest:

-- market awareness (how do my various options look? what should
go on my short list for in-depth investigation? do I just want
to do a new/local RFP/RFI, or can I buy off of some other
already completed procurement?)

-- an understanding of how to conduct an indepth review of
the most promising options (or how to score and assess
competitive submissions offered in response to an open RFP
or RFI)

-- cloud contract review and negotiation skills (what sort of
T&C's do I want? do I need SLAs? If so, how much (if anything)
should I pay for them? Is the flexibity of a year-to-year
agreement better than a prepaid multiyear agreement with
price protection? etc.)

On the other hand, if you're thinking, "How do I build apps to
run in an AWS or other cloud-as-infrastructure evironment,"
that's a totally different set of skills, obviously...

Regards,

Joe

Disclaimer: opinions above are solely my own