Monthly Archives: November 2019

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.

What You Need to Know About RAID Systems and Data Recovery

RAID is the term used for systems that employ multiple hard disk drives to form what the host computer sees as a single storage volume. RAID was initially introduced when larger capacity drives were particularly expensive and used a controller with an array of multiple cheaper, smaller capacity drives to form a large volume. This gave rise to the acronym RAID, standing for Redundant Array of Inexpensive Drives.

As well as boosting overall capacity it introduced the possibility of redundancy, where use of data ‘mirroring’ or ‘parity’ processes means that if an individual drive failed, this would not necessarily lead to a permanent loss of data. It also allowed the speed at which data could be written to and read from the array to be increased by ‘striping’ data across more than one drive simultaneously.

The vastly reduced ‘cost per GB’ of today’s high capacity drives has meant that RAID systems are now less about the cost of overall capacity, and more about increasing performance, maintaining system availability and securing data through redundancy. This has lead to the meaning of RAID now becoming accepted as a Redundant Array of Independent Drives.

A multiplicity of different RAID types has emerged indicated by numbers, i.e. RAID 0 or RAID 5. The various types each have differing attributes aimed at increasing performance or data security (or more commonly now a combination of the two), and each will be a compromise between these advantages and the resultant complexity and increased hardware costs. Each type has a wide range of independently configurable parameters meaning that the overall range of possible configurations can be bewildering.

RAID system failures can stem from a range of differing causes. Hardware failures of individual drives would normally be within the scope of the system to handle, but multiple drive failures, or failures of the controller can often lead to a system ‘crash’. Even the loss of a single drive, if not responded to in the correct manner by experienced personnel, can lead to a ‘catastrophic’ failure of the entire system. This illustrates that despite the concept of RAID having great strategic benefits for storage performance and data security, these will only be achieved where the system is understood, implemented and managed correctly.

Where a RAID system has failed for whatever reason, our the recovery procedure follows an established process:

o On-s Site or Remote Consultation and Technical Support – The first step is to gather information about the system and it’s configuration, the nature and cause of the failure, and the steps necessary to limit further data loss and initiate the recovery process. Prompt and effective support at this stage can make the recovery process easier and quicker and may even be sufficient to reinstate the system without the need for further intervention.

o In-lLab Diagnosis – The components of the system will be diagnosed for individual failure, and the data may be transposed to a recovery server for analysis to protect the original source. The next key stage is to ascertain the original configuration. This involves analysis to obtain such information as RAID Type, Disk Order, any Hot Spare Disks, Stripe Size, Parity Type and Rotation. Correct identification of these parameters is vital to recover data and may require the use of the latest applications and algorithms.

o Raid RAID Reconstruction and Commission – With the parameters established, the system can be returned to its original configuration and tested to confirm the integrity of the resulting data.

o Data Retrieval and Repair- – The data can now be recovered and checked with the client to confirm that a full recovery has been achieved. Arrangements at this stage will be made with the client to return the data in their preferred manner, either by recreating the original RAID system, or in any other form that suits their individual requirements.

o On-Site site Data and System Restoration – To complete the total RAID recovery service, the system can be reinstalled on-site by our technicians. As well as testing the system to confirm full restoration, clients can be advised as to the correct system management processes and procedures to prevent any further instances of data loss.