A Public Process?

I drink from the well that is Google Reader. If you saw my list of feeds, you'd probably question my sanity or time management. Yes, I'm sure I have too many (useless) feeds but every once in a while you find something that really piques your interest.

What piqued my interest recently was a Twitter exchange started a couple of weeks ago between Brad Arkin (Director, Product Security & Privacy for Adobe Systems )and Charlie Miller. Miller has enjoyed ongoing success in CanSecWest's pwn2own competition and has given several interviews recently.

The exchange begins after this, from what I can tell. Brad Arkin gives a recorded presentation on the work that Adobe is doing around software security. and Charlie Miller responds:

"with low expectations like that, I can see why you're so happy."

You can follow the Twitter exchange starting here and ending here. I may be way off base on how this exchange got started but there is one thing that I (a no-name security guy) would like to see come out of it. I want to see Adobe hire Miller to completely break the sh!t out of their products, have Adobe make progress in fixing and improving their software security, and have the results of said engagement shared with the public.

It makes me laugh to imagine teenage angst laden, diary entries from both sides. So, maybe there would be a time delay in the gritty "details" (read: vulnerabilities) but the result would be something that is rarely shared with the public: (nearly) complete insight into the breaking down and building back up of a large software vendor's product.

Flint update

For the two people (excluding my mom) that read the earlier post on getting up and going with Flint from Matasano, Flint has come a long way recently.

The set up and time investment to get started has gone down to the minimal amount possible. Flint is now packaged (for lack of a better term) with all of the required ruby gems and redis. That means no more installing the other requirements by hand and lowers the potential to b0rk your attempts at using Flint. Error output has vastly improved to the point where when you run into one, the error-causing line will be a part of the error output. Also, bug fixes get turned around so quickly that often *I* am the one holding up the process of testing my own config files.

You will want to check out Flint's updated site because there are now different options for getting started using the source, git repo, and even a virtual machine set up.

Here is the general process that I use now to pull updates and test new versions:
(from the Flint directory)

$ git pull
$ rake reset
$ rake app
$ rake app --trace (You'll know when it's necessary, trust me.)

The process is not groundbreaking. If you end up having to run "rake app --trace" be kind, rewind, and send a bug report to flint [at] matasano.com.

Some other tidbits about Flint that might be useful are the script/analyze and script/pix_parser scripts. These are scripts that can be used to test snipits of config files or parse whole config files, and in general act as a short cut for having to use the gui to reproduce bugs.

Until you start running your various, collected config files through Flint and probing them in deep dark places, you will not realize how messed up some Cisco configs really are. And I'm not just talking about porous rule sets.

In particular, you will want to pay attention to the "Rule Syntax" section of the report output. This is the section where the rule syntax errors will be placed. What Flint does, is compare every configuration line against the published Cisco PIX Firewall Command Reference. When errors are found, the error-causing line, the error, and the associated config line are output. More than once this has notified me of copy/paste errors that get introduced in the shuffling of files.

Installing and Using Flint from Matasano

Flint is a "free, open source web-based firewall rule scanner" written by Matasano Security.

To begin with, grab Flint from here. It's available from the Matasano git repository or via source archive.

Next you want to check out the README file.

...## Installing

gem install ./matasano_utils-0.1.gem
gem install ./Ralex-0.1.gem

It also needs the following gems:
* sinatra
* haml
* ohm
* rdiscount
* compass
* bcrypt-ruby

Flint also requires a working Redis 1.2.3+

Redis is available at http://code.google.com/p/redis/

Note, the Ubuntu redis-server package is too old.

## Running

* Start redis
* The first time you run, you will need to do run 'rake init'
* 'rake app'

This will start a Sinatra server listening on port 4567.  Point your browser at that.

Hurray! There are instructions.

Check your list of installed ruby gems with the command 'gem list' and install any gems that you don't already have. Personally, it seems like I have to (metaphorically) sacrifice a chicken to get ruby gems installed in the correct directory, in the path, and working right. But that's just me.

If you haven't stopped reading already, you will have noticed that Redis is required to get Flint working. Get the latest stable version of Redis here. Redis is a "persistent key-value database with built-in net interface written in ANSI-C for Posix systems". Check out the Redis Quick Start page for getting Redis up and running.

Now we're down to the 'Running' section of the README. Hopefully you actually read the Quick Start page for Redis and saw the './redis-server' command - it's kind of important and you should do that now.

Next, you want to be sitting in the Flint directory. Run 'rake init', followed by 'rake app'. This should notify you along the way that flint was brought up successfully and it has been given a default account of admin/admin77.

If you've gotten this far, do as the good README says and point your browser to http://localhost:4567 and see if everything went right. This is what the login screen looks like:

If something didn't go right you may get an error like this:

NoMethodError at /
undefined method `path' for #

   * file: login.rb
   * location: nil
   * line: 11

Okay. That's what it looks like when there is a user error. Remember what I said about the chickens? I was missing the Rack gem. It turns out that you need that gem installed so that you can use the path method from the Request class.

After you upload a configuration file, here is what the Overview page looks like:

Looks like there is a firewall out there that needs some help. I'll leave the rest of the exploration up to you.

Overall, Flint delivers and makes my brain hurt less when compared to a manual review of firewall rules. The GUI is pretty self-explanatory and easily navigable. I'll be keeping an eye on it as it improves over time.

A Case for Hacking Back and How InfoSec Could Get a Whole Lot More Fun^H^H^HInteresting

After Google’s Stand on China, U.S. Treads Lightly

Here are some interesting quotes from the article:

"...the company began a secret counteroffensive."

"It (Google) managed to gain access to a computer in Taiwan that it suspected of being the source of the attacks. Peering inside that machine, company engineers actually saw evidence of the aftermath of the attacks, not only at Google, but also at at least 33 other companies, including Adobe Systems, Northrop Grumman and Juniper Networks, according to a government consultant who has spoken with the investigators."

and

"For example, the servers that carried out many of the attacks were based in Taiwan, though a Google executive said “it only took a few seconds to determine that the real origin was on the mainland.”

At what point will companies start condoning and justifying, on a regular basis, this sort of active response? As much as this incident says about the current state of verifiable, targeted attacks and APT what does it say about the justification for "hacking back" against the attackers?

If an organization does not have the capability to perform this sort of 'investigation' how will your company (if you're a consultant) handle this request?

The DoJ Computer Crime & Intellectual Property Section has some interesting reading in Appendix C, Best Practices for Victim Response and Reporting:

4. Do Not Hack into or Damage the Source Computer Although it may be tempting to do so (especially if the attack is ongoing), the company should not take any offensive measures on its own, such as "hacking back" into the attacker's computer—even if such measures could in theory be characterized as "defensive." Doing so may be illegal, regardless of the motive. Further, as most attacks are launched from compromised systems of unwitting third parties, "hacking back" can damage the system of another innocent party. If appropriate, however, the company's system administrator can contact the system administrator from the attacking computer to request assistance in stopping the attack or in determining its true point of origin.

Based on the NYT article, Step 3 for responding to an incident, "Notify Law Enforcement", occurred according to this quote:

"Seeing the breadth of the problem, they alerted American intelligence and law enforcement officials and worked with them to assemble powerful evidence that the masterminds of the attacks were not in Taiwan, but on the Chinese mainland."

So, another question that arises is when, at what level, how, and to what extent did American intelligence and law enforcement officials become involved?

Even if Google put the cart before the horse, I don't think that the company nor those involved in the investigation will be punished.

Further reading:
Hacking Back: Optimal Use of Self-Defense in Cyberspace

Thimble of Knowledge

How do you hand out the "Thimble of Knowledge"?

People in Information Security run into this scenario all of the time. How do you translate your "mountain of facts" into something that accurately assesses and conveys the proper amount of information to your client, boss, or manager?

A few years ago I took some Incident Response training at CERT. The training culminated with a mock presentation of your team's findings to C-level  executive. You had 10 minutes to present your findings and provide recommendations. The instructors acted as the C-level executive and were tough, gruff, experienced, and sharp (in this part of the exercise, outside of it they were very personable and approachable). The instructors played the part to a T and had years of experience in incident response and presentations in the scenario.

Here are some guidelines that I kept in mind for that presentation and when trying to present technical information or recommendations to less technical people:

• Stick to the facts - don't exaggerate or use flowery adjectives.
  
• Know the difference between possibility and probability
• Reevaluate your "first draft" - can your points be refined or distilled down to more accurate statements? One method I use when trying to reevaluate is by applying some root cause analysis with the 5 Whys. It's not a direct translation but the process works for me.
• Be prepared - Be prepared to support your claims with additional material, whether in your mind or on paper.
  
• Keep It Simple, not Stupid -  Don't assume that just because the audience is not an information security expert that the audience's mental capacity is below average.

How do you hand out the "Thimble of Knowledge"?

The most important skill today is...

The most important skill today is... teaching.

While I was pontificating the substance of this whole effort I realized that the information sources that I get the most out of are the ones that teach me something or show me a novel way of accomplishing a task. That is what I want to accomplish with this blog. I want to document my perspective, thought process, and methods for other people to evaluate.


"Teaching" link via: http://uxmagazine.com/strategy/less-is-better

Is this thing on?

It's been almost 5 years since I posted to my old blog on Blogger. I was prompted to get back in the game after a friend asked me a question along the lines of "Why the hell aren't you out there in the community?". I couldn't come up with any good answers, so here I am.