Information Security Incident Analysis

English language dictionaries define the word “Analysis” as “Separation of individual components from whole” (Antonym of Analysis is Synthesis)

I am astonished to see how Information Security Incident Analysts take this definition word for word!

I have seen that even senior information security professionals to expect and accept security incident analysis as very vague, and insufficient.

The above said analysis had following details,(this example is an incident triggered from a security device like IPS/IDS/firewall).

1. Source IP Address
2. Destination IP Address
3. Destination Port Number
4. Vendor Signature

Actually, for the preventive action to be taken some more information should be provided to the Security/Network/System admins. The information to be provided should be as follows -

1. Source IP Address
2. Destination IP Address
3. Source Port Number (enables you to detect if it is return traffic)
4. Destination Port Number
5. Vendor Signature and what it means
6. Protocol type (TCP/UDP/ICMP)
7. Application

SIEM tools readily provide this information without much effort.

So what is the Security Analysts' job then?

Along with providing the above mentioned information, he should create a "conclusion".

Well, here is an example of how we use misnomers in our day-to-day life. Security Analyst will have to actually “Synthesize” this data to create a meaningful “Conclusion”.

This resultant conclusion will be the same as original information but in human readable format and without payloads (keeping only meta-data, no more raw now) so as to take proper action, e.g. block or just create an alert for this type of incident to pass in future.

Socio-political Impact

The SIEM implementers and the related personnel who maintain the operations and security monitoring practices should be able to handle sociopolitical situations.

These people should be well skilled to handle other IT staff to sort out issues normally found to be created, when SOC team raises security incidents.

Chances are that these people get irritated due to the queries they are asked, particularly when the raised incident is a result of an activity conducted by IT staff, and do not indicate any risk.

There should be a clear guidelines for IT staff to declare any such activities beforehand and avoid such embarrassing queries being asked to them by SOC team.

Information security staff should understand the importance of awareness training to the IT staff and such sessions should periodically conducted, and also tested for its being in practice.

It is also important that SOC people should maintain their independence. The Process Flow should clearly be laid down, segregation of duties well defined and not clashing.

The SOC team should be responsible for opening a new case of incident, have rights to re-open the incident but should never be asked for the delay in closure of the incidents. Proper closure of incidents is important and since they should have rights to re-open incidents, their independence would be violated, if they are asked about the delay. This will also violate the requirement of proper segregation of duties.
  

SIEM system health

5. While SIEM is operational, the health of the SIEM system should be regularly monitored.  This can be done by using special health monitoring features in the SIEM.

Note that there could be a better way, it is best to find out the best way of checking system health, quickly and properly, by analyzing pros and cons of each. 

It is seen that the tech people use their skills and knowledge to lay down ways  to monitor system health in a very raw way, the best way should be to use automated tools which continuously monitor system health, could be found even from within SIEM tool itself, and if it isn't there, a third party open source tool can be used for the same, with no additional cost.

SIEM and Security Model

4. When implementing SIEM, one should have a clear understanding of information security model.
But what is information security model?
A security model covers how security is to be implemented or maintained.
It is a document which states everything about the requirements to implement, maintain and support all the information security policies.
As an example let us assume that an internet use policy states that only company employees who require the internet for business can have internet access, to only those websites which the user must have a business justification.
Now, our information security model will have a related table that describes who can have access to internet and what websites. (Required to impose the internet use policy, right?)
Now you also may have got the idea why I said “When implementing SIEM, one should have a clear understanding of information security model.”
SIEM itself has a function of near real time monitoring of security and hence it will have information about this model in the form of various configurations.

SIEM to IT Infra Communication

3. Ensure that all the devices/servers in your IT infrastructure get properly integrated.

One common problem here, even when the devices are integrated successfully, there are chances that they stop communicating with the SIEM collector. In such a scenario, there should be a mechanism to detect those devices/servers, which do not send logs to the SIEM.

This mechanism should strictly be automated and an email and/or SMS alert should be generated.

Most of the SIEM products should have this functionality, unfortunately, not used extensively. At some places it is seen that the failure of logs collection from devices/servers are checked regularly with manual methods.

Such a practice should be avoided, else the SIEM would no more be a near real time monitoring system, at least for these devices/servers.

Prepartion

2. Prepare a checklist of deliverables and requirements for integration
   

List down what exactly are the delierables, how SIEM will improve the IT infrastructure. (security and other value additions).
Also identify the basic requirements for integration of current IT infrastructure with SIEM. Check the mechanism of how the SIEM communicates with the integrated devices/servers, discuss it with SMEs to create a knowledge-base for reference which should not only include the so called Plan of Action (PoA) but also detailed diagnosis in case a standard PoA fails.
Most of the SIEM implementations seen are done with a random plan, the project may seem to be neat on paper, but it may contain some glitches like the one mentioned above, i.e. SMEs are not involved to the extent they should be. Again I am clearing here that the involvement of SMEs should not only be for technical problems that come across while implementation but also to enable the project to run smoothly for longer.

Preparation 1

Since a couple of years, SIEM (Security Information and Event Management) has been a big hit in the information security field.
These products are used for a variety of practical applications ranging from information Security Incident Analysis, Incident Management, Log Management, Information Technology Forensics and Automated Risk Assessment.
The products though, look very useful, are very complex and expensive, do not directly generate revenue, nor do they actively stop any losses to the business.
Hence it is difficult to justify its deployment.
That is why information security professionals find it difficult to build a strong business case for their deployment.
Here are a few points – that will help to build an effective business case for SIEM implementation in your environment.

1. As usual with any information security implementations, understand the business objectives and how information technology is supporting it.
   

The SIEM implementation requires considerable time, it is wise to take this time into account when calculating its value, the time required may range from few months to even few years depending on the size of your IT infrastructure. Normally, this time-frame can be broken down in stages – e.g. planning, installation, configuration, tuning, preliminary reporting, fine-tuning and final reporting.
The first phase “Planning” is very important. A 3-dimensional vision is necessary for this phase and in case of a large enterprise environment a group of Subject Matter Experts (SMEs) should be consulted.

Squeezing out best from SIEM

Squeezing out best from SIEM Rules

-Ashok S. Patil

Well you have that product, SIEM, very efficient and impressive for features and it boasts a lot!!

It is good to have an intelligent event and log analysis tool which correlates thousands of events, otherwise, impossible to manually sort out and analyze, that too in near real time.

But here is a caveat.

All security products have one inherited vulnerability – they all are prone to human errors!

They are prone, because of the human nature, it is common psychology that people tend to think and apply more of “advanced” knowledge even when things are too simple, and leave room for mistakes – then with the same complexity, these mistakes are gradually eliminated, ultimately arriving to the simplicity, that they were required to keep initially.

SIEM products are no exception. There are lot of things to do and there are lot not to do too.

This article will focus on these – it will be impossible to write everything down here, else I shall end up writing a whole book!!

(*Yeah these are excerpts from my forthcoming book on Information Security, a book that will stand apart, with issues that remained, untouched so far.)

Nonetheless, I shall mention some common human errors (mistakes, actually!!).

Here is number one, not understanding basic terminology. It is worth to go through the Glossary of terms before you actually start to work on it. The Glossary of terms here, does not mean a standard Information Security Glossary, normally found elsewhere like websites of ISACA, (ISC)² etc.

Companies have their own terminology. One good example is the term “risk”.

People tend to mix their basic security understanding with that which does not apply to a specific Information Security product, particularly management and analysis software like SIEM.

Being more precise, the basics do remain the same but the terminology and words may change or have different meanings!!

Well, as a first step, you have taken your IT infrastructure, and its architecture into consideration, but you also need to understand the logic, how SIEM will correlate events.

Number two, it is sometimes seen that people put AND in place of OR and vice versa, particularly, when using negative parameters as inputs. Here your good old study of Logic gates will help you.

Avoid negative input values (e.g. not equal to), for analysis, instead treat it like inverted inputs (bubbled gates) and convert the logic gate itself into resultant logic gate using de Morgan's Theorem.

A . B = (A+B)                                               A + B = (A.B)

Consider you wanted to filter out events which have values “attack is equal to blocked” or “attack is equal to stopped”.

Check for what is desired output for trigger and create a truth table, like the one given below

The desired is, if either Blocked or Stopped is false, it should return a value true (1)

Here, see that when events have both “Blocked” and “Stopped” values equal to TRUE, only then the incident will not be triggered. Anyways we don't want to miss a single true positive, do we? And is important even if we get a few false positives.

Compare this table with basic logic gates, and you will have a solution.

“attack is equal to blocked” NAND “attack is equal to stopped”
 

But since you do not have NAND operation directly available, you may use the following -

“attack not equal to blocked” OR “attack not equal to stopped”

That is equivalent to - 

“attack is equal to blocked” NAND “attack is equal to stopped”

NAND gate truth table -   (A.B) 

                                        A + B = (A.B)

    converting this to our example -

Be aware that such methods can be eliminated, instead use of something like event filters and look-up tables serve the very purpose of filtering out false positives, in fact they are meant for the same.

“Any intelligent fool can make things bigger and more complex. It takes a touch of genius – and a lot of courage to move in the opposite direction.” - Albert Einstein

Copy the system correlation rules as templates to further customize it, and depending on your requirement start “fine tuning” them. It should strictly be “fine tuning” and not “tuning” else you will mess up with the rule.

What is “fine tuning”? Well I have elaborated this below.

A couple of years ago, in a school, kids were asked to watch a series of programs on "National Geographic" channel, my younger daughter was one of them. During the same, the local cable operator had messed up with frequencies of transmission resulted in scrambled channels (The TV is a bit old fashioned!). She herself tried to "tune" the channel, finally she thought she did it, to later understand that it was an English movie channel playing a science fiction at that time.

So she started again to tune to the right channel and finally got success.

This is called as "Tuning".

When it looked like she had successful in doing so, later when I was back home from office, I found that the picture and the sound quality of that channel was not as good as it used to be. So I started to set its frequency accurately, and yep! the channel was playing correctly.

This is "Fine Tuning"

Number Three, in SIEM (and also in Risk Analysis), "Quantitative Analysis" should never be used, where you will have to go through hundreds of false positive incidents and then decide how to "tune" the correct rule, this tuning process may continue for a stretched time, improvements will be there but at a very slow rate.

"Qualitative Analysis" on the other hand, is a good practice, where you use "System Rules" (these are as good as preset channels for your TV or bookmarks for your internet browser) as templates and then fine tune them using something like "Event Filters" and "Table Look-up" instead of tampering with the basic template, unless it is extremely necessary and there are no alternatives.

Not following this will make you prone to make mistakes.

Remember a general rule “As the complexity increases so does the probability of problems”

A classic example is using “network traffic” in exploit related rules though traffic direction is not important for security monitoring, it is still incorporated, inviting many false positives, and also missing out true positives.

You never know which traffic will be proved to be malicious generated by viruses, Trojans, spybots, adwares etc. and other malicious activities(intentional or unintentional).

Here again I repeat, better to have a few false positives rather than missing out a single true positive incident. 

On the other hand too many false positives will make a security analyst miss out incidents due to the difficulty in picking up the right one, he will have to analyze everything, and finally drop out many incidents!!

Good old “Garbage in garbage out” still stands firm!!

If the rules have been all messed up, correlation engine will receive the “garbage*” and its output will essentially be “garbage”, no matter how good the SIEM product is.

On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.                                                  —Charles Babbage, (Passages from the Life of a Philosopher)