State IT Security Policy and You CHECK 2010

1. State IT Security Policy and YouCHECK 2010 Harvard Townsend Chief Information Security Officer Kansas State University harv@ksu.edu May 26, 2010

2. 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!)

3. 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…???

4. 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.”

5. 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

6. The Players IT 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

7. 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

8. The Players Kansas 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

9. The Players Regents 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

10. The Process 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

11. The Format 1.0 Title 2.0 Purpose 3.0 Organizations Affected 4.0 References (related policies, laws, etc.) 5.0 Definitions 6.0 Policy 7.0 Procedures 8.0 Responsibilities 9.0 Cancellation (policies replaced by this one)

12. 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

13. 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…

14. 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

15. 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

16. 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

17. 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

18. 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

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. 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.”

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

22. 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

23. 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

24. 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.

25. 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

26. 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

27. 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

28. 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’tcomin’ 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

29. 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.

30. Contact Info If you have any comments or questions about state IT security policy, contact me:Harvard Townsendharv@ksu.edu785-532-2985

31. What’s on your mind?