Yale Universitys Information Security Design Review Process for

Yale University's Information Security Design Review Process for Applications March 11, 2009 8: 30 a. m. - 9: 20 a. m. Room 552 A H. Morrow Long Yale University, ITS morrow. long@yale. edu 1

Copyright H. Morrow Long 2009. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author. 2

Credits • Security Design Review Contributors – Allison Mac. Farlan (was at @Yale now @CMU) – Beth Byington (Sr. Information Security Officer) – Faith Mc. Grath (Compliance Officer) – Joyce Lush (Dir. Institution Specific Systems) • Security Design Review Participants – Yale staff (particularly in ITS Enterprise and Production Systems) improved the process. • Wordle Graphics – purpleslog@flickr. com & http: //wordle. net/

Abstract Yale University's IT Security Design Review is a formal methodology and process for assessing applications that are proposed or in the acquisition or early design phase. The initial criteria for assessment were new projects critical to the university or those with restricted and/or confidential data. Now major upgrades or existing systems and systems outside central IT may also have security design reviews. 4

<INSERT OBLIGATORY PROFOUND QUOTES ON THIS SLIDE> “The security business has no future. ” “The security industry is flying by the seat of its pants. Security infrastructure has been dictated by the bad guys… as new threats arise, we put new products in place. This is an arms race we cannot win. ” “Security companies must sell their customers solutions that assume ‘everyone is infected’ so that they can safely do business, which makes a business sustainable” -- Val Rahamani, GM for IBM ISS, RSA Conference 2008

Overview • Pre-History • Evolution: Yale Security Design Review – A Format – A Formal Process – A Formality • Current State • Lessons Learned • Future State

Pre-History • Applications used many IT technologies. • Often applications used local authentication. • Confidential data stored and displayed as less sensitive and critical data (e. g. transactions). CC #s on receipts, SSNs on pay stubs!! • Applications rarely reviewed for information security considerations. • Protection not required by law/industry (just FERPA)

Antiquity (Before the SDR era) • Meetings with Information Security (often just before “go live” launch dates) were ad-hoc. • Assessment queries were not from a standard checklist. • Every analysis of an application’s security was different. • Most applications escaped a security analysis.

Why do a Review? Gov’t Regulations and Industry Requirements Credit: Purple. Slog and http: //wordle. net/

Why do a Review? UCLA’s Big Breach December 12, 2006 - UCLA announced that a “computer hacker” illegally accessed a UCLA database and UCLA began notifying approximately 800, 000 people whose names and certain personal information were in the database. This database contained certain personal information, including Social Security numbers, dates of birth and home addresses, regarding current and some former UCLA students, faculty and staff, some student applicants and some parents of students or applicants who had applied for financial aid. SSN #s for 28, 600 people in the database (5%) were illegally retrieved. UCLA began notifying them on Jan. 10, 2007. 6/7/2021 Source: www. identitytheft. ucla. edu

Why do a Review? February 2007 • Presentation on Application Security to ITS Enterprise Systems staff which covered UCLA’s data breach and effective methods of securing Applications including performing Security Design Reviews. • ITS ES Director Chris Kielt (now Deputy CIO) at the meeting asked that we do it. • I began to ponder what to do (should go into a Security Design Review).

Security Innovations 5 Step Action Plan to Secure Software 1. Threat Modeling 2. SDRs (Security Design Reviews) 3. Get Developers Security-Savvy 4. Penetration Testing 5. Final Design Review 6/7/2021 ITS Enterprise Systems Talk

Protecting against application security vulnerabilities • All project phases: “Bake” (design) security in (better early in the SDLC) • Design phase: Application Security Reviews • Coding phase: Peer code reviews and code scanning tools • Testing phase: test plan with security test coverage cases • Before Final Acceptance & Implementation phase: – manual and/or semi-automated penetration test – automated application assessment tools? 6/7/2021 ITS Enterprise Systems Talk

6/7/2021 ITS Enterprise Systems Talk

The problem: Application Security • “ 64% of developers are not confident in their ability to write secure applications. ” – Microsoft Developer Research

The problem: Application Security “Over 70% of security vulnerabilities exist at the application layer, not the network or system layer. ” – Gartner 2004 -2006 The National Institute of Standards and Technology (NIST) claims this number is 92%

The problem: Application Security How much $$$ & effort were we focusing on Application Security?

The problem: Application Security 6/7/2021

How to design a Security Design Review? • Use established standards. • Use government or industry regulation requirements (e. g. HIPAA or PCI). • Steal or borrow someone else’s. – Military – Government – Other higher Ed institution • Hire a consultant.

IT Security Standards The nice thing about standards is that there are so many of them to choose from. -- Andrew S. Tanenbaum • NIST 800 & FIPS • ITIL • SSE-CMM • FISMA • CIS • COBIT • CAG V 1 • ISO 27001 -2 • OCTAVE

“If you have ten thousand regulations you destroy all respect for the law. ” -Winston Churchill

IT Compliance Regulations Many enterprises create industry-regulation specific information assurance programs. We did with policies (w/HIPAA) and a bit in the SDR. • FERPA • HIPAA • Sarbanes-Oxley • GLBA • MA 201 CMR 16&17 • PCI 1. 1 & 1. 2 • CA SB 1386 • FACTA • FDA 21 C. F. R. Part 11

Evolution of the Yale SDR A Form • Created from several Info. Sec checklists (“throw something on the wall –a strawman”) • Editable Word Document – later ‘locked’ • Refined over time by several individuals. • Multiple alternate sections designed for different technical architectures & application models: – Custom programming and local hosting – Shrink-wrapped and vendor-supported systems – ASP and Saa. S

Evolution of the Yale SDR A Format • Initially we set up just one meetings and brought a printed copy of the SDR form. • At times we would attempt to edit the Word document (with the answers) in real time. • We realized that we could not accomplish what we needed in one meeting. • The staff we were questioning asked for the form so that they could take it to vendors and technical staff to fill out before meeting us.

Evolution of the Yale SDR A Formal Process • We posted the SDR form Word doc online. • We set up a standard block of meeting time (Friday afternoons) with signup slots for projects. • We set up the initial criteria for new applications which should have a Security Design Review: – Should be Enterprise Systems projects/applications – Store or handle confidential/sensitive information. – Or are highly critical to the University. • We hired an IT Auditor type and gave her the additional responsibility to track open SDRs.

Evolution of the Yale SDR A Formality • Many improvements to the SDR form. • We now do reviews of non-Enterprise Systems and even non-ITS applications such as foundational systems (PGP, web technologies) • We have expanded the definition of ‘critical’ as well as the scope of confidential/sensitive data. • We have a streamlined form for Security Design Reviews of applications built on top of a vetted middleware/framework platform layer.

Web Application Security Credit: Purple. Slog and http: //wordle. net/

Gov’t Regulation and Industry Requirements – HIPAA was our first major IT Compliance effort. Credit: Purple. Slog and http: //wordle. net/

Operating System Security Credit: Purple. Slog and http: //wordle. net/

Firewalls and Network Security Protection Credit: Purple. Slog and http: //wordle. net/

Application Review: General Security Questions • Data Classification – What kind of Data is being made available by the application • Restricted/confidential/protected content? – Is the fully-assembled dataset in one place? • Fields displaying records from many sources? • Summarized in one place? – Establish whether any of the data in this application is governed by federal or state regulations. • HIPAA, FERPA, GLBA, VISA/CISP

Application Review: General Security Questions Roles and Responsibilities 1. Who’s the Client (designated contact person)? 2. Who are the data owner(s)? 3. What are the general roles related to access control (e. g. we assume that users and administrators have roles; they’re not logging in as root). 4. Who manages the hardware and OS? 5. Who is the application owner? 6. If either of #4 or #5 are non-Yale entities, are appropriate licensing agreements with appropriate security language implemented? If either #4 or #5 are non-ITS staff (departmental) is there appropriate ITS oversight? 7. Does this need to be registered as an ‘above threshold’ system?

Application Review: General Security Questions Roles and Responsibilities, continued • Access control for non-Yale individuals or vendors? – Need to document and audit vendor access controls – Need appropriate legal agreements (e. g. , BAA, MOU etc. , ) – If vendor has logon privileges, document why

Application Review: General Security Questions • Dependencies: what’s the data riding on? – Document data flow – Web, database, vendor proprietary application, etc? – Or managed by ITS, and with what subordinate applications? • Scale – Size of record base – Number of servers/systems – Frequency of calls to CAS • Audience – Who accesses the application and how (campus and remote) is this secured?

Application Review: General Security Questions • Business Criticality – How terrible is this if it goes down (to department, to Yale)? – How monitored, besides Big. Brother? – Is a documented/tested Contingency Plan (Backup; EMO; DRP) required? • All new technology? – In house training necessary? Who needs training? – Info. Sec may need to look at specific security requirements for brand-new usages; may need periodic review. • Proposed Timetable for implementation – Has the model (these applications together, etc. ) been tested on a small scale at all?

Application Review: Next Steps • Determination of data classification leads to recommendation for network placement. • Application providers develop architectural diagrams and documentation of application and data flow. • Application developers conduct tests on non-production machines using the basic roles and document the results. • Infosec audits the test implementation. • The process for security reviews and audits is integrated into change management. • Production implementation starts.

Current State – SDR Metrics • 26 Completed • 33 In Progress • 6 Discontinued • 65 Total • Approximately half have Medical data 38

Current State – Help for IT Staff • Presentations to IT Developers • Two Articles in the ITS Monday Morning News (internal IT staff news) • Documentation based on the above posted on the Web: http: //security. yale. edu/sdr/ 39

Current State – Help for IT Staff • What is a Security Design Review • Why Do we Need One • Regulatory Laws that have Risks we Examine For • Who and How is it Done • Why Do We Need to Meet • Why Use Diagrams • Application Structures • Testing Compliance • Things to Consider 40

What is a Security Design Review? • Consolidated listing of the security compliance requirements • Represents the minimum compliance requirements for the operation in the Production environment • Integrated with Yale IT Assurance Policies • Covers Physical, Telecommunications, Network, System, Platform, Database, Application, Data, and Operations Security, and Data Privacy

What is a Security Design Review? There a couple of main parts to the review: – Identify what the application does. Document how your application is supposed to be used. This also helps you determine how it can be misused. – Identify the technologies. This helps you focus on technology-specific threats later in the process. It also helps you determine the correct and most appropriate mitigation techniques.

Why? • The aim is to reduce overall security risks • Design new systems ensuring there are controls based on the protection of the information within the application for: – Identification and Authentication – Authorization and Entitlement – Information Integrity – Information Confidentiality – Availability (Production Reliability)

Why? • Identify and evaluate threats to an application • Identify mitigating controls • Assess the adequacy of the control environment • Identify gaps where controls and reporting are better needed to manage critical risks • Determine future organization and infrastructure needs to enable management of critical risks (and other risks identified by management)

Regulatory Laws Universities have a highly regulated business – Health Insurance Portability and Accountability Act – Gramm-Leach Bliley Act – Controlling the Assault of Non-Solicited Pornography and Marketing Act – European Data Protection Directive – The Children's Online Privacy Protection Act – California SB 1386 (Database Security Breach Notification Act, which has been enacted in several states in addition to California) 45

Regulatory Laws We must assess each application/system against a variety of risks: – Compliance to local Policies – Regulatory requirements – Operational – Reputational – Technology and Data Security 46

Who and How is it Done • These reviews are done with the business and/or information owner and the technical personnel to: – Complete an assessment of the business risks associated with the exposed system. – Document security requirements during the design and engineering of the system or application, based on the risk. – Ensure external communication interfaces between Yale systems and the user will be secured through the use of network or Internet security mechanisms to reduce the risk of loss of continuity, data integrity, or data confidentiality

Who and How is it Done • Information Assurance and Compliance will develop security controls that are specific to the system or network component in question. • Require Vendor Compliance – Contract Language – SAS 70 Type II reviews 48

Why Do We Need to Meet? • Helps everyone to understand where the product is most vulnerable • Expand understanding of known risks • Dialogue among participants is critical to achieving success • Each participant has different exposure levels to various risks given their job responsibilities. 49

Why Do We Need to Meet? • SDRs can also be used as a training tool for both Security and other personnel – Allows people to provide new input about security vulnerabilities, issues, & improvements to the ISO area • Communication Includes Listening – Listen with the intent to understand – Have them explain things and repeat if necessary until you truly understand 50

Why Use Diagrams? • Data flow diagrams are a useful tool to see only the key components of an application. • Focus on the scope of the application not functional details. • Analyze the data flow between different subsystems. Paying attention to data transfer flows from one boundary to another, especially where the trust levels are different. • Identify all entry points to your application as they are potential routes for attack. 51

Application Structure • Applications will use standard components which already exist within the environment. • Applications will be designed and/or implemented using standard network service protocols so that they interoperate effectively with other applications, systems, and networks components. • Applications will be developed to operate at the lowest system privilege (Least Privilege) needed to complete its functions, and will not be implemented or designed to run exclusively at Root / Administrator level. 52

Application Structure • Application developers will not create: – Additional – Overlapping or – Unneeded access control structure within applications, – but will rely in the Yale infrastructure for basic user identification and authentication. • Applications will be developed using controls that protect both the application and the data stored and transmitted from it. 53

Testing Compliance • Never assume that because we told someone what or how to do something, they understood • Scanning is done with a variety of tools (Nessus, MBSA, etc) for highly sensitive servers – Identifies other configuration security items not mentioned in the design review 54

Things to Consider • Risk is a fact of life; life is constantly changing and is uncertain. • Today’s economy requires companies to identify and respond more quickly to changing risk profiles. All management is responsible for risk management. • For risks that have not been defined/assigned, risks can “slip between the cracks” and/or be managed inconsistently due to individual perceptions of the significance of the risk. • With new systems there could be a retirement of an older system. Ensure that system resources are removed from Yale networks, along with Yale information, and physical property is properly disposed. 55

Security Advice & Recommendations Remove unneeded data or encrypt. Diagram & Document. Plan for Bad Guys & disasters. Use standards & our reference architecture. 6/7/2021

Lessons Learned • Meeting Management – scheduling, protocol, planning • Time Management – Keep track of the process and progress • • Be flexible. Be creative. Be understanding and personable. The ‘perfect’ is the enemy of the good… We still need metrics on how the SDR has (assuming it has) improved security.

“If you have ten thousand regulations you destroy all respect for the law. ” -Winston Churchill

Meetings 2 are best: 1. Initial 2. Implementation/Test (Pre-Deployment) ☛ Send latest docs to attendees well before. ☛ Only invite relevant & knowledgeable staff. ☛ Designate a note-taker to capture punch list of “fix” items left “to do” ☛ Only discuss empty or concern-raising items ☛Prepare to conclude & sign-off.

Tempus Fugit The SDR process can take time. So can planning and design by developers on a major project. Don’t stall projects unnecessarily.

Future State – 3 Lock Data

Data Classification Levels @Yale One-Lock Data is public data. Two-Lock Data is Yale. Confidential, not protected by law or regulation. Three-Lock Data is critical and/or protected by law, regulation or contract.

Future State • Adapt to ITIL and Accenture Delivery Methodology (ADM) Service Introduction Processes. • More Automation: – IT Risk Assessment & Compliance tool(s) – Software to track/report SDR progress. – Increased use of Commercial Web Application Vulnerability Assessment Software

Vulnerability Assessment Tools

Accenture® ADM SDLC P L A N Initial Meeting A N A L Y Z E D E S I G N B U I L D T E S T Final Meeting D E P L O Y

Culture Shock - Job Posting http: //www. cs. yale. edu/Internal/job-posting/gra. pdf. This position entails several tasks associated with modifying, and some new programming, of a website for an NIH sponsored web based study of care-seeking during heart attacks, or acute coronary syndromes episodes. The website is currently written in PHP and needs to be modified to comply with Yale Security Design Review. New programming tasks will require developing the linkages between the website data output and a data base …

Culture Shock - Job Posting … 16 hours per week or on an hourly basis. Pay per hour: $13. 00 Office work space and computer are provided. Skills necessary: … A commitment of at least one year is necessary. Please contact: A…. . . A……. Research Scientist Yale University School of Nursing

Questions? 68

What did you think? • Your input is important to us! • Click on “Evaluate This Session” on the Mid-Atlantic Regional program page. • Presentation available at: http: //net. educause. edu/NC 09/1020252 Contact Morrow at : morrow. long@yale. edu

This has been a chalk outline™ production.