Posted: 03 Aug 2008 06:38 AM CDT
I thought I'd share some more product demo lessons learned as a follow up to my other two posts Product Bistro: Mitchell's Rules of Demos and Product Bistro: Demo In 5 Clicks Or Less. Doing demos well isn't easy and there's a lot that goes into doing product demos properly. I hope sharing these ideas help you in your quest to help customers.
Use recorded demos. Want to avoid the demo gremlins? Want to be able to give a demo without scheduling an SE or the demo system? Want a good scenario-based demo rather than a trip down the product functionality bunny trail? Want good demo data for your demo? Want all your sales people to give the same, consistent demo, emphasizing the proper messaging and value points? Use a recorded demo. It's that easy and it works.
I've helped create Flash demos (see this example) using voice overs for the presentation, and also recorded less formal demos, using products like Camtasia Studio and a PC headset microphone (See this Xobni example). They work very effectively and sales people love 'em. Send the customer a link and they've got a demo. No SE, no scheduling, no bad demos (if the recorded demo is appropriately done), and much, much less risk of technical glitches. After using the recorded demo, follow up with an onsite or web demo to answer specific questions not covered in the standard demo... but only when necessary. A recorded demo is probably all that's needed in many situations. And giving a customer login credentials isn't the equivalent of a recorded demo. They are just as likely to have problems or struggle finding what they are looking for, so I'd recommend not giving customers their own demo login.
I can't say enough how effective and useful recorded demos can be. They can also significantly shortening the sales cycle, and free up SEs to handle more complex or specific customer issues, rather than presenting general product demos in every customer situation. They are definitely easy to create so I'd look into it if you don't already have a recorded demo.
Use a self contained demo. If anything can go wrong in a demo, it will -- so, if you are going to give a live demo, leave as little to chance as possible. The less outside factors you have to rely on, the better. Do you need to use the customer's Internet connection? Then bring your own cables (two, one for backup) and a broadband wireless card in case you fight with the customer's proxy, firewall, or VPN connections through their network. If all else fails, have a demo slide deck you can use in case you can't connect, the server's down, your laptop decides to croak, something's messed up on the demo system, or things aren't going well and you need to retrench.
"Boy Scout" Rule of Demos - Be prepared. Bring your own projector. Invest in one of the compact projectors you can take on the plane. I can't tell you how many times I've walked into a customer's conference room only to find some ancient projector that's the size of a trombone case, has really bad faded color, or one that my laptop just won't sync up with correctly. Now you spend all your time and focus acting the part of the high school AV guy trying to make some projector work, when you should be focusing on other things. Plus, everyone else in the room is distracted instead of listen to what you have to say.
If you are using a web conferencing service to deliver your demo, use your's, not the service the customer sets up. If you are presenting or giving a demo, you set it up. And make sure you use a reliable conferencing service, not one that's going to cause issues getting the meeting started. Switch to a different service if you do have issues until you find one you like and works reliably.
Lastly, carry what I call my "Swiss army knife cable kit". I have two very small portable hard drive travel cases I carry in my backpack that have just about every cable and connector combination you can think of in it. It's light weight, doesn't take much room, and now I'm prepared for just about anything short of using a flashlight to do a shadow puppet demo. (Oops. Better add a flashlight.) Just make sure you take all your equipment and cables with you when you pack up and leave.
How do you get to Carnegie Hall? Practice, practice, practice. Same for demos. Make the demo the smoothest and easiest part of your customer meetings by knowing the demo cold. Know what works, and where there are pitfalls or dead ends. Know your product front to back. Anticipate how you'll answer questions, whether it's worth the time to traverse to the place in the product that answers the question or if you'll just tell them verbally. And most importantly, be at your best by literally talking through your demo from beginning to end, working through the rough patches where you stumble your words, repeat yourself or forget those salient value points you want to make sure come across.
There's a reason why there are mirrors in hotel rooms and its not only for adjusting your tie or fixing your hair. Stand up when you give a demo so you have better command of the room and visibility of your audience (and visa versa.) And practice standing up, just like you will when giving your demo in person. Instead of watching reruns of Myth Busters in your hotel room, practice your demo for the upcoming customer meeting.
Don't bag dive. Have you ever seen a situation like this happen? "Hello Customer. Thanks for having us in. Okay, I think the best thing to do is start off by showing you our product..." That's called bag diving. Demos and product literature are the security blanket of selling. When unsure or uncomfortable, people love to bag dive, missing all the up front dialogue to set the stage for the meeting. I don't want to waste a prospects time until I know how I can laser in on helping them, and I now know to communicate that to the customer. Before you start anything else, set the context and objective of the meeting, reconfirm needs and problems, understand who's in the audience and why, etc. (I talk about this a lot more in my other two posts about demos.) So don't go for the security blanket and bag dive right into the demo. Set yourself up for success and leave the bag diving to the competition.
The importance of good demo data. Bad demo data can quickly derail a great customer meeting, making you and your product look embarrassing. If the data isn't relevant to the scenarios your talking through, or is too fake, you are just creating another obstacle the audience must work through to get to that place where they "get" how you solve their problem.
Use data that's presentable to the customer. I can't tell you how many demos I've been in where I cringed because the demo system had embarrassing or questionable data in it, causing a "note to self" to fix the demo data right after the meeting. Software developers are famous for taking license by using questionable or unprofessional looking data in their test systems. They're just having fun and don't think that anyone outside their team would ever see the demo data. Invariably someday they are asked to show software that's under development, or the test data spills over into the demo data. Again, if it can happen, it probably will.
A demo account called "moron customer" probably isn't going to show you or your product in a positive or professional light. Even an account called "developer account" (unless your product is a development tool) might scream to the customer "this software isn't baked yet, it's still under development". You don't want the demo data detracting from the real purpose you are showing a potential customer your product.
Scripts that feed in data or reset data nightly can be a blessing and a curse. Some products need ongoing data pumped into them to show how the product works (take a security monitoring system for example.) Scripts also help bring the demo system back to a known state every night, taking out any changes someone might have made while giving a demo. You often also have to use scripts to change dates in the data (so it stays relevant). But as always seems to happen, scripts break, they don't run, or something gets whacked when the demo system is upgraded. Put your demo system under change control, so everyone knows when it's unavailable, and what changes are being made. Test the demo system after every upgrade -- It is a production system, not a develop box. And log into the demo system right before every demo to make sure everything's up and running. Double check the expected data's in the system. No sense in taking any chances.
Stop selling when the customer is sold. You can undo a lot of really hard work by over selling in a demo. If you had the customer at the login screen, then stop demoing and close the sale. We all know you're really proud of the latest doodad feature that was just added to the product but that doesn't mean everyone's got to see it. Look for the "you had me at hello" signal from the customer, make sure you've covered all the needs and questions you've identified, and wrap things up. It'll save you from a lot of bruised shins, and your sales person's commission check will thank you for it.
Who owns the demo system? Ah, just who owns the demo system? The SEs? The SE manager? Marketing? Development? IT? Far too often nobody really owns the demo system, but a bunch of people work on it. I've come to the conclusion that whoever is creating the messaging, value points and demo script for product demos owns the demo system. This might be a product manager, someone in marketing, or a variety of other roles. But the bottom line is one person should own it. Support may come many other technical resources but make sure you have a clear owner. And that person or group is also responsible for training the rest of the organization on giving demos.
One last point about the demo system. Your product release cycle needs to include the creation and updating of demo data, to appropriately demonstrate new capabilities, and it needs to include upgrading the demo system software and scripts. It should be scheduled as part of the product release process, just like collateral, training, and PR.
The best demo may be the one you never give. Believe it or not but you don't necessarily need to give a demo in order to sell your product. I've seen it happen many times. The customer has a serious enough need, customer references are very strong, the match of customer needs and your capabilities are spot on, an employee from a previous company that used your product acts as a testimonial, product reviews or analysts reports speak volumes about the greatness of your product... those are all good cases where you may not need to demo your product. So keep that in mind. You can seriously shorten the sales cycle when you can make the case for the customer to buy your product without having to do a product demo.
Posted: 02 Aug 2008 10:44 PM CDT
My Grandmother always told me that a lucky person can count the really good friends they have on one hand, but a small amount of good friends far outweigh having many acquaintances. That was proven to me once again this weekend. Ever since before I had my 2 sons, I had dreams of taking my children to both a Pittsburgh Steeler game and a NY Yankee game. Last year I had a chance to take Landon and Bradley to Pittsburgh and see a Steeler game. With this being the last year for the old Yankee Stadium, I wanted to take the boys to see the Yankees at home and in the old stadium.
Getting tickets to a game at Yankee Stadium is not cheap. In looking around StubHub, for a hundred bucks a ticket (which is all I was willing to pay), the best I was going to do was out in the bleachers somewhere. But I figured it was better than nothing and was going to go for it. That was when I called my best buddy from college Tyler to see if he wanted to go with us. Tyler still lives in NY, actually he has an apt in Trump Palace and works in advertising for a large company, handling a one of the very biggest accounts. When I told him what I was looking at buying he said to hold on and let him see what he can could do.
Well Tyler came through big time. Not sure which vendor he got them from, but we had 6th row box seats behind third base, tickets to the Stadium Club, free parking (didn't use it as we took the subway) and to top it off, Tyler was staying at his friends place and insisted we stay in his place at Trump.
The boys and I had a blast hanging out in the city, going to Dylan's candy store, the Empire State Building and then heading up to the Stadium. I am sure it will be a time both they and I will never forget. Like the commercial says:
1. 3 round trip airline tickets from Florida to NY – $750.00
2. 1 night in a hotel in NYC - $400.00
3. 3 field box seats to a Yankee game - $1000.00
4. A fried like Tyler to make it all happen for free (I used miles for the airfare) and give the kids this kind of memory– PRICELESS!
Posted: 02 Aug 2008 03:15 PM CDT
So here we are with the third installment of security questions for Cisco Systems’ IPICS Expert, questions 11-15. Astute readers (and pesky English majors) will notice that the title is not possessive concerning Cisco Systems’ — tsk, tsk, I had to do this so links in email readers would work and so the title would display correctly in various Web browsers. I suppose I could have gone the Dan York route and added Tiny-URL stuff…perhaps for another post. But, IMHO, Tiny-URL’s are spooky — you never know where they’re going to take you
So, it’s been a couple of weeks now and I’ve still not heard any answers from the IPICS Expert on either of the two previous posts: Asking The Cisco Systems IPICS Expert: Questions 1-5 and Asking The Cisco Systems IPICS Expert: Questions 6-10.
Further, the IPICS Expert email address (firstname.lastname@example.org) still bounces…sigh. A little more promising, however, is some nice people from the Naval Postgraduate School I’ve been chatting with forwarded my questions to three or four people in Cisco’s Tactical Operations group last week, so we’ll see what happens. I’m hoping that these new players can move this process forward. If not, at the very least these questions will be out there drifting through the series of tubes on the Interwebs; for whatever that’s worth.
With IPICS Server V1.X, the documentation states that the INFORMIX user password cannot be changed “… do not change the informix password unless you are prompted to do so by the Cisco IPICS installation or upgrade procedure.” This seems to be a limitation, especially in organizations with password change policies (30/60/90 days, etc.). Has this issue been addressed in IPICS Server V2.0, or does changing the INFORMIX user password render the database unusable?
Concerning the IPICS ability to limit the re-use of all IPICS Server users’ previous passwords (default is previous 5), documentation on IPICS Server V2.X indicates that this password limitation does not apply to either the IPICSADMIN or IPICS user accounts. To not enforce this policy across all user accounts on the IPICS Server, especially those which are arguably “superuser” accounts, seems quite odd. Please state the justification for this selective application of password re-use limitation that excluded superuser accounts.
Cisco Systems has a history of leaving in undocumented hardcoded, “backdoor” and debugging accounts (username/passwords) in several products over the years. Can you please state here, without any question or uncertainty, that all versions of the the IPICS Server do not contain any hardcoded, backdoor or debugging accounts that are undocumented?
IPICS Server V2.X documentation indicates that for the IPICSADMIN and IPICS accounts there is neither a maximum number of invalid login attempts threshold, nor a definable lockout period (e.g. 4 hours) after a specified number of invalid login attempts. Considering that these two accounts are “superuser” level and likely targets of remote brute-force login attempts by attackers, is there any active notification such as pop-up alert, email/page alert, etc. to inform the IPICS Server administrator of such bruteforce login attempts? It seems that the only way an IPICS Server administrator would know she is under a bruteforce attack is to manually review attempted logins in the IPICS Server logs; is this correct?
During security audits and testing, customers will often use the Nessus Security Scanner to determine the vulnerabilities, if any, of their system. A common issue with Nessus scans are “false positives” during checks. What, if any, false positives can a Nessus scan of the IPICS Server 2.X can a Cisco customer expect? Please include the various scan options (default, polite, sneaky, paranoid, etc.), plugin sets (default, registered, professional, etc.), and especially host-based scans. I suggest providing the nessus.rc files and NBE-format results as well to prove verification.
As with my previous ten (as yet unanswered) questions, I thank you and look forward to your answers.
Posted: 02 Aug 2008 03:07 PM CDT
Posted: 02 Aug 2008 01:02 PM CDT
Live from the PaulDotCom studios!
Posted: 02 Aug 2008 11:21 AM CDT
[First, and foremost, this is my 100th post... so I'm very excited to be here...]
Gary McKinnon is the United States' public enemy #1 these days. No doubt you've read about him in the papers, or somewhere online. The short story is this... from February 2001 thru March 2002 Gary McKinnon penetrated something like 80+ military systems, and 16 NASA computers leaving messages, taking information and allegedly shutting down a Washington-based military net for 24hrs. Given all he's done, you'd figure there would of course be a criminal case and he'd get 5, maybe 10 years in prison and some fines right? You'd be very wrong.
Gary McKinnon is facing extradition from his native Britain and as much as 70 years in prison. Perhaps by now the terms "crueal and unusual" are creeping into your brain? Why in the world would a hacker (who hasn't done any "real damage" that's been demonstrated yet) get basically a life sentence [given that he's already in his 40's]?
The answer is quite simple ladies and gentlemen. Bruised egos. The United States government's networks are so poorly defended that they are penetrated all the time from China, internally from within the US, and now from British hackers seeking proof of the existence of little green men [erm... UFOs]. The Belfast Telegraph quotes an un-named source in the US government of saying he'd like to see Gary McKinnon "fry" for his crimes. Isn't that a little extreme? We've got states here in the US, Illinois being one of them, who have yet to pass proper child rape laws, and we're going to prosecute a "hacker" and have him "fry" for his crimes?
Obviously, if you haven't gotten all charged up about this yet, it's a clear case of over-zealous old men and women in the US legal system and government looking at things completely out of perspective. Instead of dealing out a fair punnishment (say... 12 months prison, 2 years probabtion, no computer/internet access) we're going to send him to jail for what will amount to the rest of his natural life? What a joke. The US legal system has truly hit rock-bottom, and I'm embarssed to say that I live in this country sometimes.
If we are to be the greatest country on earth, and set an example for the rest of the world- perhaps we could come up with punnishments that fit the crime. Kill/rape a child - you should "fry". Hack the government, you should get an appropriate punnishment and the government agency should be fired wholesale... and replaced with competent InfoSec and IT professionals.
It's a sad, sad day folks. I do like Gary's comment...
"I'm very angry," he says. "I genuinely believe that we are the 51st State. You see it everywhere you go, not just our foreign policy, but in our schools, our hospitals and now our courts. The British Government simply bends over backwards for America."
Posted: 02 Aug 2008 08:46 AM CDT
Very cool paper and demo over at MWR InfoSecurity on DHCP Script Injection.
The paper covers attacking the pfsense admin interface and injecting script into the DHCP hostname field. Because the admin interface runs as root your code is executed as root. The demo also uses a CRSF attack to change the password but I think its far more interesting to be able to inject script into the interface and run with all the exploitation options available there. They also released the tool to do it.
Paper on the DHCP Script Injection
Posted: 01 Aug 2008 11:02 PM CDT
I finally got around to reading Seth Godin's book The Dip and I have to say, it's a two thumbs up read. It's actually a very challenging book to read. Not a hard or a long book, but a book that really challenges you. Seth's premise, and I agree, is that anything truly worth doing (to you) experiences an initial honeymoon period followed by the dip. The dip is where you have to slog it out to go from one of the many, to one of the few, the top few in what ever market, product, industry, personal talent, skill, job, etc. you are working to be the best at. When you experience the dip, you might quit because it's too hard, without examining whether you truly want what's on the other side, or if you shouldn't have gone down this path in the first place. We also waste too much time on dead end stuff, diversify or quit when what really achieves success is reaching the pinnacle of superstar, #1 or #2, where you now have something that's scarce rather than easy to acquire.
That's why this book is so challenging. I say to myself, yep, I quit that too soon, or, that was a dead end I should have quit. But I also see where grinding it out against the dip and really blasting through it has paid off in situations for me too. I can think of personal situations, products, ideas, companies, teams, talents... all that could apply to each of these scenarios.
Seth points out that you should either do what it takes to make it through the dip, or recognize that your interests or the resources aren't there to make it through the dip and quit. Quit the wrong stuff and focus on the right stuff. Both of those scenarios are good ones. You either succeed or you don't waste time at something you won't - again, both are good choices. It's just when you really aren't doing what it takes, or don't have the resources to reach the other side of the dip, when you're wasting your time.
I saw this multiple times in the security industry. Each year at RSA I would see new companies flame out, blowing money on a super nice booth and graphics, only never to be seen or heard of the next year. Others worked their way up, from the end rows of 10x10 booths for a few years, into the 10x20s, then 20x20s in years later, etc. They were slogging it out through the dip, with every resource they had or applying their resources more cautiously so as not to be one of the flame outs. Then there were others that assembled big war chests of money, who propelled themselves to #1 or #2 because they had a large enough war chest to sustain the push for multiple years, and the chops to eventually get the product right. These latter companies are usually the most difficult ones to catch. If you can pull far ahead enough of the pack, it's much more difficult for others to create the inertia and momentum to catch up.
So how does all this apply to me and you? Well for me, I've already talked about being able to relate to a number of the situations Seth talks about. I also feel like I'm at one of those dips right now, (I say that in a really positive way, btw.) The idea of taking products to market by combining the right product strategy, competitive differentiation, social media, and traditional marketing I feel is where the forefront of building great products and companies are at today.
I love what I do, combining product strategy, creating products, bizdev, writing, professional blogging, deeply understanding customers, seeing where technology is headed, and understanding how it plays into the changing media landscape. Evangelism for what I help create and believe in is what I love to do. But I also feel like there's a lot more to the story to get to the other side of the dip, and that's what excites me. It's a blast applying what I know, and an even bigger blast figuring it out. It's why I do what I do in strategy, evangelist and CTO type roles.
I think you would get a lot out of reading Seth's book. Your dip is probably much different than mine, but what Seth's book does is help you realize or confirm whether you're on the path you should be seeking. Or maybe it's time to change paths, so you will make it through the dip.
Posted: 01 Aug 2008 08:18 PM CDT
Posted: 01 Aug 2008 05:14 PM CDT
Posted: 01 Aug 2008 03:49 PM CDT
Posted: 01 Aug 2008 03:26 PM CDT
New worms that attack social networking sites Facebook and MySpace have been uncovered.
Net-Worm.Win32.Koobface.a. and Net-Worm.Win32.Koobface.b, attack MySpace and Facebook respectively, say security firm Kaspersky Lab, which found the threats.
The worms are designed to upload malicious modules with other functionality via the web. It's likely that they will turn target machines into zombie computers to form botnets.
More here. I haven't seen this in action yet, but the way it spreads (by simply accessing your account) is kind of intriguing, isn't it? Reminds me of some of the more advanced Myspace autospamming tools that the professional spammers have been toying with for a while.
Guess this is another reason to not bother opening up social networking websites for a while. Hopefully Myspace and Facebook will take action to sort this out quickly, but anything involving 2.0 and security usually means a lot of sitting on hands so who knows.
To be honest, I'm more worried by this:
Headlines such as "Paris Hilton Tosses Dwarf On The Street" and "Examiners Caught Downloading Grades From The Internet" are typically used to encourage users to click on a bogus video link that tells them to download a so-called new version Flash Player that is a disguise for codesetup.exe, which installs malware.
Infections that exploit social networking sites - and most other sites out there, come to think of it - will only begin to slowly die away when people are educated enough NOT to click on links proclaiming that Paris is now into hurling dwarves, exciting as that might sound. For now, it just gives more ammo to the "Click on something as stupid as that and you deserve" it argument.
Posted: 01 Aug 2008 02:48 PM CDT
When I was flipping through some RSS feeds and saw this fantastic post from Gizmodo, I HAD to bring it here for discussion. Now keep in mind, this is a photographer's artistic work, but it sure does open the door to other low tech ways to subvert security systems.
One of my personal favorites is the McGuyver style (sans chewing gum and dental floss) method of defeating magnetic lock doors with a balloon, tape, and a straw. Convenience says that we should not badge in AND out. Just on the way in is fine. On the way out, we'll put sensors there so that the door will magically unlock for you. It's the high tech version of the black treadmill mat looking thing at the grocery store that we kids always used to go jump on to make the door open.
And then came the footless shoe smacking me upside my head leaving me reeling, wondering how my mom can catch me getting in trouble when she is in the back of the store buying milk and beer.
After all, it is the breakfast of champions.
Anyway, with a little ingenuity (and some luck) we can get those heavy magnets to unlock from the outside of the door! No badge required!
What other kinds of hacks have you guys seen out there for defeating security systems?
Posted: 01 Aug 2008 07:48 AM CDT
I had a conversation on a private security mailing list yesterday about Apple not shipping the update to the DNS flaw yet. So I got a hold of Apple, and they told me it would be coming out very soon.
Well, I guess late last night they posted the update. Which, among other things, fixes a bunch of security flaws, including the DNS flaw.
Open Scripting Architecture
Data Detectors Engine
Remember that ARDagent vulnerability? Well it wasn't really a bug in how ARD works, it's a bug in how ARD calls the scripting agent. It's fixed in the above "Open Scripting Architecture" bug.
Subscribe in a reader
Posted: 01 Aug 2008 04:10 AM CDT
Alan reports the recent Reconnex acquisition by McAfee today. This started my head spinning off in all sorts of directions.
Compare and contrast the price which McAfee have paid for Reconnex with that which Symantec paid for Vontu. $46m as opposed to $350m. Websense bought PortAuthority for $80m. That's quite a big chunk of change in difference. Prices are coming right down, but the reality is, that's still a good price. Reconnex have been pretty lucky, considering the current financial climate. Maybe they don't care too much, as a small privately owned company, they will have all done well and be able to ride out the storm, and that's great for them. McAfee already have Onigma under their belt, so I hope Reconnex is a good complementary piece of kit for them.
My concern is where this leaves other DLP companies. I have worked and collaborated with Vericept and Orchestria, two other players in this space. Vericept and Vontu used to be the 2 big boys, but Vontu did some great targeted marketing, picked their key accounts, did all the right things, under-developed and over-promoted in the early days, then let the technology catch up as they rode the wave. That's the way to do it, and despite Vericept's complaints that they did it the "right way", i.e. had a solid product and spent less on marketing, that's not how the world works.
Orchestria is another product that falls foul of this effect. It is vast and comprehensive, a techies dream. Give it to a sysadmin and they will not come out of their cave for a month. However, it's not the sysadmin who buys DLP. I like Orchestria, it is far more than DLP, but it isn't productised and it isn't marketed enough.
Both of these stories are disappointing, not least because I know and like the people involved in these companies and they have worked hard, possibly harder than those in the other companies I've mentioned. If I had a few million dollars, I'd buy one of them, because although the prices for DLP companies are going to be much lower from now on, the market will stay and increase, especially for those technologies which ARE more than DLP.
There are a couple of acquirers left, but they are the ones who traditionally bide their time and watch the market - HP, IBM, etc. they don't pay big bucks for technology on the rise, they pay sensible bucks for established kit which they can add to a portfolio.
Posted: 01 Aug 2008 12:55 AM CDT
As system administration has matured and information technology has come along over the past decade or so we've learned many things which appear to go in one ear and then out the other. Most of these deal with secure systems design, and basically how to keep from making yourself an easy target for hackers.
With that glowing in the back of my mind like a energy-saving lightbulb I went on a hunt for things that should not be available on the web.
First off, I think I've had this debate with people so many times it hurt my brain - but administrative interfaces to applications, appliances, or widgets simply shouldn't be available to the general web-based casual viewer. Worse yet, it should definitely *not* be index-able with a search engine.
With that in mind, I decided to give Google a chance to see how many people still allow open, administrator pages on the 'net. Granted, sometimes you just can't help this, right... but if I can index your admin page, and your authentication mechanism isn't well-built... it's only a matter of time before I pwn you. Check it out for yourself, go to Google, and use this search term "inurl:"admin" intext:administrator login" and see what you get. Scarry, huh? How many of these systems that you find do you think you can grind away at until you guess a password via brute-force?
Common boys and girls... you should *not* put an admin interface on the general net, that's what we have VPNs for, and management networks. *sigh*.
Posted: 31 Jul 2008 08:20 PM CDT
Not that there hasn't been alot to write about recently, I've just been dealing alot with this DNS issue, so by the time I get home a night I'm tired, and don't want to blog. I have had lots of interesting ideas too, I just am so tired! Sorry about that, i'll get back on track shortly.
I am going to Defcon next week, so anyone that is going, I'll see you there!
Subscribe in a reader
Posted: 31 Jul 2008 08:00 PM CDT
Blackhat 2008 Fantasy League picks.
because I'm poor and my company is cheap i'm not making it to BH, but Wesley McGrew and I have decided to do our fantasy picks.
So here is the order I plan to pirate the BH videos in...
10:00 - 11:00 Nmap: Scanning the Internet
11:15 - 12:30 Dan's talk will probably be too crowded so... Jinx: Malware 2.0
13:45 - 15:00 dunno....
15:15 - 16:30 Malware Analysis
16:45 - 18:00 Metapost exploitation **anything by val smith will be good
10:00 - 11:00 Encoded, Layered and Transcoded Syntax Attacks: Threading the Needle Past Web Application Security
13:45 15:00 Hacking and Injecting Federal Trojans
15:15 - 16:30 Most likely Jeremiah Grossman's talk or continue with Hacking and Injecting Federal Trojans
16:45 - 18:00 Pushing the Camel Through the Eye of a Needle or Methods for Understanding Targeted Attacks with Office Document
Posted: 31 Jul 2008 03:15 PM CDT
Been busy but I still wanted to post something quick.
If you didn't know, F-Secure's yearly reverse engineering challenge, Khallenge, is about to start. It works by using levels - you download a binary, figure out how to reverse it and get the password to the next level. I've done it in years past and have gotten to the last level but not beyond. Maybe I'll try this year. It starts August 1, 2008 at midnight (EEST) which should be about 5PM July 31, 2008 EST. It lasts only two days so get out there and reversing! http://www.khallenge.com/
There are many excellent blogs out there which have alot of great information on reverse engineering and malware analysis. However, I want to call out one which I consistently find excellent information on new threats and how to perform malware analysys: The Websense Security Labs Blog.
I'll be the first to admit that when I think of Websense I think of content filtering and not malware analysis. (Actually I think of some poor fool who has to visit every site that gets submitted to categorize it.) However, they have some really smart people working for them who do alot of great malware analysis work. They constantly publish excellent blog entries about different aspects of malware. This is one of the blogs which I will ensure I read whenever they publish something new. Their RSS feed is here and I highly recommend it.
Anyone have any good resources they'd like to mention?
Posted: 31 Jul 2008 02:15 PM CDT
OK, yeah, that was a reach. As long as it makes me giggle, things will be just fine.
I assume most of you are away from your RSS readers this week because you are furiously patching your DNS servers. The attack is actually quite genius, and continues to demonstrate the inordinate amount of trust we place in servers and data that should not be trusted.
The details of how the attack works can be read in the above linked article if you are interested. You probably don't have the time right now because you are rushing to patch though.
Bruce Schneier takes this opportunity to lash out at the patching process. While some security pundits don't take Bruce seriously, he's got a point. The state he speaks about is a bit Utopian in nature, but the points are valid.
Can we get to a state where software is written with security baked in? Even if we can, would that prevent this or much more sophisticated attacks from occurring?
Electronic crime is a profitable business. As we cut off the money supply, they get more creative to recover their losses. My true fear is that they will get creative enough to create a vulnerability that goes undetected for some period of time, until a trigger point hits that causes mass chaos. If we're struggling to deal with relatively simple fixes today, what will we do when something like that hits?
Posted: 31 Jul 2008 01:19 PM CDT
Posted: 31 Jul 2008 12:50 PM CDT
The live stream should be active about 6:45 PM EDT, Thursday, July 31st. We should begin recording the live show at about 7:00 PM EDT. Please keep in mind that these times are all estimates, but we will try to do the best that we can.
Don't forget to join in on the IRC channel during the stream - we can take live comments and discussion from the channel! Find us on IRC at irc.freenode.net #pauldotcom.
When active, the live stream(s) can be found at:
Please join us, and thanks for listening!
- Larry & Paul
|You are subscribed to email updates from Black Hat Security Bloggers Network |
To stop receiving these emails, you may unsubscribe now.
|Email Delivery powered by FeedBurner|
|Inbox too full? Subscribe to the feed version of Black Hat Security Bloggers Network in a feed reader.|
|If you prefer to unsubscribe via postal mail, write to: Black Hat Security Bloggers Network, c/o FeedBurner, 20 W Kinzie, 9th Floor, Chicago IL USA 60610|