Some updates to vuln visualization

A while ago, I posted about an internal tool I created, Cestus, which I use to help score my vulnerabilities in my environment.   Since then, I've made a few tweaks to the tool.

Specifically, I've added:

1. Risk-based adjustment based on host importance.  Some hosts are obviously more important than others.  Perimeter-facing mission-critical boxes score individually higher than internal utility servers behind 3 layers of firewalls.   To do this, I had to modify the database and add new fields.  Luckily with SQLite, this was a snap.
2. Scoring based on type of vulnerability service.  Vulnerabilities that require local access (such as a browser vuln) score lower on servers than external service type of vulnerability does.  Bonus risk points for an external service discovered on what should be a client box.... laptops should not have listening FTP servers on them!
3. New report on total number of vulnerabilities and total risk score per host.  Handy for shaming informative reports to asset owners.
4. New report on total number of listening services per host.  Good for seeing which boxes are leaving large footprints on your networks.  And singling out unusual looking devices.  Both have proved very "interesting" when reviewed.  Also good to compare to asset master lists to see if you missed scanning anything.
5. New report on vulnerabilities based on keyword name in description.  This lets me create useful pie charts on which vendors are causing the most number of vulnerabilities in our environment.  So far these reports haven't been that revelatory:

That's all I've got for now.  I'm still working on integrating this into our on-going threat and IDS data streams. 

 

Siracon 2015

Excited to be presenting at this year's SiraCon in Detroit

My talk will be on Third Party Risk Assessment Exposed

You hear things like "The majority of breaches occur as the result of third parties." You see a lot of surveys and read a lot of "best practices" around third party security. But what is actually happening in third-party risk assessment? It’s hard enough to measure the risk of your own organization, how can you quickly measure an external organization? Banks are required to do this but specific methods aren't defined. So what are they doing? We’ll examine data from hundreds of external assessments in the financial sector and compare this to actual breach data. We'll look at such questions like: What are the top questions asked by more than half of the assessors? What are questions asked rarely? What factors drive assessments? What important questions are missed? We’ll also dig into the top assessment standards SOC1-2-3, ISO27k, Shared Assessments and see what they’re accomplishing.

Looks to be an awesome lineup this year.  Honored to be a part of it. 

 

DIY Security tools - Cestus: Risk Modelling on Vulnerability Data

I've spoken in the past about prioritized patching and the operational constraints.  Assuming you actually want to do some prioritization, how do you go about it? 

Continuing in the data-driven security realm, I've been pushing my vulnerability management tools to their limit.  One of the tools we use is Nessus for internal vulnerability scanning.  I've been a Nessus fan since Y2K days and still love it now.  One problem with all vulnerability scanners (and reports) is that their risk ranking tools are clunky, sometime inappropriate, and occasionally over-inflated.

Most of them use CVSS, which is a nice standard though quite limited.  And do remember, "Vulnerability != risk."  As you may have read before, I do a wide variety of types of internal vulnerability scanning and then synthesize the results.

What I want to do is suck up and analyze all this scanning data, and then apply localized relevant data, and then put this through a risk model of my own choosing.   There is really no such beast, though some commercial services are very close and becoming quite useful.  And this open source tool is also pretty good too.

So in the spirit of "Make your own security tools", I started working on risk scoring tool to use with Nessus and some of my other in-house scanning tools.

I wish I could share code with you, but this is developed on my employer's dime and is used internally... so no.  The good news, it wasn't hard to do and I think I can walk you through the algorithm and the heavy lifting.

Let's start with the Nessus data itself.   You can export everything you need in a handy XML file which can be read natively by a variety of tools. 

My tool-du-jour is Python, so that's what I'm using.  The file itself is broken into two major pieces: information about the scan and discovered vulnerabilities.  I'll want both.

The information about the scan gives me when the scan was done (so I can save and compare subsequent scans) as well as which vulnerabilities were tested.  This is critical because I can see what hosts were tested for what. Then I can mark off a vulnerability that was previously found when it no longer shows up (it was fixed!).  I can also get data about the vulnerability itself, such as when it was discovered.  This is useful in my risk model because we've seen that old vulnerabilities are worse than new ones.  I also get from Nessus whether a public exploit is available for that vulnerability... and that info is in the exported XML for the scooping.  This is extremely valuable for risk modelling, as these kinds of vulnerabilities have been shown to be far more worrisome.

After I pull in the data, I need to store it since I'm looking at synthesizing multiple scans from different sources.  So I shove all of this into a local database. I've chosen SQLite just because I've used it before and easy.  Having been a former database developer, I know a little bit about data normalization. So here's the structure I'm using for now.

The way I wrote my tool was to break into two parts: loading Nessus data and reporting on it. Here's how I load my Nessus XML files (with some hints on the libraries I'm using). So basically, run it and load up all the Nessus scan files you want. They're processed and put into the database. 

The second piece is to run risk modelling and generate reports in CSV format, suitable for spreadsheeting. Here's what pops out:

Oh yeah, you can see I'm calling the thing Cestus.  Anyway, I produce two reports, one is a host/services report, which is a nice running tally of inventory of hosts and services.  This has obvious utility beyond security and since I have all the info, why not grab it and analyze it?

Second report is the meat: my synthesized list of vulnerabilities and risk scoring. 

Now, how do I calculate the "risk"?  Well, that's the beauty of doing this myself.  Answer: anyway I want. Let's build an arbitrary risk model for scoring vulnerabilities to illustrate:

Alright, we'll use CVSS as the base score.  If there's no CVSS score for a particular discovered vulnerability, then just pick 5 (right in the middle).   Now add to it based on the vulnerability's age.... the older, the higher (again arbitrary weights at this point).  Add 5 more points if there's a known exploit.  I also have another table of vulnerabilities with their own weight factors to tweak this.

I use this to add or subtract from the risk score based on what I may know about a particular vulnerability in our environment.  For example, An open SMB share rates high but I'm doing a credentialed scan, so actually the share is locked down.  Drop the score by... I dunno... 6.  Add this up, and now we've got some risk scores, which I when I open the CSV in Excel, I can quickly sort on.

This is a nice quick way at looking at things.  As you may have guessed, this is only step 1 (actually step 2) in my plan.  The next step is link this to my intrusion dashboard so I can have company-specific threat intelligence feeding my risk models.  I also would like to add more external vulnerability scanning sources and feeds into my risk modelling calculator. Of course, I'll want to improve and test my risk model against the real world, see how it performs.  When I get that all working, maybe I'll blog about it.

Data Driven Security, Part 3 - Finally some answers!

I am continuing my exploration inspired by Data Driven Security. 

In Part One, I imported some data on SSH attacks from Outlook using AWK to get it into R.

In Part Two, I converted some basic numbers into graphs, which helped visualize some strange items.  The final graph was most interesting:

It was strange that there were twice as many attacks at the Dev SSH service as the DR service.  What is going on here?

Well, we've got over 37,000 entries in here over a couple of years.  Let's break them out and get monthly totals based on target.  First, I'm going to convert those date entries to a number I can add up.
Remember the data looks like this:

Each entry has a date and what target location was hit.  So I'm going to use an ifelse to add a new column with a "1" in it for every matching target

So now I have this

Now I add another vector the dataframe, breaking dates down by month

There might be an easier way to do this, but I'm still an R noob and this seemed the easiest way forward for me. Anyway, I can plot these and compare.

You can do this for all four and compare:

This gives me two insights.  First, different SSH systems began receiving alerts at different times.  Basically there are twice as many Dev alerts as DR alerts simply because the DR system didn't generate alarms until the middle of 2014.  Same with the Tst SSH system.  So there is a long tail of Dev alarms skewing the data.  In fact, the Dev system was the SSH system to go live.  Pretty much any system on the Internet is going to receive some alarms, so a zero in the graph means that service was not alive yet.


Second, we confirm and can graphically show what IT orginally asked back in part 1. To refresh your memory: said "The IT Operations team complained about the rampup of SSH attacks recently. "

Here we can visually see that ramp up, beginning at the end of 2014 and spiking sometime in the first quarter.

The next step in our analysis would be to see who was in the spike: are these new attackers?  Where are they from?  The traffic to the targets seem to peak at different times, so there might be something worth investigating there. 

And why did the traffic die down?  Were the IPs associated with a major botnet that got taken down sometime in April 2015?  A quick Googling says yes: "A criminal group whose actions have at times been responsible for one-third of the Internet’s SSH traffic—most of it in the form of SSH brute force attacks—has been cut off from a portion of the Internet."


I hope this series was informative to you as it was to me.  I was pleasantly surprised in being find some tangible answers on current threats from simply graphing our intrusion data.  Now it's your turn!

Data Driven Security, Part: the Second

In Part 1, Last time we loaded up 2 years worth of SSH attacks (37,000 entries) into R for analysis. A quick summary command gave us some interesting highlights:

But we can make some pretty pictures for upper management because they like graphs and it's easier to show differences.

First up, let's look at our the column on the far right, top countries banging on our door.  A quick query

Builds us an object with the top ten countries in it. Now after we make sure the gplot library is loaded library(ggplot2) and then we graph it:

  And we get:

If wanted to go a little deeper, we can look at our top IP addresses... maybe make the graph easier to read. Click to embiggen.

The other interesting thing in the original summary was the totals of which different service ("target") was attacked.  We can pop out a graph on those in pretty much the same way

Hmm... the Dev SSH server has been attacked more than twice as much as the DR server.  What is going on here?

We'll find out in part 3

Getting the Data for Data Driven Security, Part One

Continuing to building on my earlier post, "Questioning your security data", I'm now going to dive into looking into looking at active attacks.

The IT Operations team complained about the rampup of SSH attacks recently.  These particular services were protected by a variety of controls (which I won't get into). One of these controls is a detective controls which generates alerts when the service is attacked.

Historically, I've found this particular control has a very low false positive rate, which makes me happy. The bad news is that the alert goes via email, which makes it hard to suck into my ELK stack. The good news it that I've got a nice historical archive of these alerts. I've got about 37k logs of attacks against 4 different SSH servers in 3 different locations from Jan 2013 to present.

Well, I've had Jay & Bob's book sitting around so now I figured it was time to do some Data Driven Security.

Note: the purpose of this post is to give you ideas and pointers to learn some new techniques.  I'm not going to define an exact step-by-step on how to do this.  If you want to learn more on specific commands, follow the links or drop a comment.  Also, I know my code is crude and lame, if you've got pointers to improve, comment away.

First off, the data exists as email alerts.  I was able to simply do an export from Outlook to text (file->save-as) into one large msg file. So the contents of the file look like:





What's nice is that we've got a real time GEOIP look up, which is handy when reviewing data that's a few years old and IP ownership might have shifted.  The question is how to get this into a form usable for analysis?   The answer for me was AWK.  This quick and ugly AWK script quickly tears through this text file:

BEGIN      {  FS = " " ; x = 0 }
    $1 == "Sent:"  { month=$3; day=$4; year=$5;str = day; sub(/,/, "", day); time1=$6;  time2=$7; }
    month == "January" { month="1" }
    month == "February" { month="2" }
    month == "March" { month="3" }
    month == "April" { month="4" }
    month == "May" { month="5" }
    month == "June" { month="6" }
    month == "July" { month="7" }
    month == "August" { month="8" }
    month == "September" { month="9" }
    month == "October" { month="10" }
    month == "November" { month="11" }
    month == "December" { month="12" }
    $1 == "Subject:" { who=$5; where=$2 ; }
    $1 == "country:"  { print where "," who "," month "/" day "/" year " " time1 " " time2 ", " toupper($2);  }   
    $1 == "missing"  { print where "," who "," month "/" day "/" year " " time1 " " time2 ", " who;  }   
END        { print " " }

You can see that my script works email headers and mostly converts the date into a format that's easier for a machine to read. I just shove my file through this script and it gives me a nice CSV that looks like this:

Column one is the targeted SSH system (I'm giving them some cryptic names here based on asset classification), the attacker's IP, the date/time of the alarm and the GEOIP lookup.   Nice.  I could pull this into Excel and bang away at it, but instead I'll yank into R for some deep analysis.

A quick aside, I'm using RStudio for this example, so
At the R command prompt, I'm pull in the csv file into a dataframe with

alertlist <- file="alerts.csv" pre="" read.csv="">

And name columns:

colnames(alertlist) <- arget="" c="" ountry="" pre="" ttackerip="" ventdate="">

Oh, and I better convert the dates into R format:

alertlist$Eventdate <- alertlist="" as.date="" d="" m="" pre="" ventdate="">

which yields

Now I'm all set to do some analysis.  A quickie summary already tells me lots of interesting things:

Stay tunes for Part 2 where I do some of that.

Assuming your breached, what do you look for?

Building on my earlier post, "Questioning your security data", I thought I would share some details on how I'm querying my SIEM. Right now, I'm using ELK to correlate security event data from a variety of sources (firewalls, IDS, HIDS, antivirus, load balancers).

The first question that I care most about is "Have I been pwned?", calling back to the title of this blog.   So here's what one of my dashboards looks like:

The big donut chart on the left is a breakdown of all malicious activity with the inner pie-chart showing country of origin and the outer spoke giving me what port the alert was detected on.  A few interesting tidbits here:  China likes to send a lot of attacks via email, Australia is tracerouting us... but I want more about what's really going on inside my network.  So let's dig deeper.


Here's another pie-chart just showing virus alarms and what port they were detected coming in on. 



















Hmmm.. lots of email malware, but a fair bit of drive-by and possible botnet cnc activity.  Good to know.

Meanwhile, the graphs on the dashboard are serving up visualizations on network incidents detected by internal firewalls and IDS  (You do segregate your internal network with firewalls don't you?)  Here's a blow up of one of those:

The query driving these graphs is in the form of  "Show all IDS-alarms and firewall blocks where the Source-IP is an RFC1918 address"


The big spike on the left is damned suspicous... but on closer inspection, I see it's my vulnerability scanning box.  Ah, that's cool.  The next highest box is an IT inventory tool, which also does some active discovery.   Nice to know I can quickly spot who's scanning on my inside network.

If this is useful or interesting (or way off), let me know.  I can share more of theses as I build out my dashboards and queries.

Can Outsourcing Handle Cybersecurity's Complexity?

An article I wrote for Money Management Magazine - "Can Outsourcing Handle Cybersecurity's Complexity?"