Update: Ron Gula corrected me on this - this is available on the free registered feed.

A little while back I spotted this article on the Tenable Blog in reading my morning RSS feeds - Tenable have added a plugin with the ability to interrogate Windows machines for the wireless SSID that they are currently associated to. Why would this be handy? How about to identify clients on your network that are bypassing network controls through using the local Starbucks’ wireless network, and therefore providing a possible entry point back into your network.

This does of course have a few prerequisites:

• You need the Direct Feed (commercial) of Nessus plugins, or Security Center, to get this functionality. If you’re a security professional using Nessus as a core tool you of course have this, don’t you? Because then you get all sorts of useful stuff like SCADA plugins, and configuration/compliance auditing.
• You need to be doing a credentialed scan for the plugin to be able to use WMI to extract this information.

This should be able to give you a point in time view of whether hosts that you are scanning are connected to a wireless network when they are scanned. You can then match this against the list of known/authorised SSID’s to identify where clients are associated to unauthorised access points (i.e. the local Starbucks).

Does this solve the problem of identifying clients bridging to a wireless network? Well, no - it has a couple of weaknesses:

• It is at a point in time, so you only have the view of what wireless networks your clients connect to when you’re scanning them.
• This just identifies the SSID, not the access point itself (i.e. the access point’s MAC address), so it’s still possible it’s a rogue access point.

However, it is certainly handy to have this kind of functionality for those who don’t necessarily have a full blown wireless security solution in place.

I am so incredibly pleased to learn that two of my fellow O’Reilly bloggers are about to become fellow O’Reilly book authors as well. I had been secretly hoping I could learn Python fast enough to work on Python for Systems Administrators myself, but as usual, smarter folks won the day, and Jeremy Jones and Noah Gift will be co-authors on the project. If you haven’t heard about it and want to throw your opinions at the authors, have a look at Jeremy’s blog post asking for input.

In other Python/Admin related news, although my day job is still “System Administrator”, I have been involved in publishing for quite some time in one way or another. In addition to writing and editing for several different publications in addition to O’Reilly, I also helped launch php|architect magazine, and have now (with the help of MTA - publishers of php|architect) launched a magazine devoted entirely to Python. It is called Python Magazine. You can see the why/when/how of it all in the announcement on my blog, and read a bit more about it in a recent interview with Free Software Magazine’s Tony Mobily.

As promised, I am following my Top 11 Reasons to Collect and Preserve Computer Logs with just as humorous and hopefully no less insightful ”Top 11 Reasons to Look at Your Logs.” 

1. The first reason is again disarmingly simple (is it, really? :-)). Read PCI DSS lately? Glanced at HIPAA? Suffer under FISMA? Yes, all of the above regulations say that you must not only have, but also review logs periodically.
2. Are your servers compromised now? How do you know if all your logs are stashed on a tape in a closet? Look at them! Now!
3. An incident happens. Really, who needs extra motivation to look at logs in such case? Using logs for incident response is a true ”no-brainer” (however, you need to be pretty “brainy” to actually analyze them in case of an incident)
4. Users - from a CEO to a janitor. You do have to know what they do on your IT systems! How? Read the logs! Everybody leaves tracks.
5. Systems log plenty of errors. Sometimes they are silly, sometimes - benign. However, often they mean that “stuff” is about to hit the fan. Periodic review of logs reveals them and saves the day.
6. Network slowed to a crawl?  Applications are slooow? Server is not … well, serving? :-) Where is the answer? In the logs, but you need to read them and understand them.
7. That policy you wrote a few months ago. Anybody following that? Anybody remembers that? Halloooo! Check the logs and you’d know.
8. By now you know that your auditor might ask for your logs. But do you know they might also check whether you looked at them? Do you? Review the logs and leave the record of this activity in the logs.
9. Change can be good. But then again, it may be the sign that your controls are lacking. Who changes what and when? From what and to what? Just review the logs.
10. Now, you hate looking at logs. You have too many (as if everybody else doesn’t…)! In this case, look at a specific subset of logs that you never saw before- NBS. Or just deploy log management that can do it for you.
11. Logs can help you predict the future (if you review, know and love them :-)). Don’t believe it? If you read them for long enough, you develop an ability to predict the future, albeit mostly future problems :-)

See also: Top 11 Reasons to Collect and Preserve Computer Logs. 

Coming soon: “Top 11 Reasons to Secure and Protect Your Logs”!

Following the new “tradition” of posting a security tip of the week (mentioned 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 #11: But These Are OUR Logs!

A common and unfortunate situation that occurs when dealing with logs is not technical, but political: not being able to get the logs you need due to political, cultural, egotistic, or other “corporate” reasons. In this tip we will try to present a few situations and solutions for those trying to wrangle logs from whatever hostile (or ambivalent - sometimes worse!) entity at your organization and thus to break the siloed approach to log management.

So, here is the situation: a desktop system starts “behaving strangely” (as evidenced by network IDS logs, which are controlled by the security team) and security wants to take a peek at the system logs to determine how it was 0wned or infected (no centralized log collection takes place). However, the security team does not have administrator-level (or, sometimes, any) access to all desktops needed to grab security logs from a Windows PC: only the desktop division of IT department does. And they refuse! Why?

• what if the security team finds that the intrusion happened due to our negligence?
• what if “they” find something else wrong while looking for logs?
• what if they crash the system and leave “us” holding the bag?
• why should they mess with “our” systems? - we are perfectly capable of taking care of it ourselves? (not! -))
• <fill whatever reasons you’ve heard!>

What can you - the security analyst or manager - do?

• leverage your existing relationships and get the logs “informally” (obviously, doesn’t scale …)
• remind them of the company security policy (hopefully, written by you to support such cases!)
• [UPDATED] ask your internal auditors for help
• use whatever desktop logs you can get a hold of (example: client anti-virus logs; other security agent)
• report them to senior management (yours or theirs; of, if you report to the same boss, both yours and theirs)

As a side note, database administrators (DBAs) are even more famously resistant to providing log data.

Overall, the tips above might help; however, to resolve such control issues once and for all, the smart organization must deploy log management tools across the entire organization and then provide limited access to the logs to all the stakeholders on the “as needed” basis …

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