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
23
Embed
Integrating Information Protection Into Data Architecture & SDLC
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
*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.
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.
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.
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.
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.
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
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