Penetration Testing mailing list archives
Re: Moving from Defense to Offense (or vice versa) to secure your network
From: James Eaton-Lee <james.mailing () gmail com>
Date: Sun, 27 Nov 2005 04:02:08 +0000
On Sat, 2005-11-26 at 17:37 -0800, Erin Carroll wrote:
All,
<snip>
So I was hoping some list members would share some similar experiences with us. 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 someone (one of the many) who got into the industry thanks to a lifelong interest in technology and how to overstep the bounds of what it was designed to do (just as with many things - I was always one of the kids at school trying to explore the service ducts and ceiling crawlspaces), and since I've always been substantially self-propelled in the industry, a large proportion of my time has been spent thinking "how would I break this" alongside "how would I set this up". My experience of network administration is that people benefiting from the same approach (either who've come from a similar background, have spend time pentesting professionally, or who just 'have the nouse' for it) are often (not always) far better suited to laterally think around some of these issues than more cleancut candidates who've ticked all of the boxes and jumped through all of the hoops (which mostly nowadays means Computer Science graduates and recent MCSE/CCNA qualifiers - and frequently those who've qualified with security certs too). I particularly find this to be the case when dealing with some of the initially less obvious (and more monotonous) aspects of security, such as filing system permissions. A perfect example of this jumped out at me the other day - resetting permissions on some system files on a (hardened) windows server, a colleague (responsible for something security-related in a *large* organisation) suggested that rather than untick *every* everyone/deny permission (seven clicks) which were breaking some maintenance (which required access to the file), I just tick full control for the everyone group (quicker, at a paltry one click), with (I'm presuming he thought) much the same effect. D'oh! I don't think in this instance, the individual in question was unaware of the risks here (and I think that if he'd considered it a little more thoroughly, he wouldn't have suggested this in the first place), but it is a perfect example of the degree to which routine and thinking-inside-the-box catch up with you. As a 'defensive' security pro, a small permission change on an obscure system file doesn't seem like much when stacked up against firewalls, IPSs, etc, but as anyone with experience being 'offensive', you have an intuitive understanding of the potential of the above for system compromise, privilege escalation, and/or abusing facilities and resources!
Is it worth it to cross-train in some manner? How have you sold someone on the advantages of penetration-testing your network to quantify and test the effectiveness of your existing defenses?
Yes, I absolutely think that it's worth raising awareness of 'the other' way of doing things for both categories. I think that those who're significantly more towards the hacker-y end of the spectrum often overlook quite obvious factors in the security of systems, such as reliability, reporting and monitoring, which you mention. The biggest point of abrasion that I've noticed in this respect is the degree to which those more deeply entangled with security tend to objectify security as a goal. This isn't the only point of friction I've seen, though, because I think this extends further than security, even with people who are technically inclined. In a previous life (in an SME rather than a large enterprise), I worked with a company who had hired a (fairly old, fairly conservative) unix admin to administrate their (NT) systems. Thanks to an inability (or unwillingness) to shift on issues, either technically or processwise, causing considerable friction. On one occasion, working with a database-heavy application that the business had bought from a vendor, the unix admin (responsible for all of the IT systems) point blank refused to make any changes to the database server (where the changes involved inserting a table into a database entirely unrelated to the app) on the dual grounds that 'the vendor should support the database server as well as the app' and '[he] wouldn't touch that windows database stuff' (he'd wanted a unix-based solution instead of the windows app). The net result for the business here was that they required alterations made to a portion of their infrastructure that the vendor wouldn't touch (because, quite rightly, it was nothing to do with their app) and that the staff member employed to manage the infrastructure wouldn't touch because he didn't like the platform and insisted that the vendor should support it even after they had refused to. Since I was onsite (for an entirely different purpose - we were actually doing business with them) I made the change for them, but poor communication between business people and technical people could quite easily have caused them serious problems, especially with only one guy having any idea how their systems were strung together. The viewpoint from the other side (and this starts to be increasingly, and detrimentally, the case as you move closer to 'business' and 'management') is that security (and IT, for that matter) are just tools, and that there's a cost/benefit decision to be made at every turning point. Good-a point as this is, the detriment (in my opinion) tends to derive from the fact that business and management staff have a poorer understanding of the security (or infrastructure) implications of any given system or factor than (mindful) security professionals do of cost/benefit analysis! In another previous life (again, in an SME), I had to compensate for a complete refusal to budge on this issue (money was involved) in upgrading a database server which was causing users of an application to have to wait up to two minutes between clicks retrieving and updating data (whilst on the phone to customers) by spending weeks performing an exhaustive analysis of virtually every system statistic available in order to make business staff agree that there was indeed a problem, even though the virtual unusability of the system was probably costing them bags of money, and the complaints of the users were loud and prolonged! In the end, it's all about balance, between defence and offence, between business and 'pure' technology or security, and many other things toboot. I'm concretely of the opinion that a better understanding of how systems are compromised is beneficial to IT staff (and business staff for that matter). In many instances, the problem here is that IT staff are quite frequently poorly versed in the technology they're working with (particularly in the wintel world) to the point at which they need to learn more about this (particularly TCP/IP - wintel guys are often really bad with networking) before learning about security is really doable in a meaningful way. Hope some of this (and the anecdot^H^H^H^H^H^H^Hexamples) helps! ;) - James.
I would be interested to hear some cases you have run into out there. -- Erin Carroll "Do Not Taunt Happy-Fun Ball"
-- James (njan) Eaton-Lee | 10807960 Semper Monemus Sed Non Audiunt, Ergo Lartus - (Jean-Croix) sites: http://www.bsrf.org.uk - http://www.security-forums.com ca: https://www.cacert.org/index.php?id=3
Attachment:
smime.p7s
Description:
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)