We’ve received a lot of requests for the resources we described during our recent Security 101: Getting on the Right Track, Right Away webcast. In addition to an archive of the webcast, here are the books, websites, and other resources that will help you get started in IT security:

Recommended Reading:

• CISSP All-in-One Exam Guide by Shon Harris – Start here with Harris’s primer on all things security
• TCP/IP Illustrated by Richard Stevens – Use this as a reference when examining packets.
• Building Internet Firewalls by Elizabeth Zwicky – The value here is fundamental concepts, not specifics about certain firewalls.
• Securing Windows NT/2000 Servers for the Internet by Stefan Norberg – An old but good text providing fundamental concepts for hardening Windows systems.
• Hardening Windows Systems by Roberta Bragg – A more recent complement to Norberg.

Recommended Tools:

• WireShark (www.wireshark.org/download.html) – Examine packets (use with “TCP/IP Illustrated”, above)
• Superscan (www.foundstone.com/us/resources/proddesc/superscan4.htm)
• Nessus (http://www.nessus.org/) and/or Nmap (http://insecure.org/) – Vulnerability scanners

Additional Tools:

• Sysinternals (http://www.microsoft.com/technet/sysinternals/default.mspx) – Variety of utilities
• PGP (www.pgp.com)  – Encryption, documentation is highly recommended, basically a primer on encryption.

Recommended Security News:

• SANS Internet Storm Center (http://isc.sans.org/)
• SecurityFocus (http://www.securityfocus.com/)
• FS-ISAC – Financial Services Information Sharing and Analysis Center ($$$) (http://www.fsisac.com/)
• Department of Homeland Security (http://www.dhs.gov/)
• US-CERT (http://www.us-cert.gov/)

Regulations and Standards

• FFIEC (http://www.ffiec.gov/)
• COBIT (www.isaca.org/cobit/)
• NIST (http://csrc.nist.gov)
• ISO 17799 (ISO/IEC 27002:2005) (http://17799.standardsdirect.org/)

Vulnerability Lists

• SANS Top 20 (www.sans.org/top20/)
• SANS @Risk Newsletter (www.sans.org/newsletters/risk/)
• BugTraq (www.securityfocus.com/archive/1)
• CVE (http://cve.mitre.org)
• Vulnwatch (http://seclists.org/vulnwatch)

Local Chapter Organizations

• ISSA (http://www.issa.org/)
• ISACA (http://www.isaca.org/)
• OWASP (http://www.owasp.org/)

Training Organizations

• SANS Institute (http://www.sans.org/)
• (ISC)² (http://www.isc2.org/)
• ISACA (http://www.isaca.org/)

Magazines and Publications

• Information Security Magazine (searchsecurity.techtarget.com/)
• CSO Magazine (www.omeda.com/cgi-win/cso.cgi)
• SC Magazine (www.scmagazine.com)
• ISSA Journal (www.issa.org/Members/Journal.html)
• Financial IT Security (www.financialitsecurity.com)

Feedback? blog@secureworks.com

Last week, the FDIC released an FAQ (link: http://www.ffiec.gov/press/pr081506.htm) on authentication guidance for the new regulations that came out last fall. On the whole there are only a few surprises for anybody who’s been paying close attention to this issue, but it’s still helpful to have these issues clarified. The one thing this FAQ made clear is that the overall trend has been to extend the reach of this guidance rather than narrow it.

For example, it tackles the question of whether the guidance applies to telephone banking systems? Yes. Any cursory reading of last fall’s guidance would NOT have led you to believe that tele-banking would have been included. But it is. And how about call centers, are they included.? Surprisingly, yes! This whole authentication issue got started with last October’s guidance, and at that point it seemed primarily about Internet banking. And now even call centers are included. So there has been scope creep.

Overall that is not a bad thing from a security perspective, but we anticipate that, for these scope creep categories, most financial institutions will NOT have much more than a plan and a risk analysis in place by the end of 2006, if even that much. But the agencies continue to beat the drum of year-end 2006 complete compliance, and with the ever expanding scope.

We notice in the FAQ one particular question that has been vexing most readers of last year’s guidance: does the guidance explicitly require the use of multi-factor authentication? The answer is no. The best way to think about the guidance, is that it is about strengthening your authentication controls around the high-risk transactions identified in the guidance. Simple use of username and password is never sufficient for “high risk” transactions. You must implement stronger authentication. And do a risk analysis of course.

The overall tone of the FAQ is ,”Yes we mean it. Yes, you have to have the authentication countermeasure in place by year-end, and yes you have to have done your risk analysis around authentication by year-end.” And we know this is NOT the end of this issue. Because ultimately authentication is not a silver bullet for combating identity theft issues, or Phishing, or Pharming, etc.

We are all in a long war, which will be fought on many fronts–there will be new technologies, there’ll be new regulations - and we are a long way from seeing that we can get the risk of identity theft down to an acceptable level. The best approach to this issue is to think of it this way, - the agencies can force you to fight this battle, but you are going to have to figure out how to win it on your own.

The great author Vladimir Nabokov said in an interview, “I think like a genius, I write like a distinguished author, I speak like a child.” I remembered that line as I began using, just now, speech recognition software (Dragon Naturally Speaking) to contribute to this blog.

Like just about everybody in my profession, I love technology, even when it’s allowing me to write like a child. But immediately upon using this software I also began to think, “ what are the security implications”? I have never heard of any voice-recognition specific exploits or vulnerabilities, but my mind naturally tends to think that there must be some, and that I should consider them. I wish this were not so. But technology has become so complex, that to NOT think about security is, nowadays, near suicidal. Even something as innocuous as voice recognition software appears as a storm cloud to us now.

In the security profession, we see flaws and bogeyman everywhere. We look for them. It’s ingrained. Someone has to take this attitude. History has shown us where the rosy colored glasses get you. But one of the less-advertised benefits of working with a security company, is to offload this constant worry. Constantly obsessing about security takes most technologists off their game, it poisons some of their optimism. Especially since it feels too overwhelming to almost anyone to try and keep up in security. Essentially, it’s impossible if you also have a day job (running or securing a company).

Security professionals are a doom and gloom crowd, and most organizations cannot afford to be saturated with that attitude. We are like those guys who lived for years and years in silos underground always thinking about nuclear war, so that you didn’t have to. Of course, we have massive resources at our disposal - exposure to tons of data, dedicated tools, manpower - and we still obsess.

Maybe that should be our motto - “Helping you to keep your joie de vivre about IT”.

Check out this story on multi-factor authentication implementation. It’s a good discussion of how different financial institutions are approaching the new requirements.

“No security expert should ever count multiple instances of ’something the user knows’ as ‘multifactor authentication’.”

I did ask this question of two examiners several months ago and they indicated that this approach would NOT comply. That’s not to say that the thinking hasn’t changed, but clearly the market is still figuring this one out.

Read the story.

[Via Security Incite]