<![CDATA[Shadow Trackers - Blog]]>Wed, 01 Nov 2017 18:58:51 -0700Weebly<![CDATA[Stop me if you've heard this joke before..]]>Thu, 02 Nov 2017 01:07:35 GMThttp://shadowtrackers.net/blog/stop-me-if-youve-heard-this-joke-beforeYou’ve heard this joke before I’m sure:

A man walks into the doctor’s office.

The doctor says: What seems to be the problem?

Man: It hurts when I do this.

Doctor: Well, stop doing that.

Ba-dum bum, pish!

While this may draw a chuckle or a groan or complaints about what universal health care will become, there are some things that this fictional situation doesn’t address. If this was real, there would actually be a diagnosis and then a suggested treatment. And that treatment would depend on what ‘THIS’ is, that the patient is doing. If ‘THIS’ is crucial to life (say lifting his hand to eat) , then the treatment options become necessities and the patient wants to pay for a permanent quality solution. If ‘THIS’ is unnecessary to life (say learning how to throw an atlatl), the answer may actually be stop doing that because it’s not worth the cost of the treatment just to so something the patient doesn’t need or want to do. If ‘THIS’ is an enhancement in life (say throwing a baseball with his kids) then the doctor and patient need to decide which treatments are available, what the effects of each one are, and perform some amount of cost benefit analysis to chose the best one for the patient.

So how does this apply to information security? Well, it’s another way to look at integrating security into an operational environment. Users are constantly requesting new capabilities in the Enterprise or complaining about the lack of functionality of the current capabilities. In this scenario you have the role of one of the doctors on the patients team working with the Ops doctor to diagnose and treat the users pain, their ‘THIS’. The ‘THIS’ for this scenario is the capability the user is asking or complaining about. And you have to find out if ‘THIS’ is required, an enhancement, or unnecessary.

If ‘THIS’ is unnecessary, then you need to be able to politely and firmly (possibly with support from policy [best] or management [hopefully]) deny the user what they want.

If ‘THIS’ is required, then you need to work with your team and with Ops to solve the user’s complaint or request at the most efficient cost in terms of time, money, and resources.

If ‘THIS’ is an enhancement, then you have some work cut out for you. Because now you need to perform some type of cost benefit analysis and provide that to management (and possibly to the user) that will help them make a good decision regarding the implementing the solution for their request or complaint. Will it be the platinum, gold, silver, or bronze implementation? Temporary or permanent? Once those questions are answered, then you can provide a recommended solution, but management must make a decision and communicate that decision to the user as to whether or not their request or complaint will be resolved.

Because sometimes that decision is still: Stop doing that.

<![CDATA[Baking my own Pi3]]>Tue, 22 Aug 2017 01:19:25 GMThttp://shadowtrackers.net/blog/baking-my-own-pi3For the past few weeks, I’ve been working at installing Bro IDS onto a Raspberry Pi 3. This is for a project I’ve been thinking about for a while and if successful, I will submit to several cons. But in the meantime, I want to document what I’ve done both for myself and anyone who may be interested.
I’m not going to repeat things where someone else has done a great job of writing them up. I will merely put a link to the web page where you can go read.
To start with I have a Raspberry Pi 3 (https://www.raspberrypi.org/products/raspberry-pi-3-model-b/) on which I installed Rasbian Lite (https://www.raspberrypi.org/downloads/raspbian/). I used Etcher (https://etcher.io/) to burn the image to a 32GB microSD card. I also bought a power supply for the Pi3 after trying unsuccessfully to use one of the MicroUSB cables/plugs I had lying around the house. Turns out most of the ones used to recharge phones are at most 2.1 A (and some not even that) and the Pi3 needs 2.5. So my Pi3 kept rebooting over and over until I got the new power supply. (BTW, this is when I REALLY miss Radio Shack. This delayed me two days waiting for Amazon to deliver). So my advice is buy the power supply when you buy the Pi3.
I don’t have a HDMI monitor, but I have plenty of VGA connected monitors. A simple HDMI=>VGA converter works no problem. I’m using the Inland brand from MicroCenter (yes, I know, why didn’t I buy the power supply while I was there… IDK..anyway). Anyway:

Once I burned the image, had the right power supply and booted up and voila! I was in.

username: pi
password: raspberry
I shouldn’t have to tell you, change these as soon as possible.
Now, I had a working Pi3, on a monitor with a keyboard. I connected it to my network and proceeded to update and patch, apt-get update && apt-get upgrade.
The raspberry foundation has a nice list of configuration steps here: https://www.raspberrypi.org/documentation/configuration/ and I worked thru them as I thought they applied to my environment.
Run the raspi-config configuration tool and set up your environment. This is where you turn on the ssh server.
I set about securing the Pi3 by doing things like turning off the bluetooth, disabling telnet, locking down ssh, etc. (https://www.raspberrypi.org/documentation/configuration/security.md)
I worked on setting up the wireless card, since I wanted the wired port to be the listening port.
That turned out to be a little bit tricky. The instructions given on the Pi3 page didn’t work for me: https://www.raspberrypi.org/documentation/configuration/wireless/wireless-cli.md
but these did:
Except if I reboot, I have to turn the wifi back on. Argh. Still working that out.
Once I got the wifi to work, ssh’d to the wlan port so I could leave the wired port for bro to use exclusively.
Once I got Raspian configured to where I liked, I started looking at how to install Bro on the Pi3. There are a bunch of folks on the web who’ve done this before:
As well as lots of instructions for installing Bro in general:

I just chose to follow the instructions here:
Since all of these instructions are pretty much the same, I’ll just note some of the challenges I had with my install and how I got through them. Obviously, YMMV.
First, regarding the pre-requisites:
I had to make sure ‘git’ actually installed correctly. It’s much easier to pull and install Bro using git. Also, a lot of custom bro scripts are kept on github, so having git installed makes it easy to deploy those.
Make sure you install GeoIPv6 as well as GeoIPv4. Raspian and the Pi3 understand IPv6 so you don’t want to miss out on that data.

Getting sendmail configured so that it could send me mail to my gmail account took a little bit of trial and error. Fortunately, I found this page:
For those that need to connect to a different port than 25, I found this:
I ran into an error when I was testing and I got :

535 Incorrect authentication data. >>> MAIL From: SIZE=18 AUTH=pi@mydomain.com”
But I must to confess…. I don’t remember what I did to fix it. If I remember, I’ll update. (second time I ran through these steps, I did NOT get this error… argh)
All of the other prerequisites installed fine. I did not install pf-ring as I did not think my environment needed that.

Finally, I was ready to install Bro. As I said, I followed the instructions at

Bro installed very nicely. I’m running as root, so I didn’t have to do any of the permission changes.

I then started bro and voila! Analysis of my network started to happen.

To monitor my network, I put in a bought a SharkTap Network Sniffer for about $70. If I had to do it again, I would buy the GS105Ev2 – ProSAFE Plus 5-port Switch for about $40. It does port mirroring and is not a single point of failure (wife and kids losing streaming because of overloaded tap: not fun to fix while at work). Both are on Amazon.

So that’s it for now. My next post on bro will talk about my adventures learning to write scripts that alert and having those alerts send me email notices.

<![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.