Idea Details

Improve Top Secret's preparedness to defend denial of service attacks

Last activity 06-13-2019 09:57 AM
Josef Thaler's profile image
08-27-2015 10:43 AM

Top Secret defends attempts to guess a password by a potential attacker by Option PTHRESH(nn). If a user exceeds the specified threshold by entering the wrong password more than nn times, Top Secret suspends the acid.

 

This mechanism opens a new vulnerability: If another attacker executes automated logins with random passwords to all acids of a departement, division or system, the organization could get in severe troubles, if all their acids are suspended because of too many wrong-password-attempts. This Kind of attack is called "denial of service attack". The attacker does not hack any password, but paralyzes a whole organisation.

 

In a CA supportcase was clearified: "There is no way to prevent your Scenario". Right, I can not prevent an attacker to conduct an attack...

 

Therefore I suggest to improve Top Secrets preparedness against such attacks by making wrong-password-processing smarter:

either by

- a delay of the negative answer ("wrong password") after a new customizable number of failing attempts for a customizable timeframe,   or

- a new temporary password suspension ("TSUSPEND") after a customizable number of failing attempts  for a customizable timeframe and a "permanent PSUSPEND after a "too many" attempts.

to slow down a running attack and to hopefully keep the organisation operative and provide to possibility to beat the attacker.

 

These or similar ideas (alsways with the focus to also defend D.O.S.-Attacks) are not principally new and are already implemented in up-to-date login mechanisms. And I'd like Top Secret to have this improved security-mechanism too.

 

I'd like to invite you to comment, vote or share an alternative approach to meet this business need!


Comments

06-03-2016 05:10 PM

One more thought:  Some products, like TPX and TSO, will cancel the logon process after "n" invalid attempts.  This isn't prefect, but it DOES make a Denial Of Service attack a little harder to do.  If you make the cancel the login number lower than PTHRESH, you have a little extra margin of safety.

 

OK - Make that TWO more thoughts:  Right now the operator gets a highlighted, non-scrollable message for an invalid MSCA password.  I think this should be available to other IDs, although I wouldn't necessarily make the limit one invalid password (I have fat fingers).

 

- Don

06-03-2016 02:16 AM

another potential measure/improvement against denial of service attacks could be https://communities.ca.com/ideas/235731454 ("Check facility before password"), maybe you might want to have a look ...    

06-01-2016 11:28 AM

Thanks, John, for this suggestion - let's say idea for an effective and flexible approach - I would definitely vote for it! 

05-29-2016 08:06 PM

Rather than make this applicable to all SCA accounts, would an additional attribute, applicable only to administrative accessor IDs, which would cause the operator to be prompted on a pending password suspension, be a better solution?

05-20-2016 11:50 AM

RACF provides a mechanism that requires an Operator Response - to allow the logon of a RACF Special (TSS SCA level) userid after X number of incorrect passwords.     TSS would quickly suspend the SCA accounts - if a script was written to simply attempt to logon multiple times with wrong password and could result in denial of service.

 

Would be great to see a similar OPERATOR Response required for SCA level accounts - that have exceeded the PTHRESH and not lock the SCA accounts out - but allow logon to proceed based upon a live operator response to the System Console and thus prevent a potential denial of service to SCA level accounts.

04-06-2016 11:26 AM

Source-Attributes reflect on source reader or terminal prefixes (r15 command function guide, ninth edition). I don't know and doubt, whether SOURCE(...)-attribut protects from signon-requests via IP, for example ldap or ftp etc. CA Support told me, that the password is checked first....

If SOURCE would work as noted above, it would be necessary, that tss returns a returncode "invalid userid" independent from a correct or incorrect password, to prevent brute-force password-hacking.    

01-06-2016 12:26 AM

Can we get some clarification here?

 

If an accessor ID has one (1) or more SOURCE(...) entries, then if a signon is processed from an unauthorized source and for which an invalid password is concurrently provided, then is the violation recorded as (1) an invalid source of system entry or (2) an invalid password?  If an invalid source of system entry violation is recognized, then does any PTHRESH or VTHRESH processing occur?  For an invalid password violation, it is clear that PTHRESH procssing must occur.

 

John P. Baker

01-04-2016 08:00 AM

Hi all,

 

User ID can be associated with a terminal and that ACID can only be used via those terminals. And anyone, which tries to use my acid cannot issue password verify requests using any terminal that is not defined to my user acid. The user will not be suspended and a message can be displayed like " terminal not authorized", so that I can still work, when someone attempts to suspend my acid.

12-31-2015 01:06 PM

I don't have any suggestion to improve Top Secret with regard to DOS attacks, but I know that z/OS Comm Server have a feature called Intrusion Detection Services which are designed to detect and take action against DOS attacks. Perhaps stopping such an attack would be better handled at the comm server level than at the security software level.

 

Documentation on Intrusion Detection Services:

IBM Knowledge Center