On Sat, 10 Apr 1999, Technical Incursion Countermeasures wrote:
> Woo! lets open the floodgates for the ethics arguments..
>
> But my argument against hiring a "hacker" is this..
>
> A penetration test at any level is not going to find you a cure for your
> security problems.. its not even going to find them all - since most of
> your real security problems will be related to your staff and their
> attitudes, not to your technical security.
This is very true....
> In short "Security is a people problem" so by hiring a hacker all you do is :
> 1. expose your organisation to possibly un-ethical people
True...
> 2. gain an assessment that does not give any positive assurance (ie. it can
> only show what the hacker found - if the hacker is not good then he won't
> find the holes that a better hacker will find)
Very true...
> 3. waste your orgs money (penetration testing is _always_ expensive and if
> its cheap then why not go and buy ISS yourself - its all they are doing -
> sometimes the expensive ones are too)
Many times this is true too, unfortunately
> You would be better to start with a controls based audit of your security
> to see if the mechanisms are in place to ensure the security like:
>
> change control on the firewall rulesets
> ensuring that user's accesses get changed as their employment changes
> ensuring that there are well known "usage guidelines"
> ensuring that there are good procedures for handling calls from users
> asking for passwrods to be renewed (aka "social engineering")
That's why doing a penetration test just after installation of a system is
less interesting than doing a test after the systems has been operational
for a longer time.... that's when the config errors, holes/bugs, policy
violations pop up... Also penetration testing is good as part of an
overall audit - to determine the real level of security posture....
> once the org passes a controls audit - then you can start doing hard
> testing against the controls to see if they are effective. And its then
Yep.... I see penetration testing as part of an audit/assesment where you
do kind of the following:
1) evaluate the security policy - if there is any -
2) determine the consensus within the organisation regarding security,
that is: how do people (managers, sysadmins, users) perceive security and
how do people think it should be. Maybe you can do some
quick-and-dirty risk analysis: where (e.g. on what network segments) is
what information stored and what security is needed where...
3) evaluate organisational procedures, guidelines, practices, etc..
4) do some operational testing.... see what's flying over the wire (e.g.,
is it really true that they only use IP based network and
application protocols or do you still see DECNET and IPX flying by)
Determine what level of security is offered by individual systems and
network components (penetration testing...)
Now it's getting to the hard part.... you'll have all these
mismatches...:-)) Procedures do not cover policies, policies do not
correspond with actual security needs and technology used Systems are not
installed according to policies, or following the right procedures. The
network is polluted with old, already phased out protocols. External
connections exist, nobody told you about, etc...
> that you need someone with a good technical knowledge - I avoid "Hacker"
> now days as it implies some idiot who's seen "Sneakers" or is a member of
> 2600 rather than a competent tester/auditor
Gr. Arjan
----
Eat hard
Sleep hard
Wear glasses if you need them
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
