Rob
________________________________
Rob Davis <rda...@lucentncg.com>
Lucent Technologies-Network Consulting Group
Network Consultant
http://www.lucentncg.com
(972) 419-3815
1-800-SKY-PAGE #126-9384
-----Original Message-----
From: jpri...@usa.net [mailto:jpri...@usa.net]
Sent: Tuesday, June 02, 1998 8:42 AM
To: fire...@lists.gnac.net
Cc: ntsec...@iss.net
Subject: [NTSEC] Ballista or ISS.
TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majo...@iss.net
Contact ntsecuri...@iss.net for help with any problems!
------------------------------------------------------------------------
---
Looks like NASA evaluated these 2 scanners. Does anyone know which
scanner does the most comprehensive assessment of NT checks?
>Date: Thu, 28 May 1998 14:47:16 -0700
>To: "Adams MM(Mark) at MSXSSC" <MA18...@MSXSSC.shell.com>,
> "'secu...@wwa.com'" <secu...@wwa.com>
>From: David P Gilliam <david.p...@jpl.nasa.gov>
>Subject: Re: [Secure-NT] Ballista or ISS?
>Resent-From: secu...@wwa.com
>
>We evaluated both products. We found that ISS scanned much more
quickly
>and the reporting tool was far better than Ballista. Additionally,
>Ballista, sometimes hung during scans or crashed the systems it was
>scanning. Need I say more?
>
>At 04:24 PM 5/28/98 -0500, Adams MM(Mark) at MSXSSC wrote:
>>Can anyone make a recommendation between Ballista and ISS for
performing
>>security auditing of an NT network?
>>
>>Mark R. Adams
>>Information Security Specialist
>>Desktop Infrastructure Deliveries - Americas
>>Shell Services International, Inc. Houston, TX
>>Mail - mark...@shellus.com
>>
>>
>>
>David
>
>David P Gilliam, Ph.D. | E-Mail : david.p...@jpl.nasa.gov
>Jet Propulsion Laboratory | Phone : (818) 354-0900
>Network & Computer Security Group | Fax : (818) 393-1377
>M/S 144-210 |
>4800 Oak Grove Dr. |
>Pasadena, CA 91109-8099 |
>
>
____________________________________________________________________
Get free e-mail and a permanent address at
http://www.netaddress.com/?N=1
>Looks like NASA evaluated these 2 scanners. Does anyone know which scanner
does the most comprehensive assessment of NT checks?
Last time I counted, they had around 30 NT/Windows checks, and we had about
140.
-----------------------------------------------------------
David LeBlanc
Internet Security Systems, Inc. | Voice: (678)443-6138
300 Embassy Row. | Fax: (678)443-6479
6000 Peachtree-Dunwoody Road NE | E-Mail: dleb...@iss.net
Atlanta, GA 30328 | www: http://www.iss.net/
Thanks for your input. May I have your clarification. Do you mean ISS RUNS
beeter on NT or it scan NT based network more effectively. Likewise, do you
mean Ballista run better on UNIX or it scan a UNIX based network.
Thanks
iCefoX
Davis, Rob wrote:
> [To unsubscribe, send mail to majo...@lists.gnac.net with
> "unsubscribe firewalls" in the body of the message.]
> -
> I have used both extensively. I think ISS does a better job with NT,
> but Ballista does a MUCH better job with UNIX. If you have the money
> use both. Ballista will crash a host machine if you enable certain
> checks - however, you are warned about the possibility :)
>
> Rob
> ________________________________
> Rob Davis <rda...@lucentncg.com>
> Lucent Technologies-Network Consulting Group
> Network Consultant
> http://www.lucentncg.com
> (972) 419-3815
> 1-800-SKY-PAGE #126-9384
>
> -----Original Message-----
> From: jpri...@usa.net [mailto:jpri...@usa.net]
> Sent: Tuesday, June 02, 1998 8:42 AM
> To: fire...@lists.gnac.net
> Cc: ntsec...@iss.net
> Subject: [NTSEC] Ballista or ISS.
>
> TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majo...@iss.net
> Contact ntsecuri...@iss.net for help with any problems!
> ------------------------------------------------------------------------
> ---
>
> Looks like NASA evaluated these 2 scanners. Does anyone know which
> scanner does the most comprehensive assessment of NT checks?
>
How many of those 140 checks are "localhost" vulnerabilities --- things
that only make a difference if you have obtained the ability to run
arbitrary commands on an NT host already? Ballista has more Unix checks
than ISS (I may be wrong), and none of them are "localhost" checks, which
are out of the scope of a remote scanner.
How many of those 140 checks could potentially require a password to
access the remote server, if the winreg pipe is made unavailable to null
sessions? Ballista tries not to include tests that won't work without
access, because including them gives people the impression that we can
test for them no matter what.
And, just out of curiousity, how many of those 140 checks are simple
registry tests? By simple, I mean that the test can be executed by
retrieving a single piece of data from the registry and analyzing it
offline.
Of the "30" (not quoted out of derision, I just don't know how many NT
checks we have exactly right now) NT checks we have, how many of those
checks can you do from the Unix version of your scanner? Do you intend to
continue full support for ISS for Unix platforms?
Of course, we both know that comparing numbers of checks side by side is a
silly excercise, not just because we count checks differently, but also
because (this is important) having a check doesn't mean that it works.
What's more important (by far) is to know how accurate the scanners are.
How many more vulnerabilities does ISS find than Ballista? Against an
arbitrary host with a known set of vulnerabilities, how close are the
results of the ISS scan to the actual vulnerabilities on that host?
Incidentally, for people that are concerned about scanning speed, you may
notice that Ballista also causes far more network traffic than ISS.
There's a reason for this.
Nota bene: I'm biased not only in that I work for Network Associates but
also in that I have involvement with the development of the Ballista
scanner.
-----------------------------------------------------------------------------
Thomas H. Ptacek The Company Formerly Known As Secure Networks, Inc.
-----------------------------------------------------------------------------
http://www.pobox.com/~tqbf "If you're so special, why aren't you dead?"
The question here is how complete is the coverage of the security of NT.
We're also concerned about finding out ways that a local user might be able
to compromise the security of the OS. For example, we check a number of
ways that an ordinary user might be able to gain admin access which you do
not. How simple the check is to do really has no bearing on what it means
to the user - all of these registry settings have some effect on NT's
security. Out of the over 100 NT checks which we do that you do not, I'm
sure there are a few that even you would agree are things you might want to
add. There might even be a couple I might want to add of your's.
Regardless of any of your other points, the fact remains that you are very
far behind in this area. Your product and ours have different strengths
and weaknesses - one of our strengths is the completeness of the NT checks.
In terms of whether or not the checks work, I think you'll find that every
one of the 140 NT checks work - I wrote and tested nearly every one of them
myself. If there happens to be an error somewhere (and I'm not currently
aware of any bugs) in those several thousand lines of code, then I'll go
fix it. Out of the 30-odd that your product does, I haven't personally
QA'd your app, so I can't speak to how well it does or doesn't work.
I didn't really want to get into slamming your product, but simply pulling
down your check list and comparing it against our database shows we have a
lot more NT checks than you do - I'd have gladly left the discussion at
that point.
> The question here is how complete is the coverage of the security of NT.
There are lots of things that we can do to improve our "coverage of the
security of NT". In the past, we have chosen not to do the ones that we
consider unreliable or less meaningful than the rest of our checks.
Localhost security problems are among these; our opinion has always been
that the only real way to do localhost scanning is to have a localhost
scanner (ISS has such a product, we do not).
That said, the reason we have thus far chosen not to do localhost checks
are:
1.) They are less meaningful in a "remote" context than the rest of the
problems we find; Ballista currently operates under the assumption
that remote command execution access to a machine equates directly
to system/root access.
2.) They are frequently (and in this specific case, always) less reliable
than "remote" checks. We do not have "potential" vulnerabilities and
"confirmed" vulnerabilities. We do not report vulnerabilities that we
cannot confirm are present.
3.) We do not want to include checks that are only sometimes accurate,
because we know that the majority of our clients will assume that the
presence of a check in the scanner means that we can reliably detect
that problem. If the "winreg" pipe is inaccessible to us, we cannot
reliably probe the registry, nor can you (without a password) ---
unless there's a bug in NT out there that you're not telling us about.
The difference then is that we choose not to give people the impression
that we can do something we can't.
4.) In the same vein, having localhost checks at all implies that we can
perform a meaningful localhost scan against a remote host. Neither of
us can do that in our respective remote scanners. We do not want to
give people the impression that they are more secure than they are.
One reason that does NOT apply here:
5.) It would be harder for us to do.
(Nope, registry analysis is much easier than, say, DNS checks).
> security. Out of the over 100 NT checks which we do that you do not,
> I'm
> sure there are a few that even you would agree are things you might want
> to
> add. There might even be a couple I might want to add of your's.
I expect that if you had a check in that arsenal of 100 NT checks that we
thought was valuable, we would add it. Our hope is that we will not be
forced by marketing claims to add checks that we don't think fit into the
scanner, so, hopefully, we won't be catching up to that "140 NT checks"
number of yours anytime soon in our remote scanner.
> Regardless of any of your other points, the fact remains that you are
> very
> far behind in this area.
We disagree on this point; I don't think not including bogus checks puts
us behind you technologically, and I think it puts our integrity in front
of yours.
Now, you did not answer any of my questions directly. Why don't we just
put the cards on the table and give the list a chance to come to their own
conclusions? You felt it was important to mention that you have 140 NT
checks. I feel it's important for you to share with us exactly what those
140 checks are doing. So, again:
A.) How many of the 140 NT checks you're referring to attempt to detect
"localhost" vulnerabilities, as opposed to problems that a person with
no prior access to the box could exploit?
B.) How many of those checks would work if access to the registry required
a password?
C.) How many of those checks amount to grabbing a piece of data from the
registry and analyzing it offline?
And, let's tack on another question:
D.) How many of those checks amount to ENUMERATING EVERY SINGLE POSSIBLE
CONFIGURATION of an NT security system; for example, how many
"auditing" tests do you count in that "140" number, which basically
amount to saying "auditing for XXX enabled".
Since you were personally involved in most of these checks, I don't think
this should take a huge amount of time to answer, but I apologize if it
does.
I didn't start this discussion, I merely responded to a point you made
that I think was misleading. Since the road has been paved for us to
actually compare our two products, let's talk about some "strengths" of
our product over yours --- and let's see whether the typically clued-in
readers of the "firewalls" list think these are more important than
unreliable localhost NT checks:
- The Ballista scanner has a framework for real packet filter testing
using the CAPE system, something we invented and which is unique to
our product. No other security scanner on the market can test packet
filters in the same manner as we can.
- The Ballista scanner has a framework for server-to-server DNS checks
which allows us to test for complex DNS server vulnerabilities
conclusively (by measuring the effects of their presence, not by
trying to grab VERSION.BIND records). No other security scanner on the
market can gauge vulnerability to cache corruption attacks in the same
manner as we can.
- The Ballista scanner performs most of the REAL Windows NT checks we
do from both our NT and Unix platforms. We have commited to support
the Unix platforms we claim to support, and will continue to do so.
- The Ballista scanner includes checks for many vulnerabilities that our
organization discovered and promptly published; we have never attempted
to market an "X-Force" vulnerability team, even though our vulnerability
research has (on the surface, at least) been vastly more productive
than yours. The readers of this list know about problems like the IMAP
overflow, the Ascend denial of service problem, and CheckPoint problems
because of us, and, because we found the problems, we consistantly have
checks before ISS does.
- The Ballista scanner has over two times as many CGI script tests as
ISS 5.0 for NT does, each of which represents a vulnerability that an
attacker with no prior access can exploit to gain access to the machine,
some of which represent vulnerabilities that my team discovered.
- The Ballista scanner has over two times as many denial-of-service checks
as ISS 5.0 for NT does, some of which represent vulnerabilities that my
team discovered.
- The Ballista scanner has more real RPC checks than ISS 5.0 for NT has,
many of which represent vulnerabilities my team discovered, allowing us
to more completely audit platforms like Solaris and SGI IRIX.
- The Ballista scanner performs enhanced auditing of Solaris NIS+
(including vulnerabilities my team discovered), RADIUS (including
vulnerabilities my team discovered), routers and terminal servers,
SSH (including vulnerabilities my team discovered), and SNMP (including
vulnerabilities my team discovered).
Was this an argument you really wanted to start? Do you really think that,
on the whole, your scanner is "far ahead of ours"? It sure doesn't look
like it to me.
I continue this argument because I work on Ballista and I have pride in my
work and in the capabilities of my team. I believe that we have
consistantly tried to do The Right Thing, even when our competition made
it a virtual marketing necessity to compromise on that. I am distressed
(to say the least) that an engineer (who should appreciate the value of
The Right Thing) is attempting to make it less feasable for us to compete
with real features, and more necessary for us to compromise the integrity
of our product with poorly conceived features.
I do not speak for Network Associates, but do note that:
A.) They own us now, and
B.) They are the largest security software developer in the world, and
C.) If Ballista is what my team could build with a tiny fraction of the
resources that ISS brought to bear on ISS 5.0 for NT, what do you
expect from us when we're actually funded, supported, and compensated?
Not that I'm smug or anything.
>What you're missing is that some people want to use the tool for
>auditing,
>and others want to use it for penetration testing.
[ lots of other similar comments elided ]
Mr. LeBlanc, apparently you do not understand what "penetration testing"
means; if you did, you wouldn't be claiming that Ballista is a
penetration-testing tool. Allow me to explain.
The purpose of a penetration test is to determine the IMPACT of
vulnerabilities on a network. Rather than cataloging the list of all
present security problems, a penetration test attempts to excercise a
subset of them, in order to determine what level of access can be gained
by leveraging enhanced access from various vulnerabilities.
If you think of the whole system of security flaws present in a network as
a graph or a tree, you can think of "penetration testing" as a "depth"
probe. What you are apparently referring to as an "auditing" tool is, on
the other hand, a "breadth" probe --- typically, "how many problems are
there one level deep", or, more succinctly, "how many problems are exposed
to the network".
Neither your product nor mine are "penetration testing" tools. Neither ISS
nor Ballista are designed to survey the overall impact of present
vulnerabilities. In fact, if one of us has a tool that is MORE like a pen
test tool than the other, it is ISS for NT 5.0 --- you use access obtained
from null-session access to the "winreg" pipe (in and of itself a
vulnerability) to probe for localhost problems.
Of course, I take your meaning when you make the obviously false claim
that we're a "penetration testing" product. What you are saying is that
Ballista has limited value to "real" IT people, because it either finds
holes that aren't relevant, or, as the WheelGroup people were fond of
saying, it "operates from the mindset of a hacker". That you are blatantly
wrong is besides the point.
However, before we continue this discussion, it would be a good idea if
you would try to avoid slandering the many people who do real work in
penetration testing by attempting to equate "pen test" with "black hat".
In any case, to wrap this (particularly dumb) sub-argument up, ISS 5.0 for
NT and Ballista 2.4 do the same thing. Both of our programs are "auditing"
tools. They both present a report of all present security flaws on a
network. The difference is that the time you spent adding support for NT
localhost checks, we spent adding support for things like firewalls, DNS
servers, authentication systems, and Unix servers.
Unfortunately for us, real security checks are much less sexy than "140 NT
checks!" and "line-manager technical reporting capabilities". I guess
that's what my team got for recruiting security developers rather than
marketing people (we had none prior to the NAI buyout) and UI developers
(we had none prior to the NAI buyout).
Speaking of that "140" number...
I find it extremely interesting that you felt it quite appropriate to
interject that comment ("we have 140 NT checks, they have 30"), prior to
anything anyone from SNI said... but, when asked to actually justify that
figure, well, now we're asking you to "do our marketing research".
Why on Earth would we want to take our cues from a company that counts as
individual checks the following (from both your manual and your "policy"
configuration tool):
Auditing: System Success
Auditing: System Failure
Auditing: Logon Success
Auditing: Logon Failure
Auditing: Object Success
Auditing: Object Failure
Auditing: Privilege Use Success
Auditing: Privilege Use Failure
Auditing: Detailed Tracking Success
Auditing: Detailed Tracking Failure
Auditing: Policy Change Success
Auditing: Policy Change Failure
Auditing: Account Management Success
Auditing: Account Management Failure
Whoah! That's 14 of your 140 checks right there! I am NOT MAKING THIS UP.
You REALLY ARE CLAIMING that these constitute FOURTEEN INDIVIDUAL CHECKS.
Apparently, ISS is banking on the fact that their customers won't notice
the fact that they count checks in a manner very different from that of
the Ballista development team.
This isn't the only place where the checks are obviously tallied
differently from us. For instance, let's look at your "users with
privilege XXX" series of checks:
Privilege: Act as System
Privilege: Add Workstation
Privilege: Backup
Privilege: Change System Time
Privilege: Create Pagefile
Privilege: Create Permanent Object
Privilege: Create Token Name
... I don't have the time to type all these in. Needless to say, ISS 5.0
for NT counts EVERY SINGLE EXTENDED PRIVILEGE A USER CAN HAVE in Windows
NT as a SEPERATE CHECK. We also have such gems as:
POSIX Enabled
OS/2 Subsystem Enabled
Note that there are no published security problems with either of them...
but who needs to do research to invent new vulnerabilities? No! We'll just
claim that they're insecure because "Windows NT was C2 evaluated with the
XXX subsystem disabled".
In fact, if we go and collapse all the "auditing enabled" checks into one
check, all the "user has extended privilege blah" checks into one check,
you lose THIRTY FOUR CHECKS. That's THIRTY FOUR CHECKS your company
FABRICATED as a marketing ploy to convince your customers that you're more
"comprehensive" than the competition... and that's just from two examples
from your check list!
See, Mr. LeBlanc, it doesn't look like we will ever catch up to that "140
checks" number... because we simply aren't going to lie to our customers
about the number of problems we find. If a product is released from us
that checks for problems within the NT localhost scope, you can bet that
we're not going to try to con our users into thinking every possible
configuration variation is a seperate vulnerability --- and if we do,
well, we all know why we'll have to do that.
There are definitely things ISS has over Ballista (in it's 2.4
incarnation). ISS has better reporting than Ballista. If you need to be
able to take the output of your scanner and feed it directly to your
clients as an audit report, ISS has winning capabilities. ISS has a better
looking UI that the NT version of Ballista. And damn, that splash screen
that pops up when you first start Internet Scanner... well, that's just
beautiful.
But in terms of real security features? Unless you think that an
unpassworded screen saver (one of those 140 checks they have) is more
important than SNMP vulnerabilities, broken CGIs, vulnerable DNS servers,
misconfigured routers, or break-root RPC problems, I don't think it's much
of a contest right now.
Unless you're really into pretty splash screens.
> There are lots of things that we can do to improve our "coverage of
the
> security of NT". In the past, we have chosen not to do the ones that
we
> consider unreliable or less meaningful than the rest of our checks.
> Localhost security problems are among these; our opinion has always
been
> that the only real way to do localhost scanning is to have a localhost
> scanner (ISS has such a product, we do not).
>
> That said, the reason we have thus far chosen not to do localhost
checks
> are:
>
> 1.) They are less meaningful in a "remote" context than the rest of
the
> problems we find; Ballista currently operates under the assumption
> that remote command execution access to a machine equates
directly
> to system/root access.
Having a scanner find vulnerability information by exploiting a remote
weakness is valuable, and since your product, Ballista, is unable to
do it, your claims are stemming from a blatantly biased viewpoint.
Some people like the fact that when Internet Scanner is testing their
NT machines, it is able to pull critical information if available,
like what security patches and hotfixes have been installed.
>
> One reason that does NOT apply here:
>
> 5.) It would be harder for us to do.
>
> (Nope, registry analysis is much easier than, say, DNS checks).
Curiously, how would you know? You claim your product lacks that
feature. In my opinion, saying DNS checks = harder would be wrong.
DNS is very well documented protocol with source code available to
anyone. To understand DNS completely takes a lot shorter learning
cycle than to know all NT registry values and what they mean. On the
other hand, all the registry keys and values are not very well
documented, the source code is not public, and the number of security
related issues is much bigger.
> I expect that if you had a check in that arsenal of 100 NT checks
that we
> thought was valuable, we would add it. Our hope is that we will not be
> forced by marketing claims to add checks that we don't think fit
into the
> scanner, so, hopefully, we won't be catching up to that "140 NT
checks"
> number of yours anytime soon in our remote scanner.
Interesting to note that you won't be adding NT checks.
>
> > Regardless of any of your other points, the fact remains that you
are
> > very
> > far behind in this area.
>
> We disagree on this point; I don't think not including bogus checks
puts
> us behind you technologically, and I think it puts our integrity in
front
> of yours.
Your claiming that the security checks are bogus? Because they really
don't test anything or is it because your product currently lacks it?
>
> I didn't start this discussion, I merely responded to a point you made
> that I think was misleading. Since the road has been paved for us to
> actually compare our two products, let's talk about some "strengths"
of
> our product over yours --- and let's see whether the typically
clued-in
> readers of the "firewalls" list think these are more important than
> unreliable localhost NT checks:
>
> - The Ballista scanner has a framework for real packet filter testing
> using the CAPE system, something we invented and which is unique to
> our product. No other security scanner on the market can test packet
> filters in the same manner as we can.
If I recall correctly, a publicly available program for real packet
filter testing called IPsend from Darren Reed was around long before
SNI and CAPE existed. You might as well as claim you invented the
wheel.
>
> - The Ballista scanner has a framework for server-to-server DNS checks
> which allows us to test for complex DNS server vulnerabilities
> conclusively (by measuring the effects of their presence, not by
> trying to grab VERSION.BIND records). No other security scanner on
the
> market can gauge vulnerability to cache corruption attacks in the
same
> manner as we can.
You can test for many vulnerabilities different ways. Are you
claiming none of Ballista checks make use of any version numbers? Or
is that too "bogus" for you?
The overall result however you test for security issues is that the
administrator knows what they need to fix.
>
> - The Ballista scanner performs most of the REAL Windows NT checks we
> do from both our NT and Unix platforms. We have commited to support
> the Unix platforms we claim to support, and will continue to do so.
From what I know about Unix and NT, doing NT registry analysis from
Unix is non-trivial and significantly more work. If you want to catch
up and follow ISS, your Unix platforms would be lacking in that
capability.
>
> - The Ballista scanner includes checks for many vulnerabilities that
our
> organization discovered and promptly published; we have never
attempted
> to market an "X-Force" vulnerability team, even though our
vulnerability
> research has (on the surface, at least) been vastly more productive
> than yours. The readers of this list know about problems like the
IMAP
> overflow, the Ascend denial of service problem, and CheckPoint
problems
> because of us, and, because we found the problems, we consistantly
have
> checks before ISS does.
If you read your own advisories, like Checkpoints, problems that you
claim to have found were given credit to others: "The information
provided in this advisory was provided to SNI by Steve Birnbaum
<sb...@security.org.il>". Not a big deal, but your claims are
overstated and misleading. This seems like a common theme in all your
posts I read...
> I continue this argument because I work on Ballista and I have pride
in my
> work and in the capabilities of my team. I believe that we have
> consistantly tried to do The Right Thing, even when our competition
made
> it a virtual marketing necessity to compromise on that. I am
distressed
> (to say the least) that an engineer (who should appreciate the value
of
> The Right Thing) is attempting to make it less feasable for us to
compete
> with real features, and more necessary for us to compromise the
integrity
> of our product with poorly conceived features.
The Right Thing? I seem to recall a similiar discussion where TIS was
claiming "the right thing" to do was not add a GUI because of
security. So for a very long time compared to the competition, they
did not have a GUI and it seriously hurt them in sales. TIS should've
probably been the #1 security company in the world since they had a
huge lead time being the first firewall company. Their "right thing"
obviously lead them to being close to last place in firewall companies
and finally being bought by an antivirus company.
>
> I do not speak for Network Associates, but do note that:
>
> A.) They own us now, and
From what I understand talking to ][ceman, SNI's lead coder, SNI
lacked those important things in business, like salespeople and a
management team. It's probably a good decision to have sold-out while
you could.
>
> B.) They are the largest security software developer in the world, and
Another claim that is wrong. They might be the largest antivirus
seller in the world, but Network Associates hasn't developed anything
innovative in awhile, they have bought alot of 3rd rate companies and
are trying to be the K-mart of security.
Being a security software developer would indicate you have
developers. After 2 to 3 months of buying most of those companies, Net
Associates has a history of firing the developers of those companies.
They probably are more like the largest security software buyer in the
world, and with all the bloated failing companies they have purchased,
they will make a nice big implosion when sales drop off because they
can't deliver the next set of promised features. To their credit,
they have the best TV "hacker" commercials. Especially the "Basic
Instinct" one where some beautiful girl sits like Sharon Stone, saying
"while you are watching me, whose watching your network?"
>
> C.) If Ballista is what my team could build with a tiny fraction of
the
> resources that ISS brought to bear on ISS 5.0 for NT, what do you
> expect from us when we're actually funded, supported, and
compensated?
With Network Associates entering the firewall market, they will be
competing with Checkpoint, Axent, Cisco, and Microsoft. TIS was way
behind Cisco Pix and Checkpoint, thus Net Associates will be funding,
supporting, and compensating more in strategic areas to try to be #1
in that market.. They can't afford to add resources into all these
companies they have bought. There's a good chance they will be wacking
some more of those sub-companies. The good thing for the developers
in California who get wacked is that there's plenty of demand in
Silicon Valley for engineers.
In my opinion, it is difficult to bring together companies of
different cultures. McAfee had a completely different culture than
Network General, TIS, PGP, etc. Many times, trying to merge all these
companies and cultures together fails.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
> >What you're missing is that some people want to use the tool for
Many people who do penetration testing use tools like network scanners
to quickly identify the current flaws on the network and then manually
exploit those issues and go from there. Therefore it is a tool that
can be used for penetration testing. You are obviously "blatantly
wrong".
> In any case, to wrap this (particularly dumb) sub-argument up, ISS
5.0 for
> NT and Ballista 2.4 do the same thing. Both of our programs are
"auditing"
> tools. They both present a report of all present security flaws on a
> network. The difference is that the time you spent adding support
for NT
> localhost checks, we spent adding support for things like firewalls,
DNS
> servers, authentication systems, and Unix servers.
Last time I looked at Internet Scanner, it had checks for firewalls,
DNS, authentication systems, and Unix servers. You have continued to
research Unix, while ISS has invested in NT checks. Considering the
acceptance of NT in the market place, you are probably putting your
foot in your mouth and will be forced to learn NT security and add
more NT checks.
> Unfortunately for us, real security checks are much less sexy than
"140 NT
> checks!" and "line-manager technical reporting capabilities". I guess
> that's what my team got for recruiting security developers rather than
> marketing people (we had none prior to the NAI buyout) and UI
developers
> (we had none prior to the NAI buyout).
Wow, from your website, SNI had a CEO whose previous failed company
was H2O, an Canadian Nintendo game company that has completely tanked
on the Alberto stock market. SNI had no marketing people, no GUI
people, no salespeople, no management team, just 2 or 3 full-time
"engineers" in Canada and a bunch of remote "security experts" who
developed checks for a network scanner. Paying $26M for SNI, Network
Associates overpaid for the company, but that has been the common
theme in the security market.
If you look at how Ballista development team counts checks, Secure
Network uses the same tallying system. Check out the SNMP checks. It's
all just a dump of SNMP, but you count it as 12 checks. SNI does the
same thing with the NetBios checks as well. Can you believe the
deceitfulness of SNI? Thank heavens they are now owned by such a
moral and ethical place like Network Associates. Network Assoc
(McAfee) never bloats their virus counts...(sarcasm).
SNMP Community check
SNMP MIB-II Miscellaneous data
SNMP MIB-II TCP table
SNMP MIB-II UDP table
SNMP MIB-II Interface Table
SNMP MIB-II Address table
SNMP MIB-II ARP table
SNMP MIB-II Routing table
SNMP LANMAN Miscelaneous information
SNMP LANMAN Service table
SNMP LANMAN Shares
SNMP LANMAN Users
Axent's NetRecon counts grabbing different NIS maps as 22 different
security checks while most other scanners count that as 1 check. But
then again, Axent is counting silly things like the ping time as a
security check, even though I don't think there's much of a security
risk there. Because most scanners make it obvious what checks they
look for, it is easy enough for anyone to look through and count them
however they want. If scanners become more popular, 3rd party testing
organizations might be able to provide an unbiased counting and
comparision of checks. That happened in the antivirus world.
Tom, or maybe you and SNI could write another white paper that
examines all of the scanners and claim to be completely unbiased
again. :)
>
> See, Mr. LeBlanc, it doesn't look like we will ever catch up to that
"140
> checks" number... because we simply aren't going to lie to our
customers
> about the number of problems we find. If a product is released from us
> that checks for problems within the NT localhost scope, you can bet
that
> we're not going to try to con our users into thinking every possible
> configuration variation is a seperate vulnerability --- and if we do,
> well, we all know why we'll have to do that.
Because your new "moral and ethical" boss told you to do it?
>
> There are definitely things ISS has over Ballista (in it's 2.4
> incarnation). ISS has better reporting than Ballista. If you need to
be
> able to take the output of your scanner and feed it directly to your
> clients as an audit report, ISS has winning capabilities. ISS has a
better
> looking UI that the NT version of Ballista. And damn, that splash
screen
> that pops up when you first start Internet Scanner... well, that's
just
> beautiful.
>
> But in terms of real security features? Unless you think that an
> unpassworded screen saver (one of those 140 checks they have) is more
> important than SNMP vulnerabilities, broken CGIs, vulnerable DNS
servers,
> misconfigured routers, or break-root RPC problems, I don't think
it's much
> of a contest right now.
You forget to mention S3 from ISS. That has several hundred more Unix
checks that Ballista lacks.
Uh. Hello? Two developers are arguing about who has the better product. Me
and Mr. LeBlanc are both biased. Obviously so. Nice incisive observation.
> Curiously, how would you know? You claim your product lacks that
> feature. In my opinion, saying DNS checks = harder would be wrong.
[ ... ]
> other hand, all the registry keys and values are not very well
> documented, the source code is not public, and the number of security
> related issues is much bigger.
It's always nice to argue with someone who knows what they are talking
about. Too bad that isn't happening now:
Windows NT registry functionality is exposed through their documented
application programming interface. Obtaining information from the registry
between two Windows NT machines is simply a matter of executing a series
of Win32 calls. The source code for those calls isn't public, but that
doesn't matter --- ISS doesn't need the source code for what they are
doing.
On the other hand, Ballista performs registry checks from Unix. There are
no APIs available to do this. We had to reverse engineer Windows Registry
RPC in order to do it. We did not have the benefit of pre-written
available documented libraries to implement these checks.
There's a reason why we don't perform 80 different registry checks like
ISS does: we avoid localhost checks, and we avoid unreliable checks.
> > scanner, so, hopefully, we won't be catching up to that "140 NT
> checks"
> > number of yours anytime soon in our remote scanner.
> Interesting to note that you won't be adding NT checks.
As interesting as you putting words into people's mouths. Nobody said we
wouldn't be adding NT checks. Of course, that's obvious.
> Your claiming that the security checks are bogus? Because they really
> don't test anything or is it because your product currently lacks it?
Because they really don't test anything.
> If I recall correctly, a publicly available program for real packet
> filter testing called IPsend from Darren Reed was around long before
> SNI and CAPE existed. You might as well as claim you invented the
> wheel.
CAPE is not a packet generator. If you knew what you were talking about
you wouldn't be making that silly argument. CAPE is a system for auditing
packet filters, something you cannot automate with a packet generator.
> You can test for many vulnerabilities different ways. Are you
> claiming none of Ballista checks make use of any version numbers? Or
> is that too "bogus" for you?
Version numbers ("banner" checks) are indeed bogus, and we avoid them
wherever possible. Whenever possible, our checks attempt to excercize the
actual vulnerability; this allows our scanner to be accurate even in the
face of modified banners and related, equally vulnerable derived software.
> The overall result however you test for security issues is that the
> administrator knows what they need to fix.
Unless the product either doesn't find the vulnerability (false negatives)
or finds vulnerabilities which don't exist (false positives).
> >From what I know about Unix and NT, doing NT registry analysis from
> Unix is non-trivial and significantly more work. If you want to catch
You'd be right. Good thing we got that work out of the way, unlike
(apparently) ISS.
> If you read your own advisories, like Checkpoints, problems that you
> claim to have found were given credit to others: "The information
> provided in this advisory was provided to SNI by Steve Birnbaum
That's one advisory. The vast, overwhelming majority are problems we
found, and the Checkpoint problem was the least of them.
> The Right Thing? I seem to recall a similiar discussion where TIS was
> claiming "the right thing" to do was not add a GUI because of
And this is a valid point in this argument how? Your logical conclusion
basically being "it's silly to argue over what the correct thing to do is;
you should just do whatever you want and whatever will get you customers,
because otherwise you will come off like those creepy TIS people."
> > B.) They are the largest security software developer in the world, and
> Another claim that is wrong. They might be the largest antivirus
> seller in the world, but Network Associates hasn't developed anything
You can spin it however you want. The fact remains that NAI is the largest
security software developer in the world.
>On Thu, 4 Jun 1998, David LeBlanc wrote:
>> Well - the guy was asking me about NT. Your "SNMP vulnerabilities, broken
>> CGIs, vulnerable DNS servers, misconfigured routers, or break-root RPC
>> problems" don't run on NT.
>Well, for clarity your above statement is only partially correct:
>1. SNMP Vulnerabilities are plentifull under NT, some much more serious
>than our scanner checks for. I guess this falls into the "I know something
>you don't" category. Tit for Tat I suppose.
Actually, I'm aware of some additional checks which need to be added in
that area. I mis-read what Thomas wrote - I read it as SMTP, not SNMP,
which as you point out is a different issue. I'm with Mike Warfield on
this one - SNMP stands for Security Not My Problem. We may know the same
things here.
>2. DNS vulnerabilities are cross platform, NT has them as does UNIX.
But they tend to be different.
>3. RPC applications under NT are not exactly without blemish either.
Oh, sure - but I don't know of many ways to break "root" with them 8-)
Seriously, there is the firewall misdirection trick, but since there isn't
a fix, we can't very well put it in a scanner.
That's the help system. Look in the database. The help system covers all
three vulnerabilties in one topic, since they are so closely related.
There is sometimes a many to one mapping between vulnerabilities and help
system topics.
[snip - again, please refrain from personal attacks]
>I am wrong. You are right. Freely conceded. This will not be the last
>time this happens. =)
I have to win sometimes... 8-)