Am 16.03.2018 um 20:41 schrieb Thomas Reinke:
LOL - you might be saying thank you as you pick up your pink slip/are
escorted out the door for impacting a production system with that
sentiment.
luckily i have the power of control the whole hardware and software
stack and since i am not an idiot such test would happen first late at
night where you can manage such a outage and if it happens the first
task next day would be seek for a replacement
anyways, no attacker ever will care about this and so the outage is
better suited at a planned schedule if it happens than at a random point
in time where nobody expected it and can explain what happend - you get
secorted out the door if your firewall is randomly and repeatly down and
only god knows why because you are nice when testing your things so
everybody but you triggers issues - worthless tests if it is vulnerable
and can be knocked out by anybody but you don't try it
The ultimate answer is dependent upon sensitivities around your assets.
The more sensitive you are, the more you work to manage those
sensitivities.
If nessus didn't present any issues, that's a good sign that your
system is likely robust enough, and I'd frame any plans in that
context (i.e. this is doing exactly what and how the external
contractor did it).
If additional concerns have been raised since then, you simply need
to address those - and they are specific to you (usually not a
technology problem).
In general, concerns are always around the unknowns and 'what if'.
To deal with that:
1) Know when your peak resource load times are (be it CPU, memory,
bandwidth, whatever). Avoid them, unless you of course are
attempting to perform a peak test (but then, that's no longer
a security issue).
2) Know when your peak sensitivity times are (Christmas shopping
season? Hmmm... Time for JD Powers to assess your reliability?
Again...maybe avoid that.
3) Know what controls are in place to keep your assets secure even
if you don't run an audit (regular patching? Keeping abreast
of advisories?).
4) If you are just starting with in-house scanning, roll out your
scanning procedures from least important assets first to the
most important ones last. That will build confidence in the
processes. Include milestones/checks along the way that you can
report back progress to everyone to keep them happy and confident
that the scans will provide information without being disruptive.
There is no one-size fits all. Tailor it to the people that have
a vested interest in what you do and why you do it, and you'll be
in good shape.
Thomas
On 03/14/2018 04:43 PM, Reindl Harald wrote:
Am 14.03.2018 um 21:06 schrieb Eero Volotinen:
I usually prefer lower scan speed as too intensive can crash firewall
devices..
if a security scan from a single node crashs your firewall device you
should say "thank you" for konwing that this crap needs to be replaced
ASAP
real attackers don't care as you do
14.3.2018 22.01 "TJ" <j...@twcny.rr.com <mailto:j...@twcny.rr.com>>
kirjoitti:
I would exclude networked printers as the scans can cause them to
produce volumes of printed gibberish (found out the hard way)
Yes, definitely scan during maintenance windows/non-business hours
until you see how well it plays in your environment. Not to mention
with less network traffic and systems activity, the scans should
finish a lot sooner
On 3/14/2018 3:53 PM, Peter Collins wrote:
(Sorry if this is a repost. I had a technical issue with my first
attempt)
I would like to use OSSIM's OpenVAS component to run asset and
vulnerability scans on both prod and non-prod. Like every place,
we want to make sure the IT infrastructure is not harmed or
jeopardized.
So what is due care when introducing scanning? Should I do the
asset scans only during maintenance windows to start off, to make
sure nothing gets broken? Or are the non destructive, non
authenticated scans considered safe enough to run during
production hours, on production assets?
I should add that Nessus has been used by an outside contractor
without issue, on our network.
Thanks so much in advance
_______________________________________________
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
