Protecting Sensitive File Data Surrounding the Database

Protecting Sensitive File Data Surrounding the Database

Risk Management: Understanding the New Options in Data Protection for DB2 and Files Ulf Mattsson, CTO Protegrity Ulf T. Mattsson 20 years with IBM Development, Manufacturing & Services Inventor of 20+ Patents Protegrity co-founder Research member of the International Federation for Information Processing (IFIP) WG 11.3 Data and Application Security American National Standards Institute (ANSI) X9 Institute of Electrical and Electronics Engineers (IEEE) The World Scientific and Engineering Academy and Society for Computer Security (WSEAS) Object Management Group (OMG) CORBA Security Service Computer Security Institute (CSI) Information Systems Security Association (ISSA) Information Systems Audit and Control Association (ISACA) 02 September 23, 2009

03 Source of Information about PCI Research http://www.knowpci.com Agenda Compliance aspects for PCI and PII data New security threats Advantages/disadvantages of different data protection options Deploying encryption and tokenization for data security Managing encryption keys across different platforms PCI and real examples Other topics Q&A Compliance & security aspects for PCI and PII data 06

Link to webinar recording https://www2.gotomeeting.com/register/553332458 Why care about database security? In 2008, this [criminal activity] was accomplished by targeting points of data concentration or aggregation and acquiring more valuable sets of consumer information. The big money is now in stealing personal identification number (PIN) information together with associated credit and debit accounts. Source: 2009 Data Breach Investigations Report Verizon Business Online Data Under Attack Not Laptops or Backup Breaches attributed to insiders are much larger than those caused by outsiders The type of asset compromised most frequently is online data: 87% of breaches could have been avoided through reasonable controls Slide source: Verizon Business 2008 Data Breach Investigations Report Assets most commonly breached Table 9. Detailed listing of compromised assets by percentage of breaches and records Asset

Asset Group % of Breaches % of Records POS system Online Data 32% 6% Database server Online Data 30% 75% Application server Online Data 12% 19% Web server Online Data 10% 0.004% File server Online Data 8% 0.1% Public kiosk system Online Data

2% 0.4% Authentication / Directory server Online Data 2% 0.1% Backup tapes Offline Data 1% 0.04% Documents Offline Data 1% 0.000% Workstation End-User System 8% 0.01% Laptop End-User System 4% 0.000% PIN Entry Device End-User System 2%

0.004% Source: 2009 Data Breach Investigations Report Verizon Business How many records breached? Median number of records breached: External Attack: 37,847 Internal Attack: 100,000 Cost of a breach is approximately $202 per record compromised Source: 2009 Data Breach Investigations Report Verizon Business Source: Fourth Annual US Cost of Data Breach Study Ponemon Institute Laws California data breach notification law Adopted in states beyond California Massachusetts privacy laws

Effective date is March 2010 Personally Identifiable Information (PII) Name Social Security Number Address Account Numbers Laws (continued)

HIPAA 164.312 Technical Safeguards (a)(2)(iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information HITECH Act of 2009 Extends security requirements to associate service providers A Simple Risk-adjusted Data Protection Plan 6 Steps to Develop the Plan: 1. Know Your Data 2. Find Your Data 3. Understand Your Enemy 4. Choose Your Defenses 5. Deploy Defenses 6. Crunch the Numbers Step1: Know Your Data Identify High Risk

Data Begin by determining the risk profile of all relevant data collected and stored Data that is resalable for a profit Value of the information to your organization Anticipated cost of its exposure Data Field Credit Card Number Social Security Number CVV Customer Name Secret Formula Employee Name Employee Health Record Zip Code Risk Level 25 20 20 12 10 9 6 3

Step 2: Find Your Data Understand the Data Flow Information in the wild Collection - Short lifecycle / High risk POS e-commerce Branch Temporary information Aggregation - Short lifecycle / High risk Operating information Operations - Typically 1 or more year lifecycle - Broad and diverse computing and database environment

Decision making information Analysis - Typically multi-year lifecycle - Homogeneous computing environment - High volume database analysis Archive Archive -Typically multi-year lifecycle -Preserving the ability to retrieve the data the future is important Where and When is Data Most at Risk? in Step 3: Understand Your Enemy Probability of Attacks Higher What is the Probability of Different Attacks on Data?

Probability Errors and Omissions RECENT ATTACKS Lost Backups, In Transit Application User (e.g. SQL Injection) SQL Users Network or Application/RAM Sniffer Valid User for the Server (e.g. Stack Overflow, data sets) Application Developer, Valid User for Data Administrator Higher Complexity Source: IBM Silicon Valley Lab(2009) Dataset Comparison Data Type Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team

018 019 Choose Your Defenses Where is data exposed to attacks? ATTACKERS Data Entry 990 - 23 - 1013 RECENT ATTACKS Data System SNIFFER ATTACK SQL INJECTION Application MALWARE / TROJAN Database 111 - 77 - 1013

DATABASE ATTACK FILE ATTACK File System MEDIA ATTACK Storage (Disk) Authorized/ Un-authorized Users Database Admin System Admin HW Service People Contractors Backup (Tape) Unprotected sensitive information:

Protected sensitive information Granular Reporting for Compliance & Better Security Application / Database Server Monitoring of Column and User Security Admin Application Database File System Application / Database Server Security Admin Application Database File System X NO Monitoring of Column and User

Top 15 Threat Action Types 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team Top 15 Threat Action Types Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team Protecting the Data Flow - Example Top 6 threat action types - Mitigation Encryption of data in transit Token, Point-to-point encryption (E2EE) or File protection Token or Point-to-point encryption (E2EE)

Monitoring And blocking Abuse of resources Infected systems Monitoring And blocking Collect usernames and passwords Specially crafted SQL statements Web Application Firewall Known usernames and passwords Monitoring And blocking

Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team Step 4: Choose Your Defenses Protect the Data Flow Mitigation at the Right System Layer Data Entry Network 990 - 23 - 1013 990 - 23 - 1013 111 - 77 - 1013 Application Application Application Database Database

File System File System Storage (Disk) Application Storage (Disk) Backup (Tape) Backup (Tape) Unprotected sensitive information: Protected sensitive information Advantages/disadvantages of different data protection options 028

Step 4: Choose Your Defenses - New Protection Models Format Controlling Encryption Example of Encrypted format: Key Manager 111-22-1013 Application Databases Data Tokenization Example of Token format: Key Manager 1234 1234 1234 4560 Application Databases Token Token Server

Data Protection Options Newer Methods Format Controlling Encryption Example of Encrypted format: 111-22-1013 Example of clear text user output: 990-23-1013 Application Databases Data Tokenization Example of Token format: 1234 1234 1234 4560 Example of clear text user output: 5549 9437 0789 4560 Application Databases

Token Server Token & CCN Data Protection Options Traditional Methods Strong Encryption Example of Encrypted format: x%$#..=.(*)& Example of clear text user output: 5549 9437 0789 4560 Application Databases Hashing (keyd HMAC SHA-1) Example of hashed format (SHA-1 = 20 bytes): (#@...&&*..x.....%$#..=.(*)& ) Example of Hashed user output: Application Databases

(#@...&&*..x.....%$#..=.(*)& ) What Is Formatted Encryption? Where did it come from? Before 2000 Different approaches, some are based on block ciphers (AES, 3DES ) Before 2005 Used to protect data in transit within enterprises What exactly is it? Secret key encryption algorithm operating in a new mode Cipher text output can be restricted to same as input code page some only supports numeric data The new modes are not approved by NIST What Is Data Tokenization? Where did it come from? Found in Vatican archives dating from the 1300s In 1988 IBM introduced the Application System/400 with shadow files to preserve data length In 2005 vendors introduced tokenization of account numbers What exactly is it?

It IS NOT an encryption algorithm or logarithm. It generates a random replacement value which can be used to retrieve the actual data later (via a lookup) Still requires strong encryption to protect the lookup table(s) Step 4: Choose Your Defenses Example Point of Sale Collection E-Commerce Branch Office Encryption Information in the wild - Short lifecycle / High risk Temporary information Aggregation - Short lifecycle / High risk Operating information

Operations Data Token - Typically 1 or more year lifecycle - Broad and diverse computing and database environment Decision making information Analysis Archive - Typically multi-year lifecycle - Homogeneous environment - High volume database analysis Archive -Typically multi-year lifecycle -Preserving the ability to retrieve the data in the future is important Direction Scalable Token Solutions Customer

Application Token Server Admin Sever Policy Management Key Management Reporting Customer Application Token Server Customer Application Customer Application

Applications are Sensitive to the Data Format Data Type Binary (Hash) Bin Data Binary (Encryption) Alphanum (FCE, Token) - Text Data Numeric (FCE, Token) Numeric (Clear Text) - No Applications Few Applications Increased intrusiveness: Many Applications Most Applications -

Application changes - Limitations in functionality - Limitations in data search - Performance issues All Applications Data 036 This is a generalized example I I

Field Original Longer Length Step 4: Choose Your Defenses A Balanced Approach Passive Approaches and Active Approaches = End-To-End Protection Database Columns Web Application Firewall Database Activity Monitoring Applications Database Activity

Monitoring / Data Loss Prevention Database Log Files Tablespace Datafiles Database Server Step 4: Choose Your Defenses Cost Effective PCI Encryption 74%WAF 55% DLP 43% DAM 18% Source: 2009 PCI DSS Compliance Survey, Ponemon Institute Step 4: Choose Your Defenses Strengths/Weaknes * * *

Best *: Compliant to PCI DSS 1.2 for making PAN unreadable Worst Step 4: Choose Your Defenses Find the Balance Cost Cost of Aversion Protection of Data Expected Losses from the Risk Total Cost Optimal Risk X I Active Protection I

Passive Protection Risk Level Step 5: Deploy Defenses Matching Data Protection Solutions with Risk Level Risk Level Data Risk Field Level Credit Card Number 25 Social Security Number 20 CVV 20 Customer Name 12 Secret Formula 10 Employee Name 9 Employee Health Record

6 Zip Code 3 Low Risk (1-5) At Risk (6-15) High Risk (16-25) Solution Monitor Monitor, mask, access control limits, format control encryption Replacement, strong encryption Managing encryption keys across different

platforms 042 Step 5: Deployment RACF Applications DB2 Files Encryption Solution ICSF Hardware Security Module Mainframe z/OS DB2 UDB

Central Key Manager Informix System i Oracle Hardware Security Module Key Management Considerations Keys should be cached or stored on the mainframe In a mature solution, the DB2 subtask should not expose the key in a dump of the DB2 master task or User Task DB2 V8+ native column-level encryption has the encryption key in a dump of the DB2 master task

The subtask should only have the key-label, which is not enough to encrypt the data and is meaningless since its only the name of the key The IBM Data Encryption Tool uses DB2 EDITPROC, and a key label is stored in the EDITPROC Key files (ICSF CKDS and other sensitive data sets) should be RACF protected and encrypted Define userids for the started tasks and prevent almost every other id from accessing the DB2 data sets There are some exceptions for administrators who must manage the logs or work with the DSN1* utilities 044 Having separate IDs for each subsystem is the standard recommendation Step 6: Crunch the Numbers Conclusion Risk-adjusted data security plans are cost effective Switching focus to a holistic view rather than

security silo methodology Understanding of where data resides usually results in a project to reduce the number of places where sensitive data is stored Protect the remaining sensitive data with a comprehensive data protection solution Use Case PCI and PII Data Protection Information in the wild Collection POS e-commerce Short lifecycle / High risk Databases often found at collection points Branch Temporary information Aggregation

Short lifecycle / High risk Use the transition as an opportunity to re-key the locks Operating information Operations Mainframe Analysis Archive Typically 1 or more year lifecycle Broad and diverse computing and database environment Wide internal audience with privileges

Decision making information Typically multi-year lifecycle Homogeneous computing environment High volume database analysis Wide internal audience with privileges Archive Typically multi-year lifecycle Preserving the ability to retrieve the data in the future is important Data Security Enforcement 046 46 RACF, ICSF

and hardware data encryption support 047 Data Protection and Encryption on z/OS PCI DSS Applications Mainframe z/OS DB2 API Fieldproc, Editproc, UDF Utility Files

RACF ICSF Encryption Solution Hardware Security Module Evaluation of Encryption Options for DB2 on z/ OS Encryption Interface Performance PCI DSS Security Transparency API UDF DB2 V7 & V8 UDF DB2 V9 Fieldproc

Editproc Best 049 Worst z10 EC CP Assist for Cryptographic Functions (CPACF) 050 Encryption of data in DB2 and files: challenges and solutions 051 Field Encryption Protecting the Data Flow Windows, Unix, Linux, iSeries

File Application Encrypt Fields Crypto Solution File File Central Key Manager Application Mainframe z/OS DB2 Application Decrypt

Fields Crypto Solution Transparent Encryption No Application Changes Windows, Unix, Linux, iSeries Encrypt Database Fields Crypto Solution Application File

File Utility Mainframe z/OS Fields File Crypto Solution Application Encrypt DB2 Central Key Manager Decrypt Fields An Enterprise View of Different Protection

Options Evaluation Criteria Disconnected environments Distributed environments Performance impact when loading data Transparent to applications Expanded storage size Transparent to databases schema Long life-cycle data Unix or Windows mixed with big iron (EBCDIC) Easy re-keying of data in a data flow High risk data Security - compliance to PCI, NIST 054 Strong Encryption Formatted Encryption Token Data Protection Options 3 Use Cases

Can use stored protected value: 1234 1234 1234 4560 Or Kjh3409)(*[email protected]$%^& Need partial Information in clear: Application 1 Application 2 1234 1234 1234 4560 Need full Information in clear: 55 49 9437 0789 4560 055 Application 3 How will different Protection Options Impact Applications?

Application Databases (CCN, SSN ) Can use stored protected value: 1234 1234 1234 4560 Or Kjh3409)(*[email protected]$%^& Need partial Information in clear: Application 1 Strong Encryption Kjh3409)(*[email protected]$%^& Key Manager Application 2 1234 1234 1234 4560 Formatted Encryption 1234 1234 1234 4560 Need full Information

in clear: Application 3 55 49 9437 0789 4560 Token 1234 1234 1234 4560 Token 056 Cipher Token $%.>/ $&# Cipher Text Token Server Application Impact with Different Protection Options

Transparency Type of Application Strong Encryption Formatted Encryption Token Strong Encryption Formatted Encryption Token Can operate on the stored protected value Need partial information in clear Need full clear text information Security Type of Application

Can operate on the stored protected value Need partial information in clear Need full clear text information 057 Application Impact with Different Protection Options erformance and scalability Type of Application Strong Encryption Formatted Encryption Token Strong Encryption Formatted Encryption

Token Can operate on the stored protected value Need partial information in clear Need full clear text information Availability Type of Application Can operate on the stored protected value Need partial information in clear Need full clear text information 058 Performance and scalability 059 3 Topologies: 1. Local SW

Database Server Key Server Local Software Encryption. (native Or 3rd party) VIEW 1 microsecond Local Hardware Encryption Chip 2. Local Hardware 3. Remote Hardware or Software (NAE)

VIEW 1 microsecond IBM CPACF, Sun T1/T2 TCP/IP, PCI bus VIEW Software Agent. (3rd party) 1000 microseconds Network Attached Encryption Remote Encryption (Hardware Chip or

Software) Encryption Solutions: 1. UDF SW 2. UDF NAE 3. ICSF CCF 4. ICSF CPACF 5. PURE CPACF VIEW UDF VIEW UDF EDITPROC

EDITPROC Network Attached Encryption (NAE) ICSF IBM CCF ICSF IBM CPACF EDITPROC FIELDPROC CPACF FILE (CKDS, ) Solution #1 + #5

DB2 VIEW UDF Encryption Function Data Space EDITPROC FIELDPROC Security Policy & Audit Throughput for Encryption on IBM z9-109 Throughput (Transactions Per Second)

2 000 000 - CPACF CPACF + ICSF 100 000 200 1M 16 Test Sample with 3DES, 1 CPU Data Length (Bytes) Throughput: NAE vs. CPACF on IBM z9-109 Throughput (64 Bytes Transactions Per Second) 7 000 000 - CPACF Based Encryption

2 000 000 - NAE/Channel Attached Encryption 10 000 2 4 Sample data from test cases 8 # of CPUs (PUs) General Encryption time for SW vs. HW on z/OS Micro seconds per decryption 400 - SW

Software encryption is very sensitive to the length of the encrypted block Hardware encryption is NOT very sensitive to the length of the encrypted block 30 - HW 318 256 Test Sample with 3DES, 1 CPU Block length (Bytes) Throughput for Database Encryption - UNIX 2,000,000 - Total Throughput Rows per Second

Software / Combination 1,000,000 - 200,000 - 1 2nd Network Attached Encryption Network Attached Encryption 5,000 1 st 10 Sample data from test cases # of

Database Servers 20 Column Encryption Performance - Different Topologies Rows Per Second 1 000 000 CPACF Supported Platforms 1 000 000 100 000 10 000 1 000 Other Platforms Data Loading (Batch) Queries (Data Warehouse & OLTP) Encryption I

I Network Attached Local Encryption (SW/HW) Encryption (SW/HW) Sample data from test cases Topology Generalization: Data Protection Methods - DB2 on zOS Performance High Clear Text Hashing Lookup

Table Encryption With DB2 Editproc (IBM tool) Column Encryption With Tokenizing DB2 Fieldproc (3rd party) Column Encryption With Low DB2 User Defined Functions Separation

of Duties (Security Level) Sample data from test cases Major Topologies for Database Encryption Separation of Duties High Database Server Network Local Call Local Call Database Server Attached Encryption Network

Encryption Server Key Store Local Local Encryption (SW/HW) Database Network Database Server Low Network Network Attached Encryption (SW/HW)

Local Encryption (SW/HW) Key Store Encryption Native Database Encryption Column Encryption Performance - Different Topologies Rows Per Second 10 000 000 Data Warehouse Platforms Mainframe Platforms 1 000 000

100 000 10 000 1 000 Unix Platforms Data Loading (Batch) Windows Platforms Queries (Data Warehouse & OLTP) Encryption I I Network Attached Local Encryption (SW/HW) Encryption (SW/HW)

Sample data from test cases Topology Mature Enterprise Solutions Performance & Scalability Platform Support (Databases & OS) ALL MAJOR Mature Enterprise Solutions Mainframe Teradata FEW Less mature 3rd Party Solutions ONE Point Solutions I I

1 000 10 000 000 Sample data from test cases Performance (rows/sec) Case Study Performance, Scalability & Software vs. Hardware Case Study: Search on Encrypted Column Name Database Server 500 000 Rows Database Server Database Server Database Server

NAE Database Server Database Server Network Network Attached Encryption Service Database Server Database Server Database Server Database Server Sample data from test cases Case Study: Network Attached Encryption Response Time With Network Attached encryption: 500 Second

Database Server Database Server Database Server Database Server Database Server Database Server Network Database Server NAE Network Attached Database Server Encryption Service Database Server Sample data from test cases

Case Study: Protegrity Response Time With integrated Database encryption: <25 Second Encryption Service Database Server Database Server Response Time After Tuning And Indexing: 1 Second Database Server Database Server Database Server Database Server Network Database Server Database Server Database Server

Sample data from test cases Total Throughput for Database Encryption Solutions 2,000,000 - Total Throughput TPS Local Database Encryption Solutions 1,000,000 - 200,000 1,000 - 1 2nd Network Attached Encryption Network Attached

Encryption st # of Database Servers Sample data from test cases Example - Implementation 077 A Security Suite Database (Ora/SQL) Enterprise Security Administrator Policy Management Data Protection System Encryption

Teradata Database Protector Mainframe Application Protector File Protector Key Management Audit Management AS/400 Tape (TD) Threat Management System Gateway Monitor Web Application Firewall

XC (API) A Solution Walkthrough Sensitive Data Collection Points - Shops - Web Cash Register Cash Register $%&# Shop Back Office Shop Back $%&#Office Applications $%&# CCN in file Shop

DB $%&# $%&# High Street Store Log Head Office Polling Server $%&# Policy ESA Policy Policy DB2

` Oracle $%^& Aggregating Platform Log Reports Windows SQL 7ks##@ Financial Institutions Loss Log Prevention *@K$ Security Server

$%&# Log ERP Log Teradata 9#42s Data Log Warehouse Archive zOS Data Protection INPUT DATA CRYPTO FILE UTILITY OUTPUT Defiance DPS for z/OS Cryptographic Services Manager

CRYPTO SERVICES/SOFTWARE CRYPTO HARDWARE POLICY ENFORCE APPLICATION API DATA DB2 APPLICATION POLICY SHARED MEMORY DATA OPEN MVS DB2 POLICY DB EDITPROC

FIELDPROC DB DEFIANCE PEP SERVER HUB CONTROLLER MEMBER SOURCE SERVER ADMIN SERVER LOG SERVER DEFIANCE SECURITY MANAGER 080 A Data Protector for z/OS Support for Triple DES keys (and AES 128, 192 & 256 depending on which Z hardware is used) No Padding also supported Supports multiple data elements

Supports multiple users Can share data elements among tables and/or columns within table Member source server supports flatfile so can use RACF query to build member file DPS for z/OS uses ACEE to find RACF userid for policy enforcement Supports audit log to Protegrity Log Server Single set of servers per LPAR, but supports multiple DB2 regions and/or multiple policies Mainframe Deployment Options Table (Row) Level: Protects data at the table level using DB/2 exit editproc Pros Transparency, performance Cons Audit not as granular, index in clear text Column Level: Protects data at the column level using fieldproc

Pros Column level, transparency, performance Cons Applications using range-search on encrypted columns when used as an index, must be character data Row-Level Encryption Capabilities and Limitations Major limitation: Indicies are not encrypted No ROWID column or LOB column in table is allowed Encrypts/decrypts entire row every time Can be costly for large row Decryption happens for every row accessed during SELECT even if data fails WHERE except when WHERE only uses INDEX Column-level Encryption Using Fieldproc Can only be specified on short string COLUMNs CHAR, VARCHAR Invoked during CREATE TABLE or ALTER TABLE Encryption invoked during INSERT/DB2 LOAD/UPDATE Encryption invoked during comparison except LIKE

Invoked before any other exit Decryption invoked during SELECT/FETCH/LIKE /unload phase of REORG Not invoked when data is null Not invoked for global DELETE with no WHERE Column-level Encyption Capabilities and Limitations Protects data in indices If only one or few columns need protection then only those are encrypted Mutually exclusive with DEFAULT WITH DEFAULT clause NOT allowed Cannot be specified on ROWID or LOB column Columns with those datatypes allowed in TABLE Can be added by ALTER TABLE for new columns No need for unload, drop table, create table, reload as with EDITPROC Column-level Encryption Read FIELDPROC warning about blank comparison in IBM DB2 Admin Guide For retrieval only invoked when column is

needed: so SELECTs that do not use column do not decrypt data Protegrity 087 Corporate Overview Enterprise Data Security Management Founded 2001 300+ customers Market leader in PCI DSS & PII data encryption 100% growth in each of last three years 11 patents granted, 18 pending Global reach 60% NA, 30% EMEA, 10% Asia Protegrity and PCI Build and maintain a secure network. 1. 2.

Protect cardholder data. 3. 4. Protect stored data Encrypt transmission of cardholder data and sensitive information across public networks Maintain a vulnerability management program. 5. Use and regularly update anti-virus software Develop and maintain secure systems and applications 6. Implement strong access control measures.

7. 8. 9. 89 Install and maintain a firewall configuration to protect data Do not use vendor-supplied defaults for system passwords and other security parameters Restrict access to data by business needto-know Assign a unique ID to each person with computer access Restrict physical access to cardholder data Regularly monitor and test networks. 10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes

Maintain an information 12. Maintain a policy that addresses Protegrity and Data Security Management An integral part of technical and business process Security Policy Centralized control Consistent enforcement Separation of duties Robust key management Reporting and Auditing

Organization wide security event reporting Comprehensive compliance reports Alerting Integration with SIM/SEM Risk-adjusted data protection 090 The Protegrity Suite Data Protection System (DPS) Encryption, monitoring, masking, tokenization Database, file and application level Threat Management System (TMS) Web application firewall Enterprise Security Administrator (ESA) Security policy Key management Alerting, reporting, and auditing 91

Recently Viewed Presentations

  • From Neutrality to War - Pre-AP World Geography

    From Neutrality to War - Pre-AP World Geography

    pressed Congress to allocate money to double the size of the army and begin construction of the world's largest navy. won the election by a paper-thin majority on the slogan, "He kept us out of war." ... From Neutrality to...
  • GGE Biplot - Ohio State University

    GGE Biplot - Ohio State University

    GGE Biplot Rebecca Nolan What is GGE biplot? A software program designed by Weikai Yan GGE stands for Genotype main effect and Genotype X Environment interaction Scatter plot that plots both genotypes and environments in the same plot What can...
  • 5th Grade Science Cells to Microorganisms

    5th Grade Science Cells to Microorganisms

    5th Grade Science: Cells to Microorganisms What do we call the basic unit of structure and function in all living things? Cell What do we call a group of tissues that work together to perform a certain function?
  • Linac RF Modulators Status Update Trevor Butler March

    Linac RF Modulators Status Update Trevor Butler March

    D. Wolff. First charge: Create a . New Modulator . Specifications . document. Effort lasted for ~ 3 months. Details can be found at . beams-doc 3979. Presented at PIP-Status Meeting Nov/2011. 3/20/2012. Trevor Butler
  • Sound Devices - Loudoun County Public Schools

    Sound Devices - Loudoun County Public Schools

    Cacophony. A mixture of harsh and inharmonious sounds. In literature, however, the term refers to the use of words with sharp, harsh, hissing and unmelodious sounds primarily those of consonants to achieve desired results. Example: A Forsaken Garden .
  • Kidney disease and the benefits of early detection

    Kidney disease and the benefits of early detection

    Chronic kidney disease and the benefits of early detection . ... > uraemic fetor, fluid overload, hypertension, anorexia, nausea, dyspepsia, pruritis, may or may not have oliguria. ... Kidney disease and the benefits of early detection
  • What were the causes and consequences of the &#x27;Great Leap ...

    What were the causes and consequences of the 'Great Leap ...

    What was the Great Leap Forward? In 1958 Mao introduced a second five year plan which became known as the 'Great Leap Forward' (GLF). He believed it was possible for China to overtake Britain as a leading industrial power within...
  • Translocation How the growing parts of the plant

    Translocation How the growing parts of the plant

    Translocation How the growing parts of the plant are provided with sugar to synthesize new cells Photosynthesis New growth Translocation A system of vascular tissue runs through all higher plants.