From: James Eaton-Lee (james.mailing@gmail.com)
Date: Sat Nov 26 2005 - 23:02:08 EST
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
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:55:12 EDT