[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How To Incident Response



lannoun@runbox.com dijo [Fri, May 12, 2017 at 04:31:11PM +0200]:
> Hi,

Hi,

> I'm performing installation for a "secure" web app.

OK, but I must first point to a minor contradiction here: Your mail's
subject talks about incident response, but you talk here about
"performing installation". Those are two very different (although,
yes, conceptually related) issues.

Before going further to your choice of applications, this first step
requires understanding what is that you are installing: Which kind of
web app? What framework is it built on? Which language does it use?

If you are building your application, start by assessing the
environment you are building against: Look for known vulnerabilities
(i.e. using the CVE database¹), try to assess how frequent and how
deep the impact of said vulnerabilities are. Check how long has it
taken for issues to be accepted / addressed / solved by the authors.

    ¹ https://cve.mitre.org/

Of course, try to choose the framework with the smallest attack
surface (i.e. if your application can do with a minimalistic framework
instead of a full-featured stack, it will probably be better).

On the other hand, if you are installing a known program (either free
or non-free), you should do the same for the program itself, as well
as other programs addressing the same application domain.

That's for installation, of course. But your mail goes on to address
what your mail subject initially suggests:

> I'm starting with psad, and suricata.
> 
> Now I'd like to install Sguil or Snorby or any alternative for packet
> capturing. My problem is that I have to compile myself which we know is not
> the best solution for security.

Keep in mind that for the next release cycle you will probably also
have to self-support Snort², as it will most likely be dropped out of
testing a couple of weeks from now (#861842). Also, Snorby falls in
the case I mentioned above: I quite like developing with Ruby on
Rails... But make sure to properly protect the system that will/would
host Snorby, as Rails has too large an attack surface for
security-sensitive stuff.

    ² https://tracker.debian.org/pkg/snort

The issue with Snorby or Sguil is not compiling them (as they are not
compiled - Ruby and Tcl scripts respectively), but supporting them
(it's up to you to track and update new upstream versions). It *might*
not be much of a burden, but again, check the projects' history; some
pieces of software are a manitenance nightmare.

> Does any alternative exists?
>
> Also, Which tool can mail me if there are any alerts?
> 
> Any other tools that I should consider?

There are many, many tools that can help you here - but they all
depend on you being skilled using them. Intrusion prevention/detection
and incident response are not really tasks that can be fully
automated. 

I suggest you take a look at several of the packages that 'apt search
intrusion detection' give you; you will find several quite old
(although good!) tools as aide or snort; you will find many tools for
file-based IDS/IPS (and it seems you are looking for a network-based
one).

To be honest, a long time ago I did have an IDS system, but in the end
I ditched it — Profiling what's "normal" and "abnormal" activity,
understanding what appears in your correlator, needs a lot of
site-specific, knowledge-intensive work. A useful IDS will also demand
a high CPU load, and strategic placement in your network
infrastructure. Of course, it depends on your network's needs; given
that I'm "just" the network administrator for a smallish research
institute with few network-exposed services, we decided after some
months the risks were not worth me devoting an almost full time to
tracking reported incidents.

The difference between IDS and IPS is that the first one reports what
has just happened, and the second actually attempts to block attacks
from succeeding. An IPS is way more powerful, but demands way more
attention - because it can be abused leading to DoS.

Anyway, that's the point of view of a small-scale sysadmin who
*thinks* does some things right :-]

Attachment: signature.asc
Description: Digital signature


Reply to: