Physical information security is the intersection or common ground between physical security and information security. It primarily concerns the protection of tangible information-related assets such as computer systems and storage media against physical, real-world threats such as unauthorized physical access, theft, fire and flood. It typically involves physical controls such as protective barriers and locks, uninterruptible power supplies, and shredders. Information security controls in the physical domain complement those in the logical domain (such as encryption), and procedural or administrative controls (such as information security awareness and compliance with policies and laws). == Background == Asset are inherently valuable and yet vulnerable to a wide variety of threats, both malicious (e.g. theft, arson) and accidental/natural (e.g. lost property, bush fire). If threats materialize and exploit those vulnerabilities causing incidents, there are likely to be adverse impacts on the organizations or individuals who legitimately own and utilize the assets, varying from trivial to devastating in effect. Security controls are intended to reduce the probability or frequency of occurrence and/or the severity of the impacts arising from incidents, thus protecting the value of the assets. Physical security involves the use of controls such as smoke detectors, fire alarms and extinguishers, along with related laws, regulations, policies and procedures concerning their use. Barriers such as fences, walls and doors are obvious physical security controls, designed to deter or prevent unauthorized physical access to a controlled area, such as a home or office. The moats and battlements of Mediaeval castles are classic examples of physical access controls, as are bank vaults and safes. Information security controls protect the value of information assets, particularly the information itself (i.e. the intangible information content, data, intellectual property, knowledge etc.) but also computer and telecommunications equipment, storage media (including papers and digital media), cables and other tangible information-related assets (such as computer power supplies). The corporate mantra "Our people are our greatest assets" is literally true in the sense that so-called knowledge workers qualify as extremely valuable, perhaps irreplaceable information assets. Health and safety measures and even medical practice could therefore also be classed as physical information security controls since they protect humans against injuries, diseases and death. This perspective exemplifies the ubiquity and value of information. Modern human society is heavily reliant on information, and information has importance and value at a deeper, more fundamental level. In principle, the subcellular biochemical mechanisms that maintain the accuracy of DNA replication could even be classed as vital information security controls, given that genes are 'the information of life'. Malicious actors who may benefit from physical access to information assets include computer crackers, corporate spies, and fraudsters. The value of information assets is self-evident in the case of, say, stolen laptops or servers that can be sold-on for cash, but the information content is often far more valuable, for example encryption keys or passwords (used to gain access to further systems and information), trade secrets and other intellectual property (inherently valuable or valuable because of the commercial advantages they confer), and credit card numbers (used to commit identity fraud and further theft). Furthermore, the loss, theft or damage of computer systems, plus power interruptions, mechanical/electronic failures and other physical incidents prevent them being used, typically causing disruption and consequential costs or losses. Unauthorized disclosure of confidential information, and even the coercive threat of such disclosure, can be damaging as we saw in the Sony Pictures Entertainment hack at the end of 2014 and in numerous privacy breach incidents. Even in the absence of evidence that disclosed personal information has actually been exploited, the very fact that it is no longer secured and under the control of its rightful owners is itself a potentially harmful privacy impact. Substantial fines, adverse publicity/reputational damage and other noncompliance penalties and impacts that flow from serious privacy breaches are best avoided, regardless of cause! == Examples of physical attacks to obtain information == There are several ways to obtain information through physical attacks or exploitations. A few examples are described below. === Dumpster diving === Dumpster diving is the practice of searching through trash in the hope of obtaining something valuable such as information carelessly discarded on paper, computer disks or other hardware. === Overt access === Sometimes attackers will simply go into a building and take the information they need. Frequently when using this strategy, an attacker will masquerade as someone who belongs in the situation. They may pose as a copy room employee, remove a document from someone's desk, copy the document, replace the original, and leave with the copied document. Individuals pretending to building maintenance may gain access to otherwise restricted spaces. They might walk right out of the building with a trash bag containing sensitive documents, carrying portable devices or storage media that were left out on desks, or perhaps just having memorized a password on a sticky note stuck to someone's computer screen or called out to a colleague across an open office. == Examples of Physical Information Security Controls == Shredding paper documents prior to their disposal can prevent unintended information leakage. Digital data can be encrypted or securely wiped. Offices may require visitors to present valid identification cards or valid access keys. Office workers may be required to obey "clear desk" policies, protecting documents and other storage media (including portable IT devices) by tidying them away out of sight (for example in locked drawers, filing cabinets, safes or a Bank vault). Workers may be required to memorize their passwords or use a password manager instead of writing passwords on paper. Computers are vulnerable to outages caused by power cuts, accidental disconnection, flat batteries, brown-outs, surges, spikes, electrical interference and electronic failures. Physical information security controls to address the associated risks include: fuses, no-break battery-backed power supplies, electrical generators, redundant power sources and cabling, "Do not remove" warning signs on plugs, surge protectors, power quality monitoring, spare batteries, professional design and installation of power circuits plus regular inspections/tests and preventive maintenance.
Scientific Working Group – Imaging Technology
The Scientific Working Group on Imaging Technology was convened by the Federal Bureau of Investigation in 1997 to provide guidance to law enforcement agencies and others in the criminal justice system regarding the best practices for photography, videography, and video and image analysis. This group was terminated in 2015. == History == As technology has advanced through the years, law enforcement has needed to stay abreast of emerging technological advances and use these in the investigation of crime. A factor that is considered when new technology is used in these investigations is the determination of whether the use of that new technology will be admissible in court. The judicial system in the United States currently has two standards used in the determination of admissibility of testimony regarding scientific evidence; the Daubert Standard and the Frye Standard. These standards guide the courts in the admissibility of testimony derived from the use of new technologies and scientific techniques. The Federal Bureau of Investigation (FBI), seeking to address possible admissibility issues with such testimony, established Scientific Working Groups starting with the Scientific Working Group on DNA Analysis and Methods (SWGDAM) in 1988. The goal of these groups is to open lines of communication between law enforcement agencies and forensic laboratories around the world while providing guidance on the use of new and innovative technologies and techniques. This guidance can lead to admissibility of evidence and/or testimony, provided proper methods in the collection of evidence and its analysis are employed. In 2009, the National Academy of Sciences released a report entitled, "Strengthening Forensic Science in the United States: A Path Forward." This report addresses many topics including challenges and disparities facing the forensic science community, standardization, certification of practitioners and accreditation of their respective entities, problems related to the interpretation of forensic evidence, the need for research, and the admission of forensic science evidence in litigation. This report mentions the Scientific Working Groups and their role in forensic science. The history of imaging technology (photography) can be said to extend back to the times of Chinese philosopher Mo-Ti (470-390 B.C.) who described the principles behind the precursor to the camera obscura. Since that time, advances in imaging technology include the discovery of chemical photographic processes in the 19th century and the use of electronic imaging technology that includes analog video cameras and digital video and still cameras. By the mid 1990s, it was apparent that technologically advanced camera systems such as these were being adopted for use in the criminal justice system. This led the FBI to convene a meeting of individuals working in the field of forensic imaging from federal, state, local, and foreign law enforcement, and the U.S. military, during the summer of 1997. As a result of this meeting, the Technical Working Group on Imaging Technology was formed from a core group of the meeting’s participants. This group later became the Scientific Working Group on Imaging Technology (SWGIT). Prior to the inception of SWGIT, some law enforcement agencies began adopting digital imaging technology. Due to the lack of guidelines or standards, some of these agencies attempted to replace all their film cameras with substandard digital cameras, only to find that the equipment they had purchased was not capable of accomplishing the mission for which they were intended. At that time only low resolution digital cameras were deemed affordable by some law enforcement agencies. Some of these agencies were forced to rethink their photography procedures and reverted to the use of film cameras or replaced their low-resolution digital cameras with higher quality, more expensive equipment. Also lacking at this early stage was guidance on how to store and archive digital image files. When SWGIT was formed, it was tasked with providing guidance to law enforcement and others in the criminal justice system by releasing documents that describe the best practices and guidelines for the use of imaging technology, to include these concerns and many others. This group was terminated in 2015. == SWGIT Function == During its existence, SWGIT provided information on the appropriate use of various imaging technologies including both established and new. This was accomplished through the release of documents such as the SWGIT Best Practices documents. As changes in technology occurred, these documents were updated. Over the course of its existence, SWGIT collaborated with other Scientific Working Groups to address imaging concerns within their respective disciplines. SWGIT published over 20 documents that dealt specifically with imaging technology. SWGIT also co-published documents with the Scientific Working Group on Digital Evidence (SWGDE) that had a component or components dealing with imaging technology. SWGIT also provided imaging technology guidance and input for documents from the Scientific Working Group on Friction Ridge Analysis, Study and Technology (SWGFAST), the Scientific Working Group for Forensic Document Examination (SWGDOC), and the Scientific Working Group on Shoeprint and Tire Tread Evidence (SWGTREAD). SWGIT assisted the American Society of Crime Lab Directors/Laboratory Accreditation Board (ASCLD/LAB) in the writing of definitions and standards for the accreditation of Digital and Multimedia Evidence sections of crime laboratories. In addition to releasing documents, SWGIT members disseminated best practices for law enforcement professionals where imaging technology was concerned. This was carried out by attending and lecturing at meetings and conferences of various forensic organizations that included: The American Academy of Forensic Sciences (AAFS) The International Association for Identification (IAI) The Law Enforcement and Emergency Services Video Association (LEVA) The American Society of Crime Lab Directors (ASCLD) The SWGIT membership consisted of approximately fifty scientists, photographers, instructors, and managers from more than two dozen federal, state, and local law enforcement agencies, as well as from the academic and research communities. The membership elected its officers from within. SWGIT was composed of the Executive Committee, four standing subcommittees, and ad hoc subcommittees appointed on an as-needed basis. The standing subcommittees were: Image Analysis, Forensic Photography, Video, and Outreach. This group was terminated in 2015. == Legal Proceedings == The following court cases have conducted Daubert v. Merrell Dow Pharm., Inc., 509 U.S. 579 (1993) hearings in which SWGIT best practice documents have been cited as accepted protocol, methodology, and as generally accepted techniques in the forensic community: U. S. v. Rudy Frabizio, U.S. District Court, Boston, MA, 2008 (Image Authentication) U.S. v. Nobumochi Furukawa, U.S. District Court, Minnesota, 2007 (Video Authentication) U.S. v. John Stroman, U.S. District Court, South Carolina, 2007 (Facial Comparison Analysis) State of Texas v. Daniel Day, Tarrant County Texas, 2005 (Camera Identification to Images) U.S. v. Marc Watzman, U.S. District Court, Northern Illinois, 2004 (Video Authentication) U.S. v. McKreith, U.S. District Court, Fort Lauderdale, FL, 2002 (Photo comparison of shirt) == Termination == This group was unfunded by the FBI in 2015.
Branch number
In cryptography, the branch number is a numerical value that characterizes the amount of diffusion introduced by a vectorial Boolean function F that maps an input vector a to output vector F ( a ) {\displaystyle F(a)} . For the (usual) case of a linear F the value of the differential branch number is produced by: applying nonzero values of a (i.e., values that have at least one non-zero component of the vector) to the input of F; calculating for each input value a the Hamming weight W {\displaystyle W} (number of nonzero components), and adding weights W ( a ) {\displaystyle W(a)} and W ( F ( a ) ) {\displaystyle W(F(a))} together; selecting the smallest combined weight across for all nonzero input values: B d ( F ) = min a ≠ 0 ( W ( a ) + W ( F ( a ) ) ) {\displaystyle B_{d}(F)={\underset {a\neq 0}{\min }}(W(a)+W(F(a)))} . If both a and F ( a ) {\displaystyle F(a)} have s components, the result is obviously limited on the high side by the value s + 1 {\displaystyle s+1} (this "perfect" result is achieved when any single nonzero component in a makes all components of F ( a ) {\displaystyle F(a)} to be non-zero). A high branch number suggests higher resistance to the differential cryptanalysis: the small variations of input will produce large changes on the output and in order to obtain small variations of the output, large changes of the input value will be required. The term was introduced by Daemen and Rijmen in early 2000s and quickly became a typical tool to assess the diffusion properties of the transformations. == Mathematics == The branch number concept is not limited to the linear transformations, Daemen and Rijmen provided two general metrics: differential branch number, where the minimum is obtained over inputs of F that are constructed by independently sweeping all the values of two nonzero and unequal vectors a, b ( ⊕ {\displaystyle \oplus } is a component-by-component exclusive-or): B d ( F ) = min a ≠ b ( W ( a ⊕ b ) + W ( F ( a ) ⊕ F ( b ) ) {\displaystyle B_{d}(F)={\underset {a\neq b}{\min }}(W(a\oplus b)+W(F(a)\oplus F(b))} ; for linear branch number, the independent candidates α {\displaystyle \alpha } and β {\displaystyle \beta } are independently swept; they should be nonzero and correlated with respect to F (the L A T ( α , β ) {\displaystyle LAT(\alpha ,\beta )} coefficient of the linear approximation table of F should be nonzero): B l ( F ) = min α ≠ 0 , β , L A T ( α , β ) ≠ 0 ( W ( α ) + W ( β ) ) {\displaystyle B_{l}(F)={\underset {\alpha \neq 0,\beta ,LAT(\alpha ,\beta )\neq 0}{\min }}(W(\alpha )+W(\beta ))} .
Hybrid cryptosystem
In cryptography, a hybrid cryptosystem is one which combines the convenience of a public-key cryptosystem with the efficiency of a symmetric-key cryptosystem. Public-key cryptosystems are convenient in that they do not require the sender and receiver to share a common secret in order to communicate securely. However, they often rely on complicated mathematical computations and are thus generally much more inefficient than comparable symmetric-key cryptosystems. In many applications, the high cost of encrypting long messages in a public-key cryptosystem can be prohibitive. This is addressed by hybrid systems by using a combination of both. A hybrid cryptosystem can be constructed using any two separate cryptosystems: a key encapsulation mechanism, which is a public-key cryptosystem a data encapsulation scheme, which is a symmetric-key cryptosystem The hybrid cryptosystem is itself a public-key system, whose public and private keys are the same as in the key encapsulation scheme. Note that for very long messages the bulk of the work in encryption/decryption is done by the more efficient symmetric-key scheme, while the inefficient public-key scheme is used only to encrypt/decrypt a short key value. == Implementations and standards == All practical implementations of public key cryptography today employ a hybrid system. Examples include the TLS protocol and the SSH protocol, that use a public-key mechanism for key exchange (such as Diffie-Hellman) and a symmetric-key mechanism for data encapsulation (such as AES). The OpenPGP file format and the PKCS#7 file format are other examples. Hybrid Public Key Encryption (HPKE, published as RFC 9180) is a modern standard for generic hybrid encryption. HPKE is used within multiple IETF protocols, including Messaging Layer Security (MLS), Oblivious DNS over HTTPS, Oblivious HTTP, Privacy Preserving Measurement, and TLS Encrypted Client Hello. Envelope encryption is an example of a usage of hybrid cryptosystems in cloud computing. In a cloud context, hybrid cryptosystems also enable centralized key management. == Example == To encrypt a message addressed to Alice in a hybrid cryptosystem, Bob does the following: Obtains Alice's public key. Generates a fresh symmetric key for the data encapsulation scheme. Encrypts the message under the data encapsulation scheme, using the symmetric key just generated. Encrypts the symmetric key under the key encapsulation scheme, using Alice's public key. Sends both of these ciphertexts to Alice. To decrypt this hybrid ciphertext, Alice does the following: Uses her private key to decrypt the symmetric key contained in the key encapsulation segment. Uses this symmetric key to decrypt the message contained in the data encapsulation segment. == Security == If both the key encapsulation and data encapsulation schemes in a hybrid cryptosystem are secure against adaptive chosen ciphertext attacks, then the hybrid scheme inherits that property as well. However, it is possible to construct a hybrid scheme secure against adaptive chosen ciphertext attacks even if the key encapsulation has a slightly weakened security definition (though the security of the data encapsulation must be slightly stronger). == Envelope encryption == Envelope encryption is term used for encrypting with a hybrid cryptosystem used by all major cloud service providers, often as part of a centralized key management system in cloud computing. Envelope encryption gives names to the keys used in hybrid encryption: Data Encryption Keys (abbreviated DEK, and used to encrypt data) and Key Encryption Keys (abbreviated KEK, and used to encrypt the DEKs). In a cloud environment, encryption with envelope encryption involves generating a DEK locally, encrypting one's data using the DEK, and then issuing a request to wrap (encrypt) the DEK with a KEK stored in a potentially more secure service. Then, this wrapped DEK and encrypted message constitute a ciphertext for the scheme. To decrypt a ciphertext, the wrapped DEK is unwrapped (decrypted) via a call to a service, and then the unwrapped DEK is used to decrypt the encrypted message. In addition to the normal advantages of a hybrid cryptosystem, using asymmetric encryption for the KEK in a cloud context provides easier key management and separation of roles, but can be slower. In cloud systems, such as Google Cloud Platform and Amazon Web Services, a key management system (KMS) can be available as a service. In some cases, the key management system will store keys in hardware security modules, which are hardware systems that protect keys with hardware features like intrusion resistance. This means that KEKs can also be more secure because they are stored on secure specialized hardware. Envelope encryption makes centralized key management easier because a centralized key management system only needs to store KEKs, which occupy less space, and requests to the KMS only involve sending wrapped and unwrapped DEKs, which use less bandwidth than transmitting entire messages. Since one KEK can be used to encrypt many DEKs, this also allows for less storage space to be used in the KMS. This also allows for centralized auditing and access control at one point of access.
Cognos ReportNet
Cognos ReportNet (CRN) was a web-based software product for creating and managing ad hoc and custom-made reports. ReportNet was developed by the Ottawa-based company Cognos (formerly Cognos Incorporated), an IBM company. The web-based reporting tool was launched in September 2003. Since IBM's acquisition of Cognos, ReportNet has been renamed IBM Cognos ReportNet like all other Cognos products. ReportNet uses web services standards such as XML and Simple Object Access Protocol and also supports dynamic HTML and Java. ReportNet is compatible with multiple databases including Oracle, SAP, Teradata, Microsoft SQL server, DB2 and Sybase. The product provides interface in over 10 languages, has Web Services architecture to meet the needs of multi-national, diversified enterprises and helps reduce total cost of ownership. Multiple versions of Cognos ReportNet have since been released by the company. Cognos ReportNet was awarded the Software and Information Industry Association (SIIA) 2005 Codie awards for the "Best Business Intelligence or Knowledge Management Solution" category. CRN's capabilities have been further used in IBM Cognos 8 BI (2005), the latest reporting tool. CRN comes with its own software development kit (SDK). == Launch == Early adopters of Cognos ReportNet for their corporate reporting needs included Bear Stearns, BMW and Alfred Publishing. Around this same time of launch, Cognos competitor Business Objects released version 6.1 of its enterprise reporting tool. Cognos ReportNet has been successful since its launch, raising revenues in 2004 from licensing fees. == Controversy == Cognos rival Business Objects announced in 2005 that BusinessObjects XI significantly outperformed Cognos ReportNet in benchmark tests conducted by VeriTest, an independent software testing firm. The tests performed showed Cognos ReportNet performed poorly when processing styled reports, complex business reports and combination of both. The tests reported a massive 21 times higher report throughput for BusinessObjects XI than Cognos ReportNet at capacity loads. Cognos soon dismissed the claims by stating Business Objects dictated the environment and testing criteria and Cognos did not provide the software to participate in benchmark test. Cognos later performed their own test to demonstrate Cognos ReportNet capabilities. == Components == Cognos Report Studio – A Web-based product for creating complex professional looking reports. Cognos Query Studio - A Web-based product for creating ad-hoc reports. Cognos Framework Manager – A metadata modeling tool to create BI metadata for reporting and dashboard applications. Cognos Connection – Main portal used to access reports, schedule reports and perform administrator activities. == Versions == Cognos ReportNet 1.1 – Java EE-style professional web-based authoring tool. (base version) Cognos ReportNet IBM Special Edition – comes with an embedded version of IBM WebSphere as its application server and IBM DB2 as its data store. Cognos Linux – for Intel-based Linux platforms.
Topincs
Topincs is a software for rapid development of web databases and web applications. It is based on LAMP and the semantic technology Topic Maps. A Topincs web database makes information accessible through browsing very much like a Wiki. Editing a page on a subject is done through forms rather than markup editing. A web database can be tailored into a web application to provide specific user groups a contextualized approach to the data. All modeling and development tasks are performed in the web browser. No other development tools are necessary. The server requires Apache, MySQL and PHP. The client works on any standards-compliant web browser on desktops, laptops, tablets, and mobile phones. The layout is automatically adjusted to smaller screens. The programmatic access to data is done via a virtual object-oriented programming interface which is set up over the schema in a few minutes. It is interpreted rather than generated. Portions of the database can be pulled into memory to accelerate bulk access. == Features == Browseable data High-quality web forms Little to no programming Development done in the browser, no other tools required Client runs in any standard-compliant web browser Virtual object-oriented programming interface User interface adjusts to screen size Supports desktops, laptops, tablets, and mobile phones Flexible data modeling == Challenges == Requires rethinking the development process and dropping many hard learned habits Requires a familiarity with two ISO standards ISO 13259 and 19756 Forms cannot be easily adjusted in layout and behavior Server installation difficult and prone to error == License == Topincs can be used in a private network for any purpose for free. The use in a public network is restricted to non-commercial applications.
Change data capture
In databases, change data capture (CDC) is a set of software design patterns used to determine and track the data that has changed (the "deltas") so that action can be taken using the changed data. The result is a delta-driven dataset. CDC is an approach to data integration that is based on the identification, capture and delivery of the changes made to enterprise data sources. For instance it can be used for incremental update of data loading. CDC occurs often in data warehouse environments since capturing and preserving the state of data across time is one of the core functions of a data warehouse, but CDC can be utilized in any database or data repository system. == Methodology == System developers can set up CDC mechanisms in a number of ways and in any one or a combination of system layers from application logic down to physical storage. In a simplified CDC context, one computer system has data believed to have changed from a previous point in time, and a second computer system needs to take action based on that changed data. The former is the source, the latter is the target. It is possible that the source and target are the same system physically, but that would not change the design pattern logically. Multiple CDC solutions can exist in a single system. === Timestamps on rows === Tables whose changes must be captured may have a column that represents the time of last change. Names such as LAST_UPDATE, LAST_MODIFIED, etc. are common. Any row in any table that has a timestamp in that column that is more recent than the last time data was captured is considered to have changed. Timestamps on rows are also frequently used for optimistic locking so this column is often available. === Version numbers on rows === Database designers give tables whose changes must be captured a column that contains a version number. Names such as VERSION_NUMBER, etc. are common. One technique is to mark each changed row with a version number. A current version is maintained for the table, or possibly a group of tables. This is stored in a supporting construct such as a reference table. When a change capture occurs, all data with the latest version number is considered to have changed. Once the change capture is complete, the reference table is updated with a new version number. (Do not confuse this technique with row-level versioning used for optimistic locking. For optimistic locking each row has an independent version number, typically a sequential counter. This allows a process to atomically update a row and increment its counter only if another process has not incremented the counter. But CDC cannot use row-level versions to find all changes unless it knows the original "starting" version of every row. This is impractical to maintain.) === Status indicators on rows === This technique can either supplement or complement timestamps and versioning. It can configure an alternative if, for example, a status column is set up on a table row indicating that the row has changed (e.g., a boolean column that, when set to true, indicates that the row has changed). Otherwise, it can act as a complement to the previous methods, indicating that a row, despite having a new version number or a later date, still shouldn't be updated on the target (for example, the data may require human validation). === Time/version/status on rows === This approach combines the three previously discussed methods. As noted, it is not uncommon to see multiple CDC solutions at work in a single system, however, the combination of time, version, and status provides a particularly powerful mechanism and programmers should utilize them as a trio where possible. The three elements are not redundant or superfluous. Using them together allows for such logic as, "Capture all data for version 2.1 that changed between 2005-06-01 00:00 and 2005-07-01 00:00 where the status code indicates it is ready for production." === Triggers on tables === May include a publish/subscribe pattern to communicate the changed data to multiple targets. In this approach, triggers log events that happen to the transactional table into another queue table that can later be "played back". For example, imagine an Accounts table, when transactions are taken against this table, triggers would fire that would then store a history of the event or even the deltas into a separate queue table. The queue table might have schema with the following fields: Id, TableName, RowId, Timestamp, Operation. The data inserted for our Account sample might be: 1, Accounts, 76, 2008-11-02 00:15, Update. More complicated designs might log the actual data that changed. This queue table could then be "played back" to replicate the data from the source system to a target. Data capture offers a challenge in that the structure, contents and use of a transaction log is specific to a database management system. Unlike data access, no standard exists for transaction logs. Most database management systems do not document the internal format of their transaction logs, although some provide programmatic interfaces to their transaction logs (for example: Oracle, DB2, SQL/MP, SQL/MX and SQL Server 2008). Other challenges in using transaction logs for change data capture include: Coordinating the reading of the transaction logs and the archiving of log files (database management software typically archives log files off-line on a regular basis). Translation between physical storage formats that are recorded in the transaction logs and the logical formats typically expected by database users (e.g., some transaction logs save only minimal buffer differences that are not directly useful for change consumers). Dealing with changes to the format of the transaction logs between versions of the database management system. Eliminating uncommitted changes that the database wrote to the transaction log and later rolled back. Dealing with changes to the metadata of tables in the database. CDC solutions based on transaction log files have distinct advantages that include: minimal impact on the database (even more so if one uses log shipping to process the logs on a dedicated host). no need for programmatic changes to the applications that use the database. low latency in acquiring changes. transactional integrity: log scanning can produce a change stream that replays the original transactions in the order they were committed. Such a change stream include changes made to all tables participating in the captured transaction. no need to change the database schema == Confounding factors == As often occurs in complex domains, the final solution to a CDC problem may have to balance many competing concerns. === Unsuitable source systems === Change data capture both increases in complexity and reduces in value if the source system saves metadata changes when the data itself is not modified. For example, some Data models track the user who last looked at but did not change the data in the same structure as the data. This results in noise in the Change Data Capture. === Tracking the capture === Actually tracking the changes depends on the data source. If the data is being persisted in a modern database then Change Data Capture is a simple matter of permissions. Two techniques are in common use: Tracking changes using database triggers Reading the transaction log as, or shortly after, it is written. If the data is not in a modern database, CDC becomes a programming challenge. === Push versus pull === Push: the source process creates a snapshot of changes within its own process and delivers rows downstream. The downstream process uses the snapshot, creates its own subset and delivers them to the next process. Pull: the target that is immediately downstream from the source, prepares a request for data from the source. The downstream target delivers the snapshot to the next target, as in the push model. === Alternatives === Sometimes the slowly changing dimension is used as an alternative method. CDC and SCD are similar in that both methods can detect changes in a data set. The most common forms of SCD are type 1 (overwrite), type 2 (maintain history) or 3 (only previous and current value). SCD 2 can be useful if history is needed in the target system. CDC overwrites in the target system (akin to SCD1), and is ideal when only the changed data needs to arrive at the target, i.e. a delta-driven dataset.