integrating information protection into data architecture & sdlc

Integrating Information Protection into Data Architecture and SDLC

Closing hidden gaps in your Software Development Life Cycle where Data

Governance is often absent

David Schlesinger CISSP Senior Security Architect [email protected] Author of The Hidden Corporation A Data Management Security Novel

Dataversity Webinar 11 December 2011

Real Headline:“Protected Patient Data Increasingly Being Lost, Stolen”

By Cole Petrochko, Associate Staff Writer, MedPage Today Published: December 01, 2011

• Nearly all healthcare organizations responding to a survey -- 96% -- reported that patient or related information has been lost, stolen, or otherwise compromised within the last two years.

• The number of data breaches involving protected health information rose by 32% from 2010, according to data published by the independent privacy and data protection group the Ponemon Institute.

• Three out of 10 respondents (29%) said a data breach resulted in medical identity theft -- up 26%.

• Two out of five respondents (41%) blamed data breaches on employee negligence -- not following data-handling procedures, sloppy mistakes, and using unsecure electronic devices -- and 49% reported lost or stolen devices.

http://www.medpagetoday.com/PracticeManagement/InformationTechnology/29962

[email protected] The Hidden Corporation 2

http://www.medpagetoday.com/PracticeManagement/InformationTechnology/29962

A Few Key Points from The Hidden Corporation

• Many Software Development Life Cycles (SLCD):

– Are designed sequentially when critical processes should occur in parallel

– Skip all data information categorization steps until the end

• This results in hidden governance gaps, inconsistent data protection, and reduced enterprise agility.

• Correcting this problem:

– saves money,

– saves time, and

– reduces corporate risk.

[email protected] 3 The Hidden Corporation

We are still in a Transition from a Legacy Data Environment

1. We only used “our” information within “our” department

2. Information lived in locked file cabinets in private offices.

3. Local control was the best way to safeguard information –even on the Mainframe.

4. External laws did not impact how we kept business information.

5. We were not continuously connected to the global Internet.


Data Sensitivity Ignorance Usually Creates Regulatory Problems and Data Loss


CEO

Finance

Billing Mgr.

Employees

Shipping Marketing

Research Sales Mgr.

Sales Staff

Consultant

Private Data

Ethnicity Data

Private Data from Data Warehouse

Data that is highly restricted in one department can sometimes be easily copied to laptops in another.

Typical Data Governance Gaps


Business sees Data Regulatory

Compliance as a distraction from their “real work” and depends on Access Security

and Legal to govern sensitive data

content

Access Security views Data Regulatory

Compliance as a “business

responsibility” and depends on the

Business to govern user data content

Data Analysts are certain the

Business, the Legal team, and Access Security folks know which

data content is “supposed” to be

authorized to each user

Legal team defines “risk” to

the business groups and

provides requirements to comply with data

regulations in their local areas

of control

“Design for Compliance” = A Typical Data Governance Process Method*


Map Business Process

Assess Risks

Classify Data

Design Roles

Design & Operate Controls

Manage Change

Inventory Controls

*Note that it shows the project team classifying their data after they have assessed risks and put in controls. This assures re-work after product launch, failed compliance audits, and lost data later. (See slide 3)

The data governance methodology shown below was presented at a large conference as a way to ensure secure application development and regulatory control.

The Missing Parallel SDLC Processes


Define all Business Data used

Identify & Classify all Regulated Data

Link data Classification To Actions

Identify Sensitive User Entitlements

Enforce user Controls at Authorization Decision time

Perform Compliance Audits

Link Data to Compliance Actions

Most software methodologies assume that magic happens and everybody knows which data is sensitive to regulations

Each Data Type Links to Laws and

Compliance Actions

This step is local, informal, and often the authorizing manager is uninformed of data sensitivity and policy

This Step often skipped due to lack of an inventory of the data actually exposed in each User Entitlement

Data Architecture for Data Protection Identifies Regulated

Information and maps its location

Map Business Process

Assess Risks

Design Roles

Design & Operate Controls

Manage Change

Inventory Controls

Classify Data

Two Separate Steps + New Concept: Entitlement


Define all Business Data used

Identify & Classify Regulated Data

Link data Classification To security Actions

Identify the Sensitive User Entitlements

Enforce Controls at Authorization Entitlement Decision

Perform Compliance Audits

Link Data to Compliance Actions

Identify the sensitive data in each individual view to determine its sensitivity. That determines the

Entitlement’s action requirements.

1. A manager makes an Entitlement Decision about giving each user initial access Authorization.

2. The ability for a worker to access the data in a view thereafter is granted by an Authorization based on that Entitlement.

* A few data regulations require specifically defined controls for named data types.

Conceptual Process Model for Regulatory Compliance at User Entitlement Time


Define your Enterprise information

and assign its Regulatory and

Security Sensitivity

Link each regulatory Family to corporate

compliance policies

Policies for data Storage

Policies for user Access

Audit trail of actions fulfilling

the policy

Manager decides if worker is

Entitled to the data

Entitlement Decision

becomes a user Authorization

Actions for data Storage

Actions for

user Access

Audit trail of actions fulfilling

the policy

Nancy Discovers that “Regulatory Family” is Not the Same as a “Security Classification”

• A Security Classification tells people how sensitive the data is to the company. The approver needs to trust the employee; and the worker must have a “Need to Know”.

• A Regulation has nothing to do with trusting people. It tells the company how to protect the information and to which workers it may be legally exposed – little more.

• Regulations add the new rule of “Allowed to Know”

• Information can have only one security classification but may belong to several regulatory families.

– Apples and Oranges.


Key Learning: Most Data Regulations have Similar Requirements and fall into a Few Families


Personally Private

Information US & EU

Sarbanes-Oxley & Insider

Data

Trade Secrets &

Competitive Information PCI Data

and California Statutes

Industry Specific,

FDA, GLB, Ctech, etc.

Future Plans –

Mergers & Divestitures

Regulations often overlap, are redundant, give the same instructions, tell you to do the identical actions each time, and are redundant.

Business Private - Legal and

Contractual

The Regulatory Family is Sufficient for Identifying Most Aggregated Data Collections


How much more information do you need to know about the contents of the tanker in order to manage your risk properly?

FLAMMABLE!

You know this database contains Private Data sensitive to PCI, and the Calif. & EU Statutes

and must be Protected Accordingly


“ What you cannot identify, you cannot manage.”

DB Contains tables with

Personally Private and PCI Data

- Chief Information Security Officer of large defense firm.

Today, Data Moves Fast but Data Regulatory Sensitivity Knowledge Often Remains In Local Business Groups


There is no specific group or system that captures information regulatory sensitivity and maintains it across the Enterprise

Customers

Research & Product

Design

Marketing

Raw materials And suppliers Market

Research

Delivery Orders

Sales Finance

Access Control HR

Products Data

Warehouse

Production & Planning

Metadata must Capture all the data about Your Data that the Enterprise Needs to Know

• Technical Metadata includes character type, field length, decimal places, field name, etc.

• Data Quality Metadata often includes source system, bounds checking, refresh rate, the formula of a derived field, and currency type used in a transaction.

• Security Metadata is often left out, but is the Security Classification.

• Regulatory Metadata is almost always left out, but would include the families of all regulations that direct the storage and exposure of this Regulated Information.


-Not an inclusive list.

Collect Regulatory Metadata in your Central Data Directory to Link the Knowledge Silos


Security Policies

PCI & Calif. Requirements

HIPAA Data

Data Retention

Business Private Information

Personal Privacy:

US and EU

“Insider” Information

Sarbanes Oxley

Central

Metadata Directory

Trade Secrets

Actions are Required For Regulatory Compliance to Be Functional

• In the book, Nancy shows why you must distill each regulation down into specific physical actions (work assignments) that satisfy regulatory requirements and company policy

• Inform business managers who determine user authorizations about the information protection actions required for each User Entitlement

• Design your process so that when specific actions are taken, they leave an audit trail.



Nancy’s Iron Law of Action

No Regulatory Compliance Can Be

Proven to Have Happened Unless There is The Audit Trail of An

Action.

Data Protection Up Front Encourages Agility

• Putting regulatory data risk analysis at the design stage of a new software acquisition project lets the project team build regulatory safeguards into the architecture and system design from the start.

• Without the worry of having to stop and change their work at the end for “security reasons,” the project team can design the data processing in a way that naturally protects the Regulated Information as part of its normal function.


Engage All Your Corporate Partners

1. Introduce information definition and regulatory policy enforcement as initial design requirements for all new applications, web systems, and databases (DBMS)

2. Help Data Analysts and Data Architects define the data’s sensitivity by leveraging your business leaders’ knowledge

3. Get the existing data policies from Information Security regarding actions protecting classified information

4. Interview Corporate Counsel to learn their data protection polices and actions (“Guidelines” will usually be forgotten)

5. Engage data governance stewards and tell them you feel their pain and want their policies that require actions


Stop Playing “Whack-A-Mole®”


Sarbanes-Oxley Act, Personal Privacy, PCI, HIPAA, FISMA, PIPEDA, Gramm-Leach, SB 1386, GAAP, and the U.S. Patriot Act ALL affect your data and their instructions greatly overlap!

Multiple, single-regulation governance initiatives design multiple, redundant data compliance solutions.

Isolated response to each new information law assures inconsistent compliance, and is the corporate equivalent of playing Whack-A-Mole

®.

for Attending

David Schlesinger CISSP

Senior Security Architect Metadata Security LLC [email protected] 602-697-4954

Author of The Hidden Corporation

Perhaps the world’s first

Data Management Security Novel

Discount Code for Attendees: HiddenCorp20 at amazon.com


Closing hidden gaps in your Software Development Life Cycle where Data Governance is often absent

mailto:[email protected]

integrating information protection into data architecture & sdlc

Technology

data warehouseconsultant

data protection

data data content isand

blamed data breaches

number of data breaches

data sensitivity ignorance

datahandling procedures

alegacy data environment1