'IT Security' in comps?

[Till Maas]

On Fri, Aug 07, 2009 at 10:48:34AM -0400, Bill Nottingham wrote:
> Till Maas (opensource at till.name) said: 
> > I considered IT might be redundant information, too, when
> > I created the groups, but also both the terms "Forensics" or "Wireless"
> > are not IT specific, therefore I put the IT-security explanation into
> > the description. There can be wireless analysis that is not security
> > related, e.g. to find sources of disturbance and there are a lot of
> > forensics tasks that are not IT-security related, but still could be
> > assisted via software.
> 
> Rather than going back and forth about concepts, I might as well just
> describe how I would organize what you have now:
> 
> network-debugging
> - Network Analysis Tools
> - Tools for analyzing and securing computer networks.
> 
> (This would include the packages from both your proposed 'reconnaissance'
> and 'wireless' groups, as well as some other tools currently in 'System
> Tools'.)

Imho most of these tools are more helpful to demonstrate security
weaknesses, than to debug faulty networks. E.g. it is imho more reliable
to run tcpdump on a host or to plugin a seperate hub, then to use
ettercap to get to analyse the traffic in the network. Most of the tools
are imho primarly useful to perform a penetration test and to
demonstrate the security vulnerabilities for a customer.

But in general a network-debugging group would be useful, too.

> forensics
> - Computer Forensic Tools
> - Tools for performing computer forensics and data recovery.
> 
> (I'd move the password tools here, as well. Not sure how clamav fits here;
> I think its current placement at the mail server level makes more sense.)

Password recovery tools do not really fit into the forensics group, too.
If forensics are performed to analyse a security incidense, one normally
does not need to recover passwords to get a timeline of what happened.
It might be used as an interem step in forensics performed by the police
to get to e.g. acquire the password of a encrypted volume, but then it
would still not be the primary target of the forensic actions.

> The intrusion detection group looks OK as a concept. As for the code
> analysis group, I'd argue that should be moved into the development
> category.
> 
> Is this something you'd find usable?

It is more usable for me to have these groups than not to have these.
But if I cannot easily install all these related groups, i.e. with one
simple command, without the need to memorize all the separate groups, it
is not useful enough for me, to put much work into it.

> Right now our toplevel groups are:
> 
> - Language support (self explanatory)
> - Desktops (fairly self explanatory)
> - Applications (End-user desktop applications)
> - Development (tools for software development)
> - Servers (various system services)
> - Base system (administration tools, and other components)
> 
> Perhaps a better solution is a new toplevel category of 'System
> Administration' (where most of your new groups would fall under); this
> widens the scope of it from just 'IT Security' to a larger scope
> that fits the existing categories. That might be a larger reorganization,
> though, as the group changes would have to filter down to the various spins.

This sounds sane in general.

> > > - the 'all packages are default' paradigm
> > 
> > I could accept to make packages not default that are e.g. already meant
> > to be deprecated by upstream, like airsnort. But I do not think that the
> > audience of these tools would only want to be presented some random
> > password cracker like it is a guideline to have only one IM client on
> > the Fedora Desktop live image. This is also reflected with the package
> > set of the security live image, which also contains all these tools and
> > not only selected ones.
> 
> Sure, but the live spin can do %group --optional to pull those in. To
> expand on what I said before, we have three main concepts for applying defaults
> in comps:
> 
> - Lots of tools that occupy the same usage case (office tools, etc.)
> 
>   Pick one best-of-breed default, the rest are optional.
> 
> - Lots of tools that occupy the same space, but are not interchangable. (games)
> 
>   Everything's optional. Pick what you want.
> 
> - A basic usage case, with various add-ons and similar tools. (many of
>   the server groups, 'system tools', etc.)
> 
>   A base set that's default; other tools are optional.

Imho it is not that easy to apply this to security analysis. E.g. it is
clear what one wants to do more or less with office tools: Writing
documents. Then it does not matter that much, whether the GUI is
developed for KDE or Gnome. But for a security analysis work, everything
depends on the target network or system. It may and will normally differ
in a lot of ways. Also since the tools may produce different results
(e.g. forensic analysis tools), one would more likely use every tool to
get as much results as possible, instead of only acquiring a subset of
the available information. So to be prepared for these tasks, one needs
more or less have every tool installed.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090811/a0420286/attachment.bin