RES: Exploits start against flaw that could hamstring huge swaths of

Tue Aug 4 17:27:15 UTC 2015

hi ya

> >> On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms <khelms at zcorum.com> wrote:
> >> > With the (large) caveat that heterogenous networks are more subject to
> >> > human error in many cases.
> >>
> >> <cough>automate!</cough>
> >>
...

On 08/04/15 at 12:21pm, Christopher Morrow wrote:
> On Tue, Aug 4, 2015 at 11:46 AM, Scott Helms <khelms at zcorum.com> wrote:
> > Automation just means your mistake goes many more places more quickly.
> >
> 
> and letting people keep poking at things that computers should be
> doing is... much worse. people do not have reliability and
> repeat-ability over time.

ditto ...
computers are experts at listening and repeatatively doing what it's 
told to do ..

> If you fear 'many more places' problems, improve your testing.

i prefer automation .. even if it's wrong, you can look at the script
and see what bad things it did and you should know what to do to fix
the problem and fix the script to prevent it from spreading that mistake 
again

<person's standard excuse>
if you ask a person(s), what did you do to create this mess, "duh... i donno"
btw, it's my kids birthday, i needed to be home an hr ago with the cake :-)

hummm... :-)
</standard>

-----

<fwiw>
for automation to work:
- folks updating the scripts should be required to know all platforms being 
  used and how its different from each other 

- folks testing the scripts/updates process/proceedures should be paid
  bonuses, even free pizza/beer for finding bugs before release to the 
  your internal world of automated-machines

- always have 3 co-developments boxes for the script develpment and
  to backup each other 

- always have 2 or more test bed boxes for initial releases of new scripts
  where those boxes can also be downgraded back to the previous release
  before the new patches was applied

- if nothing went wrong, there should be minimal issue with release a 
  patch where it doesn't propagate "problems automatically to everywhere"

  the trick is "how good are the eyes/brains" that is looking for 
  potential problems of the new releases/patches/updates/etc

- i also say always let clients pull down patches vs pushing it to
  systems that seems un-responsive to avoid having to wait for dead boxes

-----
all appps, not just bind, has occasional problems .. changing to something
else doesn't necessarily solve the original "bug" problem

pixie dust
alvin
# ddos-mitigator.net