File Integrity Monitoring – 3 Reasons Why Your Security Is Compromised Without It Part 1

Introduction
This is a 3 step series examining why File Integrity Monitoring is essential for the security of any business’ IT. This first section examines the need for malware detection, addressing the inevitable flaws in anti-virus systems.

Malware Detection – How Effective is Anti-Virus?
When malware hits a system - most commonly a Windows operating system, but increasingly Linux and Solaris systems are coming under threat (especially with the renewed popularity of Apple workstations running Mac OS X) - it will need to be executed in some way in order to do its evil deeds.
This means that some kind of system file – an executable, driver or dll has to be planted on the system. A Trojan will make sure that it gets executed without further user intervention by replacing a legitimate operating system or program file. When the program runs, or the OS performs one of its regular tasks, the Trojan is executed instead.

On a user workstation, 3rd party applications such as internet browsers, pdf readers and mundane user packages like MS Word or Excel have been targeted as a vector for intermediate malware. When the document or spreadsheet is opened, the malware can exploit vulnerabilities in the application, enabling malware to be downloaded and executed.

Either way, there will always be a number of associated file changes. Legitimate system files are replaced or new system files are added to the system.

If you are lucky, you won’t be the first victim of this particular strain of malware and your AV system – provided it has been updated recently – will have the necessary signature definitions to identify and stop the malware.

When this is not the case, and bear in mind that millions of new malware variants are introduced every month, your system will be compromised, usually without you knowing anything about it, while the malware quietly goes about its business, damaging systems or stealing your data.

FIM – Catching the Malware Other Anti-Virus Systems Miss
That is, of course, unless you are using file integrity monitoring.

Enterprise-level File Integrity Monitoring will detect any unusual filesystem activity. Unusual is important, because many files will change frequently on a system, so it is crucial that the FIM system is intelligent enough to understand what regular operation looks like for your systems and only flag genuine security incidents.

However, exclusions and exceptions should be kept to a minimum because FIM is at its best when it is operated in a ‘zero tolerance’ approach to changes. Malware is formulated with the objective that it will be effective, and this means it must both be successfully distributed and operate without detection.

The challenge of distribution has seen much in the way of innovation. Tempting emails with malware bait in the form of pictures to be viewed, prizes to be won and gossip on celebrities have all been successful in spreading malware. Phishing emails provide a convincing reason to click and enter details or download forms, and specifically targeted Spear Phishing emails have been responsible for duping even the most cybersecurity-savvy user.

Whatever the vector used, once malware is welcomed into a system, it may then have the means to propagate within the network to other systems.

So early detection is of paramount importance. And you simply cannot rely on your anti-virus system to be 100% effective, as we have already highlighted.

FIM provides this ‘zero tolerance’ to filesystem changes. There is no second-guessing of what may or may not be malware, guaranteeing that all malware is reported, making FIM 100% effective in detecting any breach of this type.

Summary
FIM is ideal as a malware detection technology as it is not prone to the ‘signature lag’ or ‘zero day vulnerabilities’ that are the Achilles’ Heel of anti-virus systems. As with most security best practices, the advice is always more is better, and operating anti-virus (even with its known flaws) in conjunction with FIM will give the best overall protection. AV is effective against legacy malware and its automated protection will quarantine most threats before they do any damage. But when malware does evade the AV, as some strains always will do, real-time FIM can provide a vital safety net.

Which File Integrity Monitoring Technology Is Best For FIM? File Integrity Monitoring FIM or SIEM FIM?

Introduction
Within the FIM technology market there are choices to be made. Agent-based or agentless is the most common choice, but even then there are both SIEM, and ‘pure-play’ FIM, solutions to choose between.


FIM – Agents or Agentless

There is never a clear advantage for either agent-based or agentless FIM. There is a balance to be found between agentless FIM and the arguably superior operation of agent-based FIM, offering

• Real-time detection of changes – agentless FIM scanners can only be effective on a scheduled basis, typically once every day
• Locally stored baseline data meaning a one-off full scan is all that is needed, while a vulnerability scanner will always need to re-baseline and hash every single file on the system each time it scans
• Greater security by being self-contained, whereas an agentless FIM solution will require a logon and network access to the host under test

Conversely, proponents of the Agentless vulnerability scanner will cite the advantages of their technology over an agent-based FIM system, including

• Up and running in minutes, with no need to deploy and maintain agents on end points, makes an agentless system easier to operate
• No need to load any 3rd party software onto endpoints, an agentless scanner is 100% self-contained
• Foreign or new devices being added to a network will always be discovered by an agentless scanner, while an agent-based system is only effective where agents have been deployed onto known hosts For these reasons there is no outright winner of this argument and typically, most organizations run both types of technology in order to benefit from all the advantages offered.

Using SIEM for FIM

Using SIEM technology is much easier to deal with. Similar to the agentless argument, a SIEM system may be operated without requiring any agent software on the endpoints, using WMI or native syslog capabilities of the host. However this is typically seen as an inferior solution the agent-based SIEM package. An agent will allow for advanced security functions such as hashing and real-time log monitoring.

For FIM, all SIEM vendors will rely on a combination of host object access auditing, combined with a scheduled baseline of the filesystem. The auditing of filesystem activity can give real-time FIM capabilities, but will require substantially higher resources from the host to operate this than a benign agent. The native auditing of the OS will not provide hash values for files so the forensic detection of a Trojan cannot be achieved to the extent that an enterprise FIM agent will do so.

The SIEM vendors have moved to address this problem by providing a scheduled baseline and hash function using an agent. The result is a solution that is the worst of all options – an agent must be installed and maintained, but without the benefits of a real-time agent!

Summary

In summary, SIEM is best used for event log analysis and FIM is best used for File Integrity Monitoring. Whether you then decide to use an agent-based FIM solution or an agentless system is tougher. In all likelihood, the conclusion will be that a combination of the two is going to be only complete solution.

File Integrity Monitoring – FIM and Why Change Management is the Best Security Measure You Can Implement

Introduction
With the growing awareness that cyber security is an urgent priority for any business there is a ready-market for automated, intelligent security defenses. The silver-bullet against malware and data theft is still being developed (promise!) but in the meantime there are hordes of vendors out there that will sell you the next best thing.

The trouble is, who do you turn to? According to, say, the Palo Alto firewall guy, his appliance is the main thing you need to best protect your company’s intellectual property, although if you then speak to the guy selling the FireEye sandbox, he may well disagree, saying you need one of his boxes to protect your company from malware. Even then, the McAfee guy will tell you that endpoint protection is where it’s at – their Global Threat Intelligence approach should cover you for all threats.

In one respect they are all right, all at the same time – you do need a layered approach to security defenses and you can almost never have ‘too much’ security. So is the answer as simple as ‘buy and implement as many security products as you can’?

Cyber Security Defenses– Can You Have Too Much of a Good Thing?
Before you draw up your shopping list, be aware all this stuff is really expensive, and the notion of buying a more intelligent firewall to replace your current one, or of purchasing a sandbox appliance to augment what your MIMEsweeper already largely provides, demands a pause for thought. What is the best return on investment available, considering all the security products on offer?

Arguably, the best value for money security product isn’t really a product at all. It doesn’t have any flashing lights, or even a sexy looking case that will look good in your comms cabinet, and the datasheet features don’t include any impressive packets per second throughput ratings. However, what a good Change Management process will give you is complete visibility and clarity of any malware infection, any potential weakening of defenses plus control over service delivery performance too.

In fact, many of the best security measures you can adopt may come across as a bit dull (compared to a new piece of kit for the network, what doesn’t seem dull?) but, in order to provide a truly secure IT environment, security best practices are essential.

Change Management – The Good, The Bad and The Ugly (and The Downright Dangerous)
There are four main types of changes within any IT infrastructure

• Good Planned Changes (expected and intentional, which improve service delivery performance and/or enhance security)
• Bad Planned Changes (intentional, expected, but poorly or incorrectly implemented which degrade service delivery performance and/or reduce security)
• Good Unplanned Changes (unexpected and undocumented, usually emergency changes that fix problems and/or enhance security)
• Bad Unplanned Changes (unexpected, undocumented, and which unintentionally create new problems and/or reduce security)

A malware infection, intentionally by an Inside Man or external hacker also falls into the last category of Bad Unplanned Changes. Similarly, a rogue Developer implanting a Backdoor into a corporate application. The fear of a malware infection, be it a virus, Trojan or the new buzzword in malware, an APT, is typically the main concern of the CISO and it helps sell security products, but should it be so?

A Bad Unplanned Change that unintentionally renders the organization more prone to attack is a far more likely occurrence than a malware infection, since every change that is made within the infrastructure has the potential to reduce protection. Developing and implementing a Hardened Build Standard takes time and effort, but undoing painstaking configuration work only takes one clumsy engineer to take a shortcut or enter a typo. Every time a Bad Unplanned Change goes undetected, the once secure infrastructure becomes more vulnerable to attack so that when your organization is hit by a cyber-attack, the damage is going to be much, much worse.

To this end, shouldn’t we be taking Change Management much more seriously and reinforcing our preventative security measures, rather than putting our trust in another gadget which will still be fallible where Zero Day Threats, Spear Phishing and straightforward security incompetence are concerned?

The Change Management Process in 2013 – Closed Loop and Total Change Visibility
The first step is to get a Change Management Process – for a small organization, just a spreadsheet or a procedure to email everyone concerned to let them know a change is going to be made at least gives some visibility and some traceability if problems subsequently arise. Cause and Effect generally applies where changes are made – whatever changed last is usually the cause of the latest problem experienced.
Which is why, once changes are implemented, there should be some checks made that everything was implemented correctly and that the desired improvements have been achieved (which is what makes the difference between a Good Planned Change and a Bad Planned Change).

For simple changes, say a new DLL is deployed to a system, this is easy to describe and straightforward to review and check. For more complicated changes, the verification process is similarly much more complex. Unplanned Changes, Good and Bad, present a far more difficult challenge. What you can’t see, you can’t measure and, by definition, Unplanned Changes are typically performed without any documentation, planning or awareness.

Contemporary Change Management systems utilize File Integrity Monitoring, providing a zero tolerance to changes. If a change is made – configuration attribute or to the filesystem – then the changes will be recorded.

In advanced FIM systems, the concept of a time window or change template can be pre-defined in advance of a change to provide a means of automatically aligning the details of the RFC (Request for Change) with the actual changes detected. This provides an easy means to observe all changes made during a Planned Change, and greatly improve the speed and ease of the verification process.

This also means that any changes detected outside of any defined Planned Change can immediately be categorized as Unplanned, and therefore potentially damaging, changes. Investigation becomes a priority task, but with a good FIM system, all the changes recorded are clearly presented for review, ideally with ‘Who Made the Change?’ data.

Summary
Change Management is always featured heavily in any security standard, such as the PCI DSS, and in any Best Practice framework such as SANS Top Twenty, ITIL or COBIT.

If Change Management is part of your IT processes, or your existing process is not fit for purpose, maybe this should be addressed as a priority? Coupled with a good Enterprise File Integrity Monitoring system, Change Management becomes a much more straightforward process, and this may just be a better investment right now than any flashy new gadgets?

Google+

File Integrity Monitoring – Use FIM to Cover All the Bases

Why use FIM in the first place?
Unlike anti-virus and firewalling technology, FIM is not yet seen as a mainstream security requirement. In some respects, FIM is similar to data encryption, in that both are undeniably valuable security safeguards to implement, but both are used sparingly, reserved for niche or specialized security requirements.

How does FIM help with data security?
At a basic level, File Integrity Monitoring will verify that important system files and configuration files have not changed, in other words, the files’ integrity has been maintained.

Why is this important? In the case of system files – program, application or operating system files – these should only change when an update, patch or upgrade is implemented. At other times, the files should never change.

Most security breaches involving theft of data from a system will either use a keylogger to capture data being entered into a PC (the theft then perpetrated via a subsequent impersonated access), or some kind of data transfer conduit program, used to siphon off information from a server. In all cases, there has to be some form of malware implanted onto the system, generally operating as a Trojan i.e. the malware impersonates a legitimate system file so it can be executed and provided with access privileges to system data.

In these instances, a file integrity check will detect the Trojans existence, and given that zero day threats or targeted APT (advanced persistent threat) attacks will evade anti-virus measures, FIM comes into its own as a must-have security defense measure. To give the necessary peace of mind that a file has remained unchanged, the file attributes governing security and permissions, as well as the file length and cryptographic hash value must all be tracked.

Similarly, for configuration files, computer configuration settings that restrict access to the host, or restrict privileges for users of the host must also be maintained. For example, a new user account provisioned for the host and given admin or root privileges is an obvious potential vector for data theft – the account can be used to access host data directly, or to install malware that will provide access to confidential data.

File Integrity Monitoring and Configuration Hardening
Which brings us to the subject of configuration hardening. Hardening a configuration is intended to counteract the wide range of potential threats to a host and there are best practice guides available for all versions of Solaris, Ubuntu, RedHat, Windows and most network devices. Known security vulnerabilities are mitigated by employing a fundamentally secure configuration set-up for the host.

For example, a key basic for securing a host is via a strong password policy. For a Solaris, Ubuntu or other Linux host, this is implemented by editing the /etc/login.defs file or similar, whereas a Windows host will require the necessary settings to be defined within the Local or Group Security Policy. In either case, the configuration settings exist as a file that can be analyzed and the integrity verified for consistency (even if, in the Windows case, this file may be a registry value or the output of a command line program).

Therefore file integrity monitoring ensures a server or network device remains secure in two key dimensions: protected from Trojans or other system file changes, and maintained in a securely defended or hardened state.

File integrity assured – but is it the right file to begin with?
But is it enough to just use FIM to ensure system and configuration files remain unchanged? By doing so, there is a guarantee that the system being monitored remains in its original state, but there is a risk of perpetuating a bad configuration, a classic case of ‘junk in, junk out’ computing. In other words, if the system was built using an impure source – the recent Citadel keylogger scam is estimated to have netted over $500M in funds stolen from bank accounts where PCs were set-up using pirated Windows Operating System DVDs, each one with keylogger malware included free of charge.

In the corporate world, OS images, patches and updates are typically downloaded directly from the manufacturer website, therefore providing a reliable and original source. However, the configuration settings required to fully harden the host will always need to be applied and in this instance, file integrity monitoring technology can provide a further and invaluable function.

The best Enterprise FIM solutions can not only detect changes to configuration files/settings, but also analyze the settings to ensure that best practice in security configuration has been applied.

In this way, all hosts can be guaranteed to be secure and set-up in line with not just industry best practice recommendations for secure operation, but with any individual corporate hardened build-standard.
A hardened build-standard is a pre-requisite for secure operations and is mandated by all formal security standards such as PCI DSS, SOX, HIPAA, and ISO27K.

Conclusion
Even if FIM is being adopted simply to meet the requirements of a compliance audit, there is a wide range of benefits to be gained over and above simply passing the audit.

Protecting host systems from Trojan or malware infection cannot be left solely to anti-virus technology. The AV blind-spot for zero day threats and APT-type attacks leaves too much doubt over system integrity not to utilize FIM for additional defense.

But preventing breaches of security is the first step to take, and hardening a server, PC or network device will fend off all non-insider infiltrations. Using a FIM system with auditing capabilities for best practice secure configuration checklists makes expert-level hardening straightforward.

Don’t just monitor files for integrity – harden them first!

Google+

File Integrity Monitoring - View Security Incidents in Black and White or in Glorious Technicolor?

The PCI DSS and File Integrity Monitoring
Using FIM, or file integrity monitoring has long been established as a keystone of information security best practices. Even so, there are still a number of common misunderstandings about why FIM is important and what it can deliver.

Ironically, the key contributor to this confusion is the same security standard that introduces most people to FIM in the first place by mandating the use of it - the PCI DSS.

PCI DSS Requirement 11.5 specifically uses the term 'file integrity monitoring' in relation to the need to "to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly"

As such, since the term 'file integrity monitoring' is only mentioned in requirement 11.5, one could be forgiven for concluding that this is the only part FIM has to play within the PCI DSS.

In fact, the application of FIM is and should be much more widespread in underpinning a solid secure posture for an IT estate. For example, other key requirements of the PCI data security standard are all best addressed using file integrity monitoring technology such as "Establish firewall and router configuration standards" (Req 1), "Develop configuration standards for all system components" (Req 2), "Develop and maintain secure systems and applications" (Req 6), "Restrict access to cardholder data by business need to know" (Req 7), Ensure proper user identification and authentication management for nonconsumer users and administrators on all system components" (Req 8), "Regularly test security systems and processes" (Req 11).
Within the confines of Requirement 11.5 only, many interpret this requirement as a simple 'has the file changed since last week?' and, taken in isolation, this would be a legitimate conclusion to reach. However, as highlighted earlier, the PCI DSS is a network of linked and overlapping requirements, and the role for file integrity analysis is much broader, underpinning other requirements for configuration hardening, configuration standards enforcement and change management.

But this isn't just an issue with how merchants read and interpret the PCI DSS. The new wave of SIEM vendors in particular are keen to take this narrow definition as 'secure enough' and for good, if selfish, reasons.

Do everything with SIEM - or is FIM + SIEM the right solution?

PCI requirement 10 is all about logging and the need to generate the necessary security events, backup log files and analyze the details and patterns. In this respect a logging system is going to be an essential component of your PCI DSS toolset.

SIEM or Event log management systems all rely on some kind of agent or polled-WMI method for watching log files. When the log file has new events appended to it, these new events are picked up by the SIEM system, backed up centrally and analyzed for either explicit evidence of security incidents or just unusual activity levels of any kind that may indicate a security incident. This approach has been expanded by many of the SIEM product vendors to provide a basic FIM test on system and configuration files and determine whether any files have changed or not.

A changed system file could reveal that a Trojan or other malware has infiltrated the host system, while a changed configuration file could weaken the host's inherently secure 'hardened' state making it more prone to attack. The PCI DSS requirement 11.5 mentioned earlier does use the word 'unauthorized' so there is a subtle reference to the need to operate a Change Management Process. Unless you can categorize or define certain changes as 'Planned', 'Authorized' or expected in some way, you have no way to label other changes as 'unauthorized' as is required by the standard.

So in one respect, this level of FIM is a good means of protecting your secure infrastructure. However, in practice, in the real-world, 'black and white' file integrity monitoring of this kind is pretty unhelpful and usually ends up giving the Information Security Team a stream of 'noise' - too many spurious and confusing alerts, usually masking the genuine security threats.

Potential security events? Yes.
Useful, categorized and intelligently assessed security events? No.

So if this 'changed/not changed' level of FIM is the black and white view, what is the Technicolor alternative? If we now talk about true Enterprise FIM (to draw a distinction from basic, SIEM-style FIM), this superior level of FIM provides file changes that have been automatically assessed in context - is this a good change or a bad change?

For example, if a Group Policy Security Setting is changed, how do you know if this is increasing or decreasing the policy's protection? Enterprise FIM will not only report the change, but expose the exact details of what the change is, was it a planned or unplanned change, and whether this violates or complies with your adopted Hardened Build Standard.

Better still, Enterprise FIM can give you an immediate snapshot of whether databases, servers, EPoS systems, workstations, routers and firewalls are secure - configured within compliance of your Hardened Build Standard or not. By contrast, a SIEM system is completely blind to how systems are configured unless a change occurs.

Conclusion

The real message is that trying to meet your responsibilities with respect to PCI Compliance requires an inclusive understanding of all PCI requirements. Requirements taken in isolation and too literally may leave you with a 'noisy' PCI solution, helping to mask rather than expose potential security threats. In conclusion, there are no short cuts in security - you will need the right tools for the job. A good SIEM system is essential for addressing Requirement 10, but an Enterprise FIM system will give you so much more than just ticking the box for Req 11.5.

Full color is so much better than black and white.

Google+

File Integrity Monitoring - FIM Could Just Save Your Business

Busted! The Citadel Cybercrime Operation

No guns were used, no doors forced open, and no masks or disguises were used, but up to $500Million has been stolen from businesses and individuals around the world. Reuters reported last week that one of the worlds biggest ever cybercrime rings has just been shut down. The Citadel botnet operation, first exposed in August last year, shows that anyone who wants to think big when it comes to cybercrime can make truckloads of money without even leaving home.

It's a familiar story of basic identity theft - PC's used to access on-line bank accounts were infiltrated by keylogging malware known as Citadel. This allowed security credentials to be stolen and then used to steal money from the victims' bank accounts. The malware had been in operation for up to 18 months and had affected up to 5 million PC's.

Like any malware, until it has been discovered, isolated and understood, anti-virus technology cannot tackle malware like Citadel. So-called 'zero day' malware can operate undetected until such time as an anti-virus definition has been formulated to recognize the malware files and remove them.

This is why file integrity monitoring software is also an essential defense measure against malware. File integrity monitoring or FIM technology works on a 'zero tolerance' basis, reporting any changes to operating system and program filesystems. FIM ensures that nothing changes on your protected systems without being reported for validation, for example, a Windows Update will result in file changes, but provided you are controlling when and how updates gets applied, you can then isolate any unexpected or unplanned changes, which could be evidence of a malware infection. Good FIM systems filter out expected, regular filechanges and focus attention on those system and configuration files which, under normal circumstances, do not change.

A victimless crime? Maybe not if you're a business that has been affected

In a situation like this, banks will usually try and unravel the problem between themselves - bank accounts that have been plundered will have had money moved to another bank account and another bank account and so on, and attempts will be made to recover any misappropriated funds. Inevitably some of the cash will have been spent but there is also a good chance that large sums can be recovered.
Generally speaking, individuals affected by identity theft or credit card fraud will have their funds reimbursed by their bank and the banking system as a whole, so it often feels like a victimless crime has been perpetrated.

Worryingly though, in this case, an American Bankers Association spokesman has been reported as saying that 'banks may require business customers to incur the losses'. It isn't clear as to why the banks may be seeking to place blame on business customers in this case. It is reported that Citadel was present in illegally pirated copies of Windows, so the victims may well be guilty of using counterfeit software, but who is to blame, and how far down the line can the blame be passed? The business customer, their supplier of the pirated software, the wholesaler who supplied the supplier?

Either way, any business user of on-line banking technology (and the consensus of estimates suggest that around half of businesses do at least 50% of their banking on-line, but that this is increasing year on year) should be concerned that protecting access to their bank account should be something they take seriously. It could well be that nobody else is looking out for you.

Conclusion

It may still be the case that 'Crime doesn't pay' but it seems that Cybercrime can pay handsomely. But for cybercrime to work, there needs to be a regular supply of victims and in this case, victims not using any kind of file integrity monitoring are leaving themselves exposed to zero-day malware which is currently invisible to anti-virus systems.

Good security is not just about installing AV software or even operating FIM but should be a layered and integrated approach. Leveraging security technology such as AV, FIM, firewalling, IDS and IPS should be done in conjunction with sound operating procedures to harden and patch systems regularly, verified with a separate auditing and governance function.
The biggest security threat is still complacency.

Google+

File Integrity Monitoring - Is FIM Better Than AV? Is a Gun Better Than a Knife?

Is a gun better than a knife?

I've been trying hard for an analogy, but this one kind of works. Which is better? A gun or a knife?
Both will help defend you against an attacker. A gun may be better than a knife if you are under attack from a big group of attackers running at you, but without ammunition, you are left defenseless. The knife works without ammunition and always provides a consistent deterrent, so in some respects, gives better protection than a gun.

Which is not a bad way to try and introduce the concept of FIM versus Anti-Virus technology. Anti-Virus technology will automatically eliminate malware from a computer, usually before it has done any damage. Both at the point at which malware is introduced to a computer, thorough email, download or USB, and at the instant at which a malware file is accessed, the AV will scan for known malware. If identified as a known virus, or even if the file exhibits characteristics that are associated with malware, the infected files can be removed from the computer.

However, if the AV system doesn't have a definition for the malware at hand, then like a gun with an empty magazine, it can't do anything to help.

File Integrity Monitoring by contrast may not be quite so 'active' in wiping out known malware, but - like a knife - it never needs ammo to maintain its role as a defense against malware. A FIM system will always report potentially unsafe filesystem activity, albeit with intelligence and rules to ignore certain activities that are always defined safe, regular or normal.

AV and FIM versus the Zero Day Threat

The key points to note from the previous description of AV operation is that the virus must either be 'known' i.e. the virus has been identified and categorized by the AV vendor, or that the malware must 'exhibit characteristics associated with malware' i.e. it looks, feels and acts like a virus. Anti-virus technology works on the principle that it has a regularly updated 'signature' or 'definition' list containing details of known malware. Any time a new file is introduced to the computer, the AV system has a look at the file and if it matches anything on its list, the file gets quarantined.

In other words, if a brand new, never-been-seen-before virus or Trojan is introduced to your computer, it is far from guaranteed that your AV system will do anything to stop it. Ask yourself - if AV technology was perfect, why would anybody still be concerned about malware?

The lifecycle of malware can be anything from 1 day to 2 years. The malware must first be seen - usually a victim will notice symptoms of the infection and investigate before reporting it to their AV vendor. At that point the AV vendor will work out how to counteract the malware in the future, and update their AV system definitions/signature files with details of this new malware strain. Finally the definition update is made available to the world, individual servers and workstations around the world will update themselves and will thereafter be rendered immune to this virus. Even if this process takes a day to conclude then that is a pretty good turnaround - after just one day the world is safe from the threat.

However, up until this time the malware is a problem. Hence the term 'Zero Day Threat' - the dangerous time is between 'Day Zero' and whichever day the inoculating definition update is provided.

By contrast, a FIM system will detect the unusual filesystem activity - either at the point at which the malware is introduced or when the malware becomes active, creating files or changing server settings to allow it to report back the stolen data.

Where is FIM better than AV?

As outlined previously, FIM needs no signatures or definitions to try and second guess whether a file is malware or not and it is therefore less fallible than AV.

Where FIM provides some distinct advantage over and above AV is in that it offers far better preventative measures than AV. Anti-Virus systems are based on a reactive model, a 'try and stop the threat once the malware has hit the server' approach to defense.

An Enterprise FIM system will not only keep watch over the core system and program files of the server, watching for malware introductions, but will also audit all the server's built-in defense mechanisms. The process of hardening a server is still the number one means of providing a secure computing environment and prevention, as we all know, is better than cure. Why try and hope your AV software will identify and quarantine threats when you can render your server fundamentally secure via a hardened configuration?
Add to this that Enterprise FIM can be used to harden and protect all components of your IT Estate, including Windows, Linux, Solaris, Oracle, SQL Server, Firewalls, Routers, Workstations, POS systems etc. etc. etc. and you are now looking at an absolutely essential IT Security defense system.

Conclusion

This article was never going to be about whether you should implement FIM or AV protection for your systems. Of course, you need both, plus some good firewalling, IDS and IPS defenses, all wrapped up with solid best practices in change and configuration management, all scrutinized for compliance via comprehensive audit trails and procedural guidelines.

Unfortunately there is no real 'making do' or cutting corners when it comes to IT Security. Trying to compromise on one component or another is a false economy and every single security standard and best practice guide in the world agrees on this.

FIM, AV, auditing and change management should be mandatory components in your security defenses.

File Integrity Monitoring – Database Security Hardening Basics

The Database – The Mother Lode of Sensitive Data

Being the heart of any corporate application means your database technology must be implemented and configured for maximum security. Whilst the desire to ‘get the database as secure as possible’ appears to be a clear objective, what does ‘secure as possible’ mean?

Whether you use Oracle 10g, Oracle 11g, DB2, Microsoft SQL Server, or even MySQL or PostgreSQL, a contemporary database is at least as complex as any modern server operation system. The database system will comprise a whole range of configuration parameters, each with security implications, including

• User accounts and password settings
• Roles and assigned privileges
• File/object permissions
• Schema structure
• Auditing functions
• Networking capabilities
• Other security defense settings, for example, use of encryption

Hardened Build Standard for Oracle, SQL Server, DB2 and others
Therefore, just as with any Windows or Linux OS, there is a need to derive a hardened build standard for the database. This security policy or hardened build standard will be derived from collected best practices in security configuration and vulnerability mitigation/remediation, and just as with an operating system, the hardening checklist will comprise hundreds of settings to check and set for the database.
Depending on the scale of your organization, you may then need hardening checklists for Oracle 10g, Oracle 11g, SQL Server, DB2, PostgreSQL and MySQL, and maybe other database systems besides.

Automated Compliance Auditing for Database Systems
Potentially, there will be a requirement to verify that all databases are compliant with your hardened build standard involving hundreds of checks for hundreds of database systems, so automation is essential, not least because the hardening checklists are complex and time-consuming to verify. There is also somewhat of a conflict to manage in as much as the user performing the checklist tests will necessarily require administrator privileges to do so. So in order to verify that the database is secure, you potentially need to loosen security by granting admin rights to the user carrying out the audit. This provides a further driver to moving the audit function to a secure and automated tool.

In fact, given that security settings could be changed at any time by any user with privileges to do so, verifying compliance with the hardened build standard should also become a regular task. Whilst a formal compliance audit might be conducted once a year, guaranteeing security 365 days a year requires automated tracking of security settings, providing continuous reassurance that sensitive data is being protected.

Insider Threat and Malware Protection for Oracle and SQL Server Database Systems
Finally, there is also the threat of malware and insider threats to consider. A trusted developer will naturally have access to system and application files, as well as the database and its filesystem. Governance of the integrity of configuration and system files is essential in order to identify malware or an insider-generated application ‘backdoor’. Part of the answer is to operate tight scrutiny of the change management processes for the organization, but automated file integrity monitoring is also essential if disguised Trojans, zero day malware or modified bespoke application files are to be detected.

File Integrity Monitoring – A Universal Solution to Hardening Database Systems
In summary, the most comprehensive measure to securing a database system is to use automated file integrity monitoring. File integrity monitoring or FIM technology serves to analyze configuration files and settings, both for vulnerabilities and for compliance with a security best practices-based hardened-build standard.
The FIM approach is ideal, as it is provides a snapshot audit capability for any database, providing an audit report within a few seconds, showing where security can be improved. This not only automates the process, making a wide-scale estate audit simple, but also de-skills the hardening exercise to an extent. Since the best practice knowledge of how to identify vulnerabilities and also which files need to be inspected is stored within the FIM tool report, the user can get an expert assessment of their database security without needing to fully research and interpret hardening checklist materials.

Finally, file integrity monitoring will also identify Trojans and zero-day malware that may have infected the database system, and also any unauthorized application changes that may introduce security weaknesses.
Of course, any good FIM tool will also provide file integrity monitoring functions to Windows, Linux and Unix servers as well as firewalls and other network devices, performing the same malware detection and hardening audit reporting as described for database systems.

For fundamentally secure IT systems, FIM is still the best technology to use.

Google+

File Integrity Monitoring and SIEM – Combat the Zero Day Threats and Modern Malware that Anti-Virus Systems miss

Introduction
It is well known that Anti-Virus technology is fallible and will continue to be so by design. The landscape (Threatscape?) is always changing and AV systems will typically update their malware signature repositories at least once per day in an attempt to keep up with the new threats that have been isolated since the previous update.

So how secure does your organization need to be? 80%? 90%? Because if you rely on traditional anti-virus defenses this is the best you can hope to achieve unless you implement additional defense layers such as FIM (file integrity monitoring) and SIEM (event log analysis).

Anti-Virus Technology – Complete With Malware Blind spots
Any Anti Virus software has an inherent weakness in that it relies on a library of malware ‘signatures’ to identify the viruses, Trojans and worms it is seeking to remove.

This repository of malware signatures is regularly updated, sometimes several times a day depending on the developer of the software being used. The problem is that the AV developer usually needs to have direct experience of any new strains of malware in order to counteract them. The concept of a 'zero day' threat is one that uses a new variant of malware yet to be identified by the AV system.

By definition, AV systems are blind to ‘zero day’ threats, even to the point whereby new versions of an existing malware strain may be able to evade detection. Modern malware often incorporates the means to mutate, allowing it to change its makeup every time it is propagated and so improve its effectiveness at evading the AV system.

Similarly other automated security technologies, such as the sandbox or quarantine approach, that aim to block or remove malware all suffer from the same blind spots. If the malware is new though – a zero day threat – then by definition there is no signature because it has not been identified before. The unfortunate reality is that the unseen cyber-enemy also knows that new is best if they want their malware to evade detection. This is evident by the fact that in excess of 10 million new malware samples will be identified in any 6 month period.

In other words most organizations typically have very effective defenses against known enemies – any malware that has been previously identified will be stopped dead in its tracks by the IPS, anti-virus system, or any other web/mail filtering with sandbox technology. However, it is also true that the majority of these same organizations have little or no protection against the zero day threat.

File Integrity Monitoring – The 2nd Line Anti-Virus Defense System for When Your Anti-Virus System Fails
File Integrity Monitoring serves to record any changes to the file system i.e. core operating system files or program components. In this way, any malware entering your key server platforms will be detected, no matter how subtle or stealthy the attack.

In addition FIM Technology will also ensure other vulnerabilities are screened out from your systems by ensuring best practices in securely configuring your Operating Systems have been applied.

For example, any configuration settings such as user accounts, password policy, running services and processes, installed software, management and monitoring functions are all potential vectors for security breaches. In the Windows environment, the Windows Local Security Policy has been gradually extended over time to include greater restrictions to numerous functions that have been exploited in the past but this in itself is a highly complex area to configure correctly. To then maintain systems in this secure configured state is impossible without automated file integrity monitoring technology.

Likewise SIEM or Security Information and Event Management systems are designed to gather and analyze all system audit trails/event logs and correlate these with other security information to present a true picture of whether anything unusual and potentially security threatening is happening.

It is telling that widely adopted and practiced security standards such as the PCI DSS place these elements at their core as a means of maintaining system security and verifying that key processes like Change Management are being observed.

Summary
Anti-virus technology is an essential and highly valuable line of defense for any organization. However, it is vital that the limitations and therefore vulnerabilities of this technology are understood and additional layers of security implemented to compensate. File Integrity Monitoring and Event Log Analysis are the ideal counterparts to an Anti-Virus system in order to provide complete security against the modern malware threat.

File Integrity Monitoring - FIM Agent Versus Agentless FIM

Introduction
The incessant escalation, both in malware sophistication and proliferation, means the need for fundamental file integrity monitoring is essential to maintain malware-free systems. Signature-based anti-virus technologies are too fallible and easily circumnavigated by zero-day malware or selectively created and targeted advanced persistent threat (APT) virus, worm or Trojan malware.

Any good security policy will recommend the use of regular file integrity checks on system and configuration files and best practice-based security standards such as the PCI DSS (Requirement 11.5), NERC CIP (System Security R15-R19), Department of Defense Information Assurance (IA) Implementation (DODI 8500.2), Sarbanes-Oxley (Section 404), FISMA - Federal Information Security Management Act (NIST SP800-53 Rev4) specifically mandate the need to perform regular checks for any unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

However, file-integrity monitoring needs to be deployed with a little advanced planning and understanding of how the file systems of your servers behave on a routine basis in order to determine what unusual and therefore potentially threatening events look like.

The next question is then whether an Agentless or Agent-based approach is best for your environment. This article looks at the pros and cons of both options.

Agentless FIM for Windows and Linux/Unix Servers
Starting with the most obvious advantage, the first clear benefit of an Agentless approach to file integrity monitoring is that it doesn't need any agent software to be deployed on the monitored host. This means that an Agentless FIM solution like Tripwire or nCircle will always be the quickest option to deploy and to get results from. Not only that but there is no agent software to update or potentially interfere with the server operation.

The typical Agentless file-integrity monitoring solution for Windows and Linux/Unix will utilize a scripted, command-line interaction with the host to interrogate the salient files. At the simplest end of the scale, Linux files can be baselined using a cat command and a comparison done with the subsequent samples to detect any changes. Alternatively, if a vulnerability audit is being performed in order to harden the server configuration, then a series of grep commands, used with regex expressions, will more precisely identify missing or incorrect configuration settings. Similarly, a Windows server can be interrogated using command line programs, for example, the net.exe program can be used to expose the user accounts on a system, or even assess the state or other attribute associated with a user account if piped with a find command e.g. net.exe users guest |find.exe /i "Account active" will return an "Account active Yes" or "Account active No" result and establish if the Guest account is enabled, a classic vulnerability for any Windows server.

Agent-Based File Integrity Monitoring
The key advantage of an Agent for FIM is that it can monitor file changes in real-time. Due to the agent being installed on the monitored host, the OS activity can be monitored and any file activity can be observed and changes recorded. Clearly any Agentless approach will need to be operated on a scheduled poll basis and inevitably there will be a pay-off between the frequency of polls being regular enough to catch changes as they happen, and the limiting the increased load on the host and network due to the monitoring. In practice polling is typically run once per day on most FIM solutions, for example Tripwire, and this means that you risk being anything up to 24 hours late to identify potential security incidents.

The second major advantage of an agent-based file-integrity solution is that the host does not need to be 'opened up' to allow monitoring. For example, all critical system and configuration files will always be protected by the host filesystem security, for example, the Windows System32 folder is always an 'Administrator Access Only' folder. In order to monitor the files in this location, any external scripted interaction will need to be provided with Admin rights over the Host and this immediately means that the host needs to be made accessible via the network and an additional User or Service Account needs to be provisioned with Admin privilege, potentially introducing a new security weakness to the system. By contrast, an Agent operates within the confines of the Host, just pushing out File Integrity changes as they are detected.

Finally having an Agent offers a distinct advantage over and above the Agentless approach in that it can offer a 'changes only' update across the network, and even then only when there is a change to report. The Agentless solution will need to run through its complete checklist of queries in order to make any assessment of whether changes have been identified and even using elaborate WMI or Powershell scripts still requires considerable resource usage on the host and the network when dragging results back.

Summary
Nobody likes installing and maintaining agents on their servers and, if this can be avoided, this is an attractive option to take.

File Integrity Monitoring and SIEM - Why Layered Security Is Essential to Combat the APT

Every time the headlines are full of the latest Cyber Crime or malware Scare story such as the Flame virus, the need to review the security standards employed by your organization takes on a new level of urgency.

The 2012 APT (Advanced Persistent Threat)
The Advanced Persistent threat differs from a regular hack or Trojan attack in that it is as the name suggests, advanced in technology and technique, and persistent, in that it is typically a sustained theft of data over many months.

So far the APT has largely been viewed as Government sponsored cyber-espionage in terms of the resources needed to orchestrate such an attack, such as the recent Flame malware which appears to have been a US or Israeli backed espionage initiative against Iran. However you always see the leading edge of technology become the norm a year later, so expect to see APT attacks reach the more mainstream, competitor-backed industrial espionage, and 'hacktivist' groups like Lulzsec and Anonymous adopting similar approaches.

The common vector for these attacks is a targeted spear phishing infiltration of the organization. Using Facebook, LinkedIn or other social media makes identification of targets much easier today, and also what kind of phishing 'bait' is going to be most effective in duping the target into providing the all-important welcoming click on the tasty links or downloads offered.

Phishing is already a well-established tool for Organized Crime gangs who will utilize these same profiled spear phishing techniques to steal data. As an interesting aside regarding organized crimes' usage of 'cybermuscle', it is reported that prices for botnets are plummeting at the moment due to oversupply of available robot networks. If you want to coerce an organization with a threat of disabling their web presence, arm yourself with a global botnet and point it at their site - DDOS attacks are easier than ever to orchestrate.

Something Must Be Done...

To be clear on what we are saying here, it isn't that AV or firewalls are no use, far from it. But the APT style of threat will evade both by design and this is the first fact to acknowledge - like the first step for a recovering alcoholic the first step is to admit you have a problem!

By definition, this kind of attack is the most dangerous because any attack that is smart enough to skip past standard defense measures is definitely going to be one that is backed by a serious intent to damage your organization (note: don't think that APT technology is therefore only an issue for blue chip organizations - that may have been the case but now that the concepts and architecture of the APT is in the mainstream, the wider hacker and hacktivist communities will already have engineered their own interpretations of the APT)
So the second fact to take on board is that there is an 'art' to delivering effective security and that requires a continuous effort to follow process and cross-check that security measures are working effectively.
The good news is that it is possible to automate the cross-checks and vigilance we have identified a need for, and in fact there are already two key technologies designed to detect abnormal occurrences within systems and to verify that security best practices are being operated.

FIM and SIEM - Security Measures Underwritten
File Integrity Monitoring or FIM serves to record any changes to the file system i.e. core operating system files or program components, and the systems' configuration settings i.e. user accounts, password policy, services, installed software, management and monitoring functions, registry keys and registry values, running processes and security policy settings for audit policy settings, user rights assignment and security options. FIM is designed to both verify that a device remains hardened and free of vulnerabilities at all time, and that the filesystem remains free of any malware.

Therefore even if some form of APT malware manages to infiltrate a critical server, well implemented FIM will detect file system changes before any rootkit protective measures that may be employed by the malware can kick in.

Likewise SIEM, or Security Information and Event Management, systems are designed to gather and analyze all system audit trails/event logs and correlate these with other security information to present a true picture of whether anything unusual and potentially security threatening is happening.
It is telling that widely adopted and practiced security standards such as the PCI DSS place these elements at their core as a means of maintaining system security and verifying that key processes like Change Management are being observed.

At the core of any comprehensive security standard is the concept of layered security - firewalling, IPS, AV, patching, hardening, DLP, tokenization, secure application development and data encryption, all governed by documented change control procedures and underpinned by audit trail analysis and file integrity monitoring. Even then with standards like the PCI DSS there is a mandated requirement for Pen Testing and Vulnerability Scanning as further checks and balances that security is being maintained.

Summary
In summary, your security policy should be built around the philosophy that technology helps secure your organizations' data, but that nothing can be taken for granted. Only by practicing continuous surveillance of system activity can you truly maintain data security, very much the essence of the Art of Layered Security.

File Integrity Monitoring And The Art of Layered Security

There is an art and a skill to building an effective security framework which requires a process, methodology and a set of tools that is right for your environment. The 'art' of good security and compliance requires an integrated and layered approach that can continuously monitor and evaluate all IT System activity in real-time to identify potential risks and threats from both internal and external sources.
The process, methodology and tools come together within this layered approach to provide the security needed to effectively and efficiently protect the environment and ensure a secure and compliant state. One of the best known examples of a formal security standard which utilises a layered security approach is the PCI DSS. PCI compliance requires adoption of all proven best practise measures for data security in order to protect cardholder data.

What is the Art of Layered Security?
The technology should be 'layered' to maximize security - including Perimeter Security, Firewall, Intrusion Detection, Penetration & Vulnerability Testing, Anti-Virus, Patch Management, Device Hardening, Change & Configuration Management, File Integrity Monitoring, Security Information and Event Log Management

The project should be delivered in a phased approach - understand the scope and environment, groups and types, priorities and locations to build up a picture of what 'good looks like' for the environment. Track all aspects of change and movement within this scope and understand how these relate to the change management process. Start small and grow, don't bite off more than you can chew
Utilize an integrated ecosystem of tools - events and changes happen all the time. Ensure the systems have the intelligence to understand the consequence of these events and what impact they may have had, whether the change was planned or unplanned and how it has impacted the compliant state.

File Integrity Monitoring vs. Anti Virus
File integrity monitoring works on a 'black and white' change comparison for a file system. FIM detects any changes to configuration settings or system files. In this way, FIM is a technology prone to false alarms, but is utterly comprehensive in detecting threats.

For each file, a complete inventory of file attributes must be collected, including a Secure Hash value. This way, even if a Trojan is introduced to the file system, this can be detected.

Anti-Virus technology works by comparing new files to a database of known malware 'signatures' and is therefore less prone to false alarms. However, by definition therefore AV can only detect known, previously identified malware and as a consequence is 'blind' to both 'zero day' threats and 'inside man' threats. Similarly, the Advanced Persistent Threat or APT favored for both Government-backed espionage and highly orchestrated intellectual property theft initiatives will always use targeted malware vectors, used sparingly to avoid detection for prolonged periods of time. In this way, Antivirus is also an ineffective defense against the APT.

The Art of Layered Security determines that both technologies should be used together to provide the best possible protection against malware. Each technology has advantages and disadvantages when compared to the other, but the conclusion is not that one is better than the other, but that both technologies need to be used together to provide maximum security for data.

The State of the Art in File Integrity Monitoring
The state of the art in FIM for system files now delivers real-time file change detection for Windows and Linux or Unix. In order to detect potentially significant changes to system files and protect systems from malware, it is essential to not just simply run a comparison of the file system once per day as has traditionally been the approach, but to provide an alert within seconds of a significant file change occurring.
The best File Integrity monitoring technology will also now identify who made the change, detailing the account name and process used to make changes, crucial for forensically investigating security breaches. It is good to know that a potential breach has occurred but even better if you can establish who and how the change was made.

How Logging And File Integrity Monitoring Technologies Can Augment Process and Procedure

Documentation Of PCI Compliance Processes? No Thanks!
Small Company PCI Compliance
For many Merchants subject to the PCI DSS, September is always a significant deadline for proving that compliance with the security measures of the PCI DSS has been met.

Unless you are a Tier 1 merchant (transacting in excess of 6 million card sales each year) and being audited by a PCI Security Standards Council QSA (Qualified Security Assessor) then you will be using the Self-Assessment route. SAQ D is the most commonly used Self Assessment Questionnaire for medium to large scale merchants.

Regardless of which type of Merchant your organization is classified as, the issues are firstly to put measures in place to meet compliance with the requirements, (so either install some security technology, e.g. a file integrity monitor, or define and document security procedures), and secondly, to prove that the measures are effective.

For smaller merchants, processes are typically not documented because there has previously been no need to do so. It stands to reason that for a small-scale IT Department, processes are commensurately simple to explain and operate, and as such, wont have needed to be documented. This being the case, however, it could also be argued that the documentation of processes, and proving that they work, is also very simple.
For instance, the change management process may be as simple as 'if any of us need to make a change, we discuss it or just send an email to the others for their information, then enter details onto a shared spreadsheet document'.

Clearly there is ample potential for human error in a process like this and for an 'inside man' hack to be perpetrated, even if the risk is low and the subsequent identification of the perpetrator straightforward.
So in this case, documenting the process is easy, but proving that it is infallible is another matter. There are too many scenarios where the process can fail, principally due to human error, but this also makes it inadequate as a means of ensuring changes cannot be made without detection. This is why many small companies lose sleep over PCI Compliance, worrying how far measures need to be taken and just how much security is enough?

Process Checks and Balances - Automated
PCI DSS Requirement 10 mandates the logging of all significant security events from the PCI estate, while PCI DSS Requirement 11.5 mandates the use of File Integrity Monitoring technology. For many organizations taking a 'checkbox' approach to PCI Compliance, the implementation of both technologies is seen as just another hassle to get through for the sake of the PCI DSS.

However, take a step back and look at the PCI DSS as a whole. The emphasis is on good security measures with sound best practices. In other words, for each dimension of security advocated by the PCI DSS there is a need to document and test related processes.

It therefore becomes clear that logging and FIM are not just overlay technologies to plug gaps left by the firewalling, hardening and antivirus measures, but integral means of verifying that your net security stance is effective.

Any file change or configuration change reported should be investigated and verified then acknowledged as an approved change. The process is automated, but simple and robust.
Similarly, a new account or privilege being assigned will be reported via your log management system, prompting an investigation and ultimately a record of the acknowledgment. As such, implementation of event log management and file integrity checker technologies can actually provide the processes needed for PCI DSS compliance. You could have a whole shelf full of change management processes and procedures, or alternatively, simply refer to your log management and File Integrity Monitoring reporting system.

PCI File Integrity Monitoring - Five More FAQs for PCI DSS Merchants

PCI DSS File integrity monitoring - What are the best options file integrity monitoring and what else do you need to know? How do you implement file integrity monitoring for Windows servers and Unix servers? How do you provide file integrity monitoring for firewall, routers, EPoS devices and servers? How does file integrity monitoring software work and what are the key features to look for? Should a file integrity monitor be agent-based or agentless?
The following is part two in a two part series listing the Top Ten FAQs for File-Integrity Monitoring that any PCI Merchant should be aware of.

1. For Log Files and Databases
Log files will change constantly on a busy server but it is important that log files are only changed in the manner expected. File integrity monitoring must be used in secure environments to protect important audit trails of system access and privilege usage and changes. The key is to only allow log files to increase in size and to alert if any changes are made to monitor for log file changes that may be an attempt to remove or change audit trail information - clearing log files or changing log files is classic hacker activity and should be monitored. Of course, event logs should be backed up centrally on a secure log server as a mandated requirement of the PCI DSS, PCI Requirement 10.
Similarly database files containing card data and personal information must be protected and an audit trail of all access and changes created. Again, database files will change constantly so the SHA1 approach will not be suitable. When using file integrity monitoring for SQL Server or file integrity monitoring for Oracle databases the best option is to log access and changes to specific tables and backup event logs centrally on your secure PCI DSS log server.

2. For System32 Folder
The most critical system files on a Windows server or EPoS till to monitor for file-integrity are within the WindowsSystem32 folder. All critical operating system programs, dll files and drivers reside within this location and it is therefore an ideal location for Trojans to reside. The threat is that a Trojan could be implanted onto the EPoS device or Card Data Handling Server (evading Anti-Virus detection because AV is only typically 70-90% effective). A file integrity monitor agent will gather a full inventory of all files within the System 32 folders and then make regular comparative checks subsequently to detect any changes made. Trojans are particularly difficult to find ordinarily because they masquerade as regular System32 program files, so they look and appear to act like the genuine program.
Similarly for Linux file integrity and Unix file integrity, all key program file systems such as the /usr/sys and /bin must be checked for integrity using a Linux or Unix file integrity monitor.

3. For Windows Updates
Windows Updates and patches for other applications will almost always involve updating program files, drivers and dll files. It is rarely clear which files will be modified by a patch and therefore any updates may generate numerous file changes across many folders and locations. Therefore it is vital that, while your file integrity monitor may track detailed changes to any one of a wide range of file attributes, you can also get good 'at a glance' summary information regarding whether a file has been added, deleted or changed.

4. Card Data and Card Data Folder File Integrity Monitoring
Where card data or other sensitive financial information is stored on an EPoS device or server the first line of defense is to limit access via folder and file rights and permissions. Even then, any user with Administrator rights will still be able to view the data and potentially copy out card numbers.
Therefore the best line of defense is to implement object access auditing on the file or folder. This will generate a full audit trail logging all access to the folder including the user account used to do so. Processing this audit trail with an intelligent, PCI event log analyzer will then ensure any unexpected access to the card data will generate an alert. For example, defining a rule to automatically distinguish between normal operations e.g. local system account access compared to a named account with administrator access.

5. PCI File Monitoring and Planned Changes/Change Acknowledgment
Of course, changes will need to be made to configuration files and system files every once in a while. It is important to keep security patches up to date and the PCI DSS mandates this should happen every month.
Operating a formal Change Management process is a key element of any IT security policy and therefore it is vital that your file integrity monitoring solution takes account of intended, planned changes. Any file changes detected as part of a planned change should be verified as part of your QA Testing and post implementation review processes to confirm that the right changes happened to the intended files only.
What about unplanned changes that are either emergency changes or those that for some reason bypass the change management process? These will all be detected and alerts raised by the file integrity monitor but there then needs to be an incident management process to investigate and either approve the changes or remediate them. The PCI DSS is not prescriptive as to how these processes should be managed so for some organizations they will use a full Service desk application to document and approve changes, whereas smaller organizations may just need a spreadsheet record of changes - use what works best for your company, not what you think a QSA will expect to see!

See part one of this series for other important file-integrity monitoring FAQs that any Merchant needing to be PCI DSS compliant should know

PCI File Integrity Monitoring - Five FAQs for PCI DSS Merchants

Requirement 11.5 of the PCI DSS specifies "the use of file-integrity monitoring tools within the cardholder data environment by observing system settings and monitored files, as well as reviewing results from monitoring activities." Additionally, "verify the tools are configured to alert personnel to unauthorized modification of critical files and to perform critical file comparisons at least weekly."
The following is part one in a two part series listing the Top Ten FAQs for File-Integrity Monitoring that any PCI Merchant should be aware of.

1. Agent-based file monitor or Agentless file monitor?
The gut reaction is that an agentless file integrity monitor is preferable - no software deployment required, no agent updates to apply and one less process running on your server. In theory at least, by enabling Object Access auditing via Group Policy or the Local Security Policy on the server or EPoS device it is possible to track file changes via Windows Events. You still need to work out how to get the local Windows Events back to a central log server, but then you will need to do this in order to comply with PCI DS requirement 10 anyway (and by the way, this will definitely need an agent to be deployed to any Windows server or Till).
However, the agent-based file-integrity monitor does have some distinct advantages over the agentless approach. Firstly, by using an agent, a PCI DSS file integrity monitoring template can be provided. This will comprise a blueprint for all folders and files that should be monitored to secure card data. In other words, a windows file monitoring agent is easier to set-up and configure.
Secondly, a windows file integrity monitor can actively inventory the file system. This approach allows the PCI DSS Merchant to demonstrate compliance with PCI DSS Requirement 11.5b by not just performing critical file comparisons weekly, but on a scheduled daily basis, or even in real-time for ultra secure environments.
Finally a file-integrity monitor for Windows that is agent-based can provide a Secure Hash Checksum of a file which is the only infallible means of guaranteeing the identity and integrity of binary system files. See FAQ 2 for more details.

2. Why use a Secure Hash Checksum for File Integrity Monitoring?
A secure hash checksum is generated by applying a hash algorithm to a file. The algorithm used is such that the resulting hash is unique. Even a one bit difference to a file will result in a significant variation to the hash. The most common algorithms used are SHA1 and MD5. SHA1 will generate a 160-bit hash value for a file, MD5 a 128-bit value. Recording and tracking changes to the Secure Hash of a file in conjunction with tracking changes to other file attributes such as permissions, modified date and size provides an infallible means of ensuring file integrity.

3. How to implement File Integrity Monitoring for Firewalls, Switches and Routers
Typically, any Firewall, Switch and Router will have a range of configuration settings which govern the performance, operation and crucially, the security of the device and the network it is protecting.
For instance, tracking changes to the running config and changes to the startup config of a router will reveal if any significant changes have been made that could affect the security of the network, Similarly tracking changes to permissions and rules on a firewall will ensure that perimeter security has not been affected.
Use of file integrity monitoring for firewalls, routers and switches is a key dimension for any change management procedure and essential for a comprehensive IT Security Policy.

4. File Integrity Monitoring for Web Applications
Web site Apps can generate lots of file changes that are not significant with respect to security of card data. For instance, images, page copy and page layouts may change frequently on an active ecommerce website, but none of these file changes will affect the security of the website. Depending on the web environment in use, there may be a mixture of ASP.NET (ascx, aspx, and asmx asdx files), Java (with js and jsp files), PHP, config or cnf files plus the more regular system files, such as dll and exe program files. It is essential to monitor file changes to all system files and config files for a car data application and web applications create more of a challenge due to the highly dynamic nature of the web app file system. A good file integrity monitor for web applications will have built-in intelligence to automatically detect significant file changes only and ignore changes to other files

5. File Integrity Monitoring for Web Applications
Web site Apps can generate lots of file changes that are not significant with respect to security of card data. For instance, images, page copy and page layouts may change frequently on an active ecommerce website, but none of these file changes will affect the security of the website. Depending on the web environment in use, there may be a mixture of ASP.NET (ascx, aspx, and asmx asdx files), Java (with js and jsp files), PHP, config or cnf files plus the more regular system files, such as dll and exe program files. It is essential to monitor file changes to all system files and config files for a car data application and web applications create more of a challenge due to the highly dynamic nature of the web app file system. A good file integrity monitor for web applications will have built-in intelligence to automatically detect significant file changes only and ignore changes to other files.

See part two in this series for more PCI DSS File Integrity Monitoring FAQs.