<![CDATA[Shadow Trackers - Blog]]>Tue, 06 Jun 2017 19:15:49 -0700Weebly<![CDATA[What is old is new again]]>Thu, 04 May 2017 01:15:10 GMThttp://shadowtrackers.net/blog/what-is-old-is-new-againMy family was driving back from a trip to my parents house a couple of weeks ago.  During that drive I had several hours where I was looking to fill the time. So I wrote down some blog ideas, listened to some podcasts, and read some blogs in my RSS feed. But I also started going through notes from past cons. I've mentioned before about how important I think it is we apply what we learn at cons.  The way I do that is by taking notes and then referring to those notes later. I often take a LOT of notes; sometimes by hand in a notebook and sometimes digitally for two reasons:

  1. Remember suggestions/tips/tricks that will help improve security
  2. Share what I learned with those who didn't go

The problem is that with so much information in my notes, things get lost or buried over time.  This means that some items that fall into category #1 don't get implemented.  So I've started taking downtimes such as the drive home to review my notes and find those things I forgot about, determine if they are still relevant, and send myself a new reminder to try them out.

So, have you been taking notes at cons that you go to?  Are you saving them in a safe place?  If so, set some time to review your old notes.  You may find some forgotten treasure in there you didn't know you had.
<![CDATA[What Does Security Do?]]>Thu, 20 Apr 2017 00:38:26 GMThttp://shadowtrackers.net/blog/what-does-security-doRemember a few years ago, there was a popular meme going around where people described what they did vice what other people think they did vice what they actually did? Well, I was thinking the other day during one of the Scout hikes I was on (The Boy Scout troop my sons are in is a hiking/backpacking troop, but that’s another blog post) about that and instead of applying it to myself, I tried to apply it to information security as a whole. Below are my thoughts based on recurring issues within information security.  Then I end with what I think we should be doing. 
What Users think Security Does
  • Add more authentication to every part of the network
  • Block access to all websites
  • Deny all requests for additional features
  • Spy on all traffic
  • Restrict permissions on each machine so that it’s unusable
What Management thinks Security Does
  • Ask for new tools/devices
  • Add additional paperwork for new regulations/laws/requirements
  • Request more training
  • Block new tech/say things can’t be done
  • Cry ‘wolf’ all the time (New attack! New Vulnerability! 0 Day! Nation State! Danger Will Robinson!)
What Operations think Security Does
  • Break things by scanning
  • Prevent systems from working by implementing unnecessary security settings
  • Slow deployments by requiring security testing/compliance
  • Increase complexity of network
  • Slow network down
  • Constant sci-fi doomsday scenarios based on unicorn possibilities
What Developers think Security Does
  • Reject completed projects/apps for “lack of security”
  • Add additional unnecessary hurdles to nearly completed projects causing delays
  • Add complexity to applications/projects
  • Confuse customers and users with ‘requirements’
  • Slow the application with implemented security
  • Raise sci-fi doomsday scenarios based on unicorn possibilities requiring esoteric configurations
What we think we do in Security


While leading a mild manner life as an overwhelmed security tier 1 security analyst

What we in Security should be doing
  • Working alongside users to understand their work flows and processes to integrate security as seamlessly as possible
  • Working with ops to engineer security into deployments and applications
  • Participating in management discussions to develop solid risk analysis based on a solid understanding of the business, critical data/processes and strategic partners.
  • Working with developers to understand the requirements of each project and design security into the application so that it is as transparent as possible to the user/customer. So that security is integrated into the solution behind the scenes and alternative solutions can be found if necessary.
  • Actively monitoring the environment, of traffic going out, coming in, and moving internally as well as activity on user workstations, externally facing servers, and internal devices for malicious and suspicious activity.
  • Developing and maintaining procedures for investigating and responding to malicious and suspicious activity.
  • Developing and executing hunt methods to find hidden malicious activity.
  • Providing management status and metrics showing the risks they are facing and where the organization stands in relation to their horizontals and verticals in terms of security.

<![CDATA[How I got into Security Engineering and what it means to me]]>Sun, 26 Feb 2017 03:05:38 GMThttp://shadowtrackers.net/blog/how-i-got-into-security-engineering-and-what-it-means-to-meMy career started with a degree in Electrical Engineering and that started with a strong curiosity to learn how things worked.  After graduating, I spent ten years in the military working on networks.  First as a sysadmin, then assigned to a team that focused on optimization and troubleshooting networks at different bases all over the world.  This is where I truly learned about how networks worked, why they worked, and how to make them work better, all the while ensuring the mission was not interrupted.  My next career stop was in a network security manager role at a government organization where I learned to navigate both the politics of getting permission to improve security and the technicality of implementing security; again without disrupting the missions of multiple interest groups.  The experience I gained during both of these jobs formed my basic philosophy of how I approached every job since then. 

This philosophy boils down to three things:

1.  My jobs as an Security Engineer is to improve the protection of users, data and processes while impeding those users, data and/or processes as little as possible.
  • Don't negatively affect the mission of your organization.  In a fight between security and mission, mission will always win.

2.  I can't do #1 without understanding how my protection improvements work, and how they have to be integrated into the network to work properly and what the impact to the network will be during and after integration. 
  • Nothing affects your credibility more than appearing that you don't have a clue about how your tools work or how the environment your tools are in work or that the effects were unanticipated.

3.  My job cannot be done in isolation.  I must have a good interactive relationship with the operations group, dev group, compliance group, users group and the management group.  Otherwise I run the risk of being ineffective, disrupting the mission and making the network less secure. 
  • You will make your job that much harder if you are arrogant, or stubborn, or condescending, or all three toward your coworkers.  They will not want to cooperate and will stonewall you and your efforts regardless of how much those efforts make sense or are required.

<![CDATA[What you need to learn to start learning Infosec]]>Sun, 05 Feb 2017 03:03:59 GMThttp://shadowtrackers.net/blog/what-you-need-to-learn-to-start-learning-infosec 
This is a little bit of a long post. Here’s the TL;DR
  • There are at least three groups of people where it appears that a percentage of each group lacks a basic understanding of IT. These groups are: Individuals getting into infosec, recent colleges grads and compliance auditors
  • My suggestion is to generate a common ground of IT knowledge all infosec professionals should know, no matter what infosec career they choose
  • I suggest this common ground have three categories: Computing, Operating Systems and Networking. In each category, there will be certain knowledge you must know and skills you must have.
  • I hope my suggestion will start many more discussions so that at some point there is a general consensus, one driven by the industry not by a company.

One of the questions I, and many others, are often asked is “How do I get into Information Security?” and over the past few years, there have been several excellent blog posts and talks covering that very topic (see the links at the bottom of this post or this link to a compilation on ForgottenSec github). However, I recently had a situation where an individual asked me this question and I realized that none of those blogs or talks could help him… yet. The reason those resources could not help him was because they all assumed the person interested in information security already had experience in IT. This person did not.

Now, as you know, not having any experience in IT is not an impediment to becoming a great infosec worker. Most of us learned IT along the way. Some people were self driven, always trying to figure out how things worked or how to make THIS work to get THAT to work. I took a different path as I was a 9-5er who was blessed enough to get some great training and have good jobs until I was bitten by the bug… now I’m as driven as any; going to cons, writing a blog, giving talks, etc. But I realized my advice to this individual was going to have to take a different approach. He was interested in learning, but I could not just have him start running nmap or playing with metasploit since he didn’t even understand TCP/IP. I first had to come up with what I thought were the prerequisites he needed to enter into the infosec field.

While I was working on this list, Shmoocon was going on and I had a chance to bounce my thoughts off several individuals at that con. Several of them pointed out another group of individuals that would benefit from this list of prerequisites: Recent graduates of colleges who had a received a cybersecurity degree of one type or another. They pointed out that many of this grads have a good understanding of what security is, but not about how it works technically. This concern was confirmed in a recent discussion on one of the SANS email lists where multiple infosec professionals talked about the challenges they were having hiring recent graduates that met the technical requirements needed to perform entry level jobs. These grads understood policy and concepts, but they couldn’t actually look at packets or even in one case, recognize a hard drive visually.

So now I had two categories of people who need some kind of baseline IT knowledge. While I was researching this article, I thought of another type of person who would benefit from that baseline; the compliance auditor. We’ve all run into the issue where we need to work with a policy or compliance auditor who only understands the checklist or the theory written into the policy. This inevitably leads to conflict when a technical solution is implemented that meets the purpose of the policy, but is unorthodox and the auditor rejects it because it doesn’t match what is written. Or the opposite, when the auditor accepts a solution because it meets what is written, but the solution doesn’t actually protect what the policy says it is supposed to protect. An auditor who has a fundamental IT understanding underneath the security knowledge would do much better in these situations.

So I looked at some certifications, some job descriptions, some course requirements, and had some discussions to get an idea of what was expected of new infosec professionals from different groups. I then began to compile a list of what I thought was common ground among all these sources. Thinking about this common ground reminded me of something. (stay with me on this) In the past, I’ve heard some people compare the maturing of our industry to how medicine matured over then centuries in training and practice and standards. While I don’t think you can take that comparison too far, I will use this one analogy: We should have a “med school” requirement. That is, there should be a certain set of skills and knowledge every infosec practitioner should learn first, regardless of the career field they enter. So when the pentester talks to the compliance auditor talks to the forensic expert, they may each have specialized abilities, but there is a common foundation they all understand. How should this common set should be formed? Well like everything else, through lots of discussion, arguments, more discussions and practical observations. Will we need some kind of industry wide board like the AMA that makes a final decision or will the masses come to some kind of general agreement? I don’t know. Please, though, let’s not have some company come up with their own certification and try to sell that to us. Will those that are self driven learn far more that this common knowledge set? Sure. Will is ensure that every infosec person is competent? No. But I hope that it is a start and what I do know is that whatever we come up with needs to be flexible as it probably should change at least every year. I think as we work to mature this field and we look for ways to bring massive amounts of people in to fill all the open positions, we need to standardize knowledge and skills.

So, here are my suggestions for the things that I suggest are the common foundational skills and knowledge needed for someone to enter into infosec. This baseline knowledge enables a person to understand the underlying architecture of how the Internet works. These are the thing that experience infosec professionals know inherently, that new people should know. And therefore, these are also the skills and knowledge someone who is non-technical needs to attain so they can start learning infosec.

A person needs to have skills and knowledge in the following three areas: Computing, Operating Systems, and Networking. Note that while there will be overlap between areas, I’ve tried to create a layered approach to the levels. So, for example, while Network Drives may be a form of storage, I’ve left that out of the Computing section and put it into the Networking section.

All about the computer, what it is, how it works and what forms it takes (desktops to IoT and everywhere else)

A person needs to know:

  • How a computer works
  • Input devices (keyboards, scanners, etc)
  • Storage (RAM, Hard Disks, USB, CD/DVD, etc)
  • Processing
  • BIOS, hard drive boot sector, booting, etc
  • How a computer program runs
  • High level language vs machine language
  • How instructions are loaded, executed and output delivered

A person should be able to:

  • Point out major components of a computer
  • Do a hard reboot, soft reboot, get into the BIOS, change boot order

A person should know about the places computers are going into and what form factors they may take.

Operation Systems 
All about the software that makes the hardware work

A person needs to know:

  • Different types of OSs (Windows, Linux/Unix, OS X at least)
  • Purpose of kernel and “user space”
  • Purpose of drivers, applications, daemons/services,
  • Purpose of accounts, groups, and their access levels (root, administrator, user, guest) and how to create new groups with new levels of access.
  • Purpose of objects and their permissions
  • How users, groups and their access levels interact with objects and their set permissions
  • Logging, what gets logged and why
  • Firmware, software, etc
  • Difference between authentication and authorization

A person needs to be able to:

  • Install an OS
  • Create users, files, folders and set permissions for different levels of access and abilities
  • Install applications and set different levels of permissions for use
  • Enable logging and read and understand logs and be able to diagnose basic problems
  • Use the command line and gui for common commands

All about how computers talk to one another, how data gets transferred and how things are controlled remotely

A person needs to know:

  • OSI model and the protocols that go with each layer
  • How the Internet works (addressing, routing, subnets, DNS, 3-way handshake, how data is transferred, ….)
  • What the following are, how they work and what they are used for:
    • Firewall
    • IDS/IPS
    • Proxy
    • DNS
    • Email server
    • Routers/Switches and permeations of this group
    • VPN/RAS/RADIUS/etc
    • Web Servers
    • Databases
  • What network traffic looks like and what the packets look like in a traffic analyzer
  • how client/server methodology works
  • Windows networking
  • *NIX networking
  • Network Authentication and RADIUS
  • Encryption
  • Remote access (RDP, telnet, ssh, scp, ftp….)
  • How accounts and groups are created and managed on a networking vs stand alone
  • How objects are created and managed on a network vs stand alone
  • How applications work on a network vs stand alone
  • How object and application permissions interact with users and groups and their access level on a network vs stand alone
  • Understand how computers and networks use binary, hexadecimal and decimal numbers
  • On a windows server: Understand windows GPO, Security policies, user accounts, user groups, event logs
  • On a Linux server: user/group, iptables

A person should to be able to:

  • Capture, identify and read network traffic (using wireshark or equivalent)
  • Install *NIX and configure different users into different groups for ssh remote access
  • Install Windows Server and configure basic policies
  • Understand logs and perform basic troubleshooting of network activity
  • Create users and groups on different platforms and configure remote access
  • Perform basic network troubleshooting (ping, traceroute, netstat, ps/tasklist, etc)

I know I forgot some things. I know I left out other things. The point is to continue the discussion.
So what have I left and and why do you think those things should be included?

Are the other people who have compiled and published their own list of common knowledge and skills? Other collections that have been proposed as a standard?

Or is this concept wrong to begin with?

Let me know your thoughts. If you have other links, I’ll post those on my page and I hope others will post my link on their page so these discussions can continue.

NOTE: I gave a 20 minute presentation on this topic at Shmoocon Epilogue in January. This post is an expansion on what I talked about then. If you want the slides, however, they are here.
File Size: 89 kb
File Type: pptx
Download File

<![CDATA[SIEM Maturity - Some additional thoughts]]>Thu, 26 Jan 2017 03:20:16 GMThttp://shadowtrackers.net/blog/siem-maturity-some-additional-thoughtsI've been managing a SIEM for about four years now and I've been really aggressive about making it as useful as possible be for all users. Recently, after achieving a fairly significant milestone, I started looking for a way to measure the maturing of our SIEM implementations. This way I could map out the areas I still need to improve. While doing my research, I found that as usual, Anton Chuvakin has this topic covered (see references below). I also found a good brief by John Velisaris at the Portland ISSA SIEM Symposium entitled “SIEM Maturity and SOC Optimization” that provided an additional view on how SIEMs should grow with your SOC that provided some additional insights. But as I started creating my own road map, I realized there were additional things I wanted to accomplish in order to feel like our implementation had reached maturity. Perhaps, these could fall under the Level 6 to which Anton alludes.

One note: I will often use the word ‘products’ when talking about the SIEM. By this, I am referring to any alerts, dashboards, reports and feeds generated by the SIEM.

I broke my goals up into categories, Documentation, Self-Monitoring, Tuning and Misc.

Documentation: While both Anton and John talk about the need to document your SIEM, I feel there are some specific items that I want to capture:

  • Document all log and event sources. In addition to monitoring all input, know where those inputs are coming from and how those inputs get to your SIEM. This really helps during troubleshooting/compliance. I have some inputs that take two to three steps from the original source to the SIEM DB. Having a place where that is written down helps prevent from having to trace each step when something breaks.
  • Document all tweaks, exceptions, 'rube goldbergs', and other customizations. As you know, some inputs work out of the box and others, well, others take some manipulation of the parser, the feed or permissions to get the input to work consistently and correctly. Annotating what you did to get the input working and why you did it, will help when that input breaks.
  • Document any feeds being sent from your SIEM to other devices or groups. In some cases, your SIEM is exporting a data feed to another party or into another device. Document who or what is getting the feed, what type of data is in that feed, how that feed was created, and why that feed was created. Also, note the POC and contact information for who or what is receiving the feed.
  • List all users and groups that have access. This should include what data each group or users should and should not have access.
  • Document alerts and reports so that someone new can quickly understand what each alert is for, why it was made and what to do when it goes off.

Self-Monitoring: While self-monitoring is also mentioned in most of the research I did, I had a few other events for which I needed to watch:

  • Monitor your users to see when and how often they log in and what they use/view. By doing this you may find new requirements, determine badly written use cases and/or find products that need to be adjusted.
  • The SIEM should track it's own metrics. While the IBM SIEM security maturity model has some good examples of SIEM and SOC metrics to track, I feel you should also track items like license usage and the load on the SIEM. This is often built in, but not always in a location that is easy to view.

Tuning: As you know, you need to tune your alerts, dashboards and reports. But while I was doing refining my products, I realized two specific tasks I needed to make happen:

  • While I mentioned earlier to document exceptions, I think I need to emphasis that you need to document the exceptions/customizations (see above) you make while tuning. This helps viewers of your products understand what they are looking at and why some data may not be included.
  • As part of tuning, you should have a method for feedback, so that you can refine your products to better suit your customers based on what they tell you.

Miscellaneous: Some additional items that I thought a mature SIEM should have:

  • A good written "Introduction to Our SIEM" type of document. This document can be given to new users and new groups that are starting to use the SIEM. It would contain basic instructions for how to search, how to use dashboards, and how to read alerts and reports. It also would contain a description of the products available and, if possible, a link to each one. The hope is that by using this document, it will accelerate a new users ability to use the SIEM without asking for help all the time.
  • Custom use cases and custom content that have been created in the SIEM. Custom use cases are use cases created for the specific enterprise that the SIEM resides in. These use cases may also include custom content; that is content generated by scripts or DB queries or monitoring tools specifically for your enterprise.
  • Context added to products and search events. By using Threat Intelligence as well as additional queries and/or inputs (such as nslookup or reference tables), all products and search results from the SIEM can provide additional information about the who, what, where, and when of an event. By providing more information the first time an analyst sees an alert or report, you speed up their ability to make a decision.
  • Automation of simple use cases in any place that the SIEM is able to take action.  This may include such actions as opening a ticket or modifying an access control list. In some cases the SIEM can take this action independently; in other cases, the SIEM works with another tool like an orchestrator to accomplish this task.

After adding these items to my maturing plan, I have a better picture of where I need to go with my SIEM and I am able to refocus my efforts to improve and increase the value it brings to my customers.

Did I miss anything? Over think something? Or is there an area I’m completely off?
Say it in the comments!


Anton Chuvakin of Gartner

IBM Brief from Portland, OR ISSA

Other links