Hi Doug!

Thank You! Thank You! Thank You! Thank You! Thank You! Thank You!

For finally phasing out the dreaded Demo account!

I have lost count on how many times I had to defend Remedy's honour about
the Demo account and countless more times having to either delete the
account or set a password for that account where no one has bothered to
give it a password before.

Again, Thank you!


Best Regards,

Theo


PS: I feel sorry for whomever is working at the Target IT Dept.
That's some serious bad luck they had. They must be facing some tough times
now.
Hope things turn out OK for them and hopefully the perpetrators are brought
to book soon.
One can already think about some "hacking Target" jokes doing the rounds
later...




On Thu, Jan 30, 2014 at 10:19 PM, Mueller, Doug <[email protected]>wrote:

> An update on this....
>
> Actually, a feature change that I knew was in the works has already been
> done in
> the shipping product (I was a bit behind).
>
> Everything is still the same from the original message...  EXCEPT for the
> Demo
> user.
>
> In the current release (and going forward of course), we DO NOT create a
> user named
> Demo -- you specify the user to create at installation for that initial
> user.  So,
> there is no longer a Demo user to worry about.  That is unless you have an
> older
> install and that user is still hanging around from that previous version
> -- and
> it is safe to remove them.
>
> So, the only known password is if WE create the DB (and again, you can do
> that
> create if you want to control even that) and we strongly recommend you
> change
> that after the initial installation.
>
> Doug Mueller
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList) [mailto:
> [email protected]] On Behalf Of Mueller, Doug
> Sent: Thursday, January 30, 2014 9:19 AM
> To: [email protected]
> Subject: Re: Target Attack and BMC Software ITSM?
>
> Everyone,
>
> Just to be clear about the Remedy environment and passwords:
>
> 1) There are absolutely NO backdoor passwords that are used for system
> access that
>    are not visible and under the control of the Administrator.
> 2) Since about 7.0, we have REQUIRED that you supply a password for the
> system
>    users -- Remedy Application Password, DSO  (there is no password for
> Escalator)
> 3) Yes, there is a default Database password to get started -- and you are
>    encouraged to change it immediately.
> 4) Yes, there is a default user installed (Demo) to give a starting point
> -- and
>    you are encouraged to change it or delete this user immediately  (and
> all of the
>    installers have been corrected for several years now to not look for a
> user
>    named Demo)
>
> So, there are no secret back doors to the system that would provide access
> and there are only two cases where there is even a temporary default
> password -- if WE create the DB, we need to do something and then you
> change it and this can be worked around if you create the DB and give us
> the information  AND  the Demo user that is loaded to give you initial
> access into the system (you have to get in somehow the first time).
>
>
> Again, if you have not changed either of the two passwords noted here, you
> should do that immediately and on every system.  Otherwise, there is no
> issue within the product around this topic.
>
> Now, there are a bunch of other security settings that I encourage you to
> use --
>
> -- restrict where run processes can run processes
> -- control the shell under which processes can run
> -- use the password management feature to enforce password rules
> -- use the feature that disables an account after x bad password attempts
>       (and make x a relatively small number like 5 or at most 10)
> -- disallow blank passwords (except for AREA cross-reference situations)
> --  and a number of other things
>
> We encrypt passwords on the wire.  We in fact default encrypt the entire
> traffic on the wire (with higher levels of encryption than the default
> available if desired).  We use a connectionless protocol with user
> validation at every call to ensure that you are who you say you are to
> prevent piggybacking connections.
>
>
> Remedy should not be vulnerable to attack of the kind described unless you
> have opened your systems to the outside and have not followed suggestions
> of changing the to key initial passwords (I would consider changing the DB
> name from ARAdmin as well just to make it that much harder to find -- and
> that is fully supported).
>
> Doug Mueller
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList) [mailto:
> [email protected]] On Behalf Of Pierson, Shawn
> Sent: Thursday, January 30, 2014 5:31 AM
> To: [email protected]
> Subject: Re: Target Attack and BMC Software ITSM?
>
> I read the article and clicked on the link to the Krebs on security site.
>  Based on that site, which may or may not be correct, it's saying that the
> potential BMC product is BMC Performance Assurance Agent.  Since this isn't
> a part of Remedy I really have no idea how it works and if there is a back
> door or if it was installed and they forgot to change a default password.
>
> In any case, it's not Remedy, so that's a good thing.
>
> Thanks,
>
> Shawn Pierson
> Remedy Developer | Energy Transfer
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList) [mailto:
> [email protected]] On Behalf Of Jeff Lockemy
> Sent: Thursday, January 30, 2014 7:23 AM
> To: [email protected]
> Subject: OT: Target Attack and BMC Software ITSM?
>
> This news article hit today...
>
> http://www.startribune.com/business/242688511.html
>
> It says that a default password in a BMC ITSM product may have contributed
> to the target attack.
>
> Jeff
>
>
>
> Jeff Lockemy
> Lead Engineer, NAVY 311
> Enterprise Service Management PMW-240
> ITIL V3 Foundation Certified
> QMX Support Services Inc.
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the
> Answers Are, and have been for 20 years"
>
> Private and confidential as detailed here:
> http://www.energytransfer.com/mail_disclaimer.aspx .  If you cannot
> access the link, please e-mail sender.
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the
> Answers Are, and have been for 20 years"
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the
> Answers Are, and have been for 20 years"
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to