Thursday, December 13, 2007

Defining incidents

Richard's post inspired me to rant about how I'm approaching the same problem. Previously I've seen systems and processes so overly complicated and detailed that they simply were not used or acknowledged. I sat on this for a while; not liking what was out there. I've began throwing ideas around based on the Tornado Fujita Scale. While the Fscale itself has specific measures (wind speeds) it also has outcomes and descriptive phrases (An F6 tornado is "Inconcievable", how cool is that?). Currently I have it down to:
|1|Loss of Information|
|2|Loss of Positive Control|
|3|Impact to Business|
|4|Black Swan|

I then matrix each of these with Types of Incidents: policy violation, malicious code, DoS, unauthorized access, other. Each of these give a basic guideline (not a rule or requirement) for each level of distinction. In the case of Malicious Software, for instance:
|0|Disruption|Spyware, one-off infection, phishing attempt|
|2|Loss of Positive Control|Active Command & Control channel|
|4|Black Swan|A TJX scale of infection that I can't or wont dream up|

Each of these levels will eventually have their own expectations on response and rules of engagement. I don't foresee a Level 0 (disruption) as necessarily being court admissible. This rules out chain of custody, forensics etc while a level 3 (impact to business) may very will have such expectations.

I like the guidelines approach, as the usage builds over time then I expect organic growth of the system to begin diving into specifics. But any initial scheme will go through maturation and not trying to create a complex framework will lead to a slower adaptation.

Tuesday, September 25, 2007

Brave New War

I just finished reading Brave New War: The Next Stage of Terrorism and the End of Globalization by John Robb. It takes a pretty interesting fellow to weave terrorism and the Iraqi insurgency with Eric Raymonds Cathedral And the Bazaar not to mention brief tangents to Bill Joy's grey goo, Bruce Schneier's brittle security, and Ray Kurzweil's Law of Accelerating Returns. And that's just the obvious stuff a typical geek would pick up. Also sprinkled throughout the book are references to military doctrine, economics, globalization, and biology.
The guy bounces around in first person like an over caffeinated blogger. And I'm certain that's the intention; his description of how he see's the world is startingly moving the online lifestyle to current events and trends. I have never put a critical eye to the whole opensource movement as a symptom of an advance of technology as opposed to a collection of bearded geeks revolting against a system. Robb puts up a strong argument for the former.

The book itself is broken up into three sections. The first section reiterates the amplifying affect of technology to individuals power to cause disorder. In the second part Robb lays out the exact makeup of 4GW, systems disruption, and other specific ideas such as global guerrillas and open-source warfare. At about this time is when I kept my laptop on my lap to keep up with the various footnotes (a decent amount of references are freely available online). Finally the third section attempts to explain the black market eco system as well as Robb's solutions to rebalance sides.

As an aside to the last section: I was a bit suprised he didn't tie in his idea of "Platforms" and open source together. From his definition opensource is an perfect example of a platform and yet he left it go unsaid.

The book itself ended with two pages of Further Reading. He is truly after my heart.

Google notebook

I just discovered google notebook. I've previously relied on starring rss feeds of note but that didn't help for non-rss content. I don't do bookmarks because I find no value in them; they have no context around the link.
It's easy, context oriented, and I love it. The paranoid in me wishes an open source version existed that I could both house on my own site and use SSL. (quick search showed no real results for such a beast). Oh well.

Monday, September 10, 2007


A few weeks ago I saw LTC John Nagl on the Daily Show which was entertaining and interesting but it was forgotten rather quickly as I'm not exactly a .mil kind of guy. I even saw the book he was touting at b&n today (I special ordered Brave New War and Demolished Man) but didn't touch it due the potential for the acronym induced boredom it had.

And boy was I right. I discovered via Danger Room that the manual Nagl and Stewart hyped is freely available for download in PDF. Of course COIN stands for COunter INsurgency while FM stands for Field Manual. I know this because it's in the glossary.

I only skimmed the FM and looked at the appendix and specifically the summaries at the end of each chapter. With that said, there are some very hip quotes that can be applied to infosec that put Sun Tzu to shame:

They [insurgents] also will do anything to preserve their greatest advantage, the ability to hide among the people. These amoral and often barbaric enemies survive by their wits, constantly adapting to the situation. Defeating them requires counterinsurgents to develop the ability to learn and adapt rapidly and continuously. This manual emphasizes this "Learn and Adapt" imperative as it discusses ways to gain and maintain the support of the people.

In this context I like to think of "the people" as users of a network. Certainly hackers do not work to gain support of users, but it should be a high priority for any security team.

One more just because it's so easy and fun:

President John F. Kennedy noted, "You [military professionals] just know something about strategy and tactics and...logistics, but also economics and politics and diplomacy and history. You must know everything you can know about military power, and you must also understand the limits of military power. You must understand that few of the important problems of our time have...been finally solved by military power alone." Nowhere is this insight more relevant than in COIN. Successful COIN efforts require unity
of effort in bringing all instruments of national power to bear. Civilian agencies can contribute directly to military operations, particularly by providing information.

Certainly strat and tactics apply to security operations but economics and politics can also translate to the business drivers/politics and a necessary understanding of the core business. Or maybe I have a certain affinity towards JFK quotes.

It's worth a skim and maybe some in-depth reading.

I'm professional

I received the official certification for the CISSP last week. I'm not a big cert guy (this is my first cert) but I did like the exam itself. I like how it makes a solid baseline. Will everybody with this cert understand the contents of the exam? No, but they can be expected to. That's really the point isn't it? Setting expectations.

I'm married to a public school teacher and when this sort of thing (re: education) comes up she says I'm great at it. I immediately respond back that I'm horrible at education, especially when it comes to a structured process such as book reading or syllabus-type courses. Instead my brain darts around between various books/articles/subjects and I leave it at that. I bring this up because I did near-zero studying for this class. Not because I'm not motivated (though that's possible!) but because learning with a specific short term goal in mind really turns me off. I read for the joy of learning, not cramming. That's why I took a bootcamp course the week before the test. I shoved a lot of facts into my head for 12 hour days 6 days before the exam.

(I gotta admit that I did feel like Mitch.)

Either way, I dig the idea of the CISSP and the fact that I'm now a card carrying member; but more importantly I liked the cramming itself. Maybe I'm not bad at syllabus' but at motivation after all.

Tuesday, September 4, 2007

shmoocon '08

shmoocon updated their site for 08's gig:

TSG is happy to announce that ShmooCon '08 will take place at the Wardman Park Marriott in Washington DC, February 15-17.

We're working on updating the website and getting information pushed out to the masses. Presentations are finally linked to (although they've been up for awhile - a number of you found them without any help) and moved into the Past Events section. Keep watching over the next few weeks as we get ready to release the CFP, announce contests and generally get the ball rolling for ShmooCon IV.

I've been to all three so far and have no plans on stopping anytime soon. Yep, I'm one of the dorks who sat around on New Years Day last year and F5'ed the page until I got tickets.

e-discovery processes

I just found the's e-discovery roadmap which is based on the edrm project. Indeed, the's e-discovery site in general looks decent and was immediately added to my blogroll.

I love FRCP 34b. No insightful comments; the roadmap is simply the most indepth process cycle i've seen yet and is worth it's weight in gold considering how new the entire thing is.

Unless you want to rely on your vendor to define your processes.

Thursday, August 16, 2007

Covert Crawling Web 2.0

Back in 2006 I saw Billy Hoffman give a talk on an app he did up to emulate user/browser experience to covertly allow crawling a website. (wired article or mp4 of the talk)

This was neat and I had a few tangent thoughts on the way into work. If this sort of technology was extended to be aware of specific website interfaces we could do some neat things.

Social networking sites for instance. We could create a mapping of trust relationships based on crawling through the site. Myspace would be pretty easy. You could also find users over a certain age that have an excessive amounts of other aged friends. hello dateline.

Even neater still would be to extend it to What a pile of recon information that is! Not only creating groups of individuals (potentially even a pseudo org chart) who work at a target company, but you can create counts of other organizations linked to that group creating thresholds that can define specific partners to that target. Lots of Oracle sales reps linked in with the target companies IT department teams? Hrm, must be an Oracle shop.

If you're patient you can do this over time too. Sudden influx of a security vendor being linked in through IT? Maybe they had an incident? Or maybe they just bought a new wizbang product and are currently deploying it. Wonder what that Sales Engineer specializes in that just linked up with half their IT? Oh, it says it in his Bio.

Just food for thought.

Wednesday, August 1, 2007

Book: Inside the Security Mind

In a very taosecurity moment I'm going to quickly review a book. All the way back in January of 2005 Dana Epp had an insightful post giving props to the book. It's been on my amazon wishlist for these last two years and I finally picked up and read it while going to/from Punta Cana. The Table of Contents itself shows the books objectives:

1 Introduction
2 A New Look At Information Security
3 The Four Virtues of Security
4 The Eight Rules of Security
5 Developing a Higher Security Mind
6 Making Security Decisions
7 Know Thyself & Know Thy Enemy
8 Practical Security Assessments
9 The Security Staff
10 Modern Considerations
11 The Rules in Practice
12 Going Forward
A Tips on Keeping Up-to-date
B Ideas for Training
C Additional Recommended Audit Processes

The book itself is a bit dated (2003) and various parts show that (Modern Considerations, Going Forward chapters) but the majority of the book narrows down to ideas and concepts that are done on a daily basis. The book should be read for chapters 3 and 4 alone. The four virtues and eight rules should resonate loud and clear- for any practitioner these are not new ideas but there's a lot to be said on clarifying, simplying, and breaking apart concepts used daily. For the newcomer, these virtues and rules truely dictate what should be internalized.
While a bit of Practical Security Assessments are a blatant selling of his companies software it still is refreshing to see down and dirty in-the-trenches suggestions on a potentially intimidating subject. The templates and suggestions put forth are truly a huge win for this book, are actionable and can be shimmed between existing processes allowing for a very good insight into technology deployment.
I don't have a star scale to go by because I'm not a book reviewer but I do recommend plowing through this in an evening or two. If anything the refreshing content will give you a new perspective of how mature your organization is (or isn't).

Tuesday, July 24, 2007

Data and Swarm Theory

One of my favorite Counter-terrorism Blogs, Global Guerrillas, posted a link to National Geographic's Introduction to Swarm Theory awhile back.

The article itself is good and worth reading.

But I also like the idea of someone out there smarter than I to apply swarm theory to a HIPS type product. Dave Aitel wrote of nematodes back in September 2005 and it didn't get a very warm reception. My gut reaction to these various articles is to implement a defensive swarm via a HIPS solution. Various hosts could form a hive, if you will, and touch each other frequently enough to get a group awareness of any threats they are seeing.

Based on the article the algorithms seem to already exist in at least some state; implementing them as a situationally aware defensive measure could be neat as hell.

I need to know more academic researchers so I can drink beer with them and shower ideas down.

Thursday, July 12, 2007

Ohio Government Laptop Stolen

Saw over on ars that Ohio lost a laptop:
Those who think they might be on the list can perform a search on or call 1-800-267-4474 to find out. Less than 60,000 people have yet signed up for the service.

I haven't lived in Ohio for the last seven years but I was on the list. The first time I'm aware that I finally made it on a list.

Threat advantage

The biggest advantage that is often attributed to the threat (aka bad guys) is time. If they have patience then they have all the time in the world to find your weak spots and abuse them.

I think that's changing.

We're obviously no longer dealing with the hobbyist threat. We're dealing with professionals who are in it for the money. Time is indeed money, which I submit makes the average bad guy use his structured attacks as seemingly fast as he can. They use the majority of their time on the front end and then execute their recon/attack as fast as they can risk.

That doesn't mean that a particular targeted operation does not take time, but it is an interesting item to keep in mind. With that said, I suspect a bigger advantage they have is the playing field. It's too easy to not see a targeted attack as the Signal:Noise ratio is spectacularly skewed and too hard to make sense of.

Phishing is a key example: Do we have an automated way of seeing a phish vs a targeted phish vs spam vs ham? We're getting there but that is a tall order.

Wednesday, May 2, 2007

buzzword alert: Evolving Threat Landscapes

I was googling around and found the below quote from Air Force Lt. Gen. Kenneth A Minihan, Director of NSA (from a brief to Senate Gov Affairs Committee, June 1998):

We distinguish two fundamental types of threat.
The unstructured threat is random and relatively
limited. It consists of adversaries with limited funds
and organization and short-term goals. While it
poses a threat to system operations, national secu-
rity is not targeted. This is the most obvious threat
today. The structured threat is considerably more
methodical and well-supported.
While the un-structured threat is the most obvious threat today,
for national security purposes we are concerned
primarily with the structured threat, since that
poses the most significant risk.

I submit that the symptoms of structured vs unstructured threats have blurred to the point of pain. As an example, MS07-017 aka the animated cursor vulnerability from April. The exploit itself was easily detected and not an issue. What I found interesting was the amount of threats I found. I discovered several payloads the exploit attempted to load on the system. Five of which I found the initial 4 days after the exploit was public that were, presumably, from five separate authors. All were undetected at the time of discovery via virustotal. Any of these four attacks could have been from either structured or unstructured threats.

The nature of unstructured attacks have changed. We are not dealing with Code Red anymore. This has been the case the last several years as crime syndicates are more involved in gaining the easy dollar. And if you're reading this site, you are probably aware of all of this.
What I find interesting is that in a lot of ways we are still in the Code Red mindset at an Information Technology and end user level. We need to get out of the idea that saturation levels do not dictate risk levels. Properly relaying the risks is key.

Wednesday, February 7, 2007

Command-line logging

I don't understand why modern terminals (with exception of putty) do not allow for logging.

I successfully use my e-mail history and IM logs to great extent when doing post mortems or other general reports. I should have that same functionality at my command prompt. And something a little more useful than "cat ~/.history". Script is handy for this (though an unfortunately hard name to google for). But I want to not have to worry about those pesky filenames so I did up a quick startlog script.


LOGDIR="/home/ben/logs/" #where we store teh logs
ITERATION=0 #start off at 0
DATE=`date "+%F"`
if [ -n "$1" ] #this is what the filename will be prefixed with

#echo -n "$PREFIX"

while [ "$STARTED" -eq "0" ]
script $LOGFILE
echo -n "Logging to $LOGFILE"


I set my PS1 prompt to also show the current time to allow me to have everything timestamped. And, handily enough, I export the log filename to the shell which leads to a new alias in .bashrc:

alias sendlog="cat $LOGFILE | mail -s '$LOGFILE Transcript'"

I haven't actually used this yet but the novelty of it is handy. On a downside, cygwin does not have script which is a real bummer.

I still think this functionality should be built into rxvt, gnome-terminal, konsole,, etc. Don't even get me started on cmd.exe "featureset".

Wednesday, January 31, 2007

Trending Metrics for McAfee

One of my clients asked me to generate some data for their internal metrics/reporting on security. I have no love for either MSSQL or McAfee's database schema so it took an hour or so to craft a query.
One of The things to watch out for is sanitizing infection hits. A browser may try upwards to 40 times in the same minute to infect you with, say, a VML exploit to get a foothold to drop some other malware. The below gets around this by grouping within a 10 minute period for the virusname and the host. This snippet averages the number of detected infections on a daily basis for January (change avg to sum to get a total for january).

select avg(b.daytotal) as "Average Virus per Day" from (
select count(a.dayhits) as daytotal, convert(char(11),a.clock,0) as completeday
from (
select 1 as dayhits,VirusName, HostName, convert(char(16),eventdatetime,0) as clock
from events
((VirusName is not NULL) or (VirusType is not NULL))
and (VirusName != '')
and (TVDEventID < 1506 OR TVDEventID > 1506)
and (TVDEventID < 4600 OR TVDEventID > 4600)
and (TVDEventID < 10000) and (TVDeventID != 1059) and (EventDateTime BETWEEN '2007-01-01' AND '2007-01-31 23:59') GROUP by virusname, HostName, convert(char(16),eventdatetime,0)

) as a
GROUP BY convert(char(11),a.clock,0)
) as b

Incidently, if you wanted to see the same type of metric for snort/mysql you could do:

select avg(a.sidcount) from (
select count(*) as sidcount from event
where timestamp > date_sub(now(), interval 30 day) and timestamp < now() group by Date_format(timestamp, '%d %m %Y')

) as a;

Monday, January 15, 2007


Maybe I'm being a bit pedantic but there seems to be a recursive loop somewhere here. The information security lifecycle tends to be quoted as:
countermeasures/protect -> detect -> respond

And of course everyone then breaks down the respond methodology down somewhere akin to:
prepare -> detect -> contain -> eradicate -> recover -> follow-up

That "d" word is pretty popular huh? I find it interesting that there's not a lot of attention towards it. Especially in IR books. As a rule of thumb, they'll spend the first chapter on the preparing stage, a section on explaining why IDS/detection is out of scope, a bit on containment, then 80% of the remaining book on eradication. (Which, incidentally, when did 'detection' become synonymous to just an IDS? Don't you get calls when things 'act wierd'?)

While it makes logical sense to have detect as a stage in the entire IR process, that doesn't mean it doesn't deserve at least a chapter on the subject. And don't you dare make that subject about snort. Indeed, detection can be broken up into stages just like IR. Since I've yet to come across any in my own reading here is my own process:
discover -> prioritize -> investigate -> escalate -> follow-up

Once we get to 'escalate' the rest of the IR process takes over, notably containment. I guess everyone likes to talk about responding because there are results from it. Same goes to implementing an IDS system or setting up awareness to sysadmins and users. Has anyone taken the time to prioritizing/categorizing events? Finding valuable metrics? Reporting? Writing a detection book that's absolutely not about technology but about managing the detection implementation? How about a magazine article? Am I simply ignorant to some de facto 'standard' on this?

Tuesday, January 2, 2007

"Never write down passwords"

Does anybody know when this security tenet began? It reminds me of TSA gibberish such as taking off one's shoes to keep people secure. "Never write down passwords" made sense ten years ago when you had one or two passwords each 4 characters long.

Not as easy when there are more and more passwords accumulating in a persons head. There's nothing wrong with writing these passwords down, just when you do it insecurely. The entire slogan boils down to awareness. It seems every security program out there recommends not to jot down the dredded secret you keep in your mind. When did awareness programs stop being honest and practical? Were they ever?

Do I advocate passwords on sticky notes? Don't be silly. But I do think that it's not an all or nothing idea. These awareness programs need to explain how to securely keep passwords documented (keeping them in safes, keeping them on your person, etc) and start being realistic. This "never write down passwords" mantra just makes everyone look like a zealot and accomplishes very little. Stupid.