CISO

Enterprise Information Security

PCI DSS & Network Devices

by Leave a Comment

PCI DSS requirements say many things about network security to make the card holder data safe and protected when it is stored, transmitted & processed. How we can achieve the maximum level of security through network devices? PCI DSS requirement talk about installation and maintenance of infrastructure devices like firewalls, IPS, routers, switches, etc. How we are going to make them secure?

We will start with access control. We have to prevent unauthorized access to the scope through these devices. There should be strict policies and procedures to access these devices and data processing facilities. A two factor authentication is an ideal solution to to access these devices. Stricter procedures should be implemented to access the data processing facilities (Physical access to the devices). All the default passwords should be replaced with memorable and non-guessable strong passwords in the operational environment.  Access to this equipment should be restricted only to authorized person with unique user id so that the tracking is possible. Apart from this, access to console port and configuration ports must be restricted and controlled. All the unnecessary ports and protocols should be disabled. Also remote access to these devices should be encrypted and enable filtering on gateways.

Implement strict policies and procedures for the configuration changes and management. As the time passes we may require changes to the configuration of these devices for short term & permanent. The change request should contain the need for temporary changes and the duration the change needs to exist. After the requirement, the device should be brought back to the original configuration and must be reported to concerned authorities. Always vigilant during this time so that the bad guys exploit these changes  to access the card holder data or interrupt the operations. Always adhere to the standards to harden these devices (NIST / IEEE).  Keep up to date with latest patches released by vendors. Experiment them in the lab environment and bring them to operational environment as early as possible, maximum within one month.

As we know, PCI is very sensitive and critical industry. Even a single minute mistake can take a financial institution to bankrupt and a nation in to financial crisis, we have to keep us vigilant always to make things safer and protected. Hope we can have better sleep by taking all these but not limited to these measures. Whenever we have a new idea to make things better, experiment it, make it fool proof, and implement it for a safer tomorrow.

Profiling a Vendor of Visa/MasterCard Plastics and Holograms

by Leave a Comment

The cardholder data breach is not a new thing. It is been a nightmare for every CIO in the world. Dancho Danchev’s blog has an interesting article on how these compromised cardholder data is turned into a physical card. He is profiling a rougue plastic card vendor. His findings are listed below, specifically the cost part.

Translated vendor’s proposition:

Below you have prices and samples of my products.

Plastics – Blanks:

1-50 = 15each

51-100 = 14 each

101+ = 13 each

201+ = 12 each

Plastics – Embossed

1 and up = 20each

101+ = 18each

201+ = 17each

Minimum order: 200USD

Shipping to: USA, International orders(min $800 + shipping)

Plastics have UV Security print on Front and Back.

Holograms Stickers and Heatpress:

VISA – Silver/Gold

VISA mini – Silver/Gold

MasterCard – Silver/Gold

Minimum order on stickers: 500pcs

Minimum order on Heatpress: 1000pcs

$0.8 per hologram

PAYMENT:

Liberty Reserve (Prefered)

Western Union (500usd minimum + 8% WU fee)

Interesting?

Credits: This post has been reproduced from Dancho Danchev’s blog. Follow him onTwitter.

Dual Control or Segregation of Duties?

by 1 Comment

Many information security professionals, event at the senior level roles, are still getting the internal control mechanisms such as Dual Control and Segregation of duties wrong. I often see that they are confused between the concepts of Dual Control and Segregation of Duties. Both these controls are applied to prevent or reduce fraud but are slightly different in its objectives

FFIEC guidance on application access: Effective application access control can enforce both segregation of duties and dual control. (pg. 48)

ISO 27002   10.1.3  Segregation of Duties:  Care should be taken that no single person can access, modify or use assets without authorization or detection. The initiation of an event should be separated from it authorization. The possibility of collusion should be considered in designing the controls.

Segregation of Duties

Segregation of Duties address the splitting of various functions with in a process to different users so that it will not create an opportunity for a single user to perform conflicting tasks. The participation of two or more persons in a transaction creates a system of checks and balances and reduces the possibility of fraud considerably. So it is important for an organization to ensure that all tasks within a process has adequate separation.

Let us look at some use cases of segregation of duties

  • A person handling cash should not post to the accounting records
  • A loan officer should not disburse loan proceeds for loans they approved
  • Those who have authority to sign cheques should not reconcile the bank accounts
  • The credit card printing personal should not print the credit card PINs
  • Customer address changes must be verified by a second employee before the change
    can be activated.

In situations where the separation of duties are not possible, because of lack of staff, the senior management should set up additional measure to offset the lack of adequate controls.

To summarise, Segregation of Duties is about Separating the conflicting duties to reduce fraud in an end to end function.

Dual Control or Split Knowledge

Dual control enforces the concept of keeping a duo responsible for an activity. It requires more than one employee available to perform a task. It utilizes two or more separate entities (usually persons),
operating together, to protect sensitive functions or information. Whenever the dual control feature is limited to .something you know., it is often called split knowledge (such as part of the password, cryptographic keys etc.) This is typically used in high value transactions / activities (as per the organizations risk appetite) such as:

  • Approving a high value transaction using a special user account, where the password of this user account is split into two and managed by two different staff. Both staff should be present to enter the password for a high value transaction. This is often combined with the separation of duties principle. In this case, the posting of the transaction would have been performed by another staff. This leads to a situation where collusion of at least 3 people are required to make a fraud transaction which is of high value
  • Payment Card and PIN printing is separated by SOD principles. Now the organization can even enhance the control mechanism by implementing dual control / split knowledge. The card printing activity can be modified to require two staff to key in the passwords for initiating the printing process. Similarly, PIN printing authentication can also be made to be implemented with dual control. Many Host Security modules (HSM) comes with built in controls for dual controls where physical keys are required to initiate the PIN printing process.
  • Managing encryption keys is another key area where dual control / split knowledge to be implemented.

PCI DSS defines Dual Control as below. This is more from a cryptographic perspective, still useful

Dual Control: Process of using two or more separate entities (usually persons) operating in concert to protect sensitive functions or information. Both entities are equally responsible for the physical protection of materials involved in vulnerable transactions. No single person is permitted to access or use the materials (for example, the cryptographic key). For manual key generation, conveyance, loading, storage, and retrieval, dual control requires dividing knowledge of the key among the entities. (See also Split Knowledge).

Split knowledge: Condition in which two or more entities separately have key components that individually convey no knowledge of the resultant cryptographic key.

It is key for information security professionals to understand the differences between Dual Control and Separation of Duties. Both complement each other, but are not the same.

The rat race of vulnerability management

by Leave a Comment

Patch management is one among the major IT Security concerns most of the organizations are worried about. It is practically not possible to have a 100% of the IT infrastructure patched with all patches released by all the software vendors in the environment. Following are some of the key challenges faced by the organizations in achieving higher compliance towards the patch management

  • IT environments are heterogeneous with various software vendors are having different patching mechanisms
  • In addition to the operating systems, applications,application servers and application plugins are required to be patched as and when there are vulnerabilities identified. How often you patch Acrobat reader or 7 zip? What about that apache server running a small interface application?
  • Many Open source software tools have less reliable patch management mechanisms. How about a fork developed for a specific application? What about the application developed by an independent consultant? What about the support guarantees and vulnerability management clauses in the same? Not many open source companies are providing dedicated support. How about a particular plugin of your favourite open source content management system like Drupal, WordPress, Joomla or any similar ones? What if the plugin is already abandoned by the developer?
  • Limited understanding of IT Administrators about a specific patch as to whether it is applicable in the environment or not. DBA.s often consider that some of the patches are not applicable for the database they are running even though the vendor recommends the implementation.
  • Lack of effective coordination with IT and business functions like application administrators, DBAs, end users, business owners etc for applying specific patches like Oracle (DBA is concerned about it), IPS (business may not want a down time), Online Banking application (downtime & new compatibility is a concern for business) etc. It is true that many of the concerns can be tested and validated by respective group of people before patching the production systems; however, many consider it as a risk (from availability perspective) to apply patches in the production unless it is proved as a requirement.
  • Compatibility issues of underlying software. This is especially applicable in the case of browsers. Let us assume one of your application requires 2 months time to get it upgraded so as to have compatibility with the latest browser upgrade? How is it handled?

No software companies are releasing new versions of the software in every 6 months. So what are there software developers are doing? Most of them are developing patches for the weaknesses identified and release patches very often. Now, the challenges of an IT Security professional is to cope up with the above challenges and protect the organization from the vulnerabilities which are not patched, but publicly announced (many times the zero day ones as well). The organizations patch cycle may not meet the vendors patch release. For example, Patch Tuesdays from Microsoft are monthly. Adobe and Mozilla talks about it once in two weeks. Chrome does it much often. Then we have other vendors which does it on ad-hoc basis.

It is a very difficult process to maintain high patch management level This leaves the organization into partial darkness when it comes to vulnerability management. There are many solutions offered by software vendors, however, many of them work in isolation. For example, WSUS from Microsoft addresses only the MS patches and not acrobat or flash. Not many solutions address the application patches or *NIX patches. Databases patches are another in the list. Virtual patching is another solution put forward by many vendors to address majority of these problems.

IT IMHO, it is important for an organization to have a comprehensive Vulnerability Management plan which addresses most of the above challenges. The solution should address the requirements such as:

  • Discovering the vulnerabilities
  • Assess the vulnerabilities
  • Remediation of the vulnerabilities
  • Assess the compensating controls
  • Assess the post effects of the new patches

What are your thoughts on this? What are the challenges in your opinion and how often you get into this rat race?

Global Payments breach.initial review

by Leave a Comment

Security breaches are become a common thing these days. They hit the front page only when the size or importance of the breach become huge. The recent security breach at the Global Payments made its way to the front page for the oblivious reason, which is nothing but the size of the breach.

Initially the size of the breach is estimated to be 10 million, later it identified as 1.5 million credit cards are affected. Even a security breach of 1.5 million credit cards is not a good news for any credit card holder.You and I are possible victims of this security breach. Visa has issued the following statement about the breach

.Visa Inc. is aware of a potential data compromise incident at a third party entity affecting card account information from all major card brands. There has been no breach of Visa systems, including its core processing network VisaNet.

Visa has provided payment card issuers with the affected account numbers so they can take steps to protect consumers through independent fraud monitoring and, if needed, reissuing cards.

It.s important for U.S. Visa consumer cardholders to know they are protected against fraudulent purchases with Visa.s zero liability fraud protection policy, which exceeds federal safeguards. As always, Visa encourages cardholders to regularly monitor their accounts and to notify their issuing financial institution promptly of any unusual activity. Additional consumer security tips are available at www.VisaSecuritySense.com.

Every business that handles payment card information is expected to protect the security and privacy of their customers. financial information by adhering to the highest data protection standards. Visa also supports advanced security layers such as encryption, tokenization and dynamic authentication through EMV chip technology to further protect sensitive account information and minimize the impact of data compromises..

Global Payments said in a statement that while enough data was taken from each account to make fraudulent transactions, the cardholders. .names, addresses and social security numbers were not obtained by the criminals,. which may limit how the stolen data can be used.

How did it impact Global Payments

  • Trading has now been halted in Global Payments. stock. The stock has fallen down by 9% before that.
  • The card company removed Global Payments from its list of .approved. processors Sunday, a move that doesn.t prevent vendors who use the payment processor from making Visa transactions, but may damage the processor.s reputation among its customers.
  • VISA strips PCI Compliance status from Global Payments
  • Penalties would be imposed on Global Payments in due course of time.

It is rumoured that the breach includes card numbers and track data. As per the PCI compliance requirements, the track data should not be stored. If it is not being stored, as they used to be PCI compliant, how is that a hacker obtain the same? Web based transactions never uses track data and the only possible area of compromise is the POS based transactions. As they are not expected to store the track data, the only possible way is to obtain the same during transmission. Now the other catch, PCI demands encryption for transmission when data is transmitted over public networks.

It would be interesting to see how the attackers got this data, if the rumour turns to be true.

PCI DSS compliance and Password policy

by 2 Comments

Usernames and passwords is still the major method of authenticating users to the systems. It would be difficult to find someone without a user name and password in the workplace. In addition, personal usernames and passwords often come into picture when people access various websites and private emails. Proper use of the usernames and passwords are important to ensure accountability of the activities performed by the users. This post is to revisit the security best practices on the username and password policies and how it relates to the PCI DSS compliance requirements.

Standard for Usernames

It is important for an organization to have the usernames built in accordance with a pre-defined standard. This will help the business to quickly identify who is the owner of a particular user name and helps the organization to quickly resolve issues in case of a troubleshooting or identify the user in case of a malicious activity. It should be communicated with in the organization so that the privilege assignments would be easy for individual users.

Imagine a situation where an organization has around 10 John.s in a 100 employee company. If all they have usernames like John1, John2 etc. how difficult it would be for someone to share a folder and assign required privilege to the right John?

Consider the username password combination as a public and private key pair where the username is public to everyone and the password is private to the user. This helps everyone easily identify who did what without much hassles and enables a faster audit trial review.

Some of the common username formats include:

  • First initial of the first name and complete last name
  • Complete first name dot complete last name.
  • Employee number with predefined prefixes

Password Policy

After the username standard is defined, the next key step is defining the password policy which defines the private or undisclosed part of the authentication mechanism. The use of password ensures the accountability of any actions performed by a user account and the owner of the user account is held responsible for the activities performed by the said user. Due to this reason, it is important for an organization to ensure to ensure that the passwords are strong and follows best practices. Some of the key components of a good password policy follows

Password Strength, occasionally part of the password standard

  • Alphanumeric passwords, special characters if needed based on the risk posture
  • Minimum 8 characters or more
  • Not to write the passwords in a clear text form like in paper, sticky notes etc. or in text editors
  • If stored electronically, use cryptographic controls to protect the same
  • Password is a private information and thus it should be kept confidential.
  • Password sharing not to be allowed
  • Not easily guessable passwords like spouses name, kids name, birthdays etc.
  • Not a word from common dictionary (think about dictionary attacks)
  • The username should not be used as the password
  • Use of uppercase and lowercase characters
  • Change the password frequently, ideally within 60-90 days of the new password creation
  • Change the password if it is known to anyone else

The above list is not an exhaustive list of password policy components. Many of these items to be considered only after assessing the security situation of your company. Passwords are not the single line of defence against identity attacks but a key step towards protecting one.s account.

PCI Compliance

Now let us look at the PCI compliance requirements related to Password policy. The Requirement 8 -  Assign a unique ID to each person with computer access is the key section where the username and password requirements are detailed. Two of the key controls are listed below from a number of items from requirement 8

  • 8.1 – Assign all users a unique ID before allowing them to access system components or
    cardholder data.
  • 8.5.8 . Do not use group, shared, or generic accounts and passwords.

The PCI DSS is drafted to include all the requirements related to password security so that the merchants and service provider will employ proper controls to restrict and identify the access to card holder environment. At first glance, the operations of creating unique user IDs may seem to be a time consuming task with few benefits when multiple employees may perform the exact same functions.

I often get questions from people asking why we can.t have just one user account or email account for a group of people? It is important from a PCI DSS or Card holder perspective that the users are identified when they access the cardholder data such is what has been accessed and when. The PCI Data Security Standard is taking proper measures with these requirements to ensure that Merchants protect themselves from the following concerns.

Without having a unique user id assigned to all users, merchants could face the following challenges:

  • Unable to find who performed what on the systems or data
  • The use of audit trials to identify who performed a change or deletion of information
  • Implement the access controls based on the job functionalities or job roles

It is important from the organization perspective that individual usernames and passwords are assigned to every user of the system and thus ensuring accountability of the actions being performed by the employees. this will ensure that you don.t have to fight with the QSA during the audit, but more importantly, it will allow you to pin point who did what. Each organization will need to determine a Username and Password Policy based on specific business needs, risk mitigation process or regulatory requirements. What is most important is that a policy exists and the employees understand and follow it consistently.

Cloud solutions & PCI DSS Compliance

by Leave a Comment

Businesses are increasing its dependence on cloud computing solutions. PCI DSS compliance is often a concern for many organizations when considering cloud or virtualized solutions. As mentioned in one of my earlier post, .If you do not store cardholder data in public cloud, then it is possible to reach compliance with PCI DSS.. It is possible for an organization to build a private cloud or virtualized which is PCI Compliant.

Before we get into the compliance aspects of public cloud, let us see which entities are in the scope: .PCI DSS compliance includes merchants and service providers who accept, capture, store, transmit or process credit and debit card data.. PCI DSS guidance also defines what is .credit and debit card data. exactly. PAN, CVV, etc represent examples of cardholder data while (for example) the name only does not.

A key step in PCI DSS implementation is Scoping and Scope Reduction where the card holder environment is segmented to reduce the control implementation scope. In reality, .Without adequate network segmentation the entire network is in scope of the PCI DSS assessment, as per PCI DSS 2.0.. So what would be the case with cloud computing?. By the above definition, Cloud Computing could be considered as a Flat Network or un-segmented network.

These 5 Essential Cloud Characteristics are a good test of whether a particular service provider is indeed a cloud provider.

  • On-demand self-service
  • Broad network access
  • Resource pooling (Location independence)
  • Rapid elasticity
  • Measured service

Essentially, cloud-based is not the same as simply web-based. Let us look at use case, if a stand alone web server is hacked does it impact you if it does not belong to you? In the case of a cloud based solution, if one webserver in the cloud which shares the resources is compromised, it is highly likely that the associated services are vulnerable and thus the risk status is high.

Now let us review some of the controls which are more relevant in terms cloud computing:

.As referenced in Requirement 12.8, all service providers with access to cardholder data (including shared hosting providers) must adhere to the PCI DSS. In addition, Requirement 2.4 states that shared hosting providers must protect each entity.s hosted environment and data. Therefore, shared hosting providers must additionally comply with the requirements in this Appendix. .

Requirement A.1: .Shared hosting providers must protect the cardholder data environment

.If the merchant shares cardholder data with a service provider, the merchant must ensure that there is an agreement with that service provider that includes their acknowledgement that the third party processor/service provider is responsible for the security of the cardholder data it possesses. In lieu of a direct agreement, the merchant must obtain evidence of the provider’s compliance with PCI DSS via other means, such as via a letter of attestation.. Source: CSA Alliance

Some challenges as outlined in the PCI SSC virtualization guidance:

.In addition to the challenges of defining scope and assigning responsibilities across a shared infrastructure, the inherent characteristics of many cloud environments present additional barriers to achieving PCI DSS compliance. Some of these characteristics include:

  • The distributed architectures of cloud environments add layers of technology and complexity to the environment.
  • Public cloud environments are designed to be public-facing, to allow access into the environment from anywhere on the Internet.
  • The infrastructure is by nature dynamic, and boundaries between tenant environments can be fluid.
  • The hosted entity has limited or no visibility into the underlying infrastructure and related security controls.
  • The hosted entity has limited or no oversight or control over cardholder data storage.
  • The hosted entity has no knowledge of ?who they are sharing resources with, or the potential risks their hosted neighbours may be introducing to the host system, data stores, or other  resources shared across a multi-tenant environment.

.In a public cloud environment, additional controls must be implemented to compensate for the inherent risks and lack of visibility into the public cloud architecture. A public cloud environment could, for example, host hostile out-of-scope workloads on the same virtualization infrastructure as a cardholder data environment. More stringent preventive, detective, and corrective controls are required to offset the additional risk that a public cloud, or similar environment, could introduce to an entity.s CDE.

These challenges may make it impossible for some cloud-based services to operate in a PCI DSS compliant manner. Consequently, the burden for providing proof of PCI DSS compliance for a cloud-based service falls heavily on the cloud provider, and such proof should be accepted only based on rigorous evidence of adequate controls.

As with all hosted services in scope for PCI DSS, the hosted entity should request sufficient assurance from their cloud provider that the scope of the provider.s PCI DSS review is sufficient, and that all controls relevant to the hosted entity.s environment have been assessed and determined to be PCI DSS compliant. The cloud provider should be prepared to provide their hosted customers with evidence that clearly indicates what was included in the scope of their PCI DSS assessment as well as what was not in scope; details of controls that were not covered and are therefore the customer.s responsibility to cover in their own PCI DSS assessment; details of which PCI DSS requirements were reviewed and considered to be ?in place? and ?not in place; and confirmation of when the assessment was conducted.

Any aspects of the cloud-based service not covered by the cloud provider.s PCI DSS review should be identified and documented in a written agreement. The hosted entity should be fully aware of any and all aspects of the cloud service, including specific system components and security controls, which are not covered by the provider and are therefore the entity.s responsibility to manage and assess

References

  • CSA Alliance presentations
  • PCI SSC virtualization guidance

How to be PCI compliant . small merchants

by Leave a Comment

PCI DSS Compliance is a very hot topic these days. With the number of card data leakage incidents, every organization which cares about the reputation wants to know how to be PCI Compliant. Few days back someone asked me about it again, How to be PCI Compliant?

My first answer to them is nothing but to ensure that no card data is stored if they don.t need them. Today, many retail outlets, clinics, restaurant chains and many others keep the card numbers stored in their databases, application logs etc. Is there a need for it? No, not really. Storing the card numbers potentially leads to the card data leakage. PCI DSS aims at reducing the card data storage. If there is no solid business reason to have the card numbers stored, card numbers should not be stored.

In most cases, the card numbers are stored only for the reference purpose and is never really used for any settlements with the corresponding banks. So if the card numbers stored are just going to be stored in the database without ever using it, the cost of storing the card numbers are much higher than the potential business benefit it would bring.

So according to one of the risk management strategies, Risk Avoidance, the card numbers should not be stored. By storing the card numbers without protection measures you are not in compliance with the PCI DSS standard

So my first answer to the question .How to be PCI Compliant. is nothing but .avoid storing the cardholder data if not needed.. If you are facing challenges in achieving this, use the comments section to share your issues.

PCI Compliance hosting

by Leave a Comment

In my earlier post about PCI Compliant Hosting, we have discussed about the PCI Compliance areas to be looked into when considering a hosting service provider. In this post, I would like to cover the scope and some of the key aspects of hosting to ensure you have the compliance towards PCI DSS

Some of the key services which requires PCI Compliant hosting include:

  • E-Commerce service providers
  • Online Banking

    • The key requirements which should be available with with the hosting in order it to be PCI Compliant includes:

  • Firewall to separate the webserver from other webservers. Limit the open services and allow only secure communications. Also to separate any database servers from having access directly from the internet
  • Configure the webservers to have only the secure services allowed.
      • Enable HTTPS and use an SSL Certificate for web communications to your server
  • Enable SSH for terminal communication, instead of Telnet
  • Enable SFTP instead of FTP for file transfers
  • Configure your servers with unique usernames for all users who would be accessing your servers
  • Modify the vendor default settings to more secure configurations. The raw MYSQL server comes with no password for the root user, for example, which needs to be changed.
  • Implement encryption on critical database tables and store the encryption keys away from these servers
  • Configure your servers meet some baseline security configurations, examples can be found at CIS Security.
  • Use secure web applications if choose to use off the shelf product. Payment services or shopping carts such as PayPal, Google Checkout etc. can be of help and would make your liability very limited towards PCI Compliance
  • If you build web applications for the purpose, it should be code reviewed for security. Web Application Firewall should be set up to ensure web application security, you may use open source web application firewalls
  • Have a mechanism established for updating the security patches, it required for PCI Compliance

In the next post related to PCI Compliance, I would try posting a checklist for verifying if the hosting service is PCI compliant hosting.

Analysing the file integrity requirement of the PCI DSS

by Leave a Comment

I always wondered about the file integrity monitoring requirement of the PCI DSS standard. What is the purpose of this requirement? Is it a control or an compensating control. Isn.t it something similar to the much debated .code review or web application firewall. subject?

To understand more about this control, I looked into the control in detail. The file integrity requirement is referenced in two places of the standard.

First reference is under the secure audit trials (10.5) where it talks about the security of the audit trials. The statement 10.5.5 .Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). On a closer look, the intention of this requirement is to ensure that in case of a modification to the already logged data happens, it should generate an alert.

The challenge I face is that some of the logs are added into the databases and some others are into flat files. The solutions we looked into were unable to provide the desired result especially in the case of flat files.

This is when we looked into the requirement closely and for implementation purpose, we looked into this slightly differently. We reached a conclusion that the need is to protect the log/ audit trial data and the access to this data should be limited and to be set as read only for all users except the application which logs the trials. Any changes to the access control will trigger an alert. This mechanism gave us fairly good control on the audit trial files.

The second reference of the file integrity is at 11.5 in which the standard requires the monitoring of the critical files related to the operating system, application and the configuration related to the system. The examples giver were System executable, Application executable, Configuration and parameter files and the stored log files

Here the challenge we faced includes the non-availability of any FIM products to cover the operating systems we have. For example, operating systems such as Tru64 and Tandem. What we have done is to identify the critical files listed above, develop a cron process to run on a weekly basis and email the information about the baseline file. A manual verification of the same will be performed to check if there is a change in the file size and date of modification. If everything is fine, it is assumed that the file integrity is intact.

Though this may not be the best way to do it, we sure consider this as a cost effective way. How does your organization do this?