Ed Gelbstein, Ph.D.
Information security has become a visible issue in business, on the move and at home. Its practice places emphasis on preventing attacks that target availability (e.g., denial of service) and those that result in infections by malicious software (malware) that allow a third party to do unauthorized things with data and information (e.g., theft, disclosure, modification, destruction of data).
The Stuxnet worm reported in 2010 altered the operation of an industrial process and was designed to damage physical equipment and modify the operator’s monitoring indications to show that the equipment was working normally.1 This was an attack on data integrity (also referred to as a “semantic attack”) that, if and when replicated on other targets, could cause major problems in critical information infrastructures such as utilities, emergency services, air traffic control and others with a large IT component on which society relies. Data governance is an essential component for strengthening data integrity.
A recent article in the ISACA Journal presents a data governance framework developed by Microsoft for privacy, confidentiality and compliance. It discusses the roles of people, process and technology; the data life cycle; and the principles of data privacy and confidentiality. It also provides links to more detailed papers on the subject of trustworthy computing.2
Here, these topics will be expanded upon, focusing on data integrity, the standards and best practices that support it, and the role of data governance. This article also introduces a nonproprietary data governance framework.
Of the three main domains of information security, availability is closely associated with technology and lends itself to being measured. Downtime is visible and can be expressed as an absolute value (e.g., in minutes per incident) or as a percentage, and it is simple enough to understand that “five nines” (99.999 percent) availability means a total cumulative downtime of around five minutes in a year. Data center operators know what it takes to achieve this.
Confidentiality is easy enough to explain, but makes sense only if data and documents have been classified into categories that reflect the business need to protect them, such as “public,” “restricted to,” “embargoed until” and “secret.”
The technical people who provide IT infrastructure and services should not be expected to perform this classification, as they may not have enough business knowledge to do so and, through outsourcing and/or cloud computing, they may even be external to the business. Therefore, business functions must take ownership of the data and their classification process, while IT service and technology providers support this with tools and processes such as identity access management (IAM) controls and encryption.
The simplest metric for confidentiality is binary: An item that should not be disclosed either has not been (confidentiality is preserved) or has been (confidentiality is lost). Unfortunately, this is not a very useful metric, as it does not reveal the impact of such a disclosure, which can range from mild embarrassment to a breach of national security.
When it comes to integrity, the situation is more complex because the word means different things to different people. This creates fertile ground for miscommunication and misunderstandings, with the risk that the activity will not be done well enough because of unclear accountabilities.
The importance of data integrity can be illustrated simply: A person needs hospital treatment that includes taking a daily medication dosage of 10 milligrams (mg). By accidental or deliberate intervention, the electronic record of the treatment is changed to a dosage of 100 mg—with fatal consequences. In another example, what if, as in a work of fiction that predates the Stuxnet attack of 2010, the control systems of a nuclear power station are interfered with to show normal conditions while, in fact, a chain reaction has been triggered?3 Are professionals aware of the many definitions of “data integrity”? According to:
Accuracy and consistency of stored data, indicated by an absence of any alteration in data between two updates of a data record. Data integrity is imposed within a database at its design stage through the use of standard rules and procedures and is maintained through the use of error checking and validation routines.4
Quality of correctness, completeness, wholeness, soundness and compliance with the intention of the creators of the data. It is achieved by preventing accidental or deliberate, but unauthorized, insertion, modification or destruction of data in a database. Data integrity is one of the six fundamental components of information security.5
There is no doubt that there are more definitions to be found. But they have overlaps, address different issues and create semantic confusion, which is a likely reason for databases to be the least protected objects in the IT infrastructure.
This is not the end of the problem statement. The decentralization of information systems and the availability of powerful programming environments for end users, particularly spreadsheets, have created potentially uncontrolled integrity vulnerabilities because such spreadsheets are used to support executive decisions, possibly without due consideration of data quality and data integrity. How should this be counted? It could be considered as:
Perhaps it could be considered as all three, in which case it must be determined who (i.e., the data owner, the end user who designed the spreadsheet, the IT department or service provider, or all of them working together) should address these.
The previous section used, as an example, untested and undocumented user-designed spreadsheets (aggravated by manual input, particularly when not assisted by validation of the values entered), but there are other, potentially more serious, triggers such as:
To complicate matters, the IT audit function may not have the critical mass to undertake audits covering all of these areas.
Attacks on data integrity involve intentional, unauthorized modifications of data at some point in their life cycle. For the purpose of this article, the data life cycle consists of:
Fraud is the oldest form of attack on data integrity, and it exists in many variants. The variants will not be discussed in this article, other than to mention an example that, in 2008, made page one in the world news: The “abuse of trust, forgery and unauthorized use of the bank’s computer systems” by a trader at Societe Generale (France) resulted in losses estimated at €4.9 billion.6 Judging from the number of publications and international conferences that deal with fraud, this issue is likely to remain high on the agenda for some time.
Web site defacements have affected many organizations in the private and public sectors for many years, but apart from some reputational damage, none could be considered as having been “catastrophic.”
Logic bombs, unauthorized software introduced into a system by one or more of its programmers/maintainers, or Trojan horses or other means can also impact data integrity through modifying data (as when a formula in a spreadsheet is incorrect) or encrypting data and then demanding a ransom to provide the decryption key. There have been several such attacks in recent years, mainly affecting hard drives in personal computers. It should be expected that attacks of this type will be launched against servers sooner or later.
Unauthorized modifications of operating systems (OSs) (server and network) and/or applications software (such as undocumented backdoors), database tables, production data and infrastructure configuration are also considered to be attacks on data integrity. It can be assumed that the findings of IT audits regularly include weaknesses in key processes, particularly the management of privileged access, change management, SoD and the monitoring of logs. These weaknesses make such modifications possible and hard to detect (until an incident occurs).
Another form of attack on data integrity is interference with Systems Control and Data Acquisition (SCADA) systems, such as those used by critical infrastructures (e.g., electricity, water supply) and in industrial processes. Frequently, these are not installed, operated or managed by the IT function. The attack on the Iranian uranium enrichment facilities in 2010 was designed to modify the behavior of the centrifuges while displaying normal conditions in the control panels.7
It should be noted that many of these control systems are not connected to the Internet and, in the case of the injection of Stuxnet software, required a manual intervention,8 which confirms that “people” remain the weakest link in information security/assurance.
For enterprises that have not already done so, a good place to start planning defenses is the adoption of best practices such as COBIT Deliver and Support (DS) 11.6 Security requirements for data management, used in conjunction with its related section in the IT Assurance Guide: Using COBIT.9
These publications summarize the control objective and its value and risk drivers and offer a list of recommended tests of the control design.
ISACA has also published a series of documents mapping standards related to information security with COBIT 4.1, and these are extremely valuable documents for practitioners and auditors. Additionally, an excellent article that maps the Payment Card Industry Data Security Standard (PCI DSS) v2.0 with COBIT 4.1 was recently published in COBIT Focus.10
An additional resource is available from Data Management Association International (DAMA): The DAMA Guide to the Data Management Body of Knowledge (DMBOK), specifically chapters three (Data Governance), seven (Data Security Management) and 12 (Data Quality Management).11
From a compliance perspective, there is a growing body of legislation that places accountability for data integrity and information assurance (IA) on organizations. In the US, this includes the Data Quality Act, Sarbanes-Oxley Act, Gramm-Leach-Bliley Act, Health Insurance Portability and Accountability Act, and Fair Credit Reporting Act—all of which impose severe penalties for noncompliance. There is also the Federal Information Security Management Act, which can impose budgetary penalties for noncompliance. (A discussion of legislation outside of the US is beyond the scope of this article; however, two major pieces of comparable legislation are the European Union [EU] “Directive on Data Protection” and the EU “8th Company Law Directive” on statutory audit12, 13).
The adoption of best practices needs to be complemented by formalizing accountabilities for the business and IT processes that support and enhance data security.
Business Responsibilities A program of data integrity assurance needs to address Detect, Deter (2D); Prevent, Prepare (2P); and Respond, Recover (2R).14 As data owners, the initiative must come from the business, and the role of the IT service provider—in-house or outsourced—should be one of implementation.
Good practices to adopt include:
IT and End-user Support Responsibilities Whoever provides information systems and technology operational services (i.e., business unit, in-house IT department, outsourcing service provider) has to demonstrate that appropriate measures—such as those defined in COBIT DS11 Manage data—are carried out to an appropriate level of maturity, and that appropriate performance and risk metrics are collected, monitored and reported.
End-user support teams (either part of IT or independent) are usually responsible for creating accounts and credentials for access to systems and data. These accounts and credentials must be documented fully and implemented only if the relevant authorizations have been formally issued.
Internal Audit Responsibilities The role of auditors is to provide independent and objective assessments of the extent to which business and IT responsibilities for data integrity have been addressed and applied.
IA is the practice of managing risks related to the use, processing, storage and transmission of information or data and the systems and processes used for those purposes. IA has grown from the practice of information security, which, in turn, grew out of practices and procedures of computer security.
Service providers (e.g., IT organizations, outsourcers) are clearly responsible for technologies and their operation and put measures in place to provide confidentiality, integrity and availability (CIA) in the operational environment. With regards to protecting data, they provide services such as backups and disaster recovery arrangements with clearly defined time and point recovery objectives (i.e., the amount of data lost in an incident) documented in service level agreements (SLAs). However, service providers do not have responsibility for data governance and its many related activities.
SLAs place clearly defined responsibilities on IT service providers, but not on data and system owners. This results in a lack of clarity related to accountabilities and, therefore, an inability to ensure that data have been properly classified and that the roles and responsibilities of data users and, in particular, privileged users are managed in a way that reflects their critical roles. As a result, data integrity remains the poor relation of information security and IA.
There is little material published on key metrics, performance and key risk indicators for data integrity in an information security context. The following may be helpful starting points:
Data governance addresses specifically the information resources that are processed and disseminated. The key elements of data governance can be categorized into six major areas: data accessibility, data availability, data quality, data consistency, data security and data auditability. DAMA produced DMBOK,15 which presents a comprehensive framework for data management and governance, including tasks to be performed and inputs, outputs, processes and controls.
GIGO is as valid today as it was when it was first formulated some 60 years ago. The difference between then and now is that the volume of data in digital form has grown exponentially, and this growth has not been accompanied by the development and strengthening of data governance disciplines. The fact regarding CIA (the three pillars of information security) remains—that availability is the only component for which metrics are well defined and generally accepted.
Not applying data integrity metrics should be seen as an obstacle, because it implies that an enterprise cannot demonstrate that confidentiality or integrity are “better” or “worse” than before procedures and processes were introduced to manage them.
As long as data governance does not receive the same degree of attention as IT governance (and the latter often remains the weak link in corporate governance), organizations will be exposed to significant operational, financial, noncompliance and reputational risk.
Related to this topic, Managing Enterprise Information Integrity: Security, Control and Audit Issues is available from the ISACA Bookstore. For information, see the ISACA Bookstore Supplement in this Journal, visit www.isaca.org/bookstore, e-mail firstname.lastname@example.org or telephone +1.847.660.5650.
1 Farwell, James P.; Rafal Rohozinski; “Stuxnet and the Future of Cyber War,” Survival, vol. 53, issue 1, 2011 2 Salido, Javier; “Data Governance for Privacy, Confidentiality and Compliance: A Holistic Approach,” ISACA Journal, vol. 6, 2010 3 Dobbs, Michael; The Edge of Madness, Simon & Shuster UK Ltd., UK, 2008 4 IBM, Top 3 Keys to Higher ROI From Data Mining, IBM SPSS white paper5 YourDictionary.com, http://computer.yourdictionary.com/data-integrity 6 See Kerviel, Jerome; L’engranage, Memoires d’un Trader, Flammarion, France, 2010, and Societe Generale, www.societegenerale.com/en/search/node/kerviel. 7 Op cit, Farwell 8 Broad, William J.; John Markoff; David E. Sanger; “Israeli Test on Worm Called Crucial in Iran Nuclear Delay,” The New York Times, 15 January 2011, www.nytimes.com/2011/01/16/world/middleeast/16stuxnet.html?pagewanted=all 9 IT Governance Institute, IT Assurance Guide: Using COBIT, USA, 2007, p. 212 10 Bankar, Pritam; Sharad Verma; “Mapping PCI DSS v2.0 With COBIT 4.1,” COBIT Focus, vol. 2, 2011, www.isaca.org/cobitnewsletter 11 Data Management Association International (DAMA), The DAMA Guide to the Data Management Body of Knowledge, Technics Publications LLC, USA, 2009, www.dama.org/i4a/pages/index.cfm?pageid=3345 12 European Union (EU), Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the Protection of Individuals With Regard to the Processing of Personal Data and on the Free Movement of Such Data 13 EU, Directive 2006/43/EC of the European Parliament and of the Council of 17 May 2006 on Statutory Audits of Annual Accounts and Consolidated Accounts, Amending Council Directives 78/660/EEC and 83/349/EEC and Repealing Council Directive 84/253/EEC 14 Adapted from the US Chiefs of Staff Joint Publication 3-28, “Civil Support,” USA, 14 September 2007 15 Op cit, DAMA
Ed Gelbstein, Ph.D.,has worked in IT for more than 40 years and is the former director of the United Nations (UN) International Computing Centre, a service organization providing IT services around the globe to most of the organizations in the UN system. Since leaving the UN, Gelbstein has been an advisor on IT matters to the UN Board of Auditors and the French National Audit Office (Cour des Comptes), and is also a faculty member of Webster University, Geneva, Switzerland. He is a regular speaker at international conferences covering audit, risk, governance and information security, and is the author of several publications. Gelbstein lives in France and may be contacted at email@example.com.
Enjoying this article? To read the most current ISACA Journal articles, become a member or subscribe to the Journal.
The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.
Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.
© 2011 ISACA. All rights reserved.
Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.