Lecture
Integrity control is the process of ensuring that data or resources remain intact and unchanged for a certain period of time or until certain events occur. This is an important aspect of information security and data management. Integrity control helps detect and prevent unauthorized changes to data or resources that may arise from errors, malicious actions, or technical failures.
Integrity control of a computer system is a mechanism needed to track the preservation of files, documents, the registry, hardware settings, and other components located on a computer or server.
There are software-based and hardware-software methods of integrity control. Hardware-software methods involve trusted boot modules installed inside the case of a computer, laptop, or server. These modules can come in different form factors, such as PCI, PCI-e, mini PCI, depending on the type of motherboard. They can restrict access to USB ports, preventing booting from unauthorized storage media such as flash drives and disks. They can also block the computer from booting if errors are detected while checking the integrity of various resources.
There are several ways to ensure integrity control:
Data hashing: By calculating a hash sum (cryptographic signature) of data and storing it, one can check whether the data has been changed since the hash was created. If the data changes, the hash sum will also change.
Digital signature: Applying a digital signature to data makes it possible to establish that the data has not been modified after signing. This is especially important for confirming the authenticity and integrity of data in electronic documents and messages.
Backup and versioning: Regularly creating data backups and keeping different versions of files allows data to be restored in case of loss or damage, ensuring its integrity.
Intrusion detection: Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) can identify anomalies in system behavior and help detect attempts by attackers to alter data.
Auditing and logging: Keeping audit trails and records of user and system actions allows changes to data to be tracked and identifies who performed particular operations and when.
Physical security: Restricting access to physical resources, such as servers or data storage, helps prevent unauthorized changes at the hardware level.
Access control: Setting the correct access permissions for files and resources limits the ability of users and processes to modify data.
Encryption: Protecting data with encryption makes it unintelligible to outsiders and prevents unauthorized modification.
Integrity control is important for ensuring data security and maintaining its accuracy and reliability across various fields, including information systems, banking, medicine, and others.
Software tools for checking integrity are designed to monitor that the contents of a computer's resources do not change. The following methods are typically used to perform this check:
Full copying of resources: This method is inefficient, since previously copied data is used for verification. In addition, it is not considered secure, since copies of the data could be substituted or stolen.
Checksum and hashing method: A special cryptographic algorithm is used here to calculate a checksum or hash for a specific resource. All resulting hashes are stored in a secure location on the user's computer.
Electronic digital signature (EDS): This method involves encrypting the hash obtained from the original data. An electronic digital signature is used to ensure the authenticity and integrity of data.
MAC (Message Authentication Code): A MAC is a unique sequence of characters generated using a cryptographic algorithm and a private key. This method is also used to ensure data integrity.
All of these methods help guarantee that data on a computer remains untouched and protected from unauthorized changes.
Systems designed to provide integrity control give the user the ability to choose the most convenient time to run checks. Usually the optimal moments for this are at boot-up or shutdown of the computer. This helps avoid placing a heavy load on the system during computational operations.
However, the most significant characteristic of such systems is how they handle a situation where a check reveals a violation of data integrity. In such a case, the system may roll back the changes to the last verified values, thereby restoring their inviolability. Alternatively, it may log the event for further analysis.
Effective management of integrity control also helps ensure the stability of the system's operation and prevent potential data breaches.
Example
A method of controlling data integrity in information and computing systems
The patented invention relates to the field of ensuring data integrity in information and computing systems. The main idea of this invention is to reduce the amount of resources needed to control data integrity in information and computing systems. This is achieved by performing integrity control only for those file system components that can be changed, and only at the moments when these components are opened to perform any actions that could affect their integrity. This approach makes it possible to reduce the number of file system objects subject to control, which in turn reduces the load on the resources spent on data integrity control in information and computing systems.
Patent authors:
Evgeny Borisovich Drobotun (RU)
Mandatory Integrity Control (MIC) is a security feature introduced in Astra Linux and Windows Vista and implemented in the subsequent line of Windows operating systems, which adds access control by means of Integrity Levels (IL). An integrity level represents the level of trustworthiness of an access subject or object. The purpose of this mechanism is to use integrity management policies and the integrity levels of the involved subjects and objects to restrict access for processes that are considered potentially less trustworthy compared to trusted processes running under the same user account.
Mandatory Integrity Control is defined using a new type of access control entry (ACE) to represent the integrity level of an object in its security descriptor. In Windows, access control lists (ACLs) are typically used to grant access rights (read, write, and execute permissions) to users or groups. When initialized, a process's access token is assigned an integrity level. When a thread attempts to access an object (for example, a file), the reference monitor compares the integrity level in the process's or thread's access token with the integrity level in the object's security descriptor. Windows restricts the allowed access rights depending on whether the subject's integrity level is higher or lower than the object's integrity level, based on the integrity policy specified in the access control entry (ACE). The security subsystem uses integrity levels for mandatory access control, as opposed to discretionary access control, which is implemented via traditional DACLs.
Windows Vista and later versions define 5 integrity levels (IL):
Untrusted (SID: S-1-16-0),
Low (SID: S-1-16-4096),
Medium (SID: S-1-16-8192),
High (SID: S-1-16-12288)
System (SID: S-1-16-16384).
By default, processes launched by a regular user (including an administrator) receive a medium integrity level, while processes launched via UAC with administrator rights receive a high one. By assigning different integrity levels, mandatory integrity control makes it possible to isolate potentially vulnerable applications (for example, applications oriented toward working on the Internet, office applications used to open documents received from untrusted sources, etc.). Processes with a low integrity level have less access (restricted write rights to system objects) than processes with higher integrity levels, since mandatory access control is enforced by the Windows OS itself .
Objects with ACLs, such as named objects, including files, registry keys, or other processes and threads, have an entry in the ACL that defines the integrity level of that object. It defines the minimum integrity level a process must have to be able to use the given object. Windows objects are assigned by default the No-Write-Up mandatory integrity policy, which specifies that a process can write to or delete an object only when its integrity level is equal to or exceeds the integrity level of the object. Therefore, a process with a Low integrity level cannot open a file with a Medium integrity level for writing, even if the DACL grants the process write access.
In addition, processes with a low integrity level cannot open process objects with a higher integrity level for reading, since process objects are assigned by default the No-Read-Up mandatory integrity policy. Consequently, a process cannot interact with another process that has a higher integrity level. A process cannot perform functions such as injecting a DLL into a process of a higher integrity level using the remote thread creation API function , or send data to another process using the process memory write function .
Although processes inherit the integrity level of the process that created them, the integrity level can be configured when a process is created. In addition to restricting the sending of window messages via User Interface Privilege Isolation (UIPI), mandatory integrity control is used by applications such as Adobe Reader, Google Chrome, Internet Explorer, and «Windows Explorer» to isolate documents from vulnerable objects in the system
Internet Explorer 7 applies a «Protected Mode» setting based on mandatory integrity control to control whether a web page is opened as a process with a low integrity level or not (provided the operating system supports mandatory integrity control), based on security zone settings, thereby preventing certain classes of security vulnerabilities. Since Internet Explorer in this case runs as a low-integrity-level process, it cannot modify system-level objects — file and registry operations are instead «virtualized». Adobe Reader 10 and Google Chrome are two other well-known applications that implement this technology to reduce their exposure to malware
Microsoft Office 2010 introduced a sandboxed environment called «Protected View» for Excel, PowerPoint, and Word, which prevents potentially dangerous documents from modifying components, files, and other resources on the system. «Protected View» runs as a low-integrity-level process, and on Windows Vista and later releases of Windows it uses mandatory integrity control and User Interface Privilege Isolation (UIPI) to further restrict the «sandbox».
However, in some cases a process with a higher integrity level must perform certain actions with respect to a process with a lower integrity level, or a process with a lower integrity level requires access to resources that only a process with a higher integrity level can access (for example, when viewing a web page in protected mode and saving a file downloaded from the Internet to a folder specified by the user). Processes with high and low integrity levels can still interact with each other using files, named pipes, LPC, or other shared objects. The shared object must have a low integrity level and be shared by both low-integrity-level and high-integrity-level processes. Since mandatory integrity control does not prevent a low-integrity-level process from sharing objects with a higher-integrity-level process, it may exploit vulnerabilities in the latter and make it act on its behalf, resulting in a squatting attack. Nevertheless, such «subversive attacks» can be prevented through the use of User Interface Privilege Isolation, which takes advantage of mandatory integrity control.
Data integrity is the maintenance and assurance of the accuracy and consistency of data over its entire life cycle, and a critical aspect of the design, implementation, and use of any system that stores, processes, or retrieves data. The term has a broad scope and can have quite different meanings depending on the specific context — even within the same computing concept. It is sometimes used as an indirect term for data quality, while data validation is a prerequisite for data integrity. Data integrity is the opposite of data corruption. The overall goal of any data integrity method is the same: to ensure that data is recorded exactly as intended (for example, a database correctly rejecting mutually exclusive possibilities). Furthermore, upon later retrieval, ensure that the data is the same as it was when originally recorded. In short, data integrity aims to prevent unintentional changes to information. Data integrity should not be confused with data security, the discipline of protecting data from unauthorized parties.
Any unintended changes to data as a result of a storage, retrieval, or processing operation, including malicious intent, unexpected hardware failure, and human error, constitute a violation of data integrity. If the changes result from unauthorized access, this may also be a data security breach. Depending on the data involved, this can range from something as harmless as a single pixel in an image differing in color from what was originally recorded, to the loss of vacation photos or a business-critical database, to even catastrophic loss of human life in a life-critical system.
Physical integrity relates to issues involving the correct storage and retrieval of the data itself. Physical integrity issues can include electromechanical faults, design flaws, material fatigue, corrosion, power interruptions, natural disasters, and other specific environmental hazards such as ionizing radiation, extreme temperatures, pressure, and g-forces. Ensuring physical integrity involves techniques such as redundant hardware, an uninterruptible power supply, certain types of RAID arrays, radiation-hardened chips, error-correcting memory, the use of a clustered file system, the use of file systems that employ block-level checksums such as ZFS, storage arrays that compute parity calculations such as exclusive or, or use a cryptographic hash function, and even having a watchdog timer on critical subsystems.
Physical integrity often makes extensive use of error-detecting algorithms known as error-correcting codes. Data integrity errors caused by human activity are often detected using simpler checks and algorithms, such as the Damm algorithm or the Luhn algorithm. These are used to maintain data integrity after manual transcription from one computer system to another by a human intermediary (for example, credit card numbers or bank routing numbers). Computer-induced transcription errors can be detected through hash functions.
In production systems, these techniques are used together to provide various degrees of data integrity. For example, a computer's file system may be configured on a fault-tolerant RAID array, but may not provide block-level checksums to detect and prevent silent data corruption. Another example: a database management system may comply with ACID properties, while the RAID controller or the hard drive's internal write cache may not.
This type of integrity is concerned with the correctness or rationality of a piece of data in a specific context. This includes topics such as referential integrity and entity integrity in a relational database, or the correct rejection of impossible sensor data in robotic systems. These issues involve ensuring that data «makes sense» given its environment. Challenges include software bugs, design flaws, and human errors. Common methods for ensuring logical integrity include things like check constraints, foreign key constraints, program assertions, and other runtime sanity checks.
Physical and logical integrity often share many of the same challenges, such as human errors and design flaws, and both must deal appropriately with concurrent write and retrieval requests, the latter being an entirely separate topic.
If a data sector has only a logical error, it can be reused by overwriting it with new data. In the case of a physical error, the affected data sector becomes permanently unusable.
Data integrity contains data retention guidelines, defining or guaranteeing the length of time data can be retained in a particular database (typically a relational database). To achieve data integrity, these rules are consistently and routinely applied to all data entering the system, and any relaxation of enforcement could cause errors in the data. Implementing data checks as close as possible to the source of input (such as human data entry) causes less erroneous data to enter the system. Strict enforcement of data integrity rules results in lower error rates and time saved troubleshooting and tracing erroneous data and the errors it causes in algorithms.
Data integrity also includes rules defining the relations a piece of data can have to other pieces of data, such as a Customer record being allowed to link to purchased Products, but not to unrelated data such as Corporate Assets. Data integrity often involves ensuring the correction of invalid data based on a fixed schema or a predefined set of rules. An example would be text data entered where a date-time value is required. Data derivation rules also apply, specifying how a data value is derived based on an algorithm, contributing inputs, and conditions. It also specifies the conditions under which a data value could be re-derived.
Data integrity is normally enforced in a database system by a series of integrity constraints or rules. Three types of integrity constraints are an inherent part of the relational data model: entity integrity, referential integrity, and domain integrity.
If a database supports these features, it is the database's responsibility to ensure data integrity as well as the consistency model for the data storage and retrieval. If a database does not support these features, it is the application's responsibility to ensure data integrity while the database supports the consistency model for the data storage and retrieval.
Having a single, well-controlled, and well-defined data integrity system increases
Modern databases support these features (see comparison of relational database management systems), and the responsibility for ensuring data integrity in fact lies with the database. Companies, and even many database systems themselves, offer products and services for migrating legacy systems to modern databases.
An example of a data integrity mechanism is the parent-child relationship of related records. If a parent record owns one or more related child records, all referential integrity processes are handled by the database itself, which automatically ensures the accuracy and integrity of the data such that no child record can exist without a parent (also called orphaned), and no parent loses its child records. It also ensures that no parent record can be deleted while the parent record owns any child records. All of this is handled at the database level and does not require integrity checks in the code of each application.
Various research findings show that neither widely used file systems (including UFS, Ext, XFS, JFS, and NTFS) nor hardware RAID solutions provide sufficient protection against data integrity issues.
Some file systems (including Btrfs and ZFS) provide checksumming of internal data and metadata, which is used to detect silent data corruption and improve data integrity. If corruption is detected in this way and the internal RAID mechanisms provided by these file systems are also used, such file systems can additionally transparently repair the corrupted data. This approach allows for improved data integrity protection covering the entire data path, commonly referred to as end-to-end data protection.
Comments