The example below shows a configuration for the service security audit feature in the Windows Communication Foundation (WCF).
The previous configuration file has effectively disabled the recording of security-critical events, which would force the administrator to look to other sources during debug or recovery efforts.
BadXML
<system.serviceModel><behaviors><serviceBehaviors><behavior name="NewBehavior"><serviceSecurityAudit auditLogLocation="Default"suppressAuditFailure="false"serviceAuthorizationAuditLevel="None"messageAuthenticationAuditLevel="None" />... </system.serviceModel>
The example below shows a configuration for the service security audit feature in the Windows Communication Foundation (WCF).
The previous configuration file has effectively disabled the recording of security-critical events, which would force the administrator to look to other sources during debug or recovery efforts.
GoodXML
<system.serviceModel><behaviors><serviceBehaviors><behavior name="NewBehavior"><serviceSecurityAudit auditLogLocation="Default"suppressAuditFailure="false"serviceAuthorizationAuditLevel="SuccessAndFailure"messageAuthenticationAuditLevel="SuccessAndFailure" /> ... </system.serviceModel>
In the following Java example the code attempts to authenticate the user. If the login fails a retry is made. Proper restrictions on the number of login attempts are of course part of the retry functionality. Unfortunately, the failed login is not recorded and there would be no record of an adversary attempting to brute force the program.
It is recommended to log the failed login action. Note that unneutralized usernames should not be part of the log message, and passwords should never be part of the log message.
BadJava
if LoginUser(){ // Login successful RunProgram(); } else { // Login unsuccessful LoginRetry(); }
In the following Java example the code attempts to authenticate the user. If the login fails a retry is made. Proper restrictions on the number of login attempts are of course part of the retry functionality. Unfortunately, the failed login is not recorded and there would be no record of an adversary attempting to brute force the program.
It is recommended to log the failed login action. Note that unneutralized usernames should not be part of the log message, and passwords should never be part of the log message.
GoodJava
if LoginUser(){ // Login successful log.warn("Login by user successful."); RunProgram(); } else { // Login unsuccessful log.warn("Login attempt by user failed, trying again."); LoginRetry(); }
Consider this command for updating Azure's Storage Logging for Blob service, adapted from [REF-1307]:
The "--log d" portion of the command says to log deletes. However, the argument does not include the logging of writes and reads. Adding the "rw" arguments to the -log parameter will fix the issue:
BadShell
az storage logging update --account-name --account-key --services b --log d --retention 90
Consider this command for updating Azure's Storage Logging for Blob service, adapted from [REF-1307]:
The "--log d" portion of the command says to log deletes. However, the argument does not include the logging of writes and reads. Adding the "rw" arguments to the -log parameter will fix the issue:
GoodShell
az storage logging update --account-name --account-key --services b --log rwd --retention 90
Consider this command for updating Azure's Storage Logging for Blob service, adapted from [REF-1307]:
The "--log d" portion of the command says to log deletes. However, the argument does not include the logging of writes and reads. Adding the "rw" arguments to the -log parameter will fix the issue:
GoodShell
Set-AzStorageServiceLoggingProperty -ServiceType Queue -LoggingOperations read,write,delete -RetentionDays 5 -Context $MyContextObject