Siem Tools


Siem Tools

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

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. NNT is a leading provider of PCI DSS and general Security and Compliance solutions. As both a File Integrity Monitoring Software Manufacturer and Security Services Provider, we are firmly focused on helping organisations protect their sensitive data against security threats and network breaches in the most efficient and cost effective manner. Article Source for File Integrity Monitoring - View Security Incidents in Black and White or in Glorious Technicolor?: http://EzineArticles.com/7787946

Security Engineer's Dream Product a Reality Now With Full Visibility of Your IT Infrastructure

Security Engineer's Dream Product a Reality Now With Full Visibility of Your IT Infrastructure


Tim Peterson (not his real name)

, an IT Security Engineer with one of the largest oil companies in the Middle East, is very frustrated these days. His chief concern is the complexity in manual collection and correlation of security data for incident identification and remediation. He spends hours querying and writing scripts to collect and compile data after a security incident. For further forensics and root cause analysis of the security incident his team takes days. Many of the team members are already multi-tasking because of reduced workforce. Tim has secured his network with security devices like routers, web content filters, firewalls, IPS but still lacks full visibility in certain areas of security. His company is using multiple tools for collecting and managing information from these devices resulting in heterogeneous set of data for the Network Operations Center (NOC), Security Operations center (SOC) and audit team. There is lot of data redundancy also. Unfortunately these tools don't talk to each other nor share the data. They do not have collaboration and correlation capability. Recently Tim planned to add a Security Information and Event Management (SIEM) or SIM solution for log management but it would have made things more complex. SOC would be flooded with too much of log data. SOC targeted better incident identification and visibility by adding SIEM in their kit but didn't meet his requirement completely. He was worried of 'false positives' because just monitoring log data cannot deliver situational awareness related to critical security incidents. SIEM tools are blind to configuration changes of your devices and, what about the asset data, performance data and network behavioral anomaly? They are all important. Tim gets log alerts from the SIEM but how can he confirm a security breach with just log data; he needs more data. He need to correlate the log event alert with configuration data and see if any configuration changes where made, who made that changes, what changes where made. Did this effect the performance? Correlating these with asset policy violation, availability information and anomalous network behavior will make more sense of the threat pattern, in fact that's actionable intelligence. So what is the use of log data when they can't make sense? When they don't give situational awareness? End of the day Tim would get reports from the SIEM which are useful from compliance point of view. But what about security? Tim still would be giving a report of 'what happened' to his management, he don't even have full visibility on the extend of damage caused by the security incident. Tim need a solution which helps him to tell the management' what is happening', he wants to automate incident identification and need better visibility in all areas of his network security. He want to react faster and proactively respond to emerging security incidents before damage is caused. SecureVue from eIQnetworks delivered Tim's requirement. SecureVue is an Enterprise Security Management (ESM) solution for security, risk and audit automation. Collaboration and correlation is the central theme of SecureVue. SecureVue collects log, vulnerability, configuration, asset, performance and flow data from all devices, hosts, applications and databases across the enterprise in a single integrated platform enabling Tim to automate incident identification to drive efficiency and reduce management complexity. Now Tim can react faster and respond to emerging threats like policy violation, non standard processes, installation of rouge application, potential financial fraud, identity or data theft, etc. Tim is ready for any security threats as he knows his network is very secure now with the end-to-end root cause analysis, historical trends & pattern analysis, faster forensic analysis, SecureVue robust correlation engine and a single console view for security & compliance. SecureVue provide visibility across networks, servers and application layers to enable Tim's organizations to gain a comprehensive understanding of the infrastructure's overall security posture. SecureVue even made Tim's job secure! Article Source for Security Engineer's Dream Product a Reality Now With Full Visibility of Your IT Infrastructure: http://EzineArticles.com/2218689

Related keywords search:

Security Engineer, security engineer salary, security engineers inc, security engineered machinery, security engineer interview questions, security engineer jobs, security engineer job description, security engineering ross anderson, security engineer degree, security engineer resume, security engineering pdf, security engineer certifications, security engineering principles, security engineer requirements, security engineering officer, security engineer google, security engineer training, security engineer career path, security engineer average salary, security engineer google salary, security engineer analyst, security engineer amazon, security engineer at google, security engineer australia, security engineer apprenticeship, security engineer amazon salary, security engineer agency, security engineer abu dhabi, security engineer amsterdam, security engineer at facebook, security engineer apple, security engineer adobe, security alarm engineer jobs, security alarm engineer, security alarm engineer training, security alarm engineer job description, security application engineer, security alarm engineer codes, security alarm engineer courses

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

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. NNT is a leading provider of general Security and PCI DSS Compliance solutions. As both a PCI DSS Compliance Software Manufacturer and Security Services Provider, we are firmly focused on helping organisations protect their sensitive data against security threats and network breaches in the most efficient and cost effective manner. NNT solutions are straightforward to use and offer exceptional value for money, making it easy and affordable for organisations of any size to achieve and retain compliance at all times. Each product has the guidelines of the PCI DSS at its core, which can then be tailored to suit any internal best practice or external compliance initiative. Article Source of File Integrity Monitoring and SIEM - Why Layered Security Is Essential to Combat the APT: http://EzineArticles.com/7233001

SIEM Plus Correlation = Security?

SIEM Plus Correlation = Security?

Introduction Whether you are working from a SANS 20 Security Best Practices approach, or working with an auditor for SOX compliance or QSA for PCI compliance, you will be implementing a logging solution. Keeping an audit trail of key security events is the only way to understand what 'regular' operation looks like. Why is this important? Because it is only when you have this clear that you can begin to identify irregular and unusual activity which could be evidence of a security breach. Better still, once you have that picture of how things should be when everything is normal and secure, an intelligent log analysis system, aka SIM or SIEM, can automatically assess events, event volumes and patterns to intelligently judge on your behalf if there is potentially something fishy going on. Security Threat or Potential Security Event? Only with Event Correlation! The promise of SIEM systems is that once you have installed one of these systems, you can get on with your day job and if any security incident occurs, it will let you know about it and what you need to do in order to take care of it. The latest 'must have' feature set is correlation, but this must be one of the most over used and abused technology term ever! The concept is straightforward: isolated events which are potential security incidents (for example, 'IPS Intrusion Detected event') are notable but not as critical as seeing a sequence of events, all correlated by the same session, for example, an IPS Alert, followed by Failed Logon, followed by a Successful Admin Logon. In reality, these advanced, true correlation rules are rarely that effective. Unless you are in a very active security bridge situation, with an enterprise comprising thousands of devices, standard single event/single alert operation should work well enough for you. For example, in the scenario above, it should be the case that you DON'T have many intrusion alerts from your IPS (if you do, you really need to look at your firewalling and IPS defenses as they aren't providing enough protection). Likewise if you are getting any failed logins from remote users to critical devices, you should put your time and effort into a better network design and firewall configuration instead of experimenting with 'clever, clever' correlation rules. It's the KISS* principle applied to security event management. As such, when you do get one of the critical alerts from the IPS, this should be enough to initiate an emergency investigation, rather than waiting until you see whether the intruder is successful at brute forcing a logon to one of your hosts (by which time it is too late to head off any way!) Correlation rules perfected - but the system has already been hacked... In fact, consider this last point further, as it is where security best practices deviate sharply from the SIEM Product Managers pitch. Everyone knows that prevention is better than cure, so why is there so much hype surrounding the need for correlated SIEM events? Surely the focus should be on protecting our Information Assets rather than implementing an expensive and complicated appliance which may or may not sound an alarm when systems are under attack? Security Best Practices will tell you that you must implement - thoroughly - the basics. The easiest and most available security best practice is to harden systems, then operate a robust change management process. By eliminating known vulnerabilities from your systems (primarily configuration-based vulnerabilities but, of course, software-related security weaknesses too via patching) you provide a fundamentally well-protected system. Layer up other defense measures too, such as anti-virus (flawed as a comprehensive defense system, but still useful against the mainstream malware threat), firewalling with IPS, and of course, all underpinned by real-time file integrity monitoring and logging, so that if any infiltration does occur, you will get to know about it immediately. Conclusion Contemporary SIEM solutions offer much promise as THE intelligent security defense system. However, experience and the evidence of ever-increasing numbers of successful security breaches tell us that there is never going to be a 'silver bullet' for defending our IT infrastructure. Tools and automation can help of course, but genuine security for systems only comes from operating security best practices with the necessary awareness and discipline to expect the unexpected. *KISS - Keep It Super Simple NNT is a Manufacturer of Data Security solutions with a focus on helping organizations reduce risk & gain compliance with standards such as PCI DSS, Sarbanes Oxley, HIPPA and ISO 27k. Our software combines Device Hardening, SIEM Solution, File Integrity Monitoring and Change & Configuration Management in one easy to use and affordable solution. Article Source for SIEM Plus Correlation = Security?: http://EzineArticles.com/8066017

The Top Ten Criteria for a Security Information and Event Management (SIEM) Tool

The Top Ten Criteria for a Security Information and Event Management (SIEM) Tool



The Top Five Security Information Management Considerations


1. Ensure your log management layer is scalable. The log management layer is responsible for collecting the hoards of audit logs within your environment; it is not likely to filter any collected data. A key requirement for a Security Information Management (SIM) tool is to collect all audit log data so that a forensic investigation can be instigated if required. This layer therefore needs to scale to ensure full log collection.
2. Comprehensive Reporting. The log management layer should be able to report on activity that have been collected and identified within the accounting and audit logs. This should include running reports across up to 90 days of data. When you are collecting 10-20 million logs a day, this means the report will need to search upwards of 2 billion entries to retrieve the requested data for the report. It is also possible that you will run several reports a day.
3. Log Collection. It is important that you can collect logs from across the enterprise. The SIM layer should be a true forensic store of accounting and audit logs that allows a complete investigation, should the need arise. This means you want logs from firewalls, operating systems, applications, VPN's, Wireless Access Points etc. You therefore need to ensure that logs from all of these sources can be collected. Plain text logs stored in flat files are typically widely collected, as are Windows Event Logs. Event logs stored database's are not easily collected, so if you have any custom built or internal built applications ensure that these logs can be collected, as often these are stored in some type of database.
4. Chain of Custody. Ensure that you can validate that the logs have not been changed or modified, since they were collected from the source device. This should include collection of the logs in real-time from the original device, to ensure they are not modified before collection. This will allow for a forensically assured investigation, if required.
5. Trend Dashboards. It is important to be able see the trend of the volume of logs being collected. When collecting millions of logs a day, dash-boarding all of that data becomes pointless, as it will be a sea of information. However the size of the haystacks can tell you if there are problems. For example if you see a huge spike in failed logins, this tells you that there is something going on within the environment that is not normal.
The Top Five Security Event Management Considerations
1. Correlation. The main purpose of a SEM tool is to filter out the noise from the forensic data and flag up or alert up any suspect behaviour. It is critical therefore that your SEM can filter the rubbish down to useful information via complex correlation rules.
It is almost useless to alert on every failed login within your environment, as in large enterprises there are hundreds or thousands of these per day. However 100 failed logins within a five minute span, from an external IP address, for an administrative account should be alerted on and investigated. Your correlation engine should support easy creation of these multiple event rules.
2. Dashboards. Once you have generated a correlated alert, you want to place this information on a dashboard for easy user consumption. While it is not feasible to dashboard the forensic data that the SIM has collected, because of the sheer volume, it is recommended to dashboard the SEM alerts, as they are likely to be significantly less in number. On average you should be alerting on less than 1% of 1% of the collected logs that equates to a maximum of 200 alerts from 2 million collected audit logs. With a really strong correlation engine we would expect to eventually tune these alerts down to 2 a day, instead of 200 a day. You only want to be alerted on TRUE security or operational risks to your enterprise, not every time someone fat fingers their password.
3. Reporting. While reporting capability is critical for SIM, it is also important for SEM. The reports are not going to be as difficult to produce, for starters you are not reporting against billions of logs, more likely you are reporting against tens of thousands of alerts. But management will want to see that critical alerts have been responded to and resolved.
4. Log Normalisation. To create detailed alerts you will need to "understand" the raw logs, for example you will need to understand what part of the log string is the group name, if for example you want to alert when a user is added to an administrator group. Most vendors will create normalisation rules for the standard off the shelf applications, but you should be able to normalise your organisations custom log formats, without having to employ the vendors, likely to be expensive, professional service consultants.
5. Alert Management. As well as creating complex alerts based on correlation rules it should be possible to track the status of generated alerts. Has the Alert been resolved? What steps were taken after the alert was raised. A built in ticketing system or tight integration in to an existing ticketing system is a critical feature of a Security Event Management tool.
For more information please check out the Security Information and Event Management website [http://securityinformationeventmanagement.com/]
Article Source for The Top Ten Criteria for a Security Information and Event Management (SIEM) Tool: http://EzineArticles.com/expert/Joe_Womberman/1338363