A Warning about Hidden Costs

Sunday, August 23, 2015 Posted by Corey Harrell 3 comments
I saw the excitement in my son's eyes as the biggest smile was stretching from ear to ear. He slowly stretched out his arm to show me what he got at camp that day. He was extremely excited and I could sense his happiness as I heard him say "I won it with only one dollar. I did it on my first try. Can we keep it?" My eyes focused on what was in his hand. It was a plastic bag with a small goldfish swimming around. "I won it at the fair today. Can we keep it?" In that split second I quickly ran through what owning a fish might entail and it was very similar to the picture used in this post. I then said "yes, we can keep it". My son excitedly ran to his summer camp counselor with so much excitement to tell her the fish was going home with him.

As we were walking to pick up my youngest son I realized the first thing I didn't think about. My five year old would be upset seeing his brother with a goldfish and knowing he doesn't have one. I thought problem solved; we'll just buy him one at the pet store while we are there getting supplies. We reached my five year old in his camp and his eyes grew bigger and bigger as he saw the bag. "Is that a fish" he asked and my seven year old replied "Daddy is getting you one too".  At that moment both kids had smiles as they kept staring at the little fish swimming in the bag. As we were walking down the hall we walked past another parent. She saw the bag with the fish and nervously said "Oh lucky you". I laughed and I could see she was a bit nervous walking down the hall to pick up her kid.

On the drive home, I remembered what my wife said at one point. Dam, my wife. Make that item number two that didn’t cross my mind when my son asked me if we could keep the fish. She has been dead set against owning a fish and this time playing like I misunderstood or didn’t hear her won’t work. “Absolutely no fish" is pretty clear. I knew I wasn’t getting out of this one so I thought I might as well get something out of it. I sent her a text message saying the boys had a big surprise for her. Despite her continued texts trying to guess the surprise on my drive home I wouldn't answer them and I only deflected saying she had to wait.

As my wife opened the door both of my sons went running up to her. They said guess what a few times trying to gather their thoughts from their excitement. Then my seven year old says "at the fair I won a fish on my first try. I did it with only one dollar. Daddy said we could keep it and he is getting Gab one too." She started to give me that stare until she walked over and started watching the fish swim around in its bag of water. Maybe she ran through what a fish would entail too but maybe not. Whatever it was I wasn't going to ask when she said it looks like we are making a trip to the pet store.

On the drive to the pet store my wife and I were on the same page. We would get to the store then buy a basic tank, a second fish, and some food. As we walked up and down the aisle there were tanks of all sizes. Not sure what size we needed we asked the store for assistance. The cashier said he would send over the fish lady. I gave him a puzzled look and was like "fish lady?" He said that's what we call her since she knows everything about fish.

We continued walking up and down the aisle waiting for the fish lady while continuously stopping my boys from wrestling each other. A younger girl was walking towards us and I asked if she was the fish lady. She laughed and then explained all the tanks and fish she owns. I told her we were looking for a tank to hold two goldfish. She said each fish should have least 10 gallons of water and then I glanced at the shelf. At that moment I knew getting the small basic tank we thought that would work was no longer an option. Nope, we had to get a real fish tank. As we continued listening to the fish lady she started going down the list of things we would need. Water conditioner, food, gravel for the bottom of the tank, filter, vegetation (fake or real), a stand for the tank to keep it level, structures for the fish to hide in, and the list went on. My wife and I both reached for our phones to confirm what she was saying without her noticing (we research everything before buying something). We were making sure she wasn't trying to pull a fast one on us and our quick research confirmed what the fish lady said. I even saw the weekly work that owning a fish entails. I stopped counting all of the things I didn’t think about when I quickly ran through the list of what I thought owning a fish entails.

After hearing the fish lady I said that's a lot more than I was expecting. My kid won a fish at the fair and we thought we would only need a basic tank. She cracked a smile and then said "oh, a fair fish huh". After she helped us and was walking away I got the feeling this must happen a lot. Parents getting a fish at the fair, going to the fish store, and then getting hit over the head with what it really entails to own a fish. We grabbed a shopping cart, grabbed all of our supplies, the fish my five year old picked out, and selected the stand for our 20 gallon tank. As we left the store I kept thinking about the dollar fish that just cost us hundreds of dollars. That evening I spent hours putting together the stand and tank while my wife was cleaning all the items going into the tank (another thing we weren't expecting).

What I thought owning a fish entailed was nothing close to what is actually involved with owning a fish. Spending a dollar to win a fish was nothing compared to the hundreds of dollars needed to take care of the fish. The weekly work I envisioned was a lot less than the actual work I have been doing for weeks.

If I could do it again knowing now what I didn't know when we sent our son to camp that day. I would do things differently. I would had told him to save his dollar and do not bring home any fish. Mommy and I are doing some research and then next weekend we will go get the supplies and fish to set up a nice tank. It will be better than just watching two goldfish swimming around in a 20 gallon tank. This is the approach I would had taken. The approach of not trying to make things work with a dollar fish because in the end I still paid the same amount as I would had going with the better option in the first place.

My guess is this story plays out every year at a lot of organizations. The only exception is organizations are not dealing with goldfish but tools.

Labels:

Go Against the Grain

Wednesday, August 12, 2015 Posted by Corey Harrell 0 comments
“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.” —Richard Buckminster Fuller

It's very easy to accept the way things are and say in response "it is what it is". It's easy to say I tried and give up when others push back against the things you want to change. It's easy to say this is how we always did it so why change anything now. Now let's put this into context of information security. It's easy to accept the thinking "that no one gets security" and then take on the mentality of not doing anything to change it by saying "it is what it is". It's easy to say I tried and give up when you make an attempt change how people approach security but then get push back by others. It's easy to say this is how we always approached securing our organization so why change anything now.

The quote I opened this post with nicely summarizes how you can go against the grain and put an organization on a better path to addressing their security risks. How you can change the existing security strategy focused on prevention to one focused on a balance between prevention, detection, and response. Start building the better approach (model) to enable others to see the value it adds. Continue building out the better approach and showing value to others. Showing the value and benefits results in people buying into the new approach. Eventually the change will take hold putting the organization on the better path. Building the better approach is more effective than fighting against the existing reality and those who are complacent with the way things are. Changing the security strategy won't occur without some resistance. There will be remnants of those who resist your changes and will fight to make things go back to the way things were. Those remnants won't be as successful in influencing change because they will be fighting against a new reality and they will lack the motivation and/or determination to go against the grain to build a better model.
Labels:

Minor Updates to Auto_rip

Monday, August 10, 2015 Posted by Corey Harrell 2 comments
This is a quick post to pass along that I updated my auto_rip script. For those who may not know, auto_rip is a wrapper script for Harlan Carvey's RegRipper program and it executes RegRipper’s plug-ins based on categories and in a specific order. To learn more about my script please see my previous post Unleashing auto_rip. The auto_rip updates are pretty minor. I separated out the changes to a change log instead of documenting changes in the script itself, added a device category (due to a new plug-in), and I added most of the new RegRipper plug-ins Harlan created (as of 7/30/15). The download location can be found on the right of my blog or using this link to its Google drive location.


****** 08/11/2015  Update *******

At this time I removed the compiled executable from auto_rip. The compiled executable is having issues and I'm working to resolve it. However, the perl script is present and works fine. As soon as I'm able to compile the script into an exe then I'll add it back to the auto_rip archive

SIEM – One Year Later

Sunday, July 26, 2015 Posted by Corey Harrell 0 comments
We are overwhelmed with data and are not sure what to look at or collect? I came across this paraphrased comment in a SIEM forum and it echoes a sentiment I have seen about SIEM. Deploying the technology results in a ton of noise and alerts making it hard to make sense of. Some organizations struggle using SIEM effectively and at times their staff are drowning in a sea of logs and alerts. The comment is also one foreign to me. I’ve read about it and seen others say this but I never witnessed it for myself. My path, my journey was a different one. This post reflects on my SIEM journey for the past year in hopes that it can help others who are either taking their first step or are already on their SIEM journeys.

Disclosure: jIIr is my personal blog and is not affiliated with my employer. This post only covers my personal experience and does not go in to details related to SIEM implementation in my employer’s environment. Any questions along these lines will unfortunately go unanswered. Some lines are not meant to be crossed and this is one of them.

Start with Why It Is Needed


My journey didn’t start when the SIEM was acquired but it occurred long before then when my perspective about security strategies changed. The security strategy is critical to explore since the strategy is the force pushing organizations down the SIEM path in the first place. Let’s go back in time to when I was in a unit performing vulnerability assessments against other public sector organizations. Over time I began to see fundamental problems with various security strategies I encountered.

Some strategies were completely centered on prevention. Almost every security resource – including funding, staffing, etc. – was applied to tasks and projects related to preventing attacks. In these organizations we always found something; in every organization we always found something. With each finding came the task of explaining to auditors on my side the cause of the finding. Auditors see things in black and white but security findings are not clear cut. The truth is we probe the target’s environment and security program moving from well protected areas to areas not well protected. These were the areas our findings came from. Organizations cannot protect everything in a manner to prevent everything; it’s an impossible task and even with an unlimited budget it is not achievable.

Some strategies were centered on compliance. Security resources and priorities are focused on the findings in the latest audit. As time goes by the security strategy is to address and reduce those findings without taking in to consideration areas posing the highest risks to the organization. At times during our engagements we were welcomed. The expectation was we would highlight areas they should focus on and help the security folks convince management to allocate the appropriate resources to address those areas. For a while I thought the work we were doing accomplished this as well. In time I became to see things differently. No matter how effective an audit is, this security strategy will never work since there is a fundamental problem. Audits only confirm if something complies with criteria outlined in a regulation, policy, or standard. If something has no criteria then it is very difficult for an audit to list it as a finding since each finding needs to be tied back to a criteria. If the criteria (regulation or policy) doesn’t address something that is a high risk to the organization then the audit/assessment will miss it as well. Making matters worse is it is very difficult to determine how effective something is. If something exists, has supporting documentation, and passes some tests in most cases this satisfies the audit requirement. Audits don’t truly evaluate how effective processes and controls are. They check a box as something being present then move on to other areas not well protected (remember it’s impossible to protect everything). This results in significant gaps in security strategies driven by compliance and the news headlines of breaches for organizations compliant with regulation X highlights this.

Then some security strategies were reactive. This is when the security strategy is based on the latest event; both inside the organization and outside of it. With each new event the organization switches focus and resources to address it even if it is not the highest risk to the organization. This leads down a path of random controls put in place to combat random threats and what little security resources are available is used in an ad-hoc manner. Reactive security strategies in my opinion are not even a strategy and are doomed for failure.

Over time, the fundamental problems with various security strategies I encountered made me ask myself a single question. If I ever found myself in a position to lead an organization’s immature security program. How should I approach building their program from scratch? Exploring this question brought me to various information security resources. It even lead me to obtaining my Masters of Science in Information Assurance. In time I came to the following conclusion:

1. There are fundamental problems with security strategies based on prevention, compliance, and reactive.

2. Most information security decisions I witnessed in my entire career were not based on actual data to support the decisions. Decisions were based on experience, intuition, what someone else recommended, or shiny new objects. At times, decisions not based on actual data resulted in bad choices, wasted what little security resources are available, and didn’t address the actual threats the organizations faced.

3. What security strategies need is “an intelligence-driven approach, whereby decisions are made based on real-time knowledge regarding the cyber adversaries and their attack methods, and the organization’s security posture against them”.

The fundamental problems with security strategies based on prevention, compliance, and reactive would be addressed in an intelligence-driven approach. Security decisions would not only address the most significant risks an organization faces but the decisions would be influenced by facts and information. The path to intelligence-driven security needs to start with the foundation mentioned in the quote below.

“To be ready to take on an intelligence program, the organization needs to have a foundation in place for monitoring the network for intrusions and a workflow process for responding to incidents.” 

This became my perspective on how security strategies needed to be and I ended up in a security office who agreed with the strategy. This strategy started me down the SIEM path as part of laying a foundation for security monitoring. The driving force behind SIEM was security monitoring and it influenced what logs were collected and how they were analyzed.

Expect a Significant Time Commitment


I knew there was going to be a significant time requirement at my $dayjob but I didn’t know about the impact on my personal time. I had a well-rounded background to take on a SIEM project but I never built the equivalent of a SOC. I read the often quoted percentage that “somewhere between 20% and 30% of SIEM deployments among his client base fail, meaning not only do they not meet predefined goals, but also that many organizations don't even bother using the product”. I also read the articles and comments about how difficult SIEM deployments are, how complicated SIEM management is, and how companies frequently end up in a sea of alerts with no clue what to do about them. I guessed what the impact would be on an organization for a failed security investment. How after getting buy-in, making a sizable investment in technology, and allocating staff to only end up with something that doesn’t meet any goals would be devastating. Not only would this not provide the needed foundation for intelligence driven security but the failure would linger for a long time for the organization. Any other request for security resources would be even more difficult because it will be looked upon as another wasted investment since the investment in SIEM failed. Any other security initiatives may be looked at with doubt and wonder if they can even be successful since the security office failed with the SIEM initiative. Needless to say, failure was possible but it wasn’t an option in my opinion.

I put most of my personal time I allocate for research, writing, and reading on hold to allow me to focus on building the SOC. I spent my time instead researching and learning from others about how to build an effective security monitoring capability. A small portion of what I explored was mentioned in the posts:  Linkz for SIEM, Linkz for Detection and Response, Making Incident Response a Security Program Enabler, and Linkz for Intelligence Driven Security and Threat Intelligence. In essence, my time at the $dayJob was spent implementing SIEM capabilities, building processes, training staff, and managing security monitoring while my personal time was spent exploring all aspects related to security monitoring and intelligence driven security.

It was a personal sacrifice I made for my employer to ensure our SIEM project would be successful but in the past year my knowledge and skills have grown by leaps and bounds. There’s a personal sacrifice leading a SIEM implementation but making that sacrifice is worth it in the end.

Prepare, Prepare, and Prepare Some More


In John Boyd’s autobiography Boyd: The Fighter Pilot Who Changed the Art of War one lesson we all can learn is how he approached things. Take the following quote about someone who Boyd influenced and was a member on his team:

“His attitude was “Maybe so. But if not me, who?” He was the right man in the right place at the right time. He had done his homework and knew his briefing was rock solid.”

The lesson we can all learn is for us to do our homework; to prepare for each possibility and the things that can and will go wrong. This is probably the best advice I could give anyone traveling down this path. You might be the right man in the right place at the right time to lead an organization as they deploy SIEM technology but you need to do your homework. You need to research and explore the issues trying to be solved, developing a detailed project plan with phases, getting buy-in by explaining the issues and why SIEM is the technology to solve it,  identifying the exact logs required and what in those logs is needed, etc.. The list goes on but the point of this advice is to prepare. Prepare, and then prepare some more since the effort and time spent doing this will ensure a smooth deployment. I spent a considerable amount of time preparing upfront and during the deployment and this helped me avoid pitfalls that could had impacted the project.

Leverage Use Cases


As I started this journey one of the first things I did was to learn from others who took this journey before me. The main person who influenced my thoughts and thus my approach was Anton Chuvakin. In most articles he advocates to leverage use cases when deploying a SIEM and hands down this is the best advice for a successful SIEM project. He authored a lot of posts on the subject but the best one as it relates to a SIEM project is the one hyperlinked in my quote below:

“The best reference I found to help architect a SIEM solution is a slide deck by Anton Chuvakin. The presentation is Five Best and Five Worst Practices for SIEM and it outlines the major areas to include in your SIEM project (16 to be exact). It may not cover everything -such as building rules, alarms, and establishing triage processes - but it does an outstanding job outlining how to avoid the pitfalls others have fallen in. If anyone is considering a SIEM deployment or in the midst of a SIEM deployment then this is the one link they will want to read.”

His slide deck influenced my SIEM project plan from the point of getting buy-in to the actual implementation. To implement a use case there wasn’t a lot of information on it so I put together the SIEM Use Case Implementation Mind Map to have a repeatable process for each use case.

The beauty in leveraging use cases. Not only does it make building a SOC more manageable by focusing on detecting certain activity in smaller chunks and building the processes around those chucks but it makes it very easy to show others the value SIEM adds. If the SIEM deployment takes one year to complete then using multiple use case can show progress and what was accomplished throughout the year. The value added is shown throughout the year instead of waiting until the end. That is if the proper preparation was done in advanced.

Focus on Triage


Thinking back over the past year and what I found to be the most challenging with SIEM technology or any detection technology for that matter is how events/alerts need to be handled. I found bringing in logs, creating custom detection rules, and tuning rules to be easy compared to developing the triage processes surrounding each category of events/alerts. My previous thoughts on the subject still ring true today:

In my opinion establishing triage processes is the second most critical step (detection rules are the first.) Triage is what determines what is accepted as "good" behavior, what needs to be addressed, and what needs to be escalated. After the rules are implemented take some time reviewing the rules that fired. Evaluate the activity that triggered the rule and try out different triage techniques. This is repeated until there is a repeatable triage process for the rules. Continue testing the repeatable triage process to make it more efficient and faster. Look at the false positives and determine if there is a way to identify them sooner in the process? Look at the techniques that require more in-depth analysis and move them to later in the process? The triage process walks a fine line between being as fast as possible and using resources as efficient as possible. Remember, the more time spent on one alarm the less time is spent on others; the less time on one alarm increases malicious activity being missed.

The triage processes are critical and can help prevent encountering the paraphrased comment I opened this post with. We are overwhelmed with data and are not sure what to look at or collect? Unfortunately, when it comes to triage for the most part you are on your own. This was one area I found to be truly lacking in documentation and the few cheat sheets I found didn’t account for the majority of stuff one needs to consider. Determining what triage processes were needed followed by developing those processes and then training others was definitely a tough challenge. It was tougher since it also involved honing those triaging processes to improve their efficiency and speed. Despite the difficulty, focusing on triage enables you to see through the noise and know what to look for.

Metrics – These Are Needed


If someone would had told me two years ago I be reading about security metrics I would had laughed out loud. Two years ago I didn’t see the value metrics offer until my eyes were opened exploring intelligence driven security. Another comment I saw in the SIEM forum was the following quote: “what information should be provided to the management on the daily basis which can justify the purchase of  SIEM”. This is where metrics can come in to play. By recording certain information it makes it easier to communicate what one is detecting and responding to. Communicating metrics and trends shows value to management, highlights weak areas in the security program, or uncovers patterns in attacks. During the past year I explored various information security metrics. As it relates to the SIEM, the VERIS schema is probably the best one I found for recording the information from detecting and responding to security events. As soon as you have the documented information then the fun part is finding creative ways to communicate these to others.

You Are Alone Standing on the Shoulders of Others


As I embarked on this journey I learned from others who have either dealt with SIEM technology or security monitoring. Initially, I read online what they published and made available to the public. I reached out to a few people about the additional questions I had. I looked around locally and reached out to others who were managing their own security monitoring capabilities. Needless to say, my SIEM journey was successful since I was standing on the shoulders of those who came before me.

However, at the end of the day each organization is different. Others can provide you with advice and share their experience but what is actually encountered is unique. The environment is unique and certain aspects of the use cases are unique as well. Due to this uniqueness, most of the time throughout the year we (my team and myself) were on our own. I mention this as a word of caution to others who may expect a vendor or others to solve their SIEM challenges for them. Others and vendors can help to a certain extent but you and your team are the ones who need to solve the challenges you face. At that point you will find yourself alone standing on the shoulders of others.
 

Looking Forward to SIEM Year 2


Reflecting back over the past year it has been a demanding challenge. The journey hasn't ended since work still needs to be done. There will always be work to do and new challenges to work through. Hopefully, the experienced I shared will avert someone from stepping on a SIEM land mind resulting in them yelling out for help as they are drowning in the sea of logs and alerts.
Labels: ,

Villager or Special Forces - That Is The Question

Friday, July 10, 2015 Posted by Corey Harrell 0 comments
At certain times we will find ourselves being like Special Forces going against what seems like a villager with a pitchfork. We are better equipped, better trained, possess more technical knowledge, and have more advanced skills. Despite their best efforts, the pitchfork and the one welding it doesn't stand a chance against our arsenal and our ability to use it.

At other times we find ourselves as the villager holding the pitchfork going up against what feels like Special Forces. They are smarter, have more resources, and possess more advanced skills. Despite our best effort and our ability to use the pitchfork; it's still a pitchfork going against a Special Forces arsenal and people who can use it.

The pendulum swings between the villager and Special Forces in the information security field. Between the two, I'd rather be the villager. The villager is the one facing the constant challenge. Unless of course, the pendulum only contains Special Forces. Special Forces against Special Forces would be the ultimate challenge.
Labels:

Linkz for Intelligence Driven Security and Threat Intelligence

Tuesday, June 30, 2015 Posted by Corey Harrell 5 comments
What’s the strategy one should use when trying to defend an organization against the threats we face today. At times the security strategy has been reactive. Decisions and the direction forward are based on the latest incident the organization experienced. This approach is not effective since it is the equivalent of firefighting where resources are used on addressing the latest fire without identifying the underlying issues causing the fires in the first place. At other times the security strategy is based on compliance. Decisions and the direction forward are based on regulations or standards the organization has to be compliant with. This approach is not as effective either. It will provide an organization with some minimum security controls but it may not help with defending against the threats we face today (the news highlights organizations who are compliant but are still compromised anyway). One security strategy that has gained traction over the years and is more effective than the previous two is intelligence driven security. The direction forward and “decisions are made based on real-time knowledge regarding the cyber adversaries and their attack methods, and the organization’s security posture against them”. This approach is more effective than the previous two since it enables an organization to allocate security resources to address the highest risks and threats they face.

In this post, I sharing linkz to various resources I found useful over the past few years related to the intelligence driven security, threat intelligence, threat intelligence data, consuming threat intelligence data, and threat intelligence sharing.

Intelligence Driven Security Links


These links are related to intelligence driven security, which RSA defined as “developing real-time knowledge on threats and the organization’s posture against those threats in order to prevent, detect, and/or predict attacks, make risk decisions, optimize defensive strategies, and enable action.”

Achieving Intelligence-Driven Information Security


The first link is one that will always hold a certain personal value since it was one of the first papers I read on the topic years ago. The RSA paper Getting Ahead of Advanced Threats: Achieving Intelligence-Driven Information Security discusses how an organization can approach managing their security program in this manner. The paper addresses: what organizations need to know, categories of cyber-risk data, intelligence driven information security, roadmap to achieving intelligence driven information security, opportunities for quick wins, and information sharing. I spent years performing vulnerability assessments against other organizations and each engagement it became more and more clear that the traditional approaches to security management were no longer effective. What was needed was an approach were factual information influenced decisions instead of decisions being based solely on someone's judgment or gut feeling. The approach in this paper is very light on details but it does address the thought process behind it and to me this was very helpful. The paper did nail the foundation one needs to have in place to achieve this as seen in the following quote: “to be ready to take on an intelligence program, the organization needs to have a foundation in place for monitoring the network for intrusions and a workflow process for responding to incidents.”

Strategic Cyber Intelligence


The reason behind leveraging intelligence in security management is to help people make better security decisions. These decisions can be related to addressing risks, security strategies, and resource usage. Despite this being the driving force behind intelligence driven security a good percentage of the material I’ve seen on the topic is more focused on the real time intelligence about threats and not about the intelligence an organization needs to make better security decisions. The next link I picked up from Richard Bejtlich and it’s a document titled Strategic Cyber Intelligence. If there is only one link to read in this post then this document is it. My words wouldn't do justice in describing this document so instead I'm opting to use part of the executive summary to describe it.

While there has been much emphasis on tactical cyber intelligence to help understand the “on-the-network” cyber-attacks so frequently in the news, there has been little discussion about the strategic and operational levels in order to better understand the overall goals, objectives, and inter-relationships associated with these tactical attacks. As a result, key consumers such as C-suite executives, executive managers, and other senior leaders are not getting the right type of cyber intelligence to efficiently and effectively inform their organizations’ risk management programs. This traditionally tactical focus also hampers the capability of the cyber intelligence function to communicate cyber risks in a way that leaders can fully interpret and understand.

Adopting Intelligence Driven Security


The next links I found helpful since they had some good talking points and a nice diagram to get buy-in to approach security in a more intelligent manner. The RSA Adopting Intelligence Driven Security paper provides a high-level overview about adopting an intelligence driven security strategy. Topics discussed include: visibility, analysis, action, and difference between today's security strategies and intelligence driven. The RSA blog post What is Intelligence Driven Security? provides very similar but less information than their paper.

Threat Intelligence Links


Threat intelligence is a needed component in achieving intelligence driven security but the two are not the same. This can be seen in the iSightPartners threat intelligence definition, which is “cyber threat intelligence is knowledge about adversaries and their motivations, intentions, and methods that is collected, analyzed, and disseminated in ways that help security and business staff at all levels protect the critical assets of the enterprise”. These links provide information about threat intelligence.

Threat intelligence: Collecting, Analysing, and Evaluating


The MWR InfoSecurity Threat intelligence: Collecting, Analysing, and Evaluating whitepaper provides an excellent overview about threat intelligence and a threat intelligence program. Topics included are: what is threat intelligence, building a threat intelligence program, strategic/operational/tactical threat intelligence, and technical threat intelligence. The paper is well worth taking the time to read since the overview touched on most components of a threat intelligence program.

Definitive Guide to Cyber Threat Intelligence


iSIGHT Partners is a vendor providing threat intelligence services. They released a short ebook titled Definitive Guide to Cyber Threat Intelligence (at the time of this post the link for the PDF is here and if it no longer works then you'll need to provide them your email address to receive the download link). In their own words the following is why they wrote the book: "We figured that since we wrote the book on cyber threat intelligence, we might as well write the book on cyber threat intelligence". The book itself is 74 pages and addresses the following: defining cyber threat intelligence, developing threat intelligence requirements, collecting threat information, analyzing and disseminating threat intelligence, using threat intelligence, implementing an intelligence program, and selecting the right threat intelligence partner. The one area where I think this book shines is by outlining the components that a commercial threat intelligence service should have.

Actionable information for Security Incident Response


ENISA released the Actionable information for Security Incident Response document that was “intended as a good practice guide for the exchange and processing of actionable information”. The document discusses some of the following points: properties of actionable information, levels of information, collecting information, preparing information, storing information, analyzing information, and case studies. The document does an outstanding job outlining the characteristics of actionable intelligence as well as a process one could use to process it.

Threat Intelligence for Dummies


Another ebook released by another threat intelligence vendor named Norse is the book Threat Intelligence for Dummies. The book is a short read (52 pages) and touches on the following areas: understanding threat intelligence, gathering threat intelligence, scoring threat intelligence, supporting incident response, threat mitigation, and buying criteria for threat intelligence solutions. The book is another option for those looking for a more general overview about threat intelligence.

Five Steps to Build an Effective Threat Intelligence Capability


The next link is for a Forrester report about building an effective threat intelligence capability. The first half of the report outlines the case for needing a threat intelligence capability while the second half discusses the actual capability. The topics include: intelligence cycle, intelligence disciplines, and five steps to build the intelligence capability. This report is another approach to building the capability and I find it beneficial to see different approaches for accomplishing the same thing. It makes it easier to pick and choose aspects from the various approaches to find what works best for you.

Open Source Threat Intelligence Data Feeds Links


Data about threats, adversaries, and methods they use can be obtained from various sources. One source for regularly updated threat data is from publically available sources. Despite the data being freely available care must be taken in selecting the data feeds to use. For each data feed its characteristics must be evaluated to determine the value added for an organization's security monitoring and response process. (Side note: consuming as many feed as possible is counterproductive and could actually impede security monitoring.)

Evaluating Threat Intelligence Data Feeds


These links are a bit dated but they are as relevant today as when they were published. David Bianco's posts The Pyramid of Pain and What Do You Get When You Cross a Pyramid With A Chain? outline an approach to evaluate the value of indicators. The Pyramid of Pain is a versatile model that can be used when not only evaluating indicators in open source threat intelligence feeds but it is also helpful when trying to assess the coverage in a security monitoring program.

Feeds, Feeds, and More Feeds


The next link is a word of caution from Jack Crook about using threat intelligence data feeds. In his post Feeds, feeds and more feeds his provides some food for thought for those looking to start consuming feeds. Below is a very telling quote from his post:

By blindly alerting on these types of indicators you also run the risk of cluttering your alert console with items that will be deemed, 99.99% of the time, false positive. This can cause your analysts to spend much unneeded time analyzing these while higher fidelity alerts are sitting there waiting to be analyzed.”

Threat Data Feeds


Now with the links about evaluating data feeds and a word of caution out of the way I can now provide links to websites that contain links to publically available sources for threat data. It’s an easy way to provide a wealth of feed options by linking work done by others.

Introducing the Active Threat Search
Critical Stack Bro Intelligence Framework (need to register but it is well worth it)
Collective Intelligence Framework Data Sources
Threat Intelligence Feeds Gathered by Combine
Opensource intel links
uiucseclab cif-configs


Consuming Threat Intelligence Data Links


One of the ENISA actionable information characteristics is ingestibility. Ingestibility is the ability of the organization receiving the data to "consume it painlessly and automatically, including correlating and associating it with other information". The consumption is what makes the information useful to an organization to identify vulnerabilities, mitigate an ongoing attack, or detecting a new threat.

Leveraging Threat Intelligence in Security Monitoring


Securosis published a decent paper titled Leveraging Threat Intelligence in Security Monitoring. The paper discusses threat intelligence sources (is mostly focused on malware), and the network security monitoring process before going into detail on integrating threat intelligence with the security monitoring process. The part I really liked about the paper is it outlines a process for managing the security monitoring process that consumes threat intelligence and it takes the time to explain each component. Even if an organization doesn't use this process its helpful to see how someone else approached consuming threat intelligence to see what can be used to improve their security monitoring processes.

How to Use Threat Intelligence with Your SIEM?


The next link is really a bunch of links. Anton Chuvakin is a Gartner analyst who focuses on SIEM, security monitoring, and incident response. His analysis reports requires a Gartner account to access but he does share some of his research on his blog. Anton wrote numerous posts addressing: consuming threat intelligence, threat intelligence, and threat intelligence data. His post How to Use Threat Intelligence with Your SIEM? talks about how SIEMs can consume threat intelligence data for an organization and the post really hits home since this is one way I consume TI data. He also released the following posts related to threat intelligence:

Threat Intelligence

On Internally-sourced Threat Intelligence
Delving into Threat Actor Profiles
On Threat Intelligence Use Cases
On Broad Types of Threat Intelligence
Threat Intelligence is NOT Signatures!
The Conundrum of Two Intelligences!


Threat Intelligence Data

On Threat Intelligence Sources
How to Make Better Threat Intelligence Out of Threat Intelligence Data?
On Comparing Threat Intelligence Feeds
Consumption of Shared Security Data
From IPs to TTPs


McAfee SIEM and Open Source Intelligence Data Feeds


An easy way to consume open source threat intelligence data is by feeding it into a properly configured SIEM and correlating the data across an organization’s logs. The next few links explain one method to accomplish this with the McAfee SIEM (formerly known as Nitro). The SIEM stores intelligence data inside items called watchlists and these watchlists can be dynamically updated with intelligence feeds. The post Creating a Watchlist from Malc0de shows how to accomplish creating a dynamic watchlist to populate it with the Malc0de feed. I populate my dynamic watchlists using a script; there are always different ways to arrive at the same destination. The watchlist containing threat intelligence data can then be used in correlation. The next post SIEM Foundations: Threat Feeds walks you through creating a static watchlist (I don’t recommend this approach with intelligence feeds) followed by showing different ways to use the watchlist.

Splunk and Open Source Intelligence Data Feeds


Different SIEMs are able to consume threat intelligence data in different ways. The previous links were for McAfee SIEM and the next links are for Splunk. The Deep Impact post Splunk and Free Open-Source Threat Intelligence Feeds “is a write-up for integrating some readily available free and open-source threat intelligence feeds and block lists into Splunk”. The thing I really liked about this post was the author not only explained how to perform this integration but he also released a script to help others do the same.

Bro and Open Source Intelligence Data Feeds


To make use of open source intelligence data feeds you don’t need a SIEM technology. All you need is technology that can consume the data feeds you selected. The next link is a great example of that. Critical Stack has put together their Threat Intelligence for The Bro Platform. I don't use Bro but I find this idea really slick. They set up a portal where you can log-in, review numerous open source intelligence feeds, select the feeds you want, and then create a subscription that gets ingested into Bro. This has really lowered the bar for people to use open source threat intelligence and even if you don't use Bro the portal is a nice reference for available data feeds.

Threat Intelligence Sharing Link


Approaching intelligence driven security provides an organization with visibility into their environments. Visibility into the threats they face, the actual attacks conducted against their environment, and their security posture to defend against those threats. Not only does intelligence driven security result in the organization consuming external threat intelligence but it enables the organization to develop and maintain their own threat intelligence based on what they are seeing. Internally developed intelligence can be shared with others. The last link is the only one I had for intelligence sharing.

NIST Guide to Cyber Threat Information Sharing


The NIST Special Publication 800-150 Guide to Cyber Threat Information Sharing (in draft format at the time of this post) expands on the NIST Computer Security Incident Handling Guide by exploring "information sharing, coordination, 228 and collaboration as part of the incident response life cycle". The guide is broken down into the following parts: incident coordination and information sharing overview, understanding current cybersecurity capabilities, establishing, & maintaining, and using information sharing relationships. The guide might be of value for those interested in a more formalized approach to intelligence sharing.

***** 07/01/15 Addendum *****


In response to this post the author of the CYINT Analysis blog pointed me to the threat intelligence resources webpage they put together. The webpage contains additonal resources I didn't discuss in this post and numerous others I wasn't aware about. I wanted to update this post to point to the CYINT Analysis resources webpage.

Security Monitoring with Attack Behavior Based Signatures

Monday, May 25, 2015 Posted by Corey Harrell 7 comments
Coaches and athletes both gather intelligence against their upcoming opponent by watching game film. Based on what they learn, they adjust their strategies to account for their opponent’s strengthens, weaknesses, and tendencies. The analogy about watching game film does not translate well to information security. In sports, the film study is to identify a single opponent’s tendencies while in information security there is no film for the numerous threats a company is up against on a weekly basis. However, the concept of watching an opponent's techniques to identify tendencies does translate. These tendencies are how they compromise systems and by identifying tendencies enables a company to adjust their security monitoring program. Companies can have the visibility to detect threats in their environment even when those threats are new or unknown. Attaining this level of visibility is possible by leveraging attack behavior based signatures in security monitoring. 

Attack Vectors


SearchSecurity defines an attack vector as "a path or means by which a hacker (or cracker) can gain access to a computer or network server in order to deliver a payload or malicious outcome." Based on this definition, the attack vector is broken down into three separate components. The path or means is the exploit used, the payload is the outcome of the exploit, and the delivery mechanism is what delivers the exploit and/or the payload to the target. The definition combines the delivery mechanism and exploit together but in reality these are separated.

As defenders, exploring attack vectors enables us to better protect systems, detect when systems are under attack, and determine how systems are compromised. The Compromised Root Cause Analysis Model goes in to detail about identifying and understanding the artifacts left on a compromised system to determine the attack vector used in the attack. This post goes in to detail about how exploring attack vectors can be used to determine when systems are under attack.

When attacking a system the attacker is constrained to the environment they are targeting. In this environment, certain actions behave a certain way every time they are performed. The behavior is dictated by the operating system and the action performed results in the operating system behaving a certain way. This behavior occurs every time the action is performed making the activity detectable. The attacker controls the exploit and payload so these can be changed making detection harder. However, the delivery mechanism component of the attack vector is susceptible to security monitoring in the Windows operating system. The delivery mechanism is dependent on the operating system and this is the environment the attacker is constrained to. Each time the attacker uses that delivery mechanism results in the same activity occurring in the operating system. This is the activity detected when using attack behavior based signatures.

Delivery Mechanism: Malicious Word Document


To elaborate on delivery mechanisms resulting in the same activity an example is needed. Word documents are a mechanism used by attackers to compromise systems. The exploits in Word documents vary from macros to hyperlinks to Microsoft Word exploits. The payloads vary even more since an attacker can use anything. Case in point, some attackers use the Dridex malware as the payload while other attackers use the Dyre malware. Traditional signature detection mechanisms try to keep pace with the changes attackers introduce in the exploit or payload. Attack behavior based signatures instead focus on the delivery mechanism’s interaction with the operating system. The activity caused by the Word document executing in the Windows operating system to deliver malware. This behavior remains the same no matter how much obfuscation or encryption attackers use to conceal the exploit and/or payload. To demonstrate this behavior what follows is a walkthrough of the activity of a malicious Word document being used as a delivery mechanism and the activity is monitored with the Microsoft Sysmon software. The sampled used in this walkthrough is the malicious document MD5 d89c0affa2c1b5eff1bfe55b011bbaa8 obtained from Malwr.com.

To compromise a system the malicious document needs to be executed. The picture below shows what occurs when the document is executed by the user. Upon execution, the user's shell (Explorer.exe) creates a process for the program that is the default reader for Word documents (files ending in .doc). In this instance and similar to most systems in enterprise environments, the default reader is Microsoft Word and the program's executable is named WINWORD.EXE.


At some point after the WINWORD.EXE process creation the exploit in the document is ran. Again, the exploit varies from macros to links to Microsoft Word exploits to embedded executables. Regardless of the exploit used, the activity of using Word as a delivery mechanism is the same and is shown in the picture below. Microsoft Word creates a child process for the payload of the attack. In this instance, WINWORD.EXE creates the process for the file kiramin86.exe inside a user profile's temp folder.


This is the activity that is susceptible to security monitoring. Microsoft Word (WINWORD.EXE) being the parent of another process that is a Windows binary (i.e. exe, pif, dll). Depending on the organization, this activity is the anomaly since Microsoft Word may rarely be the parent process of another executable or try to execute another executable. This is the type of activity attack behavior based signatures can focus on to detect new and unknown threats. The signature can be narrowed down even further to make it more accurate - such as focusing on executables in user profiles - but in essence this is the activity being detected. The signature is able to detect attack vectors using Word documents delivery mechanisms even if the exploit and payloads are different.

Technique Detection: Bypassing UAC


Attack behavior based signatures are not only limited to detecting the attack vector’s delivery mechanism. The concept can be applied to other techniques used by the attacker. At times attackers leverage techniques to bypass Windows User Account Control (UAC). UAC is a feature in Windows where every application ran under an administrator user account only runs in the context of a standard user. Bypassing UAC is a way for attackers to elevate their standard user privileges to administrator privileges. (For more information on UAC see the post UAC Impact on Malware.) The malicious document used in the previous walkthrough delivers the Dridex malware and this malware has a UAC bypass.

The May 12, 2015 post A New UAC Bypass Method that Dridex Uses outlines the current technique Dridex uses to bypass UAC. The article stated the following about how Dridex uses the application compatibility database to bypass UAC:

"An application compatibility database is a file that configures execution rules for applications that have compatibility issues. These files have an extension of sdb. Dridex leverages this feature to bypass UAC."

".Dridex uses the sdbinst command to install/uninstall application compatibility databases to install $$$.sdb."

This UAC bypass technique is constrained to the Windows environment and results in the same activity occurring in the operating system. The picture below shows the activity. The sbdinst.exe process is created and the commandline used to create the process points to an application compatibility database file (.sdb) inside the user profile. It’s activity that occurs every time so it is susceptible to detection through security monitoring. The signature’s logic could be the image value containing “sdbinst.exe” and the commandline containing .sdb file in a user profile.


Leveraging Attack Behavior Based Signatures


To leverage attack behavior based signatures in security monitoring to detect new and unknown threats is achievable. The approach requires technology to provide visibility on enterprise end points and the backend needs technology for the collection and analysis of the logs from the endpoints. The technology on the end point needs to provide visibility involving the Windows process and files the process interact with. This article leveraged Microsoft Sysmon utility since it is freely available to anyone and was suggested to me by Harlan Carvey. Other options are available for the end points including possibly existing agents that may already be deployed in enterprises. The technology for the collection and analysis of logs from the end points need to support regex or wildcards for querying the logs to identify the attack patterns. Attack behavior based signatures tend to focus on characteristics of processes involved in the attack activity. For malicious documents with Microsoft Word installed on the endpoint, the focus is on WINWORD.EXE and not necessarily the entire file path since this executable can be located in different folders (i.e. 32bit versus 64bit Word programs). Regex or wildcards support in queries enables this type of flexibility when building detection signatures.

Another consideration is attack behavior based signatures need to be used in layers customized to an enterprise. The walkthrough only demonstrated one signature for Word documents but there are numerous other attack vectors to account for. Each attack vector needs to be customized to the enterprise to account for the software installed on their endpoints. Further customization is needed since y their nature attack behavior based signatures results in false positives. The signatures detect patterns in the activity involving Windows processes. This activity can be either malicious or normal behavior. To identify false positives triage processes need to evaluate the activity flagged by the signatures to determine if they are false positives or security events. For reoccurring false positives, the signatures need to be tuned to reduce the noise from normal behavior.

Despite the technology, process, and customization challenges, leveraging attack behavior based signatures in security monitoring can be an effective approach for detecting new and unknown threats. The techniques used by attackers are constrained to our environments and their techniques cause activity on our systems that may be susceptible to detection. It just requires us to identify the activity susceptible to detection, build signatures to detect it, and then share with others to help them improve their monitoring capabilities.
Labels: