Penetration Testing mailing list archives
RE: Moving from Defense to Offense (or vice versa) to secure your network
From: "Evans, Arian" <Arian.Evans () fishnetsecurity com>
Date: Mon, 28 Nov 2005 15:00:03 -0600
-----Original Message----- From: Erin Carroll [mailto:amoeba () amoebazone com] Sent: Saturday, November 26, 2005 7:37 PM To: pen-test () securityfocus com
[...]
How many of you have switched between offense/defense and what were some of the stumbling blocks or key differences you found in how you approached your goals?
As previously mentioned in this thread, these are two *very* different skills/knowledge bases. When hiring brand-name pen-testing groups in a previous life I found that most individuals' comprehension of the art of defense was inversely proportional to skill/knowledge-base in the art of attack. Common example issues w/attacker(consultants): 1)--no idea how Windows/AD/GPO security worked. Baffled by designs I implemented that prevented compromise techniques. </RestrictAnonymous=2> 2)--common misunderstandings of network/protocol analysis, and filtering rules distinguishing between TCP/UDP implemented to limit attacks on things like old versions of BIND (e.g.-attacks typically TCP-based so easy to block completely; when UDP based were trivial to filter for) 3)--Same as #2 re: arp-cache poisoning; rarely understood VLANs; VLAN trunking; master trunk ports; why they were limited; what secure switch-fabric/VLAN design actually entailed. No real-world enterprise experience. 4)--Same as #2 re: web app security. Little/limited understanding of XSS and SQLi exploitation abilities, impact, and sound mitigation (still today). 5)--context-less findings. No solution here for outside consultant reports... requires internal business/org knowledge.
Is it worth it to cross-train in some manner?
Yes/Know (pun). Developers/business-owners will rarely fix their app/code unless you can demonstrate a successful compromise. Same with the Windows admin that isn't willing to address headaches with RA=2 (Mac/*nix clients, legacy DCs, etc) until effective compromise is demonstrated. However...: I believe "How to Hack" classes are mostly wasted/useless for skills-based objectives (as frequently sold). Admins and developers need to focus on secure design/architecture, implementation, and threat-mitigation. The behavioral result of "how to hack" is strictly awareness change (knowledge-based, not skills-based gains) for 95+% of people. (which has *a* value but different value...) Teaching someone how to properly use parameterized SQL is entirely different from teaching someone the art of SQL Injection. I do not believe that you need to know one to address the other. (Unless a specific security domain is in your defined area of responsibility.)
How have you sold someone on the advantages of penetration-testing your network to quantify and test the effectiveness of your existing defenses?
Validation. Human beings make mistakes. After imitation, mistakes are one of the key ways humans learn. Considering today's IT/security landscape is chiefly built upon security mistakes, learning via imitation (of questionable behaviors) + natural human propensity for error = necessary validation. This is demonstrated by the fact even our security controls (firewalls, AV, etc.) can be the key points of security weakness in our enterprise.
I would be interested to hear some cases you have run into out there.
It is an interesting subject. I have irritated "security professionals" before by informing them that "how to hack" is not what they want. "How to Hack" is cool, sexy, gets attention, gets budget dollars, etc. It's what "security professionals" tend to request in training RFPs for developers or admins, though I do not think it is that useful. It's why ads for "secure cars" show slow-motion video of the vehicle being *smashed*, instead of video of endless engineering-specification meetings for side-impact airbags and quarter-panel crumple-zones. But here is the part of the analogy that interests me: Do automotive engineers responsible for implementing properly designed/deployed airbags need to study accidents to design/implement them....perform "fault injection" on vehicles to learn how to improve them? I do not know. I suspect that the two aspects (fault injection; implement fault-tolerance) are disparate fields in automotive engineering, much like I believe they are in IT. Disclaimer: the above is all my opinion. I have been wrong before...a few times..., -ae ------------------------------------------------------------------------------ Audit your website security with Acunetix Web Vulnerability Scanner: Hackers are concentrating their efforts on attacking applications on your website. Up to 75% of cyber attacks are launched on shopping carts, forms, login pages, dynamic content etc. Firewalls, SSL and locked-down servers are futile against web application hacking. Check your website for vulnerabilities to SQL injection, Cross site scripting and other web attacks before hackers do! Download Trial at: http://www.securityfocus.com/sponsor/pen-test_050831 -------------------------------------------------------------------------------
Current thread:
- Moving from Defense to Offense (or vice versa) to secure your network Erin Carroll (Nov 26)
- Re: Moving from Defense to Offense (or vice versa) to secure your network James Eaton-Lee (Nov 27)
- Re: Moving from Defense to Offense (or vice versa) to secure your network Byron Sonne (Nov 27)
- Re: Moving from Defense to Offense (or vice versa) to secure your network Frederic Charpentier (Nov 27)
- Re: Moving from Defense to Offense (or vice versa) to secure your network Bob Radvanovsky (Nov 27)
- RE: Moving from Defense to Offense (or vice versa) to secure your network Erin Carroll (Nov 27)
- <Possible follow-ups>
- RE: Moving from Defense to Offense (or vice versa) to secure your network Evans, Arian (Nov 28)