Paranoia Acting Up or Just Being Reasonable?

I am still reading "Geekonomics" and - honestly! - I cannot handle more than 10-20 pages at a time since I develop a rage and start looking for a software developer to kill :-) If you need a reminder about how fragile the foundations of our civilization are, go read the book!

So, is there any public bodycount of people killed by bad (low quality OR insecure) software? All those robot gun victims, runaway robot trans, PC-controlled radiation therapy equipment? It's got to be in the hundreds by now... I thought RISKS list was doing it, but I can't find it.

How Do You Know It's The 21st Century?

That's how - you read the directions for use on the newest multi barrel 40mm automatic cannon and it says "requires only DC power and an ethernet connection for operations."

Full story here.

Fun Reading on Security - 3

Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security." Here is an issue #3, dated May 22, 2008.

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!

Technorati tags: security, reading

More Log Management Questions - Answered!

I did this VERY fun webcast with WhiteHatWorld this week and a lot of good questions about log management came up. I am answering them here for my readers. BTW, LogLogic product-specific questions can be found on LogLogic website; I am not answering them here.
 
Q1: Is a preferred log management program to consolidate the log data and then allow us to review them?
A1: The answer is "Yes!" for a vast majority of use cases consolidating logs work better than the silo'ed approach. Also, this will be answered in  longer dedicated post within a few days (link TBA).
 
Q2: Is it feasible to use a log management tool to try to determine whether application events / failures are being caused by infrastructure issues?
A2:Wow, fantastic! The answer  to this is "Yes, if you have the right logs collected." In most cases,  to get to the bottom of such issues requires having BOTH application (e.g. PeopleSoft or Oracle) and infrastructure logs (e.g. Windows or Solaris).
 
Q3: What the typical retention schedule for logs which might be required logs for compliance issues?
A3: I wish I can give a simple answer for this, but there is none. Well, PCI DSS makes it simple: 1 year for logs from in-scope systems. Other regulations are not as clear and the numbers, or - more often! - guesses at such number range from 90 days to 7 years and more.  90 days to 1 year is a common retention policy for security (on the longer side of this range) and operationally (on the shorted side of this time range) useful logs. Check this out for a few ideas for long long you might need the logs.
 
Q4: Once you have logged the events, what do you do with them?
A4: Well, I was about to laugh it off since it truly opens up a Universe of questions, issues, challenges, etc. But here is my attempt at a short answer (like, less than a book :-)): a) you collect the logs and now you can search thru them in case you need to b) you summarize them and notice the trends - overall know what is going in your environment c) you analyze them in real time to trigger alerts on "critical" log messages - failures, attacks, etc.  See this slide deck for some useful pointers.
 
Q5: Why do I create a log policy? 
A5: Log policy is a clear and simple document that show what you log on each system (and why): it helps you to configure logging across all the systems as well as helps to know what information you have in your environment (should an auditor ask, for example). A log policy also defines log retention, log review practices, etc. NIST 800-92 Guide to Security Log Management  [PDF] is a good source of info on this subject.
Enjoy!

Technorati tags: log management, logging

Cloud This, Cloud That...

Ah, weather is nice and warm, fresh wind is cooling the face, security is in the clouds. Security in the cloud? Yup. Or, if you take Mike Rothman here at face value, "lack thereof." Now, we are not talking about "cloud-based security services" here, but about "security of cloud-based services"  - big difference!

If somebody asks you "Can you have a secure cloud-based service?" - you need to ask back "What do you mean by "you"?" Seriously! Let's go back to the old joke that "the only computer that is 'secure' is the one that is turned off, cemented into a big concrete cube and stored in a locked room." But whose room? Do you own the room where the aforementioned concrete cube is stashed? No? Then maybe it is no longer 'secure' ... Think "concrete cube in the clouds - then BAM!" :-)

Joking aside, if you think that a system that is located somewhere remotely (you don't control physical security) + Internet accessible (you don't control network security) + neither written  nor audited by you (you don't control application security) can be secure, than yes, most certainly you can have a secure cloud-based service.  This also reminded me about this post by Richard where he classifies people into "two camps: those who trust their products to operate as expected and those who do not."

Now, let's review some of the issues with security of cloud based services.

First, is there public vulnerability research that made MS IIS and OpenSSH (and OpenBSD) the paragons of software security? No, this part is completely screwed up today as only criminals are "allowed" to do vulnerability research of cloud based-services (and web applications).  Comparison here is not in favor of "the clouds," and "legacy" software approach wins hands down (want trusted apps? go audit them!). To remind yourself what the world looked like without public vulnerability research, think back to early 90s: "hot new exploit - telnet as 'root' without any password" (this is where web security stands today, pretty much).

Second, can you make sure that only you will see the sensitive data (or even regulated data: PHI, credit cards, passwords, financials, etc)? Maybe, if you take care of it. As Mike R  puts it : "Basically, you can't be sure anything is secure in the cloud, so that means you have to secure it yourself. That means building your applications with some semblance of data protection [...] But ultimately if you can't prove your data hasn't been tampered with and that it's open for anyone to steal, then I suspect your auditor may have a bit of an issue with that."

Third,  can you log and audit access to your information, stored and processed somewhere in the cloud? Maybe, if you chose the provider that allows you to do it. For example, I hear that Salesforce.com access logs are good enough to enable most things you can do with OS logs. Otherwise, well, keep begging them to build it; there is no appliance you can buy to plug this hole.

Finally, if we are insane because we use software, what about cloud services?  Sorry, multiply that insanity by 10x. Replace today's mantra "I trust my software vendor" with "I trust my cloud provider, their software developers, their outsourcers (if any), the other vendor they mashup with, my ISP (and its ISP, and its ISP,  and its ISP, etc, etc), my cloud provider's ISP (and its ISP, and its ISP, etc, etc, etc)  and ... oh, wait ... and your software developers who wrote the code that connects to the above in-the-cloud service." Cool, isn't it? :-)

This paper also reminds us about the business angle: "Remember that the storage provider has less to lose than the customer"  [that is you, BTW]. At this point somebody has got to ask "is that dirty C-word hiding somewhere here? Is there a compliance angle?" You bet. And it is "simple", really: just compare a) and b) here:

a) you manage a system that contains financial records (SOX anybody?), you screw up and they are lost OR you don't screw up and they are OK (not lost)

vs

b) you DON'T manage a system that contains financial records (SOX still?) - it is in the cloud, you DON'T screw up and they are still lost since your cloud provider screws up.

Who do you think will go to jail?  And don't even get me started on the breach disclosure law angle here (if they lose your data, than you are in violation of SB1386 - that is at least my guess ...)

By now, it should be painfully obvious to any and all of my readers that "in the cloud services" are indeed the future of IT! :-) Yes, and security is a great career - with no shortage of challenges to overcome or tall peaks to climb ... now and ever. That is why I love it.

Technorati tags: saas, cloud, security, trends, future

In Passing on DLP

Now, I am not some world-famous DLP analyst, but it doesn't mean that I cannot have an opinion on this "searing-warm"  :-) security concept: "data leak 'prevention'" or DLP (notice the double quotes around prevention...)

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!" :-))

Technorati tags: security, DLP, new technology

Why Is ISO2700x Hot in UK, but Not in US?

First, something hilarious: I was teaching this brief course on logs overseas and touched upon  a  subject of ISO17799. So, having recently read how many companies in the US were ISO17799 certified, I asked my audience whether they could guess what the number was. One guy volunteered an answer, after some hesitation: "Less then 50%?"

That's "percent", folks :-)

I said to him: "You are right!" and laughed - "It is indeed less then 50!" 50 as in "count" (I read somewhere at the time that 49 companies were certified US-wide)

So, ISO17799 is hot in some countries: UK, Japan, Russia (where it is a basis for a set national standards), many others. But not in the US.

I have long been puzzled about this. What's the story?

The most likely explanation is that every security manager worth his salt read ISO17799 documents and then used the ideas and material in his own policies, procedures, etc. On the other hand, he sees no motivation whatsoever to invest in certification - since nobody is making him do it (no equivalent of a PCI auditor is standing nearby with a big axe...)

Another explanation that due to longer history of security management in the US (compared to other countries), home-grown approaches took root and no external standard will dislodge them?

Yet another hypothesis goes like this: in the US, it is more important to do a good job [managing security] than to be "standards-compliant." Is the opposite true in Europe and Asia? I dunno...

Or maybe ISO stuff is seen as "that Euro thing?" Exotic like a Hungarian chick, but just as relevant :-)

Any ideas? UK scene, any ideas? Do you care for ISO17799 at all? As a useful document to read or a something to be certified in?

Another Old Presentation: What Every Organization Must Log and Monitor

Finally, I decide to "liberate" this presentation as well: "What Every Organization Must Log and Monitor" circa 2004.

This is still very useful and relevant; also, many people will appreciate my attempt to do the impossible i.e. give a simple answer to a very complex question (BTW, it rarely works :-))

So:

| View | Upload your own

Fun Security Reading - 3

Instead of my usual "blogging frenzy" machine gun blast of short posts with links and commentary, I will now combine them into my new blog series "Fun Reading on Security" or "FRoS." Here is an issue #3, dated May 15, 2008.

• First, watch Dave Aitel beats the dead horse of academic security "research." Quote: "people who write papers in LaTeX two-column format end up saying the sky has a high negative trajectory." (other examples)
• I work for a vendor, but I am not "vendor scum." What is the difference? If you write a paper about a fake trend or about a non-existent phenomenon (that your marketing department created) with the sole intention of selling your product while masquerading your piece as "objective content", you will probably be called "vendor scum." Example: do you know why insiders are dangerous? Because of telnet and modems (no shit!) :-)
• Rich Mogul drop-kicks GRC. Then kicks it in the balls. Then steps on it. Fun read, for sure.
• Did somebody just utter "ROI"? Yeah - and that means katana blades sharpened, flamethrowers charged, pet trolls enraged :-) Yes, the beast is back - with a vengeance. Bruce Schneier hits it with +5 Flaming Blade, it doesn't die, it bites back ... again. If you love/hate ROI, read these. And Mike R comment here. Can we just replace the "R"-word with "economic measure of security" or "security efficiency?"
• Does anybody with at most half a brain believes that "almost one out of every three individuals who were informed of a data security compromise involving their personal data have ceased doing business with the company that experienced the incident" (source here and more commentary here)? Well, same people who believe FBI/CSI surveys, I guess :-) UFO? Spoon bending? Santa Claus anyone?
• NEWSFLASH!!!! Employees needs to be monitored!!! Wow!!! Reeeeally? Well, it is news to some people. Mike R makes good fun of them here.
• Harebrained paper about PCI and using cards (credit and debit), which serves as a perfect illustration of how some people perceive risk. Repeat after me: you are not liable for mis-use of your credit card, your bank is. Debit card? Very different story!
• So, risk, yes. A really good piece about risk is here. Then again, it is RiskAnalys.is? :-) More on risks of compliance stuff (also good) is here.
• Richard clearly, succinctly, brilliantly explains the "security chasm" here by commenting on Greg's article (featured in my previous FRoS): "The first camp spends more time talking about "enabling business" and "elevating the infosec conversation" while the second camp deals with the mess caused by the first world's ignorance of security problems."
• Security reading? Nah, fun security listening (that is, unless you are sick of hearing about RSA 2008 again), where we discuss - yes, you guessed right! - past RSA 2008 show.

Enjoy!

Another Old Presentation: Security Metrics

Another oldie, but ... well, maybe not goldie: my 2005 presentation on security metrics.

More On Non-lethal Weapons: Electrified Shieds

Two quotes are enough, really:

"The kit "features a peel and stick perforated [f]ilm, power supply and necessary conversion equipment. This laminate becomes electrified providing a powerful deterrent to protect officers and keep suspects or rioters at bay." What could possibly go wrong?"

Love that last sentense...

and

"It's all part of the Office of Law Enforcement Technology Commercialization's Mock Prison Riot"

Wow, a prison riot, what a fun event! ;-)

Read here.

Log Management: Insight From Ancient Times (The 80s, That Is :-))

My boss has posted two of the very fun blurbs on log management to our blog; do check them out, especially if you are the fan of the 80s :-)

• The Best of the 80s: Log Management for Operations
• More 80s: Rubik's Cube for Log Operations

Fun blurbs from the above:

"In surveys, 70%+ of organizations confess their primary budget for log management still comes from compliance. However, this same group admits for years now that 70% of their use of log data is driven by operational needs such as fault detection and problem isolation."

"The requirement to collect 100% of all log messages of all log sources is even more important in operations than it is in security." (why?)

"Rather than replacing these systems with yet another console, most companies are going to look for the ability to integrate a new information source, log data in this case, into the existing fault management console. Web services likely will be the mechanism of choice."

Another Old Presentation: Security Management Trends

Now, I have NO idea whatsoever why somebody will be interested in my "Security Management Trends 2004" (!) presentation, but here it is, released from cold storage :-)

A Few Upcoming Presentations

Just wanted to highlight a few of my upcoming presentations, live and web-based:

"Anton live:"

• SANS Security West, San Diego, CA on May 13: "'Worst Practices' of Log Management"
  
• Secure 360, Minneapolis, MN on May 14: "Application Logging 'Worst Practices'"
  

Webinars and webcasts:

• NIST 800-92 for FISMA (And Beyond) + some LogLogic product presentation on May 20
• 'Worst Practices' of Log Management webcast on May 22 (this one is FUN!)
  
• SANS Log Management Survey Review (this WILL be fun, I am warning you! :-)) on June 5th, 2008.

Enjoy!

UPDATED: 5/13/2008

Now, Somebody Please Tell Me This is A Spoof ...

... NOW!!!

"Hackers recently bombarded the Epilepsy Foundation's Web site with hundreds of pictures and links to pages with rapidly flashing images.

The breach triggered severe migraines and near-seizure reactions in some site visitors who viewed the images. People with photosensitive epilepsy can get seizures when they're exposed to flickering images, a response also caused by some video games and cartoons."

Fun Reading on Security - 2

Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security." Here is an issue #2, dated May 8, 2008.

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

1. 0x000000 blog has a neat post on security, word definition and all. It reminds us that "security is forever" since it is about people, not broken technologies. A quote: "And so we will never able to secure other people, they have to secure them self. And we know that they can't." Same blog also have a fun (but a little bizarre with a little 80s feel) interview with Richard Stallman.
2. Along the same line, discussion about security industry longevity is here at Gunnar Peterson's blog: specifically, he debates Mike R's semi-humorous prediction that in 2012 there will be 0 "security professionals." Indeed, secure networks + secure OS + secure apps < security.
3. Also a very fun read comes from DarkReading: "7 dirty secrets of the security industry." Example quotes: "The goal of the security vendor is not to secure, it's to make money" , "Security vendors want businesses to buy what they sell, so they push specific products to block specific threats "; it also discusses another facet of compliance vs security.
4. Fun - and as usual heated - debates about the "AV is dead" and "anti-anti-virus revolt" happen here. Is blacklisting  AV dead now? More dead than before? :-) Or just "limited",  but still very useful? BTW, Matasano opines on the subject here as well, calling it not a revolution, but a protest.
5. The next  Carnival of the Security Catalyst Community - April 22, 2008; as always fun. Next carnival Apr 29 is here and the last (so far) one is here.
6. Really good look at logging for developers is here. "all too often logging gets treated as optional and not necessary. In this column we will cover the essentials of logging []for developers!] from a security perspective"
7. Latest stolen account prices are posted here by AVERT Labs guys. Account with $16,000 goes for about 700 euros (!) Also, Finjan reminds us that top corporations are all owned.
8. ISP data retention rears its (ugly?) head again. Good business for LogLogic or privacy nightmare?
9. A fun read from Tizor Blog: "How did the TJX data breach happen? Part 1: Anatomy" A must read, with diagrams, etc. "After breaching the TJX wireless system, the attacker was able to gain administrative privileges to the RTS servers located at the TJX corporate headquarters in Framingham, MA."
10. A very good read from Greg Shipley: "Risk Management: Do It Now, Do It Right." A lot of interesting bits about CSOs, security technologies evolution, etc. "The journey continues. We invested hundreds of millions of dollars in intrusion-detection systems without a solid understanding of their relative effectiveness and total cost of ownership. The IDS craze led to reinvestments in intrusion-prevention systems that even today are only partially enabled, and PKI is still a bad word in many IT circles. There's no shortage of disappointments on other product fronts."
11. "Data Classification Is Dead?"  Rich Mogul explains why data classification by the owners is never going to fly... "Enterprise content is just too volatile for static tags to really represent its value. Even those of you in defense/intelligence don’t *really* do granular data classification. " This is a good reminder to shoe that just spout the propaganda "first, need to classify data." Can you hope to do "DLP" without it? Also, read this one from Rich as well: not only you can't classify, you often don't know who owns what.
12. Hot, hot, hot! "Snake Bytes " on DarkReading. "We are all in the business of stopping just enough crime to keep us in business." Wow! Definitely a must read.
13. Marcus Ranum on logging in Start Trek (read the whole thread): "What do you expect from a starship that runs on Windows-24k? Microsoft added support for syslog in 2348 - citing customer demand - but still
    has no Enterprise-class log architecture." :-)
14. Piece on PCI and log management where a vendor makes an idiotic faux pas by saying that "less than 1% logs are of interest." In reality, all (OK, most) logs are of interest under the right circumstances. And we almost never know which ones we'd need.
15. A fun blurb from a lawyer on PCI. Good conclusion too: "Regardless, now is the time for merchants to begin engaging their legal teams to address PCI compliance, and opening the lines of communication between the lawyers and security pros." He also fights the checkbox mentality by saying that  "merchants should not view their internal security personnel or QSAs as “rubber stamps” of PCI compliance." I am happy to see this lawyer basically say that if you ignore PCI, your ass is  0wned :-)

On that happy note - see you next time! :-)

Technorati tags: security, reading, trends, market

OMG, This is Sooo "Kid in A Candy Store" :-)

"First USENIX Workshop on the Analysis of System Logs (WASL '08)
December 7, 2008
San Diego, CA, USA"

CFP here.

Anton Security Tip of the Day #15: Fear and Loathing in Event 560 (and 562 and 567)

Following the new "tradition" of posting a security tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along and join the initiative. One of the bloggers called it "pay it forward" to the community.

So, Anton Security Tip of the Day #15: Fear and Loathing in Event 567

This tip digs into a seemingly simple, but really VERY esoteric subject: monitoring file access and modification via a Windows event log. Now, some people - who never studied this subject - tend to have a very simplistic view of this: just enable Object Access auditing, then right-click on a file or directory, click Security->Advanced->Auditing and then pick what types of events will be logged and by what accessing entities (i.e. users or computers). OK, so this will produce some logs, that is for sure. But are they useful?

First, why are we doing this? We typically need to know the following when we audit file access in Windows (or any other OS for that matter) for security (monitoring and investigation) or compliance:

• Time/date
• Computer where it happened
• User who touched the file
• Application he used to access the file
• File name + location (directory, share, etc)
• Type of access (read, write, create, delete, etc)
• Status (i.e. success or failure)

Can we get this from the above logs? No.

What? No!?! Really?

Yes, really. We can get some of the above, some of the time, not all of the above, all of the time. Here is an example, we are looking at event ID 560 (picture) and then at an extract from its description field.

Event:

Description (selected field):

Object Server: Security

Object Type: File

Object Name: C:\0\TestBed\simple_text_file.txt

Image File Name: C:\WINDOWS\system32\notepad.exe

Primary User Name: Anton

Primary Domain: XXXXXX

Accesses: READ_CONTROL

SYNCHRONIZE

ReadData (or ListDirectory)

WriteData (or AddFile)

AppendData (or AddSubdirectory or CreatePipeInstance)

ReadEA

WriteEA

ReadAttributes

WriteAttributes

 

WTH is that? Well, we know that the user  'Anton' has successfully read? wrote? changed attributes? did something? with a file named "C:\0\TestBed\simple_text_file.txt" using a program named "C:\WINDOWS\system32\notepad.exe." That's the best we can get, in this case! We may try to look at event IDs 562 and 567, but this missing information (i.e. the exact action performed) will not be added.

BTW, there will be  a few more dozen (sometime hundreds!) of the 560s, 562s and 567s  produced - all from just opening the text file in a notepad. The above event is notable for having BOTH "notepad" and "simple_text_file.txt" in the same event; others will have either of the two.

Anything else gets in the way? Yes, lots! MS Office will write to all files, even just opened for reading (with no user modifications to the content whatsoever), which will screw up your log monitoring efforts. If the file is on a share, more information will be missing (e.g. username might be).

So, how to use Windows event logs for file access tracking?

1. Enable logging (as described above)
2. Pick events 560 (most useful) and 562, 567 (useful too)
3. Look for fun filenames that might be touched by the users (have a list of files and users handy)
4. Figure out what programs were used to access them (this is called "Image File Name" in "WinLogSpeak")
5. Ponder the 'Accesses' section of each event until your brain turns blue :-) or until you decide whether such access is authorized or not...

Overall, this is still very useful for file access monitoring, but the process is paaaaaainful.

BTW, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.

Technorati tags: security, tips, logging, log management

Another Old Presentation: Log Baselining

As I did in the past, I am releasing another one of my old presentations. This one is about baselining logs and was given at SANS a few years ago as SANS @ Night. It mostly a subset of my "Log Mining" preso, but with some things added and clarified. Keep in mind, this is circa 2006 or so :-)

I dug out a few more fun ones, that go as far back as 2002. I will release them here in a few days.

Need Proof That I am Popular in UK! :-)

Just a little bit of stats-boosting and ego-stroking :-)

Nominate me in IT Security

Why [Some] Smart People Hate Logs?

WARNING! "Ph." in "Ph.D." at work (play?) here :-) This is one of them darn philosophical posts...

Now, some people hate logging, because  logs are too hard to deal with (enable, collect, store and especially understand and interpret). However, there is a whole other group of fairly intelligent people who "hate logs:"   the organizers of some well-known technical security conferences. The experience of many of my colleagues (and competitors!) and myself proves that a log-related talk will NOT be accepted to ANY technical security conference nowadays. Now, some were generous enough to explain why. Others were not (screw them and no link :-)).

But let me rant about this one a bit. First, it is always a possibility that they dislike me not logs:-) -  this is easily disproved, however, since some of my colleagues had the same exact experience. Do they dislike vendors talking about logs? Nah, this isn't it either - most of my conference presentations had nothing to do with LogLogic, even though they are about logs. Some of my friends (and this blog readers) tried to suggest that an audience of such events "knows everything there is to know about logs." This is not true since - gasp!- nobody knows everything there is to know about logs: they hide way too many mysteries (with useful answers!) to discount them like that.  Another one I've heard is that "real hackers don't get logged -> logs are useless", which is also silly: this is true only if you take a very narrow view of logs (e.g. NIDS alerts),; clearly, everybody is logged by the firewalls, servers, apps, etc. The challenge is not a lack of data, but too much data and not enough time and tools.

But we are about to "hit paydirt" with this question...

Tool? Did I just mention tools? This opens the last and final, deeply evil reason for such "log-hate":  one of the conference organizers mentioned that, in his opinion, there is nothing new in the field of log analysis since regex-match-based alerting (and regex-based parsing into database tables).

And you know what?

Drum roll....

He was actually somewhat right.

Indexing did come in the world of logging, but, personally, I don't find it to be a huge feat of human ingenuity (even though it is definitely useful). I also think we are not doing enough with index data (and I definitely intend to change that...)

In addition, there was A LOT of academic research on the subject, from the SRI EMERALD in the 80s (and even earlier) to today, but many of the papers I've seen sit on the "hilarious side of useless"...

So, I need a campaign "Making Logs Sexy Again!" (and some impressive research results to boot) - will it work? Let's try and find out!

Reverse Compliance or "Logs as Proof of Incompetence?"

This post is inspired by the BeastOrBudda musings on compliance here.

Now, I wrote a bunch of things about logs for PCI DSS compliance (including my book chapter) and overall logging for compliance. How about "reverse compliance" against logs?

Whaaaat? WTF is "reverse compliance?"

"Reverse compliance" is a motivation to purposefully avoid technologies that have a chance of telling you that you are NOT in compliance. Sadly, logging is featured very high on the list of such technologies that a) tell you about all the problems with your compliance posture (e.g. direct violations of regulatory requirements, lack of controls, inefficient controls, policies not followed, etc) as well as b) are mandated by various regulations (e.g. PCI DSS) and c) actively used by auditors for finding compliance issues.

When this type of thinking in progress, people start going even further towards:

• If I have no logging, people will not know that I was "0wned" for years and thus have to notify the customers (reverse breach disclosure compliance)
• If I have not logs, nobody can blame that I knew (or - had a way to know) about the successful attack and data theft?
• If breach investigation will lead to a dead end due to not having logs, maybe I won't be fined as severely?
• If I don't have logs to show the auditors, they won't blame me for mismanaging security in my environment (or - they will only blame me for not having logs and not for all the other serious issues I have...)
• If I have no logging, I cannot be found to be in violation of many PCI DSS requirements since evidence of violation will be in the logs (but, will, obviously be in violation of Requirement 10)

The key question is how widespread "reverse compliance" is? I am sure that many of my enlightened readers would think that no organization is that f*cked up :-) Well...

... some sadly are. Is "worst in class" label appropriate here? Maybe not, since these companies are thinking that they are "being smart about their business" and saving money by avoiding those "useless" (also known as "common sense" ;-)) compliance requirements.

So, will you log if logs will prove your incompetence?

That is, my friend, the whole question here...

On the other hand, I hope that this "approach" is not too common in the age of breach notification laws: logs or no logs, they will have to tell the public and - often! - without logs they will have to announce that ALL is lost. The burden in on them to prove what was NOT stolen IF the server where the data is stored was found to be owned.

For example, a compromised server + critical data stored = every record is assumed 'lost' in the absense of logs.

This is, in fact, one of the stronger motivation for log management today as it shows you clear, obvious savings: notify 200,000 people vs notify 40,000,000 people of the breach at, say, $5 apiece....

Technorati tags: compliance, security

So Cool: Richard on NAC

This is fun: Richard "IDS is dead" Stiennon says "NAC is dead."

I will now start calling him Richard "Both IDS and NAC are dead" Stiennon. Also, he is hereby proclaimed a Mortician of Security Industry :-)

Sorry, it is all in good fun!

More on that tomorrow in my "Security Reading II" piece, BTW.

Nobody Is That Dumb ... Oh, Wait X

The fans of "Anton-style humor" will (darn it, MUST!) appreciate the X-th (i.e. super-anniversary) installment in my strictly aperiodic "Nobody Is That Dumb ... Oh, Wait" series,  a cheap [but - hopefully! - more humorous] imitation of the infamous "doghouse."

Today's entry is about throwing free money and free work [of somebody else, mind you] down the proverbial crapper.

So, the other day I was at one security conference which had a bit of a vendor expo. Since I work for a log management vendor, I am always on the lookout for new log-producing technologies. Typically, I just ask the vendor to send some log samples so that we can either create an official support package for this new log source or, at least, see how such logs will fare with our log indexer (that enables LogLogic index searches and  Index Reports).

Obviously, every vendor I ever approached loved it: after all, they might get something for nothing. If they are small, integrating with LogLogic might help their business. If they are big, they are typically happy that their "partner ecosystem" is growing. All it takes for them is sending a small sample of their logs - and we will do the rest.

While cruising that show I noticed a booth of a relatively well-known (but still pretty small) security appliance vendor. So I chatted with them a bit and in the end asked the engineer to connect  me with their core  folks so that we [LogLogic] can get a sample of logs and then develop support for it.  We don't really have to do it for them, but, then again, it might come handy, who knows.

Imagine my surprise (nah, shock!) when an email came that they "don't really want that."  I thought long and hard about the possible benefits of NOT having your logs in a log management system, but only one stood above the rest - and that is STUPIDITY! Thus, this entry :-)

Technorati tags: stupidity, logs, logging

Poll #8 Log Analysis Context

So, my next poll is up - and it is fun: Which of the types of information below are most useful when trying to make sense of a log entry?

Vote here!

Past polls:

Poll #7 "What tools do you use for Windows Event Log collection?" (analysis)

Poll #6 "Which logs do you LOOK at?" (analysis)

Poll #5 "What are your top challenges with logs?" (analysis)

Poll #4 "Who looks at logs in your organization?" (analysis)

Poll #3 "What do you do with logs?" (analysis)

Poll #2 "Why collect logs?" (analysis)

Poll #1 "Which logs do you collect?" (analysis)

Log Haiku #6 (Final)

How do you eat an elephant?

Piece by piece you do!

But what it objects to it? Logs do.

 

Sorry, no more logging haiku were created - hopefully the logging book project will come back to life soon...

Monthly Blog Round-Up - April 2008

I saw this idea of a monthly blog round-up and I liked it. In general, blogs are a bit "stateless" and a lot of good content gets lost since many people, sadly, only pay attention to what they see today.

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts and topics.

1. In a bizarre twist of fate, the #1 post this month is this little blurb on what will motivate the improvement of security in the future. So, is it lawsuits after all?
2. Emerging from its well-deserved oblivion is the topic of anti-virus efficiency. Here are the posts: Answer to My Antivirus Mystery Question and a "Fun" Story, More on Anti-virus and Anti-malware, Let's Play a Fun Game Here ... A Scary Game, The Original Anti-Virus Test Paper is Here!, Protected but Owned: My Little Investigation, A Bit More on AV  and Closure (Kind of) to the Anti-Virus Efficiency/Effectiveness Saga.
3. Again this month, my logging polls are super-hot: specifically, a controversial Windows Log Collection Poll (which is a poll #7) sits among the Top5 posts (closely behind is poll #6 about logs that people actually look at).
4. People, please stop googling for "open source SIEM." :-)  Really! You are not going to find it, 'cause it doesn't exist (yes, OSSIM exists, but I still doubt that it will gain massive adoption any time soon). In any case, this tiny blurb from 2 (!) years ago where I explain why an open source SIEM will NOT emerge soon  is in Top5  posts (weird indeed!). I have to tell you that the volume of google queries for "open source SIEM" that land on my blog has increased by a factor of 8 (!!!)  over the course of last year.
5. Finally, a Top5 item which did not surprise me this month: my RSA impressions are Top5 as well (this post and the whole  RSA2008 coverage)

See you in May!

Possibly related posts / past monthly popular blog round-ups:

• Monthly Blog Round-Up - March 2008  
• Monthly Blog Round-Up - February 2008  
• Monthly Blog Round-Up - January 2008  
• Monthly Blog Round-Up - December 2007  
• Monthly Blog Round-Up - November 2007  
• Monthly Blog Round-Up - October 2007  
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007

 

Technorati tags: monthly

Log Haiku #5

To act or not to act, huh?

That is the question.

You, not logs, must answer it!