- A to Z Security Consulting from LG CNS (2) -
Have you ever experienced any kind of big disaster in your life?
Were there any minor signs signaling possible disaster that had been overlooked?
These situations can be applied to security breaches as well.
Today, as the second topic of A to Z Security Consulting from LG CNS, I’d like to talk about security information and event management solution which detects possible security threats from the smallest signs.
A to Z Security Consulting form LG CNS (1):
http://www.lgcnsblog.com/technology/countermeasures-to-card-security-issues-focusing-on-access-card-duplication/
Heinrich’s Law: There Are Always Symptoms before a Disaster
Working in a department for engineering and loss control at Travelers Insurance Company in the US, Herbert William Heinrich was statistically analyzing accidents in 1931. The result of the analysis showed that there were always minor signs before a major accident.
According to Heinrich, for every accident that causes a major injury, there are 29 accidents that cause minor injuries and 300 accidents that cause no injuries. This is called Heinrich’s Law.
Major accidents don’t just happen out of nowhere. It is well known that the sinking of the Titanic was a result of multiple minor mistakes such as speeding and a lack of supervision as well as the ignoring of over 20 warnings.
The data processing system is not that different from this kind of accidents. Although we only hear about major security breaches, minor violations and the symptoms for major accidents can commonly be seen around us. They all appear as weaknesses, but are often overlooked due to limited budgets and/or resources.
In order for us to prevent major accidents like the Titanic’s, we have to pay attention to the 300 minor symptoms to complement and monitor them. Are there any ways to manage these symptoms more easily? Let’s take a look.
What’s a Security Information and Event Management Solution?
The data processing systems we use perform a tremendous amount of work each day. They usually work well, but sometimes there are situations that can pose threats. There can also be actions that are normally done, but are considered threatening because of the causal relation between the action and other parts of the work.
For example, an authorized worker’s searching for client information, printing or copying documents, and then taking their laptop home with them to work more may seem like normal actions at work when you think of them individually.
The story becomes quite different once you connect these dots, though. If there’s an authorized worker who searches for client information excessively, prints it out, and goes home with it, we have to take a look at what’s going on. If for instance, such a pattern has lasted for a week or two, this could be seen as a threatening situation.
A security information and event management solution we’re going to learn about here is a solution which aims to analyze integrated data from multiple events and find the factors that may become security threats.
Methods and Other Issues to Consider for a Security Information and Event Management Solution
Method
Let’s take a closer look at the Security Information and Event Management Solution. The method of this solution can be specified into three major stages along with some other additional issues to consider.
Each stage has a major function: ‘data collection function’ which gathers the data from events taking place in various equipment, ‘storage and management function’ to bring about space efficiency while storing the gathered data, and ‘analysis function’ for the saved data. Besides these three functions, there are other additional issues including legal requirements and self-security.
The specifics of each stage and things to consider
Stage 1. Event data collection
How is data from events taking place on separate systems gathered?
Data processing systems internally record the information about instructions or program execution, and this record is called a ‘log’. You must have heard of the black boxes on aircrafts which hold all the operational recordings in case of accidents. Basically the record this black box holds can be understood as a log. This log is what a security information and event management solution collects in the first stage.
However, not only do these logs have different forms depending on the type of equipment and programs used, but they also use different communication methods. These differences have to be considered carefully beforehand.
For example, network equipment only uses network protocol, but servers manage logs using a file system. Security equipment tends to have a processing record in the form of a database, and some of them don’t have any log that can be sent out.
Even if there’s a log it may not hold enough information for analysis, and in that case the log from the existing equipment itself may have to be changed. Besides, the form of the subjected logs being imported must be checked in case they have completely different content, and the sizes of the logs should also be examined so that network and the system performance won’t be compromised by them.
Therefore, ‘how and what logs should we collect?’ is one of the most important questions to consider when using a security information and event management solution.
Stage 2. Log storage
The collected logs are saved within a security information and event management solution for analysis in the form of database(DB). There are diverse products with different methods and space management strategies.
To name a few, there are products that save logs in the form of relational DB for integrity, ones which use file DB for the fusibility, and others that focus on the speed with in-memory DB. It’s crucial to learn about the pros and cons of each type, because these differences affect the conditions for log analysis.
It is also important to decide how long the logs will be kept and how they’ll be managed as well as seeing if there’s enough space by checking file compression.
Stage 3. Log analysis
Security information and event management solutions have two standards for analysis that find security threats from the collected logs. One is ‘rule set’ and it checks for security violations from each piece of equipment. The other one is called ‘scenario’ and this combines the rules from multiple kinds of equipment and establishes a scenario based on their correlations to analyze it.
Existing simple analysis based on rule set
In other words, the ‘rule set’ analysis only checks if certain transactions or status fall under the threshold and are similar to the standards of general equipment like firewalls. The problem the rule set analysis has is that it’s not able to detect minor threats that don’t exceed the set threshold, because it only examines if the threshold has been breached or not. Another issue it has is that it only finds threats from only limited pieces of equipment such as the ones for network or security which explicitly show threats.
Scenario analysis aims to overcome the limits of rule set analysis. It doesn’t ignore the data under a set threshold, and it also examines normal transactions in relation to other symptoms in order to look into them more thoroughly.
For example, an executive searching for someone’s personal information may not seem like a threat at all. If however, a certain document was decrypted, printed, or e-mailed soon before or after searching for this information, this action could be considered highly suspicious and would have to be checked.
The ‘scenario analysis’ of security information and event management solution
As you see from the image above, the scenario analysis can filter certain actions that are within threshold but are circumstantially suspicious in a long term pattern. Though this method can examine threats through correlations among various pieces of equipment, its structure is quite complicated.
Scenarios need some time to be created, and the effort to build a more complete scenario should be continued even after a security information and event management solution has been established.
When we say a rule set or a scenario is well made, it means the result of its analysis can provide valuable information. For this reason, creating a better rule set and scenario is one of the key factors of a security information and event management solution.
Another thing to consider is the speed of the analysis, as the solution handles such large amounts of data. It’s important to make the right decision on whether or not the solution’s going to support certain functions like real-time searches or long/short-term searches.
Other Issues to Consider
Some of the most important issues to be considered other than the three major steps are legal requirements and self-security functions.
Firstly, the issues about legal requirements involve making a decision about if the solution is going to accept certain legal conditions in cases where the stored logs hold personal information.
If the collected logs include web logs, DB logs, and work program logs, this means they’re likely to hold personal information. Even if there isn’t any personal information among the collected logs right now, it may be included in the future once the domain of log collection expands. In this case, it’s important to consider the legal requirements unless you can guarantee to not collect any personal information in the future.
The key requirements are as followed:
- Records on access to personal information systems are kept for 6 months according to the Personal Information Protection Act.
- Records on changes in authority to personal information systems are kept for 3 years according to the the Personal Information Protection Act.
- The records must be erased once their storage period expires (in order to manage storage space)
Secondly, self-security is a function that checks if a basic security system is applied to a integrated security control system. Because the logs saved on the solution have a large amount of critical information, it’s important to consider how it’s going to identify people in order to grant them access, how complicated setting up and/or changing passwords is going to be, and if it’s going to use a secondary verification method in order to keep it safe from hacking.
Security Information and Event Management Solution in Reality and Its Limits
Cases on detecting internal information leaks
Security information and event management solutions were commonly used for audit evidence storage in the past, but now it’s being used more to detect internal information leaks.
Recently there have been multiple security incidents caused by current and former staff members’ internal information leaks. Not only are these accidents hard to detect because the staff leak information using legitimate authorities and actions at work, but they also tend to cause extensive damage.
Subject of technology leaks(Source: Industrial Intelligence Protection Center from National Information Service, Image from the ETNews article on November 24, 2014 at http://www.etnews.com/20141123000016)
Using a security information and event management solution with a selected black list for special precautions, it’s possible to prevent such cases or to minimize their damages.
The law also clearly states the necessity of regular checks and management as well as leaving and keeping evidence in logs. This means that the law sees the importance of the anticipatory activities to prevent accidents or minimize damages by regularly examining the logs and detecting early signs of threat, on top of the usual posterior actions which only store logs for audits. Such emphasis is in the same context with the idea of a security information and event management solution.
Security information and event management solutions can be a suitable and effective measure to respond to these legal conditions since it’s able to check logs scattered over multiple systems.
Limits of Security Information and Event Management Solutions
The security information and event management solution we learned today also has its limits. One thing is that this solution extracts analysis results from data in collected logs, and it needs plenty of data to do so. The accuracy of the analysis will be compromised if not enough data is collected. To prevent this problem, the security collecting solution has to support various collecting functions.
There’s also an issue involving the collection cycle for peripheral solutions. General equipment except for servers usually provides functions that are optimized for hardware performance. The problem here is that sending the logs to a security information and event management solution may cause performance degradation due to its massive data transmission process. In order to prevent this degradation, many limit the collection cycle down to once a day.
For this reason, there may be situations when the security information and event management solution can’t perform analysis immediately when needed. In order to solve this problem, it’s important to find the right collection cycle and also get the scenario and analysis cycle adjusted accordingly.
Today, we learned about security information and event management solution’s functions and what to consider when establishing one, as well as their usage and limits.
There’s one person that comes to my mind when I think of security information and event management solutions: It’s Sherlock Holmes. He can figure out exactly what’s going on with someone’s life only by looking for a quick moment. He may seem like just a master of deduction who can read everyone with a quick look. When we look closely at how he makes his observations, we realize he’s a person with a skill by which he combines tiny bits of seemingly unimportant information and comes up with a systematic analysis on people.
He and the security information and event management solution have something in common, since the solution combines 300 minor symptoms as well as important information in order to find security threats and predict possible major accidents.
Thank you for reading today’s posting on a security information and event management solution, the Sherlock Holmes in the world of security,
In the third posting of this series, we’ll take a look at medical data breaches and their prevention.
Written by Bae-Hyung Hwang, deputy department head, LG CNS Security Consulting Team