State IT Security Policy and YouCHECK 2010

Harvard TownsendChief Information Security Officer

Kansas State Universityharv@ksu.edu

May 26, 2010

Agenda

Why you should care The players The process The format The teeth Integrating state policy with local policy The SRD behemoth Existing state security policies New policies in the works Q&R (question & “response” since I don’t

have all the answers!)2

Disclaimer

#1: All opinions, judgments, assessments, appraisals, sentiments, feelings views, rants, jokes, and brilliant prognostications are mine and mine alone. They do not reflect the opinion or position of K-State, the Board of Regents, RITC, RISC, the state IT Security Council, Governor Parkinson, President Obama, the Republican party, Democratic party, Libertarian party (DEFINITELY not them since we’re talking about govt control!), Tea Party, or God. They’re just my opinion, okay?! Nor are they a statement about the competence (or lack thereof) of any individual, committee, or council, or the efficacy of any process. We’re part of government and that means bureaucracy and we all know that bureaucracy and efficiency are normally not mentioned in the same sentence.

#2: This applies to state-funded institutions that are therefore considered state agencies. Private institutions are not accountable to the state IT security policies. Community colleges…??? 3

Why you should care

Exemptions for Regents are a thing of the past The good old days:

“3.0 ORGANIZATIONS AFFECTED: All branches, boards, commissions, departments,divisions and agencies (excluding Regents Institutions) of Kansas state government, hereafter referred to as Entities.”

Present reality:“3.0 ORGANIZATIONS AFFECTED:  All branches, boards, commissions, departments, divisions, and agencies of Kansas state government, hereafter referred to as Entities.”

4

Why you should care

So, these policies do apply to any state institution and all employees thereof. Private schools and other non-government entities may leave the room now….

Policies do typically reflect best practices so is reasonable to follow them.

You don’t want to have to explain to the legislators in JCIT or your institution’s executive administration why you ignored a policy

5

The PlayersIT Executive Council (ITEC) Ultimate authority for state IT resource management, including

policies 17 members:

Chaired by Duane Goossen, Secretary of the Dept. of Administration

CITO of each branch of government CITA is non-voting member 2 cabinet-level agency heads, 1 non-cabinet Director of Budget Judicial Administrator of the Kansas Supreme Court Executive Director of the Board of Regents Commissioner of Education 1 representative of cities, 1 rep of counties Network manager of INK 3 reps from the private sector who are CEOs or CITOs

6

The Players So the Regents have one vote on ITEC even though we

have a substantial portion of the state’s employees and certainly when you add students, a significant percentage of the users of state IT resources. Also, that vote is by the CEO of the BoR, not someone with IT expertise

How well do ITEC members understand and respect Regents’ interests, esp. the private sector reps (currently from Westar, Kansas Farm Bureau, and KIPHS, Inc.)?

ITEC meets four times a year, which includes voting on IT security policies; they have the final say on policy

Seems to be little support in current ITEC for treating Regents institutions differently

See www.da.ks.gov/itec for more information 7

The PlayersKansas IT Security Council (ITSC) Operates under the auspices of ITEC “Recommends and reviews policies, guidelines, and best practices

for the overall security of IT systems, infrastructure and data within Kansas state government.”

25 members (only 18 specified in original charter), typically IT staff with security responsibility from major state agencies

Regents institutions have 1 rep (yours truly) and the Board of Regents office has 1 rep (Steve Funk)

Sherry Callahan from KU Med participates as a non-voting member Regents rep rotates through RISC, as determined by RITC Charter available at

www.da.ks.gov/itec/Documents/ITECITPolicy7300.htm

Larry Kettlewell, state of Kansas Chief IT Security Officer Chairs ITSC Oversees IT security program for state agencies

8

The PlayersRegents IT Council (RITC) Official council of the Board of Regents CIOs of each Regents university + KU Med Meets monthly, discusses IT issues of common interest, reviews

state IT security policies

Regents IT Security Council/Committee(?) (RISC) IT security officers from each Regents institution, including

community colleges Provides Regents rep. to ITSC, as designated by RITC Advises RITC on IT security matters Meets quarterly, discusses IT security issues of common interest,

advises RITC on state IT security policy

IT Advisory Board (ITAB) Advises ITEC and executive branch CITO Consists of CIOs of major state agencies Meets monthly to discuss IT issues of common interest Also reviews state IT security policies 9

The Process

10

Security policies proposed to ITSC; can come from any source, such as CITOs, but are typically drafted by ITSC members

ITSC debates, haggles, argues, arm wrestles, compromises, and edits the proposed policy to produce the first draft

Larry Kettlewell sends the draft to RITC and ITAB for review/comment

Revisions discussed with ITSC if needed ITSC votes to recommend policy to ITEC Kettlewell presents policy to ITEC who votes to approve

or not If approved by ITEC, is published on ITEC policy web

site by the KITO

The Format

1.0 Title2.0 Purpose3.0 Organizations Affected4.0 References (related policies, laws, etc.)5.0 Definitions6.0 Policy7.0 Procedures8.0 Responsibilities9.0 Cancellation (policies replaced by this one)

11

The Teeth

What are the consequences of ignoring these policies? Hmmm….

Policies do not have an “Enforcement” or “Sanctions” section

Two-fold consequence: Ignoring security policy and best practices puts

your institution at risk and potentially others outside your institution/agency

Political pressure from JCIT and other legislators, CITOs, Governor, BoR, COPS/COBO/COCAO, and of course the media

12

Integration

Consider the state policies as you develop your own; use them as a guide along with industry standards

In some cases, agency/institution policy must be at least as stringent as the state policy, like ITEC policy 7230

Others, like the media sanitization policy (ITEC policy 7900), merely say the agency must have their own policy and include very little in the way of specific requirements

If your institution is considering writing a new or updated comprehensive IT security policy, I suggest you wait until the SRD is revised…

13

The Infamous “SRD”

SRD = “Security Requirements Document”, a revision to the security requirements outlined in ITEC policy 7230A

Developed by contractor last year with state government agencies in mind – NOT the Regents institutions

Based on NIST 800-53 and the previous 7230A Approved by ITEC and published in January 2010 Fortunately, the exemption for the Regents

remains in ITEC policy 7230

14

The Infamous “SRD”

Is designed to be a comprehensive set of IT security requirements; an agency IT security policy must be at least as stringent as these requirements

If an agency does not have its own IT security policy, then 7230A is their default policy

Consists of five documents: Security Requirements Document Mandatory Procedures Mandatory Baselines (think of them as standards) Non-Mandatory Procedures Non-Mandatory Baselines

15

The Infamous “SRD”

Regents institutions had significant concerns with the policy, many stemming from the fact that universities and our student populations, research endeavors, and prolific distance learning efforts were not considered

RITC and the BoR contracted with a consultant familiar with higher ed to revise the document to be more compatible with our environments

Expectation is for this revised security policy to be the baseline for Regents institutions; may be adopted by other state agencies as well

First draft of the revised SRD just delivered to RITC this week. Hope to work on the other four documents in the fall

16

Issues with 7230A

Is still a one-size-fits-all policy (will talk about variances in the next slide)

Doesn’t sufficiently address different security classifications of systems (designed for medium security system)

Still concerned that there’s not sufficient consideration given to the uniqueness and complexity of our campus environments, esp. by ITEC

Amounts to an unfunded mandate to implement the security requirements, which is particularly disconcerting when you consider the shrinking percentage of our budgets that come from state funds

Is based on NIST, which complicates compliance for institutions that adopted a different IT security standard, like ISO 27000 series

The required annual security self-assessment tool does not match the revised 7230A – needs to be revised and then consider whether the Regents will have to use it (a very time-consuming process to do the self-assessment)

But, we want to cooperate and make it work, hence the significant effort and expense put into creating a revised security policy that’s palatable to the Regents 17

Policy Variance

The SRD is a one-size-fits-all comprehensivesecurity policy; the problem is one size can’t fit all given the diversity among state agencies, esp. when you consider the Regents institutions and our student populations

Hence there’s a need for formally granting a variance if a given security requirement can’t be achieved as written in the SRD due to: Doesn’t apply in your environment The cost in terms of $$ or resources is prohibitive Risk is mitigated in another way The risk is determined to be acceptable

Good example is the 30/60/90 day password change requirement

Can’t simply ignore security controls – must assess the risk, including risk to others outside your agency/institution

18

Policy Variance

Proposed variance language for ITECpolicy 7230, adding section “6.4 Policy Variance “:----------“An agency head or designee may grant a variance for specific security requirements that cannot be achieved by the Entity and for which the level of associated risk is acceptable to the Entity. Potential impact on others outside the Entity must be considered in the risk analysis. Such variances must be treated as confidential, include the justification for the variance, and be kept on file at the Entity along with the Entity's IT Security Policy.”

19

Policy Variance

Proposed variance language for ITECpolicy 7230, adding section “6.4 Policy Variance “:----------“An agency head or designee may grant a variance for specific security requirements that cannot be achieved by the Entity and for which the level of associated risk is acceptable to the Entity. Potential impact on others outside the Entity must be considered in the risk analysis. Such variances must be treated as confidential, include the justification for the variance, and be kept on file at the Entity along with the Entity's IT Security Policy.”

20

Existing State IT Security Policies

Listed in section 7000 of ITEC’s “IT Policies & Guidelines”:www.da.ks.gov/itec/ITPoliciesMain.htm

21

Existing State IT Security Policies

7220 KANWIN Security Policy – Does not apply to Regents since pertains to KANWIN network managed by DISC

7230 Enterprise Security Policy – Regents currently exempted, but that will probably change

7230A Default Security Requirements – Security requirements referenced by 7230 so Regents exempted for now; Regents are working on a revision that’s compatible with our environments

7300 IT Security Council Charter – Establishes Regents representation on the ITSC

7310 IT Security Self-Assessment – Regents have our own procedure and report results to the BoR office rather than state CISO

22

Existing State IT Security Policies

7320 Computer Incident Response – Regents NOT exempted, but section 6.5 specifies that Regents institutions report incidents to BoR CEO and CIO within 24 hrs of a “major security incident.” They in turn report to the state CISO and executive branch CITO. That procedure was recently revised where we now also notify the state CISO (Larry Kettlewell) and CITO (Joe Hennes) directly

7320A IT Security Reporting Protocols – Regents NOT exempted; procedures for reporting incidents, including classifying the incidents

7400 Computer Security Awareness and Training – Regents NOT exempted; extensive requirements for training ALL employees annually and tracking the training

7400A Security Awareness Requirements – Regents NOT exempted; details on the training, including topics that have to be covered

7900 Enterprise Media Sanitization – Regents NOT exempted; each agency/institution has to establish policies and procedures for sanitizing media before reuse or disposal; Regents are to follow NIST 800-88 “or an approved established industry best practice for higher education technical environments or institutions.”

7900A Media Sanitization Validation Form – Regents can develop own form

23

Pending State IT SecurityPolicies

Remote Hosting Policy (aka “Cloud Computing Policy”)

Policy for Social Media Technologies Portable Electronic Device/Media Encryption

Policy Expect to vote at the June 10 meeting on the

update to ITEC 7230 for granting variances Annual security self-assessment tool still needs a

lot of work to match the new 7230A security requirements; has to be done by August; unclear whether Regents will have to use it.

24

Remote Hosting Policy

Designed to help ensure that the quality of service and security of information is maintained when an application, service, and/or data is hosted by an external vendor

Definitions a challenge – what is “the cloud” vs. a simple remotely hosted application vs. outsourcing?

The policy was originally passed by ITSC last winter, but retracted before it went to ITEC because ITSC (yes, the same group that originally voted in favor of it) decided it was too restrictive and not workable for many agencies

Only two dissenting votes in original vote were from the Regents

So it was sent back to the drawing board for revision; first draft of revision presented to ITSC in May; will discuss further at June 10 ITSC meeting

25

Remote Hosting Policy Highlights (lowlights?):

Perform a risk assessment based on data classification/sensitivity before entering into the contract (but unfortunately does not require security controls commensurate with data classification/sensitivity)

Seeks to ensure the security of the hosting infrastructure (lots of specific requirements, plus showing evidence of security audits and/or vuln assessments)

Asks for information from the prospective vendor that many of them may not be willing to divulge

Hosted data must physically reside in the U.S. (could be problematic given the nature of “the cloud”)

Extensive reporting requirements for the vendor Breach notification requirements were removed in the latest draft

(??!!) Service level expectations also removed Does not address media sanitization at the end of the contract Does not address data ownership

26

Remote Hosting Policy MY OPINION – it is still far too restrictive and

therefore too much of a barrier, esp. in this time of tight budgets where remote hosting may provide significant cost savings

The remote hosting train has already left the station in higher ed and we’re not going to bring it back

I wholeheartedly agree that remote hosting may add risk and data security must be addressed to reduce the risk to an acceptable level

Need to have boiler plate language to include in bid specifications and contracts

27

Social Media Policy

Provides guidance for agencies and employees in the use of social media when conducting state business

State agencies much slower to adopt social media than higher ed – this is another train that has already left the station and ain’t comin’ back

Use by employees must be professional and consistent with state/agency policies

Addresses personal use vs. work-related use Does not address the student perspective Policy is general enough to allow creative use in higher

ed Currently in draft; will be discussed at June 10 ITSC

meeting, then sent to RITC for comment

28

Portable Device/MediaEncryption Policy

Designed to protect sensitive data on portable media/devices

Sensitive/confidential data, as defined by the agency’s data classification policy, must “be encrypted while at rest on portable electronic media/devices”

Controversial provision: have to label/mark devices/media to indicate “distribution limitations, handling caveats, and applicable security markings of the information stored”

Requires procedure for recovering encrypted data if the key is lost, destroyed, or changed

RITC has already reviewed it. Revised draft will be discussed at June 10 ITSC meeting and probably voted on.

29

Contact Info

If you have any comments or questions about state IT security policy, contact me:

Harvard Townsendharv@ksu.edu785-532-2985

30

What’s on your mind?

31