1. Vulnerability Assessments Part 2 3/10/04 Mark Lachniet, Analysts International

2. Introductions Mark Lachniet, Technical Director of Analyst International’s Security Services Group Technical lead developing for services, methodology, quality control, technical presales Certified Information Systems Auditor (CISA) from ISACA Certified Information Systems Security Professional (CISSP) ISC^2 Linux LPIC-1, Novell Master CNE, Microsoft MCSE, Checkpoint CCSE, TruSecure ICSA, etc. Former I.T. director of Holt Public Schools Frequent speaker for local organizations

3. Agenda Defining a Vulnerability Assessment Defining Scope Network Survey Port Scanning Vulnerability Research / Validation Common Vulnerabilities Industry Databases (CVE) Web Application Security Tools, products and information

4. Class Logistics Frequent breaks, maybe not 20 mins. I do not mind if you mess around with your computers while I am talking, in fact I encourage it - you are here because you want to be Will attempt to do more hands-on exercises and less talking Please speak up! This will be most useful if you ask questions! Don’t wait for the end Consider finding a partner, especially one of a higher or lower technical skill level

5. Class CD-ROM I have included a CD-ROM with many tools and utilities on it Some of these we will use, some of them we may not Most are 30-day expiring demos You should go to the web site(s) yourself and download the software, so you can get registered

6. Classroom Network

7. Definition of a Vulnerability Assessment Vulnerability assessment: The systematic examination of a system to identify those critical infrastructures or related components that may be at risk from an attack and the determination of appropriate procedures that can be implemented to reduce that risk. [The] systematic examination of an information system (IS) or product to determine the adequacy of security measures. identify security deficiencies, provide data from which to predict the effectiveness of proposed security measures, and confirm the adequacy of such measures after implementation. [INFOSEC-99]

8. Pen-Test vs. Vuln-Assessment This presentation is about doing a “vulnerability assessment” or “penetration test” depending on your terminology, primarily on Internet hosts Most people conceive of of a “Penetration Test” as being labor intensive, with the explicit goal of finding some way into the system, not “all ways” Conversely, a vulnerability assessment attempts to find all known holes on all systems, not necessarily exploiting them but identifying them, usually without tools Consider the metaphor of the house – a pen-test will walk through the first door and call it done, while a vulnerability assessment will try all doors and windows and give you a complete report

9. About This Presentation This methodology comes from my own work at my company, and is the basis of how we do things Many other companies offer similar services Many different methodologies and tools are available to perform these types of assessment – for the public sector you can also “partner” with someone else To take a vendor-neutral position, the work of the “Open Source Security Testing Methodology Manual” can be used to provide a baseline You can get this document for free from: http://www.isecom.org/ A Vulnerability Assessment methodology is only a start, a good background in computer security is essential for interpreting the results and doing something about it

10. Defining Scope Before beginning any work, you must carefully define your scope: –Which machines to test (IP ranges or addresses) –Which machines to exclude –Which times are good and bad to perform testing –Are you going to test for Denial of Service susceptibility? –Contact information for both the tester and the testee. This is needed in case there is a problem and the assessment must be stopped –Type of assessment to be done - Black Box (nothing is known), Grey Box (some things are known), or White Box (all things are known) –This presentation assumes a Grey Box assessment –Make sure you have legal rights to do the assessment!

11. Network Survey Perform some data collection to get the more information for your assessment In a Black Box situation, you may have to get all of this information the hard way, instead of just asking Ask the testee to identify all known hosts on the segment (be prepared to find ones they didn’t know about) Find out what services are running on the hosts – this may influence your methodology or tools (ie, heavily reliant on Microsoft or UNIX platforms) Analyze network maps, with an emphasis on DMZ and Internet-facing connections Analyze ‘whois’ and ARIN data to determine ownership of domains, etc. Identify DNS information for the target (hostnames, mail MX records, etc.)

12. Understanding TCP/IP Most Internet-connected hosts speak TCP/IP Version 4 TCP/IP Version 6 is available, and has a much larger address space, as well as enhanced security TCP/IP is generally referred to as including related protocols such as ICMP and UDP It is important to know how TCP/IP and related protocols work in order to secure your hosts, firewalls and routers

13. TCP/IP and the OSI Model Note that Internet (IP) is lower and talks IP and ICMP TCP and UDP may be on top of IP (and others as well)

14. Understanding IP At the IP layer, we are concerned about hosts being available - routing, congestion, etc. The IP layers uses ICMP (Internet Control Message Protocol) packets to pass information The most common types of ICMP messages are: –“0 Echo Reply” and “8 Echo” (used in ping) –“3 Destination Unreachable” (sometimes used to convey information from a higher layer, like UDP or TCP ports or IP hosts not being available) –“30 Traceroute” (used in traceroute) –“5 Redirect” (used to indicate a better route) See http://www.iana.org/assignments/icmp-parameters

15. Understanding ICMP In order to understand what we have on our network, it is useful to “ping” each IP in a range of potentially live addresses This is known as a “ping sweep” Essentially, we are sending an ICMP Echo Request to each IP address in a list or range, and hoping to get an ICMP Echo Reply back If we get a reply, we assume that the host is live, and connected to the Internet If we don’t get a reply, the host *may* not be live, but it may also be behind a firewall, or have some other type of protection

16. Activity #1: Ping Sweep with NMAP First install WinPCap 3.0 from the CD Then install NMAPNT to a directory on your computer Once this is done, attempt to ping- sweep our classroom network to find out who is “live” nmap -v -sP 192.168.2.0/24 Scroll up, see which hosts are live Did any host names resolve?

17. The 3-Way TCP Handshake One important TCP/IP concept to understand is the TCP 3-way handshake TCP is a connection oriented protocol - both the client and the server want to know when a connection is open, and when it can be closed The handshake is how a node will negotiate a TCP connection with another node (for example to get a web page or FTP transfer a file)

18. The 3-Way TCP Handshake

19. TCP Port Scanning Once we know what hosts are live (via ICMP ping) we want to know what services are available on the hosts (for example 25/STMP, 21/FTP, 80/WWW, 443/HTTPS, etc.) Every port is associated with a process or service. If the port is open, the associated program is probably running Look for open, as well as closed and filtered ports. (filtered implies a firewall or similar device dropped the packets instead of allowing an “ICMP Port Unreachable” message. Determines FW policy) Ports range from 1-65,535 for both TCP and UDP. That means you could be testing > 130k ports. You must decide if you want to: –test ALL ports (and hence have a better chance of finding results, but also taking a very long time) –Test a LIMITED number of ports (and hence possibly miss something, but do it very quickly)

20. Activity#2: TCP Connect Scanning In this exercise, pick a partner (victim) Using just their IP address, we will do a standard TCP connect scan of their computer Turn off personal firewalls (if any) nmap -v -sT 192.168.2.X -p 1-1024 Note how long this takes…. Now try all TCP ports! nmap -v -sT 192.168.2.X -p 1-65535 Get coffee… and muffins… How long did it take? Bored yet?

21. Non-TCP Connect Scanning It is also possible to scan hosts without actually completing the 3-way handshake This is faster, as we only need 2 packets, not 3 It is also sneakier, as the target may not consider the connection “made” until the final ACK arrives Thus, we may be able to scan a host without generating any log entries at all This is also the basis of many Denial of Service (DoS) attack - too many SYN packets can deplete memory and network resources and cause problems With NMAP we may scan with the -sS or other sneaky types of packet types Be warned, firewalls are hip to this trick

22. Useful TCP Scanning One great use of TCP port scanning is to quickly identify services, especially when they just discovered a new security flaw and you aren’t sure which machines need updates For example: –nmap -sT -p 80 192.168.2.X/24 (find all machines running web servers) –nmap -sT -p 5631 192.168.2.X/24 (find all machines running PC Anywhere) –nmap -sT -p 25 192.168.2.X/24 (find all machines running a mail server) You get the idea...

23. ID System and Services Can use software such as nmap or queso to identify the target systems operating system (due to quirks in the vendor-specific implementation of TCP/IP) Note that OS signatures can be spoofed Also, specific port sets are very common to specific operating systems (e.g. port 445 is almost always Windows 2000+) We can also fingerprint services, nmap default Connect to ports using a program such as Telnet or NetCat to grab banners or other useful information

24. Activity #3: Grabbing Banners In this case, we want to manually connect to the web server to see what version it is telnet 192.168.2.171 80 type the following (exactly) GET / HTTP/1.1 Then hit “enter” twice This can be done for some (but not all) services Also note that banners can (and should) be changed to confuse and irritate hackers

25. UDP Port Scanning UDP is a connectionless protocol, so it is a little bit harder to scan With a UDP scan, you send a packet to each UDP port on a host, and if you *do* get a response back, it is probably an “ICMP Port Unreachable” type message, indicating failure It could also be that there is a firewall in the way that is silently dropping UDP packets before the target host sees them and replies with an ICMP message Even assuming that there *is* a listening service, it might be tough to figure out which one, except based on the port number

26. Activity #4: UDP Scanning Fortunately for us, there is no firewall in the way, and we are using Windows boxes which use UDP, so we should get good results Pick a victim and scan them: nmap -v -sU -p 1-1024 192.168.2.X Note the ever popular 137/UDP and 138/UDP for Windows NetBIOS networking If you ever see this on your public segment, be very worried (and then go firewall it)

27. Vulnerability Scanning Once you have mapped your network, use a variety (no less than two) of security scanning tools from different sources to find vulnerabilities These tools typically have a database of vulnerability signatures, just like anti-virus Ideally, the program will test every signature in its database against every port (not just expected ports) This should find known (ie, documented and in the signature database) vulnerabilities on the target server Sometimes, single-purpose scripts must be used, or signatures created for the tools

28. Vulnerability Scanning Regular updates of the signature database is necessary Manual analysis of services, especially “odd” ones is usually necessary – use the Internet to look for vulnerabilities, discussion threads, do google searches, check dshield.org, incidents.org, etc. Just because a tool reports a vulnerability doesn’t mean it is actually there! This is a false positive

29. Vulnerability Verification Vulnerability Assessment tools typically operate on a “chat” sequence – send something, get something back, repeat as necessary and analyze This can lead to false positives if the software isn’t intelligent enough to assess the information it gets False positives can also be tagged through reading service banners, etc. (for example, what if someone patched the source code flaw but was still at a “known vulnerable” version of the software?) False positives are the bane of the security analyst, but not nearly as embarrassing as false negatives In some cases, its necessary to manually test using Telnet or other tools to determine if the vulnerability is real

30. Example: Mail Relay One false positive that frequently comes up is that of an open mail relay This means that a target mail server will forward email from anyone, to anyone Spammers use this to send their junk mail without getting caught Subscription services exist to find open relays, and then ban them. This is great if you want to get less spam, but not so great if your company gets on the list, since subscribers won’t be able to get any email from your company. Some mail servers are not exactly “obvious” about whether they will relay or not. GroupWise will gladly accept the email as if it was going to forward it, but then silently stick it into a junk directory

31. Example: Mail Relay >> telnet lachniet.com 25 << 220 lachniet.hn.org ESMTP Sendmail 8.12.5/8.12.5; Mon, 17 Feb 2003 16:48:12 –0500 >> helo bigfake.com << 250 lachniet.hn.org Hello host64.lan.sequoianet.com [207.73.216.64], pleased to meet you >> mail from: macul@nowhere.org << 250 2.1.0 macul@nowhere.org... Sender ok >> rcpt to: pres@whitehouse.gov << 550 5.7.1 pres@whitehouse.org... Relaying denied This is good! If you saw the following you would almost certainly have an open mail relay! (or GroupWise) << 250 2.1.5 pres@whitehouse.gov... Recipient ok

32. Example: Mail Relay Essentially, we just did manually what every Internet email program does automatically This technique is also known as “fakemail” since you can make email appear to come from anyone or anything I sometimes like to harass friends with emails from god@heaven.org, and so on (its not actually illegal. Yet) This is also sometimes used to trick people – you would probably open an attachment that seemed to come from your spouse, but not from me Note that the BEST way of testing this is to make yourself be the recipient. If you get an email in your mailbox, then it is actually relaying This is what the ORDB service does, and there is really no disputing their findings

33. Nessus The open-source Nessus Project is highly regarded as a low-cost option –Runs on UNIX/Linux operating systems –Completely open-source for program and vulnerability databases –Customizable, possible to write your own NASL signatures –Provides for basic reporting, with ways to import into a database for correlation and making pretty reports –Nessus is updated frequently and actively supported by the authors –Runs through a client-server architecture – you may have one central scanner and many clients –Supports SSL web servers!

34. Nessus Nessus is (in my personal opinion) the best of the vulnerability assessment tools, primarily because of price! Nessus is used by just about everyone who does vulnerability testing, either as the primary tool or the supplemental tool Nessus is client-server based, and uses strong encryption and authentication, and runs on UNIX Nessus has a database of over 2,000 known vulnerabilities There are also flexible (if difficult to configure) features such as reporting and modules

35. Nessus - Client Server Nessus allows multiple simultaneous users, jobs, and targets, so you can set up one Nessus server and let multiple people use it

36. Nessus WX While Nessus runs on UNIX, it is possible to run a Client on Windows This is particularly useful if you are not a UNIX person, or if you like to quickly generate PDF reports of findings Check out http://nessuswx.nessus.org/ for more information It has most of the features, and is fairly user friendly You might consider setting up one Nessus box, give your IT staff NessusWX clients, and ask them to scan each server before being placed on the Internet

37. NeWT Unfortunately, we don’t have time to install nessus on UNIX or Linux However, someone identified a commercial opportunity and ported the Nessus server to the Windows environment Check out Tenable software at http://www.tenablesecurity.com/ Although not free, it may well be cheaper than hiring a UNIX geek to install and maintain it for you There are also a number of other products from Tenable that are worth looking at They offer discounts for K-12, and the pricing is reasonable for what you get!

38. Activity #5: Using NeWT Install Newt from the CD-ROM Run the plug-in update program Run NeWT Select “New Scan Task” Type in your loopback IP “127.0.0.1” Enable all but dangerous plugins Run the scan View the report - note references to CVE and CAN, as well as links to more information about the plugin and/or issue

39. Activity #6: Configuring NeWT Click on the “Configure NeWT” link (walkthrough of features) Click on the “Manage Plugins” link on the left-hand side Not the ability to create and select vulnerability profiles (this will cut your scanning time down, but you may miss something) You may also create host profiles such as “all Internet hosts” or “all windows servers” to make things easier

40. Common Vulnerabilities SANS.ORG has a list of the top 20 vulnerabilities at http://www.sans.org/top20/ Web server flaws that can lead to enhanced access –Some will give you system/root access –Some will only give you “nobody” or “guest” –Usually from default/unpatched configurations FTP Servers –Anonymous read-only access to sensitive files (such as debug files used by developers!) –Anonymous write access. Generally turns your server into a “warez” host in short order

41. Common Vulnerabilities Windows NetBIOS vulns –Open access to ports 135, 137, 139, 445, etc. –Unrestricted or open file shares –Anonymous session / null login (allows enumeration of a lot of sensitive data) –Poor or blank user passwords –Also allows for popup ads, etc. –Massive reconnaissance opportunities (last logon, etc.) 1.Microsoft SQL server –A-la the “slammer” worm –Never allow SQL to the Internet! –Also found in the MSDE package (a desktop version of SQL server that ships with many products) –Easy to attack through web logic, so you need app security

42. LanGuard A great tool for Windows environments is LanGuard from GFI This will do scans like Nessus, but is much more aware of the Windows environment Given proper authorization, it will even check the status of machines for patches, and help you to push patches to those machines that need them* There is also scripting capability built into the product, if you need more power or flexibility This may be a great way to keep all of those Windows boxes up to date!

43. Activity #7: LanGuard Install LanGuard from the CD-ROM Check for updates and restart Type in ‘127.0.0.1’ in the target box View the results - its amazing what Windows will tell you, isn’t it? Go to Scan->options, note the ability to crack passwords Also allows you to set settings (such as auditing) on multiple hosts at once, reducing maintenance overhead

44. System Back Doors / Trojans Anything that can provide remote access to a desktop is inherently dangerous –Windows Terminal Services –Citrix / Metaframe –AT&T’s Virtual Network Console (VNC) –Timbuktu –Back Orifice Trojan –Net Bus These can frequently be identified by the known ports they operate on such as 31337

45. Documenting Vulnerabilities Once the vulnerabilities have been identified and verified, they must be documented and fixed This documentation should include : –All hosts the the vulnerability –A detailed description of the vulnerability –Links to places with more information –Information on how to fix the problem –Some type of rating of the severity of the hole: High, medium, and low? Remote compromise or local compromise? Level of access granted through the hole (admin?) Information leakage? Then read the links, prioritize and go fix!

46. Use Industry Databases The most common one is the CVE at http://cve.mitre.org Common Vulnerabilities and Exposures (CVE ® ) is: A list of standardized names for vulnerabilities and other information security exposures — CVE aims to standardize the names for all publicly known vulnerabilities and security exposures. –A Dictionary, NOT a Database –A Community-Wide Effort –Freely Available for Review or Download –Currently has 2,223 vulnerabilities

47. Use Industry Databases CVE is useful because it provides a common baseline for describing and correlating vulnerabilities –Gives a standard name, based on CVE entry –This allows you to correlate results between multiple tools that supply CVE entries Uses a review process to make sure that entries are well considered –Starts with a nomination as a CAN (didate) –Is confirmed as a CVE (vulnerability) by the editorial board

48. CVE Example

49. Creating the Toolkit Commercial Scanners give a certain level of comfort, and are often well supported and robust Internet Security Systems (iss.net) has a number of good (but very expensive) products: –Internet Scanner (for typical Vuln Assessments) –Database Scanner (for focused DB analysis) –Wireless Scanner eEye.com has the Retina Network Security Scanner that is pretty well regarded

50. Creating the Toolkit Other commercial vendors to consider: –Foundstone (www.foundstone.com) –Vigilante (www.vigilante.com) –NetIQ (www.netiq.com) –Latis (www.latis.com) –Gfi LanGuard (www.gfi.com) –Heat (www.heatscanner.com) Your mileage may vary – check for reviews on the Internet, etc. Some of the best tools are actually free

51. Creating the Toolkit Create a list of security web sites that contain information (and working attack scripts) for vulnerabilities The best is: packetstormsecurity.org Others that are essential include: –www.sans.org: A source for training, as well as student papers and example security policies –www.securityfocus.com: A general web site (now owned by Symantec) that hosts a lot of discussion lists (such as pen-test) Good for finding information on specific products, etc.

52. Web Applications Where a conventional application requires physical proximity and client software, web access is intended to be accessible to the widest possible audience As a result, they are typically open to the entire Internet community It is logical to assume that the larger the user community is, the more likely it is that someone may choose to analyze the security of the application Due to the fact that a good hacker can effectively cover their tracks and anonymously probe the security of applications, there is very little risk to the hacker to do so (as compared to an attack that requires physical proximity) Thus, web applications may require more security than others

53. Conceptual Overview of Web Apps Web applications are generally developed in Tiers –User / Client –Web Server –Business Logic –Database In many cases, the database is the same one that holds other critical organizational data!

54. Logical / Physical Overview Let us pretend that we are looking at a State of Michigan web site (note: this is only pretending!!) The purpose of the web site is to allow “self service” access to Human Resources information: –Pay stubs, deductions, direct deposit bank name –Demographic information –Emergency Contact information –Education –Dependants (names, ages) The application was written by a combination of internal and external programmers The application was written in Microsoft.NET, and communicates with the actual State of Michigan Human Resources HRMN system

55. Logical / Physical Overview

56. In order for this all to work, the HRMN system needs to trust the self service web application to access data Thus, the program logic of the self service application may be critically important, responsible for ensuring that: –Users are properly authenticated –Users are authorized to use the system –Adequate logging of activity takes place –The Internet-facing components do not have known security flaws In short, a part of the security of the human resources database now lies in an Internet-facing web application, possibly bypassing the more established and mature database security What could possibly go wrong? Implications

57. What Can Go Wrong??? Frankly, a lot….. Secure programming practices have not really been taught in higher education Productivity pressures have made security a secondary priority A lot of insecure web sites have been implemented In fact, a recent study found that no less than 92% of web pages surveyed over a 4-year period had serious security flaws http://www.vnunet.com/News/1152521 Are you confident that your web site is within the fortunate 8%? If you don’t have an explicit set of controls for application development, security and ongoing testing, you shouldn’t be!

58. Recent Example http://seattlepi.nwsource.com/national/apus_story.asp?cat egory=1110&slug=Hackers%20State%20Computers Friday, February 13, 2004 · Last updated 8:31 p.m. PT SACRAMENTO, Calif. -- Hackers broke into a state agency's server containing the sensitive personal information of tens of thousands of people who work as nannies, butlers, and gardeners, and those who employ them. The hackers gained access to employee's names, Social Security numbers and wage records, and some employers' Social Security numbers, Callori said. This is, unfortunately, more than enough information to cause harm, such as identity theft

59. Types of Flaws in Web Applications Lets look at the statistics from the previously quoted article: –Cross-site scripting (80 per cent) –SQL injection (62 per cent) –Parameter tampering (60 per cent) –Cookie poisoning (37 per cent) –Database server (33 per cent) –Web server (23 per cent) –Buffer overflow (19 per cent) My personal experience indicates that these numbers are about right Any one of these flaws could lead to a disclosure of critical or protected data Lets look at a few examples

60. Cross-Site Scripting Occurs when input from a user is not “sanitized” before being re-displayed on a web site For example, an Internet guest book may allow you to enter a message, along with the time and date that you visited a web site It may be possible to craft this message in such a way that users’ Internet browsers interpret the message as HTML code, instead of plain text If this happens, person A can make it appear to person B’s computer that a web site (presumably a trusted one) is the source of a tricky attack This commonly used to do things like steal authentication information, or redirect to a “phishing” web site to harvest passwords, credit card numbers or bank account numbers

61. Real Life Example of CSS While working for a customer, analyzing a well known SSL VPN appliance, I discovered a CSS bug I then created a proof of concept to demonstrate this bug I created a (virtually) identical copy of the VPN server’s login page, and put this on a server that I had control of I then created a special CSS web address (URL) that, when entered, would redirect the user transparently to this external web site The fake web site said “session has timed out, please log in again” message, and had a place to log in again When the user entered their username and password on the fake login, this information was written to disk on my “hacker” computer, and the user was redirected back to the *real* VPN server’s “incorrect password” page The end user would simply think that their session had timed out, and that they had mis-typed their password

62. SQL Injection The next most common flaw, SQL injection, is worse In this case, a hacker would find a part of the application code that did not perform proper input sanitization By passing special characters in form fields (e.g. a place to type in a query or address) it is then possible to embed additional commands for the HR database Since the application server is “trusted” by the back end database, it assumes that the request is legitimate and performs the query The “normal” results, as well as the database commands entered by the hacker are displayed in the browser This attack can be used to completely bypass application and database security In our working example, an identity thief hacker could then print out the names, SSN#’s and addresses of all employees and use this to steal their ID

63. Real Life Example of SQL Injection While analyzing a production Internet web site during a WASA (Web Application Security Analysis) I discovered a SQL injection flaw in the application code With this knowledge, I configured a program called “data thief” to assist me in demonstrating the vulnerability Using data thief, I was able to copy the entire back-end database, with all of the data, including usernames and passwords, across the Internet to my computer Using this database of logins and passwords, I was able to log in, and access the application as an administrator At that point, I also had the ability to run software on the database server, which was on the internal, protected network If I were a bad guy, I could have used this access to compromise additional systems on the Internal network

64. Real Life SQL Injection Example

65. Other Web Application Risks There are a number of other risks that need to be looked at: –Ability to bypass authentication systems –Ability to steal user “sessions” –Flaws in the underlying operating system / web server –Flaws in the “chain of trust” (relying on an additional system for some security component such as a SSO (Single Sign On) system) –Flaws that allow a hacker to deny service to the system (e.g. by using all of the licensed connections, flooding the server, or causing a software crash) –Reliance on client-side security (especially client-side scripting) And so on….

66. How to Protect Your Organization There are several things you want to consider when analyzing web applications: –Has a design of the system been validated both by app. Dev, DBA and I.T. security staff? –Has an adequate System Development Life Cycle (SDLC) been used throughout the project to promote consistent and quality code? –Have programmers been trained in secure programming standards? Is there an internal Q.C.? –Has a proper change control system been used to develop and maintain the system? –Has the system had a formal web application security assessment? Is the system “hardened”? (many internal and external resources can help with this)

67. Security Products – Web Application Although this is a relatively new area, a number of products exist to assist an I.T. analyst One such product, the one that is used at Analysts International, is “SPI WebInspect” from SPI Dynamics, Inc. http://www.spidynamics.com This product is very flexible, and can save thousands of hours of manual assessment time Can export pieces of data, print detailed reports, and maintain full information about the scanning activity that has occurred One of the better web application security tools available, and reasonably priced As always, don’t take my word for it, do a product evaluation of your own

68. Security Best Practices A lot of information is available for programmers, auditors and I.T. staff on web application security issues The most referenced one is the Open Web Application Security Project at http://www.owasp.org OWASP has specific guidelines for what programmers should and shouldn’t do, as well as detailed information on what the issues are and how they can be detected For more information on how to go about assessing an application using accepted methods, check out “Open Source Security Testing Methodology Manual” at http://www.isecom.org/projects/osstmm.shtml A number of product-specific web sites for major vendors also exist. A good one for both theory and practice for Microsoft is at: http://www.microsoft.com/downloads/details.aspx?displaylang =en&FamilyID=055FF772-97FE-41B8-A58C-BF9C6593F25E

69. Good Books! Any of the “Hacking Exposed” by Stuart McClure, et al books are actually quite good They can be picked up in the average Barnes and Noble / Borders book store Editions exist for NT, Windows 2000, and Linux Contain detailed, step-by-step instructions on how the attacks work You should hack yourself! This is the best way to understand how to do a vulnerability assessment Also, be warned, this information is out there for anyone else to buy as well

70. Discussion This presentation to be available at: http://lachniet.com/powerpoint Mark Lachniet CISSP, CISA, MCSE, MCNE, CCSE, LPIC-1, TICSA Technical Director, Security Group Analysts International (517) 336-1004 (voice) (517) 336-1100 (fax) mailto: mlachniet@analysts.com