Posted on

2014 Technology Goal Review

I tried to avoid writing this post and I dreaded it with the same feelings I usually had during report cards; however, it needed to be done. I was reminded of this when I saw that @kylemaxwell did a review of his 2014 goals, so I feel that I need to belly up to the bar and do one myself.

$DEITY, this is not going to be pretty.

  1. Finish my ever lengthening list of half baked projects – While, weirdly enough, I did not work and complete the three tools I mentioned, I did do a much better job of completing something when I started out on it and not declaring it “good enough” — That counts for something, right? (Grade: C-)
  2. Examine and update all my existing tools – Hahahaha. Nope. (Grade: F)
  3. Work on some hardware projects – This was one that nagged me throughout the year. My Raspberry Pi which was going to be a basis for whatever I did was… re-appropriated when a relative dropped $250 on a ready-made XBox Media Console from a shady web store that blew up within a week. $30 for some components and I was able to save him $220. More hardware related, I did some Arduino development that made some lights blink when some buttons were pressed, but nothing anywhere near my original plans. (Grade: F+) 
  4. Become active in Ham Radio again – While I did not pick up the microphone at all, I did do my fair share of advocacy. This mostly involved encouraging people to go out for their license.  The good news is that by doing so, the hobby netted one new ham. Good enough for me. (Grade: D+)
  5. Write more articles – Well, I did do an infinitely large number of articles in 2014 compared to 2011 and 2012, because anything compared to 0 is a crazy large number. Still, three is far short of where I wanted to be. Still, I’m happy I did something. (Grade: C-)

I made small progress on one of my stretch goals, specifically trying to stand up a CitySec chapter in Providence. While I had a name and a location picked out and was aiming for something this summer, I placed it on hold when a new opportunity floated my way. With any luck, this will come to fruition this spring.

I did have some takeaways from my miserable failings less than stellar performance this year:

  • I need to have a better way of tracking ideas and tasks – I have a habit of finding little bits of information or things that I want to do and I stuff them away. I then promptly never look at where I stuff them ever again and forget about them. Drives me batty.
  • I work better in changes of scenery – I find that getting outside of my usual area where I work really boosts my productivity. This seems to be transitive as while I seem to do $DAYJOB work better when I work from home, as soon as I switch over to hobby stuff, I need to be out of the house somewhere else.
  • I’m not productive on a schedule – I really have no idea how people do this, but I flip-flop from “obsessed” to “aloof” about a subject on a seemingly random basis. I need to get into a rhythm of writing, coding, or whatever on a regular schedule.

One immediate goal I have for 2015 is “come up with goals for 2015” – This will be interesting, as I should make them a bit different than the 2014 goals, even though I missed almost every single one.

Posted on

What’s more important? The engine type or the horsepower?

So this floated across my Twitter stream a couple days ago, a quote from @chacon at the Bloomberg Enterprise Technology Summit in NYC…

“API’s are more important than open source” – Scott Chacon, co-founder, GitHub #BBGTECH — Mark Palmer (@mrkwpalmer) April 24, 2014

This quote, as I am sure it was made to do, really made me think. I am a big fan of open source software; I enjoy having the ability to take someone’s work and repurpose it to my own ends. I put my money where my mouth is as well, I release most of my code, minus the really embarrassing stuff, to the public. On the other hand, I am not a zealot; I don’t feel that open source should be pushed on other people — I specifically choose the BSD license for my code as I feel the GPL is viral and limits the possible audience of my code. I don’t think the license, open or closed, that a tool falls under should make the determination on how useful it is.

At first, I scoffed at the @chacon’s statement, but after I chewed on the idea for a bit, I started to rethink my stance. One of my first questions that I ask when vendors come give a dog and pony show for their, almost invariably closed source, product at $DAYJOB is “Does it have an API?” — Enough so that it’s come a bit of a running joke with my co-workers. While I like open source software, the most important part of any software is its usability and interoperability. If a tool allows me to accomplish what I need to do in a way that I can extract the data when I am done with it, does it really matter if it’s open source? APIs give a simple way of taking a tool, closed or open, and stringing it together with other tools in your kit. If I can shove some data into the RonCo dataslicer 5000 and then extract the results with a few lines of python this can just as powerful as repurposing the code to my own ends.

I think that Scott is right. An open API makes a healthy bridge between open and closed source and it is, in my own opinion, rapidly becoming the more important question than what license the source under. By providing an ability to easily link closed tools to open ones it makes closed source even more palatable.

Posted on

Let’s not back the bus over the Target SOC… Yet…

Bloomberg Businessweek released a story today regarding the Target breach that stated Target received not one, but two alerts regarding the malware on their network that sent 40 millions credit cards and 70 million records of customer data into the greedy hands of criminals. Now, coming from a blue team background, this scenario happening on my $DAYJOB’s network keeps me up at night. One of my greatest worries is that I’m missing some kind of chain of events that I’m not piecing together while some ankle biter runs rampant over my work’s systems. It keeps me, and any other defender worth their salt, always looking over their shoulder and through their logs.

That being said, the article makes it sounds like these alerts were gift wrapped, tied with a bow, and adorned with a sign that said THIS IS GOING TO STEAL CREDIT CARDS surrounded by blinking LEDs. Anyone who has worked in a SOC or in an analyst position knows that this never the case. Starting from an event and working backwards to pick out from the noise the bits of applicable data that pointed to the event is trivial, trying to pick out data and see a pattern that points to an event on the horizon is much, much harder.

We’ve seen this kind of analysis before: Anyone who has read into military intelligence failures such as the September 11th or Pearl Harbor attacks, knows that there was a chain of events that when pieced together makes it obvious to any casual observer that the events were going to take place and if someone had simply acted, these tragedies would have been prevented. What the casual observer doesn’t realize is that while yes, the information was there, it likely was fragmented, incomplete, and most importantly, competing with many other bits of data that point to something else or nothing at all. The ability to take this data and form an accurate prediction about future events that allows someone to act takes skill, luck, and a bit of hubris.

I’m not saying Target has clean hands on this, they got their ass kicked, their security team failed, and anyone who saw that report and dismissed it or waffled on it knows that they had a hand in every bit of fraud that occurred due to those stolen records. But, I think it’s important to ask some questions before we condemn them as heavily as Bloomberg does:

  • About that “team of security specialists in Bangalore”:
    • What was their false positive rate?
    • What was their false negative rate?
    • How trained were they?
    • How many alerts did they escalate on a daily basis?
  • Regarding FireEye:
    • How trained were the SOC staff on analysis of FireEye reports?
    • How trained were the SOC staff on malware analysis in general?
    • What was the false positive rate of the FireEye device?
  • Regarding the SOC in general:
    • Was there a defined process for malware remediation?
    • How many alerts did the SOC staff deal with on a daily basis?
    • Did SOC staff have a ability to pull  the fire alarm?

The article from Bloomberg reads great, but it’s important to remember it’s not a detailed analysis report. Sadly, with the current state of affairs in information sharing, we’ll likely never know exactly what happened at Target during those fateful weeks, but if we don’t know, we really can’t judge.

Posted on

2014 Technology Goals

So, @kylemaxwell posted his 2014 Tech Goals on Twitter the other day and it was a refreshing change from the seemingly endless noise of “2014 prediction” articles that every company and their brother seem to post as the year changes. It was different, and it was a good idea. So, like every good idea I see, I’ve decided to rip it off. When I started thinking about it, I came up with a few goals for 2014:

  1. Finish my ever lengthening list of half baked projects – I like to code things. I enjoy making tools that someone might find useful. However, I have a habit of getting the tools 75%-80% done, declaring it “good enough” and letting it sit there gathering dust. I have approximately three interesting tools that are currently sitting in this state and I need to sit down and finish them.
  2. Examine and update all my existing tools – I also have a problem in which once I send something out the door, it no longer gets worked on, so another goal this year is to go through all my existing projects and tools, examine them, and either update them or retire them.
  3. Work on some hardware projects – I always want to seem to do this but I never have the wherewithal to do this. I hope that actually putting this out in public will motivate me to do so. I’ve recently been enamored with all the fun “home automation” tools out there but shy away from them due to the idea of having my house be controlled from da cloud. Some projects have been rattling around in my head to replicate some of the features I think are cool without the pesky security and privacy concerns.
  4. Become active in Ham Radio again – In early 2012, I got fed up with some of the cliques in the local hobby groups and simultaneously lost my ability to have a radio in my car (where most of my operating was done). I’ve been recently started getting the itch to get back in the hobby and I need to scratch it.
  5. Write more articles – This site has been inactive for years. I want to try to get an article written, either here or on Mayhemic Labs, every other week. (This one counts as #1!)

My boss at work always reminds me to set some “stretch goals”, which are nearly impossible to achieve, sooooo…

  1. Develop more “outside of the box” ideas for Blue Teaming/CND – I really enjoyed writing my SANS paper and this seems to be a topic garnishing more and more interest, so I think working on this is a laudable goal.
  2. Break out of the “Infosec Echo Chamber” – I often try to “put my money where my mouth is” when I say I want things to change. Unfortunately, like a lot of introverts, I enjoy staying behind my keyboard and arguing about things on Twitter. I want to start engaging non-security people about security issues.
  3. Become more engaged in InfoSec meatspace activities – I left the Boston area in 2011 and I’m now local to Providence. This unfortunately cut off my access to MassHackers and BeanSec. I need to locate and become more active in the local Providence Technology and InfoSec activities.

Here we go…

Posted on

Chris Paget, Part 97, Part 15, and RF Research

It has finally happened. I can finally write a blog post about my two favorite subjects: Information Security and Ham Radio.

Chris Paget made some news this weekend at yearly DEFCON hacker conference in Las Vegas. Paget demonstrated the flaws of the GSM cell phone protocol by creating a simple device to intercept every GSM call in a small area. Chris did a lot of work making sure that he wasn’t violating anyone’s privacy by intercepting these phone calls, up to enlisting the help of the Electronic Frontier Foundation. When reading some of Chris’ preparations, I was impressed, but the first thing that popped into my head was “Wait, that’s nice and all, but what about FCC regulations?”

To take a quick detour into FCC regulations, most unlicensed devices fall under Part 15 of the FCC rules. They have to be tested and certified by the FCC before they are marketed and sold in the United States. Whenever you see your favorite technology blog talking about how some new device is being tested by the FCC, they’re talking about this testing.

So, when Chris was explaining his presentation I figured he was going to go one of two ways: Either he was going to unveil some kind of new FCC certified cell phone interceptor (unlikely), or he was going to put on an eye patch, raise the Jolly Roger and go full pirate. However, after the presentation was done, I was reading the coverage of the presentation and saw that he did it a way that I hadn’t considered: Chris, unbeknownst to me, had an amateur radio license, so he tried to classify his transmissions under Part 97.

Part 97 is the Amateur Radio section of the FCC rules. Amateur radio is classified as an “experimental” service. As I’ve stated in my “Why you should be an Amateur” presentation, amateur radio is “radio hacking.” Chris saw that part of the European GSM band overlaps with the 33cm amateur radio band, so he (and I!) have rights to transmit there. Seems like a perfect fit, right?

Unfortunately, no. While Chris did seem to catch the “no encryption” part of the rules, he didn’t realize that his transmissions were not legal under Part 97 either for other reasons. Part 97.111 and Part 97.113 establish but “authorized” and “unauthorized” transmissions of amateur radio stations, of which Chris, by my count, violated the rules 2 or 3 different ways:

  1. Chris was using his Part 97 transmitter to communicate with Part 15 devices, not other Part 97 devices. (Violates Part 97.111(a))
  2. Chris’ GSM cell site was beaconing to cell phones to let them know it’s there. That counts as a way transmission. (Violates Part 97.113(b))
  3. Chris was impersonating a AT&T cell phone site. You can’t impersonate people on amateur radio. (Might Violate 97.113(a)(4))

Chris does get props for establishing a Morse Code beacon to ID himself every 10 minutes as defined by the rules, however, that is like a restaurant owner trying to convince the health inspector that his restaurant is OK despite the rats and roaches because his employees wash their hands after they go to the bathroom. Too little, too late.

I’m not trying to string up Chris here, I’m honestly worried for him. He’s admitted that he’s had conversations with the FCC regarding this presentation which he classified as “unproductive”. This, combined with the fact that the FCC enforcement bureau loves to hand out documents with “Notice of Apparent Liability” at the top and five figure fines on the bottom leads me to wonder if Chris isn’t headed toward a protracted legal battle with the Feds. Chris’ presentation shows a major shortcoming with the current FCC rules dealing with research. Chris should not have tried to find a loophole within the FCC regulations to do his research, it should have been legal for him to establish a low powered signal to do and demonstrate his research. We, as researchers, are running into another version of the same ostrich syndrome that prohibited users from listening to cell phone and pager traffic that were transmitted in-the-clear back in the early 1990s, and to a lesser extent, still are. With the expansion of data networks to mobile devices, it’s become even worse, as Chris’ presentation demonstrated. By not allowing research into these fields the FCC is keeping the sunlight out of the dark corners of our mobile networks and allowing the mobile phone companies to convince us that everything is OK when in reality someone with $1500 worth of equipment can intercept local mobile phone traffic is negligent at best, and criminal at worst.

While I disagree with Chris’ characterization of his transmissions being “cool” because he’s licensed as an amateur radio operator, I fully support his research and his efforts to do this research in a controlled environment. I also hope that the FCC will realize that this type of research only helps people and all the laws in the world won’t help bad people from doing this same type of activity in a malicious manner, as they already are.

Posted on

Where the hell have I been?

Been quiet over here recently, but I’ve been busy in other areas, so let’s do a quick update of what the hell has been going on:

First off, QuahogCon was a blast. My presentation went rather well, despite some technical difficulties with the lack of Internet access and the fact that I was not able to raise the local IRLP repeater from inside the building. I’ve started tweaking it a bit and submitted an abstract to The Next HOPE‘s CFP.

You can download the QuahogCon version of the slide deck here:

  • Why you should be an Amateur PPT (8.0MB)
  • Why you should be an Amateur PDF (7.0MB)

Also, available over at QuahogCon’s site is the audio of the presentation.

Next, over the past month, I re-launched Mayhemic Labs a group of very talented folks. We have started doing a few projects, the coolest one (in my not so humble opinion) is ICanStalkU, a site that rips through public photo sites looking for latitude and longitude EXIF tags. You can read more about the project at the site’s how and why pages.

So, despite the lack of activity on here, I have been keeping busy. Of course, I am always mumbling to myself on Twitter.

Posted on

My comments on the proposed changes to FCC Part 97.313

Since I already did my civic duty and submitted my comments on the NPRM for 97.113 and my all official-looking Word file was just sitting there, I went ahead and submitted my comments on the proposed amendments to the spread spectrum regulations which would limit the maximum power to 10 watts in exchange for elimination of the requirement for automatic power control. While I like the idea of eliminating the APC requirement I think the restriction to 10 watts is a bit overkill. I suggested that they increase the limit to 25 watts, as that would give amateurs a good amount of wattage to play with and still would still be 25% of what is currently allowed, mitigating interference concerns from Wireless ISPs.

My comments on FCC Docket 10-62

Posted on

My comments on the proposed change to FCC Part 97.113

The FCC has submitted a notice of proposed rule making (NPRM) to attempt to create an exception in the Part 97 rules to allow hams to participate in disaster drills on behalf of their employer. Currently, for amateurs to participate in drills on behalf of a government agency, the agency must submit a waiver to the FCC for permission. Now, I have said before that I’m a fan of the waiver process and I think that it has its place. However, I feel that giving blanket immunity to such things is not a good idea. I think I’m very much in the minority in this opinion, but after reading the comments submitted by Mark, K6HX, I felt my Quixote-esque ability to tilt at windmills stir, so I went ahead and submitted my own.

My comments on FCC Docket 10-72

Let us see what happens…