De-Coder’s Ring

Consumable Security and Technology

Month: March 2017 (page 2 of 2)

Recursive Alerts

I don’t often play SOC analyst, but when I do, I see some funny things…  some scary things… and a lot of mundane things.

One of the interesting things we’ve seen recently in the Perch SOC is what I’ll call a ‘recursive alert

What’s an alert?

I built a sensor for customers around the open source tool, Suricata.  It’s magical, wonderful, and freaking fast. The developers are awesome folks, and they deserve lots of money/beer/bourbon when you see them.  See other items related:  Suricata NSM Fields  , Suricata Stats to Influx DB/Grafana , Installing Filebeat to ship data to Elasticsearch

Suricata can monitor network traffic, looking for specific rules.  Rules can be built to look for IP addresses, domain names, packet content (strings, binary, etc).   If  a rule matches some traffic, then Suricata will generate an alert record.   These records have Network layer 3/4 information (source and destination IP addresses, ports), as well as protocol information.  It can also put the ‘printable payload’ in the alert record.  This is the ASCII printable contents of the packet that triggered the alert.  It also prints out the hex, in case it’s not printable/binary content.  This is truly wonderful when it comes troubleshoot.

Meta Alert

(Building up towards a recursive alert, hang tight)

A few days ago, our SOC lead and I were triaging a bunch of new alerts from a customer of ours.  These were bad news, we were kind of scared.  Like, honestly scared because this meant there was a major breach or infection.  In the years I’ve been doing network security, I’ve never seen this many hits on rules.. this many diverse hits on rules.. at the same time…. between two hosts.. wait a second.. something is wrong.

Multiple exploit kits, multiple content matches on web sites. ok, something funny.  Turns out, one end of the TCP connection was a backup server (keeping the type quiet for now), the other end was a Nessus server.  ah ha!  The rules were triggering on the metadata/configuration files in Nessus!   Nessus is a vulnerability scanner.  It has TONS of information about exploits..  when those files were backed up across the network, my sensor triggered!   The rules matched, but why the heck was the backed up data going in clear text over the network?   SSL/TLS is easy!  SCP/SSH is easy!  Come on vendors, pick up your game.

Recursive Alerts

Now here’s where we get recursive!  Some suricata rules look for content.  Actual, raw strings of content within packets.  They can be chained together (think this:  See “one” followed by “two” followed by “three”) for specificity, because we all hate False Positives!!  Now, imagine the ‘rules’ file that contains the … rules.   It gets backed up on the network, and BAM, the rule detected itself.   Recursive rules.  Self detecting rules.  Did it get incepted?

Lesson of the day

Use encryption on the wire when backing up everything.  Simple.

 

 

 

Ship it!

Every time I forget the mantra “F(orget) It, Ship It”, things don’t go well.  Analysis Paralysis.  Develop towards a stale goal.

Historically, projects get bogged down for ages making sure it’s “perfect”.

Face it, it’s never perfect.  Ever.

This applies to software, companies, features, church activities and anything else that might be new and untried before.  Analysis and rework is the killer of new ideas.

I build products for people to use.  I know the data that my products use.  I know some of the pain points I’m trying to solve for customers (current and future!).  It’s SO easy to say “oh dang, let’s just add this one more XYZ widget before we call MVP”.  It’s easier to add new features than it is to declare a product “good enough”.

OMG! HE SAID GOOD ENOUGH!

Yes, I did, and will again.  Nothing is ever perfect, and “good enough” is not a declaration on the quality/reliability/security of a new piece of software code.  It’s ‘good enough’ for someone to use.  This is why we strive for a minimally viable product, or MVP.

Counter that with the bad attitude: “good enough”.  That’s a statement on being lazy, not having professional quality standards and not giving a crap about what happens once something leaves your desk.  This is NOT what I’m advocating for.

Draw a line in the sand

Before you build, define your target. Define your MVP.  Define what is ‘good enough’ to your customer.   It can’t suck.  It has to add value.  It has to be easy (enough) to use.  It can’t be ugly, but it doesn’t have to be a work of art.  Ever see the first Google home page or the first version of Splunk?   Compare them to the current interfaces.  Good enough at work.

 

 

Top 5 Threats to Small Businesses

Your company is unique.

The threats against you are real.

Your company is a target.

Consider this.   If you’re a small concrete company that does a few million dollars a year in revenue (or less..  ), then you can easily become the target of some bad actors out there who think you might have just enough money to mess with you.  The target on your back may not be the same size as  Target (see what I did there?), but you’re probably a much easier target than Target..  ok, I’ll stop saying target/Target.

You are small enough that won’t have full time IT people, you absolutely don’t have security people.  You will not see an attacker probing your wifi, your email system, your public IP addresses, etc.  Here are the top 5 ways they’re going to get in:

  1. Phishing  / Spear Phishing –  Sending malicious files or web links to your email
  2. Social Engineering – Someone will gain the trust or deceive one of your employees, who will leak information
  3. Physical Security – Smash and Grab!  Say goodbye to your laptops
  4. Bad Passwords – Old, tried and true, don’t use “password” or “password123” as your password
  5. Mobile Devices – No passcode? No thumb print?  Problem!

None of those are necessarily solved by technology problems.   That’s hard for me to say, since I’m a technologist through and through.  I think code can do all and fix all.   The solution to all those things above is good employee education.

Teach your staff that there IS something to be concerned about.  Come up with secret code words when you call in and authorize a transfer of a few thousand dollars.   Be paranoid.   Think like the bad guy.  

Phishing – Don’t click links. Ever.   If the link looks like “bankofamerica[.]com”, then just type it… never click it.   The last thing you want is some ransomware infecting your network and blocking your Quickbooks file.  That would suck.

Social Engineering – Don’t give out anything. Ever.  Over the phone or in person.   The tidbit you’re sharing today, can be put together with other information over time to get access to a bank account.

Lock your doors!  Put away laptops after hours.  Look into security camera, motion sensors, etc.  Your office has a sweet window, but remember they can see in from the outside.  Got a new shiny iMac?   New target for the dude walking by who wants to steal it from you.

Passwords – Use a password manager already.   Enforce password length and don’t allow dictionary words.   Look into Dashlane, LastPass, etc.   No two systems should share a password.

Mobile – Put a passcode on it.  Make it lock automatically.  Depending on your level of paranoia, don’t allow corporate/work emails on a personal phone.  Whether that’s by policy or technology, just don’t allow it.

 

Need help with any of this?    Start a conversation.  Heck, reach out to me.   Talk to your IT contractor/help desk person.   Take it seriously.  

Newer posts

© 2017 De-Coder’s Ring

Theme by Anders NorenUp ↑