Monday, December 13, 2010

The most wonderful time of the year


No, not that “most wonderful” time of the year.  Shmoobus season is approaching.

This will be the fifth SecTwits road trip, and the third annual Shmoobus trip- a pilgrimage from the Boston area to Shmoocon in Washington, DC.

What is a Shmoobus?  It is a hacker road trip, a way to get to DC and see the wonders of the New Jersey Turnpike and much more.  I generally rent a 28-30’ RV, folks sit around the table, or on the couch.  It is a mini-con on the way to/from the con.  The route is from the Boston area (a couple of pickup spots) to Shmoocon.  There is a possibility of stops along the way, but I don’t think I want to battle NYC traffic in the RV again.

The nice folks who keep me around for entertainment, Astaro, will once again be sponsoring the Shmoobus.

The last Shmoobus was pretty close to capacity, so we need to start planning now.  We have a few options, such as chartering a bus instead of renting an RV, but that would mean no table for conversations, card games and workspace.  Also, no generator to power all those laptops and other toys.  On the other hand, We could step up to two RVs, but that means we need to find another driver willing to handle the task.  But then we could caravan.  Twice the fun?

Interested in joining us?  Drop me a line at work, jdaniel [at]



This would warm my heart, if I had one

Michelle Klinger has a post on her blog that made my week- she tells about her path to becoming a community leader.  Check out her post, “SecurityBSides Turned Me into an Adult”.



Thursday, December 9, 2010

Comment induced follow up post

I love comments, and I should make them more often.  Three comments on one of my recent posts kicked a few thoughts free, so I’m dropping them here.
Marisa Fagan’s comment helped me clarify an idea.  We often see inappropriate spending on security, and frequently shrug it off with the acceptance that “at least they’re doing something, maybe next time they’ll get it right”.  I am a proponent of accepting small victories, but if the “defense” is wrong, that is not a victory of any kind.  For any challenge, we have a finite set of resources we can use to address it.  If resources are spent on the wrong things, that is not “just” a waste of resources, it removes them from the pool and reduces (or possibly eliminates) what is available for valid solutions.
Danny pointed out a very real, but theoretical, threat.  Some would call it a “movie plot threat”, but I am growing tired of that phrase.  Risk analysis needs to consider a wide variety of risks, then categorize them and prioritize mitigations.  Even unlikely attacks deserve to be considered in the process, especially if the consequences would be high. In the context of the post, I feel that it would be inappropriate to worry much about a potential threat when there are active attacks we are not adequately addressing.  For example, you don’t see anyone in InfoSec focusing their efforts on traditional network security to address browser exploits, do you?  That would be silly.  Hmm, wait, we seem to be getting uncomfortably close to glass house syndrome.
christiania, glass house, august 2007
(photo credit seier+seier , Flickr)
Finally, Dave Kennedy’s comment included this gem:
“Report: FBI arrests Holland America passenger for releasing ship's anchor”
which highlights a real battle we sometimes face.  We are all aware of “usability vs. security” challenges, this one is a “security vs. security” challenge.  Or maybe a “safety vs. security” challenge would be more accurate.  Sometimes you need to drop anchor, and fast.  It isn’t common, especially in a modern vessel such as the cruise ship in the story- but when you need the anchor down, you need it down.  Therefore, the harder it is to drop anchor, the “less safe” the ship may be.  In this case I do think there needs to be a level of security above “some drunk can drop an anchor”.  This kind of incident is a good study in risks, threats, probabilities and outcomes, and it is visceral enough to get people’s attention.


Tuesday, December 7, 2010

BSides Updates

Out of control, but in a good way.  It was an idea kicked around on Twitter eighteen months ago.  Then the first event happened, and went amazingly well.  And then more happened. And the growth continues.  It is a simple idea, really.  Get people together, bring in good content and engaged participants.  Have fun, learn, share, repeat. 

There have been twelve events in eleven cities in the past eighteen months.  From a few dozen to several hundred people have participated in the various events.  Dozens of companies have sponsored in amounts ranging from a hundred dollars to those who have provided tens of thousands. There are at least eight new cities planning BSides events in the next several months, plus second year events in more.

The most recent event was in Ottawa, that was the first one outside of the US- and there are at least two more locations planned for Canada next year.  Later this month, BSides Berlin, BerlinSides will be the first European BSides- but there will be one in London in the spring.  Another is in the planning stages for New Delhi.

Head over to for information on upcoming events, and to see where we’ve been.  The next events on the horizon are:

Berlin during 27C3 (27c3 is now sold out).  There are even a couple of speaking slots open if you submit quickly you could get on the schedule- and as always there will be space for breakouts, impromptu talks, and private discussions.

Minneapolis/St Paul, at the Wabasha Street Caves, January 7.

The second BSides San Francisco will be February 14 and 15, registration and call for papers are still open, location will be announced soon- and it is a great one.

Then the second Austin event will be Friday and Saturday, March 11-12.  As with San Francisco, the location is going to rock, and will be announced soon.

There is even talk of a SkiSides, a BSides at a ski resort.  Keep an eye on the BSides wiki for all the details of upcoming events.  There is bound to be one near you.  And if not, you can help make one happen- send a note to info (at) to find out about organizing an event.

Finally, sponsors make it possible, and BSides provides unique opportunities for organizations to promote themselves and support the community.  info (at) is the address for sponsor info, too.  Or email me directly (you can find the address somewhere up there ^ from the blog header), I’ll be happy to answer questions about BSides.



Monday, December 6, 2010

If you have to ask, the answer is yes.

In case you missed it:
Alan Shimel wrote a good, but really depressing post over on his Open Source column at Network World, "Is There A Sexual Harassment Problem In The Open Source Community?".  Alan and I are both “old white guys” who are heartily sick of sexism in our industry, and Alan’s latest piece addresses and links to some pretty appalling things.
It really is way past time to act like responsible adults in this business.  And I may just have to act very childish at an event or two next year to make that point.  Stay tuned.


Wednesday, December 1, 2010

Invoking 9/11, lies, and ignorance.

This one has been stewing for quite a while.  It was triggered by an event that happened while I was on vacation late this summer, but I have held off on writing about it until now.  First, I didn’t want to write about it in the hype-cycle leading up to the anniversary of the September 11 attacks and look like I was riding the hype wave.  Then it was election season, with all the hype and invocation of 9/11 that brings.  Now, maybe I can get this off my chest safely.

I took an Alaskan cruise this summer.  I’m not really a “cruise” kind of guy, but the Inside Passage cruise is as stunningly beautiful as most people say it is.  One day the cruise director was talking about DVD tours of the ship and mentioned that it was the only way to see the bridge or engine room since… that’s right, the tightened security after 9/11.  Because we simply can’t have any more cruise ships flying into skyscrapers.

This is pure BS, and is actually a complete failure to grasp the nature of the threats.  Worse, it misdirects defenses and perceptions away from the real threats in a maritime environment, which are very different from the aviation world.

The “lesson” of 9/11 was that the passengers and crew of airplanes were no longer the only objective; the planes themselves were objectives- so they could be used as weapons.  Applying that “lesson” to cruise ships is stupid and dangerous for several reasons, a few of which follow.

First, there’s the matter of physics.  The navigation space of aircraft are much less restricted than ships (the sky is very large, even if some of the edges are hard), combined with the speeds of modern aircraft, the number of possible targets for an airplane attack are myriad.  Ships could be used for ramming attacks, but it just isn’t that practical- especially when you consider how tricky many approaches are to ports.  There’s a big reason harbor pilots are used to guide ships into port: tides, currents, shifting shoals are all in the way of getting to the berth- or of ramming a target.

Then there is the practicality of maritime safety.  There is none, it is almost exclusively vigilance that defends shipping.  When an airplane leaves the runway, the number of practical threat vectors narrows.  At 36,000 feet I am not worried about a guy with a rocket propelled grenade on the ground, or someone forcing the door open from outside.  When a ship leaves a harbor, it loses the protection of monitoring from on shore and adjacent vessels’ crew, it is alone and approaches to the vessel become easier, not harder.

But those details miss the larger point, the “lesson of 9/11”, the use of vessels as weapons, isn’t just impractical in the maritime environment, it downplays the very real and actively exploited threats to ships.  Piracy is rampant in parts of the world, and not just off the coast of Somalia- and that is much more like the pre-9/11 view of airline threats: hijacking and kidnapping.  It is wrong to make any statements which in any way divert attention from the piracy crisis; it diminishes the significance of both 9/11 and the scourge of piracy.

And for the specific threats posed by tours of the bridge and engine room- I completely agree that the bridge should be off limits at almost all times, but that is common sense and safety.  The bridge is no place for stray people when a ship is underway.  The same could be said for some of the engineering areas.  But when the ship is in port I have a hard time believing tours can’t be given safely.  Even if you do buy the idea of a movie-plot threat, remember that passengers and their luggage go through metal detectors and x-rays, similar to airport security (pre-nudie scanners and freedom fondles).  Defend against the real threats.

That’s it. No InfoSec angle. 

Alright, if you really need an InfoSec angle, I’m sure you can extrapolate something about misidentifying threats, and using that wrong information to create the wrong defenses, thus ignoring or even weakening viable defenses.  But we would never let that happen.  At least we don’t usually deal with dead people over our mistakes.



Sunday, October 24, 2010

Go read this…

Thanks to Alex Hutton for pointing out a great article in the Atlantic.  It is about medical research, but it transcends that topic and really applies to many areas of research and study.  The article is called Lies, Damned Lies, and Medical Science and leads with:

“Much of what medical researchers conclude in their studies is misleading, exaggerated, or flat-out wrong. So why are doctors—to a striking extent—still drawing upon misinformation in their everyday practice? Dr. John Ioannidis has spent his career challenging his peers by exposing their bad science.”

My favorite quote from the article may be:

“Maybe sometimes it’s the questions that are biased, not the answers”

That is very close in intent to something I often say, which is “if you want to know how the illusion works, do not look where the magician points”.

It is an interesting and (hopefully) thought provoking article.



Saturday, October 9, 2010

BSides slideshow

Here’s a little slideshow of photos from BSides events in Las Vegas (both ‘09 and ‘10), San Francisco, Austin, and Boston.


I cannot believe how far this has gone, and we’re just over a year into it.



Wednesday, October 6, 2010

Verizon’s PCI Compliance Report

A couple of days ago I pointed to the new Verizon Payment Card Industry Compliance Report (PDF available at

I have read and digested it, I have also read and been unable to digest (or even keep down) some of the “supporting” information.

Short version- it is a first try, and it has useful data- data you will not find elsewhere.  Some of that data and accompanying analysis can help organizations battling PCI compliance, and those who audit/assess or consult organizations attempting to comply with PCI-DSS.

There is, unfortunately, some complete crap surrounding the data, some of the report was apparently written by myopic PCI cheerleaders.  A lack of overall understanding of the security landscape, and the occasional straw man may make you want to stop reading before you get far- but don’t give up, there is much more good than bad, just keep your reality distortion shields up and you will learn from the report.  You can also learn from the mistakes of others, which is not as visceral as learning from your own mistakes but is much less painful.

Some things really jump out at you- like the 78% non-compliance rate at the initial assessment.  At the time of the initial assessment over 50% of organizations were not compliant with 8 of the 12 requirement areas.  Requirement 11, regular testing of security systems and processes came in dead last in initial compliance.

The report states that the 22% that were found compliant at the initial assessment were mostly experienced at PCI-DSS, but many that had been found complaint previously were deficient in the subsequent assessments included in this report.  It would be great to know how many of the formerly complaint were assessed by Verizon previously as opposed to how many were assessed by other QSA firms- and how the compared.  Not holding my breath for those stats, but they would be telling.  The lack of quality assurance in the QSA space is one of the things I have railed about in the past, this data could really help the PCI council address some of these problems (if they had any interest in doing so).

It will be interesting to see what conversations come from this report.



Monday, October 4, 2010

Another report from Verizon, this one on PCI

The good folks over at Verizon Business have cranked out another report, this one on on PCI.
I urge you to read the PDF for yourself (yes, PDF, and file format we should trust just as  much as EXE these days).  The blog post and podcast underwhelmed me, but you may see value in them.


The Blog post is at

and a short podcast:

I need to digest it before adding commentary.  Remember that Verizon Business has a large PCI practice.  I’m not saying there is any bias or spin- but it would be naive to overlook that fact.  Also, keep in mind that like the DBIR, the sample organizations are self-selecting, they are companies which can afford, and use Verizon for business services.  (That’s one of the great things about the latest DBIR, the addition of Secret Service data for normalize results).


Sunday, September 26, 2010

I’m going to be where?

It looks like I have a busy fall, I will be attending all kinds of events around the US and Canada.  Meet me for a beer (or bourbon) and let’s chat if you will be at any of them.  Or, go to the events because they are great events- and know I’ll be there and you can hide from me.  Whatever works for you.*not my actual legs

I will be at both InterOP and SC World Congress in New York with other folks from Astaro.  Yes, I’ll be on Booth Babe duty.  No, they promised I will not have to wear fishnets and pumps this time.  (Just try to get that image out of your head).

I will be at three of this fall’s Security BSides events.  I just missed the one in Kansas City, sounds like it was another good one.  I will be at those in:

Unfortunately, due to a scheduling conflict I will not be at BSides Delaware, but it looks like it will be yet another winner- and it is conveniently located for a lot of people in the industry.

I am helping with the HacKid Boston event coming up in just a few weeks.  This will be a fun and educational event for the kids and parents, I am really looking forward to helping make it happen (and I don’t even like kids).

And, of course, there is SecTor and the SecTorBus road trip.  There is still a seat or two open, let me know if you would like to join us for that adventure.

A couple of days before BSides DFW the Houston NAISG chapter is holding HouSecCon,

But other than that, and a few local speaking engagements, I don’t have much going on.  Except I *might* be working on a Security BSides Berlin as well as the second ones in Austin and Boston.  Oh, and ShmooBus III.  But other than that, not much.



Wednesday, September 22, 2010

I know what the law says. Or do I?

I recently attended an event where Scott Schafer, Chief of the Consumer Protection Division of the Massachusetts Attorney General’s office, reiterated the AG’s take on some aspects of MGL 93H, the Massachusetts data breach reporting law.  Specifically, Assistant AG Schafer put forward a very strict interpretation of the definition of breach in 93H, covering when you must report a breach.  The AG’s office has an interpretation of when you must report a breach that is substantially different than most people I have spoken with on the topic.


[Insert giant disclaimer here: I am not a lawyer, I am not your lawyer, this is not advice, legal or otherwise, except to advise you to contact your lawyer, etc.]

The issue revolves around breach notification when encrypted Personal Information (PI) is lost.  Here is 93H’s definition of breach:

““Breach of security”, the unauthorized acquisition or unauthorized use of unencrypted data or, encrypted electronic data and the confidential process or key that is capable of compromising the security, confidentiality, or integrity of personal information, maintained by a person or agency that creates a substantial risk of identity theft or fraud against a resident of the commonwealth. A good faith but unauthorized acquisition of personal information by a person or agency, or employee or agent thereof, for the lawful purposes of such person or agency, is not a breach of security unless the personal information is used in an unauthorized manner or subject to further unauthorized disclosure.”

The key bit for me being:

“unauthorized acquisition or unauthorized use of unencrypted data or, encrypted electronic data and the confidential process or key…”

My reading of that (and that of most people I have spoken with) is reflected in the following with my emphasis added to the text by way of red font and bracketing:

“unauthorized acquisition or unauthorized use of [unencrypted data] or, [encrypted electronic data and the confidential process or key…]

That is, losing unencrypted PI is a breach; as is losing both encrypted PI and the key to decrypt it.  I had interpreted losing encrypted data without losing the key as not meeting this definition of a breach, and thus not requiring notification.

An excerpt of 93H from Assistant AG Schafer’s slide deck shows the emphasis he placed on the phrase (underlining is as it was shown on his slide deck):

“Unauthorized acquisition or use of unencrypted data or, encrypted electronic data and the confidential process of key that is capable of compromising…”

The exclusion of “and the confidential process or key” clause from underlining is telling.

The AG’s office states that any loss of personal information is a breach and must be reported, whether encrypted or not.  The explanation is that we cannot be sure that the key has not been lost or otherwise compromised.  Two examples were given to support this position:

  1. A laptop containing PI was lost.  Although encrypted, the encryption key was taped to the laptop.
  2. An encrypted laptop containing PI was reported stolen by an employee, but the employee was actually using the laptop and using the PI for fraud.

In each case, the organization responsible for the protection of the data has a problem.  In the first case, it was unclear if the organization knew the key was on the laptop, or if there had been any user education, or even if there were policies prohibiting affixing he key to the encrypted device.  In the second case, a crime was committed, and the organization was one of the victims of the crime- but is that relevant to disclosure under 93H?

I want to make it clear that I am all in favor of strong consumer protection laws, and was one of the few people who consistently spoke out against weakening 201 CMR 17.00 at hearings as the OCABR debated the various changes to that regulation.  I am, however, opposed to vague or misleading language.

Do not look down here for answers- I think this will take some prosecutions and subsequent court decisions to set precedents and give us the guidance we need.

By the way, this discussion only applies to the idea of encryption providing “safe harbor” in the case of breach reporting.  Encryption is required for all portable devices containing PI, 201CMR17.00 is very clear on this (although “where technically feasible” provides wiggle room).



Monday, September 13, 2010

SecTorBus will roll, will you?

There will be another road trip this fall, to the excellent SecTor Security Education Conference in Toronto.  The conference portion of SecTor runs on Tuesday and Wednesday, October 26 and 27.  (there are also classes in the education portion).

Take one:




add a handful of hackers, then drive to image




and look out world.

The tentative schedule calls for the RV to make the run from Northern Virginia to the Boston Area on Sunday, October 24, Boston to Toronto on Monday.  Return trip to Boston will be Wednesday night, Boston to NoVa will be later on Thursday after a bit of rest.

Big thanks to Astaro- they have come through again to sponsor the trip, so it will be free to join us on the ride.  You will need to cover  your own conference, food and lodging expenses, but if you haven’t already registered for SecTor let me know, there should be a discount code soon for SecTorBus riders.  Due to local regulations, we cannot sleep in the RV in Toronto, so you will need a room (or a friend with a room).

Keep in mind that Toronto is in Canada, which is like a whole other country.  There will be border crossings, which means you will need a passport if you wish to make a round trip.

Once again we will be renting an RV, we should have plenty of power for laptops, and where there is coverage on the US side we will have a rolling 3g hotspot compliments of Astaro.

If you would like to join us, drop a note to jdaniel |at| for more info.



Monday, July 12, 2010

This will be interesting.

The week of Las Vegas madness that encompasses Security BSides, BlackHat and DefCon is approaching.  I am fortunate enough to be speaking twice that week-

I will be leading Security Speed Debates at 10am on Thursday, 7/29 at Security BSides.  It is an idea I have blatantly stolen from AusCert, but ours will be better, at least partly because we don’t talk funny.  I will be joined by the lovely and talented Josh Corman and Dennis Fisher (you decide which one is which) plus a “player to be named later”.  We will each have one minute to make our cases for or against a variety of incendiary topics, then we’ll give a couple of folks watching the spectacle a chance to add their opinions.  To make it more interesting, the panelists will be assigned pro or con positions, on the spot, by coin toss.  The goals are to 1: have fun, and 2: encourage conversation.

I will also be moderating a panel discussion on PCI at DefCon at noon on Sunday.  Yes, PCI at DefCon.  We have a killer team lined up for the panel, see the lineup and summary here.  I’ll be joined by James Arlen, (aka Myrcurial), Anton Chuvakin, Joshua Corman, Alex Hutton, Martin McKeay, and Dave Shackleford.  How’s that for a team?

I think our synopsis sums it up very well:

“PCI at DefCon? Are you on drugs? Sadly, no- compliance is changing the way companies "do security", and that has an effect on everyone, defender, attacker, or innocent bystander. If you think all that 0-day you've heard about this week is scary, ask yourself this: if a company accepts credit cards for payment, which is a more immediate threat- failing an audit or the possibility of being compromised by an attacker? That is one of the reasons "they" do not listen to "us" when we try to improve security in our environments- as real as they are, our threats are theoretical compared to failing a PCI assessment. Systems are hardened against audit, not attack. Sadly, this is often an improvement, but this can also reduce security and provide a template for attackers. This panel will discuss and debate strengths and weaknesses of PCI, expose systemic problems in PCI-DSS, and propose improvements.”

If you’ll be in Vegas for the fun, consider checking these out, they should be fun.


Friday, July 9, 2010

Wildly successful social engineering

Someone has done some wildly successful social engineering.  Amazing, actually.  I am not talking about the “Robin Sage” social media/social engineering case where a lot of people who should know better gave up a lot of information in a lot of different ways.  That may be interesting (we’ll see when it is presented), but even though some of the results were sensitive, that is building on a lot of prior work.
I am talking about the coverage of that story, where the reporting has largely been horrible, gullible, naive crap.  Sorry folks, but yes, that includes coverage from people I like.  If you believe a lot of what you read, you would think that a lot of people were “duped” into following/friending/linking/whatevering Ms. Sage.  This shows a gross lack of understanding of both social networking and the security community- both on the part of the journalists, and to a lesser extent, the researcher.
The people who “over-shared” really are a problem, and it may be interesting to see what Thomas Ryan (the person behind Robin Sage) presents at DefCon.  It looks like s/he got a lot of sensitive information from people who should know better- three letter agencies, military, and more.  Interesting, but “people are stupid and gullible” is not really ground-breaking, nor is mining/abusing social networking to prove this point a new idea either.  It does sound like the scope and scale may be noteworthy.  But not new, and being a skeptic, I’m not sure it is newsworthy.
Where things fall apart is the nonsense over stories which pretty much proclaim that MILLIONS OF SECURITY PROS DUPED, and point to the number of friends/links/etc. the virtually perky Ms. Sage gathered.  I would like to point out four things:
  1. Different people use social networks in different ways.  Just because someone accepts your connection request does not mean they are fooled by you.  They may not even care if you are real or fake.
    • Maybe they (sadly common) think that more connections means they are more important.
    • Maybe they are public figures of some kind, and accept most requests as a matter of policy.  If people are careful with what information they share, there is nothing wrong with this. Nothing. It is voluntary, get over it.  It is how Social Media and Social Networking work for many people.  If you don’t like this approach- don’t use it.
    • The decision to accept may be based on connections offered (via friend-of-a-friend linking) instead of being based on the person making the request.  Again, if you are cautious about what you share, there isn’t a risk here- even if it is a pretty shallow move.  Robin certainly had some interesting friends/links to entice people.  Put another way: Some days, the wingman scores.
  2. Once Robin Sage became fairly visible, the drama got interesting and a lot of people began following/linking to the myriad of Robin Sages (yes, there were clones and evil twins, too) just to watch the train wreck.  I was one of these, and like many others I had my suspicions- but didn’t care if she was real, fake, or just another troll, there was entertainment.  People were not duped, they grabbed a beer and some popcorn and watched the show.
  3. Robin Sage was called out.  Spotted.  Thoroughly outed.  Many thought “something was fishy”.  Some people did actual research and provided real details.  People had to connect/accept to do the research and confirm their suspicions.  The press almost completely missed this critical point.  They also missed the fact that once this was widely known, even more people connected to and followed Robin to watch the evolving train wreck mentioned in point 2.
  4. Mr.. Ryan apparently convinced (socially engineered) much of the media into thinking this was something it wasn’t, then and the result was not journalism, it was an embarrassment.
And this is just the worst of it this week.  Half baked ideas, giant (and flawed) leaps of logic, obvious vendor spin, and more were on parade this week.  Maybe it was the heat and no one could think clearly.  Maybe it was Vacation from Healthy Skepticism Week and no one told me.  I don’t know, but I’m not happy about it.


[Note: since posting, the question of linking to specific examples has come up. I debated it while writing this post, but in the end I decided that the issue was so pervasive that calling out specific writers or articles would not have been productive.]

Monday, June 14, 2010

Security BSides Las Vegas announcements

The venue for Security BSides Las Vegas is phenomenal.  As great as that is, BSides is about content and community, and I’m happy to spill a few details about content.  The first few talks confirmed are great and there are plenty more killer talks to be announced.  Here are a few teasers:

David Mortman has assembled an all-star panel including Marisa Fagan, Erin Jacobs, James Arlen, Dave Lewis, Leigh Honeywell, and Rafal Los for “Mentoring, Mentee-ing (Telamachusing? Manatee-ing?) In Information Security: A How-To Panel.”: Come and learn how to get the most of out the Mentor/Protégé relationship from our panel of experts.

HD Moore will present “Fun with VxWorks”: this talk focuses on the VxWorks operating system, how it works, what devices use it, and how to compromise it.  The content will include background information on VxWorks itself, a checklist of common vulnerabilities, mappings from these vulnerabilities to shipped products, and a live demo of gaining access to a widely deployed commercial product.

Gene Kim will present “Mobilizing the PCI Resistance: Lessons Learned From Fighting Prior Wars (SOX-404)”: I have noticed that there is a growing wave of discontent from the information security and compliance movement around complying with the PCI DSS… My desired outcome is to find fellow travelers who also see the pile of dead bodies in PCI compliance efforts... and catalyze a similar movement to achieve the spirit and intent of PCI DSS.

Bruce Potter will bring bring us “How to Make Network Diagrams that Don't Suck”:  We've all been there.  You walk in to a network blind and the first thing you ask for is a network diagram.  What gets handed to you has apparently fallen out of a bowl of ramen and on to the page.  Overlapping lines, big arrows, and host names in print so small that only insects can read it.

Egyp7 will deliver “Beyond r57”: PHP is an easy language to learn and is among the most popular in the web development world.  Because of this, many PHP applications are written by novice programmers with little knowledge of writing secure code.  Combine that fact with a few poor design decisions and you end up with vulnerabilities in PHP applications being published daily.

And that is barely scratching the surface.  There will be plenty more, and there will be informal and impromptu talks, too.  And healthy conversations.  Maybe an argument.

And a first for BSides, we will be arranging a press area for BSides LV.  It is the place to be, and we want to provide those covering the event a place to hold interviews and get work done.



Wednesday, June 9, 2010

I just want to fix my car.

I'll close out my series of car rants with this one, on our ability to repair our cars.  This is not a new battle, but the front has moved into new territory.  The “Experimental Security Analysis of a Modern Automobile” paper touched on the subject briefly, pointing out that some of the “vulnerabilities” they reported could be addressed by locking down diagnostic and repair procedures.  They also stated that:

“...individuals desire and should be able to do certain things to tune their own car (but not others).”

Starts off good, then takes a dive.  So, who gets to decide what you can to to your car?  That is academic arrogance and lack of perspective there folks.  Yes, if I want to use my car on public roads, I have obligations to my fellow drivers and to the law.  If I am on a racetrack, the obligations are to my fellow drivers and the rules of the sanctioning body.  In the fields of my farm, the regulators, manufacturers, and pointy-headed academics can [insert your own creative answer here] themselves.

And on the commercial side:

“Similarly, how could mechanics service and replace components in a locked-down automotive environment? Would they receive special capabilities? If so, which mechanics and why should they be trusted?”

Once again, a little historical perspective…

Manufacturers have built vehicles requiring special tools for many years, and have tried to limit access to these tools to limit independent shops’ and do-it-yourself mechanics’ ability to maintain and repair vehicles.  Manufacturers have tried to restrict access by only allowing sales of some tools to authorized dealers, and when they can’t get away with that, they resort to making tools available at excessively high prices.  Special fasteners are the most obvious example, but there are few parts of an automobile which haven’t seen bizarre adaptations which require either serious creativity, or special tools, to access or repair.

Tools like these are easy to reverse engineer and duplicate.

With these physical components, we do have the ability to look at them and improvise- and tool manufacturers can make their own versions of the tools like the ones shown above.  Unless they run into patent issues, of course.

Going beyond repairs, tuning used to be a lot more obvious, too.  Changing some settings, swapping a few parts, these were commonplace tuning techniques.  Even the term “tune up” tells us something- we had to tune cars regularly, adjusting carburetors and points were regular service procedures.  One very common performance swap was replacing the carburetor, this was not done simply for performance, but for the ability to fine tune the aftermarket carburetors in a way we couldn’t tune factory systems.  For example, use of the ubiquitous Holley carbs meant that with some skill and patience, and a couple of boxes of jets we could precisely refine the fuel mixture fed to the engine.

Holley carburetor jet assortment.

We are now in a situation where a many routine repairs require interaction with the computer systems of the automobile.  Even tasks like changing fluids or servicing brake pads can require use of the computer systems.  Depending on make and model you may need one of these ~$18,000 (USD) systems to perform simple repairs:

Automotive diagnostic and repair computer

(Note: that’s a real system used by some European manufacturers, they really are about $18k, and are just a feeble Windows 2000 laptop in a user-unfriendly form factor).

Repair information is, and has been, a bigger problem.  Mechanical systems can be torn down, inspected, and independent publishers could (and still can) create repair manuals.  The diagnostics, and the underlying operation information, was always where we fought for information; the move to computerized systems has made this information both harder to find and more desperately needed.

We can’t just look at the problem and improvise, that’s why we need the manufacturers to cooperate in making information available, or at very least we can’t allow them to block access to information.  This is not easy, there are standards, but there are also proprietary implementations- so we are back in the awkward Intellectual Property/software patents/reverse-engineering-breaks-DMCA world that is familiar to those of us in the information security.

And it is more complicated than that- if you reverse-engineer proprietary software on your computer and alter its functionality, what are the consequences for society at large?  Altering automotive systems can have a profound impact on fuel economy, emissions, braking and other safety systems- that can have a real impact on society.  Or, at least have an impact on the car in front of you if you’ve screwed up your brakes.  Again, a little perspective: we’ve always been able to screw up our cars, we are just exposing new ways to do it. 

Let’s not ignore government’s role in this situation.  Much of the push to computerization of powertrain management systems was a reaction to ever-tightening emissions and fuel economy mandates.  It doesn’t stop with the design of the car, either; most automobiles have to undergo inspections, many modifications to the fuel and emissions systems are likely to cause your vehicle to fail.

I do think the paper has highlighted a couple of real issues, and implementing some basic safeguards such as limiting the conditions under which certain commands can be executed, and limiting which systems can issue certain types of commands should improve the security of automotive computer systems without compromising our ability to repair our vehicles.

If you are interested in this issue, check out Right to RepairH.R. 2057 (PDF) the proposed “Right to Repair” bill looks like a good starting point, it is proclaimed as

“A bill to protect the rights of consumers to diagnose, service, maintain, and repair their motor vehicles, and for other purposes.”

And we could all use a little protection.  Of course, we often want protection from the government, so protections mandated by the government will require a bit of scrutiny.



Monday, June 7, 2010

A bit of deep thought.

A couple of weeks ago Michal Zalewski wrote a guest post for Ryan Naraine over on the ZDNet Zero Day blog.  It stirred up some conversation, but I wasn’t going to comment on it until I hung out with the Pauldotcom crew for their 200th episode extravaganza and Hackers for Charity fundraiser.  The post and responses came up, and after a little deep (beer-induced) thought, I decided to share a few thoughts, and offer links to a variety of responses.

First, I almost skipped the post, the first sentence lost me:

“On the face of it, the field of information security appears to be a mature, well-defined, and an accomplished branch of computer science.”

Seriously?  Anyone who thinks that is clearly delusional.  But I know the Michal is not, he is brilliant, and Ryan encouraged me to read the entire post.  So, I did.  Even though the rest of the first paragraph really isn’t much better:

“Resident experts eagerly assert the importance of their area of expertise by pointing to large sets of neatly cataloged security flaws, invariably attributed to security-illiterate developers; while their fellow theoreticians note how all these problems would have been prevented by adhering to this year’s hottest security methodology. A commercial industry thrives in the vicinity, offering various non-binding security assurances to everyone, from casual computer users to giant international corporations.”

I am not sure how someone Michal’s age attained that level of cynicism, but it is impressive.  He goes on to say we have had no successes in software security, elegantly define the problems in a few ways, and then leave us there.  Michal appears to be making the kind of assertions that triggered my last post, I think he could really use a bit of perspective.  But enough of that, if you are interested in an interesting look at software security from a variety of perspectives check out the following links.  Note: these are some seriously smart folks, It often takes me a couple of passes at some of the ideas to get it.

Michal’s original post is here.

Amrit Williams has a great response here.

Ivan Arce responded here.  Ivan is crazy smart, and this is a thorough response.  It may take a little digesting to grasp Ivan’s points.

David Mortman has a great follow up post here.

Michal has a follow up to his post on his blog, including some comments, and links to a few responses (including some of the above).

It is an interesting series of posts.  But remember, nothing you read in any of them changes the fact that tomorrow is “Patch Tuesday”, with all the baggage that brings.  So keep a little perspective as you read the installments of this little drama.



Tuesday, June 1, 2010

Time for a new mantra.

[NOTE: On re-reading this post before publishing, I realize it sounds pretty bitter in places.  It should.  But, I do want to make clear that I respect the vast majority people who do the hard work, even when I disagree with some of what they say, or the way they say it.]
We need a new mantra in information security.  We've heard various forms of "think like an attacker" for ever.  And it is absolutely true.  But seriously, enough.  Make the point to the new, the uninitiated, those outside our craft- but otherwise, stop it.  The choir knows the tune, and the chorus, and lyrics, and can do it in rounds while drunk.
Here's my proposal:
Run a [Optional: expletive of your choice] enterprise.
Or maybe just
Run a [Optional: expletive of your choice] network.
It doesn't need to be a big one environment, but your MacBook, roommate's XP laptop, and a NAS server does not count.  You need to run a network, remediate problems, scramble and patch, screw up, get yelled at when things go down, and occasionally score victories.  You need to see things work, and see things fail.  If you are both good and lucky, you may get to see The Next Big Exploit in the wild, and watch it pass you by unscathed.
I am not saying to stop thinking like an attacker, but I am suggesting that if we accept that defenders should understand the attacker, those who do attack research should experience the world from the other side.  A classic case of this is the "technology X is fundamentally broken" statements we hear year after year, con after con.  Many people don't understand why they are ignored by management and admins when they make these absolutely true statements.  I'll tell you why, because no matter what we're told about the failures of anti-virus, web filtering, IPS, or whatever, we've seen these technologies work.  Perfect, no.  Fewer helpdesk calls, yes.  That is success.  Limited success, sure.
I just want people to tell the truth, and offer solutions, even imperfect ones.  "Technology X does not work as well as you need it to, but you can minimize the pain by doing Y" will have people at your feet begging for more.
I am not even asking for researchers to "pity the poor admin", but should a little empathy develop, I'm good with that.
By the way, some of the criminals do get this.  When the new MSRT ships and your botnet starts evaporating, you learn a lesson.  Bonus points for retiring "Criminals don't play by the rules", that is the epitome of an NSR statement.  (NSR == No [stuff], Really?)
A little perspective goes a long way- which is a very good thing, because many in our business seem to have very little perspective.


Friday, May 28, 2010

Comments broken…

It looks like commenting is currently broken on the blog, trying to figure it out.  Since I’ve been too lazy to build and run my own blogging system, I’m at the mercy of the Googleplex to get this sorted out.  Sorry…

[update: it looks like only the last post has broken comments]


Thursday, May 27, 2010

Continuing the car-rant

Time to resume the review of the car security paper.  I will not pick it apart completely, but I do need to hit several more points in this post and then I'll wrap up the car rant in one more post on access to tools and information.
Backing up a bit, one thing I skipped over was the choice of automobiles.  They chose one pair of identical cars, testing one stationary and one on a test track.  Their reasoning behind the small sample, and not identifying the car, is stated as:
"We believe the risks identified in this paper arise from the architecture of the modern automobile and not simply from design decisions made by any single manufacturer. For this reason, we have chosen not to identify the particular make and model used in our tests. We believe that other automobile manufacturers and models with similar features may have similar security properties."
I am uncomfortable with these blanket assumptions for a few reasons.  First, it is irresponsible to praise or damn an entire industry based on a single sample.  Second, I assume the technology levels of auto manufacturers have been somewhat leveled by regulatory and market pressures, but it is naive to think they are all the same, or that they all treat digital security the same.  Time for another trip back in time: Going back to the pre-OBD-II days, some manufacturers had barely moved out of the seventies, while others had forged well ahead.  For example, there was some argument of the number of pins to be included in the proposed standard connector- many manufacturers complained loudly and said it was impossible to supplied the required information in the small number of connectors.  Chrysler also complained about the proposal, but their complaint was that they were already supplying more information than required in a smaller connector, Chrysler objected to needlessly adding pins.  At this time, Ford technicians were still using breakout boxes and meters for some testing while many Chrysler vehicles were connected to in-shop computers to do the same, only faster and more reliably.  At the same time (early 90's) we had data capture devices available for Chrysler products which let us capture system data while on the road.  I remember dumping the contents to the shop computer, then to floppy so that I could wave them in engineers faces at conferences.  "If you look here on the fuel injector and ignition timing traces..." was a lot better than "I don't know, but the customer still isn't happy".  Moving forward, up until a couple of years ago I know that the quality and technology of diagnostic equipment varied widely between manufacturers.  From what little I've seen from friends and clients this still appears to be true.  I do not think it is unreasonable to conclude from this that testing of multiple manufacturer's systems is warranted before making any sweeping statements.
A technical and safety nitpick: On page nine, section V. B., they discuss the setup for the stationary tests.  They raised the car on jackstands and ran the drivetrain at speeds for the tests with the wheels and powertrain unloaded.  This means the operating environment of the vehicle was artificial and bearings were spun without load- a bad idea.  Also, without the weight of the vehicle on the wheels, had something malfunctioned there could have been out-of-control vibration, possibly bouncing the car off the stands with catastrophic results.  (This one is not theoretical, I've seen bad things).  In this configuration, they tested the electronic braking system- the rear wheels were stationary while the front wheels spun at 40 MPH.  Since there are wheel speed sensors on each wheel, this put the system in an unnatural state, it is not surprising they experienced different results between the static and road tests.  They did understand this, but understanding that they were "doing it wrong" is not especially confidence inspiring.  Although they repeated some tests on the road, it just shows a basic lack of awareness- especially considering the information they could have gathered by running the system on a chassis dynamometer.  Dynos are not rare anymore, either- state emissions testing stations in many states are equipped with rudimentary ones, and performance and speed shops have reliable ones available.  Running on  a dyno would not have solved the wheel speed sensor issue, but it would have addressed load and safety issues.  As far as the the wheel speed issues, depending on the sensor it may have been possible to solve with a simple little hack of the sensor outputs while stationary.
Moving forward to page twelve, we return to good (and disturbing) information:
"The fact that many of these safety-critical attacks are still effective in the road setting suggests that few DeviceControl functions are actually disabled when the car is at speed while driving, despite the clear capability and intention in the standard to do so."
Again with the poorly implemented or enforced standard- this is critical information from the report.  They also found that it was possible to bridge the high- and low-speed busses, that is just plain wrong, and potentially terrifying.  More important findings, I really wish I wasn't questioning everything by this point.
Hopefully you have read the report, don't just accept their findings (or my observations), but put some thought of your own into it.  I hope there is follow up study, and it is done with more caution and better research.
There is one more petty thing I wish to bring up.  They refer to computer managed automobiles as "cyber-physical vehicles", what the [heck] does that mean?  We do not need more cyber-hyphenated nonsense terms.
One more quick car post is coming, then back to your irregularly-scheduled drivel.


Tuesday, May 25, 2010

Scalable is an abused word.

Vendors love to tell us how "scalable" their products are.  Many, however, fail to grasp that scales have two ends- if you start in the middle and only scale "up", your product is not truly scalable, so stop saying it is.

That's it, just another bit of bitterness from a small business advocate.



Wherein Jack plays paper shredder

In my last post I started a series of rants about cars.  As I said, it has been simmering for a while, but a paper called Experimental Security Analysis of a Modern Automobile (PDF) pushed me to write.  While the first post was not specifically about this paper, this post and some later ones will be.  I'll reiterate that there is a lot of good information in the paper, but you need to sift through a bit of arrogance and ignorance to get maximum benefit from it.  While that is almost universally true of all papers, especially academic ones (they rarely have, or even give credit to, trench-level experience), it is often hard to accept the valid parts of a paper after discovering glaring errors.
Let's start with an excerpt from the very promising abstract:
"Abstract: Modern automobiles are no longer mere mechanical devices; they are pervasively monitored and controlled by dozens of digital computers coordinated via internal vehicular networks.  While this transformation has driven major advancements in efficiency and safety, it has also introduced a range of new potential risks. In this paper we experimentally evaluate these issues on a modern automobile and demonstrate the fragility of the underlying system structure."
(Note: In the Olden Days, we also had systems which "pervasively monitored and controlled " cars, they were called "drivers").
Damn right, cars have become more computerized and the systems are networked- and now more vehicles have multiple wireless communication systems, most (if not all) with some level of access to the onboard networks.  There's a recipe for a playground of badness.  So is this paper.  Rather than shred it entirely, I'll call out a few things which set me off. 
But first, venture back in time with me.  In the early sixties, we had cars with electrically-controlled transmissions.  Not especially reliable, but we had them.  Cars had computers before that, but we didn't call them that.  They were called "automatic transmissions", controlled by hydraulic decision engines which selected the appropriate gear based an a variety of variable inputs- including throttle position, engine load, engine speed, road speed- all under amazing temperature and vibration extremes.  There have been a lot of interesting technologies in autos, often appearing earlier than people realize.  And tinkerers, mechanics, racers, gear-heads, whatever you want to call them started hacking cars and their systems as soon as they got their hands on them.  And it was not new with cars, we've tinkered and pushed the limits of stuff since crawling out of the primordial ooze.  I think a weekend in the pits at an SCCA event might prove eye opening for many- the creativity is amazing.
Diving into a few specifics of the paper, we don't make it out of the first page before we get our first warning:
"Through 80 years of mass-production, the passenger automobile has remained superficially static: a single gasoline-powered internal combustion engine; four wheels; and the familiar user interface of steering wheel, throttle, gearshift, and brake. However, in the past two decades the underlying control systems have changed dramatically."
Maybe we'll let this slide, a bit of hyperbole to start the paper off.  We'll ignore diesel engines, the move from manual to automatic transmissions, front to rear wheel drive, etc.  But then we get to:
"While the automotive industry has always considered safety a critical engineering concern (indeed, much of this new software has been introduced specifically to increase safety, e.g., Anti-lock Brake Systems)"
Anti-lock brakes have certainly evolved considerably, but ABS was effectively mandated for heavy trucks by US FMVSS 121 in 1975.  Yeah, Gerry Ford was in the White House, scourge of disco was beginning to destroy a generation, and polyester was an acceptable fabric for something called the "leisure suit".  Not quite "new" systems.  Maybe I'm still nitpicking.  Cars are different than trucks (but not that different in many ways).  There really is a lot of good information in this paper.  (Of course, if they had let their mechanics read it after getting their cars serviced it would have been a lot better).
Then, we get to this gem:
"In this paper we intentionally and explicitly skirt the question of a threat model. Instead, we focus primarily on what an attacker could do to a car if she was able to maliciously communicate on the car’s internal network. That said, this does beg the question of how she might be able to gain such access.
"While we leave a full analysis of the modern automobile’s attack surface to future research, we briefly describe here the two kinds of vectors by which one might gain access to a car’s internal networks. The first is physical access."
Another little insight for you: if I have physical access to your car, I can now do with a computer, cables and custom software what has been possible for almost eighty years with a pocketknife- damage your brakes.  (Note, cars have been around for over a century, but use of hydraulic brakes was not widespread until the thirties).  You can really get creative with digital attacks, but you've been able to do creative brake damage by exploiting physical and hydraulic vulnerabilities, there's plenty more than simply cutting lines which can be done.  Switching gears (sorry, had to) to traditional information security, ignoring the threat model is best practices.  No, wait, ignoring threat models it is a horrible idea, but sadly common.
"The other vector is via the numerous wireless interfaces implemented in the modern automobile."
Now we're talking, this is a huge problem (at least potentially), and it needs a lot of research.  Skipping forward to section IV. C., there is more critical information.  Not surprising, but important- there are poor standards, implemented poorly and un-enforced.  That is not shocking to those of us in infosec, but especially scary when we're talking about interaction of physical safety systems.  It is a bit depressing that they are surprised by this, and surprised how easily the systems fell to fuzzing attacks, another sign that the authors may not have the real-world experience I would like.
I'll continue the rantview in an upcoming post, but I may become snarky, and possibly mean about it.


Sunday, May 23, 2010

Some folks need to get over themselves.

This is a multi-part car rant, wherein I insult some "hackers" and "academics" who richly deserve it.  The targets of my scorn are not likely to hear my rants, as they have anatomically unlikely body parts shielding their ears (entire heads, actually).

Where to start...

NEWS FLASH: Car people have been "hardware hacking" longer than you have been alive.  They have also been hacking electrical and electronic systems for many decades.  And hacking onboard computer systems for a few decades.  Just because some computer literate folks decided to play with cars, "hacking cars" is new and newsworthy?  To the folks who believe this, get over yourselves.  Some might say "but Jack, computers make cars too complicated for the dumb mechanics and knuckle-dragging gear heads who beat us up in High School."  To these people I say, you weren't beaten badly enough or often enough in High School.

Back in the dark ages, when I was a mechanic, we did creative tuning and repair when we had to.  Early emissions and computer systems were less than ideal in function and reliability, so we adapted the tricks we knew and added more to compensate.  For example, there is still a handful of mixed resistors in my tool box, we used those to tune gauges- and later to tune the inputs computers received from sensors.  Strategically placed vacuum bleed valves, creative use of timers and relays, and so on- were nothing new to a competent mechanic as we dealt with the influx of computers in autos.  We played mix and match with parts- computers, sensors, chips, whatever we could.  Sure, we were not hacking code, but we broke things just enough to make them work.  If you expand the scope to cover auto racing, especially the cheap, "run what you brung" classes, the ingenuity has been amazing.  Phrases like "you can't do that" and "watch me" have been heard in the pits since the first races.

So when I see stories about car hacking I get a little twitchy.  There are cool projects, like OpenOtto, an open framework for accessing automotive systems and networks, and most folks involved in that seem to have a clue.  I do occasionally hear the odd stupid remark about it (generally from people who don't understand the fundamental difference between data and information), but overall I hope it develops into a powerful and easy to use tool.

What triggered this bit of Goodwill Towards Men?  It has been simmering for a while, but a paper called Experimental Security Analysis of a Modern Automobile (PDF) pushed me over the edge of reason.  Fine, farther over the edge.  There is a lot of good information in the paper, and some crap, and a fair bit of academic arrogance.  I'll start the dissection of the paper in an upcoming post.



Wednesday, May 19, 2010

Observing observers.

Here's a little experiment in observation for you- the next time you are in an airport, watch the watchers.  If you haven't tried it before you are in for an education.  There are a few classes of "watchers" in most airports, I want to focus on three, starting with TSA employees.

Note: TSA bashing is always good fun, but that isn't the point here.  Well, maybe just a little.

When you are in line for the security theater checkpoints, watch the TSA agents as they observe the passengers.  Are they scanning the entire area occasionally, or are they focused on a narrow space?  Do they look around at all?  How do they look at people?  How do they observe the non-passengers (crew, staff, etc.) as they go through security?  What happens when they leave their posts, do they wander off aimlessly, or scan the crowds as they head off wherever they are going?

Next up, "real" law enforcement.  Not just any policeman or sheriff, but you'll know them when you see them.  They see everyone.  They check everyone's eyes, hands and waist- not in a forced, "I just learned this in a webinar" way, but in a fluid and practiced "I am not getting sucker-punched again" way.  You'll know it when someone triggers their interest- the police are generally discreet about it, but it is often clear when someone is getting a secondary (and more thorough) inspection.  They also walk the halls with one shoulder against a wall to reduce the area they need to cover, and to reduce their attack surface.  And they don't stop looking as long as they're in public.

Casa de Sunglasses FashionistaNow, finally, the last group.  The ennui-ridden would-be fashionistas working at the Casa de Sunglasses kiosks  (or whatever they're called).  Really.  Like the police, not all have the skill, but you'll know the ones I mean when you see them.  They see everyone, they see the eyes, the hands- and if not the waist, they are certainly checking out other areas of the bodies of passers-by.  Sure, some people get checked out a lot closer than others, but no one gets by without at least a cursory look.  (I feel like a piece of meat when they look at me like that.  OK, they do not look at me like that.  But a boy can dream).

That's it.  No grandiose conclusions from me- but if you think about it, you may have some new ideas about education, motivation, and observation.  And you might become a bit more observant yourself.



Sunday, May 16, 2010

PDFs are the devil.

This isn't new, but a lot of folks don't seem to realize just how bad PDFs are.  Remember when we told people to send us PDFs instead of Word documents because we thought PDFs were "safe"?  Boy, were we wrong.  OK, we weren't wrong, but times (and threats) have certainly changed.  Now, with the XML-based Office file formats and the proliferation of PDF malware, I'm much more leery of PDFs than DOCX files.  The PDF specs are part of the problem, and the implementations of PDF readers are another part of the problem- the specs allow for things like embedded executables, and the implementations are buggy.  If you haven't read about these issues, check out the articles below:

Some have suggested disabling JavaScript in your PDF reader, but that doesn't resolve all of the issues.  I don't have a perfect solution, but I do have a suggestion, one that I've adopted- it is far from perfect, (it is slow and lacks features), but it works to add a layer of protection when viewing PDFs online.  Gpdf can be deployed to your browsers (Google Chrome and Mozilla FireFox only), it will open PDFs in Google Docs, this moves rendering to Google's servers and adds a big layer of protection to your browser.  Information and installation instructions are available from  Google docs rewrites PDFs on the fly, and adds a significant layer of protection.  Now don't be naive, Google rewrites the PDF so they can see what you are reading, and any anti-malware systems they use are to protect their servers, not you- they are Google, after all.

As I said, Gpdf is not perfect, but it is a step forward.  Which is the right direction.



Friday, May 14, 2010

Who's up for a SecTorBus trip?

We tried last year, and it almost, very nearly, happened.  But it did not.  Maybe with a bit more lead time we can do it this fall, a road trip to Toronto for the awesome SecTor security conference.  Like a Shmoobus, but headed north instead of south.  Interested? Email me at work, jdaniel [at]  I'll try to get them to sponsor again (they're cool like that).

Possible routes are Boston to Northern Virginia to Toronto, or maybe Northern Virginia to Boston to Toronto.  It depends on who joins us, and which highway that stand beside waiting for a ride.

And, no, it will not look like this:


Let me know...


Wednesday, May 12, 2010

Quick Update on HacKid

HacKid is coming together nicely, with events in the Boston area (Cambridge, actually) and Northern Virginia.  It looks like the inaugural event on the weekend of August 28-29.  The website and wiki have been updated, and there's more information on the latest episode of the Southern Fried Security podcast.

Round up the little guttersnipes and get them involved.  You, too.



Wednesday, May 5, 2010

HacKid Conferences

Have kids? Nieces, nephews, grandkids? Maybe Big Brother/Big Sister or some other rent-a-youth? Perhaps you just want to boost your chances of working with functional young folks in several years when they join the workforce.  Chris Hoff had a great idea at SOURCE Boston this year, he brought his three daughters- which got him thinking about kids, conferences and hacking.

The result sounds like a great idea, HacKid conferences, check out the site for more info, then join and contribute to the wiki.  It looks like Labor Day weekend will be the first round of events, but keep an eye on the HacKid site for updates.



Monday, April 19, 2010


Hopefully you've seen this all over the place by now, but if not...

OWASP released their updated Top Ten list for 2010 today.  From the site:

"The OWASP Top Ten provides a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are...

We urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code. "

The full 22 page PDF can be seen here (opens in Google Docs because I don't trust PDFs. Not that I trust Google, either, come to think of it).

This year's list includes a completely new list of problems we have never seen before.  No, wait, this is stuff we've been fighting for years.  We need to get the word out to the right people, and it is pretty clear that we have a way to go on that front.  This years' Top Ten features:

  • A1: Injection
  • A2: Cross-Site Scripting (XSS)
  • A3: Broken Authentication and Session Management
  • A4: Insecure Direct Object References
  • A5: Cross-Site Request Forgery (CSRF)
  • A6: Security Misconfiguration
  • A7: Insecure Cryptographic Storage
  • A8: Failure to Restrict URL Access
  • A9: Insufficient Transport Layer Protection
  • A10: Unvalidated Redirects and Forwards

Read 'em and weep.  Or, better yet, read 'em, and spread the word.



Saturday, March 27, 2010

Personal Security, Conference Stupidity

You've seen them. You've probably even been one. But you know better. I am talking about the "conference dorks", the folks who go to events and wander all over town proudly displaying their conference badges, usually with plenty of computer and/or camera gear dangling off their shoulders- you know, screaming "I'm a tourist, rob me!".


I am pretty sure what I saw wandering around SXSWi this year was the worst I've ever seen, but I've seen some pretty dumb things at RSA and NADA conventions, too- and those aren't in cities as nice as Austin. This isn't meant as a paranoid rant, or meant to spoil your fun, but seriously, think about what you're doing. Here are a few tips, primarily designed for the pedestrian, and it is far from a comprehensive list- feel free to add more or argue with me:

  • Ask someone what areas are safe, and which are not. Also ask WHEN things might be less safe.
    • Ask friends who live in the area. Not the practical joker friends, either.
    • Ask at your hotel (they want you to live long enough to check out and pay your bill).
    • Ask a local cop. Don't bother them while they're busy, don't waste their time- but they know, and they do not want to have to fill out yet another report about a crime involving an ignorant tourist.
  • Do not advertise being a tourist:
    • Don't wear name tags/badges when outside event venues. I don't care if it is a SXSWi Platinum badge, don't do it.
    • Think about the gear you carry and the way you carry it.
      • Travel light.
      • Keep straps short, and gear tucked in close.
      • If you have to carry things any distance, make sure you have one hand free at all times (or have something you don't mind dropping in one hand).
    • Look at yourself, think about where you are going (and how you're getting there). If the images don't line up, change something (clothes, route, attitude)
  • Be aware of your surroundings, and stay alert.
    • Don't be nuts, but keep your eyes open, and look around.
    • "Sweep" your path with your eyes, note what people have in their hands and look at their faces.
      • Eye contact is a tricky thing, it makes some people uncomfortable. Glance, do not stare at people.
    • If something makes you uncomfortable, stop and ask yourself why.
      • Our Fight or Flight wiring is not ideal for our modern world, but ignoring "odd feelings" about a situation is just plain dumb.
  • When walking, plan your path several dozen feet in front of where you are.
      • Avoid walking close to blind doorways, spaces between cars, blind spots near dumpsters, mailboxes, any obstacles.
      • This limits both innocent surprises of people stepping out of blind areas into your path, and puts you a step or two away from potential harm.
      • If there are solid walls or fences on one side of your route, stay close to them (stepping away for gates/doors/etc).
      • Glance back occasionally.
        • Stopping before crossing a street keeps you from getting run over, and allows you to take a good look around without being too obvious about it.
  • Traveling in groups is usually better than traveling alone.
    • But a group of idiots isn't always much better.
    • Also, ask yourself if your group could appear threatening to others.
      • Groups of drunken, obnoxious con attendees are never pleasant.
        • Unless you are in the group.
          • And even then it can be ugly.
    • Do not assume that anyone in the group knows where they are going. Plan your routes accordingly.

Another thing, I don't care who you are, or how tough you are, or what movies you've seen- avoiding a problem is the best course of action. If you go out looking for trouble, you are likely to find it.

Be safe.


Monday, March 22, 2010

Security BSides San Francisco and Austin

That was fantastic! But please remind me to leave more than ten days between these things, OK? Two more amazing BSides events have happened, first in San Francisco, then in Austin.IMG_0858

San Francisco was a two day event, there is a lot of information of the event site, audio and video will be posted "as volunteer time permits". The talks were great, every one, and the second incarnation of the PCI/Compliance panel we did at Shmoocon included a merchant and a QSA, with (not surprisingly) some strong opinions from the audience. There are more details on all presentations on the talks page. I have a photo set up in Flickr from BSides San Francisco.

IMG_1196Austin was a one day, less structured event, lining up with SXSWi, but not a traditional security conference- and there was very little crossing of the audiences. We tried to downplay expectations, but ended up with great attendance and amazing content again- and we did it in a true unconference format, even using Open Spaces in one of the rooms for breakout sessions while having the other room set up for traditional presentation formats. Links to audio and video are also being added to the site as they are posted. I have photos and a IMG_1254few video clips of BSides Austin, including the amazing afterparty, Hackers on a Duck- an after-hours, grown-up version of the classic Duck Tour.

Now that I've had a week to recover, I am really looking forward to the upcoming BSides Boston event, if you want to join us there, please sign up at EventBright, and if you would like to speak, sign up on the talks page. We will most likely do a hybrid model, some scheduled talks and some rooms setup for breakouts and impromptu conversations.


Sunday, March 21, 2010

I knew what I meant.

In my last post I shared some thoughts on Howard Schmidt and his new CyberThingie position.  I really wasn't clear on my "burning bridges" idea, and I need to correct that.  Adam Shostack gently pointed out shortcomings in the post, and helped me focus my thoughts- the clarifications follow.

To clarify what I meant in the earlier post-

I think that Howard has no budget authority, and although he negotiated a significant improvement in how he reports up the ladder and who he reports to, he is still very limited in what he can accomplish directly. Adam had some very constructive suggestions, I think pushing for transparency, and helping build/publicize guidelines/standards could actually make a difference.  But, I think he will run up against entrenched people who won't cooperate, and that's where a willingness  to spend personal capital could be critical (at least in the mind of this curmudgeon).  When persuasion and compromise fail, he has nothing to fall back on- except the fact that he can call people out, as publicly as necessary, and use all those contacts and connections he has built in his career to make it very uncomfortable to be a security obstructionist.  I don't think that is something he should undertake lightly, or regularly, but I do think setting a "don't push him too far" expectation could compensate for some of the weaknesses of his position.  I believe his situation, not needing the position, being able to go home and forget it all when he's done, could be empowering- he doesn't have to play the beltway clique games by the rules.

But, I don't think that is his style.  As I said, I hope I'm wrong, and I'm willing to help him prove me wrong.

This leaves the question of how he should distinguish between those who deserve to be called out because they really are a problem, and those who have not been convinced by his arguments.  Here I think Mr. Schmidt can turn to some of his trusted contacts before acting, but this will always be a tricky balance.



Sunday, March 14, 2010

A belated "open letter" to Howard Schmidt

I know I'm late to this party, but we have a new (but not really) Cyber-Something (not czar/tsar or anyone with authority to inflict papercuts much less beheadings), Howard Schmidt- and I have a few opinions to inflict, and an "open letter" of sorts to offer.

There were nice people who offered nice Open Letters to Mr. Schmidt in the face of ugly cynicism about the appointment, including these from Adam Shostack and Chris Hoff.  Adam had some very good suggestions, and Hoff made a genuine and altruistic offer.

I just happen to think Howard Schmidt is not the right guy; he could be, he has the credentials and experience, I just don't think he's going to move us forward.  He talks about InfoSec leadership from our paralyzed and dysfunctional federal government as being needed to solve the problems of private industry.  The phrase

"We're from the government, and we're here to help you"

has brought out the literal and figurative shotguns from concerned citizens throughout history, and in hindsight, that was often an under-reaction.

He talks about the relationships he's built and his experience.  He does not talk about the powerlessness of the position (although he did improve this dramatically before accepting the job).  Largely missing is talk about transparency, and completely missing are direct challenges to those in the way of progress.  Schmidt has the connections to make some things happen- but more importantly he has connections he can burn if they get in his way.  That's what it will take to get power into this feeble position, a willingness to pick fights, even with old friends, and publicly call out the worst obstructionists.  Schmidt is in a unique position, he does not need this, he can go live happily on his mountain, maybe sit on some boards for entertainment- so a few burned bridges aren't career limiting for him.

With these things in mind, here's my "open letter" to Howard Schmidt, I really hope he has better things to do than read this nonsense, but...

Dear Mr. Schmidt,

I'm not sure you are really the best person for the job.  It is not that you aren't qualified, but I think you are unlikely to burn bridges that you have spent a lifetime building- unfortunately, calling out people who obstruct security is one of the few powers you have.

I hope I am wrong.

As a matter of fact, I so sincerely hope I'm wrong that if you ever get desperate enough to ask me for help, I will do whatever I can to help you prove me wrong (I prove myself wrong regularly, I'm pretty good at that).  I'm not sure what skills I have to offer, but I'll try whatever you need.  I do have a talent for offending people which may be handy.

Your Humble Curmudgeon

There, that's it.


Monday, March 1, 2010

A step in the right direction

Sure, I may have trashed the regulation and regulatory process, but it is still significant.

iStock_000006229191XSmallNot Earth-shattering, but significant, especially here in the US.  Not near as significant as it should be, but a starting point.  Massachusetts' MA 201 CMR 17.00 data protection regulations are now in effect, and that is a huge step forward for the protection of personal information.  Breach disclosure laws are old news, but 201 CMR 17.00 is different, it prescribes data protection specifics, and it is not limited to those in Massachusetts:

"201 CMR 17.01 (2) Scope 
The provisions of this regulation apply to all persons that own or license personal information about a resident of the Commonwealth."

Yes, all persons (which includes companies and organizations), regardless of where they are located, are covered if they:

"Owns or licenses, receives, stores, maintains, processes, or otherwise has access to personal information in connection with the provision of goods or services or in connection with employment."

The standard interstate commerce laws cover out of state jurisdictional issues- being out of the state does not shield anyone.

This is a big deal, for two key reasons. 

First, it is leading the way in state regulation of the protections of our data.  There have been other regulations about protection of data, but I believe this is ground breaking and will be followed by other states (or at least watched from the sidelines with a bucket of popcorn and a cold beer).

Second, it has a very broad reach, it is not industry-specific, it applies to a large number of organizations which have never had regulatory requirements on their IT system before.  Specifically, it applies to:

"Person, a natural person, corporation, association, partnership or other legal entity, other than an agency, executive office, department, board, commission, bureau, division or authority of the Commonwealth, or any of its branches, or any political subdivision thereof."

Oh, and don't get wound up about the government exclusion for Massachusetts, they are covered under Executive Order 504, which mandates similar protection of data for them.

This regulation can put a significant burden on businesses which do business with Mass residents (and bother to comply), and I believe that small businesses face the biggest challenges.  (Let's be honest, the burden is to do what they should already be doing, but are not; that doesn't mean it will be easy).  Small businesses are the least likely to have dealt with regulation before (except in specific regulated fields), and they are the least likely to have the knowledgeable personnel and financial resources required to comply.  Those organizations in the 40-200 user size are probably going to have the hardest time (as they often do)- they're too big for doing everything manually, and not big enough to justify the enterprise tools to help manage some of the tasks at hand.

It will be interesting to see where this goes, if anywhere.  I don't think most people in Massachusetts are aware of this, much less those outside of the state.