Click to learn more about David Schlesinger.
A database management system (DBMS) is the embodiment in code of a logical process to store, move, analyze, select and output information. Within the code blocks that make up the DBMS program there is provision to limit a user’s rights regarding creating, reading, modifying or deleting data entries. While usually adequate in controlled and secure electronic environments, these security measures are now unsatisfactory to protect information in today’s globally-connected and globally-vulnerable world.
When essential systems and data structures are breached thought must be given to providing superior measures to protect sensitive information, especially given the ease by which this is occurring. An obstacle to implementing superior data security is our habit of working in controlled environments. Many historic data management practices, rules, policies, and ways of working now exacerbate the security problems by their failure to take into account the “brave new world of global infrastructure.”
Make no mistake, the student in a basement in Korea and her friend in Germany are both on your computer network from time to time. Both have given themselves increased rights by tricking some utility on some system, web page, or DBMS. Therefore both need to be included in your data security process planning. Global infrastructure means that the CIO must accept first, that there is an Enterprise Electronic Environment to manage and second, that the Enterprise Electronic Environment is permeable. Operational data protection processes must be in line with that very real paradigm.
Which Methodology? Who cares!
In this light, development and implementation methodologies from Waterfall to Agile fall far short. These methods usually fail to consider the sensitivity and security classifications of the information that they manage. Data content and sensitivity are not seen as germane to the development of a project. Indeed, they are often unknown to the developers. “Surely, somebody must be taking care of that?” is often the comment. However, “Shirley” was never hired! Thus, security measures are tacked on later after a bad audit or incursion, and usually slow down the entire business process.
Security analysts are seldom invited to initial software project meetings. No documented protection requirements for sensitive data are usually present at the meetings, nor how to identify data that is sensitive. Thus data security does not influence data architectural decisions. Basic data architectural decisions are usually completed prior to a full data analysis, which is assumed to be a business analysis. A security analysis would be a data analysis that characterizes the sensitivity of the data for privacy, legal and contractual protections, customer and supplier non-disclosure agreements, trade secrets, and personal private data of customers and employees. Do you do this during project planning?
Even if data sensitivity is brought up, there is often no corporate standard to indicate this sensitivity in the Enterprise Data Model. Protections are therefore applied inconsistently across the organization. The result is that when data is stolen from the department with the weakest protection, all the credit card numbers, personal health information, addresses, social security numbers, and fingerprints are posted on the Internet.
Capture and Track Data Sensitivity
Usually sensitive information requirements remain scattered across the organization, locked in the minds of experienced employees. It cannot be easily transmitted among departments and fails to be documented and available for the use of managers approving entitlement authorizations for their employees. Worse, much of this corporate knowledge leaves with every retirement and layoff. Considering that your enterprise is continuously attached to the Global Infrastructure, this knowledge loss is not an optimal situation.
A better solution is to create a snapshot of the sensitivity of the information within each information system as one of the first steps in the project planning process. This identified sensitive enterprise information can be saved as security metadata in a central repository for metadata – along with the business and technical metadata.
It never ceases to amaze security professional how many new products connected to the Global Infrastructure are tossed out into the marketplace without even consideration of the ease by which they can be subverted. Clueless manufacturers rush to market with insecure Internet devices for our homes, offices and automobiles, only to find that they are vulnerable to hacking. Cars can be hacked from distant computers; home thermostats can be controlled by strangers in Europe; talking Barbie and baby monitoring cameras can be viewed by people in Minsk. We need not follow this naïve and dangerous trend in launching our business software platforms.
But I digress.
Getting the right stakeholders together, such as business experts, security analysts, and project managers, allows data within a target business processes to be thoughtfully examined to identify the most sensitive data and define the type of sensitivity that it has. This definition can then be matched to existing corporate and legal data governance policies (You have them, right?) that control its storage, transmissions, encryption and usage
Knowledge of the existence, location, and sensitivity of this information allows the proper data protections to be built into the data storage and access system from the beginning. Thoughtful data architectural protection decisions can alleviate much of the effort of data governance while reducing corporate risk. This eliminates the need for re-engineering the system later, satisfies legal and contractual requirements for data protection, and mitigates the impact of any future hacking incursion, since the really sensitive information will be better protected – a “Win-Win” for all.