Introducing the Source Code Podcast

A few weeks ago on Twitter, I teased that I was working on a new podcast called “Source Code”. Creating a podcast is something I’ve always wanted to do, but I’ve never really had the opportunity to pursue it until now. There are a lot of great podcasts in the information security space already, and I’ve been fortunate enough to be guests on a couple of them. So, what makes mine different (aside from being able to make fun of my accent)?

Source Code is an information security podcast that’s all about education. Rather than simply providing technical segments or news, Source Code is focused on the people that push information security forward and battle in the trenches every day.

We interview practitioners from every facet of information security about their origin story. This includes how they go their start, how they got into the field, and the career decisions that made them successful (or slowed them down) along their path. It’s the story of their source code — what makes them tick. We also talk about current opinions on the state of security education to include what we’re doing right and what we’re doing wrong.

You’ll hear from plenty of household names you’ve heard of, as well as some people you should know about with interesting back stories and unique contributions to the field. Source Code celebrates the diversity of backgrounds that makes information security a unique place to exist.

The #1 question I get asked is “How do I get into infosec?” My hope is that through this podcast, I create a library of stories that can help answer that question by showing people that there are a ton of different ways to get started, and each one can lead to great success.

The podcast will live here: http://www.chrissanders.org/podcast

You can also subscribe to it using your favorite podcasting platform:

If you like what you hear, I’d sincerely appreciate you subscribing, “liking”, or giving a positive review of the podcast on whatever platform you use. 

The show is seasonal, and the first season will have eight episodes that will be released every other Friday (you get this one early). I have some GREAT guests lined up, so stay tuned.

I hope you enjoy it!

Announcing the Practical Packet Analysis Online Course

I’m excited to announce my newest training course “Practical Packet Analysis”, with a portion of the proceeds supporting multiple charities.

Register Here

It’s easy to fire up Wireshark and capture some packets…but making sense of them is another story. There’s nothing more frustrating than knowing the answers you need lie in a mountain of data that you don’t know how to sift through. That’s why I wrote the first Practical Packet Analysis book a decade ago. That book is now in its third edition, has been translated to several languages, and has sold over 25,000 copies. Now, I’m excited to create an online course based on the book. The Practical Packet Analysis online course is the best way to get hands on visual experience capturing, dissecting, and making sense of packets.

Practical Packet Analysis takes a fundamental approach by exploring the concepts you need to know without all the fluff that is normally associated with learning about network protocols. Everything you’ll learn is something you can directly apply to the job you have, or the job you want. The ability to understand packets is a critical skill for network engineers, system administrators, security analysts, forensic investigators, and programmers alike. This class will help you build those skills through a series of expert-led lectures, scenario-based demonstrations, and hands-on lab exercises.

The Practical Packet Analysis course is perfect for beginners to intermediate analysts, but seasoned pros will probably learn a few useful techniques too. Whether you’ve never capture packets before or you have and you struggle to manipulate them to effectively achieve your goals, this course will help you get over the hump. You’ll learn:

  • How networking works at the packet level.
  • How to interpret packet data at a fundamental level in hexadecimal or binary.
  • Basic and advanced analysis features of Wireshark.
  • How to analyze packets on the command line with tshark and tcpdump.
  • Reducing capture files with Berkeley packet filters and Wireshark display filters.
  • Techniques for capturing packets to make sure you’re collecting the right data.
  • How to interpret common network and transport layer protocols like IPv4, IPv6, ICMP, TCP, and UDP.
  • How to interpret common application layer protocols like HTTP, DNS, SMTP, and more.
  • Normal and abnormal stimulus and response patterns for common protocols.
  • Troubleshooting connectivity issues at the packet level.
  • Techniques for carving files from packet streams.
  • Understanding network latency and how to locate the source.
  • How common network attacks are seen by an intrusion detection systems.
  • Techniques for investigating security alerts using packet data.
  • How malware communicates on the network.

Course Format

The Practical Packet Analysis course is delivered completely online using recorded video lectures that you can go through at your convenience. It is modeled like a college course and consists of lectures that overview critical concepts, demonstrations where I walk through packet captures, and lab exercises when you are given packet captures to work through on your own to practice the concepts you’ve learned. There is also a a discussion forum where you can ask questions and share tips and tricks with other students. The course includes over 40 hours of video lecture content, and can be completed at whatever pace is comfortable for you.

Prerequisites

This course has no prerequisites, but a basic understanding of networking is helpful. It is delivered in English.

Cost

Introductory pricing for the course is $797 for a single user license. Bulk discounts are available for organizations that want to purchase multiple licenses (please contact me to discuss payment and pricing). A portion of the purchase price will go to support multiple charities including the Rural Technology Fund, the Against Malaria Foundation, and others.

You’ll receive:

  • 6 month access to course video lectures and lab exercises
  • A Certification of Course Completion
  • Continuing Education Credits (CPEs/CEUs)

Sign Up Now!

This course is only taught periodically and space is limited.

Summer 2017 Session – Begins June 12 (Registration Deadline 6/9)

Investigation Case Management with TheHive

I’ve struggled for a long time to find a case management system that I thought fit well within the constructs of how analysts actually perform investigations. Most case management systems are actually just help desk ticketing systems that have been retrofitting to fit a security use case. This is what I see most often when SOCs are using tools like Remedy, RTIR, or OTRS. Last November, a group of researchers from CERT Banque de France (CERT BDF) released a new case management system called TheHive. The authors of the project describe TheHive as an “open source and free security incident response platform designed to make life easier for SOCs, CSIRTs, CERTs, and any information security practitioners dealing with incidents that need to be investigated and acted upon swiftly.” I would simply describe TheHive as a purpose built case management system to facilitate the investigation of security incidents. I’ve enjoyed using the TheHive so much that I actually integrated it into my Investigation Theory course where I teach people how to approach investigations and hunt down bad guys. In this post, I want to discuss a few features of the TheHive and why I enjoy it so much.

Architecture and Installation

TheHive is written in Scala and uses ElasticSearch to store and access data on the back end. The front end uses AngularJS and Bootstrap. A number of REST API endpoints are also provided to allow for integrations and bulk actions.

 

You’ll see Cortex mentioned in the diagram shown above. Cortex allows users to submit observables and indicators of compromise to popular open source intelligence tools via a series of Python-based analyzers. Ultimately, it is a separate tool with it’s own codebase, but  TheHive and Cortex go together like peas and carrots, so you’ll see them mentioned a lot in TheHive documentation. The installation command I’ll provide below will actually install both of them as a single integrated container.

There is a traditional Ubuntu 16.04 installation option described here which is probably most appropriate for production systems:  https://github.com/CERT-BDF/TheHive/wiki/Installation-guide.

If you just want to try TheHive or run it locally, you can get it running via containers with Docker. The installation process here couldn’t be simpler:

  1. Build an Ubuntu 16.04 system and ensure it’s up to date on system and software patches.
  2. Install Docker
    Info: https://docs.docker.com/engine/getstarted/step_one/#step-2-install-docker
    Command: curl -fsSL https://get.docker.com/ | sh
  3. Download and run TheHive w/ Cortex ():
    Info: https://github.com/CERT-BDF/TheHive/wiki/Docker-guide—TheHive-Cortex
    Command: docker run –publish 8080:9000 –publish 8081:9001 certbdf/thehive-cortex
  4. Connect to the web interface using a browser: http://IPofServer:8080
  5. Follow the on screen prompts to create an administrative user account

Case Management

The core construct of TheHive is the investigation case. I like this because the case is also the core construct of most security investigations, whether you’re reviewing alerts, reverse engineering malware, or working a declared incident. The case construct doesn’t provide a lot of bells and whistles, but that’s okay because I don’t think it has to. A lot of ticketing systems that are built to serve too many masters quickly become too generic to be useful. That isn’t the case here.

I particularly appreciate that you can add tags to cases for quick searching and filtering. You can also track TLP levels, which can help govern and facilitate the sharing of data. This is a nice feature that really shows how TheHive was custom built for investigation tracking. All the data you put into a case is easily searchable from the search bar at the top of the screen. This makes it really easy to determine if activity you’re currently observing was present in any earlier case.

Task Tracking

Once you’ve created a case, you can create, assign, and track tasks. A task can really be anything, but I recommend using them to track the actions taken to answer investigative questions. For example, if you’re investigating an exploit kit infection, a common question might be, “What was the system doing prior to when the alert was generated?”. To answer this, you’ll need to review evidence from whatever data source you have that will hold the answer. So, a task could be “Review HTTP Proxy data to determine what the host was doing in the 10 minutes leading up to the alert.”

In addition to answer seeking, tasks are also useful to track containment, eradication, and remediation events. You can create a task for disabling user accounts, quarantining a system, deploying an image to a system, or providing user security awareness counseling.

Tasks, like cases, have the concept of assignment. Therefore, each task can be individually assigned to an analyst for the work to be performed. By default, a task doesn’t have an owner until someone clicks into it, or “takes” it from the Waiting tasks queue in the top menu bar. This effectively creates a task queue that analysts can watch to help facilitate their work load. The queue can be filtered by any number of criteria like a specific tag, a case number, a task name, or a keyword. Tasks that are assigned specifically to you will appear in the My tasks queue in the top menu bar.

Case Templates

As a SOC evolves, it becomes critical to define playbooks that help analysts consistently approach investigations that share common attributes. For example, most the steps you take to initially investigate a series of failed passwords attempts or a phishing e-mail will generally be the same. If you can define those steps, you’ll have a great head start for training new analysts and ensuring most investigations start off on a level footing. TheHive provides a unique case template system that allows you to define common investigations and pre-populate case metadata and tasks.

In the example above, I’ve defined a template for investigations related to exploit kit activity. Now, any time I create a new case I can select this template and all the information you see there will be pre-populated into the case details. The real power here is in the ability to automatically create a series of tasks that should be completed when spawning the case. This essentially lays out the investigative playbook for you. With that, you get the added benefit of automatically populating the Waiting tasks queue so that other analysts can jump into the investigation or start completing containment and eradication tasks. This is, hands down, my favorite feature of the tool.

Collaboration

A key feature of any case management system should be collaboration, and TheHive hits the mark here. Each analyst using TheHive gets their own account which is used to log any actions they take within the tool. Users can own cases and/or tasks. One thing I particularly like is that once you create a case, virtually any action taken with it is recorded to create an audit trail. This audit trail is displayed to the right side of the individual case screens in a Twitter-style feed as seen in several of the images I’ve already shared.

Observables and Analyzers

TheHive allows you to create separate entries for interesting observables within the context of a case. An observable is any interesting data artifact, and TheHive comes with a number of common observable types built in. This includes things like IP addresses, domain names, HTTP URIs, etc. Of course, you can also define your own types which makes this capability quite flexible.

There are multiple benefits to tracking observables. The obvious one is that you can search for them during later investigations to bring in additional context. You can also export them for later import into a blacklist, whitelist, or detection mechanisms. Finally, you can use the built in Cortex integration to automatically submit the observables to any number of OSINT research sites. This is a very simple process, and primarily just requires that you input API keys for each service you’ll be using. Some of the existing integrations include Passive Total, Virus Total, and Domain Tools.

API and Integrations

Because the TheHive was built on a series of open API’s, it’s incredibly flexible in terms of integrating with other tools. The authors have produced really nice API documentation here: https://github.com/CERT-BDF/TheHive/wiki/API%20documentation. You’ll see that the documentation provides multiple examples of request formatting, along with several use cases. This includes the ability to query, create, and manipulate cases, tasks, and observables. This has immediate tangible benefits.

Consider a scenario where you’re running a signature based IDS. Any time a specific set of rules associated with exploit kit activity generates an alert, you could use the API to create a new case using a template like the one I showed earlier that is specifically designed for investigation of exploit kit related activity. Using this approach you haven’t just done a simple automation, you’ve created a workflow based on the playbooks you’ve developed. When you or another analyst go to review new alerts, anything related to exploit kits will already have a series of tasks created and waiting for you to accomplish. This is a time saver for experienced analysts, and a teaching tool for younger analysts who might not know what move to make next.

In addition to the APIs, TheHive can integrate with MISP and you can also write custom analyzers for use with Cortex. Once again, there are a lot of options here.

Conclusion

This post discussed a few of my favorite features of TheHive and how they can be used in practice. There are quite a few other features like reporting and metrics that I didn’t discuss here, so make sure to check those out on your own. A lot of tools that are used in SOCs were born in them. However, this is not an easy thing to do. Every SOC I’ve been in is different, and most of the times the tools that might come out of them won’t be nearly flexible enough to fit into the workflow that exists in another organization. The developers of TheHive have hit the delicate balance of creating a tool that is focused enough to deliver on immediate use cases, while still being broadly focused and flexible enough to be adapted to differing use cases. As stated earlier, it’s for that reason I use TheHive in my Investigation Theory course and why I’ll be recommending it for individuals who want to learn how to be analysts and for organizations that are seeking a simple case management solution that can get the job done.

You can learn more about TheHive at the project’s homepage here: https://thehive-project.org/. If you’d like to learn more about the investigation process and facilitating it with TheHive, be sure to check out the Investigation Theory course.

 

* Some of the images in this post were created from my home lab, but a few were borrowed from TheHive official documentation linked throughout the article.

 

 

 

Practical Packet Analysis 3rd Edition Released!

Ten years after releasing the first edition of Practical Packet Analysis, the third edition is finished and has been released! It’s hard to believe it’s been so long. So far, existing editions have sold tens of thousands of copies, been translated into multiple languages, and been used as a textbook in multiple college courses. I’m very humbled by the success the book has seen over the past decade.

Purchase Here from Amazon

Purchase Here from No Starch Press

If you’ve never read Practical Packet Analysis…

the key word I want to focus on is Practical. There are a lot of books about networking and protocols out there that get into the specific details at magnified level, but this isn’t that book. This book is written for people who need to do things like solve network issues, troubleshoot latency, or investigate security threats. Capturing packets is easy, but understanding them isn’t, and PPA is designed to give you the practical knowledge you need to get started down the right path. Practical Packet Analysis was the first book of its kind a decade ago, and the approach I’ve taken is unlike any other book you’ll find on the topic.

If you’ve read one of the previous editions…

I think you’ll like the new one too. Much of the introductory material is the same, but I’ve added quite a bit of new content:

  • Updated content for Wireshark 2.
  • A new chapter on packet analysis from the command line with tshark and tcpdump.
  • A bonus chapter on how to read packets in hex using packet diagrams.
  • New protocol coverage of IPv6 and SMTP.
  • All new scenarios related to network troubleshooting, internet of things devices, and security scenarios.

Charitable Contributions from Book Sales

A significant portion of the royalties from Practical Packet Analysis will be going to support a number of charities. This includes the Rural Technology Fund, the Against Malaria Foundation, and several others. Through your purchase of my books we’ve been able to put computer science resources into the hands of over 10,000 students just last year alone, purchase life saving mosquito nets for thousands of African families, and so much more. I’m thrilled to be able to use my work to serve others, and I hope you’ll share in that joy with me.

Acknowledgements

First of all, I want to sincerely thank everyone who has ever purchased any of the prior editions. I know you work hard for your money, so I’m glad my work was deemed worthy of your contribution and your time. As I always do, I want to share the acknowledgements and dedications you’ll find in the first few pages.

I’d like to express sincere gratitude for the people who’ve supported me and the development of this book.

Ellen, thank you for your unconditional love and for putting up with me pecking away at the keyboard in bed for countless nights while you were trying to sleep.

Mom, even in death the example of kindness you set continues to motivate me. Dad, I learned what hard work was from you and none of this happens without that.

Jason Smith, you’re like a brother to me, and I can’t thank you enough for being a constant sounding board.

Regarding my coworkers past and present, I’m very fortunate to have surrounded myself with people who’ve made me a smarter, better person. There’s no way I can name everyone, but I want to sincerely thank Dustin, Alek, Martin, Patrick, Chris, Mike, and Grady for supporting me every day and embracing what it means to be servant leaders.

Thanks to Tyler Reguly who served as the primary technical editor. I make stupid mistakes sometimes, and you make me look less stupid. Also, thanks to David Vaughan for providing an extra set of eyes, Jeff Carrell for helping edit the IPv6 content, Brad Duncan for providing a capture file used in the security chapter, and the team at QA Café for providing a Cloudshark license that I used to organize the packet captures for the book.

Of course, I also have to extend thanks to Gerald Combs and the Wireshark development team. It’s the dedication of Gerald and hundreds of other developers that makes Wireshark such a great analysis platform. If it weren’t for their efforts, information technology and network security would be significantly worse off.

Finally, thanks to Bill, Serena, Anna, Jan, Amanda, Alison, and the rest of the No Starch Press staff for their diligence in editing and producing all three editions of Practical Packet Analysis.

Dedication

This time around, rather that dedicating the book to an individual, I chose to include the first verse of one of my favorite songs, “Amazing Grace”. These words have profound meaning, and they just felt right positioned as the first words you’ll read in these pages.

“Amazing grace, how sweet the sound That saved a wretch like me.
I once was lost but now I’m found. Was blind but now I see.”

Reviews

Finally, if you do end up with a copy of Practical Packet Analysis, I’m always grateful for a review on the books Amazon page. A positive review is the most meaningful way to help an author whose work you enjoyed. If you’d rather share your review with me directly, don’t hesitate to e-mail me. I’m always happy to hear your feedback.

Increase Security Reporting with Contact Cards

After a really nice weekend, Zeke walked into his office and logged into his workstation. He made a habit of getting to the office around 7 AM on Mondays so that he could go through the pile of unanswered e-mails from the previous week and clear out all junk that accumulated over the weekend. As he was going through e-mails, he spotted one with the subject line “401k performance highlights” that was sent towards the end of the day on Friday. He had seen it then, but was in a rush to get out the door. He opened the e-mail and read that his 401k had performed better than expected over the previous quarter. A link was provided to review the details so he clicked it. That was when he realized he had made a mistake.

The link didn’t go to his 401k provider as expected, but instead went to a suspicious looking fake site that was made to look like it. Zeke had gone through information security awareness training, so he knew how to spot forgeries like this. It was very obvious that the site was hosted on a domain made to look like a legitimate bank, but was in fact not associated with it at all. He immediately closed his browser window and waited. His system seemed to be fine. No weird pop ups, no prompts to download any software, no weird slowness. He had dodged a bullet. He remembered that he was supposed to report occurrences like this, but wasn’t entirely sure where. Was it the IT helpdesk? No, it was a special e-mail address….or was it a phone number? He quickly looked up the contact number for someone he knew who worked in information security. Hmm, no answer. It’s still pretty early so that person might not be in. He shrugged it off and went about the business of responding to unanswered mail. By the time his day got going, he forgot all about the incident and it never got reported.


Stories like the one here are common in large organizations. Many companies do their part and invest heavily in security awareness programs that teach employees how to spot phishing attempts and security anomalies so that they can be reported. However, many organizations struggle with the final step in this process — effectively enabling their users to report anomalous activity.

So, why do users fail to report security issues when they recognize them? You might expect me to provide a long-winded underlying psychology perspective. However, the answer is much simple than that. People rarely have the opportunity to report security incidents, so they forget how to do it. Just like Zeke, they forget the e-mail address or the phone number. Further, they are often hesitant about whether anyone actually cares about what they’ve observed, and they’re worried that incompetence will be exposed. Of course, there isn’t incompetence here, but all that matters is that the individual perceives the possibility of it. Nobody likes feeling dumb, so someone certainly aren’t going to go out of their way to report an incident if it means potentially going through multiple layers of people. That increases the chance that perceived incompetence gets exposed. In summation, people are less likely to report security incidents unless it’s incredibly easy, and that is a defense mechanism that is difficult to overcome.

How do you eliminate that defense mechanism? Well, that’s a difficult question with multiple facets and is far beyond the scope of what I have to offer in this humble blog post. I think the better and more practical approach is to make security incident reporting as simple as conceivably possible. For that, I offer a non-technical solution.

The best strategy for reporting security incidents that I’ve seen is simple. Provide every employee with a security reporting contact card (SRCC), like the one seen in the image below.

As you can see, this card is incredibly simple. Ideally, this is printed to the same size as a business card on heavy stock. This provides a form factor sizable enough to display all the necessary information, but small enough to be easily tucked into a wallet or purse. The idea is simple: every employee receives one of these cards and is requested to keep it close at all times. While most employees can’t be expected to remember an obscure e-mail address or phone number, they will remember that they were given this card and can reference it without hassle.

So, what is necessary to include on the SRCC? This can vary, but I recommend making sure that the card can answer these questions:

  • Who can I e-mail/call for any network security related issue?
  • Who can I e-mail/call for any physical security related issue?
  • Where can I forward phishing or scam e-mails?

The purpose of this card is not to educate people on what’s reportable. That should be a goal of your information security awareness training and certainly won’t fit on a card. However, the three questions mentioned above cover a lot of the things that will generally be reportable. By providing e-mail addresses and phone numbers, you provide an implied escalation path if something is deemed to important or time sensitive for e-mail.

A few other tips:

  • Use a bright, easily noticeable color on your card. This will help people spot it and remember where it is in their wallet/purse.
  • Make the design somewhat different from your normal company business card template.
  • Setup a special e-mail address to receive forwarded phishes separate from your normal intake queue. This will help with prioritization and tasking.
  • Build this into your security awareness training. Occasionally challenge people to produce these cards so everyone gets used to keeping them handy. Make sure you are clearly identifying what is reportable and what isn’t based on your organization’s threat model and ability to evaluate reported incidents.

If you want to get started right away, here’s a Microsoft Word template you can download and use now. Just replace the logo and information with your own, print it out, and hand them out to your employees.


So what ever happened with Zeke? Well, it turns out that once he clicked on the link in the phishing e-mail, his browser downloaded a flash exploit which led to a malware infection. An attacker was able to leverage access to this system to retrieve sensitive information about Zeke’s company. It took the attackers a few weeks to complete their attack. But, since the detection tools in the organization didn’t pick it up, and Zeke never reported it, the attack wasn’t discovered until much later. The organization did a lot of things right, but a failure to make incident reporting easy subverted much of their effort. Security contact cards a simple, affordable, effective way to make sure you don’t fall victim to a similar scenario. The minimal cost of printing and distributing these cards is nothing in comparison to what you might pay if something goes unreported.