So can open source weather out the economic storm? Emerging from the dot-com bust, open source has matured, its legal framework and values are established, and serious players are in the game. But as this post on ZDNet points out, consolidation is on the way. “IDC renamed its LinuxWorld Show in San Francisco next year Open Source World – a clear shot across the bow at O’Reilly’s OSCON.” Will open source (from free to lower-cost alternatives to commercial software) flourish in a time of tightening budgets or will projects quietly go away for lack of funding (VC and that pesky business model thing) and, let’s face it, the “extra time” of IT pros tasked yet again to do more with less?

It’s October 2008 and Charles Babcock writes, “CA Embraces Virtualization As Future of Data Center Management”. Beyond keeping up with what competitors are doing, I enjoy this article for the masterful way it depicts the nightmare that is working with traditional frameworks. Too slow, too expensive, too complex, too many modules – it’s all in here. And somehow, I don’t think that was the point of it. So, $154,000 for CA Data Center Automation Manager – which can “consult” the CA CMDB (pricing starting at what do you think, something like $500K to a million – don’t forget those services) plus CA Wily APM (Introscope 8 and Wily Customer Experience Manager 4.2; pricing anyone?) metrics that get fed back into Data Center Automation Manager to help determine the virtual machine resources that are needed. Plus can also integrate info from CA Endeavor’s software change management tracking and CA SysView and in future with CA Management Suite for Mainframe Linux, potentially. I am not kidding about this list. And, we’ve been hearing this for a while – “Unicenter” the brand goes away and is replaced by “CA NSM”. The brand goes away. Why retire a successful brand? Ah.

I love this post on EMC, “Eleven Things You Didn’t Know About the World’s Largest External Disk Storage Company.” Although I guess I really don’t know much about Joe Tucci, since #11 says:

“Contrary to conventional thought, it is not true that the EMC President/CEO is the older, gentler brother of the fictional patriarch of HBO’s hit television series.” Hunh. I just googled him, thinking maybe it was a resemblance thing. Nope."

And on a much lighter note. A funny from Dell. 2 years later, I just stumbled across this Proprietaryville , Jibjab-ish video, called Dell the Journey. Legacy systems being escorted onto the Retirement Home bus. Michael Dell as knight in shining armor, singing no less. Joe Tucci and Larry Ellison showing up as heroes leading the charge against Proprietaryville (yes, funny in and of itself). And my favorite, “Now let’s go kick some proprietary apps.”

For example, Reconnex that was recently absorbed by McAfee, touts "information protection" before compliance. Similarly, my friends from nexTier only mention "compliance" on a few pages. Even newly unveiled DLP resource  (DLP In-Depth portal) only contains a little bit  of information on how DLP solutions help with various compliance projects. People tout "data protection", " data security", "data governance" (aka "we know big words - bigger than you") or even "data risk management" (aka "we are confused about what we sell")

I decide to explore this curious phenomenon.

Initially, I thought that it was reverse compliance at work? People not wanting to know what content packs up and leaves their network. Then I thought that maybe DLP vendors just aren't "the bandwagon jumping kind" (yeah, right!) Then I thought that they are "beyond compliance" already :-)

But you know what? I actually think that it is something different, much more sinister. It is the ominous checklist mentality (here too)!  You know, DLP is newer than  most regulations (PCI DSS, HIPAA, FISMA, etc) and - what a shock! - the documentation for these mandates just doesn't mention DLP (or CMF) by name. Sure, they talk about data protection (e.g. PCI DSS Requirements 3 and 4), but mostly in terms of encryption, access control, logging (of course!).

Also, PCI DSS directly and explicitly says "get a firewall", "deploy log management", "get scanned", "install and update AV" - but where is DLP? Ain't there...

Yes, Virginia, folks who "go by the book" and just "do the minimum" are missing out on the chance to procure DLP while their compliance budgets are still flowing. To me that means that many still don't get the "compliance+" model - buy for compliance -> use for security, operations, having fun, etc. Think what a good DLP solution  will do for you in discovering regulated data across the entire organization, blocking those pesky email with SSNs, PHI (hi, HIPAA) and CCs (hi, PCI) as well as solving plenty of other problems ...

Next, insert appropriate morbid jokes <here> for "IDS is dead", "NAC is dead", "GRC is dead", everybody is dead... WTF? Are we at the cemetery or what? Is "dead" dead? Yeah, but it came back as a zombie :-) So, "dead" is a "living dead" "dead" now. Ha*3.

Finally, think! Why were you thinking of buying a SIEM? 'Cause the big "G" in the sky said so? And while you are thinking, check these fun points out:

1. Does your SIEM require 17 beefy servers to operate? How many gallons of foreign oil have to go up in smoke to power that mammoth up? And you know what happened to mammoths, don't you?
2. If your "high-performance" SIEM appliance can only run 5 correlation rules at the same time, what "high" do they mean, really? Hold this thought....
3. Is five field engineers, two developers and CTO enough to install it? Who else needs to help? Ah, sorry, I missed the DBA :-)
4. Do you know when "If CustomVariable17 = Value5" condition matches? Will you still remember it in a year?
5. Can you tell "taxonomy" from "ontology"? You can now? Good for you. Are you more secure now? More efficient? Compliant?
6. How many shifts of security analysts do you have watching the shiny consoles 24/7? If zero, then why - oh - why those consoles are running in the first place? "If a tree falls..." - you know how this one ends. Correct! You get hit by the bough.
7. When was the last time you built a custom agent for parsing and normalizing, say, SAP logs? Did it work? What did you do after it didn't? Cried? And did it help? Then a burly vendor SE showed up, charged you $37,600 and left? Happy now?
8. Do you automatically correlate IDS/IPS alerts with vulnerability data ... for client-side attacks? Really? :-)
9. There are dozens of firewall, IDS/IPS, router, etc brands, each with its own log type. This is actually simple! But there are thousands upon thousands of applications in use today. Some have logs. All are different. Care to build rules for that? Now you finally know why SIEM vendors don't parse their own Java logs (no shit!)
10. Do you know what "threat x vulnerability x random()" equals to? Yup, it still equals random(). Automated prioritization, you say?
11. Do you know why some SIEM vendors are migrating to IT GRC now? So they can go and die there ... quietly.

All in all, I have to agree with Raffy to a large extent!  The world has evolved - and SIEM has not. It might not be dead (as old attacks and defenses never really die and large organization still build and man massive SOCs where SIEM is "a must"), but in this age of web application hacking, CSRF and XSS, phishing, PCI DSS, massive bot armies, client-side 0-days, stealth malware, etc, paying $x,000,000 for a pile of ugly Java code is insane ... As a result, SIEM has greatly diminished in importance and has become just one small thing you might do with logs and some other data. What made it so? Mostly implementation complexity - but a slew of other factors mentioned above as well.

So, consider this instead:

• Compliance? "Sorry, buddy, you need this for compliance, not that. "
• Want to simplify your incident response? Get log management and fly through all your logs, not crawl through some of them.
• Have a very real need to dig into your logs for troubleshooting or tracking that pesky user? Log management works.

Now, what if you have a latent and vague desire to "correlate something" and a million nice greenbacks to flush down the drain? OK, go get your SIEM toy for $780,000 + 20% maintenance/year ... a true bargain (price valid today only).

Finally, I would like to end this on an optimistic note. Do we need more intelligence to analyze the log data we have collected? Of course! Do we have a widest set of log use cases from today's security  to tomorrow's regulations? You bet. And, for you Raffy, I'd add "... we also have other data to analyze together with logs." So, can we "reinvent SIEM?" Yes, I think so! It just hasn't been done yet ... For now, just use log management.

Their competition, tantalizingly called a “digital combat exercise,” was supposed to give onlookers a rare opportunity to watch a computer hacking job in progress, complete with play-by-play.

It didn’t work out that way, though, thanks to — what else? — some sort of technical glitch that obstructed efforts to monitor what the competitors were doing. So for the few non-techie spectators who showed up, the business of hacking was still as opaque and mysterious at the end of the 1 1/2-hour exercise as it was in the beginning.

A technical glitch? They always happen at the worst possible time, don’t they? Read on.

The commentary was to come from Peter Stephenson, a member of the program’s faculty, who sat at his own terminal and displayed on a big screen something he called a “sniffer trace,” a multi-colored table with columns of numbers and letters — the first in what was to be a series of tableaus that held the promise of monitoring all the traffic on the network next door.

The minutes passed, and not much happened. The sniffer trace stayed the same, and from time to time, when Stephenson tried to check on what individual teams were up to, the screen went blank. Could it be that the hackers weren’t getting anywhere?

Someone decided to check on them in the old-fashioned way — paying a visit in person. The report came back that they were, in fact, getting somewhere — finding holes and vulnerabilities of various kinds.

You’d think that somebody on the faculty, or one of the grad students, or even somebody in the audience would have realized the problem. The story implies that they never did figure out what those pesky hackers were up to.

Minneapolis suffers the heartbreak of leafage: Leaves are popping in Minneapolis, and Star-Tribune columnist Steve Alexander writes that residents are seeing some Wi-Fi reception problems on that city's Wi-Fi network. This is the only big-city network that can be currently described "successful," even though its long-term success has to be proven out. The firm responsible, USI Wireless, told Alexander they're working on adjusting about 5 percent of antennas to cope with the pesky greenery.

St. Louis Park sues ARINC over Wi-Fi network: The Minnesota town says the network never worked, and had earlier discussed a lawsuit. The city wants the value of the contract ($1.7m) plus a very modest amount in damages and fees ($50,000). The city plans to start removing gear if ARINC doesn't sometime in June. But they have to deal with 490 poles erected to hold the nodes and solar-charging gear--sunk into concrete. More recent testing showed that the network worked well in some areas, but the majority of the network did not, according to the Star Tribune.

Verizon builds out fiber in AT&T territory: Interesting sign of competition in otherwise monopoly-per-provider-type world. Verizon is using AT&T's hard-won statewide video franchising rules in Texas to build competitive fiber in Dallas suburbs. They're apparently not bringing telecom; they're acting like a cable TV firm with data. Verizon owns chunks of territory all over due to it encompassing GTE in a deal years ago. GTE serves suburbs west of Portland, Ore., and east of Seattle, for instance, while Qwest serves most of the rest of each state.

Foster City Wi-Fi dies on June 20: MetroFi is unlighting its cities, and Foster City opted not to spend the nearly $200,000 asking price MetroFi put on its equipment. MetroFi might still find a buyer, but June 20 is the network's current final day. Naperville, Ill., also expects a June 20 shutdown. They, too, were offered the network hardware for 200 grand.

Chehalis lights up: A small city in southern Washington votes to put in Wi-Fi hotzones. The cost is about $53,000 and annual fees $15,000. Funds will come from existing tax and grant sources. The city chose to install service to make sure they're not missing a checkbox on the amenities list for visitors and businesses rather than for a particular, measurable goal.

Nearby Centralia pulls its Wi-Fi: A pilot project in the larger city of Centralia, Wash., a bit north of Chehalis, is shut down when poles used to mount Wi-Fi radios are removed as electrical wires are buried. (The reporter here confuses broadband over powerlines (BPL) with broadband wireless.) The system might be restarted later.

Craig Settles writes up Pennsylvania's Cambria County wireless success: This is a network built for particular municipal purposes, part of Settles's long-time drumbeat about having applications first and then networks built for those networks second. He notes that Cambria built a 700 sq mi network that sounds nearly cost neutral through efficiency and cost conservation--it's cheaper to get much more service with this network than it was for a smaller array of services with incumbent-provided networks.

Santa Fe residents oppose Wi-Fi in the library on health grounds: You know what I have to say about how provable this has turned out to be in clinical studies. I am, however, as always, concerned about these people's health, even if I don't believe that Wi-Fi (or EMF) causes their problems. The group opposed to library-Fi is citing the ADA in this case, uniquely I believe. Six libraries suggested that EMF triggers seizures in epileptics, something I've never heard cited before; maybe CRTs (flickering), but EMF? Wired is substantially less kind than I am, pointing out that EMF other than Wi-Fi produces vastly higher signal strength. (They're sort of ignoring signal strength at a given point where an individual stands in relation to a transmitter, however.)

From vnunet:

The company is remaining tight-lipped on what is causing the problems, so speculation is rife in the blogosphere.

One explanation, according to security experts, is that Amazon is suffering a series of denial-of-service attacks.

Amazon’s US website was unavailable for over two hours on Friday, as was the Amazon-operated Internet Movie Database.

A blog posting by Supranamaya Ranjan, at web traffic monitoring firm Narus, claims that the cause is a “network-initiated attack”.

OK, that’s not just some blogger. If the folks at Narus say it’s a network attack, I would put my money on their analysis in a heartbeat. If you recall these are the folks that the US and Chinese governments rely on to monitor traffic. Narus is quite adept at their job.

Article Link

Well, the website for the NASA Phoenix Lander at least.

From the Register:

Add the webpages for the Phoenix Mars Lander to the list of high-profile sites that have been hacked by script kiddies. Not once, but twice.

Security pros had to take down the University of Arizona-hosted site after hackers replaced the lead blog entry with graffiti that read “hacked by VITAL.” As if that wasn’t enough, members of the self-declared “sql loverz crew” redirected baffled visitors of the Phoenix mission’s official webpage and a companion site to a third-party destination. That page gave credit to hackers going by the names BLaSTER and Cr@zy_king.

Red is the color of the Martian surface, but it seems it also describes the faces of security pros responsible for the sites. Evidently, they had better things to do than vet their scripts for SQL-injection vulnerabilities. So these hackers were willing to step in and test the sites for them.

Pesky SQL Injection attacks abound and the script kiddies are loving ‘em.

Article Link

So, can we trust that the time stamp in the log file or the one added by the log management system correctly describes when the event actually happened?

We will start from locating the timestamps in logs. Most of the log formats, such as file-based logs (web, application, some security gear, etc) and syslog, Windows event logs, database audit tables, proprietary ones, contain a timestamp. In fact, once I saw somebody use a timestamp to define logs as "timed records of IT activity." So, time is critical for logs being, well, logs :-) At this point it is worthwhile to note that file-based logs will contain a timestamp IN the file, while syslog records arriving over the UDP or TCP port 514 connection are usually timestamped upon arrival BY the syslog daemon (using its own "knowledge" of time) - and then it shows up in the syslog files in  /var/log.

Let's assess whether this "in-log timestamp" provides an adequate way of timing the actual event that is being logged. Answering this question is important for investigations and troubleshooting, but becomes  nearly a matter of life and death in case of log forensics.

Here are some fun cases and issues to consider:

First, what are the chances of a  completely false timestamp in logs (BTW, today is Jan 1, 1970!) When might that happen? Typically when a logging system own clock is reset or not set correctly. This timestamp clearly should NOT be trusted. 

Second, we can say that it’s always 5PM somewhere: in other words, what time zone are your logs in? EST? PDT? GMT? UTC? Or any of more than 24 other possibilities. If you have no idea, you should not trust the timestamp.

Third, are you in drift? Is your system clock? Those pesky drift seconds turn into minutes which then work to undermine the accuracy of timing the records (and thus your certainly and trust in evidence quality)

Fourth, syslog forwarder mysteries are plenty: some of the syslog messages will be delayed in transit and the  be timestamped by the final recipient daemon, thus completely losing when the event was originally logged. Admittedly, this delayed syslog is rare, but as more people employ buffering syslog daemons (e.g. syslog-ng), it might happen more often.

Fifth, more esoteric, but still real (and really annoying): some system logs will contain two timestamps. If you don't possess in-depth knowledge of this specific log, confusion has a chance to cut the trust as well (so, which timestamp should I use?)

Sixth, most people will not think that they will fall to something that stupid: 24 vs 12 hour time. However, when facing an unknown (and poorly designed!) log format, beware that 5:17 might well be 17:17...

Finally, if you know that something got logged at 5:17AM, then when did it happen? Beware of "Log lag!" This issues is actually to tricky to give it justice here... The simplest example is when the process leaves a log records when it exits not when it starts, possibly days earlier (thus creating a log lag).

As we dive into more issues with timing logs, we also need to think about sequence timing and absolute timing. Sequence of logged events is a critical fact! Miss the sequence and the whole “house of cards” goes …  But! Absolute time is also important! Can we be assured of both all the time? (hint: no)

So,  when you look at logs next time and you see a timestamp there - start thinking about all this :-)