New life for dead Tempe network? Another firm has expressed interest in buying the pennies on the dollar assets that remain of the former Kite Networks installation in Tempe from the firm that financed the venture as long as they can negotiate a new, more favorable deal with the city for mounting and removal rights. CTC, Inc., which the East Valley Tribune reports runs networks in the Kansas City, Mo., area, thinks there's an opportunity. The article notes that reception problems were due in part to the prevalence of stucco in Tempe, common in the southwest. Stucco walls layer plaster or other materials on a wire mesh for strength that turns a house into a bit of an accidental Faraday cage, partially shielding the home from electromagnetic radiation. (Could I go so far to say that Tempe's network could be a phoenix? Ouch.)

Wake up, you darn computer: Intel's new Remote Wake motherboards won't work with Wi-Fi, it's important to note. The feature, announced today, will let an incoming VoIP call (the articles all say "phone call over the Internet") to wake a computer, as long as the call comes from a particular source. Of course, the standard SIP protocol for VoIP doesn't have the kind of security and integrity that would allow this; Intel has to overcome the problem with network address translation that renders most computer unreachable from outside the local network without a separate service like GoToMyPC or LogMeIn; and it will only work for computers connected via Ethernet to a local network, because Wi-Fi is off when a computer sleeps, while Ethernet can remain lightly active. I don't have the protocol details yet, but there's long been a Wake on LAN protocol that required support in a router, operating system, and Ethernet card; Intel may be leveraging this.

1. First, a bunch of security blogs (actually, the amount did SHRINK a bit compared to before - security blogosphere is too darn noisy and the signal/noise ratio is dropping thru the floor ...): here is the link
2. Travel blogs: here
3. A few blogs on presenting and writing (and blogging): here
4. A few career blogs: here
5. Miscellaneous fun blogs: warfare, psywar, influence, etc
6. Some VC, product management and general business blogs: here

In any case, hope it was useful!

1. Misspell both HIPAA and SOX (how the f does one misspell SOX?)
2. Confuse "risks" and "threats"
3. Think that "Trojan is a vulnerability" AND "DoS is a vulnerability"
   
4. Quote "Insiders are 80%" without thinking for one darn second
5. Think that a loss of "$20 million is catastrophic to any company"
6. Talk about "NIST compliance"
   

Somebody asked me: "That's great that you have such a clear  vision of a future log management technology - but tell me first what future business problems will such 'ideal tool of the future' solve?"

First, I laughed and said: "Dude, look around, will ya? :-) There are plenty of log-related problems today which we are not even close to solving. We need to solve the problems of today first, before we can get to solving the future problems..."

So, what I consider to be the biggest log-related problems of today?

1. Not knowing what to log - whether  for compliance, tracking attackers or troubleshooting system problems. Remember all the comedy about "Tell me EXACTLY what to log for PCI?" If not, reread it!
2. Log volume  - there is too darn many log messages (seriously, 100,000 each second is a lot of log - but there is more at large companies!), and, which is worse, a lot of them are of unknown value to the users (might be useful, might not - but you never know in advance); thus, log clutter networks, systems and brains of security/system analysts.
3. Log diversity - logs all look different (at least while standards are being developed) and no single person have the skill set to understand  more than a few types. PIX admin groking SAP logs? No way!
4. In light of the above, just pure bad logs are also a major challenge - logs that miss a key piece of info (like the infamous "login failed" without the username...) or are useless in some other way are sadly common.
5. How about getting the logs from all the nooks and crannies where they are stuck  (think application logs here) - it is a problem if you want to achieve  (expand, rather) your operational awareness of applications.
6. Finally (not really, the list can go on and on), making sense of logs in  an automated fashion is still a #1 challenge  (IMHO) - we are getting better creating tools for humans to go thru logs (via reports and search), but log->conclusion process still requires a human, and a darn smart one.

Now, when you read the above think "end user", not "log management  vendor" challenges (I plan to post about these later). My idea of an ideal tool will seek to solve these and others.

Along the same line, this picture from 4th SANS Log Management Survey shows how people perceive the logging challenges:

as well as my logging challenges poll (analysis here):

Now, let's think of logging problems of the near future, say in 2 years.

But you'd have to wait for the next post for this :-)

Call me easily impressible, call me naive, darn, call me "out of touch with current security issues," but this book struck a major, major chord with me. It really did.

Now, I have experienced as much poor quality and insecure software as the next guy. I am never ever surprised about some feature in MS Office (or other application, really) just flat out not working or not working as expected or not working every time.

I suspect that, by now, every human on Earth who ever laid their hands on a computer knows:

software = might NOT work.

Now, we expect roads, bridges, toasters, chainsaws, bicycles, cars (until they put software in them...) to work and work they do. And if they don't - the company who manufactures them usually makes them work for us fast - or goes away, cut down by the "benevolent" axe of capitalism. Now, software is totally different (my thinking about this one).

And everybody knows it. But nobody was brave enough to take a hard look at this and analyze how that simple fact affected, affects and will affect our society. And, for my extra-paranoid readers: "... and how it might end that very society."

Until "Geekonomics!"

This book might not reveal any secrets about how software works to an IT professional (it will reveal how law works though!), but it will explain why bad software is everywhere, why we are stuck with it, why it will not improve by itself and - sorry for a hysterical note here! - how we might all fucking die because of it. It then unemotionally predicts why more people will certainly die because of bad software. It studies the complicated dynamics of today's software market such as who is more at fault for bad software - buyers who agree to buy or vendors who make it (or both). It also suggests that many of today's regulations and compliance "thingies" are a little misguided (e.g. in a battle a PCI DSS-compliant enterprise and a 0-day-wielding hacker, any sane person will bet on an 0-day). It is also very well-written; it won't bore an experienced IT  or security pro and it will not overwhelm a mere IT user.

First, it explains why the software is the "foundation of our civilization" today, and how it will be more so in the future. Next, it casts a look at "innovation" and ponders how innovation-driven software development relates to the  fact that users don't touch 90% of features of a typical software. In the third chapter is presents the view of the "0wned world" where "only the stupid [cybercriminals] get caught."  Next chapters looks at how government oversight works in other areas (e.g. FDA), how it might work - and how it might fail (and did fail in the past). While doing it, the book dispels the "government will just  make it worse" myth (basically, because some things are really bad and quickly streaming towards worse already). The amazing chapter 5 gives the clearest explanation of litigation (torts, etc) that I have ever seen (the book is worth reading just for chapter 5 alone!). Chapter 6 takes a super-pessimistic look at open-source software (no comment - just read it). Finally, several possible future - "the way forward" - is discussed.

Another thing I would like to mention about this book is that a reader should keep in mind that it is not about "insecure" software: it is about bad quality, unsafe software in general and less about "hackable" software. The author chose to not make this distinction very clear, perhaps on purpose.

So, everybody in software business, security business - in fact, just everybody who uses a computer - MUST READ THIS BOOK! Seriously, understanding the point made there might be a matter of life or death for some (all?) of us.

As a conclusion, if you want the visual image of the future to end my review, here it is: it is not "Terminator" future (where machines kill people out of evil) that we must fear and work to prevent, but "Robocop" future (where they do due to software bugs).

Go read the darn book!  And support liability for software manufactures. Also, in a few days, check this out (not yet but hover over the link to get a preview...)

So my next iteration of fun reading on security, logging and other topics.

• Security and fraud: different worlds, same people?  To me this story was pretty shocking; now I guess I should accept that for some people security business is just another scam.
• ROI Again? The paper goes like "Darn the terms and definitions, it is a good thing." But what "it" is? If you never define it, how can one claim that it is a good thing? Amrit then comes and drop kicks it. Thanks buddy, what "a paradigm shit"!
• A really good read (and I mean it!) about security evolution comes from Gunnar. Check the table he has and weep, really weep.
• "Fifty years of DARPA: Hits, misses and ones to watch" (past history) and "Fifty years of DARPA: Hits, misses and ones to watch, part II"  (current project to watch) - extreme fun!
• An [ex-] TJX employee explains that TJX security is still horribly broken, yes, even after the breach and all the hoopla.
• Finally, one intelligent comment about Google "Indiagate" (warning: Slashdot link). This story reminds us that Internet + different countries, culture, laws =  big problem that will only grow bigger.
• Third Annual Movie-Plot Threat Contest ends (winner, finalists, all entries)
• Read "State of Affairs" from RSnake, then "the nature of things" from Jeremiah, then  "grossman and rsnake lay eggs" from LonerVamp. Welcome to the world where everybody is 0wned and nobody is talking! Think a little. Stop when you get to "... so it sounds like a good idea to be a blackhat today. should I switch sides?"
• Along the same line, Emergent Chaos on Blackhat Tax. Will it finally make security "a cost of doing business"? When I read stuff like I pray that a set of useful security metrics will be sent to us by the gods.
• Can security be "built-in" and "transparent to users?" Sorry, but no; read this, this and this.  Security is about humans, not bad OSs and weak network protocols.
• Interesting discussion on ISO2700x and ISO17799, sparked by my blog post. So, why not ISO? People seem to insist on doing compliance regulation by regulation despite all the known inefficiencies of it...
• Finally, Richard Bejtlich's gem - no, GEM: "Security": Whose Responsibility?" Read it NOW! BTW, C-I-A is dead.

Enough for now!

I admit that in the past I poked jokes at DLP for being "ADLP", with "A" standing for "accidental." Indeed, most of the technology approaches I've seen were "good enough" for preventing accidental leaks (e.g. Excel sheet with SSNs being emailed to an external party by mistake)  and for preventing truly idiotic "insider" attacks of the same nature. Whether they sniffed or used desktop agents, the tools were good enough to do the above, but not much more (or, they allowed you to do more, but via a truly ginormous effort by your security team). And then a retarded kindergarten kid can bypass them in his sleep without working up a sweat ...

In other words, DLP was for keeping honest (but sloppy) people honest and keeping idiots idiotic (but a bit safer). Which is, don't get me wrong, pretty darn useful: after all, overall, employee mistakes still cause more damage than hackers (!)

However, whenever I heard about DLP, I always felt some deeper longing for more - maybe for a technology that CAN actually stop some, clearly defined classes of malicious data theft, perpetrated by non-idiots.

What such technology might be? Well, IMHO,  it should have three things:

1. Easy on the end user (=information owner) - thus no manual information tagging needed (don't you know, its dead!)
2. Easy on the tool operator (=security team) - thus no super-granular policy-writing  needed (and please - spare me the regexes!)
3. Effective enough to stop malicious insider of reasonable skill  over specific information channels- thus, some new technology for accurate detection of possibly modified documents across channels (e.g. common network)

Tough to match? Yup, it sure it. But that's not all: I'd like it to defend against theft of  structured, unstructured and structured->unstructured (e.g. database contents pasted to email!) information over just about any network channel (not device theft and not USB/portal device download - these are a different story).  What's more, I think that to enable #3 above the DLP "box" needs to actually understand what the document is about and to do it in a human-like fashion (Yes, including rephrased (!) content. Yes, I am picky :-)).

The above clearly does NOT mean that the technology is  not bypassable - there is always an encrypted zip file and gpg, custom encrypted network protocols, or even a screenshot emailed, etc (not even going to device theft, USB xfers or camera phone + screenshot + MMS). It just means that it takes DLP a few big notches up from "anti-retard defense"  to blocking a malicious and dedicated non-IT employee from stealing the crown jewels.

And, if one is trying to be honest about DLP, he need to define what is out of scope (after all, only narrowly defined problems are actually solvable in this space, not "our MagicBox  6.1 will block ALL data theft," which is absurd - if you believe that, you need your head examined).

I was pretty shocked to learn that something like this actually exists today: the next wave of DLP start-ups is about to emerge. For example, NexTierNetworks can detect information traces even in modified and heavily edited documents (I would like to try rephrasing as well; I suspect it will work!). When I saw a demo I was pretty impressed that you can get a financial document, change a few things here and there, paste it to email - and the system will still stop it by saying "uh-uh, this is sensitive info, no can do" :-) Mind you, this is not what current DLP vendors call "fingerprinting," since it actually uses what the document is about i.e. works on a - hate the word! - semantic or meaning level. So, DLP + a bit of NLP (the other NLP) = magic :-)

As a disclosure, I have to say that I just joined their Advisory Board, but, as you can guess, I joined because I am impressed (not "impressed because I joined!" :-))