Great Information Security Resources from the DSD

I’ve referenced the Australian Defence Signals Directorate’s Cloud Computing Security Considerations document in the past, but they have a lot of other resources available.  Many of the references are wonderfully light on government-speak and bloat, and are downright informative and readable (amazing, I know).

Their Strategies to Mitigate Targeted Cyber Intrusions lists the top 35 mitigations for intrusions, and is a solid list- including not only efficacy ratings, but user resistance, and upfront and ongoing costs.  They call out application whitelisting as the number one mitigation, and consider it mandatory.

Their website has a lot of good info, I find the Information security advice and Information security references sections to be the most informative.

Yes, they spell “defence” funny, but then they probably think Americans spell defense funny, too.

 

Jack

Act now, it’s crunch time for (ISC)2 candidates

If you hold a CISSP or other certification from (ISC)2, please read this.  If not, you’ll probably want to skip it, unless you are having difficulty sleeping.

I keep trying to ignore it this year, but I can’t.  There are a bunch of people running for the (ISC)2 Board of Directors, including about a bazillion unendorsed candidates.  OK, maybe not a full bazillion, but at least seven- and they need at least 500 “signatures” to get their names on the ballot for the upcoming election.

I think Rob Graham summed up my feelings very well in this post.  I think (ISC)2 and the CISSP just need to go away, be put on an ice floe and sent out to sea- but since that seems unlikely, I’ll support folks who want to make a change.  Wim Remes made it to the board last year from a write-on candidacy, let’s see if we can get more- at least on the ballot.

Grecs has done a great job keeping tabs on the candidates, blog posts, and articles on the subject- see this post at the Nova InfoSec portal- it has all the details you need to find most of the candidates, and instructions on signing their petitions (it’s easy, just send an email to the candidate from the email address on record with (ISC)2 including your full name, (ISC)2 member number, and a statement that you are signing/endorsing).

I believe getting write-in candidates on the ballot is worth the few minutes it takes, it gives us a choice of BoD members, and (I hope) it sends a message about the “endorsed” candidate pool, and that whole process of restricting choice of candidates.  Signing the petition to get someone on the ballot does not commit you to voting for them in the election, and there seems to be no limit on the number of petitions you can sign (In the actual election you can vote for no more than four candidates).

Please take a few minutes and review the positions of the various candidates, especially “The Four Horsemen”- and then please sign the petitions of those you feel appropriate.

 

Jack

Pauldotcom 300th episode

I assume if you are a regular Pauldotcom listener you probably know about this week’s special episode- but if not: it is the 300th episode, and will run from 10:00 am to 6:00pm EDT.  The lineup of guests and tech segments is outstanding, and we will be raising money for breast cancer research throughout the event.

Full details are at the episode 300 page, here are just a few highlights:

Tech segments galore

Panel discussions on Mobile Security, Security Awareness Training, What Really Works in Network Defense, and Is Pentesting Worth It?

The guest lineup is amazing, including Charlie Miller, Wendy Nather, SpaceRogue, David Mortman, Josh Wright, Zach Lanier, Dameon Welch-Abernathy (aka "Phoneboy"), and many more

Please join us live on Friday, or enjoy the audio or video recordings later- and help us raise money to fight breast cancer.  Links to make donations are on the top of the episode 300 page.

 

Jack

The BSides Las Vegas 2013 Innovation Challenge (aka "The Science Fair")

Yes, 2013. There are a lot of great BSides (and other) events between now and then, but we want to get the word out about this to give people time to come up with some amazing submissions for this challenge.  The Innovation Challenge is being run in conjunction with Security BSides Las Vegas 2013 by a team lead by A. P. Delchi.  Full details of the “Science Fair” are in the press release below:

The BSides Las Vegas Innovation Challenge
Aka "The Science Fair"
Produced by: A.P. Delchi

OVERVIEW:
Remember the heady days of the science fair? Demo parties? People coming together to show off the amazing bits of awesome that they had made in their basement? It’s time to revive this tradition and bring it to the modern day security conference. From an open call to the world, twelve teams representing hackerspaces and maker groups will be selected to come to Las Vegas to compete in four categories in front of a panel of judges to demonstrate what they have accomplished. Awards will be based on cash and hardware provided by sponsors and donations from across the industry.

THE CHALLENGE:
Get your hackerspace, maker group, or team of friends who tinker in your basement and prepare your best projects and innovations to be presented to the BSides Las Vegas conference. This is an open call to groups that have established themselves, or are up and coming and ready to amaze the world. Submission methods are up to the group, but videos, pictures and live demonstrations are suggested. The call for submissions will be seeking entries for the following categories:

Category One: Things that make things
Did your group build a 3D printer, laser cutter, CNC device or some other piece of awesome that helps you make other things? What did you do with it after you built it? For example some folks have built 3D printers and used them to fabricate parts from skateboard wheels to carrying cases. Show us what you built, and what you built with it!

Category Two: Biohacking
Has your group experimented in gene splicing, implants, aeroponics, automated hydroponics, biofuels or other such biologically inspired projects? Bring your beakers and your Jacobs ladders to the people who rarely hear about such things. Innovations such as a kit to test food to see if it contains GMOs, Innovative home farming methods using automation and chemistry are what we are after.

Category Three: Vehicles
Get out of the garage and in front of the people! Have you turned your ordinary car into a hackmobile? Converted an old school bus into a rolling data center? Does your car have more storage space than your home computer? We are talking more than just thumpy bumpy sound systems – we want to see your home made Batmobile. Atomic engines to power! Nessus scanners active, rolling Wi-Fi hotspots activated! Make it so!

Category Four: Demos
From the good ‘ol days of demo parties, show us what you’ve got! You will have your moment on stage to display your awesome. Remember the talent show scene from Revenge of the Nerds? We now have EL wire and wearable MIDI. Take us on a magic carpet ride of awesome that shows what your team can do. Unlike the other categories, you will perform at the awards party and no one will know until it’s over who will win this category. Clap your hands everybody, and everybody clap your hands!

Open submissions start NOW. Submissions can be anything from photographs, videos, live streaming or wherever your imagination takes you. Six months out from the event a panel of judges will select three submissions from each category for a total of twelve groups who will be invited to come to BSides Las Vegas and make their presentations. From there a second panel of judges hand-picked from the old , new, and weird school will judge the submissions with the winners being announced at an open party during the conference.

THE PRIZES:
Prize packages will be determined based on sponsor and donor contributions. At this time hundreds of trained squirrels are working to contact potential sponsors and contributors to make the rewards the best we can muster. As this develops we will keep you updated.
In each of the four categories, the prized will be :
1st place : Amazing package of stuff and things, to further your awesome and make your innovations come true.
2nd place : A not as amazing as first place but still enough to give you toys to take back and build, innovate and make things happen.
3rd place: Guaranteed entry into the competition next year without having to go through preliminary judging.
Prizes for the first three categories will be awarded at an awards party to be held after judging. The demo competition and awards will happen as part of that party. Plans for live bands, DJ’s and sponsor demonstrations are in the works!

SPONSORS & DONORS:
Does the idea of a show of awesome and supporting hackerspaces & maker group innovation make you feel warm and fuzzy inside? Do you want to donate hardware from your company, or sponsor the event in other ways?  Let us know! We will be reaching out in every way we can to ensure that the sponsors and donors as well as the participants are recognized in the forward march of human driven innovation. Security BSides Las Vegas, Inc. is a registered Nevada non-profit educational and charitable organization and the contest organizers are ready to work with you to help make this an amazing competition.

NOW GET OUT THERE AND START BUILDING!

Marketing to the cynical, skeptical, and jaded (us)

There was a good thread on the Security BSides Organizers’ mail list about sponsorships, and I shared some observations and opinions about the best ways for BSides sponsors to get the most value out of their investment.  It was suggested I turn my comments into a blog post about marketing to InfoSec pros in general.  So here it is, somewhat cleaned up and expanded, my suggestions for marketing to the jaded, professionally skeptical, and often cynical technology and security pro.

The key is contact. BSides events are different from most events because we want sponsors, not vendors, to keep the atmosphere non-commercial.  To get real return out of BSides the goal needs to be awareness, not lead-generation (although recruiting is generally an exception to the "no lead gen" idea).  This applies to most marketing, multiple low-impact points of contact or visibility might be ignored, but they are likely to have real reinforcement value if done properly- and are unlikely to offend or annoy people.  Simply driving for the leads often gives a pile of useless email addresses, and people who are annoyed with your calls and email.  This is not to say no leads will come from BSides or other “low-impact” events, but that they should not be the primary objective.

With BSides, there may be various underlying goals, brand awareness (look at Milton Security, or Astaro); awareness of what the company does/does now (wow, Tripwire does all that now?); or goodwill and brand reinforcement (Barracuda, IOActive, Qualys).  (Forgive me missing many examples here, I’m using these based on some BSides experiences, this is by no means a comprehensive list).  Sponsors who have a defined their objectives will do best- as with most things in life, having a reasonable goal is a pretty good idea.

No matter what, participation is key to amplifying the message and investment.  Having people at the event, speaking, volunteering, contributing, that is the key to maximizing value IMHO. (And remember, I'm in vendor land, I pay attention to these things for work, not just BSides).  That’s right folks, just sending money is great for the event, and has value for the sponsor- but you have to participate and engage to get the greatest results.  Prove you want to be part of the community, that you are listening, not just broadcasting, and have some fun too.

This is not to say that when I walk into your booth at a trade show and ask about your product that I am not a lead.  But when I walk by and someone leaps out to accost me- I am absolutely not a lead.  And by the way, if you are really serious about lead generation I’m sure you can answer the following questions about those leads:

• What percentage of total leads are “real”, “qualified” or whatever terminology you use to determine level of effort in follow up? (You don’t treat them all the same do you? That would be foolish).
• An easy one: what’s the cost per qualified lead?
• What is the close ratio on gross and qualified leads?
• What is the profit margin on those leads, and how does that compare to average transactions, and other to events?
• Bonus for the hard-core: what’s the retention rate on customers acquired at the event?  (Assumes subscription, support, or other recurring costs related to the initial sale).

What, you can’t answer those questions?  Then surely you are working on setting up a metrics program so you can, right?  Otherwise, you are probably wasting a lot of time and money, and likely annoying a lot of folks in the process.  For the record, I spent many years paying attention to lead generation and lead metrics for a variety of industries.  That was in a past life, but it appears to still be relevant.

Words like “engagement” and “community” are overused by charlatans, marketing gurus, and social media experts- but if you cut the crap and actually engage the community, people will pay attention.

And while I’m on a roll: “influencer” is another abused term, but some people do have more of a voice in the community than others.  Ignoring people who “aren’t ready to buy” could be a very bad idea if they are interested in what you do.

Remember, “marketing” isn’t a dirty word as long as they’re buying the drinks.

 

Jack

Nonsense abounds, and more is coming.

I can’t even think about reading coverage of the Amazon Web Services outage, the hype and stupidity is already overwhelming.

The cloud has failed us again!

Yes, and we have failed it again, too- as we have pretty much every preceding technology.  If I understand it correctly, the “logic” is that those who put all of their cloud services in a single zone with a single provider, a zone/provider combo with a few scars in its history at that, are somehow the victims of a failure they should have anticipated and mitigated.  Fine, everyone’s a victim, whatever.  I propose the following slogan for AWS:

AWS, we’re cheap and so are you. Do it right or STFU.

But let’s not dwell on that, recently there have been a couple of other rant-worth stories.  We can ease into full blown rant mode with this one:

“99% of attacks could be stopped by patching”

At least according to the above article in Infosecurity Magazine.  There is a huge and flawed leap required to get to this utter nonsense, and it needs to be beaten down, and hard.  The article says Microsoft’s chief UK security advisor Stuart Aston

“pointed out that less than 1% of attacks are based on zero-day exploits”

and I’ll buy that, but I would obviously like an actual reference, and you know, some of that “DATA” stuff to back up that claim.  Then it gets interesting, with an epic leap of logical fallacy leading to…

 

 

 

 

 

 

 

 

“The implication is clear: 99% of attacks could be stopped by anti-malware and up-to-date, fully-patched, software.”

No, it cannot. That is so very wrong, on multiple levels.  First and foremost, you cannot “stop attacks”, you can only stop or alter the consequences of the attacks.  You can stop attacks from succeeding (sometimes), and minimize the impact on your organization, but the attacks will come no matter what you do.  And no, it is not pedantic to get wound up over using the wrong terminology in a trade publication.  Get it right.  Further, the idea that “attacks” only fall into two categories, zero-day and patchable, is more nonsense.  No, patching and anti-malware will not fix logic flaws, authentication failures, misconfiguration, or a myriad of other problems.  Nonsense and drivel, stop it.

But that is really only a minor annoyance compared to the rage-inducing drivel which recently  came from Ramon Krikken, a research vice president at Gartner.

As referenced in this Search Security article, Mr. Krikken said some logical things, such as there is a clear disconnect between security and application development, and that developers are going to do what they are measured on- which is generate code, not necessarily generate secure code.  There are some other viable references and observations in there, but they madness comes from his view of Web App Firewalls and other bolt-ons:

“The application security challenge has become so difficult to address through development, Krikken said, that he instead encouraged enterprises to consider an alternative strategy that relies less on developers and more on integrating defensive technologies – like Web app firewalls (WAFs), database audit and protection (DAP) products and XML gateways – into the enterprise application architecture.”

Secure coding is so hard that we need to rely on WAFs and other bolt-ons to protect us?  But WAFs are software, and by definition must include web applications, and as we know web software has vulnerabilities, so do I need to put another WAF in front of my WAF to protect it?  How far does that go?  We have seen vulnerabilities in WAFs, and we will see more.  Also, WAFs are far from perfect, they can do nothing about most complex bugs, and can rarely handle logic flaws, so we’re just throwing another layer of complexity in the stack to add security?  Bolt-on security doesn’t have a great track record.

There is a place for WAFs, in my mind they can perform two functions very well: filter out basic internet crap, and when properly tuned (generally with custom rules) they can provide defense against known weaknesses in web applications until the code can be fixed.  WAFs are frequently bypassed, and are generally difficult to properly tune; this nonsense from Mr. Krikken has damaged application security.  He may have said mitigating things, but the takeaway is “I don’t need secure code, because that’s hard, I just need a WAF”.  And that is dangerously wrong.

If I were a cynical person, I might think Mr. Krikken has made his living in the “advising people who sell bandages to trauma patients” world of information security too long to be taken seriously.  Glad I’m not like that.

Full disclosure/reminder bits: I work in vendorland, and have for the past several years- and these vendors use analysts to help focus products and messages.  Hopefully it is obvious that I have not fallen completely under the spell of industry analysts.  (With at least one notable exception).

 

Jack

BSides Las Vegas Speaker Mentorship

One of the many great things happening this year at BSides Las Vegas is the New Speaker Mentor program.  The goal is to encourage new speakers to participate in the community, this will help both the new speakers and the community.  It can be difficult to give that first talk, that’s why a team of mentors will work with the new speakers to hone their presentation and provide support for them.  Full details are available at the Mentorship Program page and information on submitting a talk to this (or any track at BSides LV0 are at the CFP page.

If you are interested in participating, or know someone who might be, please join us for this new program.  And do it soon, the CFP for all tracks closes June 15.

 

Jack

A meandering rant on sexism.

This has been a bad year for technology.  Not necessarily for the business of technology (although it is very hard to discuss the current state of the tech and InfoSec biz without using the word “bubble”), but for the culture and future of tech.

I commented on the depressing “booth babe” situation at RSA in this year’s RSA wrap-up blog post, it is an ongoing embarrassment.  As I’ve said before, in the right contexts I have nothing against attractive people, fast cars, or other things normally used to sell cheap beer- I just don’t believe tech and security events are the correct contexts.  There are not very many women in tech, and that is not a simple problem to fully diagnose or correct.  There is plenty of blame to go around, starting with the way we market to and educate brainwash young folks, but what we do inside tech industries is our responsibility and we have a lot to fix.

A couple of weeks ago I was at Infosecurity Europe in London.  It is very much like a somewhat smaller (but still big) RSA San Francisco event.  The attendees (at least from my perch in the Tenable booth) were much more likely to be customers seeking information on the latest products and services than attendees at RSA, which certainly gets a lot of customers- but is really a business-to-business event IMHO.  I had many great conversations with customers, prospects, and folks who just wanted to chat.  I’m looking forward to going back next year- but I’m working out my schedule so that I can get over to BSides London next time.  BUT, the booth babe phenomenon was a blight on Infosecurity Europe, too.  Probably worse than RSA.

Last week I was at InterOP Las Vegas.  It is a big networking show, with a healthy dose of cloud, and a touch of security.  I enjoyed the event, and hope to put together some thoughts about what “security” means to a non-security crowd.  Sadly, there were more “booth babes” than in years past.  Special dishonorable mention goes to WatchGuard for succumbing to the lure of the booth babe over technical innovation in a field they dominated a decade ago.

And then there was the Dell fiasco.  Dell had a partner event in Denmark and the moderator they hired for the day was, well, not moderate.  In a series of demeaning and sexist remarks following Michael Dell’s talk Mads Christensen said some really inappropriate things.  The primary source of coverage is this post at Elektronista (if you are a sentient being, you’ll probably want to skip the comments), and Molly Wood has a good follow up post on why we need to keep talking about women in tech.  Sadly, Dell has only apologized weakly thus far, and no actions appear to have been taken.  It looks like Christensen issued a non-apology (I’m sorry if you were offended…).  The ability to hire and retain good employees is critical to a company’s ability to execute, and with a dire shortage of candidates for many security and tech roles Dell’s mistake and subsequent inaction may cause them some HR pain.  Let’s hope it does.

And, not to be completely negative here, ExtraHop Networks gets credit for going in a different direction to draw attention to their booth.  And they are doing it because what they do works, not as a political statement. Because it works, the excuse for using booth babes, is turned around here.  See this post at Network World for details and links.

As a reminder, I’m an old, white, heterosexual male with a great job.  I’m supposed to be part of the problem, not one of the voices ranting about it.  I can’t imagine my outrage if I were a woman trying to deal with the tech industry.  It is unacceptable.

By the way, I’ve been an “old boy” for a while now, and yet I have not received a single invitation to join any of the much-heralded Old Boys’ Clubs.  Perhaps I’ve done something to offend the Old Boys’ Clubs, such as not wanting this industry to be one.

 

Jack

Context matters

A recurring theme for me lately is explaining the significance of taking things in context.  When discussing vulnerabilities with people (I do this a lot working at Tenable), some folks don’t intuitively grasp that context is critical in translating a finding into usable and valuable information.

Let’s shift gears, a few weeks ago I was in Texas for BSidesAustin.  While I was there I picked up a couple of bumperstickers, this one’s my favorite:

(For those who don’t know, that’s a stylized flag of my home state of Texas, and Texas is always trying to secede from something).

What does this have to do with context?  Imagine this bumpersticker on the back of a Cadillac Escalade in Houston, there’s the stereotypical Texan sick of the meddling of the federal government and the liberal hatred of the Second Amendment.  Now, let’s picture the same sticker on the back of a Toyota Prius in Cambridge, Massachusetts-  the sentiment is more likely “get rid those ignorant hick psycho cowboys who are screwing up America”.  Context matters.

So, back to that vulnerability, opportunity, threat, bug, whatever it is you are contemplating.  You have to ask yourself “Is this on the back of a Houston Escalade, or a Cambridge Prius?”.  Not literally, of course, and certainly not out loud- people would give you the kind of look I’m used to getting.  BUT, you do need to assess how the vulnerability is exposed and what mitigations are in place (or possible); how hard the threat may be to execute against your situation; whether there is a graceful failure mode if the opportunity turns out to be inopportune, etc.

Consequences of the action or situation are also part of the context; the world is full of unintended consequences, please limit your contribution to them.

I guess what I’m saying is don’t make decisions in a vacuum, because that would suck.

 

Jack

Wait, what? Someone has to look at those logs?

Anton Chuvakin has a good post over on the Gartner blog about security monitoring and cloud systems.  Depending on your point of view and/or experience, you may think his comments are thought provoking, or possibly obvious (this will probably depend on where you are on the cloud adoption path).  I agree with the good Dr. Chuvakin, but my recent conversations with people trying to come to grips with monitoring and log analysis have given me some contradictory insights.

Anton is correct in his mapping of visibility and coverage, and on the observations of the perspective of CSP-MSSPs (Cloud Service Provider – Managed Security Service Provider), but there is one point I have heard loudly from some people- that in spite of some MSSP’s theoretical threat intelligence and perspective advantages, they simply do not understand the businesses they serve well enough to provide enough value to justify their expense.

In my recent peer-to-peer session on What Works in Log Analysis at the RSA Conference some participants were struggling to pull log management and analysis back in-house after outsourcing it.  Their battle was that the MSSPs never lived up to the promise of economies of scale and advanced insight into traffic anomalies, possibly due to shortcomings on the part of the MSSPs, and possibly because the advantages of scale and “big picture” view were offset by a lack of focus on the specific circumstances of the customer.  As with many other issues in business, you (hopefully) know your situation better than anyone else.  I’m not saying that you can’t outsource SIEM, log management/analysis, or anything else for that matter- I’m just saying you need to understand the trade-offs and make sure you monitor the MSSP until you are satisfied- and then keep monitoring them.  Any effort you duplicate in monitoring the performance of your CSP-MSSP or MSSP is cheap insurance- the last thing you want to face is a surprise failure of your monitoring service and the sudden need to rebuild an in-house monitoring program.  You thought getting all that data pushed out to the MSSP was a pain- just imagine trying to get it back.

 

Jack

Who put all that travel on my calendar?

I did it to myself if I’m honest.  I will grumble about airlines, the TSA, hotels, cabs, etc.- but the great thing is that I get to see old friends, meet folks, and have some engaging (and inane) conversations.  Some of my upcoming adventures are below- if you’ll be at these events or in the general area either find me and say hello, or hide from me, as you feel appropriate.

I’ll be at BSides Austin later this week, participating in a cloud computing panel and later giving an update on the stress and burnout research.  And joining in Hackers on a Duck III.

Next week I will be helping at SOURCE Boston and MassHackers BeaCon (both in Boston), followed by a trip to London for Infosecurity Europe where I’ll be working the Tenable booth (and hopefully sneaking over to BSides London).

After just enough time to do some laundry, I’ll be at NAISG Securanoia in Boston, helping with the event and speaking on the state of information (in)security, then off to InterOP in Las Vegas where I’ll join the panel “So you want to be a Tech Influencer”.  Next stop will be BSidesROC, in Rochester, NY, and then maybe home before heading out again to Las Vegas and who knows where else.  Travel arrangements per that old Johnny Cash song.

I’m not hard to spot, subtlety is not one of my strong suits- find me and chat.

 

Jack

Filling in some blanks

My last post had some incomplete thoughts (this is not unusual), and I decided to address some of them (this is unusual).

I mentioned that segmenting your network was advantageous for a variety of scanning and monitoring reasons, but I didn’t didn’t elaborate, let me do that now.

There are some great systems for data correlation which can tell you significant things- for example whether that IDS alert was for traffic targeting a host vulnerable to the specific attack detected.  Unfortunately, we don’t all have the resources to have such systems, or the time to tune them.  If, however, you have an effectively segmented network and see an IDS alert for an attack against Internet Explorer in a segment with only Linux servers you can relax.  On the other hand, if you see alerts for an event targeting a Windows bug you have yet to patch, and it is inbound to your Windows segment- it is time to crank up the caffeine and get busy.  You get the idea.  And it extends beyond IDS, even simple network stats can become informative- anomalous traffic is much easier to spot in a segmented network, a sudden increase in inbound traffic to a workstation segment, outbound requests from web servers, or SMTP where it doesn’t belong are just a few examples.  You can certainly sort this out with a little analysis, but in a well segmented network you can reduce the amount of thought required to make “react or relax” decisions.

Some of the other reasons I mentioned are more obvious, keeping traffic in local segments where possible to minimize network noise, and protecting systems from having Something Bad™ rip through the network unhindered.  A couple of thoughts on the segmentation-for-security concept are worth elaboration; grouping by OS makes sense from a management perspective, but if you do that it won’t stop the aforementioned Bad Things™ from running wild, so consider how best to segment for your situation and needs.  It may be that the security disadvantages of putting all similar digital eggs in one basket are offset by the administrative advantages.  Knowing you can scan, patch, and monitor quickly and accurately may be a stronger defense than splitting up your Windows environment.  On the other hand, if it takes a long time to get patches deployed, the added separation may buy you time when bad things happen before patches or mitigations are deployed.  If you do segment for security, you need to put meaningful rules in place to restrict the traffic or you are just adding latency and complexity without adding security.  I would like to tell you that deciding what traffic to allow will be easy, but it probably won’t be.  First, note that I said “traffic to allow”, that is because a default block rule is needed internally as well as for inbound and outbound traffic to the wider internet.  You may need to temporarily allow all traffic internally and perform analysis on what ports and protocols traverse the links, then build rules based on existing traffic.  This is not ideal, as you could allow inappropriate traffic based on “grandfathering” bad behavior, but this is a starting point; as you implement the filtering rules make sure they make sense.  As always, understanding your environment is critical to doing this properly.

Still not a complete story, but hopefully this has filled in a few holes in my last post and given a bit more insight into how and why to implement or extend segmentation.

 

Jack

Segfaults

Network segmentation faults, that is- not those pesky software problems.  Penetration testers and others often say network segmentation doesn’t stop attackers, and that at best segmentation only slows them slightly. Systems and network admins often complain of needlessly complicated routing and access rules, latency, and other problems. 

What these people say is largely true and also largely wrong.  Because they are doing it wrong, and for the wrong reasons.

Network segmentation does not mean simply adding a hop between network segments to confuse and exhaust the poor little packets, and it is not just a tool for restricting traffic for controlling access.

Obviously restricting traffic and isolating access in logical network divisions by function, type, criticality, sensitivity or other reasons relevant to your environment is a logical reason to think about segmentation, but that is only the beginning.

VLAN if you must, but I like physical segregation where possible.  Especially for the most high-traffic and most sensitive segments.  I prefer to use a firewall with a lot of real ports, not one of those crappy things where most of the ports are just switch ports for the LAN.  Just make sure whatever gear you use can fling packets without adding noticeable latency.

Thankfully, broadcast storms are largely a thing of the past, but isolation can still help in diagnosing network oddities.  Not pretty or sophisticated- but sometimes disconnecting segments is the fastest way to find problems.  I can unplug a lot of patch cables (or power cords) in the time it takes to log in and poke around in most network gear (where’s the damned CAM table shown in this version of $EXPLETIVE).  Also, the switch/router/firewall interfaces are great places for packet captures when you are having one of those “the packets hate me” days.  You know, the ones where you go digging for the old taps and suck traffic right off the wire (or fiber).

Why else should you segment?  Network and systems management can be enhanced by segmentation and isolation, as can performance- patch and systems management servers, departmental servers, printers and more can be placed in the most advantageous segment of the network.  For systems which can’t be in the target segment, traffic can be restricted and directed to limit noise on the wire (or fiber, or ether, whatever).

And finally, near and dear to me lately, we have scanning and monitoring.  All your Apache servers in one segment?  Great, patch or vulnerability scans can regularly scan that segment with minimal stray results if the scans have the relevant tuning.  The great unwashed of Windows workstations?  Hammer those with scans looking for unpatched RDP or whatever the Next Big Bug is- without annoying the PostgreSQL servers over there in the DB segment.  It goes without saying that you put scanners in each segment to minimize network noise.  And not just active scanners: passive scanners, network analyzers, netflow sensors, IDS sensors, full packet capture systems, and more can benefit from segmentation and isolation of traffic.

This even applies to virtual segmentation.  Well, some of it does, and there are some virtual equivalents for some things.

 

Jack

Let’s look these gift horses in the mouth

I have a habit of tearing up the various reports and surveys that wander past my view in the world of information security.  This is often really unkind of me, because we need to share more information on what works and what doesn’t if we are going to move forward in this struggle to protect whatever it is we’re trying to protect.  Companies like Veracode, Verizon, Mandiant, Trustwave, and others put a lot of effort into sanitizing, organizing, and distributing the information they gather in their various endeavors, and they share it for free (or at least just an email address).  In a desert largely devoid of data, these reports are oases of information.

And here I am being an ungrateful bastard, trying to x-ray the teeth of these gift horses, then complaining loudly about gingivitis, impacted molars, selection bias, confirmation bias, corporate agendas, and other things Crest™ and a good flossing will never fix.

The problem is that a lot of the data leaves me wanting more.  More details on the data we get, just plain “more data”, and more context.  I also want more honesty about the shortcomings of the reports and data.  Let’s not even talk about some of the bizarre conclusions.  And it makes me crazy (crazier) when I see contradictions in a single report, then one report contradicts another company’s report, then year over year reports appear random rather than additive or complementary.

When you read this year’s Report X from Company Y, ask yourself how the information presented made it into that dataset.  In the case of the breach reports remember that they are about failures- organizations which were:

1. Compromised
2. Discovered it (probably not themselves)
3. Called Company Y to help them solve it
4. And could afford Company Y’s rates, and paid them

Suppose that skews things?  Yeah, me too.  Where are the success stories?

If you see me talk about any of the career studies I’m involved in you will generally hear me start talking about known flaws in the data, after the disclaimers and caveats we move into what we feel comfortable saying about what we have collected.  Of course, I’m not trying to facilitate a transfer of funds from your organization to mine, so maybe its unfair of me to expect the same from those with a financial motive.

And for closing complaints: stop with the moronic USA Today-style “infographics” which tell me less than text would.  Combine the graphics with mixed dark on light and light on dark type/background, add PDF format- and we can’t read them on anything but a large monitor (or in dead-tree mode).  Just make the reports available in epub/mobi so I can read them on my terms and not be forced to read them in the deity-forsaken PDF format these always come in.

And, thanks for doing all that work.  Just stop making me hate you for it.

 

Jack

Post BSidesSF and RSA Post

It was a great week for Security BSides.  I post semi-regular updates to the BSides Google group if you want the ongoing story, but a couple of high points:

I met with Mike Dahn and Gene Kim for a few Board meetings, we reviewed accounting, roles, 501(c)(3) filing status (which is ‘waiting for CPA to complete the audits”), how best to support BSides event organizers, and more.

We had a great conversation with folks from RSA and the RSA Conference.  We all want to minimize needless tension, and RSA was gracious.  The event organizers for BSides San Francisco will continue the conversation with RSA in the coming months.

I had some good conversations with folks from Black Hat.  This will be tricky, we have a direct overlap on dates, and a greater overlap on speakers, sponsors, and attendees than we do with RSA.  But, we’ve started talking.

And finally, planning for BSides Las Vegas 2012 moved forward through several good conversations during the week.

The RSA Conference was the RSA Conference.  It is where a lot of business of InfoSec gets done.  I thought it was better than the past few years as far as talk content.  As has been observed by many, it is not generally the place for cutting edge research, and the expo is all about selling security products.  It can be disillusioning to see the crass commercial side of our business.  The split between those who say RSA is great, and those who leave scarred and scared seems to be whether you have productive meetings during the week (and I had a lot of those this year).

Our Burnout panel went well, we filled the room on Monday afternoon.  Members of the team will be presenting at other venues including AIDE and possibly Infosec UK.  I’ll post more about the career research, as well as the burnout project, as those efforts evolve.

Amazingly my P2P session on “What Works in Log Analysis” was packed, too.  Of course, we had more questions than answers, but people have realized how much data we are missing in our own logs, and want to ease the pain of finding the goods.

All the usual vendor hype and FUD was out in full force on the Expo floor and beyond.  “Big Data” was the buzz phrase of the year, and it seemed at least as poorly defined as APT, Cyber, Cloud, and other past buzzes (even though most have real definitions to those who actually know what they are talking about).  Some glaring examples:

Ferraris and firewalls? I get the speed reference, but really…

Special dishonorable mention goes to Bit9 with the little girl in their poster- ugly scare tactics are ugly.

Good vendors blighting themselves is a recurring theme, whether it is execs telling untruths and trashing the competition, or folks showing ignorance in talks, or just general boorish behavior- there was plenty to see.  Let’s not even discuss what the bad vendors do.

Special dishonorable mention in this category goes to NetOptics, a good company with great products. I have nothing against fast cars, attractive women, or network tools- in the proper context. All three in one obnoxiously loud booth is not the proper context for any of them, especially when I just want to see the latest in traffic capture tools.  Sadly, NetOptics seems to think this is the way to present themselves at RSA, they were a bit obnoxious last year too.  There were certainly worse vendors there, but it really annoys me when good companies do bad things.  The usual fear and hype mongers are somehow easier to ignore than people tarnishing their own otherwise good image.

And yes, we are still dealing with the “booth babe” phenomenon, and NetOptics was far from the only vendor guilty of this.  I have an answer to this, but it will have to wait for Las Vegas.  It involves fishnets, short shorts, and probably eye bleach.  You’ve been warned.

Finally, thank you very much to my fellow members of the Security Bloggers Network for voting this the most entertaining security blog of the year.  It may just guilt me into writing more.  But don’t hold your breath.  (I do have a backlog of posts to write for my drunken con, er, travel blog).

Jack

Read this…

You know those posts where I just phone it in and suggest you go read something?  This is one of those.  Take a few minutes and head over to the Idoneous Security Blog and read Insecure at any speed, it is a great post from someone who kows what she’s talking about.  You’ll probably want to read the rest of what you find over there, too.

Now, back to digesting the Trustwave report.  Where’s my coffee?

 

Jack

Speaking at RSA

I’ll be moderating a panel at RSA on Monday, Feb 27 between 12:30 and 1:40, session PROF-001.  The topic is a continuation of the work we have done in the past year on Stress and Burnout in the Information Security Community.  Although the ongoing “attitudes in infosec careers” survey covers a much broader range of topics than stress and burnout, some of the relevant data collected from that survey will be discussed in the panel.  A reminder: the Career Attitudes in InfoSec survey is open for another week, please see this blog post for details and I would appreciate it if you consider taking the survey.  And thanks to everyone who took the survey and helped to spread the word about it.

I’ll also be leading a peer-to-peer session on “What works in log analysis”.  The session is P2P-205C on Wednesday Feb. 29, from 2:10 to 3:00.  I really want this to be a peer-to-peer discussion and exchange of ideas, so if you are interested please come ready to share your thoughts and experiences.  We gather a lot of information in logs, but we don’t always gather the right information, or use it wisely.  The Verizon DBIRs show that log analysis hasn’t led to incident detection in the cases they have worked, but that over 60% of the time there was relevant information in the logs.  Does that mean we aren’t using the data properly (or at all)?  Or does that mean that the folks who do log management and analysis properly don’t end up having to call Verizon for incident response services?  Hmm.

The rest of the week you can find me at BSides San Francisco, wandering the floor and talks at RSA, at the Tenable booth at RSA, and of course, at the Tonga Room (and probably Jack’s Cannery Bar).

 

Jack

How much sharing is too much?

We always hear calls for more information sharing in InfoSec, but is it really needed or helpful?  What is the point of me telling you I was compromised by spear phishing, SQL injection, cross site scripting, cross site request forgery, default credentials, or anything else we’ve know about for years?  If you are ignoring all of the well-known risks, it is a waste of my time preparing the data and sharing it, and it is a waste of your time reading it.  This isn’t as disturbing as some of the oversharing we see on the internet, but it may be more distracting. 

Maybe you should just do what you already know needs to be done.  Don’t give me that look, you know exactly what I mean.  We need to talk about security sometimes, but more often we need to shut up and DO security.

On the other hand, if you are taking things seriously and are at least making a good faith effort- then knowing the specifics of what attacks are in the wild, who they are targeting, and details of the compromise timeline could be very valuable in prioritizing your defenses and focusing your monitoring.  The New School folks are much more eloquent in explaining the value of information sharing done properly, so I’ll refer you to them for more on that.

Oh, and if you do choose to share information, the more RAW DATA you share, the better.  Add context and color, share observations, theories, and maybe even a conclusion or two- but give us the data whenever possible.  And go easy on the images, a good infographic is a thing of beauty (probably because of their scarcity), but overthought and underdelivered graphics seem to be the norm. Don’t do that.

 

Jack

Put away the pitchforks…

It looks like all is well, or at least functional.  The folks at the RSA Conference are issuing waivers for RSA sponsors and exhibitors to participate in BSides San Francisco.  I’ve swapped messages with one of our friends at RSA- I do not know how things got as tense as they did as quickly as they did, but it seems that it has been resolved almost as quickly.

Let’s be honest, there will be tension in situations like this- the events are adjacent, occur on overlapping days, and people cannot be two places at once.  The RSA Conference is an enormous undertaking and the people who put it on are protective of their enterprise- and those of us in the BSides community are even more protective of our community.  BSiders are all volunteers, busy with jobs, modern life, and the challenges of running events on tight budgets- the folks at RSA are in their crunch time: thousands of attendees, hundreds of exhibitor companies, hundreds of speakers, and many others are bearing down on them, the pressures must be significant.  In light of that, it is easy to see how what should be a constructive conversation could end up being, well, not constructive.  But that is behind us.  (If you are reading this, you’ve seen the BSides perspective, here is RSA’s post on this)

There will be frustrations with each other again, but hopefully we can minimize those- I still see more mutual benefits than challenges, but the critical thing for now is that BSidesSF will happen as planned, and the sponsors of that event will not be placed in an uncomfortable position.  BSides organizers have worked, or at least communicated, with almost every “A-Side” event in recent times.  The relationships generally range from outstanding to at least understanding, and that is our goal.  (Note: There is one parallel event where things really are competitive… but I can’t even think about it now.  Some day I will have to send a peace dove over to them and see if they return it, or cook and eat it; that day is not today).

I’ve learned a little more about event management and conflict resolution this week.  In retrospect I should have picked up the phone and made a call or two to try to sort things out directly.

I do want to thank all of the sponsors of BSides San Francisco for working through this, and thank those who stepped in with sponsorship when things looked questionable.  Among those, Lee Kushner of InfoSec Leaders deserves special thanks for his significant moral and financial support of Security BSides San Francisco.

I am looking forward to both RSA and BSides later this month.  I’ll be speaking at RSA for the first time this year, and I am also leading a peer to peer session for the first time (more on that in another post).

For those who are surprised at my conciliatory tone, and disappointed by my lack of vitriol, I apologize- I just don’t see any value in dwelling on past frustrations in this case.

Thank you to everyone who showed their support for BSides, the event and the community.

 

Jack

Security BSides San Francisco, and RSA conference

I thought we were making progress last year, but I may have been mistaken.  The RSA Conference is enforcing the non-compete clause in their sponsor and exhibitor agreements, that means a written waiver is required for an RSA Conference sponsor/exhibitor to hold or participate in anything RSAC feels is “competing” within five miles of the RSA Conference (their definition of “competing” is pretty broad, too).  Last year they issued waivers for BSidesSF sponsors, but so far this year they are refusing to issue waivers.  For more details on this situation, please see this post at Infosec Island.

It would be great if you politely let RSA know that supporting the community is not a bad thing.  They really don’t need to feel challenged by a free event drawing a few hundred people next to their commercial event drawing well over 10,000.  Don’t go flaming @RSAConference on Twitter or anything like that, but if you are a sponsor/exhibitor, speaker, or attendee- maybe take a minute and let them know how you feel.

I will be speaking at RSA this year, partly because one of the comments we heard last year was that many BSides speakers don’t even submit to RSAC.  That seems unlikely to happen again if I have misunderstood RSA’s true attitude towards BSides.

Oh, and if you happen to know anyone who is not exhibiting at RSA who might be interested in sponsoring BSidesSF- you know where to send them.

Thanks

Jack

Bumper Sticker “wisdom”

I saw a bumper sticker the other day that made me think about the trite things often said in InfoSec.  The bumper sticker said (paraphrasing):

“War never solved anything, except ending communism, fascism, nazism, and slavery”

While somewhat nonsensical, I’m sure a lot of folks cheer the sentiment.  I really wasn’t in the mood to interrupt my vacation to discuss the state of global communism, the fall (and pending rise) of Russia; China, its sphere of influence, and the economic power wielded there.  Nor did I wish to engage on fascism’s passing due to natural causes when Franco died a comfortable old man.  I’ll give him the nazism thing, but given the number of people enslaved globally that is far from “ended”.

My point is not about the politics of war, but about the temptation to buy into things which “sound right” and make you feel good.  Things are rarely that simple.  Let’s consider anti-virus, the Schrödinger's cat of InfoSec (reported to be both dead and alive, and we don’t know for sure until we open the malware).  The truth is that it is alive, but sickly; hairballs everywhere in spite of special diet of CPU and RAM.

If the answers were bumper-sticker-easy, InfoSec wouldn’t be fun.  Of course, some days (especially post-vacation Mondays) I would settle for less “fun”.

 

Jack

InfoSec career attitudes survey

I have a favor to ask- please consider taking a survey on attitudes about your career in Information Security.  I’m helping a group of smart folks look into what makes InfoSec folks tick, and what makes us twitch.
This survey is mostly focused on your current situation, and this specific survey was selected because it is a standard measurement recognized by folks who study such things; this means aggregated results can be used for comparison with other professions (where there is survey data available) and averages.
The survey is copyrighted, and has some license restrictions imposed on anyone who uses it, the most notable is that unique logins are required for anyone taking the survey.  This means we need you to send a request to take the survey, and provide us an email address under your control so we can reply with a link to the survey, and enter the address in permitted users list.  We do not care what email address you use, so feel free to use an anonymous account from any of the freebies like Gmail, Hotmail/Live, etc.  The survey site requires a username, we are using the email address you provide as the username- again, we’re happy with anonymized addresses.  If you request to take the survey we do ask that you follow through and take it, each email address we enter counts as a licensed survey, whether completed or not and we pay per license to administer the survey.
We are going to give a $100 Amazon gift card to a randomly selected survey respondent as an incentive, if you are interested in that and use a “disposable” email address you may want to keep the account until early March when the winner is notified.

What to expect:

The first step is to request access to the survey and provide consent to participate (see below).  We will send a survey link to each person requesting to participate.
At the survey site enter the email address used for the request, create a password to complete account setup, then continue to the survey.
The survey starts ten demographic questions, these will help categorize results, and discover patterns- but they are optional, if you wish to skip any, please do.
The survey itself has a sample question and sixteen real questions, all multiple choice.
Expect to spend ten to fifteen minutes total on the registration and survey. Unless you obsess over stuff, like I often do- but even then it shouldn’t take much more than fifteen minutes.

The privacy and confidentiality bits:
The survey data is downloaded with email addresses included, they will be stripped from the data immediately.  We will keep two files, one with email addresses only (for notifying the winner of the gift card), the other with raw data (demographic data and survey results).  When the current project is complete and winner notified, all email addresses will be deleted from files and email system used for the survey, and we will request the data be purged from the survey administration site.  Anonymized results will be analyzed, and the results presented at appropriate venues, but raw data and email address files will always be encrypted when retrieved from the survey host, both file-level and full-disk encryption, using two different encryption applications.
There is more info on the survey website.  If you would like to participate, please submit the Contact form on the survey site, or send an email to info@careerstudy.org consenting to participate and we will reply with a link to the survey.
I know you have a lot of demands on your time, I would be grateful if you would consider participating in this survey and sharing ten to fifteen minutes to help our research.
[EDIT] I missed two things in the initial post:
1) We will share aggregate results in a couple of ways, I'll post some here, other members of the team will post some, and we will present at a variety of events.  I'll try to list upcoming presentations as I become aware of them.
 2) The careerstudy.org site is Flash (yeah, I know, it was free with the domain).  If Flash is not an option for you, just send an email to info@careerstudy.org to give consent and request access- we will reply with a survey link.

Thanks
Jack