Learn how file integrity monitoring solutions work and the capabilities you should expect your solution to have. Then review a detailed checklist you should complete before purchasing your solution. Finally, discover how Tripwire Enterprise effectively combines file integrity monitoring with configuration assessment-a single configuration control solution that proactively assesses and monitors the IT infrastructure and enables organizations to achieve and maintain compliance with standards and regulations.

Sniffing, or monitoring all traffic on a network, is so 1999. That is when L0pht came out with AntiSniff, which could detect many scenarios where someone was sniffing a wired network. How can we be using plain text authentication protocols in 2008? It is a well known and easily solved problem. But people authenticate in clear text everyday when they log into social networking or blogs or other “unimportant” applications. The problem is when they use those same credentials for work or online banking.

We need to think of any application that alows users to authenticate in the clear as broken. If 3 journalists can monitor passwords, anyone can.

Update 08/08/2008 12:30pm EST:

It turns out the attack was likely a MITM attack where the attackers ran their own DHCP server and handed out a gateway IP that was controlled by them. At least one reporter was connecting to his organization’s content management system over unencrypted HTTP and got his password compromised. More details in “How eWeek Got Hacked at Black Hat.”

he Court of Federal Claims that first heard the case threw it out, and the new Appellate ruling upholds that decision. The reasoning behind the decisions focuses on the US government's sovereign immunity, which the court describes thusly: "The United States, as [a] sovereign, 'is immune from suit save as it consents to be sued . . . and the terms of its consent to be sued in any court define that court's jurisdiction to entertain the suit.'"

In the case of copyright law, the US has given up much of its immunity, but the government retains a few noteworthy exceptions. The one most relevant to this case says that when a government employee is in a position to induce the use of the copyrighted material, "[the provision] does not provide a Government employee a right of action 'where he was in a position to order, influence, or induce use of the copyrighted work by the Government.'" Given that Davenport used his position as part of the relevant Air Force office to get his peers to use his software, the case fails this test.

But the court also addressed the DMCA claims made by Blueport, and its decision here is quite striking. "The DMCA itself contains no express waiver of sovereign immunity," the judge wrote, "Indeed, the substantive prohibitions of the DMCA refer to individual persons, not the Government." Thus, because sovereign immunity is not explicitly eliminated, and the phrasing of the statute does not mention organizations, the DMCA cannot be applied to the US government, even in cases where the more general immunity to copyright claims does not apply.

It appears that Congress took a "do as we say, not as we need to do" approach to strengthening digital copyrights.

This new remote WiFi attack is particularly timely as a new indictment of 11 for ID theft of over 100 Million credit cards (watch video to see Veracode’s CEO) was handed down this week.  Guess how they got in?  They used War Driving to get on insecure internal WiFi networks and then used the internal access to install sniffing software.  The attackers were mostly from foriegn countries and the companies attacked in the US.  So at some point someone must have been in the country to physically scan the networks. 

David Maynor’s WarShipping trick solves this “need to be there” problem  to do wireless attacks.  Why travel and risk being physically apprehended when you can just mail a package with a WiFi and WAN enabled device and just hack remotely? 

We will have to see how insecure these businesses that need to be PCI compliant are now that this massive WiFi attack has been made public.  I find it takes a widely publicized attack of your organization or a close peer to actually get many security problems fixed.  I bet some retailer’s IT departments started scambling after this was made public.

Attackers like to keep updating their methods just ahead of compliance requirements.  Sometimes I think that becoming compliant is protecting yourself from last year’s attack due to the lag time between attacks becoming prevelant, compliance standards changing, and then organizations making security updates to meet complaince.

With application security we may already be a little behind.  PCI requirement 6.6 kicked in June 2008 and requires organizations handling credit card data to audit their applications for the vulnerability classes outlined in OWASP Top Ten 2004 (yes, note the lag time).  I fear a 100 Million ID theft scale compromise is still looming using application security attacks.

This new remote WiFi attack is particularly timely as a new indictment of 11 for ID theft of over 100 Million credit cards (watch video to see Veracode’s CEO) was handed down this week. Guess how they got in? They used War Driving to get on insecure internal WiFi networks and then used the internal access to install sniffing software. The attackers were mostly from foriegn countries and the companies attacked in the US. So at some point someone must have been in the country to physically scan the networks.

David Maynor’s WarShipping trick solves this “need to be there” problem to do wireless attacks. Why travel and risk being physically apprehended when you can just mail a package with a WiFi and WAN enabled device and just hack remotely?

We will have to see how insecure these businesses that need to be PCI compliant are now that this massive WiFi attack has been made public. I find it takes a widely publicized attack of your organization or a close peer to actually get many security problems fixed. I bet some retailer’s IT departments started scambling after this was made public.

Attackers like to keep updating their methods just ahead of compliance requirements. Sometimes I think that becoming compliant is protecting yourself from last year’s attack due to the lag time between attacks becoming prevelant, compliance standards changing, and then organizations making security updates to meet complaince.

With application security we may already be a little behind. PCI requirement 6.6 kicked in June 2008 and requires organizations handling credit card data to audit their applications for the vulnerability classes outlined in OWASP Top Ten 2004 (yes, note the lag time). I fear a 100 Million ID theft scale compromise is still looming using application security attacks.

Q1: How do you handle variety of log sources? There are so many, almost beyond my capability.

A1: Sorry to ponder the meaning of "is" here, but what is meant by "handle"? It is really not that hard to collect logs from a large number of diverse sources (as long as the logs can be delivered via syslog or exist as files and can be collected). Now, there will certainly be challenges  when the volume of logs gets large, but if by "handle" you mean "collect + store", it is really not that hard, given the right tools. Now, if "handle" means "make sense of what all those logs are trying to tell you," it is a different story altogether.

Q2: You talked about the importance of logging; however for an intermediate or novice admin what are the starting steps .. what are the minimal logs they should start at once?

A2: Answered in "Log Management - Day 1" If you want a simple list of things to "enable today,"  I cannot really answer it since I know neither your needs, nor your environment. In other words, this is the "what is the meaning of life question?" :-)

Q3: What regulations, rules or guidance exist regarding sharing or visibility of logs to users?

A3: PCI DSS says in Requirement 10.5:  "Secure audit trails so they cannot be altered.
10.5.1 Limit viewing of audit trails to those with a job-related need
10.5.2 Protect audit trail files from unauthorized modifications
10.5.3 Promptly back-up audit trail files to a centralized log server or media that is difficult to
alter"

NIST guidance for FISMA also says something similar (for example, look in NIST 800-92 doc). Overall, log protection and security are mentioned in many other regulations as well.

Q4: Privileged groups membership monitoring in AD one of the most important from my point of view. However I did not find effective way to monitor/report on changes in those groups. Any recommendations?

A4: This is indeed a tricky one which might take more space to answer than I have here; it might also take you 'beyond logs.' One good source of information is Randy Smith's site and, specifically, his webinar on 'Active Directory "Logging Gap"' (here somewhere) - which covers how to audit things of that sort when then native logging is not sufficient.

Q5: How I can learn what exactly I need to log?

A5: OMG, this is a $1,000,000 question :-) Let me answer "how can I learn" part and not the "what exactly I need to log part,"  (also see discussion on "MUST-DO Logging for PCI?") as it is actually answerable. To learn what you need to log, first ask "Why?" (and then see this) - basically establish what you want to accomplish with logs, catalogue your systems, figure how to tweak the logging knobs - and then do it!

Q6: How granular should logging be? What is your recommendation for enterprise servers like domain servers and Windows servers?

A6: Again, too long to answer here in details (it will become a subject of a longer blog post later), but some pointers follow: here for Windows (MS site also have a few recommendations on audit policies)

Q7: What is "more control" and what is "less control" that you mention in the webcast? Can you give an example?

A7: OK, I did say that "sometimes when you implement more controls, you actually have less control." What do I mean? If you buy a firewall (a network security control) and then - over time, of course - configure it with 7800 rules (!) that are supposed to give you control over who can and cannot access your network, you will not gain control over your environment. You will actually be less in control of who is touching your network, compared to, say, having only 20 rules.

Q8: What about mandated NIST controls for government systems? Auditing is a specific control for Moderate and High risk systems. What list of events do you recommend for auditing?

A8: This is too long to answer here, but NIST 800-92 Guide is a really good source of such info ("Guide to Computer Security Log Management [PDF]") Also, see my presentation on NIST 800-92 Guide in the Real World.

Q9: The issue that many organizations get stuck on, is the monitoring process, and defining what exceptions to monitor for? Is there guidance / framework for this? How much of it is system specific and how much is applicable generally to all systems?

A9: I outlined some general ideas back in 2004 via this presentation (note to self - update that to be more 2008-relevant); it is mostly general, but also has pointers to specific system. Keep in mind that it is focused on security, not operational monitoring (which is often no less important - in fact, often MORE important)

Enjoy! Sorry for being brief with some of the answers - I am woefully late with this even as they are...

Other questions that I answered in the past:

• More Log Management Questions - Answered!
• Some Burning Logging Questions - Answered!

New Speaking of Security co-host, Amanda VanVeen, meets with Jeff Carpenter, Senior Product Marketing Manager at RSA, to discuss how the latest release of RSA Aughtentication Manager supports organizations focusing on business continuity. When natural or man-made disasters hit, it's important that employees be able to quickly and easily access network resources, but it's equally important to know just who those new remote workers are.