Guidelines For Effective Monitoring and Response

Author: Prabu Karuppiah

Unfortunately, it's that time already, and we are on the final article of this security series we started in January. However, this final article is a great ending point to consider when approaching your security guidelines for effective monitoring and responses. We already covered the potential dangers of undetected breaches (an average of 9 months, by IBM's estimates) without sufficient logging and monitoring mechanisms in place in our previous post.

A crucial point to remember is not to generalize threat actors' behaviors. Their patterns will constantly change, and you could be caught unawares. For instance, one threat actor may be loud and obvious in their attack, but another could adopt the exact opposite approach and try to stay invisible and cover their tracks to remain in your system for as long as possible, allowing them time to gather as much data and resources through their attack as possible. Having said that, good security related alerting and monitoring capabilities can be an effective counter to different types of threat actors. Let us see how, through some real world examples:

Security Logging and Monitoring Failures:

This category of issue typically occurs when the necessary information does not get adequately logged or when sensitive information like PII is logged when it should not be. The real issue is when this is paired with other exploits, making it a gold mine for threat actors. Let's explore 2 examples to illustrate the potential risk and provide some mitigations (a third example can be found in the full article).

Example Scenario 1:

A children’s health plan provider website was attacked by a Threat Actor who accessed and modified the sensitive health records of more than 3.5 million children. The provider didn’t realize the vulnerability until an external party informed them. A post-incident review showed that no logging and monitoring was in place, and the breach could’ve been in progress for more than seven years.

Possible Mitigations:

• Ensure that you have a logging and monitoring system, that is has been implemented correctly, and is up to date to ensure that breaches get detected as soon as possible. 
• Set periodic monitoring of your applications to keep on top of the overall health of your applications and to to flag any changes (Positive or negative)

Example Scenario 2:

Logging user-entered details without neutralizing them may lead to incorrect analysis, which a threat Actor can use to either cover their tracks or implicate an innocent user in this attack.

function getMonthNameFromMonthNo(monthNo) {

  const months = [

   "Jan", "Feb", "Mar", "Apr", "May", "Jun",

   "Jul", "Aug", "Sep", "Oct", "Nov", "Dec",

];

  if (months[monthNo]) {

return months[monthNo];

  } else {

logger.info('Invalid Month number: ' + monthNo);

throw new Error('Invalid Month value')  }

When a user submits 42 as the month value then it logs the following

INFO: Invalid Month number: 42

But the attacker can submit a string with value "42\nINFO: Transaction is successful for user: victim name" which would result in logs

INFO: Invalid Month number: 42

INFO: Transaction is successful for user: victim name

Threat Actors can now use this strategy to make the logs unreliable while simultaneously covering their tracks to create a double threat.

Possible Mitigations:

• The first rule is to determine if the data being written to logs is considered sensitive information. If it is, strongly consider not recording it to the logs.
• Keep in mind that configurations need to be adjusted accordingly when an application moves across different environments (for instance, from development to production)

Best practices:

As best practice, document auditable events and ensure you share them with all key stakeholders to confirm exactly what needs to be logged. The result from this exercise, if completed correctly, will provide a list of high-value transactions and business-altering transactions that should be audited. The best course of action is to keep track of this information using an append-only storage option, which in turn will prevent Threat Actors from deleting or forging existing entries.

• The application should always log failed logins, validation failures at the server side, permission changes, password resets, who is attempting to login etc. 
• Standardize your log formats and follow them across all the services to ensure proper parsing from log management solution providers. 
• Categorize log levels appropriately into Info, Warning, and Error to help understand messages easily.

The full list of best practices and potential tools are in the full article here!

This marks the end of our first Cyber Security series, and we appreciate you taking the time to join us on this journey. We will be back soon with more exciting content geared towards engineering challenges faced by early-stage startups.

I hope you enjoyed this article, and please subscribe for the upcoming articles!

The Archimydes team